カオス テストは、予期しない障害や中断を導入することで、ソフトウェア システムの回復性をテストするために使用される手法です。 カオステストは、カオスエンジニアリングとも呼ばれます。 カオス テストの目的は、弱点を特定し、アプリの回復性を向上することです。
カオステストは、 システムが予期しない方法で失敗するという考えに基づいています。 従来のテスト方法では、これらの予期しない故障モードを明らかにするには不十分なことがよくあります。 カオス テストを使用する場合は、サーバーのクラッシュ、ネットワーク遅延、リソースの枯渇など、実際のシナリオをシミュレートします。 これらの動作をシミュレートすると、通常のテスト条件下では明らかでない可能性のある隠れた問題や弱点を明らかにするのに役立ちます。
混乱のテストについて留意すべき重要なポイントを次に示します。
- 積極的に行動しましょう。 カオス テストでは、障害が発生するのを待つのではなく、障害を事前に導入して、システムがどのように応答するかを確認します。 カオス テストを使用すると、問題が大きな問題になる前に、問題を特定して修正できます。
- 知見を得る。 カオス テストの目的は、障害から学ぶことです。 それらを導入することで、ストレス下でのシステムの動作に関する貴重な洞察を得ることができ、その情報を使用して改善することができます。
- チームでの取り組みを促進します。 カオステストは、協力して行うときに最も効果的です。 開発者、テスト担当者、運用担当者、その他の利害関係者からの意見が必要です。 協力することで、テストする最も重要な領域を特定し、全員に情報を確実に提供することができます。
- 小さく始めて、段階的に進めましょう。 カオステストを初めて始めるときは、小さく始めて、テストの複雑さを徐々に増やしていくことをお勧めします。 小さい値から始めると、信頼度を高め、さまざまな条件下でのシステムの動作について理解を深めるのに役立ちます。
要約すると、混乱テストは、アプリの回復性の向上に役立つ強力な手法です。 障害を事前に導入し、そこから学習することで、問題が大きな問題になる前に特定して修正できます。
アプリが呼び出す API のカオステスト
カオステストは、多くの場合、インフラストラクチャ:サーバー、ネットワーク、コンテナーに焦点を当てます。 アプリが API に依存している場合、ユーザーが気付く障害の一部は、それらの API に起因します。たとえば、支払いプロバイダーからの500エラー、GitHub または OpenAI からの429エラー、または 80 ミリ秒ではなく 8 秒かかる応答です。 個々の API 応答のレベルで、これらの依存関係に同じカオステストのアイデアを適用できます。
- エラー。
5xxエラーをランダムに返し、アプリが安全に再試行できるものを再試行し、それ以外には役立つメッセージが表示されることを確認します。 - 調整。
429ヘッダーを付けてRetry-Afterを返し、アプリが再度呼び出す前に待機することを確認します。 - 遅延。 応答を遅らせて、タイムアウト、スピナー、応答が順不同で届いたときの動作を確認します。
| Approach | 見つけたもの | 見逃したもの |
|---|---|---|
| 本番を待つ | 実際の失敗 | ユーザーがそれをクリックするまでのすべて |
| テストで API をモックするか、コーディング エージェントにモックを記述させる | エラー 分岐が実行されるかどうか | API の実際のエラー形式、SDK の再試行ポリシー、そして実行中のアプリがどのように動作するか。 アプリでは、モックにアクセスするためにテスト専用のスイッチも必要です。 |
| 実際のインフラストラクチャに障害を発生させる (サービスの強制終了やネットワーク トラフィックのブロックなど) | システムが障害に対処する方法 | 特定のエラー コードや Retry-After ヘッダーなどの API レベルの障害 |
| アプリの実際のトラフィックをインターセプトし、API エラーを挿入する | 実際の URL のエラー、スロットリング、待機時間 (選択したレートで) | インフラストラクチャの障害。 それらには、インフラストラクチャのカオスツールを使用します。 |
アプリで試す
Dev Proxy は、実際の URL を呼び出し続けている間に、API 障害をアプリに発生させます。 コードを変更することなく、任意のテクノロジ スタック上の任意の種類のアプリで動作します。 たとえば、ランダム エラーで API への要求の半分を失敗させる場合は、「ランダム エラー でアプリをテストする」に従い、それらを遅くするには、「低速な API 応答をシミュレートする」を参照してください。 CI パイプラインで同じテストを実行するには、「CI/CD で Dev Proxy を使用」を参照してください。
次のステップ
Dev Proxy