Kafka システムの信頼性を検証するにはどうすればよいですか?今やっと理解できた

Kafka で構築されたシステムが特定の信頼性を提供する必要がある場合、それに応じて Kafka を構成し、プロデューサー アプリケーションとコンシューマー アプリケーションで必要な処理を行った後、システム全体が期待される信頼性を達成したことをどのように確認すればよいでしょうか。この記事ではこれについて紹介します。

[[284091]]

要点:

• 概要
• 構成を確認する
• アプリケーションを確認する
• オンライン監視

1. 概要

先ほども申し上げたように、信頼性というのは簡単に得られるものではありませんし、検証方法も簡単ではありません。それは3つの段階に分かれています:

• プロデューサーとコンシューマーを介さずに Kafka 構成を検証し、Kafka が期待どおりに動作していることを確認します。
• プロデューサーとコンシューマーのアプリケーションを追加して、プロデューサーとコンシューマーのパフォーマンスが期待どおりであることを確認します。
• アプリケーションの起動後、アプリケーションと Kafka のインジケーター、ログなどを監視し、信頼性に関連する問題を特定して修正します。

2. 構成の確認

検証：実際には、実際の効果が期待された効果と一致しているかどうかを確認するテストです。したがって、検証の前に期待される結果を確認する必要があります。このステップでエラーが発生すると、検証が成功しなくなる可能性があります。

設定の検証は、設定ファイルが正しいかどうかを肉眼で確認することではなく、Kafka が提供するツールを使用することです。 Kafka には、org.apacha.kafka.tools パッケージの下に VerifiableProducer と VerifiableConsumer という 2 つのクラスがあります。これら 2 つのクラスはコマンド ラインから実行でき、さまざまなテスト フレームワークでも使用できます。

VerifiableProducer は、指定したパラメータに応じて一定数のメッセージを送信できます。メッセージの内容は 1 から増加する数値です。パラメータには、ack、再試行回数、送信速度などが含まれます。実行時に、各メッセージが正常に送信されたか、失敗したかが出力されます。 VerifiableConsumer は、VerifiableProducer によって生成されたメッセージを消費し、消費された順序でメッセージの内容を出力し、オフセットのコミットとパーティションの再割り当てに関するメッセージを出力します。

これら 2 つのコマンドライン ツールのパラメータを見てみましょう。

初めて使用するので、いくつかのパラメータをランダムに選択して設定します。

VerifiableProducer を使用してデータを送信します。

次に、VerifiableConsumer を使用して領収書を受け取ります。

max-messages が 10 に設定されており、トピックには 5 つのメッセージしかないため、終了しません。

上記は単なるデモンストレーションです。ブローカーは 1 つだけであり、非常に安定しています。実際のテストでは、より複雑なシナリオを構築する必要があります。

• リーダー選出: リーダーがいるブローカーをシャットダウンした後、プロデューサーとコンシューマーが回復するまでにどのくらいの時間がかかりますか?
• コントローラの選択、コントローラの再起動、システム全体の回復にはどのくらいの時間がかかりますか?
• ローリング再起動、つまりブローカーを 1 つずつ再起動することで、メッセージが失われないことを保証できますか?
• 汚いリーダー選挙。ダーティーリーダー選挙が行われると、生産者と消費者に何が起こるのでしょうか?彼らはその結果を受け入れることができるでしょうか?

実際のニーズに応じてテスト シナリオを構築し、すべてのテストに合格したら次のステップに進みます。

3. アプリケーションを確認する

実際、このステップの検証方法は前のステップと非常に似ています。唯一の違いは、プロデューサーとコンシューマーが自分で開発したアプリケーション コードに置き換えられ、Kafka 構成は変更されず、アプリケーション内のプロダクションとコンシューマーが起動され、構築されたシナリオでテストが実行されることです。次に例を示します。

• プロデューサーとコンシューマーはKafkaクラスターから切断されています
• リーダー選挙が行われる
• ブローカーのローリング再起動
• 消費者はローリング再起動を実行する
• プロデューサーのローリング再起動

テスト結果が期待どおりでない場合は、原因を突き止めて修正します。すべての検証に合格したら、次のステップに進みます。

4. オンライン監視

このステップは非常に重要です。最初の 2 つのステップで漏れがあったり、時間内に実行されなかったりした場合でも、監視によって問題が時間内に発見され、損失を回避できるためです。

監視コンテンツには、JMX、ログ、その他のより複雑なカスタム インジケーターが含まれる場合があります。

JMX モニタリング

Kafka には JMX モニタリングが付属しており、ブローカー、プロデューサー、コンシューマーを監視するためのさまざまなインジケーターがあります。

ブローカーにとって、ISR コピーの最小数に達していないパーティションの数、同期されているパーティション コピーの数、オフライン パーティションの数、コントローラーの数、失敗したプロダクション要求の数、リーダー選出の数と時間など、監視する価値のある指標は多数あり、これらはすべて非常に重要です。

プロデューサーにとって、信頼性に関連する 2 つのメトリックは、メッセージあたりの平均エラー率と平均再試行率です。これら 2 つのメトリックが増加すると、システムに何らかの問題があることを意味します。

コンシューマーにとって最も重要な指標は消費ラグです。これは、コンシューマーの現在の消費位置がトピックの各パーティションの最新メッセージからどれだけ遅れているかを示します。理想的には、0 と非常に小さい値の間で変動します。一定のしきい値まで増加した場合は、処理する必要があります。

ログ監視

Kafka のログ監視は、他のアプリケーション ログ監視とそれほど変わりません。ログに表示される WARN と ERROR に注意してください。異常があると信頼性に影響する可能性があります。

その他の監視

JMX 監視とログ監視に満足できない場合は、自分で他の監視を拡張または追加することができます。 JMX によって報告されるインジケーターは拡張でき、ログの内容も増やすことができますが、ソース コードを変更する必要がある場合があります。

監視システム

一般的に、Kafka の監視タスクは、専用の監視および運用保守障害管理システムによって完了する必要があります。私は Kafka を監視するために、Xiaomi の Open-Falcon と InfluxData の Telegraf + InfluxDB + Grafana スイートの 2 つのシステムを使用しました。全員大丈夫です。監視したい内容を柔軟にカスタマイズでき、複数のアラーム方法をサポートしています。たとえば、Open-Falcon は電子メールと WeChat アラームをサポートしており、Grafana のページの外観は非常に優れています。他にもたくさんあるはずですが、私は使ったことがないので、無駄なことは言いません。