マネージドスケーリングを有効にしているのに、またはサイズ変更メトリックスが満たされているのに、EMR クラスターがスケーリングされないのはなぜですか?

最終更新日: 2023 年 1 月 12 日

Amazon EMR クラスターでスケーリングを有効にしたか、サイズ変更メトリクスが満たされているのに、クラスターがスケーリングされません。

解決方法

マネージドスケーリングが有効になっており、リサイズメトリクスが満たされているにもかかわらず、EMR クラスターがスケールしない一般的な理由は次のとおりです。

スケーリング用の Amazon CloudWatch メトリックスに設定されているしきい値が満たされていない

自動スケーリングは CloudWatch メトリックスに依存します。スケールアップまたはスケールダウンに対応するメトリクスのしきい値が満たされない場合、スケーリングは行われません。

Amazon CloudWatch の Amazon EMR メトリクスをチェックして、スケーリングルールに設定されているメトリクスが入力されていることを確認します。たとえば、ContainerPendingRatio、YARNMemoryAvailablePercentage などがスケーリングルールで定義されているとおりに入力されていることを確認します。

Amazon EMR メトリクスが CloudWatch に期待どおりに入力されない一般的な理由は次のとおりです。

ファイル /etc/hadoop/conf/hadoop-metrics2.properties が存在しないか、破損しています。たとえば、ファイルがカスタムのブートストラップアクションによって上書きされた可能性があります。
Hadoop や YARN などのメトリクス関連のコンポーネントに問題がある可能性があります。対応するアプリケーションログを確認して、エラーがないかどうかを確認します。
マネージドスケーリングの場合は、プライマリノードで sudo systemctl status MetricsCollector コマンドを実行して、MetricsCollector デーモンが実行されていることを確認します。

YARN ベースではないアプリケーションを使っている

YARN をベースにしていない Presto などのアプリケーションは、YARN によって生成されたメトリクスに基づくスケーリング方法を使用します。そのため、Presto クエリの使用率が高くてもクラスターはスケーリングされません。YARN ベースではないアプリケーションを使用している場合は、手動スケーリングを使用してください。たとえば、Amazon EMR のサイズ変更 API をカスタム Presto メトリックスを使用するように設定できます。

コアインスタンスグループまたはタスクインスタンスグループが停止状態、または arrested 状態にある

停止状態、または arrested 状態のコアインスタンスグループまたはタスクインスタンスグループは、サイズ変更またはスケーリング時に停止状態になります。トラブルシューティングの手順については、「停止状態」を参照してください。

再構成すると、インスタンスグループは停止状態になります。詳細については、「インスタンスグループ再構成のトラブルシューティング」を参照してください。

EMR に HDFS アプリケーションの問題があり、コアノードをスケーリングする際に問題が発生します。

次の条件に当てはまる場合は、コアノードを固定しておくことがベストプラクティスです。

データを Amazon Simple Storage Service (Amazon S3) バケットに保存し、
HDFS の使用率は最低限です。

HDFS の問題を避けるためだけにタスクノードをスケーリングします。

コアノードのスケーリングは、タスクノードのスケーリングよりも時間がかかります。これは、コアノードには HDFS データの保存に使用される追加サービス (Datanode) があるためです。HDFS データの使用停止には時間がかかります。ユースケースでコアノードのスケーリングが必要で、スケーリングが行き詰まっている場合は、HDFS の廃止に問題がある可能性があります。HDFS の廃止によりスケーリングが停止している場合のトラブルシューティングを行うには、次の項目を確認します。

HDFS サービスの状態 (Namenode と Datanode) を確認します。
hdfs dfsadmin -report コマンドを実行して、欠落しているブロック、破損しているブロック、またはレプリケーションが不十分なブロックがないかどうかを確認します。
ディスク、メモリ、または CPU の問題が原因で異常なコアノードがないかどうかを確認します。
HDFS のレプリケーション係数が 3 や 2 などの高い数値に設定されているかどうかを確認します。レプリケーション係数を 3 または 2 に設定し、コアノードを 1 にスケールダウンしようとすると、スケーリングが停止します。これは、最小限のレプリカを維持する必要があるためです。

リクエストされた容量は Amazon EMR では使用できない

リクエストされた Amazon Elastic Compute Cloud (Amazon EC2) の容量が Amazon EMR で使用できない場合、タイムアウト期間が過ぎるとスケーリングは失敗します。スケーリングが長時間停止し、AWS CloudTrail イベントで容量不足エラーが発生した場合は、手動でサイズ変更を実行します。スケーリングは2〜3時間で、停止します。