API・メッセージング

ストリーミング処理すとりーみんぐしょり

リアルタイム処理Apache Kafkaイベント駆動メッセージキューバッチ処理データパイプライン

ストリーミング処理について教えて

簡単に言うとこんな感じ！

データが届くたびにすぐ処理する仕組みだよ！動画をダウンロードし終わってから再生するんじゃなくて、届いた分からどんどん再生する感じ。注文が入った瞬間に在庫を減らしたり、不正取引をリアルタイムで検知したりできるんだ！

ストリーミング処理とは

ストリーミング処理とは、データが生成されたそのタイミングで、次々と連続的に処理していく方式のことです。センサーのログ、ユーザーのクリック操作、決済トランザクションなど、絶え間なく流れてくる「データストリーム」をリアルタイムに処理し、素早く結果を得ることができます。

従来のバッチ処理（データを一定量ためてから一括処理する方式）と対照的な概念で、「夜間バッチで翌朝に集計結果が出る」のではなく「操作した瞬間に集計が更新される」という体験を実現します。ECサイトのリアルタイム在庫反映、不正検知、IoTセンサーの異常アラートなど、ビジネスの即時性が求められる場面で広く使われています。

システム選定の場面では「どれくらいの遅延（レイテンシ）が許容されるか」がバッチ処理との使い分けの鍵になります。コストや複雑さはバッチより高くなる傾向がありますが、「リアルタイム性」が競争優位につながる領域では投資対効果が高い技術です。

ストリーミング処理の仕組みと構造

データの流れを「川」に例えると理解しやすいです。川（ストリーム）は常に流れ続けており、途中に設置した「水車」（処理ノード）が流れてきた水を受け取って仕事をします。

役割	概念	具体例
データ発生源	プロデューサー	Webアプリ、センサー、POS端末
データの通り道	ストリーム／トピック	Kafkaトピック、Kinesisストリーム
処理ロジック	コンシューマー／プロセッサー	集計・フィルタ・変換を行うアプリ
結果の保存先	シンク（Sink）	データベース、ダッシュボード、アラート

覚え方：「川と水車」で整理しよう

🌊 プロデューサー（源流）→ ストリーム（川）→ プロセッサー（水車）→ シンク（ダム・貯水池）

この流れを意識すると、「どこが遅延しているか」「どこを増強すれば処理が速くなるか」の議論がしやすくなります。

ストリーミング処理の主要概念

用語	意味
イベント	処理の最小単位。「ユーザーAが商品Xをクリックした」など
ウィンドウ	一定時間や件数でイベントをまとめて集計する単位（例：直近5分間の注文数）
レイテンシ	データ発生から処理完了までの遅延時間
スループット	単位時間あたりに処理できるイベント数
バックプレッシャー	処理が追いつかない時に上流を制御する仕組み
Exactly-once	同じイベントを重複なく、かつ欠けることなく1回だけ処理する保証

歴史と背景

1990年代後半〜2000年代初頭：インターネットの普及により、Webサーバーのアクセスログが爆発的に増加。夜間バッチでの分析では翌朝まで結果が出ず、リアルタイム性の必要性が意識され始める
2000年代中頃：金融業界で高頻度取引（HFT）や不正検知のニーズが高まり、ミリ秒単位の処理が求められるようになる
2011年：Twitter社がApache Stormをオープンソースとして公開。分散ストリーミング処理の先駆けとして注目を集める
2011年：LinkedIn社がApache Kafkaを開発・公開。メッセージキューとストリーミング処理基盤として急速に普及
2014年：Apache Flinkが登場。真のストリーミング（1イベントずつ処理）と強力な状態管理で高い評価を獲得
2016年：Apache Spark Structured Streamingが登場。バッチ処理との統一APIで使いやすさが向上
2019年〜現在：クラウド各社（AWS Kinesis、Google Cloud Dataflow、Azure Event Hubs）がマネージドサービスを拡充。インフラ管理不要でストリーミング処理を導入できる時代に

バッチ処理との比較・主要ツール

ストリーミング処理とバッチ処理は対立ではなく、用途に応じた使い分けが重要です。

比較項目	バッチ処理	ストリーミング処理
処理タイミング	一定量たまったら一括	発生したらすぐ
遅延	分〜時間単位	ミリ秒〜秒単位
コスト・複雑さ	低め	高め
向いているケース	月次集計・レポート・ML学習	不正検知・在庫管理・IoT監視
代表ツール	Hadoop、Spark Batch	Kafka、Flink、Kinesis

主要ストリーミング処理プラットフォームの位置づけ

ストリーミング処理導入時のチェックポイント

【発注・選定時に確認すべき3つの問い】

Q1. どのくらいの遅延が許容されますか？
    ・ミリ秒以内 → Flink等の本格ストリーミング
    ・数秒〜1分  → Spark Streamingや準リアルタイムも選択肢
    ・数時間以内 → バッチ処理で十分かも

Q2. 1秒あたり何件のイベントを処理しますか？
    ・数百件/秒   → 小規模、シンプルな構成でOK
    ・数万件/秒以上 → Kafkaなどの高スループット基盤が必要

Q3. 同じデータを2回処理したら困りますか？
    ・困る（決済・在庫など） → Exactly-once保証が必要
    ・少し重複してもOK      → at-least-onceで十分、コスト低

規格・RFC番号	内容
RFC 4287	Atom配信フォーマット（ストリーミング的なフィード配信の基礎）
RFC 7540	HTTP/2（ストリーミング転送を効率化するサーバープッシュ等を規定）
RFC 8441	HTTP/2上でのWebSocketブートストラップ（双方向ストリーミング通信）