ストリーミングデータの設計 Kinesis Data Streams・Firehose・MSKを要件から選ぶ

SAA-C03では、ログやクリックストリーム、IoTデータなど「止まらないデータ」を扱うサービス選定が頻出です。Kinesisの3つのサービスとMSKは名前が似ていて混同しやすいため、要件文のどの言葉でどれを選ぶかを整理します。

覚え方は「保持・変換・互換」の3つの観点

ストリーミングの設計は、保持＝データをストリームに残して複数の消費者が読み直す必要があるか、変換＝配信先へ届ける前に整形や圧縮をしたいだけか、互換＝既存のApache Kafkaアプリケーションをそのまま動かしたいか、の3点で決まります。

Kinesis Data Streams：複数のコンシューマーと再読み取り

Data Streamsはシャード単位でレコードを保持し、複数のアプリケーションが独立した位置から読み取れます。保持期間は24時間から最長365日で、「複数の分析アプリが同じデータを並行処理する」「障害後に過去のデータを再処理する」という要件がサインです。シャード数で容量を決めるプロビジョンドモードと、自動で拡縮するオンデマンドモードがあり、書き込みはシャードあたり毎秒1MBまたは1000レコードが目安です。消費側はLambdaのイベントソースやKCL(Kinesis Client Library)を使い、拡張ファンアウトでコンシューマーごとに専用の読み取り帯域を確保できます。

Kinesis Data Firehose：とにかく配信先へ届ける

Firehoseはコードを書かずにS3、Redshift、OpenSearch Service、Splunkなどへデータを配信するサービスです。バッファ(サイズまたは時間)で溜めてから書くため準リアルタイム(最短で数秒から60秒程度)で、Lambdaによる変換やParquetへの形式変換、圧縮を組み込めます。「ログをS3に集めてAthenaで分析したい」「サーバー管理なしでOpenSearchへ流したい」ならFirehoseで、複数コンシューマーや再読み取りは不要というのが典型です。

Amazon MSK：Kafkaをそのまま使う

MSKはマネージドなApache Kafkaです。既存のKafkaプロデューサーやコンシューマーを改修せずに移行したい、Kafkaのエコシステム(Kafka ConnectやSchema Registry)を使いたい、という要件で選びます。MSK Serverlessならクラスターの容量管理も不要です。Kinesisより運用の自由度が高い一方、要件にKafkaという言葉がなければKinesisを選ぶのが基本です。

チェックリスト

• ARRAY(0xa00043088)

まとめ

ストリーミングは「保持・変換・互換」の3観点で読み解けば、Data Streams、Firehose、MSKのどれを選ぶかが要件文から自然に決まります。 理解度の確認にはクイズが便利です。試験範囲や申し込みの最新情報はAWS認定 公式ページもあわせて確認してください。