Amazon MSK クラスターのトラブルシューティング

次の情報は、お使いの Amazon MSK クラスター に関する問題を解決するために役立ちます。問題を投稿することもできますAWS re:Post。

コンシューマーグループが PreparingRebalance 状態から変化しない

1 つ以上のコンシューマーグループが永続的リバランシング状態から変化しない場合、原因は Apache Kafka の問題である、KAFKA-9752 の可能性があります。これは Apache Kafka バージョン 2.3.1 および 2.4.1 に影響します。

この問題を解決するには、クラスターをこの問題の修正が含まれている Amazon MSK のバグ修正バージョン 2.4.1.1 にアップグレードすることをお勧めします。既存のクラスターを Amazon MSK バグ修正バージョン 2.4.1.1 に更新する方法については、「Apache Kafka バージョンの更新」を参照してください。

クラスターを Amazon MSK バグ修正バージョン 2.4.1.1 にアップグレードせずにこの問題を解決するための回避策は、Kafka クライアントを スタティック・メンバーシップ・プロトコル を使用するように設定するか、またはスタックしたコンシューマーグループの調整ブローカーノードを 確認して再起動 します。

スタティック・メンバーシップ・プロトコルの実装

クライアントに静的メンバーシッププロトコルを実装するには、以下を実行します。

1. Kafka Consumers の設定で group.instance.id のプロパティを、グループ内のコンシューマを識別する静的文字列に設定します。

2. 設定の他のインスタンスが静的文字列を使用できるように更新されていることを確認してください。

3. Kafka コンシューマーに変更をデプロイします。

静的メンバーシッププロトコルの使用は、クライアント構成のセッションタイムアウトが、コンシューマグループのリバランスを早期にトリガーすることなくリカバリできる期間に設定されている場合、より効果的です。例えば、コンシューマーアプリケーションが 5 分間の使用不可を許容できる場合、セッションタイムアウトの妥当な値は、デフォルト値の 10 秒ではなく 4 分になります。

注記

静的メンバーシッププロトコルを使用すると、この問題が発生する確率を低下させることができます。しかし、静的メンバーシッププロトコルを使用していても、この問題が発生する可能性はあります。

コーディネートブローカーノードの再起動

コーディネートブローカーノードを再起動するには、以下の操作を実行します。

1. 「kafka-consumer-groups.sh」コマンドを使用してグループコーディネーターを特定します。

2. を使用して、スタックしているコンシューマグループのグループコーディネーターを再起動します。 RebootBrokerAPI アクション。

Amazon へのブローカーログの配信中にエラーが発生しましたCloudWatchログ

Amazon にブローカーログを送信するようにクラスターを設定しようとするとCloudWatchログ、2つの例外のいずれかが発生する可能性があります。

InvalidInput.LengthOfCloudWatchResourcePolicyLimitExceeded 例外が発生した場合は、/aws/vendedlogs/ から始まるロググループを使用して再試行してください。詳細については、「特定の Amazon Web Services からのログ記録を有効にする」を参照してください。

手に入れたらInvalidInput.NumberOfCloudWatchResourcePoliciesLimitExceeded例外、既存の Amazon を選択してくださいCloudWatchアカウントにポリシーを記録し、次の JSON を追加します。

{"Sid":"AWSLogDeliveryWrite","Effect":"Allow","Principal":{"Service":"delivery.logs.amazonaws.com"},"Action":["logs:CreateLogStream","logs:PutLogEvents"],"Resource":["*"]}

上記の JSON を既存のポリシーに追加しようとしても、選択したポリシーの最大長に達したというエラーが表示される場合は、その JSON を別の Amazon のポリシーに追加してみてください。CloudWatchポリシーをログに記録します。JSON を既存のポリシーに追加したら、Amazon へのブローカーログ配信の設定をもう一度試してください。CloudWatchログ。

デフォルトのセキュリティグループがない

クラスターを作成しようとしたときに、デフォルトのセキュリティグループがないことを示すエラーが表示される場合は、共有された VPC を使用している可能性があります。管理者に、この VPC のセキュリティグループを記述するアクセス許可を付与してもらうよう依頼して、再試行してください。このアクションを許可するポリシーの例については、「Amazon EC2: 特定の VPC に関連付けられた EC2 セキュリティグループの管理をプログラムによりコンソールで許可する」を参照してください。

クラスターが [作成中] 状態のまま停止しているように見える

クラスターの作成には、最大 30 分かかる場合があります。30 分間待ってから、クラスターの状態を再度確認します。

クラスターの状態が [作成中] から [失敗] に変わる

クラスターをもう一度作成してみてください。

クラスターの状態は [アクティブ] であるが、プロデューサーがデータを送信できないか、コンシューマーがデータを受信できない

• クラスターの作成が成功した（クラスターの状態は ACTIVE）がデータの送受信ができない場合は、プロデューサーおよびコンシューマーのアプリケーションがクラスターにアクセスできることを確認してください。詳細については、ステップ 3: クライアントマシンを作成する のガイダンスを参照してください。

• プロデューサーとコンシューマーにクラスターへのアクセスがある場合で、データの生成と消費に問題が生じる場合、原因は KAFKA-7697 である可能性があります。これは、Apache Kafka バージョン 2.1.0 に影響し、1 つ以上のブローカーでデッドロックを引き起こす可能性があります。このバグの影響を受けない Apache Kafka 2.2.1 への移行を検討してください。統合する方法について詳細は、「Apache Kafkaを使用してクラスターを移行する MirrorMaker」を参照してください。

AWS CLI が Amazon MSKを認識しない

AWS CLI がインストールされていても Amazon MSK コマンドが認識されない場合は、AWS CLI を最新バージョンにアップグレードしてください。AWS CLI をアップグレードする方法の詳細については、「AWS Command Line Interface のインストール」を参照してください。AWS CLI を使用して Amazon MSK コマンドを実行する方法については、「Amazon MSK: 仕組み」を参照してください。

パーティションがオフラインになるか、レプリカが同期しない

これは、ディスクの容量不足の症状である可能性があります。ディスク容量が不足している を参照してください。

ディスク容量が不足している

ディスク容量の管理に関するベストプラクティスについては、「ディスク容量のモニタリング」および「データ保持パラメータの調整」を参照してください。

メモリが不足している

MemoryUsed メトリックが高くなったり、MemoryFree が低くなったりしても、問題があるわけではありません。Apache Kafka はできるだけ多くのメモリを使用し、最適に管理するように設計されています。

プロデューサーが受け取るNotLeaderForPartitionException

これは時折発生する一時的なエラーです。プロデューサーの retries の設定パラメータを現在の値よりも大きい値に設定してください。

複製が不十分なパーティション (URP) がゼロより大きい

UnderReplicatedPartitions メトリックは監視すべき重要なメトリックの 1 つです。正常な MSK クラスターでは、このメトリックの値は 0 です。ゼロより大きい場合は、次のいずれかの理由が考えられます。

• UnderReplicatedPartitions がスパイクの場合、着信トラフィックと発信トラフィックを処理するために適切なサイズでクラスターがプロビジョニングされていないことが問題である可能性があります。ベストプラクティス を参照してください。

• もしUnderReplicatedPartitionsトラフィックが少ない期間も含め、常に 0 より大きい場合、問題は、ブローカーにトピックアクセスを許可しない制限付き ACL を設定したことが原因と考えられます。パーティションを複製するには、ブローカーに READ トピックと DESCRIBE トピックの両方を許可する必要があります。DESCRIBE は、デフォルトで READ 権限が付与されます。ACL の設定については、Apache Kafka のドキュメントの「認証と ACL」を参照してください。

クラスターには __amazon_msk_canary と __amazon_msk_canary_state というトピックがあります

MSK クラスターのトピックの中に、__amazon_msk_canary および __amazon_msk_canary_state という名前のものがあることがあります。これらは Amazon MSK によって作成される、クラスターのヘルスと診断メトリクスに使用される内部トピックです。これらのトピックのサイズはごくわずかで、削除できません。

パーティションレプリケーションが失敗する

CLUSTER_ACTIONS に ACL が設定されていないことを確認してください。

パブリックアクセスが有効になっているクラスターにアクセスできない

クラスターでパブリックアクセスが有効になっていても、インターネットからアクセスできない場合は、以下の手順を実行します。

1. クラスターのセキュリティグループのインバウンドルールで、お使いのIP アドレスとクラスターのポートが許可されていることを確認します。クラスターポート番号のリストについては、ポート情報 を参照してください。また、セキュリティグループのアウトバウンドルールでアウトバウンド通信が許可されていることを確認してください。セキュリティグループのインバウンドおよびアウトバウンドルールについてのより詳しい情報は、Amazon VPC ユーザーガイドのVPC のセキュリティグループを参照してください。

2. お使いの IP アドレスとクラスターのポートが、クラスターの VPC ネットワーク ACL のインバウンドルールで許可されていることを確認してください。セキュリティグループとは異なり、ネットワーク ACL はステートレスです。つまり、インバウンドルールとアウトバウンドルールの両方を設定する必要があります。アウトバウンドルールでは、IPアドレスへのすべてのトラフィック（ポート範囲：0～65535）を許可します。より詳細な情報は、Amazon VPC ユーザーガイドのルールの追加と削除を参照してください。

3. クラスターにアクセスする際は、パブリックアクセスブートストラップブローカーの文字列を使用してください。パブリックアクセスが有効な MSK クラスターには、パブリックアクセス用と AWS 内部からのアクセス用の 2 つの異なるブートストラップブローカーの文字列があります。詳細については、「AWS Management Console を使用したブートストラップブローカーの取得」を参照してください。

内部からクラスターにアクセスできないAWS: ネットワークの問題

Apache Kafka アプリケーションが MSK クラスターと正常に通信できない場合は 、まず次の接続テストを実行します。

1. 「Amazon MSK クラスターで使用するブートストラップブローカーの取得」で説明されている方法のいずれかを使用して、ブートストラップブローカーのアドレスを取得します。

2. 次のコマンドで、bootstrap-broker を前のステップで取得したブローカーアドレスの 1 つに置き換えます。クラスターが TLS 認証を使用するように設定されている場合は、port-number を 9094 に置き換えます。クラスターで TLS 認証を使用しない場合は、port-number を 9092 に置き換えます。クライアントマシンからコマンドを実行します。

   telnet bootstrap-broker port-number

3. すべてのブートストラップブローカーに対して上記のコマンドを繰り返します。

4. で説明されている方法のいずれかを使用してくださいAmazon MSK クラスターに使用する Apache Manage ZooKeeper 接続文字列の取得クラスターの Apache のアドレスを取得するにはZooKeeperノード。

5. クライアントマシンで次のコマンドを実行し、置き換えますアパッチ-ZooKeeper-ノードアパッチのどちらかのアドレスでZooKeeper前のステップで取得したノード。2181 はポート番号です。すべての Apache に対して同じ手順を繰り返しますZooKeeperノード。

   telnet Apache-ZooKeeper-node 2181

クライアントマシンがブローカーと Apache にアクセスできる場合ZooKeeperノード、これは接続の問題がないことを意味します。この場合、Apache Kafka クライアントが正しく設定されているかどうかを確認するには、次のコマンドを実行します。bootstrap-brokers を取得するには、「Amazon MSK クラスターで使用するブートストラップブローカーの取得」で説明されているいずれかの方法を使用します。topic をトピックの名前に置き換えます。

<path-to-your-kafka-installation>/bin/kafka-console-producer.sh --broker-list bootstrap-brokers --producer.config client.properties —topic topic

前のコマンドが成功した場合は、クライアントが正しくセットアップされていることを意味します。それでもアプリケーションから生成および使用できない場合は、アプリケーションレベルで問題をデバッグします。

クライアントマシンがブローカーと Apache にアクセスできない場合ZooKeeperノード。クライアントマシン設定に基づくガイダンスについては、以下のサブセクションを参照してください。

同じ VPC 内の Amazon EC2 クライアントおよび MSK クラスター

クライアントマシンが MSK クラスターと同じ VPC にある場合、クラスターのセキュリティグループに、クライアントマシンのセキュリティグループからのトラフィックを受け入れるインバウンドルールがあることを確認します。これらのルールの設定については、セキュリティグループルールを参照してください。クラスターと同じ VPC にある Amazon EC2 インスタンスからクラスターにアクセスする方法の例については、「Amazon MSK の使用を開始する」を参照してください。

異なる VPC 内の Amazon EC2 クライアントと MSK クラスター

クライアントマシンとクラスターが 2 つの異なる VPC にある場合は、次のことを確認します。

• 2 つの VPC がピア接続されている。

• ピア接続のステータスはアクティブである。

• 2 つの VPC のルートテーブルが正しく設定されている。

VPC ピア接続の詳細については、「VPC ピア接続の使用」を参照してください。

オンプレミスクライアント

AWS VPN を使用して MSK クラスターに接続するように設定されているオンプレミスのクライアントの場合には、次のことを確認します。

• VPN 接続のステータスは UP である。VPN 接続のステータスを確認する方法については、「VPN トンネルの現在のステータスを確認するにはどうすればよいですか?」を参照してください。

• クラスターの VPC のルートテーブルには、ターゲットが Virtual private gateway(vgw-xxxxxxxx) 形式であるオンプレミス CIDR のルートが含まれています。

• MSK クラスターのセキュリティグループは、ポート 2181、ポート 9092 (クラスターがプレーンテキストのトラフィックを受け入れる場合)、ポート 9094 (クラスターが TLS で暗号化されたトラフィックを受け入れる場合) でトラフィックを許可します。

AWS VPN のトラブルシューティングガイダンスについては、「クライアント VPN のトラブルシューティング」を参照してください。

AWS Direct Connect

クライアントが AWS Direct Connect を使用する場合は、「AWS Direct Connect のトラブルシューティング」を参照してください。

上記のトラブルシューティングガイダンスで問題が解決しない場合は、ファイアウォールがネットワークトラフィックをブロックしていないことを確認します。さらにデバッグを行う際は、tcpdump や Wireshark などのツールを使用してトラフィックを分析し、トラフィックが MSK クラスターに到達していることを確認してください。

認証失敗:接続数が多すぎます

ザ・Failed authentication ... Too many connectserror は、1 つ以上の IAM クライアントがアグレッシブなレートで接続しようとしているため、ブローカーが自身を保護していることを示します。ブローカーがより高いレートで新しい IAM 接続を受け付けられるようにするには、reconnect.backoff.ms設定パラメーター。

ブローカーごとの新規接続のレート制限の詳細については、を参照してください。Amazon MSK クォータページ。

MSK サーバーレス:クラスターの作成が失敗する

MSK Serverless クラスターを作成しようとしてワークフローが失敗した場合、VPC エンドポイントを作成する権限がない可能性があります。管理者が VPC エンドポイントの作成を許可して VPC エンドポイントを作成する権限を付与していることを確認します。ec2:CreateVpcEndpointアクション。

すべての Amazon MSK アクションを実行するために必要な権限の一覧については、以下を参照してください。AWS管理ポリシー:アマゾンMSKFullAccess。