Amazon GameLift Servers - ターゲットベーススケーリング詳解
はじめに
本記事では Amazon GameLift Servers におけるスケーリング機能について、公式ドキュメントをもとに整理します。特に managed EC2 fleet の自動スケーリング機能を対象とし、主にターゲットベーススケーリングにフォーカスして仕組みと特性を解説します。
Amazon GameLift Servers の概要
Amazon GameLift Servers は、マルチプレイヤーゲーム向けの専用ゲームサーバーを AWS 上でホスティングできるマネージドサービスです。 managed EC2 fleet を利用することで、ゲームサーバーのデプロイ、インスタンスのヘルス管理、スケーリング、メトリクスレポートなどの運用をサービス側に任せながらゲームを提供できます。
GameLift Servers で使う主な用語
基本構成要素に関する用語
-
フリート (fleet) :
GameLift Servers が管理するゲームサーバー群の単位です。特定のゲームビルドとインスタンスタイプの組み合わせで構成される EC2 インスタンスの集合を指します。 -
インスタンス (instance) :
フリート内で起動される Amazon EC2 インスタンスです。ゲームサーバープロセスを実行し、ゲームセッションをホストします。 -
ゲームサーバープロセス (game server process) :
インスタンス上で実行されるゲームサーバーアプリケーションのプロセスです。ひとつのインスタンス上に複数プロセスを起動できます。
セッション関連の用語
-
ゲームセッション (game session) :
プレイヤーが参加するゲームのひと区切りです。部屋やマッチに相当し、プレイヤーが集まりゲームをプレイする単位を指します。 -
プレイヤーセッション (player session) :
プレイヤーとゲームセッションの紐付けを表す概念です。特定のプレイヤーがどのゲームセッションに参加しているかを GameLift が管理するために使います。
容量設定とスケーリング対象の用語
-
目的のインスタンス数 (Desired capacity) :
フリートで維持したいインスタンス数です。スケーリングポリシーは最終的にこの値を増減し、 GameLift が Desired capacity に向けてインスタンスを起動したり終了したりします。 -
最小サイズ (Minimum capacity) :
フリートで許可されるインスタンス数の下限です。スケーリングによっても、この値より少ないインスタンス数にはなりません。 -
最大サイズ (Maximum capacity) :
フリートで許可されるインスタンス数の上限です。予期しないスケールのし過ぎを防ぐための安全上限として使います。
スケーリングポリシー関連の用語
-
ターゲットベーススケーリング (target based auto scaling) :
特定のメトリクスの値が設定した目標値に近づくように、インスタンス数を自動的に増減する方式です。 GameLift Servers では PercentAvailableGameSessions を対象として、ゲームセッションの余力を一定割合に保つために使います。 -
ルールベーススケーリング (rule based auto scaling) :
メトリクスとしきい値、比較条件、評価期間、増減量などを組み合わせてルールを定義し、その条件を満たしたときにインスタンス数を増減する方式です。ターゲットベースだけではカバーしにくい条件を補うときに使います。 -
スケーリングポリシー (scaling policy) :
ターゲットベースまたはルールベースのいずれかの方式で定義された、スケーリングの設定一式です。ひとつのフリートに複数のポリシーを設定できます。
対象読者
- GameLift Servers の導入を検討しており、スケーリング仕様を正しく理解したいエンジニア
- 既存のゲーム基盤を GameLift Servers に移行し、コスト最適化と安定稼働を両立したいアーキテクト
参考情報
- Auto scale fleet capacity with Amazon GameLift Servers
- Target-based auto scaling - Amazon GameLift Servers
- ScalingPolicy API リファレンス (MetricName、 PolicyType など)
GameLift Servers のスケーリング機能の全体像
フリート容量とスケーリング対象
GameLift Servers のスケーリングは、フリートに属する EC2 インスタンス数を増減する機能です。フリート容量は、そのフリートが同時にホストできるゲームセッション数やプレイヤー数の上限に直結します。
managed EC2 fleet では、各フリート (およびロケーション) に対して次の 3 つの値を持ちます。
- 最小サイズ (Minimum size) : インスタンス数の下限
- 最大サイズ (Maximum size) : インスタンス数の上限
- 目的のインスタンス数 (Desired capacity) : 実際に維持したいインスタンス数
スケーリング機能は最終的にこの Desired capacity を更新し、それに合わせてインスタンスの起動と終了が行われます。 GameLift Servers は、最小サイズと最大サイズの範囲内でのみ Desired capacity を変更します。
スケーリング容量 > 編集 ボタンから変更できます。


スケーリング方式の種類
GameLift Servers の自動スケーリングでは、次の 2 種類のポリシー方式が提供されています。
- ターゲットベーススケーリング (PolicyType : TargetBased)
- ルールベーススケーリング (PolicyType : RuleBased)
ターゲットベーススケーリングは、特定のメトリクスの値が目標値に近づくようにインスタンス数を調整します。 GameLift Servers では PercentAvailableGameSessions というメトリクスだけを対象にしたターゲットトラッキングとして実装されています。

ルールベーススケーリングは、メトリクスのしきい値、比較条件、評価期間、増減量などを組み合わせてルールを書き、条件を満たした場合にインスタンス数を増減します。ターゲットベースを補完するための手段として位置付けられています。

ターゲットベーススケーリングの仕組みと特徴
PercentAvailableGameSessions とバッファの考え方
ターゲットベーススケーリングは PercentAvailableGameSessions というメトリクスを追跡します。 PercentAvailableGameSessions は、現在のフリート容量に対して未使用のゲームセッションがどれだけ残っているかを示す割合です。
この割合は、プレイヤーの急な増加に対するバッファと見なせます。空きセッションスロットが十分にあれば、新規プレイヤーは数秒程度でゲームセッションに参加できます。一方で空きがない場合は、新しいインスタンスやサーバープロセスが起動するまで、または既存ゲームの終了を待つ必要があり、プレイヤー待機時間が分単位になる可能性があります。
ターゲットベースポリシーの動作
- フリートの PercentAvailableGameSessions を継続的に監視します。
- この値が設定した目標値より低くなった場合、 Desired capacity を増やしてインスタンスを追加し、空きセッション割合を増やします。
- この値が目標値より高い状態が続く場合、 Desired capacity を減らしてインスタンスを削除し、余剰な容量を減らします。

デモアプリを作成し、実際のスケーリングの挙動を確認した際のキャプチャです。反応型=ルールベース、目標追従=ターゲットベースとして、2種のフリートのスケーリング挙動を検証しました。
ターゲットベーススケーリングのメリットとデメリット
ターゲットベーススケーリングのメリットは次の通りです。
- メトリクスと目標値を指定するだけで、自動的にスケールアップとスケールダウンを行えるため、設定がシンプルです。
- 需要の増減に追従しながら常に一定割合のバッファを保てるため、ピーク時のプレイヤー待機時間を抑えやすいです。
- バッファの割合を調整することで、プレイヤー体験とコストのバランスを明示的に設計できます。
一方で、次のようなトレードオフがあります。
- 常に一定割合の空きセッションを持つ設計のため、ターゲット値を高く設定すると、平常時でも未使用インスタンスのコストがかかります。
- 特定メトリクスのしきい値に応じた細かい制御 (たとえば QueueDepth や WaitTime に応じたエスカレーション) は、別途ルールベーススケーリングで補う必要があります。
まとめ
本記事では、 Amazon GameLift Servers の managed EC2 fleet を対象に、フリートスケーリングの基本とターゲットベーススケーリングの仕組みを整理しました。ターゲットベーススケーリングによって、 PercentAvailableGameSessions を用いてバッファを自動的に維持し、プレイヤー待機時間とコストのバランスをシンプルに設計できます。実際の負荷をかけた検証や、ルールベーススケーリングとの組み合わせを検討することで、自分たちのタイトルに適したスケール戦略を作り込んでいけます。






