

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# ゲームセッション配置のカスタマイズ
<a name="customize-game-session-placement"></a>

ゲームセッション配置のカスタマイズにより、配置システムをファインチューニングして、プレイヤーベースに可能な限り最高のゲームプレイエクスペリエンスを提供することができます。プレイヤーの互換性と設定、コスト効率、地理的分散、サービスの中断に対する耐障害性などの運用上の考慮事項に合わせて配置を最適化できます。

# ゲームセッションキューをカスタマイズする
<a name="queues-design"></a>

このトピックでは、ゲームセッションキューをカスタマイズして、ゲームセッションの配置に関する最善の決定を行う方法について説明します。ゲームセッションキューとその仕組みの詳細については、「[ゲームセッションの配置を設定する](queues-intro.md)」を参照してください。

以下の Amazon GameLift Servers 機能にはキューが必要です:
+ [FlexMatch でのマッチメーキング](https://docs.aws.amazon.com/gameliftservers/latest/flexmatchguide/match-tasks.html)
+ [スポットインスタンスのキューの設計](spot-tasks.md)

**Topics**
+ [キューのスコープを定義する](queues-design-scope.md)
+ [マルチロケーションキューを構築する](queues-design-multiregion.md)
+ [キューメトリクスの評価](queues-design-metrics.md)

# キューのスコープを定義する
<a name="queues-design-scope"></a>

ゲームのプレイヤー集団には、一緒にプレイしてはいけないプレイヤーグループが存在する可能性があります。たとえば、ゲームを 2 つの言語で公開する場合、各言語には独自のゲームサーバーが必要です。

プレイヤー集団のゲームセッション配置を設定するには、プレイヤーセグメントごとに個別のキューを作成します。各キューをスコープ設定して、プレイヤーを正しいゲームサーバーに配置します。キューのスコープ設定の一般的な方法には、次のようなものがあります。
+ **地理的なロケーション別。**複数の地理的エリアにゲームサーバーをデプロイする場合、プレイヤーのレイテンシーを削減するために、ロケーション別にプレイヤー用のキューを構築できます。
+ **ビルド/スクリプトのバリエーション別。**ゲームサーバーのバリエーションが複数ある場合は、同じゲームセッションでプレイできないプレイヤーグループをサポートしている可能性があります。例えば、ゲームサーバーのビルドまたはスクリプトは、異なる言語やデバイスタイプなどをサポートすることがあります。
+ **イベントタイプ別。**特別なキューを作成して、トーナメントやその他の特別なイベント参加者のゲームを管理できます。

## 複数のキューを設計する
<a name="queues-design-players"></a>

ゲームとプレイヤーによっては、複数のゲームセッションキューを作成する必要がある場合があります。ゲームクライアントサービスが新規のゲームセッションをリクエストする際に、どのゲームセッションキューを使用するか指定されます。複数のキューを使用するかどうかを判断するには、以下を検討してください。
+ ゲームサーバーのバリエーション。ゲームサーバーのバリエーションごとに個別のキューを作成することができます。キュー内のすべてのフリートは、互換性のあるゲームサーバーをデプロイする必要があります。これは、キューを使用してゲームに参加するプレイヤーが、キュー内の任意のゲームサーバーでプレイできる必要があるためです。
+ 異なるプレイヤーグループ。Amazon GameLift Servers がプレイヤーグループに基づいてゲームセッションを配置する方法をカスタマイズできます。たとえば、特別なインスタンスタイプまたはランタイム設定を必要とする特定のゲームモードに合わせてキューをカスタマイズする必要がある場合があります。または、トーナメントやその他のイベントのプレースメントを管理するために特別なキューが必要な場合があります。
+ ゲームセッションのキューメトリクス。ゲームセッションの配置メトリクスの収集方法に基づいて、キューを設定できます。詳細については、「[キューの Amazon GameLift Servers メトリクス](monitoring-cloudwatch.md#gamelift-metrics-queue)」を参照してください。

# マルチロケーションキューを構築する
<a name="queues-design-multiregion"></a>

すべてのキューにマルチロケーション設計を推奨します。この設計により、プレイスメント速度とホスティングの耐障害性が向上します。プレイヤーレイテンシーデータを使用して、最小のレイテンシーでプレイヤーをゲームに参加させるには、マルチロケーション設計が必要です。スポットインスタンスフリートを使用するマルチロケーションキューを構築する場合は、「[スポットフリートによるゲームホスティングコストの削減](fleets-spot.md)」の手順に従ってください。

マルチロケーションキューを作成する 1 つの方法は、[マルチロケーションフリート](gamelift-regions.md#gamelift-regions-hosting)をキューに追加することです。こうすることで、キューは、任意のフリートのロケーションにゲームセッションを配置できます。冗長性を保つため、設定やホームロケーションが異なる他のフリートを追加することもできます。マルチロケーションのスポットインスタンスのフリートを使用している場合は、ベストプラクティスに従って、同じロケーションを含むオンデマンドインスタンスのフリートを含めてください。

次の例では、基本的なマルチロケーションキューの設計プロセスについて説明します。この例では、2 つのフリートを使用します。1 つはスポットインスタンスフリートで、もう 1 つはオンデマンドインスタンスフリートです。各フリートには、配置場所 AWS リージョン として `us-east-1`、、`us-east-2``ca-central-1`、および があります`us-west-2`。

**マルチロケーションフリートを含む基本的なマルチロケーションキューを作成するには**

1. キューを作成するロケーションを選択します。クライアントサービスをデプロイした場所の近くのロケーションにキューを配置することで、リクエストの待ち時間を最小限に抑えることができます。この例では、キューを `us-east-1` に構築します。

1. 新しいキューを作成し、キューの送信先としてマルチロケーションフリートを追加します。送信先の順序によって、Amazon GameLift Servers がゲームセッションを配置する方法が決まります。この例では、最初にスポットインスタンスフリートをリストし、オンデマンドインスタンスフリートを 2 番目にリストしています。

1. キューのゲームセッションのプレイスメント優先順位を定義します。この順序により、キューが利用可能なゲームサーバーを最初に検索するロケーションが決まります。この例では、デフォルトの優先順序を使用します。

1. ロケーションの順序を定義します。ロケーションの順序を定義しない場合、Amazon GameLift Servers はロケーションをアルファベット順に使用します。

![\[サンプルキューの場所と送信先順序を示すコンソールのスクリーンショット。\]](http://docs.aws.amazon.com/ja_jp/gameliftservers/latest/developerguide/images/queue-multi-location-1.png)


![\[サンプルキューの配置優先度とロケーションの順序を示すコンソールのスクリーンショット。\]](http://docs.aws.amazon.com/ja_jp/gameliftservers/latest/developerguide/images/queue-multi-location-2.png)


# キューメトリクスの評価
<a name="queues-design-metrics"></a>

キューのパフォーマンスを評価するには、メトリクスを使用します。キューに関係するメトリクスは、[Amazon GameLift Servers コンソール](https://console.aws.amazon.com/gamelift) または Amazon CloudWatch で表示できます。キューメトリクスのリストと説明については、「[キューの Amazon GameLift Servers メトリクス](monitoring-cloudwatch.md#gamelift-metrics-queue)」を参照してください。

キューメトリクスは、以下に関する分析情報を提供します。
+ **キュー全体のパフォーマンス** – キューメトリックは、キューがプレイスメントリクエストにどの程度正常に応答したかを示します。これらのメトリクスは、プレイスメントが失敗するタイミングと理由を特定するのにも役立ちます。フリートを手動でスケールしたキューの場合、`AverageWaitTime` および `QueueDepth` メトリクスはキューの容量をいつ調整する必要があるか示す場合があります。
+ **FleetIQ アルゴリズムのパフォーマンス** - FleetIQ アルゴリズムを使用する配置リクエストの場合、メトリクスはアルゴリズムが理想的なゲームセッションの配置を見つける頻度を示します。プレイスメントでは、プレイヤーのレイテンシーが最も低いリソースや、コストが最も低いリソースを優先的に使用することができます。Amazon GameLift Servers が理想的なプレイスメントを発見できない一般的な理由を特定するエラーメトリクスもあります。メトリクスの詳細については、「[Amazon CloudWatch で Amazon GameLift Servers を監視する](monitoring-cloudwatch.md)」を参照してください。
+ **[ロケーション固有のプレイスメント]** – マルチロケーションキューの場合、メトリクスはロケーション別の正常なプレイスメントを示します。FleetIQ アルゴリズムを使用するキューの場合、このデータはプレイヤーのアクティビティの発生箇所に関する有益な分析情報を提供します。

FleetIQ アルゴリズムのパフォーマンスメトリクスを評価する場合は、以下のヒントを参考にしてください。
+ キューの理想的なプレイスメントを発見する比率を追跡するには、`PlacementsSucceeded` メトリクスと最小レイテンシーおよび最低料金に関する FleetIQ のメトリクスを併用します。
+ キューが理想的なプレイスメントを見つける比率を上げるには、以下のエラーメトリクスを確認してください。
  + `FirstChoiceOutOfCapacity` が高い場合は、キューのフリートに合わせて容量スケーリングを調整してください。
  + `FirstChoiceNotViable` エラーメトリクスが高い場合は、スポットインスタンスフリートを確認してください。特定のスポットインスタンスタイプの中断率が高すぎる場合、スポットフリートは「有効でない」とみなされます。この問題を解決するには、キューを変更して異なるインスタンスタイプのスポットインスタンスのフリートを使用します。ロケーションごとに異なるインスタンスタイプのスポットインスタンスフリートを含めることをお勧めします。

# ゲームセッション配置に優先順位を付ける
<a name="queues-design-priority"></a>

Amazon GameLift Servers はアルゴリズムを使用して、キューの送信先に優先順位を付ける方法と、新しいゲームセッションを配置する場所を決定します。アルゴリズムは、順序付けられた一連の基準に基づいています。デフォルトの優先順位を使用することも、順序をカスタマイズすることもできます。キューの優先順位はいつでも編集できます。

**デフォルトの優先順序**

1. **レイテンシー** – ゲームセッション配置リクエストにプレイヤーのロケーション固有のレイテンシーデータが含まれている場合、Amazon GameLift Servers は各ロケーションの平均プレイヤーレイテンシーを計算し、平均が最も低いフリートロケーションにゲームセッションを配置しようとします。

1. **コスト** – リクエストにレイテンシーデータが含まれていない場合、または複数のフリートのレイテンシーが等しい場合、Amazon GameLift Servers は各フリートのホスティングコストを評価します。フリートのホスティングコストは、フリートタイプ (スポットまたはオンデマンド)、インスタンスタイプ、ロケーションによって異なります。

1. **送信先** - 複数のフリートのレイテンシーとコストが等しい場合、Amazon GameLift Servers は、キュー設定にリストされている送信順序に基づいてフリートに優先順位を付けます。

1. **場所** – マルチロケーションフリートを持つキューの場合、他のすべての条件が等しい場合、Amazon GameLift Servers はアルファベット順に基づいてフリートの場所の優先順位を付けます。

## キューがゲームセッション配置の優先順位を付ける方法をカスタマイズする
<a name="queues-design-priority-custom"></a>

キューが配置条件の優先順位を付ける方法をカスタマイズできます。キューは、受信するすべてのゲームセッション配置リクエストにカスタム優先順位を適用します。

**注記**  
カスタム優先度設定を作成し、4 つの条件をすべて含めない場合、Amazon GameLift Servers は欠落している条件をデフォルトの順序で自動的に追加します。

**キューの優先度設定をカスタマイズする方法**

[Amazon GameLift Servers コンソール](https://console.aws.amazon.com/gamelift/)または AWS Command Line Interface (AWS CLI) を使用して、カスタム優先度設定を作成します。

------
#### [ Console ]

[Amazon GameLift Servers コンソール](https://console.aws.amazon.com/gamelift/)では、新しいキューの作成時または既存のキューの更新時に、キューの優先順位をカスタマイズできます。作業する AWS リージョンを選択します。

コンソールの左側のナビゲーションバーを開き、**[キュー]** を選択します。[キュー] ページで、既存のキューを選択し、**[編集]** を選択します。

1. **[ゲームセッション配置の優先度]** セクションに移動します。各優先条件をドラッグアンドドロップして、必要な順序を作成します。

1. **[ロケーションの順序]** セクションに移動します。優先する場所を追加します。このリストは、キューに複数のロケーションを持つフリートがある場合に便利です。少なくとも 1 つの場所を指定する必要があります。ここで指定した場所が最初に優先され、次にキューの送信先の他のすべての場所が優先されます。

1. **[Save changes]** (変更の保存) をクリックします。

------
#### [ AWS CLI ]

コマンド[https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/update-game-session-queue.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/update-game-session-queue.html)と `--priority-configuration`オプションを使用して、キューの優先順位をカスタマイズします。 は現在のデフォルト AWS リージョンのキューAmazon GameLift Serversを更新するか、`--region`タグを追加して別の AWS リージョンを指定できます。

次のリクエスト例では、指定されたキューの優先度設定を追加または更新します。

```
aws gamelift update-game-session-queue \ 
    --name "example-queue-with-priority"
    --priority-configuration PriorityOrder="COST','LOCATION","DESTINATION",LocationOrder="us-east-1","us-east-2","ca-central-1","us-west-2" \
```

------

## プレイヤーのレイテンシー別に配置を優先する
<a name="queues-design-priority-custom-latency"></a>

プレイヤーに可能な限り最高のプレイヤーエクスペリエンスを提供し、レイテンシーを最小限に抑えるには、ゲームセッション配置システムを設定するときに次の手順を実行します。
+ ゲームセッションを配置する場所を選択するときにレイテンシーを優先するようにキューを設定します。デフォルトでは、レイテンシーは優先度リストの最上位にあります。キューの優先度設定をカスタマイズし、レイテンシーを優先度順に配置する場所を選択することもできます。
+ キューのプレイヤーレイテンシーポリシーを設定します。レイテンシーポリシーを使用すると、ゲームセッション配置で許容するレイテンシーの量にハードリミットを設定できます。Amazon GameLift Servers が制限を超えることなくゲームセッションを配置できない場合、プレイスメントリクエストはタイムアウトして失敗します。単一のレイテンシーポリシーを設定することも、時間の経過とともにレイテンシー制限を徐々に緩和する一連のポリシーを作成することもできます。一連のポリシーを使用すると、初期レイテンシーの制限を非常に低く指定でき、短い遅延後にレイテンシーが高いプレイヤーに対応できます。レイテンシーポリシーの作成の詳細については、「[プレイヤーレイテンシーポリシーを作成する](queues-design-latency.md)」を参照してください。
+ ゲームセッションの配置リクエストを行うときは ([「StartGameSessionPlacement」](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_StartGameSessionPlacement.html)を参照)、各プレイヤーのレイテンシーデータを含めます。プレイヤーレイテンシーデータには、ゲームセッションを配置できるすべての場所の値が含まれます。たとえば、 AWS リージョン us-east-2 と ca-central-1 にゲームセッションを配置するキューの場合、レイテンシーデータは次のようになります。

  ```
  "PlayerLatencies": [ 
      { "LatencyInMilliseconds": 100, "PlayerId": "player1", "RegionIdentifier": "us-east-2" },
      { "LatencyInMilliseconds": 100, "PlayerId": "player1", "RegionIdentifier": "ca-central-1" },
      { "LatencyInMilliseconds": 150, "PlayerId": "player2", "RegionIdentifier": "us-east-2" },
      { "LatencyInMilliseconds": 150, "PlayerId": "player2", "RegionIdentifier": "ca-central-1" }
    ]
  ```

  正確なレイテンシー測定値を取得するには、Amazon GameLift Servers の UDP ping ビーコンを使用します。これらのエンドポイントを使用すると、プレイヤーデバイスと潜在的な各ホスティングロケーション間の実際の UDP ネットワークレイテンシーを測定できるため、ICMP ping を使用するよりも正確な配置決定を行うことができます。UDP ping ビーコンを使用してレイテンシーを測定する方法の詳細については、「[UDP ping ビーコン](reference-udp-ping-beacons.md)」を参照してください。

## 場所による配置の優先順位付け
<a name="queues-design-priority-custom-location"></a>

優先順位付けされた地理的位置のリストに基づいてゲームセッションを配置するようにキューを設定できます。場所は、キューが新しいゲームセッションを配置する場所を選択する方法を決定する基準の 1 つです。デフォルトでは、場所はレイテンシー、コスト、送信先の後、4 番目に優先されます。

ゲームセッションの配置では、送信先と場所の意味が多少異なります。
+ *送信先*とは、特定のフリートを指し、デプロイされているすべてのフリートのホスティングリソースが含まれます。送信先で優先順位を付けると、Amazon GameLift Servers はフリート内の任意の場所に配置できます。マルチロケーションマネージドフリートと Anywhere フリートは、1 つ以上の場所にデプロイされるホスティングリソースを持つことができます。
+ *ロケーション*とは、フリートのホスティングリソースがデプロイされる特定の地理的位置を指します。フリートには、Local Zones AWS リージョンやカスタムロケーション (Anywhere フリートの場合) など、複数のロケーションを含めることができます。単一ロケーションのマネージドフリートには 1 つのロケーションがあり、常に AWS リージョンです。マルチロケーションマネージドフリートは、ホームリージョンに加え、リモートロケーションを持つことができます。Anywhere フリートには 1 つ以上のカスタムロケーションがあります。

ロケーションごとにプレイスメントを優先順位付けする場合、Amazon GameLift Servers は優先ロケーションを含むキューの送信先を検索し、使用可能なホスティングリソースを検索します。優先ロケーションを持つ送信先が複数ある場合、Amazon GameLift Servers は次の優先度基準 (コスト、レイテンシー、送信先) に進みます。

キューのロケーションの優先順位付け方法に影響を与えるには、いくつかの方法があります。
+ キューがすべてのゲームセッションの配置リクエストを処理する方法を設定します。
  + **キューに優先度設定を追加します。**キューの優先度設定には、順序付けられたロケーションのリストが含まれます。優先順位を付けるロケーションを 1 つ以上指定できます。このリストはロケーションを除外するものではなく、利用可能なホスティングリソースを最初に探す場所を Amazon GameLift Servers に指定するだけです。順序付けられたロケーションリストの一般的な用途は、ほとんどのトラフィックを 1 つ以上の特定の地理的場所にファネルし、バックアップ容量として追加の場所を使用する場合です。[UpdateGameSessionQueue](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_UpdateGameSessionQueue.html) を呼び出して優先度設定を追加します。
  + **フィルター設定をキューに追加します。**フィルター設定は、キューの許可リストです。使用可能なホスティングリソースを検索するときに、リストにない場所を無視するように Amazon GameLift Servers に指示します。フィルター設定には 2 つの一般的な用途があります。まず、複数のロケーションを持つフリートの場合、フィルターを使用してフリートのロケーションの一部を除外できます。次に、特定のロケーションでの配置を一時的に禁止する場合があります。たとえば、ロケーションで一時的な問題が発生している可能性があります。キューのフィルター設定はいつでも更新できるため、必要に応じてロケーションを簡単に追加および削除できます。[UpdateGameSessionQueue](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_UpdateGameSessionQueue.html) を呼び出してフィルター設定を追加します。
+ 個々のプレイスメントリクエストには特別な手順を使用します。
  + **ゲームセッションの配置リクエストに優先度のオーバーライドリストを含めます。**[StartGameSessionPlacement](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_StartGameSessionPlacement.html) リクエストを使用して、ロケーションの代替優先度リストを指定できます。このリストは、その 1 つのリクエストのみのロケーションに対してキューが設定した優先順位を効果的に置き換えます。他のリクエストには影響しません。このオーバーライド機能にはいくつかの要件があります。
    + オーバーライドリストは、優先度設定が `LOCATION` であるキューを最優先としてのみ使用します。
    + 同じプレイスメントリクエストにプレイヤーレイテンシーデータを含めないでください。Amazon GameLift Servers が解決できないロケーションを優先する場合、レイテンシーデータを含めると競合が発生します。
    + 優先度のオーバーライドリストで使用可能なリソースが見つからない場合の Amazon GameLift Servers の処理方法を決定します。キューの他のロケーションにフォールバックするか、オーバーライドリストへの配置を制限するかを選択します。デフォルトでは、Amazon GameLift Servers はキューの他のロケーションへの配置を試みるためにフォールバックします。
    + オーバーライドリストにロケーションを追加するなど、必要に応じてキューのフィルター設定を更新します。オーバーライドリストはフィルターリストを無効にしません。

# プレイヤーレイテンシーポリシーを作成する
<a name="queues-design-latency"></a>

プレイスメントリクエストにプレイヤーレイテンシーデータが含まれている場合、Amazon GameLift Servers は、すべてのプレイヤーに対して、平均レイテンシーが最小のロケーションのゲームセッションを検出します。平均プレイヤーレイテンシーに基づいてゲームセッションを配置することで、Amazon GameLift Servers は多くのプレイヤーを高いレイテンシーのゲームに配置することを防ぎます。ただし、Amazon GameLift Servers はそれでもプレイヤーを非常に高いレイテンシーで配置します。このようなプレイヤーに対応するため、プレイヤーレイテンシーポリシーを作成します。

プレイヤーレイテンシーポリシーは、Amazon GameLift Servers がリクエストされたゲームセッションを、リクエスト内のプレイヤーが最大値を超えるレイテンシーを経験するロケーションに配置するのを防止します。また、プレイヤーレイテンシーポリシーは、Amazon GameLift Servers がゲームセッションリクエストをレイテンシーの高いプレイヤーとマッチングしないようにすることもできます。

**ヒント**  
グループ内のすべてのプレイヤーで同様のレイテンシーを必要とするなど、プレイヤーのレイテンシーのルールを具体的に管理したい場合は、[Amazon GameLift Servers FlexMatch](https://docs.aws.amazon.com/gameliftservers/latest/flexmatchguide/match-intro.html) を使用して、レイテンシーベースのマッチメーキングルールを作成します。

たとえば、タイムアウトが 5 分間で、次のプレイヤーレイテンシーポリシーのあるキューについて検討してみましょう。

1. 120 秒かけて、すべてのプレイヤーのレイテンシーが 50 ミリ秒未満のロケーションを検索します。

1. 120 秒かけて、すべてのプレイヤーのレイテンシーが 100 ミリ秒未満のロケーションを検索します。

1. 次に、キューのタイムアウトまでの残り時間を使って、すべてのプレイヤーレイテンシーが 200 ミリ秒未満のロケーションを検索します。

![\[徐々に緩和されるレイテンシーポリシーの例を示すコンソールのスクリーンショット。\]](http://docs.aws.amazon.com/ja_jp/gameliftservers/latest/developerguide/images/queue-latency-policy.png)


# スポットインスタンスのキューの設計
<a name="spot-tasks"></a>

スポットフリートを使用すると、ホスティングコストを大幅に削減できます。スポットフリートとその使用方法の詳細については、「[オンデマンドインスタンスとスポットインスタンスの比較](gamelift-compute.md#gamelift-compute-spot)」を参照してください。

ゲームホスティングソリューションにスポットフリートが含まれている場合は、ゲームセッションプレイスメントキューを使用する必要があります。Amazon GameLift Servers はキューを使用して複数のゲームホスティングリソースを検索し、新しいゲームセッションをホストするために利用可能な最適なリソースを選択します。スポットフリートでは、キューはホスティングコストを最小限に抑え、スポットの中断を回避するために特に重要です。このトピックは、中断、スローダウン、停止が発生した場合でもプレイヤーのゲームをホストし続けることができる回復力のあるキューを設定するのに役立ちます。キューが利用可能なホスティングリソースに優先順位を付ける方法は、ホスティングコストなどのいくつかの要因に基づいてカスタマイズできます。

マッチメーキングに FlexMatch を使用していますか? マッチメイキングを配置する既存のゲームセッションキューにスポットフリートを追加できます。

## スポットフリートの実装タスク
<a name="spot-tasks-queue"></a>

スポットフリートを使用するようにゲームホスティングソリューションを作成または更新する場合は、次のタスクを完了します。スポットの可用性と回復性を最適化するキューを構築する方法の詳細については、「[スポットフリートによるゲームホスティングコストの削減](fleets-spot.md)」を参照してください。

1. **ゲームセッションキューのフリート送信先のセットを選択して作成します。**

   まず、キューでゲームセッションを配置する場所を決定します。キューは複数のフリートを検索して、最適な配置を見つけることができます。各フリートは、複数の地理的な場所にデプロイされたインスタンスを持つことができます。ロケーションタイプとインスタンスタイプの両方で異なるフリートを持つキューは、プレイスメントを成功させる可能性が高くなります。効果的で回復力のあるスポット最適化キューを設計するためのベストプラクティスを参照してください。

1. **スポット最適化ゲームセッションキューを作成します。**

   キューを作成し、スポットフリート用に設定します。新しいキューの作成および設定のヘルプについては、「[ゲームセッションキューを作成する](queues-creating.md)」を参照してください。Amazon GameLift Servers コンソールまたは AWS CLI を使用して、キューを作成または編集できます。
   + ステップ 1 からフリートの送信先を追加します。
   + 必要に応じて送信先の順序に優先順位を付けます。デフォルトでは、Amazon GameLift Servers は送信先のコストで優先順位を付けるため、送信先間のコストが最も低い場合にのみ送信先の順序が使用されます。
   + プレイヤーのレイテンシーの前にゲームホスティングコストを優先する場合は、カスタムプレイスメントの優先順位を指定します。「[ゲームセッション配置に優先順位を付ける](queues-design-priority.md)」を参照してください。

1. **ソリューション内の他のコンポーネントを更新して、新しいキューを使用します。**

   ソリューションがスポット最適化キューを使用して新しいゲームセッションを開始すると、キューは中断の可能性の高いフリートでゲームセッションを配置することを自動的に回避します。代わりに、プレイヤーのレイテンシー、ホスティングコスト、送信先の順序など、定義された優先順位に一致するリソースについて、実行可能なすべてのフリートを検索します。
   + FlexMatch を使用していない場合 – バックエンドサービスを更新して、ゲームセッションリクエストで新しいスポット最適化キューを指定します。バックエンドサービスは、ゲームクライアントに代わって (`StartGameSessionPlacement()` を使用して) Amazon GameLift Servers に API リクエストを行い、各リクエストはキュー名を指定する必要があります。ゲームクライアントにゲームセッション配置を実装する方法については、「[ゲームセッションを作成する](gamelift-sdk-client-api.md#gamelift-sdk-client-api-create)」を参照してください。
   + FlexMatch を使用している場合 – マッチメーキング設定を更新して、新しいスポット最適化キューにゲームセッションリクエストを送信します。マッチメーキングシステムがプレイヤーマッチを形成すると、指定されたキューにゲームセッション配置リクエストを送信して、マッチの新しいゲームセッションを開始します。FlexMatch モードが「マネージド」に設定されているマッチメーキング設定のみがプレイスメントキューを指定できます。CLI または AWS コンソールを使用してマッチメーキング設定を更新できます Amazon GameLift Servers ([「マッチメーキング設定の編集](https://docs.aws.amazon.com/gameliftservers/latest/flexmatchguide/match-create-configuration-edit.html)」を参照）。

1. **スポットフリートとキューのパフォーマンスを評価します。**

   Amazon GameLift Servers コンソールの Amazon GameLift Servers メトリクス、または Amazon CloudWatch を表示してパフォーマンスを確認できます。Amazon GameLift Servers メトリクスの詳細については、「[Amazon CloudWatch で Amazon GameLift Servers を監視する](monitoring-cloudwatch.md)」を参照してください。主なメトリクスには次のものがあります。
   + 中断率 – スポットフリートのインスタンスとゲームセッションについてスポットに関連した中断の回数と頻度を追跡する `InstanceInterruptions` および `GameSessionInterruptions` メトリクスを使用します。再要求されたインスタンスのゲームセッションのステータスは `TERMINATED`、ステータス理由は `INTERRUPTED` です。
   + キューの有効性 – プレイスメントの成功率、平均待機時間、キューの深度などのキューメトリクスを追跡し、スポットフリートによってキューのパフォーマンスに影響が出ないことを確認します。
   + フリート使用率 – インスタンス、ゲームセッションおよびプレイヤーセッションをモニタリングします。オンデマンドフリートの使用率は、中断を避けるためにキューがスポットフリートへのプレイスメントを避けている指標になります。

## スポットフリートを使用したキューのベストプラクティス
<a name="queues-design-spot"></a>

 スポットインスタンスのフリートとキューを作成するときは、次のベストプラクティスを使用します。
+ **キューの地理的カバレッジを拡張します。**プレイヤーが 1 つの にクラスター化されていても AWS リージョン、スポットフリートに隣接する場所を追加します。このアプローチにより、リージョンの速度低下、停止、スポットの中断時にキャパシティを維持するキューの機能が向上します。マルチロケーションフリートは、スポットインスタンスとオンデマンドインスタンスの両方で動作します。
+ **キューのインスタンスタイプのカバレッジを多様化します。** はインスタンスタイプに基づいてスポットの実行可能性Amazon GameLift Serversを評価するため、さまざまなインスタンスタイプのスポットフリートがあると、複数のスポットフリートが同時に実行できなくなる可能性が低くなります。各ロケーションに異なるインスタンスタイプを持つ少なくとも 2 つのスポットフリートを含めます。
**注記**  
料金は、フリートの数ではなく、使用するインスタンスに基づいています。それぞれ 10 個のインスタンスで 5 つのフリートを実行することは、同様のコストで 50 個のインスタンスで 1 つのフリートを実行することと同じです。料金はインスタンスタイプ、サイズ、場所によって異なります。

  スポットインスタンスタイプをグループ化するためのヒント: 
  + `m6g.medium`、`m6g.large`、`m6g.xlarge` など、同じファミリーでインスタンスタイプを使用します。インスタンスタイプが大きいほどコストは高くなりますが、一度により多くのゲームセッションをホストすることもできます。
  + 広く利用可能なインスタンスタイプを選択します。通常、旧世代のファミリー (C5, M5、R5 など) と一般的なサイズ (.large、.xlarge、.2xlarge など) は可用性が高くなります。
  + Amazon GameLift Servers コンソールで 30～90 日間の料金履歴を確認します。一貫した可用性パターンを持つインスタンスタイプを探します。
  + Amazon GameLift Servers コンソール、フリート作成ツールを使用して、インスタンスタイプのロケーションカバレッジを調べます。
+ **バックアップ容量のオンデマンドフリートを追加します。**ゲームホスティングは、スポットフリートが利用できないときはいつでもオンデマンドフリートに切り替えることができます。各ロケーションに少なくとも 1 つのオンデマンドフリートを配置して、プレイヤーのレイテンシーを低く保ちます。バックアップオンデマンドフリートに自動スケーリングを追加すると、必要なまでスケールダウンしたままにできます。
+ **すべてのフリート送信先にエイリアスを割り当てます。**キューの送信先ごとにエイリアスを作成します。エイリアスを使用すると、フリートを置き換える必要がある場合に簡単かつ効率的になります。
+ **キューの優先順位付け戦略を適用します。**キューがゲームセッションの配置先を優先する方法をカスタマイズできます (詳細については、「[ゲームセッション配置に優先順位を付ける](queues-design-priority.md)」を参照)。スポット最適化キューの場合、コストで優先順位を付けると、可能な限り低コストのスポットフリートが使用されます。

  送信先順序を指定して、特定のフリートに優先順位を付けることもできます。たとえば、一部のユーザーは、定期的に使用するプライマリフリートのセットと、バックアップとしてセカンダリフリートのセットを指定します。このシナリオでは、キューの送信先順序を設定して、プライマリフリートを最初に一覧表示します。次に、キューの優先順位を宛先とそれに続くコストで設定します。