Google Cloud Next Tokyo '25 の「Next Tokyo イベントアンバサダー」に選出いただきました G-gen の堂原です。当記事は、Google Cloud Next '25 Tokyo の2日目に行われたブレイクアウトセッション「最新技術で実現する Pokémon Trading Card Game Pocket のスケーラブルな運用とコスト最適化」のレポートです。

他の Google Cloud Next Tokyo '25 の関連記事は Google Cloud Next Tokyo '25 カテゴリの記事一覧からご覧いただけます。

セッションの概要

本セッションでは、月間アクティブユーザ数が 5,100 万人（2024 年度第 4 四半期平均）にも達するスマートフォン向けゲームアプリ Pokémon Trading Card Game Pocket（以下、ポケポケ）のアーキテクチャ及び、インフラ基盤で取り入れられている最新技術について紹介されました。

全体アーキテクチャ

ポケポケのインフラ基盤は、API Server と Battle Server の 2 つの Google Kubernetes Engine（GKE） クラスタで構成されています。　API Server はプレイヤー情報の管理やマッチメイキングを行い、Battle Server では実際の対戦処理が行われます。API Server のデータベースとしては Spanner が稼働しています。

実際のアクセス数は非公表であるものの、本基盤に対して以下の規模の負荷試験を実施したとのことです。

API Server に対して 70 万 RPS（Request Per Second）以上
Spanner に対して 1,000 万 QPS（Query Per Second）以上
スパイクは 3 分間で 9 倍以上

Spanner Pre-splitting で大規模なスパイクに立ち向かう

概要

前半パートでは、Spanner を運用するにあたって考える必要があるスプリット戦略について、ポケポケで採用されている Pre-splitting という機能が紹介されました。

Spanner について

Spanner（または Cloud Spanner）は Google Cloud が提供するフルマネージドデータベースであり、強整合性を保証しつつ水平スケーリングが可能なデータベースとなっています。

Spanner については、以下の記事で解説していますのでご参照ください。

blog.g-gen.co.jp

Spanner の負荷分散の仕組みと課題

Spanner では、データがスプリットという単位に分割されて管理されています。Spanner の処理部であるノードが、それぞれに割り当てられたスプリットの処理を行うことで負荷分散が行われています。スプリットは負荷状況に応じて、自動で追加や削除が行われます。

参考 : スキーマの概要 | Spanner | Google Cloud

そんなスプリットですが、自動で追加されるまでには時間がかかるため、スパイク時には追加が間に合わずレイテンシが悪化するという課題があります。

スパイクに対するこれまでの対処法

スパイクに対してスプリットの追加が間に合わないという課題に対して、これまではウォームアップを実施することで対処されていたそうです。ローンチ前にダミーデータであらかじめ負荷をかけておくことで、十分なスプリットを確保した状態でローンチするという手法となります。

ただし、この方法にも以下のような課題がありました。

ローンチ後に発生するスパイクに対しては使用できない
ウォームアップ中は人が張り付いて負荷状況を調整しないといけない
- ミスをするとスプリットを割りすぎてコスト増加につながる

Pre-splitting

Pre-splitting は、特定のテーブル・インデックスのスプリットを予め設定することができる機能です。この機能により、ローンチ時など、スパイクが想定されるタイミングで事前にスプリットを増やすことができます。

本機能を使うことにより、ポケポケではスプリット不足が起因のレイテンシ悪化がほぼ無くなったとのことです。ただし、以下のような配慮すべきポイントについても紹介されていました。

スプリットポイント（どの値でスプリットを分けるか）が不適切な場合、特定のスプリットに負荷が集中する（ホットスポット）
スプリット数の予測
- スプリット数が少ないと、ホットスポットが発生する
- スプリット数が多いと、ノード数が減らせずコスト増加につながる
スパイク後はノード数を減らすことでコスト削減が可能だが、1 ノードあたりのスプリット数が増えすぎるとパフォーマンスが低下する
- 目安として「1 ノード 50 スプリットを超える際は慎重に」と紹介されていました

C4A インスタンスへの移行

概要

後半パートでは、GKE クラスタのインスタンスとして C4A インスタンスを導入した事例について紹介されました。

C4A インスタンスとは

C4A インスタンスは、Google Cloud が提供する Compute Engine マシンタイプの一種です。2024 年 10 月 31 日に一般提供が開始され、Arm ベースの Axion プロセッサが搭載されています。メモリについても、均一メモリアクセス（UMA）が採用されており、一貫したパフォーマンスを提供することができます。

参考 : Compute Engine の汎用マシンファミリー | Compute Engine Documentation | Google Cloud

導入効果

Google 公式ブログにおいて、x86 ベースのインスタンスと比べて費用対効果が最大 65% 向上すると記載されている C4A インスタンスですが、ポケポケ環境においては、それまで採用していた Tau T2D インスタンスと比較して以下のような費用対効果が得られました。

API Server : 73% 向上
Battle Server : 11% 向上

また、Tau T2D インスタンスではメモリアクセスに起因して発生していた CPU 性能の劣化についても、先述の通り UMA が採用されている C4A インスタンスでは発生することが無くなったそうです。

更に、セッションではマシンタイプの移行に際して以下のような利点が紹介されていました。

Tau T2D インスタンスから C4A インスタンスへの移行が容易であった
C4A インスタンスは CPU 使用率に対して、比例的に許容 RPS が伸びた
- 他のマシンタイプの場合、ハイパースレッディングがあると CPU 使用率 50 % を境に性能の劣化が見られることがある
エネルギー効率も最大 60% と高く、環境に配慮したマシンタイプとなっている