Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ゲーム「IDOLY PRIDE」を構成するGCPアーキテクチャの全貌
Search
QualiArts
June 09, 2022
Technology
1
490
ゲーム「IDOLY PRIDE」を構成するGCPアーキテクチャの全貌
QualiArts
June 09, 2022
Tweet
Share
More Decks by QualiArts
See All by QualiArts
UnityのHumanoidと共存する キャラクタジョイント制御と 制作ワークフロー
qualiarts
1
5.6k
詳解 "Fixing For Loops in Go 1.22" 自作linterをgolangci-lintへコントリビュートした話
qualiarts
9
2.1k
Goバックエンド標準化プロジェクトの取り組み
qualiarts
4
1.3k
自作ツールTitanと ベクターUIを使った IDOLY PRIDEの UIアニメーションの実装
qualiarts
0
3.5k
膨大なシナリオから 該当シーンを一瞬で検索! IDOLY PRIDEの シナリオ補助ツール開発
qualiarts
0
2.4k
エンジニアとクリエイターで作る!モバイルゲーム開発における理想的なUIアニメーション開発フロー
qualiarts
0
4.6k
ゲームの抽選ロジックにGenericsを使ってみたら開発が楽になった話
qualiarts
0
1.6k
モバイルゲームのUI開発を支える基盤の仕組み
qualiarts
0
1.5k
IDOLY PRIDEにおけるAssetBundleビルドパイプラインについて
qualiarts
0
2.9k
Other Decks in Technology
See All in Technology
マップを速く表示するために
tsuboyan5
0
160
TerraformとGitHub Actionsで手軽に実装するECSのCI/CD
k___tkg
0
220
HA K8s Clusterのスタンダードが覆る!? Cilium 1.18の🔥激アツ🔥新機能
logica0419
0
120
Eight Engineering Unit 紹介資料
sansan33
PRO
0
3k
バックエンドのコードファーストなOpenAPIスキーマ駆動開発 - TSKaigi2025
yujitorii
1
250
情熱と工夫で走り抜け! コミュニティをささえるObservability実践録
b1gb4by
1
120
Introduction to Sansan for Engineers / エンジニア向け会社紹介
sansan33
PRO
5
37k
会社員しながら本を書いてきた知見の共有
sat
PRO
2
620
会社紹介資料 / Sansan Company Profile
sansan33
PRO
6
360k
研究開発部メンバーの働き⽅ / Sansan R&D Profile
sansan33
PRO
3
17k
大事なのは、AIの精度だけじゃない!〜1円のズレも許されない経理領域とAI〜
jun_nemoto
8
4.5k
Slackひと声でブログ校正!Claudeレビュー自動化編
yusukeshimizu
3
120
Featured
See All Featured
Adopting Sorbet at Scale
ufuk
76
9.4k
How to Ace a Technical Interview
jacobian
276
23k
Scaling GitHub
holman
459
140k
Docker and Python
trallard
44
3.4k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.5k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
34
2.3k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
Why You Should Never Use an ORM
jnunemaker
PRO
56
9.4k
Code Reviewing Like a Champion
maltzj
523
40k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
14
870
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.3k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Transcript
「IDOLY PRIDE」を構成する GCPアーキテクチャの全貌 株式会社QualiArts 筋野正太
所属:株式会社QualiArts 入社:2014年 技術:Go, k8s, GCP, AWS etc... 筋野 正太 バックエンドエンジニアとして「IDOLY
PRIDE」のAPI/インフラの開発を担当 現在は複数のゲームや、社内ツールのインフラを管理しつつ、新規ゲームを開発中 技術書典12で「SGE Go Tech Book」を執筆 Go Conference 2022 Spring で「大規模ゲーム開発におけるContext活用パターン」を登壇 twitter: @8kkadrop
全体概要
IDOLY PRIDE について 「IDOLY PRIDE」はアイドルをテーマとし たメディアミックス作品 ゲームの開発と運営はQualiArtsが担当 • アイドルマネジメントRPG •
2021年06月24日リリース • Go, gRPC, GKE, Spanner etc...
各環境について IDOL YPRIDE の開発では以下の環境を用意して使い分けている • Development: エンジニアが開発で利用する環境 • Sandbox: プランナーやデバッガーが検証で利用する環境
• Staging: 本番リリース前に最終確認を行う環境 • Production: ユーザーのアクセスする本番環境 環境毎にGKEクラスタを用意して運用 また、Production環境は GCP プロジェクトを別で管理 (今回は本番環境を中心に話していきます)
全体構成
話す内容 • Application ◦ ゲームAPI / 関連ツール 構成 ◦ リリース戦略
◦ オートスケール • Database ◦ データベース一覧 ◦ マスタデータ管理 • Log ◦ ゲームログ ◦ Adjustログ • Others ◦ ユーザー名検索 ◦ 外部サービス
Application
ゲームAPI / 関連ツール ゲームに関わるAPIやツールはGKE上に構築 Preemptible VM (PVM) • API、課金基盤、メンテナンス用API etc…
• スケールさせる必要のある Pod は PVM に作成 • (構築当時、Spot VM がまだなかった) Standard VM (SVM) • 管理ツール、バッチ処理、CDツール • 管理ツールなど常時起動させたいものを SVM に作成 • その他、スケールさせる必要のない Pod を同居
ゲームAPIの構成 認証は Firebase Authentication を利用する Blue/Greenデプロイ用に API と API(Pre) という2種類の
Pod が存在する API • ユーザーアクセス用のPod API (Pre) • リリース前の確認用環境 (Preview) • リリース時のみ作成される
Preview 用の Pod は どういった使い方をされるのか?
新バージョンのAPIリリースは、Blue/Greenデプロイで行う 通常時は Active App (ユーザー用アプリ) も Preview App (確認用アプリ) も
同じ Pod を参照している リリース戦略 GKE prd-db User QualiArts Active App Preview App v1.0.0 Active Pod
新バージョンリリース時に新しい 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
確認完了後、Active App をリリースバージョンの Pod に向ける 旧バージョンの Pod は一定時間後に削除する リリース戦略 GKE
prd-db User QualiArts Active App Preview App v1.1.0 Active Pod
オートスケール Pod, GKEノード, Spannerユニットはk8sのCRDを 利用してスケールさせる 管理は Helm で行い、サイズと時間を設定するとそ れぞれのスケールAPIを叩く仕様
何故わざわざ CRD を利用して スケールさせるのか?
CRDを利用したオートスケールのメリット ゲームの負荷は徐々に上がるケースでなく、スパイクするケースが多い そのため、事前にスケール時間を設定する事で負荷のスパイクに備えられる また、スケールタイミングを細かく設定する事でコストを大幅に削減できる ピーク時のスペックを維持する場合と比較して30%ほどコスト削減できた
Database
データ管理は 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... データベース一覧
マスタデータ管理 マスタデータは Cloud SQL に登録し、バイナリファイルに変換して GCS に置く APIでマスタを利用する際は GCS から取得してAPIのメモリにキャッシュする
マスタデータ管理(Q&A) なぜ Spanner で一括管理しないのか? スプレッドシートを利用したマスタの一括投入や、別環境への同期を行う際に ミューテーション上限に引っかかる可能性があったため。 また、トランザクションデータとDBが分かれる事で負荷を気にせず運用できる。 長期運用でマスタが肥大化した際に問題はないか? バイナリデータに変換する際にデータを加工し、期間外のマスタはキャッシュに 載せないなどの工夫をする。
Log
ゲームログ ゲームのログは Pub/Sub、Dataflow を経由して BigQuery へ送る Dataflow はカスタムテンプレートを作成して利用している
Adjustログ ゲームログとは別にモバイル測定SaaSの Adjust を利用してログを取得している • Cloud Functions でリアルタイムコールバック用のAPIを用意する • ゲームログと同じく、Pub/Sub、Dataflow
を通して BigQuery へ流す
Others
ユーザー名検索 ユーザー名からユーザーデータを検索するため、Elastic Cloud を活用 (カスタマーサービスチームで利用) 名前変更を Pub/Sub で受け取り、Cloud Function で
Elastic Cloud に送信する
外部サービス キャンペーンコード入力サービスや、お問い合わせ フォームは Cloud Run を使用 何故GKEに同居させないのか? • ゲーム関連システムから切り離しやすくする •
常時アクセスがあるわけではない
まとめ
まとめ IDOLY PRIDE を構成する GCP のアーキテクチャについて説明しました。 • ゲーム関連のコンテナは GKE 上に構築
• Cloud SQL、Cloud Spanner を中心にデータ管理している • ログは Pub/Sub、Dataflow を利用して BigQuery に集約 • 外部サービスは Cloud Run で構築 (画像関連やCI/CDなど話せていないこともあるので、また別の機会で)