Lambda/Kappaアーキテクチャ

田中VPoE「バッチ処理とストリーミング処理、それぞれ学んだ。実際のシステムでは両方を組み合わせることが多い。Lambdaアーキテクチャと、そのシンプル版であるKappaアーキテクチャを比較しよう。」

あなた「バッチで正確性を担保しつつ、ストリーミングでリアルタイム性も確保する構成ですね。」

田中VPoE「そうだ。ただし、2つのパイプラインを維持するコストも考慮する必要がある。それぞれの長所と短所を理解して選択しよう。」

Lambdaアーキテクチャ

概要

バッチ処理層とリアルタイム処理層の2系統を持つアーキテクチャです。

                     ┌─→ [Batch Layer] ─→ [Batch View]  ─┐
[Data Source] ─→ [Raw Data]                                ├→ [Serving Layer] → Query
                     └─→ [Speed Layer] ─→ [Real-time View]─┘

3つの層

層	役割	ツール例
Batch Layer	全データの再処理、正確な集計	Spark, dbt, Airflow
Speed Layer	リアルタイムの近似集計	Kafka Streams, Flink
Serving Layer	バッチ結果とリアルタイム結果の統合	Druid, ClickHouse

NetShop社での適用例

注文イベント
    ├─→ [Kafka] → [Flink] → リアルタイム売上ダッシュボード
    │                        （近似値、数秒のレイテンシ）
    │
    └─→ [S3] → [Spark/dbt] → 日次正確な売上レポート
                               （正確な値、翌朝までに完成）

Lambdaアーキテクチャの問題点

問題	説明
コードの重複	バッチとストリーミングで同じロジックを2回実装
運用負荷	2系統のパイプラインの監視・メンテナンス
整合性	バッチとリアルタイムの結果が一時的に不一致
デバッグの困難さ	問題がどちらの層で発生したか特定が難しい

Kappaアーキテクチャ

概要

ストリーミング処理のみで全てを処理するアーキテクチャです。

[Data Source] → [Stream Processing] → [Serving Layer] → Query
                       ↑
              [Reprocessing: Replay from Log]

設計思想

全データをイベントログ（Kafka）に保存
ストリーム処理エンジンが唯一の処理パス
再処理が必要な場合はログを再生（Replay）

項目	Lambda	Kappa
処理パス	バッチ + ストリーミング	ストリーミングのみ
コード重複	あり	なし
運用負荷	高	低
再処理	バッチで実行	ログ再生で実行
データ保持	ストレージ + ログ	ログ（長期保持）
適用条件	複雑な集計、厳密な正確性	ストリーム処理で完結する場合

どちらを選ぶか

Lambdaが適するケース

バッチでしか計算できない複雑な集計（機械学習モデルの再学習等）
ストリーム処理の近似値では許容できない厳密な正確性が必要
既存のバッチパイプラインがあり、リアルタイム機能を追加したい

Kappaが適するケース

全ての処理がストリームで完結する
運用チームが小さく、シンプルさが重要
イベントログの長期保持が可能

現実的なアプローチ

推奨: 段階的アプローチ

Step 1: バッチ処理でMVPを構築
Step 2: リアルタイム要件が明確な機能だけストリーミング化
Step 3: 必要に応じてLambda/Kappaを採用

Unified Batch + Streaming

近年のフレームワークはバッチとストリーミングの統一APIを提供しています。

# Apache Spark Structured Streaming の例
from pyspark.sql import SparkSession

spark = SparkSession.builder.getOrCreate()

# ストリーミング読み込み
stream_df = (
    spark.readStream
    .format("kafka")
    .option("kafka.bootstrap.servers", "localhost:9092")
    .option("subscribe", "orders")
    .load()
)

# バッチと同じAPIで処理
result = (
    stream_df
    .selectExpr("CAST(value AS STRING) as json")
    .select(from_json("json", schema).alias("data"))
    .select("data.*")
    .groupBy(window("timestamp", "5 minutes"))
    .agg(sum("total_amount").alias("revenue"))
)

# ストリーミング出力
query = (
    result.writeStream
    .outputMode("update")
    .format("console")
    .start()
)

まとめ

項目	ポイント
Lambda	バッチ + ストリーミングの2パス、正確性重視だが運用負荷が高い
Kappa	ストリーミングのみ、シンプルだがログ長期保持が前提
選択基準	正確性要件、チーム規模、既存資産を考慮
統一API	Spark等で同じコードでバッチ/ストリーミングを処理

チェックリスト

LambdaアーキテクチャとKappaアーキテクチャの違いを説明できる
各アーキテクチャの長所と短所を比較できる
ユースケースに応じた適切なアーキテクチャを選択できる
段階的なアプローチで導入する戦略を理解している

次のステップへ

Lambda/Kappaアーキテクチャを理解しました。次は演習でストリーミングパイプラインを実際に設計してみましょう。

推定読了時間：30分