Apache Kafkaエコシステムの包括的な手動テスト方法論は、スキーマライフサイクル管理、クラスターのストレス下でのコンシューマ挙動、および障害モードの処理を体系的に探査する必要があります。テスターは、Confluent Schema Registryの互換性ルールを検証するために、意図的にスキーマ変異を導入しながら、生産品質のメッセージボリュームをシミュレートするシナリオを設計する必要があります。これにより、データ契約が分散チーム間で一貫して保たれ、既存のコンシューマが壊れることはありません。
このアプローチでは、制御されたコンシューマグループメンバーシップの変更を作成して再バランスをトリガーし、オフセットコミットおよびメッセージ順序保証を確認します。さらに、故障したAvroペイロードの手動インジェクションにより、エラーハンドリングメカニズムがメインコンシューマパイプラインを停止することなく毒薬メッセージをデッドレタートピックに正しくルーティングすることを検証します。これらの活動は、ネットワークパーティション中のコントローラ選出の安定性を確認するために、ZooKeeperまたはKRaftメタデータと直接対話する必要があります。
金融サービス会社で、私たちのチームはIBM MQからKafka 3.5への支払い処理の移行中に重要なデータ損失リスクに直面しました。システムはトランザクションイベントのためにAvroスキーマとConfluent Schema Registryを利用しており、スキーマの変更がコンシューマアプリケーションをクラッシュさせ、再バランスイベントが重複した支払いレコードを生成することを発見しました。移行の締め切りは厳しく、自動化テストスイートの開発の余地はありませんでした。
最初のアプローチは、組み込みKafkaブローカーを持つ既存の自動統合テストにのみ依存することを提案しました。これにより迅速なフィードバックループと簡単なCI/CD統合が可能でしたが、実際のネットワーク遅延の影響および、数日間のソークテスト中にのみ現れる並行スキーマ進化シナリオを捉えることはできませんでした。
2番目のアプローチは、事前定義されたチャーターなしの純粋な探索テストを提案しました。これにより、予期しない挙動を発見するための最大の柔軟性が提供されましたが、ブローカーの再起動中のプロデューサの冪等性の失敗などの重要な障害モードの不均一なカバレッジのリスクがあり、正確に一度だけのセマンティクスにおけるエッジケースを見逃す可能性がありました。
私たちは、構造化されたテストチャーターとカオス工学の原則を組み合わせたハイブリッドな方法論を選択しました。このアプローチにより、スキーマ互換性マトリックスの体系的なカバレッジが提供され、想起された挙動の適応的な探査が可能になりました。メッセージのピーク摂取中にブローカーノードのローリング再起動を手動でトリガーし、コンシューマのラグと再バランスパターンを観察しながら、後方互換性のある変更と互換性のない変更を通じてスキーマを進化させてレジストリの強制を検証しました。
結果として、重複処理のインシデントが排除され、プロダクションに破壊的な変更が到達するのを防ぐスキーマガバナンスプロセスが確立されました。コンシューマグループは、シミュレートされたノード障害中に安定したスループットを維持し、デッドレターキューは破損したトランザクションメッセージをメイン処理ストリームに影響を与えることなく正常に隔離しました。
ブローカーが書き込みを承認しているが、ネットワークタイムアウトが原因でクライアント側の再試行が発生する場合に、Kafkaプロデューサの再試行が正確に一度だけのセマンティクスを違反しないことを手動でどのように検証しますか？
候補者は、メッセージメタデータ内のProducer ID（PID）およびシーケンス番号を検査する重要性を見落としがちです。手動テスト中には、プロデューサーとコンシューマーでDEBUGログを有効にし、次に、ネットワーク遅延をシミュレートするためにToxiproxyまたはiptablesルールを使用して意図的に導入します。Kafkaブローカーの重複排除ロジックが、コンシューマレコードのLogAppendTimeおよびOffset値をチェックして重複したシーケンス番号を拒否することを確認してください。
重要な洞察は、手動テスターがkafka-console-consumerを使用して__consumer_offsetsトピックを直接検査する必要があることです。このとき、formatterフラグを設定してコーディネータメタデータを表示し、トランザクショナルマーカー（CommitおよびAbort）がログセグメントに正しく表示されることを確認します。
異種処理遅延を持つコンシューマグループでStickyAssignor対RangeAssignorを使用する際に、パーティション割り当ての偏りをどのように特定する手動技術は何ですか？
多くのテスターは、パーティション分配が再バランス中の正確に一度だけの保証に直接影響を与えることを認識していません。これを手動で検証するには、**Thread.sleep()**の変種を使用して人工的な処理遅延を持つコンシューマインスタンスを作成し、kafka-consumer-groups.shを介してコンシューマグループの説明を監視し、コンシューマを追加および削除して再バランスをトリガーします。
Current-OFFSET、Log-END-OFFSET、およびLAG列を観察して、StickyAssignorが意図したとおりにマイナーなメンバーシップ変更中にパーティションの所有権を維持しているかどうかを検出します。パーティション間のラグの標準偏差を手動で計算する必要があります。顕著なばらつきは、フェイルオーバーシナリオ中の処理順序保証に違反する可能性のある割り当ての偏りを示します。
自動互換性チェックにのみ依存せずにSchema Registryの互換性モード（BACKWARD、FORWARD、FULL）を検証するにはどうしますか？
初心者はしばしばレジストリレベルの互換性の強制と実行時デシリアライズ挙動の違いを見落とします。特定の互換性設定でスキーマバージョンを登録し、次に古いスキーマバージョンを使用してメッセージを生成し、新しいクライアントライブラリを使用して消費することで手動テストを行います（その逆も同様です）。
Schema Registry REST APIに対してcurlコマンドを使用してスキーマを登録し、互換性エンドポイントが期待されたtrueまたはfalseを返すことを確認します。その後、明示的なスキーマバージョンを持つkafka-avro-console-producerを使用して、プロデューサがコンシューマより遅れる生産シナリオをシミュレートします。重要な検証は、期待されたスキーマに違反するメッセージを受信したときにSerializationExceptionがコンシューマアプリケーションで適切に処理され、SpecificRecord実装がフィールドを静かにドロップしたり、ビジネスロジックを破損するnullデフォルトで埋め込んだりしないことを確認することです。