クラスター設定のベストプラクティス

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

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

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

• インスタンスグループ

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

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

  • 1 つのインスタンスグループのオートスケーリングを Amazon EMR にセットアップして、指定する Amazon CloudWatch メトリクスの値に基づいて自動的にインスタンスを追加、削除します。詳細については、「クラスターのスケーリングを使用する」を参照してください。

• インスタンスフリート

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

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

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

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

ほとんどの Amazon EMR クラスターには次のガイドラインがあてはまります。

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

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

• コアノードとタスクノードの計算ニーズは、アプリケーションが実行する処理のタイプによって異なります。汎用のインスタンスタイプでは多くのジョブを実行できます。これは、CPU、ディスク領域、入出力に関して、バランスの取れたパフォーマンスを発揮します。計算集約的なクラスターは、比率的に RAM より CPU が多い、High CPU インスタンス上で実行するとメリットがあります。データベースおよびメモリキャッシュアプリケーションは、大きいメモリインスタンスで実行するとメリットがあります。解析、NLP、機械学習のようなネットワークと CPU を多く使用するアプリケーションは、クラスターコンピューティングインスタンスで実行すると利点があります。この場合、比例的に CPU リソースが大きくなり、ネットワークパフォーマンスが向上します。

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

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

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

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

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

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

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

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

• 全ノード上の 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

注記

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

• yarn.node-labels.enabled: true

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

スポットインスタンスを使って Amazon EMR クラスターを実行すると便利なシナリオがいくつかあります。

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

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

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

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

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

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

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

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

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

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

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

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

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

• 各データブロックが RAID のような冗長性を実現するために　HDFS に保存されている方法を説明する、レプリケーションの要因。デフォルトで、レプリケーション係数は、10 個以上のノードのクラスターで 3、4～9 個のノードのクラスターで 2、3 個以下のノードのクラスターで 1 です。

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

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

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

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

• より大きいストレージ容量で、Amazon EC2 インスタンスタイプを選択する

• データ圧縮を使用する

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

レプリケーション係数を減らすことは、HDFS データの冗長性や、クラスターの HDFS ブロックの損失や破損から復元する能力が低下するため、注意して使用する必要があります。