LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

Kinesis/MSKのストリーミングコストが高くなる理由

Kinesis/MSKのストリーミングコスト最適化とは、Amazon Kinesis Data StreamsまたはAmazon MSK（Amazon Managed Streaming for Apache Kafka、以下MSK）で構築したリアルタイムデータ基盤の運用費用を、機能・可用性を維持しながら適正化する取り組みを指します。

ストリーミング基盤のコストが想定以上に膨らむ背景には、いくつかの共通したパターンがあります。開発当初はトラフィック規模を見積もりながらプロビジョニングしたものの、本番環境での実測値がずれたまま放置されているケースや、デフォルト設定のままデプロイされたパーティション数やデータ保持期間が過剰なまま継続しているケースが代表的です。

Kinesis Data StreamsとAmazon MSKは、リアルタイムデータ処理という目的こそ似ていますが、課金モデルが大きく異なります。どちらのサービスも、設計段階の判断が毎月の請求額に直結するため、料金構造を正確に理解することがコスト最適化の第一歩です。

MSKの課金構造とブローカー種別別コスト最適化

Amazon MSKの料金は、ブローカーの種別（Standard・Express・Serverless）と使用するインスタンスサイズによって決まります^*1。

Standardブローカーでは、kafka.m7g.largeが0.204 USD/時間、kafka.m5.largeが0.21 USD/時間で提供されています。一方のExpressブローカー（express.m7g.large）は0.408 USD/時間と単価は高めですが、データ取り込みが0.01 USD/GBの従量制となっており、スループットの変動が大きいワークロードで総コストを抑えられる場合があります。

Serverlessは0.75 USD/クラスタ時間＋0.0015 USD/パーティション時間で、容量設計が不要な反面、書き込み200 MB/秒・読み込み400 MB/秒のキャパシティ上限があります。継続的に高スループットが必要な用途には向きません。

クラスタ内レプリケーションは無料

MSKのコスト構造で見落とされやすいのが、クラスタ内レプリケーション転送の扱いです。AWS公式ドキュメントによると、「ブローカー間およびメタデータノードとブローカー間のレプリケーションに使用されるデータ転送には料金はかかりません」とされています^*1。

レプリケーション係数を3に設定してもクラスタ内転送コストは発生しないため、可用性とコストのバランスを取る設計が比較的しやすい特徴があります。コストが積み上がるのは主にストレージと外部へのデータ転送です。

Expressブローカーによるブローカー数削減

Expressブローカーは、Standardブローカーと比較してブローカーあたりのスループットが向上しています。AWS公式情報では、同じワークロードをより少ないブローカー数でカバーできる可能性があると案内されています^*2。ブローカー台数を削減できれば、時間課金のトータルコストを抑えられます。

ただし、Expressブローカーが対応するのはm7gインスタンスファミリーのみで、Kafkaバージョン3.6以上が必要です。既存クラスタを移行する場合は、Kafkaバージョンのアップグレードも含めた計画が必要になります。

ストレージ階層化でコスト削減

MSK Standardブローカーでは階層化ストレージが利用できます。プライマリストレージが0.10 USD/GB-月に対し、低コスト層は0.060 USD/GB-月と料金が抑えられます^*1。アクセス頻度の低い古いメッセージを低コスト層に移動させることで、ストレージ費用の圧縮が図れます。取り出しには0.0015 USD/GBが発生する点は踏まえた設計が必要です。

Kinesis Data Streamsのオンデマンド vs プロビジョンド選択

Kinesis Data Streamsには、プロビジョンドモードとオンデマンドモードの2つがあります^*3。選択を誤るとコストが不必要に膨らむため、それぞれの特性を把握しておくことが重要です。

開発・検証環境では、プロビジョンドモードで1シャードのみ確保する運用がコスト抑制に有効です。1シャードの費用は0.015 USD/時間（約11 USD/月）に抑えられます^*3。本番昇格後にシャード数を増やす、または必要に応じてオンデマンドに切り替える設計が現実的です。

一方、データ量が安定して大きい本番環境では、プロビジョンドの方がトータルコストを予測しやすい傾向があります。データ量の推移をCloudWatchで継続的に監視し、モードの見直しタイミングを定期的に判断する体制が必要です。

拡張データ保持はコストに直結

デフォルトのデータ保持期間は24時間ですが、7日間への延長には0.020 USD/シャード時間の追加料金が発生します^*3。7日間を超える長期保持は0.023 USD/GB-月のストレージ料金が別途かかります。保持期間をビジネス要件の最小値に絞ることが、コスト削減の確実な一手です。

共通の最適化レバー：保持期間・パーティション・モニタリング

KinesisとMSKに共通するコスト最適化の手段として、データ保持期間の見直し、パーティション（シャード）設計の最適化、継続的なモニタリングの3点が挙げられます。

データ保持期間は要件の最小値に設定

MSKでもKinesisでも、メッセージの保持期間が長いほどストレージコストが積み上がります。ダウンストリームのコンシューマがデータを処理できる時間を確認し、必要最小限の保持期間に設定することがコスト削減につながります。アーカイブが必要なデータはS3などの低コストストレージに転送し、ストリーミング層の保持期間は短く保つ設計が望ましいです。

パーティション数の適正化

MSK Serverlessはパーティション時間（0.0015 USD/パーティション時間）で課金されます^*1。不要なパーティションを持ち続けると費用が積み上がるため、スループット要件に基づいた設計が必要です。過剰なパーティション数は消費側の処理リソースも増加させるため、ストリーミング基盤全体のコストに影響します。

MSK Standardブローカーでも、コンシューマグループのラグ状況をAmazon CloudWatch経由でモニタリングし、パーティション数の過不足を定期的に評価する運用が推奨されます。

CloudWatchメトリクスによる継続監視

コスト最適化の効果を持続させるには、CloudWatchによるスループット・ラグ・エラー率の継続監視が欠かせません。KinesisではGetRecords.IteratorAgeMilliseconds（コンシューマのラグ）、MSKではKafkaDataLogsDiskUsedやBytesInPerSec/BytesOutPerSecを定期的に確認します。アラームを設定してスロットリングや異常なデータ量増加を早期検知できる体制を整えることで、コストの予期せぬ増加を防げます。

内製対応の壁——必要な専門スキルと工数

ストリーミング基盤のコスト最適化を内製で進める場合、AWSの料金構造の深い理解に加えて複数の専門領域にわたるスキルが求められます。

• Apache Kafka（またはKinesisクライアントライブラリ）の設定チューニング知識
• パーティション設計・レプリケーション係数の設計経験
• AWS Cost ExplorerおよびCloudWatchを用いたコスト分析スキル
• Terraform・CloudFormationなどIaC（Infrastructure as Code）ツールによる設定変更管理
• 本番環境でのサービス無停止移行計画の立案と実行経験

これらを網羅する人材を自社で確保・育成するには、採用から実戦投入まで半年から1年規模のリードタイムを要する場合があります。また、最適化の検討から実装・検証までを一連のプロジェクトとして進めるには、Kafkaを熟知したエンジニア2〜3名が数か月間コミットできる体制が必要です（参考工数：市場参考値・一次資料ではありません）。

内製で特に注意すべきリスクは、設定変更の誤りがサービス停止や本番データの損失につながる可能性がある点です。MSKのブローカー種別変更や、Kinesisのシャード再分割は、手順を誤るとコンシューマのラグが急増し、リアルタイム処理の遅延が発生します。こうした失敗は数時間から数日規模のシステム影響につながるため、本番環境での変更には十分な検証と実績が求められます。

外注で進めるストリーミングコスト最適化の5ステップ

外部パートナーへの委託で進める場合、以下の5ステップが一般的なプロセスになります。

1. 現状診断：AWS Cost ExplorerとCloudWatchのメトリクスを用い、コストの内訳と使用率の乖離を可視化します
2. 最適化案の策定：ブローカー種別・シャード数・保持期間・モードの変更オプションを列挙し、見込み削減幅を算定します
3. ステージング環境での検証：変更後の設定をステージング環境で動作確認し、コンシューマへの影響を測定します
4. 本番移行：サービス影響が出ないよう段階的にロールアウトします。ロールバック手順もあらかじめ準備します
5. 継続監視・再最適化：移行後もCloudWatchアラームとコスト追跡を継続し、トラフィック変化に応じた再最適化を担います

外注の利点は、本番実績のある手順書と実装パターンをすぐに適用できる点にあります。自社でゼロから試行錯誤するよりも、サービス停止リスクを抑えながら短期間で成果を出しやすい傾向があります。

委託範囲は「現状診断と最適化案の提示のみ」から「移行実装と継続監視まで一括」まで幅があります。自社の運用体制や内製エンジニアのスキルレベルに応じて、どこまでを委託するかを最初に明確にしておくことが、契約トラブルの回避につながります。

外注パートナー選定の3つの評価軸

ストリーミング基盤のコスト最適化を委託するパートナーを選ぶ際は、以下の3点で評価することをお勧めします。

評価軸1：KinesisとMSKの両方に対応した実績

KinesisとMSKは課金モデルが異なるため、一方のみの経験では最適な選択ができません。自社が現在使用しているサービスに実績があるかを確認します。MSK ExpressブローカーやServerlessへの移行支援経験があるかどうかも、重要な確認ポイントです。

評価軸2：IaCによる変更管理の実践

Terraform（テラフォーム：クラウドインフラをコードで管理するツール）やAWS CloudFormationを用いた構成管理ができるパートナーかどうかを確認します。手動操作による設定変更は変更履歴が残らず、問題発生時のロールバックに時間がかかります。コードによる管理がされているかは、長期的な保守コストに直結します。

評価軸3：元請（プライムベンダー）としての責任体制

コスト最適化の実装後に問題が発生した場合、誰が責任を持って対応するかを契約前に確認しておくことが重要です。複数の下請けに分散している体制では、問題切り分けと対応に時間がかかるケースがあります。元請（プライムベンダー）として一括で対応できる体制を持つパートナーを選ぶことで、トラブル時の対応速度が向上します。

まとめ：コスト削減に向けた3つの判断軸

本稿では、Amazon Kinesis Data StreamsとAmazon MSKにおけるストリーミングコストの最適化ポイントと、外注で進める際の進め方を整理しました。要点を3点に集約します。

第一に、MSKはブローカー種別（Standard/Express/Serverless）の選択がコストの大枠を決めます。Expressブローカーによるブローカー数削減、階層化ストレージの活用、クラスタ内レプリケーション無料の特性を活かした設計がポイントです。第二に、Kinesisはオンデマンドかプロビジョンドかのモード選択と、データ保持期間の適正化が費用に直結します。開発環境は1シャードのプロビジョンド運用でコストを抑えられます。第三に、設定変更の誤りは本番サービスへの影響リスクを伴うため、Kafka・AWS双方の実績を持つパートナーへの外注が、リスクを抑えた最適化手段として有効です。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Amazon Web Services「Amazon MSK の料金」（2025年確認）
2. *2　出典：Amazon Web Services「Amazon MSK よくある質問」（2025年確認）
3. *3　出典：Amazon Web Services「Amazon Kinesis Data Streams の料金」（2025年確認）

Tweet