アベイラビリティーゾーンの柔軟性

各 AWS リージョン には、アベイラビリティーゾーンと呼ばれる複数の独立した場所があります。インスタンスを起動するときに、オプションで でアベイラビリティーゾーン (AZ) を指定できます。 AWS リージョン 使用する 。アベイラビリティーゾーンの柔軟性は、複数の にまたがるインスタンスの分散ですAZs。あるインスタンスで障害が発生しても、別の AZ のインスタンスでリクエストを処理できるようにアプリケーションを設計できます。アベイラビリティーゾーンの詳細については、「Amazon EC2ユーザーガイド」の「リージョンとゾーンのドキュメント」を参照してください。

インスタンスの柔軟性とは、容量要件を満たすために複数のインスタンスタイプを使用することです。インスタンスに柔軟性を持たせると、インスタンスのサイズ、ファミリー、世代をまたいで集計された容量を使用できます。柔軟性が高いほど、単一のインスタンスタイプを使用するクラスターと比較して、必要な量のコンピューティング容量を見つけて割り当てられる可能性が高くなります。

インスタンスとアベイラビリティーゾーンの柔軟性により、単一のインスタンスタイプまたは AZ を持つクラスターと比較して、容量不足エラー (ICE） とスポット中断が減少します。最初のインスタンスファミリーとサイズがわかったら、ここで説明するベストプラクティスを参考にして、どのインスタンスを分散させるかを判断してください。このアプローチにより、パフォーマンスとコストの変動を最小限に抑えながら、Amazon EC2キャパシティプールの可用性を最大化できます。

アベイラビリティーゾーンに関する柔軟性

仮想プライベートクラウド (VPC) で使用するようにすべてのアベイラビリティーゾーンを設定し、EMRクラスター用に選択することをお勧めします。クラスターは 1 つのアベイラビリティーゾーンにのみ存在する必要がありますが、Amazon EMRインスタンスフリートでは、異なるアベイラビリティーゾーンに複数のサブネットを選択できます。Amazon がクラスターEMRを起動すると、これらのサブネットを検索して、指定したインスタンスと購入オプションを検索します。複数のサブネットに対して EMRクラスターをプロビジョニングすると、単一のサブネット内のクラスターと比較して、クラスターはより深い Amazon EC2キャパシティプールにアクセスできます。

EMR クラスターの仮想プライベートクラウド (VPC) で使用する特定の数のアベイラビリティーゾーンに優先順位を付ける必要がある場合は、Amazon でスポットプレイスメントスコア機能を活用できますEC2。スポットプレイスメントスコアリングでは、スポットインスタンスのコンピューティング要件を指定し、上位 10 位EC2を返します。 AWS リージョン または アベイラビリティーゾーンは、1～10 のスケールでスコアリングされます。スコア 10 はスポットリクエストが成功する可能性が高いことを示し、スコア 1 はスポットリクエストが成功する可能性が低いことを示します。スポットプレイスメントスコアリングの使用方法の詳細については、「Amazon ユーザーガイド」の「スポットプレイスメントスコア」を参照してください。 EC2

インスタンスタイプに関する柔軟性

インスタンスの柔軟性とは、容量要件を満たすために複数のインスタンスタイプを使用することです。インスタンスの柔軟性は、Amazon EC2 スポットインスタンスとオンデマンドインスタンスの両方の使用にメリットをもたらします。スポットインスタンスを使用すると、インスタンスの柔軟性により、Amazon はリアルタイムの容量データを使用して、より深い容量プールからインスタンスEC2を起動できます。また、どのインスタンスが最も可用性が高いかを予測します。これにより、中断が少なくなり、ワークロード全体のコストを削減できます。オンデマンドインスタンスでは、インスタンスの柔軟性により、合計容量がより多くのインスタンスプールにプロビジョニングされるときに、容量不足エラー (ICE) が減少します。

インスタンスグループクラスターでは、最大 50 個のEC2インスタンスタイプを指定できます。配分戦略を使用するインスタンスフリートの場合、プライマリ、コア、タスクの各ノードグループに最大 30 個のEC2インスタンスタイプを指定できます。インスタンスの範囲が広いほど、インスタンスの柔軟性のメリットも高まります。

インスタンスに柔軟性を持たせる

アプリケーションのインスタンスに柔軟性を持たせるには、次のベストプラクティスを考慮してください。

インスタンスファミリーとサイズを決定する

Amazon EMR は、さまざまなユースケースで複数のインスタンスタイプをサポートしています。これらのインスタンスタイプは「Amazon でサポートされているインスタンスタイプ EMR」ドキュメントに記載されています。各インスタンスタイプは、そのタイプがどのアプリケーションに最適化されているかを説明するインスタンスファミリーに属します。

新しいワークロードでは、m5 や c5 などの汎用ファミリーのインスタンスタイプでベンチマークする必要があります。次に、Ganglia と の OS とYARNメトリクスをモニタリングします。 Amazon CloudWatch は、ピーク負荷時のシステムのボトルネックを判断します。ボトルネックには、CPU、メモリ、ストレージ、I/O オペレーションが含まれます。ボトルネックを特定したら、コンピューティング最適化、メモリ最適化、ストレージ最適化、またはインスタンスタイプに適した他のインスタンスファミリーを選択します。詳細については、「」の「Amazon ベストプラクティスガイド」の「Spark ワークロードに適したインフラストラクチャを決定する」ページを参照してください GitHub。 EMR

次に、アプリケーションに必要な最小の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 インスタンスは を利用 AWS Amazon のクラウドワークロードに最適な価格パフォーマンスを提供する Graviton2 プロセッサ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) を含めます。