Lambdaアーキテクチャとは？バッチ層とスピード層の構成・二重計上の対処とKappaとの選び分け

Lambdaアーキテクチャは、同じ入力データをバッチ処理とストリーム処理の2経路に流し、クエリ時に両方の結果を合成して返すデータ処理の構成です。Nathan Marz氏が2011年10月13日のブログ「How to beat the CAP theorem」で示し、Marz氏とJames Warren氏の共著『Big Data』（Manning・2015年4月刊）で体系化されました。名前は似ていますが、AWSのサーバーレス実行環境であるAWS Lambdaとは無関係です。この記事では3つの層が何を出力するのか、両方のビューを足すときに何が壊れるのかを実際に動かしたコードで確認し、Kappaやレイクハウスとどう選び分けるかまでを扱います。

まとめ

• バッチ層が全履歴からバッチビューを、スピード層が直近データからリアルタイムビューを作り、サービング層はバッチビューを読み取り可能な形で保持する分担です。両者の合成はクエリ側で行います。
• 初出は2011年10月13日のブログで、原文はバッチ層とリアルタイム層の2系統として書かれています。「サービング層」は後年の整理で付いた呼び名です。
• 2つのビューを単純に足すと境界のイベントが二重計上されます。バッチ側が取り込み済みの範囲とスピード側の範囲を重ねない、というのが合成の前提です。
• Jay Kreps氏は2014年7月2日に「Questioning the Lambda Architecture」を公開し、同じロジックを2つの分散システムで保守する負担を批判してKappaアーキテクチャを提案しました。
• 2026年9月時点で新規に組むなら、Lambdaは第一候補になりません。既存のバッチ基盤に速報経路を足す場合や、確定値と速報値で求められる精度が本質的に違う場合に検討します。
• 旧来の定番だったSummingbirdは2022年1月にアーカイブ済み、Spark Streaming（DStream）はSpark 3.4.0で非推奨です。構成例をそのまま流用しないでください。

3つの層が担う処理と出力

Lambdaアーキテクチャは、到着したデータを複製して2本の経路に同時に流します。片方は精度を優先して遅れる経路、もう片方は速度を優先して粗い経路です。Microsoftのアーキテクチャガイドはこの2本をコールドパス（バッチ層）とホットパス（スピード層）と呼んでいます。

バッチ層：不変のマスターデータセットとバッチビュー

バッチ層は、受け取った生データを上書きせずに追記だけで保持します。値の訂正も「新しいタイムスタンプ付きレコードの追加」として表現するため、任意の時点の状態を後から再計算できるのが利点です。効いてくるのは復旧時です。集計ロジックにバグが見つかっても、ロジックを直して全履歴を流し直せば、誤った集計結果は完全に置き換わります。

そのうえで、定期的に全件を走査して集計結果を事前計算し、バッチビューとして保存します。実行間隔は鮮度の要件と処理量から決めます。反映までの遅れに効くのは待ち時間だけではありません。計算そのものにかかる時間と、ビューを差し替えるまでの時間も積み上がります。

スピード層：直近ウィンドウだけを扱うリアルタイムビュー

スピード層が担当するのは、バッチ層がまだ取り込めていない直近の数時間分だけです。全履歴をリアルタイムに処理しようとしないことが要点で、原文はTo compensate for those few hours of data, you need a realtime system that runs in parallel with the batch system.と書いています。対象を直近に限るから、逐次更新という重い処理が現実的なコストに収まります。

扱う範囲が狭いぶん、集計を近似で済ませる余地があります。バッチ層が追いついた時点で同じ区間が再計算値に置き換わるため、速報値の誤差を捨てられるからです。ただし近似が前提というわけではなく、厳密に数えるかどうかは業務要件で決めます。実装にはKafkaのようなログ基盤とストリーム処理エンジンを組み合わせるのが一般的です。処理モデルそのものの違いはストリーム処理とは？仕組み・処理モデルとバッチ処理との使い分けを実装視点で解説で扱っています。

サービング層：バッチビューの格納とランダム読み取り

サービング層の役割は、しばしば「2つのビューを合成する層」と説明されますが、原著の定義は違います。書籍『Big Data』1.7.2はThe serving layer is a specialized distributed database that loads in a batch view and makes it possible to do random reads on it.と書いています。つまりサービング層が読み込むのはバッチビューだけで、新しいものができると自動で差し替わる仕組みです。

このデータベースに求められる性質も限定的です。原著はA serving layer database supports batch updates and random reads. Most notably, it doesn't need to support random writes.と続けています。ランダム書き込みを捨てることでデータベースの複雑さの大半が消える、という設計判断です。ElephantDBやVoldemort read-onlyが挙げられていたのはこのためです。

では2つのビューはどこで合成されるのか。クエリ側です。原文はTo resolve a query function, you query the batch view and the realtime view and merge the results together.と書いており、両方を引いて突き合わせるのはクエリを発行する側の仕事とされています。責務の置き場所は実装で変わりますが、原著は合成をサービング層の定義に含めていません。

そもそも2011年のブログ本文に「serving layer」という語は一度も登場しません（全文を取得して確認）。3層という整理とこの呼称が定着したのは書籍化以降です。原典と用語が一致しなくても誤りではありません。

AWS Lambdaとの同名異義

「lambda architecture」で検索すると、AWS LambdaのCPUアーキテクチャ（x86_64とarm64の選択）を説明した公式ドキュメントが混ざって出てきます。2つのLambdaは無関係です。

Lambdaアーキテクチャは製品名ではなく、データ処理の設計パターンの呼び名です。一方のAWS Lambdaは、イベントを受けて関数を実行するマネージドサービスです。AWS Lambdaを使わずにLambdaアーキテクチャを組むことも、AWS Lambdaでスピード層の一部を実装することもできます。同じ資料に両方が登場することもあるため、設計書でこの語を見たらどちらを指しているか先に確認してください。

バッチ処理とリアルタイム処理を両方持つ理由

バッチ処理は全件を対象にできるので精度が高く、そのぶん結果が出るまで待たされます。ストリーム処理は到着した順に処理するので速い代わりに、全履歴の走査や複雑な結合には向きません。どちらか一方では「正確かつ最新」を同時に満たせない、というのがLambdaアーキテクチャの出発点です。

ただし、この前提は2011年当時のものです。当時のストリーム処理エンジンは全履歴の再計算を現実的な時間で終えられませんでしたが、現在はそこが変わりました。

ビューを足すと二重計上が起きる条件

合成で最初に問題になるのが、対象期間の重なりです。バッチビューとリアルタイムビューは同じイベントを含みうるため、素直に足すと2回数えます。どの程度ずれるのかを、5件のイベントで実際に動かして確認します。

from datetime import datetime, timezone

def ts(s):
    return datetime.fromisoformat(s).replace(tzinfo=timezone.utc)

events = [
    ("u1", ts("2026-09-18T09:58:00"), 1),
    ("u2", ts("2026-09-18T09:59:30"), 1),
    ("u3", ts("2026-09-18T10:00:10"), 1),
    ("u4", ts("2026-09-18T10:01:00"), 1),
    ("u5", ts("2026-09-18T10:02:40"), 1),
]

batch_upto = ts("2026-09-18T10:01:30")
speed_from = ts("2026-09-18T09:59:00")

batch_view = sum(v for _, t, v in events if t <= batch_upto)
speed_naive = sum(v for _, t, v in events if t >= speed_from)
speed_fixed = sum(v for _, t, v in events if t > batch_upto)

print("events total     :", sum(v for _, _, v in events))
print("batch_view       :", batch_view)
print("speed_view naive :", speed_naive)
print("merged   naive   :", batch_view + speed_naive)
print("speed_view fixed :", speed_fixed)
print("merged   fixed   :", batch_view + speed_fixed)

Python 3.9.6で実行した結果です。

events total     : 5
batch_view       : 4
speed_view naive : 4
merged   naive   : 8
speed_view fixed : 1
merged   fixed   : 5

実際のイベントは5件なのに、素朴な合成は8を返しました。スピード層の集計開始時刻（09:59:00）がバッチ層の取り込み済み境界（10:01:30）より前にあるため、その間の3件が両方のビューに入っているからです。修正版はスピード層の条件をt > batch_uptoに変え、正しく5を返しています。

ここから導かれる実装上の要件は3つです。第1に、公開済みのバッチビューがどの範囲の入力を含んでいるかを、ビューと対応付けて管理する必要があります。バッチジョブが遅延したときに進まなくなるのはこの境界のほうで、現在時刻との差が開いていきます。境界を固定値で書くと、遅延した瞬間に取りこぼしが出ます。

第2に必要なのは、スピード層の保持期間を、その境界が現在時刻から最も離れうる幅より長く取ることです。バッチが4時間遅れうるのに直近1時間しか保持していなければ、その差が欠損になります。

第3に、合計値ではなくユニークユーザー数のような重複排除を伴う指標は、足し算では合成できません。厳密に求めるならユーザーIDの集合を両方のビューに持たせて和集合の要素数を数えます。近似でよければ、ユーザーIDを登録したHyperLogLogのようなマージ可能な構造をビューに置き、マージしてから基数を推定します。

上のコードには前提があります。境界時刻以前のイベントがすべてバッチビューに入っている、という前提です。遅れて到着したイベントがあるとこの前提が崩れ、時刻だけで切る修正版でも次のバッチまで集計から抜け落ちます。実務での対処は、取り込み範囲を時刻ではなく入力のオフセットやバッチIDで管理するか、遅延分の補正を別に設けるかの二択です。遅延データをストリーム処理エンジン側でどう扱うかはウォーターマーク（ストリーム処理）とは？生成戦略と進行停止の切り分けを解説にまとめています。

主要コンポーネントの保守状況

Lambdaアーキテクチャの解説記事には、10年前の構成例がそのまま残っていることがあります。2026年9月時点の状況は次のとおりです。

最も注意が要るのはSummingbirdです。バッチとストリームで同じロジックを二重実装する問題への回避策として長く紹介されてきましたが、リポジトリは2022年1月20日にアーカイブされて読み取り専用になり、READMEにはstatus: retiredのバッジが付いています。READMEのMaven利用案内に記載されたバージョンは0.9.1、GitHubのリリース一覧で最も新しいものは2016年6月23日のv0.11.0-RC1です。新規プロジェクトの選択肢にはなりません。

Spark Streamingも同様です。DStreamベースのAPIはSpark 3.4.0で非推奨となり、公式ドキュメントはThere are no longer updates to DStream and it's a legacy project.と明記したうえでYou should use Spark Structured Streaming for your streaming applications.と案内しています。Structured StreamingはバッチとストリームでDataFrame／Dataset APIが共通なので、二重実装の問題自体が小さくなります。

Apache Stormは終わっていません。3.0.0が2026年7月22日、3.1.0が2026年9月12日にリリースされており、開発は継続しています。選定で比較したいのは保守状況よりもAPIの形です。Flinkは同じDataStreamプログラムをenv.setRuntimeMode(RuntimeExecutionMode.BATCH);でバッチ実行でき、公式ドキュメントは有限入力なら実行モードによらずwill produce the same final results regardless of the configured execution modeと説明しています。バッチ層とスピード層を1つのコードベースで書ける、という意味です。エンジンの選定はApache Flinkとは？ユースケース3分類と最新版2.3の構成・Kafkaとの違いを解説、入力側のログ基盤はApache Kafkaとは？仕組み・ユースケースとKafka 4系のKRaft構成を実装視点で解説を参照してください。

Kappa・レイクハウスとの選び分け

Lambdaアーキテクチャの弱点は、性能ではなく保守コストです。同じ集計ロジックをバッチ側とストリーム側の2箇所に書き、両者の結果を一致させ続ける必要があります。この負担に正面から異議を唱えたのがJay Kreps氏で、2014年7月2日のO’Reilly Radar記事はThe problem with the Lambda Architecture is that maintaining code that needs to produce the same result in two complex distributed systems is exactly as painful as it seems like it would be.と書いています。

Kappaアーキテクチャ：処理経路の一本化とログ再生

Kreps氏の提案は、バッチ層を無くしてストリーム処理だけで完結させる構成です。過去データの再計算が必要になったら、ログの先頭からイベントを再生し直して新しいビューを作ります。この名前は同じ記事の中で本人が付けたもので、Maybe we could call this the Kappa Architectureという一文が出典です。ギリシャ文字を割り当てるほどの新規性はないかもしれない、と本人が続けている点も含めて、Lambdaへの対案という位置づけがよく表れています。

ロジックが1箇所になるぶん、保守は明確に楽です。代わりに、ログを必要な再計算期間だけ保持できること、再生が許容時間内に終わることが前提になります。どれだけ遡る必要があるかは要件次第で、Kreps氏の記事も30日分を保持して作り直す例を挙げています。その保持と再生ができない基盤では、Kappaは採用できません。

レイクハウス：共通テーブル基盤と処理エンジンの分担

Microsoftのアーキテクチャガイドは現在、Lambda・Kappaと並べてレイクハウスアーキテクチャを解説しています。Delta LakeやApache Icebergのようなオープンテーブル形式がACIDトランザクションと更新に対応したことで、生データと集計結果を同じテーブル基盤に置き、バッチ処理とストリーム処理の両方から読み書きできるようになりました。Delta Lakeの公式ドキュメントはこれをunifies streaming and batch data processingと表現しています。再計算そのものを実行するのはSparkやFlinkといった処理エンジンで、テーブル形式が計算を肩代わりするわけではありません。層を処理系ではなくテーブルの段階として整理する運用はメダリオンアーキテクチャとは：Bronze・Silver・Goldの層設計と再処理をコード付きで解説、基盤そのものの位置づけはデータレイクハウスとは？データレイク・DWHとの違いとアーキテクチャを実装視点で解説で扱っています。

2026年にLambdaを選ぶ条件と選ばない条件

新規にデータ基盤を設計するなら、Lambdaアーキテクチャは選ばないほうがよい、というのがここでの結論です。理由は単純で、Lambdaが解いていた「ストリーム処理では全履歴を扱えない」という制約が、エンジンとテーブル形式の両側から解消されたからです。Flinkは同じコードでバッチとストリームを実行でき、Structured Streamingは同じDataFrame APIを両方に使え、レイクハウスでは共通のテーブル基盤を両方の処理から読み書きして作り直せます。二重実装のコストを払う見返りが薄くなりました。

それでもLambdaが合理的な場面はあります。すでに本番で動いているバッチ基盤があり、そこにリアルタイムの経路を後付けする場合です。稼働中のバッチジョブと検証済みの集計結果を捨てずに、速報値だけを別経路で足せます。全面移行は避けられますが、2経路の結果を突き合わせる検証と監視は追加で必要になります。もう1つは、バッチ側とストリーム側で求められる精度が本質的に違う場合です。日次の確定レポートは監査に耐える精度が要る一方、ダッシュボードの速報値は概算で構わない、といった要件なら、2つの経路を持つこと自体が仕様になります。

逆に、「リアルタイム集計が欲しい」という要件だけでLambdaを選ぶのは避けてください。この場合に必要なのはストリーム処理基盤であって、バッチ層の追加ではありません。バッチとストリームの記述を1つに寄せる方向であれば、Apache Beamとは｜バッチとストリームを同じコードで書く仕組みとランナー選定の判断基準も選択肢になります。

よくある質問

LambdaアーキテクチャはAWS Lambdaと関係がありますか？

関係ありません。Lambdaアーキテクチャは2011年に提唱されたデータ処理の構成で、AWS Lambdaは2014年に登場したサーバーレスの関数実行サービスです。名前が同じだけで由来も対象も別です。ただしAWS Lambdaをスピード層の実装手段として使うことは可能で、その場合は両方の意味が同じ設計書に登場します。

Lambdaアーキテクチャは誰がいつ提唱しましたか？

Nathan Marz氏が2011年10月13日に公開したブログ「How to beat the CAP theorem」が初出です。体系的な解説は、2015年4月刊のMarz氏・James Warren氏の共著『Big Data』（Manning）にあります。

LambdaとKappaはどちらを選ぶべきですか？

新規構築ならKappa、またはレイクハウス構成を先に検討してください。同じロジックを2箇所に保守する負担が、Lambdaの実運用で最も重くのしかかります。Lambdaが適するのは、既存のバッチ基盤にリアルタイム経路を追加するケースです。ただしKappaはログを長期保持して再生できることが前提なので、その基盤がなければ成立しません。

バッチ処理とリアルタイム処理の違いは何ですか？

入力の区切り方が違います。バッチ処理は期間で区切った有限のデータを一括で処理し、結果が出るまで数十分から数時間かかる代わりに全件を対象にできます。ストリーム処理は終わらない入力を到着順に処理し、ミリ秒から数秒で結果を返す代わりに、全期間の集計や複雑な結合には向きません。

コールドパスとホットパスは何を指しますか？

コールドパスがバッチ層、ホットパスがスピード層を指す別名です。Microsoftのアーキテクチャガイドがこの呼び方を使っています。データが「冷えてから」まとめて処理する経路と、「熱いうちに」即座に処理する経路、という対比です。指しているものは層の名前と同じなので、資料ごとに用語が違っても構成は変わりません。

関連記事

• ストリーム処理とは？仕組み・処理モデルとバッチ処理との使い分けを実装視点で解説
• Apache Flinkとは？ユースケース3分類と最新版2.3の構成・Kafkaとの違いを解説
• メダリオンアーキテクチャとは：Bronze・Silver・Goldの層設計と再処理をコード付きで解説
• ウォーターマーク（ストリーム処理）とは？生成戦略と進行停止の切り分けを解説
• Apache Kafkaとは？仕組み・ユースケースとKafka 4系のKRaft構成を実装視点で解説