ストリーミング処理 vs バッチ処理の違いとは？クラウドデータパイプライン設計とAWS・Azure主要サービス対応表

データパイプラインを設計するとき、「ストリーミング処理」と「バッチ処理」のどちらを選ぶかは、アーキテクチャ全体を左右する重要な判断です。オンプレ時代は夜間バッチ一択だったインフラエンジニアも、クラウドに移行するとリアルタイム処理の選択肢が現実的になり、設計の幅が広がります。

この記事では、ストリーミング処理とバッチ処理の本質的な違いから、それぞれに対応するAWS・Azureの主要サービス一覧、現場での判断フローまでを、オンプレ経験者の視点で整理します。

なぜ「ストリーミング vs バッチ」が設計の分岐点になるのか

オンプレのデータ処理システムでは、夜間バッチによる一括処理が長年の定番でした。処理対象の増減に合わせてサーバーリソースを追加購入するには時間とコストがかかるため、「処理を夜間に集中させて昼間のピーク負荷を回避する」設計が合理的だったからです。

クラウドに移行すると状況が変わります。必要なときに必要なだけリソースを確保・解放できるため、「データが来たらすぐに処理する」ストリーミングアーキテクチャが経済的・技術的に現実的な選択肢になります。

ただしストリーミング処理は万能ではありません。設計の複雑さと常時稼働コストの観点から、バッチ処理の方が適切なケースも多くあります。両者の特性を正確に理解することが、データパイプライン設計の出発点です。

バッチ処理とは何か

1. バッチ処理の仕組みと特徴

バッチ処理とは、一定量のデータをまとめて蓄積し、決まったタイミングで一括処理する方式です。

・蓄積してから処理: 1時間分・1日分のデータを溜めてからまとめて処理する
・スループット重視: 大量データを効率よく一気に処理することに最適化されている
・レイテンシは許容範囲内で無視: 処理完了まで数分～数時間かかっても許容される設計
・スケジュール起動: cronや時間起動トリガーで定期実行されることが多い

オンプレで言えば、毎日深夜2時に実行する売上集計バッチや、月末の請求処理がこれに当たります。

2. オンプレでのバッチ処理との比較

3. バッチ処理に向いているユースケース

・日次売上集計: 前日分のトランザクションを一括集計してDWH（データウェアハウス）に書き込む
・ETL/ELT処理: S3・Azure Blob StorageのrawデータをParquetに変換して分析用DBへロードする
・機械学習モデルの再学習: 週次で大量の教師データを使ってモデルを更新する
・帳票・レポート生成: 月末に全顧客の利用明細PDFを一括生成する
・データバックアップ・エクスポート: 夜間にDBのスナップショットをS3に転送する

ETL・ELTの違いについてはETLとELTの違い：クラウドデータ基盤のパイプライン設計ガイドも参照してください。

ストリーミング処理とは何か

1. ストリーミング処理の仕組みと特徴

ストリーミング処理とは、データが発生した瞬間（またはほぼリアルタイム）に処理する方式です。データは「流れ」として扱われ、蓄積を待たずに逐次処理されます。

・発生即処理: データが届いたタイミングで処理ロジックがすぐに走る
・レイテンシ重視: 数ミリ秒～数秒以内の反応時間が求められる
・継続的稼働: 24時間365日、常にデータを受け付けて処理し続ける
・ウィンドウ処理: 「直近5分間の平均値」など、時間窓を使った集計が可能
・順序・重複への配慮: ネットワーク遅延によるデータ到着順序の逆転や重複を考慮した設計が必要

オンプレに類似するシステムを探すなら、金融系の取引監視システムや製造業のラインセンサー監視が近い立ち位置です。ただしオンプレでは専用ハードウェアが必要だったものが、クラウドではマネージドサービスで実現できます。

2. ストリーミング処理に向いているユースケース

・不正取引検知: クレジットカードの決済データをリアルタイムに分析し、異常なパターンを即座に検知してブロックする
・IoTセンサーデータ処理: 工場のセンサーから毎秒届くデータを処理して異常値を即時アラート
・クリックストリーム分析: Webサイトのユーザー行動をリアルタイムに集計してレコメンド表示に反映
・ログのリアルタイム監視: アプリケーションログをストリームで取り込み、エラーレートの急増を即座に検知
・チャット・メッセージング: ユーザー間のメッセージをキューを通じてリアルタイムに配送する

バッチ処理 vs ストリーミング処理 徹底比較

AWSのサービス対応表

1. バッチ処理系AWSサービス

・AWS Glue: フルマネージドのETL/ELTサービス。Sparkベースのジョブをサーバーレスで実行。S3のrawデータをParquetに変換してAthenaやRedshiftに流す用途が典型的。
・Amazon EMR: HadoopやSparkクラスターをクラウドで動かすサービス。PBクラスの超大規模バッチ処理に対応。Spot Instanceと組み合わせることでコストを大幅に抑えられる。
・AWS Batch: コンテナベースのバッチジョブ管理サービス。EC2やFargateのSpot Instanceを使って大量の並列ジョブを効率よく実行できる。
・Amazon Athena: S3のデータをSQLでクエリするサーバーレス分析サービス。スキャンしたデータ量課金のため、定期バッチ分析に向いている。コスト削減の詳細はAmazon Athena コスト最適化ガイドを参照。
・Amazon Redshift: クラウドDWH。大量データの集計・分析クエリに強い。Serverlessモードならジョブ実行時のみ課金できる。詳細はAmazon Redshift コスト最適化ガイドを参照。

2. ストリーミング処理系AWSサービス

・Amazon Kinesis Data Streams（KDS）: リアルタイムデータストリームの取り込みと配送。最大7日間のデータ保持と複数コンシューマーへの並行配信に対応。詳細はAmazon Kinesis入門ガイドを参照。
・Amazon Kinesis Data Firehose（KFF）: ストリームデータをS3・Redshift・OpenSearchなどに自動配送するサービス。バッファリングで小バッチに変換するため「ニアリアルタイム」処理に最適。コードなしで動く手軽さが特徴。
・Amazon Kinesis Data Analytics（KDA）: Apache Flinkベースのストリーム処理エンジン。ウィンドウ集計・リアルタイム異常検知が可能。SQL APIとFlinkアプリケーションの両方をサポートする。
・Amazon MSK（Managed Streaming for Apache Kafka）: フルマネージドのApache Kafka。複数コンシューマーが同じストリームを独立して読む大規模イベント駆動アーキテクチャに向いている。詳細はAmazon MSK入門ガイドを参照。
・AWS Lambda（イベント駆動）: KinesisやMSKのイベントでトリガーし、軽量なストリーム処理を実行。シンプルな変換・フィルタリング処理には最も手軽な選択肢。
・Amazon EventBridge Pipes: イベントソースとターゲットをローコードで接続。Kinesisほどの高スループットは不要だが、システム間のリアルタイム連携に向いている。

Azureのサービス対応表

1. バッチ処理系Azureサービス

・Azure Data Factory（ADF）: マネージドETLサービス。400以上のコネクタでオンプレ・クラウド間のデータ統合パイプラインを構築できる。AWSのGlueに相当。GUI操作でパイプライン設計が可能な点が特徴。
・Azure HDInsight: HadoopやSparkのマネージドクラスター。大規模バッチ処理に対応。AWS EMRに相当するが、現在はDatabricksに移行するケースが増えている。
・Azure Databricks: Spark + Delta Lakeベースのデータ基盤。バッチとストリーミングを統一した「レイクハウスアーキテクチャ」を実現できる。ノートブック環境の使いやすさで現場での採用が進んでいる。
・Azure Synapse Analytics: データウェアハウス（旧SQL DW）とデータレイクを統合したサービス。Amazon Redshiftの対抗馬。Serverless SQLプールを使えばAthena同様のアドホッククエリも可能。
・Azure Batch: 大規模な並列コンピューティングジョブの実行基盤。AWSのAWS Batchに相当。

2. ストリーミング処理系Azureサービス

・Azure Event Hubs: 大規模なイベントストリームの取り込みサービス。Amazon Kinesis Data Streamsに相当。秒間数百万件のイベント取り込みに対応し、Apache KafkaプロトコルとAPIレベルで互換性がある。
・Azure Stream Analytics: SQLライクなクエリでストリームデータをリアルタイム分析するサービス。Amazon Kinesis Data Analyticsに近い立ち位置。クエリをGUIで設定できるため導入が手軽。
・Azure IoT Hub: IoTデバイスからのデータ受信に特化したストリーミングサービス。デバイス管理・デバイスツイン・D2C/C2Dメッセージングが充実している点がEvent Hubsとの違い。
・Azure Service Bus: メッセージキューとトピック（パブリッシュ/サブスクライブ）を提供。Enterprise Messagingの機能（Dead Letter Queue・セッション・トランザクション）が充実しており、AWSのSQS+SNSよりもエンタープライズ向けのメッセージング要件に向いている。

AWS・Azure サービス早見表

現場での使い分け：設計判断フロー

データパイプラインを設計するとき、まず問うべきは「いつ結果が必要か」という点です。以下のフローで判断してください。

ステップ1: レイテンシ要件を確認する

「データが発生してから、処理結果が必要になるまでの許容時間」を明確にします。

・数秒以内が必要 → ストリーミング処理一択
・数分以内が許容できる → ストリーミングまたはマイクロバッチ（短い間隔でのバッチ）
・1時間以上が許容できる → バッチ処理で十分（シンプルで安価）

ステップ2: データの発生パターンを確認する

・データが常に継続的に発生する（IoT・クリックストリーム・取引ログ）→ ストリーミングが自然
・データが特定タイミングで一気に蓄積される（ログローテーション・日次ファイル転送）→ バッチが向いている

ステップ3: コスト・運用複雑さを評価する

ストリーミングは24時間稼働コストと設計の複雑さを伴います。「リアルタイムである必要が本当にあるか」を改めて問い直してください。多くのビジネス要件は「5分以内の反映」で十分であり、その場合はバッチ（5分間隔）やマイクロバッチで対応できます。

ステップ4: ラムダアーキテクチャ / カッパアーキテクチャを検討する

現場では「バッチ層（高スループット・低コスト）とスピード層（リアルタイム・低レイテンシ）を両方持つ」ラムダアーキテクチャが採用されることもあります。ただし2つのシステムを保守するコストが増えるため、最近はストリーミング処理のみで完結させるカッパアーキテクチャが注目されています。Apache FlinkやSparkのストリーミングモードが成熟した現在、ラムダアーキテクチャを選ぶ理由は減ってきています。

よくあるトラブルと対処法

問題1: ストリーミング処理でデータが重複・欠損する

ネットワーク障害やリトライによってメッセージが重複して届くことがあります。処理ロジックに冪等性（同じメッセージを複数回処理しても結果が変わらない性質）を持たせることが必須です。処理済みのメッセージIDをDynamoDBや Redis に記録して重複を排除する設計が有効です。

詳細は冪等性（Idempotency）設計入門ガイドも参照してください。

問題2: バッチ処理が月末・期末だけ極端に遅延する

処理対象データ量が月末に急増するケースでは、固定のクラスターサイズでは対応できないことがあります。AWS GlueやEMRのオートスケーリング設定、またはSpot Instanceの活用で動的にリソースを拡張する設計を検討してください。データ量のピークに合わせてワーカー数を変えるだけで、コストを抑えながら処理時間を短縮できます。

問題3: Kinesis Data Streamsのシャード詰まり

Kinesisはシャードごとに秒1MB・秒1,000件の書き込み制限があります。急激なデータ増加時にシャードを追加しないと書き込みエラーが発生します。以下のCLIコマンドでシャード数を動的に変更できます。

# AWS CLI: Kinesis Data Streamのシャード数を増やす（スケールアウト）
aws kinesis update-shard-count \
  --stream-name MyDataStream \
  --target-shard-count 4 \
  --scaling-type UNIFORM_SCALING \
  --region ap-northeast-1

# 現在のシャード状況を確認する
aws kinesis describe-stream-summary \
  --stream-name MyDataStream \
  --region ap-northeast-1

CloudWatchの「WriteProvisionedThroughputExceeded」メトリクスをアラートに設定しておくと、詰まりが起きる前に検知できます。

問題4: ストリーミングとバッチの集計結果に乖離が出る

ストリーミング処理で集計した数値と、バッチで集計した数値が一致しないケースは珍しくありません。ウィンドウの定義（イベント時間 vs 処理時間）、遅延データの扱い（Watermark設定）、重複排除ロジックが各システムで揃っているかを確認してください。特に「イベント発生時刻」と「システム受信時刻」のどちらを基準にするかを明確にしておくことが重要です。

問題5: Glueジョブのメモリ不足でジョブが落ちる

AWS Glueはデフォルトのワーカータイプ（G.1X）では扱えるデータ量に限界があります。ジョブが途中で失敗する場合は、ワーカータイプをG.2Xに上げるか、ワーカー数を増やして対応してください。処理するParquetファイルのパーティション設計も見直すと改善することがあります。

本記事のまとめ

ストリーミング処理とバッチ処理の選択は、技術の優劣ではなくビジネス要件とのマッチングです。

「リアルタイムでなければならない理由」がない場合は、シンプルなバッチ処理を選ぶことが現場では正解なことも多い。一方、IoT・金融取引・ユーザー行動分析のように「今起きていることを今知る必要がある」ユースケースでは、ストリーミング処理への投資は十分に回収できます。

データ基盤全体の設計についてはデータレイク・データウェアハウス・データマートの違いも、クラウドへのLinuxサーバー構築の基礎については姉妹サイトLinuxMaster.JPもあわせて参考にしてください。