パイプラインの保守とトラブルシューティング

データパイプラインは、作った後の保守が仕事の大半を占めます。ジョブが失敗した、急に遅くなった、データが届かない、という問題が起きたときに、どこを見て原因を絞り込み、どう直して再実行するかを決めておくことが大切です。

DEA では、、、、の失敗の調べ方と、性能問題 (遅延、、リソース不足) の切り分け、そして再実行と保守の運用が問われます。

Point

Troubleshooting = 問題の解決 です。症状から原因を絞り込み、対処する一連の作業を指します。
Root cause = 根本原因 です。表面の症状ではなく、問題を起こした元の原因を指します。
和訳
- Troubleshoot: 問題を解決する
- Weblio英和辞書「troubleshoot」

概要

トラブルシューティングは、「どこで失敗したか」を特定し、「なぜ失敗したか」をログとで調べ、「直して再実行する」流れです。

調べる場所	分かること
ワークフローの実行履歴	どのステップで、どの入力で失敗したか
ログ ( Logs、)	エラーの内容 (権限、接続、構文、データの不正)
メトリクス (CloudWatch)	遅れ、、メモリやの不足
UI	どのステージやタスクが遅いか、やの有無
	誰がいつ設定を変えたか、どの呼び出しが拒否されたか

主要技術

①AWS Glue ジョブの失敗の調べ方 ⚠️ 頻出

見る場所	内容
ジョブの実行履歴	状態 (FAILED、TIMEOUT)、エラーメッセージ、実行時間、使った
Logs	`/aws-glue/jobs/` 以下のドライバーとのログ。連続ログ記録を有効にすると実行中も見られます
オブザーバビリティ	エラーの分類 (メモリ不足、権限、、接続など)、メモリ、、ワーカーの使用率
UI	ステージとタスクの所要時間、の量、偏り

よくある失敗と対処です。

症状	原因	対処
OutOfMemory (ドライバー)	`collect()` で大きな結果を集めた、大量のの一覧	結果はに書く、ファイルをまとめて読む (グループ化の設定)、ワーカーの種類を大きくする
OutOfMemory (エグゼキューター)	大きすぎるパーティション、スキュー	パーティション数を増やす、、ワーカーの種類を大きくする
権限のエラー (AccessDenied)	ジョブのロールに S3、、カタログ、の権限がない	ロールのポリシー、KMS のキーポリシー、Lake Formation の権限を確かめる
接続のエラー	の接続先へ届かない (、、、)	接続のネットワーク設定、セキュリティグループの自己参照のルールを確かめる
同じデータを2回処理した、または処理が漏れた	の設定、	ブックマークを有効にし、同時に動く数を 1 にする
タイムアウト	データ量の増加、スロットリング	タイムアウトの値、ワーカー数、Flex を外す (急ぐジョブ)

②Amazon EMR のステップの失敗の調べ方

見る場所	内容
ステップの状態とログ	のコンソールでステップの状態 (FAILED) と、`stderr`・`stdout`・`controller` のログを確かめます。
のログの場所 (ログ URI)	クラスターのログ (ステップ、ノード、アプリケーション) が S3 に保存されます。クラスターを終了した後も調べられます。
アプリケーションの UI	の履歴サーバー、YARN のタイムラインサーバーで、ジョブの実行の詳細を見ます。
の	`AppsPending` (資源待ち)、`YARNMemoryAvailablePercentage` (メモリの不足)、`HDFSUtilization`

症状	対処
ステップがずっと PENDING / アプリケーションが待たされる	コアノード・タスクノードを増やす、マネージドスケーリングを有効にする
がメモリ超過で強制終了される	Spark ののメモリ設定を見直す、メモリの大きいインスタンスにする
ブートストラップアクションで起動に失敗	S3 のブートストラップのログでスクリプトのエラーを確かめる
スポットのタスクノードが回収されて遅れる	インスタンスフリートで複数の種類を指定する、重要な処理はのコアノードに置く

⚠️ 頻出: 「EMR クラスターを終了した後で、失敗したステップの原因を調べたい」は、S3 のログの場所に保存されたログです。

③MWAA と Step Functions の失敗の調べ方

サービス	失敗の特定	原因の確認	再実行
	UI で失敗したタスク (赤) を探します	タスクのログ ( Logs の Task ロググループ)、が出ないなら DAGProcessing のログ、パッケージなら requirements の導入ログ	原因を直してタスクをクリアし、再実行します (#25)
	実行履歴のグラフで失敗したステートを探します	ステートの入力と出力、エラー名と原因 (States.TaskFailed、States.Timeout、権限エラー)。呼んだ先 (、) のログ	Standard は redrive で失敗したステップから再開します (#24)

Step Functions でよくあるのは、ステートマシンの実行ロールに、呼び出す先 (Glue の StartJobRun、ジョブの状態の取得など) の権限が足りないことです。.sync で完了を待つ統合では、ジョブの状態の確認に必要な権限とのルールの管理の権限も必要です。

④性能問題の切り分け ⚠️ 頻出

症状	見るもの	原因の候補	対処
ストリームの処理が遅れる	の `IteratorAgeMilliseconds`、の `IteratorAge`	コンシューマーの処理が遅い、が少ない	Lambda の並列化係数とバッチサイズ、シャードの追加、
書き込みや呼び出しが拒否される	`ThrottledRequests`、`WriteProvisionedThroughputExceeded`、`Throttles`	キャパシティの不足、ホットキー、数の上限	、キャパシティの追加 ()、キーの分散
バッチのジョブが日ごとに遅くなる	読み込んだファイル数とバイト数、 UI	データの増加、の増加	ファイルの統合 ()、パーティション、ワーカーの追加
一部のタスクだけが遅い	のの、Spark UI	データの偏り	、AQE、 (#58)
クエリが遅い ()	スキャンしたデータ量、実行の計画	パーティションが効いていない、CSV のまま、小さいファイル	への変換、パーティション、列の絞り込み (#53)
クエリが遅い ()	のキューの待ち、`EXPLAIN`、ディスクの使用率	同時実行の不足、の不適切、不足	、分散キー・の見直し、VACUUM と ANALYZE

⑤再実行と保守の運用

運用	内容
に作る	再実行しても重複しないよう、パーティションの上書きやで書き込みます (#26)。
失敗したところから再開	の redrive、ワークフローの再開、のタスクのクリアを使い、成功した手順はやり直しません。
失敗したデータの隔離と再処理	や隔離用のの場所にためたデータを、原因を直した後で再処理します。
バックフィル	過去の期間を処理し直します。Airflow はデータの期間ごとの実行に向きます。
バージョンの更新	Glue のバージョン、のリリース、Airflow のバージョンのサポート終了を確かめ、計画的に上げます。
実行手順書 (ランブック)	よくある失敗と対処を手順にまとめ、通知に手順書の場所を含めます。
変更の記録	設定の変更はで行い、とで変更の履歴を追えるようにします。

試験対策

①判断マトリクス

問題文のキーワード	見るもの・行うこと	理由
ジョブがメモリ不足で失敗	オブザーバビリティとログ → パーティション数、ワーカーの種類、`collect()` の除去	ドライバーかかで対処が違います。
Glue ジョブがに書けない	ジョブのロール、のキーポリシー	権限のエラーはロールとキーを確かめます。
Glue ジョブがに接続できない	Glue 接続の・・	ネットワークの到達性の問題です。
終了したクラスターの失敗の原因	S3 のログの場所	クラスター終了後もログが残ります。
EMR のアプリケーションが資源待ち	`AppsPending` → ノードの追加、マネージドスケーリング	YARN の資源が不足しています。
のタスクの失敗の原因	UI と Logs の Task ロググループ	タスクごとのログで確認します。
のどこで失敗したか	実行履歴のグラフと、ステートの入出力	失敗したステートとエラー名が分かります。
失敗した手順からやり直したい	Step Functions の redrive / Glue ワークフローの再開	成功した手順を繰り返しません。
ストリームの処理の遅れ	Iterator age のメトリクス	コンシューマーの遅れを示します。
誰が設定を変えて失敗し始めたか		の呼び出しの記録です。

②よくある誤答

原因を調べずに、ワーカーやノードを増やすこと。権限やネットワークの問題、は、台数を増やしても解決しません。
失敗のたびにパイプラインを最初から再実行すること。重い処理のやり直しと重複の原因になります。失敗したところから再開します。
のログをクラスターのローカルにだけ置くこと。クラスターを終了すると消えるため、のログの場所を設定します。