ゲームサーバー構築の観点から見たEC2とCompute Engineの比較

はじめに

最近友人に依頼されたり、自分自身でゲームをプレイするためにマルチプレイ用のゲームサーバーを構築する機会が多々ありました。仕事柄AWSが提供するEC2とGoogle Cloudが提供するCompute Engineに触れることが多いので、構築の際は主にこの2つのサービスを使い分けながら作業を進めています。

そこで今回はこれまでの作業で得られた経験をもとに、両サービスの相違点についてまとめてみました。既にどちらかのサービスを利用してゲームサーバーを構築されている方や、サービスの選択に悩んでいる方の一助になれば幸いです。

1. 料金体系とコスト

多くの人がサービスを選択する上でここを気にすると思います。今回は最終的な費用として響いてくる3つの観点からまとめてみました。

スポットインスタンスの挙動

両クラウドともに余剰キャパシティを安価に利用できる仕組み（AWS Spot Instances / Google Cloud Spot VMs）がありますが、回収時の猶予時間や価格変動のモデルが異なります。

• EC2ではスポットインスタンス中断予告が飛んでから終了するまでに2分間の猶予がありますが、Compute Engineには30秒の猶予しかありません。実際のところ30秒のうちにセーブとプロセス終了を完了させるのはシビアであり、自動セーブ等で対応するのが現実的になります。

• 価格変動の観点では、Google CloudのSpot VMの単価は各リージョン・マシンタイプごとに固定されており、突発的な価格変動が発生しないのに対し、AWSのEC2では需給状況に応じて価格が緩やかに変動します。

継続利用割引

少人数の利用を想定し、随時サーバーを落とす運用を想定されている方には不要な観点ですが、ある程度の人数の方が時間を問わず遊ぶことを想定されている方は継続利用割引の違いについて理解しておく必要があります。

• Google Cloud: N1やN2などの汎用インスタンスは、1ヶ月の中で一定割合（25%以上）稼働させるだけで、月末に継続利用割引（SUD）が自動適用されます。※ただし、安価なE2シリーズやTau T2AなどはSUD対象外

• AWS: 事前契約を結ばない限り、継続利用の割引を受けることはできません。割引を受けるにはCompute Savings Plansなどを事前契約する必要があります。

停止中に発生するコスト

少人数のプレイを前提にされている方の多くは利用時のみ起動し、それ以外は停止しておく運用をされると思います。両サービスとも停止時に料金が発生しますが、その加算方法が異なります。差分が発生するのは静的なパブリックIPの取り扱いの部分です。

• AWS: インスタンスにアタッチされていようと、停止していようと、保持しているパブリックIPv4アドレス1つにつき一律約$3.6/月（$0.005/時間）が発生します。

• Google Cloud: インスタンスが起動して通信を行っている間は低価格（条件により無料枠あり）ですが、VMを停止してIPアドレスが「未使用（未アタッチ）」状態になると、$0.010/時間（約$7.2/月）の待機ペナルティ課金が発生します。

停止中も静的なパブリックIPを使用する場合はGoogle Cloudの方が高く付きそうです。

2. コンピュート性能とインスタンスの特性

快適なゲームプレイのためには適切なスペックのインスタンスを構築する必要があります。コスパ良くインスタンスを選択するには下記の差を理解した上で考えると良いかもしれません。

バースト系インスタンスの挙動の差

コストを抑えるたいときに候補に上がるバースト系インスタンスですが、負荷限界に達したときの挙動がサービス毎に大きく異なります。

• AWS（T3 / T4g）: CPUクレジット方式

  • アイドル時に「クレジット」を蓄積し、ワールド生成や爆発などでCPU使用率が跳ね上がるとクレジットを消費してバーストします。

  • 弱点: 長時間プレイしてクレジットが完全に枯渇すると、CPU性能がベースライン（例: 20〜40%）に厳格に固定されます。結果としてTick落ち（TPS低下）、プレイヤーの巻き戻り（ラバーバンド）、最悪の場合はタイムアウト切断が頻発します。

• Google Cloud（E2シリーズ）: 動的スケジューリング方式

  • こちらにはCPUクレジットという概念がありません。ホスト側のハイパーバイザーがリソースの空き状況に応じて動的にCPUタイムスライスを割り当てます。

  • クレジット切れによる急激な性能低下は起きませんが、同居する他のテナントの負荷状況によってパフォーマンスにわずかなブレ（ジッター）が生じることがあります。

インスタンスのカスタマイズ性

プレイするゲームによって必要となるリソースが異なります。リソースの追い込みという観点ではGoogle Cloudに軍配が上がります。

• Google Cloud「カスタムマシンタイプ」

  • Google Cloudでは、vCPU数とメモリ容量を1vCPU / 1GB単位で自由に組み合わせてインスタンスを作成できます（例: 2 vCPU / 16GB RAM や 4 vCPU / 24GB RAM）。

• AWSの制約（固定比率）

  • AWSはあらかじめ定義されたインスタンスファミリーから選択する必要があります。例えばメモリを16GB確保しようとすると、メモリ最適化の r6i.large（2 vCPU / 16GB）や、汎用の m6i.xlarge（4 vCPU / 16GB）などを選ぶ必要があり、世代やインスタンスタイプごとの選択肢に縛られてしまいます。

3. ストレージ構成とI/O性能の決定方式

ゲームサーバーにおいて、ストレージのI/O性能（読み書き速度）は「オートセーブ時のラグ（サーバーの一瞬のフリーズ）」や「新規エリア探索時の地形生成（チャンク生成）の滑らかさ」に直結します。AWSの「EBS（Elastic Block Store）」とGoogle Cloudの「Persistent Disk（PD）」では、このI/O性能の決まり方に決定的な違いがあり、注意する必要があります。

小容量ディスクを選んだ際の性能

少人数用ゲームサーバーの場合、OSとゲームデータを含めてもディスク容量は30GB〜50GB程度あれば十分なことが多いです。※Terrariaなどの軽量な2Dゲームの場合、10~20GBで済んでしまいます。
しかしこのくらいの小容量ディスクを選んだ場合の性能は大きく異なります。

• AWS（gp3）: 初期の状態から「爆速」

  • AWSの現行標準である gp3 ボリュームは、ディスク容量に関わらず最低でも「3,000 IOPS」および「スループット 125 MB/s」がベースラインとして無料で付与されます。

• Google Cloud（Persistent Disk）: 容量比例スケーリングの罠

  • Google Cloudの標準的な pd-balanced（バランス型永続ディスク）は、ディスクのGB数に比例してIOPSやスループットの上限が決まる仕様です。※もしゲーム用に30GBの pd-balanced を作成した場合、書き込みスループットはわずか 4.2 MB/s 程度に制限されます。この状態でゲームのオートセーブが走るとディスクの書き込み待ち（I/Oボトルネック）が発生してしまう可能性があります。

これを回避するためにGoogle Cloudでは十分なI/O性能を確保するために敢えてオーバーな容量を確保する必要がある場合があります。もしくはより高性能なSSD永続ディスク（pd-ssd）を選択することでも回避できますが、費用はやや高く付きます。

4. ネットワーク費用とパブリックIPアドレス

データ転送（下り・アウトバウンド）の費用

AWSはEC2からのインターネットアウトバウンド通信に対して毎月 100GB の無料枠があります。一方、Google Cloudは「Standard Tier」というルーティング方式を選択すると毎月 200GB の無料枠が利用できます。

数人で週末や夜間にプレイする程度であれば、月間のアウトバウンド通信量は数十GBに収まることが多く、AWSでもGoogle Cloudでも通信費は実質無料（無料枠内）に収まるケースが大半です。
MODを大量に導入したマインクラフトを大人数で遊ぶようなチャンクの読み込みを多く必要とする運用を考えている場合はここも考慮する必要があります。

Compute Engine特有機能「ネットワーク ティア」の存在

Google Cloud特有の機能として、高品質なGoogle独自のグローバルファイバー網を通る「Premium Tier」と、一般的なインターネットISPを経由する安価な「Standard Tier」を選べます。ゲームのPingを下げたい場合はPremium Tierを選択しましょう。
※東京リージョン（asia-northeast1）にインスタンスを作成すればStandard Tierを選択してもプレイに支障が出るほどの遅延は発生しないことが多かったです。

最後に

自分でこの記事を作っている間にも意外と知らなかった観点が多いことに気づきました。私は少人数のサーバー運用になることが多いため、これらの観点を気にしても大きな差額になることはあまりありませんが、SEとしてはこれらを意識して選定する必要があるかもしれません。
今後はEC2やCompute Engine以外のサービスを利用したより安い構成について考えてみたいです。