$30 off During Our Annual Pro Sale. View Details »

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

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

QualiArts

June 09, 2022
Tweet

More Decks by QualiArts

Other Decks in Technology

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