Azure Chaos Studio とは

Azure Chaos Studio は、カオスエンジニアリングを使って、クラウドアプリケーションとサービスの回復性を測定、把握、改善するのに役立つマネージドサービスです。カオスエンジニアリングは、制御された障害挿入実験を実行するために、実際の障害をアプリケーションに挿入する手法です。

回復性は、中断を処理して復旧するためのシステムの機能です。アプリケーションの中断により、ビジネスやミッションに悪影響を及ぼすエラーや障害が発生する可能性があります。 Azure アプリケーションの開発、移行、運用のいずれを行う場合でも、アプリケーションの回復性を検証して改善することが重要です。

Chaos Studio は、アプリケーションが中断や障害に効果的に対応することを検証することで、悪影響を回避するのに役立ちます。 Chaos Studio を使って、仮想マシン (VM) の停止や高 CPU 使用率など、実際のインシデントに対する回復性をテストできます。

次のビデオでは、Chaos Studio の背景について詳しく説明します。

Chaos Studio のシナリオ

サービスの開発から運用ライフサイクルまでまたがるさまざまな回復性検証シナリオに、カオスエンジニアリングを使用できます。 2 種類のシナリオがあります。

シフトライト: これらのシナリオでは、運用環境または運用前環境を使います。通常、シフトライトシナリオは、実際の顧客トラフィックやシミュレートされた負荷を使って行います。
シフトレフト: これらのシナリオでは、開発環境または共有テスト環境を使用できます。シフトレフトシナリオは、実際の顧客トラフィックを使わずに行うことができます。

Chaos Studio は、次の一般的なカオスエンジニアリングシナリオに使用できます。

これらのシナリオの多くでは、最初にアドホックカオス実験を使って回復性を構築します。その後、新しいデプロイによって回復性が低下しないことを継続的に確認します。確認は、継続的インテグレーション/継続的デプロイパイプラインでデプロイゲートとしてカオス実験を実行することで行います。

Chaos Studio を使うと、Azure リソースに対する安全で制御されたフォールト挿入を調整できます。カオス実験は Chaos Studio の中核となります。カオス実験では、実行する障害と実行対象のリソースを記述します。ニーズに応じて、並列または直列に実行するように障害を編成できます。

Chaos Studio では、2 種類の障害がサポートされています。

サービス直接: これらの障害は、インストールやインストルメンテーションなしで、Azure リソースに対して直接実行されます。たとえば、Azure Cache for Redis クラスターの再起動や、Azure Kubernetes Service ポッドへのネットワーク待機時間の追加などがあります。
エージェントベース: これらの障害は、VM または仮想マシンスケールセットで実行され、ゲスト内で障害が発生します。たとえば、仮想メモリへの負荷や、プロセスの強制終了などがあります。

各障害には、中止するプロセスや生成するメモリ負荷の量など、構成できる特定のパラメーターがあります。

カオス実験を構築するときは、順番に実行する 1 つ以上の "ステップ" を定義します。各ステップには、ステップ内で並列に実行される 1 つ以上の "ブランチ" が含まれています。各ブランチには、障害の挿入や一定期間の待機など、1 つ以上の "アクション" が含まれています。

障害を実行する対象のリソース "ターゲット" を "セレクター" と呼ばれるグループにまとめて、各アクションでリソースのグループを簡単に参照できるようにします。

次の図は、Chaos Studio でのカオス実験のレイアウトを示したものです。

Diagram that shows the layout of a chaos experiment.

カオス実験は、サブスクリプションとリソースグループに含まれる Azure リソースです。 Azure portal または Chaos Studio REST API を使って、実験の作成、更新、開始、キャンセル、状態の表示などを行うことができます。

カオスエンジニアリングの使用方法を理解したら、次のステップに進むことができます。