Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DeNA の次世代ゲームを支える Takasho と Google Cloud の活用/goo...

DeNA の次世代ゲームを支える Takasho と Google Cloud の活用/googlecloudinsidegamesandapps_motohironakamura

ディー・エヌ・エーの次世代ゲームを支える Web サーバーフレームワーク Takasho で、Google Kubernetes Engine (GKE) や Cloud Spanner を中心に、開発環境・本番環境それぞれでどのように Google Cloud を活用しているかを紹介します。

DeNA_Tech

April 07, 2021
Tweet

More Decks by DeNA_Tech

Other Decks in Technology

Transcript

  1. Speaker • 中村 基裕 • 株式会社ディー・エヌ・エー (2019 ~) • ゲーム事業本部

    • リードエンジニア • Takasho のインフラを管理 2
  2. 6 Takasho の特徴 • クライアントに寄せたゲームロジック • データの生成・保存はクライアントの責務 • クエスト報酬、スコア計算など •

    サーバーが負う責務 • 時刻や確率に依存する処理 • ガチャ、ログインボーナスなど • アイテムを付与する経路や量を固定化 • 仮想通貨の付与、ミッション報酬など • 運営からのアクション
  3. 12 本日紹介する事例 • Cloud Monitoring を活用した Pod の水平スケール • Cloud

    Pub/Sub を使ったバックグラウンド処理 • スパイクにも耐えるCloud Spanner のオートスケール
  4. 13 本日紹介する事例 • Cloud Monitoring を活用した Pod の水平スケール • Cloud

    Pub/Sub を使ったバックグラウンド処理 • スパイクにも耐えるCloud Spanner のオートスケール
  5. ゲームAPI の水平スケールの設計 • 何を基にスケールするか • I/O バウンドなワークロード特性 • ゲームロジックをクライアントに寄せているため •

    ほとんどが DB の読み書き、APIコール • 秒間リクエスト数 (RPS) を指標に選択 • Pod 数(並列数)を増やすことでスループットが向上 • しきい値の設定 • 負荷試験でスパイクを再現 • 早めに Pod 数を増やせるよう敏感な設定に 14
  6. 外部指標の取得 • 秒間リクエスト数をどこから取得するか? • Custom Metrics API • ユーザーが定義したメトリクスを取得する仕組み •

    Cloud Monitoring API を利用 • Takasho とは独立したサービス • 高負荷時でも安定してメトリクスを取得 • 独自のPrometheus は採用せず • これ自体の管理が必要 15
  7. Cloud Monitoring を活用した Pod の水平スケール • 採用して良かった点 • 自身のシステムとは独立 •

    RPS を取るための手間(準備)がほぼ無し • HTTP LB の指標がすでに用意されている • 導入に苦労した点 • 取得できるメトリクスが 1分以上前のもの • 早めにスケールするように調整 • バッファーを用意 18
  8. 19 本日紹介する事例 • Cloud Monitoring を活用した Pod の水平スケール • Cloud

    Pub/Sub を使ったバックグラウンド処理 • スパイクにも耐えるCloud Spanner のオートスケール
  9. Cloud Pub/Sub を使ったバックグラウンド処理 • 時間のかかる処理はバックグラウンドで実行 • MBaaS との連携 • 仮想通貨の消費・追加

    • 大量のログの整形・送信 • 重いリクエストのレイテンシを一定の水準に保てる • 主にI/O 待ちの長いようなリクエスト 20
  10. メッセージの配信順序はデフォルトでFIFOではない • デフォルトでは順序はバラバラ • FIFO を期待して処理すると思わぬ結果になる • 対策 • Pub/Sub

    から受信した順番で処理しない • キーとなる値をメッセージに含める • キーから一連のタスクを取得し処理 29
  11. Takasho でとった対策 • シーケンシャルな処理はPub/Sub のメッセージ順に依存させない • 仮想通貨の場合 • Pub/Sub からは対象のプレイヤー

    ID を受け取る • 対象のプレイヤーの未処理のタスクを DB から作成日時順に取得 • 順にタスクを処理 36
  12. Pub/Sub を使ったバックグラウンド処理 • 採用して良かった点 • 高い可用性 (>= 99.95, pubsub/sla) •

    仮想通貨やログ送信などの重たい処理がバックグラウンドで処理可能に • API のレイテンシを一定水準に • 導入(後)に苦労した点 • リリース後に想定していないエラー • 仮想通貨・ログの処理遅延 • 遅延したときの対応を想定しておく 42
  13. 43 本日紹介する事例 • Cloud Monitoring を活用した Pod の水平スケール • Cloud

    Pub/Sub を使ったバックグラウンド処理 • スパイクにも耐えるCloud Spanner のオートスケール
  14. Takasho でのCloud Spanner の活用 • 開発環境 • シングルノードインスタンス • 環境ごとにデータベースを作成

    • 本番環境 • 従来タイトルと比べると費用がケタ違い • 負荷に応じてノード数を調整することがコスト観点で重要 44
  15. Takasho でのCloud Spanner のオートスケール • 通常時 • メトリクスに基づいてスケール • ガチャ開始前後

    • 事前に指定したノード数に増やしておく • 開始後一定時間はノード数を維持 • メトリクスに応じたスケールアウトのみ許可 60
  16. Takasho でのCloud Spanner の活用 • 導入して良かった点 • シャーディングが不要 • コードがシンプルに

    • ノードの増減が簡単 • リリース時に多めにし、後から縮退が可能 • 導入(後)に苦労した点 • Split についての理解 • どうやってウォームアップするのか? • Spanner の費用が特に大きい • オートスケーラーの導入で最適化 • 開発環境のコスト削減は今後に期待 61
  17. 63 本日紹介した事例 • Cloud Monitoring を活用した Pod の水平スケール • Cloud

    Pub/Sub を使ったバックグラウンド処理 • スパイクにも耐えるCloud Spanner のオートスケール