ゲーム「IDOLY PRIDE」を構成するGCPアーキテクチャの全貌

Transcript

1. 「IDOLY PRIDE」を構成する GCPアーキテクチャの全貌 株式会社QualiArts 筋野正太
2. 所属：株式会社QualiArts 入社：2014年 技術：Go, k8s, GCP, AWS etc... 筋野 正太 バックエンドエンジニアとして「IDOLY PRIDE」のAPI/インフラの開発を担当 現在は複数のゲームや、社内ツールのインフラを管理しつつ、新規ゲームを開発中 技術書典12で「SGE Go Tech Book」を執筆 Go Conference 2022 Spring で「大規模ゲーム開発におけるContext活用パターン」を登壇 twitter: @8kkadrop
3. 全体概要
4. IDOLY PRIDE について 「IDOLY PRIDE」はアイドルをテーマとし たメディアミックス作品 ゲームの開発と運営はQualiArtsが担当 • アイドルマネジメントRPG • 2021年06月24日リリース • Go, gRPC, GKE, Spanner etc...
5. 各環境について IDOL YPRIDE の開発では以下の環境を用意して使い分けている • Development： エンジニアが開発で利用する環境 • Sandbox： プランナーやデバッガーが検証で利用する環境 • Staging： 本番リリース前に最終確認を行う環境 • Production： ユーザーのアクセスする本番環境 環境毎にGKEクラスタを用意して運用 また、Production環境は GCP プロジェクトを別で管理 （今回は本番環境を中心に話していきます）
6. 全体構成
7. 話す内容 • Application ◦ ゲームAPI / 関連ツール 構成 ◦ リリース戦略 ◦ オートスケール • Database ◦ データベース一覧 ◦ マスタデータ管理 • Log ◦ ゲームログ ◦ Adjustログ • Others ◦ ユーザー名検索 ◦ 外部サービス
8. Application
9. ゲームAPI / 関連ツール ゲームに関わるAPIやツールはGKE上に構築 Preemptible VM (PVM) • API、課金基盤、メンテナンス用API etc… • スケールさせる必要のある Pod は PVM に作成 • （構築当時、Spot VM がまだなかった） Standard VM (SVM) • 管理ツール、バッチ処理、CDツール • 管理ツールなど常時起動させたいものを SVM に作成 • その他、スケールさせる必要のない Pod を同居
10. ゲームAPIの構成 認証は Firebase Authentication を利用する Blue/Greenデプロイ用に API と API(Pre) という2種類の Pod が存在する API • ユーザーアクセス用のPod API (Pre) • リリース前の確認用環境 (Preview) • リリース時のみ作成される
11. Preview 用の Pod は どういった使い方をされるのか？
12. 新バージョンのAPIリリースは、Blue/Greenデプロイで行う 通常時は Active App (ユーザー用アプリ) も Preview App (確認用アプリ) も 同じ Pod を参照している リリース戦略 GKE prd-db User QualiArts Active App Preview App v1.0.0 Active Pod
13. 新バージョンリリース時に新しい Pod を作成する Preview App でリリースバージョンの Pod にアクセスし、最終確認を行う （ArgoCDのAPIを利用して下記状態でリリースを停止させる機能を実装） リリース戦略 GKE prd-db User QualiArts Active App Preview App v1.0.0 Active Pod v1.1.0 Preview Pod
14. 確認完了後、Active App をリリースバージョンの Pod に向ける 旧バージョンの Pod は一定時間後に削除する リリース戦略 GKE prd-db User QualiArts Active App Preview App v1.1.0 Active Pod
15. オートスケール Pod, GKEノード, Spannerユニットはk8sのCRDを 利用してスケールさせる 管理は Helm で行い、サイズと時間を設定するとそ れぞれのスケールAPIを叩く仕様
16. 何故わざわざ CRD を利用して スケールさせるのか？
17. CRDを利用したオートスケールのメリット ゲームの負荷は徐々に上がるケースでなく、スパイクするケースが多い そのため、事前にスケール時間を設定する事で負荷のスパイクに備えられる また、スケールタイミングを細かく設定する事でコストを大幅に削減できる ピーク時のスペックを維持する場合と比較して30%ほどコスト削減できた
18. Database
19. データ管理は Cloud SQL、Cloud Spanner、Cloud Memorystore、GCS を活用 Cloud SQL：マスタデータ • Item, Stage, Event etc... Cloud Spaner：トランザクションデータ • User, UserItem, UserStage etc... Cloud Memorystore：キャッシュデータ • Ranking, Other Cache etc... データベース一覧
20. マスタデータ管理 マスタデータは Cloud SQL に登録し、バイナリファイルに変換して GCS に置く APIでマスタを利用する際は GCS から取得してAPIのメモリにキャッシュする
21. マスタデータ管理（Q&A） なぜ Spanner で一括管理しないのか？ スプレッドシートを利用したマスタの一括投入や、別環境への同期を行う際に ミューテーション上限に引っかかる可能性があったため。 また、トランザクションデータとDBが分かれる事で負荷を気にせず運用できる。 長期運用でマスタが肥大化した際に問題はないか？ バイナリデータに変換する際にデータを加工し、期間外のマスタはキャッシュに 載せないなどの工夫をする。
22. Log
23. ゲームログ ゲームのログは Pub/Sub、Dataflow を経由して BigQuery へ送る Dataflow はカスタムテンプレートを作成して利用している
24. Adjustログ ゲームログとは別にモバイル測定SaaSの Adjust を利用してログを取得している • Cloud Functions でリアルタイムコールバック用のAPIを用意する • ゲームログと同じく、Pub/Sub、Dataflow を通して BigQuery へ流す
25. Others
26. ユーザー名検索 ユーザー名からユーザーデータを検索するため、Elastic Cloud を活用 （カスタマーサービスチームで利用） 名前変更を Pub/Sub で受け取り、Cloud Function で Elastic Cloud に送信する
27. 外部サービス キャンペーンコード入力サービスや、お問い合わせ フォームは Cloud Run を使用 何故GKEに同居させないのか？ • ゲーム関連システムから切り離しやすくする • 常時アクセスがあるわけではない
28. まとめ
29. まとめ IDOLY PRIDE を構成する GCP のアーキテクチャについて説明しました。 • ゲーム関連のコンテナは GKE 上に構築 • Cloud SQL、Cloud Spanner を中心にデータ管理している • ログは Pub/Sub、Dataflow を利用して BigQuery に集約 • 外部サービスは Cloud Run で構築 （画像関連やCI/CDなど話せていないこともあるので、また別の機会で）