← AWSサービスの内部原理 コース
55. 配信保証の地図 — 4つのサービスを同じ物差しで並べる
SQS・SNS・Kinesis・EventBridgeを『配信保証・順序・push/pull・保存の性質』という4本の物差しで並べ、どれをいつ使うかが暗記でなく導出になる様子を図で追っていきます。
① 土台はどれもat-least-once — 「1回以上」しか約束しない
送信側(producer / publisher)ネットワークは失敗しうる
再送は「二重に届く」可能性を生む(これが原理)
SQS標準分散アーキテクチャの帰結で複製配信
「more than one copy of a message might be delivered」SNS5XX/429を再試行
同じ通知を再送しうるKinesisproducerリトライで重複レコード
put失敗時の再試行受信側は「同じものが2回来る」前提で作る= 冪等な消費(既習)
- SQS標準の公式表現: 「Standard queues ensure at-least-once message delivery … more than one copy of a message might be delivered」。重複と順序の乱れは『highly distributed architecture(高度に分散した構造)』の帰結と説明される
- at-least-onceは『失敗したら再送』の当然の代償。exactly-onceを本当に達成するのは分散システムでは高価なので、多くのサービスがこの土台を選ぶ
- 既習: Lambdaの非同期呼び出し・イベントソースマッピングも同じat-least-once。だから消費側の冪等化は本編を通した共通処方
4サービスに共通する最下層はat-least-once=『少なくとも1回、ただし2回以上もありうる』。原因は違ってもすべて再送に行き着き、だから受信側の冪等性が全編共通の答えになる。
② exactly-onceは「魔法」ではなく重複排除ID+ロックの工学
MessageDeduplicationId5分間の重複排除ウィンドウ内で同一IDを弾く
= 冪等キーの実装(既習)受信後の二重処理も…
可視性タイムアウト受信中は他のコンシューマから隠す=時限ロック
Delete するまで確定しない2フェーズSQS FIFOの「exactly-once processing」入口の重複排除 × 出口の排他ロックの合わせ技
- 『exactly-once』はネットワークが魔法で1回配信になるのではなく、重複排除ウィンドウ+可視性タイムアウトという2つの工学的仕掛けで『実質1回処理』に近似したもの
- 公式: 「If you retry the SendMessage action within the 5-minute deduplication interval, Amazon SQS doesn't introduce any duplicates into the queue」。IDは明示指定のほか、本文のSHA-256ハッシュから自動生成(content-based deduplication)もできる
- DynamoDB編のパーティションキー、SQS FIFOのメッセージグループID、Kinesisのシャードはすべて『何かのスコープを区切るキー』という同型。ここでは重複排除IDが『冪等のスコープを区切るキー』
FIFOの『exactly-once』は例外ではなく、at-least-onceの土台の上に重複排除IDと可視性タイムアウト(ロック)を積んだ工学的近似。仕組みが見えれば『なぜFIFOは遅いか』も『なぜ標準は速いか』も同じ天秤の両端として読める。
③ 順序は「常に何かの単位の中でだけ」保証される
SQS標準順序なし=ベストエフォート
「messages may occasionally arrive out of order」共通原理: 順序=直列化点。スコープを狭めるほど並列性が下がる
SQS FIFOメッセージグループID内で順序
Kinesisシャード内でシーケンス番号順
グローバルな全順序は誰も約束しない並列性とのトレードオフだから
- FIFOのグループID、Kinesisのシャード(パーティションキーのMD5ハッシュで決まる)は『順序を保つ単位』。同じキーのものだけ順序が揃う
- Kinesis公式: シーケンス番号は『unique per partition-key within its shard』。順序はシャードをまたがない
- 既習との一致: DynamoDB編のパーティションキーと同じ原理。『順序のスコープ=並列のスコープ』を区切るキーが必ず1つある
順序保証は『あり/なし』の二択ではなく『どの単位の中でなら順序が立つか』の問い。標準SQS=単位なし、FIFO=グループID、Kinesis=シャード。狭い単位で順序を買うほど並列性を手放すのは、分散システムの動かせない天秤。
④ push か pull か — 誰が取りに行き、誰が押し込むか
SQSコンシューマがReceiveMessageで引く
ロングポーリング最大20秒Kinesis(共有)GetRecordsで引く
拡張ファンアウトだけHTTP/2プッシュ送信側が押し込む(push)
SNSサブスクリプションへ配達
落ちてたら送信側が再試行を背負うEventBridgeルールがターゲットへ送る
pull=受信側がペースを握る / push=送信側が到達を保証しに行く既習『ポーリング vs プッシュ』の答え合わせ
- pushの宿命: 受信側が落ちていれば送信側が面倒を見るしかない → SNSの4フェーズ再試行(AWS管理エンドポイントは23日で100,015回)とDLQはこの帰結
- pullの利点: コンシューマが自分の処理速度でペースを握れる(バックプレッシャ)。だからSNS+SQSは『pushの即時性』と『pullのペース制御』を組み合わせる定番
- Kinesisだけが両刀: 共有スループット=GetRecordsによるpull、拡張ファンアウト=公式に『pushes the records to you over HTTP/2 using SubscribeToShard』。『同じログを何者が読むか』で経路を選べる
pullは受信側がペースを握り、pushは送信側が到達を保証しに行く。この違いから『SNSはなぜ再試行とDLQを持つか』『なぜSNS+SQSを重ねるか』『Kinesisはなぜ両方選べるか』が一本の原理で導ける。
⑤ 保存の性質 — 消えるキュー / 貯めないルーター / 消えないログ
SQS破壊的読み取りのキュー
Deleteで消える。1メッセージ1処理者SNS / EventBridge貯めないルーター
受けて即配る。保持しない → 取りこぼしはDLQで受けるKinesis非破壊の共有ログ
読んでも消えない。カーソルは読者ごと(既定24時間・最大365日)- SQS=消費で確定して消す(処理はちょうど1者)。Kinesis=位置(カーソル)を進めるだけなので複数アプリが独立・同時に読める(公式: 「each application can consume data from the stream independently and concurrently」)
- SNS/EventBridgeは貯蔵しないから、配りきれない分の受け皿にDLQ(SQS)を付ける。EventBridge公式: 「An event bus is a router that receives events and delivers them to zero or more destinations, or targets」
- 既習との接続: KinesisはDynamoDB Streamsと同じ『追記ログ』の汎用版。リプレイ(過去に戻って読み直す)はログ構造の当然の帰結
保存の性質は『読んだあとどうなるか』で決まる。消えるキュー(SQS)・貯めないルーター(SNS/EventBridge)・消えない共有ログ(Kinesis)。この一点で『複数の読者が独立に進めたいならKinesis』『1タスク1処理者ならSQS』が即決まる。
⑥ 4軸マトリクス — 選択は暗記でなく導出になる
SQS配信=at-least-once(FIFOは近似exactly-once) / 順序=なし(FIFOはグループ内) / pull / 消えるキュー
SNS配信=at-least-once(再試行) / 順序=なし(FIFOトピック除く) / push / 貯めないルーター
Kinesis配信=at-least-once / 順序=シャード内 / pull(EFOはpush) / 消えない共有ログ
EventBridge配信=at-least-once / 順序=なし / push / 貯めないルーター(内容ベースの配線)
- 使い分けの導出例 — 1タスクを確実に1回処理したい: SQS(消えるキュー×pullでペース制御) / 1イベントを多数へ即ファンアウト: SNS or EventBridge(貯めないルーター×push) / 同じデータを複数系統が独立に集計・保管したい: Kinesis(非破壊の共有ログ) / 属性で宛先を仕分けたい: EventBridgeルール(内容ベースルーティング) or SNSフィルタポリシー
- EventBridgeのat-least-onceも再試行の裏返し: 配信失敗時は既定で24時間・最大185回まで指数バックオフ+ジッターで再試行し、使い切ると破棄(だからDLQを付ける)
- SNS(トピックを選んで発行)とEventBridge(1本に流してルールが仕分ける)はどちらもpush型の貯めないルーターだが、主役が『発行側のチャネル選択』か『受信側のルール』かで分かれる
- この表の各セルは①〜⑤で導いた原理の要約。だから丸暗記でなく『配信・順序・push/pull・保存』の4問に答えれば毎回このセルを再構成できる
4軸(配信保証・順序・push/pull・保存の性質)を縦の物差しにすると、4サービスの選択は暗記表でなく導出になる。既習の分散システム基礎(at-least-once・冪等性・順序スコープ・ポーリングvsプッシュ)がそのまま各列の答えになっているのが、この編全体の答え合わせ。