Amazon Kinesis入門｜リアルタイムデータストリーミングの基礎からKDS・KFF・KDAの違いまで現場で使える実践ガイド

ログファイルやセンサーデータ、Webのアクセスログなど、「データが止まらず流れ続ける」ような場面で、バッチ処理では追いつかないと感じたことはないでしょうか。オンプレ時代は一定時間ログを溜めてから夜間バッチで処理するのが定番でしたが、クラウド時代はリアルタイムでデータを処理してビジネスに活かす設計が当たり前になってきました。

この記事では、AWSのリアルタイムデータストリーミングサービス群「Amazon Kinesis」について、オンプレ経験者にもわかりやすく解説します。Kinesis Data Streams・Kinesis Data Firehose・Kinesis Data Analyticsそれぞれの違いと、実際の使い方・料金・現場Tipsまで体系的にまとめています。

なぜリアルタイムストリーミングが必要なのか？バッチ処理との違い

オンプレ環境では、ログの収集といえばfluentdやrsyslogで1時間おきにS3やNFSに書き出し、夜間バッチでまとめて集計するパターンが主流でした。これはこれで堅実な設計ですが、次のような場面では限界があります。

・不正アクセスのリアルタイム検知: 1時間後に集計しても手遅れになる
・ECサイトの購買データ分析: キャンペーン効果をリアルタイムで把握して施策を即座に切り替えたい
・IoTセンサーデータの異常検知: 機器の故障を予兆段階で検知してダウンタイムを防ぎたい
・ゲームのスコアボード: プレイヤーのアクションを即時反映させたい
・金融系の取引監視: 不正取引パターンを検知して自動でアカウントをロックしたい

こういった「データが発生した瞬間に処理が必要な」ユースケースに対応するのが、リアルタイムストリーミングアーキテクチャです。オンプレで言えばApache Kafkaがその代表格ですが、Amazon KinesisはそのマネージドサービスとしてAWSが提供しています。インフラの構築・維持管理なしにストリーミング基盤を素早く立ち上げられるのが最大のメリットです。

バッチ処理とストリーミング処理の違いを整理すると次のようになります。

「両方使う」のが現場の正解です。例えば「IoTセンサーデータをKinesisでリアルタイム異常検知しつつ、同じデータをS3に蓄積して月次でバッチ集計する」という組み合わせはよく見られます。

Amazon Kinesisのサービス群と違い

「Kinesis」という名前がついたサービスはAWSに複数存在します。まずここをしっかり整理しておきましょう。

この記事ではインフラエンジニアが現場で使う機会の多い「KDS・KFF・KDA」の3つに絞って解説します。

1. Kinesis Data Streams（KDS）の仕組み

KDSは、データの送り手（Producer）と受け手（Consumer）を分離するためのストリームです。Kafkaでいう「トピック」に相当します。

ストリームは「シャード」という単位に分割されており、1シャードあたりの処理能力は次の通りです。

・書き込み上限: 最大1,000レコード/秒 または 1MB/秒（どちらか先に到達した方）
・読み取り上限: 最大2MB/秒
・データ保持期間: デフォルト24時間（最大365日まで延長可能）

大量のデータを処理したい場合はシャード数を増やす（スケールアウト）ことで対応します。保持期間内はConsumerが何度でも再読み取りできるため、Consumer側に障害が起きても後からデータを再処理できます。これはKafkaのオフセット管理と同じ考え方です。

容量モードは「プロビジョニング済み」と「オンデマンド」の2種類があります。オンデマンドモードはシャード数を自動でスケールしてくれるため、検証環境や負荷が読みにくいシステムに向いています。本番環境で安定した負荷が見えてきたらプロビジョニング済みに切り替えてコストを最適化するのが定石です。

2. Kinesis Data Firehose（KFF）の仕組み

KFFは、受け取ったデータをバッファリングして宛先に自動配信するフルマネージドサービスです。対応宛先は以下の通りです。

・Amazon S3: ログのアーカイブやデータレイク構築に最適
・Amazon Redshift: S3経由でDWHにロード
・Amazon OpenSearch Service: ログ検索・可視化に活用
・Splunk / HTTP Endpoint: サードパーティツールへの配信

KDSとの最大の違いは、ConsumerのコードやLambda関数を自分で書かなくても良い点です。バッファリング（一定サイズ or 一定時間で自動フラッシュ）と宛先配信が自動化されているため、「S3にアクセスログをリアルタイムで貯めたい」程度の用途ならKFF単体で完結します。データ変換が必要な場合は、Lambda関数を組み込んでフォーマット変換（JSON→Parquet等）も可能です。

3. Kinesis Data Analytics（KDA）の仕組み

KDAは、KDSやKFFのストリームデータに対してSQLまたはApache Flinkを使ってリアルタイム集計・フィルタリングを行うサービスです。

たとえば「直近1分間のエラーレートが5%を超えたらCloudWatchアラームを発火させる」「5秒間の移動平均を計算して外れ値を検知する」といった処理を、SQLのウィンドウ関数で記述できます。オンプレでSpark Streamingや自作メッセージ処理スクリプトを書いていたエンジニアにとって、SQLだけで同等の処理を実装できるのは大きな魅力です。Apache Flinkアプリケーションで複雑な処理も書けます。

基本的な使い方（KDSの実践手順）

ここでは最も基礎的なKDSのストリーム作成から、データの送受信までを順番に解説します。コンソール操作とCLI操作の両方を紹介します。

1. データストリームの作成

AWSマネジメントコンソールから「Kinesis」を検索し、「Kinesis Data Streams」→「データストリームを作成」を選択します。

設定項目のポイントは以下の2点です。

・データストリーム名: 任意の名前（例: access-log-stream）
・容量モード: 「プロビジョニング済み」（シャード数を手動指定）または「オンデマンド」（自動スケール）

AWS CLIで作成する場合は次のコマンドを使います。

# AWS CLI でKDSストリームを作成
# --stream-name: ストリーム名
# --shard-count: シャード数（プロビジョニングモードの場合）

aws kinesis create-stream \
  --stream-name access-log-stream \
  --shard-count 1

# 作成確認
aws kinesis describe-stream-summary \
  --stream-name access-log-stream

小規模な検証やトラフィックが読めない場合は「オンデマンド」から始めるのをお勧めします。

2. データの送信（Producer）

AWS CLIでテスト送信する場合は次のコマンドを使います。

# AWS CLI でテストレコードを送信
# --data: 送信データ（Base64エンコード済み文字列）
# --partition-key: シャードの振り分けキー（任意の文字列）

aws kinesis put-record \
  --stream-name access-log-stream \
  --data "$(echo -n '{"timestamp":"2026-05-07T10:00:00Z","level":"ERROR","message":"DB connection failed"}' | base64)" \
  --partition-key "server-01"

# 複数レコードをまとめて送信（最大500件）
aws kinesis put-records \
  --stream-name access-log-stream \
  --records file://records.json

実際のProducerには、AWS SDK（Python/Java/Node.js等）またはKinesis Producer Library（KPL）を使います。KPLはバッチ送信・圧縮・再試行を自動化してくれるため、本番環境での採用を積極的に検討してください。特に高スループットが求められる場面では、KPLの集約機能により1つのKinesisレコードに複数のアプリケーションレコードをパックしてコストを削減できます。

3. データの受信（Consumer）

KDSのデータを読み取る（Consume）には、Lambda関数をEventSourceMappingで接続する方法が最もシンプルです。

# Lambda関数をKDSトリガーに接続
# --starting-position: TRIM_HORIZON=最初から / LATEST=最新から
# --batch-size: 1回の呼び出しで処理するレコード数（最大10,000）

aws lambda create-event-source-mapping \
  --function-name process-access-log \
  --event-source-arn arn:aws:kinesis:ap-northeast-1:123456789012:stream/access-log-stream \
  --starting-position TRIM_HORIZON \
  --batch-size 100 \
  --bisect-batch-on-function-error

LambdaはKDSからポーリングして自動でデータを受け取ります。Lambda関数内でレコードのBase64デコードと処理ロジックを実装します。`–bisect-batch-on-function-error`オプションを付けると、処理失敗時にバッチを二分割して問題レコードを特定しやすくなります。本番環境では必ず設定しておきましょう。

4. Kinesis Data Firehoseの設定（S3配信）

KFFでS3にデータを配信する場合の基本設定です。

# KFF配信ストリームを作成（コンソールからGUIで設定するのが一般的だが、CLIの例）
aws firehose create-delivery-stream \
  --delivery-stream-name access-log-to-s3 \
  --delivery-stream-type DirectPut \
  --s3-destination-configuration '{
    "RoleARN": "arn:aws:iam::123456789012:role/firehose-s3-role",
    "BucketARN": "arn:aws:s3:::my-access-log-bucket",
    "Prefix": "access-logs/year=!{timestamp:yyyy}/month=!{timestamp:MM}/day=!{timestamp:dd}/",
    "BufferingHints": {
      "SizeInMBs": 5,
      "IntervalInSeconds": 300
    },
    "CompressionFormat": "GZIP"
  }'

バッファサイズ（SizeInMBs）またはバッファ間隔（IntervalInSeconds）のどちらかを満たしたタイミングでS3に書き出します。GZIPやParquet形式での圧縮もサポートしており、S3のストレージコスト削減と後続のクエリ処理速度向上に繋がります。

料金の仕組み（コスト感覚）

KDS・KFF・KDAそれぞれの課金単位を整理します（2026年5月時点・東京リージョン、USD表記）。

コスト注意点1 — KDSのシャード課金:
KDSのプロビジョニングモードでは、シャードが増えると時間課金がかさみます。1シャードあたり月額で計算すると約$10.8（$0.015 × 24時間 × 30日）です。シャードを10個立てると月額$108のベースコストがかかります。トラフィックが予測しやすい本番環境ではシャード数を絞り込み、予測が難しい検証環境ではオンデマンドモードを使うと無駄な費用を抑えられます。

コスト注意点2 — KFFの小ファイル問題:
KFFのバッファ間隔を短く（60秒）設定すると、S3に大量の小さなファイルが生成されます。後続のAWS Glue・Athenaのスキャン効率が落ちてコストが増えるため、リアルタイム性よりもコスト重視の場面では5分〜15分のバッファ間隔に設定するのが現場の定石です。

コスト注意点3 — KDAのKPU課金:
KDAは「起動しているだけで課金」されます。クエリを動かしていない時間も含めてKPU課金が発生するため、24時間起動すると月額約$80/KPU（$0.11 × 24 × 30）になります。検証が終わったらアプリケーションを必ず停止してください。

応用・実務Tips

KDS vs KFFをどう選ぶか:
まず「宛先がS3・Redshift・OpenSearchだけで、特にコードを書かずに流し込みたい」という場合はKFFを選びます。Consumer側でビジネスロジック（異常検知・集計・データ変換）が必要な場合はKDSを選びます。KFFはKDSをソースとして接続することもできるため、「KDSでリアルタイム処理 → KFFでS3にアーカイブ」という組み合わせが現場では最も多いパターンです。

シャード数の見積もり方:
1シャードは書き込み1MB/秒・1,000レコード/秒が上限です。想定ピーク時のデータ量をMB/秒で見積もり、余裕を持って1.5〜2倍のシャード数を設定するのが現場の定石です。例えばピーク時に3MB/秒のデータが来るなら、3 × 2 = 6シャードを目安にします。オンデマンドモードなら自動でスケールするため、最初はオンデマンドで実負荷を計測してからシャード数を決めるのが安全です。

Enhanced Fan-Outで複数Consumerを高速化:
デフォルトのGetRecords APIを使う場合、全Consumerで共有される読み取りスループット（2MB/秒/シャード）が分散します。Enhanced Fan-Out（拡張ファンアウト）を有効にすると、Consumer専用に2MB/秒/シャードが確保されるため、複数の独立したConsumerを低レイテンシーで動かせます。ただし追加料金（$0.015/シャード時間 + $0.013/GB）がかかります。

オンプレKafkaからの移行の判断基準:
Amazon MSK（Managed Streaming for Apache Kafka）もAWSにはあります。既存のKafkaコードをほぼ流用したい場合はMSK、新規開発でAWSネイティブに構築したい場合はKDSが適しています。MSKは既存Kafkaエコシステム（Kafka Connect、Kafka Streams）との親和性が高く、KDSはAWS Lambda・Glue・Firehoseとの統合がより自然です。

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

ProvisionedThroughputExceededExceptionが発生する
シャードの書き込み上限（1MB/秒または1,000レコード/秒）を超えているサインです。対処法は2つあります。①シャード数を増やしてスループットを拡張する、②Producerに指数バックオフ＋ジッター付きのリトライを実装して書き込みを分散させる。KPLを使っている場合は自動でリトライしますが、シャード不足の根本原因を解消することが先決です。CloudWatchのIncomingRecords/IncomingBytesメトリクスで使用率を定常的に監視しましょう。

Consumer Lagが増え続ける
ConsumerのGetRecords.IteratorAgeMillisecondsをCloudWatchで監視していると、処理速度がProducerの書き込み速度に追いついていないことがわかります。対処法として、①Lambdaの同時実行数を増やす（シャードあたり最大10並列）、②バッチサイズを増やして1回の呼び出しでより多くのレコードを処理する、③Enhanced Fan-Outを有効化して複数Consumerのレイテンシーをフラットにするといったアプローチがあります。

データ保持期間を超えてデータが消える
KDSのデフォルト保持期間は24時間です。Consumer側の障害復旧が24時間を超えると、そのデータは永久に失われます。重要なデータは保持期間を7日〜365日に延長するか、KFFと組み合わせてS3に常時バックアップしておくことをお勧めします。データ保持期間の延長は1時間あたり$0.023/シャード（東京リージョン）の追加料金がかかります。

KFFのS3配信が遅い
KFFのバッファ設定（サイズと時間）が大きすぎると、S3への配信が遅れます。準リアルタイムで確認したい場合はバッファ間隔を60秒（最小値）・バッファサイズを1MB（最小値）に設定してください。ただし、小さなファイルが大量生成される「S3の小ファイル問題」との兼ね合いで調整が必要です。S3配信の成否はCloudWatchのDeliveryToS3.Success/Failedメトリクスで確認できます。

Lambda関数がKDSのレコードを重複処理する
KDSはAt-Least-Once配信を保証します。つまり同一レコードが複数回ConsumerのLambdaに届く可能性があります。副作用のある処理（DBへの書き込みなど）は冪等性（同じレコードを2回処理しても結果が変わらない設計）を確保することが重要です。レコードのシーケンス番号やパーティションキーをDynamoDBに記録して重複排除するパターンがよく使われます。

本記事のまとめ

Amazon Kinesisは、オンプレのバッチ処理からリアルタイムストリーミングへ移行する際の中核サービスです。まずサービスの使い分けを頭に入れておきましょう。

「KDSで収集・処理 → KFFでS3にアーカイブ」という組み合わせが現場では最もよく使われます。まずはAWSコンソールからKDSのストリームを1つ作成して、AWS CLIでレコードを送受信する実験から始めると理解が深まります。

AWSのサーバー構築やLinuxコマンドの基礎については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。クラウドとLinuxを組み合わせた現場力を身につけたい方はあわせてご覧ください。