前回の記事では Stream Processing Engine の進化について触れました。今回は少し面白い現象――リアルタイム処理のニーズが出たとき、なぜ HTTP を使おうと考えることがあるのか？――を取り上げます。
HTTP：エンジニアの万能ツール
プロダクトマネージャーが勢いよく言います：
「リアルタイム注文統計システムが欲しい！」
エンジニアの第一直感はだいたいこうです：
「簡単だよ！新しい注文が入ったら統計サービスに POST して、処理が終わったら成功を返せばいい。これで完成！」
なぜこう考えるのか？ それは HTTP がエンジニアにとってスイスアーミーナイフのように万能だからです：
- 馴染みやすさ満点：フロントエンドもバックエンドも使っていて、目をつぶってでも書ける
- ツールの支援が豊富：Postman、curl、Swagger、欲しいものは全部ある
- 学習コストほぼゼロ：Kafka を学ぶより 1000 倍簡単
-
デバッグが超簡単：
curlコマンドひとつでテスト可能
こうして典型的な同期モデルが出来上がります。
この「HTTP」案を見てみましょう
1. 同期システムアーキテクチャ
- 店舗バックエンド（Producer）：新しい注文があれば統計サービスに POST
- 統計サービス（Server）：リクエストを受け取る → メモリ内のカウンタを更新 → 成功を返す
- レポートページ（Consumer）：数秒ごとに GET /stats で最新データを取得
フローチャート：
店舗システム--同期HTTP--> 統計サービス <--同期HTTP-- レポートページ
完璧に見えますよね？エンジニアなら誰でも 5 分で書けますし、新しい技術を学ぶ必要もありません。
しかし…
2. トラフィックが増えると問題が浮き彫りに
HTTP 同期モデルは低トラフィックでは確かに問題なく、シンプルかつ有効です。
しかし、システムが大規模になると次のような課題が現れます：
(1) 高い結合度
店舗システムは統計サービスの処理が完了するまで待たなければ注文処理が終わりません。統計サービスが遅いと、注文 API 全体が遅くなります。
(2) ピークトラフィックの課題
ピーク時に 10 万件の注文が来ると、統計サービスは同時に 10 万件の HTTP リクエストを処理しなければならず、容易にボトルネックになります。
(3) フォールトトレランスの試練
ネットワークの揺らぎやサービス再起動時に、一部の統計データが失われる可能性があります。再送や補償の仕組みが必要になります。
3. なぜ非同期モデルに変えるのか？
同期モデルの根本的な問題は：送信と処理が同じタイミングに縛られていることです。
どちらか一方が遅れると、もう一方も影響を受けます。まるで二人が鎖で繋がれて一緒に走っているようなものです。
より良い方法は**中間レイヤー（メッセージキュー / イベントストリームプラットフォーム）**を導入することです：
- 店舗バックエンド：新しい注文を「イベントストリームに投げる」だけで、統計処理が終わるのを待つ必要はない
- 統計サービス：イベントストリームからデータを取り、自分のペースで処理する
非同期モデルの三大メリット：
- 耐圧性：ピーク時はまずデータをキューに入れて、後から順に処理できる
- 疎結合：店舗システムと統計サービスがお互いに影響しない
- フォールトトレランス：イベントストリーム自体が永続化でき、サービスが落ちても再起動後に補完できる
まとめ
HTTP 同期モデルは素晴らしい出発点であり、小規模システムでは非常に実用的です。
しかしトラフィックが増えると、同期処理の本質的な性質が結合度やスケーラビリティの課題を生みます。
このタイミングで考えるべきは非同期イベント駆動アーキテクチャです。中間レイヤーを挟んでプロデューサーとコンシューマーを疎結合にし、システムをより柔軟にします。
次回はクラシックな Lambda アーキテクチャ を掘り下げ、速さと正確さを両立する仕組みを見ていきましょう！