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

# Amazon EMR ノード割り当て戦略とシナリオを把握する
<a name="managed-scaling-allocation-strategy"></a>

このセクションでは、Amazon EMR Managed Scaling で使用できるノード割り当て戦略と一般的なスケーリングシナリオの概要について説明します。

## ノード割り当て戦略
<a name="node-allocation-strategy"></a>

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 はインスタンスの削除をキャンセルし、スケールアップ操作を実行します。

## ノード割り当てに関する考慮事項
<a name="node-allocation-considerations"></a>

スポットの再利用時に HDFS データが失われないように、コアノードに対してオンデマンド購入オプションを使用することをお勧めします。タスクノードに対してスポット購入オプションを使用すると、タスクノードにスポットインスタンスを追加するときのコストが削減され、ジョブ実行が高速になります。

## ノード割り当てシナリオ
<a name="node-allocation-scenarios"></a>

最大、最小、オンデマンド制限、および最大コアノードの各パラメータをさまざまな組み合わせで、セットアップすることで、ニーズに基づいてさまざまなスケーリングシナリオを作成できます。

**シナリオ 1: コアノードのみをスケーリングする**

コアノードのみをスケーリングするには、マネージドスケーリングパラメータが次の要件を満たしている必要があります。
+ オンデマンド制限が最大限度と等しいこと。
+ 最大コアノードが最大限度と等しいこと。

オンデマンド制限と最大コアノードのパラメータが指定されていないときは、両方のパラメータがデフォルトで最大限度に設定されます。

このシナリオは、ノードラベルでマネージドスケーリングを使用し、アプリケーションプロセスを `CORE` ノードでのみ実行するように制限する場合には適用されません。マネージドスケーリングはエグゼキューターの需要に対応するためにタスクノードをスケーリングするからです。

コアノードのみをスケーリングするシナリオの例を次に示します。


<table>
<thead>
  <tr><th>クラスターの初期状態</th><th>スケーリングパラメータ</th><th>スケーリングの動作</th></tr>
</thead>
<tbody>
  <tr><td>**インスタンスグループ**<br />コア:1 オンデマンド<br />タスク:1 オンデマンドと 1 スポット</td><td>`UnitType`: Instances<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 20 <br />`MaximumCoreCapacityUnits`: 20</td><td rowspan="2">オンデマンドタイプを使用して、コアノードで 1 ～ 20 個のインスタンスまたはインスタンスフリートユニットをスケーリングします。タスクノードのスケーリングはありません。<br />ノードラベルでマネージドスケーリングを使用し、アプリケーションプロセスを `ON_DEMAND` ノードに制限すると、クラスターは、需要のタイプに応じて、`On-Demand` または `Spot` タイプを使用して `CORE` ノードで 1～20 個のインスタンスまたはインスタンスフリートユニットをスケーリングします。</td></tr>
  <tr><td>**インスタンスフリート**<br />コア:1 オンデマンド<br />タスク:1 オンデマンドと 1 スポット</td><td>UnitType: InstanceFleetUnits<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 20 <br />`MaximumCoreCapacityUnits`: 20</td></tr>
</tbody>
</table>


**シナリオ 2: タスクノードのみをスケーリングする**

タスクノードのみをスケーリングするには、マネージドスケーリングパラメータが次の要件を満たしている必要があります。
+ 最大コアノードが最小限度と等しいこと。

タスクノードのみをスケーリングするシナリオの例を次に示します。


<table>
<thead>
  <tr><th>クラスターの初期状態</th><th>スケーリングパラメータ</th><th>スケーリングの動作</th></tr>
</thead>
<tbody>
  <tr><td>**インスタンスグループ**<br />コア:2 オンデマンド<br />タスク:1 スポット</td><td>`UnitType`: Instances<br />`MinimumCapacityUnits`: 2<br />`MaximumCapacityUnits`: 20<br />`MaximumCoreCapacityUnits`: 2</td><td rowspan="2">コアノードを 2 個に固定し、0 から 18 インスタンスまたはインスタンスフリートユニットの間のタスクノードのみをスケーリングします。最小限度と最大限度の間の容量が、タスクノードのみに追加されます。<br /> ノードラベルでマネージドスケーリングを使用し、アプリケーションのプロクセスを ON\_DEMAND ノードに制限すると、クラスターはコアノードを 2 に安定させ、需要のタイプに応じて、`On-demand` または `Spot` タイプを使用する 0～18 個のインスタンスまたはインスタンスフリートユニットの間でのみタスクノードをスケーリングします。</td></tr>
  <tr><td>**インスタンスフリート**<br />コア:2 オンデマンド<br />タスク:1 スポット</td><td>`UnitType`: InstanceFleetUnits<br />`MinimumCapacityUnits`: 2<br />`MaximumCapacityUnits`: 20<br />`MaximumCoreCapacityUnits`: 2</td></tr>
</tbody>
</table>


**シナリオ 3: クラスター内のオンデマンドインスタンスのみ**

オンデマンドインスタンスのみを使用するには、クラスターとマネージドスケーリングパラメータが次の要件を満たしている必要があります。
+ オンデマンド制限が最大限度と等しいこと。

  オンデマンド制限が指定されていないときは、パラメータ値がデフォルトで最大限度に設定されます。デフォルト値は、Amazon EMR がオンデマンドインスタンスのみをスケーリングすることを示します。

最大コアノードが最大限度未満の場合、最大コアノードパラメータを使用して、コアノードとタスクノード間で容量割り当てを分割できます。

インスタンスグループで構成されるクラスターでこのシナリオを有効にするには、初期構成時にクラスター内のすべてのノードグループがオンデマンドマーケットタイプを使用する必要があります。

このシナリオは、ノードラベルでマネージドスケーリングを使用し、アプリケーションプロセスを `ON_DEMAND` ノードでのみ実行するように制限する場合には適用されません。マネージドスケーリングはエグゼキューターの需要に対応するために `Spot` ノードをスケーリングするからです。

クラスター全体にオンデマンドインスタンスを持つシナリオの例を次に示します。


<table>
<thead>
  <tr><th>クラスターの初期状態</th><th>スケーリングパラメータ</th><th>スケーリングの動作</th></tr>
</thead>
<tbody>
  <tr><td>**インスタンスグループ**<br />コア:1 オンデマンド<br />タスク:1 オンデマンド </td><td>`UnitType`: Instances<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 20 <br />`MaximumCoreCapacityUnits`: 12</td><td rowspan="2">オンデマンドタイプを使用して、コアノードで 1 ～ 12 個のインスタンスまたはインスタンスフリートユニットをスケーリングします。オンデマンドを使用して、タスクノードで残りの容量をスケーリングします。スポットインスタンスを使用したスケーリングはありません。<br /> ノードラベルでマネージドスケーリングを使用し、アプリケーションプロセスを `CORE` ノードに制限すると、クラスターは、需要のタイプに応じて、`ON_DEMAND` タイプを使用して `CORE` または `task` ノードで 1～20 個のインスタンスまたはインスタンスフリートユニットをスケーリングします。コアノードでのスケーリングは、12 インスタンスまたはインスタンスフリートユニットを超えません。</td></tr>
  <tr><td>**インスタンスフリート**<br />コア:1 オンデマンド<br />タスク:1 オンデマンド</td><td>`UnitType`: InstanceFleetUnits<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 20 <br />`MaximumCoreCapacityUnits`: 12</td></tr>
</tbody>
</table>


**シナリオ 4: クラスター内のスポットインスタンスのみ**

スポットインスタンスのみを使用するには、マネージドスケーリングパラメータが次の要件を満たしている必要があります。
+ オンデマンド制限が 0 に設定されていること。

最大コアノードが最大限度未満の場合、最大コアノードパラメータを使用して、コアノードとタスクノード間で容量割り当てを分割できます。

インスタンスグループで構成されるクラスターでこのシナリオを有効にするには、コアインスタンスグループが初期設定時にスポット購入オプションを使用する必要があります。タスクインスタンスグループにスポットインスタンスがない場合、Amazon EMR Managed Scaling は、必要に応じてスポットインスタンスを使用してタスクグループを作成します。

このシナリオは、ノードラベルでマネージドスケーリングを使用し、アプリケーションプロセスを `ON_DEMAND` ノードでのみ実行するように制限する場合には適用されません。マネージドスケーリングは、アプリケーションプロセスの需要に合わせて `ON_DEMAND` ノードをスケーリングするからです。

クラスター全体にスポットインスタンスを持つシナリオの例を次に示します。


<table>
<thead>
  <tr><th>クラスターの初期状態</th><th>スケーリングパラメータ</th><th>スケーリングの動作</th></tr>
</thead>
<tbody>
  <tr><td>**インスタンスグループ**<br />コア:1 スポット<br />タスク:1 スポット</td><td>`UnitType`: Instances<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 0</td><td rowspan="2">スポットを使用して、コアノードで 1 ～ 20 個のインスタンスまたはインスタンスフリートユニットをスケーリングします。オンデマンドタイプを使用したスケーリングはありません。<br />ノードラベルでマネージドスケーリングを使用し、アプリケーションプロセスを `CORE` ノードに制限すると、クラスターは、需要のタイプに応じて、Spot を使用して `CORE` または `TASK` ノードで 1～20 個のインスタンスまたはインスタンスフリートユニットをスケーリングします。Amazon EMR は `ON_DEMAND` タイプを使用してスケーリングしません。</td></tr>
  <tr><td>**インスタンスフリート**<br />コア:1 スポット<br />タスク:1 スポット</td><td>`UnitType`: InstanceFleetUnits<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 0</td></tr>
</tbody>
</table>


**シナリオ 5: コアノードのオンデマンドインスタンスと、タスクノードのスポットインスタンスをスケーリングする**

コアノードのオンデマンドインスタンスと、タスクノードのスポットインスタンスをスケーリングするには、マネージドスケーリングパラメータが次の要件を満たしている必要があります。
+ オンデマンドの制限が最大コアノードに等しいこと。
+ オンデマンド制限と最大コアノードの両方が最大限度未満であること。

インスタンスグループで構成されるクラスターでこのシナリオを有効にするには、コアノードグループがオンデマンド購入オプションを使用する必要があります。

このシナリオは、ノードラベルでマネージドスケーリングを使用し、アプリケーションプロセスを `ON_DEMAND` ノードまたは `CORE` ノードでのみ実行するように制限する場合には適用されません。

コアノードのオンデマンドインスタンスと、タスクノードのスポットインスタンスをスケーリングするシナリオの例を次に示します。


<table>
<thead>
  <tr><th>クラスターの初期状態</th><th>スケーリングパラメータ</th><th>スケーリングの動作</th></tr>
</thead>
<tbody>
  <tr><td>**インスタンスグループ**<br />コア:1 オンデマンド<br />タスク:1 オンデマンドと 1 スポット</td><td>`UnitType`: Instances<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 7 <br />`MaximumCoreCapacityUnits`: 7</td><td rowspan="2">タスクノードにすでに 1 つのオンデマンドユニットがあり、オンデマンドの最大制限が 7 であるため、コアノードで 6 個のオンデマンドユニットまでスケールアップします。次に、タスクノードで 13 個のスポットユニットまでスケールアップします。</td></tr>
  <tr><td>**インスタンスフリート**<br />コア:1 オンデマンド<br />タスク:1 オンデマンドと 1 スポット</td><td>`UnitType`: InstanceFleetUnits<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 7<br />`MaximumCoreCapacityUnits`: 7</td></tr>
</tbody>
</table>


**シナリオ 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 インスタンスををスケーリングするシナリオの例を次に示します。


<table>
<thead>
  <tr><th>クラスターの初期状態</th><th>スケーリングパラメータ</th><th>スケーリングの動作</th></tr>
</thead>
<tbody>
  <tr><td>**インスタンスグループ**<br />コア:1 オンデマンド<br />タスク:1 オンデマンド</td><td>`UnitType`: Instances<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 10<br />`MaximumCoreCapacityUnits`: 20</td><td rowspan="2">オンデマンドまたはスポット市場タイプを使用して、クラスターのアプリケーションプロセスの需要に基づいて 1～20 ノードの `CORE` ノードをスケーリングします。Amazon EMR が `TASK` ノードを割り当てた後、エグゼキュターの需要と利用可能な残りの容量に基づいて `CORE` ノードをスケーリングします。<br />リクエストされた `CORE` と `TASK` ノードの合計は 20 `maximumCapacity` を超えません。リクエストされたオンデマンドコアノードとオンデマンドタスクノードの合計は、10 `maximumOnDemandCapacity` を超えません。追加のコアノードまたはタスクノードは、スポットマーケットタイプを使用します。</td></tr>
  <tr><td>**インスタンスフリート**<br />コア:1 オンデマンド<br />タスク:1 オンデマンド</td><td>`UnitType`: InstanceFleetUnits<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 10<br />`MaximumCoreCapacityUnits`: 20</td></tr>
</tbody>
</table>


**シナリオ 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` ノードは最大コア容量で静的のままになります。

アプリケーションプロセスの需要に応じてオンデマンドインスタンスを、エグゼキューターの需要に応じてスポットインスタンスををスケーリングするシナリオの例を次に示します。


<table>
<thead>
  <tr><th>クラスターの初期状態</th><th>スケーリングパラメータ</th><th>スケーリングの動作</th></tr>
</thead>
<tbody>
  <tr><td>**インスタンスグループ**<br />コア:1 オンデマンド<br />タスク:1 オンデマンド</td><td>`UnitType`: Instances<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 20<br />`MaximumCoreCapacityUnits`: 10</td><td rowspan="2">`CORE` またはスポット `TASK` タイプを使用して、クラスターのアプリケーションプロセスの需要に基づいて 1～20 ノードの `ON_DEMAND` ノードをスケーリングします。Amazon EMR が `SPOT` ノードを割り当てた後、エグゼキュターの需要と利用可能な残りの容量に基づいて `ON_DEMAND` ノードをスケーリングします。<br />リクエストされた `ON_DEMAND` と `SPOT` ノードの合計は 20 `maximumCapacity` を超えません。リクエストされたオンデマンドコアノードとスポットコアノードの合計は 10 `maximumCoreCapacity` を超えません。追加のオンデマンドノードまたはスポットノードは、`TASK` ノードタイプを使用します。</td></tr>
  <tr><td>**インスタンスフリート**<br />コア:1 オンデマンド<br />タスク:1 オンデマンド</td><td>`UnitType`: InstanceFleetUnits<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 20<br />`MaximumCoreCapacityUnits`: 10</td></tr>
</tbody>
</table>