462 Views
September 24, 24
スライド概要
Serverless Days Tokyo 2024
Breaking Downは現在若年層を中心に注目されている格闘技のイベントです。スタートアップとして限られたリソースの中で、Cloud RunやTiDB Serverlessなどのサーバーレス技術を中心にどのようにBreaking Downのライブ配信サービスを構築していったのかをご紹介します。
サーバーレスで構築する Breaking Down LIVE Serverless Days Tokyo 2024 BACKSTAGE, Inc. Yuto Akiba (@akkey0222) © 2024 BACKSTAGE Inc.
自己紹介 秋葉 祐人 / Yuto Akiba @akkey0222 @touyu 2018年にスタートアップを共同創業し、クリエーター支援プラットフォームを開発。 2022年から株式会社BACKSTAGEにジョイン。 複数の事業を横断しつつ、バックエンドを中心に担当。 © 2024 BACKSTAGE Inc.
© 2024 BACKSTAGE Inc.
アプリ Breaking Down Club XD(音楽フェス) Wavers(朝倉海さん) etc... © 2024 BACKSTAGE Inc. ライブ配信
Breaking Down LIVE とは? Breaking Downのイベントを リアルタイムで視聴できるサービス •主な機能 •PPVでのチケット購入 •コメント機能 •出演者へのギフト機能 •ユーザ参加型の投票機能 © 2024 BACKSTAGE Inc.
Breaking Down LIVE の背景 • 元々別の企業が運営していたシステムを買収し運用 • 旧システムの構成 • Amplify(S3 + CloudFront) • Cloud Firestore • Cloud Functions • 最初は問題なく運用できていたが、あるとき配信中に障害発生 © 2024 BACKSTAGE Inc.
障害の原因 • Firestoreの利用方法に問題 (※Firestore自体が悪かったわけではない) • コメント内のユーザの情報を個別かつキャッシュなしに取得していた • Firestore側でホットスポットが発生、読み書きのレイテンシーが急増 秒間コメント数 x 表示コメント数 x 視聴ユーザ数 = 推定数百万QPS Firestore © 2024 BACKSTAGE Inc.
旧システムの課題 • コード上の負債が増大 • フロントエンドから直接Firestoreを呼び出し実行しており、 コアな業務ロジックとViewのコードがごちゃまぜに、、 → 安定した配信と効率良い開発のためにリプレイスを決断 © 2024 BACKSTAGE Inc.
リプレイスの注力ポイント • 安定した配信を行えるように • 開発コスト、運用コストはできる限り抑えたい • エンジニアは正社員2名程度 • アプリケーションのコアな機能開発に意識を向けたい • インフラコストもできる限り抑えたい © 2024 BACKSTAGE Inc.
リプレイス時の課題 負荷予測が困難 • イベントや興行ごとにトラフィック量が大きく異なる • 不定期で発生するスパイク • ユーザの投票タイミング • PPVの購入タイミング 最大約50倍の 秒間リクエスト数 • 専任のインフラエンジニアがいない © 2024 BACKSTAGE Inc.
アプリケーションサーバーの選定 • Vercel (フロントエンド, Next.js) • Next.js, Turborepoとの相性 • PRごとのプレビュー設定の容易さ(Cloud Runでも可能ですがより手軽) • 静的コンテンツを自動でキャッシュしてくれる(CDN) • Cloud Run (バックエンド, TypeScript) • 他のGoogle Cloud サービスの相性の良さ • 高いスケーリング性能 • アクセスがない場合はほぼコストがかからない © 2024 BACKSTAGE Inc.
Cloud Run の課題① • ユーザ投票時のピークタイミングでAPI全体で約5sレイテンシー発生 • 原因 • コンテナ起動に時間がかかっていた • Container Startup Latency が P99 で約9s • 急なスパイクにスピンアップが追いつかない © 2024 BACKSTAGE Inc.
Cloud Run のコンテナ起動比較 • 改善前: 約9.02s • Node.js(Fastify): 約2.49s • Go(net/http): 約158ms © 2024 BACKSTAGE Inc.
Cloud Run のコンテナ起動速度改善 • 起動速度の改善案 • 「起動時の CPU ブースト」はすでに有効 • Docker イメージサイズ削減 ※1 コンテナ起動時間のボトルネックにはならない • • デプロイ速度、ビルド速度は向上する • 依存関係の削減 • 特にOpenTelemetryの自動計測を外したときに大きく改善 ※1: Cloud Run 上のコンテナのライフサイクル(https://cloud.google.com/blog/ja/products/serverless/lifecycle-container-cloud-run) © 2024 BACKSTAGE Inc.
Cloud Run のコンテナ起動速度改善結果 • 改善後は約4sにまで下がり、 50%程度改善 • まだ完全にスパイクに絶えられ る状態ではなく、現状は配信直 前に最低インスタンスを設定し 対応 © 2024 BACKSTAGE Inc.
Cloud Run の課題② • コールドスタート問題 • Cloud Schedulerで定期的にヘルスチェックを実行 • 最小インスタンスを1に設定するより低コスト © 2024 BACKSTAGE Inc.
データベースの選定 • 当初は利用経験のあったCloud SQLなどのマネージドなDBサービスを念頭に • ピーク時よりバッファをもたせたスペックで対処(力技) • インフラコストの増加 • 実装を工夫する • レプリケーションでは読み取りの負荷は軽減可能、しかし書き込み負荷は減 らせない • シャーディングはシステムの複雑化が避けられず安定運用に不安 & コスト面 はあまり改善されない © 2024 BACKSTAGE Inc.
様々なフルマネージドなDBサービスを探すものの、、 • コンピューティングリソースのオートスケール未対応 • ストレージのスケールのみ対応 • 費用が高い • スタートアップからすると利用料が高い • 未使用の期間にもコストが掛かってしまう • レイテンシーが高い • 日本リージョンが提供されておらず、数百msのレイテンシーが発生するというケースも • NoSQL • NoSQL用の設計を求められるためできれば慣れているSQLを使用したい © 2024 BACKSTAGE Inc.
TiDB Serverless • TiDBとは? • MySQLと互換性のあるOSSの分散型SQLデータベース(NewSQL) • TiDB Cloud • PingCAPさんが提供されているTiDBのマネージドサービス • TiDB Dedicated • TiDBのほぼすべての機能を利用できる • スケールに関してはユーザがリソース管理をする • TiDB Serverless • 自動でスケールする従量課金のサーバーレスデータベース • 機能に一部制限があるもののDedicated より手軽に使用可能 © 2024 BACKSTAGE Inc.
TiDB Serverlessの選定理由 オートスケール 手動での設定なしに自動でコンピューティ ングリソースもスケール可能 高レイテンシー レイテンシー Cloud SQLを使用したときと比較して少し レイテンシーは上がってしまうものの約数 十ms以内で許容できる © 2024 BACKSTAGE Inc. コスト 未使用の期間のコストがストレージ分の 費用のみ MySQL互換 使い慣れているSQLをそのまま使用できる ので追加の学習コストが低い
TiDB Serverlessの懸念点 • 外部キー制約が実験的なサポート • 負荷テストで問題ないこと確認し、現在は有効にして運用 • 問題が発生しても foreign̲key̲checks を無効にすることですぐに対処可能 • Cloud Provider が現状はAWSのみの対応 • AWSを使用している場合は、Private Endpointを使用できるが、 • Cloud RunなどGoogle Cloudをメインで使用している場合はPublic接続を使用すること になる • MySQL100%互換ではない • Triggerが使用できない • UPDATE … SELECT 文が使用できない © 2024 BACKSTAGE Inc.
リプレイスしてどうだったか • 安定した配信 ◎ • 大きなトラブルが発生すること無く運用できている • 開発コスト、運用コスト ◯ • TiDB ServerlessはMySQLと変わらない扱いで実装できており、スペック調整なしで 非常に楽に開発、運用できている • Cloud Runのコンテナ起動速度の問題で、配信直前には設定変更が必要だが、ダウンタイ ムなしで変更可能なため、運用コストは限りなく低く抑えられている • インフラコスト ◎ • 利用が少ない時期はほぼ費用がかからずに運用可能 • オーバースペックになるタイミングが少なくできている • 配信中の料金もリプレイス以前よりも下がっている © 2024 BACKSTAGE Inc.
エンジニア募集しています バックエンドエンジニア Go, TypeScript Webフロントエンジニア Next.js(TypeScript) x.com/akkey0222 モバイルエンジニア Flutter © 2024 BACKSTAGE Inc. https://bit.ly/4cFLtlM
アンケートのお願い アンケート回答者には TiDBオリジナルTシャツ を プレゼント! ※回答期限は2024年9⽉21⽇(⼟) 16:00まで。 受取場所:PingCAPブース 受取⽅法:完了画⾯を表⽰ ※枚数やサイズに限りがありま すので予めご了承ください。