Amazon EMR でマネージドスケーリングを使用する - Amazon EMR
概要可用性パラメータ考慮事項機能履歴

Amazon EMR でマネージドスケーリングを使用する

重要

マネージドスケーリングには、最新の Amazon EMR リリース (Amazon EMR 6.14.0) を使用することを強くお勧めします。一部の初期のリリースでは、断続的なアプリケーション障害やスケーリングの遅延が発生する可能性があります。Amazon EMR では、5.x リリース 5.30.2、5.31.1、5.32.1、5.33.1 以降、および 6.x リリース 6.1.1、6.2.1、6.3.1 以降でこの問題を解決しました。リージョンと提供リリースの詳細については、「マネージドスケーリングの提供状況」を参照してください。

概要

Amazon EMR バージョン 5.30.0 以降 (Amazon EMR 6.0.0 を除く) では、Amazon EMR Managed Scaling を有効にできます。マネージドスケーリングを使用すると、ワークロードに基づいてクラスター内のインスタンスやユニットの数を自動的に増減できます。Amazon EMR は引き続きクラスターのメトリクスを評価し、クラスターのコストと速度を最適化するためのスケーリングを決定します。マネージドスケーリングは、インスタンスグループとインスタンスフリートのいずれかで構成されるクラスターで使用できます。

マネージドスケーリングの提供状況

  • アジアパシフィック (ジャカルタ) では、Amazon EMR 6.14.0 以降で Amazon EMR Managed Scaling を利用できます。

  • 以下の AWS リージョンでは、Amazon EMR Managed Scaling は Amazon EMR 5.30.0 および 6.1.0 以降で利用できます。

    米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン、北カリフォルニア)、南米 (サンパウロ)、欧州 (フランクフルト、アイルランド、ロンドン、ミラノ、パリ、ストックホルム)、カナダ (中部)、アジアパシフィック (香港、ムンバイ、ソウル、シンガポール、シドニー、東京)、中東 (バーレーン)、アフリカ (ケープタウン)、AWS GovCloud (米国東部)、AWS GovCloud (米国西部)、Sinnet が運営する中国 (北京)、NWCD が運営する中国 (寧夏)。

  • Amazon EMR Managed Scaling は、Spark、Hadoop、Hive、Flink などの YARN アプリケーションでのみ機能します。Presto や HBase など、YARN に基づいていないアプリケーションはサポートされていません。

マネージドスケーリングのパラメータ

マネージドスケーリングでは、以下のパラメータを設定する必要があります。制限は、コアノードとタスクノードのみに適用されます。初期設定後にプライマリノードをスケールすることはできません。

  • 最小(MinimumCapacityUnits) — 1 クラスターに許可される EC2 容量の下限。これは、インスタンスグループについては仮想中央処理装置 (vCPU) コアまたはインスタンスで測定されます。インスタンスフリートについてはユニットで測定されます。

  • 最大(MaximumCapacityUnits) — 1 クラスターに許可される EC2 容量の上限。これは、インスタンスグループについては仮想中央処理装置 (vCPU) コアまたはインスタンスで測定されます。インスタンスフリートについてはユニットで測定されます。

  • オンデマンド制限(MaximumOnDemandCapacityUnits) (オプション) — クラスター内のオンデマンドマーケットタイプに許可される EC2 容量の上限。このパラメータが指定されていない場合、デフォルトは MaximumCapacityUnits の値になります。

    • このパラメータは、オンデマンドインスタンスとスポットインスタンスの間で容量割り当てを分割するために使用します。例えば、最小パラメータを 2 インスタンス、最大パラメータを 100 インスタンス、オンデマンド制限を 10 インスタンスに設定した場合、Amazon EMR Managed Scaling は最大 10 のオンデマンドインスタンスにスケールアップし、残りの容量をスポットインスタンスに割り当てます。詳細については、「ノード割り当てシナリオ」を参照してください。

  • 最大コアノード(MaximumCoreCapacityUnits) (オプション) — クラスターのコアノードタイプに許可される EC2 キャパシティの上限。このパラメータが指定されていない場合、デフォルトは MaximumCapacityUnits の値になります。

    • このパラメータは、コアノードとタスクノードの間で容量割り当てを分割するために使用します。例えば、最小パラメータを 2 インスタンス、最大を 100 インスタンス、最大コアノードを 17 インスタンスに設定した場合、Amazon EMR Managed Scaling は最大 17 のコアノードにスケールアップし、残りの 83 インスタンスをタスクノードに割り当てます。詳細については、「ノード割り当てシナリオ」を参照してください。

マネージドスケーリングパラメータの詳細については、「ComputeLimits」を参照してください。

Amazon EMR Managed Scaling に関する考慮事項

  • マネージドスケーリングは、一部の AWS リージョンと Amazon EMR リリースでサポートされています。詳細については、「マネージドスケーリングの提供状況」を参照してください。

  • Amazon EMR Managed Scaling の必須パラメータを設定する必要があります。詳細については、「マネージドスケーリングのパラメータ」を参照してください。

  • マネージドスケーリングを使用するには、metrics-collector プロセスが API Gateway のマネージドスケーリング用のパブリック API エンドポイントに接続できる必要があります。Amazon Virtual Private Cloud でプライベート DNS 名を使用すると、マネージドスケーリングは正しく機能しません。マネージドスケーリングが動作するようにするには、次のアクションのうち 1 つを実行することをお勧めします。

  • スケールダウン中に YARN ジョブが断続的に遅く、YARN リソースマネージャーのログに、その間にほとんどのノードが拒否リストに記載されたことが示された場合は、廃止タイムアウトしきい値を調整できます。

    spark.blacklist.decommissioning.timeout を 1 時間から 1 分に減らして、他の保留中のコンテナがタスク処理の続行にノードを使用できるようにします。

    最長の「Spark タスク」がノード上でまだ実行されている間に、Amazon EMR がノードを強制終了しないように、YARN.resourcemanager.nodemanager-graceful-decommission-timeout-secs もより大きな値に設定する必要があります。現在のデフォルトは 60 分です。つまり、YARN は、ノードが廃止状態になってから 60 分後にコンテナを強制終了します。

    以下は YARN リソースマネージャーログの行の例で、ノードが廃止状態に追加されたことを示しています。

    2021-10-20 15:55:26,994 INFO org.apache.hadoop.YARN.server.resourcemanager.DefaultAMSProcessor (IPC Server handler 37 on default port 8030): blacklist are updated in Scheduler.blacklistAdditions: [ip-10-10-27-207.us-west-2.compute.internal, ip-10-10-29-216.us-west-2.compute.internal, ip-10-10-31-13.us-west-2.compute.internal, ... , ip-10-10-30-77.us-west-2.compute.internal], blacklistRemovals: []

    Amazon EMR がノードの廃止時に YARN の拒否リストと連携する方法、Amazon EMR のノードが拒否リストに追加されるケース、Spark ノードの廃止動作の設定について詳細を確認してください。

  • EBS ボリュームの使用率が高すぎると、マネージドスケーリングの問題が発生する可能性があります。EBS ボリュームの使用率を 90% 未満にすることをお勧めします。詳細については、「インスタンスストレージ」を参照してください。

  • Amazon CloudWatch メトリクスは、Amazon EMR マネージドスケーリングの運用に不可欠です。Amazon CloudWatch メトリクスを注意深く監視して、データが欠落していないことを確認することをお勧めします。欠落しているメトリクスを検出するように CloudWatch アラームを設定する方法の詳細については、「Amazon CloudWatch でのアラームの使用」を参照してください。

  • Presto がインストールされていない 5.30.0 クラスターおよび 5.30.1 クラスターでマネージドスケーリング操作を実行すると、特にスケールダウン操作の後にすぐ、スケールアップ操作が実行されたときに、アプリケーション障害が発生するか、ユニフォームインスタンスグループまたはインスタンスフリートが ARRESTED 状態のままになる場合があります。

    回避策として、ジョブに Presto が必要ない場合でも、Amazon EMR リリース 5.30.0 および 5.30.1 を使用してクラスターを作成するときに、インストールするアプリケーションとして Presto を選択します。

  • Amazon EMR Managed Scaling の最大コアノードとオンデマンド制限を設定するときは、インスタンスグループとインスタンスフリートの違いを考慮してください。各インスタンスグループは、オンデマンドインスタンスとスポットインスタンスに対して、同じインスタンスタイプと同じ購入オプションで構成されています。各インスタンスフリートについては、オンデマンドインスタンスとスポットインスタンスとしてプロビジョニングできる 5 つのインスタンスタイプを指定できます。詳細については、「インスタンスフリートまたはユニフォームインスタンスグループを使用してクラスターを作成する」、「インスタンスフリートオプション」、および「ノード割り当てシナリオ」を参照してください。

  • Amazon EMR 5.30.0 以降で、マスターセキュリティグループのデフォルトの [すべて許可] アウトバウンドルールを削除して 0.0.0.0/ にした場合、サービスアクセス用のセキュリティグループへのアウトバウンド TCP 接続をポート 9443 で許可するルールを追加する必要があります。サービスアクセス用のセキュリティグループで、マスターセキュリティグループからのインバウンド TCP トラフィックをポート 9443 で許可する必要もあります。セキュリティグループの設定の詳細については、「Amazon EMR-managed security group for the primary instance (private subnets))」を参照してください。

  • マネージドスケーリングは YARN ノードラベル 機能をサポートしていません。マネージドスケーリングを使用するクラスターではノードラベルを使用しないでください。例えば、エグゼキューターをタスクノードでのみ実行できるようにしないでください。Amazon EMR クラスターでノードラベルを使用すると、クラスターがスケールアップされず、アプリケーションが遅くなる可能性があります。

  • AWS CloudFormation を使用して Amazon EMR Managed Scaling を設定できます。詳細については、「AWS CloudFormation ユーザーガイド」の「AWS::EMR::Cluster」を参照してください。

機能履歴

この表に、Amazon EMR Managed Scaling 機能の更新を示します。

リリース日 機能 Amazon EMR のバージョン
2023 年 10 月 10 日 マネージドスケーリングが ap-southeast-3 アジアパシフィック (ジャカルタ) リージョンで利用可能になりました。 6.14.0 以降
2023 年 7 月 28 日 マネージドスケーリングが強化され、Amazon EMR で現在のインスタンスグループでスケールアップに遅延が生じた場合、スケールアップ時に別のタスクインスタンスグループに切り替わるようになりました。 5.34.0 以降、6.4.0 以降
2023 年 6 月 16 日 マネージドスケーリングが強化され、アプリケーションマスターを実行しているノードを認識し、そのノードがスケールダウンされないようになりました。詳細については、「ノード割り当て戦略とシナリオを把握する」を参照してください。 5.34.0 以降、6.4.0 以降
2022 年 3 月 21 日 クラスターのスケールダウン時に使用される Spark シャッフルデータの認識機能が追加されました。Apache Spark とマネージドスケーリング機能が有効になっている Amazon EMR クラスターの場合、Amazon EMR は Spark エグゼキューターと中間シャッフルデータのロケーションを継続的にモニタリングします。Amazon EMR はこの情報を使用して、使用率の高いシャッフルデータを含まない、使用率の低いインスタンスのみをスケールダウンします。これにより、損失したシャッフルデータの再計算が発生しなくなり、コスト削減とジョブパフォーマンスの向上につながります。詳細については、Spark のプログラミングガイドを参照してください。 5.34.0 以降、6.4.0 以降