質問への回答。

質問の歴史

リトライロジックは、マイクロサービスアーキテクチャがモノリスに取って代わった際の基本的な弾力性パターンとして現れました。これにより、システムは一時的なネットワーク障害や時間的な利用不可にさらされました。初期の実装では、サーバーを圧倒するカタストロフィックな「雷鳴の群れ」を生じるような単純な即時リトライが使われました。業界は、クライアントのリトライストームを非同期させるために、冪等性キーがリトライチェーン全体で持続することを検証し、回路ブレーカーステートマシン（クローズ、オープン、ハーフオープン）を検証することが重要な盲点であることを認識しました。従来の同期テストアサーションでは、変動レイテンシウィンドウや分散ステート検証を扱うことができません。

問題

コアの課題は、クライアントの意図とサーバーの認識の間の観測可能性のギャップにあります。クライアントが失敗した支払いリクエストをリトライする際、自動化フレームワークは4つの同時懸念を確認する必要があります： (1) クライアントは適切な変動のある期間（ジッター）を待ってから試行し、サーバーを叩きつけないこと； (2) サーバーは重複する冪等性キーを認識し、再処理することなく元の応答を返すこと； (3) 回路ブレーカーは失敗のしきい値を超えた後にオープンへと遷移し、リソース消費を避けるために迅速に失敗すること； (4) ハーフオープン状態の間、正確に1つのプローブリクエストがバックエンドに到達し、後続のリクエストは即座に拒否されること。標準のモッキングツールは、現実的なTCPレベルの動作（パケット損失、接続リセット、可変レイテンシ）をシミュレートできず、これらのイベントをアプリケーション層のメトリクスと関連付けることができないために失敗します。

解決策

テストオーケストレーターによって直接制御されるプログラム可能なプロキシアーキテクチャをToxiproxyまたはEnvoyのサイドカーを使用して実装します。これにより、テストクライアントとテスト対象（SUT）間に「混乱レイヤー」が作成されます。

弾力性プロキシ制御: サイドカーとしてToxiproxyをデプロイします。テストスイートは、特定のタイムスタンプでlatency,timeout、またはreset_peerのような「トキシック」（障害モード）を動的に追加/削除するために、Toxiproxy HTTP APIを使用します。
テレメトリの相関: SUTをOpenTelemetryまたはMicrometerで計装し、リトライ試行に対してスパン/メトリックを発行します。テストフレームワークは、トレースIDを使用してプロキシのトキシティイベントとアプリケーションスパンを相関させ、リトライが有毒なアクティブウィンドウ内でのみ発生したことを主張します。
冪等性の検証: 最初のリクエストの前にUUIDv4の冪等性キーを生成します。それをスレッドローカルコンテキストに保存します。プロキシを介してリクエストを発行し、最初の2回の試行が失敗するように設定します。最終的に成功した応答にヘッダーX-Idempotency-Replay: trueが含まれていることを確認します（または、データベースクエリを介してそのキーに対して1つの元帳エントリしか存在しないことを確認します）。
ステートマシンの検証: プロキシが回路ブレーカーのしきい値（例えば、10秒間に5回の失敗）に達するまで503エラーを返すように強制します。回路ブレーカーのヘルスエンドポイント（またはメトリクスを調べることにより）を介して、オープンに遷移したことを主張します。次にトキシックを削除し、ハーフオープンタイムアウトを待ち、正確に1つのプローブリクエストがバックエンドに到達し、並行リクエストが即座に503 Service Unavailableを受信することを確認します。

コード例

import requests
import toxiproxy
import time
import statistics
from assertpy import assert_that

class ResilienceTest:
    def test_retry_jitter_and_circuit_breaker(self, proxy_client):
        # セットアップ: プロキシを設定し500msのレイテンシを注入、その後タイムアウト
        proxy = proxy_client.get_proxy("payment_service")
        
        # フェーズ 1: リトライを伴う冪等性
        idem_key = "idem-12345"
        proxy.add_toxic("slow", "latency", attributes={"latency": 500})
        
        start = time.time()
        r = requests.post(
            "http://localhost:8474/proxy/payment_service",
            headers={"Idempotency-Key": idem_key},
            json={"amount": 100},
            timeout=10
        )
        duration = time.time() - start
        
        # 基本0.5s、指数バックオフ2^試行 + ジッター
        # 試行1: 0.5s（失敗）、試行2: 1.0s + ジッター（失敗）、試行3: 2.0s（成功）
        assert_that(duration).is_between(3.0, 4.5)  # ジッターによりばらつきが許容される
        
        # フェーズ 2: 回路ブレーカーのしきい値
        proxy.add_toxic("error", "timeout", attributes={"timeout": 0})
        
        failure_times = []
        for i in range(7):  # 5のしきい値を超える
            try:
                requests.get("http://localhost:8474/proxy/payment_service/health", timeout=1)
            except:
                failure_times.append(time.time())
        
        # 回路がオープンの後にファストフェイル（リトライ遅延なし）を確認
        if len(failure_times) >= 2:
            gap = failure_times[-1] - failure_times[-2]
            assert_that(gap).is_less_than(0.1)  # バックオフ遅延なし = 回路がオープン

生活の中の状況

コンテキストと問題の説明

あるフィンテック企業において、我々の支払いゲートウェイは、REST経由でレガシーバンキングAPIと統合されていました。ブラックフライデーセール中に、銀行は30秒間503エラーを返す障害を経験しました。我々のサービスは、単純な即時リトライ（3回の試行、0msの遅延）で構成されており、2,000件の正当な支払いリクエストを6,000件/秒に変換し、銀行の回復エンドポイントを攻撃しました。この「リトライストーム」は銀行インフラを崩壊させ、45分間のダウンタイムと200万ドルの取引損失を引き起こしました。我々の既存の自動化スイートは固定の200ms遅延を持つWireMockを使用しており、すべてのテストに合格しましたが、変動するネットワークレイテンシをシミュレートせず、リトライ試行間のタイミングを測定しなかったため、雷鳴の群れの動作を完全に捕捉できませんでした。

検討された異なるソリューション

ソリューションA: 固定の失敗シナリオを持つ静的モックサーバー

我々は、最初のNリクエストに対して503エラーを返し、その後200を返すようにWireMockのセットアップを拡張することを考えました。このアプローチは、決定論的なアサーションとサブ秒のテスト実行を提供しました。しかし、TCPレベルのネットワークパーティション（接続リセット、パケット損失）をシミュレートすることや、クライアントのリトライ間隔がジッターを伴った指数バックオフカーブに従っているか検証する能力が不足していました。利点はシンプルさとスピードでしたが、欠点は環境の忠実度が低く、回路ブレーカーのしきい値をテストする能力がないことでした。

ソリューションB: コンテナレベルのカオスエンジニアリング

我々は、Dockerデーモンレベルでネットワークレイテンシを導入するためにPumbaを評価しました（例：pumba netem --duration 1m delay --time 5000）。これにより現実的なネットワーク劣化が提供されましたが、精密なターゲティングが不足していました。特定のAPIエンドポイントをターゲットにしたり、特定のテストアクションに合わせて失敗注入を同期させたりすることができず、リトライタイミングについてのアサーションがほとんど不可能になりました。利点は高いリアリズムですが、欠点はテストの隔離が不十分で、全てのコンテナに影響を与え、不確定な実行によりフラスコCI結果が生じ、重複キーを確認するためのトラフィックを傍受できなかったため、冪等性を検証できませんでした。

ソリューションC: プログラム可能なプロキシと分散トレーシング（選択されました）

我々は、Docker Composeのテスト環境においてToxiproxyをサイドカーとして実装し、pytestフィクスチャからREST API経由で制御しました。これにより、リクエストが発行された正確なタイミングで、我々のサービスとモック銀行コンテナの間に特定のトキシック動作（例：timeout、reset_peer）を注入することが可能になりました。我々は、各リトライ試行の正確なタイムスタンプをキャプチャするためにJaegerトレーシングと組み合わせました。利点には、障害タイミングに対する詳細な制御、分散トレースでの主張の能力（バックオフ間隔の確認）、再現性のあるシナリオが含まれました。欠点はインフラの複雑さが増し、オペレーターがプロキシ設定を理解するための学習曲線があることです。

選択されたソリューションとその理由

我々は、再試行ポリシーと回路ブレーカーの交差点を検証するために必要な観測可能性と制御を提供したため、ソリューションCを選びました。プログラム可能なプロキシを使用することで、プロダクションからの正確な「503のブリップの後の雷鳴の群れ」シナリオを再現できました。プロキシのトキシティイベントとアプリケーションログを相関させることにより、「フルジッター」の実装によってピークリトライ負荷を6,000 req/sから340 req/sに減少させたことが示されました（94％の削減）。決定論的な制御により、これらのテストをCIでフラスコなしに実行でき、弾力性設定が後退していないことへの信頼を提供しました。

結果

自動化スイートは、ハーフオープン状態の検証中に重要なバグを検出しました：回路ブレーカーは成功したプローブ回復時に失敗カウンターをリセットしていなかったため、次の小さなグリッチで早期にオープンに戻ってしまっていました。状態マシンロジックを修正した後、システムはその後の銀行APIインシデント中に滑らかにデグレードし、完全に失敗するのではなくキャッシュされた支払い確認を提供しました。テストスイートは現在、プルリクエストの一部として4分で実行され、リトライと回路ブレーカーの構成の後退を防いでいます。

候補者が見逃すことが多いこと

ジッターが指数バックオフのリトライの雷鳴の群れを防ぐ方法、そして固定のスリープアサーションを使用せずにテストでその効果を統計的に検証する方法は？

ジッターはリトライ間隔にランダム性を導入します（例：delay = random_between(0, min(cap, base * 2^attempt))）、回復しているサーバーを圧倒する同期クライアントリトライを防ぎます（雷鳴の群れ）。これを自動化で検証するには、失敗しているエンドポイントに対して3回のリトライ試行が構成された100の並列リクエストを実行します。各リトライ試行のタイムスタンプを分散トレーシングまたはプロキシログを介してキャプチャします。正確な値について主張する代わりに、サーバーでの到着間隔の標準偏差を計算します。標準偏差がしきい値を超えることを主張します（例：1秒の基本遅延の場合、>800ms）。効果的なランダム化を確認するために、2つのリトライが互いに100msのウィンドウ内で発生しないことを主張することもできます。固定のスリープアサーションはジッターの確率的な性質を無視し、遅く、不安定なテストを生み出すため失敗します。

リトライ間での冪等性キーのローテーションが危険な理由、そしてテストフレームワークがサーバー側の重複除去を適切に検証するために冪等性キーの保存をどのように扱うべきかは？

リトライ間で冪等性キーをローテート（再生成）すると、安全性の保証が壊れ、サーバーが各リクエストを別個の操作と見なすために重複請求や在庫の二重割り当てを引き起こす可能性があります。キーは、単一の論理操作のためにリトライチェーン全体で同一でなければなりません。テスト自動化では、リトライループに入る前にUUIDv4を使ってキーを生成し、スレッドローカルまたはテストスコープのコンテキストに保存します。レース条件をテストするために、同じキーを使用して10スレッドを同時にエンドポイントに送信します。正確に1つのスレッドがHTTP 200を受け取り、他は409 Conflictまたは同一の成功レスポンスボディを受け取ることを主張し、サーバー側の重複除去の原子性を確認します。リトライループのキャッチブロック内で新しいキーを生成してはなりません。

回路ブレーカーの「ハーフオープン」状態の特定のリスクは何であり、この状態を自動化スイートでテストするのが特に難しい理由は何ですか？

ハーフオープン状態は、回路ブレーカーのタイムアウトが期限切れになる（例：オープン状態で60秒）と発生し、下流サービスが回復したかどうかをテストするために制限された数のプローブリクエスト（通常は1）を可能にします。このウィンドウ内で複数のリクエストが滑り込むか、プローブがバックグラウンドのヘルスチェックによって汚染されるリスクがあります。これにより、サービスがまだ失敗している間に回路が誤ってクローズに遷移したり、回復しているにもかかわらずオープンに留まったりする可能性があります。これをテストするのは難しいです。なぜなら、時間の精度とトラフィックの隔離が必要だからです。共有環境では、バックグラウンドプロセスや他のテストがリクエストを送信し、プローブカウントに干渉する可能性があります。解決策は、ハーフオープンウィンドウの間、単一のプローブリクエスト以外のすべてのトラフィックをブロックするプログラム可能なプロキシを使用するか、SUT内に回路ブレーカー制御エンドポイント（例：/actuator/circuitbreakers）を公開して内部状態マシンを直接確認し、テストにおいて時間ベースの待機の必要を回避することです。