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
420
ゲーム「IDOLY PRIDE」を構成するGCPアーキテクチャの全貌
QualiArts
June 09, 2022
Tweet
Share
More Decks by QualiArts
See All by QualiArts
UnityのHumanoidと共存する キャラクタジョイント制御と 制作ワークフロー
qualiarts
1
4.2k
詳解 "Fixing For Loops in Go 1.22" 自作linterをgolangci-lintへコントリビュートした話
qualiarts
9
1.8k
Goバックエンド標準化プロジェクトの取り組み
qualiarts
4
1.2k
自作ツールTitanと ベクターUIを使った IDOLY PRIDEの UIアニメーションの実装
qualiarts
0
1.8k
膨大なシナリオから 該当シーンを一瞬で検索! IDOLY PRIDEの シナリオ補助ツール開発
qualiarts
0
2.2k
エンジニアとクリエイターで作る!モバイルゲーム開発における理想的なUIアニメーション開発フロー
qualiarts
0
2.8k
ゲームの抽選ロジックにGenericsを使ってみたら開発が楽になった話
qualiarts
0
1.5k
モバイルゲームのUI開発を支える基盤の仕組み
qualiarts
0
1.4k
IDOLY PRIDEにおけるAssetBundleビルドパイプラインについて
qualiarts
0
2.8k
Other Decks in Technology
See All in Technology
AWSエンジニアに捧ぐLangChainの歩き方
tsukuboshi
1
310
日本語プログラミングとSpring Bootアプリケーション開発 #kanjava
yusuke
2
370
Creative Pair
kawaguti
PRO
1
150
Women in Agile
kawaguti
PRO
3
180
Autify Company Deck
autifyhq
2
41k
[2025クラウドガバナンスはこう変わる!マルチアカウント運用のre:Invent最新情報と活用例] re:Invent 2024 から見る AWS マルチアカウントガバナンスのこれまでとこれから
0nihajim
0
110
ソフトウェアアーキテクトのための意思決定術: Software Architecture and Decision-Making
snoozer05
PRO
19
4.3k
20250130_『SUUMO』の裏側!第2弾 ~機械学習エンジニアリング編
recruitengineers
PRO
1
450
君はPostScriptなウィンドウシステム 「NeWS」をご存知か?/sunnews
koyhoge
0
610
WAF に頼りすぎない AWS WAF 運用術 meguro sec #1
izzii
0
340
AIをプロダクトに実装するならAPIで分離しよう 〜タクシーアプリ『GO』のアーキテクチャ実例紹介〜
74th
2
130
開発者が自律的に AWS Security Hub findings に 対応する仕組みと AWS re:Invent 2024 登壇体験談 / Developers autonomously report AWS Security Hub findings Corresponding mechanism and AWS re:Invent 2024 presentation experience
kaminashi
0
110
Featured
See All Featured
Writing Fast Ruby
sferik
628
61k
No one is an island. Learnings from fostering a developers community.
thoeni
20
3.1k
Designing for Performance
lara
604
68k
Adopting Sorbet at Scale
ufuk
74
9.2k
Automating Front-end Workflow
addyosmani
1367
200k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
128
19k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Become a Pro
speakerdeck
PRO
26
5.1k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
49
2.2k
Navigating Team Friction
lara
183
15k
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など話せていないこともあるので、また別の機会で)