翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon MSK の主な特徴および概念
Amazon MSK Provisioned のクラスターには、クラスターのパフォーマンスを最適化し、ストリーミングのニーズに対応する幅広い機能および能力が用意されています。以下のトピックでは、これらの機能について詳しく説明します。
+ [AWS マネジメントコンソール](https://console.aws.amazon.com/msk)
+ [Amazon MSK API リファレンス](https://docs.aws.amazon.com/msk/1.0/apireference)
+ [Amazon MSK CLI コマンドリファレンス](https://docs.aws.amazon.com/cli/latest/reference/kafka/index.html)
**Topics**
+ [Amazon MSK ブローカー タイプ](broker-instance-types.md)
+ [Amazon MSK のブローカーサイズ](broker-instance-sizes.md)
+ [標準ブローカーのストレージ管理](msk-storage-management.md)
+ [Amazon MSK Provisioned 設定](msk-configuration.md)
+ [クラスターのインテリジェントリバランシング](intelligent-rebalancing.md)
+ [MSK プロビジョンド クラスターへのパッチ適用](patching-impact.md)
+ [ブローカーのオフラインおよびクライアントフェイルオーバー](troubleshooting-offlinebroker-clientfailover.md)
+ [Amazon MSK のセキュリティ](security.md)
+ [Amazon MSK ログ記録](msk-logging.md)
+ [メタデータ管理](metadata-management.md)
+ [トピックオペレーション](msk-topic-operations-information.md)
+ [Amazon MSK リソース](resources.md)
+ [Apache Kafka バージョン](kafka-versions.md)
+ [Amazon MSK クラスターをトラブルシューティングする](troubleshooting.md)
# Amazon MSK ブローカー タイプ
MSK プロビジョニングには、標準 と Express の 2 つのブローカータイプがあります。標準 ブローカーではクラスターを最も柔軟に設定できる一方で、Express ブローカーは高性能ストリーミングアプリケーションを実行するための伸縮性、スループット、回復力、使いやすさが向上します。
各サービスの詳細については、以下のトピックを参照してください。次の表は、標準 ブローカーと Express ブローカーの主な機能の比較も示しています。
| 機能 | 標準 ブローカー | Express ブローカー |
| --- | --- | --- |
| [ストレージ管理](msk-storage-management.md) | 顧客管理型 (機能には EBS ストレージ、階層型ストレージ、プロビジョニング済みストレージスループット、オートスケーリング、ストレージ容量アラートが含まれます) | 完全な MSK 管理 |
| [サポートされているインスタンス](broker-instance-sizes.md) | T3, M5, M7g | M7g |
| [サイズとスケーリングに関する考慮事項](bestpractices-intro.md) | スループット、接続数、パーティション、ストレージ | スループット、接続数、パーティション |
| [ブローカーのスケーリング](msk-update-broker-count.md) | 垂直スケーリングと水平スケーリング | 垂直スケーリングと水平スケーリング |
| [Kafka バージョン](kafka-versions.md) | 「[Apache Kafka バージョン](kafka-versions.md)」を参照してください。 | バージョン 3.6 から開始 |
| [Apache Kafka の設定](msk-configuration.md) | より多くの設定が可能 | 主に MSK 管理による、高い復元力が実現された |
| [セキュリティ](security.md) | 暗号化、プライベート/パブリックアクセス、認証と認可 - IAM、SASL/SCRAM、mTLS、プレーンテキスト、Kafka ACLs | 暗号化、プライベート/パブリックアクセス、認証と認可 - IAM、SASL/SCRAM、mTLS、プレーンテキスト、Kafka ACLs |
| [モニタリング](monitoring.md) | CloudWatch、オープンモニタリング | CloudWatch、オープンモニタリング |
**注記**
MSK API を使用してブローカータイプを切り替えることで、 MSK プロビジョンド クラスター を標準 ブローカータイプから Express ブローカータイプに変更することはできません。目的のブローカータイプ (Standard または Express) で新しいクラスターを作成する必要があります。
**Topics**
+ [Amazon MSK 標準 ブローカー](msk-broker-types-standard.md)
+ [Amazon MSK Express ブローカー](msk-broker-types-express.md)
# Amazon MSK 標準 ブローカー
MSK プロビジョニングの標準 ブローカーは、 クラスター のパフォーマンスを最も柔軟に設定できます。アプリケーションに必要な可用性、耐久性、スループット、レイテンシ特性を実現するため、幅広いクラスター構成から選択できます。ストレージ容量をプロビジョニングし、必要に応じて増やすこともできます。Amazon MSK は、Standard ブローカーおよび接続されたストレージリソースのハードウェア保守を処理し、発生する可能性のあるハードウェアの問題を自動的に修復します。このドキュメントでは、[ストレージ管理](msk-storage-management.md)、[設定](msk-configuration-standard.md)、[メンテナンス](patching-impact.md#patching-standard-brokers)に関するトピックなど、スタンダードブローカーに関連するさまざまなトピックについて詳しく説明します。
# Amazon MSK Express ブローカー
MSK プロビジョニングの Express ブローカーを使用すると、Apache Kafka の管理が簡単になり、大規模に実行するためのコスト効率が向上し、予想される低レイテンシーで伸縮性が向上します。ブローカーには、自動的にスケールする pay-as-you-go のストレージが含まれており、サイジング、プロビジョニング、プロアクティブモニタリングは必要ありません。選択したインスタンスサイズに応じて、各ブローカーノードは標準の Apache Kafka ブローカーと比較して、ブローカーあたり最大 3 倍のスループットを提供し、最大 20 倍の速度でスケールアップし、 90% 速く回復します。Express ブローカーは Amazon MSK のベストプラクティスに基づくデフォルト設定で事前構成されており、クライアントのスループットクォータを強制適用することで、クライアント間および Kafka のバックグラウンド操作とのリソース競合を最小限に抑えます。
エクスプレスブローカーを利用する際の主な考慮事項と機能は以下の通りです。
+ **ストレージ管理なし**: Express ブローカーを使用すると、[ストレージリソースをプロビジョニングまたは管理する](msk-storage-management.md)必要がなくなります。弾力性があり、事実上無制限で、従量課金制、かつ完全に管理されたストレージを利用できます。高スループットのユースケースでは、コンピューティングインスタンスとストレージボリューム間の相互作用、および関連するスループットのボトルネックについて考慮する必要はありません。これらの機能によりクラスタ管理が簡素化され、ストレージ管理の運用オーバーヘッドが排除されます。
+ **高速なスケーリング**: Express ブローカーでは、クラスターのスケーリングとパーティションの移動を、Standard ブローカーに比べて最大 20 倍高速に行えます。この機能は、今後の負荷急増に対応するためにクラスターをスケールアウトする必要がある場合や、コスト削減のためにクラスターをスケールインする必要がある場合に極めて重要です。クラスターのスケーリングの詳細については、[ クラスターの拡張 ](msk-update-broker-count.md)、[ ブローカーの削除 ](msk-remove-broker.md)、[ パーティションの再割り当て](msk-update-broker-type.md)、[ 再調整のための LinkedIn の Cruise Control の設定 ](cruise-control.md)に関するセクションを参照してください。
+ **高いスループット**: Express ブローカーは、スタンダードブローカーと比較して、ブローカー1台あたり最大 3 倍のスループットを提供します。例えば、m7g.16xlarge サイズの Express ブローカー 1 台あたり最大 500 MBps で安全にデータを書き込みできます。これは同等の Standard ブローカーの 153.8 MBps と比較して高い性能です (両数値とも、レプリケーションやリバランスなどのバックグラウンド操作に十分な帯域幅が割り当てられていることを前提としています)。
+ **高いレジリエンスのために設定**: Express ブローカーは、クラスターの耐障害性を向上させるための様々なベストプラクティスを自動的に提供します。これには、重要な Apache Kafka 設定に対するガードレール、スループットクォータ、およびバックグラウンド操作や予期せぬ修復のためのキャパシティ予約が含まれます。これらの機能により、大規模な Apache Kafka アプリケーションを安全かつ容易に実行できるようになります。詳細については、[Express ブローカー設定](msk-configuration-express.md)および[Amazon MSK Express ブローカークォータ](limits.md#msk-express-quota)のセクションを参照してください。
+ **メンテナンスウィンドウ**なし: Express ブローカーのメンテナンスウィンドウはありません。Amazon MSK は、クラスターのハードウェアを継続的に自動的に更新します。詳細については、[Express ブローカーのパッチ適用](https://docs.aws.amazon.com/msk/latest/developerguide/patching-impact.html#patching-express-brokers) を参照してください。
## Express ブローカーに関する追加情報
+ Express ブローカーは Apache Kafka API を使用しますが、KStreams API はまだ完全にはサポートしていません。
+ Express ブローカーは 3AZs 設定でのみ使用できます。
+ Express ブローカーは、一部のインスタンスサイズでのみ使用できます。更新されたリストについては、[Amazon MSK の料金](https://aws.amazon.com/msk/pricing/) を参照してください。
+ Express ブローカーは、3.6、3.8、3.9 の Apache Kafka バージョンでサポートされています。
+ Express ブローカーは、Apache Kafka バージョン 3.9 以降から KRaft モードを使用して作成できます。
**これらのブログを見る**
MSK Express ブローカーの詳細と使用中の Express ブローカーの実際の例については、以下のブログを参照してください。
[Amazon MSK 用の Express ブローカーを導入して、Kafka クラスターに高スループットと高速スケーリングを実現](https://aws.amazon.com/blogs/aws/introducing-express-brokers-for-amazon-msk-to-deliver-high-throughput-and-faster-scaling-for-your-kafka-clusters/)
[Amazon MSK の Express ブローカー: 最大 20 倍の高速パフォーマンスで Turbo-charged Kafka スケーリング](https://aws.amazon.com/blogs/big-data/express-brokers-for-amazon-msk-turbo-charged-kafka-scaling-with-up-to-20-times-faster-performance/)
このブログでは、Express ブローカーがどのように機能するかを示します。
より高速なスループット、迅速なスケーリング、および障害からの復旧時間の改善を提供します
ストレージ管理の複雑さを解消する
# Amazon MSK のブローカーサイズ
Amazon MSK プロビジョニング クラスターを作成する際には、必要なブローカーのサイズを指定します。[ブローカータイプ](broker-instance-types.md)に応じて、Amazon MSK は以下のブローカーサイズをサポートしています。
**標準 ブローカーサイズ**
+ kafka.t3.small
+ kafka.m5.large、kafka.m5.xlarge、kafka.m5.2xlarge、kafka.m5.4xlarge、kafka.m5.8xlarge、kafka.m5.12xlarge、kafka.m5.16xlarge、kafka.m5.24xlarge
+ kafka.m7g.large、kafka.m7g.xlarge、kafka.m7g.2xlarge、kafka.m7g.4xlarge、kafka.m7g.8xlarge、kafka.m7g.12xlarge、kafka.m7g.16xlarge
**Express ブローカーのサイズ**
+ express.m7g.large、 express.m7g.xlarge、 express.m7g.2xlarge、 express.m7g.4xlarge、 express.m7g.8xlarge、 express.m7g.12xlarge、 express.m7g.16xlarge
**注記**
一部のブローカーサイズは、Certian AWS リージョンでは使用できない場合があります。地域別の利用可能なインスタンスの最新リストについては、[Amazon MSK 料金ページの](https://aws.amazon.com/msk/pricing/)更新されたブローカーインスタンス料金表を参照してください。
## ブローカーサイズに関する、その他の注意事項
+ M7g ブローカーは AWS Graviton プロセッサ (Amazon Web Services によって構築されたカスタム Arm ベースのプロセッサ) を使用します。M7g ブローカーでは、同等の M5 インスタンスと比較して、価格パフォーマンスが向上しています。M7g ブローカーでは、同等の M5 インスタンスよりも消費電力が少なくなります。
+ Amazon MSK は、2.8.2 および 3.3.2 以降の Kafka バージョンを実行する MSK プロビジョンド クラスターで M7g ブローカーをサポートしています。
+ M7g および M5 ブローカーは、T3 ブローカーよりも高いベースラインのスループットパフォーマンスを備えており、本稼働ワークロードに推奨されます。M7g および M5 ブローカーはまた、ブローカーあたり T3 ブローカーよりも多くのパーティションを持つことができます。より大きな本稼働グレードのワークロードを実行している場合、またはより多くのパーティションを必要とする場合は、M7g または M5 ブローカーを使用します。M7g および M5 インスタンスのサイズについての詳細は、「[Amazon EC2 汎用インスタンス](https://aws.amazon.com/ec2/instance-types/)」を参照してください。
+ T3 ブローカーには、CPU クレジットを使用して一時的にパフォーマンスをバーストする機能があります。小規模から中規模のストリーミングワークロードをテストする場合、またはスループットが一時的に急上昇する低スループットのストリーミングワークロードがある場合は、低コストの開発のために T3 ブローカーを使用します。T3 ブローカーが本稼働ワークロードまたは重要なワークロードに対して十分であるかどうかを判断するために、概念実証テストを実行することをお勧めします。T3 ブローカーのサイズについての詳細は、「[Amazon EC2 T3 インスタンス](https://aws.amazon.com/ec2/instance-types/t3/)」を参照してください。
ブローカーサイズの選択方法についての詳細は、「[標準ブローカーと Express ブローカーのベストプラクティス](bestpractices-intro.md)」を参照してください。
# 標準ブローカーのストレージ管理
Amazon MSK には、MSK クラスターのストレージ管理に役立つ機能が用意されています。
**注記**
[Express ブローカー](msk-broker-types-express.md)を使用すると、データに使用されるストレージリソースをプロビジョニングまたは管理する必要はありません。これにより、クラスター管理が簡素化され、Apache Kafka クラスターの運用上の問題の一般的な原因の一つが排除されます。同様に、アイドル状態のストレージ容量をプロビジョニングする必要はなく、使用した分に対してのみ料金が発生するため、支出も少なくなります。
**標準ブローカーのタイプ**
[標準ブローカー](msk-broker-types-standard.md)では、さまざまなストレージオプションと機能から選択できます。Amazon MSK には、MSK クラスターのストレージ管理に役立つ機能が用意されています。
スループット の管理に関する情報は、 [Amazon MSK クラスター 内の標準 ブローカー の ストレージ スループットを プロビジョニング する](msk-provision-throughput.md) を参照してください。
**Topics**
+ [標準ブローカーの階層型ストレージ](msk-tiered-storage.md)
+ [Amazon MSK 標準 ブローカー ストレージ をスケールアップする](msk-update-storage.md)
+ [Amazon MSK クラスター内の標準 ブローカー のストレージ スループットを管理する](msk-provision-throughput-management.md)
# 標準ブローカーの階層型ストレージ
階層型ストレージは Amazon MSK 用の低コストのストレージ階層で、実質的に無制限にストレージをスケーリングできるため、ストリーミングデータアプリケーションの構築を費用対効果の高い方法で行うことができます。
パフォーマンスとコストのバランスをとる階層型ストレージを使用して構成された Amazon MSK クラスターを作成できます。Amazon MSK は、Apache Kafka トピックの保持制限に達するまで、パフォーマンスが最適化されたプライマリストレージ階層にストリーミングデータを保存します。その後、Amazon MSK は新しい低コストのストレージ階層に自動的にデータを移動します。
アプリケーションが階層型ストレージからのデータの読み取りを開始すると、最初の数バイトは読み取りレイテンシーが大きくなることが予想されます。残りのデータを低コスト階層から順次読み取り始めると、プライマリストレージ階層と同様のレイテンシーになることが予想されます。低コストの階層型ストレージ用にストレージをプロビジョニングしたり、インフラストラクチャを管理したりする必要はありません。任意の量のデータを保存することができ、使用量に応じた料金のみが発生します。この機能は、[KIP-405: Kafka 階層型 ストレージ](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage)で導入された API と互換性があります。
MSK の階層型ストレージクラスターのサイズ設定、モニタリング、最適化の詳細については、「[Amazon MSK の階層型ストレージを使用して、本番ワークロードを実行するためのベストプラクティス](https://aws.amazon.com/blogs/big-data/best-practices-for-running-production-workloads-using-amazon-msk-tiered-storage/)」を参照してください。
階層型 ストレージ には、次のような特徴があります。
+ 実質的に無制限にストレージをスケーリングできます。Apache Kafka インフラストラクチャをスケーリングする方法を考える必要はありません。
+ ブローカーの数を増やすことなく、Apache Kafka トピックのデータをより長く保持したり、トピックのストレージを増やしたりできます。
+ これにより、安全バッファーが長くなり、処理中の予期しない遅延に対処できるようになります。
+ 既存のストリーム処理コードと Kafka API を使用して、古いデータを正確な生成順序で再処理できます。
+ セカンダリストレージのデータをブローカーディスク間でレプリケートする必要がないため、パーティションの再調整が高速化されます。
+ ブローカーと階層型ストレージ間のデータは VPC 内を移動し、インターネットを経由しません。
+ クライアントマシンは、階層型ストレージが有効になっていないクラスターに接続するのと同じプロセスを使用して、階層型ストレージが有効になっている新しいクラスターに接続することができます。「[クライアントマシンを作成する](https://docs.aws.amazon.com/msk/latest/developerguide/create-client-machine.html)」を参照してください。
## Amazon MSK クラスターの階層型ストレージの要件
+ 階層型ストレージを有効にして新しいトピックを作成するには、Apache Kafka クライアントのバージョン 3.0.0 以降を使用する必要があります。既存のトピックを階層型ストレージに移行するには、バージョン 3.0.0 より前の Kafka クライアント (サポートされている Apache Kafka の最小バージョンは 2.8.2.tiered) を使用するクライアントマシンを再構成して、階層型ストレージを有効にすることができます。「[ステップ 4: Amazon MSK クラスターにトピックを作成する](create-topic.md)」を参照してください。
+ 階層型ストレージが有効になっている Amazon MSK クラスターでは、バージョン 3.6.0 以降または 2.8.2.tiered を使用する必要があります。
## Amazon MSK クラスターの階層型ストレージの制約と制限
階層型ストレージには、次の制約と制限があります。
+ アプリケーションがトランザクション機能をアクティブに使用していない限り、Amazon MSK の remote\$1tier から読み取りを行う際にクライアントが `read_committed` に設定されていないことを確認してください。
+ 階層型ストレージは、 AWS GovCloud (米国) リージョンでは利用できません。
+ 階層型ストレージは、プロビジョンドモードのクラスターにのみ適用されます。
+ 階層型ストレージでは、ブローカーサイズ t3.small はサポートされていません。
+ 低コストストレージでの最小保持期間は 3 日間です。プライマリストレージには最小保持期間はありません。
+ 階層型ストレージは、ブローカーの複数のログディレクトリをサポートしていません (JBOD 関連機能)。
+ 階層型 ストレージ は、圧縮されたトピックをサポートしていません。階層型 ストレージ が有効になっている すべてのトピックで cleanup. Policy が 「DELETE」 のみに設定されていることを確認します。
+ 階層型ストレージクラスターは、トピックの作成後の log.cleanup.policy ポリシーの変更をサポートしていません。
+ 階層型 ストレージ は、個々の トピック では無効にできますが、クラスター 全体では 無効にできません。いったん無効にすると、トピックに対して階層型ストレージを再度有効にすることはできません。
+ Amazon MSK バージョン 2.8.2.tiered を使用している場合、別の階層ストレージがサポートされている Apache Kafka バージョンにのみ移行できます。階層ストレージがサポートされているバージョンをこれ以上使用したくない場合は、新しい MSK クラスターを作成し、データをそのクラスターに移行してください。
+ kafka-log-dirs ツールは、階層型ストレージのデータサイズを報告できません。このツールは、プライマリストレージ内のログセグメントのサイズのみを報告します。
トピックレベルに階層型ストレージを設定する際に注意すべきデフォルト設定および制約については、「[Amazon MSK 階層型ストレージのトピックレベル設定に関するガイドライン](msk-guidelines-tiered-storage-topic-level-config.md)」を参照してください。
# Amazon MSK トピックの階層型ストレージにログセグメントをコピーする方法
新規または既存のトピックに対して階層型ストレージを有効にすると、Apache Kafka はクローズ済みのログセグメントをプライマリストレージから階層型ストレージにコピーします。
+ Apache Kafka は、クローズ済みのログセグメントのみをコピーします。ログセグメント内のすべてのメッセージを階層型ストレージにコピーします。
+ アクティブセグメントは階層化の対象ではありません。ログセグメントサイズ (segment.bytes) またはセグメントロール時間 (segment.ms) によって、セグメントをクローズする速度と、その後 Apache Kafka がそれらを階層型ストレージにコピーする速度が制御されます。
階層型ストレージが有効になっているトピックの保持設定は、階層型ストレージが有効になっていないトピックの設定とは異なります。次のルールは、階層型ストレージが有効になっているトピックでのメッセージの保持を制御します。
+ Apache Kafka では、log.retention.ms (時間) と log.retention.bytes (サイズ) という 2 つの設定で保持を定義します。これらの設定によって、Apache Kafka がクラスターに保持するデータの合計期間とサイズが決まります。階層型ストレージモードを有効にするかどうかにかかわらず、これらの設定はクラスターレベルで設定します。トピックレベルの設定はトピック設定でオーバーライドできます。
+ 階層型ストレージを有効にすると、プライマリの高性能ストレージ階層にデータを保存する期間を追加で指定できます。例えば、トピックの全体保持期間 (log.retention.ms) が 7 日間、ローカル保持期間 (local.retention.ms) が 12 時間に設定されている場合、クラスターのプライマリストレージは最初の 12 時間のみデータを保持します。低コストのストレージ階層では、7 日間フルにデータを保持します。
+ 通常の保持設定はフルログに適用されます。これには階層型の部分とプライマリの部分が含まれます。
+ local.retention.ms 設定または local.retention.bytes 設定は、プライマリストレージでのメッセージの保持を制御します。Apache Kafka は、ローカルの保持設定とは無関係に、閉じたログセグメントを (segment.bytes または segment.ms に基づいて) 閉じたらすぐに階層型ストレージにコピーします。セグメントが階層型ストレージにコピーされると、セグメントは local.retention.ms または local.retention.bytes のしきい値に達するまでプライマリストレージに残ります。この時点で、データはプライマリストレージから削除されますが、階層型ストレージでは引き続き使用できます。これにより、古いデータが低コストの階層型ストレージから提供される間、最新のデータを高性能のプライマリストレージに保持して高速アクセスを実現できます。
+ Apache Kafka がログセグメント内のメッセージを階層型ストレージにコピーすると、retention.ms または retention.bytes の設定に基づいてクラスターからメッセージが削除されます。
## Amazon MSK における階層型ストレージのシナリオ例
このシナリオは、階層型ストレージが有効になっている場合に、プライマリストレージにメッセージを持つ既存のトピックがどのように動作するかを示しています。remote.storage.enable を `true` に設定すると、このトピックで階層型ストレージが有効になります。この例では、retention.ms は 5 日間に設定され、local.retention.ms は 2 日間に設定されています。セグメントの有効期限が切れたときの一連のイベントは次のとおりです。
**Time T0 - 階層型ストレージを有効にする前。**
このトピックに対して階層型ストレージを有効にする前に、2 つのログセグメントがあります。セグメントの 1 つは、既存のトピックパーティション 0 に対してアクティブです。
![\[Time T0 - 階層型ストレージを有効にする前。\]](http://docs.aws.amazon.com/ja_jp/msk/latest/developerguide/images/tiered-storage-segments-1.png)
**Time T1 (2 日未満) - 階層型ストレージが有効。セグメント 0 が階層型ストレージにコピーされます。**
このトピックの階層型ストレージを有効にすると、Apache Kafka は閉じたログセグメント 0 を、閉じた直後に階層型ストレージにコピーします。セグメントは、保持設定ではなく segment.bytes または segment.ms 設定に基づいて閉じます。Apache Kafka はプライマリストレージにもコピーを保持します。アクティブなセグメント 1 は、まだアクティブで閉じていないため、階層型ストレージにコピーできません。このタイムラインではまだ、Amazon MSK によりセグメント 0 とセグメント 1 のメッセージに保持設定が適用されていません (local.retention.bytes/ms, retention.ms/bytes)。
![\[Time T1 (2 日未満) - 階層型ストレージが有効。セグメント 0 が階層型ストレージにコピーされます。\]](http://docs.aws.amazon.com/ja_jp/msk/latest/developerguide/images/tiered-storage-segments-2.png)
**Time T2 - ローカル保持が有効。**
2 日後、セグメント 0 のローカル保持しきい値に達します。local.retention.ms を 2 日間に設定することでこれを決定します。セグメント 0 はプライマリストレージから削除されるようになりましたが、階層型ストレージで引き続き使用できます。セグメント 0 は、ローカル保持の有効期限が切れた時刻 T2 ではなく、閉じた時刻 T1 にすでに階層型ストレージにコピーされていることに注意してください。 T2 アクティブなセグメント 1 は、まだアクティブなため、削除することも階層型ストレージにコピーすることもできません。
![\[Time T2 - ローカル保持が有効。\]](http://docs.aws.amazon.com/ja_jp/msk/latest/developerguide/images/tiered-storage-segments-3.png)
**Time T3 - 全体保持が有効。**
5 日後、保持設定が有効になり、Kafka はログセグメント 0 と関連メッセージを階層型ストレージから消去します。セグメント 1 はアクティブであるため、まだ有効期限の対象ではなく、階層型ストレージへのコピー対象でもありません。セグメント 1 はまだクローズされていないため、セグメントロールの対象ではありません。
![\[Time T3 - 全体保持が有効。\]](http://docs.aws.amazon.com/ja_jp/msk/latest/developerguide/images/tiered-storage-segments-4.png)
# で階層型ストレージを使用して Amazon MSK クラスターを作成する AWS マネジメントコンソール
このプロセスでは、 AWS マネジメントコンソールを使用して階層型ストレージの Amazon MSK クラスターを作成する方法について説明します。
1. [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/) で Amazon MSK コンソールを開きます。
1. **Create cluster** (クラスターの作成) を選択します。
1. 階層型 ストレージに対して **カスタム作成** を選択します。
1. クラスターの名前を指定します。
1. **[クラスタータイプ]** で **[プロビジョンド]** を選択します。
1. クラスターを作成するために使用する Amazon MSK の階層型ストレージをサポートする Amazon Kafka のバージョンを選択します。
1. **kafka.t3.small** 以外のサイズのブローカーを指定します。
1. Amazon MSK で各アベイラビリティーゾーンに作成するブローカーの数を選択します。ブローカーの最小数は各アベイラビリティーゾーンにつき 1 つで、最大数は各クラスターにつき 30 です。
1. ブローカーを分散させるゾーンの数を指定します。
1. ゾーンごとにデプロイされる Apache Kafka ブローカーの数を指定します。
1. **[ストレージオプション]** を選択します。これには、階層型ストレージモードを有効にするための **[階層化ストレージ と EBS ストレージ]** が含まれます。
1. クラスター作成ウィザードの残りのステップを実行します。完了すると、**[確認と作成]** ビューに、クラスターストレージモードとして **[階層化ストレージ と EBS ストレージ]** が表示されます。
1. [**Create cluster (クラスターの作成)**] を選択します。
# で階層型ストレージを使用して Amazon MSK クラスターを作成する AWS CLI
クラスターで階層型ストレージを有効にするには、階層型ストレージに適切な Apache Kafka バージョンと属性を使用してクラスターを作成します。以下のコード例に従います。また、次のセクションの「[で階層型ストレージを有効にした Kafka トピックを作成する AWS CLI](#msk-create-topic-tiered-storage-cli)」のステップを実行します。
クラスターの作成でサポートされる属性の完全なリストについては、「[create-cluster](https://docs.aws.amazon.com//cli/latest/reference/kafka/create-cluster.html)」を参照してください。
```
aws kafka create-cluster \
—cluster-name "MessagingCluster" \
—broker-node-group-info file://brokernodegroupinfo.json \
—number-of-broker-nodes 3 \
--kafka-version "3.6.0" \
--storage-mode "TIERED"
```
## で階層型ストレージを有効にした Kafka トピックを作成する AWS CLI
階層型ストレージを有効にしてクラスターを作成したときに開始したプロセスを完了するには、後述のコード例に示された属性を指定して階層型ストレージを有効にしたトピックも作成します。階層型ストレージ特有の属性には、次のものがあります。
+ 時間ベースの保持設定に使用する `local.retention.ms` (10 分間など)、またはログセグメントのサイズ制限に使用する `local.retention.bytes`。
+ 階層型ストレージが有効にするには、`remote.storage.enable` を `true` に設定します。
以下の設定では local.retention.ms を使用していますが、この属性を local.retention.bytes に置き換えることもできます。この属性は、Apache Kafka がデータをプライマリストレージから階層型ストレージにコピーするまでに、待機できる時間またはコピーできるバイト数を制御します。サポートされている設定属性の詳細については、「[トピックレベルの設定](https://docs.aws.amazon.com//msk/latest/developerguide/msk-configuration-properties.html#msk-topic-confinguration)」を参照してください。
**注記**
Apache Kafka クライアントのバージョン 3.0.0 以降を使用する必要があります。これらのバージョンでは、`remote.storage.enable` という設定をサポートします。これは、当該クライアントバージョンの `kafka-topics.sh` にのみ含まれます。以前のバージョンの Apache Kafka を使用する既存のトピックで階層型ストレージを有効にするには、「[既存の Amazon MSK トピックでの階層型ストレージの有効化](msk-enable-disable-topic-tiered-storage-cli.md#msk-enable-topic-tiered-storage-cli)」セクションを参照してください。
```
bin/kafka-topics.sh --create --bootstrap-server $bs --replication-factor 2 --partitions 6 --topic MSKTutorialTopic --config remote.storage.enable=true --config local.retention.ms=100000 --config retention.ms=604800000 --config segment.bytes=134217728
```
# 既存の Amazon MSK トピックで階層型ストレージを有効または無効にする
これらのセクションでは、作成済みのトピックで階層型ストレージを有効または無効にする方法について説明します。階層型ストレージを有効にした新しいクラスターとトピックを作成するには、「[AWS マネジメントコンソールを使用して階層型ストレージを持つ Amazon MSK クラスターを作成する](https://docs.aws.amazon.com//msk/latest/developerguide/msk-create-cluster-tiered-storage-console)」を参照してください。
## 既存の Amazon MSK トピックでの階層型ストレージの有効化
既存のトピックで階層型ストレージを有効にするには、次の例に示す `alter` コマンド構文を使用します。既存のトピックで階層型ストレージを有効にする場合は、特定の Apache Kafka クライアントバージョンに制限されません。
```
bin/kafka-configs.sh --bootstrap-server $bsrv --alter --entity-type topics --entity-name msk-ts-topic --add-config 'remote.storage.enable=true, local.retention.ms=604800000, retention.ms=15550000000'
```
## 既存の Amazon MSK トピックの階層型ストレージを無効にする
既存のトピックで階層型ストレージを無効にするには、階層型ストレージを有効にするときと同じ順序で `alter` コマンド構文を使用します。
```
bin/kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-name MSKTutorialTopic --add-config 'remote.log.msk.disable.policy=Delete, remote.storage.enable=false'
```
**注記**
階層型ストレージを無効にすると、階層型ストレージのトピックデータは完全に削除されます。Apache Kafka はプライマリストレージデータを保持しますが、これには、`local.retention.ms` に基づくプライマリ保持ルールが引き続き適用されます。トピックで階層化ストレージを無効にすると、再度有効にすることはできません。既存のトピックで階層型ストレージを無効にする場合は、特定の Apache Kafka クライアントバージョンに制限されません。
# AWS CLI を使用して既存の Amazon MSK クラスターで階層型ストレージを有効にする
**注記**
圧縮トピックは階層型ストレージではサポートされないため、クラスターの log.cleanup.policy が `delete` に設定されている場合にのみ階層型ストレージを有効にできます。後で、個々のトピックの log.cleanup.policy を `compact` に設定できます (その特定のトピックで階層型ストレージが有効になっていない場合)。サポートされている設定属性の詳細については、「[トピックレベルの設定](https://docs.aws.amazon.com//msk/latest/developerguide/msk-configuration-properties.html#msk-topic-confinguration)」を参照してください。
1. **Kafka バージョンの更新** — クラスターバージョンは単純な整数ではありません。クラスターの最新バージョンを検索するには、 `DescribeCluster`オペレーションまたは `describe-cluster` AWS CLI コマンドを使用します。サンプルのバージョンは `KTVPDKIKX0DER` です。
```
aws kafka update-cluster-kafka-version --cluster-arn ClusterArn --current-version Current-Cluster-Version --target-kafka-version 3.6.0
```
1. クラスターストレージモードを編集します。次のコード例は、[https://docs.aws.amazon.com/cli/latest/reference/kafka/update-storage.html](https://docs.aws.amazon.com/cli/latest/reference/kafka/update-storage.html) API を使用してクラスターストレージモードを `TIERED` に編集する方法を示しています。
```
aws kafka update-storage --current-version Current-Cluster-Version --cluster-arn Cluster-arn --storage-mode TIERED
```
# コンソールを使用して既存の Amazon MSK クラスターの階層型ストレージを更新する
このプロセスでは、 AWS マネジメントコンソールを使用して階層型ストレージの Amazon MSK クラスターを更新する方法について説明します。
MSK クラスターの現在の Apache Kafka バージョンが 2.8.2.tiered であることを確認します。MSK クラスターを 2.8.2.tiered バージョンにアップグレードする必要がある場合は、「[Apache Kafka バージョンの更新](https://docs.aws.amazon.com/msk/latest/developerguide/version-upgrades.html)」を参照してください。
**注記**
圧縮トピックは階層型ストレージではサポートされないため、クラスターの log.cleanup.policy が `delete` に設定されている場合にのみ階層型ストレージを有効にできます。後で、個々のトピックの log.cleanup.policy を `compact` に設定できます (その特定のトピックで階層型ストレージが有効になっていない場合)。サポートされている設定属性の詳細については、「[トピックレベルの設定](https://docs.aws.amazon.com//msk/latest/developerguide/msk-configuration-properties.html#msk-topic-confinguration)」を参照してください。
1. [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/) で Amazon MSK コンソールを開きます。
1. クラスター の概要ページに移動し、[**プロパティ**] を選択します。
1. [**ストレージ**] セクション に移動し、 [**クラスター ストレージ モードを編集**] を選択します。
1. [**階層化 ストレージ と EBS ストレージ**] を選択し、[**変更を保存**] を選択します。
# Amazon MSK 標準 ブローカー ストレージ をスケールアップする
ブローカーごとに EBS ストレージの量を増やすことができます。ストレージを減らすことはできません。
ストレージボリュームは、このスケールアップオペレーション中も引き続き使用できます。
**重要**
MSK クラスター用にストレージをスケーリングすると、追加のストレージがすぐに使用できるようになります。ただし、ストレージのスケーリングイベントが発生するたびに、クラスターにはクールダウン期間が必要です。Amazon MSK は、このクールダウン期間を利用してクラスターを最適化します。その後、クラスターは再びスケーリングできるようになります。この期間は、クラスターのストレージサイズ、使用率、トラフィックに応じて、最小 6 時間から 24 時間以上までさまざまです。これは、自動スケーリングイベントと、[UpdateBrokerStorage](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-nodes-storage.html#UpdateBrokerStorage) オペレーションを使用した手動スケーリングの両方に適用されます。ストレージの適切なサイジングについては、「[標準 ブローカーのベストプラクティス](bestpractices.md)」を参照してください。
階層型ストレージを使用すると、ブローカーのストレージ容量を無制限にスケールアップできます。「[標準ブローカーの階層型ストレージ](msk-tiered-storage.md)」を参照してください。
**Topics**
+ [Amazon MSK クラスターの自動スケーリング](msk-autoexpand.md)
+ [標準ブローカーの手動スケーリング](manually-expand-storage.md)
# Amazon MSK クラスターの自動スケーリング
使用量の増加に応じてクラスターのストレージを自動的に拡張するには、Amazon MSK のアプリケーション自動スケーリングを設定できます。自動スケーリングポリシーでは、ディスク使用率のターゲットと最大スケーリング容量を設定します。
Amazon MSK の自動スケーリングを使用する前に、次の点を考慮する必要があります。
+
**重要**
ストレージスケーリングアクションは、6 時間ごとに 1 回だけ実行できます。
まず、ストレージ需要に適したサイズのストレージボリュームから始めることが推奨されます。クラスターの適切なサイズ設定のガイダンスについては、「[クラスターの適正サイズ設定: クラスターあたりの標準ブローカー数](bestpractices.md#brokers-per-cluster)」を参照してください。
+ Amazon MSK では、使用量の減少に応じたクラスターストレージの削減は行われません。Amazon MSK では、ストレージボリュームのサイズを減らすことはできません。クラスターストレージの容量を減らす必要がある場合は、既存のクラスターを小さいストレージのクラスターに移行してください。クラスターの移行については、「[MSK クラスターへの移行](migration.md)」を参照してください。
+ Amazon MSK は、アジア太平洋地域 (大阪) 、アフリカ (ケープタウン) およびアジア太平洋地域 (マレーシア) での自動スケーリングのサポートはしていません。
+ 自動スケーリングポリシーをクラスターに関連付けると、Amazon EC2 Auto Scaling はターゲット追跡用の Amazon CloudWatch アラームを自動的に作成します。自動スケーリングポリシーのあるクラスターを削除しても、この CloudWatch アラームは保持されます。CloudWatch アラームを削除するには、クラスターを削除する前に、クラスターから自動スケーリングポリシーを削除する必要があります。ターゲット追跡の詳細については、「Amazon EC2 Auto Scaling ユーザーガイド」の「[Amazon EC2 Auto Scaling のターゲットトラッキングスケーリングポリシー](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html)」を参照してください。
**Topics**
+ [Amazon MSK の自動スケーリングポリシーの詳細](msk-autoexpand-details.md)
+ [Amazon MSK クラスターの自動スケーリングを設定する](msk-autoexpand-setup.md)
# Amazon MSK の自動スケーリングポリシーの詳細
自動スケーリングポリシーでは、クラスターに関する次のパラメータを定義します。
+ **ストレージ使用率ターゲット** : Amazon MSK がオートスケーリングオペレーションをトリガーするために参照するストレージ使用率のしきい値。使用率のターゲットは、現在のストレージ容量の 10% ～ 80% に設定できます。ストレージ使用率ターゲットの設定の推奨値は 50% から 60% です。
+ **最大ストレージ容量**: Amazon MSK でブローカーストレージに対して設定できるスケーリングの上限。最大ストレージ容量は、各ブローカーにつき最大 16 TiB に設定できます。詳細については、「[Amazon MSK クォータ](limits.md)」を参照してください。
Amazon MSK は、`Maximum Disk Utilization` メトリクスが `Storage Utilization Target` 設定以上であることを検出すると、10 GiB または現在のストレージの 10% の 2 つの数値のうち大きい方と同量だけストレージ容量を増やします。例えば、現在の容量が 1000 GiB の場合、その量は 100 GiB となります。このサービスは、ストレージ使用率を 1 分ごとにチェックします。さらにスケーリングオペレーションが行われるたびに、10 GiB または現在のストレージの 10% の 2 つの数値のうち大きい方と同量だけストレージが増えていきます。
自動スケーリングオペレーションが発生したかを判別するには、[ListClusterOperations](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-operations.html#ListClusterOperations) オペレーションを使用します。
# Amazon MSK クラスターの自動スケーリングを設定する
Amazon MSK コンソール、Amazon MSK API、または を使用して CloudFormation 、ストレージの自動スケーリングを実装できます。CloudFormation のサポートは、[Application Auto Scaling](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-applicationautoscaling-scalabletarget.html) を通じて利用できます。
**注記**
クラスターの作成時に自動スケーリングを実装することはできません。最初にクラスターを作成してから、そのクラスターに対して自動スケーリングポリシーを作成して有効にする必要があります。ただし、Amazon MSK サービスによるクラスターの作成時に、ポリシーを作成することはできます。
**Topics**
+ [Amazon MSK を使用して自動スケーリングを設定する AWS マネジメントコンソール](msk-autoexpand-setup-console.md)
+ [CLI を使用して自動スケーリングの設定をする](msk-autoexpand-setup-cli.md)
+ [API を使用して Amazon MSK の自動スケーリングを設定する](msk-autoexpand-setup-api.md)
# Amazon MSK を使用して自動スケーリングを設定する AWS マネジメントコンソール
このプロセスでは、ストレージの自動スケーリングを実装するための、Amazon MSK コンソールの使用方法について説明します。
1. にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/msk/home?region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/) で Amazon MSK コンソールを開きます。
1. クラスターリストから、 お客様のクラスターを選択します。これにより、クラスターの詳細がリストされたページに移動します。
1. **[Auto scaling for storage]** (ストレージのオートスケーリング) セクションで、**[Configure]** (設定) を選択します。
1. オートスケーリングポリシーを作成して名前を付けます。ストレージ使用率のターゲット、最大ストレージ容量、およびターゲットメトリクスを指定します。
1. `Save changes` を選択してください。
新しいポリシーを保存して有効にすると、ポリシーがクラスターに対してアクティブになります。Amazon MSK は、ストレージ使用率が設定した値に達すると、クラスターのストレージを拡張します。
# CLI を使用して自動スケーリングの設定をする
このプロセスでは、ストレージの自動スケーリングを実装するための、Amazon MSK CLI の使用方法について説明します。
1. [[RegisterScalableTarget]](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/#available-commands) コマンドを使用して、ストレージ使用率ターゲットを登録します。
1. [[PutScalingPolicy]](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/#available-commands) コマンドを使用して、自動拡張ポリシーを作成します。
# API を使用して Amazon MSK の自動スケーリングを設定する
このプロセスでは、ストレージの自動スケーリングを実装するために、Amazon MSK API の使用方法について説明します。
1. [[RegisterScalableTarget]](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_RegisterScalableTarget.html) API を使用して、ストレージ使用率ターゲットを登録する。
1. [PutScalingPolicy](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_PutScalingPolicy.html) API を使用して、自動拡張ポリシーを作成する。
# 標準ブローカーの手動スケーリング
ストレージを増やすには、クラスターが `ACTIVE` 状態になるのを待ちます。ストレージのスケーリングのクールダウン期間は、各イベント間で最低で 6 時間です。このオペレーションによって追加のストレージがすぐに使用可能になりますが、クラスターで最適化を実行するため、この操作に最大 24 時間以上かかることがあります。これらの最適化の所要時間は、ストレージの容量に比例します。
## を使用したブローカーストレージのスケールアップ AWS マネジメントコンソール
1. [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/) で Amazon MSK コンソールを開きます。
1. ブローカーストレージをアップデートしたい MSK クラスターを選択します。
1. [**Storage**] (ストレージ) セクションで、[**Edit**] (編集) を選択します。
1. 必要なストレージボリュームを指定します。ストレージの量を増やすだけで、減らすことはできません。
1. **[Save changes]** (変更の保存) をクリックします。
## を使用したブローカーストレージのスケールアップ AWS CLI
*ClusterArn*をクラスターの作成時に取得したAmazon リソースネーム (ARN) に置き換えて、次のコマンドを実行します。クラスターの ARN がない場合は、すべてのクラスターを一覧表示することで見つけられます。詳細については、「[Amazon MSK クラスターを一覧表示する](msk-list-clusters.md)」を参照してください。
*Current-Cluster-Version* を、クラスターの現在のバージョンに置き換えます。
**重要**
クラスターのバージョンは単純な整数ではありません。クラスターの最新バージョンを検索するには、[DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster) オペレーションまたは [describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html) AWS CLI コマンドを使用します。サンプルのバージョンは `KTVPDKIKX0DER` です。
*Target-Volume-in GiB* パラメータは、各ブローカーが持つストレージの量を表します。すべてのブローカーのストレージのみ、更新できます。ストレージを更新するブローカーを個別に指定することはできません。*Target-Volume-in-GiB* に指定する値は、100 GiB を超える整数である必要があります。更新操作後のブローカーごとのストレージは 16384 GiB を超えることはできません。
```
aws kafka update-broker-storage --cluster-arn ClusterArn --current-version Current-Cluster-Version --target-broker-ebs-volume-info '{"KafkaBrokerNodeId": "All", "VolumeSizeGB": Target-Volume-in-GiB}'
```
## API を使用したブローカーストレージのスケールアップ
API を使用してブローカーストレージを更新するには、「[UpdateBrokerStorage](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn-nodes-storage.html#UpdateBrokerStorage)」を参照してください。
# Amazon MSK クラスター内の標準 ブローカー のストレージ スループットを管理する
Amazon MSK コンソール、CLI、および API を使用して、スループットをプロビジョニングする方法については、「[Amazon MSK クラスター 内の標準 ブローカー の ストレージ スループットを プロビジョニング する](msk-provision-throughput.md)」を参照してください。
**Topics**
+ [Amazon MSK ブローカースループットのボトルネックと最大スループット設定](#throughput-bottlenecks)
+ [Amazon MSK クラスターのストレージスループットを測定する](#throughput-metrics)
+ [Amazon MSK クラスター内のプロビジョンドストレージの設定更新値](#provisioned-throughput-config)
+ [Amazon MSK クラスター 内の標準 ブローカー の ストレージ スループットを プロビジョニング する](msk-provision-throughput.md)
## Amazon MSK ブローカースループットのボトルネックと最大スループット設定
ブローカースループットのボトルネックには、ボリュームスループット、Amazon EC2 から Amazon EBS へのネットワークスループット、Amazon EC2 のエグレススループットなど、複数の原因があります。プロビジョンドストレージのスループットを有効にして、ボリュームスループットを調整できます。ただし、ブローカースループットの制限は、Amazon EC2 から Amazon EBS へのネットワークスループットと Amazon EC2 のエグレススループットによって発生する可能性があります。
Amazon EC2 のエグレススループットは、コンシューマーグループの数と、コンシューマーグループあたりのコンシューマーの数の影響を受けます。また、Amazon EC2 から Amazon EBS へのネットワークスループットと Amazon EC2 のエグレススループットはどちらも、ブローカーサイズが大きいほど高くなります。
ボリュームサイズが 10 GiB 以上の場合は、250 MiB/秒以上のストレージスループットをプロビジョニングできます。デフォルトは 250 MiB/秒です。ストレージスループットをプロビジョニングするには、ブローカーサイズ kkafka.m5.4xlarge 以上 (または kafka.m7g.2xlarge 以上) を選択する必要があります。また、次の表に示すように最大スループットを指定できます。
****
| ブローカーサイズ | ストレージの最大スループット (MiB/秒) |
| --- | --- |
| kafka.m5.4xlarge | 593 |
| kafka.m5.8xlarge | 850 |
| kafka.m5.12xlarge | 1,000 |
| kafka.m5.16xlarge | 1,000 |
| kafka.m5.24xlarge | 1,000 |
| kafka.m7g.2xlarge | 312.5 |
| kafka.m7g.4xlarge | 625 |
| kafka.m7g.8xlarge | 1,000 |
| kafka.m7g.12xlarge | 1,000 |
| kafka.m7g.16xlarge | 1,000 |
## Amazon MSK クラスターのストレージスループットを測定する
`VolumeReadBytes` および `VolumeWriteBytes` メトリクスを使用して、クラスターの平均ストレージスループットを測定できます。これら 2 つのメトリクスを合計は、ストレージの平均スループット (バイト単位) を示します。クラスターのストレージの平均スループットを取得するには、これら 2 つのメトリクスを SUM に、期間を 1 分に設定し、次の式を使用します。
```
Average storage throughput in MiB/s = (Sum(VolumeReadBytes) + Sum(VolumeWriteBytes)) / (60 * 1024 * 1024)
```
`VolumeReadBytes` および `VolumeWriteBytes` メトリクスについては、「[`PER_BROKER` レベルモニタリング](metrics-details.md#broker-metrics)」を参照してください。
## Amazon MSK クラスター内のプロビジョンドストレージの設定更新値
Amazon MSK 設定は、プロビジョンドスループットを有効にする前でも後でも更新できます。ただし、`num.replica.fetchers` 設定パラメータの更新と、プロビジョンドスループットの有効化の両方のアクションを実行するまでは、目的のスループットは表示されません。
Amazon MSK のデフォルト設定では、`num.replica.fetchers` の値は 2 です。`num.replica.fetchers` を更新する際には、次の表の推奨値を使用できます。これらの値は参考用です。これらの値は、ユースケースに基づいて調整することが推奨されます。
****
| ブローカーサイズ | num.replica.fetchers |
| --- | --- |
| kafka.m5.4xlarge | 4 |
| kafka.m5.8xlarge | 8 |
| kafka.m5.12xlarge | 14 |
| kafka.m5.16xlarge | 16 |
| kafka.m5.24xlarge | 16 |
更新した設定は最大 24 時間有効にならない場合があり、ソースボリュームが十分に利用されていない場合はさらに時間がかかる場合があります。ただし、移行ボリュームのパフォーマンスは、移行期間中は少なくともソースストレージボリュームのパフォーマンスと同等です。フルに利用されている 1 TiB ボリュームの場合、更新された設定に移行するには、通常は約 6 時間かかります。
# Amazon MSK クラスター 内の標準 ブローカー の ストレージ スループットを プロビジョニング する
Amazon MSK ブローカーは、データをストレージボリュームに保持します。ストレージ I/O は、プロデューサーがクラスターに書き込むとき、ブローカー間でデータがレプリケートされるとき、およびコンシューマーがメモリ内にないデータを読み取るときに消費されます。ボリュームストレージのスループットは、ストレージボリュームにデータを書き込んだり、ストレージボリュームからデータを読み取ったりできる速度です。プロビジョンドストレージのスループットは、クラスター内のブローカーに対してその速度を指定する機能です。
ブローカーのサイズが `kafka.m5.4xlarge` 以上で、ストレージボリュームが 10 GiB 以上のクラスターに対して、プロビジョンドスループットの速度 (MiB/秒) を指定できます。プロビジョンドスループットは、クラスター作成時に指定できます。また、`ACTIVE` 状態のクラスターのプロビジョンドスループットを有効または無効にすることもできます。
スループット の管理に関する情報は、 [Amazon MSK クラスター内の標準 ブローカー のストレージ スループットを管理する](msk-provision-throughput-management.md) を参照してください。
**Topics**
+ [を使用して Amazon MSK クラスターストレージスループットをプロビジョニングする AWS マネジメントコンソール](#provisioned-throughput-console)
+ [を使用して Amazon MSK クラスターストレージスループットをプロビジョニングする AWS CLI](#provisioned-throughput-cli)
+ [API を使用して Amazon MSK クラスターを作成する際にストレージスループットをプロビジョニングする](#provisioned-throughput-api)
## を使用して Amazon MSK クラスターストレージスループットをプロビジョニングする AWS マネジメントコンソール
このプロセスでは、 を使用して、プロビジョニングされたスループットを有効にした Amazon MSK クラスター AWS マネジメントコンソール を作成する方法の例を示します。
1. にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/msk/home?region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/) で Amazon MSK コンソールを開きます。
1. **Create cluster** (クラスターの作成) を選択します。
1. **Custom create** (カスタム作成) を選択します。
1. クラスターの名前を指定します。
1. **[ストレージ]** セクションで、**[有効化]** を選択します。
1. ブローカーあたりのストレージスループットの値を選択します。
1. VPC、ゾーンとサブネット、セキュリティグループを選択します。
1. [**次へ**] を選択します。
1. [**セキュリティ**] ステップ の一番下で [**次へ**] を選択します。
1. **[モニタリングおよびタグ]** ステップの一番下で **[次へ]** を選択します。
1. クラスター設定を確認し、**[クラスターの作成]** を選択します。
## を使用して Amazon MSK クラスターストレージスループットをプロビジョニングする AWS CLI
このプロセスでは、 を使用して、プロビジョニングされたスループットを有効にしたクラスター AWS CLI を作成する方法の例を示します。
1. 次の JSON をコピーして、ファイルに貼り付けます。サブネット ID とセキュリティグループ ID のプレースホルダーは、自分のアカウントの値に置き換えてください。ファイルに `cluster-creation.json` という名前を付け、保存します。
```
{
"Provisioned": {
"BrokerNodeGroupInfo":{
"InstanceType":"kafka.m5.4xlarge",
"ClientSubnets":[
"Subnet-1-ID",
"Subnet-2-ID"
],
"SecurityGroups":[
"Security-Group-ID"
],
"StorageInfo": {
"EbsStorageInfo": {
"VolumeSize": 10,
"ProvisionedThroughput": {
"Enabled": true,
"VolumeThroughput": 250
}
}
}
},
"EncryptionInfo": {
"EncryptionInTransit": {
"InCluster": false,
"ClientBroker": "PLAINTEXT"
}
},
"KafkaVersion":"2.8.1",
"NumberOfBrokerNodes": 2
},
"ClusterName": "provisioned-throughput-example"
}
```
1. 前のステップで JSON ファイルを保存したディレクトリから次の AWS CLI コマンドを実行します。
```
aws kafka create-cluster-v2 --cli-input-json file://cluster-creation.json
```
## API を使用して Amazon MSK クラスターを作成する際にストレージスループットをプロビジョニングする
クラスターの作成時にプロビジョンドストレージのスループットを設定するには、[CreateClusterV2](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters.html#CreateClusterV2) を使用します。
# Amazon MSK Provisioned 設定
Amazon MSK は、ブローカー、トピック、および メタデータ ノードのデフォルト設定を提供します。また、カスタム設定を作成し、それらを使用して新しい MSK クラスターを作成したり、既存のクラスターを更新することもできます。MSK 設定は、一連のプロパティとそれに対応する値で構成されます。クラスターで使用するブローカーの種類に応じて、設定のデフォルト値が異なり、変更可能な設定項目も異なります。標準ブローカーおよび Express ブローカーの設定方法の詳細については、以下のセクションを参照してください。
**Topics**
+ [標準ブローカーの設定](msk-configuration-standard.md)
+ [Express ブローカー設定](msk-configuration-express.md)
+ [ブローカー設定オペレーション](msk-configuration-operations.md)
# 標準ブローカーの設定
このセクションでは、標準ブローカーの設定プロパティについて説明します。
**Topics**
+ [カスタム Amazon MSK 設定](msk-configuration-properties.md)
+ [デフォルト Amazon MSK 設定](msk-default-configuration.md)
+ [Amazon MSK 階層型ストレージのトピックレベル設定に関するガイドライン](msk-guidelines-tiered-storage-topic-level-config.md)
# カスタム Amazon MSK 設定
Amazon MSK を使用してカスタム MSK 構成を作成し、以下の Apache Kafka 構成プロパティを設定できます。明示的に設定しないプロパティは、[デフォルト Amazon MSK 設定](msk-default-configuration.md) にある値を取得します。設定プロパティの詳細については、「[Apache Kafka の設定](https://kafka.apache.org/documentation/#configuration)」を参照してください。
| 名前 | 説明 |
| --- | --- |
| allow.everyone.if.no.acl.found | このプロパティを false に設定する場合は、最初に、クラスターに対して Apache Kafka ACL を定義する必要があります。最初に Apache Kafka ACL を定義せずにこのプロパティを false に設定すると、クラスターにアクセスできなくなります。その場合は、設定を再度更新し、このプロパティを true に設定することで、クラスターへのアクセスを回復できます。 |
| auto.create.topics.enable | サーバーでトピックの自動作成を有効にします。 |
| compression.type | 特定のトピックの最終的な圧縮タイプ。このプロパティは、スタンダードの圧縮コーデック (gzip、snappy、lz4、および zstd) に設定できます。また、uncompressed に設定することもできます。この値は、圧縮しないことと同等です。値を producer に設定すると、プロデューサーが設定した元の圧縮コーデックが保持されます。 |
| connections.max.idle.ms | アイドル接続のタイムアウト (ミリ秒単位)。サーバーソケットプロセッサスレッドは、接続のアイドル状態がこのプロパティに対して設定されている値を超えると、その接続を閉じます。 |
| default.replication.factor | 自動的に作成されるトピックのデフォルトのレプリケーション係数。 |
| delete.topic.enable | トピックの削除オペレーションを有効にします。この設定をオフにすると、管理ツールからトピックを削除することができません。 |
| group.initial.rebalance.delay.ms | グループコーディネーターが、最初の再調整を実行する前に、新しいグループに追加のデータコンシューマーが参加するのを待機する時間。遅延を長くすると再調整を減らせる可能性がありますが、処理が開始されるまでの時間が長くなります。 |
| group.max.session.timeout.ms | 登録されたコンシューマーの最大セッションタイムアウト。タイムアウトを長くすると、コンシューマーはハートビート間でより多くの時間をメッセージの処理に使用できるようになりますが、その代償として、障害検出に要する時間が長くなります。 |
| group.min.session.timeout.ms | 登録されたコンシューマーの最小セッションタイムアウト。タイムアウトを短くすると、障害検出までの時間が短縮される一方で、より頻繁にコンシューマーのハートビートが発生するようになります。これにより、ブローカーリソースが圧迫される可能性があります。 |
| leader.imbalance.per.broker.percentage | ブローカーごとに許容されるリーダーの不均衡率。ブローカーごとにこの値を超えると、コントローラーはリーダーバランスをトリガーします。この値はパーセントで指定されます。 |
| log.cleaner.delete.retention.ms | Apache Kafka が削除されたレコードを保持する時間。最小値は 0 です。 |
| log.cleaner.min.cleanable.ratio | この設定プロパティには、0 から 1 までの値を指定できます。この値は、ログコンパクターがログのクリーニングを試行する頻度を決定します (ログ圧縮が有効になっている場合)。デフォルトでは、Apache Kafka は、ログの 50％ 以上が圧縮されている場合は、そのログのクリーニングを回避します。この比率は、ログで重複によって浪費される最大スペースを制限します (50％ の場合、ログの最大 50％ が重複である可能性があることを意味します)。比率が高いほど、クリーニングは少なく、効率的ですが、ログ内の無駄なスペースが多くなります。 |
| log.cleanup.policy | 保存ウィンドウ外のセグメントのデフォルトのクリーンアップポリシー。カンマ区切りの有効なポリシーのリスト。有効なポリシーは delete および compact です。階層型ストレージに対応したクラスターの場合、有効なポリシーは delete のみです。 |
| log.flush.interval.messages | メッセージがディスクにフラッシュされるまでにログパーティションに蓄積されるメッセージの数。 |
| log.flush.interval.ms | トピック内のメッセージがディスクにフラッシュされるまでにメモリに保持される最大時間 (ミリ秒単位)。この値を設定しない場合、log.flush.Scheduler.interval.ms の値が使用されます。最小値は 0 です。 |
| log.message.timestamp.difference.max.ms | この設定は Kafka 3.6.0 では廃止されました。log.message.timestamp.before.max.ms および log.message.timestamp.after.max.ms の 2 つの設定が追加されました。ブローカーがメッセージを受信したときのタイムスタンプと、メッセージで指定されたタイムスタンプとの間の最大時間差。log.message.timestamp.type=CreateTime の場合、タイムスタンプの差がこのしきい値を超えると、メッセージは拒否されます。log.message.timestamp.type = LogAppendTime の場合、この設定は無視されます。 |
| log.message.timestamp.type | メッセージ内のタイムスタンプがメッセージの作成時刻であるか、ログの追加時刻であるかを指定します。指定できる値は、CreateTime および LogAppendTime です。 |
| log.retention.bytes | 削除する前のログの最大サイズ。 |
| log.retention.hours | log.retention.ms プロパティの 3 次である、ログファイルを削除する前に保持する時間数。 |
| log.retention.minutes | log.retention.ms プロパティに対してセカンダリである、ログファイルを削除する前に保持する時間 (分)。この値を設定しない場合、log.retention.hours の値が使用されます。 |
| log.retention.ms | ログファイルを削除する前に保持するミリ秒数 (ミリ秒単位)。設定されていない場合は、log.retention.minutes の値が使用されます。 |
| log.roll.ms | 新しいログセグメントがロールアウトされるまでの最大時間 (ミリ秒単位)。このプロパティを設定しない場合は、log.roll.hours の値が使用されます。このプロパティの可能な最小値は 1 です。 |
| log.segment.bytes | 1 つのログファイルの最大サイズ。 |
| max.incremental.fetch.session.cache.slots | 維持される増分取得セッションの最大数。 |
| message.max.bytes | Kafka が許容する最大レコードバッチサイズ。この値を増やし、0.10.2 より古いコンシューマーが存在する場合、コンシューマーの取得サイズも増やして、この大きさのレコードバッチを取得できるようにする必要があります。 最新のメッセージ形式バージョンでは、効率を上げるために、常にメッセージがバッチにグループ化されます。以前のメッセージ形式バージョンでは、非圧縮レコードはバッチにグループ化されません。その場合、この制限は単一のレコードにのみ適用されます。 この値は、トピックレベルの max.message.bytes 設定を使用して、トピックごとに設定できます。 |
| min.insync.replicas | プロデューサーが acks を `"all"` (または `"-1"`) に設定した場合、min.insync.replicas の値は書き込みが成功したと見なされるために書き込みを確認する必要があるレプリカの最小数を指定します。この最小値を満たせない場合、プロデューサーは例外 (NotEnoughReplicas、または NotEnoughReplicasAfterAppend) を発生させます。 min.insync.replicas と acks の値を使用すると、より高い耐久性を保証できます。例えば、レプリケーション係数が 3 のトピックを作成し、min.insync.replicas を 2 に設定して、acks を `"all"` に設定して生成するとします。これにより、大部分のレプリカが書き込みを受け取らない場合、プロデューサーが例外を発生させることができます。 |
| num.io.threads | サーバーがリクエストを処理するために使用するスレッドの数。これにはディスク I/O が含まれる場合があります。 |
| num.network.threads | サーバーがネットワークからリクエストを受信し、ネットワークにレスポンスを送信するために使用するスレッドの数。 |
| num.partitions | トピックごとのログパーティションのデフォルト数。 |
| num.recovery.threads.per.data.dir | スタートアップ時にログを復元し、シャットダウン時にログをフラッシュするために使用されるデータディレクトリごとのスレッド数。 |
| num.replica.fetchers | ソースブローカーからのメッセージのレプリケートに使用されるフェッチャースレッドの数。この値を大きくすると、フォロワーブローカーでの I/O 並列処理の度合いが高くなります。 |
| offsets.retention.minutes | コンシューマーグループがすべてのコンシューマーを失う (つまり、空になる) と、オフセットはこの保持期間にわたって保持されてから破棄されます。スタンドアロンのコンシューマー (手動割り当てを使用するコンシューマー) の場合、オフセットは、最後のコミットの時刻にこの保持期間を足した時刻に有効期限切れになります。 |
| offsets.topic.replication.factor | オフセットトピックのレプリケーション係数。可用性を確保するには、この値を高く設定します。内部トピックの作成は、クラスターサイズがこのレプリケーション係数の要件を満たすまで失敗します。 |
| replica.fetch.max.bytes | パーティションごとに取得しようとするメッセージのバイト数。これは絶対最大値ではありません。フェッチの空でない最初のパーティションの最初のレコードバッチがこの値より大きい場合、進行を保証するためにそのレコードバッチが返されます。message.max.bytes (ブローカー設定) または max.message.bytes (トピック設定) は、ブローカーが受け入れる最大レコードバッチサイズを定義します。 |
| replica.fetch.response.max.bytes | フェッチレスポンス全体に対して予想される最大バイト数。レコードはバッチでフェッチされます。また、フェッチの空でない最初のパーティションの最初のレコードバッチがこの値より大きい場合、進行を保証するためにそのレコードバッチが引き続き返されます。これは絶対最大値ではありません。message.max.bytes (ブローカー設定) または max.message.bytes (トピック設定) プロパティは、ブローカーが受け付ける最大レコードバッチサイズを指定します。 |
| replica.lag.time.max.ms | フォロワーがフェッチリクエストを送信していないか、またはリーダーのログ終了オフセットまでこのミリ秒数以上消費されていない場合、リーダーはフォロワーを ISR から削除します。MinValue: 10000MaxValue = 30000 |
| replica.selector.class | ReplicaSelector を実装する完全修飾クラス名。ブローカーは、この値を使用して優先リードレプリカを見つけます。Apache Kafka バージョン 2.4.1 以降を使用していて、コンシューマーが最も近いレプリカからフェッチできるようにする場合は、このプロパティを org.apache.kafka.common.replica.RackAwareReplicaSelector に設定します。詳細については、「[Apache Kafka バージョン 2.4.1 (代わりに 2.4.1.1 を使用)](supported-kafka-versions.md#2.4.1)」を参照してください。 |
| replica.socket.receive.buffer.bytes | ネットワークリクエスト用のソケット受信バッファ。 |
| socket.receive.buffer.bytes | ソケットサーバーソケットの SO\$1RCVBUF バッファー。このプロパティに設定できる最小値は -1 です。値が -1 の場合、Amazon MSK は OS のデフォルトを使用します。 |
| socket.request.max.bytes | ソケットリクエストの最大バイト数。 |
| socket.send.buffer.bytes | ソケットサーバーソケットの SO\$1SNDBUF バッファー。このプロパティに設定できる最小値は -1 です。値が -1 の場合、Amazon MSK は OS のデフォルトを使用します。 |
| transaction.max.timeout.ms | トランザクションの最大タイムアウト。クライアントのリクエストしたトランザクション時間がこの値を超えると、ブローカーは InitProducerIdRequest でエラーを返します。これにより、クライアントが大きすぎるタイムアウトを設定するのを防ぎ、トランザクションに含まれるトピックから読み取りを行うコンシューマーが停止するのを回避することができます。 |
| transaction.state.log.min.isr | トランザクショントピックに対してオーバーライドされる min.insync.replicas 設定。 |
| transaction.state.log.replication.factor | トランザクショントピックのレプリケーション係数。このプロパティに高い値を設定すると、可用性が向上します。内部トピックの作成は、クラスターサイズがこのレプリケーション係数の要件を満たすまで失敗します。 |
| transactional.id.expiration.ms | トランザクションコーディネーターが、トランザクション ID を有効期限切れにする前に、現在のトランザクションのトランザクションステータスの更新の受信を待機する時間 (ミリ秒単位)。この設定は、プロデューサー ID の有効期限切れにも影響します。これは、プロデューサー ID の有効期限は、指定されたプロデューサー ID での最後の書き込みからこの時間が経過すると切れるためです。トピックの保持設定が原因でプロデューサー ID からの最後の書き込みが削除された場合、プロデューサー ID の有効期限切れが早くなる可能性があります。このプロパティの最小値は 1 ミリ秒です。 |
| unclean.leader.election.enable | ISR セットに含まれていないレプリカを、データ損失の可能性がある場合でも、最終手段として、リーダーとして使用するかどうかを指定します。 |
| zookeeper.connection.timeout.ms | ZooKeeper モードクラスター。クライアントが ZooKeeper への接続を確立するのを待機する最大時間。この値を設定しない場合、zookeeper.session.timeout.ms の値が使用されます。 MinValue = 6000 MaxValue = 18000 クラスターのダウンタイムを避けるため、T3.small では、この値を 10,000 に設定することをお勧めします。 |
| zookeeper.session.timeout.ms | ZooKeeper モードクラスター。Apache ZooKeeper セッションのタイムアウト (ミリ秒単位)。 MinValue = 6000 MaxValue = 18000 |
カスタム MSK 設定を作成する方法、すべての設定を一覧表示する方法、または説明する方法については、「[ブローカー設定オペレーション](msk-configuration-operations.md)」を参照してください。カスタム MSK 設定を使用して MSK クラスターを作成したり、新しいカスタム設定でクラスターを更新したりするには、「[Amazon MSK の主な特徴および概念](operations.md)」を参照してください。
既存の MSK クラスターをカスタム MSK 設定で更新すると、Amazon MSK は、必要に応じてローリング再起動を実行し、顧客のダウンタイムを最小限に抑えるためのベストプラクティスを使用します。例えば、Amazon MSK は各ブローカーを再起動した後、次のブローカーに移動する前に、設定の更新中にブローカーが見逃した可能性のあるデータにブローカーがキャッチアップできるようにします。
## 動的 Amazon MSK 設定
Amazon MSK が提供する設定プロパティに加えて、ブローカーの再起動を必要としないクラスターレベルおよびブローカーレベルの設定プロパティを動的に設定できます。一部の設定プロパティを動的に設定できます。Apache Kafka のドキュメントの「[Broker Configs](https://kafka.apache.org/documentation/#brokerconfigs)」の表で、読み取り専用としてマークされていないプロパティがこれに該当します。動的設定およびコマンド例については、Apache Kafka のドキュメントの「[Updating Broker Configs](https://kafka.apache.org/documentation/#dynamicbrokerconfigs)」を参照してください。
**注記**
`advertised.listeners` プロパティは設定できますが、`listeners` プロパティは設定できません。
## トピックレベルの Amazon MSK 設定
Apache Kafka コマンドを使用して、新規および既存のトピックのトピックレベルの設定プロパティを設定するか変更することができます。トピックレベルの設定プロパティの詳細と設定方法の例については、Apache Kafka のドキュメントの「[Topic-Level Configs](https://kafka.apache.org/documentation/#topicconfigs)」を参照してください。
# デフォルト Amazon MSK 設定
MSK クラスターを作成し、カスタム MSK 設定を指定しない場合、Amazon MSK は、次の表に示す値を使用してデフォルト設定を作成および使用します。このテーブルにないプロパティの場合、Amazon MSK はご使用のバージョンの Apache Kafka に関連付けられているデフォルトを使用します。これらのデフォルト値のリストについては、[Apache Kafka の設定](https://kafka.apache.org/documentation/#configuration)を参照してください。
| 名前 | 説明 | 非階層型ストレージクラスターのデフォルト値 | 階層型ストレージ対応クラスターのデフォルト値 |
| --- | --- | --- | --- |
| allow.everyone.if.no.acl.found | 特定のリソースに一致するリソースパターンがない場合、リソースには ACL が関連付けられていません。この場合、このプロパティを true に設定すると、スーパーユーザーだけでなく、すべてのユーザーがリソースにアクセスできます。 | true | true |
| auto.create.topics.enable | サーバー上のトピックの自動作成を有効にします。 | false | false |
| auto.leader.rebalance.enable | 自動リーダーバランシングを有効にします。バックグラウンドスレッドは、必要に応じて一定の間隔でリーダーバランスをチェックして開始します。 | true | true |
| default.replication.factor | 自動的に作成されるトピックのデフォルトのレプリケーション係数。 | 3 つのアベイラビリティーゾーン内のクラスターの場合は 3、2 つのアベイラビリティーゾーン内のクラスターの場合は 2。 | 3 つのアベイラビリティーゾーン内のクラスターの場合は 3、2 つのアベイラビリティーゾーン内のクラスターの場合は 2。 |
| local.retention.bytes | 古いセグメントを削除する前の、パーティションのローカルログセグメントの最大サイズ。この値を設定しない場合、log.retention.bytes の値が使用されます。有効な値は、常に log.retention.bytes の値以下にする必要があります。デフォルト値 -2 は、ローカル保持に制限がないことを示します。これは、retention.ms/bytes 設定の -1 に相当します。local.retention.ms プロパティと local.retention.bytes プロパティは、ログセグメントをローカルストレージに保持する期間を決定するために使用されるという点で log.retention に似ています。既存の log.retention.\$1 設定は、トピックパーティションの保持設定です。これには、ローカルストレージとリモートストレージの両方が含まれます。有効な値: [-2; \$1Inf] の整数 | -2 は制限なし | -2 は制限なし |
| local.retention.ms | 削除するまでローカルログセグメントを保持するミリ秒数。この値を設定しない場合、Amazon MSK は log.retention.ms の値を使用します。有効な値は、常に log.retention.bytes の値以下にする必要があります。デフォルト値 -2 は、ローカル保持に制限がないことを示します。これは、retention.ms/bytes 設定の -1 に相当します。local.retention.ms と local.retention.bytes の値は log.retention と似ています。MSK はこの設定を使用して、ログセグメントをローカルストレージに保持する期間を決定します。既存の log.retention.\$1 設定は、トピックパーティションの保持設定です。これには、ローカルストレージとリモートストレージの両方が含まれます。有効な値は 0 より大きい整数です。 | -2 は制限なし | -2 は制限なし |
| log.message.timestamp.difference.max.ms | この設定は Kafka 3.6.0 では廃止されました。log.message.timestamp.before.max.ms および log.message.timestamp.after.max.ms の 2 つの設定が追加されました。ブローカーがメッセージを受信したときのタイムスタンプと、メッセージで指定されたタイムスタンプとの間に許容される最大差です。log.message.timestamp.type=CreateTime の場合、タイムスタンプの差がこのしきい値を超えると、メッセージは拒否されます。log.message.timestamp.type = LogAppendTime の場合、この設定は無視されます。不必要な頻度でのログローリングを避けるために、許容されるタイムスタンプの最大差は log.retention.ms 以下にする必要があります。 | 9223372036854775807 | Kafka 2.8.2. (階層型) および Kafka 3.7.x (階層型) の場合は 86400000。 |
| log.segment.bytes | 1 つのログファイルの最大サイズ。 | 1073741824 | 134217728 |
| min.insync.replicas | プロデューサーが acks の値を `"all"` (または `"-1"`) に設定した場合、min.insync.replicas の値は書き込みが成功したと見なされるために書き込みを確認する必要があるレプリカの最小数を指定します。この値がこの最小値を満たしていない場合，プロデューサーは例外 (NotEnoughReplicas または NotEnoughReplicasAfterAppend) を発生させます。 min.insync.replicas と acks の値を組み合わせて使用すると、より高い耐久性を保証できます。例えば、レプリケーション係数が 3 のトピックを作成し、min.insync.replicas を 2 に設定して、acks を `"all"` に設定して生成するとします。これにより、大部分のレプリカが書き込みを受け取らない場合、プロデューサーが例外を発生させることができます。 | 3 つのアベイラビリティーゾーン内のクラスターの場合は 2、2 つのアベイラビリティーゾーン内のクラスターの場合は 1。 | 3 つのアベイラビリティーゾーン内のクラスターの場合は 2、2 つのアベイラビリティーゾーン内のクラスターの場合は 1。 |
| num.io.threads | サーバーがリクエストを生成するために使用するスレッドの数。これにはディスク I/O が含まれる場合があります。 | 8 | max(8, vCPUs)。vCPUs はブローカーのインスタンスサイズによって異なります |
| num.network.threads | サーバーがネットワークからリクエストを受信し、ネットワークにレスポンスを送信するために使用するスレッドの数。 | 5 | max(5, vCPUs / 2)。vCPUs はブローカーのインスタンスサイズによって異なります |
| num.partitions | トピックごとのログパーティションのデフォルト数。 | 1 | 1 |
| num.replica.fetchers | ソースブローカーからのメッセージをレプリケートするために使用されるフェッチャースレッドの数。この値を大きくすると、フォロワーブローカーの I/O 並列処理の度合いを上げることができます。 | 2 | max(2, vCPUs / 4)。vCPUs はブローカーのインスタンスサイズによって異なります |
| remote.log.msk.disable.policy | 階層型ストレージを無効にする場合は、remote.storage.enable と一緒に使用します。remote.storage.enable を false に設定した場合に階層型ストレージ内のデータが削除されるようにするには、このポリシーを Delete に設定します。 | 該当なし | なし |
| remote.log.reader.threads | リモートログリーダーのスレッドプールサイズ。リモートストレージからデータを取得するタスクをスケジュールする際に使用されます。 | 該当なし | max(10, vCPUs \$1 0.67)。vCPUs はブローカーのインスタンスサイズによって異なります |
| remote.storage.enable | これを true に設定すると、トピックの階層型 (リモート) ストレージが有効になります。これを false に設定し、remote.log.msk.disable.policy が Delete に設定されている場合、トピックレベルの階層型ストレージが無効になります。階層型ストレージを無効にすると、リモートストレージからデータが削除されます。トピックの階層型ストレージを無効にすると、再度有効にすることはできません。 | false | false |
| replica.lag.time.max.ms | フォロワーがフェッチリクエストを送信していないか、またはリーダーのログ終了オフセットまでこのミリ秒数以上消費されていない場合、リーダーはフォロワーを ISR から削除します。 | 30000 | 30000 |
| retention.ms | 必須フィールド。最短期間は 3 日間です。設定は必須であるため、デフォルトはありません。 Amazon MSK は retention.ms 値と local.retention.ms を使用して、データがローカルから階層型ストレージに移動するタイミングを決定します。local.retention.ms 値は、データをローカルから階層型ストレージに移動するタイミングを指定します。retention.ms 値は、階層型ストレージからデータを削除する (つまり、クラスターから削除する) タイミングを指定します。有効な値: [-1; \$1Inf] の整数 | 最小 259,200,000 ミリ秒 (3 日間)。無期限に保持する場合は -1。 | 最小 259,200,000 ミリ秒 (3 日間)。無期限に保持する場合は -1。 |
| socket.receive.buffer.bytes | ソケットサーバーソケットの SO\$1RCVBUF バッファー。値が -1 の場合、OS のデフォルトが使用されます。 | 102400 | 102400 |
| socket.request.max.bytes | ソケットリクエストの最大バイト数。 | 104857600 | 104857600 |
| socket.send.buffer.bytes | ソケットサーバーソケットの SO\$1SNDBUF バッファー。値が -1 の場合、OS のデフォルトが使用されます。 | 102400 | 102400 |
| unclean.leader.election.enable | ISR セットに含まれていないレプリカを、データ損失の可能性がある場合でも、最終手段として、リーダーとして使用するかどうかを指定します。 | true | false |
| zookeeper.session.timeout.ms | Apache ZooKeeper セッションのタイムアウト (ミリ秒単位)。 | 18000 | 18000 |
| zookeeper.set.acl | セキュア ACL を使用するようにクライアントを設定します。 | false | false |
カスタム設定値の指定方法については、「[カスタム Amazon MSK 設定](msk-configuration-properties.md)」を参照してください。
# Amazon MSK 階層型ストレージのトピックレベル設定に関するガイドライン
階層型ストレージをトピックレベルで設定する場合のデフォルト設定と制限は次のとおりです。
+ Amazon MSK では、階層型ストレージが有効になっているトピックのログセグメントサイズを小さくすることはできません。セグメントを作成する場合、最小ログセグメントサイズは 48 MiB、または最小セグメントロール時間は 10 分です。これらの値は segment.bytes プロパティと segment.ms プロパティにマッピングされます。
+ local.retention.ms/bytes の値は、retention.ms/bytes より小さくする必要があります。これは階層型ストレージの保持設定です。
+ local.retention.ms/bytes のデフォルト値は -2 です。つまり、retention.ms の値が local.retention.ms/bytes に使用されます。この場合、データはローカルストレージと階層型ストレージの両方に残り (それぞれ 1 つのコピー)、同時に有効期限切れになります。このオプションでは、ローカルデータのコピーがリモートストレージに保持されます。この場合、消費トラフィックから読み取られるデータはローカルストレージから取得されます。
+ retention.ms のデフォルト値は 7 日間です。retention.bytes には、デフォルトサイズの制限はありません。
+ retention.ms/bytes の最小値は -1 です。これは、無期限に保持することを意味します。
+ local.retention.ms/bytes の最小値は -2 です。これは、ローカルストレージでは無期限に保持されることを意味します。これは、retention.ms/bytes を -1 に設定するのと同じです。
+ 階層型ストレージが有効になっているトピックには、トピックレベル設定の retention.ms が必須です。retention.ms の最小値は 3 日間です。
階層型ストレージの制約の詳細については、「[Amazon MSK クラスターの階層型ストレージの制約と制限](msk-tiered-storage.md#msk-tiered-storage-constraints)」を参照してください。
# Express ブローカー設定
Apache Kafka には、MSK Provisioned のクラスターのパフォーマンスを調整するために使用できる数百のブローカー設定があります。誤った値または最適でない値を設定すると、クラスターの信頼性およびパフォーマンスに影響する可能性があります。Express ブローカーは、重要な設定に最適な値を設定し、一般的な設定ミスから保護することで、MSK Provisioned のクラスターの可用性と耐久性を向上させます。読み取りおよび書き込みアクセスに基づく設定には、以下の 3 つのカテゴリがあります。[読み取り / 書き込み (編集可能)](msk-configuration-express-read-write.md)、[読み取り専用](msk-configuration-express-read-only.md)、および読み取り不可 / 書き込み不可の設定です。一部の設定では、クラスターが実行されている Apache Kafka バージョンに対して Apache Kafka のデフォルト値が引き続き使用されます。それらを Apache Kafka のデフォルトとしてマークします。
**Topics**
+ [MSK Express のカスタムブローカー設定 (読み取り / 書き込みアクセス)](msk-configuration-express-read-write.md)
+ [Express ブローカーの読み取り専用設定](msk-configuration-express-read-only.md)
# MSK Express のカスタムブローカー設定 (読み取り / 書き込みアクセス)
読み取り / 書き込みブローカーの設定は、Amazon MSK の[設定の更新機能](msk-update-cluster-config.md)を使用するか、Apache Kafka の AlterConfig API を使用して更新できます。Apache Kafka ブローカー設定は静的または動的のどちらか一方です。静的設定を適用するにはブローカーの再起動が必要ですが、動的設定にはブローカーの再起動は必要ありません。設定プロパティと更新モードの詳細については、「[ブローカー設定の更新](https://kafka.apache.org/documentation/#dynamicbrokerconfigs)」を参照してください。
**Topics**
+ [MSK Express ブローカーの静的設定](#msk-configuration-express-static-configuration)
+ [Express ブローカーの動的設定](#msk-configuration-express-dynamic-configuration)
+ [Express ブローカーのトピックレベルの設定](#msk-configuration-express-topic-configuration)
## MSK Express ブローカーの静的設定
Amazon MSK を使用してカスタム MSK 設定ファイルを作成し、以下の静的プロパティを設定できます。Amazon MSK は、ユーザーが設定していないその他のすべてのプロパティを設定および管理します。静的設定ファイルは、MSK コンソールまたは [configurations コマンド](msk-configuration-operations-create.md)を使用して作成および更新できます。
| プロパティ | 説明 | デフォルト値 |
| --- | --- | --- |
| allow.everyone.if.no.acl.found | このプロパティを false に設定する場合は、最初にクラスターに Apache Kafka ACL を定義していることを確認してください。事前に Apache Kafka ACL を定義していない場合、このプロパティを誤って設定すると、クラスターにアクセスできなくなります。その場合は、設定を再度更新し、このプロパティを正確に設定することで、クラスターへのアクセスを回復できます。 | true |
| auto.create.topics.enable | サーバー上のトピックの自動作成を有効にします。 | false |
| compression.type | 特定のトピックに対する最終的な圧縮タイプを指定する。この設定では、標準の圧縮コーデックである gzip、snappy、lz4、zstd を受け入れます。 この設定では、さらに、圧縮なしと同等および「`producer`」の、生成元が設定した元の圧縮コーデックを保持する「`uncompressed`」も受け付けます。 | Apache Kafka のデフォルト |
| connections.max.idle.ms | アイドル接続のタイムアウト (ミリ秒単位)。サーバーソケットプロセッサスレッドは、接続のアイドル状態がこのプロパティに対して設定されている値を超えると、その接続を閉じます。 | Apache Kafka のデフォルト |
| delete.topic.enable | トピックの削除オペレーションを有効にします。この設定をオフにすると、管理ツールからトピックを削除することができません。 | Apache Kafka のデフォルト |
| group.initial.rebalance.delay.ms | グループコーディネーターが、最初の再調整を実行する前に、新しいグループに追加のデータコンシューマーが参加するのを待機する時間。遅延を長くすると再調整を減らせる可能性がありますが、処理が開始されるまでの時間が長くなります。 | Apache Kafka のデフォルト |
| group.max.session.timeout.ms | 登録されたコンシューマーの最大セッションタイムアウト。タイムアウトを長くすると、コンシューマーはハートビート間でより多くの時間をメッセージの処理に使用できるようになりますが、その代償として、障害検出に要する時間が長くなります。 | Apache Kafka のデフォルト |
| leader.imbalance.per.broker.percentage | ブローカーごとに許容されるリーダーの不均衡率。ブローカーごとにこの値を超えると、コントローラーはリーダーバランスをトリガーします。この値はパーセントで指定されます。 | Apache Kafka のデフォルト |
| log.cleanup.policy | 保存ウィンドウ外のセグメントのデフォルトのクリーンアップポリシー。カンマ区切りの有効なポリシーのリスト。有効なポリシーは delete および compact です。階層型ストレージに対応したクラスターの場合、有効なポリシーは、次の delete のみです。 | Apache Kafka のデフォルト |
| log.message.timestamp.after.max.ms | メッセージのタイムスタンプおよびブローカーのタイムスタンプの間の許容されるタイムスタンプの差。メッセージのタイムスタンプはブローカーのタイムスタンプと同じ、またはそれ以降であってもよく、その最大許容差はこの設定で指定された値によって決まります。 `log.message.timestamp.type=CreateTime` の場合、タイムスタンプの差がこの指定されたしきい値を超えるとメッセージは拒否されます。`log.message.timestamp.type=LogAppendTime` の場合、この設定は無視されます。 | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms、要するに 1 日) |
| log.message.timestamp.before.max.ms | ブローカーのタイムスタンプとメッセージタイムスタンプの許容されるタイムスタンプの差。メッセージのタイムスタンプはブローカーのタイムスタンプと同じ、またはそれ以前であってもよく、その最大許容差はこの設定で指定された値によって決まります。 `log.message.timestamp.type=CreateTime` の場合、タイムスタンプの差がこの指定されたしきい値を超えるとメッセージは拒否されます。`log.message.timestamp.type=LogAppendTime` の場合、この設定は無視されます。 | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms、要するに 1 日) |
| log.message.timestamp.type | メッセージ内のタイムスタンプがメッセージの作成時刻であるか、ログの追加時刻であるかを指定します。指定できる値は、CreateTime および LogAppendTime です。 | Apache Kafka のデフォルト |
| log.retention.bytes | 削除する前のログの最大サイズ。 | Apache Kafka のデフォルト |
| log.retention.ms | ログファイルを削除する前に保持するミリ秒数。 | Apache Kafka のデフォルト |
| max.connections.per.ip | 各 IP アドレスから許可される最大接続数。これは、max.connections.per.ip.overrides プロパティを使用してオーバーライドが設定されている場合、0 に設定できます。制限値に達した場合、その IP アドレスからの新規接続は切断されます。 | Apache Kafka のデフォルト |
| max.incremental.fetch.session.cache.slots | 維持される増分取得セッションの最大数。 | Apache Kafka のデフォルト |
| message.max.bytes | Kafka が許容する最大レコードバッチサイズ。この値を増やし、0.10.2 より古いコンシューマーが存在する場合、コンシューマーの取得サイズも増やして、この大きさのレコードバッチを取得できるようにする必要があります。 最新のメッセージ形式バージョンでは、効率を上げるために、常にメッセージがバッチにグループ化されます。以前のメッセージ形式バージョンでは、非圧縮レコードはバッチにグループ化されません。その場合、この制限は単一のレコードにのみ適用されます。トピックレベル `max.message.bytes` の設定により、この値をトピックごとに設定できます。 | Apache Kafka のデフォルト |
| num.partitions | 各トピックに対するデフォルトのパーティション数。 | 1 |
| offsets.retention.minutes | コンシューマーグループがすべてのコンシューマーを失う (つまり、空になる) と、オフセットはこの保持期間にわたって保持されてから破棄されます。スタンドアロンの消費者 (手動割り当てを使用するコンシューマー) の場合、オフセットは、最後のコミットの時刻に、この保持期間を加えた時刻に有効期限切れになります。 | Apache Kafka のデフォルト |
| replica.fetch.max.bytes | パーティションごとに取得しようとするメッセージのバイト数。これは絶対最大値ではありません。フェッチの空でない最初のパーティションの最初のレコードバッチがこの値より大きい場合、進行を保証するためにそのレコードバッチが返されます。message.max.bytes (ブローカー設定) または max.message.bytes (トピック設定) は、ブローカーが受け入れる最大レコードバッチサイズを定義します。 | Apache Kafka のデフォルト |
| replica.selector.class | ReplicaSelector を実装する完全修飾クラス名。ブローカーは、この値を使用して優先リードレプリカを見つけます。消費者が最も近いレプリカから取得できるようにするには、このプロパティ`org.apache.kafka.common.replica.RackAwareReplicaSelector`を設定してください。 | Apache Kafka のデフォルト |
| socket.receive.buffer.bytes | ソケットサーバーソケットの SO\$1RCVBUF バッファー。値が -1 の場合、OS のデフォルトが使用されます。 | 102400 |
| socket.request.max.bytes | ソケットリクエストの最大バイト数。 | 104857600 |
| socket.send.buffer.bytes | ソケットサーバーソケットの SO\$1SNDBUF バッファー。値が -1 の場合、OS のデフォルトが使用されます。 | 102400 |
| transaction.max.timeout.ms | トランザクションの最大タイムアウト。クライアントのリクエストしたトランザクション時間がこの値を超えると、ブローカーは InitProducerIdRequest でエラーを返します。これにより、クライアントが大きすぎるタイムアウトを設定するのを防ぎ、トランザクションに含まれるトピックから読み取りを行うコンシューマーが停止するのを回避することができます。 | Apache Kafka のデフォルト |
| transactional.id.expiration.ms | トランザクションコーディネーターが、トランザクション ID を有効期限切れにする前に、現在のトランザクションのトランザクションステータスの更新の受信を待機する時間 (ミリ秒単位)。この設定は、プロデューサー ID の有効期限にも影響します。これは、指定されたプロデューサー ID の有効期限は、指定されたプロデューサー ID での最後の書き込みからこの時間が経過すると切れるためです。トピックの保持設定が原因でプロデューサー ID からの最後の書き込みが削除された場合、プロデューサー ID の有効期限切れが早くなる可能性があります。このプロパティの最小値は 1 ミリ秒です。 | Apache Kafka のデフォルト |
## Express ブローカーの動的設定
Apache Kafka AlterConfig API または Kafka-configs.sh ツールを使用して、次の動的設定を編集できます。Amazon MSK は、ユーザーが設定していないその他のすべてのプロパティを設定および管理します。ブローカーの再起動を必要としない クラスター-レベルおよびブローカーレベルの設定プロパティを動的に設定できます。
| プロパティ | 説明 | デフォルトの値 |
| --- | --- | --- |
| advertised.listeners | `listeners` 設定プロパティと異なる場合、クライアントが使用するためのリスナーを公開します。IaaS 環境では、これはブローカーがバインドするインターフェイスとは異なる必要がある場合があります。これを設定しない場合、リスナー の値が使用されます。リスナーとは異なり、0.0.0.0 のメタアドレスを advertise (公開) として指定することはできません。 また、`listeners` とは異なり、このプロパティでは ポート番号の重複が許可されており、その結果、あるリスナーが別のリスナーのアドレスを advertise (公開) するように設定することができます。外部ロードバランサーが使用されている場合、これが有用な場合があります。 このプロパティはブローカーごとに設定されます。 | null |
| compression.type | 特定のトピックの最終的な圧縮タイプ。このプロパティは、スタンダードの圧縮コーデック (`gzip`、`snappy`、`lz4`、および `zstd`) に設定できます。また、`uncompressed` に設定することもできます。この値は、圧縮しないことと同等です。値を `producer` に設定すると、プロデューサーが設定した元の圧縮コーデックが保持されます。 | Apache Kafka のデフォルト |
| log.cleaner.delete.retention.ms | ログ圧縮が有効なトピックにおいて、削除用トゥームストーンマーカーを保持する期間。この設定は、コンシューマーがオフセット 0 から読み取りを開始した場合に、最終状態の有効なスナップショットを取得するために、読み取りを完了しなければならない時間の上限も定めます。そうしないと、スキャンが完了する前に削除用トゥームストーンが収集される場合があります。 | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms、要するに 1 日)、Apache Kafka デフォルト |
| log.cleaner.min.compaction.lag.ms | ログ内でメッセージが圧縮されずに保持される最小時間。この設定は、圧縮処理中のログにのみ適用されます。 | 0、Apache Kafka デフォルト |
| log.cleaner.max.compaction.lag.ms | ログ内でメッセージが圧縮対象外のままとなる最大時間。この設定は、圧縮処理中のログにのみ適用されます。この設定は、[7日間、Long.Max] の範囲に制限されます。 | 9223372036854775807、Apache Kafka デフォルト |
| log.cleanup.policy | 保存ウィンドウ外のセグメントのデフォルトのクリーンアップポリシー。カンマ区切りの有効なポリシーのリスト。有効なポリシーは `delete` および `compact` です。階層型ストレージに対応したクラスターの場合、有効なポリシーは、次の `delete` のみです。 | Apache Kafka のデフォルト |
| log.message.timestamp.after.max.ms | メッセージのタイムスタンプおよびブローカーのタイムスタンプの間の許容されるタイムスタンプの差。メッセージのタイムスタンプはブローカーのタイムスタンプと同じ、またはそれ以降であってもよく、その最大許容差はこの設定で指定された値によって決まります。`log.message.timestamp.type=CreateTime` の場合、タイムスタンプの差がこの指定されたしきい値を超えるとメッセージは拒否されます。`log.message.timestamp.type=LogAppendTime` の場合、この設定は無視されます。 | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms、要するに 1 日) |
| log.message.timestamp.before.max.ms | ブローカーのタイムスタンプとメッセージタイムスタンプの許容されるタイムスタンプの差。メッセージのタイムスタンプはブローカーのタイムスタンプと同じ、またはそれ以前であってもよく、その最大許容差はこの設定で指定された値によって決まります。`log.message.timestamp.type=CreateTime` の場合、タイムスタンプの差がこの指定されたしきい値を超えるとメッセージは拒否されます。`log.message.timestamp.type=LogAppendTime` の場合、この設定は無視されます。 | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms、要するに 1 日) |
| log.message.timestamp.type | メッセージ内のタイムスタンプがメッセージの作成時刻であるか、ログの追加時刻であるかを指定します。指定できる値は、`CreateTime` および `LogAppendTime` です。 | Apache Kafka のデフォルト |
| log.retention.bytes | 削除する前のログの最大サイズ。 | Apache Kafka のデフォルト |
| log.retention.ms | ログファイルを削除する前に保持するミリ秒数。 | Apache Kafka のデフォルト |
| max.connection.creation.rate | ブローカーでいつでも許可される最大接続作成レート。 | Apache Kafka のデフォルト |
| max.connections | ブローカーで同時に許可される接続の最大数。この制限は、`max.connections.per.ip` を使用して設定された IP ごとの制限に加えて適用されます。 | Apache Kafka のデフォルト |
| max.connections.per.ip | 各 IP アドレスから許可される最大接続数。これは、max.connections.per.ip.overrides プロパティを使用してオーバーライドが設定されている場合、`0` に設定できます。制限値に達した場合、その IP アドレスからの新規接続は切断されます。 | Apache Kafka のデフォルト |
| max.connections.per.ip.overrides | デフォルトの最大接続数に対する、IP アドレスまたはホスト名ごとのオーバーライドをコンマ区切りで列挙したリスト。例として値は `hostName:100,127.0.0.1:200` です | Apache Kafka のデフォルト |
| message.max.bytes | Kafka が許容する最大レコードバッチサイズ。この値を増やし、0.10.2 より古いコンシューマーが存在する場合、コンシューマーの取得サイズも増やして、この大きさのレコードバッチを取得できるようにする必要があります。最新のメッセージ形式バージョンでは、効率を上げるために、常にメッセージがバッチにグループ化されます。以前のメッセージ形式バージョンでは、非圧縮レコードはバッチにグループ化されません。その場合、この制限は単一のレコードにのみ適用されます。トピックレベル `max.message.bytes` の設定により、この値をトピックごとに設定できます。 | Apache Kafka のデフォルト |
| producer.id.expiration.ms | トピックパーティションリーダーがプロデューサー ID を期限切れにする前に待機する時間 (ミリ秒単位) プロデューサー ID は、関連するトランザクションが進行中の間は有効期限切れになりません。プロデューサー ID は、トピックの保持設定によりそのプロデューサー ID からの最後の書き込みが削除された場合、より早く期限切れになる可能性があることに注意してください。この値を再試行中に期限切れを防ぐため、またメッセージの重複を防止するために、同じまたは、`delivery.timeout.ms`それ以上に設定することが有効です。ただし、ほとんどのユースケースではデフォルト値で十分です。 | Apache Kafka のデフォルト |
## Express ブローカーのトピックレベルの設定
Apache Kafka コマンドを使用して、新規および既存のトピックのトピックレベルの設定プロパティを設定するか変更することができます。トピックレベルの設定を指定できない場合、Amazon MSK はブローカーのデフォルト設定を使用します。ブローカーレベルの設定と同様に、Amazon MSK はトピックレベルの設定プロパティの一部を変更から保護します。例としては、レプリケーション係数、`min.insync.replicas`、`unclean.leader.election.enable` などがあります。レプリケーション係数の値が`3`以外の値でトピックを作成しようとすると、Amazon MSK はデフォルトでレプリケーション係数`3` が設定されたトピックを作成します。トピックレベルの設定プロパティの詳細と設定方法の例については、Apache Kafka のドキュメントの「[Topic-Level Configs](https://kafka.apache.org/documentation/#topicconfigs)」を参照してください。
| プロパティ | 説明 |
| --- | --- |
| cleanup.policy | この設定は、ログセグメントで使用する保持ポリシーを指定します。「削除」ポリシー (デフォルト) は、古いセグメントの保持期間またはサイズ制限に達した場合にそれらを破棄します。「コンパクト」ポリシーはログ圧縮を有効にし、各キーに対して最新の値を保持します。両方のポリシーをカンマ区切りで指定することも可能です (例: 「delete,compact」)。この場合、保持時間とサイズの設定に基づき古いセグメントは破棄され、保持されたセグメントは圧縮されます。Express ブローカーにおける圧縮は、パーティション内のデータが 256 MB に達した後にトリガーされます。 |
| compression.type | 特定のトピックに対する最終的な圧縮タイプを指定する。この設定は、標準の圧縮コーデック (`gzip`、`snappy`、`lz4`、`zstd`) を受け入れます。さらに、圧縮なし、および`producer`同等の設定を受け入れます`uncompressed`;これは、プロデューサーが設定した元の圧縮コーデックを保持することを意味します。 |
| delete.retention.ms | ログ圧縮が有効なトピックにおいて、削除用トゥームストーンマーカーを保持する期間。この設定は、コンシューマーがオフセット 0 から読み取りを開始した場合に、最終状態の有効なスナップショットを取得するために、読み取りを完了しなければならない時間の上限も定めます。そうしないと、スキャンが完了する前に削除用トゥームストーンが収集される場合があります。 この設定のデフォルト値は 86400000 (24 \$1 60 \$1 60 \$1 1000 ms、要するに 1 日)、Apache Kafka Default |
| max.message.bytes | Kafka が許可する最大レコードバッチサイズ (圧縮が有効な場合、圧縮後のサイズ)。この値を増やし、より年長の消費者が存在する場合は、消費者がこれほど大きなレコードバッチを取得できるように、`0.10.2`消費者のフェッチサイズも増やす必要がある。最新のメッセージ形式バージョンでは、効率を上げるために、レコードは常にバッチにグループ化されます。以前のメッセージ形式バージョンでは、圧縮されていないレコードはバッチにグループ化されず、この制限は単一のレコードにのみ適用されます。これは、トピックレベルの`max.message.bytes config`でトピックごとに設定できます。 |
| message.timestamp.after.max.ms | この設定は、メッセージのタイムスタンプとブローカーのタイムスタンプの間の許容されるタイムスタンプ差を設定します。メッセージのタイムスタンプはブローカーのタイムスタンプと同じ、またはそれ以降であってもよく、その最大許容差はこの設定で指定された値によって決まります。`message.timestamp.type=CreateTime` の場合、タイムスタンプの差がこの指定されたしきい値を超えるとメッセージは拒否されます。`message.timestamp.type=LogAppendTime` の場合、この設定は無視されます。 |
| message.timestamp.before.max.ms | この設定は、ブローカーのタイムスタンプとメッセージのタイムスタンプの間の許容されるタイムスタンプ差を設定します。メッセージのタイムスタンプはブローカーのタイムスタンプと同じ、またはそれ以前であってもよく、その最大許容差はこの設定で指定された値によって決まります。`message.timestamp.type=CreateTime` の場合、タイムスタンプの差がこの指定されたしきい値を超えるとメッセージは拒否されます。`message.timestamp.type=LogAppendTime` の場合、この設定は無視されます。 |
| message.timestamp.type | メッセージ内のタイムスタンプが、メッセージ作成時刻であるか ログ 追記時刻かを定義する。この値は `CreateTime` または `LogAppendTime` のいずれかでなければなりません |
| min.compaction.lag.ms | ログ内でメッセージが圧縮されずに保持される最小時間。この設定は、圧縮処理中のログにのみ適用されます。 この設定のデフォルト値は 0、Apache Kafka Default |
| max.compaction.lag.ms | ログ内でメッセージが圧縮対象外のままとなる最大時間。この設定は、圧縮処理中のログにのみ適用されます。この設定は、[7日間、Long.Max] の範囲に制限されます。 この設定のデフォルト値は 9223372036854775807、Apache Kafka Default です。 |
| retention.bytes | この設定は、パーティション (ログセグメントで構成される) が成長できる最大サイズを制御します。これにより、「削除」保持ポリシーを使用している場合に、古いログセグメントを破棄してスペースを確保するタイミングを決定します。デフォルトではサイズ制限はなく、時間制限のみが設定されています。この制限はパーティションレベルで適用されるため、パーティションの数を掛けてトピックの保持をバイト単位で計算します。さらに、`retention.bytes configuration` は `segment.ms` および `segment.bytes` 設定とは独立して動作します。さらに、`retention.bytes`がゼロに設定されている場合、新しいセグメントのローリングが開始されます。 |
| retention.ms | この設定は、「削除」保持ポリシーを使用している場合に、古いログセグメントを破棄して空き領域を確保する前に、ログを保持する最大時間を制御します。これは、消費者がデータを読み取るまでの所要時間に関する SLA (サービスレベル契約) を表しています。`-1` に設定する場合、時間制限は適用されません。さらに、`retention.ms` 設定は `segment.ms` および `segment.bytes` 設定とは独立して動作します。さらに、`retention.ms`条件が満たされた場合、新しいセグメントのローリングが開始されます。 |
# Express ブローカーの読み取り専用設定
Amazon MSK は、これらの設定の値を設定し、クラスター の可用性に影響を与える可能性のある変更から保護します。これらの値はクラスター上で実行されている Apache Kafka のバージョンによって異なる場合がありますので、必ずご自身のクラスターの値を確認してください。
次の表は、Express ブローカーの読み取り専用設定を一覧表示します。
| プロパティ | 説明 | Express ブローカー値 |
| --- | --- | --- |
| broker.id | このサーバーのブローカー ID。 | 1、2、3... |
| broker.rack | ブローカーのラック。これは耐障害性のためのラック認識レプリケーション割り当てに使用されます。例: `RACK1`、`us-east-1d` | AZ ID または サブネット ID |
| default.replication.factor | すべてのトピックに対するデフォルトのレプリケーション係数。 | 3 |
| fetch.max.bytes | フェッチリクエストに対して返す最大バイト数。 | Apache Kafka のデフォルト |
| group.max.size | 一つの消費者グループが収容できる消費者の最大数。 | Apache Kafka のデフォルト |
| inter.broker.listener.name | ブローカー間の通信に使用される リスナー の名前。 | REPLICATION\$1SECURE または REPLICATION |
| inter.broker.protocol.version | ブローカー間プロトコルを使用するバージョンを指定します。 | Apache Kafka のデフォルト |
| リスナー | リスナー リスト - リスナー として監視する URIs と リスナー 名のカンマ区切りリスト。advertised.listeners property は設定できますが、listeners プロパティは設定できません。 | MSK 生成された |
| log.message.format.version | ブローカーがログにメッセージを追加するために使用するメッセージ形式バージョンを指定します。 | Apache Kafka のデフォルト |
| min.insync.replicas | プロデューサーが acks を `all` (または `-1`)に設定した場合、`min.insync.replicas` の値は書き込みが成功と見なされるために必要な最小レプリカ数を指定します。この最小値を満たせない場合、プロデューサーは例外(`NotEnoughReplicas` または `NotEnoughReplicasAfterAppend`) を発生させます。 プロデューサーの ack の値を使用して、より高い耐久性の保証を強化できます。acks を「all」に設定します。これにより、大部分のレプリカが書き込みを受け取らない場合、プロデューサーが例外を発生させることができます。 | 2 |
| num.io.threads | サーバーがリクエストの生成に使用するスレッドの数。これには、ディスク I/O が含まれる場合があります (m7g.large, 8)、 (m7g.xlarge, 8)、 (m7g.2xlarge, 16)、 (m7g.4xlarge, 32)、 (m7g.8xlarge, 64)、 (m7g.12xlarge, 96)、 (m7g.16xlarge, 128) | インスタンス タイプに基づきます。=Math.max(8、2 \$1 vCPUs) |
| num.network.threads | サーバーがネットワークからリクエストを受信し、ネットワークにレスポンスを送信するために使用するスレッドの数。 (m7g.large, 8)、 (m7g.xlarge, 8)、 (m7g.2xlarge, 8)、 (m7g.4xlarge, 16)、 (m7g.8xlarge, 32)、 (m7g.12xlarge, 48)、 (m7g.16xlarge, 64) | インスタンス タイプに基づきます。=Math.max(8、vCPUs) |
| replica.fetch.response.max.bytes | フェッチレスポンス全体に対して予想される最大バイト数。レコードはバッチでフェッチされます。また、フェッチの空でない最初のパーティションの最初のレコードバッチがこの値より大きい場合、進行を保証するためにそのレコードバッチが引き続き返されます。これは絶対最大値ではありません。message.max.bytes(ブローカー設定) またはmax.message.bytes (トピック設定) プロパティは、ブローカーが受け入れる最大レコードバッチサイズを指定します。 | Apache Kafka のデフォルト |
| request.timeout.ms | この設定は、クライアントがリクエストの応答を待機する最大時間を制御します。タイムアウトが経過するまでに応答が受信されない場合、クライアントは必要に応じてリクエストを再送信するか、再試行回数が上限に達した場合はリクエストを失敗とする。 | Apache Kafka のデフォルト |
| transaction.state.log.min.isr | トランザクショントピックのオーバーライド min.insync.replicas 設定。 | 2 |
| transaction.state.log.replication.factor | トランザクショントピックのレプリケーション係数。 | Apache Kafka のデフォルト |
| unclean.leader.election.enable | ISR セットに含まれていないレプリカが、最終手段としてリーダーとして機能することを許可します。これによりデータ損失が発生する可能性があります。 | FALSE |
# ブローカー設定オペレーション
Apache Kafka ブローカー設定は静的または動的のどちらか一方です。静的設定を適用するには、ブローカーの再起動が必要です。動的設定を更新するためにブローカーを再起動する必要はありません。設定プロパティと更新モードの詳細については、Apache Kafka Configuration を参照してください。
このトピックでは、カスタム MSK 設定を作成する方法と、それらの設定に対してオペレーションを実行する方法について説明します。MSK 設定を使用してクラスターを作成または更新する方法については、「[Amazon MSK の主な特徴および概念](operations.md)」を参照してください。
**Topics**
+ [設定を作成する](msk-configuration-operations-create.md)
+ [設定の更新](msk-configuration-operations-update.md)
+ [設定を削除](msk-configuration-operations-delete.md)
+ [設定メタデータを取得](msk-configuration-operations-describe.md)
+ [設定変更の詳細を取得する](msk-configuration-operations-describe-revision.md)
+ [現在のリージョンにおけるアカウントの設定一覧](msk-configuration-operations-list.md)
+ [Amazon MSK 設定状態](msk-configuration-states.md)
# 設定を作成する
このプロセスでは、カスタム Amazon MSK 設定を作成する方法と、その設定に対してオペレーションを実行する方法について説明します。
1. 設定する設定プロパティと、それらに割り当てる値を指定するファイルを作成します。次に、設定ファイルの例を示します。
```
auto.create.topics.enable = true
log.roll.ms = 604800000
```
1. 次の AWS CLI コマンドを実行し、*config-file-path* を、前のステップで設定を保存したファイルへのパスに置き換えます。
**注記**
設定に選択する名前は、次の正規表現「^[0-9A-Za-z][0-9A-Za-z-]\$10,\$1\$1」と一致する必要があります。
```
aws kafka create-configuration --name "ExampleConfigurationName" --description "Example configuration description." --kafka-versions "1.1.1" --server-properties fileb://config-file-path
```
このコマンドを実行した後の正常なレスポンスの例を以下に示します。
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"CreationTime": "2019-05-21T19:37:40.626Z",
"LatestRevision": {
"CreationTime": "2019-05-21T19:37:40.626Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "ExampleConfigurationName"
}
```
1. 上記のコマンドは、新しい設定の Amazon リソースネーム (ARN) を返します。この ARN は、他のコマンドでこの設定を参照する必要があるため、保存します。設定の ARN を紛失した場合は、アカウント内のすべての設定をリストして、ARN を再確認することができます。
# 設定の更新
このプロセスでは、カスタム Amazon MSK 設定を更新する方法について説明します。
1. 更新する設定プロパティと、それらに割り当てる値を指定するファイルを作成します。次に、設定ファイルの例を示します。
```
auto.create.topics.enable = true
min.insync.replicas = 2
```
1. 次の AWS CLI コマンドを実行します。*config-file-path* は、前のステップで設定を保存したファイルへのパスに置き換えてください。
*configuration-arn* は、設定の作成時に取得した ARN に置き換えてください。設定の作成時に ARN を保存しなかった場合は、`list-configurations` コマンドを使用して、アカウント内のすべての設定をリストすることができます。目的の設定がレスポンス内のリストに表示されます。設定の ARN もそのリストに表示されます。
```
aws kafka update-configuration --arn configuration-arn --description "Example configuration revision description." --server-properties fileb://config-file-path
```
1. このコマンドを実行した後の正常なレスポンスの例を以下に示します。
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"LatestRevision": {
"CreationTime": "2020-08-27T19:37:40.626Z",
"Description": "Example configuration revision description.",
"Revision": 2
}
}
```
# 設定を削除
次の手順は、クラスターに接続されていない設定を削除する方法を示しています。クラスターに添付されている設定を削除することはできません。
1. この例を実行する際には、*configuration-arn* を、設定の作成時に取得した ARN に置き換えてください。設定の作成時に ARN を保存しなかった場合は、`list-configurations` コマンドを使用して、アカウント内のすべての設定をリストすることができます。目的の設定がレスポンス内のリストに表示されます。設定の ARN もそのリストに表示されます。
```
aws kafka delete-configuration --arn configuration-arn
```
1. このコマンドを実行した後の正常なレスポンスの例を以下に示します。
```
{
"arn": " arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"state": "DELETING"
}
```
# 設定メタデータを取得
次の手順は、Amazon MSK 設定を記述して、設定に関するメタデータを取得する方法を示しています。
1. 次のコマンドは、設定に関するメタデータを返します。設定の詳細な説明を取得するには、`describe-configuration-revision` を実行します。
この例を実行する際には、*configuration-arn* を、設定の作成時に取得した ARN に置き換えてください。設定の作成時に ARN を保存しなかった場合は、`list-configurations` コマンドを使用して、アカウント内のすべての設定をリストすることができます。目的の設定がレスポンス内のリストに表示されます。設定の ARN もそのリストに表示されます。
```
aws kafka describe-configuration --arn configuration-arn
```
1. このコマンドを実行した後の正常なレスポンスの例を以下に示します。
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-abcd-1234-abcd-abcd123e8e8e-1",
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"KafkaVersions": [
"1.1.1"
],
"LatestRevision": {
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "SomeTest"
}
```
# 設定変更の詳細を取得する
このプロセスでは、Amazon MSK 設定リビジョンの詳細な説明を示します。
`describe-configuration` コマンドを使用して MSK 設定を記述すると、設定のメタデータが表示されます。設定の詳細な記述を取得するには、`describe-configuration-revision` コマンドを使用します。
+ 次のコマンドを実行します。*configuration-arn* は、設定の作成時に取得した ARN に置き換えてください。設定の作成時に ARN を保存しなかった場合は、`list-configurations` コマンドを使用して、アカウント内のすべての設定をリストすることができます。目的の設定がレスポンス内のリストに表示されます。設定の ARN もそのリストに表示されます。
```
aws kafka describe-configuration-revision --arn configuration-arn --revision 1
```
このコマンドを実行した後の正常なレスポンスの例を以下に示します。
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-abcd-1234-abcd-abcd123e8e8e-1",
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"Revision": 1,
"ServerProperties": "YXV0by5jcmVhdGUudG9waWNzLmVuYWJsZSA9IHRydWUKCgp6b29rZWVwZXIuY29ubmVjdGlvbi50aW1lb3V0Lm1zID0gMTAwMAoKCmxvZy5yb2xsLm1zID0gNjA0ODAwMDAw"
}
```
`ServerProperties` の値は base64 でエンコードされます。base64 デコーダー (https://www.base64decode.org/ など) を使用して手動でデコードする場合は、カスタム設定の作成に使用した元の設定ファイルの内容を取得します。この場合、次のようになります。
```
auto.create.topics.enable = true
log.roll.ms = 604800000
```
# 現在のリージョンにおけるアカウントの設定一覧
このプロセスでは、現在の AWS リージョンのアカウント内のすべての Amazon MSK 設定を一覧表示する方法について説明します。
+ 以下のコマンドを実行してください。
```
aws kafka list-configurations
```
このコマンドを実行した後の正常なレスポンスの例を以下に示します。
```
{
"Configurations": [
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-abcd-1234-abcd-abcd123e8e8e-1",
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"KafkaVersions": [
"1.1.1"
],
"LatestRevision": {
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "SomeTest"
},
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"CreationTime": "2019-05-03T23:08:29.446Z",
"Description": "Example configuration description.",
"KafkaVersions": [
"1.1.1"
],
"LatestRevision": {
"CreationTime": "2019-05-03T23:08:29.446Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "ExampleConfigurationName"
}
]
}
```
# Amazon MSK 設定状態
Amazon MSK 設定は、次のいずれかの状態になります。設定に対してオペレーションを実行するには、設定が `ACTIVE` または `DELETE_FAILED` 状態である必要があります。
+ `ACTIVE`
+ `DELETING`
+ `DELETE_FAILED`
# クラスターのインテリジェントリバランシング
Amazon MSK は、Express ブローカーを使用するすべての新しい MSK プロビジョンドクラスターにインテリジェントな再調整を提供します。この機能は、パーティション分散とクラスタースケーリングオペレーションを自動的に管理するため、サードパーティー製ツールは必要ありません。インテリジェントリバランシングは、クラスターをスケールアップまたはスケールダウンするときにパーティションを自動的に再調整します。また、リソースの不均衡や過負荷がないかクラスターの状態を継続的にモニタリングし、ワークロードを再分散します。
インテリジェントリバランシングは、30 分以内に完了し、スケーリング中のクラスターの可用性に影響を与えない高速スケーリングオペレーションを提供します。すべての新しい MSK Express ベースのプロビジョンドクラスターでデフォルトで有効になっており、推奨される最大パーティション制限であるブローカーあたり 20,000 パーティションで動作します。さらに、この機能は追加料金なしで使用でき、設定は必要ありません。
2025 年 11 月 20 日以降、Amazon MSK Express ブローカーがサポートされているすべての AWS リージョンでインテリジェントリバランシングを利用できます。
**Topics**
+ [インテリジェントな再調整の仕組み](#how-intelligent-rebalancing-works)
+ [インテリジェントな再調整メトリクスのモニタリング](#intelligent-rebalancing-metrics)
+ [インテリジェントな再調整を使用する際の考慮事項](#intelligent-rebalancing-considerations)
+ [1 回のオペレーションで Amazon MSK クラスターをスケールアップ/ダウンする](intelligent-rebalancing-scaling-clusters.md)
+ [Amazon MSK クラスターの定常状態の再調整](intelligent-rebalancing-self-balancing-paritions.md)
## インテリジェントな再調整の仕組み
Express ブローカーを使用するすべての新しい MSK プロビジョンドクラスターでは、インテリジェントリバランシングがデフォルトで有効になっています。これには、以下の状況のサポートが含まれます。
+ **スケールアップとスケールダウン**: ワンクリックで MSK Express ベースのクラスターにブローカーを追加または削除できます。追加または削除するブローカーを指定すると、インテリジェントリバランシングは、内部の AWS ベストプラクティスに基づいて、新しいクラスター設定全体にパーティションを自動的に再分散します。
+ **定常状態の再調整**: 定常状態では、この機能はクラスターの状態を継続的にモニタリングし、次の場合にパーティションを自動的に再調整します。
+ リソース使用率はブローカー間で偏ります。
+ ブローカーが過剰にプロビジョニングされているか、十分に活用されていない。
+ 新しいブローカーが追加されるか、既存のブローカーが削除されます。
**注記**
インテリジェントリバランシングが有効になっている場合、Cruise Control などのサードパーティーツールを使用してパーティションの再バランシングを行うことはできません。これらのサードパーティーツールが提供するパーティション再割り当て API を使用するには、まずインテリジェントな再調整を一時停止する必要があります。
この機能は Amazon MSK コンソールで使用できます。この機能は、 AWS CLI、Amazon MSK APIsまたは AWS SDK、および を使用しても使用できます AWS CloudFormation。詳細については、「[Amazon MSK クラスターのスケーリング](intelligent-rebalancing-scaling-clusters.md)」および「[定常状態の再調整](intelligent-rebalancing-self-balancing-paritions.md)」を参照してください。
## インテリジェントな再調整メトリクスのモニタリング
次の Amazon CloudWatch メトリクスを使用して、進行中および過去のインテリジェントな再調整オペレーションのステータスをモニタリングできます。
+ `RebalanceInProgress`: このメトリクスは、再調整が進行中の場合は 1、それ以外の場合は 0 の値で 1 分ごとに発行されます。
+ `UnderProvisioned`: クラスターが現在プロビジョニング中で、パーティションの再調整を実行できないことを示します。ブローカーを追加するか、クラスターのインスタンスタイプをスケールアップする必要があります。
MSK プロビジョンドクラスターのモニタリングについては、[](monitoring.md)「」および「」を参照してください[](cloudwatch-metrics.md)。
## インテリジェントな再調整を使用する際の考慮事項
+ インテリジェントリバランシングのサポートは、Express ブローカーを使用する新しい MSK プロビジョンドクラスターでのみ使用できます。
+ 自動パーティション再割り当ての場合、ブローカーあたり最大 20,000 個のパーティションの最大サポートを利用できます。
+ インテリジェント再調整が有効になっている場合、パーティション再割り当て APIs またはサードパーティーの再調整ツールを使用することはできません。このような APIs またはサードパーティーツールを使用するには、まず MSK Express ベースのクラスターのインテリジェントな再調整を一時停止する必要があります。
# 1 回のオペレーションで Amazon MSK クラスターをスケールアップ/ダウンする
インテリジェントなリバランシングを使用すると、クラスター内のブローカー数を 1 つのアクションで編集することで、クラスターをスケールアップまたはスケールダウンできます。これは、Amazon MSK コンソール、または AWS CLI Amazon MSK APIs または AWS SDK、および を使用して実行できます AWS CloudFormation。ブローカー数を変更すると、Amazon MSK は以下を実行します。
+ パーティションを新しいブローカーに自動的に配布します。
+ 削除されるブローカーからパーティションを移動します。
クラスターをスケールアップおよびスケールダウンしても、クライアントがデータを生成および消費するためのクラスターの可用性は影響を受けません。
**Topics**
------
#### [ Scaling clusters using AWS マネジメントコンソール ]
1. [https://console.aws.amazon.com/msk/home?region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/) で Amazon MSK コンソールを開きます。
1. **クラスター**ページで、新しく作成した Express ベースのクラスターを選択します。プロビジョニングされた Express ベースのクラスターの作成については、「」を参照してください[ステップ 1: MSK プロビジョニングされたクラスターを作成する](create-cluster.md)。
1. Actions ****ドロップダウンリストで、**ブローカー数の編集**を選択します。
1. **ゾーンあたりのブローカー数の編集**ページで、次のいずれかを実行します。
+ クラスターにブローカーを追加するには、**各アベイラビリティーゾーンにブローカーを追加**を選択し、追加するブローカーの数を入力します。
+ クラスターからブローカーを削除するには、**各アベイラビリティーゾーンからブローカーを 1 **つ削除する を選択します。
1. **[Save changes]** (変更の保存) をクリックします。
------
#### [ Scaling clusters using AWS CLI ]
ブローカー数を編集することで、クラスターをスケールアップまたはスケールダウンできます。でこれを行うには AWS CLI、次の例に示すように update[update-broker-count](https://docs.aws.amazon.com/cli/latest/reference/kafka/update-broker-count.html) コマンドを使用します。このコマンドでは、 `target-broker-count`パラメータでクラスターに必要なブローカーの数を指定します。
```
aws msk update-broker-count --cluster-arn arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1 --current-version ABCDEF1GHIJK0L --target-broker-count 6
```
------
#### [ Scaling clusters using AWS SDK ]
ブローカー数をプログラムで編集することで、クラスターをスケールアップまたはスケールダウンできます。 AWS SDK を使用してこれを行うには、次の例に示すように [UpdateBrokerCount](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-nodes-count.html#UpdateBrokerCount) API を使用します。`TargetNumberOfBrokerNodes` パラメータには、クラスターに必要なブローカーの数を指定します。
```
update_broker_count_response = client.update_broker_count(
ClusterArn='arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1',
CurrentVersion='ABCDEF1GHIJK0L',
TargetNumberOfBrokerNodes=6
)
```
------
# Amazon MSK クラスターの定常状態の再調整
定常状態の再調整はインテリジェントな再調整機能の一部であり、Express ブローカーを使用するすべての新しい MSK プロビジョンドクラスターでデフォルトで有効になっています。クラスターをスケールアップまたはスケールダウンすると、Amazon MSK は新しいブローカーにパーティションを配布し、削除のためにブローカーからパーティションを移動することで、パーティション管理を自動的に処理します。ブローカー間でワークロードを最適に分散するために、インテリジェントな再調整では Amazon MSK のベストプラクティスを使用して、ブローカーの再調整を自動的に開始するためのしきい値を決定します。
必要に応じて、定常状態の再調整を一時停止および再開できます。定常状態の再調整は、クラスターを継続的にモニタリングし、以下を実行します。
+ ブローカーリソースの使用状況 (CPU、ネットワーク、ストレージ) を追跡します。
+ データの可用性に影響を与えることなく、パーティションの配置を自動的に調整します。
+ Express ブローカーの再調整オペレーションは、スタンダードブローカーと比較して最大 180 倍速く完了します。
+ クラスターのパフォーマンスを維持します。
**Topics**
------
#### [ Pause and resume steady state rebalancing in AWS マネジメントコンソール ]
1. [https://console.aws.amazon.com/msk/home?region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/) で Amazon MSK コンソールを開きます。
1. **クラスター**ページで、Express ベースのクラスターを選択します。プロビジョニングされた Express ベースのクラスターの作成については、「」を参照してください[ステップ 1: MSK プロビジョニングされたクラスターを作成する](create-cluster.md)。
1. クラスターの詳細ページで、**インテリジェント再調整**ステータスが**アクティブ**であることを確認します。インテリジェントリバランシングが利用できない場合、またはステータスが**一時停止**の場合は、新しい Express ベースのクラスターを作成します。
1. Actions ****ドロップダウンリストで、**「インテリジェントリバランシングの編集**」を選択します。
1. **インテリジェントリバランシングの編集**ページで、次の操作を行います。
1. **一時停止** を選択します。
1. **[Save changes]** (変更の保存) をクリックします。
------
#### [ Pause and resume steady state rebalancing using AWS CLI ]
**ACTIVE** を使用してクラスターの再調整ステータスを に設定するには AWS CLI、次の例に示すように、[update-rebalancing](https://docs.aws.amazon.com/cli/latest/reference/kafka/update-rebalancing.html) コマンドを使用します。このコマンドでは、 `rebalancing`パラメータを使用してステータスを指定します。
```
aws msk update-rebalancing --cluster-arn arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1 --current-version ABCDEF1GHIJK0L --rebalancing "{\"Rebalancing\":{\"Status\":\"ACTIVE\"}}"
```
------
#### [ Pause and resume steady state rebalancing using AWS SDK ]
[UpdateRebalancingRequest](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-rebalancing.html#UpdateRebalancing) API を使用してクラスターの再調整ステータスを設定して、ブローカー数をプログラムで変更することもできます。次の例は、再調整ステータスを **ACTIVE**および に設定する方法を示しています**PAUSED**。
```
final UpdateRebalancingRequest updateRebalancingRequest = new UpdateRebalancingRequest()
.withClusterArn(arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1)
.withCurrentVersion(ABCDEF1GHIJK0L)
.withRebalancing(new Rebalancing().withStatus("ACTIVE"));
```
```
final UpdateRebalancingRequest updateRebalancingRequest = new UpdateRebalancingRequest()
.withClusterArn(arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1)
.withCurrentVersion(ABCDEF1GHIJK0L)
.withRebalancing(new Rebalancing().withStatus("PAUSED"));
```
------
# MSK プロビジョンド クラスターへのパッチ適用
Amazon MSK は、定期的に クラスター 内のブローカーのソフトウェアを更新します。メンテナンスには、計画的な更新または計画外の修復が含まれます。計画メンテナンスには、クラスター の健全性、セキュリティ、およびパフォーマンスを維持するために必要なオペレーティングシステムの更新、セキュリティ更新、その他のソフトウェア更新が含まれます。予期せぬインフラの劣化を解決するため、計画外のメンテナンスを実施します。標準 ブローカーと Express ブローカーでメンテナンスを実行しますが、その体験は異なります。
## 標準ブローカーへのパッチ適用
[ベストプラクティス](bestpractices.md) に従っている場合、標準ブローカーの更新はアプリケーションの書き込みおよび読み取り操作に影響を与えません。
Amazon MSK では、ソフトウェアのローリング更新を使用してクラスターの高可用性を維持します。このプロセス中、ブローカーは一度に 1 つずつ再起動され、Kafka により自動的にリーダーシップが別のオンラインブローカーに移行されます。または AWS マネジメントコンソール および `ListClusterOperations` APIs を使用してクラスターオペレーションを表示する`DescribeClusterOperation`と、これらのメンテナンスオペレーションはオペレーションタイプ で表示されます`SECURITY_PATCHING`。Kafka クライアントには、パーティションのリーダーシップの変更を自動的に検出し、MSK クラスターへのデータの書き込みと読み取りを継続するメカニズムが組み込まれています。パッチ適用中を含め、クラスターを常に円滑に動作させるには[Apache Kafka クライアントのためのベストプラクティス](bestpractices-kafka-client.md)に従ってください。
ブローカーがオフラインになった後、クライアントで一時的な切断エラーが表示されるのは正常です。また、短い期間 (最大 2 分、通常これより短い) で p99 の読み取りおよび書き込みレイテンシー (通常高いミリ秒、最大約 2 秒) の急増が見られます。これらの急増は予想され、クライアントが新しいリーダーブローカーに再接続することによって引き起こされます。また、生成や消費には影響せず、再接続後に解決されます。詳細については、「[ブローカーのオフラインおよびクライアントフェイルオーバー](https://docs.aws.amazon.com/msk/latest/developerguide/troubleshooting-offlinebroker-clientfailover.html)」を参照してください。
また、シャットダウンされたブローカーのパーティションがデータを複製しなくなったため、メトリクス `UnderReplicatedPartitions` の増加も見られます。これは、他のブローカーでホストされているこれらのパーティションのレプリカとしてのアプリケーションの書き込みと読み取りには影響しません。これらのブローカーは現在、リクエストを提供しています。
ソフトウェアの更新後、ブローカーがオンラインに戻ったら、オフライン中に生成されたメッセージを「キャッチアップ」する必要があります。キャッチアップ中に、ボリュームスループットと CPU の使用率の増加も見られる場合もあります。ブローカーに十分な CPU、メモリ、ネットワーク、ボリュームリソースがある場合、これらはクラスターへの書き込みと読み取りには影響しません。
## Express ブローカーのパッチ適用
Express ブローカーにメンテナンスウィンドウはありません。Amazon MSK は、継続的に時間配分されたタイミングでクラスターを自動的に更新します、これにより、月内に単発のブローカー再起動が時折発生することが予想されます。これにより、クラスタ全体の定期メンテナンス期間に合わせて計画や調整を行う必要がなくなります。同様に、リクエストを処理する他のブローカーにリーダーシップが変わるため、ブローカーの再起動中もトラフィックは中断されません。ブローカーの再起動中も、リーダーシップが他のブローカーに移行し、リクエスト処理を継続するため、トラフィックは、常に中断することはありません。または AWS マネジメントコンソール および `ListClusterOperations` APIs を使用してクラスターオペレーションを表示する`DescribeClusterOperation`と、これらのメンテナンスオペレーションはオペレーションタイプ で表示されます`BROKER_UPDATE`。
Express ブローカーは、ベストプラクティスの設定と ガードレール が事前に設定されており、メンテナンス中に発生する可能性のある負荷変化に対して クラスター の耐性を高めます。Amazon MSK は、ブローカーの再起動時に問題を引き起こす可能性のある クラスター の過負荷の影響を軽減するため、Express ブローカーの スループット クォータを設定します。これらの改善により、Express ブローカーを使用する際の事前通知、計画、およびメンテナンスウィンドウが不要になります。
Express ブローカーは常にデータを 3 重に複製するため、クライアントは再起動時に自動的にフェイルオーバーします。レプリケーション係数が 1 または 2 に設定されていても、トピックが使用できなくなるような心配はありません。また、再起動後の Express ブローカーは、標準ブローカーに比べてキャッチアップが高速です。Express ブローカーにおける高速パッチ適用により、 クラスター にスケジュールした コントロールプレーン アクティビティの計画的な中断を最小限に抑えることができます。
すべての Apache Kafka アプリケーションと同様に、Express ブローカーに接続するクライアントには、依然として共有クライアント-サーバー契約が存在します。ブローカー間のリーダーシップフェイルオーバーを処理できるようクライアントを設定することは、依然として極めて重要です。クラスターを常に[Apache Kafka クライアントのためのベストプラクティス](bestpractices-kafka-client.md)円滑に操作するため、パッチ適用時を含め、以下の手順に従ってください。ブローカーの再起動後、[クライアント側で一時的な切断エラー](troubleshooting-offlinebroker-clientfailover.md)が発生するのは正常な動作です。これにより、フォロワーブローカーがパーティションのリーダーシップを引き継ぐため、生産と消費には影響しません。Apache Kafka クライアントは自動的にフェイルオーバーし、新しいリーダーブローカーへのリクエストの送信を開始します。
# ブローカーのオフラインおよびクライアントフェイルオーバー
Kafka はオフラインブローカーを許可します。ベストプラクティスに従う健全でバランスの取れたクラスター内の単一のオフラインブローカーについては、生成や消費の際に影響を及ぼしたり失敗の原因になることはありません。これは、別のブローカーがパーティションのリーダーシップを引き継ぎ、Kafka クライアントライブラリが自動的にフェイルオーバーして新しいリーダーブローカーへのリクエストの送信が開始されるためです。
**クライアントサーバー契約**
これにより、クライアントライブラリとサーバー側の動作での共有契約になります。サーバーでは 1 つ以上の新しいリーダーを正常に割り当て、クライアントではブローカーを変更して新しいリーダーへタイムリーにリクエストを送信する必要があります。
Kafka では、例外を使用してこのフローを制御します。
**手順の例**
1. ブローカー A がオフライン状態になります。
1. Kafka クライアントで例外 (通常はネットワーク切断または not\$1leader\$1for\$1partition) を受け取ります。
1. これらの例外により、Kafka クライアントによるメタデータの更新がトリガーされ、最新のリーダーについて知ることができます。
1. Kafka クライアントにより、他のブローカーの新しいパーティションリーダーへのリクエストの送信が再開されます。
通常、このプロセスにかかるのは Java の拡張クライアントとデフォルト設定では 2 秒未満です。クライアント側のエラーは詳細で反復的ですが、「WARN」のレベルで示されているように、懸念が引き起こされることはありません。
**例: 例外 1**
`10:05:25.306 [kafka-producer-network-thread | producer-1] WARN o.a.k.c.producer.internals.Sender - [Producer clientId=producer-1] Got error produce response with correlation id 864845 on topic-partition msk-test-topic-1-0, retrying (2147483646 attempts left). Error: NETWORK_EXCEPTION. Error Message: Disconnected from node 2`
**例: 例外 2**
`10:05:25.306 [kafka-producer-network-thread | producer-1] WARN o.a.k.c.producer.internals.Sender - [Producer clientId=producer-1] Received invalid metadata error in produce request on partition msk-test-topic-1-41 due to org.apache.kafka.common.errors.NotLeaderOrFollowerException: For requests intended only for the leader, this error indicates that the broker is not the current leader. For requests intended for any replica, this error indicates that the broker is not a replica of the topic partition.. Going to request metadata update now"`
Kafka クライアントでは、通常 1 秒以内、最大 3 秒でこれらのエラーが自動的に解決されます。これは、クライアント側のメトリクスで p99 の生成および消費レイテンシー(通常 100 ミリ秒台の高いミリ秒) として表示されます。これより長い場合は通常、クライアント設定またはサーバー側のコントローラーで負荷の問題が発生しています。トラブルシューティングのセクションを参照してください。
他のブローカーでの `BytesInPerSec` および `LeaderCount` メトリクスの増加を確認することで、フェイルオーバーが成功したことを確認できます。これにより、トラフィックとリーダーシップが期待どおりに移動されたことが証明されます。また、`UnderReplicatedPartitions` メトリクスの増加も確認できます。これは、レプリカがシャットダウンブローカーでオフラインになっているときに予想されます。
**トラブルシューティング**
上記のフローは、クライアントとサーバーの契約を破棄することで中断される可能性があります。最も一般的な問題の原因は次のとおりです。
+ Kafka クライアントライブラリの設定ミスまたは誤った使用。
+ サードパーティーのクライアントライブラリによる予期しないデフォルトの動作とバグ。
+ コントローラーが過負荷になることによる、パーティションリーダーの割り当ての遅延。
+ 新しいコントローラーが選択されることによる、パーティションリーダーの割り当ての遅延。
リーダーシップのフェイルオーバーを処理する際に正しい動作が確実に行われるようにするため、以下をお勧めします。
+ コントローラーのブローカーが適切にスケーリングされ、リーダーシップの割り当てが遅くならないように、サーバー側の[ベストプラクティス](https://docs.aws.amazon.com/msk/latest/developerguide/bestpractices.html)に従う必要があります。
+ クライアントライブラリでは、クライアントがフェイルオーバーを処理できるように再試行を有効にする必要があります。
+ クライアントライブラリでは、接続/リクエストストームを回避するため、retry.backoff.ms (デフォルトは 100) を設定する必要があります。
+ クライアントライブラリでは、request.timeout.ms と delivery.timeout.ms をアプリケーションの SLA に沿った値に設定する必要があります。値が大きいほど、特定の障害タイプでフェイルオーバーが遅くなります。
+ クライアントライブラリでは、初期検出での可用性への影響を回避するため、bootstrap.servers に少なくとも 3 つのランダムなブローカーが含まれていることを確認する必要があります。
+ 一部のクライアントライブラリは他のライブラリよりもレベルが低く、アプリケーションデベロッパーによる再試行ロジックと例外処理の実装が期待されます。使用例については、クライアントライブラリ固有のドキュメントを参照し、正しい再接続/再試行ロジックに従っていることを確認してください。
+ 生成、成功したリクエスト数、再試行不可能なエラーのエラー数については、クライアント側のレイテンシーをモニタリングすることをお勧めします。
+ ブローカーのオフライン期間中、リクエストの生成や消費に影響がないにもかかわらず、古いサードパーティーの golang ライブラリと ruby ライブラリが冗長モードのままであることがわかりました。リクエストメトリクスに加えて、ビジネスレベルのメトリクスを常にモニタリングし、ログに実際の影響とノイズがあるかどうかを判断することをお勧めします。
+ ネットワーク/not\$1leader の一時的な例外は正常であり、影響はなく kafka プロトコルの一部として想定されるため、警告しないでください。
+ UnderReplicatedPartitions は正常であり、影響はなく単一のオフラインブローカー中に発生することが予想されるため、警戒しないでください。
# Amazon MSK のセキュリティ
でのクラウドセキュリティが最優先事項 AWS です。お客様は AWS 、セキュリティを最も重視する組織の要件を満たすように構築されたデータセンターとネットワークアーキテクチャからメリットを得られます。
セキュリティは、 AWS お客様とお客様の間の責任共有です。[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)ではこれをクラウド*の*セキュリティおよびクラウド*内*のセキュリティと説明しています。
+ **クラウドのセキュリティ** – AWS クラウドで AWS サービスを実行するインフラストラクチャを保護する AWS 責任があります。 AWS また、 では、安全に使用できるサービスも提供しています。サードパーティーの監査者は、[AWS コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)コンプライアンスプログラムの一環として、当社のセキュリティの有効性を定期的にテストおよび検証。Amazon Managed Streaming for Apache Kafka に適用されるコンプライアンス プログラムについては、[コンプライアンスプログラムによる対象範囲内の Amazon Web Services](https://aws.amazon.com/compliance/services-in-scope/)を参照してください。
+ **クラウドのセキュリティ** – お客様の責任は、使用する AWS サービスによって決まります。また、お客様は、お客様のデータの機密性、企業の要件、および適用可能な法律および規制などの他の要因についても責任を担います。
このドキュメントは、Amazon MSK を使用するときに責任共有モデルを適用する方法を理解するのに役立ちます。次のトピックでは、セキュリティとコンプライアンスの目標を達成するために Amazon MSK を設定する方法を示します。また、Amazon MSK リソースのモニタリングと保護に役立つ他の Amazon Web Services の使用方法についても学びます。
**Topics**
+ [Amazon Managed Streaming for Apache Kafka におけるデータ保護](data-protection.md)
+ [Amazon MSK API の認証と認可](security-iam.md)
+ [Apache Kafka API の認証と認可](kafka_apis_iam.md)
+ [Amazon MSK クラスターのセキュリティグループの変更](change-security-group.md)
+ [Amazon MSK クラスター内の Apache ZooKeeper ノードへのアクセスを制御する](zookeeper-security.md)
+ [Amazon Managed Streaming for Apache Kafka のコンプライアンス検証](MSK-compliance.md)
+ [Amazon Managed Streaming for Apache Kafka の復元力](disaster-recovery-resiliency.md)
+ [Amazon Managed Streaming for Apache Kafka におけるインフラストラクチャセキュリティ](infrastructure-security.md)
# Amazon Managed Streaming for Apache Kafka におけるデータ保護
責任 AWS [共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)、Amazon Managed Streaming for Apache Kafka のデータ保護に適用されます。このモデルで説明されているように、 AWS はすべての を実行するグローバルインフラストラクチャを保護する責任があります AWS クラウド。ユーザーは、このインフラストラクチャでホストされるコンテンツに対する管理を維持する責任があります。また、使用する「 AWS のサービス 」のセキュリティ設定と管理タスクもユーザーの責任となります。データプライバシーの詳細については、[データプライバシーに関するよくある質問](https://aws.amazon.com/compliance/data-privacy-faq/)を参照してください。欧州でのデータ保護の詳細については、*AWS セキュリティブログ*に投稿された「[AWS 責任共有モデルおよび GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/)」のブログ記事を参照してください。
データ保護の目的で、認証情報を保護し AWS アカウント 、 AWS IAM アイデンティティセンター または AWS Identity and Access Management (IAM) を使用して個々のユーザーを設定することをお勧めします。この方法により、それぞれのジョブを遂行するために必要な権限のみが各ユーザーに付与されます。また、次の方法でデータを保護することもお勧めします:
+ 各アカウントで多要素認証 (MFA) を使用します。
+ SSL/TLS を使用して AWS リソースと通信します。TLS 1.2 は必須ですが、TLS 1.3 を推奨します。
+ で API とユーザーアクティビティのログ記録を設定します AWS CloudTrail。CloudTrail 証跡を使用して AWS アクティビティをキャプチャする方法については、「 *AWS CloudTrail ユーザーガイド*」の[CloudTrail 証跡の使用](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html)」を参照してください。
+ AWS 暗号化ソリューションと、その中のすべてのデフォルトのセキュリティコントロールを使用します AWS のサービス。
+ Amazon Macie などの高度な管理されたセキュリティサービスを使用します。これらは、Amazon S3 に保存されている機密データの検出と保護を支援します。
+ コマンドラインインターフェイスまたは API AWS を介して にアクセスするときに FIPS 140-3 検証済み暗号化モジュールが必要な場合は、FIPS エンドポイントを使用します。利用可能な FIPS エンドポイントの詳細については、「[連邦情報処理規格 (FIPS) 140-3](https://aws.amazon.com/compliance/fips/)」を参照してください。
お客様の E メールアドレスなどの極秘または機密情報を、タグ、または **[名前]** フィールドなどの自由形式のテキストフィールドに含めないことを強くお勧めします。これは、コンソール、API、または SDK を使用して Amazon MSK AWS CLIまたは他の AWS のサービス を使用する場合も同様です。 AWS SDKs タグ、または名前に使用される自由記述のテキストフィールドに入力したデータは、請求または診断ログに使用される場合があります。外部サーバーに URL を提供する場合、そのサーバーへのリクエストを検証できるように、認証情報を URL に含めないことを強くお勧めします。
**Topics**
+ [Amazon MSK 暗号化](msk-encryption.md)
+ [Amazon MSK 暗号化の使用を開始する](msk-working-with-encryption.md)
+ [インターフェイス VPC エンドポイントで Amazon MSK API を使用する](privatelink-vpc-endpoints.md)
# Amazon MSK 暗号化
Amazon MSK には、厳格なデータ管理要件を満たすために使用できるデータ暗号化オプションが用意されています。Amazon MSK が暗号化に使用する証明書は、13 か月ごとに更新する必要があります。Amazon MSK は、すべてのクラスターに対してこれらの証明書を自動的に更新します。Amazon MSK が証明書の更新操作を開始した際、Express ブローカークラスターは `ACTIVE` の状態のままになります。標準 ブローカー クラスター の場合、 Amazon MSK は、証明書の更新操作を開始する際に、 クラスター の状態を `MAINTENANCE` に設定します。更新が完了すると、 MSK は `ACTIVE` に戻ります。クラスター が証明書の更新操作中の間は、引き続きデータを生成して使用できますが、それに対して更新操作を一切実行できません。
## 保管中の Amazon MSK 暗号化
Amazon MSK は[AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/) (KMS) と統合して、透過的なサーバー側暗号化を提供します。Amazon MSK は、保管中のデータを常に暗号化します。MSK クラスターを作成するときに、Amazon MSK が保管中のデータの暗号化に使用する AWS KMS key を指定できます。KMS キーを指定しない場合、Amazon MSK がユーザーの代わりに [AWS マネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk)を作成し、それを使用します。KMS キーの詳細については、「AWS Key Management Service デベロッパーガイド**」の「[AWS KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys)」を参照してください。
## 転送中の Amazon MSK 暗号化
Amazon MSKは TLS 1.2 を使用します。デフォルトでは、MSK クラスターのブローカー間で転送中のデータを暗号化します。このデフォルトは、クラスターの作成時に上書きできます。
クライアントとブローカー間の通信では、次の 3 つの設定のいずれかを指定する必要があります。
+ TLS 暗号化データのみを許可します。これはデフォルトの設定です。
+ プレーンテキストと TLS 暗号化データの両方を許可します。
+ プレーンテキストのデータのみを許可します。
Amazon MSK ブローカーはパブリック AWS Certificate Manager 証明書を使用します。したがって、Amazon Trust Services を信頼するトラストストアは、Amazon MSK ブローカーの証明書も信頼します。
転送中の暗号化を有効にすることを強くお勧めしますが、CPU オーバーヘッドが増加し、数ミリ秒のレイテンシーが発生する可能性があります。ただし、ほとんどのユースケースはこれらの違いに敏感ではなく、影響の大きさは、クラスター、クライアント、および使用プロファイルの構成によって異なります。
# Amazon MSK 暗号化の使用を開始する
MSK クラスターを作成するときに、JSON 形式で暗号化設定を指定できます。以下に例を示します。
```
{
"EncryptionAtRest": {
"DataVolumeKMSKeyId": "arn:aws:kms:us-east-1:123456789012:key/abcdabcd-1234-abcd-1234-abcd123e8e8e"
},
"EncryptionInTransit": {
"InCluster": true,
"ClientBroker": "TLS"
}
}
```
`DataVolumeKMSKeyId` では、[カスタマーマネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk)か、またはアカウント内の MSK 用の AWS マネージドキー (`alias/aws/kafka`) を指定できます。を指定しない場合`EncryptionAtRest`でも、Amazon MSK は で保管中のデータを暗号化します AWS マネージドキー。クラスターが使用しているキーを判別するには、`GET` リクエストを送信するか `DescribeCluster` API オペレーションを呼び出します。
`EncryptionInTransit` の場合、`InCluster` のデフォルト値は true ですが、Amazon MSK がブローカー間を通過するときにデータを暗号化しないようにする場合は、false に設定できます。
クライアントとブローカー間で転送されるデータの暗号化モードを指定するには、`ClientBroker` を `TLS`、`TLS_PLAINTEXT`、または `PLAINTEXT` のいずれかに設定します。
**Topics**
+ [Amazon MSK クラスターの作成時に暗号化設定を指定する](msk-working-with-encryption-cluster-create.md)
+ [Amazon MSK TLS 暗号化をテストする](msk-working-with-encryption-test-tls.md)
# Amazon MSK クラスターの作成時に暗号化設定を指定する
このプロセスでは、Amazon MSK クラスターの作成時に暗号化設定を指定する方法について説明します。
**クラスターの作成時に暗号化設定を指定する**
1. 前述の例の内容をファイルに保存し、任意の名前を付けます。たとえば、`encryption-settings.json` と呼びます。
1. `create-cluster` コマンドを実行し、`encryption-info` オプションを使用して、設定 JSON ファイルを保存したファイルを指定します。以下に例を示します。*\$1YOUR MSK VERSION\$1* は、Apache Kafka クライアントバージョンと一致するバージョンに置き換えてください。MSK クラスターバージョンの確認方法については、「[MSK クラスターバージョンの確認](create-topic.md#find-msk-cluster-version)」を参照してください。MSK クラスターバージョンと異なる Apache Kafka クライアントバージョンを使用すると、Apache Kafka データの破損、損失、ダウンタイムが発生する可能性があることに注意してください。
```
aws kafka create-cluster --cluster-name "ExampleClusterName" --broker-node-group-info file://brokernodegroupinfo.json --encryption-info file://encryptioninfo.json --kafka-version "{YOUR MSK VERSION}" --number-of-broker-nodes 3
```
次に、このコマンドを実行した後の正常な応答の例を示します。
```
{
"ClusterArn": "arn:aws:kafka:us-east-1:123456789012:cluster/SecondTLSTest/abcdabcd-1234-abcd-1234-abcd123e8e8e",
"ClusterName": "ExampleClusterName",
"State": "CREATING"
}
```
# Amazon MSK TLS 暗号化をテストする
このプロセスでは、Amazon MSK で TLS 暗号化をテストする方法について説明します。
**TLS 暗号化をテストするには**
1. [ステップ 3: クライアントマシンを作成する](create-client-machine.md) のガイダンスに従って、クライアントマシンを作成します。
1. クライアントマシンに Apache Kafka をインストールします。
1. この例では、JVM トラストストアを使用して MSK クラスターと通信します。これを行うには、まずクライアントマシンに `/tmp` という名前のフォルダを作成します。次に、Apache Kafka インストールの `bin` フォルダに移動し、次のコマンドを実行します。 (JVM パスは異なる場合があります)。
```
cp /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.201.b09-0.amzn2.x86_64/jre/lib/security/cacerts /tmp/kafka.client.truststore.jks
```
1. クライアントマシン上の Apache Kafka インストールの `bin` フォルダに、次の内容の `client.properties` というテキストファイルを作成します。
```
security.protocol=SSL
ssl.truststore.location=/tmp/kafka.client.truststore.jks
```
1. AWS CLI がインストールされているマシンで次のコマンドを実行し、*clusterARN* をクラスターの ARN に置き換えます。
```
aws kafka get-bootstrap-brokers --cluster-arn clusterARN
```
正常に実行された場合の結果は次のようになります。次のステップで必要になるため、この結果を保存します。
```
{
"BootstrapBrokerStringTls": "a-1.example.g7oein.c2.kafka.us-east-1.amazonaws.com:0123,a-3.example.g7oein.c2.kafka.us-east-1.amazonaws.com:0123,a-2.example.g7oein.c2.kafka.us-east-1.amazonaws.com:0123"
}
```
1. 次のコマンドを実行します。その際、*BootstrapBrokerStringTls* は、前のステップで取得したブローカーエンドポイントの 1 つに置き換えてください。
```
/bin/kafka-console-producer.sh --broker-list BootstrapBrokerStringTls --producer.config client.properties --topic TLSTestTopic
```
1. 新しいコマンドウィンドウを開き、同じクライアントマシンに接続します。その後、次のコマンドを実行して、コンソールコンシューマーを作成します。
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBrokerStringTls --consumer.config client.properties --topic TLSTestTopic
```
1. プロデューサーウィンドウで、テキストメッセージに続けてリターンを入力し、コンシューマーウィンドウで同じメッセージを探します。Amazon MSK は、このメッセージを転送中に暗号化しました。
暗号化されたデータを操作するように Apache Kafka クライアントを設定する方法の詳細については、「[Kafka クライアントの設定](https://kafka.apache.org/documentation/#security_configclients)」を参照してください。
# インターフェイス VPC エンドポイントで Amazon MSK API を使用する
AWS PrivateLink を搭載したインターフェイス VPC エンドポイントを使用すると、Amazon VPC と Amazon MSK APIs 間のトラフィックが Amazon ネットワークから出るのを防ぐことができます。インターフェイス VPC エンドポイントには、インターネットゲートウェイ、NAT デバイス、VPN 接続、または AWS Direct Connect 接続は必要ありません。[AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) は、Amazon VPC 内のプライベート IPs を持つ Elastic Network Interface を使用して、 AWS サービス間のプライベート通信を可能にする AWS テクノロジーです。詳細については、[Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) and [Interface VPC Endpoints (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint)」を参照してください。
アプリケーションは、 AWS PrivateLink を使用して Amazon MSK プロビジョンド API と MSK Connect APIs に接続できます。開始するには、 Amazon MSK API の インターフェース VPC エンドポイント を作成して、インターフェース VPC エンドポイント を介して Amazon VPC リソース との間で流れる トラフィック を開始します。FIPS 対応の インターフェイス VPC エンドポイント は、米国 リージョン で使用可能です。詳細については、「[ インターフェイス エンドポイント の作成](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint)」を参照してください。
この機能を使用することで、Apache Kafka クライアントは、接続文字列を取得するためにインターネットを経由することなく、Amazon MSK Provisioned または MSK Connect リソースに接続するための接続文字列を動的に取得できます。
インターフェース VPC エンドポイントを作成する際は、以下のサービス名エンドポイントのいずれかを選択してください。
**MSK Provisioned の場合:**
+ 次のサービス名エンドポイントは、新しい接続ではサポートされなくなりました。
+ com.amazonaws.region.kafka
+ com.amazonaws.region.kafka-fips (FIPS 対応)
+ IPv4 トラフィックと IPv6 トラフィックの両方をサポートするデュアルスタックエンドポイントサービスは次のとおりです。
+ aws.api.region.kafka-api
+ aws.api.region.kafka-api-fips (FIPS 対応)
デュアルスタックエンドポイントを設定するには、[デュアルスタックと FIPS エンドポイント](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html)のガイドラインに従う必要があります。
region は、リージョンコードです。MSK プロビジョンド 互換 API を使用するには、このサービス名を選択します。詳細については、*https://docs.aws.amazon.com/msk/1.0/apireference/* の「[オペレーション](https://docs.aws.amazon.com/msk/1.0/apireference/operations.html)」をご参照ください。
**MSK Connect の場合:**
+ com.amazonaws.region.kafkaconnect
region は、リージョンコードです。MSK Connect 互換 API を連携するには、このサービス名を選択します。詳細については、*Amazon MSK Connect API リファレンス*の[「アクション」](https://docs.aws.amazon.com/MSKC/latest/mskc/API_Operations.html)を参照してください。
インターフェイス VPC エンドポイント の作成手順を含む詳細については、*AWS PrivateLink 「ガイド」*の「[インターフェイス エンドポイント の作成](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint)」を参照してください。
## Amazon MSK Provisioned または MSK Connect の API の VPC エンドポイントへのアクセスを制御する
VPC エンドポイントポリシーは、VPC エンドポイントにポリシーをアタッチするか、IAM ユーザー、グループ、またはロールにアタッチされたポリシーの追加フィールドを使用して、アクセスが指定された VPC エンドポイント経由のみで行われるようにアクセスを制限することにより、アクセスを制御します。MSK Provisioned または MSK Connect サービスのいずれかに対するアクセス権限を定義するには、適切なポリシー例を使用してください。
エンドポイントの作成時にポリシーをアタッチしない場合、サービスへのフルアクセスを許可するデフォルトのポリシーが Amazon VPC によって自動的にアタッチされます。エンドポイントポリシーは、IAM アイデンティティベースのポリシーやサービス固有のポリシーを上書きしたり置き換えたりするものではありません。これは、評価項目から指定されたサービスへのアクセスを制御するための別のポリシーです。
詳細については、「*AWS PrivateLink ガイド*」の「[VPC エンドポイントによるサービスのアクセス コントロール](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html)」を参照してください。
------
#### [ MSK Provisioned — VPC policy example ]
**読み取り専用アクセス**
このサンプルポリシーは、VPC エンドポイントにアタッチできます。詳細については、Amazon VPC のリソースに対するアクセスの制御を参照してください。これにより、 アクション は、それが アタッチ されている VPC エンドポイント を介した オペレーション の一覧表示と説明のみに制限されます。
```
{
"Statement": [
{
"Sid": "MSKReadOnly",
"Principal": "*",
"Action": [
"kafka:List*",
"kafka:Describe*"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
**MSK Provisioned — VPC エンドポイントポリシーの例**
特定の MSK クラスターへのアクセスを制限する
このサンプルポリシーは、VPC エンドポイントにアタッチできます。これにより、アタッチされている VPC エンドポイントを介して特定の Kafka クラスターへのアクセスを制限されます。
```
{
"Statement": [
{
"Sid": "AccessToSpecificCluster",
"Principal": "*",
"Action": "kafka:*",
"Effect": "Allow",
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/MyCluster"
}
]
}
```
------
#### [ MSK Connect — VPC endpoint policy example ]
**コネクタを一覧表示し、新しいコネクタを作成する**
以下は、MSK Connect のエンドポイント ポリシーの例です。このポリシーにより、指定されたロールはコネクタを一覧表示し、新規コネクタを作成できます。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "MSKConnectPermissions",
"Effect": "Allow",
"Action": [
"kafkaconnect:ListConnectors",
"kafkaconnect:CreateConnector"
],
"Resource": "*",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/MyMSKConnectExecutionRole"
]
}
}
]
}
```
**MSK Connect — VPC エンドポイント ポリシーの例**
指定された VPC 内の特定の IP アドレスからのリクエストのみを許可する
次の例は、指定した VPC 内の指定した IP アドレスから送信されたリクエストのみが成功するように許可するポリシーを示しています。他の IP アドレスからのリクエストは失敗します。
```
{
"Statement": [
{
"Action": "kafkaconnect:*",
"Effect": "Allow",
"Principal": "*",
"Resource": "*",
"Condition": {
"IpAddress": {
"aws:VpcSourceIp": "192.0.2.123"
},
"StringEquals": {
"aws:SourceVpc": "vpc-555555555555"
}
}
}
]
}
```
------
# Amazon MSK API の認証と認可
AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全に制御 AWS のサービス するのに役立つ です。IAM 管理者は、Amazon MSK リソースを使用するための*認証* (サインイン) および*承認* (許可を持つ) できるユーザーを制御します。IAM は、追加料金なしで使用できる AWS のサービス です。
**Topics**
+ [Amazon MSK と IAM の連携の仕組み](security_iam_service-with-iam.md)
+ [Amazon MSK の ID ベースのポリシーの例](security_iam_id-based-policy-examples.md)
+ [Amazon MSK のサービスリンクロール](using-service-linked-roles.md)
+ [AWS Amazon MSK の マネージドポリシー](security-iam-awsmanpol.md)
+ [Amazon MSK の ID およびアクセスのトラブルシューティング](security_iam_troubleshoot.md)
# Amazon MSK と IAM の連携の仕組み
IAM を使用して Amazon MSK へのアクセスを管理する前に、Amazon MSK で使用できる IAM の機能を理解する必要があります。Amazon MSK およびその他の AWS のサービスが IAM と連携する方法の概要を把握するには、IAM *ユーザーガイド*の[AWS 「IAM と連携する のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。
**Topics**
+ [Amazon MSK の ID ベースのポリシー](security_iam_service-with-iam-id-based-policies.md)
+ [Amazon MSK のリソースベースのポリシー](security_iam_service-with-iam-resource-based-policies.md)
+ [Amazon MSK タグに基づく認可](security_iam_service-with-iam-tags.md)
+ [Amazon MSK IAM ロール](security_iam_service-with-iam-roles.md)
# Amazon MSK の ID ベースのポリシー
IAM アイデンティティベースポリシーでは、許可または拒否するアクションとリソース、またアクションを許可または拒否する条件を指定できます。Amazon MSK は、特定のアクション、リソース、および条件キーをサポートします。JSON ポリシーで使用するすべての要素については、「*IAM ユーザーガイド*」の「[IAM JSON ポリシーの要素のリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)」を参照してください。
## Amazon MSK の ID ベースのポリシーのアクション
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。
JSON ポリシーの `Action` 要素にはポリシー内のアクセスを許可または拒否するために使用できるアクションが記述されます。このアクションは関連付けられたオペレーションを実行するためのアクセス許可を付与するポリシーで使用されます。
Amazon MSK のポリシーアクションは、アクションの前に次のプレフィックスを使用します : `kafka:`。例えば、Amazon MSK `DescribeCluster` API オペレーションを使用して MSK クラスターを記述する許可を誰かに付与するには、ポリシーに `kafka:DescribeCluster` アクションを含めます。ポリシーステートメントには`Action` または `NotAction` 要素を含める必要があります。Amazon MSK は、このサービスで実行できるタスクを記述する独自の一連のアクションを定義します。
MSK トピック APIs「」を参照してください[IAM 認可ポリシーアクションとリソースのセマンティクス](kafka-actions.md)。 `kafka-cluster`
単一のステートメントに複数のアクションを指定するには次のようにコンマで区切ります。
```
"Action": ["kafka:action1", "kafka:action2"]
```
ワイルドカード (\$1) を使用して複数アクションを指定できます。例えば、`Describe` という単語で始まるすべてのアクションを指定するには、次のアクションを含めます。
```
"Action": "kafka:Describe*"
```
Amazon MSK アクションのリストを表示するには、「*IAM ユーザーガイド*」の「[Amazon Managed Streaming for Apache Kafka のアクション、リソース、および条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonmanagedstreamingforapachekafka.html)」を参照してください。
## Amazon MSK ID ベースのポリシーのリソース
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件**下で**アクション**を実行できるかということです。
`Resource` JSON ポリシー要素はアクションが適用されるオブジェクトを指定します。ベストプラクティスとして、[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) を使用してリソースを指定します。リソースレベルのアクセス許可をサポートしないアクションの場合は、ステートメントがすべてのリソースに適用されることを示すために、ワイルドカード (\$1) を使用します。
```
"Resource": "*"
```
Amazon MSK インスタンスリソースには次の ARN があります。
```
arn:${Partition}:kafka:${Region}:${Account}:cluster/${ClusterName}/${UUID}
```
ARN の形式の詳細については、[「Amazon リソースネーム (ARNs AWS 「サービス名前空間](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html)」を参照してください。
例えば、ステートメントで `CustomerMessages` インスタンスを指定するには、次の ARN を使用します。
```
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/CustomerMessages/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2"
```
特定のアカウントに属するすべてのインスタンスを指定するには、ワイルドカード (\$1) を使用します。
```
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/*"
```
リソースを作成するためのアクションなど、一部の Amazon MSK アクションは、特定のリソースで実行できません。このような場合は、ワイルドカード (\$1) を使用する必要があります。
```
"Resource": "*"
```
複数リソースを単一ステートメントで指定するには、ARN をカンマで区切ります。
```
"Resource": ["resource1", "resource2"]
```
Amazon MSK リソースタイプとその ARN のリストを表示するには、「*IAM ユーザーガイド*」の「[Amazon Managed Streaming for Apache Kafka によって定義されたリソース](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-resources-for-iam-policies)」を参照してください。各リソースの ARN を指定できるアクションについては、「[Amazon Managed Streaming for Apache Kafka によって定義されるアクション](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-actions-as-permissions)」を参照してください。
## Amazon MSK ID ベースのポリシーの条件キー
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。
`Condition` 要素は、定義された基準に基づいてステートメントが実行される時期を指定します。イコールや未満などの[条件演算子](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html)を使用して条件式を作成して、ポリシーの条件とリクエスト内の値を一致させることができます。すべての AWS グローバル条件キーを確認するには、*「IAM ユーザーガイド*」の[AWS 「グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)」を参照してください。
Amazon MSK は、独自の条件キーのセットを定義し、いくつかのグローバル条件キーの使用もサポートしています。すべての AWS グローバル条件キーを確認するには、*IAM ユーザーガイド*の[AWS 「グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)」を参照してください。
Amazon MSK 条件キーのリストを表示するには、*IAM ユーザーガイド*の[Amazon Managed Streaming for Apache Kafka の条件キー](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-policy-keys)を参照してください。条件キーを使用できるアクションとリソースについては、[Amazon Managed Streaming for Apache Kafka によって定義されたアクション](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-actions-as-permissions)を参照してください。
## Amazon MSK ID ベースのポリシーの例
Amazon MSK アイデンティティベースのポリシーの例を表示するには、[Amazon MSK の ID ベースのポリシーの例](security_iam_id-based-policy-examples.md) を参照してください。
# Amazon MSK のリソースベースのポリシー
Amazon MSK は、Amazon MSK クラスターで使用するクラスターポリシー (リソースベースのポリシーとも呼ばれます) をサポートしています。クラスターポリシーを使用して、Amazon MSK クラスターへのプライベート接続を設定するためのクロスアカウントのアクセス許可を付与する IAM プリンシパルを定義できます。IAM クライアント認証と併用すると、クラスターポリシーを使用して、接続クライアントの Kafka データプレーンのアクセス許可を細かく定義することもできます。
クラスターポリシーでサポートされる最大サイズは 20 KB です。
クラスターポリシーの設定方法の例については、「[ステップ 2: クラスターポリシーを MSK クラスターにアタッチする](mvpc-cluster-owner-action-policy.md)」を参照してください。
# Amazon MSK タグに基づく認可
Amazon MSK クラスターにタグをアタッチすることができます。タグに基づいてアクセスを管理するには、`kafka:ResourceTag/key-name`、`aws:RequestTag/key-name`、または `aws:TagKeys` の条件キーを使用して、ポリシーの[条件要素](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)でタグ情報を提供します。Amazon MSK リソースのタグ付けに関する情報は、「[Amazon MSK クラスターをタグ付ける](msk-tagging.md)」を参照してください。
タグを使用することでのみ、クラスターへのアクセスを制御できます。トピックやコンシューマーグループにタグを付けるには、ポリシーにタグなしの個別の記述を追加する必要があります。
クラスターのタグに基づいてクラスターへのアクセスを制限するためのアイデンティティベースのポリシーの例を表示するには、「[タグに基づく Amazon MSK クラスターへのアクセス](security_iam_id-based-policy-examples-view-widget-tags.md)」を参照してください。
アイデンティティベースのポリシーの条件を使用して、タグに基づいて Amazon MSK リソースへのアクセスを制御できます。この例では、クラスターの説明、ブートストラップブローカーの取得、ブローカーノードの一覧表示、更新、削除をユーザーに許可するポリシーの作成方法を示しています。ただし、このポリシーはクラスタータグ`Owner`の値がそのユーザー`username`の値である場合にのみ許可を付与されます。次のポリシーの 2 番目の記述では、クラスター上のトピックへのアクセスを許可します。本ポリシーの最初の記述では、いかなるトピックへのアクセスも許可されていません。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AccessClusterIfOwner",
"Effect": "Allow",
"Action": [
"kafka:Describe*",
"kafka:Get*",
"kafka:List*",
"kafka:Update*",
"kafka:Delete*"
],
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Owner": "${aws:username}"
}
}
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:*Topic*",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:topic/*"
]
}
]
}
```
------
# Amazon MSK IAM ロール
[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)は、特定のアクセス許可を持つ、Amazon Web Services アカウント内のエンティティです。
## Amazon MSK での一時的な認証情報の使用
一時的な認証情報を使用して、フェデレーションでサインインする、IAM 役割を引き受ける、またはクロスアカウント役割を引き受けることができます。一時的なセキュリティ認証情報を取得するには、[AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) や [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) などの AWS STS API オペレーションを呼び出します。
Amazon MSK は、一時的な認証情報の使用をサポートしています。
## サービスリンクロール
[サービスにリンクされたロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role)により、Amazon Web Services は他のサービスのリソースにアクセスして、ユーザーに代わってアクションを完了することができます。サービスリンクロールは IAM アカウント内に表示され、サービスによって所有されます。 管理者は、サービスにリンクされたロールのアクセス許可を表示できますが、編集することはできません。
Amazon MSK は、サービスにリンクされたロールをサポートします。Amazon MSK サービスにリンクされたロールの作成または管理の詳細については、「[Amazon MSK のサービスリンクロール](using-service-linked-roles.md)」 。
# Amazon MSK の ID ベースのポリシーの例
デフォルトでは、IAM ユーザーとロールには Amazon MSK API アクションを実行する権限がありません。IAM 管理者は、指定されたリソースで特定の API 操作を実行するための許可をユーザーとロールに付与する IAM ポリシーを作成する必要があります。続いて、管理者はそれらの権限が必要な IAM ユーザーまたはグループにそのポリシーをアタッチする必要があります。
JSON ポリシードキュメントのこれらの例を使用して、IAM アイデンティティベースのポリシーを作成する方法については、「IAM ユーザーガイド」の「[JSON タブでのポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor)」を参照してください。
**Topics**
+ [ポリシーに関するベストプラクティス](security_iam_service-with-iam-policy-best-practices.md)
+ [ユーザーが自分の権限を表示できるようにする](security_iam_id-based-policy-examples-view-own-permissions.md)
+ [1 つの Amazon MSK クラスターへのアクセス](security_iam_id-based-policy-examples-access-one-cluster.md)
+ [タグに基づく Amazon MSK クラスターへのアクセス](security_iam_id-based-policy-examples-view-widget-tags.md)
# ポリシーに関するベストプラクティス
ID ベースのポリシーは、ユーザーのアカウント内で誰かが Amazon MSK リソースを作成、アクセス、または削除できるどうかを決定します。これらのアクションでは、 AWS アカウントに費用が発生する場合があります。アイデンティティベースポリシーを作成したり編集したりする際には、以下のガイドラインと推奨事項に従ってください:
+ ** AWS 管理ポリシーを開始し、最小特権のアクセス許可に移行する** – ユーザーとワークロードにアクセス許可の付与を開始するには、多くの一般的なユースケースにアクセス許可を付与する*AWS 管理ポリシー*を使用します。これらは で使用できます AWS アカウント。ユースケースに固有の AWS カスタマー管理ポリシーを定義することで、アクセス許可をさらに減らすことをお勧めします。詳細については、*IAM ユーザーガイド* の [AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) または [ジョブ機能のAWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) を参照してください。
+ **最小特権を適用する** – IAM ポリシーでアクセス許可を設定する場合は、タスクの実行に必要な許可のみを付与します。これを行うには、特定の条件下で特定のリソースに対して実行できるアクションを定義します。これは、最小特権アクセス許可とも呼ばれています。IAM を使用して許可を適用する方法の詳細については、*IAM ユーザーガイド* の [IAM でのポリシーとアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) を参照してください。
+ **IAM ポリシーで条件を使用してアクセスをさらに制限する** - ポリシーに条件を追加して、アクションやリソースへのアクセスを制限できます。たとえば、ポリシー条件を記述して、すべてのリクエストを SSL を使用して送信するように指定できます。条件を使用して、サービスアクションが などの特定の を通じて使用されている場合に AWS のサービス、サービスアクションへのアクセスを許可することもできます CloudFormation。詳細については、*IAM ユーザーガイド* の [IAM JSON ポリシー要素:条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) を参照してください。
+ **IAM アクセスアナライザー を使用して IAM ポリシーを検証し、安全で機能的な権限を確保する** - IAM アクセスアナライザー は、新規および既存のポリシーを検証して、ポリシーが IAM ポリシー言語 (JSON) および IAM のベストプラクティスに準拠するようにします。IAM アクセスアナライザーは 100 を超えるポリシーチェックと実用的な推奨事項を提供し、安全で機能的なポリシーの作成をサポートします。詳細については、*IAM ユーザーガイド* の [IAM Access Analyzer でポリシーを検証する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) を参照してください。
+ **多要素認証 (MFA) を要求する** – で IAM ユーザーまたはルートユーザーを必要とするシナリオがある場合は AWS アカウント、MFA をオンにしてセキュリティを強化します。API オペレーションが呼び出されるときに MFA を必須にするには、ポリシーに MFA 条件を追加します。詳細については、*IAM ユーザーガイド* の [MFA を使用した安全な API アクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) を参照してください。
IAM でのベストプラクティスの詳細については、「*IAM ユーザーガイド*」の「[IAM でのセキュリティベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。
# ユーザーが自分の権限を表示できるようにする
この例では、ユーザーアイデンティティにアタッチされたインラインおよびマネージドポリシーの表示を IAM ユーザーに許可するポリシーの作成方法を示します。このポリシーには、コンソールで、または AWS CLI または AWS API を使用してプログラムでこのアクションを実行するアクセス許可が含まれています。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# 1 つの Amazon MSK クラスターへのアクセス
この例では、Amazon Web Services アカウントの IAM ユーザーに、クラスターの 1 つである `purchaseQueriesCluster` へのアクセスを許可します。このポリシーにより、ユーザーはクラスターを記述し、ブートストラップブローカーを取得し、ブローカーノードを一覧表示し、更新することができます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"UpdateCluster",
"Effect":"Allow",
"Action":[
"kafka:Describe*",
"kafka:Get*",
"kafka:List*",
"kafka:Update*"
],
"Resource":"arn:aws:kafka:us-east-1:012345678012:cluster/purchaseQueriesCluster/abcdefab-1234-abcd-5678-cdef0123ab01-2"
}
]
}
```
------
# タグに基づく Amazon MSK クラスターへのアクセス
アイデンティティベースのポリシーの条件を使用して、タグに基づいて Amazon MSK リソースへのアクセスを制御できます。この例では、クラスターの記述、クラスターのブートストラップブローカーの取得、ブローカーノードの一覧表示、更新、削除をユーザーに許可するポリシーの作成方法を示しています。ただし、クラスター タグ `Owner` にそのユーザーのユーザー名の値がある場合のみ、アクセス許可は付与されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AccessClusterIfOwner",
"Effect": "Allow",
"Action": [
"kafka:Describe*",
"kafka:Get*",
"kafka:List*",
"kafka:Update*",
"kafka:Delete*"
],
"Resource": "arn:aws:kafka:us-east-1:012345678012:cluster/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Owner": "${aws:username}"
}
}
}
]
}
```
------
このポリシーをアカウントの IAM ユーザーにアタッチできます。`richard-roe` という名前のユーザーが MSK クラスターを更新しようとする場合、クラスターには `Owner=richard-roe` または `owner=richard-roe` のタグを付ける必要があります。それ以外の場合、アクセスは拒否されます。条件キー名では大文字と小文字は区別されないため、条件タグキー `Owner` は `Owner` と `owner` に一致します。詳細については、「*IAM ユーザーガイド*」の「[IAM JSON ポリシー要素: 条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)」を参照してください。
# Amazon MSK のサービスリンクロール
Amazon MSK は AWS Identity and Access Management (IAM) [ サービスにリンクされたロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role)を使用します。サービスにリンクされたロールは、Amazon MSK に直接リンクされている一意のタイプの IAM ロールです。サービスにリンクされたロールは Amazon MSK によって事前定義されており、サービスがユーザーに代わって他の AWS サービスを呼び出すために必要なすべてのアクセス許可が含まれています。
サービスにリンクされたロールを使用すると、必要な設定を手動で追加する必要がないため、 Amazon MSK の設定が簡単になります。Amazon MSK は、サービスにリンクされたロールの権限を定義します。特に明記されていない限り、Amazon MSK のみがそのロールを引き受けることができます。定義された権限には、信頼ポリシーとアクセス許可ポリシーが含まれ、そのアクセス許可ポリシーを他の IAM エンティティに添付することはできません。
サービスにリンクされたロールをサポートする他のサービスについては、[IAM と連携する Amazon Web Services](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) を参照し、**サービスにリンクされたロール**列が**Yes** (はい) になっているサービスを探してください。そのサービスのサービスにリンクされたロールのドキュメントを表示するには、リンク付きの**はい**を選択します。
**Topics**
+ [サービスにリンクされたロールのアクセス許可](slr-permissions.md)
+ [サービスにリンクされたロールの作成](create-slr.md)
+ [サービスにリンクされたロールの編集](edit-slr.md)
+ [のサービスにリンクされたロールをサポートするリージョン](slr-regions.md)
# Amazon MSK のサービスリンクロールのアクセス許可
Amazon MSK では、**AWSServiceRoleForKafka** という名前のサービスリンクロールを使用します。Amazon MSK は、このロールを使用してリソースにアクセスし、次のようなオペレーションを実行します。
+ `*NetworkInterface` — カスタマーアカウントのネットワークインターフェイスを作成および管理します。これにより、カスタマー VPC 内のクライアントがクラスターブローカーにアクセスできるようなります。
+ `*VpcEndpoints` – を使用して、カスタマー VPC 内のクライアントがクラスターブローカーにアクセスできるようにする、カスタマーアカウントの VPC エンドポイントを管理します AWS PrivateLink。Amazon MSK は、`DescribeVpcEndpoints`、`ModifyVpcEndpoint`、および `DeleteVpcEndpoints` に対するアクセス許可を使用します。
+ `secretsmanager` – を使用してクライアント認証情報を管理します AWS Secrets Manager。
+ `GetCertificateAuthorityCertificate` — プライベート認証局の証明書を取得します。
+ `*Ipv6Addresses` – ユーザーアカウントのネットワークインターフェイスに IPv6 アドレスを割り当てたり割り当て解除したりして、MSK クラスターの IPv6 接続を有効にします。
+ `ModifyNetworkInterfaceAttribute` – お客様のアカウントのネットワークインターフェイス属性を変更して、MSK クラスター接続の IPv6 設定を構成します。
このサービスリンクロールは、マネージドポリシー `KafkaServiceRolePolicy` にアタッチされます。このポリシーの更新については、「[KafkaServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/KafkaServiceRolePolicy.html)」を参照してください。
AWSServiceRoleForKafka サービスリンクロールは、以下のサービスを信頼してロールを引き受けます。
+ `kafka.amazonaws.com`
ロールのアクセス許可ポリシーは、Amazon MSK がリソースに対して以下のアクションを実行することを許可します。
サービスリンクロールの作成、編集、削除を IAM エンティティ (ユーザー、グループ、ロールなど) に許可するにはアクセス許可を設定する必要があります。詳細については、「*IAM ユーザーガイド*」の「[サービスリンクロールの許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)」を参照してください。
# Amazon MSK のサービスリンクロールを作成する
サービスにリンクされたロールを手動で作成する必要はありません。 AWS マネジメントコンソール、、 AWS CLIまたは AWS API で Amazon MSK クラスターを作成すると、Amazon MSK によってサービスにリンクされたロールが作成されます。
このサービスリンクロールを削除した後で再度作成する必要が生じた場合は同じ方法でアカウントにロールを再作成できます。Amazon MSK クラスターを作成すると、Amazon MSK はサービスにリンクされたロールを再度作成します。
# Amazon MSK のサービスリンクロールを編集する
Amazon MSK では、AWSServiceRoleForKafka サービスにリンクされたロールを編集することはできません。サービスにリンクされたロールを作成すると、多くのエンティティによってロールがリファレンスされる可能性があるため、ロール名を変更することはできません。ただし、IAM を使用してロールの説明を編集することはできます。詳細については、「*IAM ユーザーガイド*」の「[サービスにリンクされたロールの編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)」を参照してください。
# Amazon MSK のサービスリンクロールがサポートされるリージョン
Amazon MSK は、サービスが利用可能なすべてのリージョンでサービスにリンクされたロールの使用をサポートします。詳細については、「[AWS リージョンとエンドポイント](https://docs.aws.amazon.com/general/latest/gr/rande.html)」を参照してください。
# AWS Amazon MSK の マネージドポリシー
AWS 管理ポリシーは、 によって作成および管理されるスタンドアロンポリシーです AWS。 AWS 管理ポリシーは、ユーザー、グループ、ロールにアクセス許可の割り当てを開始できるように、多くの一般的なユースケースにアクセス許可を付与するように設計されています。
AWS 管理ポリシーは、すべての AWS お客様が使用できるため、特定のユースケースに対して最小特権のアクセス許可を付与しない場合があることに注意してください。ユースケースに固有の[カスタマー管理ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)を定義して、アクセス許可を絞り込むことをお勧めします。
AWS 管理ポリシーで定義されているアクセス許可は変更できません。が AWS マネージドポリシーで定義されたアクセス許可 AWS を更新すると、ポリシーがアタッチされているすべてのプリンシパル ID (ユーザー、グループ、ロール) に影響します。 AWS は、新しい が起動されるか、新しい API オペレーション AWS のサービス が既存のサービスで使用できるようになったときに、 AWS マネージドポリシーを更新する可能性が高くなります。
詳細については、「**IAM ユーザーガイド」の「[AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)」を参照してください。
# AWS マネージドポリシー: AmazonMSKFullAccess
このポリシーは、プリンシパルにすべての Amazon MSK アクションへのフルアクセスを許可する管理者権限を付与します。このポリシーの権限は、次のようにグループ化されています。
+ Amazon MSK 権限は、すべての Amazon MSK アクションを許可します。
+ **`Amazon EC2` アクセス許可** – このポリシーでは、API リクエストで渡されたリソースを検証するために必要です。これは、Amazon MSK がクラスターでリソースを正常に使用できるようにするためです。このポリシーの残りの Amazon EC2 アクセス許可により、Amazon MSK はクラスターへの接続を可能にするために必要な AWS リソースを作成できます。
+ **`AWS KMS` アクセス許可** – リクエストで渡されたリソースを検証するために、API コール中に使用されます。これらは、Amazon MSK が、渡されたキーを Amazon MSK クラスターで使用できるようにするために必要です。
+ **`CloudWatch Logs, Amazon S3, and Amazon Data Firehose` アクセス許可** – ログ配信先が到達可能で、ブローカーログの使用に有効であることを、Amazon MSK が確認できるようにするために必要です。
+ **`IAM` アクセス許可** – Amazon MSK がアカウント内でサービスリンクロールを作成できるようにし、ユーザーがサービス実行ロールを Amazon MSK に渡すことができるようにするために必要です。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"kafka:*",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"ec2:DescribeSecurityGroups",
"ec2:DescribeRouteTables",
"ec2:DescribeVpcEndpoints",
"ec2:DescribeVpcAttribute",
"kms:DescribeKey",
"kms:CreateGrant",
"logs:CreateLogDelivery",
"logs:GetLogDelivery",
"logs:UpdateLogDelivery",
"logs:DeleteLogDelivery",
"logs:ListLogDeliveries",
"logs:PutResourcePolicy",
"logs:DescribeResourcePolicies",
"logs:DescribeLogGroups",
"S3:GetBucketPolicy",
"firehose:TagDeliveryStream"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateVpcEndpoint"
],
"Resource": [
"arn:*:ec2:*:*:vpc/*",
"arn:*:ec2:*:*:subnet/*",
"arn:*:ec2:*:*:security-group/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateVpcEndpoint"
],
"Resource": [
"arn:*:ec2:*:*:vpc-endpoint/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/AWSMSKManaged": "true"
},
"StringLike": {
"aws:RequestTag/ClusterArn": "*"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:*:ec2:*:*:vpc-endpoint/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "CreateVpcEndpoint"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteVpcEndpoints"
],
"Resource": "arn:*:ec2:*:*:vpc-endpoint/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/AWSMSKManaged": "true"
},
"StringLike": {
"ec2:ResourceTag/ClusterArn": "*"
}
}
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "kafka.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/kafka.amazonaws.com/AWSServiceRoleForKafka*",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "kafka.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/kafka.amazonaws.com/AWSServiceRoleForKafka*"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/delivery.logs.amazonaws.com/AWSServiceRoleForLogDelivery*",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "delivery.logs.amazonaws.com"
}
}
}
]
}
```
------
# AWS マネージドポリシー: AmazonMSKReadOnlyAccess
このポリシーは、ユーザーが Amazon MSK で情報を表示できるようにする読み取り専用の権限を付与します。このポリシーが添付されているプリンシパルは、既存のリソースを更新または削除したり、新しい Amazon MSK リソースを作成したりすることはできません。例えば、これらの権限を持つプリンシパルは、自分のアカウントに関連付けられているクラスターと構成のリストを表示できますが、クラスターの構成や設定を変更することはできません。このポリシーの権限は、次のようにグループ化されています。
+ **`Amazon MSK` アクセス許可** – Amazon MSK リソースを一覧表示し、記述し、それらに関する情報を取得できるようにします。
+ **`Amazon EC2` アクセス許可** – クラスターに関連付けられている Amazon VPC、サブネット、セキュリティグループ、および ENI を記述するために使用されます。
+ **`AWS KMS` アクセス許可** – クラスターに関連付けられているキーを記述するために使用されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"kafka:Describe*",
"kafka:List*",
"kafka:Get*",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"kms:DescribeKey"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
# AWS マネージドポリシー: KafkaServiceRolePolicy
KafkaServiceRolePolicy を IAM エンティティにアタッチすることはできません。このポリシーは、Amazon MSK が MSK クラスター上の VPC エンドポイント (コネクタ) の管理、ネットワークインターフェイスの管理、 AWS Secrets Managerを使用したクラスター認証情報の管理などのアクションを実行できるようにする、サービスリンクロールにアタッチされています。詳細については、「[Amazon MSK のサービスリンクロール](using-service-linked-roles.md)」を参照してください。
次の表は、Amazon MSK が変更の追跡を開始してからの KafkaServiceRolePolicy 管理ポリシーの更新を示しています。
| 変更 | 説明 | 日付 |
| --- | --- | --- |
| [KafkaServiceRolePolicy に追加された IPv6 接続のサポート](#security-iam-awsmanpol-KafkaServiceRolePolicy) — 既存のポリシーの更新 | Amazon MSK は KafkaServiceRolePolicy にアクセス許可を追加し、MSK クラスターの IPv6 接続を有効にしました。これらのアクセス許可により、Amazon MSK は IPv6 アドレスをネットワークインターフェイスに割り当てたり割り当てを解除したり、お客様のアカウントのネットワークインターフェイス属性を変更したりできます。 | 2025 年 11 月 17 日 |
| [KafkaServiceRolePolicy](#security-iam-awsmanpol-KafkaServiceRolePolicy) — 既存のポリシーに対する更新 | Amazon MSK に、マルチ VPC プライベート接続をサポートするためのアクセス許可が追加されました。 | 2023 年 3 月 8 日 |
| Amazon MSK が変更の追跡を開始しました | Amazon MSK は KafkaServiceRolePolicy 管理ポリシーの変更の追跡を開始しました。 | 2023 年 3 月 8 日 |
# AWS マネージドポリシー: AWSMSKReplicatorExecutionRole
この `AWSMSKReplicatorExecutionRole` ポリシーは、MSK クラスター間でデータをレプリケートするためのアクセス許可を Amazon MSK Replicator に付与します。このポリシーの権限は、次のようにグループ化されています。
+ **`cluster`** – IAM 認証を使用してクラスターに接続するアクセス許可を Amazon MSK Replicator に付与します。また、クラスターを記述および変更するアクセス許可も付与します。
+ **`topic`** – トピックを記述、作成、変更し、トピックの動的設定を変更するアクセス許可を Amazon MSK Replicator に付与します。
+ **`consumer group`** – コンシューマーグループを記述および変更し、MSK クラスターからデータを読み書きし、レプリケーターによって作成された内部トピックを削除するアクセス許可を Amazon MSK Replicator に付与します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ClusterPermissions",
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect",
"kafka-cluster:DescribeCluster",
"kafka-cluster:AlterCluster",
"kafka-cluster:DescribeTopic",
"kafka-cluster:CreateTopic",
"kafka-cluster:AlterTopic",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData",
"kafka-cluster:AlterGroup",
"kafka-cluster:DescribeGroup",
"kafka-cluster:DescribeTopicDynamicConfiguration",
"kafka-cluster:AlterTopicDynamicConfiguration",
"kafka-cluster:WriteDataIdempotently"
],
"Resource": [
"arn:aws:kafka:*:*:cluster/*"
]
},
{
"Sid": "TopicPermissions",
"Effect": "Allow",
"Action": [
"kafka-cluster:DescribeTopic",
"kafka-cluster:CreateTopic",
"kafka-cluster:AlterTopic",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData",
"kafka-cluster:DescribeTopicDynamicConfiguration",
"kafka-cluster:AlterTopicDynamicConfiguration",
"kafka-cluster:AlterCluster"
],
"Resource": [
"arn:aws:kafka:*:*:topic/*/*"
]
},
{
"Sid": "GroupPermissions",
"Effect": "Allow",
"Action": [
"kafka-cluster:AlterGroup",
"kafka-cluster:DescribeGroup"
],
"Resource": [
"arn:aws:kafka:*:*:group/*/*"
]
}
]
}
```
------
# AWS マネージドポリシーに対する Amazon MSK の更新
このサービスがこれらの変更の追跡を開始してからの Amazon MSK の AWS マネージドポリシーの更新に関する詳細を表示します。
| 変更 | 説明 | 日付 |
| --- | --- | --- |
| [AWSMSKReplicatorExecutionRole に追加された WriteDataIdempotently アクセス許可](security-iam-awsmanpol-AWSMSKReplicatorExecutionRole.md) – 既存のポリシーの更新 | Amazon MSK は、MSK クラスター間のデータレプリケーションをサポートするために、AWSMSKReplicatorExecutionRole ポリシーに WriteDataIdempotently アクセス許可を追加しました。 | 2024 年 3 月 12 日 |
| [AWSMSKReplicatorExecutionRole](security-iam-awsmanpol-AWSMSKReplicatorExecutionRole.md) – 新しいポリシー | Amazon MSK は、 Amazon MSK Replicator をサポートする AWSMSKReplicatorExecutionRole ポリシーを追加しました。 | 2023 年 12 月 4 日 |
| [AmazonMSKFullAccess](security-iam-awsmanpol-AmazonMSKFullAccess.md) – 既存のポリシーに更新 | Amazon MSK に、Amazon MSK Replicator をサポートするためのアクセス許可が追加されました。 | 2023 年 9 月 28 日 |
| [KafkaServiceRolePolicy](security-iam-awsmanpol-KafkaServiceRolePolicy.md) — 既存のポリシーに対する更新 | Amazon MSK に、マルチ VPC プライベート接続をサポートするためのアクセス許可が追加されました。 | 2023 年 3 月 8 日 |
| [AmazonMSKFullAccess](security-iam-awsmanpol-AmazonMSKFullAccess.md) – 既存のポリシーに更新 | Amazon MSK は、クラスターへの接続を可能にする新しい Amazon EC2 権限を追加しました。 | 2021 年 11 月 30 日 |
| [AmazonMSKFullAccess](security-iam-awsmanpol-AmazonMSKFullAccess.md) – 既存のポリシーに更新 | Amazon MSK は、Amazon EC2 ルートテーブルを記述できるようにするための新しい権限を追加しました。 | 2021 年 11 月 19 日 |
| Amazon MSK が変更の追跡を開始しました | Amazon MSK は、 AWS 管理ポリシーの変更の追跡を開始しました。 | 2021 年 11 月 19 日 |
# Amazon MSK の ID およびアクセスのトラブルシューティング
次の情報を使用して、Amazon MSK および IAM での作業中に発生する可能性のある一般的な問題を診断および修正するのに役立ててください。
**Topics**
+ [私は Amazon MSK でのアクションの実行を認可されていません](#security_iam_troubleshoot-no-permissions)
## 私は Amazon MSK でのアクションの実行を認可されていません
にアクションを実行する権限がないと AWS マネジメントコンソール 通知された場合は、管理者に連絡してサポートを依頼する必要があります。管理者とは、サインイン認証情報を提供した担当者です。
次のエラー例は、`mateojackson` IAM ユーザーがコンソールを使用してクラスターを削除しようとしているが、`kafka:DeleteCluster` 許可を持っていない場合に発生します。
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: kafka:DeleteCluster on resource: purchaseQueriesCluster
```
この場合、Mateo は管理者に、`kafka:DeleteCluster` アクションを使用して `purchaseQueriesCluster` リソースにアクセスできるようにポリシーを更新するように依頼します。
# Apache Kafka API の認証と認可
IAM を使用して、クライアントを認証し、Apache Kafka アクションを許可または拒否できます。または、TLS または SASL/SCRAM を使用してクライアントを認証し、Apache Kafka ACL を使用してアクションを許可または拒否することもできます。
クラスターで [Amazon MSK オペレーション](https://docs.aws.amazon.com/msk/1.0/apireference/operations.html)を実行できるユーザーを制御する方法については、「[Amazon MSK API の認証と認可](security-iam.md)」を参照してください。
**Topics**
+ [IAM アクセスコントロール](iam-access-control.md)
+ [Amazon MSK の相互 TLS クライアント認証](msk-authentication.md)
+ [AWS Secrets Manager を使用したサインイン認証情報認証](msk-password.md)
+ [Apache Kafka ACL](msk-acls.md)
# IAM アクセスコントロール
Amazon MSK の IAM アクセス制御により、MSK クラスターの認証と認可の両方を処理できます。これにより、認証に 1 つのメカニズムを使用し、認可に別のメカニズムを使用する必要がなくなります。たとえば、クライアントがクラスターへの書き込みを試みると、Amazon MSK は IAM を使用して、そのクライアントが認証済みアイデンティティであるかどうか、およびクラスターへの作成が認可されているかどうかをチェックします。
IAM アクセスコントロールは Java クライアントと Java 以外のクライアント (Python、Go、JavaScript、.NET で記述された Kafka クライアントを含む) で機能します。Kafka バージョン 2.7.1 以降を搭載した MSK クラスターでは、非 Java クライアント向けの IAM アクセス制御が使用可能です。
IAM アクセス制御を可能にするために、Amazon MSK は Apache Kafka ソースコードに小さな変更を加えます。これらの変更によって、Apache Kafka のエクスペリエンスに目立った違いが生じることはありません。Amazon MSK はアクセスイベントをログに記録するため、それらを監査できます。
IAM アクセス制御を使用する MSK クラスターの Apache Kafka ACL API を呼び出すことができます。ただし、 Apache Kafka のアクセス制御リスト (ACL)は、 IAM 識別子に対する認証には影響しません。IAM 識別子へのアクセスを制御するには、IAM ポリシーを使用する必要があります。
**重要な考慮事項**
MSK クラスターで IAM アクセス制御を使用する際には、以下の重要な考慮事項を念頭に置いてください。
IAM アクセス制御は Apache ZooKeeper ノードには適用されません。これらのノードへのアクセスを制御する方法については、「[Amazon MSK クラスター内の Apache ZooKeeper ノードへのアクセスを制御する](zookeeper-security.md)」を参照してください。
クラスターが IAM アクセス制御を使用している場合、`allow.everyone.if.no.acl.found` Apache Kafka 設定は効果がありません。
IAM アクセス制御を使用する MSK クラスターの Apache Kafka ACL API を呼び出すことができます。ただし、 Apache Kafka のアクセス制御リスト (ACL)は、 IAM 識別子に対する認証には影響しません。IAM 識別子へのアクセスを制御するには、IAM ポリシーを使用する必要があります。
# Amazon MSK の IAM アクセス制御の仕組み
Amazon MSK の IAM アクセス制御を使用するには、次のステップを実行します。これらの詳細については、以下のトピックで詳しく説明します。
+ [IAM アクセス制御を使用する Amazon MSK クラスターを作成する](create-iam-access-control-cluster-in-console.md)
+ [IAM アクセス制御用にクライアントを設定する](configure-clients-for-iam-access-control.md)
+ [IAM ロールの認可ポリシーを作成する](create-iam-access-control-policies.md)
+ [IAM アクセス制御用のブートストラップブローカーを入手する](get-bootstrap-brokers-for-iam.md)
# IAM アクセス制御を使用する Amazon MSK クラスターを作成する
このセクションでは AWS マネジメントコンソール、、 API、または を使用して、IAM アクセスコントロールを使用する Amazon MSK クラスター AWS CLI を作成する方法について説明します。既存のクラスターに対して IAM アクセス制御を有効にする方法については、「[Amazon MSK クラスターのセキュリティ設定を更新する](msk-update-security.md)」を参照してください。
**AWS マネジメントコンソール を使用して、IAM アクセスコントロールを使用するクラスターを作成する**
1. [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/) で Amazon MSK コンソールを開きます。
1. **Create cluster** (クラスターの作成) を選択します。
1. **Create cluster with custom settings** (カスタム設定でクラスターを作成) を選択します。
1. **Authentication** (認証) セクションで、**IAM access control** (IAMアクセス制御) を選択します。
1. クラスターを作成するための残りのワークフローを完了します。
**API または AWS CLI を使用して、IAM アクセスコントロールを使用するクラスターを作成する**
+ IAM アクセス制御を有効にしてクラスターを作成するには、[CreateCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster) API または [create-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/create-cluster.html) CLI コマンドを使用して、`ClientAuthentication` パラメータに次の JSON を渡します：`"ClientAuthentication": { "Sasl": { "Iam": { "Enabled": true } }`。
# IAM アクセス制御用にクライアントを設定する
クライアントが IAM アクセス制御を使用する MSK クラスターと通信できるようにするために、次のメカニズムのいずれかを使用できます。
+ SASL\$1OAUTHBEARER メカニズムを使用する Java 以外のクライアント設定
+ SASL\$1OAUTHBEARER メカニズムまたは AWS\$1MSK\$1IAM メカニズムを使用する Java のクライアント設定
## SASL\$1OAUTHBEARER メカニズムを使用して IAM を設定する
1. 以下の Python Kafka クライアントの例を使用して、 client.properties 設定ファイルを編集してください。設定の変更は他の言語でも同様です。
```
from kafka import KafkaProducer
from kafka.errors import KafkaError
from kafka.sasl.oauth import AbstractTokenProvider
import socket
import time
from aws_msk_iam_sasl_signer import MSKAuthTokenProvider
class MSKTokenProvider():
def token(self):
token, _ = MSKAuthTokenProvider.generate_auth_token('')
return token
tp = MSKTokenProvider()
producer = KafkaProducer(
bootstrap_servers='',
security_protocol='SASL_SSL',
sasl_mechanism='OAUTHBEARER',
sasl_oauth_token_provider=tp,
client_id=socket.gethostname(),
)
topic = ""
while True:
try:
inp=input(">")
producer.send(topic, inp.encode())
producer.flush()
print("Produced!")
except Exception:
print("Failed to send message:", e)
producer.close()
```
1. 選択した設定言語用のヘルパーライブラリをダウンロードし、その言語ライブラリのホームページにある*「はじめに」*セクションの手順に従ってください。
+ JavaScript: [https://github.com/aws/aws-msk-iam-sasl-signer-js\$1getting-started](https://github.com/aws/aws-msk-iam-sasl-signer-js#getting-started)
+ Python: [https://github.com/aws/aws-msk-iam-sasl-signer-python\$1get-started](https://github.com/aws/aws-msk-iam-sasl-signer-python#get-started)
+ Go: [https://github.com/aws/aws-msk-iam-sasl-signer-go\$1getting-started](https://github.com/aws/aws-msk-iam-sasl-signer-go#getting-started)
+ .NET: [https://github.com/aws/aws-msk-iam-sasl-signer-net\$1getting-started](https://github.com/aws/aws-msk-iam-sasl-signer-net#getting-started)
+ JAVA: SASL\$1OAUTHBEARER の Java サポートは [https://github.com/aws/aws-msk-iam-auth/releases](https://github.com/aws/aws-msk-iam-auth/releases) jar ファイルを介して提供されます
## MSK カスタム AWS\$1MSK\$1IAM メカニズムを使用して IAM を設定する
1. 以下を `client.properties` ファイルに追加します。**を、クライアント上のトラストストアファイルへの完全修飾パスに置き換えます。
**注記**
特定の証明書を使用しない場合は、`client.properties` ファイルから `ssl.truststore.location=` を削除できます。`ssl.truststore.location` に値を指定しない場合、Java プロセスではデフォルトの証明書が使用されます。
```
ssl.truststore.location=
security.protocol=SASL_SSL
sasl.mechanism=AWS_MSK_IAM
sasl.jaas.config=software.amazon.msk.auth.iam.IAMLoginModule required;
sasl.client.callback.handler.class=software.amazon.msk.auth.iam.IAMClientCallbackHandler
```
AWS 認証情報用に作成した名前付きプロファイルを使用するには、クライアント設定ファイルに `awsProfileName="your profile name";` を含めます。名前付きプロファイルの詳細については、 AWS CLI ドキュメントの[「名前付きプロファイル](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html)」を参照してください。
1. 最新の安定した[aws-msk-iam-auth](https://github.com/aws/aws-msk-iam-auth/releases) JAR ファイルをダウンロードし、クラスパスに配置します。Maven を使用する場合は、次の依存関係を追加し、必要に応じてバージョン番号を調整します。
```
software.amazon.msk
aws-msk-iam-auth
1.0.0
```
Amazon MSK クライアント プラグインは、Apache 2.0 ライセンスの下でオープンソース化されています。
# IAM ロールの認可ポリシーを作成する
クライアントに対応する IAM ロールに認可ポリシーを添付します。認可ポリシーでは、ロールに対して許可または拒否するアクションを指定します。クライアントが Amazon EC2 インスタンス上にある場合は、認可ポリシーをその Amazon EC2 インスタンスの IAM ロールに関連付けます。または、名前付きプロファイルを使用するようにクライアントを設定してから、認可ポリシーをその名前付きプロファイルのロールに関連付けることができます。 [IAM アクセス制御用にクライアントを設定する](configure-clients-for-iam-access-control.md) は、名前付きプロファイルを使用するようにクライアントを設定する方法を説明しています。
IAM ポリシーを作成する方法については、[IAM ポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)を参照してください。
以下は、MyTestCluster という名前のクラスターの認可ポリシーの例です。`Action` 要素と `Resource` 要素のセマンティクスを理解するには、「[IAM 認可ポリシーアクションとリソースのセマンティクス](kafka-actions.md)」を参照してください。
**重要**
IAM ポリシーに加えた変更は、IAM API と AWS CLI にすぐに反映されます。ただし、ポリシーの変更が有効になるまでにかなりの時間がかかる場合があります。ほとんどの場合、ポリシーの変更は1分以内に有効になります。ネットワークの状態により、遅延が増える場合があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect",
"kafka-cluster:AlterCluster",
"kafka-cluster:DescribeCluster"
],
"Resource": [
"arn:aws:kafka:us-east-1:111122223333:cluster/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1"
]
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:*Topic*",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:topic/MyTestCluster/*"
]
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:AlterGroup",
"kafka-cluster:DescribeGroup"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:group/MyTestCluster/*"
]
}
]
}
```
------
データの生成や消費など、一般的な Apache Kafka のユースケースに対応するアクション要素を使用してポリシーを作成する方法については、「[クライアント認可ポリシーの一般的なユースケース](iam-access-control-use-cases.md)」を参照してください。
Kafka バージョン 2.8.0 以降では、**WriteDataIdempotently** アクセス許可は廃止されました ([KIP-679](https://cwiki.apache.org/confluence/display/KAFKA/KIP-679%3A+Producer+will+enable+the+strongest+delivery+guarantee+by+default))。デフォルトでは、`enable.idempotence = true` が設定されています。したがって、Kafka バージョン 2.8.0 以降では、IAM は Kafka ACL と同じ機能を提供しません。そのトピックへの `WriteData` アクセス権限を提供するだけでは、トピックに対して `WriteDataIdempotently` を実行することはできません。これは、`WriteData` が**すべて**のトピックに提供されている場合には該当しません。その場合は、`WriteDataIdempotently` は許可されます。これは、 IAM ロジックの実装と Kafka ACL の実装方法の違いによるものです。さらに、トピックにべき等的に書き込むには、`transactional-ids` へのアクセスも必要です。
この問題を回避するために、以下のようなポリシーを使用することが推奨されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect",
"kafka-cluster:AlterCluster",
"kafka-cluster:DescribeCluster",
"kafka-cluster:WriteDataIdempotently"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:cluster/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1"
]
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:*Topic*",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:topic/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/TestTopic",
"arn:aws:kafka:us-east-1:123456789012:transactional-id/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/*"
]
}
]
}
```
------
この場合、`WriteData` への書き込みを許可する`TestTopic`と同時に`WriteDataIdempotently`、 クラスターへの冪等性書き込みを許可します。このポリシーは、必要な `transactional-id` リソースへのアクセスも追加します。
なぜなら、`WriteDataIdempotently` は、クラスターレベルのアクセス許可であるため、トピックレベルでは使用できません。もし、`WriteDataIdempotently` がトピックレベルに制限されている場合、このポリシーは機能しません。
# IAM アクセス制御用のブートストラップブローカーを入手する
「[Amazon MSK クラスターのブートストラップブローカーを取得する](msk-get-bootstrap-brokers.md)」を参照してください。
# IAM 認可ポリシーアクションとリソースのセマンティクス
**注記**
Apache Kafka バージョン 3.8 以降を実行しているクラスターの場合、IAM アクセスコントロールはトランザクションを終了するための WriteTxnMarkers API をサポートしています。3.8 より前のバージョンの Kafka を実行しているクラスターの場合、IAM アクセスコントロールは WriteTxnMarkers を含む内部クラスターアクションをサポートしていません。これらの以前のバージョンでは、トランザクションを終了するには、IAM 認証の代わりに適切な ACLs で SCRAM または mTLS 認証を使用します。
このセクションでは、IAM 認可ポリシーで使用できるアクション要素とリソース要素のセマンティクスについて説明します。ポリシーの例については「[IAM ロールの認可ポリシーを作成する](create-iam-access-control-policies.md)」を参照してください。
## 認可ポリシーアクション
次の表に、Amazon MSK の IAM アクセス制御を使用するときに認可ポリシーに含めることができるアクションを示します。表の*アクション*列のアクションを認可ポリシーに含める場合は、*必須アクション*列の対応するアクションも含める必要があります。
| アクション | 説明 | 必須アクション | 必要なリソース | サーバーレスクラスターに適用可能 |
| --- | --- | --- | --- | --- |
| kafka-cluster:Connect | クラスターに接続して認証するためのアクセス許可を付与します。 | なし | クラスター | はい |
| kafka-cluster:DescribeCluster | Apache Kafka の DESCRIBE CLUSTER ACL に相当する、クラスターのさまざまな側面を記述するためのアクセス許可を付与します。 | `kafka-cluster:Connect` | クラスター | はい |
| kafka-cluster:AlterCluster | Apache Kafka の ALTER CLUSTER ACL と同等の、クラスターのさまざまな側面を変更するためのアクセス許可を付与します。 | `kafka-cluster:Connect` `kafka-cluster:DescribeCluster` | クラスター | いいえ |
| kafka-cluster:DescribeClusterDynamicConfiguration | Apache Kafka の DESCRIBE\$1CONFIGSCLUSTER ACL に相当する、クラスターの動的設定を記述するためのアクセス許可を付与します。 | `kafka-cluster:Connect` | クラスター | いいえ |
| kafka-cluster:AlterClusterDynamicConfiguration | Apache Kafka の ALTER\$1CONFIGSCLUSTER ACL に相当する、クラスターの動的設定を変更するためのアクセス許可を付与します。 | `kafka-cluster:Connect` `kafka-cluster:DescribeClusterDynamicConfiguration` | クラスター | いいえ |
| kafka-cluster:WriteDataIdempotently | Apache Kafka の IDEMPOTENT\$1WRITECLUSTER ACL に相当する、クラスターにデータをべき等に書き込むためのアクセス許可を付与します。 | `kafka-cluster:Connect` `kafka-cluster:WriteData` | クラスター | はい |
| kafka-cluster:CreateTopic | Apache Kafka の CREATECLUSTER/TOPIC ACL に相当する、クラスター上にトピックを作成するためのアクセス許可を付与します。 | `kafka-cluster:Connect` | トピック | はい |
| kafka-cluster:DescribeTopic | Apache Kafka の DESCRIBETOPIC ACL に相当する、クラスター上のトピックを記述するためのアクセス許可を付与します。 | `kafka-cluster:Connect` | トピック | はい |
| kafka-cluster:AlterTopic | Apache Kafka の ALTER TOPIC ACL に相当する、クラスター上のトピックを変更するためのアクセス許可を付与します。 | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | トピック | はい |
| kafka-cluster:DeleteTopic | Apache Kafka の DELETE TOPIC ACL に相当する、クラスター上のトピックを削除するためのアクセス許可を付与します。 | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | トピック | はい |
| kafka-cluster:DescribeTopicDynamicConfiguration | Apache Kafka の DESCRIBE\$1CONFIGSTOPIC ACL に相当する、クラスター上のトピックの動的設定を記述するためのアクセス許可を付与します。 | `kafka-cluster:Connect` | トピック | はい |
| kafka-cluster:AlterTopicDynamicConfiguration | Apache Kafka の ALTER\$1CONFIGSTOPIC ACL に相当する、クラスター上のトピックの動的設定を変更する許可を付与します。 | `kafka-cluster:Connect` `kafka-cluster:DescribeTopicDynamicConfiguration` | トピック | はい |
| kafka-cluster:ReadData | Apache Kafka の READ TOPIC ACL に相当する、クラスター上のトピックからデータを読み取りためのアクセス許可を付与します。 | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:AlterGroup` | トピック | はい |
| kafka-cluster:WriteData | Apache Kafka の WRITE TOPIC ACL に相当する、クラスター上のトピックにデータを書き込みためのアクセス許可を付与します | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | トピック | はい |
| kafka-cluster:DescribeGroup | Apache Kafka の DESCRIBE GROUP ACL に相当する、クラスター上のグループを記述するためのアクセス許可を付与します。 | `kafka-cluster:Connect` | グループ | はい |
| kafka-cluster:AlterGroup | Apache Kafka の READ GROUP ACL に相当する、クラスター上のグループに参加するためのアクセス許可を付与します。 | `kafka-cluster:Connect` `kafka-cluster:DescribeGroup` | グループ | はい |
| kafka-cluster:DeleteGroup | Apache Kafka の DELETE GROUP ACL に相当する、クラスター上のグループを削除するためのアクセス許可を付与します。 | `kafka-cluster:Connect` `kafka-cluster:DescribeGroup` | グループ | はい |
| kafka-cluster:DescribeTransactionalId | Apache Kafka の DESCRIBE TRANSACTIONAL\$1ID ACL に相当する、クラスター上のトランザクション ID を記述するためのアクセス許可を付与します。 | `kafka-cluster:Connect` | transactional-id | はい |
| kafka-cluster:AlterTransactionalId | Apache Kafka の WRITE TRANSACTIONAL\$1ID ACL に相当する、クラスター上のトランザクション ID を変更するためのアクセス許可を付与します。 | `kafka-cluster:Connect` `kafka-cluster:DescribeTransactionalId` `kafka-cluster:WriteData` | transactional-id | はい |
コロンの後のアクションでは、アスタリスク (\$1) ワイルドカードを何度でも使用できます。以下は例です。
+ `kafka-cluster:*Topic` は、`kafka-cluster:CreateTopic`、`kafka-cluster:DescribeTopic`、`kafka-cluster:AlterTopic`、および `kafka-cluster:DeleteTopic` の略です。`kafka-cluster:DescribeTopicDynamicConfiguration` や `kafka-cluster:AlterTopicDynamicConfiguration` は含まれていません。
+ `kafka-cluster:*` はすべての権限を表します。
## 認可ポリシーリソース
次の表は、Amazon MSK の IAM アクセスコントロールを使用するときに認可ポリシーで使用できる 4 種類のリソースを示しています。クラスターの Amazon リソースネーム (ARN) は、 から、 AWS マネジメントコンソール または [DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster) API または [describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html) AWS CLI コマンドを使用して取得できます。次に、クラスター ARN を使用して、トピック、グループ、およびトランザクション ID の ARN を作成できます。認可ポリシーでリソースを指定するには、そのリソースのARNを使用します。
| [リソース] | ARN 形式 |
| --- | --- |
| クラスター | arn:aws:kafka:region:account-id:cluster/cluster-name/cluster-uuid |
| Topic | arn:aws: kafka:region:account-id:topic/cluster-name/cluster-uuid/topic-name |
| Group | arn:aws:kafka:region:account-id:topic/cluster-name/cluster-uuid/group-name |
| トランザクション ID | arn:aws:kafka:region:account-id:transactional-id/cluster-name/cluster-uuid/transactional-id |
アスタリスク (\$1) ワイルドカードは、`:cluster/`、`:topic/`、`:group/`、および `:transactional-id/` の後に続く ARN の部分のどこでも何度でも使用できます。以下は、アスタリスク (\$1) ワイルドカードを使用して複数のリソースを参照する方法の例です。
+ `arn:aws:kafka:us-east-1:0123456789012:topic/MyTestCluster/*`: クラスターの UUID に関係なく、MyTestCluster という名前のクラスター内のすべてのトピック。
+ `arn:aws:kafka:us-east-1:0123456789012:topic/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/*_test`: 名前が MyTestCluster で、UUID が abcd1234-0123-abcd-5678-1234abcd-1 であるクラスター内で、名前が「\$1test」で終わるすべてのトピック。
+ `arn:aws:kafka:us-east-1:0123456789012:transactional-id/MyTestCluster/*/5555abcd-1111-abcd-1234-abcd1234-1`: アカウント内の MyTestCluster という名前のクラスターのすべてのインカネーションにわたる、トランザクション ID が 5555abcd-1111-abcd-1234-abcd1234-1 であるすべてのトランザクション。つまり、MyTestCluster という名前のクラスターを作成し、それを削除してから、同じ名前で別のクラスターを作成すると、このリソース ARN を使用して、両方のクラスターで同じトランザクション ID を表すことができます。ただし、削除されたクラスターにはアクセスできません。
# クライアント認可ポリシーの一般的なユースケース
次の表の最初の列は、いくつかの一般的なユースケースを示しています。クライアントに特定のユースケースの実行を許可するには、そのユースケースに必要なアクションをクライアントの認可ポリシーに含め、`Effect` を `Allow` に設定します。
Amazon MSK の IAM アクセス制御の一部であるすべてのアクションについては、「[IAM 認可ポリシーアクションとリソースのセマンティクス](kafka-actions.md)」を参照してください。
**注記**
アクションはデフォルトで拒否されます。クライアントに実行を認可するすべてのアクションを明示的に許可する必要があります。
****
| ユースケース | 必須アクション |
| --- | --- |
| 管理者 | `kafka-cluster:*` |
| トピックを作成する | `kafka-cluster:Connect` `kafka-cluster:CreateTopic` |
| データを生成する | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:WriteData` |
| データの使用 | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DescribeGroup` `kafka-cluster:AlterGroup` `kafka-cluster:ReadData` |
| データを無差別に生成する | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:WriteData` `kafka-cluster:WriteDataIdempotently` |
| トランザクションでデータを生成する | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:WriteData` `kafka-cluster:DescribeTransactionalId` `kafka-cluster:AlterTransactionalId` |
| クラスターの設定を説明する | `kafka-cluster:Connect` `kafka-cluster:DescribeClusterDynamicConfiguration` |
| クラスターの設定を更新する | `kafka-cluster:Connect` `kafka-cluster:DescribeClusterDynamicConfiguration` `kafka-cluster:AlterClusterDynamicConfiguration` |
| トピックの設定を説明する | `kafka-cluster:Connect` `kafka-cluster:DescribeTopicDynamicConfiguration` |
| トピックの設定を更新する | `kafka-cluster:Connect` `kafka-cluster:DescribeTopicDynamicConfiguration` `kafka-cluster:AlterTopicDynamicConfiguration` |
| トピックを変更する | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:AlterTopic` |
# Amazon MSK の相互 TLS クライアント認証
アプリケーションから Amazon MSK ブローカーへの接続に対して、TLS を使用したクライアント認証を有効にできます。クライアント認証を使用するには、 AWS Private CAが必要です。は、クラスター AWS アカウント と同じ にあるか、別の アカウントにある AWS Private CA ことができます。の詳細については、 AWS Private CA[「 の作成と管理 AWS Private CA](https://docs.aws.amazon.com/acm-pca/latest/userguide/create-CA.html)」を参照してください。
Amazon MSK は、証明書失効リスト (CRL) をサポートしていません。クラスタートピックへのアクセスを制御したり、侵害された証明書をブロックしたりするには、Apache Kafka ACLs と AWS セキュリティグループを使用します。Apache Kafka ACL の使用については、「[Apache Kafka ACL](msk-acls.md)」を参照してください。
**Topics**
+ [クライアント認証をサポートする Amazon MSK クラスターを作成します。](msk-authentication-cluster.md)
+ [認証を使用するようにクライアントを設定する](msk-authentication-client.md)
+ [認証を使用してメッセージを生成および消費する](msk-authentication-messages.md)
# クライアント認証をサポートする Amazon MSK クラスターを作成します。
この手順では、 を使用してクライアント認証を有効にする方法を示します AWS Private CA。
**注記**
相互 TLS を使用してアクセスを制御する場合は AWS Private CA 、MSK クラスターごとに独立した を使用することを強くお勧めします。そうすることで、PCA によって署名された TLS 証明書が単一の MSK クラスターでのみ認証されるようになります。
1. 次の内容で、`clientauthinfo.json` という名前のファイルを作成します。*Private-CA-ARN* を PCA の ARN に置き換えます。
```
{
"Tls": {
"CertificateAuthorityArnList": ["Private-CA-ARN"]
}
}
```
1. [を使用してプロビジョニングされた Amazon MSK クラスターを作成する AWS CLI](create-cluster-cli.md) の説明に従って、`brokernodegroupinfo.json` という名前のファイルを作成します。
1. クライアント認証では、クライアントとブローカー間の転送中に暗号化を有効にする必要があります。次の内容で、`encryptioninfo.json` という名前のファイルを作成します。*KMS-Key-ARN* を KMS キーの ARN と置き換えます。`ClientBroker` を `TLS` または `TLS_PLAINTEXT` に設定できます。
```
{
"EncryptionAtRest": {
"DataVolumeKMSKeyId": "KMS-Key-ARN"
},
"EncryptionInTransit": {
"InCluster": true,
"ClientBroker": "TLS"
}
}
```
暗号化の詳細については、「[Amazon MSK 暗号化](msk-encryption.md)」を参照してください。
1. AWS CLI がインストールされているマシンで、次のコマンドを実行して、認証と転送中の暗号化が有効になっているクラスターを作成します。レスポンスで提供されるクラスター ARN を保存します。
```
aws kafka create-cluster --cluster-name "AuthenticationTest" --broker-node-group-info file://brokernodegroupinfo.json --encryption-info file://encryptioninfo.json --client-authentication file://clientauthinfo.json --kafka-version "{YOUR KAFKA VERSION}" --number-of-broker-nodes 3
```
# 認証を使用するようにクライアントを設定する
このプロセスでは、認証を使用するクライアントとして使用する Amazon EC2 インスタンスを設定する方法について説明します。
このプロセスでは、クライアントマシンの作成、トピックの作成、および必要なセキュリティ設定により、認証を使用してメッセージを生成および消費する方法について説明します。
1. クライアントマシンとして使用する Amazon EC2 インスタンスを作成します。わかりやすくするために、クラスターで使用したのと同じ VPC にこのインスタンスを作成します。このようなクライアントマシンの作成方法の例については、「[ステップ 3: クライアントマシンを作成する](create-client-machine.md)」を参照してください。
1. [Create a topic]（トピックの作成） 例については、「[ステップ 4: Amazon MSK クラスターにトピックを作成する](create-topic.md)」の手順を参照してください。
1. AWS CLI がインストールされているマシンで、次のコマンドを実行してクラスターのブートストラップブローカーを取得します。*Cluster-ARN* をクラスターの ARN に置き換えます。
```
aws kafka get-bootstrap-brokers --cluster-arn Cluster-ARN
```
`BootstrapBrokerStringTls` に関連付けられた文字列をレスポンスに保存します。
1. クライアントマシンで次のコマンドを実行して、JVM トラストストアを使用してクライアントトラストストアを作成します。JVM パスが異なる場合は、それに応じてコマンドを調整します。
```
cp /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.201.b09-0.amzn2.x86_64/jre/lib/security/cacerts kafka.client.truststore.jks
```
1. クライアントマシンで次のコマンドを実行して、クライアントのプライベートキーを作成します。*Distinguished-Name*、*Example-Alias*、*Your-Store-Pass*、および *Your-Key-Pass* を任意の文字列に置き換えてください。
```
keytool -genkey -keystore kafka.client.keystore.jks -validity 300 -storepass Your-Store-Pass -keypass Your-Key-Pass -dname "CN=Distinguished-Name" -alias Example-Alias -storetype pkcs12 -keyalg rsa
```
1. クライアントマシンで次のコマンドを実行して、前のステップで作成したプライベートキーを使用して証明書リクエストを作成します。
```
keytool -keystore kafka.client.keystore.jks -certreq -file client-cert-sign-request -alias Example-Alias -storepass Your-Store-Pass -keypass Your-Key-Pass
```
1. `client-cert-sign-request` ファイルを開き、それが `-----BEGIN CERTIFICATE REQUEST-----` で始まり、`-----END CERTIFICATE REQUEST-----` で終わることを確認します。`-----BEGIN NEW CERTIFICATE REQUEST-----` で始まる場合は、ファイルの先頭と末尾から単語 `NEW` (およびそれに続く単一のスペース) を削除します。
1. AWS CLI がインストールされているマシンで、次のコマンドを実行して証明書リクエストに署名します。*Private-CA-ARN* を PCA の ARN に置き換えます。必要に応じて、有効性の値を変更できます。ここでは、例として 300 を使用します。
```
aws acm-pca issue-certificate --certificate-authority-arn Private-CA-ARN --csr fileb://client-cert-sign-request --signing-algorithm "SHA256WITHRSA" --validity Value=300,Type="DAYS"
```
レスポンスで提供された証明書 ARN を保存します。
**注記**
クライアント証明書を取得するには、`acm-pca get-certificate` コマンドを使用して証明書 ARN を指定します。詳細については、*AWS CLI 「 コマンドリファレンス」*の「[get-certificate](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/acm-pca/get-certificate.html)」を参照してください。
1. 次のコマンドを実行して、 が AWS Private CA 署名した証明書を取得します。*Certificate-ARN* を、前のコマンドに対するレスポンスから取得した ARN に置き換えます。
```
aws acm-pca get-certificate --certificate-authority-arn Private-CA-ARN --certificate-arn Certificate-ARN
```
1. 前のコマンドを実行した JSON 結果から、`Certificate` および `CertificateChain` に関連付けられた文字列をコピーします。これらの 2 つの文字列を、signed-certificate-from-acm という名前の新しいファイルに貼り付けます。`Certificate` に関連付けられた文字列を貼り付けます。次に、`CertificateChain` に関連付けられた文字列を貼り付けます。`\n` 文字を新しい行に置き換えます。証明書と証明書チェーンを貼り付けた後のファイルの構造を次に示します。
```
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
```
1. 次のコマンドを実行して、この証明書をキーストアに追加し、MSK ブローカーと対話するときに提示できるようにします。
```
keytool -keystore kafka.client.keystore.jks -import -file signed-certificate-from-acm -alias Example-Alias -storepass Your-Store-Pass -keypass Your-Key-Pass
```
1. 次の内容で、`client.properties` という名前のファイルを作成します。トラストストアとキーストアの場所を、`kafka.client.truststore.jks` を保存したパスに調整します。*\$1YOUR KAFKA VERSION\$1* プレースホルダーは、ご使用の Kafka クライアントバージョンに置き換えてください。
```
security.protocol=SSL
ssl.truststore.location=/tmp/kafka_2.12-{YOUR KAFKA VERSION}/kafka.client.truststore.jks
ssl.keystore.location=/tmp/kafka_2.12-{YOUR KAFKA VERSION}/kafka.client.keystore.jks
ssl.keystore.password=Your-Store-Pass
ssl.key.password=Your-Key-Pass
```
# 認証を使用してメッセージを生成および消費する
このプロセスでは、認証を使用してメッセージを生成および消費する方法について説明します。
1. 次のコマンドを実行して、トピックを作成します。`client.properties` という名前のファイルは、前の手順で作成したファイルです。
```
/bin/kafka-topics.sh --create --bootstrap-server BootstrapBroker-String --replication-factor 3 --partitions 1 --topic ExampleTopic --command-config client.properties
```
1. 次のコマンドを実行して、コンソールプロデューサーを起動します。`client.properties` という名前のファイルは、前の手順で作成したファイルです。
```
/bin/kafka-console-producer.sh --bootstrap-server BootstrapBroker-String --topic ExampleTopic --producer.config client.properties
```
1. クライアントマシンの新しいコマンドウィンドウで、次のコマンドを実行してコンソールコンシューマーを起動します。
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBroker-String --topic ExampleTopic --consumer.config client.properties
```
1. プロデューサーウィンドウにメッセージを入力し、コンシューマーウィンドウに表示されるようにします。
# AWS Secrets Manager を使用したサインイン認証情報認証
AWS Secrets Manager を使用して保存および保護されるサインイン認証情報を使用して、Amazon MSK クラスターへのアクセスを制御できます。ユーザーの認証情報を Secrets Manager に保存すると、認証情報の監査、更新、ローテーションなど、クラスター認証のオーバーヘッドが削減されます。Secrets Manager を使用すると、クラスター間でユーザーの認証情報を共有することもできます。
シークレットを MSK クラスターに関連付けた後、MSK は定期的に認証データを同期します。
**Topics**
+ [サインイン認証情報認証の仕組み](msk-password-howitworks.md)
+ [Amazon MSK クラスターの SASL/SCRAM 認証を設定する](msk-password-tutorial.md)
+ [ユーザーの使用](msk-password-users.md)
+ [SCRAM シークレットを使用する場合の制限事項](msk-password-limitations.md)
# サインイン認証情報認証の仕組み
Amazon MSK のサインイン認証情報認証では、SASL/SCRAM (Simple Authentication and Security Layer/Salted Challenge Response Mechanism) 認証を使用します。クラスターのサインイン認証情報認証を設定するには、「[AWS Secrets Manager](https://docs.aws.amazon.com//secretsmanager/?id=docs_gateway)」でシークレットリソースを作成し、サインイン認証情報をそのシークレットに関連付けます。
SASL/SCRAMは、[RFC 5802](https://tools.ietf.org/html/rfc5802)で定義されています。SCRAM は、セキュリティで保護されたハッシュアルゴリズムを使用し、クライアントとサーバー間でプレーンテキストのサインイン認証情報を送信しません。
**注記**
クラスターに SASL/SCRAM 認証を設定すると、Amazon MSK はクライアントとブローカー間のすべてのトラフィックに対して TLS 暗号化をオンにします。
# Amazon MSK クラスターの SASL/SCRAM 認証を設定する
AWS Secrets Manager でシークレットを設定するには、Secrets Manager [ユーザーガイドの「シークレットの作成と取得](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html)」チュートリアルに従います。 [AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)
Amazon MSK クラスターのシークレットを作成するときは、次の要件に注意してください。
+ シークレットタイプには、**他のタイプのシークレット (API キーなど)** を選択します。
+ シークレット名は、プレフィックス **AmazonMSK\$1** から始まる必要があります。
+ 既存のカスタム AWS KMS キーを使用するか、シークレットの新しいカスタム AWS KMS キーを作成する必要があります。Secrets Manager は、デフォルトでシークレットのデフォルト AWS KMS キーを使用します。
**重要**
デフォルト AWS KMS キーで作成されたシークレットは、Amazon MSK クラスターでは使用できません。
+ **[プレーンテキスト]** オプションを使用してキーと値のペアを入力するには、サインイン認証情報データは次の形式である必要があります。
```
{
"username": "alice",
"password": "alice-secret"
}
```
+ シークレットの ARN (Amazon リソース名) 値をレコードします。
+
**重要**
「[クラスターの適切なサイズ設定: 標準ブローカーあたりのパーティション数](bestpractices.md#partitions-per-broker)」で説明されている制限を超えるクラスターに Secrets Manager シークレットを関連付けることはできません。
+ を使用してシークレット AWS CLI を作成する場合は、 `kms-key-id`パラメータのキー ID または ARN を指定します。エイリアスは指定しないでください。
+ シークレットをクラスターに関連付けるには、Amazon MSK コンソールまたは [BatchAssociateScramSecret](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-scram-secrets.html#BatchAssociateScramSecret) オペレーションのいずれかを使用します。
**重要**
シークレットをクラスターに関連付けると、Amazon MSK はそのシークレットにリソースポリシーをアタッチします。これにより、定義したシークレット値にクラスターがアクセスして読み取ることができるようになります。このリソースポリシーは変更しないでください。変更すると、クラスターがシークレットにアクセスできなくなる可能性があります。シークレットリソースポリシーやシークレット暗号化に使用される KMS キーに変更を加えた場合は、必ずシークレットを MSK クラスターに再度関連付けてください。これにより、クラスターがシークレットに引き続きアクセスできるようになります。
次の `BatchAssociateScramSecret` オペレーションの JSON 入力の例は、シークレットをクラスターに関連付けます。
```
{
"clusterArn" : "arn:aws:kafka:us-west-2:0123456789019:cluster/SalesCluster/abcd1234-abcd-cafe-abab-9876543210ab-4",
"secretArnList": [
"arn:aws:secretsmanager:us-west-2:0123456789019:secret:AmazonMSK_MyClusterSecret"
]
}
```
# サインイン認証情報を使用したクラスターへの接続
シークレットを作成してクラスターに関連付けると、クライアントをクラスターに接続できます。次の手順は、SASL/SCRAM 認証を使用するクラスターにクライアントを接続する方法を示しています。また、トピックの例に対して生成および消費する方法も示します。
**Topics**
+ [SASL/SCRAM 認証を使用してクライアントをクラスターに接続する](#w2aab9c13c29c17c13c11b9b7)
+ [接続の問題のトラブルシューティング](#msk-password-tutorial-connect-troubleshooting)
## SASL/SCRAM 認証を使用してクライアントをクラスターに接続する
1. AWS CLI がインストールされているマシンで次のコマンドを実行します。*cluster-ARN* を自身のクラスター ARN に置き換えます。
```
aws kafka get-bootstrap-brokers --cluster-arn clusterARN
```
このコマンドの JSON 結果から、`BootstrapBrokerStringSaslScram` という名前の文字列に関連付けられた値を保存します。この値は後のステップで使用します。
1. クライアントマシンで、シークレットに保存されているユーザー認証情報を含む JAAS 設定ファイルを作成します。例えば、ユーザー **alice** の場合、次の内容を含む `users_jaas.conf` という名前のファイルを作成します。
```
KafkaClient {
org.apache.kafka.common.security.scram.ScramLoginModule required
username="alice"
password="alice-secret";
};
```
1. 次のコマンドを使用して、JAAS 設定ファイルを `KAFKA_OPTS` 環境パラメータとしてエクスポートします。
```
export KAFKA_OPTS=-Djava.security.auth.login.config=/users_jaas.conf
```
1. `/tmp` ディレクトリに `kafka.client.truststore.jks` という名前のファイルを作成します。
1. (オプション)次のコマンドを使用して、 JVM `cacerts` フォルダから JDK キーストアファイルを、前の手順で作成した`kafka.client.truststore.jks`ファイルにコピーします。*JDKFolder* は、インスタンス上の JDK フォルダの名前に置き換えてください。例えば、JDK フォルダには `java-1.8.0-openjdk-1.8.0.201.b09-0.amzn2.x86_64` という名前が付いている場合があります。
```
cp /usr/lib/jvm/JDKFolder/lib/security/cacerts /tmp/kafka.client.truststore.jks
```
1. Apache Kafka のインストール済み環境の `bin` ディレクトリに、次の内容を含む `client_sasl.properties` という名前のクライアントプロパティファイルを作成します。このファイルは、SASL メカニズムとプロトコルを定義します。
```
security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-512
```
1. 例となるトピックを作成するには、次のコマンドを実行します。*BootstrapBrokerStringSaslScram* を、このトピックの手順 1 で取得したブートストラップブローカー文字列に置き換えます。
```
/bin/kafka-topics.sh --create --bootstrap-server BootstrapBrokerStringSaslScram --command-config /client_sasl.properties --replication-factor 3 --partitions 1 --topic ExampleTopicName
```
1. 作成したサンプルトピックにデータを生成するには、クライアントマシンで次のコマンドを実行します。*BootstrapBrokerStringSaslScram* を、このトピックの手順 1 で取得したブートストラップブローカー文字列に置き換えます。
```
/bin/kafka-console-producer.sh --broker-list BootstrapBrokerStringSaslScram --topic ExampleTopicName --producer.config client_sasl.properties
```
1. 作成したトピックからデータを消費するには、クライアントマシンで次のコマンドを実行します。*BootstrapBrokerStringSaslScram* を、このトピックの手順 1 で取得したブートストラップブローカー文字列に置き換えます。
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBrokerStringSaslScram --topic ExampleTopicName --from-beginning --consumer.config client_sasl.properties
```
## 接続の問題のトラブルシューティング
Kafka クライアントコマンドを実行する際、特に大規模なトピックやデータセットを操作する場合、Java ヒープメモリエラーが発生する可能性があります。これらのエラーは、Kafka ツールが Java アプリケーションとしてデフォルトのメモリ設定で実行されるため、ワークロードに対して不十分な場合があります。
`Out of Memory Java Heap` エラーを解決するには、`KAFKA_OPTS` 環境変数を変更してメモリ設定を含めることで、Java ヒープサイズを増やすことができます。
次の例では、ヒープの最大サイズを 1GB (`-Xmx1G`) に設定します。この値は、使用可能なシステムメモリと要件に基づいて調整できます。
```
export KAFKA_OPTS="-Djava.security.auth.login.config=/users_jaas.conf -Xmx1G"
```
大規模なトピックを消費する場合、メモリ使用量を抑えるために、`--from-beginning` の代わりに時間ベースまたはオフセットベースのパラメータの使用を検討してください。
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBrokerStringSaslScram --topic ExampleTopicName --max-messages 1000 --consumer.config client_sasl.properties
```
# ユーザーの使用
**ユーザーの作成：**キーバリューのペアとして秘密のユーザーを作成します。Secrets Manager コンソールで **[プレーンテキスト]** オプションを使用する場合は、サインイン認証情報データを次の形式で指定する必要があります。
```
{
"username": "alice",
"password": "alice-secret"
}
```
**ユーザーアクセスの取り消し：**クラスターにアクセスするためのユーザーの認証情報を取り消すには、最初にクラスターの ACL を削除または適用してから、シークレットの関連付けを解除することをお勧めします。これは、次の理由によるものです。
+ ユーザーを削除しても既存の接続は閉じられません。
+ シークレットへの変更が反映されるまでに最大 10 分かかります。
Amazon MSK で ACL を使用する方法については、「[Apache Kafka ACL](msk-acls.md)」を参照してください。
ZooKeeper モードを使用するクラスターの場合、ユーザーが ACL を変更できないように、ZooKeeper ノードへのアクセスを制限することをお勧めします。詳細については、「[Amazon MSK クラスター内の Apache ZooKeeper ノードへのアクセスを制御する](zookeeper-security.md)」を参照してください。
# SCRAM シークレットを使用する場合の制限事項
SCRAM シークレットを使用する場合は、次の制限に注意してください。
+ Amazon MSK は、SCRAM-SHA-512 認証のみをサポートします。
+ Amazon MSK クラスターには、最大 1000 人のユーザーを含めることができます。
+ シークレット AWS KMS key で を使用する必要があります。デフォルトの Secrets Manager 暗号化キーを使用するシークレットを Amazon MSK で使用することはできません。KMS キーの作成については、「[対称暗号化 KMS キーの作成](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk)」を参照してください。
+ Secrets Manager で非対称 KMS キーを使用することはできません。
+ [BatchAssociateScramSecret](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-scram-secrets.html#BatchAssociateScramSecret) オペレーションを使用して、一度に最大 10 個のシークレットをクラスターに関連付けることができます。
+ Amazon MSK クラスターに関連付けられているシークレットの名前には、プレフィックス **Amazon MSK\$1** が必要です。
+ Amazon MSK クラスターに関連付けられたシークレットは、クラスターと同じ Amazon Web Services アカウントと AWS リージョンに存在する必要があります。
# Apache Kafka ACL
Apache Kafka には、プラグイン可能なオーソライザーがあり、すぐに使用できるオーソライザーの実装とともに出荷されます。Amazon MSK では、ブローカーの `server.properties` ファイルでこのオーソライザーが有効になります。
Apache Kafka ACL の形式は、「プリンシパル P は [許可/拒否] オペレーション O です。ResourcePattern RP に一致する任意のリソース R のホスト H から」です。RP が特定のリソース R と一致しない場合、R には ACL が関連付けられていないため、スーパーユーザー以外は R にアクセスできません。この Apache Kafka の動作を変更するには、プロパティ `allow.everyone.if.no.acl.found` を true に設定します。Amazon MSK は、デフォルトで true に設定します。これは、Amazon MSK クラスターでは、リソースに ACL を明示的に設定しない場合、すべてのプリンシパルがこのリソースにアクセスできることを意味します。リソースで ACL を有効にすると、許可されたプリンシパルのみがリソースにアクセスできます。トピックへのアクセスを制限し、TLS 相互認証を使用してクライアントを認可する場合は、Apache Kafka オーソライザー CLI を使用して ACL を追加します。ACL の追加、削除、および一覧表示の詳細については、[Kafka 認可コマンドラインインターフェイス](https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Authorization+Command+Line+Interface)を参照してください。
Amazon MSK はブローカーをスーパーユーザーとして設定するため、すべてのトピックにアクセスできます。これにより、`allow.everyone.if.no.acl.found` プロパティがクラスターの設定に定義されているかどうかにかかわらず、ブローカーはプライマリパーティションからメッセージを複製できるようになります。
**トピックに対する読み取りおよび書き込みアクセス権を追加するか削除するには**
1. ブローカーを ACL テーブルに追加して、ACL が設定されているすべてのトピックから読み取りを実行できるようにします。ブローカーにトピックへの読み取りアクセスを許可するには、MSK クラスターと通信できるクライアントマシンで次のコマンドを実行します。
*Distinguished-Name* をクラスターのブートストラップブローカーの DNS に置き換え、この識別名の最初のピリオドより前の文字列をアスタリスク (`*`) に置き換えます。たとえば、クラスターのブートストラップブローカーの 1 つに DNS `b-6.mytestcluster.67281x.c4.kafka.us-east-1.amazonaws.com` がある場合は、以下のコマンドの *Distinguished-Name* を `*.mytestcluster.67281x.c4.kafka.us-east-1.amazonaws.com` に置き換えます。ブートストラップブローカーを取得する方法については、「[Amazon MSK クラスターのブートストラップブローカーを取得する](msk-get-bootstrap-brokers.md)」を参照してください。
```
/bin/kafka-acls.sh --bootstrap-server BootstrapServerString --add --allow-principal "User:CN=Distinguished-Name" --operation Read --group=* --topic Topic-Name
```
1. クライアントアプリケーションに、トピックへの読み取りアクセス権を付与するには、クライアントマシンで次のコマンドを実行します。相互 TLS 認証を使用する場合は、プライベートキーの作成時に使用したのと同じ *Distinguished-Name* を使用します。
```
/bin/kafka-acls.sh --bootstrap-server BootstrapServerString --add --allow-principal "User:CN=Distinguished-Name" --operation Read --group=* --topic Topic-Name
```
読み取りアクセス権を削除するには、同じコマンドを実行し、`--add` を `--remove` に置き換えます。
1. トピックへの書き込みアクセス権を付与するには、クライアントマシンで次のコマンドを実行します。相互 TLS 認証を使用する場合は、プライベートキーの作成時に使用したのと同じ *Distinguished-Name* を使用します。
```
/bin/kafka-acls.sh --bootstrap-server BootstrapServerString --add --allow-principal "User:CN=Distinguished-Name" --operation Write --topic Topic-Name
```
書き込みアクセス権を削除するには、同じコマンドを実行し、`--add` を `--remove` に置き換えます。
# Amazon MSK クラスターのセキュリティグループの変更
このページでは、既存の MSK クラスターのセキュリティグループを変更する方法について説明します。特定のユーザーセットにアクセスを提供したり、クラスターへのアクセスを制限したりするために、クラスターのセキュリティグループを変更する必要がある場合があります。セキュリティグループの詳細については、「Amazon VPC ユーザーガイド」の[VPCのセキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)を参照してください。
1. クラスター内のブローカーのリストを取得する AWS CLI には、 の [ListNodes](https://docs.amazonaws.cn/en_us/msk/1.0/apireference/clusters-clusterarn-nodes.html#ListNodes) API または [list-nodes](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/list-nodes.html) コマンドを使用します。このオペレーションの結果には、ブローカーに関連付けられている Elastic Network Interface (ENI) の ID が含まれます。
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) で Amazon EC2 コンソールを開きます。
1. 画面の右上隅にあるドロップダウンリストを使用して、クラスターが展開されているリージョンを選択します。
1. 左側のペインの **Network & Security** (ネットワークとセキュリティ) で、**Network Interfaces** (ネットワークインターフェイス) を選択します。
1. 最初のステップで取得した最初の ENI を選択します。画面上部の **Actions** (アクション) メニューを選択し、[**Change Security Groups**] (セキュリティグループの変更) を選択します。この ENI に新しいセキュリティグループを割り当てます。最初のステップで取得した ENI ごとに、このステップを繰り返します。
**注記**
Amazon EC2 コンソールを使用してクラスターのセキュリティグループに対して行った変更は、MSK コンソールの **[ネットワーク設定]** には反映されません。
1. クライアントがブローカーにアクセスできるように、新しいセキュリティグループのルールを構成します。セキュリティグループルールの設定については、「Amazon VPC ユーザーガイド」の[ルールの追加、削除、更新](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html?shortFooter=true#AddRemoveRules)を参照してください。
**重要**
クラスターのブローカーに関連付けられているセキュリティグループを変更してから、そのクラスターに新しいブローカーを追加すると、Amazon MSK は、クラスターの作成時にクラスターに関連付けられていた元のセキュリティグループに新しいブローカーを関連付けます。ただし、クラスターが正しく機能するには、すべてのブローカーが同じセキュリティグループに関連付けられている必要があります。したがって、セキュリティグループを変更した後に新しいブローカーを追加する場合は、前の手順を再度実行して、新しいブローカーの ENI を更新する必要があります。
# Amazon MSK クラスター内の Apache ZooKeeper ノードへのアクセスを制御する
セキュリティ上の理由から、Amazon MSK クラスターの一部である Apache ZooKeeper ノードへのアクセスを制限できます。ノードへのアクセスを制限するには、それらに別のセキュリティグループを割り当てます。その後、そのセキュリティグループにアクセスできるユーザーを決定できます。
**重要**
このセクションは、KRaft モードで実行されているクラスターには適用されません。「[KRaft モード](metadata-management.md#kraft-intro)」を参照してください。
**Topics**
+ [Apache ZooKeeper ノードを別のセキュリティグループに配置するには](zookeeper-security-group.md)
+ [Apache ZooKeeper での TLS セキュリティの使用](zookeeper-security-tls.md)
# Apache ZooKeeper ノードを別のセキュリティグループに配置するには
Apache ZooKeeper ノードへのアクセスを制限するには、それらに別のセキュリティグループを割り当てます。セキュリティグループルールを設定することで、この新しいセキュリティグループにアクセスできるユーザーを選択できます。
1. クラスターの Apache ZooKeeper 接続文字列を取得します。この方法の詳細は、「[ZooKeeper モード](metadata-management.md#msk-get-connection-string)」を参照してください。接続文字列には、Apache ZooKeeper ノードの DNS 名が含まれています。
1. `host` や `ping` などのツールを使用して、前の手順で取得した DNS 名を IP アドレスに変換します。この手順の後半で必要になるため、これらの IP アドレスを保存します。
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) で Amazon EC2 コンソールを開きます。
1. 左側のペインの [**Network & Security (ネットワークとセキュリティ)**] で、[**Network Interfaces (ネットワークインターフェイス)**] を選択します。
1. ネットワークインターフェイスのテーブルの上にある検索フィールドに、クラスターの名前を入力し、「return」と入力します。これにより、テーブルに表示されるネットワークインターフェイスの数を、クラスターに関連付けられたインターフェイスの数に制限します。
1. リストの最初のネットワークインターフェイスに対応する行の先頭にあるチェックボックスをオンにします。
1. ページの下部にある詳細ペインで、[**Primary private IPv4 IP (プライマリプライベート IPv4 IP)**] を探します。この IP アドレスがこの手順の最初に取得した IP アドレスのいずれかに一致する場合は、このネットワークインターフェイスがクラスターの一部である Apache ZooKeeper ノードに割り当てられていることを意味します。それ以外の場合は、このネットワークインターフェイスの隣にあるチェックボックスをオフにして、リスト内の次のネットワークインターフェイスを選択します。ネットワークインターフェイスを選択する順序は関係ありません。以降のステップでは、Apache ZooKeeper ノードに割り当てられているすべてのネットワークインターフェイスで、同じオペレーションを 1 つずつ実行します。
1. Apache ZooKeeper ノードに対応するネットワークインターフェイスを選択する場合は、ページ上部の [**Actions (アクション)**] メニューを選択し、[**Change Security Groups (セキュリティグループを変更)**] を選択します。このネットワークインターフェイスに新しいセキュリティグループを割り当てます。セキュリティグループの作成については、Amazon VPC ドキュメントの[セキュリティグループの作成](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html?shortFooter=true#CreatingSecurityGroups)を参照してください。
1. 前のステップを繰り返して、クラスターの Apache ZooKeeper ノードに関連付けられているすべてのネットワークインターフェイスに同じ新しいセキュリティグループを割り当てます。
1. これで、この新しいセキュリティグループにアクセスできるユーザーを選択できるようになりました。セキュリティグループルールの設定については、Amazon VPC ドキュメントの[ルールの追加、削除、更新](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html?shortFooter=true#AddRemoveRules)を参照してください。
# Apache ZooKeeper での TLS セキュリティの使用
クライアントと Apache ZooKeeper ノード間の転送中の暗号化に TLS セキュリティを使用できます。Apache ZooKeeper ノードで TLS セキュリティを実装するには、次の手順を実行します。
+ Apache ZooKeeper で TLS セキュリティを使用するには、クラスターで Apache Kafka バージョン 2.5.1 以降を使用する必要があります。
+ クラスターを作成または構成するときに TLS セキュリティを有効にします。Apache Kafka バージョン 2.5.1 以降で TLS を有効にして作成されたクラスターは、Apache ZooKeeper エンドポイントで TLS セキュリティを自動的に使用します。TLS セキュリティの設定については、「[Amazon MSK 暗号化の使用を開始する](msk-working-with-encryption.md)」を参照してください。
+ [DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster) オペレーションを使用して TLS Apache ZooKeeper エンドポイントを取得します。
+ `kafka-configs.sh` および [https://kafka.apache.org/documentation/#security_authz_cli](https://kafka.apache.org/documentation/#security_authz_cli) ツールで使用する、または ZooKeeper シェルで使用する Apache ZooKeeper 設定ファイルを作成します。各ツールでは、`--zk-tls-config-file` パラメータを使用して Apache ZooKeeper の設定を指定します。
次の例は、典型的な Apache ZooKeeper 設定ファイルを示しています。
```
zookeeper.ssl.client.enable=true
zookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty
zookeeper.ssl.keystore.location=kafka.jks
zookeeper.ssl.keystore.password=test1234
zookeeper.ssl.truststore.location=truststore.jks
zookeeper.ssl.truststore.password=test1234
```
+ その他のコマンド (`kafka-topics` など) の場合は、`KAFKA_OPTS` 環境変数を使用して Apache ZooKeeper パラメーターを設定する必要があります。次の例は、Apache ZooKeeper パラメーターを他のコマンドに渡すように `KAFKA_OPTS` 環境変数を設定する方法を示しています。
```
export KAFKA_OPTS="
-Dzookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty
-Dzookeeper.client.secure=true
-Dzookeeper.ssl.trustStore.location=/home/ec2-user/kafka.client.truststore.jks
-Dzookeeper.ssl.trustStore.password=changeit"
```
`KAFKA_OPTS` 環境変数を設定すると、CLI コマンドを通常どおりに使用できます。次の例では、`KAFKA_OPTS` 環境変数の Apache ZooKeeper 設定を使用して Apache Kafka トピックを作成します。
```
/bin/kafka-topics.sh --create --zookeeper ZooKeeperTLSConnectString --replication-factor 3 --partitions 1 --topic AWSKafkaTutorialTopic
```
**注記**
Apache ZooKeeper 設定ファイルで使用するパラメーターの名前と、`KAFKA_OPTS` 環境可変で使用するパラメーターの名前は一貫していません。設定ファイルおよび `KAFKA_OPTS` 環境変数の、どのパラメーターでどの名前を使用するかに注意してください。
TLS を使用して Apache ZooKeeper ノードにアクセスする方法の詳細については、[KIP-515: ZK クライアントが新しい TLS でサポートされている認証を使用できるようにする](https://cwiki.apache.org/confluence/display/KAFKA/KIP-515%3A+Enable+ZK+client+to+use+the+new+TLS+supported+authentication)を参照してください。
# Amazon Managed Streaming for Apache Kafka のコンプライアンス検証
サードパーティーの監査人は、 AWS コンプライアンスプログラムの一環として、Amazon Managed Streaming for Apache Kafka とコンプライアンスを評価します。これらには、PCI および HIPAA BAA が含まれます。
特定のコンプライアンスプログラムの対象となる AWS サービスのリストについては、「コンプライアンスプログラム[による対象範囲内のアマゾン サービスコンプライアンスプログラム](https://aws.amazon.com/compliance/services-in-scope/)」を参照してください。一般的な情報については、[AWS 「 Compliance ProgramsAssurance](https://aws.amazon.com/compliance/programs/)」を参照してください。
を使用して、サードパーティーの監査レポートをダウンロードできます AWS Artifact。詳細については、[「Downloading Reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)」を参照してください。
Amazon MSK を使用する際のお客様のコンプライアンス責任は、お客様のデータの機密性、貴社のコンプライアンス目的、適用される法律および規制によって決まります。 は、コンプライアンスに役立つ以下のリソース AWS を提供します。
+ 「[セキュリティ＆コンプライアンスクイックリファレンスガイド](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance)」 – これらのデプロイガイドには、アーキテクチャ上の考慮事項の説明と、 AWSでセキュリティとコンプライアンスに重点を置いたベースライン環境をデプロイするための手順が記載されています。
+ [「Architecting for HIPAA Security and Compliance」ホワイトペーパー](https://docs.aws.amazon.com/whitepapers/latest/architecting-hipaa-security-and-compliance-on-aws/architecting-hipaa-security-and-compliance-on-aws.html) – このホワイトペーパーでは、企業が AWS を使用して HIPAA 準拠のアプリケーションを作成する方法について説明します。
+ [AWS コンプライアンスリソース](https://aws.amazon.com/compliance/resources/) – このワークブックとガイドのコレクションは、お客様の業界や地域に適用される場合があります。
+ [「 デベロッパーガイド」の「ルールによるリソースの評価](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)」 – この AWS Config サービスは、リソース設定が内部プラクティス、業界ガイドライン、および規制にどの程度準拠しているかを評価します。 *AWS Config *
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) – この AWS サービスは、 内のセキュリティ状態を包括的に把握 AWS し、セキュリティ業界標準とベストプラクティスへの準拠を確認するのに役立ちます。
# Amazon Managed Streaming for Apache Kafka の復元力
AWS グローバルインフラストラクチャは、 AWS リージョンとアベイラビリティーゾーンを中心に構築されています。 AWS リージョンは、低レイテンシー、高スループット、高度に冗長なネットワークで接続された複数の物理的に分離されたアベイラビリティーゾーンを提供します。アベイラビリティーゾーンでは、ゾーン間で中断することなく自動的にフェールオーバーするアプリケーションとデータベースを設計および運用することができます。アベイラビリティーゾーンは、従来の単一または複数のデータセンターインフラストラクチャよりも可用性、フォールトトレランス、および拡張性が優れています。
AWS リージョンとアベイラビリティーゾーンの詳細については、[AWS 「 グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)」を参照してください。
# Amazon Managed Streaming for Apache Kafka におけるインフラストラクチャセキュリティ
マネージドサービスである Amazon Managed Streaming for Apache Kafka は、ホワイトペーパー[「Amazon Web Services: セキュリティプロセスの概要](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf)」に記載されている AWS グローバルネットワークセキュリティ手順で保護されています。
AWS 公開された API コールを使用して、ネットワーク経由で Amazon MSK にアクセスします。クライアントで Transport Layer Security (TLS) 1.0 以降がサポートされている必要があります。TLS 1.2 以降が推奨されています。また、Ephemeral Diffie-Hellman (DHE) や Elliptic Curve Ephemeral Diffie-Hellman (ECDHE) などの Perfect Forward Secrecy (PFS) を使用した暗号スイートもクライアントでサポートされている必要があります。これらのモードは、Java 7 以降など、最近のほとんどのシステムでサポートされています。
また、リクエストにはアクセスキー ID と、IAM プリンシパルに関連付けられているシークレットアクセスキーを使用して署名する必要があります。または、[AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) を使用して、一時的なセキュリティ認証情報を生成し、リクエストに署名することもできます。
# Amazon MSK ログ記録
Apache Kafka ブローカーログは、Amazon CloudWatch Logs、Amazon S3、Amazon Data Firehose の 1 つまたは複数の配信先タイプに配信できます。を使用して Amazon MSK API コールを記録することもできます AWS CloudTrail。
**注記**
ブローカーログは、MSK Standard ブローカーと Express ブローカーの両方で使用できます。
## ブローカーログ
ブローカーログを使用すると、Apache Kafka アプリケーションのトラブルシューティングを行い、MSK クラスターとの通信を分析できます。新規または既存の MSK クラスターを設定して、INFO レベルのブローカーログを CloudWatch ロググループ、S3 バケット、Firehose 配信ストリームの 1 つまたは複数の配信先リソースのタイプに配信できます。その後、Firehose を使用して、配信ストリームから OpenSearch Service にログデータを配信できます。
ブローカーログをクラスターに配信するようにクラスターを設定する前に、宛先リソースを作成する必要があります。Amazon MSK は、これらの宛先リソースがまだ存在しない場合、それらを作成しません。これらの 3 種類の宛先リソースとその作成方法については、次のドキュメントを参照してください。
+ [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/Welcome.html)
+ [Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html)
### 必要なアクセス許可
Amazon MSK ブローカーログの送信先を設定するには、Amazon MSK アクションに使用する IAM ID に、[AWS マネージドポリシー: AmazonMSKFullAccess](security-iam-awsmanpol-AmazonMSKFullAccess.md) ポリシーに記載されているアクセス許可が必要です。
ブローカーログを S3 バケットにストリーミングするには、`s3:PutBucketPolicy` アクセス許可も必要です。S3 バケットポリシーについては、「Amazon S3 ユーザーガイド」の「[S3 バケットポリシーを追加する方法](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/add-bucket-policy.html)」を参照してください。一般的な IAM ポリシーの詳細については、 「IAM ユーザーガイド」の[アクセス管理](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html)を参照してください。
### SSE-KMS バケットで使用するために必要な KMS キーポリシー
カスタマーマネージドキーで マネージドキー (SSE-KMS) AWS KMSを使用して S3 バケットのサーバー側の暗号化を有効にした場合は、Amazon MSK がバケットにブローカーファイルを書き込めるように、KMS キーのキーポリシーに以下を追加します。
```
{
"Sid": "Allow Amazon MSK to use the key.",
"Effect": "Allow",
"Principal": {
"Service": [
"delivery.logs.amazonaws.com"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
}
```
### を使用してブローカーログを設定する AWS マネジメントコンソール
新しいクラスターを作成する場合は、**Monitoring** (モニタリング) セクションで **ブローカーログ配信** の見出しを探します。Amazon MSK がブローカーログを配信する宛先を指定できます。
既存のクラスターの場合は、クラスターのリストから当該クラスターを選択し、**[プロパティ]** タブを選択します。**[ログ配信]** セクションまで下にスクロールして、**[編集]** ボタンを選択します。Amazon MSK がブローカーログを配信する宛先を指定できます。
### を使用してブローカーログを設定する AWS CLI
`create-cluster` または `update-monitoring` コマンドを使用する場合は、オプションで `logging-info` パラメータを指定し、次の例のように JSON 構造体を渡すことができます。この JSON では、3 つの送信先タイプはすべてオプションです。
**注記**
ログ配信を設定するには、Firehose ストリームで `LogDeliveryEnabled` タグを`true`に設定する必要があります。が CloudWatch Logs 用に AWS 作成するサービスにリンクされたロールは、このタグを使用して、すべての Firehose 配信ストリームにアクセス許可を付与します。このタグを削除すると、サービスにリンクされたロールは Firehose ストリームにログを配信できなくなります。サービスにリンクされたロールに含まれるアクセス許可を示す IAM ポリシーの例については、*Amazon CloudWatch ユーザーガイド*の[「リソースアクセス許可に使用される IAM ロール」](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-infrastructure-V2-Firehose.html)を参照してください。
```
{
"BrokerLogs": {
"S3": {
"Bucket": "amzn-s3-demo-bucket",
"Prefix": "ExamplePrefix",
"Enabled": true
},
"Firehose": {
"DeliveryStream": "ExampleDeliveryStreamName",
"Enabled": true
},
"CloudWatchLogs": {
"Enabled": true,
"LogGroup": "ExampleLogGroupName"
}
}
}
```
### API を使用してブローカーログを設定する
[CreateCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster)または[UpdateMonitoring](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-monitoring.html#UpdateMonitoring)オペレーションに渡す JSON でオプションの `loggingInfo` 構造を指定できます。
**注記**
デフォルトでは、ブローカーロギングが有効になっている場合、Amazon MSK は `INFO` レベルのログを指定された宛先に記録します。ただし、スタンダードブローカーの場合、Apache Kafka 2.4.X 以降のユーザーはブローカーログレベルを任意の [log4j ログレベル](https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Level.html)に動的に設定できます。ブローカーのログレベルを動的に設定する方法については、[KIP-412: 動的なアプリケーションログレベルをサポートするように管理者 API を拡張する](https://cwiki.apache.org/confluence/display/KAFKA/KIP-412%3A+Extend+Admin+API+to+support+dynamic+application+log+levels)を参照してください。ログレベルを `DEBUG` または `TRACE` に動的に設定する場合は、ログの送信先として Amazon S3 または Firehose を使用することをお勧めします。CloudWatch Logs をログの宛先として使用し、`DEBUG` または `TRACE` レベルのロギングを動的に有効にした場合、Amazon MSK はログのサンプルを継続的に配信する場合があります。これはブローカーのパフォーマンスに大きな影響を与える可能性があるため、`INFO` ログレベルが問題の根本原因を特定するのに十分なほど詳細でない場合にのみ使用する必要があります。
# を使用した API コールのログ記録 AWS CloudTrail
**注記**
AWS CloudTrail ログは、 を使用する場合にのみ Amazon MSK で使用できます[IAM アクセスコントロール](iam-access-control.md)。
Amazon MSK は AWS CloudTrail、Amazon MSK のユーザー、ロール、または のサービスによって実行されたアクションを記録する AWS サービスである と統合されています。CloudTrail は、API コールをイベントとしてキャプチャします。キャプチャされた呼び出しには、Amazon MSK コンソールからの呼び出しと Amazon MSK API オペレーションへのコード呼び出しが含まれます。また、トピックやグループの作成や変更などの Apache Kafka アクションもキャプチャします。
追跡を作成すると、Amazon MSK のイベントを含め、CloudTrail イベントを Amazon S3 バケットに継続的に配信できるようになります。追跡を設定しない場合でも、CloudTrail コンソールの **Event history ** (イベント履歴) で最新のイベントを表示できます。CloudTrail によって収集された情報を使用して、Amazon MSK または Apache Kafka アクションに対して行われた要求、要求が行われた IP アドレス、要求を行った人、要求が行われた日時、および追加の詳細を判別できます。
CloudTrail の設定や有効化の方法など、CloudTrail の詳細については、「[AWS CloudTrail ユーザーガイド](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/)」を参照してください。
## CloudTrail の Amazon MSK 情報
アカウントを作成すると、Amazon Web Services アカウントで CloudTrail が有効になります。MSK クラスターでサポートされているイベントアクティビティが発生すると、そのアクティビティはイベント**履歴**の他の AWS サービスイベントとともに CloudTrail イベントに記録されます。AWS アカウントでの最近のイベントを表示、検索、ダウンロードできます。詳細については、[CloudTrail イベント履歴を使用したイベントの表示](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html)を参照してください。
Amazon MSK のイベントを含む、Amazon Web Services アカウントのイベントの継続的なレコードについては、追跡を作成してください。*追跡*により、CloudTrail はログファイルを Amazon S3 バケットに配信できます。デフォルトでは、コンソールで証跡を作成すると、すべての リージョンに証跡が適用されます。追跡は AWS パーティション内のすべてのリージョンからのイベントをログに記録し、指定した Amazon S3 バケットにログファイルを配信します。さらに、CloudTrail ログに収集されたイベントデータをさらに分析して処理するように他の Amazon サービスを設定できます。詳細については、次を参照してください:
+ [証跡の作成のための概要](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [CloudTrail がサポートするサービスと統合](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations)
+ [CloudTrail 用 Amazon SNS 通知の構成](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html)
+ [複数のリージョンから CloudTrail ログファイルを受け取る](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html)および[複数のアカウントから CloudTrail ログファイルを受け取る](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)
Amazon MSK は、すべての [Amazon MSK オペレーション](https://docs.aws.amazon.com/MSK/2.0/APIReference/operations.html)をイベントとして CloudTrail ログファイルに記録します。さらに、次の Apache Kafka アクションをログに記録します。
+ kafka-cluster:DescribeClusterDynamicConfiguration
+ kafka-cluster:AlterClusterDynamicConfiguration
+ kafka-cluster:CreateTopic
+ kafka-cluster:DescribeTopicDynamicConfiguration
+ kafka-cluster:AlterTopic
+ kafka-cluster:AlterTopicDynamicConfiguration
+ kafka-cluster:DeleteTopic
各イベントまたはログエントリには、誰がリクエストを生成したかという情報が含まれます。アイデンティティ情報は、以下を判別するのに役立ちます。
+ リクエストがルートユーザーまたは AWS Identity and Access Management (IAM) ユーザー認証情報を使用して行われたかどうか。
+ リクエストがロールまたはフェデレーションユーザーのテンポラリなセキュリティ認証情報を使用して行われたかどうか。
+ リクエストが別の AWS サービスによって行われたかどうか。
詳細については、「[CloudTrail userIdentity 要素](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html)」を参照してください。
## 例 : Amazon MSK ログ ファイルエントリ
「トレイル」は、指定した Amazon S3 バケットにイベントをログファイルとして配信するように設定できます。CloudTrail のログファイルは、単一か複数のログエントリを含みます。イベントは、任意のソースからの単一の要求を表し、要求されたアクション、アクションの日時、要求パラメーターなどに関する情報が含まれます。CloudTrail ログファイルは、パブリック API コールと Apache Kafka アクションの順序付けられたスタックトレースではないため、特定の順序で表示されません。
次の例は、`DescribeCluster` および `DeleteCluster` Amazon MSK アクションを示す CloudTrail ログエントリを示しています。
```
{
"Records": [
{
"eventVersion": "1.05",
"userIdentity": {
"type": "IAMUser",
"principalId": "ABCDEF0123456789ABCDE",
"arn": "arn:aws:iam::012345678901:user/Joe",
"accountId": "012345678901",
"accessKeyId": "AIDACKCEVSQ6C2EXAMPLE",
"userName": "Joe"
},
"eventTime": "2018-12-12T02:29:24Z",
"eventSource": "kafka.amazonaws.com",
"eventName": "DescribeCluster",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.0",
"userAgent": "aws-cli/1.14.67 Python/3.6.0 Windows/10 botocore/1.9.20",
"requestParameters": {
"clusterArn": "arn%3Aaws%3Akafka%3Aus-east-1%3A012345678901%3Acluster%2Fexamplecluster%2F01234567-abcd-0123-abcd-abcd0123efa-2"
},
"responseElements": null,
"requestID": "bd83f636-fdb5-abcd-0123-157e2fbf2bde",
"eventID": "60052aba-0123-4511-bcde-3e18dbd42aa4",
"readOnly": true,
"eventType": "AwsApiCall",
"recipientAccountId": "012345678901"
},
{
"eventVersion": "1.05",
"userIdentity": {
"type": "IAMUser",
"principalId": "ABCDEF0123456789ABCDE",
"arn": "arn:aws:iam::012345678901:user/Joe",
"accountId": "012345678901",
"accessKeyId": "AIDACKCEVSQ6C2EXAMPLE",
"userName": "Joe"
},
"eventTime": "2018-12-12T02:29:40Z",
"eventSource": "kafka.amazonaws.com",
"eventName": "DeleteCluster",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.0",
"userAgent": "aws-cli/1.14.67 Python/3.6.0 Windows/10 botocore/1.9.20",
"requestParameters": {
"clusterArn": "arn%3Aaws%3Akafka%3Aus-east-1%3A012345678901%3Acluster%2Fexamplecluster%2F01234567-abcd-0123-abcd-abcd0123efa-2"
},
"responseElements": {
"clusterArn": "arn:aws:kafka:us-east-1:012345678901:cluster/examplecluster/01234567-abcd-0123-abcd-abcd0123efa-2",
"state": "DELETING"
},
"requestID": "c6bfb3f7-abcd-0123-afa5-293519897703",
"eventID": "8a7f1fcf-0123-abcd-9bdb-1ebf0663a75c",
"readOnly": false,
"eventType": "AwsApiCall",
"recipientAccountId": "012345678901"
}
]
}
```
以下の例は、`kafka-cluster:CreateTopic` アクションを示す CloudTrail ログエントリです。
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "ABCDEFGH1IJKLMN2P34Q5",
"arn": "arn:aws:iam::111122223333:user/Admin",
"accountId": "111122223333",
"accessKeyId": "CDEFAB1C2UUUUU3AB4TT",
"userName": "Admin"
},
"eventTime": "2021-03-01T12:51:19Z",
"eventSource": "kafka-cluster.amazonaws.com",
"eventName": "CreateTopic",
"awsRegion": "us-east-1",
"sourceIPAddress": "198.51.100.0/24",
"userAgent": "aws-msk-iam-auth/unknown-version/aws-internal/3 aws-sdk-java/1.11.970 Linux/4.14.214-160.339.amzn2.x86_64 OpenJDK_64-Bit_Server_VM/25.272-b10 java/1.8.0_272 scala/2.12.8 vendor/Red_Hat,_Inc.",
"requestParameters": {
"kafkaAPI": "CreateTopics",
"resourceARN": "arn:aws:kafka:us-east-1:111122223333:topic/IamAuthCluster/3ebafd8e-dae9-440d-85db-4ef52679674d-1/Topic9"
},
"responseElements": null,
"requestID": "e7c5e49f-6aac-4c9a-a1d1-c2c46599f5e4",
"eventID": "be1f93fd-4f14-4634-ab02-b5a79cb833d2",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"eventCategory": "Management",
"recipientAccountId": "111122223333"
}
```
# メタデータ管理
Amazon MSK では、Apache ZooKeeper または KRaft メタデータ管理モードがサポートされています。
Amazon MSK の Apache Kafka バージョン 3.7.x から、ZooKeeper モードの代わりに KRaft モードを使用するクラスターを作成できます。KRaft ベースのクラスターは、メタデータを管理する際に Kafka 内のコントローラーに依存します。
**Topics**
+ [ZooKeeper モード](#msk-get-connection-string)
+ [KRaft モード](#kraft-intro)
## ZooKeeper モード
[Apache ZooKeeper](https://zookeeper.apache.org/) は、設定情報の維持、名前付け、分散化された同期の提供、およびグループサービスを提供する一元化されたサービスです。これらの種類のサービスはすべて、Apache Kafka を含む分散アプリケーションによって何らかの形で使用されます。
クラスターが ZooKeeper モードを使用している場合は、以下の手順を使用して Apache ZooKeeper 接続文字列を取得できます。ただし、Kafka 2.5 で `--zookeeper` フラグが非推奨になり、Kafka 3.0 から削除されたため、`BootstrapServerString` を使用してクラスターに接続し、管理オペレーションを実行することをお勧めします。
### を使用して Apache ZooKeeper 接続文字列を取得する AWS マネジメントコンソール
1. [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/) で Amazon MSK コンソールを開きます。
1. このテーブルには、このアカウントにある現在のリージョンのすべてのクラスターが表示されます。説明を表示するには、クラスターの名前を選択します。
1. **[Cluster summary]** (クラスターの概要) ページで、**[View client information]** (クライアント情報の表示) を選択します。これにより、ブートストラップブローカーと Apache ZooKeeper 接続文字列が表示されます。
### を使用して Apache ZooKeeper 接続文字列を取得する AWS CLI
1. クラスターの Amazon リソースネーム (ARN) がわからない場合は、アカウント内のすべてのクラスターを一覧表示することで見つけることができます。詳細については、「[Amazon MSK クラスターを一覧表示する](msk-list-clusters.md)」を参照してください。
1. Apache ZooKeeper 接続文字列とクラスターに関するその他の情報を取得するには、*ClusterArn* をクラスターの ARN に置き換えて次のコマンドを実行します。
```
aws kafka describe-cluster --cluster-arn ClusterArn
```
この `describe-cluster` コマンドの出力は、次の JSON の例のようになります。
```
{
"ClusterInfo": {
"BrokerNodeGroupInfo": {
"BrokerAZDistribution": "DEFAULT",
"ClientSubnets": [
"subnet-0123456789abcdef0",
"subnet-2468013579abcdef1",
"subnet-1357902468abcdef2"
],
"InstanceType": "kafka.m5.large",
"StorageInfo": {
"EbsStorageInfo": {
"VolumeSize": 1000
}
}
},
"ClusterArn": "arn:aws:kafka:us-east-1:111122223333:cluster/testcluster/12345678-abcd-4567-2345-abcdef123456-2",
"ClusterName": "testcluster",
"CreationTime": "2018-12-02T17:38:36.75Z",
"CurrentBrokerSoftwareInfo": {
"KafkaVersion": "2.2.1"
},
"CurrentVersion": "K13V1IB3VIYZZH",
"EncryptionInfo": {
"EncryptionAtRest": {
"DataVolumeKMSKeyId": "arn:aws:kms:us-east-1:555555555555:key/12345678-abcd-2345-ef01-abcdef123456"
}
},
"EnhancedMonitoring": "DEFAULT",
"NumberOfBrokerNodes": 3,
"State": "ACTIVE",
"ZookeeperConnectString": "10.0.1.101:2018,10.0.2.101:2018,10.0.3.101:2018"
}
}
```
前述の JSON の例では、`describe-cluster` コマンドの出力の `ZookeeperConnectString` キーを示しています。クラスターにトピックを作成する必要がある場合に備え、このキーに対応する値をコピーして保存します。
**重要**
Apache ZooKeeper 接続文字列を取得できるようにするには、Amazon MSK クラスターが `ACTIVE` の状態である必要があります。クラスターがまだ `CREATING` 状態である場合、`describe-cluster` コマンドの出力に `ZookeeperConnectString` は含まれません。このような場合、数分待ってから、クラスターが `ACTIVE` 状態になった後に `describe-cluster` を再度実行します。
### API を使用した Apache ZooKeeper 接続文字列の取得
API を使用して Apache ZooKeeper 接続文字列を取得するには、「[DescribeCluster](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)」を参照してください。
## KRaft モード
Amazon MSK では、Kafka バージョン 3.7.x で KRaft (Apache Kafka Raft) のサポートが導入されました。Apache Kafka コミュニティでは、[Apache ZooKeeper](#msk-get-connection-string) に代わって Apache Kafka クラスターのメタデータ管理に使用できる KRaft が開発されました。KRaft モードでは、クラスターメタデータは ZooKeeper ノードではなく Kafka クラスターの一部である Kafka コントローラーのグループ内で伝播されます。KRaft コントローラーは追加料金なしで含まれており、追加のセットアップや管理は必要ありません。KRaft の詳細については、「[KIP-500](https://cwiki.apache.org/confluence/display/KAFKA/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum)」を参照してください。
MSK の KRaft モードに関する注意点をいくつか示します。
+ KRaft モードは、新しいクラスターでのみ使用できます。クラスターが作成されると、メタデータモードを切り替えることはできません。
+ MSK コンソールでは、クラスター作成ウィンドウで Kafka バージョン 3.7.x を選択し、KRaft チェックボックスをオンにすると、Kraft ベースのクラスターを作成できます。
+ MSK API の [https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster) または [https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters.html#CreateClusterV2](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters.html#CreateClusterV2) オペレーションを使用して Kraft モードでクラスターを作成するには、`3.7.x.kraft` をバージョンとして指定する必要があります。`3.7.x` をバージョンとして使用して、ZooKeeper モードでクラスターを作成します。
+ ブローカーあたりのパーティション数は、KRaft ベースのクラスターと ZooKeeper ベースのクラスターで同じです。ただし、KRaft では、[クラスターでより多くのブローカー](https://docs.aws.amazon.com/msk/latest/developerguide/limits.html)をプロビジョニングすることで、各クラスターでより多くのパーティションをホストできます。
+ Amazon MSK で KRaft モードを使用するために必要な API の変更はありません。ただし、クライアントが現在も `--zookeeper` 接続文字列を使用している場合は、`--bootstrap-server` 接続文字列を使用してクラスターに接続するようにクライアントを更新する必要があります。`--zookeeper` フラグは Apache Kafka 2.5 で非推奨になり、Kafka 3.0 以降では削除されています。そのため、クラスターへのすべての接続には、最新の Apache Kafka クライアントバージョンと `--bootstrap-server` 接続文字列を使用することをお勧めします。
+ ZooKeeper モードは、ZooKeeper もサポートされているすべての Apache Kafka リリースバージョンで引き続き使用できます。Apache Kafka バージョンのサポート終了と今後の更新の詳細については、「[サポート対象の Apache Kafka バージョン](supported-kafka-versions.md)」を参照してください。
+ 使用するすべてのツールが、ZooKeeper 接続なしで Kafka Admin API を使用できることを確認する必要があります。クラスターを Cruise Control に接続する更新された手順については、「[LinkedIn の Cruise Control for Apache Kafka を Amazon MSK で使用する](cruise-control.md)」を参照してください。Cruise Control には、[ZooKeeper なしで Cruise Control を実行する](https://github.com/linkedin/cruise-control/wiki/Run-without-ZooKeeper)手順もあります。
+ 管理アクションのためにクラスターの KRaft コントローラーに直接アクセスする必要はありません。ただし、オープンモニタリングを使用してメトリクスを収集する場合は、クラスターに関するコントローラー関連以外のメトリクスを収集するため、コントローラーの DNS エンドポイントも必要です。これらの DNS エンドポイントは、MSK コンソールから、または [ListNodes](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-nodes.html#ListNodes) API オペレーションを使用して取得できます。KRaft ベースのクラスター用にオープンモニタリングを設定する更新された手順については、「[Prometheus で MSK プロビジョンドクラスターをモニタリングする](open-monitoring.md)」を参照してください。
+ ZooKeeper モードのクラスターを介して KRaft モードのクラスターをモニタリングする必要がある追加の [CloudWatch メトリクス](https://docs.aws.amazon.com/msk/latest/developerguide/metrics-details.html)はありません。MSK では、クラスターで使用される KRaft コントローラーが管理されます。
+ `--bootstrap-server` 接続文字列を使用して、KRaft モードのクラスターで ACL の管理を継続できます。ACL の管理に `--zookeeper` 接続文字列を使用しないでください。「[Apache Kafka ACL](msk-acls.md)」を参照してください。
+ KRaft モードでは、クラスターのメタデータは Kafka 内の KRaft コントローラーに保存され、外部の ZooKeeper ノードには保存されません。したがって、[ZooKeeper ノードと同様に](https://docs.aws.amazon.com/msk/latest/developerguide/zookeeper-security.html)、コントローラーノードへのアクセスを個別に制御する必要はありません。
# トピックオペレーション
Amazon MSK APIs を使用して、Kafka 管理クライアントを設定および維持しなくても、MSK プロビジョンドクラスター内のトピックを管理できます。これらの APIs を使用すると、保持ポリシーやクリーンアップポリシーなどの設定とともに、レプリケーション係数やパーティション数などのトピックプロパティを定義または読み取ることができます。CLI、 AWS SDKs、Kafka AWS トピックをプログラムで管理できます。 AWS CloudFormation これらの APIsは Amazon MSK コンソールにも統合され、すべてのトピックオペレーションが 1 か所に集約されます。ガイド付きデフォルトを使用して数回クリックするだけで、トピック設定、パーティションレベルの情報、メトリクスを包括的に可視化しながら、トピックを作成または更新できるようになりました。
**重要**
これらのトピックの API レスポンスは、約 1 分ごとに更新されるデータを反映しています。変更後の最新のトピックの状態については、クエリを実行する前に約 1 分かかります。
## トピック APIsを使用するための要件
+ クラスターは MSK プロビジョンドクラスターである必要があります。これらの APIsは MSK Serverless クラスターでは使用できません。
+ クラスターは Apache Kafka バージョン 3.6.0 以降を実行している必要があります。サポートされているバージョンの詳細については、「」を参照してください[サポート対象の Apache Kafka バージョン](supported-kafka-versions.md)。
+ クラスターは `ACTIVE`状態である必要があります。クラスターの状態の詳細については、「[MSK プロビジョンドクラスターの状態を理解する](msk-cluster-states.md)」を参照してください。
+ 適切な IAM アクセス許可が必要です。詳細については、「[トピックオペレーション APIsの IAM アクセス許可](#topic-operations-permissions)」を参照してください。
## トピックオペレーション APIsの IAM アクセス許可
これらの APIs呼び出すには、適切な IAM アクセス許可が必要です。次の表に、各 API に必要なアクセス許可を示します。
**トピックオペレーション APIs に必要なアクセス許可**
| API | 必要な許可 | [リソース] |
| --- | --- | --- |
| ListTopics | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | クラスター ARN、トピック ARN |
| DescribeTopic | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DescribeTopicDynamicConfiguration` | クラスター ARN、トピック ARN |
| DescribeTopicPartitions | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DescribeTopicDynamicConfiguration` | クラスター ARN、トピック ARN |
| CreateTopic | `kafka-cluster:Connect` `kafka-cluster:CreateTopic` | クラスター ARN、トピック ARN |
| DeleteTopic | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DeleteTopic` | クラスター ARN、トピック ARN |
| UpdateTopic | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:AlterTopic` `kafka-cluster:AlterTopicDynamicConfiguration` | クラスター ARN、トピック ARN |
**注記**
では`kafka-cluster:Connect`、IAM ポリシーでクラスター ARN を指定します。その他のすべてのアクションについては、IAM ポリシーでトピック ARN を指定します。
**注記**
では`ListTopics`、ワイルドカード (\$1) を使用して、クラスター上のすべてのトピックを一致させることができます。例: `arn:aws:kafka:us-east-1:123456789012:topic/my-cluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/*`。
Amazon MSK の IAM アクセスコントロールの詳細については、「」を参照してください[IAM アクセスコントロール](iam-access-control.md)。
**Topics**
+ [トピック APIsを使用するための要件](#topic-operations-requirements)
+ [トピックオペレーション APIsの IAM アクセス許可](#topic-operations-permissions)
+ [Amazon MSK クラスター内のトピックを一覧表示する](msk-list-topics.md)
+ [トピックに関する詳細情報を取得する](msk-describe-topic.md)
+ [トピックのパーティション情報を表示する](msk-describe-topic-partitions.md)
+ [Amazon MSK クラスターでトピックを作成する](msk-create-topic.md)
+ [Amazon MSK クラスターのトピックを更新する](msk-update-topic.md)
+ [Amazon MSK クラスター内のトピックを削除する](msk-delete-topic.md)
# Amazon MSK クラスター内のトピックを一覧表示する
MSK プロビジョンドクラスター内のすべてのトピックを一覧表示して、パーティション数やレプリケーション係数などの基本的なメタデータを表示できます。これは、クラスターのトピックのモニタリング、インベントリチェックの実行、または詳細な調査のためのトピックの特定に役立ちます。
**注記**
`ListTopics` API は、基本的なトピックメタデータを提供します。現在のステータスや設定など、特定のトピックに関する詳細情報を取得するには、 `DescribeTopic` API を使用します。詳細については、「[トピックに関する詳細情報を取得する](msk-describe-topic.md)」を参照してください。
**注記**
この API レスポンスは、約 1 分ごとに更新されるデータを反映します。変更後の最新のトピックの状態については、クエリを実行する前に約 1 分かかります。
**Topics**
+ [を使用してトピックを一覧表示する AWS マネジメントコンソール](list-topics-console.md)
+ [を使用してトピックを一覧表示する AWS CLI](list-topics-cli.md)
+ [API を使用してトピックを一覧表示する](list-topics-api.md)
# を使用してトピックを一覧表示する AWS マネジメントコンソール
1. にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/msk/home?region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/) で Amazon MSK コンソールを開きます。
1. クラスターのリストで、トピックを一覧表示するクラスターの名前を選択します。
1. クラスターの詳細ページで、**トピックタブ**を選択します。
1. この表は、トピック名、パーティション数、レプリケーション係数、out-of-syncレプリカ数など、クラスター内のすべてのトピックを示しています。
# を使用してトピックを一覧表示する AWS CLI
次のコマンドを実行し、*ClusterArn* をクラスターの Amazon リソースネーム (ARN) に置き換えます。クラスターの ARN がない場合は、すべてのクラスターを一覧表示することで見つけられます。詳細については、「[Amazon MSK クラスターを一覧表示する](msk-list-clusters.md)」を参照してください。
```
aws kafka list-topics --cluster-arn ClusterArn
```
このコマンドの出力は、次の JSON の例のようになります。
```
{
"topics": [
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"partitionCount": 3,
"replicationFactor": 3,
"outOfSyncReplicaCount": 0
},
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/AnotherTopic",
"topicName": "AnotherTopic",
"partitionCount": 6,
"replicationFactor": 3,
"outOfSyncReplicaCount": 1
}
]
}
```
## 結果のページ分割
クラスターに多くのトピックがある場合は、ページ分割を使用して小さなバッチで結果を取得できます。`--max-results` パラメータを使用して返すトピックの最大数を指定し、 `--next-token`パラメータを使用して結果の次のページを取得します。
```
aws kafka list-topics --cluster-arn ClusterArn --max-results 10
```
利用可能な結果が他にもある場合、レスポンスには`nextToken`値が含まれます。このトークンを使用して、結果の次のページを取得します。
```
aws kafka list-topics --cluster-arn ClusterArn --max-results 10 --next-token NextToken
```
## 名前によるトピックのフィルタリング
`--topic-name-filter` パラメータを使用してプレフィックスを指定することで、トピックのリストをフィルタリングできます。これにより、名前が指定されたプレフィックスで始まるトピックのみが返されます。
```
aws kafka list-topics --cluster-arn ClusterArn --topic-name-filter "prod-"
```
このコマンドは、 `prod-orders`や など`prod-`、名前が で始まるトピックのみを返します`prod-inventory`。
# API を使用してトピックを一覧表示する
API を使用してトピックを一覧表示するには、[ListTopics](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics.html#ListTopics)」を参照してください。
# トピックに関する詳細情報を取得する
現在のステータス、パーティション数、レプリケーション係数、設定など、MSK プロビジョンドクラスター内の特定のトピックに関する詳細情報を取得できます。これは、トラブルシューティング、トピック設定の検証、またはオペレーション中のトピックステータスのモニタリングに役立ちます。
**注記**
この API レスポンスは、約 1 分ごとに更新されるデータを反映します。変更後の最新のトピックの状態については、クエリを実行する前に約 1 分かかります。
**Topics**
+ [を使用してトピックを記述する AWS マネジメントコンソール](describe-topic-console.md)
+ [を使用してトピックを記述する AWS CLI](describe-topic-cli.md)
+ [API を使用してトピックを記述する](describe-topic-api.md)
# を使用してトピックを記述する AWS マネジメントコンソール
1. にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/msk/home?region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/) で Amazon MSK コンソールを開きます。
1. クラスターのリストで、説明するトピックを含むクラスターの名前を選択します。
1. クラスターの詳細ページで、**トピックタブ**を選択します。
1. トピックのリストで、表示するトピックの名前を選択します。
1. トピックの詳細ページには、ステータス、パーティション数、レプリケーション係数、設定など、トピックに関する情報が表示されます。
# を使用してトピックを記述する AWS CLI
次のコマンドを実行し、*ClusterArn* をクラスターの Amazon リソースネーム (ARN) に置き換え、*TopicName* を記述するトピックの名前に置き換えます。
```
aws kafka describe-topic --cluster-arn ClusterArn --topic-name TopicName
```
このコマンドの出力は、次の JSON の例のようになります。
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"partitionCount": 3,
"replicationFactor": 3,
"configs": "Y29tcHJlc3Npb24udHlwZT1wcm9kdWNlcgpyZXRlbnRpb24ubXM9NjA0ODAwMDAw",
"status": "ACTIVE"
}
```
## トピックのステータスについて
`status` フィールドは、トピックの現在の状態を示します。次の表に、使用可能なステータス値を示します。
**トピックのステータス値**
| ステータス | 説明 |
| --- | --- |
| [CREATING] (作成中) | トピックを作成中です。 |
| アクティブ | トピックはアクティブで、使用できる状態です。 |
| [UPDATING] (更新中) | トピック設定は更新中です。 |
| 削除中 | トピックは削除中です。 |
## トピック設定について
`configs` フィールドには、トピックの Kafka 設定プロパティが含まれ、Base64 形式でエンコードされます。設定を読み取り可能な形式で表示するには、Base64 文字列をデコードする必要があります。
次の例は、Linux または macOS で `base64` コマンドを使用して設定をデコードする方法を示しています。
```
echo "Y29tcHJlc3Npb24udHlwZT1wcm9kdWNlcgpyZXRlbnRpb24ubXM9NjA0ODAwMDAw" | base64 --decode
```
デコードされた出力には、トピック設定プロパティがキーと値の形式で表示されます。
```
compression.type=producer
retention.ms=604800000
```
トピックレベルの設定プロパティの詳細については、「」を参照してください[トピックレベルの Amazon MSK 設定](msk-configuration-properties.md#msk-topic-confinguration)。
# API を使用してトピックを記述する
API を使用してトピックを記述するには、[DescribeTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname.html#DescribeTopic)」を参照してください。
# トピックのパーティション情報を表示する
MSK プロビジョンドクラスター内の特定のトピックのパーティションに関する詳細情報を取得できます。この情報には、パーティション番号、リーダーブローカー、レプリカブローカー、同期内レプリカ (ISR) が含まれます。これは、パーティション分散のモニタリング、レプリケーションが不十分なパーティションの特定、レプリケーションの問題のトラブルシューティングに役立ちます。
**注記**
この API レスポンスは、約 1 分ごとに更新されるデータを反映します。変更後の最新のトピックの状態については、クエリを実行する前に約 1 分かかります。
**Topics**
+ [を使用してパーティション情報を表示する AWS マネジメントコンソール](describe-topic-partitions-console.md)
+ [を使用してパーティション情報を表示する AWS CLI](describe-topic-partitions-cli.md)
+ [API を使用してパーティション情報を表示する](describe-topic-partitions-api.md)
# を使用してパーティション情報を表示する AWS マネジメントコンソール
1. にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/msk/home?region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/) で Amazon MSK コンソールを開きます。
1. クラスターのリストで、トピックを含むクラスターの名前を選択します。
1. クラスターの詳細ページで、**トピックタブ**を選択します。
1. トピックのリストで、パーティション情報を表示するトピックの名前を選択します。
1. トピックの詳細ページにパーティション情報が表示され、各パーティションのパーティション番号、リーダーブローカー、レプリカ、同期内レプリカが表示されます。
# を使用してパーティション情報を表示する AWS CLI
次のコマンドを実行し、*ClusterArn* をクラスターの Amazon リソースネーム (ARN) に置き換え、*TopicName* をトピックの名前に置き換えます。
```
aws kafka describe-topic-partitions --cluster-arn ClusterArn --topic-name TopicName
```
このコマンドの出力は、次の JSON の例のようになります。
```
{
"partitions": [
{
"partition": 0,
"leader": 1,
"replicas": [1, 2, 3],
"isr": [1, 2, 3]
},
{
"partition": 1,
"leader": 2,
"replicas": [2, 3, 1],
"isr": [2, 3, 1]
},
{
"partition": 2,
"leader": 3,
"replicas": [3, 1, 2],
"isr": [3, 1]
}
]
}
```
## パーティション情報について
レスポンスには、パーティションごとに次の情報が含まれます。
+ **partition** — パーティション番号。パーティションには 0 から番号が付けられます。
+ **leader** — このパーティションのリーダーのブローカー ID。リーダーがパーティションに対するすべての読み取りおよび書き込みリクエストを処理します。
+ **レプリカ** — このパーティションのレプリカを持つブローカー IDs のリスト。これには、同期内レプリカとout-of-syncレプリカの両方が含まれます。
+ **isr** — 同期レプリカであるブローカー IDs のリスト。これらのレプリカはリーダーに完全に追いついており、必要に応じてリーダーとして引き継ぐことができます。
上記の例では、パーティション 2 にout-of-syncレプリカがあります。`replicas` リストにはブローカー 2 が含まれていますが、`isr`リストには含まれていません。これは、ブローカー 2 がこのパーティションのリーダーに完全に追いついていないことを示します。
## 結果のページ分割
トピックに多数のパーティションがある場合は、ページ分割を使用して小さなバッチで結果を取得できます。`--max-results` パラメータを使用して返すパーティションの最大数を指定し、 `--next-token`パラメータを使用して結果の次のページを取得します。
```
aws kafka describe-topic-partitions --cluster-arn ClusterArn --topic-name TopicName --max-results 10
```
使用可能な結果が他にもある場合、レスポンスには`nextToken`値が含まれます。このトークンを使用して、結果の次のページを取得します。
```
aws kafka describe-topic-partitions --cluster-arn ClusterArn --topic-name TopicName --max-results 10 --next-token NextToken
```
## 一般的なユースケース
パーティション情報の表示は、いくつかのシナリオで役立ちます。
+ **レプリケート不足のパーティションの識別** — `replicas`と `isr`のリストを比較して、一部のレプリカが同期していないパーティションを識別します。これは、パフォーマンスの問題やブローカーの問題を示している可能性があります。
+ **パーティション分散のモニタリング** — バランスの取れた負荷を確保するために、パーティションリーダーがブローカー間で均等に分散されていることを確認します。
+ **レプリケーションの問題のトラブルシューティング** — ISR リストを調べて、レプリケーションに追いついていないブローカーを特定します。
+ **パーティションの再調整の計画** — この情報を使用して、再調整オペレーションを実行する前に現在のパーティションレイアウトを理解します。
# API を使用してパーティション情報を表示する
API を使用してパーティション情報を表示するには、[DescribeTopicPartitions](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname-partitions.html#DescribeTopicPartitions)」を参照してください。
# Amazon MSK クラスターでトピックを作成する
カスタム Kafka AdminClient を設定せずに、この API を使用して MSK プロビジョンドクラスターでトピックを直接作成できます。トピックを作成するときは、トピック名、パーティション数、レプリケーション係数、およびオプションでトピック設定を指定します。
**Topics**
+ [を使用してトピックを作成する AWS マネジメントコンソール](create-topic-console.md)
+ [を使用してトピックを作成する AWS CLI](create-topic-cli.md)
+ [API を使用してトピックを作成する](create-topic-api.md)
# を使用してトピックを作成する AWS マネジメントコンソール
1. にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/msk/home?region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/) で Amazon MSK コンソールを開きます。
1. クラスターのリストで、トピックを作成するクラスターの名前を選択します。
1. クラスターの詳細ページで、**トピックタブ**を選択します。
1. **[トピックを作成]** を選択します。
1. トピック名、パーティション数、レプリケーション係数を入力します。必要に応じて、設定を追加します。複数のトピックを一度に作成できます。
1. **[トピックを作成]** を選択します。
# を使用してトピックを作成する AWS CLI
次のコマンドを実行し、*ClusterArn* をクラスターの Amazon リソースネーム (ARN) に置き換えます。クラスターの ARN がない場合は、すべてのクラスターを一覧表示することで見つけられます。詳細については、「[Amazon MSK クラスターを一覧表示する](msk-list-clusters.md)」を参照してください。
```
aws kafka create-topic --cluster-arn ClusterArn --topic-name MyTopic --partition-count 3 --replication-factor 3
```
このコマンドの出力は、次の JSON の例のようになります。
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"status": "CREATING"
}
```
# API を使用してトピックを作成する
API を使用してトピックを作成するには、[CreateTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics.html#CreateTopic)」を参照してください。
# Amazon MSK クラスターのトピックを更新する
既存のトピックのパーティション数またはトピックレベルの設定を更新します。このオペレーションは、再作成を必要とせずにトピックを変更します。
**注記**
パーティション数またはトピック設定は 1 回の API コールで更新できますが、両方を同時に更新することはできません。両方を更新するには、個別の API コールを実行します。
**Topics**
+ [を使用してトピックを更新する AWS マネジメントコンソール](update-topic-console.md)
+ [を使用してトピックを更新する AWS CLI](update-topic-cli.md)
+ [API を使用してトピックを更新する](update-topic-api.md)
# を使用してトピックを更新する AWS マネジメントコンソール
1. にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/msk/home?region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/) で Amazon MSK コンソールを開きます。
1. クラスターのリストで、更新するトピックを含むクラスターの名前を選択します。
1. クラスターの詳細ページで、**トピックタブ**を選択します。
1. 更新するトピックを選択し、**パーティション設定の編集**または**アクション**から**設定の編集**を選択します。
1. 必要に応じてパーティション数または設定を更新します。
1. **[保存]** を選択します。
# を使用してトピックを更新する AWS CLI
次のコマンドを実行し、*ClusterArn* をクラスターの Amazon リソースネーム (ARN) に置き換え、*TopicName* を更新したいトピックの名前に置き換えます。
```
aws kafka update-topic --cluster-arn ClusterArn --topic-name TopicName --partition-count 6
```
このコマンドの出力は、次の JSON の例のようになります。
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"status": "UPDATING"
}
```
# API を使用してトピックを更新する
API を使用してトピックを更新するには、[UpdateTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname.html#UpdateTopic)」を参照してください。
# Amazon MSK クラスター内のトピックを削除する
トピックを削除すると、そのすべてのデータ、メタデータ、パーティション情報が完全に削除されます。この操作は元に戻すことができません。
**Topics**
+ [を使用してトピックを削除する AWS マネジメントコンソール](delete-topic-console.md)
+ [を使用してトピックを削除する AWS CLI](delete-topic-cli.md)
+ [API を使用してトピックを削除する](delete-topic-api.md)
# を使用してトピックを削除する AWS マネジメントコンソール
1. にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/msk/home?region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/) で Amazon MSK コンソールを開きます。
1. クラスターのリストで、削除するトピックを含むクラスターの名前を選択します。
1. クラスターの詳細ページで、**トピックタブ**を選択します。
1. 削除するトピックを選択し、**アクション**から削除**を選択します**。
1. 削除を確認し、**削除**を選択します。
# を使用してトピックを削除する AWS CLI
次のコマンドを実行し、*ClusterArn* をクラスターの Amazon リソースネーム (ARN) に置き換え、*TopicName* を削除するトピックの名前に置き換えます。
```
aws kafka delete-topic --cluster-arn ClusterArn --topic-name TopicName
```
このコマンドの出力は、次の JSON の例のようになります。
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"status": "DELETING"
}
```
# API を使用してトピックを削除する
API を使用してトピックを削除するには、[DeleteTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname.html#DeleteTopic)」を参照してください。
# Amazon MSK リソース
*リソース*とは、Amazon MSK においては、文脈に応じて 2 つの意味があります。API の文脈では、リソースはオペレーションを呼び出すことができる構造を指します。これらのリソースとそれらに対して呼び出すことができるオペレーションのリストについては、Amazon MSK API リファレンス の[リソース](https://docs.aws.amazon.com/msk/1.0/apireference/resources.html)を参照してください。[IAM アクセスコントロール](iam-access-control.md) の文脈における意味では、[認可ポリシーリソース](kafka-actions.md#msk-iam-resources) セクションで定義されているように、ユーザーはリソースへのアクセスを許可または拒否することができ、このようなエンティティのことをリソースと呼びます。
# Apache Kafka バージョン
Amazon MSK クラスターを作成するときは、クラスターに含める Apache Kafka バージョンを指定します。既存のクラスターの Apache Kafka バージョンを更新することもできます。この章のトピックは、Kafka バージョンサポートのタイムラインとベストプラクティスの提案を理解するのに役立ちます。
**Topics**
+ [サポート対象の Apache Kafka バージョン](supported-kafka-versions.md)
+ [Amazon MSK バージョンのサポート](version-support.md)
# サポート対象の Apache Kafka バージョン
Amazon Managed Streaming for Apache Kafka (Amazon MSK) は、次の Apache Kafka および Amazon MSK バージョンをサポートします。Apache Kafka コミュニティによるサポート期間は、バージョンのリリース日から約 12 か月間です。詳細については、[Apache Kafka EOL (サポート終了) ポリシーを参照してください](https://cwiki.apache.org/confluence/display/KAFKA/Time+Based+Release+Plan#TimeBasedReleasePlan-WhatIsOurEOLPolicy?)。
次の表に、Amazon MSK がサポートする Apache Kafka バージョンを示します。
| Apache Kafka バージョン | MSK リリース日 | サポート終了日 |
| --- | --- | --- |
| [1.1.1](https://archive.apache.org/dist/kafka/1.1.1/RELEASE_NOTES.html) | -- | 2024-06-05 |
| [2.1.0](https://archive.apache.org/dist/kafka/2.1.0/RELEASE_NOTES.html) | -- | 2024-06-05 |
| [2.2.1](https://archive.apache.org/dist/kafka/2.2.1/RELEASE_NOTES.html) | 2019-07-31 | 2024-06-08 |
| [2.3.1](https://archive.apache.org/dist/kafka/2.3.1/RELEASE_NOTES.html) | 2019-12-19 | 2024-06-08 |
| [2.4.1](https://archive.apache.org/dist/kafka/2.4.1/RELEASE_NOTES.html) | 2020-04-02 | 2024-06-08 |
| [2.4.1.1](https://archive.apache.org/dist/kafka/2.4.1/RELEASE_NOTES.html) | 2020-09-09 | 2024-06-08 |
| [2.5.1](https://archive.apache.org/dist/kafka/2.5.1/RELEASE_NOTES.html) | 2020-09-30 | 2024-06-08 |
| [2.6.0](https://archive.apache.org/dist/kafka/2.6.0/RELEASE_NOTES.html) | 2020-10-21 | 2024-09-11 |
| [2.6.1](https://archive.apache.org/dist/kafka/2.6.1/RELEASE_NOTES.html) | 2021-01-19 | 2024-09-11 |
| [2.6.2](https://archive.apache.org/dist/kafka/2.6.2/RELEASE_NOTES.html) | 2021-04-29 | 2024-09-11 |
| [2.6.3](https://archive.apache.org/dist/kafka/2.6.3/RELEASE_NOTES.html) | 2021-12-21 | 2024-09-11 |
| [2.7.0](https://archive.apache.org/dist/kafka/2.7.0/RELEASE_NOTES.html) | 2020-12-29 | 2024-09-11 |
| [2.7.1](https://archive.apache.org/dist/kafka/2.7.1/RELEASE_NOTES.html) | 2021-05-25 | 2024-09-11 |
| [2.7.2](https://archive.apache.org/dist/kafka/2.7.2/RELEASE_NOTES.html) | 2021-12-21 | 2024-09-11 |
| [2.8.0](https://archive.apache.org/dist/kafka/2.8.0/RELEASE_NOTES.html) | 2021-05-19 | 2024-09-11 |
| [2.8.1](https://archive.apache.org/dist/kafka/2.8.1/RELEASE_NOTES.html) | 2022-10-28 | 2024-09-11 |
| [2.8.2 階層型](https://archive.apache.org/dist/kafka/2.8.2/RELEASE_NOTES.html) | 2022-10-28 | 2025-01-14 |
| [3.1.1](https://archive.apache.org/dist/kafka/3.1.1/RELEASE_NOTES.html) | 2022-06-22 | 2024-09-11 |
| [3.2.0](https://archive.apache.org/dist/kafka/3.2.0/RELEASE_NOTES.html) | 2022-06-22 | 2024-09-11 |
| [3.3.1](https://archive.apache.org/dist/kafka/3.3.1/RELEASE_NOTES.html) | 2022-10-26 | 2024-09-11 |
| [3.3.2](https://archive.apache.org/dist/kafka/3.3.2/RELEASE_NOTES.html) | 2023-03-02 | 2024-09-11 |
| [3.4.0](https://archive.apache.org/dist/kafka/3.4.0/RELEASE_NOTES.html) | 2023-05-04 | 2025-08-04 |
| [3.5.1](https://archive.apache.org/dist/kafka/3.5.1/RELEASE_NOTES.html) | 2023-09-26 | 2025-10-23 |
| [3.6.0](https://archive.apache.org/dist/kafka/3.6.0/RELEASE_NOTES.html) | 2023-11-16 | 2026-06-01 |
| [3.7.x](https://archive.apache.org/dist/kafka/3.7.0/RELEASE_NOTES.html) | 2024-05-29 | -- |
| [3.8.x](https://downloads.apache.org/kafka/3.8.0/RELEASE_NOTES.html) | 2025-02-20 | -- |
| [3.9.x](https://downloads.apache.org/kafka/3.9.0/RELEASE_NOTES.html) (推奨) | 2025-04-21 | -- |
| [4.0.x](https://downloads.apache.org/kafka/4.0.0/RELEASE_NOTES.html) | 2025-05-16 | -- |
| [4.1.x](https://downloads.apache.org/kafka/4.1.0/RELEASE_NOTES.html) | 2025-10-15 | -- |
詳細については、「Amazon MSK バージョンのサポートポリシーについて」を参照してください[Amazon MSK バージョンのサポートポリシー](version-support.md#version-support-policy)。
## Amazon MSK バージョン 4.1.x
Amazon Managed Streaming for Apache Kafka (Amazon MSK) で Apache Kafka バージョン 4.1 がサポートされるようになりました。これにより、プレビュー機能としてキュー、早期アクセスの新しいストリーム再調整プロトコル、適格なリーダーレプリカ (ELR) が導入されました。これらの機能に加えて、Apache Kafka バージョン 4.1 にはさまざまなバグ修正と改善が含まれています。
Kafka 4.1 の主なハイライトは、プレビュー機能としてのキューの導入です。複数のコンシューマーを使用して同じトピックパーティションからのメッセージを処理できるため、 point-to-point メッセージ配信を必要とするワークロードの並列性とスループットが向上します。新しい Streams Rebalance Protocol は Kafka 4.0 のコンシューマー再調整プロトコルに基づいて構築され、ブローカー調整機能を Kafka Streams に拡張して、タスクの割り当てと再調整を最適化します。さらに、ELR は可用性を強化するためにデフォルトで有効になりました。
詳細と改善点とバグ修正の完全なリストについては、[バージョン 4.1 の Apache Kafka リリースノート](https://downloads.apache.org/kafka/4.1.0/RELEASE_NOTES.html)を参照してください。
Amazon MSK で Apache Kafka 4.1 の使用を開始するには、 AWS マネジメントコンソール、、または AWS SDKs を使用して新しいクラスターを作成するときに AWS CLI、バージョン 4.1.x を選択します。インプレースローリング更新を使用して、既存の MSK プロビジョンド クラスターをアップグレードすることもできます。Amazon MSK はブローカーを再起動して可用性を維持し、アップグレード中にデータを保護します。Kafka バージョン 4.1 のサポートは、Amazon MSK が提供されているすべての AWS リージョン で利用できます。
## Amazon MSK バージョン 4.0.x
Amazon Managed Streaming for Apache Kafka (Amazon MSK) が、Apache Kafka バージョン 4.0 をサポートするようになりました。このバージョンでは、クラスターの管理とパフォーマンスにおける最新の進歩が MSK プロビジョンドにもたらされます。Kafka 4.0 では、新しいコンシューマー再調整プロトコルが導入されました。このプロトコルは一般公開され、グループの再調整をよりスムーズかつ迅速に行うことができます。さらに、Kafka 4.0 では、Java 17 を使用するブローカーとツールが必要であり、セキュリティとパフォーマンスが向上し、さまざまなバグ修正と改善が含まれ、Apache ZooKeeper によるメタデータ管理が廃止されます。
詳細と改善点とバグ修正の完全なリストについては、[バージョン 4.0 の Apache Kafka リリースノート](https://downloads.apache.org/kafka/4.0.0/RELEASE_NOTES.html)を参照してください。
## Amazon MSK バージョン 3.9.x (推奨)
Amazon Managed Streaming for Apache Kafka (Amazon MSK) が、Apache Kafka バージョン 3.9 をサポートするようになりました。このバージョンは、トピックレベルで階層型ストレージを無効にするときに階層型データを保持できるようにすることで、階層型ストレージの機能を強化します。コンシューマーアプリケーションは、ローカルストレージとリモートストレージ全体で継続的なログオフセットを維持しながら、リモートログ開始オフセット (Rx) から履歴データを読み取ることができます。
バージョン 3.9 は、ZooKeeper と KRaft の両方のメタデータ管理システムをサポートする最後のバージョンです。Amazon MSK は、リリース日から最低 2 年間、バージョン 3.9 の延長サポートを提供します。
詳細と改善点とバグ修正の完全なリストについては、[バージョン 3.9ｘ の Apache Kafka リリースノート](https://downloads.apache.org/kafka/3.9.0/RELEASE_NOTES.html)を参照してください。
## Amazon MSK バージョン 3.8.x
Amazon Managed Streaming for Apache Kafka (Amazon MSK) が、Apache Kafka バージョン 3.8 をサポートするようになりました。メタデータ管理に KRAFT モードまたは ZooKeeper モードを使用してバージョン 3.8 を使用して新しいクラスターを作成したり、既存の ZooKeeper ベースのクラスターをバージョン 3.8 を使用するようにアップグレードしたりできます。Apache Kafka バージョン 3.8 には、パフォーマンスを向上させるいくつかのバグ修正と新機能が含まれています。主な新機能には、圧縮レベル設定のサポートが含まれます。これにより、デフォルトの圧縮レベルを変更できるため、lz4、zstd、gzip などの圧縮タイプを使用する際のパフォーマンスをさらに最適化できます。
詳細と改善点とバグ修正の完全なリストについては、[バージョン 3.8ｘ の Apache Kafka リリースノート](https://downloads.apache.org/kafka/3.8.0/RELEASE_NOTES.html)を参照してください。
## Apache Kafka バージョン 3.7.x (本番環境対応の階層型ストレージ搭載)
MSK での Apache Kafka バージョン 3.7.x には、Apache Kafka バージョン 3.7.0 のサポートが含まれています。新しい 3.7.x バージョンを使用する場合は、クラスターを作成するか、既存のクラスターをアップグレードします。このバージョン命名の変更により、Apache Kafka コミュニティで 3.7.1 などの新しいパッチ修正バージョンがリリースされたときに、それを採用する必要がなくなりました。Amazon MSK は、将来のパッチバージョンが使用可能になると、自動的に 3.7.x を更新してサポートします。これにより、バージョンアップグレードをトリガーすることなく、パッチ修正バージョンを通じて使用可能なセキュリティおよびバグ修正のメリットを得ることができます。Apache Kafka によってリリースされたこれらのパッチ修正バージョンでは、バージョンの互換性が損なわれることはありません。そのため、クライアントアプリケーションの読み込みまたは書き込みエラーを心配することなく、新しいパッチ修正バージョンのメリットを享受できます。CloudFormation などのインフラストラクチャ自動化ツールが、このバージョン命名の変更を考慮して更新されていることを確認してください。
Amazon MSK は、Apache Kafka バージョン 3.7.x で KRaft モード (Apache Kafka Raft) をサポートするようになりました。Amazon MSK では、ZooKeeper ノードと同様に、KRaft コントローラーが追加料金なしで含まれており、追加のセットアップや管理は必要ありません。Apache Kafka バージョン 3.7.x で、KRaft モードまたは ZooKeeper モードでクラスターを作成できるようになりました。Kraft モードでは、Zookeeper ベースのクラスターのブローカークォータ 30 と比較して、制限の引き上げをリクエストしなくても最大 60 ブローカーの追加が可能なため、クラスターごとにより多くのパーティションをホストできます。MSK における KRaft の詳細については、[KRaft モード](metadata-management.md#kraft-intro) をご覧ください。
Apache Kafka バージョン 3.7.x には、パフォーマンスを向上させるいくつかのバグ修正と新機能も含まれています。主な改善点としては、クライアントのリーダー検出の最適化、ログセグメントフラッシュの最適化オプションなどがあります。改善点とバグ修正の詳細な一覧については、Apache Kafka [3.7.0](https://archive.apache.org/dist/kafka/3.7.0/RELEASE_NOTES.html) のリリースノートを参照してください。
## Apache Kafka バージョン 3.6.0 (本番移行可能階層型ストレージ搭載)
Apache Kafka バージョン 3.6.0 (本番移行可能階層ストレージ) の詳細については、Apache Kafka ダウンロードサイトの[リリースノート](https://archive.apache.org/dist/kafka/3.6.0/RELEASE_NOTES.html)を参照してください。
Amazon MSK は、安定性を保つため、このリリースでもクォーラム管理に ZooKeeper を引き続き使用および管理します。
## Amazon MSK バージョン 3.5.1
Amazon Managed Streaming for Apache Kafka (Amazon MSK) が、新規および既存のクラスターで Apache Kafka バージョン 3.5.1 をサポートするようになりました。Apache Kafka 3.5.1 には、パフォーマンスを向上させるいくつかのバグ修正と新機能が含まれています。主な機能には、コンシューマーに対する新しいラック認識のパーティション割り当ての導入などがあります。Amazon MSK は、このリリースでもクォーラム管理に ZooKeeper を引き続き使用および管理します。改善点とバグ修正の詳細な一覧については、Apache Kafka 3.5.1 のリリースノートを参照してください。
Apache Kafka バージョン 3.5.1 の詳細については、Apache Kafka ダウンロードサイトの[リリースノート](https://archive.apache.org/dist/kafka/3.5.1/RELEASE_NOTES.html)を参照してください。
## Amazon MSK バージョン 3.4.0
Amazon Managed Streaming for Apache Kafka (Amazon MSK) が、新規および既存のクラスターで Apache Kafka バージョン 3.4.0 をサポートするようになりました。Apache Kafka 3.4.0 には、パフォーマンスを向上させるいくつかのバグ修正と新機能が含まれています。主な機能には、最も近いレプリカからフェッチする際の安定性を向上させる修正が含まれます。Amazon MSK は、このリリースでもクォーラム管理に ZooKeeper を引き続き使用および管理します。改善点とバグ修正の詳細な一覧については、Apache Kafka 3.4.0 のリリースノートを参照してください。
Apache Kafka バージョン 3.4.0 の詳細については、Apache Kafka ダウンロードサイトの[リリースノート](https://archive.apache.org/dist/kafka/3.4.0/RELEASE_NOTES.html)を参照してください。
## Amazon MSK バージョン 3.3.2
Amazon Managed Streaming for Apache Kafka (Amazon MSK) が、新規および既存のクラスターで Apache Kafka バージョン 3.3.2 をサポートするようになりました。Apache Kafka 3.3.2 には、パフォーマンスを向上させるいくつかのバグ修正と新機能が含まれています。主な機能には、最も近いレプリカからフェッチする際の安定性を向上させる修正が含まれます。Amazon MSK は、このリリースでもクォーラム管理に ZooKeeper を引き続き使用および管理します。改善点とバグ修正の詳細な一覧については、Apache Kafka 3.3.2 のリリースノートを参照してください。
Apache Kafka バージョン 3.3.2 の詳細については、Apache Kafka ダウンロードサイトの[リリースノート](https://archive.apache.org/dist/kafka/3.3.2/RELEASE_NOTES.html)を参照してください。
## Amazon MSK バージョン 3.3.1
Amazon Managed Streaming for Apache Kafka (Amazon MSK) が、新規および既存のクラスターで Apache Kafka バージョン 3.3.1 をサポートするようになりました。Apache Kafka 3.3.1 には、パフォーマンスを向上させるいくつかのバグ修正と新機能が含まれています。主な機能には、メトリクスとパーティショナーの強化が含まれます。Amazon MSK は、安定性を保つため、このリリースでもクォーラム管理に ZooKeeper を引き続き使用および管理します。改善点とバグ修正の詳細な一覧については、Apache Kafka 3.3.1 のリリースノートを参照してください。
Apache Kafka バージョン 3.3.1 の詳細については、Apache Kafka ダウンロードサイトの[リリースノート](https://archive.apache.org/dist/kafka/3.3.1/RELEASE_NOTES.html)を参照してください。
## Amazon MSK バージョン 3.1.1
Amazon Managed Streaming for Apache Kafka (Amazon MSK) が、新規および既存のクラスターで Apache Kafka バージョン 3.1.1 および 3.2.0 をサポートするようになりました。Apache Kafka 3.1.1 と Apache Kafka 3.2.0 には、パフォーマンスを向上させるいくつかのバグ修正と新機能が含まれています。主な機能には、メトリクスの強化やトピック ID の使用などがあります。MSK は、安定性を確保するために、このリリースでもクォーラム管理に ZooKeeper を引き続き使用および管理します。改善点とバグ修正の詳細な一覧については、Apache Kafka 3.1.1 および 3.2.0 のリリースノートを参照してください。
Apache Kafka バージョン 3.1.1 および 3.2.0 の詳細については、Apache Kafka ダウンロードサイトの [3.2.0 のリリースノート](https://archive.apache.org/dist/kafka/3.2.0/RELEASE_NOTES.html)と [3.1.1 のリリースノート](https://archive.apache.org/dist/kafka/3.1.1/RELEASE_NOTES.html)を参照してください。
## Amazon MSK 階層型ストレージバージョン 2.8.2.tiered
このリリースは、Apache Kafka バージョン 2.8.2 の Amazon MSK のみのバージョンであり、オープンソースの Apache Kafka クライアントと互換性があります。
2.8.2.tiered リリースには、[Apache Kafka の KIP-405](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage) で導入された API と互換性のある階層型ストレージ機能が含まれています。Amazon MSK 階層型ストレージ機能の詳細については、「[標準ブローカーの階層型ストレージ](msk-tiered-storage.md)」を参照してください。
## Apache Kafka バージョン 2.5.1
Apache Kafka バージョン 2.5.1 には、Apache ZooKeeper および管理クライアントの転送中の暗号化など、いくつかのバグ修正と新機能が含まれています。Amazon MSK は、[DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)オペレーションでクエリできる TLS ZooKeeper エンドポイントを提供します。
[DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)オペレーションの出力には、TLS zookeeper エンドポイントを一覧表示する `ZookeeperConnectStringTls` ノードが含まれます。
次の例は、`DescribeCluster` オペレーションの応答の `ZookeeperConnectStringTls` ノードを示しています。
```
"ZookeeperConnectStringTls": "z-3.awskafkatutorialc.abcd123.c3.kafka.us-east-1.amazonaws.com:2182,z-2.awskafkatutorialc.abcd123.c3.kafka.us-east-1.amazonaws.com:2182,z-1.awskafkatutorialc.abcd123.c3.kafka.us-east-1.amazonaws.com:2182"
```
zookeeper で TLS 暗号化を使用する方法については、「[Apache ZooKeeper での TLS セキュリティの使用](zookeeper-security-tls.md)」を参照してください。
Apache Kafka バージョン 2.5.1 の詳細については、Apache Kafka ダウンロードサイトの[リリースノート](https://archive.apache.org/dist/kafka/2.5.1/RELEASE_NOTES.html)を参照してください。
## Amazon MSK のバグ修正バージョン 2.4.1.1
このリリースは、Apache Kafka バージョン 2.4.1 の Amazon MSK のみのバグ修正バージョンです。このバグ修正リリースには、[KAFKA-9752](https://issues.apache.org/jira/browse/KAFKA-9752)の修正が含まれています。これは、コンシューマーグループが継続的にリバランスして `PreparingRebalance` 状態のままになるまれな問題です。この問題は、Apache Kafka バージョン 2.3.1 および 2.4.1 を実行しているクラスターに影響します。このリリースには、Apache Kafka バージョン 2.5.0 で利用可能なコミュニティで作成された修正が含まれています。
**注記**
バージョン 2.4.1.1 を実行している Amazon MSK クラスターは、Apache Kafka バージョン 2.4.1 と互換性のあるすべての Apache Kafka クライアントと互換性があります。
Apache Kafka 2.4.1 を使用する場合は、新しい Amazon MSK クラスターに MSK バグ修正バージョン 2.4.1.1 を使用することをお勧めします。Apache Kafka バージョン 2.4.1 を実行している既存のクラスターをこのバージョンに更新して、この修正を組み込むことができます。既存のクラスターのアップグレードについては、「[Apache Kafka バージョンのアップグレード](version-upgrades.md)」を参照してください。
クラスターをバージョン 2.4.1.1 にアップグレードせずにこの問題を回避するには、[Amazon MSK クラスターをトラブルシューティングする](troubleshooting.md) ガイドの [コンシューマーグループが `PreparingRebalance` 状態から変化しない](troubleshooting.md#consumer-group-rebalance) セクションを参照してください。
## Apache Kafka バージョン 2.4.1 (代わりに 2.4.1.1 を使用)
**注記**
Apache Kafka バージョン 2.4.1 で MSK クラスターを作成することはできなくなりました。代わりに、Apache Kafka バージョン 2.4.1 と互換性のあるクライアントで [Amazon MSK のバグ修正バージョン 2.4.1.1](#2.4.1.1) を使用できます。また、Apache Kafka バージョン 2.4.1 を使用する MSK クラスターが既にある場合は、代わりに Apache Kafka バージョン 2.4.1.1 を使用するように更新することをお勧めします。
KIP-392 は、Apache Kafka の 2.4.1 リリースに含まれている主要な Kafka 改善提案の1つです。この改善により、コンシューマーは最も近いレプリカからフェッチできます。この機能を使用するには、コンシューマープロパティの `client.rack` をコンシューマーのアベイラビリティーゾーンの ID に設定します。AZ ID の例は `use1-az1` です。Amazon MSK は、`broker.rack` をブローカーのアベイラビリティーゾーンの ID に設定します。また、`replica.selector.class` 設定プロパティを `org.apache.kafka.common.replica.RackAwareReplicaSelector` に設定する必要があります。これは、Apache Kafka が提供するラック認識の実装です。
Apache Kafka のこのバージョンを使用すると、`PER_TOPIC_PER_BROKER` モニタリングレベルのメトリクスは、その値が初めてゼロ以外になった後にのみ表示されます。詳細については、「[`PER_TOPIC_PER_BROKER` レベルモニタリング](metrics-details.md#broker-topic-metrics)」を参照してください。
アベイラビリティーゾーン IDs[「リソースの AZ IDs](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html)」を参照してください。 AWS Resource Access Manager
設定プロパティの設定については、「[Amazon MSK Provisioned 設定](msk-configuration.md)」を参照してください。
KIP-392 の詳細については、Confluence ページの [Allow Consumers to Fetch from Closest Replica](https://cwiki.apache.org/confluence/display/KAFKA/KIP-392:+Allow+consumers+to+fetch+from+closest+replica)を参照してください。
Apache Kafka バージョン 2.4.1 の詳細については、Apache Kafka ダウンロードサイトの[リリースノート](https://archive.apache.org/dist/kafka/2.4.1/RELEASE_NOTES.html)を参照してください。
# Amazon MSK バージョンのサポート
このトピックでは、[Amazon MSK バージョンのサポートポリシー](#version-support-policy) と [Apache Kafka バージョンのアップグレード](version-upgrades.md) の手順について説明します。Kafka バージョンをアップグレードする場合は、「[バージョンアップグレードのベストプラクティス](version-upgrades-best-practices.md)」で説明されているベストプラクティスに従ってください。
**Topics**
+ [Amazon MSK バージョンのサポートポリシー](#version-support-policy)
+ [Apache Kafka バージョンのアップグレード](version-upgrades.md)
+ [バージョンアップグレードのベストプラクティス](version-upgrades-best-practices.md)
## Amazon MSK バージョンのサポートポリシー
このセクションでは、Amazon MSK でサポートされている Kafka バージョンのサポートポリシーについて説明します。
+ すべての Kafka バージョンは、サポート終了日までサポートされます。サポート終了日の詳細については、「[サポート対象の Apache Kafka バージョン](supported-kafka-versions.md)」を参照してください。サポート終了日までに、MSK クラスターを推奨される Kafka バージョン以降のバージョンにアップグレードしてください。Apache Kafka バージョンのアップグレードの詳細については、「[Apache Kafka バージョンのアップグレード](version-upgrades.md)」を参照してください。サポート終了日を過ぎた Kafka バージョンを使用するクラスターは、推奨される Kafka バージョンに自動的にアップグレードされます。自動アップグレードは、サポート終了日以降にいつでも実行される可能性があります。アップグレード前に通知は届きません。
+ MSK では、新しく作成された、サポート終了日が公開されている Kafka バージョンを使用するクラスターのサポートを段階的に廃止します。
# Apache Kafka バージョンのアップグレード
既存の MSK クラスターを新しいバージョンの Apache Kafka にアップグレードできます。クラスターの Kafka バージョンをアップグレードする前に、クライアント側のソフトウェアのバージョンが新しい Kafka バージョンの機能をサポートしていることを確認してください。
アップグレード中にクラスターの高可用性にする方法については、「[高可用性クラスターの構築](bestpractices.md#ensure-high-availability)」を参照してください。
**を使用して Apache Kafka バージョンをアップグレードする AWS マネジメントコンソール**
1. [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/) で Amazon MSK コンソールを開きます。
1. ナビゲーションバーで、クラスターを作成したリージョンを選択します。
1. アップグレードする MSK クラスターを選択します。
1. **Properties** タブで **[Apache Kafka バージョン]** セクションで **Upgrade** を選択します。
1. **Apache Kafka バージョン** セクションで、次の操作を行います。
1. *Apache Kafka バージョンの選択*ドロップダウンリストで、アップグレードするターゲットバージョンを選択します。例えば、[**3.9.x**] を選択します。
1. (オプション) **バージョンの互換性を表示**を選択して、クラスターの現在のバージョンと利用可能なアップグレードバージョンとの互換性を検証します。次に、**選択**を選択して続行します。
**注記**
Amazon MSK は、ほとんどの Apache Kafka バージョンへのインプレースアップグレードをサポートしています。ただし、ZooKeeper ベースの Kafka バージョンから KRaft ベースのバージョンにアップグレードする場合は、新しいクラスターを作成する必要があります。次に、データを新しいクラスターにコピーし、クライアントを新しいクラスターに切り替えます。
1. (オプション) **クラスター設定の更新**チェックボックスを選択して、新しいバージョンと互換性のある設定更新を適用します。これにより、新しいバージョンの機能と改善が可能になります。
既存のカスタム設定を維持する必要がある場合は、このステップをスキップできます。
**注記**
サーバー側のアップグレードでは、クライアントアプリケーションは自動的に更新されません。
クラスターの安定性を維持するために、バージョンダウングレードはサポートされていません。
1. **アップグレード** を選択して、プロセスを開始します。
**を使用して Apache Kafka バージョンをアップグレードする AWS CLI**
1. *ClusterArn*をクラスターの作成時に取得したAmazon リソースネーム (ARN) に置き換えて、次のコマンドを実行します。クラスターの ARN がない場合は、すべてのクラスターを一覧表示することで見つけられます。詳細については、「[Amazon MSK クラスターを一覧表示する](msk-list-clusters.md)」を参照してください。
```
aws kafka get-compatible-kafka-versions --cluster-arn ClusterArn
```
このコマンドの出力には、クラスターをアップグレードできる Apache Kafka バージョンのリストが含まれています。次の例のようになります。
```
{
"CompatibleKafkaVersions": [
{
"SourceVersion": "2.2.1",
"TargetVersions": [
"2.3.1",
"2.4.1",
"2.4.1.1",
"2.5.1"
]
}
]
}
```
1. *ClusterArn*をクラスターの作成時に取得したAmazon リソースネーム (ARN) に置き換えて、次のコマンドを実行します。クラスターの ARN がない場合は、すべてのクラスターを一覧表示することで見つけられます。詳細については、「[Amazon MSK クラスターを一覧表示する](msk-list-clusters.md)」を参照してください。
*Current-Cluster-Version* を、クラスターの現在のバージョンに置き換えます。*TargetVersion* では、前のコマンド出力から任意のターゲットバージョンを指定できます。
**重要**
クラスターのバージョンは単純な整数ではありません。クラスターの最新バージョンを検索するには、[DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster) オペレーションまたは [describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html) AWS CLI コマンドを使用します。サンプルのバージョンは `KTVPDKIKX0DER` です。
```
aws kafka update-cluster-kafka-version --cluster-arn ClusterArn --current-version Current-Cluster-Version --target-kafka-version TargetVersion
```
前のコマンドの出力は以下の JSON のようになります。
```
{
"ClusterArn": "arn:aws:kafka:us-east-1:012345678012:cluster/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2",
"ClusterOperationArn": "arn:aws:kafka:us-east-1:012345678012:cluster-operation/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2/0123abcd-abcd-4f7f-1234-9876543210ef"
}
```
1. `update-cluster-kafka-version` オペレーションの結果を取得するには、*ClusterOperationArn*を `update-cluster-kafka-version` コマンドの出力で取得した ARN に置き換えて、次のコマンドを実行します。
```
aws kafka describe-cluster-operation --cluster-operation-arn ClusterOperationArn
```
この `describe-cluster-operation` コマンドの出力は、次の JSON の例のようになります。
```
{
"ClusterOperationInfo": {
"ClientRequestId": "62cd41d2-1206-4ebf-85a8-dbb2ba0fe259",
"ClusterArn": "arn:aws:kafka:us-east-1:012345678012:cluster/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2",
"CreationTime": "2021-03-11T20:34:59.648000+00:00",
"OperationArn": "arn:aws:kafka:us-east-1:012345678012:cluster-operation/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2/0123abcd-abcd-4f7f-1234-9876543210ef",
"OperationState": "UPDATE_IN_PROGRESS",
"OperationSteps": [
{
"StepInfo": {
"StepStatus": "IN_PROGRESS"
},
"StepName": "INITIALIZE_UPDATE"
},
{
"StepInfo": {
"StepStatus": "PENDING"
},
"StepName": "UPDATE_APACHE_KAFKA_BINARIES"
},
{
"StepInfo": {
"StepStatus": "PENDING"
},
"StepName": "FINALIZE_UPDATE"
}
],
"OperationType": "UPDATE_CLUSTER_KAFKA_VERSION",
"SourceClusterInfo": {
"KafkaVersion": "2.4.1"
},
"TargetClusterInfo": {
"KafkaVersion": "2.6.1"
}
}
}
```
`OperationState` の値が `UPDATE_IN_PROGRESS` の場合は、しばらく待ってから再度 `describe-cluster-operation` コマンドを実行します。オペレーションが完了すると、`OperationState` の値は `UPDATE_COMPLETE` になります。Amazon MSK がオペレーションを完了するのに必要な時間はさまざまであるため、オペレーションが完了するまで繰り返しチェックする必要がある場合があります。
**API を使用して Apache Kafka バージョンを更アップグレードする**
1. [GetCompatibleKafkaVersions](https://docs.aws.amazon.com//msk/1.0/apireference/compatible-kafka-versions.html#GetCompatibleKafkaVersions) オペレーションを呼び出して、クラスターをアップグレードできる Apache Kafka バージョンのリストを取得します。
1. [UpdateClusterKafkaVersion](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn-version.html#UpdateClusterKafkaVersion) オペレーションを呼び出して、クラスターを互換性のある Apache Kafka バージョンのいずれかにアップグレードします。
# バージョンアップグレードのベストプラクティス
Kafka バージョンアップグレードプロセスの一環として実行されるローリング更新中にクライアントの継続性を確保するために、クライアントと Apache Kafka トピックの設定について次のように確認します。
+ トピックのレプリケーション係数 (RF) の最小値は、2 つの AZ クラスターの場合は `2` に、3 つの AZ クラスターの場合は `3` に設定します。RF 値が `2` の場合、パッチ適用中にオフラインパーティションが発生する可能性があります。
+ 最小同期レプリカ (minISR) を、レプリケーション係数 (RF) `miniISR = (RF) - 1` より 1 小さい最大値に設定します。これにより、パーティションレプリカセットが 1 つのレプリカがオフラインまたは過小レプリケーションされることを許容できます。
+ 複数のブローカー接続文字列を使用するようにクライアントを設定します。クライアントの接続文字列に複数のブローカーが含まれていると、クライアント I/O をサポートする特定のブローカーにパッチが適用され始めた場合にフェイルオーバーができるようになります。複数のブローカーを含む接続文字列を取得する方法については、「[Amazon MSK クラスターのブートストラップブローカーを取得する](https://docs.aws.amazon.com//msk/latest/developerguide/msk-get-bootstrap-brokers.html)」を参照してください。
+ 新しいバージョンで使用できる機能を活用するために、接続クライアントを推奨バージョン以降にアップグレードすることをお勧めします。クライアントのアップグレードは、MSK クラスターの Kafka バージョンのサポート終了 (EOL) 日に左右されないため、EOL 日までに完了する必要はありません。Apache Kafka は、[双方向のクライアント互換性ポリシー](https://kafka.apache.org/protocol#protocol_compatibility)を提供しているため、古いクライアントが新しいクラスターで動作することも、その逆も可能になります。
+ バージョン 3.x.x を使用する Kafka クライアントには、デフォルトの `acks=all` と `enable.idempotence=true` が付属している可能性があります。`acks=all` は、以前のデフォルトの `acks=1` とは異なり、すべての同期レプリカが生成要求を承認することを保証することで追加の耐久性を提供します。同様に、`enable.idempotence` のデフォルトは以前は `false` でした。`enable.idempotence=true` をデフォルトに変更すると、重複したメッセージが発生する可能性が低くなります。これらの変更はベストプラクティス設定と見なされ、通常のパフォーマンスパラメータの範囲内でわずかな追加遅延が発生する可能性があります。
+ 新しい MSK クラスターを作成するときは、推奨される Kafka バージョンを使用します。推奨される Kafka バージョンを使用すると、最新の Kafka 機能と MSK 機能を活用できます。
# Amazon MSK クラスターをトラブルシューティングする
次の情報は、お使いの Amazon MSK クラスター に関する問題を解決するために役立ちます。[AWS re:Post](https://repost.aws/) に問題を投稿することもできます。Amazon MSK Replicator のトラブルシューティングについては、「[MSK Replicator のトラブルシューティング](msk-replicator-troubleshooting.md)」を参照してください。
**Topics**
+ [ボリュームを置き換えると、レプリケーションの過負荷によりディスクが飽和します。](#replication-overload-disk-saturation)
+ [コンシューマーグループが `PreparingRebalance` 状態から変化しない](#consumer-group-rebalance)
+ [Amazon CloudWatch Logs へのブローカーログの配信エラー](#cw-broker-logs-error)
+ [デフォルトのセキュリティグループがない](#troubleshooting-shared-vpc)
+ [クラスターが [作成中] 状態のまま停止しているように見える](#troubleshooting-cluster-stuck)
+ [クラスターの状態が [作成中] から [失敗] に変わる](#troubleshooting-cluster-failed)
+ [クラスターの状態は [アクティブ] であるが、プロデューサーがデータを送信できないか、コンシューマーがデータを受信できない](#troubleshooting-nodata)
+ [AWS CLI が Amazon MSK を認識しない](#troubleshooting-nocli)
+ [パーティションがオフラインになるか、レプリカが同期しない](#troubleshooting-offlinepartition-outofsyncreplicas)
+ [ディスク容量が不足している](#troubleshooting-lowdiskspace)
+ [メモリが不足している](#troubleshooting-lowmemory)
+ [プロデューサーが NotLeaderForPartitionException を取得する](#troubleshooting-NotLeaderForPartitionException)
+ [レプリケート不足のパーティション (URP) 数がゼロより大きい](#troubleshooting-urp)
+ [クラスターには \$1\$1amazon\$1msk\$1canary と \$1\$1amazon\$1msk\$1canary\$1state というトピックがあります](#amazon_msk_canary)
+ [パーティションレプリケーションが失敗する](#partition_replication_fails)
+ [パブリックアクセスが有効になっているクラスターにアクセスできない](#public-access-issues)
+ [IPv6 ブートストラップを介してクラスターにアクセスできない](#dualstack-issues)
+ [内からクラスターにアクセスできない AWS: ネットワークの問題](#networking-trouble)
+ [認証の失敗: 接続が多すぎる](#troubleshoot-too-many-connects)
+ [認証の失敗: セッションが短すぎます](#troubleshoot-session-too-short)
+ [MSK サーバーレス: クラスターの作成に失敗する](#troubleshoot-serverless-create-cluster-failure)
+ [MSK 設定で KafkaVersionsList を更新できません](#troubleshoot-kafkaversionslist-cfn-update-failure)
## ボリュームを置き換えると、レプリケーションの過負荷によりディスクが飽和します。
予期しないボリュームハードウェア障害が発生した場合、Amazon MSK はボリュームを新しいインスタンスに置き換えることがあります。Kafka は、クラスター内の他のブローカーからパーティションをレプリケートすることで、新しいボリュームに再入力します。パーティションがレプリケートされてキャッチアップされると、リーダーシップと同期レプリカ (ISR) メンバーシップの対象となります。
**問題**
ボリュームの置き換えから復帰するブローカーでは、さまざまなサイズの一部のパーティションが他のパーティションよりも先にオンラインに戻る場合があります。これは、これらのパーティションが、他のパーティションをキャッチアップしている (レプリケートしている) のと同じブローカーからのトラフィックを提供している可能性があるため、問題になる可能性があります。このレプリケーショントラフィックは、基盤となるボリュームスループット制限を飽和させる場合があります。制限は、デフォルトの場合、1 秒あたり 250 MiB です。この飽和状態が発生すると、既にキャッチアップされているパーティションが影響を受け、キャッチアップされたパーティション (リモート Ack `acks=all` によるリーダーパーティションだけでなく) と ISR を共有するブローカーのクラスター全体のレイテンシーが発生します。この問題は、サイズが異なるパーティションの数が多い大規模なクラスターでより一般的です。
**推奨事項**
+ レプリケーション I/O の体制を改善するには、[ベストプラクティスのスレッド設定](https://docs.aws.amazon.com/msk/latest/developerguide/bestpractices.html#optimize-broker-threads)が整っていることを確認します。
+ 基になるボリューム飽和の可能性を減らすには、より高いスループットでプロビジョニングされたストレージを有効にします。高スループットレプリケーションの場合、最小スループット値は 500 MiB/秒が推奨されますが、実際に必要な値はスループットとユースケースによって異なります。[Amazon MSK クラスター 内の標準 ブローカー の ストレージ スループットを プロビジョニング する](msk-provision-throughput.md)。
+ レプリケーション圧力を最小限に抑えるには、`num.replica.fetchers` をデフォルト値 `2` に下げます。
## コンシューマーグループが `PreparingRebalance` 状態から変化しない
1 つ以上のコンシューマーグループが永続的リバランシング状態から変化しない場合、原因は Apache Kafka の問題である、[KAFKA-9752](https://issues.apache.org/jira/browse/KAFKA-9752) の可能性があります。これは Apache Kafka バージョン 2.3.1 および 2.4.1 に影響します。
この問題を解決するには、クラスターをこの問題の修正が含まれている [Amazon MSK のバグ修正バージョン 2.4.1.1](supported-kafka-versions.md#2.4.1.1) にアップグレードすることをお勧めします。既存のクラスターを Amazon MSK バグ修正バージョン 2.4.1.1 に更新する方法については、「[Apache Kafka バージョンのアップグレード](version-upgrades.md)」を参照してください。
クラスターを Amazon MSK バグ修正バージョン 2.4.1.1 にアップグレードせずにこの問題を解決するための回避策は、Kafka クライアントを [静的メンバーシッププロトコル](#consumer-group-rebalance-static) を使用するように設定するか、またはスタックしたコンシューマーグループの調整ブローカーノードを [識別と再起動](#consumer-group-rebalance-reboot) します。
### 静的メンバーシッププロトコルの実装
クライアントに静的メンバーシッププロトコルを実装するには、以下を実行します。
1. [ Kafka Consumers](https://kafka.apache.org/26/javadoc/index.html?org/apache/kafka/clients/consumer/KafkaConsumer.html) の設定で `group.instance.id` のプロパティを、グループ内のコンシューマを識別する静的文字列に設定します。
1. 設定の他のインスタンスが静的文字列を使用できるように更新されていることを確認してください。
1. Kafka コンシューマーに変更をデプロイします。
静的メンバーシッププロトコルの使用は、クライアント構成のセッションタイムアウトが、コンシューマグループのリバランスを早期にトリガーすることなくリカバリできる期間に設定されている場合、より効果的です。例えば、コンシューマーアプリケーションが 5 分間の使用不可を許容できる場合、セッションタイムアウトの妥当な値は、デフォルト値の 10 秒ではなく 4 分になります。
**注記**
静的メンバーシッププロトコルを使用すると、この問題が発生する確率を低下させることができます。しかし、静的メンバーシッププロトコルを使用していても、この問題が発生する可能性はあります。
### コーディネートブローカーノードの再起動
コーディネートブローカーノードを再起動するには、以下の操作を実行します。
1. 「`kafka-consumer-groups.sh`」コマンドを使用してグループコーディネーターを特定します。
1. スタックしたコンシューマーグループのグループコーディネーターを、API アクションの [RebootBroker](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-reboot-broker.html#RebootBroker) を使用してリスタートします。
## Amazon CloudWatch Logs へのブローカーログの配信エラー
Amazon CloudWatch Logs にブローカーログを送信するようにクラスターを設定する際には、以下の 2 つのうちのどちらかの例外が発生することがあります。
`InvalidInput.LengthOfCloudWatchResourcePolicyLimitExceeded` 例外が発生した場合は、`/aws/vendedlogs/` から始まるロググループを使用して再試行してください。詳細については、「[特定の Amazon Web Services からのログ記録を有効にする](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html)」を参照してください。
`InvalidInput.NumberOfCloudWatchResourcePoliciesLimitExceeded` 例外が発生した場合は、アカウントで Amazon CloudWatch Logs の既存のポリシーを選択し、次の JSON をそのポリシーに追加してください。
```
{"Sid":"AWSLogDeliveryWrite","Effect":"Allow","Principal":{"Service":"delivery.logs.amazonaws.com"},"Action":["logs:CreateLogStream","logs:PutLogEvents"],"Resource":["*"]}
```
上の JSON を既存のポリシーに追加しようとして、選択したポリシーの最大長に達しているというエラーが表示された場合は、Amazon CloudWatch Logs の別のポリシーに JSON を追加してみてください。既存のポリシーに JSON を追加したら、もう一度 Amazon CloudWatch Logs へのブローカーログの配信を設定してください。
## デフォルトのセキュリティグループがない
クラスターを作成しようとしたときに、デフォルトのセキュリティグループがないことを示すエラーが表示される場合は、共有された VPC を使用している可能性があります。管理者に、この VPC のセキュリティグループを記述するアクセス許可を付与してもらうよう依頼して、再試行してください。このアクションを許可するポリシーの例については、「[Amazon EC2: 特定の VPC に関連付けられた EC2 セキュリティグループの管理をプログラムによりコンソールで許可する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_ec2_securitygroups-vpc.html)」を参照してください。
## クラスターが [作成中] 状態のまま停止しているように見える
クラスターの作成には、最大 30 分かかる場合があります。30 分間待ってから、クラスターの状態を再度確認します。
## クラスターの状態が [作成中] から [失敗] に変わる
クラスターをもう一度作成してみてください。
## クラスターの状態は [アクティブ] であるが、プロデューサーがデータを送信できないか、コンシューマーがデータを受信できない
+ クラスターの作成が成功した (クラスターの状態は `ACTIVE`) がデータの送受信ができない場合は、プロデューサーおよびコンシューマーのアプリケーションがクラスターにアクセスできることを確認してください。詳細については、[ステップ 3: クライアントマシンを作成する](create-client-machine.md) のガイダンスを参照してください。
+ プロデューサーとコンシューマーにクラスターへのアクセスがある場合で、データの生成と消費に問題が生じる場合、原因は [KAFKA-7697](https://issues.apache.org/jira/browse/KAFKA-7697) である可能性があります。これは、Apache Kafka バージョン 2.1.0 に影響し、1 つ以上のブローカーでデッドロックを引き起こす可能性があります。このバグの影響を受けない Apache Kafka 2.2.1 への移行を検討してください。統合する方法について詳細は、「[Kafka ワークロードを Amazon MSK クラスターに移行する](migration.md)」を参照してください。
## AWS CLI が Amazon MSK を認識しない
AWS CLI がインストールされているが、Amazon MSK コマンドを認識しない場合は、 AWS CLI を最新バージョンにアップグレードします。のアップグレード方法の詳細については AWS CLI、[「 のインストール AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」を参照してください。を使用して Amazon MSK コマンド AWS CLI を実行する方法については、「」を参照してください[Amazon MSK の主な特徴および概念](operations.md)。
## パーティションがオフラインになるか、レプリカが同期しない
これは、ディスクの容量不足の症状である可能性があります。「[ディスク容量が不足している](#troubleshooting-lowdiskspace)」を参照してください。
## ディスク容量が不足している
ディスク容量の管理に関するベストプラクティスについては、「[ディスク容量のモニタリング](bestpractices.md#bestpractices-monitor-disk-space)」および「[データ保持パラメータの調整](bestpractices.md#bestpractices-retention-period)」を参照してください。
## メモリが不足している
`MemoryUsed` メトリックが高くなったり、`MemoryFree` が低くなったりしても、問題があるわけではありません。Apache Kafka はできるだけ多くのメモリを使用し、最適に管理するように設計されています。
## プロデューサーが NotLeaderForPartitionException を取得する
これは時折発生する一時的なエラーです。プロデューサーの `retries` の設定パラメータを現在の値よりも大きい値に設定してください。
## レプリケート不足のパーティション (URP) 数がゼロより大きい
`UnderReplicatedPartitions` メトリックは監視すべき重要なメトリックの 1 つです。正常な MSK クラスターでは、このメトリックの値は 0 です。ゼロより大きい場合は、次のいずれかの理由が考えられます。
+ `UnderReplicatedPartitions` がスパイクの場合、着信トラフィックと発信トラフィックを処理するために適切なサイズでクラスターがプロビジョニングされていないことが問題である可能性があります。「[標準 ブローカーのベストプラクティス](bestpractices.md)」を参照してください。
+ トラフィックが少ない期間も含めて `UnderReplicatedPartitions` が一貫して 0 より大きい場合、ブローカーにトピックアクセスを許可しない制限付き ACL が設定されていることが問題である可能性があります。パーティションを複製するには、ブローカーに READ トピックと DESCRIBE トピックの両方を許可する必要があります。DESCRIBE は、デフォルトで READ 権限が付与されます。ACL の設定については、Apache Kafka のドキュメントの「[認可と ACL](https://kafka.apache.org/documentation/#security_authz)」を参照してください。
## クラスターには \$1\$1amazon\$1msk\$1canary と \$1\$1amazon\$1msk\$1canary\$1state というトピックがあります
MSK クラスターのトピックの中に、`__amazon_msk_canary` および `__amazon_msk_canary_state` という名前のものがあることがあります。これらは Amazon MSK によって作成される、クラスターのヘルスと診断メトリクスに使用される内部トピックです。これらのトピックのサイズはごくわずかで、削除できません。
## パーティションレプリケーションが失敗する
CLUSTER\$1ACTIONS に ACL が設定されていないことを確認してください。
## パブリックアクセスが有効になっているクラスターにアクセスできない
クラスターでパブリックアクセスが有効になっていても、インターネットからアクセスできない場合は、以下の手順を実行します。
1. クラスターのセキュリティグループのインバウンドルールで、お使いのIP アドレスとクラスターのポートが許可されていることを確認します。クラスターポート番号のリストについては、[ポート情報](port-info.md) を参照してください。また、セキュリティグループのアウトバウンドルールでアウトバウンド通信が許可されていることを確認してください。セキュリティグループのインバウンドおよびアウトバウンドルールについてのより詳しい情報は、Amazon VPC ユーザーガイドの[VPC のセキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)を参照してください。
1. お使いの IP アドレスとクラスターのポートが、クラスターの VPC ネットワーク ACL のインバウンドルールで許可されていることを確認してください。セキュリティグループとは異なり、ネットワーク ACL はステートレスです。つまり、インバウンドルールとアウトバウンドルールの両方を設定する必要があります。アウトバウンドルールでは、IP アドレスへのすべてのトラフィック (ポート範囲: 0～65535) を許可します。より詳細な情報は、Amazon VPC ユーザーガイドの[ルールの追加と削除](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#Rules)を参照してください。
1. クラスターにアクセスする際は、パブリックアクセスブートストラップブローカーの文字列を使用してください。パブリックアクセスが有効な MSK クラスターには、パブリックアクセス用と AWS内部からのアクセス用の 2 つの異なるブートストラップブローカーの文字列があります。詳細については、「[を使用してブートストラップブローカーを取得する AWS マネジメントコンソール](get-bootstrap-console.md)」を参照してください。
## IPv6 ブートストラップを介してクラスターにアクセスできない
提供された IPv6 ブートストラップ文字列を使用してクラスターに接続できない場合は、次の手順に従います。
1. クライアントに IPv4 アドレスと IPv6 アドレスの両方が割り当てられていることを確認します。クライアントアプリケーションは、IPv4 と IPv6 の両方のアドレス指定が有効で適切に設定されたサブネットで実行されている必要があります。VPC に IPv4 CIDR ブロックと関連付けられた IPv6 CIDR ブロックの両方があるかどうかを確認し、サブネットで IPv4 アドレスと IPv6 アドレスの両方が有効になっていることを確認し、EC2 インスタンスまたはクライアント環境で IPv4 アドレスと IPv6 アドレスの両方が割り当てられていることを確認します。詳細については、[VPCs ユーザーガイド」の「VPC とサブネットの IP アドレス指定](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html)」を参照してください。
1. 関連する IPv6 ポートがセキュリティグループのインバウンドルールとアウトバウンドルールに存在することを確認します。IPv6 アドレスからのクラスターのポートへのトラフィックを許可するインバウンドルールを追加し、IPv6 トラフィックを許可するアウトバウンドルールを設定します。特定のポート番号については、MSK ドキュメントの[「ポート情報](https://docs.aws.amazon.com/msk/latest/developerguide/port-info.html)」を参照してください。デュアルスタックモードで実行している場合は、IPv4 ルールと IPv6 ルールの両方を更新してください。セキュリティグループのインバウンドおよびアウトバウンドルールについてのより詳しい情報は、Amazon VPC ユーザーガイドの[VPC のセキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html)を参照してください。
1. IPv6 サポートの JVM プロパティ設定が正しいことを確認します。クライアントアプリケーションで、 `java.net.preferIPv6Addresses` を に設定`true`し、 `java.net.preferIPv4Stack` を に設定します`false`。これらの設定は、システムプロパティまたは JVM 引数として設定できます。これらの変更を有効にしたら、アプリケーションを再起動します。
## 内からクラスターにアクセスできない AWS: ネットワークの問題
Apache Kafka アプリケーションが MSK クラスターと正常に通信できない場合は 、まず次の接続テストを実行します。
1. 「[Amazon MSK クラスターのブートストラップブローカーを取得する](msk-get-bootstrap-brokers.md)」で説明されている方法のいずれかを使用して、ブートストラップブローカーのアドレスを取得します。
1. 次のコマンドで、*bootstrap-broker* を前のステップで取得したブローカーアドレスの 1 つに置き換えます。クラスターが TLS 認証を使用するように設定されている場合は、*port-number* を 9094 に置き換えます。クラスターで TLS 認証を使用しない場合は、*port-number* を 9092 に置き換えます。クライアントマシンからコマンドを実行します。
```
telnet bootstrap-broker port-number
```
ここで、ポート番号は次の値になります。
+ クラスターが TLS 認証を使用するように設定されている場合、9094。
+ クラスターで TLS 認証を使用しない場合、9092。
+ パブリックアクセスが有効になっている場合は、別のポート番号が必要です。
クライアントマシンからコマンドを実行します。
1. すべてのブートストラップブローカーに対して上記のコマンドを繰り返します。
クライアントマシンがブローカーにアクセスできる場合は、接続に問題はありません。この場合、Apache Kafka クライアントが正しく設定されているかどうかを確認するには、次のコマンドを実行します。*bootstrap-brokers* を取得するには、「[Amazon MSK クラスターのブートストラップブローカーを取得する](msk-get-bootstrap-brokers.md)」で説明されているいずれかの方法を使用します。*topic* をトピックの名前に置き換えます。
```
/bin/kafka-console-producer.sh --broker-list bootstrap-brokers --producer.config client.properties --topic topic
```
前のコマンドが成功した場合は、クライアントが正しくセットアップされていることを意味します。それでもアプリケーションから生成および使用できない場合は、アプリケーションレベルで問題をデバッグします。
クライアントマシンがブローカーにアクセスできない場合、以下のサブセクションで、クライアントマシンの設定に基づくガイダンスを参照してください。
### 同じ VPC 内の Amazon EC2 クライアントおよび MSK クラスター
クライアントマシンが MSK クラスターと同じ VPC にある場合、クラスターのセキュリティグループに、クライアントマシンのセキュリティグループからのトラフィックを受け入れるインバウンドルールがあることを確認します。これらのルールの設定については、[セキュリティグループルール](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SecurityGroupRules)を参照してください。クラスターと同じ VPC にある Amazon EC2 インスタンスからクラスターにアクセスする方法の例については、「[Amazon MSK の使用を開始する](getting-started.md)」を参照してください。
### 異なる VPC 内の Amazon EC2 クライアントと MSK クラスター
クライアントマシンとクラスターが 2 つの異なる VPC にある場合は、次のことを確認します。
+ 2 つの VPC がピア接続されている。
+ ピア接続のステータスはアクティブである。
+ 2 つの VPC のルートテーブルが正しく設定されている。
VPC ピア接続の詳細については、「[VPC ピア接続の使用](https://docs.aws.amazon.com/vpc/latest/peering/working-with-vpc-peering.html)」を参照してください。
### オンプレミスクライアント
を使用して MSK クラスターに接続するように設定されたオンプレミスクライアントの場合は Site-to-Site VPN、以下を確認してください。
+ VPN 接続のステータスは `UP` である。VPN 接続のステータスを確認する方法については、「[VPN トンネルの現在のステータスを確認するにはどうすればよいですか?](https://aws.amazon.com/premiumsupport/knowledge-center/check-vpn-tunnel-status/)」を参照してください。
+ クラスターの VPC のルートテーブルには、ターゲットが `Virtual private gateway(vgw-xxxxxxxx)` 形式であるオンプレミス CIDR のルートが含まれています。
+ MSK クラスターのセキュリティグループは、ポート 2181、ポート 9092 (クラスターがプレーンテキストのトラフィックを受け入れる場合)、ポート 9094 (クラスターが TLS で暗号化されたトラフィックを受け入れる場合) でトラフィックを許可します。
Site-to-Site VPN トラブルシューティングガイダンスの詳細については、[「クライアント VPN のトラブルシューティング](https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/troubleshooting.html)」を参照してください。
### Direct Connect
クライアントが を使用している場合は Direct Connect、[「トラブルシューティング Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Troubleshooting.html)」を参照してください。
上記のトラブルシューティングガイダンスで問題が解決しない場合は、ファイアウォールがネットワークトラフィックをブロックしていないことを確認します。さらにデバッグを行う際は、`tcpdump` や `Wireshark` などのツールを使用してトラフィックを分析し、トラフィックが MSK クラスターに到達していることを確認してください。
## 認証の失敗: 接続が多すぎる
`Failed authentication ... Too many connects` エラーは、1 つ以上の IAM クライアントが過剰な頻度で接続を試みているため、ブローカーが自身を保護していることを示しています。ブローカーがより高頻度で新しい IAM 接続を受け入れることができるように、[https://kafka.apache.org/documentation/#producerconfigs_reconnect.backoff.ms](https://kafka.apache.org/documentation/#producerconfigs_reconnect.backoff.ms) 設定パラメータを増やすことができます。
ブローカーごとの新規接続頻度の制限について詳しくは、「[Amazon MSK クォータ](limits.md)」ページを参照してください。
## 認証の失敗: セッションが短すぎます
`Failed authentication ... Session too short` エラーは、クライアントが、まもなく期限切れになる IAM 認証情報を使用してクラスターに接続しようとすると発生します。IAM 認証情報の更新方法を確認してください。おそらく、認証情報がセッションの有効期限の直前に置き換えられ、サーバー側で問題が発生し、認証が失敗します。
## MSK サーバーレス: クラスターの作成に失敗する
MSK サーバーレスクラスターを作成しようとしてワークフローが失敗した場合、VPC エンドポイントを作成するアクセス許可がない可能性があります。`ec2:CreateVpcEndpoint` アクションを許可して、管理者によって VPC エンドポイントを作成するアクセス許可が付与されていることを確認します。
すべての Amazon MSK アクションを実行するために必要なアクセス許可の完全なリストについては、「[AWS マネージドポリシー: AmazonMSKFullAccess](security-iam-awsmanpol-AmazonMSKFullAccess.md)」を参照してください。
## MSK 設定で KafkaVersionsList を更新できません
[AWS::MSK::Configuration](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html) リソースの [KafkaVersionsList](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html#cfn-msk-configuration-kafkaversionslist) プロパティを更新すると、更新は次のエラーで失敗します。
```
Resource of type 'AWS::MSK::Configuration' with identifier '' already exists.
```
`KafkaVersionsList` プロパティを更新すると、 は古い設定を削除する前に、更新されたプロパティを使用して新しい設定 AWS CloudFormation を再作成します。新しい設定が既存の設定と同じ名前を使用するため、 CloudFormation スタックの更新は失敗します。このような更新には、[リソースの置き換え](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-update-behaviors.html#update-replacement) が必要です。正常に `KafkaVersionsList` を更新するには、同じオペレーションで [Name](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html#cfn-msk-configuration-name) プロパティも更新する必要があります。
さらに、設定が AWS マネジメントコンソール または を使用して作成されたクラスターにアタッチされている場合は AWS CLI、[リソースの削除試行の失敗](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors-resource-removed-not-deleted)を防ぐために、設定リソースに以下を追加します。
```
UpdateReplacePolicy: Retain
```
更新が成功した後、Amazon MSK コンソールに移動し、古い設定を削除してください。MSK 設定の詳細については、「[Amazon MSK Provisioned 設定](msk-configuration.md)」を参照してください。