自動スケーリング機能は、クラウドベースのビッグデータプラットフォーム E-MapReduce（EMR）が提供するコア機能です。自動スケーリングルールを構成すると、システムはビジネス要件に基づいて EMR クラスタのノードを追加または削除します。これは、ビジネスワークロードの変動の要件を満たし、コストを削減するのに役立ちます。このトピックでは、ビジネス要件に基づいて EMR クラスタに適切な自動スケーリングルールを構成する方法について説明します。
前提条件
- DataLake、Dataflow、オンライン分析処理（OLAP）、DataServing、またはカスタムクラスタが作成されていること。詳細については、「クラスタの作成」をご参照ください。
- 従量課金インスタンスまたはプリエンティブルインスタンスを含むタスクノードグループがクラスタに作成されていること。詳細については、「ノードグループの作成」をご参照ください。
ステップ 1：トリガーモードの選択
| シナリオ | トリガーモード |
| ビジネスワークロードが経時的に定期的に変動する場合、または特定の期間内に固定数のノードが必要な場合。 | 時間ベースのスケーリングを使用することをお勧めします。 |
| ビジネスワークロードが大きな時間パターンなしに変動し、必要なノードの数がビジネスワークロードによって変化する場合。 | 負荷ベースのスケーリングを使用することをお勧めします。これは、構成したクラスタ負荷メトリックに基づいてビジネスワークロードの変動を検出し、ジョブの実行効率を向上させるのに役立ちます。 |
| ビジネスが時間ベースのスケーリングと負荷ベースのスケーリングの両方の特性を満たす場合。 | 時間ベースのスケーリングと負荷ベースのスケーリングを一緒に使用することをお勧めします。 |
ステップ 2：自動スケーリングルールの構成
- スケールアウトルールはスケールインルールよりも優先されます。
- 時間ベースのスケーリングルールと負荷ベースのスケーリングルールは、トリガーシーケンスに基づいて実行されます。
- 負荷ベースのスケーリングルールは、クラスタ負荷メトリックがトリガーされた時間に基づいてトリガーされます。
- 同じクラスタ負荷メトリックで構成された負荷ベースのスケーリングルールは、ルールが構成された順序でトリガーされます。
時間ベースのスケーリング
ビジネスボリュームが増加する可能性のある時点に基づいて、繰り返し実行されるか、1回だけ実行される時間ベースのスケールアウトルールを構成できます。また、オフピーク時にノード数を減らすためのスケールインルールを構成することもできます。構成した時間ベースのスケーリングルールが繰り返し実行される場合は、Rule Expiration Time パラメータを構成して、ルールの有効期限を指定できます。時間ベースのスケーリングルールの有効期限が切れると、スケーリングアクティビティはトリガーされません。
たとえば、ビジネスワークロードは毎日 22:00 に増加し、04:00 に減少するとします。この場合、毎日 22:00 に繰り返し実行される時間ベースのスケールアウトルールと、毎日 04:00 に繰り返し実行される時間ベースのスケールインルールを構成できます。
パラメータとクラスタ負荷メトリックの詳細については、「自動スケーリングルールの追加」をご参照ください。
負荷ベースのスケーリング
- クラスタ負荷メトリックを選択します。Metric MonitoringMonitoring タブの
サブタブで、[ダッシュボード] ドロップダウンリストから [YARN-HOME] を選択します。さまざまな期間のビジネスワークロードに基づいてクラスタ負荷メトリックの変化を観察し、適切なメトリックを選択します。メトリックの値は、容量の変化と反比例する必要があります。スケーリングアクティビティが発生した後、インスタンスの数が増減すると、メトリックの値は減少します。
たとえば、負荷ベースのスケールアウトルールを構成し、yarn_resourcemanager_queue_AppsPending メトリックの平均値が 60 秒以内に 1 以上の場合にルールがトリガーされるとします。上記の条件が満たされると、1 つのノードが追加されます。スケールアウトアクティビティがトリガーされると、保留中のタスクの数を減らすことができます。
次の表にリストされているクラスタ負荷メトリックを使用することをお勧めします。EMR クラスタ負荷メトリック サービス 説明 yarn_resourcemanager_queue_AvailableMBPercentage YARN ルートキューの合計メモリに対する使用可能メモリの割合。 yarn_resourcemanager_queue_AvailableVCores YARN ルートキューで使用可能な vCPU の数。 yarn_resourcemanager_queue_AvailableMB YARN ルートキューで使用可能なメモリの量。単位：MB。 yarn_resourcemanager_queue_AppsPending YARN ルートキューで保留中のタスクの数。 yarn_resourcemanager_queue_PendingContainers YARN ルートキューで割り当てられるコンテナの数。 yarn_resourcemanager_queue_AvailableVCoresPercentage YARN ルートキューで使用可能な vCPU の割合。 - 負荷ベースのスケーリングルールを構成します。
- 負荷ベースのスケーリングルールを初めて構成する場合は、スケールアウトルールに保留関連のメトリックを、スケールインルールに使用可能関連のメトリックを選択できます。
- 負荷ベースのスケーリングルールに複数の負荷メトリックベースのトリガー条件を構成し、条件間に論理演算子 AND または OR を指定できます。これにより、メトリックベースのトリガー条件をきめ細かく管理できます。
- 頻繁なスケーリングアクティビティによって発生するリソースの浪費を防ぐために、負荷ベースのスケーリングルールのクールダウン時間を指定できます。クールダウン時間中は、条件が満たされていても、負荷ベースのスケーリングルールはトリガーされません。
ノードを追加するための平均期間は 1.55 分で、100 ノードを追加するための平均期間はわずか 1.83 分です。スケールアウトルールのクールダウン時間を 100 ～ 300（単位：秒）の範囲の値に設定できます。このようにして、新しいノードが使用された後、構成されたクラスタ負荷メトリックの値が減少するかどうかを確認し、別のスケールアウトアクティビティが必要かどうかを判断できます。これは、リソースの浪費を防ぐのに役立ちます。
- クラスタ負荷メトリックの変化に迅速に対応するために、[統計期間] パラメータを 1 分に設定することをお勧めします。パラメータの値が大きすぎると、期限切れのデータによってスケーリングアクティビティがトリガーされる可能性があります。これは、不要なリソースの浪費につながります。
- 既存のノードがジョブを処理する能力と予想されるビジネスの成長に基づいて、追加または削除するノードの数を指定できます。また、関連するクラスタ負荷メトリックの値を減らすために必要なノードの数を見積もることもできます。
- 1 日以内に負荷ベースのスケーリングルールが有効になる有効期間を指定できます。異なる期間に異なる負荷ベースのスケーリングルールを構成できます。
- ノードグループの最大ノード数と最小ノード数を指定します。
Limits on Node Quantity of Current Node Group パラメータは、現在のノードグループのノード数の制限を指定します。Maximum Number of Instances パラメータは、現在のノードグループのノード数の上限を指定します。これは、ノードグループが無制限にスケールアウトされるのを防ぎます。Minimum Number of Instances パラメータは、ビジネスを処理するために必要なノード数の下限を指定します。予期しない要因によりインスタンスが解放された場合、システムは最小インスタンス数を満たすようにインスタンスを追加します。
- 負荷ベースのスケーリングルールを変更します。
負荷ベースのスケーリングルールを構成した後、特定の期間のメトリックとスケーリングアクティビティレコードに基づいてルールのパラメータを変更できます。
- スケーリングアクティビティが頻繁にトリガーされ、追加されたインスタンスがアイドル状態になり、頻繁に削除される場合は、ルールで AND 論理演算子を使用して負荷メトリックベースのトリガー条件を追加し、スケーリングアクティビティの頻度を減らすことができます。また、Cooldown Time パラメータの値を増やすこともできます。
- ジョブに複数のスケールアウトアクティビティが必要な場合、またはスケールアウト速度がジョブ処理の要件を満たしていない場合は、各スケールアウトアクティビティに追加されるインスタンスの数を増やすことができます。