Docker で Kafka サービスを使用するにはどうすればいいですか?メッセージサービステストの実践

背景とシステム紹介：

Kafka は、Web サイト上の消費者のすべてのアクション ストリーム データを処理できる、高スループットの分散型パブリッシュ/サブスクライブ メッセージング システムです。通常、高スループットが求められるため、解決策としてはログ データの処理とログの集約が行われます。

[[348168]]

この記事で取り上げる分散システム（C システムと呼ぶ）が形になり始めています。システムの構築が進み、機能が徐々に向上するにつれて、Cシステム周辺システムのログ消費需要も徐々に増加しています。ログ消費のニーズを満たすために、システム C のゲートウェイ システムにログ送信機能を追加し、外部へのメッセージ送信を実現することが決定されました。

システム C のゲートウェイ システムは、分散システムのアクセス検証を主に担当し、受け入れられた要求の合法性、セキュリティ、およびその他の内容の必要な検証を実行します。ゲートウェイ システムにメッセージ送信機能を配置する場合、主に次の 2 つの点を考慮する必要があります。

• ゲートウェイ システム ログには、要求の元の情報が記録され、トランザクション要求のシナリオと内容を完全に説明できます。
• 複数のシステム間でメッセージを送信するときに一貫性のない標準を回避するために、統一されたメッセージ形式と仕様を策定すると便利です。一貫性のない標準は、その後のメッセージの消費に問題を引き起こします。

オンラインメッセージ送信テスト

ゲートウェイ システムは、メッセージを送信するかどうかを制御するためにメッセージ制御テーブルを設定します。同時に、すべてのログ データを送信するのではなく、必要に応じてさまざまなディメンションからどのメッセージを送信する必要があるかを制御して、システム リソースの浪費を回避し、メッセージの使用効率を向上させることができます。

1. 通常のトランザクションメッセージの送信

つまり、送信サービスの基本的な機能テストです。トランザクション要求がバックグラウンドで正常に実行されると、ゲートウェイ システムのメッセージ送信機能がトリガーされ、要求に関連するログ情報がメッセージにカプセル化されて送信されます。メッセージ制御データは、読み取り速度を向上させるためにアプリケーション サーバーにキャッシュされ、POSTMAN ツールを通じて照会および検証できます。

メッセージ送信の明示的な表示はないため、ログを照会して、メッセージが正常かどうか、送信ルールがメッセージ制御テーブルの構成ルールに準拠しているかどうか、送信された内容が正確で完全かどうか、トピックが正しく使用されているかどうか、バス システムが正常かどうか、メッセージが正しく受信されているかどうかを確認してテストが完了します。

2. 送信されたトランザクションメッセージを確認する

ゲートウェイシステムでは、トランザクションの実行結果（成功/失敗）を検証するための検証機能が提供されます。ネットワーク上の理由やその他の理由により、チェック済みトランザクションの結果が受信されない場合、トランザクションにメッセージ送信機能が構成されていると、チェック済みトランザクションの元のトランザクション情報がメッセージにカプセル化されて、トランザクションが正常に検証された後に送信されます。これにより、トランザクションのすべての使用シナリオでメッセージを正しく送信できるようになります。

3. 例外メッセージの処理

異常シナリオでは、主に Kafka がメッセージを正常に送信できない状況を検証します。 Kafka サーバーの IP アドレスを変更し、間違ったトピックを設定することで、Kafka メッセージ送信の失敗のシナリオをシミュレートし、ゲートウェイ システムが異常メッセージ テーブルにメッセージを正しく完全に記録できるかどうかを検証します。

4. サーキットブレーカーシナリオテスト

サーキットブレーカーは、Kafka に異常があるか、メッセージ サービスに過度の負荷がかかっていることを意味します。その結果、ゲートウェイ システムの他の正常な機能に影響が及びます。ゲートウェイ システム自体が通常の外部サービスを提供できるようにするには、メッセージ サービスを一時的にシャットダウンする必要があります。送信するメッセージを異常メッセージ テーブルに記録し、メッセージを一括して再送信することで、メッセージ サービスが終了します。

バッチメッセージ処理テスト

定期的なポーリングにより、異常メッセージテーブルに記録されたメッセージが再送信されます。同時に、メッセージヒューズメカニズムが設定されます。 Kafka に異常が発生した場合、メッセージ送信はメッセージ記録テーブルに完全に切り替えられ、Kafka の完全な障害を回避しながら、このシステムの正常な外部サービスを確保します。

メッセージ再送信機能

当日の再送信メッセージは定期的にポーリングされ、異常メッセージ テーブルは 5 分ごとにスキャンされます。正常に送信されなかったメッセージは再送信されます。送信試行が 3 回失敗すると、メッセージのステータスが「異常」に更新されます。テストの主な検証内容は次のとおりです。

• 再送信メッセージのスクリーニング。
• 間違ったメッセージ（空のメッセージなど）の処理。
• 再発行スレッド競合処理メカニズムなど

前日メッセージ再送機能は、前日に送信されなかった異常メッセージを再送信します。当日再送信機能に似ていますが、スケジュールされたポーリング機能ではありません。

例外メッセージのエクスポート

再送信後もメッセージが失敗する場合は、データの整合性を確保するために後続の処理用のエクスポート機能が提供されます。

パフォーマンステスト

生産後に予想されるメッセージ送信量は非常に大きく、1億以上と推定されるため、パフォーマンス要件は比較的高くなります。

推定トランザクション量を参考に、80/20ルール（トランザクション量の80%が20%の時間で発生する）に従うと、生産後のシステムのTPSは約7,000になると予測されます。システムの以前のパフォーマンステスト指標を参考に、標準ポジショニング2000を使用し、テストと生産のTPS比は1：3.5です。テスト環境リソースと本番環境リソースの比率は約 1:16 であり、TPS のテスト対本番環境比率よりもはるかに大きくなります。したがって、この基準に到達すれば、生産システムのパフォーマンス要件を満たすことができると考えています。

ベンチマーク テスト、負荷テスト、混合シナリオ テストを実施した結果、メッセージ サービスはテスト環境で 2,000 を超える TPS を達成し、システム リソースは適切な範囲内でした。

要約する

Kafka は、ゲートウェイ システムのメッセージング サービスの基盤を提供する、比較的成熟したメッセージング システムです。ただし、Kafka では時折疑似死現象が発生し、メッセージがブロックされることがあります。当初は仮死状態という現象をシミュレートしようと計画していましたが、プロジェクト開発者や Kafka サポートスタッフと話し合った結果、当面はこのシナリオをシミュレートすることはできないことがわかり、これも今回残った残念な点です。