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

以下では AWS リージョン、Amazon EMR マネージドスケーリングは Amazon EMR 6.14.0 以降で使用できます。

以下では AWS リージョン、Amazon EMR マネージドスケーリングは Amazon EMR 5.30.0 および 6.1.0 以降で使用できます。

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

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

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

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

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

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

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

マネージドスケーリングを使用するには、metrics-collector プロセスが API Gateway のマネージドスケーリング用のパブリック API エンドポイントに接続できる必要があります。でプライベート DNS 名を使用すると Amazon Virtual Private Cloud、マネージドスケーリングは正しく機能しません。マネージドスケーリングが動作するようにするには、次のアクションのうち 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 EMR でのインスタンスストレージのオプションと動作」を参照してください。

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))」を参照してください。

AWS CloudFormation を使用して Amazon EMR マネージドスケーリングを設定できます。詳細については、「AWS CloudFormation ユーザーガイド」の「AWS::EMR::Cluster」を参照してください。

スポットノードを使用している場合は、Amazon EMR がスポットノードを削除するときに Amazon EMR がアプリケーションプロセスを削除しないように、ノードラベルの使用を検討してください。ノードラベルの詳細については、「Task nodes」を参照してください。

Amazon EMR リリース 6.15 以前では、ノードラベル付けはデフォルトではサポートされていません。詳細については、「Understand node types: primary, core, and task nodes」を参照してください。

Amazon EMR リリース 6.15 以前を使用している場合は、コアノードやタスクノードなどのノードタイプごとにのみノードラベルを割り当てることができます。ただし、Amazon EMR リリース 7.0 以降を使用している場合は、オンデマンドやスポットなどのノードタイプと市場タイプ別にノードラベルを設定できます。

アプリケーションプロセスをコアノードに制限すると、アプリケーションプロセスの需要が増加し、エグゼキュターの需要が減少した場合、同じサイズ変更オペレーションでコアノードをバックに追加し、タスクノードを削除できます。詳細については、「Understanding node allocation strategy and scenarios」を参照してください。

Amazon EMR はタスクノードにラベル付けしないため、YARN プロパティを設定して、タスクノードのみのアプリケーションプロセスを制限することはできません。ただし、市場タイプをノードラベルとして使用する場合は、アプリケーションプロセス配置に ON_DEMAND または SPOT ラベルを使用できます。アプリケーションのプライマリプロセスにスポットノードを使用することはお勧めしません。

ノードラベルを使用する場合、Amazon EMR が一部のインスタンスを廃止している間、クラスターで実行されているユニットの合計が、マネージドスケーリングポリシーで設定された最大コンピューティングセットを一時的に超える可能性があります。リクエストされたユニットの合計は、常にポリシーの最大コンピューティング以下にとどまります。

マネージドスケーリングは、ノードラベル ON_DEMAND と SPOT または CORE と TASK のみをサポートします。カスタムノードラベルはサポートされていません。

Amazon EMR は、クラスターの作成時とリソースのプロビジョニング時にノードラベルを作成します。Amazon EMR は、クラスターを再設定するときにノードラベルの追加をサポートしていません。また、クラスターの起動後にマネージドスケーリングを設定するときにノードラベルを変更することはできません。

マネージドスケーリングは、アプリケーションプロセスとエグゼキュターの需要に基づいてコアノードとタスクノードを個別にスケーリングします。コアスケールダウン中の HDFS データ損失の問題を回避するには、コアノードの標準プラクティスに従います。コアノードと HDFS レプリケーションに関するベストプラクティスの詳細については、「Considerations and best practices」を参照してください。

アプリケーションプロセスとエグゼキュターの両方を core または ON_DEMAND ノードにのみ配置することはできません。いずれかのノードにアプリケーションプロセスとエグゼキュターの両方を追加する場合は、yarn.node-labels.am.default-node-label-expression 設定を使用しないでください。

例えば、アプリケーションプロセスとエグゼキュターの両方を ON_DEMAND ノードに配置するには、最大コンピューティングを ON_DEMAND ノードの最大値と同じに設定します。また、yarn.node-labels.am.default-node-label-expression 設定を削除します。

アプリケーションプロセスとエグゼキュターの両方を core ノードに追加するには、yarn.node-labels.am.default-node-label-expression 設定を削除します。

ノードラベルでマネージドスケーリングを使用する場合は、複数のアプリケーションを並行して実行する予定がある場合は、yarn.scheduler.capacity.maximum-am-resource-percent: 1 プロパティを設定します。これにより、アプリケーションプロセスで使用可能な CORE または ON_DEMAND ノードが完全に利用されます。

ノードラベルでマネージドスケーリングを使用する場合は、yarn.resourcemanager.decommissioning.timeout プロパティをクラスターで実行されているアプリケーションよりも長い値に設定します。これにより、Amazon EMR マネージドスケーリングがアプリケーションを再スケジュールして、CORE または ON_DEMAND ノードをリコミッションする必要が生じる可能性が低くなります。