Amazon MSK（Managed Streaming for Apache Kafka）入門｜オンプレKafkaクラスターをAWSで完全マネージド化する実践ガイド

「自社でKafkaクラスターを3年以上運用してきたが、ZooKeeperのバージョン管理やブローカーのOSパッチ当て、クラスター拡張時のパーティション再バランス作業で運用チームが消耗している」──そういった現場は今も珍しくない。

Amazon MSK（Managed Streaming for Apache Kafka）は、KafkaブローカーをAWSがフルマネージドで提供するサービスだ。既存のKafkaアプリケーションが使っているAPIをそのまま使えるため、オンプレからの移行ハードルが低く、運用負荷を大幅に削減できる。

この記事では、すでにKafkaを知っているオンプレ出身のインフラエンジニアを対象に、MSKの仕組み・料金体系・クラスター作成から接続確認までの手順・よくあるトラブルと対処法まで解説する。

なぜMSKなのか？オンプレKafkaとの違いと移行の背景

オンプレでKafkaを自前運用すると、以下の作業が継続的に発生する。

・ZooKeeperの管理: Kafkaのメタデータ管理に使うZooKeeperも別クラスターとして構築・運用が必要。Kafka 3.7以降のKRaftモードでZooKeeperレスになるが、移行作業自体が一仕事になる
・ブローカーOSのパッチ適用: ブローカーが動くサーバーのセキュリティパッチを定期的に当てる必要がある。ローリングアップデート中もパーティションリーダーの移動が発生する
・クラスター拡張時の再バランス: ブローカー追加後のパーティション再バランスは、ネットワーク帯域を消費しながら時間がかかる。cruise-controlなどのツールで管理している現場も多い
・監視基盤の整備: JMXエクスポーター＋Prometheus＋Grafanaの組み合わせを自前で構築・維持しなければならない
・ディスク容量管理: ログ保持期間とブローカー台数の掛け算でストレージが膨らみ、増設タイミングの判断が難しい

MSKが肩代わりしてくれる主な作業は次のとおりだ。

・ZooKeeperまたはKRaftノードの管理: ユーザーはZooKeeperの存在を意識しなくてよい
・ブローカーのOSパッチ: AWSがバックグラウンドで自動適用する
・マルチAZ配置: 3ブローカー構成のとき、デフォルトで3つのアベイラビリティゾーンに分散配置される
・CloudWatch統合: JMXメトリクスがCloudWatchに自動連携される
・ストレージのTiered Storage: S3をバックエンドにした階層型ストレージでブローカーのディスクコストを削減できる

ただし、Kafkaのメジャーバージョンアップはユーザー側でトリガーする必要がある点は把握しておくこと。コントロールプレーンの更新はAWS任せだが、Kafkaのバージョンは自分で引き上げる。「マネージドだから完全放置できる」は過信だ。また、トピック設定（`log.retention.hours`等）の変更もユーザー作業となる。

オンプレとMSKの運用負荷比較をまとめると次のようになる。

MSKの基本アーキテクチャを理解する

MSKを構成する主要コンポーネントは次のとおりだ。

・ブローカーノード: Kafkaブローカーが動くEC2インスタンス相当のリソース。ユーザーはインスタンスタイプ（kafka.m5.largeなど）を選択するが、SSH等でブローカーに直接入ることはできない
・ZooKeeperノード（Kafka 3.6以前）: MSKがAWSアカウント内の別VPCで管理する。ZooKeeper接続エンドポイントが提供されるが、ノード自体の操作は不可
・KRaftモード（Kafka 3.7以降）: ZooKeeperを使わずKafka自体でメタデータを管理する。新規クラスター作成時に選択できる
・VPC統合: MSKはユーザーのVPC内にElastic Network Interface（ENI）を作成する。アプリケーションはVPC内からブローカーエンドポイントに接続する
・KMSによる暗号化: 保存データはデフォルトでAWS管理のKMSキーで暗号化される。顧客管理キー（CMK）も指定可能だ

クライアントからの接続プロトコルは次の3種類から選択できる。

・PLAINTEXT（ポート9092）: 暗号化なし。VPC内の閉域通信に限定されるが、本番環境ではTLSを使うべきだ
・TLS（ポート9094）: 通信を暗号化する。MSKがACMによる証明書を自動管理する
・SASL/SCRAM（ポート9096）: ユーザー名/パスワード認証。AWS Secrets Managerに認証情報を格納して使う

ネットワーク設計で最初につまずくポイントは、ブローカーエンドポイントがVPC内のプライベートIPアドレスで返ってくることだ。オンプレのKafkaでは外部から直接接続するケースもあるが、MSKはデフォルトでVPC内に閉じている。オンプレのアプリケーションからMSKに接続するには、AWS Direct ConnectかSite-to-Site VPNが必要になる。

基本的な使い方（クラスター作成から接続確認まで）

1. MSKクラスターの作成（マネジメントコンソール）

マネジメントコンソールで「Amazon MSK」→「クラスターを作成」を選択する。主な設定項目は次のとおりだ。

・クラスター作成方法: 「クイック作成」と「カスタム作成」がある。本番環境はカスタム作成でVPCやセキュリティグループを明示的に指定することを推奨する
・Kafkaバージョン: 2026年7月時点では3.7.x系が最新。新規クラスターではKRaftモードを選択できる
・ブローカータイプ: 「プロビジョニング済み（標準ブローカー）」か「MSK Serverless」を選ぶ。標準ブローカーはインスタンスタイプ固定、Serverlessはパーティション時間課金（後述）だ
・ブローカーインスタンスタイプ: 開発・検証用なら `kafka.t3.small`、本番は `kafka.m5.large` 以上が目安。t3系は本番には推奨されない
・ブローカー数とAZ: 本番は3ブローカー（3AZ）が基本。2ブローカー（2AZ）でも動くが、ブローカー障害時の可用性が落ちる
・EBSストレージ（GiB）: 1ブローカーあたりのディスク容量を指定する。作成後も変更可能。Tiered Storageを有効にする場合は最低1000GiBが必要だ
・VPC・サブネット・セキュリティグループ: ブローカーのENIが作成されるサブネットを指定する。プライベートサブネットを選択すること

セキュリティグループは、クライアントEC2のセキュリティグループからMSKブローカーのセキュリティグループへの、Kafkaポート（9092/9094/9096）へのインバウンドルールを設定する。クラスターの作成には15分程度かかる。

2. トピックの作成（Kafka CLI）

クラスターが起動したら、Kafka CLIでトピックを作成する。クライアントとなるEC2インスタンス（ブローカーと同一VPC内）にKafkaのクライアントツールをインストールする。

# Kafkaクライアントツールのインストール（Amazon Linux 2023の例）
sudo dnf install -y java-21-amazon-corretto-headless
wget https://downloads.apache.org/kafka/3.7.0/kafka_2.13-3.7.0.tgz
tar xzf kafka_2.13-3.7.0.tgz
export PATH=$PATH:~/kafka_2.13-3.7.0/bin

# MSKクラスターのブートストラップエンドポイントを確認
# マネジメントコンソール: クラスター詳細→「クライアント情報」タブ
# またはAWS CLI:
# aws kafka get-bootstrap-brokers --cluster-arn 

# トピック作成（パーティション6、レプリケーションファクター3）
kafka-topics.sh --create \
  --bootstrap-server  \
  --command-config client.properties \
  --topic orders \
  --partitions 6 \
  --replication-factor 3

# トピック一覧の確認
kafka-topics.sh --list \
  --bootstrap-server  \
  --command-config client.properties

TLS接続に必要な `client.properties` は次のように設定する。

# client.properties（TLS接続用）
security.protocol=SSL
ssl.truststore.location=/usr/lib/jvm/java-21-amazon-corretto/lib/security/cacerts
ssl.truststore.password=changeit

MSKのTLS証明書はAWS ACMが管理するため、JVMに標準で含まれるトラストストア（cacerts）を参照すればルートCA証明書を別途インポートする必要はない。

3. プロデューサー・コンシューマーの動作確認

Kafkaに付属するコンソールツールで、メッセージの送受信を確認できる。

# コンソールプロデューサー（ターミナル1で実行）
kafka-console-producer.sh \
  --bootstrap-server  \
  --producer.config client.properties \
  --topic orders

# コンソールコンシューマー（ターミナル2で実行）
kafka-console-consumer.sh \
  --bootstrap-server  \
  --consumer.config client.properties \
  --topic orders \
  --from-beginning

プロデューサー側でメッセージを入力すると、コンシューマー側でリアルタイムに受信できることを確認する。ここまで動けばMSKとの基本的な接続は成功だ。

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

MSKの料金は主に次の3軸で構成される（2026年7月時点・東京リージョン ap-northeast-1 の目安。執筆時点の情報のため、最新料金はAWS公式料金ページを参照すること）。

1. ブローカーインスタンス料金
インスタンスタイプ×ブローカー数×稼働時間で課金される。

3ブローカー構成（kafka.m5.large）の場合、ブローカー料金だけで月額約$450前後となる。

2. EBSストレージ料金
1ブローカーあたりのEBS容量に対して約$0.10/GB-月で課金される。3ブローカー×1,000GiBなら月額約$300の追加コストとなる。

3. MSK Serverless（代替オプション）
パーティション時間（約$0.0015/パーティション時間）＋ネットワーク送受信量で課金される。スループットが断続的・予測困難な場合、特に開発環境では有効だ。スループットが安定して高い場合は標準ブローカーのほうがコストパフォーマンスが良くなるケースが多い。

コスト削減の主なポイント
・Tiered Storage: 古いセグメントをS3に自動移行することでブローカーのEBS容量を削減できる。S3の料金はEBSより安いため、保持期間が長いトピック（例: 30日以上のログ）で有効だ
・開発環境はMSK Serverless: 標準ブローカーはクラスターを削除しないと課金が止まらない。開発環境にServerlessを使うと、使わない時間のコストを大幅に削減できる
・インスタンスサイジングの見直し: CloudWatchの `CpuUser`・`NetworkRxThroughput`・`ActiveControllerCount` などのメトリクスを定期的に確認し、オーバープロビジョニングになっていないか点検する

応用・実務Tips

【使い分け】Amazon KinesisとMSKはどちらを選ぶか

ストリーミングサービスとしてAmazon Kinesis Data Streamsと並んで検討されることが多い。両者の選択基準を整理する。

オンプレでKafkaを使っているならMSKのほうが移行コストが低い。既存のKafka資産がなくAWSだけで完結させたい場合は、KinesisのほうがシンプルでLambda等との統合がしやすい。

MSK ConnectでSink/Sourceコネクターを活用する

MSK Connectは、Kafka Connectのマネージドサービスだ。Kafkaのトピックデータを外部システムへ流し込む「Sinkコネクター」や、外部システムからKafkaに取り込む「Sourceコネクター」をマネージドワーカー上で動かせる。

実務でよく使われる組み合わせ例を挙げると次のとおりだ。

・Amazon S3 Sink Connector: トピックデータをS3にParquetやJSONで書き出す。データレイク構築の定番パターンだ
・Amazon OpenSearch Sink Connector: アプリケーションログをKafka経由でOpenSearchに流し込む。ログ分析基盤の構築に有効だ
・JDBC Source Connector: RDBのデータ変更（Change Data Capture）をKafkaトピックに取り込む

オンプレのKafka ConnectワーカーをMSK Connectに置き換えることで、コネクターワーカーの管理をAWSに委任でき、インフラの運用負荷をさらに削減できる。

AWS Glue Schema Registryの統合

オンプレでConfluentのSchema Registryを使っている場合、MSKでの代替としてAWS Glue Schema Registryがある。Avro・Protobuf・JSONスキーマに対応しており、IAMによるアクセス制御が可能だ。

新規構築ならGlue Schema Registryがシンプルで統合しやすい。オンプレからの移行でConfluentのSchema Registryを引き続き使いたい場合は、EC2上にConfluent Schema Registryを別途立ててMSKと組み合わせる形が安定している。

クライアントEC2のLinux設定チューニング

MSKのプロデューサー・コンシューマーが動くEC2インスタンスでは、Kafkaの高スループット処理のためにLinuxのカーネルパラメーターチューニングが効果的な場合がある。`/proc/sys/net/core/wmem_max` や `net.core.rmem_max` の調整など、Linuxの実践的なサーバー設定については姉妹サイトLinuxMaster.JPで解説している。

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

【トラブル1】ブローカーに接続できない（Connection refused / タイムアウト）

最も多い原因はセキュリティグループの設定ミスだ。クライアントEC2のセキュリティグループからMSKブローカーのセキュリティグループへの、Kafkaポート（9092/9094/9096）へのインバウンドルールが正しく設定されているか確認する。

次に多いのは、接続プロトコルとエンドポイントの不一致だ。TLS用エンドポイント（ポート9094）を使いながら `security.protocol=PLAINTEXT` を設定すると接続できない。マネジメントコンソールの「クライアント情報」に表示されるエンドポイント種別と、`client.properties` の `security.protocol` が一致しているかを確認する。

【トラブル2】スループットが期待どおりに上がらない

パーティション数が少ないと、コンシューマーを増やしてもスループットが頭打ちになる。Kafkaの並列度はパーティション数に依存するため、コンシューマーグループのスレッド（インスタンス）数を超えるパーティション数を確保するのが基本だ。パーティション数はトピック作成後に増やせる（減らすことはできない）。

ブローカー側では、CloudWatchの `NetworkRxErrors`・`NetworkTxErrors`・`BytesOutPerSec` を確認してネットワーク帯域が詰まっていないかを確認する。ボトルネックがブローカーインスタンスのネットワーク帯域にある場合はインスタンスタイプのアップサイズを検討する。

【トラブル3】コンシューマーラグが増え続ける

コンシューマーラグ（Consumer Lag）は、プロデューサーが書き込んだ最新オフセットとコンシューマーが処理済みのオフセットの差分だ。ラグが増え続ける場合、コンシューマーの処理速度よりプロデューサーの書き込み量が上回っている状態になっている。

CloudWatchの `EstimatedMaxTimeLag` や `SumOffsetLag` メトリクスを監視し、コンシューマーの処理ロジック最適化・インスタンスのスケールアップ・パーティション追加を組み合わせて対処する。コンシューマーグループに参加できるコンシューマー数はパーティション数が上限のため、パーティションを増やしてから水平スケールする順番で対処する。

【トラブル4】Kafkaバージョンアップ後に接続エラーが発生する

Kafkaのメジャーバージョンアップ後に、クライアント側（プロデューサー・コンシューマー）の `kafka-clients` ライブラリバージョンが古いと接続エラーや機能不具合が発生することがある。MSKはAPIの後方互換性を維持しているが、古いクライアントライブラリでは新しいブローカーのプロトコル機能に対応できない場合がある。

バージョンアップ前に、クライアントアプリケーションが使うKafkaクライアントライブラリのバージョンをAWSが公開している互換性情報で確認してからアップグレードすること。まず開発環境でバージョンアップをトライして動作確認してから本番に適用するのが安全だ。

【トラブル5】ブローカーのディスク使用率が急増する

トピックの保持期間設定（`log.retention.hours` や `log.retention.bytes`）が適切でない場合、メッセージが蓄積し続けてブローカーのEBSが逼迫する。CloudWatchの `KafkaDataLogsDiskUsed` を監視し、閾値（80%程度）でアラームを設定しておく。

急増した場合の対処としては、該当トピックの `retention.bytes` を一時的に小さくする、またはTiered Storageを有効化してS3に古いセグメントを移行する方法が有効だ。EBSの容量拡張（`modify-broker-storage`コマンド）も可能だが、数分間の作業時間がかかる。

本記事のまとめ

Amazon MSKは、オンプレでKafkaを運用してきたインフラエンジニアにとって、Kafkaエコシステムをそのまま活かしながら運用負荷を大きく削減できるマネージドサービスだ。

オンプレのKafkaからMSKへの移行は、APIレベルの互換性が高いため比較的スムーズに進めやすい。まず開発環境をMSK Serverlessで立ち上げ、既存アプリケーションの接続確認から始めると手戻りが少ない。本番移行の際は、コンシューマーグループのオフセットをどう引き継ぐかを事前に設計しておくのが重要なポイントだ。