Amazon MSKクラスターのトラブルシューティング - Amazon Managed Streaming for Apache Kafka
ボリュームの置き換えにより、レプリケーションの過負荷によりディスクが飽和するコンシューマーグループが PreparingRebalance 状態から変化しないAmazon CloudWatch Logs へのブローカーログの配信エラーデフォルトのセキュリティグループがないクラスターが CREATING 状態でスタックしているように見えるクラスターの状態が から CREATING に変わる FAILEDクラスターの状態は ACTIVEですが、プロデューサーはデータを送信できないか、コンシューマーはデータを受信できませんAWS CLI は Amazon を認識しません MSKパーティションがオフラインになるか、レプリカが同期しないディスク容量が不足しているメモリが不足しているプロデューサーが取得する NotLeaderForPartitionException0 より大きいレプリケート不足パーティション (URP）クラスターには __amazon_msk_canary と __amazon_msk_canary_state というトピックがありますパーティションレプリケーションが失敗するパブリックアクセスが有効になっているクラスターにアクセスできない内からクラスターにアクセスできない AWS: ネットワークの問題認証の失敗: 接続が多すぎるMSK サーバーレス: クラスターの作成が失敗する

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

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

以下の情報は、Amazon MSKクラスターで発生する可能性のある問題のトラブルシューティングに役立ちます。AWS re:Post に問題を投稿することもできます。Amazon MSK レプリケーターのトラブルシューティングについては、「」を参照してくださいMSK レプリケーターのトラブルシューティング。

ボリュームの置き換えにより、レプリケーションの過負荷によりディスクが飽和する

予期しないボリュームハードウェア障害が発生した場合、Amazon はボリュームを新しいインスタンスに置き換えるMSKことがあります。Kafka は、クラスター内の他のブローカーからパーティションをレプリケートすることで、新しいボリュームを再入力します。パーティションがレプリケートされ、キャッチアップされると、リーダーシップとインシンクレプリカ (ISR) メンバーシップの対象となります。

問題

ボリュームの置き換えから回復するブローカーでは、さまざまなサイズのパーティションが他のパーティションよりも先にオンラインになる場合があります。これは、これらのパーティションが、他のパーティションに追いついている (レプリケートしている) のと同じブローカーからのトラフィックを提供している可能性があるため、問題になる可能性があります。このレプリケーショントラフィックは、基盤となるボリュームスループット制限を飽和させる場合があります。デフォルトの場合、1 秒あたり 250 MiB です。この飽和状態が発生すると、すでにキャッチアップされているパーティションに影響し、キャッチアップされたパーティション (リモートアックによるリーダーパーティションだけでなく) ISR と共有しているブローカーのクラスター全体のレイテンシーが発生しますacks=all。この問題は、サイズが異なるパーティションの数が多い大規模なクラスターでより一般的です。

推奨事項

  • レプリケーション I/O の体制を改善するには、ベストプラクティスのスレッド設定が設定されていることを確認してください。

  • 基になるボリューム飽和の可能性を減らすには、より高いスループットでプロビジョニングされたストレージを有効にします。ハイスループットレプリケーションの場合、最小スループット値は 500 MiB /秒が推奨されますが、必要な実際の値はスループットとユースケースによって異なりますAmazon MSKクラスター内のブローカーのストレージスループットのプロビジョニング。

  • レプリケーション圧力を最小限に抑えるには、 をデフォルト値 num.replica.fetchersに下げます2。

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

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

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

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

静的メンバーシッププロトコルの実装

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

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

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

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

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

注記

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

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

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

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

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

Amazon CloudWatch Logs へのブローカーログの配信エラー

Amazon CloudWatch Logs にブローカーログを送信するようにクラスターを設定しようとすると、2 つの例外のいずれかが表示される場合があります。

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

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: 特定の に関連付けられたEC2セキュリティグループの管理をプログラムで許可するVPC」を参照してください。

クラスターが CREATING 状態でスタックしているように見える

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

クラスターの状態が から CREATING に変わる FAILED

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

クラスターの状態は ACTIVEですが、プロデューサーはデータを送信できないか、コンシューマーはデータを受信できません

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

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

AWS CLI は Amazon を認識しません MSK

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

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

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

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

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

メモリが不足している

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

プロデューサーが取得する NotLeaderForPartitionException

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

0 より大きいレプリケート不足パーティション (URP）

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

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

  • トラフィックが少ない期間を含め、一貫して UnderReplicatedPartitionsが 0 より大きい場合、問題は、トピックへのアクセスをブローカーに許可ACLsしない制限を設定していることかもしれません。パーティションをレプリケートするには、ブローカーが READおよび DESCRIBEトピックの両方に対して承認されている必要があります。DESCRIBE は、デフォルトで READ認証で付与されます。の設定の詳細についてはACLs、「Apache Kafka ドキュメント」の「認証」とACLs「」を参照してください。

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

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

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

CLUSTER_ ACLsに設定していないことを確認しますACTIONS。

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

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

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

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

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

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

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

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

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

    telnet bootstrap-broker port-number

    port-number が次の場合：

    • クラスターがTLS認証を使用するように設定されている場合は 9094。

    • 9092 クラスターがTLS認証を使用しない場合。

    • パブリックアクセスが有効になっている場合は、別のポート番号が必要です。

    クライアントマシンからコマンドを実行します。

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

クライアントマシンがブローカーにアクセスできる場合は、接続に問題がないことを意味します。この場合、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

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

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

同じ の Amazon EC2クライアントとMSKクラスター VPC

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

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

クライアントマシンとクラスターが 2 つの異なる にある場合はVPCs、以下を確認してください。

  • この 2 VPCsつはピアリングされています。

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

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

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

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

を使用してMSKクラスターに接続するようにセットアップされているオンプレミスクライアントの場合は AWS VPN、以下を確認してください。

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

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

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

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

AWS Direct Connect

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

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

認証の失敗: 接続が多すぎる

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

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

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

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

すべての Amazon MSKアクションを実行するために必要なアクセス許可の完全なリストについては、「」を参照してくださいAWS マネージドポリシー: mazonMSKFullアクセス。