Amazon Kinesisとリアルタイムストリーミング
バッチ処理とストリーミング処理の違いを整理し、Amazon Kinesisの主要サービスを用途に合わせて選ぶ方法を学びます。
データをまとめて処理するか、届くそばから処理するか
データ処理の方式は、大きくバッチ処理とストリーミング処理に分けられます。両者の違いは、データを処理単位にまとめてから実行するか、データの到着に合わせて継続的に実行するかです。
| 観点 | バッチ処理 | ストリーミング処理 |
|---|---|---|
| データの扱い | 一定期間や一定量のデータを集め、まとまりとして処理する | 到着したデータを連続したイベントとして扱う |
| 処理開始 | スケジュール時刻、またはデータ量などの条件を満たしたとき | データが到着するたび、または短い間隔で継続的に |
| 結果が得られるまで | バッチの収集・実行間隔に左右される | 低遅延で結果を反映しやすい |
| 適した例 | 前日の売上を集計し、定期レポートを作る | 工場設備の振動値を監視し、異常の兆候を検出する |
バッチ処理は、まとまったデータ全体を対象に集計や変換を行いやすい方式です。たとえば、毎晩一日の出荷実績をまとめて集計する場合、処理を決まった時刻に開始できます。データをためてから実行するため、結果が必要になる時点まで一定の遅れを許容できる分析に向いています。
ストリーミング処理では、データの発生後すぐに処理を始めます。設備から継続的に届く振動値を監視する例では、一定時間幅の平均や最大値を計算し、通常範囲を外れた状態を見つけたら担当システムへ通知できます。過去の期間を振り返る処理だけでなく、現在進行中のデータから状況を判断したい場合に有効です。
リアルタイムといっても、すべてのデータを1件ずつ即時に保存・分析するとは限りません。一定の時間幅やデータ量で区切って集約し、そのまとまりを処理する場合もあります。許容できる遅延、処理内容、配信先に合わせて、どこでどの程度バッファーを持つかを決めます。
リアルタイム処理を支える要素
ストリーム処理を成立させるには、データを受け取るだけでは足りません。取り込みから分析までを継続して動かし、流量が変わっても処理が追いつく仕組みが必要です。
- 安定してデータを収集する
多数の機器やアプリケーションから発生するデータを、欠落や過剰な待ち時間を抑えながら受け取ります。 - 到着データを整形・集計・保存する
データ形式を整えたり、時間幅ごとの集計値を計算したり、後から分析できる保存先へ送ったりします。処理に必要な間だけ一時的にデータを保持することもあります。 - 新しいデータから継続的に分析する
直近の状態や変化を評価し、ダッシュボードの更新や異常検知、後続処理の起動につなげます。 - 流量の変化に対処する
通常時とピーク時のデータ量が大きく違う場合でも、取り込み側と処理側の容量を適切に確保し、遅延や処理待ちが増えすぎないようにします。
Amazon Kinesisは、AWS上でストリーミングデータを取り込み、処理し、配信または分析するためのサービス群です。Kinesisという単一の処理エンジンがすべてを行うのではなく、データを保持するサービス、保存先へ届けるサービス、ストリームに計算を適用するサービスなどから、要件に合うものを選びます。
Kinesisの主なサービス
Amazon Kinesis Data Streams
Kinesis Data Streamsは、継続的に発生するレコードをストリームに取り込み、一定期間保持して、コンシューマーアプリケーションが読み取れるようにするサービスです。データの取り込みだけでなく、その後にどのような処理を行うかをアプリケーション側で設計したい場合に適しています。
プロデューサーがレコードを書き込み、コンシューマーがストリームから読み出して処理します。複数のコンシューマーを用意すれば、同じ取り込みデータをそれぞれ別の目的に利用できます。保持されたデータを読み進める方式なので、コンシューマーの処理位置を管理し、必要に応じて過去のレコードを再処理する設計にも使えます。
一方、コンシューマーの実装、処理の再試行や重複への対応、ストリーム容量の設計など、データを使うアプリケーション側で考える範囲があります。取り込み後の処理を細かく制御したい場合や、複数の利用者が同じストリームを別々に処理したい場合に候補になります。
Amazon Data Firehose
Amazon Data Firehoseは、ストリーミングデータを保存先や分析先へ配信するフルマネージドサービスです。送信元からデータを受け取り、設定した配信先へ届けるため、配信だけを目的とするコンシューマーアプリケーションを自分で常時運用する必要がありません。設定により、配信前のデータ変換や形式変換を組み合わせることもできます。
配信先にはAmazon S3、Amazon Redshift、Amazon OpenSearch Serviceなどがあり、対応するサードパーティーの宛先も利用できます。データはバッファーサイズまたはバッファー時間の条件に応じて配信されるため、常に1件ずつ即時に転送されるわけではありません。設定や配信先に応じた遅延を許容しながら、ストリームをデータレイクや分析先へ届けたい場合に向いています。
名称には注意が必要です。Amazon Data Firehoseは、以前のAmazon Kinesis Data Firehoseから2024年2月に変更された現在のサービス名です。古い問題文、画面、資料に旧名称が残っていても、同じ配信サービスを指すことがあります。
Amazon Managed Service for Apache Flink
Amazon Managed Service for Apache Flinkは、Apache Flinkを使ったストリーム処理アプリケーションをAWS上で実行するマネージドサービスです。継続して届くデータに集計や変換を適用し、状態を維持する処理や、イベント時刻を考慮した時間窓の分析などを構築できます。基盤のプロビジョニングやFlinkアプリケーションの運用をAWSに任せながら、処理ロジックを実装できます。対話的にデータを調査・分析する用途では、Apache Zeppelinベースのノートブック環境を提供するAmazon Managed Service for Apache Flink Studioもあります。
サービス名は、2023年にAmazon Kinesis Data Analytics for Apache Flinkから変更されました。したがって、現在のAWSサービスを選ぶ場面ではManaged Service for Apache Flinkという名称を使います。
過去に使われたAmazon Kinesis Data Analytics for SQL Applicationsは別の旧サービスです。これはManaged Service for Apache Flinkへ名前だけを変更したものではありません。新規アプリケーションの作成は2025年10月15日に終了し、既存アプリケーションも2026年1月27日から利用できなくなりました。古い説明にあるSQL版を、現在利用可能な選択肢として扱わないようにします。
Amazon Kinesis Video Streams
Amazon Kinesis Video Streamsは、カメラなどから映像をAWSへ取り込み、必要に応じて保存し、リアルタイムまたは保存後に利用できるようにするサービスです。映像のフレーム単位の処理、ライブ再生、保存映像の分析など、メディアデータ向けの機能を提供します。音声やレーダーなど、時間情報を伴うメディア以外のデータも扱えます。
一般的なアプリケーションイベントやログを扱うData Streams、保存先へ配信するData Firehose、連続データを計算するManaged Service for Apache Flinkとは、対象データと用途が異なります。動画を中心とした取り込み・保存・再生が必要なときに、専用サービスとして検討します。
目的からサービスを選ぶ
| 要件 | 主な選択肢 | 判断のポイント |
|---|---|---|
| レコードを保持し、独自のコンシューマーで処理したい | Kinesis Data Streams | データ保持と読み取り位置を活用し、アプリケーションで処理方法を制御する |
| データをS3や分析先へ継続的に届けたい | Amazon Data Firehose | 配信先とバッファー条件を設定し、配信処理のアプリケーション運用を減らす |
| 時間窓の集計や状態を持つストリーム分析を行いたい | Amazon Managed Service for Apache Flink | Apache Flinkの処理ロジックをマネージド環境で継続実行する |
| ライブ映像を取り込み、保存・再生・分析したい | Amazon Kinesis Video Streams | 一般的なレコードストリームではなく、映像などのメディアデータを扱う |
たとえば、工場設備の測定値を到着直後に複雑なルールで評価するなら、Data Streamsとストリーム処理アプリケーションの組み合わせが候補になります。生産ラインの稼働記録を長期分析用のAmazon S3へ定期的に送りたいなら、Data Firehoseが候補です。一定時間ごとの振動値の分布や異常傾向を継続計算したいならManaged Service for Apache Flinkを検討できます。設備のカメラ映像そのものをライブ表示・解析する要件であれば、Kinesis Video Streamsの役割です。
ここで重要なのは、Data StreamsとData Firehoseを単純な新旧や優劣で比較しないことです。Data Streamsはストリームをアプリケーションで読み取るための仕組みを提供し、Data Firehoseはデータを配信先へ運ぶ作業を引き受けます。前者は処理の自由度とコンシューマー設計が中心で、後者は配信先、変換、運用負荷、許容できる配信遅延が選択の軸になります。
学習時に押さえる区別
- バッチ処理とストリーミング処理:データをまとめてから処理するのか、データの到着に合わせて継続処理するのか。
- Data StreamsとData Firehose:保持されたストリームをアプリケーションで消費するのか、マネージドな配信サービスで宛先へ届けるのか。
- Data FirehoseとManaged Service for Apache Flink:配信先へデータをロードするのか、Flinkの計算ロジックで継続的に処理・分析するのか。
- 標準イベントと映像:一般的なデータレコードの取り込み・分析と、ライブ映像の転送・保存・再生はサービスの目的が異なる。
- 新旧名称:Kinesis Data FirehoseはAmazon Data Firehose、Kinesis Data Analytics for Apache FlinkはAmazon Managed Service for Apache Flinkへ名称が変わった。Kinesis Data Analytics for SQL Applicationsは別サービスで、2026年1月に終了している。
Kinesisのサービス群が適しているのは、発生直後のデータに基づいて監視・分析・連携を行う必要がある場面です。日次集計のように処理開始を遅らせてもよいならバッチ方式、到着直後の状態変化を扱うならストリーミング方式を基準に考えます。そのうえで、アプリケーションによる柔軟な消費、マネージドな配信、ストリーム分析、映像処理のどれが必要かを選びます。
公式ドキュメント
重要ポイント
- ▸バッチ処理は一定期間に集めたデータをまとめて処理し、ストリーミング処理は到着するデータを継続的に処理する
- ▸リアルタイム処理には、安定した取り込み、継続的な変換・集計、低遅延な分析、負荷変動への対応が必要
- ▸Kinesis Data Streamsは保持したストリームをアプリケーションで読み取り、処理方法を細かく制御したい場合に使う
- ▸Amazon Data Firehoseはサーバーやコンシューマーアプリを運用せず、ストリーミングデータを対応する保存先や分析先へ配信する
- ▸Amazon Managed Service for Apache Flinkは、ストリーミングデータに継続的な計算や状態を持つ分析を適用する
- ▸Amazon Kinesis Video Streamsは映像などのメディアデータを取り込み、保存、再生、分析する専用サービス
このトピックの学習を完了しますか?
完了状態はいつでも切り替えられます
この試験ドメイン内で次の学習に進む
同じサービスの関連トピック
連携サービス に関連するトピックを続けて確認できます。