Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

全体概要

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

全体構成

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

Application

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

新バージョンリリース時に新しい 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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

Database

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

Log

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

Others

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

まとめ

Slide 29

Slide 29 text

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