Kinesis vs MSK vs SQS — ストリーミングとキューの選択基準
イベントデータを受けて渡す AWS サービスのうち、SQS・SNS・EventBridge の間の選択はメッセージング 3 種比較で扱いました。この記事はその次の分かれ道です。結論を先に書くと、「一度処理して終わり」の作業の受け渡しは SQS、複数のコンシューマーが同じデータを読み直す必要があるストリームは Kinesis、そして Kafka のプロトコル・エコシステムが要件のときだけ MSK です。 ストリームが要らないのに Kinesis を選ぶ、Kafka 要件がないのに MSK を選ぶ、というのがこの領域のよくある過剰設計です。料金は us-east-1 基準です。
一目でわかる比較 #
| 項目 | SQS | Kinesis Data Streams | MSK |
|---|---|---|---|
| モデル | キュー(消費したら削除) | ストリーム(保持期間内は再読) | ストリーム(Kafka) |
| 順序保証 | FIFO キュー限定 | シャード内で保証 | パーティション内で保証 |
| 複数コンシューマー | 不向き(SNS との組み合わせが必要) | 標準サポート | 標準サポート |
| 課金 | 100 万件あたり約 $0.40 | シャード時間あたり約 $0.015 または GB 単位 | ブローカーインスタンス時間 + ストレージ |
| アイドルコスト | 0 | プロビジョンドはシャード維持費 | クラスター常時コスト |
| 運用負担 | ほぼなし | シャード管理(オンデマンドで緩和) | 最大(Express・サーバーレスで緩和) |
| エコシステム | AWS 統合 | AWS 統合(Lambda・Firehose) | Kafka エコシステム全体 |
モデルの違い — 消費したら消えるのか、読み直すのか #
SQS のメッセージは、1 つのコンシューマーが処理して削除したら終わりです。作業の受け渡し、負荷の平準化、非同期処理という用途に正確に合い、Step Functions との役割分担で扱ったとおり、バックエンド処理の基本部品です。料金も 100 万件あたり約 $0.40 で最も単純です。
Kinesis と MSK のストリームは違います。データが保持期間(デフォルト 24 時間、延長可能)の間残っていて、複数のコンシューマーがそれぞれの位置から同じデータを独立に読みます。 クリックストリームをリアルタイムダッシュボードと S3 への蓄積と異常検知が同時に読む構成、障害後に特定時点から読み直す再処理がストリームの固有領域です。逆にコンシューマーが 1 つだけで再読の要件がなければ、ストリームのこの能力は使わない機能に料金と運用を払うことになります。
判断の質問は 2 つです。同じデータを読むコンシューマーが 2 つ以上あるか? 過ぎたデータを読み直す必要があるか? どちらもいいえなら SQS で終わりで、1 つでもはいならストリーム系に進みます。
Kinesis — AWS ネイティブなストリームの 2 モード #
Kinesis Data Streams は AWS 統合が強みです。Lambda トリガー、Firehose 経由の S3・ウェアハウスへの蓄積が設定レベルで付きます。課金モードは 2 つです。
- プロビジョンド: シャード時間あたり約 $0.015。シャードごとに書き込み 1MB/s・読み取り 2MB/s の上限があり、スループットに合わせてシャード数を管理します。シャード 2 個で月約 $22 と、スループットが予測できる常時ストリームでは最も安くなります。
- オンデマンド: スループット管理なしの GB 単位課金です。標準モードで受信 GB あたり約 $0.08、2025 年末に追加された Advantage モードは受信約 $0.032・送信約 $0.016 と単価を大きく下げました(モード・単価は導入時点で再確認)。スパイクが大きいかスループットの予測が立たなければオンデマンドで始め、使用パターンが定まったらプロビジョンドと比較する順序が安全です。
注意すべき落とし穴は、シャード数とコンシューマー数の掛け算です。コンシューマーが増えるとシャードごとの読み取り上限を分け合うため、コンシューマーの多い構成は拡張ファンアウト(enhanced fan-out、追加料金)かシャード増設が必要になります。コンシューマー 3〜4 個の水準までは問題ありませんが、それ以上を計画するなら設計段階で計算しておきます。
MSK — Kafka が要件のときだけ #
MSK はマネージド Kafka です。選ぶ理由は性能ではなくエコシステムと移植性です。既存の Kafka クラスターから移行する場合、Kafka Connect・Streams・Flink のようなエコシステムのツールをそのまま使いたい場合、マルチクラウド・オンプレミスの移植性が要件の場合、パーティション数千個規模の大型ストリームプラットフォームを作る場合が正当な理由です。この要件がなければ、同じストリームモデルをはるかに少ない運用で提供する Kinesis が基本です。
MSK の中にも枝があります。標準ブローカーは、ブローカーインスタンス時間 + EBS ストレージ課金で、ブローカーのサイズ・数・ストレージを自分で運用する伝統的な構成です。Express ブローカーはストレージ管理をなくしてブローカーあたりのスループットを高めた世代で、標準に比べてスループット・復旧速度が大きく改善され、新規プロビジョンドクラスターの推奨デフォルトになりました。MSK サーバーレスはクラスター時間あたり約 $0.75 + パーティション・転送量の課金で、下限が月約 $550 から始まります。サーバーレスという名前と違ってアイドルコストが 0 ではないため、小規模ワークロードならサーバーレス MSK より Kinesis オンデマンドが構造的に安くなります。
選択の手順 #
- キューで足りるかをまず見ます: 複数コンシューマー・再読の要件がなければ SQS です。ストリームは必要になってから導入しても遅くありません。
- ストリームが必要なら Kinesis を基本に置きます: AWS の中で完結するパイプラインなら、Lambda・Firehose 統合が運用の大部分を吸収します。
- Kafka 要件を明示的に確認します: 既存 Kafka の移行、エコシステムのツール、移植性、超大型規模のうち該当する項目を書き出します。なければ MSK を選ぶ理由もありません。
- Kinesis のモードはスループットの予測で分けます: 予測できるならプロビジョンドシャード、不確実ならオンデマンドで始めて実測後に再評価します。
- MSK に進むなら Express ブローカーから検討します: 新規クラスターのデフォルトで、小規模なのに MSK が必要ならサーバーレスの下限コスト(月約 $550)と Kinesis を必ず比較します。
まとめ #
- 判断の質問は 2 つです。コンシューマーが 2 つ以上か、読み直す必要があるか。どちらもいいえなら SQS、1 つでもはいならストリームです。
- ストリームの基本は Kinesis です。AWS 統合が運用を吸収し、プロビジョンドシャード(時間あたり約 $0.015)とオンデマンドの 2 モードで規模に合わせます。
- MSK は Kafka エコシステム・移植性・超大型規模という明示的な要件があるときだけ選びます。要件なしに選ぶのは、最も高い運用を買うことです。
- MSK のプロビジョンドは Express ブローカーが新規のデフォルトで、サーバーレスは下限が月約 $550 なので、小規模では Kinesis オンデマンドが安くなります。
- コンシューマー数 × シャード読み取り上限、オンデマンドの GB 単価といった数値は設計段階で計算し、導入時点で現行料金を再確認します。