Amazon EMR で Spark ジョブが失敗したのはなぜですか?

所要時間3分

Amazon EMR での Apache Spark ジョブが失敗しました。

解決方法

アプリケーションの障害

エラー ShuffleBlockFetcherIterator: ip-192-168-14-250.us-east-2.compute.internal からブロックを取得できませんでした: 7337

org.apache.spark.network .client.ChunkFetchFailureException: Failure while fetching StreamChunkId[streamId=842490577174,chunkIndex=0]: java.lang.RuntimeException: Executor is not registered (appId=application_1622819239076_0367, execId=661)

この問題は、Amazon EMR のエグゼキュターワーカーノードが異常な状態にある場合に発生する可能性があります。ワーカーノードのディスク使用率が 90% の使用率しきい値を超えると、YARN NodeManager ヘルスサービスはそのノードを UNHEALTHY と報告します。異常のあるノードは Amazon EMR 拒否リストに含まれます。さらに、YARN コンテナはそれらのノードに割り当てられません。

この問題をトラブルシューティングするには、次の手順を実行します。

EMR クラスターマスターノードの Resource Manager ログを確認して、異常なワーカーノードがないかどうかを確認します。詳細については、Amazon EMR の Spark で ExecutorLostFailure 「Slave lost (スレーブが失われました)」エラーを解決するには、どうすれば良いですか?を参照、およびディスク使用率が高いセクションを確認してください。
影響を受けたノードのディスク容量使用率を確認して、ディスク容量を消費しているファイルを確認し、データリカバリを実行してノードを正常な状態に復元します。詳細については、Amazon EMR クラスターのコアノードがディスク容量不足になる原因を教えてくださいを参照してください。

ERROR [Executor task launch worker for task 631836] o.a.s.e.Executor:Exception in task 24.0 in stage 13028.0 (TID 631836) java.util.NoSuchElementException: None.get

このエラーは、アプリケーションコードと SparkContext の初期化に問題がある場合に発生します。

同じセッション内で複数の SparkContext ジョブがアクティブになっていないことを確認してください。Java Virtual Machine (JVM) によると、アクティブな SparkContext は一度に 1 つだけです。別の SparkContext を初期化する場合は、新しいジョブを作成する前にアクティブなジョブを停止する必要があります。

リクエストによりコンテナが強制終了しました。終了コードは 137 です

この例外は、YARN コンテナ内のタスクがそのコンテナに割り当てられた物理メモリを超えた場合に発生します。これは通常、シャッフルパーティション、一貫性のないパーティションサイズ、エグゼキュターコアの数が多い場合に発生します。

Spark ドライバーログのエラーの詳細を確認して、エラーの原因を特定します。詳細については、Amazon EMR クラスターで Spark ドライバーのログにアクセスする方法を教えてくださいを参照してください。

ドライバーログのエラーの例を次に示します。

ERROR YarnScheduler: Lost executor 19 on ip-10-109-xx-xxx.aws.com : Container from a bad node: container_1658329343444_0018_01_000020 on host: ip-10-109-xx-xxx.aws.com . Exit status: 137.Diagnostics:
Container killed on request. Exit code is 137
Container exited with a non-zero exit code 137.
Killed by external signal
Executor container 'container_1658329343444_0018_01_000020' was killed with exit code 137. To understand the root cause, you can analyze executor container log.
# java.lang.OutOfMemoryError: Java heap space
# -XX:OnOutOfMemoryError="kill -9 %p"
# Executing /bin/sh -c "kill -9 23573"...

先の述べたエラースタックトレースは、エグゼキュターにデータの処理を続行するのに十分なメモリがないことを示しています。このエラーは、さまざまなジョブステージで、ナロー変換とワイド変換のどちらでも発生する可能性があります。

この問題を解決するには、次のいずれかを実行します。

エグゼキュターのメモリを増やす。
注: エグゼキュターメモリには、タスクの実行に必要なメモリとオーバーヘッドメモリが含まれます。これらの合計が JVM のサイズと YARN の最大コンテナサイズを超えてはなりません。
Spark パーティションを追加する。
シャッフルパーティションの数を増やす。
エグゼキュターコアの数を減らす。

詳細については、Amazon EMR の Spark で「リクエストによりコンテナが強制終了しました。終了コードは 137 です」というエラーを解決するには、どうすればよいですかを参照してください。

Spark ジョブがハング状態になっていて、完了していない

Spark ジョブが停止している理由は幾つかあります。たとえば、Spark ドライバー (アプリケーションマスター) プロセスに影響があったり、エグゼキューターコンテナーが失われたりした場合です。

これは通常、ディスク容量の使用率が高い場合や、クラスターノードにスポットインスタンスを使用してスポットインスタンスが終了した場合に発生します。詳細については、Amazon EMR の Spark で ExecutorLostFailure「Slave lost (スレーブが失われました)」というエラーを解決するには、どうすれば良いですか?を参照してください。

この問題をトラブルシューティングするには、次の手順を実行します。

Spark アプリケーションマスターまたはドライバーのログを確認し、例外がないかを調べてください。
YARN ノードリストに異常なノードがないかを検証します。コアノードのディスク使用率が使用率のしきい値を超えると、YARN Node Manager ヘルスサービスはノードを UNHEALTHY と報告します。異常のあるノードは Amazon EMR 拒否リストに含まれます。さらに、YARN コンテナはそれらのノードに割り当てられません。
ディスク容量の使用状況をモニタリングし、EMR クラスターワーカーノードの使用率を 90% 未満に保つよう Amazon Elastic Block Store (Amazon EBS) ボリュームを設定します。

WARN エグゼキュタ: heartbeater org.apache.spark.rpc.RpcTimeoutException でドライバーと通信する問題: [10000 ミリ秒] 後にタイムアウトになります。このタイムアウトは spark.executor.heartbeatInterval によって制御されます

Spark エグゼキューターは、spark.executor.heartbeatInterval プロパティで指定された間隔でハートビートシグナルを Spark ドライバーに送信します。ガベージコレクションが長時間停止している間、エグゼキュータはハートビートシグナルを送信しないことがあります。ドライバーは、指定された値を超えてハートビートシグナルを送信しなかったエグゼキューターを強制終了します。

TimeoutException

タイムアウトの例外は、エグゼキューターがメモリの制約下にあるか、データ処理中に OOM の問題に直面した場合に発生します。これはガベージコレクションプロセスにも影響を及ぼし、さらなる遅延の原因となります。

ハートビートタイムアウトエラーを解決するには、次のいずれかの方法を使用します。

エグゼキュターのメモリを増やす。また、アプリケーションプロセスによっては、データの再分割をしてください。
ガベージコレクションの調整。
Spark.Executor.heartbeatInterval の間隔を増やしてください。
spark.network.timeout の期間を長く指定してください。

ExecutorLostFailure 「Exit status: -100.Diagnostics: Container released on a *lost* node

このエラーは、ディスク領域の使用率が高いためにコアまたはタスクノードが終了したときに発生します。長期的に高い CPU 使用率または使用可能なメモリの低下によってノードが応答しなくなった場合にも、このエラーは発生します。トラブルシューティングの手順については、Amazon EMR で「Exit status: -100.Diagnostics: Container released on a *lost* node」エラーを解決する方法を教えて下さいを参照してください。

注: このエラーは、クラスターノードにスポットインスタンスを使用し、スポットインスタンスが終了した場合にも発生する可能性があります。このシナリオでは、EMR クラスターは、終了したスポットインスタンスの代わりにオンデマンドインスタンスをプロビジョニングします。つまり、アプリケーションは自動的に復元する可能性があります。詳細については、Amazon EMR の伸縮性と回復力を高めるための Spark の機能強化を参照してください。

エグゼキューター 38: java.sql.SQLException (ネットワークエラー IOException: 接続がタイムアウトしました (接続がタイムアウトしました)

この問題は、データの読み取りまたは書き込み時にソケット接続を確立するための SQL データベースとの通信に関連するものです。DB ホストが EMR クラスターセキュリティグループからポート 1433 で受信接続を受信できることを確認します。

また、SQL DB に設定されている並列データベース接続の最大数と DB インスタンスクラスのメモリ割り当てを確認してください。データベース接続もメモリを消費します。使用率が高い場合は、データベース設定と許可されている接続数を確認してください。詳細については、データベース接続の最大数を参照してください。

Amazon S3 の例外

HTTP 503「Slow Down」

HTTP 503 の例外は、Prefix の Amazon Simple Storage Service (Amazon S3) のリクエストレートを超えた場合に発生します。503 の例外は、必ずしも障害が発生することを意味するわけではありません。ただし、問題を軽減することでアプリケーションのパフォーマンスを向上させることができます。

詳細については、Amazon EMR で Spark または Hive ジョブが HTTP 503「Slow Down」AmazonS3Exception で失敗するのはなぜですか?を参照してください。

HTTP 403「アクセス拒否」

HTTP 403 エラーは、次のような不正確なまたは有効ではない認証情報によって発生します。

アプリケーションコードで指定された認証情報またはロール
Amazon EC2 インスタンスプロファイルロールにアタッチされているポリシー
Amazon S3 の Amazon Virtual Private Cloud (Amazon VPC) エンドポイント
S3 のレプリケート元およびレプリケート先バケットポリシー

403 エラーを解決するには、関連する AWS Identity and Access Management (IAM) ロールまたはポリシーが Amazon S3 へのアクセスを許可していることを確認してください。詳細については、Amazon EMR アプリケーションが HTTP 403「アクセス拒否」AmazonS3Exception で失敗するのはなぜですか?を参照してください。

HTTP 404「Not Found」

HTTP 404 エラーは、アプリケーションが S3 でオブジェクトを見つけることを想定していたものの、リクエストの時点ではオブジェクトが見つからなかったことを示しています。一般的な原因には次のものがあります。