ストーリー

バッチ処理 vs ストリーム処理

比較

ストリーム処理の基本概念

イベント時間 vs 処理時間

イベント時間 (Event Time):
  イベントが実際に発生した時刻
  例: ユーザーが 14:00:00 にボタンをクリックした

処理時間 (Processing Time):
  イベントが処理エンジンに到達した時刻
  例: ネットワーク遅延やバッファリングにより 14:00:05 に到着

ウォーターマーク (Watermark):
  「これ以降、この時刻以前のイベントは来ない」という宣言
  遅延イベントの許容範囲を定義する

  時間軸:
  14:00  14:01  14:02  14:03  14:04  14:05
    ↑      ↑      ↑      ↑
    |      |      |      └── ウォーターマーク（3分遅延許容）
    |      |      └── このイベントは許容範囲内
    |      └── このイベントも許容範囲内
    └── 14:00のイベントが14:04に到着 → 遅延イベントとして処理

ウィンドウ処理

タンブリングウィンドウ（5分間隔）:
  |--window 1--|--window 2--|--window 3--|
  00:00  00:05  00:05  00:10  00:10  00:15

スライディングウィンドウ（5分幅、1分スライド）:
  |--window 1--|
     |--window 2--|
        |--window 3--|
  00:00  00:01  00:02  00:03  00:04  00:05

セッションウィンドウ（ギャップ 30分）:
  |---session 1---|     |---session 2---|
  イベント  イベント       イベント  イベント
            ← 30分以内 →  ← 30分超 →

主要ストリーム処理フレームワーク

ツール比較

マネージドサービス

配信保証

3つのセマンティクス

Exactly-once の実現方法:

1. べき等（Idempotent）処理
   同じメッセージを複数回処理しても結果が変わらない設計
   例: UPSERT（INSERT ON CONFLICT UPDATE）

2. トランザクション
   Kafkaのトランザクション機能で、読み取り→処理→書き込みを
   アトミックに実行

3. チェックポイント
   処理状態を定期的に保存し、障害時にチェックポイントから復元

「ストリーム処理で最も重要なのは配信保証だ。データが失われるのは論外だが、重複も厄介だ。売上イベントが2回処理されたら売上が2倍になる。Exactly-onceが理想だが、実装コストが高い場合はAt-least-once + べき等処理で対処する」 — 田中VPoE

まとめ

チェックリスト

• バッチ処理とストリーム処理の違いを説明できる
• イベント時間と処理時間の違い、ウォーターマークの役割を理解した
• 3種類のウィンドウ処理の使い分けを説明できる
• 3つの配信保証セマンティクスの違いとトレードオフを理解した

次のステップへ

次は「イベント駆動アーキテクチャ」を学びます。ストリーム処理の基盤となるイベント駆動の設計パターンを身につけましょう。

推定読了時間: 30分