テスト¶

単体テスト、統合テスト、スキーマの互換性テストはいずれも、CI/CD パイプラインで回復性のあるアプリケーションを構築するうえで重要なステップです。Kafka コミュニティでは、クライアントアプリケーションのテストに役立つさまざまなリソースが開発されています。

単体テスト¶

単体テストは、短時間で実行でき、独立した機能ブロックのコードが想定どおりに機能することを検証するものです。他のサービスに対する依存関係は最小限で、アプリケーションのロジックをテストすることができます。

ksqlDB では、ksql-test-runner というテスト実行用のコマンドラインツールが公開されています。このツールでは、必要な項目を指定して、ksqlDB ステートメントが正常に動作するかどうかを自動的にテストできます。短時間で実行でき、Kafka や ksqlDB クラスターを実行している必要はありません。Kafka チュートリアルにサンプルがあります。このツールは変更される可能性があり、後方互換性は保証されないことに注意してください。

Kafka Streams アプリケーションで、TopologyTestDriver を使用します。これは Kafka Streams のロジックをテストするテストクラスです。起動時間が非常に短く、Kafka Streams トポロジーで一度に 1 つのメッセージのテストを実行でき、デバッグやステップ実行が容易に行えます。Kafka チュートリアルのサンプルを参照してください。Kafka Streams プロセッサーを独自に開発した場合、単体テストを行う必要があります。Processor は結果を返すのではなく、コンテキストに転送するため、単体テストでは、転送されたデータを検査用にキャプチャできる疑似的なコンテキストが必要になります。そのためには、MockProcessorContext を使用します。Kafka Streams テストにサンプルがあります。

基本的なプロデューサーとコンシューマーについては、単体テストで使用できる模擬インターフェイスがあります。JVM のプロデューサーおよびコンシューマーの単体テストでは、MockProducer および MockConsumer を使用できます。それぞれ KafkaProducer および KafkaConsumer で実装されているものと同じインターフェイスが実装され、同じ I/O 処理がすべて疑似的に再現されています。「Build your first Apache KafkaProducer application」の MockProducer の例と、「Build your first Apache KafkaConsumer application」の MockConsumer の例を参照してください。JVM でない librdkafka のプロデューサーおよびコンシューマーの場合は、言語によって異なります。rdkafka_mock を使用することもできます。これは、他の依存関係を持たない、Kafka プロトコルブローカー API の最小限の実装です。librdkafka の例を参照してください。

統合テスト¶

統合テストでは、他のサービスとのエンドツーエンドのテストを行います。Testcontainers という、JUnit テスト、データベース、ブラウザーなど、Docker コンテナー内のあらゆるものに対応した Java ライブラリを使用できます。Testcontainer により、Kafka ブローカーは専用のクラスパスを持つ専用の JVM を取得でき、ブローカーのメモリーと CPU がテスト自体から分離されます。また、Docker 用にいくつかのプロセッサーを割り当てることでパフォーマンスの調整ができます。詳細については、以下を参照してください。

もう 1 つの方法として、非同期のマルチスレッドクラスターを提供する EmbeddedKafkaCluster を使用することもできます。Testcontainers と異なり、テストと同じ JVM 内に追加のスレッドおよびオブジェクトが割り当てられます。これは、kafka-streams-test-utils で提供されているインターフェイスですが、パブリックインターフェイスではなく、後方互換性も保証されていません。

EmbeddedKafkaCluster: Apache Kafka テストのサンプル
EmbeddedSingleNodeKafkaCluster: EmbeddedKafkaCluster に似ていますが、EmbeddedSingleNodeKafkaCluster にはスキーマレジストリが含まれている点が異なります。Kafka Streams テストのサンプルを参照してください。

JVM でない librdkafka クライアントの場合には、以下のものを使用できます。

rdkafka_mock。単体テストに記載されているとおりです。
Trivup。シンプルな Kafka クラスターを用意するための、軽量で、コミュニティによってサポートされているフレームワークです。

スキーマの管理と進化¶

プロデューサーとコンシューマーのスキーマが進化しても、Kafka プロデューサーは、Kafka コンシューマーが読み取ることのできるスキーマを使用してデータを書き込むという暗黙の契約があります。Kafka アプリケーションは、これらのスキーマに依存し、スキーマに加えられるすべての変更で互換性が維持され、実行が可能であることを前提とします。そこで役立つのが、スキーマの一元管理と、スキーマの進化に伴う互換性チェックの機能を提供する Confluent Schema Registry です。

アプリケーションでスキーマレジストリを使用している場合、単体テストでスキーマレジストリインスタンスをシミュレーションできます。Confluent Schema Registry の MockSchemaRegistryClient を使用して、データのシリアル化と逆シリアル化を行うためのスキーマの登録と取得を行います。Kafka チュートリアルの MockSchemaRegistryClient の例を参照してください。

Kafka Streams API とスキーマレジストリを使用してサンプルのストリーミングアプリケーションとテストの構築を開始したら、統合テストには、統合テストに記載されているいずれかのツールを使用します。

アプリケーションが本稼働環境で実行されるようになった後で、スキーマが進化する場合がありますが、古いバージョンと新しいバージョンのどちらのスキーマを使用していても、すべてのアプリケーションで互換性を確保する必要があります。Confluent Schema Registry ではスキーマの進化が考慮されており、互換性チェックの機能が用意されています。これにより、プロデューサーとコンシューマーの間の契約違反を防止できます。そのため、プロデューサーとコンシューマーが別々にアップデートされ、それぞれのスキーマが個別に進化しても、プロデューサーとコンシューマーは新旧のデータを確実に読み取ることができます。Confluent では Schema Registry Maven プラグインを提供しています。このプラグインでは、以前登録されたスキーマに対する新しいスキーマの互換性を確認できます。Java サンプルクライアントの pom.xml でこのプラグインのサンプルを確認できます。

パフォーマンステスト¶

わずか数秒で Kafka クライアントアプリケーションを起動し、実行することができますが、本稼働環境に移行する前に、アプリケーションのパフォーマンスを調整する必要があります。ユースケースが異なれば、サービス目標を決定付ける一連の要件も異なるので、自分のサービス目標が何であるかを以下から決定する必要があります。

スループット
レイテンシ
永続性
可用性

サービス目標を決定したら、アプリケーションのパフォーマンステストを実施します。ベンチマークテストを実行して、現在の動作を確認してから、調整を行います。詳細については、「最適化およびチューニング」を参照してください。

ちなみに

最新のハードウェアで実施された、クラウドにおける Kafka のパフォーマンスベンチマークテストとその結果については、「Apache Kafka Performance, Latency, Throughput, and Test」を参照してください。

カオステスト¶

カオステストでは、アプリケーションの回復性を向上させるため、積極的に障害のテストを行います。他の種類のテストでは発見できないようなアプリケーションの問題を明らかにするのに役立ちます。ランダムに障害を発生させるか、リソースが制限された状態をシミュレーションして、アプリケーションやシステムの動作を確認します。

カオステスト用のツールには、たとえば次のようなものがあります。

Trogdor
Toxiproxy などの Testcontainers モジュール
Docker 環境用の Pumba

Confluent Cloud でのテスト¶

アプリケーションが起動して、Confluent Cloud で稼働するようになったら、アーキテクチャの各機能部分がすべて正常に動作していることを検証し、エンドツーエンドからのデータフローを確認します。Confluent Cloud に関するその他の考慮事項は、次のとおりです。

ネットワークのスループットとレイテンシ
開発環境、テスト環境、本稼働環境の分離
クラウド固有のセキュリティ認証と認可

データセット¶

より複雑なシナリオに対応する場合や、クライアントアプリケーションをテストする場合、チーム内向けに見栄えのいい Kafka のデモを作成する場合などには、もう少し現実的なデータセットを使用する必要が出てきます。

実際の本稼働環境のデータセット¶

1 つの方法は、実際の本稼働環境のデータセットを使用してテストする方法です。可能であれば、実際の本稼働環境のデータ（Kafka トピックのコピーなど）をテスト環境に取り込みます。次のツールを使用すると、Kafka のネイティブ API を使用して、本稼働環境からテスト環境にデータをコピーできます。

Confluent Replicator
MirrorMaker
Cluster Linking: クラスター同士を直接接続して、一方のクラスターから他方のクラスターにトピックをミラーリングできます。Connect は必要ありません。

または、プレビルドされた、フルマネージド型の Apache Kafka® コネクターを使用して、ソースシステムから直接データを取得します。

模擬データ¶

実際のデータソースや実際のクラスターと連携できる状態でない場合でも、トピック用に面白いテストデータを生成することができます。最も簡単な方法は、複雑なレコードや複数のフィールドを持つスキーマ定義を事前定義してデータジェネレーターを使用する方法です。Kafka Connect Datagen を使用すると、Avro、JSON_SR、JSON、または Protobuf のいずれかのフォーマットをデータに適用できます。