Lambda vs Kappa アーキテクチャ比較

データ基盤 UML Architecture

作成日: 2026-04-03 / 作成者: SAS-Sasao

flowchart TB
    SRC["Data Sources: IoT / Web App / Database CDC"]

    subgraph L["Lambda Architecture"]
        direction TB
        LK["Apache Kafka (Message Broker)"]
        subgraph LB["Batch Layer"]
            direction TB
            HDFS["Hadoop HDFS (Raw Store)"] --> SPARK["Apache Spark (Batch)"]
            SPARK --> BV["Batch Views (Druid/HBase)"]
        end
        subgraph LS["Speed Layer"]
            direction TB
            FLINK["Flink/Storm (Stream)"] --> RTV["RT Views (Redis/Cassandra)"]
        end
        LK --> HDFS
        LK --> FLINK
        BV --> SERVE["Serving Layer - Presto/Trino (Merge Views)"]
        RTV --> SERVE
    end

    subgraph K["Kappa Architecture"]
        direction TB
        KK["Apache Kafka (Immutable Log / Long Retention)"]
        SP["Stream Processor (Flink / Kafka Streams)"]
        SS["Serving Store (Elasticsearch / Cassandra)"]
        KK --> SP
        SP --> SS
        SP -.->|"Reprocessing (Log Replay from offset 0)"| KK
    end

    SRC --> LK
    SRC --> KK
    SERVE --> C["Data Consumers: Engineer / Analyst / App"]
    SS --> C

draw.io XML をダウンロード

概要

大規模データ処理における2つの代表的アーキテクチャパターン「Lambda Architecture」と「Kappa Architecture」を同一キャンバス上で並列比較するUMLスタイルの構成図。データ生成者（UMLアクター）、メッセージブローカー（Kafka）、処理エンジン（Spark/Flink）、ストレージ（シリンダー形状のDB）、利用者（アクター/アプリケーション）を適切なUMLシェイプで表現し、全データフローを可視化している。

Nathan Marzの提唱: Lambda ArchitectureはNathan Marzが2011年に提唱。 Batch LayerとSpeed Layerの二重構造で正確性とリアルタイム性を両立する。 Kappa ArchitectureはJay Krepsが2014年に提唱し、ストリーム処理のみで同等の結果を得るシンプル化を実現した。

構成要素

アーキテクチャ	コンポーネント	説明
Lambda	Apache Kafka	メッセージブローカー。全データソースからのイベントを受信
Hadoop HDFS	バッチ層の生データストア。全履歴を永続保存
Apache Spark (Batch)	バッチ処理エンジン。大量データの一括変換・集計
Batch Views (Druid/HBase)	バッチ処理結果の事前集計ビュー
Apache Flink / Storm	スピード層のストリーム処理エンジン。低レイテンシ処理
Real-time Views (Redis)	ストリーム処理結果のリアルタイムビュー
Serving Layer (Presto)	Batch ViewsとRT Viewsをマージしてクエリに応答
Kappa	Apache Kafka (Immutable Log)	イミュータブルログ。長期保持設定で全履歴を保存
Stream Processor (Flink)	唯一の処理パス。全データをストリームとして処理
Serving Store (ES/Cassandra)	処理結果の配信ストア。クエリに直接応答

アーキテクチャ

コンポーネント

説明

Lambda

Apache Kafka

メッセージブローカー。全データソースからのイベントを受信

Hadoop HDFS

バッチ層の生データストア。全履歴を永続保存

Apache Spark (Batch)

バッチ処理エンジン。大量データの一括変換・集計

Batch Views (Druid/HBase)

バッチ処理結果の事前集計ビュー

Apache Flink / Storm

スピード層のストリーム処理エンジン。低レイテンシ処理

Real-time Views (Redis)

ストリーム処理結果のリアルタイムビュー

Serving Layer (Presto)

Batch ViewsとRT Viewsをマージしてクエリに応答

Kappa

Apache Kafka (Immutable Log)

イミュータブルログ。長期保持設定で全履歴を保存

Stream Processor (Flink)

唯一の処理パス。全データをストリームとして処理

Serving Store (ES/Cassandra)

処理結果の配信ストア。クエリに直接応答

設計のポイント

Lambda: 二重パスの正確性保証 — Batch Layerが全履歴から正確な結果を算出し、Speed Layerの近似結果を補正する。最終的整合性（eventual consistency）モデル。

Kappa: 単一パスのシンプルさ — ストリーム処理のみで完結するため、コードベースが統一され運用負荷が低い。再処理はKafka Log Replay（offset 0から再消費）で実現。

Kafkaの役割の違い — Lambdaではメッセージブローカーとして短期バッファ、Kappaではイミュータブルログとして長期保持。Kappaの成立にはKafkaの保持期間設定が鍵。

適用判断の基準 — 大量履歴の再計算が頻繁に必要→Lambda、イベント駆動でリアルタイム性重視→Kappa。多くのモダンシステムはKappa寄りに進化している。

学習ポイント

Batch/Speed二重管理のコスト — Lambda Architectureの最大の課題は、同一のビジネスロジックをBatch（Spark）とSpeed（Flink）の2つのフレームワークで実装・保守する必要がある点。これが技術的負債と運用負荷の主因となる。

イミュータブルログの威力 — Kappa ArchitectureはKafkaのイミュータブルログ（append-only、offset管理）を活用し、「再処理=新しいConsumerを過去のoffsetから再起動する」というシンプルなモデルで再計算を実現する。

ストコン移行への示唆 — コンビニストコンのPOSトランザクションデータは典型的なイベントストリーム。AWS移行時にKinesis Data Streams + Flink（Managed Service）でKappaパターンを適用すれば、リアルタイム売上集計と履歴分析を単一パイプラインで実現できる。

Serving Layerの設計判断 — LambdaのServing Layer（Presto/Trino）はBatch ViewsとRT Viewsのマージクエリを実行する。このマージロジックの複雑さがKappaへの移行動機の一つ。Kappaでは単一のServing Store（ES/Cassandra）に書き込むだけで済む。

現代のハイブリッドアプローチ — 実務ではLambda/Kappaの純粋型ではなく、Delta Lake / Apache Iceberg等のLakehouseアーキテクチャが台頭。バッチとストリームの統合処理を単一フレームワーク（Spark Structured Streaming等）で実現する。

Generated by /company-drawio — draw.io MCP Server