Azure Chaos Studio

解決する課題

「障害が起きても本当に耐えられるか」は、実際に障害を起こしてみないと確証が得られません。Azure Chaos Studio は、依存先の停止やネットワークの遅延、リソースの高負荷などを意図的に注入する実験を計画的に実行し、アプリの回復力（レジリエンス）と隠れた弱点を本番障害が起きる前に可視化します。

• 冗長化や自動フェイルオーバーが設計どおりに機能するかを、実障害を待たずに検証したい
• 依存サービスの停止や遅延に対し、アプリがグレースフルに劣化できるか確かめたい
• 障害時のアラートやランブックが実際に機能するかを、訓練（ゲームデー）で確認したい
• リリースのたびに回復力の回帰が起きていないかを継続的にテストしたい
• 障害注入を安全に制御し、検証が想定外に広がって実害を出すのを防ぎたい

主要概念と用語

• カオス エンジニアリング: 制御された障害を意図的に注入し、システムの回復力を検証する取り組み。本サービスはこれをマネージドに支援する
• 実験（Experiment）: 障害注入の定義。どのリソースに、どのフォールトを、どの順序・並列で注入するかをまとめた単位
• フォールト（Fault）: 注入する障害の種類。VM のシャットダウン、CPU 高負荷、ネットワーク遅延、リソースのアクション実行などがある
• ステップ / ブランチ / アクション: 実験の構造。ステップを順番に進め、各ステップ内のブランチを並列に走らせ、ブランチ内のアクション（フォールトや待機）を実行する
• ターゲット（Target）: フォールトを注入する対象として有効化したリソース。あらかじめオンボードして有効にしておく必要がある
• 機能（Capability）: ターゲットで有効にした個々のフォールト能力。対象に応じて使えるフォールトの種類を絞り込める
• セレクター（Selector）: 実験内で対象リソースをまとめて指す名前付きのグループ。フォールトをこのグループへ適用する
• エージェント型フォールト: 対象 VM にエージェントを入れて注入する障害。CPU・メモリ・ディスク負荷などゲスト OS 内部に作用する
• サービス直接型フォールト: エージェント不要で、Azure のリソース API を通じて注入する障害。リソースの停止や再起動など外側から作用する

仕様・制限・クォータ

• フォールトは大きくエージェント型とサービス直接型に分かれる。前者は対象にエージェントの導入が必要で、後者はエージェント不要でリソースに直接作用する
• 実験対象のリソースは、事前に**ターゲットとして有効化（オンボード）し、使う機能（フォールト能力）**を選んでおく必要がある
• 実験はステップ→ブランチ→アクションの階層で構成し、順次実行と並列実行、待機を組み合わせて障害シナリオを表現する
• 対応するフォールトの種類や対象リソースは拡充され続けているため、計画時は対象サービスごとに利用可能なフォールトの最新一覧を確認する
• サブスクリプションやリージョンごとに、扱える実験数などに上限があり得るため、大規模利用時は最新の制限値を確認する
• 具体的な対応フォールト・リージョン・上限は変動するため、断定せず最新の公式情報を参照する

内部の仕組み

利用者は実験を定義し、対象リソースをターゲットとして有効化したうえで、どのフォールトをどの順序・並列で注入するかをステップとブランチで記述します。実験を開始すると、Chaos Studio が定義に従ってフォールトを対象へ適用し、指定の時間が経過すると自動的に元の状態へ戻します。

• サービス直接型のフォールトは、Azure のリソース API を介して対象に作用する。エージェントの導入が不要で、リソースの停止・再起動・スロットリングなどを外側から起こせる
• エージェント型のフォールトは、対象 VM に導入したエージェントを通じてゲスト OS の内部に作用し、CPU・メモリ・ディスクの逼迫などを再現する
• 実験はマネージド ID を使って対象リソースへフォールトを適用するため、必要な権限をその ID に限定して付与する
• フォールトには継続時間を指定し、時間が来ると注入を解除して通常状態へ復帰させる
• 実行中はAzure Monitor のメトリクスやログと突き合わせ、障害下での挙動（フェイルオーバー、エラー率、応答時間）を観測する

設計パターン / ベストプラクティス

• 仮説駆動で設計する: 「依存先が落ちてもフェイルオーバーで継続できる」など、検証したい仮説を立ててから実験を組む
• ブラスト半径を限定する: セレクターで対象を絞り、まずは一部のインスタンスやステージング環境に注入して影響を封じ込める
• 段階的に広げる: 小さな実験で安全性を確認してから、対象範囲・フォールトの強度・本番への適用へと少しずつ拡大する
• 観測とセットで実施する: 実験前に正常時のメトリクスを把握し、注入中・回復後の挙動を Azure Monitor で比較して弱点を特定する
• CI/CD やゲームデーに組み込む: 定期的な訓練やパイプラインに実験を組み込み、回復力の回帰を継続的に検出する
• 緊急停止の手順を用意する: 想定外の影響が出たときに実験を即時停止できる手順を周知し、関係者へ事前に告知してから実施する

運用・監視

• 実験の実行中・実行後は Azure Monitor のメトリクスとログで対象システムの挙動を観測し、仮説どおりに回復したかを検証する
• 想定外の影響が出た場合に備え、実験を停止できる手順を整え、誰でも迅速に止められるようにしておく
• 実験は az CLI や REST API、パイプラインから自動化し、定期的な回復力テストとして繰り返し実行する
• 実験ごとの結果（注入したフォールト、対象、観測されたメトリクスの変化）を記録し、見つかった弱点を改善のバックログに回す
• 対象のオンボード状況や使用する機能を点検し、実験対象から外れたリソースを整理する

コスト

課金は、おおむねフォールトを注入していた時間（実験で障害を発生させた稼働分）に基づく従量制です。実験を実行していない間の固定的なコストは小さく、検証に使った分だけがかかる考え方です。なお、実験そのものに加え、実験で動かした対象リソース側の課金（再起動に伴う再プロビジョニングなど）も併せて意識します。

セキュリティ

• 実験から対象リソースへの作用はマネージド ID を使い、その ID に必要最小限の権限だけを付与して影響範囲を限定する
• 実験の作成・実行権限は Microsoft Entra ID と Azure RBAC で制御し、誰がどの環境に障害を注入できるかを厳密に管理する
• 障害注入は実害につながり得る操作のため、対象環境を明確に区別し、本番への適用は承認と告知のうえで慎重に行う
• 実験定義やログに機微情報を残さないよう注意し、対象の指定やパラメーターに秘匿値を直書きしない
• ターゲットとして有効化するリソースと使う機能を最小限にとどめ、不要なフォールト能力を有効化したままにしない

関連サービス・比較

回復力の検証という点では Azure Load Testing が近い関係にあります。Load Testing が「高負荷をかけて性能とスケール限界を測る」のに対し、Chaos Studio は「障害を注入して回復力と弱点を測る」もので、目的が補完的です。両者を組み合わせると、負荷と障害の両面から本番前の堅牢性を高められます。

ハンズオン / CLI例

# 拡張機能を追加（必要に応じて）
az extension add --name chaos

# 対象リソースをターゲットとして有効化（オンボード）
# 例: VM をサービス直接型のターゲットとして登録
az resource create \
  --resource-group demo-rg \
  --namespace Microsoft.Chaos \
  --resource-type targets \
  --name Microsoft-VirtualMachine \
  --parent "providers/Microsoft.Compute/virtualMachines/demo-vm" \
  --properties "{}"

# 定義した実験を作成（実験本体は ARM/JSON テンプレートで指定）
az chaos experiment create \
  --resource-group demo-rg \
  --name demo-experiment \
  --location japaneast \
  --steps @experiment-steps.json \
  --selectors @experiment-selectors.json \
  --identity-type SystemAssigned

# 実験を開始（障害注入を実行）
az chaos experiment start \
  --resource-group demo-rg \
  --name demo-experiment

# 想定外の影響が出たら実験を停止
az chaos experiment cancel \
  --resource-group demo-rg \
  --name demo-experiment