カフカがダブルイレブン中にメッセージを紛失したことに私は驚いた

[[438994]]

正直に言うと、今年のダブル11はちょっと運が悪かった。私が担当していた Kafka クラスターにはいくつか問題がありました。しかし、これらの問題があったからこそ、今年のダブル11は非常に充実したものになったのです。また、体系的に Kafka を学習しなければ、実稼働クラスターにタイムリーな警告を提供できず、障害を未然に防ぐことができないことにも気付きました。そこで、私はKafkaのカーネルを勉強しようと決心しました。

この記事では、まず、予想していなかった障害、つまり Kafka の運用環境での大規模なメッセージ損失についてお話しします。

まず最初に説明するのは、メッセージの損失は停電によるものではなく、クラスター内のレプリカの数は 3 であり、メッセージの送信者が設定した ack は -1 (すべて) であるということです。

このように厳密に設定しても、なぜメッセージの損失が発生するのでしょうか?著者の説明を聞いてください。

1. 断層現象

障害が発生したとき、複数のプロジェクト チームから、コンシューマー グループの場所が数日前にリセットされたというフィードバックを受け取りました。スクリーンショットは次のとおりです。

上記のコンシューマー グループの遅延監視曲線から判断すると、バックログ数が一瞬にしてゼロから急上昇し、当初はサイトがリセットされたのではないかと疑われました。

なぜポジションがリセットされるのでしょうか?

何？あなたの記事には、Kafka がメッセージを失った理由について書かれていませんでしたか?なぜ消費者団体の立場がリセットされたとおっしゃったのですか？なんとキャッチーなタイトルでしょう！！！

いいえ、いいえ、いいえ、読者の皆様、これはまったく的外れではありません。この質問を持ってきて、私と一緒に探究してみましょう。

2. 問題分析

問題に遭遇しても慌てないでください。正直に言うと、MQ ベースのアプリケーションの場合、コンシューマー側では通常、冪等性が実装されます。つまり、ビジネスに影響を与えることなくメッセージを繰り返し処理できます。したがって、解決策としては、まずプロジェクト チームに評価を依頼し、問題が発生する 30 分ほど前に手動で場所を設定して、出血を速やかに止めることです。

虎のように激しい一連の作戦の後、問題の原因を慎重に分析する必要があります。

当時の Kafka サーバーのログ (server.log) を確認すると、次のログが表示されます。

上記のログは認識できないほど変更されています。主なログは次のとおりです。

• グループ consumerGroupName のメンバー consumer-1-XX が失敗したため、グループから削除されました
• ハートビートの有効期限が切れたときにグループ XXXX を再調整する準備をしています

上記のログは非常に明確です。ハートビート検出の有効期限が切れたため、コンシューマー グループ コーディネーターがコンシューマーをコンシューマー グループから削除し、再バランスをトリガーしました。

コンシューマー グループの再バランス調整: トピック パーティションの数またはコンシューマーの数が変更された場合、コンシューマー側で負荷分散を実現するために、コンシューマー間でパーティションを再分配する必要があります。

再バランス調整期間中、すべてのメッセージ コンシューマーは消費を一時停止します。コンシューマーがパーティションの負荷分散を再度完了すると、サーバーからメッセージをプルし続けます。この時点では、消費者はどこから開始すればよいかわからないため、最後に消費した場所から消費を継続できるように、サーバーに場所を照会する必要があります。

これで、消費場所が最も早い場所にリセットされます。場所が分からなくなっていると理解できますか？では、なぜ位置が失われるのでしょうか?

理由は2つあります。

• サーバーは位置情報を失うため、クライアントは位置情報を照会できない
• クライアントがサーバーに-1を送信したため、サイトが失われました。

現在、当社ではKafkaバージョン2.2.xを使用しています。コンシューマ グループの場所は、システム トピック (__consumer_offsets) に保存されます。サーバー レベルでもトピック レベルでも、パラメーター unclean.leader.election.enable は false に設定され、ISR セット内のレプリカのみがリーダー選出に参加できることを示します。これにより、位置情報メッセージが失われたり、特定の履歴上の場所に戻されたりすることがなくなります。

クライアントが位置情報を送信するための API を調べてみると、クライアントの位置情報のカプセル化に使用されるエンティティ クラスが位置情報を検証することがわかりました。コードのスクリーンショットは次のとおりです。

渡された場所が -1 の場合、例外が直接スローされるため、クライアントは -1 の場所をサーバーに送信する機会がありません。なぜその場所が失われているのですか?

さらに調査するには、コンシューマー グループが最初に場所を取得する方法に焦点を当て、ソース コードの観点から分析し、重要なログを見つけ、ログ ファイルを比較して、問題の解決策を見つける必要があります。

2.1 クライアントサイト検索メカニズム

クライアントの位置情報取得の仕組みを探るために、著者は起動時のコンシューマーのプロセスを詳細に読みました。具体的なエントリは、KafkaConsumer のポーリング メソッドです。詳細なフローチャートは次のとおりです。

上記の要点は次のとおりです。

• コンシューマー (KafkaConsumer) がメッセージをポーリングすると、updateAssignmentMetadataIfNeeded メソッドが呼び出されます。このメソッドは主に、コンシューマー グループの初期化、コンシューマー グループの再調整、コンシューマーの場所の取得などのメタデータ関連のタスクを実行します。
• 現在のコンシューマ グループによってサブスクライブされているパーティション (再バランス調整後に割り当てられたパーティション) にすべて場所がある場合は、場所を更新する必要がないことを示す true が返されます。
• 現在割り当てられているパーティションに正しい場所がない場合 (たとえば、再バランス調整後に新しく追加されたパーティションなど)、場所検索要求をサーバーに送信する必要があります。サーバーは __consumer_offsets トピックを照会し、位置情報を返します。
• 場所が見つかった場合は、DEBUG レベルのログ (パーティションのオフセットの設定) が出力され、サーバーから見つかった場所が出力されます。場所が見つからない場合は、DEBUG レベルのログ (パーティションのコミットされたオフセットが見つかりません) も出力されます。
• 場所が見つからない場合は、コンシューマー グループの構成に従って場所戦略をリセットする必要があります。具体的な設定パラメータはauto.offset.resetで、オプションの値は次のとおりです。
  • 最新 最新サイト
  • 最も古いサイト
  • なし 位置をリセットしない
• リセット位置に何も選択されていない場合は、NoOffsetForPartitionException がスローされます。
• リセット位置が最新または最早の場合、コンシューマーはクエリされた位置から消費を開始し、DEBUG レベルのログ (パーティション XX のオフセットをオフセット XXXX にリセットします) を出力します。
• 残念ながら、消費者のサイト検索メカニズムの Kafka クライアントによって出力されるプロセス ログは DEBUG レベルであり、これは基本的に実稼働環境では出力されないため、問題のトラブルシューティング (十分な証拠の発見) に不便が生じます。

ここで、Kafka のログ出力戦略について不満を言わなければなりません。サイトの変更は非常に重大な状態変更であり、これらのログを出力する頻度はそれほど高くありません。ログ レベルでは DEBUG ではなく INFO を使用する必要があります。

Kafka のログはデバッグなので、その時点では追加の説明を提供する証拠はありませんでした。私たちにできることは、ハートビートのタイムアウトによって再バランス調整がトリガーされた理由を突き止めることだけでした。

ヒント: ハートビートがタイムアウトして再バランス調整がトリガーされる理由については、障害分析に関連する後続の記事で詳しく説明します。

リバランストリガーの原因を突き止めた後、テスト環境でストレステストを実施し、再現しました。同時に、証拠を見つけるためにクライアントのログ レベルをデバッグに設定しました。私たちの努力は報われ、上記の 3 つのログを完璧に見つけることができました。

• パーティションのオフセットの設定 場所は最初のクエリ中に見つかり、-1 ではなく、最も古い場所でもありません。
• パーティションのコミットされたオフセットが見つかりません。再バランス調整とログ クエリを繰り返した後、場所を正しくクエリすることができず、場所が見つからない (-1 を返す) という結果が返されました。
• パーティション XX のオフセットをオフセット XXXX にリセットしています。リセット ポリシーに従って位置がリセットされました。

上記のログ分析から、サーバーにコンシューマー グループを格納するための場所があることも明確にわかります。そうでなければ、最初のログは表示されず、有効な場所が正常に見つかることになります。ただし、その後の再バランス処理で、場所を複数回照会する必要がある場合は、代わりに -1 が返されます。どのような状況でサーバーは -1 を返しますか?

ブローカー サーバーがハートビート パケットを処理するためのエントリ ポイントは、kafkaApis の handleOffsetFetchRequest メソッドです。以下に示すように、位置を取得するためのキーコードを見つけます。

上記から、サーバーが INVALID_OFFSET = -1L を返す状況は次のようになります。

• コンシューマ グループ メタデータ マネージャーのキャッシュ (メモリ) にコンシューマ グループが存在しないため、-1 が返されます。どのような状況で、サーバーはコンシューマー グループのメタデータを使用しなくなりますか?
  • __consumer_offsets トピックのパーティションでリーダー選出が発生し、ブローカーが現在所有しているパーティションがフォロワーに変更されると、パーティションに対応するコンシューマー グループのメタデータが削除されます。なぜこのようなことが起こるのでしょうか?その理由は、Kafka のコンシューマー グループが、コンシューマー グループの再バランスを調整するためにブローカー側でグループ コーディネーターを選出する必要があるためです。選出アルゴリズムは、コンシューマー グループ名のハッシュコードを取得し、取得した値を consumer_offsets トピックのパーティション数で割ってパーティション番号を取得し、パーティションのリーダー ノードが配置されているブローカーがコンシューマー グループのグループ コーディネーターになります。したがって、パーティション リーダーが変更された場合は、それに関連付けられているコンシューマー グループのグループ コーディネーターを再選出する必要があります。
  • コンシューマー グループを削除するときは、デバイスを削除します。
• コンシューマー グループの状態は GroupState.Dead です。通常、次の状況では、コンシューマー グループの状態が Dead に変わります。
  • 消費者グループが削除されました
  • __consumer_offsets パーティションのリーダーが変更され、サイトのリロードがトリガーされます。まず、コンシューマ グループの状態を Dead に変更する必要があります。その後、新しいパーティション リーダーが配置されているマシンに新しいサイトがロードされ、コンシューマ グループが再バランス調整されます。

サーバーはコンシューマー グループの位置情報を保存しません。これは、コンシューマー グループがまだ位置情報を送信していないことを示します。

上記のような状況で、長期間運営している消費者団体の場合、上記のような状況が発生するのでしょうか？サーバー上の関連ログを調べると、多数の __consumer_offsets 関連のパーティションでリーダー選出が行われており、上記の最初の状況が簡単に引き起こされる可能性があることがわかります。このように、コンシューマ グループによって開始されたオフセット フェッチ要求は -1 を返す可能性が高く、これにより、コンシューマ グループはリセット戦略に従って位置をリセットするように誘導されます。

記事の冒頭を見ると、消費者グループが設定したリセット戦略が最も早く、消費者グループの消費者バックログが一瞬にして0から数億に急増した理由を説明できます。

これを見ると、突然背筋が凍るような感覚がするのではないでしょうか？コンシューマー グループによって設定された位置リセット戦略 (auto.offset.reset) が最新の場合、メッセージの損失、つまり一部の消費がスキップされて消費されないという問題が起こりやすくなります。概略図は以下のとおりです。

この記事はここで終わります。 Leader 選出のために Kafka クラスターに大量の __consumer_offsets が出現する理由については、今後の記事で順次詳しく説明します。これからも注目して下さい。

3. 感想

正直に言うと、Kafka サーバーが使用するプログラミング言語は Scala なので、著者は Kafka のソースコードを読もうとはせず、Kafka のメッセージ送信とメッセージ消費のメカニズムだけを詳細に分析しました。社内のさまざまなプロジェクトにおける Kafka の利用上の課題は簡単に解決できると思っていましたが、実際はそうではありません。プロジェクトチームの相談にはスムーズに対応できますが、サーバーに問題が発生すると、やはり少し混乱してしまいます。もちろん、クラスターの問題に対する緊急時の対応計画は万全ですが、いったん問題が発生すると、すぐに復旧できても、障害が発生すると損失は避けられません。そのため、私たちは、自分が担当する内容について、しっかりと勉強し、事前に検査を行い、体系的な知識に基づいて、事前に失敗を回避する必要があります。

たとえば、ほとんどの人は、後続のバージョンでの Kafka の消費位置がシステム トピック __consumer_offsets に保存されることを知っているはずですが、このトピックのパーティションでリーダー選出が行われると、多数のコンシューマー グループのバランスが再調整され、コンシューマー グループが消費を停止することを知っている人はどれくらいいるでしょうか。

したがって、著者は、Kafka サーバーの関連ソース コードを注意深く読み、体系的に Kafka を理解し、作業中の Kafka をより適切に制御することを決意します。 「Kafka の原則と実践」コラムが近日公開されます。興味のある友人は、記事の前のラベルをクリックして注目することができます。

最後に、皆さんの「いいね！」をお待ちしております。皆さんの「いいね！」も私の最大のモチベーションです。また次回お会いしましょう。