ブローカーのオフラインおよびクライアントフェイルオーバー - Amazon Managed Streaming for Apache Kafka

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

ブローカーのオフラインおよびクライアントフェイルオーバー

Kafka はオフラインブローカーを許可します。ベストプラクティスに従う健全でバランスの取れたクラスター内の単一のオフラインブローカーについては、生成や消費の際に影響を及ぼしたり失敗の原因になることはありません。これは、別のブローカーがパーティションのリーダーシップを引き継ぎ、Kafka クライアントライブラリが自動的にフェイルオーバーして新しいリーダーブローカーへのリクエストの送信が開始されるためです。

クライアントサーバー契約

これにより、クライアントライブラリとサーバー側の動作での共有契約になります。サーバーでは 1 つ以上の新しいリーダーを正常に割り当て、クライアントではブローカーを変更して新しいリーダーへタイムリーにリクエストを送信する必要があります。

Kafka では、例外を使用してこのフローを制御します。

手順の例

  1. ブローカー A がオフライン状態になります。

  2. Kafka クライアントで例外 (通常はネットワーク切断または not_leader_for_partition) を受け取ります。

  3. これらの例外により、Kafka クライアントによるメタデータの更新がトリガーされ、最新のリーダーについて知ることができます。

  4. 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 クライアントライブラリの設定ミスまたは誤った使用。

  • サードパーティーのクライアントライブラリによる予期しないデフォルトの動作とバグ。

  • コントローラーが過負荷になることによる、パーティションリーダーの割り当ての遅延。

  • 新しいコントローラーが選択されることによる、パーティションリーダーの割り当ての遅延。

リーダーシップのフェイルオーバーを処理する際に正しい動作が確実に行われるようにするため、以下をお勧めします。

  • コントローラーのブローカーが適切にスケーリングされ、リーダーシップの割り当てが遅くならないように、サーバー側のベストプラクティスに従う必要があります。

  • クライアントライブラリでは、クライアントがフェイルオーバーを処理できるように再試行を有効にする必要があります。

  • クライアントライブラリでは、接続/リクエストストームを回避するため、retry.backoff.ms (デフォルトは 100) を設定する必要があります。

  • クライアントライブラリでは、request.timeout.ms と delivery.timeout.ms をアプリケーションの SLA に沿った値に設定する必要があります。値が大きいほど、特定の障害タイプでフェイルオーバーが遅くなります。

  • クライアントライブラリでは、初期検出での可用性への影響を回避するため、bootstrap.servers に少なくとも 3 つのランダムなブローカーが含まれていることを確認する必要があります。

  • 一部のクライアントライブラリは他のライブラリよりもレベルが低く、アプリケーションデベロッパーによる再試行ロジックと例外処理の実装が期待されます。使用例については、クライアントライブラリ固有のドキュメントを参照し、正しい再接続/再試行ロジックに従っていることを確認してください。

  • 生成、成功したリクエスト数、再試行不可能なエラーのエラー数については、クライアント側のレイテンシーをモニタリングすることをお勧めします。

  • ブローカーのオフライン期間中、リクエストの生成や消費に影響がないにもかかわらず、古いサードパーティーの golang ライブラリと ruby ライブラリが冗長モードのままであることがわかりました。リクエストメトリクスに加えて、ビジネスレベルのメトリクスを常にモニタリングし、ログに実際の影響とノイズがあるかどうかを判断することをお勧めします。

  • ネットワーク/not_leader の一時的な例外は正常であり、影響はなく kafka プロトコルの一部として想定されるため、警告しないでください。

  • UnderReplicatedPartitions は正常であり、影響はなく単一のオフラインブローカー中に発生することが予想されるため、警戒しないでください。