はじめに

本記事は Google Cloud Next 2025 Day2(2025年8月5日)において DeNA の天野氏と柴田氏が講演された「最新技術で実現する Pokémon Trading Card Game Pocket のスケーラブルな運用とコスト最適化」のレポートです。

公式セッション紹介

Pokémon Trading Card Game Pocket は月間アクティブユーザ数が 5100 万人( 2024 年度第 4 四半期平均)となり、非常に大規模なトラフィックとスパイクアクセスを特徴とするゲームです。
この開発にあたっては、最新技術を取り入れることでより良いユーザ体験とコスト最適化、運用しやすさなどのバランスをとっています。
本セッションでは、サーバ構成のアーキテクチャを概説した後、採用した最新技術として Spanner の Pre-splitting と C4A インスタンス移行の具体的な事例を紹介します。

（出典：最新技術で実現する Pokémon Trading Card Game Pocket のスケーラブルな運用とコスト最適化）

発表資料・アーカイブ

Google Cloud Next Tokyoのアーカイブサイトで本セッションの内容は公開されていません。

概要／おすすめポイント

「Pokémon Trading Card Game Pocket」いわゆる「ポケポケ」は累計ダウンロード数1億、2024年度の第4四半期のMAU(月次アクティブユーザー数)が5100万人を超えている超大規模ゲームになります。

[出典：DeNA、累計DL数1億突破の『ポケポケ』の平均MAUは5100万と明かす]

本セッションではそのような大規模なゲームシステムを支えるインフラ基盤についてのシステムアーキテクチャや、具体的なスケーラブルな運用方法などが紹介されており、Cloud Spanner を採用している方や、Axion(ArmアーキテクチャのVM)の採用を検討している方には参考になると思いました。

セッション内容の紹介

Agenda
1. 全体アーキテクチャ
2. Spanner Pre-splitting で大規模なスパイクに立ち向かう
3. C4A インスタンスへの移行

1. 全体アーキテクチャ

ポケポケの全体アーキテクチャは、次のようにクライアントからの接続を API Server(GKE Cluster) で受け、通常の処理であればそのまま処理、バトルを行う場合には Battler Server(GKE Cluster) に振り向けるような仕組みになっています。

データベースとして、Memorystore for Redisや Cloud Spanner が利用されています。

通常の処理

バトルの処理

今回の発表では、この中の Cloud Spanner の新機能と、Google Cloud の ARM ベースのCPUである Axion(C4Aインスタンス) をGKE Clusterに採用したときの性能向上についての発表です。

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

ポケポケのリリースにあたって実施した最大規模の負荷試験は次の通りでした（実際のアクセス数は非公開）。

API Server : 70万RPS 以上
Spanner ： 1,000万QPS 以上
スパイク： 3分間で9倍以上

Spannerの負荷分散の仕組み

Spannerは内部的に自動的にシャーディングが行われ、データはSplitという単位で分割され、そのSplitがサーバ毎に分散されることでDBアクセスの負荷が分散されます。

ここで、初期段階ではSplitが一つしかないため、下図のように一つのサーバに負荷が集中する形になります。

ローンチ時の課題

上述のような負荷分散の仕組みのため、ローンチ時に「Split不足でレイテンシが悪化する」という課題がありました。

今までは、次のようにローンチ前に負荷掛けを行い、事前にSplitを複数作成しておくことで対処を行っていました。

ローンチ後の課題

ローンチ後にキャンペーンなどでスパイクが発生すると想定される場合に、本番稼働しているデータベースに対して負荷掛けの実施やメンテナンス時間を確保することはなるべく避けたいが、今までは簡単な対処法がない状態でした。

Pre-Splittingでの対応

Spannerで Pre-Splitting といういわゆる 事前分割 を実施しておくことで、事前に負荷が予測されるときにの対処を行うことが可能となりました。

事前分割の概要

基本的にポケポケでは本機能を利用するようになってからは、Split不足でのレイテンシ悪化はほぼ防げるようになりました。

Splitのリスク

事前分割(Pre-Splitting)ではSplit数を指定する必要があるため、幾つか注意点があります。

Split Pointの設定

Splitはキーで分割されるため、分割するポイントが誤っていると結局特定のSplitに負荷が集中してしまう、という事が発生しえます。

Split数の予測

Splitの数が足りていない場合にはホットスポットが発生、Splitの数が多すぎる場合にはノード数の削減が大変になる、というようなことが起きえます。必要なSplit数は経験などを考慮して次図の式で決めていますが、システムに依るので自身の環境・アクセスパターンに適した形で検討していく必要があります。

(ピーク後の)ノード数削減

ピークを越えたらノード数を削減してコスト削減を行うことが可能となるが、ノード(Spannerサーバ)あたりのSplit数が50を超える場合には性能影響の発生可能性があるため、慎重に実施した方がよいという話が紹介されていました(Split自体も指定した寿命を過ぎると減少するため、そちらと調整する形)。

Pre-splitting のまとめ

ローンチ時もローンチ後も大規模スパイクにはPre-Splittingが有効
負荷試験・計算で対象とSplit数を決める
ノードあたりのSplit数が50を超える場合には慎重にノード削減を行う

現在はSplit数をSQLで取得していますが、メトリックのような形で取得できると運用が楽になるので、そこはGoogle Cloudが対応すると良いですね。

3. C4A インスタンスへの移行

GKEのクラスタをx86ベースの Tau T2D インスタンスからArmベースの C4A インスタンスへの移行を行った際の移行方法や移行後の性能向上についての紹介です。

C4Aインスタンス

C4Aインスタンスは Google自身が設計・カスタマイズを行っているArmベースの Axion プロセッサを搭載しているCPUとなり、x86ベースのインスタンスに比べると費用対効果が高い、とされてます。
C4Aインスタンスを採用した目的としては、次の二点があります。

コスト低減
パフォーマンスの一貫性向上

コスト低減効果

次図のように、API Serverは73%と劇的に向上効果がありましたが、Battle Serverでは11%でした。AWSでもArmベースの Graviton が発表された際に様々な検証が行われていましたが、基本的には性能は向上するがワークロードによる、という結論になっていたと記憶しています。Axionベースも影響が大きなワークロードとそれほどでもないワークロードがある、というのは理解できる状態になると考えています。

API Server： 73%向上
Battle Server： 11％向上

パフォーマンスの一貫性向上効果

Tau T2Dではメモリアクセスに起因して稀にCPU性能が劣化する、という状態が発生していました。
C4Aではメモリ帯域の向上（DDR4-3200 → DDR5-5600）¹していることと、均一メモリアクセス（UMA）を備えた単一ノード内に配置されるためにノイジーネイバーが発生しないこと、が安定性に寄与していると考えています。
後述のとおり、負荷特性も線形で安定していました。

C4Aインスタンスに移行してよかったポイント

以下のポイントが挙げられます。

移行作業が簡単

次図の４ステップで特に問題なく移行を行うことができました。

理想的な負荷特性

CPU使用率に対して rps がほぼ線形となるため、ノードリソースの有効活用が行えます。

環境にも優しい

x86ベースに比べ、エネルギー効率が60%超となります。
使用リージョンの再生可能エネルギー率が 95% となっています²。

DDR4-3200：25.6GB/s → DDR5-5600：44.8GB/s (理論値) ↩
Googleの公開情報によると再生可能エネルギー率が 95% を超えるリージョンは 2025年8月25日時点では Finland, Stockholm, Zurich, Paris, Montreal の 5リージョンです ↩