翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 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)」を参照してください。