メッセージキューとイベントストリーミング

🎓 レベル：標準　|　重要度：A（必須）

📎 前提：バッチ処理とストリーム処理・データ取り込み（バッチ・CDC）　|　関連：ストリーム処理

要点（BLUF）

メッセージキュー／イベントストリーミングは、送り手（producer）と受け手（consumer）を疎結合にする中継。送り手は「誰が読むか」を知らずに発行し、受け手は好きなときに購読する（pub/sub）。
Kafkaの核心は、メッセージを消したら終わりのキューでなく、追記専用の永続ログ（append-only log）として保持すること。受け手はオフセットを進めながら読み、**過去に遡って再生（replay）**できる。
この「再生可能なログ」が、CDC配送・複数消費者・ストリーム処理・障害復旧をまとめて支える。ログがデータ基盤の背骨になる。

概念 ── 疎結合な中継としてのpub/sub

直接「アプリAがアプリBを呼ぶ」とすると、Bが落ちればAも詰まり、受け手が増えるたびにAを改修することになります。間にログ（トピック）を挟むと、Aは「発行するだけ」、B/C/Dは「各自のペースで購読するだけ」。送受の都合を切り離せます。

flowchart LR
    P1["producer（注文サービス）"] --> T["トピック（追記ログ）"]
    P2["producer（CDC）"] --> T
    T --> C1["consumer（分析）"]
    T --> C2["consumer（不正検知）"]
    T --> C3["consumer（DWH取り込み）"]

仕組み ── ログ・パーティション・オフセット

Kafkaのトピックはパーティションに分かれ、各パーティション内では順序が保証されます。メッセージには連番（オフセット）が付き、消費者は「どこまで読んだか」をオフセットで覚えます。

flowchart LR
    subgraph TOPIC["トピック（partition 0）"]
      direction LR
      M0["off0"] --> M1["off1"] --> M2["off2"] --> M3["off3 ..."]
    end
    C["consumer：offset=2 まで読了 -> 次はoff3から"]

永続・再生：読まれてもメッセージは消えず保持期間まで残る。新しい消費者はoffset=0から、障害復旧時は「最後にコミットしたoffset」から再開できる。
パーティションで並列・順序：同じキー（例：顧客ID）を同じパーティションに送れば、その顧客のイベント順序が保たれつつ、パーティション間は並列（→ シャッフルとパーティショニングと同じ分割発想）。
配送保証：通常はat-least-once（最低1回・重複あり得る）。だから受け手は冪等に作る（→ べき等性と再実行）。

設計の勘所 ── キュー vs ログ

観点	従来のメッセージキュー	イベントログ（Kafka）
消費後	メッセージ削除	保持（再生可能）
消費者	基本1つが取り出す	複数が独立に読める
再処理	不可（消えている）	offsetを戻せば再生
用途	タスク分配	イベント基盤・CDC・分析

なぜそうするか ── 「ログ」を真実の源にする

なぜメッセージを消さず、ログとして残すのか。「何が起きたか」の事実列（イベント）こそが一次データだからです。状態（現在の残高）はイベント列（入出金の履歴）から再構成できますが、逆はできません。ログを真実の源にすれば、新しい用途が出ても過去のイベントを再生して作り直せる。CDC（→ データ取り込み（バッチ・CDC））がDBログを流すのも、メダリオンのbronze（→ メダリオンアーキテクチャ）が生を残すのも、同じ「事実を捨てない」思想です。再生可能なログは、データ基盤に“やり直し”の自由を与えます。

⚠️ よくある落とし穴

exactly-onceを素朴に期待 → 実際はat-least-once。受け手を冪等に（→ べき等性と再実行）。
パーティションキー設計を怠る → 同一エンティティの順序が崩れる／偏る（skew）。
保持期間を無限／極短に → 無限はコスト爆発、極短は再生不能。要件で設定。
consumerのoffsetコミット漏れ → 障害復旧で重複・取りこぼし。コミット位置を正しく管理。

対応ラボ

なし（基盤概念回・本番Kafkaは外部前提）。ログを使うストリーム集計はストリーム処理のラボで扱う。