クラスターの設定のガイドラインとベストプラクティス - Amazon EMR

「翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。」

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

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

どのインスタンスタイプを使用するべきか

クラスターで使用するインスタンスタイプとインスタンス数を計画する場合は、代表的なサンプルデータセットを使用してテストクラスターを実行し、クラスター内のノードの使用率をモニタリングすることをお勧めします。詳細については、「 」を参照してください。View and Monitor a Cluster. テストする前に、このセクションのガイドラインを確認して開始点を見つけます。

デフォルトで、1 つの AWS アカウントで実行できる EC2 インスタンスの総数は 20 です。これはつまり、クラスターに構成できるノードの総数が 20 であることを意味します。クォータの引き上げをリクエストする方法の詳細については、「AWS のサービスクォータ」を参照してください。

各ノードに必要な処理能力とメモリは、いくつかの要因によって異なります。

  • 処理するデータセットのサイズと、どれほど早く結果を得るか。

  • 使用するビッグデータアプリケーションのスイート。

  • タスクの実行とストレージの負担を共有できるインスタンスグループ内のノードの数。

ほとんどのAmazon EMRクラスターは、 などの汎用インスタンスタイプで実行できますm5.xlarge。高速出力を必要とする計算集約的なクラスターは、コンピューティングの最適化または高速化コンピューティングインスタンスで実行するとメリットがあります。データベースおよびメモリキャッシュアプリケーションは、メモリ最適化インスタンスで実行するとメリットがあります。解析、自然言語処理、機械学習など、ネットワークを集中的および CPU を多用するアプリケーションは、拡張ネットワーキングを提供するインスタンスで実行するとメリットがあります。拡張ネットワーキングをサポートするインスタンスの識別子には、多くの場合「n」が付きます。詳細については、「インスタンスタイプエクスプローラー」を参照してください。

また、ノードタイプに基づいて以下のガイドラインを検討します。

マスターノードの考慮事項

一般的に、クラスターが大きいほど、データセットが大きいほど、マスターノードが必要とするメモリが大きくなります。デフォルトのm5.xlargeインスタンスは良い開始点ですが、クラスターが大きくなるにつれて2xlarge や *4xlarge などのメモリの大きいインスタンスタイプを使用することを検討してください。

Spark ワークロードの場合、メモリの断片化を避けるために、マスターノードのメモリ容量を 32 以上のGiBメモリを持つインスタンスタイプに増やすことを検討してください。ほとんどのアプリケーションには 32 で十分GiBです。複数のセッションを実行する場合や、マスターノードで実行されているドライバーでクライアントモードを使用する場合は、より多くのメモリ容量を持つインスタンスを使用することを検討してください。これには、Zeppelin または Jupyter が複数のノートブックセッションを実行するノートブックアプリケーションが含まれます。

マスターノードの機能を選択するときは、メタデータ処理の要件を考慮してください。ローカルディスクストレージと HDFS を使用する大規模なクラスターでは、HDFS NameNode デーモンに対応するために追加のメモリが必要になる場合があります。HBase 大規模なデータセットを持つ クラスターでは、 に対応するために追加のメモリが必要になる場合がありますHBaseHMaster。 Hive と Spark SQL を使用するクラスターでは、多数のパーティションを持つ大きなメタストア用に追加のメモリが必要になる場合があります。

Presto ワークロードの場合は、予想されるクエリ結果のサイズを考慮します。クエリの結果が大きくなると、マスターノードの需要も高くなります。これにより、より多くのメモリ容量の利点が得られます。

コアノードとタスクノードに関する考慮事項

処理できるデータの量は、コアノードのストレージ容量と、入力、処理中、および出力のデータのサイズによって異なります。入力データセット、中間データセット、および出力データセットは、処理中にクラスターに保存されます。

コアノードとタスクノードの計算ニーズは、アプリケーションが実行する処理のタイプによって異なります。タスクノードを追加すると、コアノードの処理の負担を軽減できます。では多くのジョブを実行できますm5.xlarge。データを収集するためのウェブクロールなど、遅延を発生させている外部依存関係がアプリケーションにある場合は、機能していないインスタンスでクラスターを実行してコストを削減できる場合があります。インスタンスは、外部依存関係が終了している間、ジョブの実行にさらに時間がかかる場合があります。

パフォーマンスを向上させるには、コアノードとタスクノードの両方でメモリ容量、処理能力、または処理能力を増やすことを検討してください。クラスターのさまざまなフェーズで容量要件が異なる場合は、少数のコアノードまたはタスクノードから開始し、オンザフライで数を増減できます。

Spark ワークロードの場合、Spark はメモリGiBの 8 つをそれ自体用に予約していると仮定します。これはかなりのベースラインメモリオーバーヘッドです。Spark ワークロードの場合、そのオーバーヘッドと Spark エグゼキュターに対応するために、追加のメモリを持つインスタンスを検討します。

スポットインスタンスはどのような場合に使用しますか?

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'

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

マスターノードは、クラスターを制御し、指示を与えます。マスターノードが終了するとクラスターも終了するので、マスターノードは、突然終了しても問題が発生しないクラスターを実行している場合にのみ、スポットインスタンスとして起動するようにします。たとえば、新しいアプリケーションをテストしている場合、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 ストレージの容量は、次の要因に応じて異なります。

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

  • 使用するインスタンスタイプの EC2 インスタンスストアの容量。インスタンスストアボリュームの詳細については、https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.htmlの「Linux インスタンス用 Amazon EC2 ユーザーガイドAmazon EC2 インスタンスストア.」を参照してください。

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

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

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

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

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

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

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

  • データ圧縮を使用する

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

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