パルワールドの185万同時接続を支えたクラウドインフラ最適化戦略：「月額7000万円」の出費を回避
2024年8月に開催されたGoogle Cloud Next Tokyo ’24で、オンラインゲーム「パルワールド」のインフラ戦略を、開発元のポケットペアが解説した。急激なユーザー数増加によるクラウドコストの増大に対し、アーキテクチャの見直しと工夫によって、コスト最適化を実現した。
パルワールドは、広大な世界で不思議な生物「パル」を集め、戦闘、建築、農業などを行わせながら冒険をする、オープンワールド・サバイバルクラフトゲームだ。最大32名のマルチプレイに対応し、ピアツーピアやコミュニティサーバなど、さまざまなやり方で楽しめる。2024年1月19日にリリースされ、2024年8月時点で累計プレーヤー数2500万人、PCゲームなどのオンライン販売を取り扱うプラットホーム「Steam」での同時接続数も210万人を超えている。
「この規模のヒットは予測していませんでした」と言うのは、開発・運営を行うポケットペアのリードネットワークエンジニア、中條博斗氏だ。ゲームのリリース直後、開発チームはさらなる品質の向上を目指し、アップデートをリリースするなど多忙を極めていた。
「ひょっとしてサーバ代で倒産する？」
そうした状況の中、「サーバ代で倒産する」と、ポケットペア代表取締役社長の溝部拓郎氏がXにポストし話題となる。この頃は、アクセス数の爆発的な増加に対し、サービスを落とさないようリソースを追加し対処していた。その結果、Google Cloudの費用が積み上がり、月額で7000万円を超える予測となった。その後すぐにコスト最適化を進め、結果的にははるかに少ない請求金額に収まった。
パルワールドのマルチプレイ環境は大きく分けて2種類ある。ピアツーピア（P2P）方式と、誰かが立てたサーバに参加する専用サーバ方式だ。
P2Pはプレーヤー同士で直接接続するやり方。ホストとなるプレーヤーが自分のPCをプレイ端末兼サーバとして動かし、他のプレーヤーを招待する。
専用サーバ方式は、文字通りサーバ専用機にゲームクライアントから接続するやり方だ。ポケットペアで運営する公式ゲームサーバは、誰でも無料で遊べる。また、有志が立てるサーバは「コミュニティサーバ」と呼ばれる。立てた人がさまざまなルールを設定でき、既に数万台が登録されている。
これらのサーバをゲーム内から直接閲覧、検索する仕組みは、ポケットペアからAPIサーバの形で提供されている。APIサーバは2つの役割を担う。1つ目はゲームサーバの一覧情報の提供で、公式ゲームサーバとコミュニティサーバの確認や検索ができる。
Spannerの活用で高性能と運用負荷の軽減を実現
ユーザーは、一覧からサーバを選択し、直接サーバに接続する。APIサーバはゲームサーバのIPアドレスやポート番号などの接続情報に加え、ユーザーがサーバを選択する際に必要なサーバ名や人数などの補足情報も管理する。
2つ目の役割が、不適切なテキストをフィルタリングする機能だ。これはゲーム内のチャットやプレーヤー名、パル名などで不適切なテキストをマスクする。APIサーバは、「Google Kubernetes Engine（GKE）」上でコンテナとして稼働している。アプリケーション自体はGo言語で実装されている。
ゲームのAPIサーバはゲーム自体のコンテンツやアップデートなどにより、アクティブユーザー数が大きく変化する。これによりAPIサーバの負荷も変動し、これにはGKEのオートスケーリング機能を使用し自動で対処している。
APIサーバの環境は、GKEを中心に「Cloud CDN」「Cloud Load Balancing」などを組み合わせで構成されており、ゲームクライアントからサーバ情報の取得や検索などのリクエストを受け取って処理する。ゲームサーバからは、登録人数の更新などを行う。サーバ情報のデータは、「Google Cloud Spanner（Spanner）」で管理している。また、テキストフィルターは一部処理に時間がかかるものがあるので、結果をキャッシュして高速化するためにメモリーストアのRedisを使用している。
当初は、最大30万台のゲームサーバを想定し、リクエスト数は1万QPS（Queries Per Second）程度の負荷に耐えることを要件としていた。そのための負荷試験段階で、大量サーバの情報を更新しながらユーザーがそのサーバ情報を検索する処理に耐えられないことが判明。より高い性能を得るためにSpannerが採用された。
Spannerには有効期間（TTL）機能があるが、厳密に処理するには検索クエリでWhere句を用い除外しなければならず、削除処理が最大72時間遅延する課題も発生した。稼働していないサーバ情報は削除する必要があるため、これはTTL機能には頼らず時間経過による削除処理機能を実装し対処している。
当初の要件は、リリース直後のものだ。時間が経過したことで、現状は最大で想定の3分の1程度の負荷にとどまっており、問題なく運用できている。
Spannerへのアクセス方法は、主に2つの実装がある。一つはPostgreSQLとの一貫性を提供するPGAdapterを使用するもの。もう一つは各種ライブラリーなどでSpannerのドライバを使用し、Google Standard SQLを用いる方法だ。
当初、Spannerへのクエリの実行にはPGAdapterを使用しPostgreSQLのクエリを実行していた。しかし、APIサーバとPGAdapterのCPUの負荷比率が1：5程度となった。オートスケーリングでこれを解消するのは難しく、CPU負荷が高くなることからPGAdapterを廃止してSpannerのドライバを使用する方法に移行した。
「API自体がそれほど複雑ではなかったことと、ライブラリが充実していたことで、比較的容易に実装を変更できました」と言うのは、ポケットペア リードインフラエンジニアの西北尚史氏だ。結果的にPGAdapterのオーバーヘッドがなくなり、性能は劇的に向上し、スケーリング設定も容易になった。結果として、リソース効率やコスト面でも大きな成果を得られたと説明する。
パルワールドのAPIサーバでは、APIサーバ自体とSpannerに対する負荷軽減の施策として、Cloud CDNを使用したキャッシュも利用している。サーバ一覧や検索結果などをキャッシュの対象としているためリアルタイム性は犠牲となるが、ゲームサーバの起動には時間がかかるため、数秒レベルの遅延は許容範囲内である。Cloud CDN自体は、APIサーバの稼働時から導入し、キャッシュヒット率はおおむね30〜40％で推移し一定の成果を上げている。
ゲームサーバ用途でもメリットの多いGKE
パルワールドは、同じワールドで複数人が同時にプレイできる。プレイ方法にはゲームクライアント同士で通信するコープモード、専用のサーバでソフトウェアを動作させ実現する専用サーバの2つがある。専用サーバには公式サーバとコミュニティサーバの2つがあり、公式サーバでもGKEを採用している。
一般に、ゲームサーバはステートフルなことが多い。セーブデータはデータベースではなくファイルに格納され、サーバとゲームクライアントが一対一に通信するため、並列化し負荷を軽減するのが難しい。
パルワールドのゲームサーバも、ステートフルセットを利用し1台のポッドで並列化せずに運用している。セーブデータはパーシステントボリュームを使い、ストレージにファイルとして保存する。
ゲームクライアントはノードのホストポートに直接接続し、Kubernetesでよく利用されるサービスやイングレス、Load Balancerなどは利用していない。一見、Kubernetesで管理するメリットは少ないように思えるが「GKEには便利な場面がたくさんあります」と、ポケットペア SREの笹和成氏は言う。
例えば、Kubernetesの自動化機能が利用できる。これがゲームサーバの運用を大きく助けてくれる。管理が容易で、起動時や終了時の何らかの処理や定期的な実行を、Kubernetesのリソースファイルを追加するだけで実現できる。これにより、VMやOSの管理から解放され、リソース管理の負担も軽減される。
Google Cloudの各種サービスとの連携も強力で、セーブデータのバックアップやリストアも容易に実現できる。管理対象のサーバは、Kubernetesマニフェストで起動され、GitHub上で管理することで状態把握を容易にしている。リソースファイルの操作履歴も残り、オペレーションの共通化や情報収集にも役立つ。公式サーバでは、プレーヤーの快適なプレイ体験のためにKubernetesの仕組みを最大限活用し、サーバプログラム本体への特殊な実装を最小限に抑えている。
「コンテナの不正終了時の自動再起動や、定期的なバックアップと再起動などもKubernetesの基本的な機能で実現できます」と、笹氏。これらはKubernetesの基本的な機能で実現できる。
バックアップとリストアは、パーシステントボリュームのバックアップにボリュームスナップショットを利用している。ボリュームスナップショットは「Google Compute Engine」のスナップショットに対応しており、Kubernetes内でリソースを作成するだけでGoogle Cloudにもリソースが自動的に作成される。
バックアップは差分バックアップ形式であり、前回のバックアップからの変更部分のみが保存されるため、バックアップサイズとコストを削減できる。リストアは、公式サーバが利用するパーシステントボリュームに、リストアしたい時点のボリュームスナップショットのリソース名を指定するだけで、その時点まで戻せるため非常に便利だ。
公式サーバは、Helmでパッケージングしている。パッケージには、サーバのイメージや設定、定期再起動やバックアップのリテンションのスクリプトも同梱している。HelmのバリューズはGitHub上で管理される。バリューズには、説明文やサーバに必要なスペック、定期再起動の間隔などの設定を記載し、ワークフローにはサーバ名やポート番号、リストアのためのボリュームスナップショットのリソース名など固有の値を記入している。
これらでサーバはコード化され、実験環境のパラメーターを変更するだけで簡単に本番環境に展開できる。サーバの数が増減しても、オートスケーリングが効くので物理的なマシンを考慮する必要はない。「もしVM（仮想マシン）を利用していたら、パッケージの詰め直しの手間が発生したり、サーバ数とリソース数を計算しうまく詰め直したりしなければなりません」と笹氏。GKEはHTTPサーバのような利用だけではなく、バルワールドのようなリアルタイムゲームサーバでもかなり有用だと強調した。
Copyright © ITmedia, Inc. All Rights Reserved.