用語
スタンバイ サーバーのスケーリングについて理解すべき用語です。- Target Standby – 一般に Standby Target や Standing by target とも呼ばれ、スタンバイ プールの枯渇を防ぐために利用可能な状態にしておくスタンバイ サーバー数のターゲット数値をプラットフォームによって設定される値です。
- Target Standby Floor – 新しいゲーム サーバーの需要を満たすためにアイドル状態に保つサーバー数の最小床値を表す、ゲーム開発者が構成可能な指標。
- Actual Standby – Multiplayer Servers プラットフォームによって報告されるスタンバイ サーバーの数量。その値は、Dynamic Standby が有効化されている場合と、Dynamic Standby が無効化されている場合とで異なります。
- Pre-propping - Azure と PlayFab は、仮想マシンを作成し、そのオペレーティング システムを初期化し、その環境を構成する必要があります。PlayFab は、仮想マシンが顧客に割り当てられて課金される前に、この pre-propping アクティビティを行います。
- Propping - ゲーム サーバー アセットをロードする必要があり、ゲーム サーバー アプリケーション自体も、多くの場合、プレイヤーの準備をするための時間が必要です。
- Standing by マルチプレイヤー サーバーの需要を即座に満たすために、一部のサーバーはプレイヤー向けに常時アイドル状態のまま準備されています。
Target standby の構成
スタンドバイ ターゲットは、ビルドごと、リージョンごとに構成します。通常、スタンドバイ レベルは、プロッピング時間とターゲット割り当てレートに比例して設定する必要があります。 Standing by Target = (Propping Time + Server time to standing by) * Target Allocation Rate たとえば、プロッピングに 100 秒かかる Linux サーバーで、5 秒ごとに最大 1 台のサーバーが割り当てられる (0.2 サーバー/秒) と予想されるゲームの場合。100 * 0.2 = 20 サーバーのスタンドバイ プールが、このビルドを安定してサポートします。100 秒後には 20 サーバーが消費されますが、別の 20 サーバーを構築する時間があったことになります。RequestMultiplayerServer API を呼び出す際には、プレイヤー エクスペリエンスにおいて許容できるすべてのリージョンを指定することが重要です。リージョン #1 に利用可能なスタンドバイ サーバーがない場合は、リージョン #2 が要求され、構成したリージョンの数だけ続行されます。
スケーリングの利点
スケーリングの利点の概要は以下のとおりです。スケーリング方法
PlayFab は、サーバーをいつ、どのようにスケーリングするかに関する複数のメカニズムを提供します。ゲーム開発者は以下の柔軟性を持っています。- 最小および最大しきい値の構成
- (a) インスタンス タイプ、(b) VM サイズ、(c) リージョンなどのサーバー ビルド プロファイルごとにスケール構成をカスタマイズ
- 開発者ポータルまたは Multiplayer Servers RESTful API から手軽に変更を管理
- サーバーおよび使用状況チャートでスケーリング メトリックを監視
- Default
- Scheduled
- Dynamic
スケーリング オプションの全範囲を完全に活用するには、まず以下の主要な概念と用語を理解する必要があります。
主要な概念
- スケーリング メカニズムは、スタンバイ サーバーの可用性の数を制御します
- スタンバイ サーバーとは、アクティブに接続されたプレイヤーがいない VM 割り当て済みサーバーです。これらは、RequestMultiplayerServer API 呼び出しに応じてプレイヤー接続を受け入れる状態に遷移します。ゲーム サーバー プロセスが終了すると、終了状態に遷移します
- スケーリング メカニズムは、ビルドの各リージョンで一意に適用されます
- 各スケーリング構成は、リージョン オーバーライドとして表現されます