翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon EMR クラスターのアベイラビリティーゾーンの柔軟性
各 AWS リージョン には、アベイラビリティーゾーンと呼ばれる複数の独立した場所があります。インスタンスを起動するときは、必要に応じて、使用している AWS リージョン でアベイラビリティーゾーン (AZ) を指定できます。[アベイラビリティーゾーンの柔軟性](#emr-flexibility-az)とは、インスタンスを複数の AZ に分散させることです。あるインスタンスで障害が発生しても、別の AZ のインスタンスでリクエストを処理できるようにアプリケーションを設計できます。詳細については、「*Amazon EC2 ユーザーガイド*」の「[リージョンとゾーン](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones)」のドキュメントを参照してください。
[インスタンスの柔軟性](#emr-flexibility-types)とは、容量要件を満たすために複数のインスタンスタイプを使用することです。インスタンスに柔軟性を持たせると、インスタンスのサイズ、ファミリー、世代をまたいで集計された容量を使用できます。柔軟性が高いほど、単一のインスタンスタイプを使用するクラスターと比較して、必要な量のコンピューティング容量を見つけて割り当てられる可能性が高くなります。
インスタンスとアベイラビリティーゾーンの柔軟性により、インスタンスタイプまたは AZ が 1 つのクラスターに比べて、[容量不足エラー (ICE)](emr-events-response-insuff-capacity.md) やスポットの中断が少なくなります。最初のインスタンスファミリーとサイズがわかったら、ここで説明するベストプラクティスを参考にして、どのインスタンスを分散させるかを判断してください。このアプローチは、パフォーマンスとコストの変動を最小限に抑えながら、Amazon EC2 容量プールの可用性を最大化します。
## アベイラビリティーゾーンに関する柔軟性
すべてのアベイラビリティーゾーンを仮想プライベートクラウド (VPC) で使用するように設定し、EMR クラスター用に選択することをお勧めします。クラスターは 1 つのアベイラビリティーゾーンにのみ存在する必要がありますが、Amazon EMR インスタンスフリートでは、アベイラビリティーゾーンごとに複数のサブネットを選択できます。Amazon EMR は、クラスターを起動するときに、指定されたインスタンスと購入オプションをこれらのサブネットで探します。複数のサブネットの EMR クラスターをプロビジョニングすると、クラスターは、単一のサブネット内のクラスターと比較して、より深い Amazon EC2 キャパシティプールにアクセスできます。
EMR クラスターの仮想プライベートクラウド (VPC) で特定の数のアベイラビリティーゾーンを優先的に使用する必要がある場合は、Amazon EC2 のスポットプレイスメントスコア機能を活用できます。スポットプレイスメントスコアリングでは、スポットインスタンスのコンピューティング要件を指定し、EC2 は 1～10 のスケールでスコア付けされた上位 10 個の AWS リージョン またはアベイラビリティーゾーンを返します。スコア 10 はスポットリクエストが成功する可能性が高いことを示し、スコア 1 はスポットリクエストが成功する可能性が低いことを示します。スポットプレイスメントスコアリングの使用方法の詳細については、「*Amazon EC2 ユーザーガイド*」の「[スポットプレースメントスコア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-placement-score.html)」を参照してください。
## インスタンスタイプに関する柔軟性
インスタンスの柔軟性とは、容量要件を満たすために複数のインスタンスタイプを使用することです。インスタンスの柔軟性は Amazon EC2 スポットインスタンスとオンデマンドインスタンスの使用の両方にメリットをもたらします。スポットインスタンスでは、インスタンスの柔軟性により、Amazon EC2 はリアルタイムの容量データを使用して、より深い容量プールからインスタンスを起動できます。また、どのインスタンスが最も可用性が高いかを予測します。これにより、中断が少なくなり、ワークロード全体のコストを削減できます。オンデマンドインスタンスを使用すると、インスタンスが柔軟になり、より多くのインスタンスプールに合計キャパシティをプロビジョニングする場合の、キャパシティ不足エラー (ICE) が減少します。
**インスタンスグループ**クラスターでは、最大 50 の EC2 インスタンスタイプを指定できます。配分戦略付きの**インスタンスフリート**では、プライマリ、コア、タスクノードグループごとに最大 30 の EC2 インスタンスタイプを指定できます。インスタンスの範囲が広いほど、インスタンスの柔軟性のメリットも高まります。
### インスタンスに柔軟性を持たせる
アプリケーションのインスタンスに柔軟性を持たせるには、次のベストプラクティスを考慮してください。
**Topics**
+ [インスタンスファミリーとサイズを決定する](#emr-flexibility-express-size)
+ [追加のインスタンスを含める](#emr-flexibility-express-include)
#### インスタンスファミリーとサイズを決定する
Amazon EMR は、異なるユースケース向けに複数のインスタンスタイプをサポートします。これらのインスタンスタイプは「[Amazon EMR でサポートされているインスタンスタイプ](emr-supported-instance-types.md)」ドキュメントに記載されています。各インスタンスタイプは、そのタイプがどのアプリケーションに最適化されているかを説明するインスタンスファミリーに属します。
新しいワークロードでは、`m5` や `c5` などの汎用ファミリーのインスタンスタイプでベンチマークする必要があります。次に、Ganglia および Amazon CloudWatch の OS と YARN のメトリクスを監視し、ピーク負荷時のシステムボトルネックを特定します。ボトルネックには、CPU、メモリ、ストレージ、I/O 操作が含まれます。ボトルネックを特定したら、コンピューティング最適化、メモリ最適化、ストレージ最適化、またはインスタンスタイプに適した他のインスタンスファミリーを選択します。詳細については、GitHub の Amazon EMR ベストプラクティスガイドの「[Determine right infrastructure for your Spark workloads](https://github.com/aws/aws-emr-best-practices/blob/main/website/docs/bestpractices/Applications/Spark/best_practices.md#bp-512-----determine-right-infrastructure-for-your-spark-workloads)」ページを参照してください。
次に、アプリケーションに必要な最小の YARN コンテナまたは Spark エグゼキュターを特定します。これはコンテナに収まる最小のインスタンスサイズであり、クラスターの最小インスタンスサイズでもあります。この指標を使用して、さらに分散できるインスタンスを特定してください。インスタンスが小さいほど、インスタンスの柔軟性が高まります。
インスタンスの柔軟性を最大限に高めるには、できるだけ多くのインスタンスを活用する必要があります。ハードウェア仕様が似ているインスタンスを使用して分散することをおすすめします。これにより、コストとパフォーマンスの変動を最小限に抑えながら EC2 容量プールに最大限にアクセスできるようになります。規模を問わず分散できます。そのためには、 AWS Graviton とそれ以前の世代を優先してください。一般的に、ワークロードごとに少なくとも 15 種類のインスタンスタイプの間で柔軟に対応してみてください。汎用インスタンス、コンピューティング最適化インスタンス、またはメモリ最適化インスタンスから開始することをお勧めします。これらのインスタンスタイプは最大の柔軟性を提供します。
#### 追加のインスタンスを含める
多様性を最大限に高めるには、追加のインスタンスタイプを含めます。まず、インスタンスサイズ、Graviton、および生成の柔軟性を優先します。これにより、コストとパフォーマンスのプロファイルが似ている追加の EC2 キャパシティプールにアクセスできるようになります。ICE やスポットでの中断によりさらに柔軟性が必要な場合は、バリアントとファミリーの柔軟性を検討してください。それぞれのアプローチには、ユースケースと要件に応じたトレードオフがあります。
+ **サイズの柔軟性** — まず、同じファミリー内でサイズの異なるインスタンスを分散させます。同じファミリー内のインスタンスはもコストとパフォーマンスは同じですが、ホストごとに異なる数のコンテナを起動できます。例えば、必要なエグゼキュターの最小サイズが 2vCPU と 8Gb メモリの場合、最小インスタンスサイズは `m5.xlarge` です。サイズを柔軟にするために、`m5.xlarge`、`m5.2xlarge`、`m5.4xlarge`、`m5.8xlarge`、`m5.12xlarge`、`m5.16xlarge` および `m5.24xlarge` を含めてください。
+ **Graviton の柔軟性** — Graviton インスタンスでは、サイズだけでなく分散も可能です。Graviton インスタンスは、Amazon EC AWS 2 のクラウドワークロードに最適な価格パフォーマンスを提供する Graviton2 プロセッサを搭載しています。 Amazon EC2 例えば、`m5.xlarge` の最小インスタンスサイズに、Graviton の柔軟性のために、`m6g.xlarge`、`m6g.2xlarge`、`m6g.4xlarge`、`m6g.8xlarge` および `m6g.16xlarge` を含めることができます。
+ **生成の柔軟性** — Graviton やサイズの柔軟性と同様に、前世代のファミリーのインスタンスは同じハードウェア仕様を共有しています。これにより、アクセス可能な Amazon EC2 プールの合計が増加し、同様のコストとパフォーマンスのプロファイルになります。生成の柔軟性を高めるため、`m4.xlarge`、`m4.2xlarge`、`m4.10xlarge`、および `m4.16xlarge` を含めます。
+ **ファミリーとバリアントの柔軟性**
+ **キャパシティ** — キャパシティを最適化するには、インスタンスファミリー全体でインスタンスに柔軟性を持たせることをお勧めします。異なるインスタンスファミリーの一般的なインスタンスには、容量要件を満たすのに役立つより深いインスタンスプールがあります。ただし、ファミリーのインスタンスが異なれば、vCPU とメモリの比率は異なります。このため、想定されるアプリケーションコンテナのサイズが別のインスタンス用であれば、十分に利用できないことになります。例えば `m5.xlarge` には、インスタンスファミリーの柔軟性のために、コンピューティング最適化インスタンス (`c5` など) やメモリ最適化インスタンス (`r5` など) が含まれます。
+ **コスト** — コストを最適化するには、バリアント全体でインスタンスに柔軟性を持たせることをお勧めします。これらのインスタンスのメモリと vCPU の比率は初期インスタンスと同じです。バリアントの柔軟性とのトレードオフは、これらのインスタンスの容量プールが小さいため、追加の容量が制限されたり、スポットの中断が増えたりする可能性があることです。例えば `m5.xlarge` では、インスタンスバリアントの柔軟性のために、AMD ベースのインスタンス (`m5a`)、SSD ベースのインスタンス (`m5d`)、またはネットワーク最適化インスタンス (`m5n`) を含めます。