こんにちは。
AWSでマネージドなKafkaを扱うとき、Amazon MSK(Managed Streaming for Apache Kafka)は選択肢の一つです。
この記事では、構築・運用の中で気づいた押さえておきたいポイントの一部を紹介します。
前提条件
本記事で触れている内容は、以下の構成を前提としています。
-
ブローカータイプ:標準ブローカー(kafka.m5.large など)
-
クラスタタイプ:プロビジョンドクラスタ
-
メタデータ管理:Apache Zookeeper モード
Serverlessや Express ブローカーなどはユースケースに応じて検討してください。また、あくまで参考資料となります。環境によって最適解は変わるため、必要に応じて検討してください。
可用性のベストプラクティス
Amazon MSK(Managed Streaming for Apache Kafka)で高可用性を実現する際の基本は レプリケーションファクタ(RF) とmin.insync.replicas(ISR)の設定です。
基本の考え方
MSKにおいても、複数 AZ へ跨がって配置するのがベストプラクティスとなります。
MSKはブローカーと呼ばれるノードの数やスペックを指定し、クラスターを作成します。
そのクラスター構築では、下記を設定するのが一般的です。
| 設定項目 | 推奨値 |
| レプリケーションファクタ(default.replication.factor) | AZ 数と同じ値(3AZ の場合は 3 |
| min.insync.replicas | RF – 1(3AZ の場合は 2) |
この設定により、以下のような障害パターンに対応できる構成になります。
- ブローカー単体のダウン(AZ 障害)
- メンテナンスによるローリングアップデート
- ネットワーク一時障害によるブローカー切断
デフォルト設定の活用
この設定はAmazon MSKのデフォルト設定を選択すると自動で適用されます。カスタム設定を利用する場合は、明示的に設定しましょう。
- MSK コンフィグ画面(例)
- 3AZに分散したクラスター上で作成したトピック詳細
Topic: MSKTutorialTopic TopicId: 8TdcHHTZRgaoF9JmsPS1yg PartitionCount: 1 ReplicationFactor: 3 Configs: min.insync.replicas=2,message.format.version=3.0-IV1,unclean.leader.election.enable=true
コスト面とサブネットへの注意
可用性を向上させるためには重要な設定ですが、下記も考慮しておく必要があります。
- ブローカー数が増えるほど MSK の利用料金も線形に上昇する
- ブローカー数が増えると、サブネットの空き IP アドレスを消費する
クライアント接続文字列には “全ブローカー” を含める
複数 AZ に跨ってクラスターを構築したら、それを正しく活かすために重要なのが クライアント側の接続設定です。
ベストプラクティスとしては、各 AZ のブローカーを最低1つ以上、bootstrap.servers に含めることを推奨します。全ブローカーを列挙しておくと、フェイルオーバーの信頼性が高まります。
bootstrap.servers=b-1.example:xxxx,b-2.example:xxxx,b-3.example:xxxx
この設定の利点:
- どれか 1 台のブローカーが停止しても、他のブローカーへ自動フェイルオーバーできる
- AZ 障害発生時でも、残存するブローカーに切り替えられる
接続先の取得方法
MSKを構築したら、AWS コンソールから接続先をコピーすることで、全ての AZ(ブローカー)を含めることができます。
- ブートストラップサーバー(接続先)の取得例
スケールアウト時に見落としやすい “AZ 数 × ブローカー数”
MSK では、ブローカーは AZ に均等配置される仕様になっています。 そのため、スケールアウトすると以下のように AZ 数の倍数で増えていきます。
| AZ 構成 | ブローカー数の遷移 |
| 3AZ | 3台 → 6台 → 9台 → … |
| 2AZ | 2台 → 4台 → 6台 → … |
スケールアウトによるブローカーの追加
「ちょっと性能上げたいから ブローカーを 1 台だけ増やそう」ということはできません。
「追加するブローカー数」を1に設定すると、利用している全てのAZに1つずつ追加されます。
「追加するブローカー数」を1に設定すると、利用している全てのAZに1つずつ追加されます。
- 図:ブローカー追加時の AZ ごとの挙動イメージ
この仕様が影響するポイントは次の通りです。
| 影響項目 | 詳細 |
| コスト上昇 | ブローカー数が想定以上に増えて、利用料金が大きく増大する |
| IP 枯渇 | サブネットの IP 消費量が AZ × ブローカー数で増えていき、デプロイ不可能に |
| パーティション再配置 | 増やしたブローカーに合わせてパーティション再配置が必要になる |
コスト例(東京リージョン、m5.xlarge):
| ブローカー数 | 月額コスト |
| 3台 | 1,189.17 USD |
| 6台 | 2,378.34 USD |
ポイント
“IP 枯渇” は後戻りが難しい部分なので、MSKで使用するサブネットを小さく切りすぎない設計が重要です。
ネットワークインターフェースの画面から、各ブローカーの状況を確認できます。(Apache ZooKeeperノードも含まれる)
ネットワークインターフェースの画面から、各ブローカーの状況を確認できます。(Apache ZooKeeperノードも含まれる)
- 図:ENI(ネットワークインターフェース)状況の例
ブローカーのスケールアウトとスケールアップ及びパーティション再配置については、別の機会に改めて触れる予定です。
MSK のモニタリングレベル
MSK では、クラスタの状態を監視するために モニタリングレベルが 4 種類用意されています。
どのレベルを選ぶかによって取得できるメトリクスの粒度やコストが変わるため、運用目的に応じて選択することが大切です。
MSK のモニタリングレベル 4 種類
| レベル | 特徴 | コスト |
| DEFAULT | クラスター・コンシューマー・プロデューサーの基本的な性能を把握できる | 無料 |
| PER_BROKER | ブローカー単位でより詳細なメトリクスを取得できる | 別途料金が必要 |
| PER_TOPIC_PER_BROKER | ブローカー及びトピック単位でのメトリクスを取得可能 | 別途料金が必要 |
| PER_TOPIC_PER_PARTITION | ブローカーごと、トピックごと、パーティションレベルで詳細なメトリクスを取得可能。 | 別途料金が必要 |
4つのレベルからモニタリングレベルを選択できますが、DEFAULT レベルでも運用に必要な主要指標はほぼ揃っています。
監視の方針次第ではありますが、利用料金に影響するため、まずは DEFAULT で要件を満たせているか確認することをおすすめします。
監視の方針次第ではありますが、利用料金に影響するため、まずは DEFAULT で要件を満たせているか確認することをおすすめします。
ブローカータイプは“性能”+“パーティション上限”で選ぶ
MSK のブローカータイプは単純に性能だけで選ぶのではなく、 ブローカーあたりのパーティション数の推奨値や、更新オペレーションをサポートするパーティション上限 も考慮する必要があります。
特に、大量のトピック(数百~数千)を作成する場合は、必ず考慮に入れましょう。
パーティション数の目安
MSKではブローカーサイズに応じて推奨のパーティション数が決まっています。詳しくは公式ドキュメントをご確認ください。
| ブローカーサイズ | 推奨パーティション数 |
| kafka.m5.large | 1000 |
| kafka.m5.2xlarge | 2000 |
大量のトピック(数百~数千)を作成する場合、ブローカーあたりのパーティション数が増えるため、高スペックのブローカーを選ぶ必要があることを忘れないようにしてください。
例えば、下記のようなクラスターを用意しトピックを作成したとします。
- MSKクラスターを 1 台用意
- 環境ごと(dev / stg / prd)に同じトピックを複製
トピック例(XXXは連番)
- SampleTopicXXX-dev
- SampleTopicXXX-stg
最終的にクラスターで 数百~千単位のトピックが生成され、これに伴ってブローカーのスペックが十分でないと CPU やメモリが不足する場合があります。
ブローカーサイズごとにパーティション上限が決まっている
インスタンスタイプの性能のみに着目していると、気づきにくいポイントですが、運用時に困ることになります。
上限を超過した場合、更新オペレーションができなくなる点に十分注意すべきです。
この点を考慮せずにリリースした場合、MSKクラスターに対する様々な更新ができないという状態になってしまいます。
パーティション上限
MSK には ブローカーごとのパーティション上限があり、トピック作成やパーティション追加、ブローカー設定変更などの更新オペレーションを安全に行うための制約です。
例:kafka.t3.small
- ブローカーあたり300パーティションが上限
- 上限を超えてクラスターの負荷が高い、パーティション追加やクラスター設定変更時に エラーが発生
例えば、パーティション数が1のトピックを300個超作成した場合を考えてみます。
このような状態で MSK クラスターの設定変更を実施しようとすると、下記のようなエラーが発生します。
The number of partitions per broker is above the recommended limit. Add more brokers and rearrange the partitions per broker to be below the recommended limit, then retry the request
このように、ブローカー当たりのパーティション数が上限を超えると、設定変更などのオペレーションができなくなります。
上限に余裕を持たせてパーティションを設計し、定期的にメトリクスを監視することが重要です。
スケールアウトに耐えるサブネット
MSK クラスターを作成する際、サブネット設計は意外と見落とされがちなポイントです。
スケールアウトのたびに IP を消費する
MSK のブローカーは EC2 と同じで、サブネットの IP を消費します。
スケールアウトを何度か行うと、IP が枯渇してデプロイできないケースがあります。
スケールアウトを何度か行うと、IP が枯渇してデプロイできないケースがあります。
ポイント
MSK クラスター作成後、サブネットを変更することはできません。
そのため、最初に十分な IP アドレスの余裕を持たせてサブネットを設計することが重要です。
そのため、最初に十分な IP アドレスの余裕を持たせてサブネットを設計することが重要です。
例えば、ブローカーを1つ追加した際、各 AZ に 1 つずつ追加されるため、ネットワークインターフェースの数が急増します。Apache ZooKeeperノードも含めて管理する必要があります。
データ移行
MSK はクラスター内に作成したトピック内にデータを保持する仕組みのため、別クラスターを作成した場合はデータを移行する手間が発生します。
設計時のコツ
サブネット設計時には 「将来的に別クラスターを作らずに済むための IP アドレス余裕」を確保することを推奨します。
またMSK Connect を使う場合、ワーカーが 自動的に同じサブネットにデプロイされます。
またMSK Connect を使う場合、ワーカーが 自動的に同じサブネットにデプロイされます。
- MSK Connector の構築画面(例)
- MSK Connect 構築時のENI
ワーカーもブローカーと同じサブネットにデプロイされるため、IP アドレスの消費が増加します。
MSK クラスター単体でも十分に IP を消費しますが、Connect を追加するとさらに圧迫される可能性があります。
ストレージ:増やせるけど減らせない
ブローカーのストレージは後から増やすことはできますが、減らすことはできません。
MSK の EBS ストレージは”スケールアップのみ”
現在設定されているストレージが初期値かつ最小値になっています。
コスト面も考慮し、初期設定は慎重に見積もりましょう。またMSK では retention 設定がない限り、無期限でデータを保存します。
無制限のままだと、いつの間にかディスクスペースがなくなっていた、という状況に陥ります。必ず適切な保持期間を設定しましょう。
無制限のままだと、いつの間にかディスクスペースがなくなっていた、という状況に陥ります。必ず適切な保持期間を設定しましょう。
IAM 認証で“運用しやすい”アクセス制御にする
MSK は IAM を使った認証(IAM Access Control)をサポートしており、AWS の IAM ポリシーと同じ考え方で権限管理ができるのが大きなメリットです。
トピック単位でのアクセス拒否など、細かい制御が可能
IAM 認証では、IAM ポリシーにより柔軟なアクセス権限を表現できます。
アクセス制御の例
- あるアプリには「特定トピックの読み取り・書き込みだけ許可」
- 別のアプリには「特定トピックへの読み取りだけ許可」
- 管理用ユーザーには「全トピック管理操作を許可」
IAMポリシー例
末尾が「-dev」のトピックへの操作のみを許可するポリシーです。
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"kafka-cluster:*Topic*",
"kafka-cluster:ReadData",
"kafka-cluster:WriteData"
],
"Resource": "arn:aws:kafka:*:123456789000:topic/*/*/*-dev"
}
「-dev」トピックへのproducer実行例(成功)
sh-5.2$ ./bin/kafka-console-producer.sh --bootstrap-server <bootstrap-server>--topic SampleTopic001-dev --producer.config ./config/client.properties >message1
「-stg」トピックへのproducer実行例(権限エラー)
sh-5.2$ ./bin/kafka-console-producer.sh --bootstrap-server <bootstrap-server>--topic SampleTopic001-stg --producer.config ./config/client.properties
>message1
[2025-11-28 09:15:09,879] WARN [Producer clientId=console-producer] Error while fetching metadata with correlation id 5215 : {SampleTopic001-stg=TOPIC_AUTHORIZATION_FAILED} (org.apache.kafka.clients.NetworkClient)
[2025-11-28 09:15:09,885] ERROR [Producer clientId=console-producer] Topic authorization failed for topics [SampleTopic001-stg] (org.apache.kafka.clients.Metadata)
[2025-11-28 09:15:09,887] ERROR Error when sending message to topic SampleTopic001-stg with key: null, value: 8 bytes with error: (org.apache.kafka.clients.producer.internals.ErrorLoggingCallback)
org.apache.kafka.common.errors.TopicAuthorizationException: Not authorized to access topics: [SampleTopic001-stg]
末尾が「-stg」のトピックへ操作する権限はないため、権限エラーが発生します。
このように、IAMポリシーを利用することで、トピックレベルでの権限制御も可能です。
Kafka バージョンアップは“短いサイクル”を前提に
Amazon MSK で利用する Kafka バージョンは、他のサービスと同様に常に一定の更新サイクルを意識しておく必要があります。
MSK のサポート終了
利用するバージョンにもよりますが、おおよそ 2 年ほどでサポートが終了します。 詳細はAWS公式ドキュメントをご確認ください。
サポート終了後も同バージョンを使い続けることはできず、AWS によって自動的にバージョンアップが行われます。そのため、サポート期限を把握し、事前にバージョンアップの影響を確認しておくことが重要です。
互換性の確認
Kafka のバージョンを上げると、プロデューサー/コンシューマーのクライアントにも影響します。
- ライブラリの互換性
- API の変更
- クライアントの再接続の挙動
- 新機能による設定パラメータの追加
これらは事前に検証しておきましょう。アプリ側のクライアントが古いバージョンのままで、MSK だけ先にアップグレードしてしまい、動作不具合が発生してしまう恐れがあります。
MSK のバージョンアップはローリング方式
MSK のメジャーアップデートはブローカー単位でローリング方式により実施されます。 クラスターを複数 AZ に配置しておけば、アップデート中も処理を継続できます。
クライアント側も、全てのブローカーを接続先に含めておくことで、切替時の影響を最小化できます。
bootstrap.servers=b-1.example:xxxx,b-2.example:xxxx,b-3.example:xxxx
まとめ
Amazon MSK は高可用性と優れた管理機能を備えたマネージドサービスですが、設計段階での決定が運用に大きく影響します。
本記事で紹介した内容は、Amazon MSK設計時に注意すべき項目の一部をまとめたものです。MSK のベストプラクティスはこれだけではなく、チーム規模やユースケースに応じて、さらに細かい調整が必要になる場合があります。あくまで参考資料として、自組織の要件に合わせて検討してください。
最後に、プロビジョンドクラスターは一時停止できません。ブローカータイプによっては利用料金が高額になる場合もあります。検証目的で構築し、不要になった場合は必ずクラスターを削除することを忘れないようにしましょう。
本記事が皆さんの MSK 構築・運用の一助となれば幸いです。











