Amazon Kinesis で構築するリアルタイムデータパイプライン - Data Streams と Data Firehose の使い分け
Data Streams でリアルタイムデータを取り込み、Data Firehose で S3・Redshift・OpenSearch に自動配信する。シャード設計とオンデマンドモードの使い分けでストリーミングパイプラインを構築する方法を解説します。
Kinesis の概要
Kinesis はリアルタイムストリーミングデータの収集・処理・分析を提供するサービス群です。Data Streams はカスタムコンシューマーによるリアルタイム処理、Data Firehose は S3 や Redshift への自動配信、Managed Apache Flink はストリームデータへの SQL/Flink 処理を提供します。
Data Streams と Firehose の使い分け
Data Streams はシャード単位でスループットを管理し、Lambda や KCL (Kinesis Client Library) でカスタム処理を実装します。サブ秒のレイテンシが必要なリアルタイムアラートや、複数のコンシューマーが同じストリームを読む場合に適しています。Data Firehose はプロデューサーからのデータを自動的にバッファリングし、S3、Redshift、OpenSearch、Splunk に配信します。配信前にデータ変換 (Lambda) やフォーマット変換 (Parquet) を適用でき、コンシューマーの実装が不要です。ログの集約と分析基盤への配信には Firehose が最適です。
Data Streams の設計パターン
Data Streams のシャード数はスループット要件で決定します。 1 シャードは書き込み 1 MB/秒 (1,000 レコード/秒)、読み取り 2 MB/秒を提供します。オンデマンドモードではシャード数が自動調整され、プロビジョンドモードでは手動で設定します。パーティションキーの設計でデータの分散を制御し、ホットシャード (特定シャードへの偏り) を防止します。拡張ファンアウトを有効にすると、コンシューマーごとに専用の 2 MB/秒の読み取りスループットが割り当てられ、複数のコンシューマーが互いに影響せずにデータを処理できます。 KCL (Kinesis Client Library) はシャードのリバランスとチェックポイントを自動管理し、コンシューマーアプリケーションの開発を簡素化します。 Kinesis について体系的に学びたい方は、関連書籍 (Amazon)も参考になります。
Kinesis の料金最適化
Data Streams のプロビジョンドモードはシャード時間 (約 0.015 ドル/時) と PUT ペイロードユニット (25KB 単位、100 万ユニットあたり約 0.014 ドル) で課金されます。オンデマンドモードはデータ取り込み量 (1 GB あたり約 0.08 ドル) と読み取り量で課金され、トラフィックが変動するワークロードに適しています。Data Firehose は取り込みデータ量 (1 GB あたり約 0.029 ドル) のみの課金で、シャード管理が不要です。レコードの集約 (複数の小さなレコードを 1 つの PUT にまとめる) で PUT ペイロードユニット数を削減し、Data Streams のコストを最適化します。データ保持期間をデフォルトの 24 時間から延長すると追加料金が発生するため、リプレイ要件に応じて最小限に設定します。
Lambda 連携とエラー処理
Data Streams を Lambda で処理する場合、イベントソースマッピングがシャードからのレコード取得とバッチ呼び出しを管理します。処理に失敗したバッチは再試行されますが、特定のレコードで詰まり続けると後続が滞るため、失敗箇所を二分探索で切り分ける設定や、再試行回数の上限、失敗レコードの退避先を指定して、問題のあるレコードだけを隔離します。シャードあたりの並列実行数を上げるとスループットが増し、それでも同一シャード内の順序は保たれます。これらを適切に設定することで、安定したリアルタイム処理を実現できます。
Firehose の変換と配信設計
Data Firehose は、配信前にデータを加工できます。Lambda でレコードを変換し、JSON を Parquet などの列指向形式へ変換して保存すれば、後段の分析クエリが高速かつ低コストになります。動的パーティショニングを使うと、レコードの内容に応じて S3 の保存先パスを振り分けられ、日付や属性ごとに整理されたデータレイクを自動で構築できます。バッファのサイズと時間を調整してレイテンシとファイルサイズのバランスを取り、変換や配信に失敗したレコードは専用のエラー出力先に退避させて、取りこぼしを防ぎます。
順序保証・再処理・保持期間
Data Streams ではシャード単位で順序が保たれるため、順序が重要なデータはパーティションキーの設計で同じシャードに集約します。データはストリームに一定期間保持され、保持期間内であればコンシューマーが過去に遡って再処理 (リプレイ) できます。障害でコンシューマーが停止しても、復旧後に取りこぼした分から読み直せるのが利点です。ただし保持期間の延長は追加コストになるため、再処理の要件に見合った期間に設定します。重複処理が起こりうる前提で、処理を冪等に設計しておくと、再処理時の副作用を避けられます。
監視と運用のポイント
ストリーミング基盤では、コンシューマーの遅延を示す指標 (取得したレコードの経過時間) を監視することが最重要です。これが増加し続ける場合、処理能力が取り込み量に追いついていないサインなので、シャード数やコンシューマーの並列度を見直します。書き込みや読み取りのスロットリングが発生していないかも確認し、ホットシャードの兆候があればパーティションキーの設計を改善します。これらの指標をダッシュボードとアラームで継続的に追うことで、遅延や取りこぼしが深刻化する前に手を打てます。
まとめ
Kinesis はリアルタイムストリーミングデータの処理基盤です。Data Streams でカスタムリアルタイム処理を実装し、拡張ファンアウトで複数コンシューマーの並列処理を実現します。Data Firehose で S3 や Redshift への配信を自動化し、レコード集約で PUT ペイロードユニット数を削減してコストを最適化します。オンデマンドモードでシャード管理の運用負荷も排除できます。