スポットインスタンスのクラスターインスタンスタイプとベストプラクティスの設定

このセクションのガイダンスを使用して、 EMRクラスター内のノードタイプごとにプロビジョニングするインスタンスタイプ、購入オプション、およびストレージの量を決定します。

使用すべきインスタンスタイプ

Amazon EC2インスタンスをクラスターに追加するには、いくつかの方法があります。選択の必要がある方法は、クラスターにインスタンスグループ設定を使用しているか、またはインスタンスフリート設定を使用しているかによって異なります。

• インスタンスグループ

  • 既存のコアおよびタスクインスタンスグループと同じタイプのインスタンスを手動で追加します。

  • 手動でタスクインスタンスグループを追加します。これには、別のインスタンスタイプを使用できます。

  • EMR インスタンスグループの Amazon で自動スケーリングを設定し、指定した Amazon CloudWatch メトリクスの値に基づいてインスタンスを自動的に追加および削除します。詳細については、「Amazon EMRクラスタースケーリングを使用してワークロードの変化に合わせて調整する」を参照してください。

• インスタンスフリート

  • 単一のタスクインスタンスフリートを追加します。

  • 既存のコアおよびタスクインスタンスフリートにオンデマンドおよびスポットインスタンスのターゲット容量を変更します。詳細については、「クラスターのインスタンスフリートの計画と設定」を参照してください。

クラスターのインスタンスを計画する 1 つの方法は、代表的なデータのサンプルセットで、テストクラスターを実行し、クラスター内のノードの使用状況を監視することです。詳細については、「作業の実行時に Amazon EMRクラスターを表示およびモニタリングする」を参照してください。別の方法は、考慮するインスタンスの容量を計算し、その値をデータのサイズに対して比較することです。

一般に、タスクを割り当てるプライマリノードタイプには、処理能力の高いEC2インスタンスは必要ありません。タスクを処理して にデータを保存するコアノードタイプの Amazon EC2インスタンスにはHDFS、処理能力とストレージ容量の両方が必要です。データを保存しないタスクノードタイプの Amazon EC2インスタンスには、処理能力のみが必要です。使用可能な Amazon EC2インスタンスとその設定に関するガイドラインについては、「」を参照してくださいAmazon で使用する Amazon EC2インスタンスタイプを設定する EMR。

ほとんどの Amazon EMRクラスターには、次のガイドラインが適用されます。

• で実行するオンデマンド Amazon EC2インスタンスの合計数には vCPU の制限があります。 AWS あたりの アカウント AWS リージョン。 vCPU 制限とアカウントの制限引き上げをリクエストする方法の詳細については、Linux インスタンス用 Amazon ユーザーガイドの「オンデマンドインスタンス」を参照してください。 EC2

• プライマリノードには通常、大量の計算要件がありません。多数のノードを持つクラスター、または特にプライマリノード (、Hue など) にデプロイされたアプリケーションを持つクラスターの場合JupyterHub、より大きなプライマリノードが必要になる場合があり、クラスターのパフォーマンスを向上させるのに役立ちます。例えば、小さなクラスター (50 以下のノード) には m5.xlarge インスタンスを使用し、より大きなクラスターではより大きなインスタンスタイプに増やすことを検討します。

• コアノードとタスクノードの計算ニーズは、アプリケーションが実行する処理のタイプによって異なります。汎用インスタンスタイプでは、、CPUディスク容量、入出力の点でバランスの取れたパフォーマンスを提供する多くのジョブを実行できます。計算負荷の高いクラスターは、 CPUよりも比例的に多い高CPUインスタンスで を実行するとメリットが得られますRAM。データベースおよびメモリキャッシュアプリケーションは、大きいメモリインスタンスで実行するとメリットがあります。解析、、機械学習などのネットワーク集約型およびCPU集約型のアプリケーションはNLP、クラスターコンピューティングインスタンスで を実行することでメリットを得られます。これにより、比例的に高いCPUリソースとネットワークパフォーマンスが得られます。

• クラスターの段階によって必要な容量が異なる場合は、少ない数のコアノードから始め、タスクノードの数を増減してジョブフローでの容量要件の変化に合わせます。

• 処理可能なデータの量は、コアノードの容量と、入力、処理時、および出力のデータのサイズによって異なります。処理中、入力、中間、および出力データセットはすべてクラスターに存在します。

スポットインスタンスを使用すべき場合

Amazon でクラスターを起動するときにEMR、スポットインスタンスでプライマリインスタンス、コアインスタンス、またはタスクインスタンスを起動することを選択できます。各インスタンスグループタイプがクラスターではそれぞれ異なる役割を果たすので、スポットインスタンス上で各ノードタイプを起動したときの意味合いもそれぞれ異なります。クラスターの実行中にインスタンス購入オプションを変更することはできません。プライマリノードおよびコアノードのオンデマンドインスタンスをスポットインスタンスに変更する、またはその逆に変更するには、クラスターを終了して新しいクラスターを起動する必要があります。タスクノードについては、新しいタスクインスタンスグループまたはインスタンスフリートを開始し、古いものを削除できます。

タスクノードのスポットインスタンスの終了によるジョブの失敗を防ぐための Amazon EMR設定

スポットインスタンスはタスクノードの実行によく使用されるため、Amazon EMRにはYARNジョブをスケジュールするデフォルトの機能があるため、スポットインスタンスで実行されているタスクノードが終了したときにジョブの実行が失敗することはありません。Amazon EMR は、アプリケーションマスタープロセスをコアノードでのみ実行できるようにすることでこれを行います。アプリケーションマスタープロセスは実行中のジョブを制御し、ジョブが有効である間は存続する必要があります。

Amazon EMRリリース 5.19.0 以降では、組み込みYARNノードラベル機能を使用してこれを実現しています。(以前のバージョンではコードパッチを使用していました)。yarn-site および capacity-scheduler設定分類のプロパティは、YARNキャパシティスケジューラと公平スケジューラがノードラベルを利用できるようにデフォルトで設定されます。Amazon EMRはコアノードに COREラベルを自動的に付け、アプリケーションマスターが CORE ラベルの付いたノードでのみスケジュールされるようにプロパティを設定します。yarn-site および capacity-scheduler 設定分類の関連プロパティを手動で変更するか、関連XMLファイルを直接変更すると、この機能が破損したり、この機能が変更される可能性があります。

Amazon は、デフォルトで次のプロパティと値EMRを設定します。これらのプロパティを設定するときは注意が必要です。

注記

Amazon 6.x EMR リリースシリーズ以降、YARNノードラベル機能はデフォルトで無効になっています。アプリケーションプライマリプロセスは、デフォルトでコアノードとタスクノードの両方で実行できます。YARN ノードラベル機能を有効にするには、次のプロパティを設定します。

• yarn.node-labels.enabled: true

• yarn.node-labels.am.default-node-label-expression: 'CORE'

• 全ノード上の yarn-site (yarn-site.xml)

  • yarn.node-labels.enabled: true

  • yarn.node-labels.am.default-node-label-expression: 'CORE'

  • yarn.node-labels.fs-store.root-dir: '/apps/yarn/nodelabels'

  • yarn.node-labels.configuration-type: 'distributed'

• プライマリおよびコアノード上の yarn-site (yarn-site.xml)

  • yarn.nodemanager.node-labels.provider: 'config'

  • yarn.nodemanager.node-labels.provider.configured-node-partition: 'CORE'

• 全ノード上の capacity-scheduler (capacity-scheduler.xml)

  • yarn.scheduler.capacity.root.accessible-node-labels: '*'

  • yarn.scheduler.capacity.root.accessible-node-labels.CORE.capacity: 100

  • yarn.scheduler.capacity.root.default.accessible-node-labels: '*'

  • yarn.scheduler.capacity.root.default.accessible-node-labels.CORE.capacity: 100

スポットインスタンス上のプライマリノード

プライマリノードは、クラスターを制御し、指示を与えます。プライマリノードが終了するとクラスターも終了するので、プライマリノードは、突然終了しても問題が発生しないクラスターを実行している場合にのみ、スポットインスタンスとして起動するようにします。例えば、新しいアプリケーションをテストしている場合、Simple Storage Service (Amazon S3) などの外部ストアにクラスターのデータを定期的に保持している場合、またはクラスターが確実に完了することよりもコストの方が重要なクラスターを実行している場合などがこれに当てはまります。

プライマリインスタンスグループをスポットインスタンスとして起動する場合、クラスターは、そのスポットインスタンスリクエストが満たされるまで開始されません。最大スポット料金を選択する場合は、この点を考慮に入れてください。

スポットインスタンスプライマリノードを追加できるのは、クラスターの起動時のみです。実行中のクラスターに対してプライマリノードを追加したり削除したりすることはできません。

通常は、クラスター全体 (すべてのインスタンスグループ) をスポットインスタンスとして実行している場合にのみ、プライマリノードをスポットインスタンスとして実行します。

スポットインスタンス上のコアノード

コアノードは、 を使用してデータを処理し、情報を保存しますHDFS。コアインスタンスを終了すると、データ損失のリスクがあります。このため、部分的なHDFSデータ損失が許容できる場合にのみ、スポットインスタンスでコアノードを実行する必要があります。

コアインスタンスグループをスポットインスタンスとして起動すると、Amazon はリクエストされたすべてのコアインスタンスをプロビジョニングできるまでEMR待ってから、インスタンスグループを起動します。つまり、6 つの Amazon EC2インスタンスをリクエストし、最大スポット料金以下の 5 つのインスタンスしか利用できない場合、インスタンスグループは起動しません。Amazon は、6 つの Amazon EC2インスタンスがすべて使用可能になるまで、またはクラスターを終了するまで待機しEMR続けます。1 つのコアインスタンスグループに含まれるスポットインスタンスの数を変更して、実行中のクラスターに容量を追加することができます。インスタンスグループの操作方法およびインスタンスフリートでのスポットインスタンスの動作の詳細については、「インスタンスフリートまたはユニフォームインスタンスグループでクラスターを作成する」を参照してください。

スポットインスタンス上のタスクノード

タスクノードはデータを処理しますが、 に永続データを保持しませんHDFS。スポット価格が最大スポット料金を上回ったためにクラスターが終了した場合、データは失われず、クラスターに対する影響も最小限に抑えられます。

1 つ以上のタスクインスタンスグループをスポットインスタンスとして起動すると、Amazon は最大スポット料金を使用して、可能な限り多くのタスクノードをEMRプロビジョニングします。つまり、6 つのノードを持つタスクインスタンスグループをリクエストし、最大スポット料金以下で使用できるスポットインスタンスが 5 つしかない場合、Amazon は 5 つのノードを持つインスタンスグループEMRを起動し、可能であれば 6 番目を追加します。

スポットインスタンスとしてタスクインスタンスグループを起動すると、最小限のコストで戦略的にクラスターの容量を拡大できます。プライマリインスタンスグループとコアインスタンスグループをオンデマンドインスタンスとして起動する場合、その容量はクラスターを実行するために確保されます。必要に応じて、タスクインスタンスグループにタスクインスタンスを追加し、ピークトラフィックの負荷に対応するか、データ処理の速度を上げます。

コンソールを使用してタスクノードを追加または削除できます。 AWS CLI、、または API。また、タスクグループを追加することもできますが、作成後にタスクグループを削除することはできません。

アプリケーション向けのインスタンスの設定シナリオ

次の表は、通常さまざまなアプリケーションシナリオに適しているノードタイプ購入オプションと構成のクイックリファレンスです。各シナリオタイプの詳細情報を表示するには、リンクを選択します。

アプリケーションシナリオ	プライマリノードの購入オプション	コアノード購入オプション	タスクノード購入オプション
長時間稼働クラスターおよびデータウェアハウス	オンデマンド	オンデマンドまたはインスタンスフリートの組み合わせ	スポットまたはインスタンスフリートの組み合わせ
コスト主導のワークロード	スポット	スポット	スポット
データクリティカルなワークロード	オンデマンド	オンデマンド	スポットまたはインスタンスフリートの組み合わせ
アプリケーションのテスト	スポット	スポット	スポット

スポットインスタンスが Amazon EMRクラスターの実行に役立つシナリオがいくつかあります。

長時間稼働クラスターおよびデータウェアハウス

データウェアハウスなどの計算能力に予測可能なばらつきがある永続的な Amazon EMRクラスターを実行している場合は、スポットインスタンスでピーク需要を低コストで処理できます。プライマリインスタンスグループおよびコアインスタンスグループをオンデマンドインスタンスとして通常の容量に対応するように起動し、タスクインスタンスグループをスポットインスタンスとしてピーク負荷の要件に対応するように起動することができます。

コスト主導のワークロード

完了までの時間よりも、コストをかけないことの方が重要な一時クラスターを実行している場合、一部の作業が失われてもよいときは、クラスター全体 (プライマリ、コア、およびタスクインスタンスグループ) をスポットインスタンスとして実行して、最大限のコスト削減を実現できます。

データクリティカルなワークロード

完了までの時間よりも、コストをかけないことの方が重要な一時クラスターを実行している場合、すべての作業を保持する必要があるときは、プライマリインスタンスグループとコアインスタンスグループをオンデマンドインスタンスとして起動し、スポットインスタンスの 1 つ以上のタスクインスタンスグループで補完します。プライマリインスタンスグループとコアインスタンスグループをオンデマンドインスタンスとして実行するHDFSと、データが に保持され、スポットマーケットの変動による終了からクラスターが保護されます。同時に、タスクインスタンスグループをスポットインスタンスとして実行することで発生するコスト削減も実現されます。

アプリケーションのテスト

実稼働環境で起動できるよう準備する目的で新しいアプリケーションをテストする場合は、クラスター全体 (プライマリ、コア、およびタスクインスタンスグループ) をスポットインスタンスとして実行し、テストコストを削減できます。

クラスターに必要なHDFS容量の計算

クラスターで使用できるHDFSストレージの量は、次の要因によって異なります。

• コアノードに使用される Amazon EC2インスタンスの数。

• 使用されるEC2インスタンスタイプの Amazon インスタンスストアの容量。インスタンスストアボリュームの詳細については、「Amazon ユーザーガイド」の「Amazon EC2インスタンスストア」を参照してください。 EC2

• コアノードにアタッチされた Amazon EBSボリュームの数とサイズ。

• レプリケーション係数。各データブロックが RAIDのような冗長性HDFSのために にどのように保存されるかを考慮します。デフォルトで、レプリケーション係数は、10 個以上のノードのクラスターで 3、4～9 個のノードのクラスターで 2、3 個以下のノードのクラスターで 1 です。

クラスターのHDFS容量を計算するには、コアノードごとに、インスタンスストアボリューム容量を Amazon EBSストレージ容量 (使用する場合) に追加します。計算結果にコアノードの数をかけて、その合計をコアノードの数に基づいてレプリケーション係数で割ります。例えば、Amazon EBSボリュームがアタッチされていない 800 GB のインスタンスストレージを持つ、タイプ i2.xlarge の 10 コアノードを持つクラスターでは、合計約 2,666 GB が で使用できます HDFS (10 ノード x 800 GB ÷ 3 レプリケーション係数）。

計算されたHDFS容量値がデータよりも小さい場合は、次の方法でHDFSストレージ量を増やすことができます。

• Amazon EBSボリュームを追加してクラスターを作成するか、Amazon EBSボリュームがアタッチされたインスタンスグループを既存のクラスターに追加する

• より多くのコアノードを追加する

• ストレージ容量が大きい Amazon EC2インスタンスタイプの選択

• データ圧縮を使用する

• レプリケーション要素を減らすためにHadoop 構成設定を変更する

レプリケーション係数を減らすと、HDFSデータの冗長性が低下し、クラスターが紛失または破損したHDFSブロックから回復できるため、慎重に使用する必要があります。