翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon EMR クラスタースケーリングを使用してワークロードの変化に適応する
需要が変動するワークロードに応じて、Amazon EMR クラスターで使用できる Amazon EC2 インスタンスの数を自動または手動で調整できます。自動スケーリングを使用するには、2 つのオプションがあります。Amazon EMR Managed Scaling を有効にすることも、カスタムの自動スケーリングポリシーを作成することもできます。以下の表では、2 つのオプションの違いについて説明しています。
| | Amazon EMR Managed Scaling | カスタム自動スケーリング |
| --- | --- | --- |
| スケーリングポリシーとルール | ポリシーは必要ありません。Amazon EMR は、クラスターメトリクスを継続的に評価し、最適化されたスケーリング決定を行うことにより、自動スケーリングアクティビティを管理します。 | スケーリングアクティビティ、評価期間、クールダウン期間をトリガーする特定の条件などの、自動スケーリングポリシーとルールを定義して管理する必要があります。 |
| サポートされている Amazon EMR リリース | Amazon EMR バージョン 5.30.0 以降 (Amazon EMR バージョン 6.0.0 を除く) | Amazon EMR バージョン 4.0.0 以降 |
| サポートされているクラスター構成 | インスタンスグループまたはインスタンスフリート | インスタンスグループのみ |
| スケーリング制限の設定 | スケーリング制限は、クラスター全体に対して設定されます。 | スケーリング制限は、各インスタンスグループに対してのみ設定できます。 |
| メトリクス評価頻度 | 5 ～ 10秒ごと メトリクスの評価を頻繁に行うことで、Amazon EMR によるスケーリング決定の精度が高くなります。 | 評価期間は 5 分単位でのみ定義できます。 |
| サポートされているアプリケーション | Spark、Hadoop、Hive、Flink などの YARN アプリケーションのみがサポートされています。Amazon EMR Managed Scaling は、Presto や HBase などの YARN に基づいていないアプリケーションをサポートしていません。 | 自動スケーリングルールを定義するときに、サポート対象とするアプリケーションを選択できます。 |
## 考慮事項
+ Amazon EMR クラスターは、常に 1 つまたは 3 つのプライマリノードで構成されます。クラスターを最初に設定すると、コアノードとタスクノードのみをスケールできます。クラスターのプライマリノードの数をスケールすることはできません。
+ インスタンスグループの場合、再設定操作とサイズ変更操作は同時ではなく順番に行われます。インスタンスグループのサイズ変更中に再設定を開始すると、インスタンスグループで実行中のサイズ変更が完了次第、再設定が開始されます。逆に、インスタンスグループが再設定でビジー状態のときにサイズ変更オペレーションを開始することにより、再設定が完了するとサイズ変更が開始されます。
# Amazon EMR でマネージドスケーリングを使用する
**重要**
マネージドスケーリングには、最新の Amazon EMR リリース (Amazon EMR 7.12.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 以降 |
# Amazon EMR のマネージドスケーリングを設定する
以下のセクションでは、 AWS マネジメントコンソール、、 AWS SDK for Javaまたは でマネージドスケーリングを使用する EMR クラスターを起動する方法について説明します AWS Command Line Interface。
**Topics**
+ [AWS マネジメントコンソール を使用してマネージドスケーリングを設定する](#managed-scaling-console)
+ [AWS CLI を使用してマネージドスケーリングを設定する](#managed-scaling-cli)
+ [AWS SDK for Java を使用してマネージドスケーリングを設定する](#managed-scaling-sdk)
## AWS マネジメントコンソール を使用してマネージドスケーリングを設定する
Amazon EMR コンソールを使用して、クラスターの作成時にマネージドスケーリングを設定したり、実行中のクラスターのマネージドスケーリングポリシーを変更したりできます。
------
#### [ Console ]
**コンソールを使用して、クラスターの作成時にマネージドスケーリングを設定するには**
1. にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr) で Amazon EMR コンソールを開きます。
1. 左側のナビゲーションペインの **[EMR on EC2]** で、**[クラスター]** を選択し、**[クラスターの作成]** を選択します
1. Amazon EMR リリース **[emr-5.30.0]** 以降を選択します。ただし、バージョン **[emr-6.0.0]** は除きます。
1. **[クラスターのスケーリングとプロビジョニングのオプション]** で **[EMR マネージドスケーリングを使用]** を選択します。インスタンスの **[最小]** 数と **[最大]** 数、**[最大コアノード]** インスタンス、**[最大オンデマンド]** インスタンスを指定します。
1. クラスターに適用するその他のオプションを選択します。
1. クラスターを起動するには、**[クラスターの作成]** を選択します。
**コンソールを使用して既存のクラスターにマネージドスケーリングを設定するには**
1. にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr) で Amazon EMR コンソールを開きます。
1. 左側のナビゲーションペインの **[EMR on EC2]** で **[クラスター]** を選択し、更新するクラスターを選択します。
1. クラスターの詳細ページの **[インスタンス]** タブで、**[インスタンスグループ設定]** セクションを見つけます。**[クラスタースケーリングを編集]** を選択し、インスタンスの **[最小]** 数と **[最大]** 数、および **[オンデマンド]** 制限に新しい値を指定します。
------
## AWS CLI を使用してマネージドスケーリングを設定する
Amazon EMR の AWS CLI コマンドを使用して、クラスターの作成時にマネージドスケーリングを設定できます。短縮構文を使用して、関連コマンドのインラインで JSON 設定を指定したり、設定 JSON を含むファイルを参照したりできます。また、既存のクラスターにマネージドスケーリングポリシーを適用して、以前に適用したマネージドスケーリングポリシーを削除することもできます。さらに、スケーリングポリシーの詳細設定を実行中のクラスターから取得できます。
**クラスター起動時にマネージドスケーリングを有効化する**
マネージドスケーリングは、次の例で示すように、クラスターの起動時に有効にできます。
```
aws emr create-cluster \
--service-role EMR_DefaultRole \
--release-label emr-7.12.0 \
--name EMR_Managed_Scaling_Enabled_Cluster \
--applications Name=Spark Name=Hbase \
--ec2-attributes KeyName=keyName,InstanceProfile=EMR_EC2_DefaultRole \
--instance-groups InstanceType=m4.xlarge,InstanceGroupType=MASTER,InstanceCount=1 InstanceType=m4.xlarge,InstanceGroupType=CORE,InstanceCount=2 \
--region us-east-1 \
--managed-scaling-policy ComputeLimits='{MinimumCapacityUnits=2,MaximumCapacityUnits=4,UnitType=Instances}'
```
`create-cluster` を使用する場合は、--managed-scaling-policy オプションを使用して、マネージドポリシー設定を指定することもできます。
**既存のクラスターへのマネージドスケーリングポリシーの適用**
マネージドスケーリングポリシーは、次の例で示すように、既存のクラスターに適用できます。
```
aws emr put-managed-scaling-policy
--cluster-id j-123456
--managed-scaling-policy ComputeLimits='{MinimumCapacityUnits=1,
MaximumCapacityUnits=10, MaximumOnDemandCapacityUnits=10, UnitType=Instances}'
```
`aws emr put-managed-scaling-policy` コマンドを使用して、マネージドスケーリングポリシーを既存のクラスターに適用することもできます。次の例では、マネージドスケーリングポリシー設定を指定する JSON ファイル `managedscaleconfig.json` への参照を使用します。
```
aws emr put-managed-scaling-policy --cluster-id j-123456 --managed-scaling-policy file://./managedscaleconfig.json
```
次の例は、マネージドスケーリングポリシーを定義する `managedscaleconfig.json` ファイルの内容を示しています。
```
{
"ComputeLimits": {
"UnitType": "Instances",
"MinimumCapacityUnits": 1,
"MaximumCapacityUnits": 10,
"MaximumOnDemandCapacityUnits": 10
}
}
```
**マネージドスケーリングポリシー設定の取得**
`GetManagedScalingPolicy` コマンドを使用すると、ポリシー設定を取得できます。たとえば、次のコマンドは、クラスター ID `j-123456` を持つクラスターの設定を取得します。
```
aws emr get-managed-scaling-policy --cluster-id j-123456
```
このコマンドでは、次のサンプルアウトプットが生成されます。
```
1. {
2. "ManagedScalingPolicy": {
3. "ComputeLimits": {
4. "MinimumCapacityUnits": 1,
5. "MaximumOnDemandCapacityUnits": 10,
6. "MaximumCapacityUnits": 10,
7. "UnitType": "Instances"
8. }
9. }
10. }
```
での Amazon EMR コマンドの使用の詳細については AWS CLI、「」を参照してください[https://docs.aws.amazon.com/cli/latest/reference/emr](https://docs.aws.amazon.com/cli/latest/reference/emr)。
**マネージドスケーリングポリシーの削除**
`RemoveManagedScalingPolicy` コマンドを使用すると、ポリシー設定を削除できます。たとえば、次のコマンドでは、クラスター ID `j-123456` を持つクラスターの設定を削除します。
```
aws emr remove-managed-scaling-policy --cluster-id j-123456
```
## AWS SDK for Java を使用してマネージドスケーリングを設定する
以下のプログラム抜粋では、 AWS SDK for Javaを使用してマネージドスケーリングを設定する方法を示します。
```
package com.amazonaws.emr.sample;
import java.util.ArrayList;
import java.util.List;
import com.amazonaws.AmazonClientException;
import com.amazonaws.auth.AWSCredentials;
import com.amazonaws.auth.AWSStaticCredentialsProvider;
import com.amazonaws.auth.profile.ProfileCredentialsProvider;
import com.amazonaws.regions.Regions;
import com.amazonaws.services.elasticmapreduce.AmazonElasticMapReduce;
import com.amazonaws.services.elasticmapreduce.AmazonElasticMapReduceClientBuilder;
import com.amazonaws.services.elasticmapreduce.model.Application;
import com.amazonaws.services.elasticmapreduce.model.ComputeLimits;
import com.amazonaws.services.elasticmapreduce.model.ComputeLimitsUnitType;
import com.amazonaws.services.elasticmapreduce.model.InstanceGroupConfig;
import com.amazonaws.services.elasticmapreduce.model.JobFlowInstancesConfig;
import com.amazonaws.services.elasticmapreduce.model.ManagedScalingPolicy;
import com.amazonaws.services.elasticmapreduce.model.RunJobFlowRequest;
import com.amazonaws.services.elasticmapreduce.model.RunJobFlowResult;
public class CreateClusterWithManagedScalingWithIG {
public static void main(String[] args) {
AWSCredentials credentialsFromProfile = getCreadentials("AWS-Profile-Name-Here");
/**
* Create an Amazon EMR client with the credentials and region specified in order to create the cluster
*/
AmazonElasticMapReduce emr = AmazonElasticMapReduceClientBuilder.standard()
.withCredentials(new AWSStaticCredentialsProvider(credentialsFromProfile))
.withRegion(Regions.US_EAST_1)
.build();
/**
* Create Instance Groups - Primary, Core, Task
*/
InstanceGroupConfig instanceGroupConfigMaster = new InstanceGroupConfig()
.withInstanceCount(1)
.withInstanceRole("MASTER")
.withInstanceType("m4.large")
.withMarket("ON_DEMAND");
InstanceGroupConfig instanceGroupConfigCore = new InstanceGroupConfig()
.withInstanceCount(4)
.withInstanceRole("CORE")
.withInstanceType("m4.large")
.withMarket("ON_DEMAND");
InstanceGroupConfig instanceGroupConfigTask = new InstanceGroupConfig()
.withInstanceCount(5)
.withInstanceRole("TASK")
.withInstanceType("m4.large")
.withMarket("ON_DEMAND");
List igConfigs = new ArrayList<>();
igConfigs.add(instanceGroupConfigMaster);
igConfigs.add(instanceGroupConfigCore);
igConfigs.add(instanceGroupConfigTask);
/**
* specify applications to be installed and configured when Amazon EMR creates the cluster
*/
Application hive = new Application().withName("Hive");
Application spark = new Application().withName("Spark");
Application ganglia = new Application().withName("Ganglia");
Application zeppelin = new Application().withName("Zeppelin");
/**
* Managed Scaling Configuration -
* Using UnitType=Instances for clusters composed of instance groups
*
* Other options are:
* UnitType = VCPU ( for clusters composed of instance groups)
* UnitType = InstanceFleetUnits ( for clusters composed of instance fleets)
**/
ComputeLimits computeLimits = new ComputeLimits()
.withMinimumCapacityUnits(1)
.withMaximumCapacityUnits(20)
.withUnitType(ComputeLimitsUnitType.Instances);
ManagedScalingPolicy managedScalingPolicy = new ManagedScalingPolicy();
managedScalingPolicy.setComputeLimits(computeLimits);
// create the cluster with a managed scaling policy
RunJobFlowRequest request = new RunJobFlowRequest()
.withName("EMR_Managed_Scaling_TestCluster")
.withReleaseLabel("emr-7.12.0") // Specifies the version label for the Amazon EMR release; we recommend the latest release
.withApplications(hive,spark,ganglia,zeppelin)
.withLogUri("s3://path/to/my/emr/logs") // A URI in S3 for log files is required when debugging is enabled.
.withServiceRole("EMR_DefaultRole") // If you use a custom IAM service role, replace the default role with the custom role.
.withJobFlowRole("EMR_EC2_DefaultRole") // If you use a custom Amazon EMR role for EC2 instance profile, replace the default role with the custom Amazon EMR role.
.withInstances(new JobFlowInstancesConfig().withInstanceGroups(igConfigs)
.withEc2SubnetId("subnet-123456789012345")
.withEc2KeyName("my-ec2-key-name")
.withKeepJobFlowAliveWhenNoSteps(true))
.withManagedScalingPolicy(managedScalingPolicy);
RunJobFlowResult result = emr.runJobFlow(request);
System.out.println("The cluster ID is " + result.toString());
}
public static AWSCredentials getCredentials(String profileName) {
// specifies any named profile in .aws/credentials as the credentials provider
try {
return new ProfileCredentialsProvider("AWS-Profile-Name-Here")
.getCredentials();
} catch (Exception e) {
throw new AmazonClientException(
"Cannot load credentials from .aws/credentials file. " +
"Make sure that the credentials file exists and that the profile name is defined within it.",
e);
}
}
public CreateClusterWithManagedScalingWithIG() { }
}
```
# Amazon EMR の高度なスケーリング
EC2 バージョン 7.0 の Amazon EMR 以降では、Advanced Scaling を活用してクラスターのリソース使用率を制御できます。Advanced Scaling では、ビジネスニーズに応じてリソースの使用率とパフォーマンスレベルを調整するための使用率パフォーマンススケールが導入されています。設定した値は、クラスターの重み付けをリソースの節約にするか、サービスレベルアグリーメント (SLA) の機密性の高いワークロードを処理するためにスケールアップするかを決定します。この場合、迅速な完了が不可欠です。スケーリング値が調整されると、マネージドスケーリングはインテントを解釈し、インテリジェントにスケーリングしてリソースを最適化します。マネージドスケーリングの詳細については、「[Configure managed scaling for Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/managed-scaling-configure.html)」を参照してください。
## 高度なスケーリング設定
高度なスケーリングに設定した値は、クラスターを要件に合わせて最適化します。値の範囲は ****1～**100 です**。指定できる値は **1**、**25**、**50**、**75**、**100** です。インデックスをこれら以外の値に設定することにより、検証エラーが発生します。
スケーリング値はリソース使用率戦略にマッピングされます。以下のリストでは、これらのいくつかを定義します:
+ **使用率最適化 [1]** – この設定により、リソースのオーバープロビジョニングが防止されます。コストを低く抑え、効率的なリソース使用率を優先する場合は、低い値を使用します。これにより、クラスターのスケールアップが遅くなります。これは、ワークロードの急増が定期的に発生しており、リソースの急激な増加を望まない場合のユースケースに適しています。
+ **バランスを取る [50]** – リソース使用率とジョブパフォーマンスのバランスが取れます。この設定は、ほとんどのステージでランタイムが安定している安定したワークロードに適しています。また、実行時間が短いステージと長いステージが混在するワークロードにも適しています。どちらを選択するかわからない場合は、この設定から始めることをお勧めします。
+ **パフォーマンス最適化 [100]** – この戦略はパフォーマンスを優先します。クラスターは積極的にスケールアップされ、ジョブが迅速に完了し、パフォーマンス目標を達成します。パフォーマンス最適化は、高速実行が重要なサービスレベルアグリーメント (SLA) の機密性の高いワークロードに適しています。
**注記**
使用可能な中間値は、クラスターの高度なスケーリング動作を微調整するために、戦略間の中間点を提供します。
## Advanced Scaling の利点
データ量の変更、コストターゲットの調整、SLA 実装など、環境や要件にばらつきがあるので、クラスターのスケーリングは、目標を達成するためにクラスター設定を調整するのに役立ちます。その他の主な利点には以下が含まれます:
+ **きめ細かな制御の強化** – 使用率パフォーマンス設定の導入により、要件に応じてクラスターのスケーリング動作を簡単に調整できます。コンピューティングリソースの需要に合わせてスケールアップすることも、使用パターンに基づいてリソースを節約するためにスケールダウンすることもできます。
+ **コスト最適化の向上** – コスト目標をより簡単に満たす要件に応じて、使用率の低い値を選択できます。
## 最適化の開始方法
**セットアップと設定**
以下のステップを使用してパフォーマンスインデックスを設定し、スケーリング戦略を最適化します。
1. 次のコマンドは、使用率最適化 `[1]` スケーリング戦略を使用して既存のクラスターを更新します。
```
aws emr put-managed-scaling-policy --cluster-id 'cluster-id' \
--managed-scaling-policy '{
"ComputeLimits": {
"UnitType": "Instances",
"MinimumCapacityUnits": 1,
"MaximumCapacityUnits": 2,
"MaximumOnDemandCapacityUnits": 2,
"MaximumCoreCapacityUnits": 2
},
"ScalingStrategy": "ADVANCED",
"UtilizationPerformanceIndex": "1"
}' \
--region "region-name"
```
属性 `ScalingStrategy` と `UtilizationPerformanceIndex` は新しく、スケーリングの最適化に関連しています。マネージドスケーリングポリシーの `UtilizationPerformanceIndex` 属性に対応する値 (1、25、50、75、100) を設定することで、さまざまなスケーリング戦略を選択できます。
1. デフォルトのマネージドスケーリング戦略に戻すには、 属性 `ScalingStrategy` と `UtilizationPerformanceIndex` を含めずに `put-managed-scaling-policy` コマンドを実行します。(これはオプションです。) このサンプルでは、これを行う方法を示します:
```
aws emr put-managed-scaling-policy \
--cluster-id 'cluster-id' \
--managed-scaling-policy '{"ComputeLimits":{"UnitType":"Instances","MinimumCapacityUnits":1,"MaximumCapacityUnits":2,"MaximumOnDemandCapacityUnits":2,"MaximumCoreCapacityUnits":2}}' \
--region "region-name"
```
**モニタリングメトリクスを使用したクラスター使用率の追跡**
EMR バージョン 7.3.0 以降、Amazon EMR はメモリと仮想 CPU に関連する 4 つの新しいメトリクスを公開します。これらを使用して、スケーリング戦略全体でクラスター使用率を測定できます。これらのメトリクスはあらゆるユースケースで使用できますが、ここで提供される詳細を使用して高度なスケーリングをモニタリングできます。
使用できる便利なメトリクスは以下のとおりです:
+ **YarnContainersUsedMemoryGBSeconds** – YARN によって管理されるアプリケーションによって消費されるメモリの量。
+ **YarnContainersTotalMemoryGBSeconds** – クラスター内の YARN に割り当てられた合計メモリ容量。
+ **YarnNodesUsedVCPUSeconds** – YARN によって管理される各アプリケーションの合計 VCPU 秒。
+ **YarnNodesTotalVCPUSeconds** – YARN の準備が整っていない時間枠を含む、消費されたメモリの合計 VCPU 秒数。
Amazon CloudWatch Logs Insights を使用してリソースメトリクスを分析できます。機能には、リソースの使用とスケーリングに固有のメトリクスを抽出するのに役立つ専用のクエリ言語が含まれています。
Amazon CloudWatch コンソールで実行できる次のクエリは、メトリクス計算を使用して、消費メモリ (e2) の実行合計を合計メモリ (e3) の実行合計で割って平均メモリ使用率 (e1) を計算します。
```
{
"metrics": [
[ { "expression": "e2/e3", "label": "Average Mem Utilization", "id": "e1", "yAxis": "right" } ],
[ { "expression": "RUNNING_SUM(m1)", "label": "RunningTotal-YarnContainersUsedMemoryGBSeconds", "id": "e2", "visible": false } ],
[ { "expression": "RUNNING_SUM(m2)", "label": "RunningTotal-YarnContainersTotalMemoryGBSeconds", "id": "e3", "visible": false } ],
[ "AWS_EMR_ManagedResize", "YarnContainersUsedMemoryGBSeconds", "ACCOUNT_ID", "793684541905", "COMPONENT", "ManagerService", "JOB_FLOW_ID", "cluster-id", { "id": "m1", "label": "YarnContainersUsedMemoryGBSeconds" } ],
[ ".", "YarnContainersTotalMemoryGBSeconds", ".", ".", ".", ".", ".", ".", { "id": "m2", "label": "YarnContainersTotalMemoryGBSeconds" } ]
],
"view": "timeSeries",
"stacked": false,
"region": "region",
"period": 60,
"stat": "Sum",
"title": "Memory Utilization"
}
```
ログをクエリするには、 AWS コンソールで CloudWatch を選択します。CloudWatch Logs Insights の詳細については、「Amazon CloudWatch Logs ユーザーガイド」の「[Analyzing log data with CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)」を参照してください。
以下の図は、サンプルクラスターのこれらのメトリクスを示しています:
![\[使用率統計を示すグラフ。\]](http://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/images/scaling_graph_EMR.png)
## 考慮事項と制限事項
+ スケーリング戦略の有効性は、固有のワークロード特性とクラスター設定によって異なります。スケーリング設定を試して、ユースケースに最適なインデックス値を決定することをお勧めします。
+ Amazon EMR の高度なスケーリングは、バッチワークロードに特に適しています。SQL/データウェアハウスおよびストリーミングワークロードの場合、最適なパフォーマンスを得るには、デフォルトのマネージドスケーリング戦略を使用することをお勧めします。
+ Amazon EMR Advanced Scaling は、クラスターでノードラベル設定が有効になっている場合はサポートされていません。クラスター内でアドバンストスケーリングとノードラベル設定の両方が一緒に有効になっている場合、スケーリング動作はデフォルトのマネージドスケーリング設定が有効になっているかのようになります。
+ パフォーマンス最適化スケーリング戦略は、デフォルトのマネージドスケーリング戦略よりも長い期間、高いコンピューティングリソースを維持することで、ジョブの実行を高速化します。このモードでは、リソースの需要に合わせて迅速にスケールアップすることを優先するため、ジョブを迅速に完了できます。これにより、デフォルトの戦略と比較してコストが高くなる可能性があります。
+ クラスターがすでに最適化され、完全に利用されている場合、高度なスケーリングを有効にしても追加の利点が得られない可能性があります。状況によっては、高度なスケーリングを有効にすることにより、ワークロードの実行時間が長くなるため、コストが増加する可能性があります。このような場合は、デフォルトのマネージドスケーリング戦略を使用して、最適なリソース割り当てとコスト効率を確保することをお勧めします。
+ マネージドスケーリングのコンテキストでは、設定がパフォーマンス最適化 [**100**] から使用率最適化 [**1**] に調整されるため、実行時間の経過とともにリソース使用率に重点がシフトします。ただし、ワークロードの性質とクラスターのトポロジによって結果が異なる場合があることに注意してください。ユースケースに最適な結果を得るには、ワークロードでスケーリング戦略をテストして、最適な設定を決定することを強くお勧めします。
+ **PerformanceUtilizationIndex** は、以下の値のみを受け入れます:
+ **1**
+ **25**
+ **50**
+ **75**
+ **100**
他の値を送信することにより、検証エラーが発生します。
# Amazon EMR ノード割り当て戦略とシナリオを把握する
このセクションでは、Amazon EMR Managed Scaling で使用できるノード割り当て戦略と一般的なスケーリングシナリオの概要について説明します。
## ノード割り当て戦略
Amazon EMR Managed Scaling は、次のスケールアップ戦略とスケールダウン戦略に基づいて、コアノードとタスクノードを割り当てます。
**スケールアップ戦略**
+ Amazon EMR リリース 7.2 以降では、マネージドスケーリングが最初にノードラベルとアプリケーションプロセス制限 YARN プロパティに基づいてノードを追加します。
+ Amazon EMR リリース 7.2 以降では、ノードラベルを有効にし、アプリケーションプロセスを `CORE` ノードに制限すると、アプリケーションプロセスの需要が増加し、エグゼキュターの需要が増加すると、Amazon EMR Managed Scaling によってコアノードとタスクノードがスケールアップされます。同様に、ノードラベルを有効にし、アプリケーションプロセスを `ON_DEMAND` ノードに制限すると、マネージドスケーリングではアプリケーションプロセスの需要が増加した場合にオンデマンドノードをスケールアップし、エグゼキュターの需要が増加するとスポットノードをスケールアップします。
+ ノードラベルが有効になっていない場合、アプリケーションプロセスの配置はノードまたは市場タイプに制限されません。
+ ノードラベルを使用することで、マネージドスケーリングでは同じサイズ変更オペレーションで異なるインスタンスグループとインスタンスフリートをスケールアップおよびスケールダウンできます。例えば、`instance_group1` に `ON_DEMAND` ノード、`instance_group2` に `SPOT` ノードがあり、ノードラベルが有効で、アプリケーションプロセスが `ON_DEMAND` ラベル付きのノードに制限されているシナリオです。マネージドスケーリングでは、アプリケーションプロセスの需要が減少し、エグゼキュターの需要が増加すると、`instance_group1` スケールダウンし、`instance_group2` をスケールアップします。
+ Amazon EMR で現在のインスタンスグループでスケールアップに遅延が発生すると、マネージドスケーリングを使用するクラスターは自動的に別のタスクインスタンスグループに切り替わります。
+ `MaximumCoreCapacityUnits` パラメータが設定されている場合、Amazon EMR はコアユニットが最大許容制限に達するまで、コアノードをスケーリングします。残りの容量はすべてタスクノードに追加されます。
+ `MaximumOnDemandCapacityUnits` パラメータが設定されている場合、Amazon EMR は、オンデマンドユニットが最大許容制限に達するまで、オンデマンドインスタンスを使用してクラスターをスケーリングします。残りの容量はすべて、スポットインスタンスを使用して追加されます。
+ `MaximumCoreCapacityUnits` と `MaximumOnDemandCapacityUnits` の両方のパラメータが設定されている場合、Amazon EMR はスケーリング中に両方の制限を考慮します。
例えば、`MaximumCoreCapacityUnits` が `MaximumOnDemandCapacityUnits` 未満の場合、Amazon EMR はまず、コア容量の制限に達するまでコアノードの容量をスケールします。残りの容量については、Amazon EMR はまずオンデマンドインスタンスを使用してオンデマンドの制限に達するまでタスクノードをスケールし、次にスポットインスタンスを使用してタスクノードをスケールします。
**スケールダウン戦略**
+ スケールアップ戦略と同様に、Amazon EMR はノードラベルに基づいてノードを削除します。ノードラベルの詳細については、「[Understand node types: primary, core, and task nodes](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-master-core-task-nodes.html)」を参照してください。
+ ノードラベルを有効にしていない場合、EMR Managed Scaling は、タスクノードを削除し、次に目的のスケールダウン目標容量が達成されるまでコアノードを削除します。マネージドスケーリングでは、指定されたマネージドスケーリングポリシーの最小制約を下回ってクラスターがスケールダウンされることはありません。
+ Amazon EMR バージョン 5.34.0 以上、および Amazon EMR バージョン 6.4.0 以上では、Spark シャッフルデータ対応がサポートされています。これにより、マネージドスケーリングが既存のシャッフルデータを認識している間にインスタンスがスケールダウンするのを防ぎます。シャッフル操作の詳細については、[Spark のプログラミングガイド](https://spark.apache.org/docs/latest/rdd-programming-guide.html#shuffle-operations)を参照してください。マネージドスケーリングは、アクティブな Spark アプリケーションの現在および以前のステージのシャッフルデータを含むノードを最大 30 分までスケールダウンしないように最善を尽くします。これにより、意図しないシャッフルデータの損失が最小化でき、ジョブを再試行したり、中間データを再計算したりする必要がなくなります。ただし、シャッフルデータ損失の防止は保証されません。Spark シャッフル保護を強化するために、リリースラベル 7.4 以降のクラスターではシャッフル対応をお勧めします。次のフラグをクラスター設定に追加して、Spark シャッフル保護を改善します。
+ `yarn.nodemanager.shuffledata-monitor.interval-ms` フラグ (デフォルトは 30,000 ミリ秒) または `spark.dynamicAllocation.executorIdleTimeout`のいずれか (デフォルトは 60 秒) がデフォルト値から変更されている場合は、必要なフラグを更新`true`して条件が`spark.dynamicAllocation.executorIdleTimeout > yarn.nodemanager.shuffledata-monitor.interval-ms`そのままであることを確認します。
```
[
{
"Classification": "yarn-site",
"Properties": {
"yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data": "true"
}
},
{
"Classification": "spark-defaults",
"Properties": {
"spark.dynamicAllocation.enabled": "true",
"spark.shuffle.service.removeShuffle": "true"
}
}
]
```
+ マネージドスケーリングでは、まずタスクノードを削除し、次に目的のスケールダウン目標容量が達成されるまでコアノードを削除します。クラスターのスケーリングは、指定されたマネージドスケーリングポリシーの最小制約を下回ることはありません。
+ Amazon EMR 5.x リリース 5.34.0 以降、および 6.x リリース 6.4.0 以降で起動されたクラスターの場合、アプリケーションが実行されているアクティブなステージがある場合、Amazon EMR Managed Scaling は Apache Spark `ApplicationMaster`用の を持つノードをスケールダウンしません。これにより、ジョブの失敗や再試行が最小限に抑えられ、ジョブのパフォーマンスが向上し、コストが削減されます。クラスター内のどのノードで `ApplicationMaster` が実行されているかを確認するには、Spark 履歴サーバーにアクセスし、Spark アプリケーション ID の **[Executors]** タブでドライバーをフィルタリングします。
+ EMR マネージドスケーリングによるインテリジェントスケーリングは Spark のシャッフルデータ損失を最小限に抑えますが、スケールダウン中に一時的なシャッフルデータが保護されない場合があります。スケールダウン中にシャッフルデータの耐障害性を強化するには、YARN で**シャッフルデータのグレースフル廃止**を有効にすることをお勧めします。YARN で**シャッフルデータのグレースフル廃止**が有効になっている場合、シャッフルデータを持つスケールダウン用に選択されたノードは**廃止**状態になり、シャッフルファイルの提供を継続します。YARN ResourceManager は、ノードがシャッフルファイルが存在しないとレポートするまで待機してから、クラスターからノードを削除します。
+ Amazon EMR バージョン 6.11.0 以上では、Tez および MapReduce シャッフルハンドラーの両方の **Hive** シャッフルデータの Yarn ベースの正常な廃止がサポートされています。
+ `yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data` を `true` に設定して、シャッフルデータのグレースフル廃止を有効にします。
+ Amazon EMR バージョン 7.4.0 以上では、外部シャッフルサービスが有効になっている場合 (EC2 の EMR でデフォルトで有効)、Spark シャッフルデータの Yarn ベースの正常な廃止がサポートされています。
+ Spark 外部シャッフルサービスのデフォルトの動作は、Spark on Yarn を実行する時に、Yarn NodeManager がアプリケーション終了時にアプリケーションシャッフルファイルを削除することです。これは、ノードの廃止速度とコンピューティング使用率に影響する可能性があります。長時間実行されるアプリケーションでは、アクティブなシャッフルデータがないノードをより迅速に廃止できるように、使用していないシャッフルファイルを削除するように `spark.shuffle.service.removeShuffle` を `true` に設定することを検討してください。
+ Amazon EMR バージョン 7.4.0 以降で Spark シャッフルデータ損失を最小限に抑えるには、次のフラグを設定することを検討してください。
+ `yarn.nodemanager.shuffledata-monitor.interval-ms` フラグ (デフォルトは 30,000 ミリ秒) または `spark.dynamicAllocation.executorIdleTimeout`のいずれか (デフォルトは 60 秒) がデフォルト値から変更されている場合は、必要なフラグを更新`true`して条件が`spark.dynamicAllocation.executorIdleTimeout > yarn.nodemanager.shuffledata-monitor.interval-ms`維持されていることを確認します。
```
[
{
"Classification": "yarn-site",
"Properties": {
"yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data": "true"
}
},
{
"Classification": "spark-defaults",
"Properties": {
"spark.dynamicAllocation.enabled": "true",
"spark.shuffle.service.removeShuffle": "true"
}
}
]
```
クラスターに負荷がない場合、Amazon EMR は前の評価で提案された新しいインスタンスの追加をキャンセルし、スケールダウン操作を実行します。クラスターの負荷が大きい場合、Amazon EMR はインスタンスの削除をキャンセルし、スケールアップ操作を実行します。
## ノード割り当てに関する考慮事項
スポットの再利用時に HDFS データが失われないように、コアノードに対してオンデマンド購入オプションを使用することをお勧めします。タスクノードに対してスポット購入オプションを使用すると、タスクノードにスポットインスタンスを追加するときのコストが削減され、ジョブ実行が高速になります。
## ノード割り当てシナリオ
最大、最小、オンデマンド制限、および最大コアノードの各パラメータをさまざまな組み合わせで、セットアップすることで、ニーズに基づいてさまざまなスケーリングシナリオを作成できます。
**シナリオ 1: コアノードのみをスケーリングする**
コアノードのみをスケーリングするには、マネージドスケーリングパラメータが次の要件を満たしている必要があります。
+ オンデマンド制限が最大限度と等しいこと。
+ 最大コアノードが最大限度と等しいこと。
オンデマンド制限と最大コアノードのパラメータが指定されていないときは、両方のパラメータがデフォルトで最大限度に設定されます。
このシナリオは、ノードラベルでマネージドスケーリングを使用し、アプリケーションプロセスを `CORE` ノードでのみ実行するように制限する場合には適用されません。マネージドスケーリングはエグゼキューターの需要に対応するためにタスクノードをスケーリングするからです。
コアノードのみをスケーリングするシナリオの例を次に示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)
**シナリオ 2: タスクノードのみをスケーリングする**
タスクノードのみをスケーリングするには、マネージドスケーリングパラメータが次の要件を満たしている必要があります。
+ 最大コアノードが最小限度と等しいこと。
タスクノードのみをスケーリングするシナリオの例を次に示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)
**シナリオ 3: クラスター内のオンデマンドインスタンスのみ**
オンデマンドインスタンスのみを使用するには、クラスターとマネージドスケーリングパラメータが次の要件を満たしている必要があります。
+ オンデマンド制限が最大限度と等しいこと。
オンデマンド制限が指定されていないときは、パラメータ値がデフォルトで最大限度に設定されます。デフォルト値は、Amazon EMR がオンデマンドインスタンスのみをスケーリングすることを示します。
最大コアノードが最大限度未満の場合、最大コアノードパラメータを使用して、コアノードとタスクノード間で容量割り当てを分割できます。
インスタンスグループで構成されるクラスターでこのシナリオを有効にするには、初期構成時にクラスター内のすべてのノードグループがオンデマンドマーケットタイプを使用する必要があります。
このシナリオは、ノードラベルでマネージドスケーリングを使用し、アプリケーションプロセスを `ON_DEMAND` ノードでのみ実行するように制限する場合には適用されません。マネージドスケーリングはエグゼキューターの需要に対応するために `Spot` ノードをスケーリングするからです。
クラスター全体にオンデマンドインスタンスを持つシナリオの例を次に示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)
**シナリオ 4: クラスター内のスポットインスタンスのみ**
スポットインスタンスのみを使用するには、マネージドスケーリングパラメータが次の要件を満たしている必要があります。
+ オンデマンド制限が 0 に設定されていること。
最大コアノードが最大限度未満の場合、最大コアノードパラメータを使用して、コアノードとタスクノード間で容量割り当てを分割できます。
インスタンスグループで構成されるクラスターでこのシナリオを有効にするには、コアインスタンスグループが初期設定時にスポット購入オプションを使用する必要があります。タスクインスタンスグループにスポットインスタンスがない場合、Amazon EMR Managed Scaling は、必要に応じてスポットインスタンスを使用してタスクグループを作成します。
このシナリオは、ノードラベルでマネージドスケーリングを使用し、アプリケーションプロセスを `ON_DEMAND` ノードでのみ実行するように制限する場合には適用されません。マネージドスケーリングは、アプリケーションプロセスの需要に合わせて `ON_DEMAND` ノードをスケーリングするからです。
クラスター全体にスポットインスタンスを持つシナリオの例を次に示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)
**シナリオ 5: コアノードのオンデマンドインスタンスと、タスクノードのスポットインスタンスをスケーリングする**
コアノードのオンデマンドインスタンスと、タスクノードのスポットインスタンスをスケーリングするには、マネージドスケーリングパラメータが次の要件を満たしている必要があります。
+ オンデマンドの制限が最大コアノードに等しいこと。
+ オンデマンド制限と最大コアノードの両方が最大限度未満であること。
インスタンスグループで構成されるクラスターでこのシナリオを有効にするには、コアノードグループがオンデマンド購入オプションを使用する必要があります。
このシナリオは、ノードラベルでマネージドスケーリングを使用し、アプリケーションプロセスを `ON_DEMAND` ノードまたは `CORE` ノードでのみ実行するように制限する場合には適用されません。
コアノードのオンデマンドインスタンスと、タスクノードのスポットインスタンスをスケーリングするシナリオの例を次に示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)
**シナリオ 6: アプリケーションプロセスの需要に応じて`CORE`インスタンスをスケールし、エグゼキュターの需要に応じて `TASK` インスタンスをスケールします。**
このシナリオは、ノードラベルでマネージドスケーリングを使用し、アプリケーションプロセスを `CORE` ノードでのみ実行するように制限する場合にのみ適用できます。
アプリケーションプロセスの需要とエグゼキュターの需要に基づいて `CORE` ノードと `TASK` ノードをそれぞれスケーリングするには、クラスターの起動時に次の設定を行う必要があります。
+ `yarn.node-labels.enabled:true`
+ `yarn.node-labels.am.default-node-label-expression: 'CORE'`
`ON_DEMAND` 制限と最大 `CORE` ノードのパラメータが指定されていないときは、両方のパラメータがデフォルトで最大限度に設定されます。
最大 `ON_DEMAND` ノードが最大限度未満の場合、マネージドスケーリングでは、最大 `ON_DEMAND` ノードパラメータを使用して、`ON_DEMAND` ノードと `SPOT` ノード間で容量割り当てを分割できます。最大 `CORE` ノードパラメータを最小容量パラメータ以下に設定すると、`CORE` ノードは最大コア容量で静的のままになります。
アプリケーションプロセスの需要に応じて CORE インスタンスを、エグゼキューターの需要に応じて TASK インスタンスををスケーリングするシナリオの例を次に示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)
**シナリオ 7: アプリケーションプロセスの需要に応じて`ON_DEMAND`インスタンスをスケールし、エグゼキュターの需要に応じて `SPOT` インスタンスをスケールします。**
このシナリオは、ノードラベルでマネージドスケーリングを使用し、アプリケーションプロセスを `ON_DEMAND` ノードでのみ実行するように制限する場合にのみ適用できます。
アプリケーションプロセスの需要とエグゼキュターの需要に基づいて `ON_DEMAND` ノードと `SPOT` ノードをそれぞれスケーリングするには、クラスターの起動時に次の設定を行う必要があります。
+ `yarn.node-labels.enabled:true`
+ `yarn.node-labels.am.default-node-label-expression: 'ON_DEMAND'`
`ON_DEMAND` 制限と最大 `CORE` ノードのパラメータが指定されていないときは、両方のパラメータがデフォルトで最大限度に設定されます。
最大 `CORE` ノードが最大限度未満の場合、マネージドスケーリングでは、最大 `CORE` ノードパラメータを使用して、`CORE` ノードと `TASK` ノード間で容量割り当てを分割できます。最大 `CORE` ノードパラメータを最小容量パラメータ以下に設定すると、`CORE` ノードは最大コア容量で静的のままになります。
アプリケーションプロセスの需要に応じてオンデマンドインスタンスを、エグゼキューターの需要に応じてスポットインスタンスををスケーリングするシナリオの例を次に示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)
# Amazon EMR のマネージドスケーリングメトリクスについて
Amazon EMR は、クラスターでマネージドスケーリングが有効になっているとき、1 分単位の精度のデータで高解像度のメトリクスを公開します。Amazon EMR コンソールまたは Amazon CloudWatch コンソールを使用して、マネージドスケーリングによって制御されるすべてのサイズ変更の開始と完了のイベントを表示できます。CloudWatch メトリクスは、Amazon EMR マネージドスケーリングの運用に不可欠です。CloudWatch メトリクスを注意深く監視して、データが欠落していないことを確認することをお勧めします。欠落しているメトリクスを検出するように CloudWatch アラームを設定する方法の詳細については、「[Amazon CloudWatch でのアラームの使用](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)」を参照してください。Amazon EMR での CloudWatch Events の使用の詳細については、「[CloudWatch イベントをモニタリングする](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-cloudwatch-events.html)」を参照してください。
次のメトリクスは、クラスターの現在の容量またはターゲットの容量を示します。これらのメトリクスは、マネージドスケーリングが有効になっている場合にのみ使用できます。インスタンスフリートで構成されるクラスターの場合、クラスター容量のメトリクスは `Units` 単位で測定されます。インスタンスグループで構成されるクラスターの場合、クラスター容量のメトリクスは、マネージドスケーリングポリシーで使用される単位タイプに基づき、`Nodes` 単位または `vCPU` 単位で測定されます。
| メトリクス | 説明 |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/managed-scaling-metrics.html) | マネージドスケーリングによって決定された、クラスター内の単位/ノード/vCPU の合計ターゲット数。 単位: *Count* |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/managed-scaling-metrics.html) | 実行中のクラスターで使用可能な単位/ノード/vCPU の現在の合計数。クラスターのサイズ変更がリクエストされると、クラスターに新しいインスタンスが追加または削除された後に、このメトリクスが更新されます。 単位: *Count* |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/managed-scaling-metrics.html) | マネージドスケーリングによって決定された、クラスター内の CORE 単位/ノード/vCPU のターゲット数。 単位: *Count* |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/managed-scaling-metrics.html) | クラスターで実行されている CORE 単位/ノード/vCPU の現在の数。 単位: *Count* |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/managed-scaling-metrics.html) | マネージドスケーリングによって決定された、クラスター内の TASK 単位/ノード/vCPU のターゲット数。 単位: *Count* |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/managed-scaling-metrics.html) | クラスターで実行されている TASK 単位/ノード/vCPU の現在の数。 単位: *Count* |
次のメトリクスは、クラスターとアプリケーションの使用状況を示します。これらのメトリクスは、すべての Amazon EMR 機能で使用できますが、クラスターでマネージドスケーリングが有効になっているときは、1 分単位の精度のデータで高解像度のメトリクスが公開されます。以下のメトリクスを前の表のクラスター容量メトリクスと関連付けることで、マネージドスケーリングの決定について理解することができます。
| メトリクス | 説明 |
| --- | --- |
| `AppsCompleted` | YARN に送信され、完了したアプリケーションの数。 ユースケース:クラスターの進捗状況を監視する 単位: *Count* |
| `AppsPending` | YARN に送信され、保留状態になっているアプリケーションの数。 ユースケース:クラスターの進捗状況を監視する 単位: *Count* |
| `AppsRunning` | YARN に送信され、実行中であるアプリケーションの数。 ユースケース:クラスターの進捗状況を監視する 単位: *Count* |
| ContainerAllocated | ResourceManager によって割り当てられるリソース コンテナの数。 ユースケース:クラスターの進捗状況を監視する 単位: *Count* |
| `ContainerPending` | キュー内にあり、まだ割り当てられていないコンテナの数。 ユースケース:クラスターの進捗状況を監視する 単位: *Count* |
| ContainerPendingRatio | 割り当てられたコンテナに対する保留中のコンテナの比率 (ContainerPendingRatio = ContainerPending/ContainerAllocated)。ContainerAllocated = 0 の場合は、ContainerPendingRatio = ContainerPending になります。ContainerPendingRatio の値は、割合 (%) ではなく数値を表します。この値は、コンテナ割り当て動作に基づくクラスターリソースのスケーリングに役立ちます。 単位: *Count* |
| `HDFSUtilization` | 現在使用されている HDFS ストレージの割合。 ユースケース:クラスターのパフォーマンスを分析する 単位: *パーセント* |
| `IsIdle` | クラスターが作業を行っていないが、まだ有効で課金されていることを示します。タスクもジョブも実行されていない場合は 1 に設定され、それ以外の場合は 0 に設定されます。この値は 5 分間隔で確認され、値が 1 の場合は、確認時にクラスターがアイドル状態だったことのみを示します。5 分間ずっとアイドル状態だったことを示すわけではありません。誤検出を避けるには、5 分ごとの確認で複数回連続してこの値が 1 である場合に通知するように、アラームを指定する必要があります。たとえば、30 分間にわたってこの値が 1 だった場合に通知するようアラームを指定できます。 ユースケース:クラスターのパフォーマンスを監視する 単位: *ブール* |
| `MemoryAvailableMB` | 割り当てに使用できるメモリの量。 ユースケース:クラスターの進捗状況を監視する 単位: *Count* |
| `MRActiveNodes` | MapReduce のタスクまたはジョブを現在実行しているノードの数。YARN メトリクス `mapred.resourcemanager.NoOfActiveNodes` と同等。 ユースケース:クラスターの進捗状況を監視する 単位: *Count* |
| `YARNMemoryAvailablePercentage` | YARN に対する利用可能な残りのメモリの割合 (YARNMemoryAvailablePercentage = MemoryAvailableMB / MemoryTotalMB)。この値は、YARN のメモリの使用状況に基づくクラスターリソースのスケーリングに役立ちます。 単位: *パーセント* |
以下のメトリクスは、YARN コンテナとノードで使用されるリソースに関する情報を提供します。YARN リソースマネージャーからのこれらのメトリクスは、クラスターで実行されているコンテナとノードが使用するリソースに関するインサイトを提供します。これらのメトリクスを前のテーブルのクラスター容量メトリクスと比較することにより、マネージドスケーリングの影響をより明確に把握できます:
| メトリクス | 関連リリース | 説明 |
| --- | --- | --- |
| `YarnContainersUsedMemoryGBSeconds` | リリースラベル 7.3.0 以上で使用可能 | 発行期間に消費されたコンテナメモリ \$1 秒。 **単位:** GB \$1 秒 |
| `YarnContainersTotalMemoryGBSeconds` | リリースラベル 7.3.0 以上で使用可能 | 公開期間の合計 yarn コンテナ \$1 秒。 **単位:** GB \$1 秒 |
| `YarnContainersUsedVCPUSeconds` | リリースラベル 7.5.0 以上で使用可能 | 発行期間に消費されたコンテナ VCPU \$1 秒。 **単位:** VCPU \$1 秒 |
| `YarnContainersTotalVCPUSeconds` | リリースラベル 7.5.0 以上で使用可能 | 発行期間の合計コンテナ VCPU \$1 秒。 **単位:** VCPU \$1 秒 |
| `YarnNodesUsedMemoryGBSeconds` | リリースラベル 7.5.0 以上で使用可能 | 発行期間に消費されたノードメモリ \$1 秒。 **単位:** GB \$1 秒 |
| `YarnNodesTotalMemoryGBSeconds` | リリースラベル 7.5.0 以上で使用可能 | 発行期間の合計ノードメモリ \$1 秒。 **単位:** GB \$1 秒 |
| `YarnNodesUsedVCPUSeconds` | リリースラベル 7.3.0 以上で使用可能 | 発行期間に消費されたノード VCPU \$1 秒。 **単位:** VCPU \$1 秒 |
| `YarnNodesTotalVCPUSeconds` | リリースラベル 7.3.0 以上で使用可能 | 発行期間の合計ノード VCPU \$1 秒。 **単位:** VCPU \$1 秒 |
## マネージドスケーリングメトリクスをグラフ化する
以下の手順で示すように、メトリクスをグラフ化することにより、クラスターのワークロードパターンと、Amazon EMR Managed Scaling によって行われた対応するスケーリング決定を視覚化できます。
**CloudWatch コンソールでマネージドスケーリングメトリクスをグラフ化するには**
1. [CloudWatch コンソール](https://console.aws.amazon.com/cloudwatch/)を開きます。
1. ナビゲーションペインで [**Amazon EMR**] を選択します。モニタリングするクラスターのクラスター識別子を検索できます。
1. グラフ化するメトリクスまでスクロールダウンします。グラフを表示するメトリクスを開きます。
1. 1 つ以上のメトリクスをグラフ化するには、各メトリクスの横にあるチェックボックスを選択します。
次の例は、クラスターの Amazon EMR Managed Scaling のアクティビティを示しています。グラフには、アクティブ度の低いワークロードがある場合にコストを節約する、3 つの自動スケールダウン期間が示されています。
![\[グラフ管理スケーリングメトリクス\]](http://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/images/Managed_Scaling_Decision.png)
すべてのクラスターの容量および使用率のメトリクスが、1 分間隔で公開されます。各 1 分間データには追加の統計情報も関連付けられており、`Percentiles`、`Min`、`Max`、`Sum`、`Average`、`SampleCount` などさまざまな関数に使用できます。
たとえば、次のグラフでは、`Sum`、`Average`、`Min`、`SampleCount` とともに、同じ `YARNMemoryAvailablePercentage` メトリクスが異なるパーセンタイル (P10、P50、P90、P99) で描画されます。
![\[異なるパーセンタイルを使用してマネージドスケーリングメトリクスをグラフ化する\]](http://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/images/Managed_Scaling_Metrics.png)
# カスタムポリシーによる自動スケーリングを Amazon EMR のインスタンスグループに使用する
Amazon EMR リリース 4.0 以上のカスタムポリシーによる自動スケーリングを使用することにより、*スケーリングポリシー*で指定した CloudWatch メトリクスやその他のパラメータに基づいて、プログラムでコアノードとタスクノードをスケールアウトおよびスケールインできます。カスタムポリシーによる自動スケーリングは、インスタンスグループ設定を使用するときに利用できます。インスタンスフリートを使用するときには利用できません。インスタンスグループとインスタンスフリートの詳細については、「[インスタンスフリートまたはユニフォームインスタンスグループで Amazon EMR クラスターを作成する](emr-instance-group-configuration.md)」を参照してください。
**注記**
Amazon EMR でカスタムポリシー機能による自動スケーリングを使用するには、クラスターの作成時に `VisibleToAllUsers` パラメータに `true` を設定する必要があります。詳細については、「[SetVisibleToAllUsers](https://docs.aws.amazon.com/emr/latest/APIReference/API_SetVisibleToAllUsers.html)」を参照してください。
スケーリングポリシーは、インスタンスグループ設定の一部です。インスタンスグループの初期設定時にポリシーを指定するか、インスタンスグループがアクティブになった後でも、既存のクラスターのインスタンスグループを変更して、ポリシーを指定できます。プライマリインスタンスグループを除くクラスター内の各インスタンスグループは、独自のスケーリングポリシーを持つことができます。スケーリングポリシーはスケールアウトルールとスケールインルールで構成されます。スケールアウトルールとスケールインルールは、それぞれに異なるパラメータを用いて、個別に設定できます。
スケーリングポリシーは、 AWS マネジメントコンソール、、 AWS CLIまたは Amazon EMR API で設定できます。 AWS CLI または Amazon EMR API を使用する場合は、スケーリングポリシーを JSON 形式で指定します。さらに、 AWS CLI または Amazon EMR API を使用する場合、カスタム CloudWatch メトリクスを指定できます。カスタムのメトリクスは、 AWS マネジメントコンソールでの選択には使用できません。最初にコンソールを使用してスケーリングポリシーを作成する場合は、まず、多数のアプリケーションが事前設定されているデフォルトのポリシーが適しています。デフォルトのルールは削除したり変更できます。
自動スケーリングを使用すれば、実行中でも EMR クラスターの容量を変更できますが、ベースラインとなるワークロード要件を考慮し、ノードおよびインスタンスグループ設定を計画してください。詳細については、「[クラスター設定のガイドライン](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-instances-guidelines.html)」を参照してください。
**注記**
ほとんどのワークロードで、リソースの活用を最適化するには、スケールイン、スケールアウトの両方のルールを設定することが理想となります。一方を設定せずにどちらかのルールのみを設定すると、規模の拡大や縮小の後に、インスタンスカウントを手動でサイズ調整する必要があります。つまりこの方法では、手動でのリセットを伴う「一方通行の」自動スケールアウトまたはスケールインポリシーを設定することになります。
## 自動スケーリングの IAM ロールを作成する
Amazon EMR での自動スケーリングには、スケーリングアクティビティがトリガーされたときにインスタンスを追加および削除する権限がある IAM ロールが必要です。デフォルトロールである `EMR_AutoScaling_DefaultRole` は、適切なロールポリシーと信頼ポリシーで設定されており、この目的に使用できます。で初めてスケーリングポリシーを使用してクラスターを作成すると AWS マネジメントコンソール、Amazon EMR はデフォルトのロールを作成し、アクセス許可のデフォルトの管理ポリシー をアタッチします`AmazonElasticMapReduceforAutoScalingRole`。
で自動スケーリングポリシーを使用してクラスターを作成する場合は AWS CLI、まずデフォルトの IAM ロールが存在するか、適切なアクセス許可を提供するポリシーがアタッチされたカスタム IAM ロールがあることを確認する必要があります。デフォルトロールを作成するには、クラスターを作成する前に `create-default-roles` コマンドを実行します。その後、クラスターの作成時に `--auto-scaling-role EMR_AutoScaling_DefaultRole` オプションを指定します。または、カスタムの自動スケーリングロール (例: `--auto-scaling-role MyEMRAutoScalingRole`) を作成して、クラスター作成時に指定することもできます。カスタマイズされた自動スケーリングロールを Amazon EMR 向けに作成する場合は、管理ポリシーに基づいたカスタムロールのアクセス許可ポリシーをベースにすることをお勧めします。詳細については、「[サービスおよびリソースへの Amazon EMR アクセス許可の IAM AWS サービスロールを設定する](emr-iam-roles.md)」を参照してください。
## 自動スケーリングルールについて
スケールアウトルールがインスタンスグループのスケーリングをトリガーするときに、ルールに従って Amazon EC2 インスタンスがインスタンスグループに追加されます。Amazon EC2 インスタンスが `InService` 状態になるとすぐに、Apache Spark、Apache Hive、Presto などのアプリケーションで新しいノードを使用できます。インスタンスを終了し、ノードを削除するスケールインルールを設定することもできます。自動的にスケーリングする Amazon EC2 インスタンスのライフサイクルの詳細については、「*Amazon EC2 Auto Scaling ユーザーガイド*」の「[Auto Scaling のライフサイクル](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroupLifecycle.html)」を参照してください。
クラスターが Amazon EC2 インスタンスを削除する方法を設定できます。請求の Amazon EC2 インスタンス時間の境界と、タスクの完了時のどちらで削除するかを選択できます。この設定は自動スケーリングと手動でのサイズ変更オペレーションの両方に適用されます。この設定の詳細については、「[Amazon EMR クラスターのクラスタースケールダウンオプション](emr-scaledown-behavior.md)」を参照してください。
ポリシー内の各ルールのうち、次のパラメータで自動スケーリングの動作を決定します。
**注記**
ここに記載されているパラメータは、Amazon EMR AWS マネジメントコンソール の に基づいています。 AWS CLI または Amazon EMR API を使用する場合、追加の高度な設定オプションを使用できます。詳細オプションついて詳しくは、「*Amazon EMR API リファレンス*」の「[SimpleScalingPolicyConfiguration](https://docs.aws.amazon.com/ElasticMapReduce/latest/API/API_PutAutoScalingPolicy.html)」を参照してください。
+ 最大インスタンスおよび最小インスタンス。**[最大インスタンス]** という制約は、インスタンスグループに含めることができる Amazon EC2 インスタンスの最大数を指定します。これはすべてのスケールアウトルールに適用されます。同様に、**[最小インスタンス]** という制約は、Amazon EC2 インスタンスの最小数を指定します。これはすべてのスケールインルールに適用されます。
+ **ルール名**は、ポリシー内で一意である必要があります。
+ **スケーリング調整**は、ルールによりトリガーされた規模の拡大や縮小の間に追加 (スケールアウトルールの場合)、または終了 (スケールインルールの場合) する EC2 インスタンスの数を決定します。
+ **CloudWatch メトリクス**は、アラーム条件用に監視されます。
+ **比較演算子**は、CloudWatch メトリクスを**しきい値**と比較してトリガー条件を決定します。
+ **評価期間**は、5 分単位で増分します。規模の拡大や縮小がトリガーされる前に CloudWatch メトリクスがトリガー条件になる必要があります。
+ **クールダウン期間** (秒単位) は、何らかのルールによって開始されるスケーリングアクティビティと、次に開始されるスケーリングアクティビティとの間で経過する必要がある時間です。インスタンスグループがスケーリングを完了し、スケーリング後の状態に達したときに、クールダウン期間によって、後続のスケーリングをトリガーする可能性のある CloudWatch メトリクスを安定させることができます。詳細については、「*Amazon EC2 Auto Scaling ユーザーガイド*」の「[Auto Scaling のクールダウン](https://docs.aws.amazon.com/autoscaling/ec2/userguide/Cooldown.html)」を参照してください。
![\[AWS マネジメントコンソール Amazon EMR の自動スケーリングルールパラメータ。\]](http://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/images/auto-scaling-rule-params.png)
## 考慮事項と制限事項
+ Amazon CloudWatch メトリクスは、Amazon EMR の自動スケーリングの運用に不可欠です。Amazon CloudWatch メトリクスを注意深く監視して、データが欠落していないことを確認することをお勧めします。欠落しているメトリクスを検出するように Amazon CloudWatch アラームを設定する方法の詳細については、「[Amazon CloudWatch でのアラームの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)」を参照してください。
+ EBS ボリュームの使用率が高すぎると、マネージドスケーリングの問題が発生する可能性があります。EBS ボリュームの使用率を注意深く監視して、EBS ボリュームの使用率が 90% 未満であることを確認することをお勧めします。追加の EBS ボリュームを指定する方法については、「[インスタンスストレージ](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-storage.html)」を参照してください。
+ Amazon EMR リリース 5.18 から 5.28 のカスタムポリシーによる自動スケーリングでは、Amazon CloudWatch メトリクスでデータが間欠的に欠落しているために、スケーリングに失敗することがあります。自動スケーリングを向上させるために、最新の Amazon EMR バージョンを使用することをお勧めします。5.18 から 5.28 の間の Amazon EMR リリースを使用する必要がある場合は、パッチの使用について、[AWS サポート](https://aws.amazon.com/premiumsupport/)にお問い合わせいただくこともできます。
## を使用して自動スケーリング AWS マネジメントコンソール を設定する
クラスターを作成する際、高度なクラスター設定オプションを使用して、インスタンスグループにスケーリングポリシーを設定します。既存のクラスターの**ハードウェア**設定でインスタンスグループを変更することにより、実行中のインスタンスグループのスケーリングポリシーを作成または変更することもできます。
1. 新しい Amazon EMR コンソールに移動し、サイドナビゲーションから **[古いコンソールに切り替え]** を選択します。古いコンソールに切り替えたときの動作の詳細については、「[Using the old console](https://docs.aws.amazon.com/emr/latest/ManagementGuide/whats-new-in-console.html#console-opt-in)」を参照してください。
1. クラスターを作成する場合、Amazon EMR コンソールで、**[クラスターの作成]** を選択し、**[詳細オプションに移動する]** を選択します。次に、**[ステップ 1: ソフトウェアおよびステップ]** のオプションを選択し、**[ステップ 2: ハードウェア構成]** に移動します。
** - または - **
実行中のクラスターのインスタンスグループを変更する場合、クラスターリストからクラスターを選択し、その後 [**ハードウェア**] セクションを展開します。
1. **[クラスターのスケーリングとプロビジョニングのオプション]** セクションで **[クラスタースケーリングを有効にする]** を選択します。次に、[**Create a custom Auto Scaling policy (カスタムの自動スケーリングポリシーを作成する)**] を選択します。
[**Custom automatic scaling policies (カスタムの自動スケーリングポリシー)**] の表で、設定するインスタンスグループの行に表示されている鉛筆アイコンをクリックします。Auto Scaling ルールの画面が開きます。
1. インスタンスグループをスケールアウトした後に含める**最大インスタンス**を入力するか、インスタンスグループをスケールインした後に含める**最小インスタンス**を入力します。
1. ルールのパラメータを編集するには鉛筆をクリックします。ポリシーからルールを削除するには [**X**] を、ルールを追加するには [**Add rule**] をクリックします。
1. このトピックで先に記載したとおり、ルールのパラメータを選択します。Amazon EMR で利用可能な CloudWatch メトリクスの説明については、「*Amazon CloudWatch ユーザーガイド*」の「[Amazon EMR のメトリクスとディメンション](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/emr-metricscollected.html)」を参照してください。
## を使用して自動スケーリング AWS CLI を設定する
Amazon EMR の AWS CLI コマンドを使用して、クラスターの作成時とインスタンスグループの作成時に自動スケーリングを設定できます。短縮構文を使用して、関連コマンドのインラインで JSON 設定を指定したり、設定 JSON を含むファイルを参照したりできます。既存のインスタンスグループに自動スケーリングポリシーを適用したり、以前適用されていた自動スケーリングポリシーを削除することもできます。さらに、スケーリングポリシーの詳細設定を実行中のクラスターから取得できます。
**重要**
自動スケーリングポリシーを持つクラスターを作成するときは、`--auto-scaling-role MyAutoScalingRole` コマンドを使用して、自動スケーリング用の IAM ロールを指定する必要があります。デフォルトロールは、`EMR_AutoScaling_DefaultRole` で、`create-default-roles` コマンドを使用して作成できます。ロールはクラスターが作成された後にのみ追加でき、既存のクラスターには追加できません。
自動スケーリングポリシーの設定時に使用できるパラメータの詳細については、「*Amazon EMR API リファレンス*」の「[PutAutoScalingPolicy](https://docs.aws.amazon.com/ElasticMapReduce/latest/API/API_PutAutoScalingPolicy.html)」を参照してください。
### インスタンスグループに適用する自動スケーリングポリシーを持つクラスターを作成する
`aws emr create-cluster` コマンドの `--instance-groups` オプション内で自動スケーリング設定を指定できます。次の例は、create-cluster コマンドを示しています。このコマンドには、インラインにコアインスタンスグループの自動スケーリングポリシーがあります。コマンドは、Amazon EMR AWS マネジメントコンソール の で自動スケーリングポリシーを作成するときに表示されるデフォルトのスケールアウトポリシーと同等のスケーリング設定を作成します。簡潔にするために、スケールインポリシーは表示されません。スケールインルールなしで、スケールアウトルールを作成するのは推奨されていません。
```
aws emr create-cluster --release-label emr-5.2.0 --service-role EMR_DefaultRole --ec2-attributes InstanceProfile=EMR_EC2_DefaultRole --auto-scaling-role EMR_AutoScaling_DefaultRole --instance-groups Name=MyMasterIG,InstanceGroupType=MASTER,InstanceType=m5.xlarge,InstanceCount=1 'Name=MyCoreIG,InstanceGroupType=CORE,InstanceType=m5.xlarge,InstanceCount=2,AutoScalingPolicy={Constraints={MinCapacity=2,MaxCapacity=10},Rules=[{Name=Default-scale-out,Description=Replicates the default scale-out rule in the console.,Action={SimpleScalingPolicyConfiguration={AdjustmentType=CHANGE_IN_CAPACITY,ScalingAdjustment=1,CoolDown=300}},Trigger={CloudWatchAlarmDefinition={ComparisonOperator=LESS_THAN,EvaluationPeriods=1,MetricName=YARNMemoryAvailablePercentage,Namespace=AWS/ElasticMapReduce,Period=300,Statistic=AVERAGE,Threshold=15,Unit=PERCENT,Dimensions=[{Key=JobFlowId,Value="${emr.clusterId}"}]}}}]}'
```
次のコマンドは、コマンドラインを使用して、`instancegroupconfig.json` という名前のインスタンスグループ設定ファイルの一部としての自動スケーリングポリシー定義を提供する方法を示しています。
```
aws emr create-cluster --release-label emr-5.2.0 --service-role EMR_DefaultRole --ec2-attributes InstanceProfile=EMR_EC2_DefaultRole --instance-groups file://your/path/to/instancegroupconfig.json --auto-scaling-role EMR_AutoScaling_DefaultRole
```
次の構成ファイルのコンテンツ:
```
[
{
"InstanceCount": 1,
"Name": "MyMasterIG",
"InstanceGroupType": "MASTER",
"InstanceType": "m5.xlarge"
},
{
"InstanceCount": 2,
"Name": "MyCoreIG",
"InstanceGroupType": "CORE",
"InstanceType": "m5.xlarge",
"AutoScalingPolicy":
{
"Constraints":
{
"MinCapacity": 2,
"MaxCapacity": 10
},
"Rules":
[
{
"Name": "Default-scale-out",
"Description": "Replicates the default scale-out rule in the console for YARN memory.",
"Action":{
"SimpleScalingPolicyConfiguration":{
"AdjustmentType": "CHANGE_IN_CAPACITY",
"ScalingAdjustment": 1,
"CoolDown": 300
}
},
"Trigger":{
"CloudWatchAlarmDefinition":{
"ComparisonOperator": "LESS_THAN",
"EvaluationPeriods": 1,
"MetricName": "YARNMemoryAvailablePercentage",
"Namespace": "AWS/ElasticMapReduce",
"Period": 300,
"Threshold": 15,
"Statistic": "AVERAGE",
"Unit": "PERCENT",
"Dimensions":[
{
"Key" : "JobFlowId",
"Value" : "${emr.clusterId}"
}
]
}
}
}
]
}
}
]
```
### 自動スケーリングポリシーを持つインスタンスグループをクラスターに追加する
`create-cluster` を使用するときと同じ方法で、`--instance-groups` オプションを使用して、`add-instance-groups` コマンドでスケーリングポリシーの設定を指定できます。次の例では、インスタンスグループ設定がある JSON ファイル `instancegroupconfig.json` への参照を使用しています。
```
aws emr add-instance-groups --cluster-id j-1EKZ3TYEVF1S2 --instance-groups file://your/path/to/instancegroupconfig.json
```
### 既存のインスタンスグループに自動スケーリングポリシーを適用するか、適用されたポリシーを変更する
`aws emr put-auto-scaling-policy` コマンドを使用して自動スケーリングポリシーを既存のインスタンスグループに適用します。インスタンスグループは、自動スケーリング IAM ロールを使用するクラスターの一部である必要があります。次の例では、自動スケーリングポリシー設定を指定する JSON ファイル `autoscaleconfig.json` への参照を使用します。
```
aws emr put-auto-scaling-policy --cluster-id j-1EKZ3TYEVF1S2 --instance-group-id ig-3PLUZBA6WLS07 --auto-scaling-policy file://your/path/to/autoscaleconfig.json
```
`autoscaleconfig.json` ファイルのコンテンツは、前の例と同じスケールアウトルールを定義するもので、次に示されています。
```
{
"Constraints": {
"MaxCapacity": 10,
"MinCapacity": 2
},
"Rules": [{
"Action": {
"SimpleScalingPolicyConfiguration": {
"AdjustmentType": "CHANGE_IN_CAPACITY",
"CoolDown": 300,
"ScalingAdjustment": 1
}
},
"Description": "Replicates the default scale-out rule in the console for YARN memory",
"Name": "Default-scale-out",
"Trigger": {
"CloudWatchAlarmDefinition": {
"ComparisonOperator": "LESS_THAN",
"Dimensions": [{
"Key": "JobFlowId",
"Value": "${emr.clusterID}"
}],
"EvaluationPeriods": 1,
"MetricName": "YARNMemoryAvailablePercentage",
"Namespace": "AWS/ElasticMapReduce",
"Period": 300,
"Statistic": "AVERAGE",
"Threshold": 15,
"Unit": "PERCENT"
}
}
}]
}
```
### 自動スケーリングポリシーをインスタンスグループから削除する
```
aws emr remove-auto-scaling-policy --cluster-id j-1EKZ3TYEVF1S2 --instance-group-id ig-3PLUZBA6WLS07
```
### 自動スケーリングポリシー設定を取得する
`describe-cluster` コマンドは InstanceGroup ブロックのポリシー設定を取得します。たとえば、次のコマンドは、クラスター ID `j-1CWOHP4PI30VJ` を持つクラスターの設定を取得します。
```
aws emr describe-cluster --cluster-id j-1CWOHP4PI30VJ
```
このコマンドでは、次のサンプルアウトプットが生成されます。
```
{
"Cluster": {
"Configurations": [],
"Id": "j-1CWOHP4PI30VJ",
"NormalizedInstanceHours": 48,
"Name": "Auto Scaling Cluster",
"ReleaseLabel": "emr-5.2.0",
"ServiceRole": "EMR_DefaultRole",
"AutoTerminate": false,
"TerminationProtected": true,
"MasterPublicDnsName": "ec2-54-167-31-38.compute-1.amazonaws.com",
"LogUri": "s3n://aws-logs-232939870606-us-east-1/elasticmapreduce/",
"Ec2InstanceAttributes": {
"Ec2KeyName": "performance",
"AdditionalMasterSecurityGroups": [],
"AdditionalSlaveSecurityGroups": [],
"EmrManagedSlaveSecurityGroup": "sg-09fc9362",
"Ec2AvailabilityZone": "us-east-1d",
"EmrManagedMasterSecurityGroup": "sg-0bfc9360",
"IamInstanceProfile": "EMR_EC2_DefaultRole"
},
"Applications": [
{
"Name": "Hadoop",
"Version": "2.7.3"
}
],
"InstanceGroups": [
{
"AutoScalingPolicy": {
"Status": {
"State": "ATTACHED",
"StateChangeReason": {
"Message": ""
}
},
"Constraints": {
"MaxCapacity": 10,
"MinCapacity": 2
},
"Rules": [
{
"Name": "Default-scale-out",
"Trigger": {
"CloudWatchAlarmDefinition": {
"MetricName": "YARNMemoryAvailablePercentage",
"Unit": "PERCENT",
"Namespace": "AWS/ElasticMapReduce",
"Threshold": 15,
"Dimensions": [
{
"Key": "JobFlowId",
"Value": "j-1CWOHP4PI30VJ"
}
],
"EvaluationPeriods": 1,
"Period": 300,
"ComparisonOperator": "LESS_THAN",
"Statistic": "AVERAGE"
}
},
"Description": "",
"Action": {
"SimpleScalingPolicyConfiguration": {
"CoolDown": 300,
"AdjustmentType": "CHANGE_IN_CAPACITY",
"ScalingAdjustment": 1
}
}
},
{
"Name": "Default-scale-in",
"Trigger": {
"CloudWatchAlarmDefinition": {
"MetricName": "YARNMemoryAvailablePercentage",
"Unit": "PERCENT",
"Namespace": "AWS/ElasticMapReduce",
"Threshold": 75,
"Dimensions": [
{
"Key": "JobFlowId",
"Value": "j-1CWOHP4PI30VJ"
}
],
"EvaluationPeriods": 1,
"Period": 300,
"ComparisonOperator": "GREATER_THAN",
"Statistic": "AVERAGE"
}
},
"Description": "",
"Action": {
"SimpleScalingPolicyConfiguration": {
"CoolDown": 300,
"AdjustmentType": "CHANGE_IN_CAPACITY",
"ScalingAdjustment": -1
}
}
}
]
},
"Configurations": [],
"InstanceType": "m5.xlarge",
"Market": "ON_DEMAND",
"Name": "Core - 2",
"ShrinkPolicy": {},
"Status": {
"Timeline": {
"CreationDateTime": 1479413437.342,
"ReadyDateTime": 1479413864.615
},
"State": "RUNNING",
"StateChangeReason": {
"Message": ""
}
},
"RunningInstanceCount": 2,
"Id": "ig-3M16XBE8C3PH1",
"InstanceGroupType": "CORE",
"RequestedInstanceCount": 2,
"EbsBlockDevices": []
},
{
"Configurations": [],
"Id": "ig-OP62I28NSE8M",
"InstanceGroupType": "MASTER",
"InstanceType": "m5.xlarge",
"Market": "ON_DEMAND",
"Name": "Master - 1",
"ShrinkPolicy": {},
"EbsBlockDevices": [],
"RequestedInstanceCount": 1,
"Status": {
"Timeline": {
"CreationDateTime": 1479413437.342,
"ReadyDateTime": 1479413752.088
},
"State": "RUNNING",
"StateChangeReason": {
"Message": ""
}
},
"RunningInstanceCount": 1
}
],
"AutoScalingRole": "EMR_AutoScaling_DefaultRole",
"Tags": [],
"BootstrapActions": [],
"Status": {
"Timeline": {
"CreationDateTime": 1479413437.339,
"ReadyDateTime": 1479413863.666
},
"State": "WAITING",
"StateChangeReason": {
"Message": "Cluster ready after last step completed."
}
}
}
}
```
# 実行中の Amazon EMR クラスターのサイズを手動で変更する
、、または Amazon EMR API を使用して AWS マネジメントコンソール AWS CLI、実行中のクラスター内のコアおよびタスクインスタンスグループとインスタンスフリートからインスタンスを追加および削除できます。クラスターがインスタンスグループを使用する場合、明示的にインスタンス数を変更します。クラスターでインスタンスフリートを使用する場合、オンデマンドインスタンスとスポットインスタンスのターゲットユニットを変更できます。次に、インスタンスフリートは新しいターゲットに合わせてインスタンスを追加または削除します。詳細については、「[インスタンスフリートオプション](emr-instance-fleet.md#emr-instance-fleet-options)」を参照してください。アプリケーションは、インスタンスが利用可能になったらすぐに、新しくプロビジョニングされた Amazon EC2 インスタンスを使用してノードをホストできます。インスタンスを削除すると、Amazon EMR はジョブを中断しない方法でタスクを終了し、データ損失を防止します。詳細については、「[タスクの完了時に終了](emr-scaledown-behavior.md#emr-scaledown-terminate-task)」を参照してください。
## コンソールを使用してクラスターのサイズを変更する
Amazon EMR コンソールを使用して、実行中のクラスターのサイズを変更できます。
------
#### [ Console ]
**新しいコンソールを使用して既存のクラスターのインスタンス数を変更するには**
1. にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr) で Amazon EMR コンソールを開きます。
1. 左側のナビゲーションペインの **[EMR on EC2]** で **[クラスター]** を選択し、更新するクラスターを選択します。クラスターは実行中である必要があります。プロビジョニングしているクラスターや終了したクラスターのサイズを変更することはできません。
1. クラスターの詳細ページの **[インスタンス]** タブで、**[インスタンスグループ]** パネルを表示します。
1. 既存のインスタンスグループのサイズを変更するには、サイズを変更するコアインスタンスグループまたはタスクインスタンスグループの横にあるラジオボタンを選択し、**[インスタンスグループのサイズを変更]** を選択します。インスタンスグループの新しいインスタンス数を指定し、**[サイズ変更]** を選択します。
**注記**
実行中のインスタンスグループのサイズを縮小することを選択した場合、Amazon EMR はデータ損失を最小限に抑えるため、グループから削除するインスタンスをインテリジェントに選択します。サイズ変更アクションをより細かく管理するには、インスタンスグループの **[ID]** を選択し、削除するインスタンスを選択して、**[削除]** オプションを使用します。インテリジェントなスケールダウン動作の詳細については、「[Amazon EMR クラスターのクラスタースケールダウンオプション](emr-scaledown-behavior.md)」を参照してください。
1. サイズ変更アクションをキャンセルする場合は、ステータスが **[サイズ変更中]** のインスタンスグループのラジオボタンを選択し、アクションのリストから **[サイズ変更を停止]** を選択します。
1. ワークロードの増加に応じて 1 つまたは複数のタスクインスタンスグループをクラスターに追加するには、リストアクションから **[タスクインスタンスグループを追加]** を選択します。Amazon EC2 インスタンスタイプを選択し、タスクグループのインスタンス数を入力して、**[タスクインスタンスグループを追加]** を選択すると、クラスターの **[インスタンスグループ]** パネルに戻ります。
------
ノードの数を変更すると、インスタンスグループの [**Status (ステータス)**] が更新されます。変更リクエストが完了すると、[**Status (ステータス)**] が [**Running (実行中)**] になります。
## を使用してクラスターのサイズを変更する AWS CLI
を使用して AWS CLI 、実行中のクラスターのサイズを変更できます。タスクノードの数は増減することができ、実行中のクラスターのコアノードの数を増やすことができます。 AWS CLI または API を使用して、コアインスタンスグループのインスタンスをシャットダウンすることもできます。そうする場合は、注意が必要です。コアインスタンスグループのインスタンスをシャッドダウンすると、データが失われる可能性があり、インスタンスは自動的に置換されません。
コアグループおよびタスクグループのサイズの変更以外に、 AWS CLIを使用して、実行中のクラスターに 1 つ以上のタスクインスタンスグループを追加することもできます。
**でインスタンス数を変更してクラスターのサイズを変更するには AWS CLI**
コアグループまたはタスクグループにインスタンスを追加でき、 `InstanceCount` パラメータを使用して サブコマンドを使用して AWS CLI `modify-instance-groups`タスクグループからインスタンスを削除できます。コアグループまたはタスクグループにインスタンスを追加するには、`InstanceCount` を増やします。タスクグループのインスタンス数を減らすには、`InstanceCount` を減らします。タスクグループのインスタンス数を 0 に変更すると、すべてのインスタンスが削除されますが、インスタンスグループは削除されません。
+ タスクインスタンスグループのインスタンス数を 3 個から 4 個に増やすには、次のコマンドを入力し、*ig-31JXXXXXXBTO* をインスタンスグループ ID に置き換えます。
```
aws emr modify-instance-groups --instance-groups InstanceGroupId=ig-31JXXXXXXBTO,InstanceCount=4
```
`InstanceGroupId` を取得するには、`describe-cluster` サブコマンドを使用します。出力は、各インスタンスグループの ID が含まれている、`Cluster` という名前の JSON オブジェクトです。このコマンドを使用するには、クラスター ID が必要です (`aws emr list-clusters` コマンドまたはコンソールを使用して取得できます)。インスタンスグループ ID を取得するには、次のコマンドを入力し、*j-2AXXXXXXGAPLF* をクラスター ID に置き換えます。
```
aws emr describe-cluster --cluster-id j-2AXXXXXXGAPLF
```
では AWS CLI、 `--modify-instance-groups`サブコマンドを使用してコアインスタンスグループのインスタンスを終了することもできます。
**警告**
`EC2InstanceIdsToTerminate` の指定は注意して行う必要があります。インスタンスは、そこで実行中のアプリケーションのステータスにかかわらず即時削除され、自動的には置き換えられません。これは、クラスターの [**Scale down behavior**] 設定とは無関係です。この方法でインスタンスを削除すると、データ損失や、予測不可能なクラスター動作が発生する可能性があります。
特定のインスタンスを終了するには、インスタンスグループ ID (`aws emr describe-cluster --cluster-id` サブコマンドによって返されます) とインスタンス ID（`aws emr list-instances --cluster-id` サブコマンドによって返されます）が必要です。次のコマンドを入力し、*ig-6RXXXXXX07SA* をインスタンスグループ ID に置き換え、*i-f9XXXXf2* をインスタンス ID に置き換えます。
```
1. aws emr modify-instance-groups --instance-groups InstanceGroupId=ig-6RXXXXXX07SA,EC2InstanceIdsToTerminate=i-f9XXXXf2
```
での Amazon EMR コマンドの使用の詳細については AWS CLI、「」を参照してください[https://docs.aws.amazon.com/cli/latest/reference/emr](https://docs.aws.amazon.com/cli/latest/reference/emr)。
**を使用してタスクインスタンスグループを追加してクラスターのサイズを変更するには AWS CLI**
では AWS CLI、 `--add-instance-groups`サブコマンドを使用して 1～48 個のタスクインスタンスグループをクラスターに追加できます。タスクインスタンスグループは、プライマリインスタンスグループとコアインスタンスグループが含まれるクラスターにのみ追加できます。を使用すると AWS CLI、 `--add-instance-groups`サブコマンドを使用するたびに最大 5 つのタスクインスタンスグループを追加できます。
1. クラスターに 1 つのタスクインスタンスグループを追加するには、次のコマンドを入力し、*j-JXBXXXXXX37R* をクラスター ID に置き換えます。
```
1. aws emr add-instance-groups --cluster-id j-JXBXXXXXX37R --instance-groups InstanceCount=6,InstanceGroupType=task,InstanceType=m5.xlarge
```
1. クラスターに複数のタスクインスタンスグループを追加するには、次のコマンドを入力し、*j-JXBXXXXXX37R* をクラスター ID に置き換えます。1 つのコマンドで最大 5 個のタスクインスタンスグループを追加できます。
```
aws emr add-instance-groups --cluster-id j-JXBXXXXXX37R --instance-groups InstanceCount=6,InstanceGroupType=task,InstanceType=m5.xlarge InstanceCount=10,InstanceGroupType=task,InstanceType=m5.xlarge
```
での Amazon EMR コマンドの使用の詳細については AWS CLI、「」を参照してください[https://docs.aws.amazon.com/cli/latest/reference/emr](https://docs.aws.amazon.com/cli/latest/reference/emr)。
## サイズ変更を中断する
Amazon EMR バージョン 4.1.0 以降を使用して、既存のサイズ変更操作中に、サイズ変更を実行できます。さらに、既に提出されたサイズ変更リクエストを中止したり、新規リクエストを提出して先のリクエストの処理が終了するのを待たずに上書きすることもできます。また、既存のサイズ変更をコンソールから中止することも、クラスターのターゲット数を現在の数とした `ModifyInstanceGroups` API 呼び出しを使用して中止することも可能です。
以下のスクリーンショットには、[**Stop**] を選択することで中止することのできる、サイズ変更中のタスクインスタンスグループが示されています。
![\[Task instance group showing resizing status with options to resize or stop.\]](http://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/images/resize-stop.png)
**を使用してサイズ変更を中断するには AWS CLI**
を使用して、 `modify-instance-groups`サブコマンドでサイズ変更 AWS CLI を停止できます。インスタンスグループに 6 つのインスタンスがあり、これを 10 に増やしたいとします。そして、その後このリクエストをキャンセルしたいとします:
+ 最初のリクエスト:
```
aws emr modify-instance-groups --instance-groups InstanceGroupId=ig-myInstanceGroupId,InstanceCount=10
```
最初のリクエストを中止する 2 番目のリクエスト:
```
aws emr modify-instance-groups --instance-groups InstanceGroupId=ig-myInstanceGroupId,InstanceCount=6
```
**注記**
この処理は非同期であるため、後から申請したリクエストが反映される前に、以前の API リクエストに関したインスタンスの数の変更が表示される場合があります。サイズを縮小する場合、現行のノードで作業中のインスタンスグループのサイズは、それらのノードにおける作業が完了するまで縮小されないことがあります。
## 停止状態
新しいクラスターノードを起動しようとしているときに、多数のエラーが発生すると、インスタンスグループが停止状態になります。たとえば、ブートストラップアクションの実行中に新しいノードが失敗した場合、インスタンスグループは *SUSPENDED* 状態になり、新しいノードのプロビジョニングが続行されなくなります。基本となる問題を解決したら、クラスターのインスタンスグループで必要な数のノードをリセットしてください。その後、インスタンスグループはノードの割り当てを再開します。インスタンスグループを変更すると、Amazon EMR は再度ノードをプロビジョニングしようとします。実行中のノードについては再開または終了しません。
では AWS CLI、 `list-instances` サブコマンドは、 `describe-cluster` サブコマンドと同様に、すべてのインスタンスとその状態を返します。Amazon EMR によってインスタンスグループのエラーが検出されると、グループの状態が `SUSPENDED` に変更されます。
**を使用して SUSPENDED 状態のクラスターをリセットするには AWS CLI**
クラスター内のインスタンスの状態を表示するには、`describe-cluster` サブコマンドを入力し、`--cluster-id` パラメータを指定します。
+ クラスター内のすべてのインスタンスとインスタンスグループについての情報を表示するには、次のコマンドを入力し、*j-3KVXXXXXXY7UG* をクラスター ID に置き換えます。
```
1. aws emr describe-cluster --cluster-id j-3KVXXXXXXY7UG
```
出力には、インスタンスグループとインスタンスの状態に関する情報が表示されます:
```
1. {
2. "Cluster": {
3. "Status": {
4. "Timeline": {
5. "ReadyDateTime": 1413187781.245,
6. "CreationDateTime": 1413187405.356
7. },
8. "State": "WAITING",
9. "StateChangeReason": {
10. "Message": "Waiting after step completed"
11. }
12. },
13. "Ec2InstanceAttributes": {
14. "Ec2AvailabilityZone": "us-west-2b"
15. },
16. "Name": "Development Cluster",
17. "Tags": [],
18. "TerminationProtected": false,
19. "RunningAmiVersion": "3.2.1",
20. "NormalizedInstanceHours": 16,
21. "InstanceGroups": [
22. {
23. "RequestedInstanceCount": 1,
24. "Status": {
25. "Timeline": {
26. "ReadyDateTime": 1413187775.749,
27. "CreationDateTime": 1413187405.357
28. },
29. "State": "RUNNING",
30. "StateChangeReason": {
31. "Message": ""
32. }
33. },
34. "Name": "MASTER",
35. "InstanceGroupType": "MASTER",
36. "InstanceType": "m5.xlarge",
37. "Id": "ig-3ETXXXXXXFYV8",
38. "Market": "ON_DEMAND",
39. "RunningInstanceCount": 1
40. },
41. {
42. "RequestedInstanceCount": 1,
43. "Status": {
44. "Timeline": {
45. "ReadyDateTime": 1413187781.301,
46. "CreationDateTime": 1413187405.357
47. },
48. "State": "RUNNING",
49. "StateChangeReason": {
50. "Message": ""
51. }
52. },
53. "Name": "CORE",
54. "InstanceGroupType": "CORE",
55. "InstanceType": "m5.xlarge",
56. "Id": "ig-3SUXXXXXXQ9ZM",
57. "Market": "ON_DEMAND",
58. "RunningInstanceCount": 1
59. }
60. ...
61. }
```
特定のインスタンスグループについての情報を表示するには、`list-instances` サブコマンドを入力し、`--cluster-id` および `--instance-group-types` パラメータを指定します。プライマリ、コアまたはタスクグループの情報を表示できます。
```
1. aws emr list-instances --cluster-id j-3KVXXXXXXY7UG --instance-group-types "CORE"
```
`modify-instance-groups` 状態のクラスターをリセットするには、`--instance-groups` サブコマンドを使用し、`SUSPENDED` パラメータを指定します。インスタンスグループ ID は、`describe-cluster` サブコマンドによって返されます。
```
1. aws emr modify-instance-groups --instance-groups InstanceGroupId=ig-3SUXXXXXXQ9ZM,InstanceCount=3
```
## クラスターサイズを縮小する場合の考慮事項
実行中のクラスターのサイズを縮小する場合は、以下の Amazon EMR の動作とベストプラクティスについて考慮してください。
+ 進行中のジョブへの影響を減らすため、Amazon EMR は削除するインスタンスをインテリジェントに選択します。クラスターのスケールダウン動作の詳細については、「Amazon EMR 管理ガイド」の「[タスクの完了時に終了](emr-scaledown-behavior.md#emr-scaledown-terminate-task)」を参照してください。
+ クラスターのサイズをスケールダウンすると、Amazon EMR は削除したインスタンスから残っているインスタンスにデータをコピーします。グループに残っているインスタンスに、このデータを保存するのに十分なストレージ容量があることを確認してください。
+ Amazon EMR は、グループ内のインスタンスの HDFS を廃止しようと試みます。クラスターのサイズを縮小する前に、HDFS への書き込み I/O を最小限に抑えることをお勧めします。
+ クラスターのサイズ縮小時に最も細かく管理するには、コンソールでクラスターを表示して **[インスタンス]** タブに移動します。サイズを変更するインスタンスグループの **[ID]** を選択します。次に、削除する特定のインスタンスに対して **[削除]** オプションを使用します。
# Amazon EMR の容量を制御するためのプロビジョニングタイムアウトの設定
インスタンスフリートを使用することにより、*プロビジョニングのタイムアウト*を設定できます。プロビジョニングのタイムアウトでは、クラスターの起動時やクラスターのスケーリング操作時に、クラスターが指定された時間のしきい値を超えた場合、インスタンス容量のプロビジョニングを停止するよう Amazon EMR に指示します。以下のトピックでは、クラスターの起動とクラスターのスケールアップ操作に対してプロビジョニングのタイムアウトを設定する方法について説明します。
**Topics**
+ [Amazon EMR でクラスター起動のプロビジョニングのタイムアウトを設定する](emr-provisioning-timeout-launch.md)
+ [Amazon EMR でクラスターサイズ変更のプロビジョニングのタイムアウト期間をカスタマイズする](emr-provisioning-timeout-resize.md)
# Amazon EMR でクラスター起動のプロビジョニングのタイムアウトを設定する
クラスター内の各フリートにスポットインスタンスをプロビジョニングするためのタイムアウト期間を定義できます。Amazon EMR がスポット容量をプロビジョニングできない場合は、代わりにクラスターを終了させるか、オンデマンド容量をプロビジョニングするかを選択できます。クラスターのサイズ変更プロセス中にタイムアウト期間が終了すると、Amazon EMR はプロビジョニングされていないスポットリクエストをキャンセルします。プロビジョニングされていないスポットインスタンスは、オンデマンド容量に転送されません。
Amazon EMR コンソールでクラスター起動のプロビジョニングのタイムアウト期間をカスタマイズするには、次の手順を実行します。
------
#### [ Console ]
**コンソールを使用してクラスターの作成時にプロビジョニングのタイムアウトを設定するには**
1. にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr) で Amazon EMR コンソールを開きます。
1. 左側のナビゲーションペインの **[EMR on EC2]** で、**[クラスター]** を選択し、**[クラスターの作成]** を選択します
1. **[クラスターの作成]** ページで **[クラスター設定]** に移動し、**[インスタンスフリート]** を選択します。
1. **[クラスターのスケーリングとプロビジョニングのオプション]** で、コアフリートとタスクフリートのスポットサイズを指定します。
1. **[スポットタイムアウトの設定]** で、**[スポットタイムアウト後にクラスターを終了する]** または **[スポットタイムアウト後にオンデマンドに切り替える]** のいずれかを選択します。次に、スポットインスタンスのプロビジョニングのタイムアウト期間を指定します。デフォルト値は 1 時間です。
1. クラスターに適用するその他のオプションを選択します。
1. 設定したタイムアウトを使用してクラスターを起動するには、**[クラスターの作成]** を選択します。
------
#### [ AWS CLI ]
**`create-cluster` コマンドでプロビジョニングのタイムアウトを指定するには**
```
aws emr create-cluster \
--release-label emr-5.35.0 \
--service-role EMR_DefaultRole \
--ec2-attributes '{"InstanceProfile":"EMR_EC2_DefaultRole","SubnetIds":["subnet-XXXXX"]}' \
--instance-fleets '[{"InstanceFleetType":"MASTER","TargetOnDemandCapacity":1,"TargetSpotCapacity":0,"LaunchSpecifications":{"OnDemandSpecification":{"AllocationStrategy":"lowest-price"}},"InstanceTypeConfigs":[{"WeightedCapacity":1,"EbsConfiguration":{"EbsBlockDeviceConfigs":[{"VolumeSpecification":{"SizeInGB":32,"VolumeType":"gp2"},"VolumesPerInstance":2}]},"BidPriceAsPercentageOfOnDemandPrice":100,"InstanceType":"m5.xlarge"}],"Name":"Master - 1"},{"InstanceFleetType":"CORE","TargetOnDemandCapacity":1,"TargetSpotCapacity":1,"LaunchSpecifications":{"SpotSpecification":{"TimeoutDurationMinutes":120,"TimeoutAction":"SWITCH_TO_ON_DEMAND"},"OnDemandSpecification":{"AllocationStrategy":"lowest-price"}},"InstanceTypeConfigs":[{"WeightedCapacity":1,"EbsConfiguration":{"EbsBlockDeviceConfigs":[{"VolumeSpecification":{"SizeInGB":32,"VolumeType":"gp2"},"VolumesPerInstance":2}]},"BidPriceAsPercentageOfOnDemandPrice":1,"InstanceType":"m5.xlarge"}],"Name":"Core - 2"}]'
```
------
# Amazon EMR でクラスターサイズ変更のプロビジョニングのタイムアウト期間をカスタマイズする
クラスター内の各フリートにスポットインスタンスをプロビジョニングするためのタイムアウト期間を定義できます。Amazon EMR はスポット容量をプロビジョニングできない場合、サイズ変更リクエストをキャンセルし、追加のスポット容量をプロビジョニングしようとする試みを停止します。クラスター作成時にタイムアウトを設定できます。実行中のクラスターでは、タイムアウトを追加や更新できます。
タイムアウト期間が終了すると、Amazon EMR は自動的に Amazon CloudWatch Events ストリームにイベントを送信します。CloudWatch では、指定パターンに応じてイベントに一致するルールを作成し、イベントをターゲットにルーティングして、アクションを実行できます。例えば、E メール通知を送信するようにルールを設定できます。ルールの作成方法の詳細については、「[CloudWatch を使用して Amazon EMR イベントに対するルールを作成する](emr-events-cloudwatch-console.md)」を参照してください。さまざまなイベントの詳細については、「[インスタンスフリートの状態変更イベント](emr-manage-cloudwatch-events.md#emr-cloudwatch-instance-fleet-events)」を参照してください。
## クラスターのサイズ変更におけるプロビジョニングのタイムアウトの例
** AWS CLIでサイズ変更のプロビジョニングのタイムアウトを指定する**
次の例では、`create-cluster` コマンドを使用して、サイズ変更のプロビジョニングのタイムアウトを追加しています。
```
aws emr create-cluster \
--release-label emr-5.35.0 \
--service-role EMR_DefaultRole \
--ec2-attributes '{"InstanceProfile":"EMR_EC2_DefaultRole","SubnetIds":["subnet-XXXXX"]}' \
--instance-fleets '[{"InstanceFleetType":"MASTER","TargetOnDemandCapacity":1,"TargetSpotCapacity":0,"InstanceTypeConfigs":[{"WeightedCapacity":1,"EbsConfiguration":{"EbsBlockDeviceConfigs":[{"VolumeSpecification":{"SizeInGB":32,"VolumeType":"gp2"},"VolumesPerInstance":2}]},"BidPriceAsPercentageOfOnDemandPrice":100,"InstanceType":"m5.xlarge"}],"Name":"Master - 1"},{"InstanceFleetType":"CORE","TargetOnDemandCapacity":1,"TargetSpotCapacity":1,"LaunchSpecifications":{"SpotSpecification":{"TimeoutDurationMinutes":120,"TimeoutAction":"SWITCH_TO_ON_DEMAND"},"OnDemandSpecification":{"AllocationStrategy":"lowest-price"}},"ResizeSpecifications":{"SpotResizeSpecification":{"TimeoutDurationMinutes":20},"OnDemandResizeSpecification":{"TimeoutDurationMinutes":25}},"InstanceTypeConfigs":[{"WeightedCapacity":1,"EbsConfiguration":{"EbsBlockDeviceConfigs":[{"VolumeSpecification":{"SizeInGB":32,"VolumeType":"gp2"},"VolumesPerInstance":2}]},"BidPriceAsPercentageOfOnDemandPrice":1,"InstanceType":"m5.xlarge"}],"Name":"Core - 2"}]'
```
次の例では、`modify-instance-fleet` コマンドを使用して、サイズ変更のプロビジョニングのタイムアウトを追加しています。
```
aws emr modify-instance-fleet \
--cluster-id j-XXXXXXXXXXXXX \
--instance-fleet '{"InstanceFleetId":"if-XXXXXXXXXXXX","ResizeSpecifications":{"SpotResizeSpecification":{"TimeoutDurationMinutes":30},"OnDemandResizeSpecification":{"TimeoutDurationMinutes":60}}}' \
--region us-east-1
```
次の例では、`add-instance-fleet-command` を使用して、サイズ変更のプロビジョニングのタイムアウトを追加しています。
```
aws emr add-instance-fleet \
--cluster-id j-XXXXXXXXXXXXX \
--instance-fleet '{"InstanceFleetType":"TASK","TargetOnDemandCapacity":1,"TargetSpotCapacity":0,"InstanceTypeConfigs":[{"WeightedCapacity":1,"EbsConfiguration":{"EbsBlockDeviceConfigs":[{"VolumeSpecification":{"SizeInGB":32,"VolumeType":"gp2"},"VolumesPerInstance":2}]},"BidPriceAsPercentageOfOnDemandPrice":100,"InstanceType":"m5.xlarge"}],"Name":"TaskFleet","ResizeSpecifications":{"SpotResizeSpecification":{"TimeoutDurationMinutes":30},"OnDemandResizeSpecification":{"TimeoutDurationMinutes":35}}}' \
--region us-east-1
```
**でサイズ変更と起動のプロビジョニングタイムアウトを指定する AWS CLI**
次の例では、`create-cluster` コマンドを使用して、サイズ変更と起動のプロビジョニングのタイムアウトを追加しています。
```
aws emr create-cluster \
--release-label emr-5.35.0 \
--service-role EMR_DefaultRole \
--ec2-attributes '{"InstanceProfile":"EMR_EC2_DefaultRole","SubnetIds":["subnet-XXXXX"]}' \
--instance-fleets '[{"InstanceFleetType":"MASTER","TargetOnDemandCapacity":1,"TargetSpotCapacity":0,"LaunchSpecifications":{"OnDemandSpecification":{"AllocationStrategy":"lowest-price"}},"InstanceTypeConfigs":[{"WeightedCapacity":1,"EbsConfiguration":{"EbsBlockDeviceConfigs":[{"VolumeSpecification":{"SizeInGB":32,"VolumeType":"gp2"},"VolumesPerInstance":2}]},"BidPriceAsPercentageOfOnDemandPrice":100,"InstanceType":"m5.xlarge"}],"Name":"Master - 1"},{"InstanceFleetType":"CORE","TargetOnDemandCapacity":1,"TargetSpotCapacity":1,"LaunchSpecifications":{"SpotSpecification":{"TimeoutDurationMinutes":120,"TimeoutAction":"SWITCH_TO_ON_DEMAND"},"OnDemandSpecification":{"AllocationStrategy":"lowest-price"}},"ResizeSpecifications":{"SpotResizeSpecification":{"TimeoutDurationMinutes":20},"OnDemandResizeSpecification":{"TimeoutDurationMinutes":25}},"InstanceTypeConfigs":[{"WeightedCapacity":1,"EbsConfiguration":{"EbsBlockDeviceConfigs":[{"VolumeSpecification":{"SizeInGB":32,"VolumeType":"gp2"},"VolumesPerInstance":2}]},"BidPriceAsPercentageOfOnDemandPrice":1,"InstanceType":"m5.xlarge"}],"Name":"Core - 2"}]'
```
## サイズ変更のプロビジョニングのタイムアウトに関する考慮事項
インスタンスフリートに対してクラスターのプロビジョニングのタイムアウトを設定するときは、以下の動作を考慮してください。
+ スポットインスタンスとオンデマンドインスタンスの両方でプロビジョニングのタイムアウトを設定できます。プロビジョニングの最小タイムアウトは 5 分です。プロビジョニングの最大タイムアウトは 7 日間です。
+ プロビジョニングのタイムアウトは、インスタンスフリートを使用する EMR クラスターにのみ設定できます。コアフリートとタスクフリートはそれぞれ個別に設定する必要があります。
+ クラスターの作成時に、プロビジョニングのタイムアウトを設定できます。実行中のクラスターに対してタイムアウトを追加したり、既存のタイムアウトを更新したりできます。
+ 複数のサイズ変更操作を送信すると、Amazon EMR は各サイズ変更操作のプロビジョニングのタイムアウトを追跡します。例えば、クラスターのプロビジョニングのタイムアウトを *60* 分に設定します。*次に、時間 T1* にサイズ変更操作 *R1* を送信します。時間 *T2* に 2 つ目のサイズ変更操作 *R2* を送信します。R1 のプロビジョニングのタイムアウト期限は *T1 \$1 60 分*です。R2 のプロビジョニングのタイムアウト期限は *T2 \$1 60 分*です。
+ タイムアウト時間が過ぎる前に新しいスケールアップのサイズ変更操作を送信した場合、Amazon EMR は EMR クラスターの容量をプロビジョニングし続けようとします。
# Amazon EMR クラスターのクラスタースケールダウンオプション
**注記**
スケールダウン動作オプションは、Amazon EMR リリース 5.10.0 以降でサポートされなくなりました。Amazon EC2 に秒単位の請求が導入されたため、Amazon EMR クラスターのデフォルトのスケールダウン動作は、タスクの完了時に終了するようになりました。
Amazon EMR リリース 5.1.0 から 5.9.1 のスケールダウン動作には、Amazon EC2 請求のインスタンス時間の境界での終了と、タスク完了時の終了の 2 つのオプションがあります。Amazon EMR リリース 5.10.0 以降では、Amazon EC2 に秒単位の請求が導入されたため、インスタンス時間の境界での終了の設定は廃止されています。このオプションが使用できないバージョンでは、インスタンス時間の境界での終了を指定することはお勧めされていません。
**警告**
を使用して `modify-instance-groups`で AWS CLI を発行する場合`EC2InstanceIdsToTerminate`、これらのインスタンスは、これらの設定を考慮せずに、それらで実行されているアプリケーションのステータスに関係なく、すぐに終了します。この方法でインスタンスを削除すると、データ損失や、予測不可能なクラスター動作が発生する可能性があります。
タスク完了時の終了を指定すると、Amazon EMR は、Amazon EC2 インスタンスを削除する前にタスクを拒否リストに登録し、ノードから削除します。いずれの動作を指定しても、HDFS の破損につながる可能性があれば、Amazon EMR はコアインスタンスグループの Amazon EC2 インスタンスを削除しません。
## タスクの完了時に終了
Amazon EMR では、ワークロードに影響を与えずにクラスターをスケールダウンできます。Amazon EMR は、データを失ったりジョブを中断したりすることなく、サイズ縮小処理中にコアノードとタスクノードの YARN、HDFS、およびその他のデーモンを適切に停止しようとします。Amazon EMR は、グループに割り当てられた作業が完了し、アイドル状態の場合にのみインスタンスグループのサイズを縮小します。YARN NodeManager のグレースフルな廃止の場合、ノードが廃止を待つ時間を手動で調整できます。
**注記**
正常に廃止されると、データが失われる可能性があります。必ずデータをバックアップしてください。
**重要**
HDFS データは、異常なコアインスタンスの正常な置換中に完全に失われる可能性があります。常にデータをバックアップすることをお勧めします。
この時間は、`YARN-site` 設定分類のプロパティを使用して設定します。5.12.0 以降 Amazon EMR リリースを使用する場合、`YARN.resourcemanager.nodemanager-graceful-decommission-timeout-secs` プロパティを指定します。以前の Amazon EMR リリースを使用する場合、`YARN.resourcemanager.decommissioning.timeout` プロパティを指定します。
停止時間がタイムアウトした時点で実行中のコンテナーまたは YARN アプリケーションがあった場合、そのノードは強制的に停止され、実行中のコンテナーは YARN によって他のノードで再スケジュールされます。デフォルト値は 3,600 秒 (1 時間) です。このタイムアウトを任意の高い値に設定することで、グレースフルな縮小を強制的に行い、長い時間待機させることができます。詳細については、Apache Hadoop ドキュメントの「[Graceful Decommission of YARN Nodes](http://hadoop.apache.org/docs/stable/hadoop-yarn/hadoop-yarn-site/GracefulDecommission.html)」を参照してください。
### タスクノードグループ
Amazon EMR は、ステップやアプリケーションに対して実行されているタスクがないインスタンスをインテリジェントに選択し、それらのインスタンスを最初にクラスターから削除します。クラスター内のすべてのインスタンスが使用されている場合、Amazon EMR はインスタンスのタスクが完了するの待ってからクラスターから削除します。デフォルトの待機時間は 1 時間です。この値は `YARN.resourcemanager.decommissioning.timeout` 設定で変更できます。Amazon EMR では、この新しい設定が動的に使用されます。この値を任意の大きな数に設定することで、Amazon EMR がタスクを終了することなく、クラスターのサイズを縮小できます。
### コアノードグループ
コアノードでは、インスタンスグループのサイズを縮小するのに YARN NodeManager および HDFS DataNode デーモンの両方を停止する必要があります。YARN では、グレースフルなサイズ縮小により、停止の対象となるノードは、保留中や未完了のコンテナまたはアプリケーションがない場合にのみ `DECOMMISSIONED` 状態に移行します。停止作業開始時においてノードでコンテナーが実行されていない場合、停止作業は即終了します。
HDFS では、グレースフルなサイズ縮小により、HDFS のターゲット容量にすべての既存ブロックが収まるよう十分な大きさが確保されます。ターゲット容量の大きさが十分でない場合、残りのノードが HDFS にある現在のデータを処理できるように、一部のコアインスタンスのみが停止されます。ノードが完全に停止されるよう、HDFS に十分な容量があるよう確認してください。また、インスタンスグループの削減を試みる前に、書き込み I/O を最小限に抑えるようにしてください。書き込み I/O が多すぎると、サイズ変更操作の完了が遅れる可能性があります。
もう 1 つの制限は、デフォルトのレプリケーション係数です。`dfs.replication`内部`/etc/hadoop/conf/hdfs-site`。Amazon EMR では、クラスターの作成時に、クラスター内のインスタンス数に基づいて値が設定されます。インスタンス数が 1～3 の場合は `1`、4～9 の場合は `2`、10 以上の場合は `3` となります。
**警告**
ノードが 4 つ未満のクラスターで `dfs.replication` を 1 に設定すると、単一ノードがダウンした場合に HDFS データが失われる可能性があります。本番環境のワークロードには、少なくとも 4 つのコアノードを持つクラスターを使用することをお勧めします。
Amazon EMR では、クラスターはコアノードを `dfs.replication` 未満にスケールすることはできません。例えば、`dfs.replication = 2` の場合、コアノードの最小数は 2 です。
マネージドスケーリングや自動スケーリングを使用する場合や、クラスターのサイズを手動で変更する場合は、`dfs.replication` を 2 以上に設定することをお勧めします。
グレースフルな縮小では、コアノードを HDFS のレプリケーション係数未満に減らすことはできません。これは、レプリカが不十分な場合に HDFS がファイルを閉じることができるようにするためです。この制限を回避するには、レプリケーション係数を低く設定し直してから NameNode デーモンを再起動します。
# Amazon EMR のスケールダウン動作を設定します。
**注記**
インスタンス時間で終了するスケールダウン動作オプションは、Amazon EMR リリース 5.10.0 以降でサポートされなくなりました。次のスケールダウン動作オプションは、リリース 5.1.0 から 5.9.1 の Amazon EMR コンソールにのみ表示されます。
AWS マネジメントコンソール、 AWS CLI、または Amazon EMR API を使用して、クラスターの作成時にスケールダウン動作を設定できます。
------
#### [ Console ]
**コンソールを使用してスケールダウン動作を設定するには**
1. にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr) で Amazon EMR コンソールを開きます。
1. 左側のナビゲーションペインの **[EMR on EC2]** で、**[クラスター]** を選択し、**[クラスターの作成]** を選択します
1. **[クラスターのスケーリングとプロビジョニングのオプション]** セクションで、**[カスタム自動スケーリングを使用]** を選択します。**[カスタムオートスケーリングポリシー]** で、**プラスアクションボタン**を選択して **[スケールイン]** ポリシーを追加します。**[スケールイン]** ポリシーと **[スケールアウト]** ポリシーの両方を追加することをお勧めします。ポリシーを 1 セットのみ追加すると、Amazon EMR は一方向スケーリングのみを実行し、他のアクションを手動で実行する必要があります。
1. クラスターに適用するその他のオプションを選択します。
1. クラスターを起動するには、**[クラスターの作成]** を選択します。
------
#### [ AWS CLI ]
**を使用してスケールダウン動作を設定するには AWS CLI**
+ `--scale-down-behavior` オプションを使用して、`TERMINATE_AT_INSTANCE_HOUR` または `TERMINATE_AT_TASK_COMPLETION` のいずれかを指定します。
------