# キャパシティプランニング
<a name="capacity-planning"></a>

 AWS リージョンにおける Amazon EC2 の容量は無限のように見えますが、Outposts の容量には限りがあり、注文したコンピューティング容量の合計によって制約されます。Outposts デプロイのコンピューティングキャパシティの計画と管理はお客様の責任となります。N\$1M 可用性モデルをサポートするのに十分なコンピューティングキャパシティを注文する必要があります。N は必要なサーバー数、M はサーバー障害に対応するためにプロビジョニングされたスペアサーバーの数です。N\$11 と N\$12 が最も一般的な可用性レベルです。

 各ホスト (`C5`、`M5`、`R5` など) は、単一ファミリーの EC2 インスタンスをサポートします。EC2 コンピューティングサーバーでインスタンスを起動する前に、各サーバーが提供する [EC2 インスタンスサイズ](https://aws.amazon.com/ec2/instance-types/)を指定するスロッティングレイアウトを準備する必要があります。AWS は、要求されたスロッティングレイアウトで各サーバーを構成します。

 ホストは、すべてのスロットが同じインスタンスサイズ (48 個の `m5.large` スロットなど) である同種スロットでも、インスタンスタイプが混在する異種スロット (4 つの `m5.large`、4 つの `m5.xlarge`、3 つの `m5.2xlarge`、1 つの `m5.4xlarge`、および 1 つの `m5.8xlarge` など) でもかまいません。これらのスロッティング設定の視覚化については、次の 3 つの図を参照してください。

![\[m5.24xlarge ホストのコンピューティングリソースを示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-outposts-high-availability-design/images/m5-24xlarge-server-resources.png)


![\[48 個の m5.large スロットに同種スロットされた m5.24xlarge ホストを示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-outposts-high-availability-design/images/m5-24xlarge-slotted-into-48-m5-large-slots.png)


![\[4 つの m5.large、4 つの m5.xlarge、3 つの m5.2xlarge、1 つの m5.4xlarge、および 1 つの m5.8xlarge スロットに異種スロットされた m5.24xlarge ホストを示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-outposts-high-availability-design/images/m5-24xlarge-slotted-into-different-x5-slots.png)


 

ホストの全容量をスロットする必要はありません。空き容量が割り当てられていないホストにスロットを追加できます。AWS Outposts のキャパシティ管理 API または UI を使用して新しいキャパシティタスクを作成することで、スロッティングレイアウトを変更できます。詳細については、「*ラックの AWS Outposts ユーザーガイド*」の「[Capacity management for AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-capacity.html)」を参照してください。特定のスロットが実行中のインスタンスによって占有されているため、新しいスロットレイアウトを適用できない場合は、新しいキャパシティタスクを完了するために特定のインスタンスをシャットダウンまたは再起動する必要がある場合があります。`CreateCapacityTask` API を使用すると、指定された Outpost ID に存在する各インスタンスサイズの数を表すことができ、実行中のインスタンスのためにタスクを完了できない場合は、リクエストを満たすために停止する必要があるインスタンスを返します。この時点で、返されたインスタンスの 1 つを停止したくない場合は、「N」個の追加オプションを表示することをオプションで指定できます。また、キャパシティタスクタスクのリクエストを満たすためにシャットダウンするインスタンスとして提案しない EC2 インスタンス ID、EC2 インスタンスタグ、アカウント、またはサービスを指定することもできます。使用するオプションを選択したら、Dry Run パラメータを使用して提案された変更を検証し、実装する前に潜在的な影響を理解することをお勧めします。

 すべてのホストは、プロビジョニングされたスロットを Outpost の EC2 容量プールに提供し、特定のインスタンスタイプとサイズのすべてのスロットは 1 つの EC2 容量プールとして管理されます。例えば、`m5.large`、`m5.xlarge`、`m5.2xlarge`、`m5.4xlarge`、および `m5.8xlarge` スロットを持つ以前の異種スロットホストは、これらのスロットを 5 つの EC2 容量プール、つまりインスタンスタイプとサイズごとに 1 つのプールに分配します。これらのプールは複数のホストに分散される可能性があるため、ワークロードの高可用性を実現するためにはインスタンス配置を検討する必要があります。

 N\$1M ホストの可用性を考慮して予備の容量を計画する際には、ホストスロッティングと EC2 容量プールを考慮することが重要です。AWS は、ホストの失敗や機能低下を検出し、失敗したホストを交換するためにサイト訪問をスケジュールします。EC2 容量プールは、Outpost 内の各インスタンスファミリー (N\$11) の少なくとも 1 台のサーバーの障害に耐えるように設計する必要があります。この最低限のホスト可用性により、ホストが失敗した場合やサービスを停止する必要が生じた場合に、同じファミリーの残りのホストのスペアスロットで、失敗したインスタンスや劣化したインスタンスを再起動できます。

 同じスロットのホストや、同じスロッティングレイアウトを持つ異種スロットのホストのグループがある場合、N\$1M の可用性の計画はシンプルです。すべてのワークロードを実行するのに必要なホストの数 (N) を計算し、障害やメンテナンス中のサーバーの可用性に関する要件を満たすために (M) 台のホストを追加するだけです。

NUMA 境界のため、次のスロッティング設定は使用できません。
+ 3 つの `m5.8xlarge`
+ 1 つの `m5.16xlarge` および 1 つの `m5.8xlarge`

AWS アカウント チームに連絡して、計画された AWS Outposts ラックスロッティング設定を検証してください。

 次の図では、4 台の `m5.24xlarge` ホストが同じスロッティングレイアウトで異種スロットされています。4 台のホストは 5 個の EC2 容量プールを作成します。これら 4 台のホストで実行されているインスタンスの N\$11 の可用性を維持するために、各プールは最大の使用率 (75%) で稼働しています。いずれかのホストが失敗しても、残りのホストで失敗したインスタンスを再起動するための十分な余裕があります。

![\[EC2 ホストスロット、実行中のインスタンス、スロットプールの視覚化を示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-outposts-high-availability-design/images/ec2-server-slots-and-pools.png)


 ホストのスロット構成が同じでない、より複雑なスロッティングレイアウトの場合は、EC2 容量プールごとに N\$1M の可用性を計算する必要があります。次の式を使用して、(特定の EC2 容量プールにスロットを割り当てる) ホストが失敗しても、残りのホストで実行中のインスタンスを処理できるホストの台数を計算できます。

![\[式 M = (使用可能なプールスロット数/最大ホストスロット数)\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-outposts-high-availability-design/images/equation.png)


 コードの説明は以下のとおりです。
+ **poolSlotsavailable** は、特定の EC2 容量プールで使用可能なスロットの数です (プール内のスロットの総数から実行中のインスタンスの数を引いたもの)
+  **serverSlotsmax** は、任意のホストが特定の EC2 容量プールに提供するスロットの最大数 
+  **M** は、失敗しても残りのホストで実行中のインスタンスを実行できるホストの台数 

 ***例:*** Outpost には、1 つの `m5.2xlarge` 容量プールにスロットを提供するホストが 3 台あります。最初のホストは 4 スロット、2 番目のホストは 3 スロット、3 番目のホストは 2 スロットを提供します。Outpost の `m5.2xlarge` インスタンスプールの合計容量は 9 スロット (4 \$1 3 \$1 2) です。Outpost には 4 つの実行中の `m5.2xlarge` インスタンスがあります。失敗しても、残りのホストで実行中のインスタンスを実行できるホストは何台ですか。

![\[3 つの等式\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-outposts-high-availability-design/images/equations.png)


 ***回答:*** いずれのホストを失っても、残りのホストで実行中のインスタンスを引き続き使用できます。

## コンピューティングキャパシティプランニングの推奨プラクティス
<a name="recommended-practices-for-compute-capacity-planning"></a>
+  Outpost の各 EC2 容量プールに N\$1M の冗長性を持たせるように、コンピューティングキャパシティのサイズを設定します。
  +  同種または同一の異種スロットのサーバーに N\$1M 台のサーバーをデプロイします。
  +  各 EC2 容量プールの N\$1M 可用性を計算し、各プールが可用性要件を満たしていることを確認します。