前回の記事では「トラフィックの増加に伴い、同期処理は結合度とスケーラビリティに課題をもたらす」ことを取り上げました。そこで自然に出てくる発想が「それならストリーミングで全データを処理すればいいのでは？」です。しかし 2010 年代初頭、純粋なストリーミングアーキテクチャは技術的なハードルに直面していました。

ビッグデータ勃興の時代、「即時処理」はまだ贅沢品でした。Hadoop と MapReduce は大規模データのバッチ処理を得意とする一方で、秒〜分レベルの即時クエリにはほとんど対応できませんでした。ラムダアーキテクチャは、この痛点を解決するために生まれた古典的なアーキテクチャです。

Lambda Architecture の設計思想

ラムダアーキテクチャはレイヤー分割の戦略を採用し、データ処理を 3 つの独立した層に分けます。

                    Raw Data Stream
                          │
                ┌───────────────────┐
                │                   │
                ▼                   ▼
        ┌─────────────┐      ┌──────────────┐
        │ Batch Layer │      │ Speed Layer  │
        │             │      │              │
        │             │      │              │
        └─────────────┘      └──────────────┘
                │                    │
                │                    │
                │                    │
                └──────────┼─────────┘
                           ▼
                ┌─────────────────────┐
                │   Serving Layer     │
                └─────────────────────┘

三層アーキテクチャの詳解

Batch Layer（バッチ層）

役割：全量データを処理し、最終的な正確性を担保
特徴：処理は遅いが結果は完全に正確。複雑な分析に適する
技術スタック：Hadoop、Spark、Hive

Speed Layer（スピード層）

役割：最新到着データを処理し、低レイテンシな結果を提供
技術スタック：Storm、Flink、Kafka Streams

Serving Layer（サービング層）

役割：2 層の結果を統合し、外部に統一クエリインターフェースを提供
特徴：利用者はデータの出所を意識せず、透過的にクエリできる
技術スタック：Cassandra、HBase、Elasticsearch

この設計の核心は、「即時性」と「最終的一貫性（正確性）」の両立にあります。

実装方法

ラムダアーキテクチャの典型的な実装では次のように進めます。

Batch Layer の処理フロー：

Hadoop、Hive、Spark で履歴の全量データを処理
毎日（または数時間ごと）に完全再計算
処理後に Serving DB へ書き込み

Speed Layer の処理フロー：

Storm、Spark Streaming、Flink で新着データを処理
直近の時間窓（数秒〜数時間）だけを対象に処理
同じ Serving DB を即時更新

クエリ側の統合：

クエリ側は Serving DB に対してリクエストを送るだけで、Batch と Speed のデータが透過的に統合されます。

Lambda Architecture の実装コンセプト

💡注意

本文のコードはすべて概念説明のための擬似コード（Pseudo Code）です。実装上の考え方とフローを示すことが目的です。

EC の注文集計を例にします：

from flask import Flask, jsonify

app = Flask(__name__)

@app.route("/query/<merchant_id>")
def query(merchant_id):
    batch_result = query_batch_table(merchant_id)# バッチ層の結果を照会
    speed_result = query_speed_table(merchant_id)# スピード層の結果を照会
    combined_result = batch_result + speed_result# 照会結果をマージするreturn jsonify({"merchant_id": merchant_id, "order_count": combined_result})

def query_batch_table(merchant_id):
# バッチ層の照会を模擬（完全な履歴データ）return 1000# 仮にバッチ計算が 1000 件とするdef query_speed_table(merchant_id):
# スピード層の照会（本日の増分）を模擬。ここでいくつかの計算が行われるreturn 50# 仮にスピード計算が 50 件とするif __name__ == "__main__":
    app.run(debug=True)

このコードはラムダアーキテクチャの要点――クエリ時に Batch と Speed の結果を動的に合算し、利用者に「準リアルタイムでありつつ最終的に正しい」データを提供する――を示しています。

長所・短所の分析

長所

インフラ制約の克服：スピード層が Hadoop の高レイテンシという弱点を補完
明快で拡張しやすいアーキテクチャ：バッチとスピードが独立にスケールし相互干渉しない
クエリ層の単純化：クエリは単一のサービング DB に投げるだけ
高いフォールトトレランス：2 系統が相互のバックアップとなる

短所

開発・運用コストの増大：2 つの処理ロジックを維持し、一貫性を保つのは難しい
デバッグの複雑さ：2 系統のロジックによりデータ追跡が困難
Serving DB への高負荷要件：高並行書き込みと安定したクエリを両立する必要

まとめ

Hadoop 時代、ラムダアーキテクチャは確かに核心的な痛点を解消し、企業に初めて「ほぼ即時」の分析体験をもたらしました。開発・運用のコストは倍増しましたが、その進化の過程が示すのは、アーキテクチャとは当時の技術的制約の中での最良の折衷である、という事実です。

最初の 3 日間は理論面から以下を検討しました：

なぜ HTTP の同期モデルを選ぶのか
同期モデルの課題と非同期化の必然性
ラムダアーキテクチャはどのように即時性と正確性を両立するか

次回からはいよいよ机上の空論を離れて実戦に入ります！

Day 4 からの十数日は実装に手を動かし、まずは素の Python で Kafka consumer を書くところから始め、シンプルな擬似コードを通じて、ストリーム処理エンジンの核となる機能と動作原理を段階的に理解していきます。

袖をまくってコードを書く準備はできましたか？当時のエンジニアたちが、いかにして素朴な手段を積み重ねて強力なストリーム処理システムを作り上げたのかを、一緒に体感していきましょう！