翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon EMR でマネージドスケーリングを使用する
**重要**
マネージドスケーリングには、最新の Amazon EMR リリース (Amazon EMR 7.13.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 以降でこの問題を解決しました。リージョンと提供リリースの詳細については、「[マネージドスケーリングの提供状況](#emr-managed-scaling-availability)」を参照してください。
## 概要
Amazon EMR バージョン 5.30.0 以降 (Amazon EMR 6.0.0 を除く) では、Amazon EMR Managed Scaling を有効にできます。マネージドスケーリングを使用すると、ワークロードに基づいてクラスター内のインスタンスやユニットの数を自動的に増減できます。Amazon EMR は引き続きクラスターのメトリクスを評価し、クラスターのコストと速度を最適化するためのスケーリングを決定します。マネージドスケーリングは、インスタンスグループとインスタンスフリートのいずれかで構成されるクラスターで使用できます。
## マネージドスケーリングの提供状況
+ 以下では AWS リージョン、Amazon EMR マネージドスケーリングは Amazon EMR 6.14.0 以降で使用できます。
+ アジアパシフィック (台北) (ap-east-2)
+ アジアパシフィック (メルボルン) (ap-southeast-4)
+ アジアパシフィック (マレーシア) (ap-southeast-5)
+ アジアパシフィック (ニュージーランド) (ap-southeast-6)
+ アジアパシフィック (タイ) (ap-southeast-7)
+ カナダ西部 (カルガリー) (ca-west-1)
+ 欧州 (スペイン) (eu-south-2)
+ メキシコ (中部) (mx-central-1)
+ 以下では AWS リージョン、Amazon EMR マネージドスケーリングは Amazon EMR 5.30.0 および 6.1.0 以降で使用できます。
+ 米国東部 (バージニア北部) (us-east-1)
+ 米国東部 (オハイオ) (us-east-2)
+ 米国西部 (オレゴン) (us-west-2)
+ 米国西部 (北カリフォルニア) (us-west-1)
+ アフリカ (ケープタウン) (af-south-1)
+ アジアパシフィック (香港) (ap-east-1)
+ アジアパシフィック (ムンバイ) (ap-south-1)
+ アジアパシフィック (ハイデラバード) (ap-south-2)
+ アジアパシフィック (ソウル) (ap-northeast-2)
+ アジアパシフィック (シンガポール) (ap-southeast-1)
+ アジアパシフィック (シドニー) (ap-southeast-2)
+ アジアパシフィック (ジャカルタ) (ap-southeast-3)
+ アジアパシフィック (東京) (ap-northeast-1)
+ アジアパシフィック (大阪) (ap-northeast-3)
+ カナダ (中部) (ca-central-1)
+ 南米 (サンパウロ) (sa-east-1)
+ ヨーロッパ (フランクフルト) (eu-central-1)
+ 欧州 (チューリッヒ) (eu-central-2)
+ 欧州 (アイルランド) (eu-west-1)
+ ヨーロッパ (ロンドン) (eu-west-2)
+ 欧州 (ミラノ) (eu-south-1)
+ 欧州 (パリ) (eu-west-3)
+ 欧州 (ストックホルム) (eu-north-1)
+ イスラエル (テルアビブ) (il-central-1)
+ 中東 (UAE) (me-central-1)
+ 中国 (北京) (cn-north-1)
+ 中国 (寧夏) (cn-northwest-1)
+ AWS GovCloud (米国東部) (us-gov-east-1)
+ AWS GovCloud (米国西部) (us-gov-west-1)
+ 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 のオンデマンドインスタンスにスケールアップし、残りの容量をスポットインスタンスに割り当てます。詳細については、「[ノード割り当てシナリオ](managed-scaling-allocation-strategy.md#node-allocation-scenarios)」を参照してください。
+ **最大コアノード**(`MaximumCoreCapacityUnits`) (オプション) — クラスターのコアノードタイプに許可される EC2 キャパシティの上限。このパラメータが指定されていない場合、デフォルトは `MaximumCapacityUnits` の値になります。
+ このパラメータは、コアノードとタスクノードの間で容量割り当てを分割するために使用します。例えば、最小パラメータを 2 インスタンス、最大を 100 インスタンス、最大コアノードを 17 インスタンスに設定した場合、Amazon EMR Managed Scaling は最大 17 のコアノードにスケールアップし、残りの 83 インスタンスをタスクノードに割り当てます。詳細については、「[ノード割り当てシナリオ](managed-scaling-allocation-strategy.md#node-allocation-scenarios)」を参照してください。
マネージドスケーリングパラメータの詳細については、「[https://docs.aws.amazon.com/emr/latest/APIReference/API_ComputeLimits.html](https://docs.aws.amazon.com/emr/latest/APIReference/API_ComputeLimits.html)」を参照してください。
## Amazon EMR Managed Scaling に関する考慮事項
+ マネージドスケーリングは、制限付きリリース AWS リージョン と Amazon EMR リリースでサポートされています。詳細については、「[マネージドスケーリングの提供状況](#emr-managed-scaling-availability)」を参照してください。
+ Amazon EMR Managed Scaling の必須パラメータを設定する必要があります。詳細については、「[マネージドスケーリングのパラメータ](#emr-managed-scaling-parameters)」を参照してください。
+ マネージドスケーリングを使用するには、metrics-collector プロセスが API Gateway のマネージドスケーリング用のパブリック API エンドポイントに接続できる必要があります。でプライベート DNS 名を使用する場合 Amazon Virtual Private Cloud、マネージドスケーリングは正しく機能しません。マネージドスケーリングが動作するようにするには、次のアクションのうち 1 つを実行することをお勧めします。
+ Amazon VPC から API Gateway のインターフェイス VPC エンドポイントを削除します。
+ 「[VPC から API Gateway API に接続するときに「HTTP 403 Forbidden」エラーが発生するのはなぜですか?](https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-vpc-connections/)」の手順に従い、プライベート DNS 名の設定を無効にします。
+ 代わりに、クラスターをプライベートサブネットで起動します。詳細については、「[プライベートサブネット](emr-clusters-in-a-vpc.md#emr-vpc-private-subnet)」のトピックを参照してください。
+ スケールダウン中に 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 の拒否リストと連携する方法](https://aws.amazon.com/blogs/big-data/spark-enhancements-for-elasticity-and-resiliency-on-amazon-emr/)、[Amazon EMR のノードが拒否リストに追加されるケース](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-troubleshoot-error-resource-3.html)、[Spark ノードの廃止動作の設定](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-configure.html#spark-decommissioning)について詳細を確認してください。
+ Spark ワークロードの場合、Spark プロパティ **spark.dynamicAllocation.enabled** を `FALSE` に変更して Spark Dynamic Resource Allocator (DRA) を無効にすることにより、マネージドスケーリングの問題が発生する可能性があります。この場合、クラスターはワークロードに必要な数を超えてスケールアップできます (最大コンピューティングまで)。これらのワークロードで Managed Scaling を使用する場合は、Spark DRA を有効にしておくことをお勧めします。これは、このプロパティのデフォルト状態です。
+ EBS ボリュームの使用率が高すぎると、マネージドスケーリングの問題が発生する可能性があります。EBS ボリュームの使用率を 90% 未満にすることをお勧めします。詳細については、「[Amazon EMR でのインスタンスストレージのオプションと動作](emr-plan-storage.md)」を参照してください。
+ Amazon CloudWatch メトリクスは、Amazon EMR マネージドスケーリングの運用に不可欠です。Amazon CloudWatch メトリクスを注意深く監視して、データが欠落していないことを確認することをお勧めします。欠落しているメトリクスを検出するように CloudWatch アラームを設定する方法の詳細については、「[Amazon CloudWatch でのアラームの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)」を参照してください。
+ Presto がインストールされていない 5.30.0 クラスターおよび 5.30.1 クラスターでマネージドスケーリング操作を実行すると、特にスケールダウン操作の後にすぐ、スケールアップ操作が実行されたときに、アプリケーション障害が発生するか、ユニフォームインスタンスグループまたはインスタンスフリートが `ARRESTED` 状態のままになる場合があります。
回避策として、ジョブに Presto が必要ない場合でも、Amazon EMR リリース 5.30.0 および 5.30.1 を使用してクラスターを作成するときに、インストールするアプリケーションとして Presto を選択します。
+ Amazon EMR Managed Scaling の最大コアノードとオンデマンド制限を設定するときは、インスタンスグループとインスタンスフリートの違いを考慮してください。各インスタンスグループは、オンデマンドインスタンスとスポットインスタンスに対して、同じインスタンスタイプと同じ購入オプションで構成されています。各インスタンスフリートについては、オンデマンドインスタンスとスポットインスタンスとしてプロビジョニングできる 5 つのインスタンスタイプを指定できます。詳細については、「[インスタンスフリートまたはユニフォームインスタンスグループを使用してクラスターを作成する](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-instance-group-configuration.html)」、「[インスタンスフリートオプション](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-instance-fleet.html#emr-instance-fleet-options)」、および「[ノード割り当てシナリオ](managed-scaling-allocation-strategy.md#node-allocation-scenarios)」を参照してください。
+ Amazon EMR 5.30.0 以降で、マスターセキュリティグループのデフォルトの **[すべて許可]** アウトバウンドルールを削除して 0.0.0.0/ にした場合、サービスアクセス用のセキュリティグループへのアウトバウンド TCP 接続をポート 9443 で許可するルールを追加する必要があります。サービスアクセス用のセキュリティグループで、マスターセキュリティグループからのインバウンド TCP トラフィックをポート 9443 で許可する必要もあります。セキュリティグループの設定の詳細については、「[Amazon EMR-managed security group for the primary instance (private subnets)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-man-sec-groups.html#emr-sg-elasticmapreduce-master-private))」を参照してください。
+ AWS CloudFormation を使用して Amazon EMR マネージドスケーリングを設定できます。詳細については、「*AWS CloudFormation ユーザーガイド*」の「[AWS::EMR::Cluster](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticmapreduce-cluster.html)」を参照してください。
+ スポットノードを使用している場合は、Amazon EMR がスポットノードを削除するときに Amazon EMR がアプリケーションプロセスを削除しないように、ノードラベルの使用を検討してください。ノードラベルの詳細については、「[Task nodes](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-master-core-task-nodes.html#emr-plan-task)」を参照してください。
+ Amazon EMR リリース 6.15 以前では、ノードラベル付けはデフォルトではサポートされていません。詳細については、「[Understand node types: primary, core, and task nodes](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-master-core-task-nodes.html)」を参照してください。
+ Amazon EMR リリース 6.15 以前を使用している場合は、コアノードやタスクノードなどのノードタイプごとにのみノードラベルを割り当てることができます。ただし、Amazon EMR リリース 7.0 以降を使用している場合は、オンデマンドやスポットなどのノードタイプと市場タイプ別にノードラベルを設定できます。
+ アプリケーションプロセスをコアノードに制限すると、アプリケーションプロセスの需要が増加し、エグゼキュターの需要が減少した場合、同じサイズ変更オペレーションでコアノードをバックに追加し、タスクノードを削除できます。詳細については、「[Understanding node allocation strategy and scenarios](https://docs.aws.amazon.com/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)」を参照してください。
+ Amazon EMR はタスクノードにラベル付けしないため、YARN プロパティを設定して、タスクノードのみのアプリケーションプロセスを制限することはできません。ただし、市場タイプをノードラベルとして使用する場合は、アプリケーションプロセス配置に `ON_DEMAND` または `SPOT` ラベルを使用できます。アプリケーションのプライマリプロセスにスポットノードを使用することはお勧めしません。
+ ノードラベルを使用する場合、Amazon EMR が一部のインスタンスを廃止している間、クラスターで実行されているユニットの合計が、マネージドスケーリングポリシーで設定された最大コンピューティングセットを一時的に超える可能性があります。リクエストされたユニットの合計は、常にポリシーの最大コンピューティング以下にとどまります。
+ マネージドスケーリングは、ノードラベル `ON_DEMAND` と `SPOT` または `CORE` と `TASK` のみをサポートします。カスタムノードラベルはサポートされていません。
+ Amazon EMR は、クラスターの作成時とリソースのプロビジョニング時にノードラベルを作成します。Amazon EMR は、クラスターを再設定するときにノードラベルの追加をサポートしていません。また、クラスターの起動後にマネージドスケーリングを設定するときにノードラベルを変更することはできません。
+ マネージドスケーリングは、アプリケーションプロセスとエグゼキュターの需要に基づいてコアノードとタスクノードを個別にスケーリングします。コアスケールダウン中の HDFS データ損失の問題を回避するには、コアノードの標準プラクティスに従います。コアノードと HDFS レプリケーションに関するベストプラクティスの詳細については、「[Considerations and best practices](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-considerations.html)」を参照してください。
+ アプリケーションプロセスとエグゼキュターの両方を `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` ノードをリコミッションする必要が生じる可能性が低くなります。
+ シャッフルデータ損失によるアプリケーション障害のリスクを軽減するために、Amazon EMR はクラスターからメトリクスを収集し、現在および以前のステージの既存の一時的なシャッフルデータがあるノードを決定します。まれに、メトリクスは、すでに完了または終了したアプリケーションの古いデータを引き続き報告できます。これは、クラスター内のインスタンスのタイムリーなスケールダウンに影響を与える可能性があります。大量のシャッフルデータを持つクラスターの場合は、EMR バージョン 6.13 以降の使用を検討してください。
## 機能履歴
この表に、Amazon EMR Managed Scaling 機能の更新を示します。
| リリース日 | 機能 | Amazon EMR のバージョン |
| --- | --- | --- |
| 2024 年 11 月 20 日 | マネージドスケーリングは、il-central-1 イスラエル (テルアビブ)、me-central-1 中東 (UAE)、ap-northeast-3 アジアパシフィック (大阪)の各リージョンで利用できます。 | 5.30.0 および 6.1.0 以上 |
| 2024 年 11 月 15 日 | マネージドスケーリングが、eu-central-2 欧州 (チューリッヒ) リージョンで利用可能になりました。 | 5.30.0 および 6.1.0 以上 |
| 2024 年 8 月 20 日 | ノードラベルがマネージドスケーリングで使用できるようになりました。これにより、市場タイプまたはノードタイプに基づいてインスタンスにラベル付けして、自動スケーリングを改善できます。 | 7.2.0 以上 |
| 2024 年 3 月 31 日 | マネージドスケーリングが ap-south-2 アジアパシフィック (ハイデラバード) リージョンで利用可能になりました。 | 6.14.0 以降 |
| 2024 年 2 月 13 日 | マネージドスケーリングが、eu-south-2 欧州 (スペイン) リージョンで利用可能になりました。 | 6.14.0 以降 |
| 2023 年 10 月 10 日 | マネージドスケーリングが ap-southeast-3 アジアパシフィック (ジャカルタ) リージョンで利用可能になりました。 | 6.14.0 以降 |
| 2023 年 7 月 28 日 | マネージドスケーリングが強化され、Amazon EMR で現在のインスタンスグループでスケールアップに遅延が生じた場合、スケールアップ時に別のタスクインスタンスグループに切り替わるようになりました。 | 5.34.0 以降、6.4.0 以降 |
| 2023 年 6 月 16 日 | マネージドスケーリングが強化され、アプリケーションマスターを実行しているノードを認識し、そのノードがスケールダウンされないようになりました。詳細については、「[Amazon EMR ノード割り当て戦略とシナリオを把握する](managed-scaling-allocation-strategy.md)」を参照してください。 | 5.34.0 以降、6.4.0 以降 |
| 2022 年 3 月 21 日 | クラスターのスケールダウン時に使用される Spark シャッフルデータの認識機能が追加されました。Apache Spark とマネージドスケーリング機能が有効になっている Amazon EMR クラスターの場合、Amazon EMR は Spark エグゼキューターと中間シャッフルデータのロケーションを継続的にモニタリングします。Amazon EMR はこの情報を使用して、使用率の高いシャッフルデータを含まない、使用率の低いインスタンスのみをスケールダウンします。これにより、損失したシャッフルデータの再計算が発生しなくなり、コスト削減とジョブパフォーマンスの向上につながります。詳細については、[Spark のプログラミングガイド](https://spark.apache.org/docs/latest/rdd-programming-guide.html#shuffle-operations)を参照してください。 | 5.34.0 以降、6.4.0 以降 |