質問への回答

質問の歴史

モノリシックアーキテクチャでは、APIテストは単一のエンドポイントに対して簡素なリクエストレスポンス検証に依存しており、セッションは中央集権的なセッションストアに保持されていました。マイクロサービスへの移行により、複数のサービスを通じたビジネスオペレーションの分散トランザクションの複雑さが生じ、テスターはネットワークの境界を越えた状態を追跡し、オートスケーリングやブルーグリーンデプロイメントなどのインフラの変動に対応する必要があります。

問題

従来のAPI自動化は、各サービス呼び出しを独立したトランザクションとして扱い、部分的な障害がサービス境界を越えて補償アクションを引き起こす必要があるサガや分散トランザクションを検証できません。また、ハードコードされたサービスエンドポイントは動的スケーリングに対してテストを脆弱にし、制御された故障注入がないため、サーキットブレーカーの設定や再試行ポリシーは本番中のインシデントが発生するまで検証されず、壊滅的なカスケード障害を引き起こします。

解決策

静的構成を使用するのではなく、ランタイムで動的エンドポイントを解決するために、ConsulやEurekaなどのサービスディスカバリーレジストリを活用する振る舞い意識のテストハーネスを実装します。このアーキテクチャは、イベントソーシングリスナーを通じてサガパターンの検証を実装し、サービスコール全体で相関IDを追跡することで、部分的な障害時に補償トランザクションが正しく実行されることを確保します。さらに、Istioなどのサービスメッシュ制御プレーンと統合し、レイテンシやエラー応答を注入できるようにし、アプリケーションコードを変更することなく、専用のテスト環境を必要とせずにサーキットブレーカーの検証を可能にします。

public class DistributedSagaTest {
    private DynamicServiceMesh mesh;
    private SagaEventValidator validator;
    private FaultInjector faultInjector;
    
    @BeforeMethod
    public void setup() {
        mesh = new DynamicServiceMesh(ServiceRegistry.consul());
        validator = new SagaEventValidator(KafkaConfig.testConsumer());
        faultInjector = new IstioFaultInjector(mesh);
    }
    
    @Test
    public void testOrderSagaWithCircuitBreaker() {
        String sagaId = UUID.randomUUID().toString();
        OrderRequest order = new OrderRequest("SKU-123", 2);
        
        // フェーズ1: 在庫を予約
        Response reserve = mesh.post(Service.INVENTORY, "/reserve", order, sagaId);
        assertEquals(reserve.getStatus(), 201);
        
        // サーキットブレーカをトリガーするために支払いサービスのレイテンシを注入
        faultInjector.addLatency(Service.PAYMENT, 5000, 0.5);
        
        // フェーズ2: レジリエンス検証付きで支払いを処理
        PaymentResult result = validator.executeWithValidation(sagaId, () -> {
            return mesh.post(Service.PAYMENT, "/charge", order, sagaId);
        });
        
        if (result.isCircuitBreakerOpen()) {
            // 補償トランザクションが在庫を解放することを検証
            validator.awaitCompensatingEvent(sagaId, "INVENTORY_RELEASED", Duration.ofSeconds(5));
            InventoryStatus status = mesh.get(Service.INVENTORY, "/status/" + order.getSku(), sagaId);
            assertEquals(status.getReservedQuantity(), 0);
        }
    }
}

実生活の状況

ある金融技術会社は、モノリシックな支払い処理システムから、取引検証、防止検出、元帳管理、通知ディスパッチを含む12の相互依存サービスからなるマイクロサービスアーキテクチャに移行しました。自動化チームは、プロパティファイルに保存された静的に設定されたエンドポイントを使用してこれらのサービスをテストしようとしましたが、サービスのIPアドレスやポートが予測不可能に変更されるため、最初の週にテスト実行の40％が失敗しました。

チームは、この不安定性を解決するために3つの異なるアーキテクチャアプローチを検討しました。最初のオプションは、すべてのサービスがテストラン中に接続する中央集権的なテストデータベースを実装し、共有状態を通じてデータの整合性を確保することでした。これにより分散トランザクションの複雑さは解消されましたが、サービス間に危険なカップリングが導入され、本番に類似した構成でテストするという原則を侵害し、各サービスが独自のデータストアを保持することができ、シリアル化エラーや接続プールの問題を隠す可能性があります。第二のアプローチは、WireMockのようなツールを使用してすべての依存サービスを包括的にモックすることを提案し、安定性と迅速な実行を提供しましたが、実際のサービス相互作用でのみ現れるネットワークタイムアウト、サーキットブレーカーの設定ミス、イベントブローカーのレイテンシに関連する統合失敗を検出できませんでした。

採用された解決策は、Istioを使用してサービスメッシュサイドカーパターンを実装し、プラットフォームのDNSレジストリを介して動的サービスディスカバリを促進し、相関ヘッダーを注入して分散トランザクションを追跡するカスタムサガテストオーケストレーターを組み合わせました。このアーキテクチャにより、テストはハードコードされたIPではなくメッシュディスカバリを介してエンドポイントを解決できるようになり、Istioの故障注入機能によりアプリケーションコードを変更することなく再試行ポリシーとサーキットブレーカーの検証が可能になります。サガオーケストレーターは、補償トランザクションイベントのためにKafkaトピックをリッスンするイベントジャーナルを維持し、部分的な障害が分散元帳を越えてロールバックシーケンスを正しくトリガーすることを検証できるようにしました。

実装後、このフレームワークは、継続的に再デプロイされる環境において、500回のエンドツーエンドのトランザクションフローを毎日成功裏に実行し、以前の単体および契約テストで見逃されていた補償トランザクションロジックの3つの重大なレースコンディションを特定しました。動的発見メカニズムは、環境に関連するテストの失敗を完全に排除し、混乱工学の統合は、次の高トラフィックイベント中に本番環境でカスケード障害を引き起こす可能性のあるサーキットブレーカーの閾値に関する設定ミスを捕捉し、推定12時間のダウンタイムを節約しました。

候補者が見落としがちなこと

不安定なテストを導入することなく、分散システムにおける最終的な整合性をどのように検証しますか？

多くの候補者は、Thread.sleep()や最大可能レイテンシに固定された暗黙的な待機を提案しますが、これは実行を著しく遅くし、変動する負荷条件下では信頼性がありません。正しいアプローチは、ビジネスイベントの完了に基づいた決定論的退出基準を持つ指数バックオフを伴う適応ポーリングを実装し、Awaitilityのようなライブラリを使用してデータベースやメッセージブローカーでサガの完了マーカーを確認するカスタム条件述語を使用します。これにより、テストはタイミングを推測するのではなく、実際の整合性の境界を検証し、サービスレベル目標で定義された許容可能なビジネス閾値を超えた場合に迅速に失敗します。

マイクロサービスにおける消費者駆動の契約テストとエンドツーエンドの統合テストの根本的なアーキテクチャの違いは何ですか？また、一方を他方に置き換えることによって失敗に至る理由は何ですか？

候補者はしばしばこれらのアプローチを混同し、契約テストのみがシステムの機能性を保証するか、エンドツーエンドテストがすべてのシナリオに対して十分なインターフェース検証を提供すると主張します。消費者駆動の契約テストは、Pactのようなツールを使用して特定のサービスペア間のスキーマ互換性とリクエストレスポンス契約を検証し、プロバイダーの変更が個々の消費者を破らないことを保証しますが、複数のサービスを越えた分散トランザクションの出現する挙動を検証することはできません。逆に、エンドツーエンドテストはこれらの複雑な相互作用パターンと障害モードの伝播を検証しますが、フィードバックが遅く、すべてのサービスバージョンのすべての組み合わせをテストできないため、正しいアーキテクチャはインターフェースの変更に対して契約テストを主な迅速なフィードバックメカニズムとして使用し、分散トランザクションの境界をターゲットとする選択的なエンドツーエンドシナリオで補完します。

複数のデータベースとメッセージブローカーを跨ぐ分散トランザクションを検証する際、テストデータの隔離をどのように処理しますか？

ほとんどの候補者は、クリーンアップスクリプトを持つ共有テストデータベースや単純なUUIDのランダム化を提案しますが、マイクロサービスは別々のデータストアを維持し、単一のビジネストランザクションがPostgreSQL、MongoDB、Kafkaトピックを同時に作成することを考慮していません。適切な隔離は、直接データベースの切断を避けるために、サガ補償メカニズムを通じてスターワイプパターンを実装することを要求し、テストが本番環境で整合性を維持するために使用される同じクリーンアップワークフローを呼び出すことを確保します。さらに、テスト開始時に注入された分散トレースヘッダーを使用して、すべての作成データにタグ付けを行い、サービス間で外部キー制約を尊重しながら正確なクリーンアップクエリを可能にする必要があります。