耐障害性のあるデータパイプライン

データパイプラインは、ネットワークの瞬断、の、壊れたレコード、ジョブの途中停止など、さまざまな失敗に出会います。のあるパイプラインとは、こうした失敗が起きても、データを失わず、二重に書かず、自動で回復するか、少なくとも安全に止まって知らせるパイプラインです。

DEA では、リトライ、 (デッドレターキュー)、な書き込み、を組み合わせて、性能・可用性・・レジリエンス・耐障害性を満たす設計を選べるかが問われます。

Point

Resilience = 回復力 です。障害が起きても元の状態へ戻れる性質を指します。
Fault tolerance = 耐障害性 です。一部が壊れても全体が動き続ける性質を指します。
Idempotent = 冪等 (べきとう) です。同じ処理を何回実行しても結果が同じになる性質です。
DLQ = Dead-Letter Queue の略で、処理できなかったメッセージの退避先です。
和訳
- Idempotent: 冪等の
- Weblio英和辞書「idempotent」

概要

失敗への備えは、「一時的な失敗を自動で乗り越える」「乗り越えられない失敗を隔離する」「やり直しても壊れないようにする」の3層で考えます。

層	目的	主な手段
乗り越える	一時的な失敗から自動で回復します	とジッター付きの再試行、自動スケーリング
隔離する	何度やっても失敗するデータでパイプライン全体を止めません	、失敗レコードの退避先 ( のエラー用プレフィックス)、品質チェックによる隔離
やり直しても壊れない	再実行や重複配信で結果が変わらないようにします	な書き込み、、

主要技術

①リトライと指数バックオフ ⚠️ 頻出

(呼び出しすぎによる拒否) やネットワークの瞬断は、少し待ってやり直せば成功することが多い失敗です。待ち時間を回ごとに2倍、4倍と伸ばすと、待ち時間にばらつきを入れるジッターを組み合わせます。

場所	再試行の仕組み
AWS	標準で再試行します。リトライモード (standard、adaptive) と最大回数を設定できます (#61)。
	Retry フィールドで、エラー名ごとに待ち時間、倍率、最大回数を宣言します (#24)。
のイベントソースマッピング	・ Streams では最大再試行回数、レコードの最大経過時間、失敗時のバッチ二分割を設定します。
Lambda の非同期呼び出し	失敗時に自動で再試行し、最後は失敗時の送信先 (、など) へ送ります。
ジョブ	ジョブの最大再試行回数を設定できます。
()	タスクごとに `retries` と `retry_delay` を設定します。

再試行は、回数と待ち時間の上限を必ず決めます。無限に再試行すると、壊れたデータを永遠に処理し続けたり、下流のサービスを過負荷にしたりします。

②DLQ と失敗レコードの退避

何度再試行しても失敗するデータ (形式が壊れたレコードなど) を「毒入りメッセージ」と呼ぶことがあります。これを取り除かないと、同じデータで処理が止まり、後続のデータまで遅れます。

サービス	退避先	動き
	(別の SQS キュー)	受信回数が最大受信数 (maxReceiveCount) を超えたメッセージを DLQ へ移します。原因を直した後は、DLQ から元のキューへ戻す (redrive) ことができます。
(・ Streams)	失敗時の送信先 (SQS、、など)	再試行を使い切ったバッチの情報を送ります。
	S3 のエラー用プレフィックス	変換や配信に失敗したレコードを S3 にバックアップします。
	隔離用の S3 の場所	品質ルールに合わない行を分けて書き出します (#57)。

DLQ に入ったら、の (DLQ のメッセージ数が 0 より大きい) と SNS で担当者に知らせます。

⚠️ 頻出: 「一部の不正なメッセージのためにキューの処理が止まる」は、SQS の DLQ と maxReceiveCount で隔離します。

③冪等な書き込みとチェックポイント ⚠️ 頻出

多くの AWS のメッセージングは「少なくとも1回」の配信です。つまり、同じデータが2回届くことがあります。また、ジョブを途中から再実行すると、一部のデータを2回書くおそれがあります。そこで、書き込みをにします。

手法	内容	例
キーで上書き ()	主キーが同じなら更新、なければ挿入します	の PutItem、の MERGE、の MERGE INTO
パーティション単位の置き換え	処理対象の日付パーティションを丸ごと書き直します	`dt=2026-10-17` を削除してから書く、の動的パーティション上書き
重複排除	メッセージ ID やイベント ID で重複を除きます	の重複排除 ID、処理済み ID を DynamoDB に記録
条件付き書き込み	既に処理済みなら書かない	DynamoDB の条件式 (attribute_not_exists)

は「どこまで処理したか」を記録する仕組みです。再開時は記録した位置から続けます。

仕組み	記録するもの
	前回までに処理したのファイルやの行を記録し、次回は新しい分だけを読みます。
(Kinesis Client Library)	ごとの読み取り位置を DynamoDB のリースのテーブルに記録します。
	アプリケーションの状態を定期的にチェックポイントとして保存し、障害時に復元します。
Spark Structured Streaming	チェックポイントの場所 (S3) に処理の進み具合を保存します。

④可用性とスケーラビリティ

パイプラインが止まらず、量が増えても追いつくための設計の原則です。

原則	内容	例
	生産者と消費者の間にバッファを置き、片方の遅れや停止がもう片方に波及しないようにします	、、
と	台数の管理や障害時の置き換えを AWS に任せます	、、、、 Serverless
マルチ	1 つのアベイラビリティーゾーンの障害で止まらないようにします	Kinesis・SQS・は標準で複数 AZ にデータを保存します。はブローカーを複数 AZ に配置します。
	処理を分割して並列に増やせるようにします	Kinesis の、Glue のワーカー数とオートスケーリング、分散マップ
保持と再生	処理に失敗しても、元データから作り直せるようにします	生データを S3 に保持する、Kinesis の保持期間を延ばして再読み込みする

生データ (raw) をそのまま S3 に保存しておき、変換後のデータとは分けておくと、変換の不具合が見つかっても生データから作り直せます。これが再現性のあるパイプラインの基本です。

⑤Well-Architected Framework のデータ分析レンズ

AWS Well-Architected Framework には、分析ワークロード向けの観点をまとめたデータ分析レンズ (Data Analytics Lens) があります。でこのレンズを選ぶと、自分のワークロードを質問に沿って見直し、改善点を一覧にできます。

柱	データパイプラインでの観点の例
運用上の優秀性	パイプラインの状態とデータ品質を監視し、失敗を通知する
セキュリティ	データの分類、暗号化、のアクセス
信頼性	失敗からの回復、再処理できる設計、データの
パフォーマンス効率	データ形式とパーティションの最適化、適切なサービスの選択
	ライフサイクルによる階層化、使った分だけの課金の活用
持続可能性	不要なデータの削除、効率的な形式による処理量の削減

試験対策

①判断マトリクス

問題文のキーワード	選ぶ手段	理由
一時的なでジョブが失敗する	とジッター付きの再試行	少し待てば成功する失敗を自動で乗り越えます。
不正なメッセージで処理が止まる	の (maxReceiveCount)	問題のメッセージだけを隔離して後続を流します。
で変換に失敗したレコードを失いたくない	のエラー用プレフィックスへのバックアップ	失敗レコードを後から再処理できます。
再実行で重複データができる	な書き込み (、パーティション上書き、条件付き書き込み)	何度書いても結果が同じになります。
前回処理した分を除いて新しいファイルだけ処理		処理済みの位置を記録します。
生産側と消費側の速度差を吸収したい	SQS / によるバッファリング	で、片方の遅れが波及しません。
変換の不具合を後から直してデータを作り直したい	生データを S3 に保持	生データから再処理できます。
分析ワークロードの設計をベストプラクティスで見直したい	のデータ分析レンズ	分析向けの質問で改善点を洗い出します。

②よくある誤答

再試行の上限を決めずに無限に再試行すること。毒入りメッセージで処理が止まり続けます。
「少なくとも1回」の配信なのに、単純な追記 (INSERT) だけで書くこと。重複が発生します。
変換後のデータだけを保存し、生データを捨てること。不具合が見つかっても作り直せません。
のためにで自前のキューを組むこと。やのを使う方が運用負荷が低くなります。