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

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

Transcript

1. DeNA の次世代ゲームを支える Takasho と Google Cloud の活用 2021/04/03 株式会社ディー・エヌ・エー 中村 基裕
2. Speaker • 中村 基裕 • 株式会社ディー・エヌ・エー (2019 ~) • ゲーム事業本部 • リードエンジニア • Takasho のインフラを管理 2
3. 3 本日お話すること Takasho について Google Cloud の活用事例紹介 1 2
4. 4 ① Takasho について
5. 5 Takasho とは • DeNA 内製のゲームサーバーフレームワーク • プロダクション対応済みのコードを再利用 • 運用オペレーションの共通化 • 内製の MBaaS と連携して利用 • アカウント管理 • プッシュ通知 • 課金 • ログ保存
6. 6 Takasho の特徴 • クライアントに寄せたゲームロジック • データの生成・保存はクライアントの責務 • クエスト報酬、スコア計算など • サーバーが負う責務 • 時刻や確率に依存する処理 • ガチャ、ログインボーナスなど • アイテムを付与する経路や量を固定化 • 仮想通貨の付与、ミッション報酬など • 運営からのアクション
7. Takasho のアーキテクチャ 7
8. 8 ② Google Cloud の活用事例紹介
9. Takasho のアーキテクチャ 9 外部指標による水 平スケール
10. Takasho のアーキテクチャ 10 バックグラウンド処理
11. Takasho のアーキテクチャ 11 オートスケール
12. 12 本日紹介する事例 • Cloud Monitoring を活用した Pod の水平スケール • Cloud Pub/Sub を使ったバックグラウンド処理 • スパイクにも耐えるCloud Spanner のオートスケール
13. 13 本日紹介する事例 • Cloud Monitoring を活用した Pod の水平スケール • Cloud Pub/Sub を使ったバックグラウンド処理 • スパイクにも耐えるCloud Spanner のオートスケール
14. ゲームAPI の水平スケールの設計 • 何を基にスケールするか • I/O バウンドなワークロード特性 • ゲームロジックをクライアントに寄せているため • ほとんどが DB の読み書き、APIコール • 秒間リクエスト数 (RPS) を指標に選択 • Pod 数(並列数)を増やすことでスループットが向上 • しきい値の設定 • 負荷試験でスパイクを再現 • 早めに Pod 数を増やせるよう敏感な設定に 14
15. 外部指標の取得 • 秒間リクエスト数をどこから取得するか？ • Custom Metrics API • ユーザーが定義したメトリクスを取得する仕組み • Cloud Monitoring API を利用 • Takasho とは独立したサービス • 高負荷時でも安定してメトリクスを取得 • 独自のPrometheus は採用せず • これ自体の管理が必要 15
16. Horizontal Pod Autoscaler 設定例 16 最大・最小のPod数を指定 HTTP LBのRPSを使用 PodあたりのRPS
17. 17 水平スケールの様子
18. Cloud Monitoring を活用した Pod の水平スケール • 採用して良かった点 • 自身のシステムとは独立 • RPS を取るための手間(準備)がほぼ無し • HTTP LB の指標がすでに用意されている • 導入に苦労した点 • 取得できるメトリクスが 1分以上前のもの • 早めにスケールするように調整 • バッファーを用意 18
19. 19 本日紹介する事例 • Cloud Monitoring を活用した Pod の水平スケール • Cloud Pub/Sub を使ったバックグラウンド処理 • スパイクにも耐えるCloud Spanner のオートスケール
20. Cloud Pub/Sub を使ったバックグラウンド処理 • 時間のかかる処理はバックグラウンドで実行 • MBaaS との連携 • 仮想通貨の消費・追加 • 大量のログの整形・送信 • 重いリクエストのレイテンシを一定の水準に保てる • 主にI/O 待ちの長いようなリクエスト 20
21. 仮想通貨のバックグラウンド処理の例 21 ① ガチャを回す
22. 仮想通貨のバックグラウンド処理の例 22 ② 仮想通貨の 見た目上の残高を更新
23. 仮想通貨のバックグラウンド処理の例 23 ③ Pub/Sub にタスクを送信 (MBaaSへの反映が必要)
24. 仮想通貨のバックグラウンド処理の例 24 ④ 結果を返す
25. 仮想通貨のバックグラウンド処理の例 25 ⑤ タスクを受け取る
26. 仮想通貨のバックグラウンド処理の例 26 ⑥ 残高を反映
27. Pub/Sub を使ったバックグラウンド処理の注意点 • 冪等性はアプリケーションで担保する必要がある • メッセージは 1 回以上配信される • メッセージの配信順序はデフォルトでFIFOではない • 順序指定キーはレイテンシとのトレードオフ • FIFO を期待すると不整合が起こる 27
28. 冪等性はアプリケーションで担保 • メッセージは 1 回以上配信される • 重複処理にならないようにする • 対策 • メッセージにIDを含める • DB に処理済みのID があれば処理しない 28
29. メッセージの配信順序はデフォルトでFIFOではない • デフォルトでは順序はバラバラ • FIFO を期待して処理すると思わぬ結果になる • 対策 • Pub/Sub から受信した順番で処理しない • キーとなる値をメッセージに含める • キーから一連のタスクを取得し処理 29
30. FIFO を期待してしまったPub/Sub との連携 30 ① +100 ② -50
31. 31 ③ 仮想通貨の 見た目上の残高を更新 FIFO を期待してしまった Pub/Sub との連携
32. 32 ④ +100 ⑤ -50 FIFO を期待してしまった Pub/Sub との連携
33. 33 ⑥ -50 FIFO を期待してしまった Pub/Sub との連携
34. 34 ⑦ 残高がマイナス（エラー） FIFO を期待してしまった Pub/Sub との連携
35. 35 ⑧ メッセージが ACK できない ⑨ 仮想通貨の処理が遅延 FIFO を期待してしまった Pub/Sub との連携
36. Takasho でとった対策 • シーケンシャルな処理はPub/Sub のメッセージ順に依存させない • 仮想通貨の場合 • Pub/Sub からは対象のプレイヤー ID を受け取る • 対象のプレイヤーの未処理のタスクを DB から作成日時順に取得 • 順にタスクを処理 36
37. 改善後のPub/Sub との連携 37 ① +100 ② -50
38. 38 ③ 仮想通貨の 見た目上の残高を更新 改善後のPub/Sub との連携
39. 39 ④ DB にタスクを書き込み ⑤ プレイヤー ID を送信 改善後のPub/Sub との連携
40. 40 ⑥ プレイヤー IDを受信 ⑦ DB からタスクを取得 改善後のPub/Sub との連携
41. 41 ⑧ 順番に反映 改善後のPub/Sub との連携
42. Pub/Sub を使ったバックグラウンド処理 • 採用して良かった点 • 高い可用性 (>= 99.95, pubsub/sla) • 仮想通貨やログ送信などの重たい処理がバックグラウンドで処理可能に • API のレイテンシを一定水準に • 導入(後)に苦労した点 • リリース後に想定していないエラー • 仮想通貨・ログの処理遅延 • 遅延したときの対応を想定しておく 42
43. 43 本日紹介する事例 • Cloud Monitoring を活用した Pod の水平スケール • Cloud Pub/Sub を使ったバックグラウンド処理 • スパイクにも耐えるCloud Spanner のオートスケール
44. Takasho でのCloud Spanner の活用 • 開発環境 • シングルノードインスタンス • 環境ごとにデータベースを作成 • 本番環境 • 従来タイトルと比べると費用がケタ違い • 負荷に応じてノード数を調整することがコスト観点で重要 44
45. Cloud Spanner のオートスケール • 利用している OSS • cloudspannerecosystem/autoscaler • メトリクスを収集して設定値に基づいてオートスケール 45
46. オートスケーラーのアーキテクチャ 46 出典: https://github.com/cloudspannerecosystem/autoscaler/blob/master/resources/architecture-per-project.png
47. オートスケーラーのアーキテクチャ 47 出典: https://github.com/cloudspannerecosystem/autoscaler/blob/master/resources/architecture-per-project.png オートスケール設定を保持
48. オートスケーラーのアーキテクチャ 48 出典: https://github.com/cloudspannerecosystem/autoscaler/blob/master/resources/architecture-per-project.png メトリクスを収集
49. オートスケーラーのアーキテクチャ 49 出典: https://github.com/cloudspannerecosystem/autoscaler/blob/master/resources/architecture-per-project.png • ノード数を計算 • スケールを実行
50. オートスケーラーの設定例 50 段階的に増やす
51. オートスケーラーの問題点 • リクエストのスパイクに追いつけない • 直前のメトリクスからノード数を増やしても遅い • ノードは事前に増やして負荷を掛ける必要がある • 増やしたノードに Split を分配するため 51
52. Takasho でのオートスケールの工夫 • ガチャ開始前に事前にノード数を増やす • マスターデータから開始時間を取得 • ガチャ開始の数時間前に設定を書き換え • 事前に決めたノード数に増やす 52
53. オートスケーラーのアーキテクチャ(工夫版) 53 • ガチャの開始時間を取得 • 設定を更新
54. オートスケールの様子 54 ガチャ開始
55. オートスケールの様子 55 メトリクスによるオートスケール期間
56. オートスケールの様子 56 スケールアウト #2 スケールアウト #1
57. オートスケールの様子 57 メトリクスに基づいて、 スケールアウトのみ実行
58. オートスケールの様子 58 メトリクスによるオートスケール期間
59. ガチャ開始前の設定例 59 maxNodes に一気に増やす CronJob から maxNodes を調整
60. Takasho でのCloud Spanner のオートスケール • 通常時 • メトリクスに基づいてスケール • ガチャ開始前後 • 事前に指定したノード数に増やしておく • 開始後一定時間はノード数を維持 • メトリクスに応じたスケールアウトのみ許可 60
61. Takasho でのCloud Spanner の活用 • 導入して良かった点 • シャーディングが不要 • コードがシンプルに • ノードの増減が簡単 • リリース時に多めにし、後から縮退が可能 • 導入(後)に苦労した点 • Split についての理解 • どうやってウォームアップするのか？ • Spanner の費用が特に大きい • オートスケーラーの導入で最適化 • 開発環境のコスト削減は今後に期待 61
62. 62 本日お話したこと Takasho について Google Cloud の活用事例紹介 1 2
63. 63 本日紹介した事例 • Cloud Monitoring を活用した Pod の水平スケール • Cloud Pub/Sub を使ったバックグラウンド処理 • スパイクにも耐えるCloud Spanner のオートスケール
64. Twitterアカウント @DeNAxTech では、 DeNA のエンジニアリングに関する 登壇資料やブログを紹介しています！ ぜひ Twitter をフォローしてみてください！