Azureの混乱エンジニアリングでは、障害が回復性のギャップを露呈する前に、制御された障害をアプリケーションがどのように処理するかをテストします。 Azure Chaos Studioは、障害の挿入を適用して、リソースの使用不能や突然の負荷などの中断をシミュレートします。 Chaos Studio ワークスペースから始めて、リソースを検出し、実稼働前環境でシナリオを実行します。
Azure Chaos Studioは、これらの原則をマネージド サービスとして適用します。 Chaos Studio ワークスペースは現在のリソース モデルです。 ワークスペースはリソースを検出し、関連する停止パターンをシミュレートする シナリオ を推奨します。 実験 (クラシック) は、ターゲットと機能を使用するカスタム障害構成のレガシ モデルです。 モデルを選択するには、「Chaos Studio のワークスペースと実験 (クラシック) のどちらを選択するか」を参照してください。
回復性テストが重要な理由
分散クラウド アプリケーションは、個別に障害が発生する可能性があるインフラストラクチャ、サービス、ネットワークに依存します。 アプリケーションが許容するように設計されていない場合、1 つのコンポーネントの中断がシステム全体のインシデントに連鎖する可能性があります。 たとえば、データベースのフェールオーバー、DNS の停止、または可用性ゾーンがオフラインになるなどです。
回復性は、個々のコンポーネントではなく、システム全体のプロパティです。 アプリケーションが特定の障害パターンで存続するかどうかを知る唯一の方法は、その条件でテストすることです。 Chaos エンジニアリングは、実稼働前および運用環境でこれを行うための構造化された方法を提供します。
カオス エンジニアリングChaos Studio適用する方法
Chaos Studioは、制御された時間制限された方法でAzureリソースに対して障害を挿入します。 Chaos Studio ワークスペースでは、シナリオによって、障害パターンのアクション、影響を受けるリソースの種類、シーケンスが定義されます。 実験 (クラシック) では、実験によって、どの障害がどのターゲットに対して実行され、並列で実行されるか順番に実行されるかが定義されます。
多くの継続的な障害は時間に制限され、実験の終了時に一時的な変更が削除されます。 たとえば、障害によって、追加したネットワーク セキュリティ グループ規則が削除されたり、停止したリソースが再起動されたりします。 実験 (クラシック) の場合は、 障害ライブラリとアクション ライブラリでクリーンアップ動作を確認します。