スキップしてコンテンツを表示

マネージドスケーリングがオンになっているか、サイズ変更のメトリクスが満たされているのに、EMR クラスターがスケーリングしない理由を教えてください。

所要時間2分
0

マネージドスケーリングをオンにしているか、サイズ変更のメトリクスが満たされているのに、EMR クラスターがスケーリングしません。

解決策

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

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

Amazon CloudWatch の Amazon EMR メトリクスを確認して、スケーリングルールで設定されたメトリクス (ContainerPendingRatioYARNMemoryAvailablePercentage など) が表示されていることを確認します。

以下のいずれかの理由により、Amazon EMR メトリクスが CloudWatch に想定どおりに反映されない場合があります。

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

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

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

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

suspended 状態または arrested 状態にあるコアまたはタスクインスタンスグループは、サイズ変更またはスケーリング時にスタックします。詳細については、「Suspended state」(Suspended 状態) を参照してください。

再設定により、インスタンスグループが arrested 状態になることがあります。詳細については、「Troubleshoot instance group reconfiguration」(インスタンスグループの再設定に関するトラブルシューティング) を参照してください。

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

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

  • Amazon Simple Storage Service (Amazon S3) バケットにデータを保存している。
  • Hadoop 分散ファイルシステム (HDFS) の使用率が最小限である。

注: HDFS の問題を回避するために、タスクノードのみをスケーリングするのがベストプラクティスです。

コアノードのスケーリングは、タスクノードのスケーリングよりも時間がかかります。これは、コアノードに HDFS データの保存に使用される追加のサービス (Datanode) があるためです。HDFS データの廃止には時間がかかります。コアノードのスケーリングが必要なユースケースでスケーリングがスタックしている場合は、HDFS の廃止に問題がある可能性があります。

HDFS の廃止が原因でスタックしているスケーリングをトラブルシューティングするには、以下の操作を実行してください。

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

リクエストされたキャパシティが Amazon EMR で使用できない

リクエストされた Amazon Elastic Compute Cloud (Amazon EC2) のキャパシティが Amazon EMR で利用できない場合、タイムアウト期間後にスケーリングが失敗します。スケーリングが 2~3 時間以上スタックし、AWS CloudTrail イベントでキャパシティ不足エラーが発生した場合は、手動でサイズ変更を実行してください。

関連情報

Using automatic scaling with a custom policy for instance groups in Amazon EMR (Amazon EMR のインスタンスグループのカスタムポリシーによる自動スケーリングを使用する)

Manually resize a running Amazon EMR cluster (実行中の Amazon EMR クラスターのサイズを手動で変更する)

Using managed scaling in Amazon EMR (Amazon EMR でのマネージドスケーリングを使用する)

Top 9 performance tuning tips for PrestoDB on Amazon EMR (Amazon EMR での PrestoDB のパフォーマンスチューニングのヒント 9 選)

AWS公式更新しました 7ヶ月前
コメントはありません

関連するコンテンツ