リソース制限の設定コンテナフリートのメモリ割り当てを理解する NVMe ドライブアクセスの設定必須コンテナの指定ネットワーク接続を構成するコンテナのヘルスチェックを設定するコンテナの依存関係の設定コンテナフリートを設定する

Amazon GameLift Servers コンテナフリートをカスタマイズする

このセクションのトピックでは、Amazon GameLift Servers マネージドコンテナのオプション機能の一部を説明します。これらの機能は、必要に応じて、いずれか単独でも、複数組み合わせても使用できます。

トピック

リソース制限の設定
コンテナフリートのメモリ割り当てを理解する
NVMe ドライブアクセスの設定
必須コンテナの指定
ネットワーク接続を構成する
コンテナのヘルスチェックを設定する
コンテナの依存関係の設定
コンテナフリートを設定する

リソース制限の設定

各コンテナグループについて、そのコンテナグループがソフトウェアを実行するために必要なメモリおよびコンピューティング能力を設定できます。Amazon GameLift Servers はこの情報を使用してグループ全体のリソースを管理します。さらに、この情報を使って、フリートイメージが保持できるゲームサーバーコンテナグループの数を算出します。個々のコンテナに対して制限を設定することもできます。

コンテナグループのメモリおよびコンピューティング能力の上限を設定できます。デフォルトでは、これらのリソースはグループ内のすべてのコンテナで共有されます。個々のコンテナに制限を設定することで、リソース管理をさらに細かく調整できます。

個々のコンテナにオプションの制限を設定

コンテナごとにリソース制限を設定すると、個々のコンテナがグループのリソースをどのように使用するかをより細かく管理できます。コンテナ固有の制限を設定しない場合、グループ内のコンテナはすべてグループのリソースを共有します。共有することで、必要なリソースを柔軟に使用しやすくなります。一方で、プロセス同士がリソースを奪い合い、結果的にコンテナが障害を起こす可能性も高まります。

任意のコンテナに対して、以下のいずれかの ContainerDefinition プロパティを設定できます。

MemoryHardLimitMebibytes – コンテナの最大メモリ制限を設定します。コンテナがこの制限を超えると、再起動されます。
Vcpu 制限 – コンテナが専有して使用するための最小 vCPU リソースを予約します。コンテナには、この予約済みリソースが常に利用可能です。追加のリソースが利用可能な場合、この最小値を上回ることも可能です。(1024 CPU ユニットは 1 vCPU に相当します)。

コンテナグループの総合リソース制限を設定します。

個々のコンテナに制限を設定する場合、コンテナグループに必要なメモリや vCPU リソース量を調整する必要が生じる場合があります。目的は、ゲームサーバーのパフォーマンスを最適化するために十分なリソースを割り当てることです。Amazon GameLift Servers は、この制限情報を使用して、1 つのフリートインスタンスにどれだけのゲームコンテナサーバーグループを配置できるかを計算します。また、この情報はコンテナフリートのインスタンスタイプを選択する際にも使用します。

コンテナグループに必要な合計メモリと vCPU を計算します。以下の点を考慮してください。

コンテナグループ内のすべてのコンテナで実行されるすべてのプロセスは何ですか。これらのプロセスに必要なリソースを加算します。コンテナ固有の制限に注意してください。
各コンテナグループで実行する予定の同時ゲームサーバープロセス数はいくつですか。これはゲームサーバーコンテナイメージで決定します。

コンテナグループ要件の見積もりに基づいて、次の ContainerGroupDefinition プロパティを設定します。

TotalMemoryLimitMebibytes – コンテナグループの最大メモリ制限を設定します。グループ内のすべてのコンテナは、割り当てられたメモリを共有します。個々のコンテナ制限を設定する場合、合計メモリはそのコンテナ固有の最大メモリ制限以上である必要があります。
TotalVcpuLimit – コンテナグループの最大 vCPU 制限を設定します。グループ内のすべてのコンテナは、割り当てられた CPU リソースを共有します。個々のコンテナ制限を設定する場合、合計 CPU 制限は、すべてのコンテナ固有の CPU 制限の合計以上である必要があります。ベストプラクティスとして、この値をコンテナ CPU 制限の合計の 2 倍に設定することを検討してください。

シナリオの例

次の 3 つのコンテナを使用して、ゲームサーバーコンテナグループを定義するとします。

コンテナ A はゲームサーバーコンテナです。1 つのゲームサーバーのリソース要件は、512 MiB と 1024 CPU で見積もられます。コンテナで 1 つのサーバープロセスを実行する予定です。このコンテナは最も重要なソフトウェアを実行するため、桃利制限と vCPU リザーブ制限は設定しません。
コンテナ B は、リソース要件が 1024 MiB および 1536 CPU と推定されるサポートコンテナです。メモリ上限は2048 MiB、CPUリザーブの上限は1024 CPUユニットに設定されています。
コンテナ C は別のサポートコンテナです。メモリのハードリミットは512 MiB、CPUリザーブの上限は512 CPUユニットに設定されています。

この情報を使用して、コンテナグループに対して次の合計制限を設定します。

合計メモリ制限: 7680 MiB。この値は、メモリの上限 (1024 MiB) を超えています。
合計 CPU 制限: 13312 CPU。この値は CPU 制限 (1024+512 CPU) の合計を超えています。

コンテナフリートのメモリ割り当てを理解する

がフリートインスタンスにコンテナグループをAmazon GameLift Serversデプロイする場合、インスタンスのすべてのメモリがコンテナで使用できるわけではありません。は、オペレーティングシステム、Amazon ECS エージェント、およびその他のサポートサービスのインスタンスメモリの一部Amazon GameLift Serversを予約します。予約メモリの量は、インスタンスタイプの合計メモリによって異なります。このオーバーヘッドを理解することで、使用可能なリソースを最大限に活用するようにコンテナグループ定義を設定できます。

メモリオーバーヘッド数式

Amazon GameLift Servers は、次の手順を使用してコンテナグループで使用できるメモリを計算します。

メモリバッファの割合を決定します。 は、次の階層に基づいてインスタンスの合計メモリの割合Amazon GameLift Serversを予約します。

インスタンスメモリ (MiB)	予約割合
5,000 未満	8%
5,000～9,999	6%
10,000～89,999	5%
90,000～199,999	4%
200,000 以上	3%

使用可能なメモリを計算します。インスタンスメモリの合計からリザーブドメモリを減算します。

AvailableMemory = InstanceMemory - round(InstanceMemory × BufferPercentage)
インスタンスごとのコンテナグループメモリを減算します。フリートがインスタンスごとのコンテナグループを使用している場合は、使用可能なメモリTotalMemoryLimitMebibytesからそのコンテナグループを減算します。インスタンスごとに 1 つのコンテナグループがフリートインスタンスごとに実行されます。

AvailableMemory = AvailableMemory - PerInstanceCGD.TotalMemoryLimitMebibytes
ログルーターのオーバーヘッドを考慮します。フリートのログ記録が有効になっている場合、はログルーターのゲームサーバーコンテナグループごとにさらに 50 MiB Amazon GameLift Serversを予約します。
ゲームサーバーコンテナグループの最大数を計算します。メモリによってインスタンスに収まるゲームサーバーコンテナグループの最大数は、次のとおりです。

MaxGroupsByMemory = floor(AvailableMemory / (GameServerCGD.TotalMemoryLimitMebibytes + LogRouterMemory))

ここで、 LogRouterMemoryはログ記録が有効になっている場合は 50 MiB、ログ記録が無効になっている場合は 0 です。

注記

メモリは、インスタンスに収まるゲームサーバーコンテナグループの数を決定する 1 つの要素にすぎません。は vCPU 容量と使用可能な接続ポートAmazon GameLift Serversも考慮し、3 つの計算の最小値を使用します。

メモリ計算の例

ログ記録が有効になっているc5.xlargeインスタンス (合計メモリ 8,192 MiB) を使用するフリートを考えてみましょう。

インスタンスメモリは 8,192 MiB で、5,000～9,999 層 (6% バッファ) に相当します。
予約メモリ = round(8,192 × 0.06) = 492 MiB
使用可能なメモリ = 8,192～492 = 7,700 MiB
512 TotalMemoryLimitMebibytesのインスタンスごとのコンテナグループを使用する場合: 使用可能なメモリ = 7,700～512 = 7,188 MiB
各ゲームサーバーコンテナグループの TotalMemoryLimitMebibytesが 1,024 の場合: MaxGroupsByMemory = floor(7,188 / (1,024 + 50)) = floor(7,188 / 1,074) = 6

インスタンスタイプ別の使用可能なメモリ

次の表は、一般的に使用されるインスタンスタイプの合計メモリと使用可能なメモリ (Amazon GameLift Serversバッファの後) を示しています。コンテナグループ定義を設定するときは、これらの値を出発点として使用します。使用可能なメモリ列には、インスタンス上のすべてのコンテナグループで使用できるメモリが表示されてから、インスタンスごとのコンテナグループまたはログルーターのオーバーヘッドが減算されます。

インスタンスタイプ	合計メモリ (MiB)	バッファの割合	使用可能なメモリ (MiB)
`c5.large`	4,096	8%	3,768
`c5.xlarge`	8,192	6%	7,700
`c5.2xlarge`	16,384	5%	15,565
`c5.4xlarge`	32,768	5%	31,130
`c5.9xlarge`	73,728	5%	70,042
`c5.12xlarge`	98,304	4%	94,372
`c5.18xlarge`	147,456	4%	141,558
`c5.24xlarge`	196,608	4%	188,744
`m5.large`	8,192	6%	7,700
`m5.xlarge`	16,384	5%	15,565
`m5.2xlarge`	32,768	5%	31,130
`m5.4xlarge`	65,536	5%	62,259
`m5.8xlarge`	131,072	4%	125,829
`m5.12xlarge`	196,608	4%	188,744
`r5.large`	16,384	5%	15,565
`r5.xlarge`	32,768	5%	31,130
`r5.2xlarge`	65,536	5%	62,259
`r5.4xlarge`	131,072	4%	125,829
`c6i.large`	4,096	8%	3,768
`c6i.xlarge`	8,192	6%	7,700
`c6i.2xlarge`	16,384	5%	15,565
`c6i.4xlarge`	32,768	5%	31,130
`c6i.8xlarge`	65,536	5%	62,259
`c7i.large`	4,096	8%	3,768
`c7i.xlarge`	8,192	6%	7,700
`c7i.2xlarge`	16,384	5%	15,565
`c7i.4xlarge`	32,768	5%	31,130
`c7i.8xlarge`	65,536	5%	62,259
`m7i.large`	8,192	6%	7,700
`m7i.xlarge`	16,384	5%	15,565
`m7i.2xlarge`	32,768	5%	31,130
`m7i.4xlarge`	65,536	5%	62,259
`m7i.8xlarge`	131,072	4%	125,829
`m7i.12xlarge`	196,608	4%	188,744
`r7i.large`	16,384	5%	15,565
`r7i.xlarge`	32,768	5%	31,130
`r7i.2xlarge`	65,536	5%	62,259
`r7i.4xlarge`	131,072	4%	125,829

ここにリストされていないインスタンスタイプの場合、上記の式を使用して使用可能なメモリを計算できます。選択したインスタンスタイプの合計メモリについては、Amazon EC2 インスタンスタイプのドキュメントを参照してください。

NVMe ドライブアクセスの設定

d タイプのインスタンスでは、ホストの起動時に NVMe ドライブが /data ディレクトリに自動的にマウントされます。コンテナが SSD ストレージにアクセスできるようにするには、次のContainerGroupDefinitionプロパティを設定しますMountPoints。

InstancePath – ホストインスタンスの自動マウント NVMe ドライブを参照/dataするには、に設定します。
AccessLevel – コンテナのニーズに適したアクセスレベルを選択します (例: READ_ONLY または READ_WRITE)。
ContainerPath – (オプション) インスタンスパスをコンテナ内にマウントするパスを指定します。指定しない場合、デフォルトでインスタンスパスになります。

マウントポイントの詳細については、「Amazon GameLift Servers API リファレンス」のContainerMountPoint」を参照してください。

必須コンテナの指定

各インスタンスのコンテナグループごとに、各コンテナをEssential (必須) または Non-essential (非必須) として指定します。インスタンス単位のコンテナグループには、少なくとも 1 つの必須コンテナが必要です。必須コンテナは、コンテナグループの重要な処理を担当します。必須コンテナは、常に稼働していることが期待されます。失敗すると、コンテナグループ全体が再起動します。

ContainerDefinitionプロパティEssentialを各コンテナの true または false に設定します。

ネットワーク接続を構成する

外部トラフィックがコンテナフリート内の任意のコンテナに接続できるように、ネットワークアクセスをカスタマイズできます。例えば、ゲームクライアントがゲームに参加できるようにするには、ゲームサーバープロセスを実行するコンテナに対してネットワーク接続を構成する必要があります。ゲームクライアントは、ポートと IP アドレスを使用してgameサーバーに接続します。

コンテナフリートでは、クライアントとサーバー間の接続は直接には行われません。内部的には、コンテナ内のプロセスはコンテナポートで待ち受けます。外部からのトラフィックは、接続ポートを使用してフリート内のインスタンスに接続されます。Amazon GameLift Servers は、内部コンテナポートと外部公開ポートのマッピングを管理し、トラフィックがインスタンス上の正しいプロセスにルーティングされるようにします。

Amazon GameLift Servers は、ネットワーク接続に対する追加の制御レイヤーを提供します。各コンテナフリートには受信許可設定があり、外部公開ポートごとのアクセス制御が可能です。例えば、すべての接続ポートの許可を無効にして、フリート内のコンテナへのアクセスを完全に遮断することも可能です。

フリートの受信許可、接続ポート、およびコンテナポートを更新できます。

警告

カスタムの InstanceConnectionPortRange または InstanceInboundPermissions を指定した場合、Amazon GameLift Servers はフリートでこれらの値を管理しなくなります。意図しない動作を避けるために、両方のフィールドを設定する必要があります。

コンテナポート範囲の設定

各コンテナ定義の一部として、コンテナポート範囲を設定します。これは、コンテナグループ定義に必要なパラメータです。外部アクセスが必要なすべての同時実行プロセスに対応できるよう、十分な数のポートを設定する必要があります。一部のコンテナにはポートが不要な場合もあります。

ゲームサーバーコンテナには、同時に実行される各ゲームサーバープロセスに対して、それぞれポートが必要です。ゲームサーバープロセスは、割り当てられたポートをリッスンし、その情報を Amazon GameLift Servers に報告します。

接続ポート範囲の設定

接続ポートのセットを使用してコンテナフリートを構成します。接続ポートは、コンテナを実行しているフリートインスタンスへの外部アクセスを提供します。Amazon GameLift Servers は接続ポートを割り当て、必要に応じてコンテナポートにマッピングします。

デフォルトでは、Amazon GameLift Servers がすべてのコンテナグループに必要なポート数を計算し、それに応じたポート範囲を設定します。コンテナグループ定義に更新をデプロイすると更新される、Amazon GameLift Servers によって計算された値を使用することを強く推奨します。接続ポート範囲をカスタマイズする必要がある場合は、次のガイダンスを使用します。

コンテナフリートを作成する際は、接続ポート範囲を定義します (ContainerFleet:InstanceConnectionPortRange を参照)。フリート内のすべてのコンテナグループに含まれるコンテナポートにマッピングできるよう、ポート範囲に十分な数のポートが含まれていることを確認します。必要な最小接続ポートを計算するには、次の式を使用します。

[Total number of container ports defined for containers in the game server container group] * [Number of game server container groups per instance] + [Total number of container ports defined for containers in the per-instance container group]

ベストプラクティスとして、接続ポートの最小数を 2 倍にします。

注記

接続ポート数は、インスタンスあたりのゲームサーバーコンテナグループの数を制限する可能性があります。フリートに、インスタンスごとに1つのゲームサーバーコンテナグループしか対応できないだけの接続ポートしかない場合、たとえインスタンスに複数のゲームサーバーコンテナグループを実行できる十分な計算リソースがあっても、Amazon GameLift Servers は 1 つのゲームサーバーコンテナグループしかデプロイしません。

受信許可を設定する

受信許可は、受信トラフィックに対して開放する接続ポートを指定することで、コンテナフリートへの外部アクセスを制御します。この設定を使用して、必要に応じてフリートのネットワークアクセスをオンまたはオフにできます。

コンテナフリートを作成するときは、一連のインバウンド権限を定義します（ContainerFleet::InstanceInboundPermissions を参照）。受信許可ポートは、フリートの接続ポート範囲と一致している必要があります。

注記

コンテナポートは InstanceConnectionPortRange からランダムに選ばれるため、セッション接続を確実に行うには、InstanceConnectionPortRange に含まれるすべてのポートがInstanceInboundPermissions によって許可されている必要があります。

シナリオの例

この例では、3 つのネットワーク接続プロパティをどのように設定するかを示します。

フリートのゲームサーバーコンテナグループには、1つのコンテナがあり、1 つのゲームサーバープロセスを実行しています。

ゲームサーバーコンテナグループ定義では、このコンテナの PortConfiguration パラメータを次のように設定します。
```
"PortConfiguration": {
  "ContainerPortRanges": [ { "FromPort": 10, "ToPort": 20, "Protocol": "TCP"} ]  } 
```
フリートには、1 つのコンテナを持つインスタンス単位のコンテナグループもあります。このグループには、ネットワークアクセスを必要とするプロセスが1つ含まれています。インスタンス単位のコンテナ定義では、このコンテナの PortConfiguration パラメータを次のように設定します。
```
"PortConfiguration": {
  "ContainerPortRanges": [ { "FromPort": 25, "ToPort": 25, "Protocol": "TCP"} ]  }
```

フリートでは、1 インスタンスあたり20個のゲームサーバーコンテナグループが構成されています。この情報に基づいて、必要な接続ポート数を次の計算式で求めることができます。
- 最小: 21 ポート 〔1 ゲームサーバーコンテナ port × インスタンスあたり 20 ゲームサーバーコンテナ groups ＋ 1 per-instance コンテナポート〕
- ベストプラクティス: 42 ポート [最小ポート数 x 2]
コンテナフリートを作成するときは、InstanceConnectionPortRange パラメータを次のように設定します。
```
"InstanceConnectionPortRange": { "FromPort": 1010, "ToPort": 1071 }
```
使用可能なすべての接続ポートへのアクセスを許可したいと考えています。コンテナフリートを作成するときは、InstanceInboundPermissions パラメータを次のように設定します。
```
"InstanceInboundPermissions": [ 
  {"FromPort": 1010, "ToPort": 1071, "IpRange": "10.24.34.0/23", "Protocol": "TCP"} ]
```

コンテナのヘルスチェックを設定する

コンテナは、ターミナル障害が発生して実行が停止すると、自動的に再起動します。コンテナが必須 (Essential) と見なされている場合、そのコンテナが停止するとコンテナグループ全体が再起動されます。

すべてのゲームサーバーコンテナは、自動的に必須コンテナとして扱われます。サポートコンテナも必須に設定できますが、その場合は正常性を報告する仕組みが必要です。必須でないサポートコンテナにも、ヘルスチェックを設定できます。

コンテナの正常性を評価するための、独自のカスタム基準を定義し、その基準を検証するためにヘルスチェックを使用できます。コンテナのヘルスチェックは、Docker コンテナイメージまたはコンテナ定義内に記述できます。コンテナ定義にヘルスチェックを設定すると、コンテナイメージ内の設定は上書きされます。

コンテナヘルスチェックには、次の SupportContainerDefinition プロパティを設定します。

Command — コンテナの状態の一部を確認するコマンドを指定します。正常性の基準は、任意に定義できます。コマンドの終了コードは、次のいずれかである必要があります: 1 (異常) または 0 (正常)。
StartPeriod — ヘルスチェックの失敗カウントを開始するまでの遅延時間を指定します。この遅延により、コンテナはプロセスをブートストラップするための時間を確保できます。
Interval — ヘルスチェックコマンドを実行する頻度を指定します。コンテナ障害をどのくらい早く検出して解決しますか?
Timeout — ヘルスチェックコマンドを再試行するまでの成功・失敗の待機時間を設定します。ヘルスチェックコマンドの完了に必要な時間はどれくらいですか？
Retries — 失敗を登録する前にヘルスチェックコマンドを何回再試行する必要がありますか?

コンテナの依存関係の設定

各コンテナグループ内では、コンテナのステータスに基づいて、コンテナ間の依存関係を設定できます。依存関係を設定することで、他のコンテナの状態に応じて、依存先コンテナの起動やシャットダウンのタイミングを制御できます。

依存関係の主なユースケースの 1 つは、コンテナグループのスタートアップおよびシャットダウンの順序を構成することです。

たとえば、コンテナ A を最初に起動し、B や C が起動する前に正常終了させたい場合があります。これを実現するには、まずコンテナBに対してコンテナAへの依存関係を設定します。条件として、コンテナAが正常に完了することを指定します。続けて、同じ条件でコンテナ C にもコンテナ A への依存関係を設定します。スタートアップシーケンスは、シャットダウン時に逆順で実行されます。

コンテナフリートを設定する

コンテナフリートを作成する際は、以下の設計上の判断項目を考慮してください。これらの判断項目の多くは、コンテナのアーキテクチャと設定内容に依存します。

フリートをどこにデプロイするかを決定します。

一般的には、レイテンシーを最小限に抑えるため、プレイヤーに近い地域にデプロイするのが理想です。コンテナフリートは、がAmazon GameLift Serversサポート AWS リージョンする任意のにデプロイできます。同じゲームサーバーを追加の地理的場所にデプロイする場合は、 AWS リージョンおよび Local Zones を含むリモートロケーションをフリートに追加できます。マルチロケーションフリートを持つフリートでは、各ロケーションで個別に容量を調整できます。サポートされているフリートのロケーションの詳細については、「Amazon GameLift Servers サービスロケーション」を参照してください。

ネットワークのレイテンシーデータを収集するには、UDP ping ビーコンを使用して、各地域のレイテンシーを測定し、プレイヤーデバイスとフリート候補ロケーション間の遅延を予測することを検討してください。これらの特別なエンドポイントは、従来の ICMP ping の代わりに UDP メッセージを受け入れるため、正確なレイテンシー測定が可能になり、最適なフリートロケーションの選択に役立ちます。

フリートで使用するインスタンスタイプとサイズを選択する

Amazon GameLift Servers は、幅広い Amazon EC2 インスタンスタイプをサポートしており、これらはすべてコンテナフリートで利用できます。利用可能なインスタンスタイプと料金は、ロケーションによって異なります。サポートされているインスタンスタイプのリストは、Amazon GameLift Servers コンソールの「リソース、インスタンス、およびサービスのクォータ」内で、ロケーション別にフィルタリングして確認できます。

インスタンスタイプを選択するときは、まずインスタンスファミリーを検討してください。インスタンスファミリでは、CPU、メモリ、ストレージ、ネットワーキング機能をさまざまな組み合わせで提供しています。EC2 インスタンスファミリの詳細情報を取得します。各ファミリー内では、さまざまなインスタンスサイズを選択できます。インスタンスサイズを選択するときは、次の点を考慮してください。

ワークロードをサポートできる最小インスタンスサイズを教えてください。この情報を活用して、小さすぎるインスタンスタイプを除外しましょう。
コンテナアーキテクチャに適したインスタンスタイプサイズは何ですか？理想的には、ゲームサーバーコンテナグループの複数のコピーを無駄なスペースを最小限に抑えて収容できるサイズを選択します。
ゲームに適したスケーリングの粒度 (細かさ) はどれくらいですか？フリートの容量スケーリングにはインスタンスの追加や削除が伴い、各インスタンスは特定の数のゲームセッションをホストする能力を持ちます。インスタンスごとに、どれだけの容量を追加・削除したいかを検討しましょう。プレイヤーの需要が分単位で数千規模に変動する場合は、数百から数千のゲームセッションをホストできる大規模インスタンスの利用が有効です。一方で、小さなインスタンスタイプを用いることで、より細かくスケーリング制御ができる場合もあります。
インスタンスサイズによって、コスト削減の可能性はありますか？一部のインスタンスタイプでは、利用可能性によりロケーションごとにコストが異なることがあります。

その他のフリート設定を構成する

コンテナフリートを設定するときは、次のオプション機能を使用できます。

他の AWS リソースにアクセスするようにゲームサーバーを設定します。「Amazon GameLift Servers ホストされたゲームサーバーを他の AWS リソースに接続する」を参照してください。
スケールダウン時に、アクティブなプレイヤーが参加しているゲームセッションが途中終了しないように保護します。
一定期間内に 1 人のユーザーがフリート上で作成できるゲームセッション数を制限します。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

コンピューティングリソースを選択する

スポットフリートによるホスティングコストの削減