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

Transcript

1. 「IDOLY PRIDE」を構成する
   GCPアーキテクチャの全貌
   株式会社QualiArts 筋野正太
   

   View Slide

2. 所属：株式会社QualiArts
   入社：2014年
   技術：Go, k8s, GCP, AWS etc...
   筋野 正太
   バックエンドエンジニアとして「IDOLY PRIDE」のAPI/インフラの開発を担当
   現在は複数のゲームや、社内ツールのインフラを管理しつつ、新規ゲームを開発中
   技術書典12で「SGE Go Tech Book」を執筆
   Go Conference 2022 Spring で「大規模ゲーム開発におけるContext活用パターン」を登壇
   twitter:
   @8kkadrop
   

   View Slide

3. 全体概要
   

   View Slide

4. IDOLY PRIDE について
   「IDOLY PRIDE」はアイドルをテーマとし
   たメディアミックス作品
   ゲームの開発と運営はQualiArtsが担当
   ● アイドルマネジメントRPG
   ● 2021年06月24日リリース
   ● Go, gRPC, GKE, Spanner etc...
   

   View Slide

5. 各環境について
   IDOL YPRIDE の開発では以下の環境を用意して使い分けている
   ● Development： エンジニアが開発で利用する環境
   ● Sandbox： プランナーやデバッガーが検証で利用する環境
   ● Staging： 本番リリース前に最終確認を行う環境
   ● Production： ユーザーのアクセスする本番環境
   環境毎にGKEクラスタを用意して運用
   また、Production環境は GCP プロジェクトを別で管理
   （今回は本番環境を中心に話していきます）
   

   View Slide

6. 全体構成
   

   View Slide

7. 話す内容
   ● Application
   ○ ゲームAPI / 関連ツール 構成
   ○ リリース戦略
   ○ オートスケール
   ● Database
   ○ データベース一覧
   ○ マスタデータ管理
   ● Log
   ○ ゲームログ
   ○ Adjustログ
   ● Others
   ○ ユーザー名検索
   ○ 外部サービス
   

   View Slide

8. Application
   

   View Slide

9. ゲームAPI / 関連ツール
   ゲームに関わるAPIやツールはGKE上に構築
   Preemptible VM (PVM)
   ● API、課金基盤、メンテナンス用API etc…
   ● スケールさせる必要のある Pod は PVM に作成
   ● （構築当時、Spot VM がまだなかった）
   Standard VM (SVM)
   ● 管理ツール、バッチ処理、CDツール
   ● 管理ツールなど常時起動させたいものを SVM に作成
   ● その他、スケールさせる必要のない Pod を同居
   

   View Slide

10. ゲームAPIの構成
    認証は Firebase Authentication を利用する
    Blue/Greenデプロイ用に API と API(Pre) という2種類の Pod が存在する
    API
    ● ユーザーアクセス用のPod
    API (Pre)
    ● リリース前の確認用環境 (Preview)
    ● リリース時のみ作成される
    

    View Slide

11. Preview 用の Pod は
    どういった使い方をされるのか？
    

    View Slide

12. 新バージョンのAPIリリースは、Blue/Greenデプロイで行う
    通常時は Active App (ユーザー用アプリ) も Preview App (確認用アプリ) も
    同じ Pod を参照している
    リリース戦略
    GKE
    prd-db
    User
    QualiArts
    Active App
    Preview App
    v1.0.0
    Active Pod
    

    View Slide

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
    

    View Slide

14. 確認完了後、Active App をリリースバージョンの Pod に向ける
    旧バージョンの Pod は一定時間後に削除する
    リリース戦略
    GKE
    prd-db
    User
    QualiArts
    Active App
    Preview App
    v1.1.0
    Active Pod
    

    View Slide

15. オートスケール
    Pod, GKEノード, Spannerユニットはk8sのCRDを
    利用してスケールさせる
    管理は Helm で行い、サイズと時間を設定するとそ
    れぞれのスケールAPIを叩く仕様
    

    View Slide

16. 何故わざわざ CRD を利用して
    スケールさせるのか？
    

    View Slide

17. CRDを利用したオートスケールのメリット
    ゲームの負荷は徐々に上がるケースでなく、スパイクするケースが多い
    そのため、事前にスケール時間を設定する事で負荷のスパイクに備えられる
    また、スケールタイミングを細かく設定する事でコストを大幅に削減できる
    ピーク時のスペックを維持する場合と比較して30%ほどコスト削減できた
    

    View Slide

18. Database
    

    View Slide

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...
    データベース一覧
    

    View Slide

20. マスタデータ管理
    マスタデータは Cloud SQL に登録し、バイナリファイルに変換して GCS に置く
    APIでマスタを利用する際は GCS から取得してAPIのメモリにキャッシュする
    

    View Slide

21. マスタデータ管理（Q&A）
    なぜ Spanner で一括管理しないのか？
    スプレッドシートを利用したマスタの一括投入や、別環境への同期を行う際に
    ミューテーション上限に引っかかる可能性があったため。
    また、トランザクションデータとDBが分かれる事で負荷を気にせず運用できる。
    長期運用でマスタが肥大化した際に問題はないか？
    バイナリデータに変換する際にデータを加工し、期間外のマスタはキャッシュに
    載せないなどの工夫をする。
    

    View Slide

22. Log
    

    View Slide

23. ゲームログ
    ゲームのログは Pub/Sub、Dataflow を経由して BigQuery へ送る
    Dataflow はカスタムテンプレートを作成して利用している
    

    View Slide

24. Adjustログ
    ゲームログとは別にモバイル測定SaaSの Adjust を利用してログを取得している
    ● Cloud Functions でリアルタイムコールバック用のAPIを用意する
    ● ゲームログと同じく、Pub/Sub、Dataflow を通して BigQuery へ流す
    

    View Slide

25. Others
    

    View Slide

26. ユーザー名検索
    ユーザー名からユーザーデータを検索するため、Elastic Cloud を活用
    （カスタマーサービスチームで利用）
    名前変更を Pub/Sub で受け取り、Cloud Function で Elastic Cloud に送信する
    

    View Slide

27. 外部サービス
    キャンペーンコード入力サービスや、お問い合わせ
    フォームは Cloud Run を使用
    何故GKEに同居させないのか？
    ● ゲーム関連システムから切り離しやすくする
    ● 常時アクセスがあるわけではない
    

    View Slide

28. まとめ
    

    View Slide

29. まとめ
    IDOLY PRIDE を構成する GCP のアーキテクチャについて説明しました。
    ● ゲーム関連のコンテナは GKE 上に構築
    ● Cloud SQL、Cloud Spanner を中心にデータ管理している
    ● ログは Pub/Sub、Dataflow を利用して BigQuery に集約
    ● 外部サービスは Cloud Run で構築
    （画像関連やCI/CDなど話せていないこともあるので、また別の機会で）
    

    View Slide