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

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

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

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

• インスタンスグループ

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

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

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

• インスタンスフリート

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

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

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

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

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

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

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

• コアノードとタスクノードの計算ニーズは、アプリケーションが実行する処理のタイプによって異なります。多くのジョブは汎用インスタンスタイプで実行でき、 、ディスク容量CPU、入出力の点でバランスの取れたパフォーマンスを提供します。計算集約型クラスターは、 CPUを比例的に超える高CPUインスタンスで を実行するとメリットがありますRAM。データベースおよびメモリキャッシュアプリケーションは、大きいメモリインスタンスで実行するとメリットがあります。解析、、機械学習などのネットワーク集約型NLPおよびCPU集約型のアプリケーションは、クラスターコンピューティングインスタンスで を実行することで、比例的に高い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ラベルの付いたノードでのみスケジュールされるようにプロパティを設定します。ヤーンサイトおよびキャパシティスケジューラ設定分類の関連プロパティを手動で変更するか、関連するXMLファイルを直接変更すると、この機能が壊れたり、この機能が変更されたりする可能性があります。

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

注記

Amazon EMR 6.x リリースシリーズ以降、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 つのコアインスタンスグループに含まれるスポットインスタンスの数を変更して、実行中のクラスターに容量を追加することができます。インスタンスグループの操作方法およびインスタンスフリートでのスポットインスタンスの動作の詳細については、「インスタンスフリートまたはユニフォームインスタンスグループを使用して Amazon EMRクラスターを作成する」を参照してください。

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

タスクノードはデータを処理しますが、永続データを に保持しません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 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ブロックからクラスターが回復する能力が低下するため、慎重に使用する必要があります。