メインコンテンツへスキップ
ビルド エイリアスは、ビルドの上位にある管理レイヤーで、RequestMultiplayerServer の呼び出しを複数のビルドに制御された方法で分散させることができます。これにより、ビルド間のアップグレードや以下に示すいくつかのシナリオが、よりシンプルかつ信頼できるものになります。エイリアスは、各ビルドの ID とその重みのリストを指定することでこれを実現します。ビルドの重みは、各割り当てリクエストでそのビルドが最初に試行される可能性を設定します。たとえば、Build 1 の重みが 8、Build 2 の重みが 2 の場合、Build 1 はリクエストの約 80% で最初に試行されるため、StandingBy サーバーがある間はリクエストの約 80% を処理します。あるリージョンで Build 1 の StandingBy サーバーがなくなると、それらのリクエストは代わりに Build 2 に送られるため、そのリージョンでは Build 2 がリクエストの 20% を超えて処理する場合があります。ただし、各リクエストのリージョンが優先され、重みはリージョン内でどのビルドがリクエストを処理するかを決定するだけです。詳細については、他のビルドやリージョンへのフォールバックを参照してください。

後方互換性のある安全な展開

これは、ビルド間のアップグレードで最も一般的なシナリオで、ゲーム サーバーを更新し、リテール クライアントが両方のサーバーと互換性がある場合です。 クライアントは、次の構成を持つ Alias 1 を参照します:
  • Build 1: Weight = 1
Build 2 が作成されると、Alias 1 は次のように変更されます:
  • Build 1: Weight = 8
  • Build 2: Weight = 2
すべての新しいサーバー要求が Build 2 によって満たされるようになるまで、重みを徐々に変更していくことができます。この時点で Build 1 の重みは 0 になり、エイリアスから削除できます。 エイリアスの典型的な使用例は、クライアントの互換バージョンとゲーム モードに関連付けることです。たとえば “DeathMatch client 2.2 RETAIL” のようになります。エイリアスを使用すると、この体験を支えるビルドを継続的に更新しつつ、この高レベルの抽象化を管理できます。エイリアスは、必要に応じてビルドをロールバックすることも容易にします。

後方互換性のない展開

このケースでは、現在のゲーム クライアントが古いサーバー ビルドと互換性がないため、ゲーム クライアントの更新と同時にゲーム サーバーを更新したいと考えています。あるビルドから別のビルドへの移行は、次のように行います: 古いクライアントは Alias 1 を参照し、次の構成となります:
  • Build 1: Weight = 1
Build 2 が作成されると、新しいクライアントは Alias 2 を参照し、次の構成となります:
  • Build 2: Weight = 1
このシナリオでは、エイリアスはビルドと同様に使用され、その多重化機能は使用されません。

後方互換性のある一括展開

これは、後方互換性のあるビルド間のアップグレード シナリオに似ていますが、需要の変化がより急激です。あるビルドから別のビルドへの移行は、次のように行います: クライアントは Alias 1 を参照し、次の構成となります:
  • Build 1: Weight = 1
Build 2 が作成されると、Alias 1 は次のように変更されます:
  • Build 1: Weight = 0
  • Build 2: Weight = 1

後方互換性のある展開のテスト

ゲーム サーバーを更新したい場合で、クライアント バージョンが両方のサーバーと互換性がありますが、すべてのプレイヤー向けに大規模に展開する前に 2 番目のバージョンをテストしたい場合。あるビルドから別のビルドへのテストと移行は、次のように行うことができます: クライアントは Alias 1 を参照し、次の構成となります:
  • Build 1: Weight = 1
Build 2 が作成されると、テスト クライアントは Alias 2 を参照し、次の構成となります:
  • Build 2: Weight = 1
Build 2 が検証されると、Alias 1 は次のように変更されます:
  • Build 1: Weight = 8
  • Build 2: Weight = 2
徐々に Build 2 の重みが増え、すべてのトラフィックを吸収するようになります。

他のビルドやリージョンへのフォールバック

エイリアスは、複数のビルド間でフォールバックを可能にすることで、マルチプレイヤー サーバー展開をより堅牢にします。エイリアスからサーバーを要求する場合は、プレイヤーに許容できるエクスペリエンスを提供するすべてのリージョンを、優先順に PreferredRegions に列挙します。PlayFab Multiplayer Servers (MPS) は、各リクエストを次のように処理します:
  1. MPS はビルドの重みを使用して、リクエストに対するエイリアスのビルドの順序を決定します。重みが大きいビルドほど、最初に来る可能性が高くなります。
  2. MPS は、列挙された順にリージョンを確認します。各リージョンで、その順序ですべてのビルドを試行します。そのリージョンに展開されていないビルドはスキップされます。
  3. MPS は、StandingBy サーバーを持つ最初のビルドからサーバーを割り当てます。そのリージョンにどのビルドにも StandingBy サーバーがない場合、MPS は次のリージョンに進みます。どのリージョンにもない場合、リクエストは MultiplayerServerTooManyRequests エラーで失敗します。
リージョンの順序は、常にビルドの重みよりも優先されます。プレイヤーには容量のある最も優先度の高いリージョンのサーバーが割り当てられ、重みはそのリージョンでどのビルドがプレイヤーを処理するかを決定するだけです。重みは、ビルド間 (たとえば仮想マシン (VM) サイズ間) のコストとパフォーマンスの優先度を表すために使用します。より多くのリージョンをカバーするビルドをエイリアスに追加しても、容量が増えるだけです。 重みが 0 のビルドは、フォールバックとしても割り当てに使用されることはありません。ビルドをフォールバックとして保持するには、代わりに小さな 0 以外の重み (たとえば、メイン ビルドの 999 に対して 1) を指定します。 エイリアスのどのビルドも要求されたどのリージョンにも展開されていない場合、リクエストは MultiplayerServerNotFound エラーで失敗します。両方のエラーを回避する方法については、ベスト プラクティスと起動チェックリストを参照してください。 たとえば、EastUS をリージョン #1、West US をリージョン #2 としてランク付けするビルド エイリアスをターゲットとする割り当てリクエストがあるとします。このビルド エイリアスは、Build 1 と Build 2 の 2 つのビルドに同様の重みを付けています。 ある割り当てで Build 1 が順序の最初に来ると仮定します。
  1. East US での Build 1 の割り当てが試行されます。
  2. #1 が失敗した場合、East US での Build 2 の割り当てが試行されます。
  3. #2 が失敗した場合、WestUS での Build 1 の割り当てが試行されます。
  4. #3 が失敗した場合、WestUs での Build 2 の割り当てが試行されます。
特に、あるビルドから別のビルドへ徐々にアップグレードする場合、このフォールバック動作は、いずれかのビルドに問題があってもプレイヤーが最低レイテンシーのサーバーを取得できるように最適化されています。

PlayFab REST API を使用したビルド エイリアスの管理

Game Manager でビルド エイリアスを管理できるようになりました。開始するには、「Builds overview page」を参照してください。
  1. API を使用してビルド エイリアスを作成します。 API:
    サンプル ボディ:
    サンプル レスポンス:
    ビルド エイリアス ID はレスポンスの一部として提供されます。
  2. ビルド エイリアスの任意のパラメーターを更新します。 API:
    サンプル ボディ:
    サンプル レスポンス:
  3. ビルド エイリアスを削除します。 API:
    サンプル ボディ:
  4. ビルド エイリアスを一覧表示します。 API:
    サンプル レスポンス:

ビルド エイリアスを使用して割り当てる

ビルド エイリアスを使用して割り当てるには、RequestMultiplayerServer の呼び出しでビルド エイリアス ID を指定します。 API:
サンプル ボディ:
最終更新日 2026年10月20日