スタンバイの規模拡張
PlayFab の規模拡張機能を使用すると、開発者は実際のプレイヤーの需要に合わせてゲーム サーバーのホスティング容量を調整できます。 これらの制御により、開発者はゲームサーバーのホスティング コストを効率的に抑えながら、マルチプレイヤー ゲームに新規プレイヤーを最小限の待ち時間で迅速に参加させるための十分な容量を確保することができます。
ゲーム サーバーの規模拡張は、ゲームが正常に展開され、運用された後に開発者が考えるものです。 このセクションで紹介する制御方法は、新規プレイヤーを最小限の待ち時間、または直ぐに追加できるだけの十分な容量を維持しながら、開発者がリソース拡張の弾力性を定めることに役立ちます。
準備状態とスタンバイ状態のサーバーはユーザーのタイトルに請求されるため、コストを削減するためにこれらのプロセスを最適化する必要があります。 ここでターゲット スタンバイについて計算する方法を得る前に、理解すると役に立つ用語を示します。
用語
スタンバイ サーバーのスケーリングについて理解する必要がある用語。
- ターゲット スタンバイ – スタンバイ ターゲット、そしてスタンディング バイ ターゲットとも呼ばれるこの値は、スタンバイ プールの枯渇を回避するために使用できる、スタンバイ サーバーのターゲット数を指定する、プラットフォームによって設定される値のセットです。
- ターゲット スタンバイ フロア– ゲーム開発者が設定可能な指標で、新しいゲーム サーバーの需要を満たすためにアイドル状態にしておくサーバーの最小フロア数を表します。
- 実際のスタンバイ – マルチプレイヤー サーバー プラットフォームで報告される待機中のサーバーの数で、動的スタンバイが有効な場合と無効な場合で値が異なります。
- 事前準備 - Azure と PlayFab では、仮想マシンを作成し、そのオペレーティング システムを初期化し、その環境を構成する必要があります。 PlayFab は、仮想マシンが顧客に割り当てられ、請求される前に、この事前準備アクティビティを推進します。
- 準備 - ゲーム サーバーのアセットを読み込む必要があり、ゲーム サーバー アプリケーションそれ自身も、しばしばプレイヤーのために準備の時間が必要です。
- Standing by マルチプレイヤー サーバーの需要を即座に満たすために、一部のサーバーはプレイヤーのために常にアイドル状態です。
ターゲット スタンバイの構成
ビルドごと、およびリージョンごとに、スタンバイ ターゲットを構成します。 通常、スタンディングバイ レベルは、準備時間とターゲット割り当て率に比例して設定する必要があります: 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 が要求され、さらに引き続いて、構成した多くのリージョンに対して続行されます。
規模拡張の利点
規模拡張の利点の概要は次を含みます:
| 利点 | 説明 |
|---|---|
| アプリケーションの可用性の向上 | 容量を事前にプロビジョニングすることで、ゲーム サーバー プールに常に適切な量の VM を配置していることを確認して下さい |
| コンピューティング コストの削減 | コストを最適化するために必要な場合にのみインスタンスを追加 |
| 購入オプション間でインスタンスを拡張 | 規模拡張オプションを使用することで、インスタンスの種類、領域、サイズ、およびゲーム サーバーのビルド構成全体でパフォーマンスを最適化 |
規模拡張メソッド
PlayFab には、サーバーを規模拡張するタイミングと方法を規模拡張するための複数のメカニズムが用意されています。 ゲーム開発者には、以下のような柔軟性があります。
- 最小しきい値と最大しきい値の構成
- (a) インスタンスの種類、(b) VM サイズ、(c) 領域などのサーバー ビルド プロファイルごとの拡張構成のカスタマイズ
- 開発者ポータルまたは Multiplayer Servers RESTful API から簡単に変更を管理
- サーバー、使用状況グラフで規模拡張メトリックを監視
ゲーム サーバーの規模拡張を構成する 3 つの方法は次のとおりです:
- 既定
- 予定
- 動的
それぞれに固有のアプローチがありますが、プレーヤーの需要が既知または未知の状態であることがトリガーとなります。 既定の方法では、設定された最大のサーバーまで規模拡張し、完了したセッションに応じて規模縮小します。 このメカニズムでは、開発者に要求された追加の特別な手順はありません。 これは最も簡易な方法で、そこでは開発者がサーバーの最大数とスタンバイ数の上限を設定することで、PlayFab がプレイヤーの要求に応じて VM を自動的に縮小そして拡張させます。
| コントロール | プレイヤーの需要 | 方法 | ユース ケース | Yield |
|---|---|---|---|---|
| 既定 | 予期しない | 自動 | 通常のゲーム操作 | トラフィックの急増に対して十分な速度で拡張しない |
| 予定 | 予測可能 | 計画 | 計画されているイベントの起動 | プレイヤー需要のシフトのスケジュール変更を追跡する |
| 動的 | 予期しない | 数式 | 急激なトラフィックの急増 |
規模拡張の選択肢の広さを十分に理解するためには、まず以下の主要な概念と用語を理解する必要があります。
主要な概念
- 規模拡張メカニズムは、スタンバイ サーバーの可用性の数を制御します
- スタンバイ サーバーは、アクティブな接続プレイヤーが存在しない、 VM に割り当てられたサーバーです。 RequestMultiplayerServer API 呼び出しに応答してプレイヤー接続の受け入れに遷移します: ゲーム サーバー プロセスが終了すると、終了状態に遷移します
- 規模拡張メカニズムは、ビルドの各領域で一意に適用されます
- 各規模拡張構成は、領域のオーバーライドとして表されます
スタンバイ プールの不足
PlayFab のマルチプレイヤー サーバーは、スタンバイ サーバーのバンクを提供します。 プレイヤーの要求に応じてゲーム サーバーを追加する要求を即時に満たすことについての支援を提供します。 追加サーバーの需要が、予約からサーバーを取得してプロビジョニングするために必要な時間よりも速く増加すると、スタンバイ サーバーのプールが枯渇します。 使用可能なサーバーのプールは「不足」状態になり、追加のサーバーをプロビジョニングできるようになるまでゲーム サーバーの要求は失敗します。 スケジュール スタンバイと動的スタンバイ スケーリングの方法では、プレイヤーの需要に応じてゲームサーバーのプロビジョニング増加が自動的に有効化させます。