チュートリアル: シナリオを使用して AKS ゾーンの回復性をテストする

このAzure Chaos Studio シナリオチュートリアルでは、Chaos Studio ワークスペースを使用して、ゾーン障害に対するAzure Kubernetes Service (AKS)サンプルアプリケーションの回復性をテストします。アプリをゾーン冗長テストクラスターにデプロイし、ノードインフラストラクチャに対して コンピューティングゾーンダウン を実行します。初回実行では、1 つのゾーンに固定されたフロントエンドが提供されます。ポッドの配置を修正し、シナリオを再実行し、アプリケーションの可用性レポートとシナリオレポートを比較します。

このチュートリアルでは、最初のデモを適切に行い、AKS クイックスタートの AKS ストアデモサンプルアプリケーションを再利用するため、コンテナーレジストリやビルド手順はありません。約 1 時間の計画: クラスターの作成と、それぞれ約 5 分の 2 つのシナリオ実行。

Important

Chaos Studio ワークスペースとシナリオはパブリックプレビュー段階です。 Microsoftは、このプレビューを "そのまま" および "利用可能な場合" で提供し、サービスレベルアグリーメントまたは制限付き保証の対象ではありません。 Microsoftは、ベストエフォートベースでプレビューのカスタマーサポートを提供します。このプレビューは、運用環境での使用を目的としていません。詳細については、以下の記事を参照してください。

このチュートリアルでは、以下の内容を学習します。

ノードが 3 つの可用性ゾーンにまたがる AKS クラスターを作成します。
AKS ストアデモサンプルアプリケーションをデプロイし、決定論的デモ用にフロントエンドを 1 つのゾーンにピン留めします。
ネットショップ、ターゲットノード、ポッドの配置をリアルタイムで追跡するブラウザーベースのモニターを起動します。
クラスターのインフラストラクチャリソースグループをスコープとしたワークスペースを作成します。
コンピューティングゾーンダウンシナリオを実行し、アプリケーションの失敗を観察します。
ハードゾーン単位の配置コントラクトを使用してデプロイを修正し、検証して、シナリオをもう一度実行します。
2 つのシナリオレポートを比較します。

このチュートリアルでは、動作中のデモ用に最適化します。各ステップの背後にある概念、AKS が管理するインフラストラクチャの中断に関する注意事項、および実際のワークロードで結果を解釈する方法については、「Chaos Studioを使用した AKS でのワークロードの回復性のテスト」を参照してください。

前提条件

Azure サブスクリプション。 Azure アカウントをお持ちでない場合は、開始する前に無料アカウントを作成してください。
Azure CLI、kubectl、kubelogin、Python 3 (標準ライブラリのみ - インストールするパッケージなし)。 Azure Cloud Shellには、4 つすべてがプレインストールされています。ローカルで作業する場合は、az aks install-cliとkubeloginを使用してkubectlを個別にインストールします。
サブスクリプションに登録されている Microsoft.Chaos リソースプロバイダー。登録手順については、「ワークスペースのクイックスタートの前提条件」を参照してください。

ゾーン冗長 AKS クラスターを作成する

ゾーン障害テストは、1 つを存続させるために構築されたクラスターに対してのみ意味があるため、3 つのノードが 3 つの可用性ゾーンに分散されたクラスターを作成します。この例では、米国東部 2 を使用します。可用性ゾーンを持つ任意のリージョンが機能します。

リソースグループとクラスターを作成します。

az group create --name chaos-demo-rg --location eastus2

az aks create \
  --resource-group chaos-demo-rg \
  --name chaos-demo-aks \
  --node-count 3 \
  --zones 1 2 3 \
  --generate-ssh-keys

クラスターの作成には数分かかります。

新しいCloud Shell セッションでは、kubectlはまだクラスターに接続されていません。 kubectl コマンドを実行する前に、サブスクリプションを設定し、資格情報をフェッチし、kubeconfig をMicrosoft Entra認証用に変換します。
```
az account set --subscription <SUBSCRIPTION_ID>
az aks get-credentials --resource-group chaos-demo-rg --name chaos-demo-aks
kubelogin convert-kubeconfig -l azurecli
```
サブスクリプション ID を <SUBSCRIPTION_ID>に置き換えます。そのサブスクリプションがすでにアクティブなものである場合は、az account set をスキップします。 kubelogin手順は、新しいCloud Shell セッションでも必要です。それなしでは、Entra 認証クラスターに対する最初のkubectl コマンドが認証エラーで失敗します。
ノードが 3 つのゾーンにまたがることを確認します。
```
kubectl get nodes -L topology.kubernetes.io/zone
```
ZONE列には、eastus2-1、eastus2-2、eastus2-3など、各ゾーンに 1 つのノードが表示されます。リージョン名の後のゾーン番号は、シナリオ構成の後半でターゲットにするものです。

サンプルアプリケーションをデプロイする

AKS ストアのデモは、Web フロントエンド、製品サービス、注文サービス、RabbitMQ キューを備えた小規模な小売店舗です。そのコンテナーイメージはパブリックであるため、1 つのコマンドでデプロイできます。

アプリケーションをデプロイします。
```
kubectl apply -f https://raw.githubusercontent.com/Azure-Samples/aks-store-demo/2.2.0/aks-store-quickstart.yaml
```
マニフェストは、すべてのコンポーネントを 1 つのレプリカでデプロイします。クラスターはゾーン冗長ですが、アプリケーションは冗長ではありません。このチュートリアルでは、この回復性のギャップを公開して修正します。
フロントエンドがパブリック IP アドレスを取得するまで待ちます。
```
kubectl get service store-front --watch
```
EXTERNAL-IPの値が<pending>からパブリック IP アドレスに変わったら、Ctrl+Cを押してウォッチを停止します。
ブラウザーで http://<EXTERNAL-IP> を開き、ストアの読み込みを確認します。このタブは開いたままにしておきます。これは、テスト中のアプリケーションの正常性のセカンダリビューです。後で起動するモニターが主要なビューです。

アプリケーション自体のビルドとデプロイ方法については、 AKS チュートリアルシリーズを参照してください。

決定論的デモ用にフロントエンドを 1 つのゾーンにピン留めする

注

1 つのレプリカを 1 つのゾーンにピン留めすることは 、運用環境の推奨事項ではなく、このデモの意図的な教育セットアップです。運用環境のデプロイでは、単一のレプリカを 1 つのゾーンに制限しないでください。これにより、クラスターが提供するように構築されている冗長性が削除されます。このチュートリアルでは、実行1での失敗が、スケジューラがたまたま選んだゾーンに左右されるのではなく、確実に再現できるように、意図的にこのようにしています。

意図的なピンがないと、スケジューラはフロントエンドの単一レプリカを任意のゾーンに配置でき、単純な再スケジュールは、影響が見逃しやすいほど迅速に行われる可能性があります。レプリカを既知のゾーンにピン留めすると、デモを実行するたびにターゲットが予測可能になり、エラーが監視できるようになります。

store-front ポッドが現在実行されているノードを見つけて、そのノードのゾーンラベルを読み取ります。
```
STORE_NODE="$(kubectl get pods -l app=store-front -o jsonpath='{.items[0].spec.nodeName}')"
PIN_ZONE="$(kubectl get node "$STORE_NODE" -o jsonpath="{.metadata.labels['topology\.kubernetes\.io/zone']}")"
echo "$PIN_ZONE"
```
PIN_ZONE は、 eastus2-1などの完全なゾーンラベルです。このシェルセッションを開いたままにしておきます。この値は、モニター用に再利用し、後でシナリオ構成に再利用します (数字、最後のハイフンの後の部分 (たとえば、eastus2-1の1) のみを要求します)。

store-frontデプロイにパッチを適用して、そのゾーンでスケジュールを要求し、パッチにデモのみのパターンとしてフラグを設定する注釈を追加します。

kubectl patch deployment store-front --patch "$(cat <<EOF
{
  "metadata": {
    "annotations": {
      "chaos-demo.aks-zone-down-demo/deliberate-anti-pattern": "Pins the single front-end replica to zone ${PIN_ZONE} so run 1 is deterministic. Removed as part of the fix later in this tutorial - do not carry this pin into a real deployment."
    }
  },
  "spec": {
    "template": {
      "spec": {
        "affinity": {
          "nodeAffinity": {
            "requiredDuringSchedulingIgnoredDuringExecution": {
              "nodeSelectorTerms": [
                {
                  "matchExpressions": [
                    {"key": "topology.kubernetes.io/zone", "operator": "In", "values": ["${PIN_ZONE}"]}
                  ]
                }
              ]
            }
          }
        }
      }
    }
  }
}
EOF
)"

kubectl rollout restart deployment/store-front
kubectl rollout status deployment/store-front --timeout=300s

保持されているピンを確認します。レプリカは、 $PIN_ZONEのノードに戻る必要があります。
```
STORE_NODE="$(kubectl get pods -l app=store-front -o jsonpath='{.items[0].spec.nodeName}')"
STORE_ZONE="$(kubectl get node "$STORE_NODE" -o jsonpath="{.metadata.labels['topology\.kubernetes\.io/zone']}")"
echo "Pod is in zone: $STORE_ZONE (expected $PIN_ZONE)"
```
2つの値が一致しない場合は、前の手順を繰り返してください。一致するまで、実行1は決定論的になりません。

デモモニターをダウンロードして起動する

ターミナル専用の kubectl ウォッチは、ライブデモ中に遅すぎて見逃しやすいです。ストアフロント独自のシグナルは、クラスターのシグナルと歩調を合わせて変動するわけではありません。このチュートリアルでは、実行を監視する主な方法として、Chaos Studio サンプルリポジトリの小さなPython モニタースクリプトを使用します。

モニターと修正検証スクリプトをダウンロードします。
```
curl -O https://raw.githubusercontent.com/microsoft/chaos-studio/f9573c943694e88cf3aacbca38debe84fa91a62c/samples/aks-zone-down-demo/monitor.py
curl -O https://raw.githubusercontent.com/microsoft/chaos-studio/f9573c943694e88cf3aacbca38debe84fa91a62c/samples/aks-zone-down-demo/verify-fix.sh
chmod +x verify-fix.sh
```
これらのリンクは特定のコミットにピン留めされているため、後でサンプルに加えた変更に関係なく動作し続けます。このプル要求がマージされ次第、このチュートリアルの今後の改訂版は、代わりにタグ付きリリースに移行できるようになります。
ネットショップの外部 IP と前のセクションでピン留めしたゾーンをポイントして、モニターを起動します。
```
python3 monitor.py --storefront-url http://<EXTERNAL-IP> --target-zone "$PIN_ZONE"
```
モニターはPython標準ライブラリのみを使用するため、インストールする他に何もありません。既定では、5 秒ごとにポーリングされます。 --interval または MONITOR_INTERVAL_SECONDS 環境変数で構成できます。この既定値は、Kubernetes API またはネットショップをあまり積極的にポーリングせずにシグナルの順序を解決するのに十分な頻度です。
Cloud Shellで、[Web プレビュー] を選択し、ポートを 8787 に設定して、ブラウザータブでモニターを開きます。ローカルで実行している場合は、代わりにhttp://localhost:8787を開きます。

これで、監視ページが両方の実行でメインの表示になります。次の 4 つの信号が表示されます。
- ネットショップの HTTP 状態 - ネットショップに対するキャッシュが無効化された要求であるため、キャッシュされた成功ではなく、ライブで到達可能/到達不能な状態が表示されます。
- ターゲットゾーンノードの状態 - ターゲットゾーン内のノードが Ready か NotReadyか。
- フロントエンドポッドの配置 - どのstore-frontポッドが実行されているか、およびそれぞれがどのゾーンにあるか。
- 遷移履歴 - 上記のすべての状態変化の実行中のタイムラインとタイムスタンプが表示されるため、ライブで気付いた内容に依存するのではなく、実行が終了した後のシーケンスを確認できます。
kubectlまたは Kubernetes API に対するポーリングが失敗した場合 (たとえば、API サーバーに一時的に到達できないか、kubeconfig が古くなった場合)、影響を受けるシグナルが "チェック" プレースホルダーに残るのではなく、モニターにエラーの名前が付いた赤色のバナーが表示されます。ダッシュボードの他の部分は、バナーが表示されている間も、最後に正常だった状態と履歴を表示し続けます。バナーをそれ自体のシグナルとして扱う:モニターが可視性を失ったことを意味し、監視している内容が正常であるわけではないことを意味します。

インフラストラクチャリソースグループをスコープとしたワークスペースを作成する

AKS は、クラスターのノード仮想マシンスケールセットを、クラスターリソースを含むリソースグループではなく、別の インフラストラクチャ リソースグループ (既定では MC_ で始まる名前) に配置します。ノードを検出するようにワークスペースのスコープをインフラストラクチャリソースグループに設定します。背景については、「 AKS クラスターをスコープとするワークスペースでコンピューティング先が見つからない理由」を参照してください。

インフラストラクチャリソースグループ名を見つけます。

az aks show --resource-group chaos-demo-rg --name chaos-demo-aks --query nodeResourceGroup -o tsv

Azure ポータルで、Chaos Studioを検索し、[ワークスペース] を選択して、[作成] を選択します。
[ 基本 ] タブで、 chaos-demo-rg リソースグループを選択し、ワークスペースに chaos-demo-workspaceという名前を付け、サポートされているリージョンを選択します。ワークスペースリージョンは、クラスターリージョンと一致する必要はありません。
[ スコープ ] タブで、スコープの種類として [リソースグループ ] を選択し、手順 1 でインフラストラクチャリソースグループを選択します。
Identity タブで、システム割り当て済み を選択します。
[確認と作成]>[作成]、[リソースに移動] の順に選択します。

検出が完了すると、クラスターのノード仮想マシンスケールセット ( aks-nodepool1-12345678-vmss など) が検出されたリソースとして表示されます。
ポータルに、ID にワークスペーススコープに対する読み取りアクセス許可がないというバナーが表示されている場合は、[ ワークスペーススコープに対する閲覧者ロールの割り当て] を選択します。ロールの割り当てを作成するには、インフラストラクチャリソースグループの所有者またはユーザーアクセス管理者権限が必要です。

次のセクションでシナリオ自体に必要なロールを ID に付与します。検証では、不足しているものが正確に示されます。各ワークスペース作成手順の完全なチュートリアルについては、ワークスペースのクイックスタートを参照してください。

シナリオを実行し、アプリの失敗を監視する

コンピューティングゾーンダウン シナリオでは、構成された期間、ターゲットゾーン内の仮想マシンスケールセットインスタンスをシャットダウンすることで、可用性ゾーンの障害をシミュレートします。アクションの期間が終了すると、インスタンスが再起動します。

ワークスペースで [シナリオ] を選択し、 シナリオ ライブラリから [コンピューティングゾーンダウン ] を選択します。
シナリオを構成します。可用性ゾーンの場合は、$PIN_ZONEの番号 (最後のハイフンの後の部分 (たとえば、eastus2-1の1) を入力します。時間を 5 分に設定します。ネットショップ、ノード、ポッドのシグナルが落ち着くのを確認するのに十分な長さです。過剰な待機は必要ありません。この 5 分間の数値は、この特定のデモ用にサイズ設定されています。他のシナリオの種類では、テスト対象に基づいて独自の期間ガイダンスが提供されます。たとえば、DNS キャッシュ動作を中心に構築されたシナリオでは、レコードのキャッシュ TTL を超えるのに十分な期間が必要です。これは、5 分をはるかに超える可能性があります。 [ 構成の保存] を選択します。
検証では、ワークスペースのマネージド ID が、ターゲットリソースに対してシナリオに必要なすべてのアクションを実行できるかどうかを確認します。検証でアクセス許可が不足していると報告された場合は、シナリオ構成ページで [アクセス許可の修正 ] を選択して、ID に推奨される組み込みロールを付与します。このシナリオでは、ノードの Virtual Machine Scale Sets における Virtual Machine Contributor を指します。自分でロールを割り当てたり、組み込みロールではなく最小特権のカスタムロールを使用したりするには、「Chaos Studio ワークスペースのアクセス許可と ID」および「Chaos Studio ワークスペースで最小特権カスタムロールを使用する」を参照してください。

実行時に必要なロールがまだ見つからない場合は、実行が開始されますが、シャットダウンアクションはシナリオレポートのアクセス許可エラーで失敗します。
[ 実行 ] を選択して確認します。

シャットダウンが有効になるまでに実行が開始されてから数分かかる場合があるため、モニターですぐに何も変更されない場合は、警告を表示しないでください。次に、モニターページを見ます。

ネットショップ HTTP シグナルとターゲットノードの状態は、同時に変化しません。アプリケーションレベルのシグナルは、ユーザーが実際に経験するものであり、プライマリとして扱うものです。ノードとポッドのシグナルは、後で追いつくクラスター内部のブックキーピングです。ノードが NotReady を示す前に、ネットショップが顕著に到達不能と表示されることを期待します。そのギャップは通常の非同期信号伝達であり、デモの問題ではありません。
ターゲットノードの状態が NotReadyに変わります。
フロントエンドはそのゾーンに固定されているため、その唯一のレプリカは、それ以外の場所で実行することは許可されません。 Kubernetes が Pod を再スケジュールできるようになるまで、ストアフロントは到達不能な状態のままです。ピンが設定されている状態では、これはターゲットノードが復旧するか、配置制約を変更した場合にのみ発生します。ここで固定ダウンタイム数に依存しないでください。モニターの切り替え履歴で、実行で実際に何が起こったかを確認します。

この結果がその発見です。クラスターはゾーン冗長でしたが、アプリケーションの配置の選択によって、ゾーン障害は、その制約が維持されている限り終了時期の定まらない停止に発展しました。モニターの移行履歴は、ネットショップがダウンしたときと、後で戻ったときの正確な記録です。

トラブルシューティング: 影響が確認できない

モニターに、run 1 の間中ストアフロントが到達可能な状態のままであることが表示される場合は、シナリオが機能しなかったと判断する前に、次の項目を確認してください。

ピンが有効であることを確認します。 kubectl get pods -l app=store-front -o wideを実行し、ポッドのノードが$PIN_ZONEになっていることを確認します。パッチが適用されなかった場合、スケジューラによってレプリカが別の場所に配置されている可能性があります。停止発生中の単純な再スケジュールは、PIN コードを入力しないと見逃してしまうほど速く行われる場合があります。
モニターが適切なゾーンと URL を監視することを確認します。 クラスターの正確な monitor.py 値とストアフロント URL を使用して、--target-zone を再起動します。古い値または入力ミスの値は、誤解を招く "正常" 状態を示します。
シナリオレポートで Skipped アクションを確認します。 シャットダウンアクションにSucceededではなくSkippedが表示された場合、ターゲットゾーンに一致するターゲットが見つかりませんでした。結果の解釈を参照してください。
もう少し待ってください。 シャットダウンアクション自体は、実行の開始後に有効にされるまでに少し時間がかかります。モニターの遷移履歴には、発生した正確なタイムスタンプが表示されます。

デプロイを修正して確認する

ここで、意図的に単一ゾーンに限定したピンを、クラスター規模の真の修正策に置き換えます。具体的には、3 つのレプリカを用意し、各ゾーンに 1 つずつ配置されるよう厳密に制約します。

前に追加したゾーンピンを削除します。

kubectl patch deployment store-front --type=merge --patch '{"spec":{"template":{"spec":{"affinity":null}}}}'

フロントエンドを 3 つのレプリカにスケールアップし、単に推奨するだけでなく、ゾーンごとに 1 つのレプリカを必須とするトポロジースプレッド制約を追加します:
```
kubectl patch deployment store-front --patch '{"spec":{"replicas":3,"template":{"spec":{"topologySpreadConstraints":[{"maxSkew":1,"topologyKey":"topology.kubernetes.io/zone","whenUnsatisfiable":"DoNotSchedule","labelSelector":{"matchLabels":{"app":"store-front"}}}]}}}}'
```
whenUnsatisfiable: DoNotSchedule では、各ゾーンに 1 つのレプリカを配置することが必須要件になります。その条件を満たせないレプリカは、すでにそれを持つゾーンに配置されるのではなく、Pending のままになります。これは意図的なトレードオフです。このテストの前提となるゾーンカバレッジを保証する一方で、ゾーンに一時的に空きがない場合、レプリカがスケジュールされない可能性を伴います。 ScheduleAnyway は、スケジューラが制約を圧力下でスキップできるようにします。これは、この修正プログラムが閉じる障害モードです。
修正プログラムを信頼する前に確認してください。検証スクリプトを実行します。ロールアウトを待機するため、古い単一レプリカリビジョンの古いポッドはカウントされず、すべてのゾーンに少なくとも 1 つの Readystore-front ポッドがあることを確認します。
```
./verify-fix.sh
```
kubectl呼び出し、API 要求、または返される JSON は、一時的に失敗する可能性があります。短いタイムアウト、接続の切断は、修正自体が失敗したことを意味しません。スクリプトは、最初のエラーを終了するのではなく、独自のタイムアウトまでこれらの一時的なエラーを再試行します。そのタイムアウトが経過して初めて、非ゼロのステータスで終了し、どのゾーンでまだ準備完了レプリカが不足しているかを示す診断メッセージを出力します。合格するまで、ステップ2を実行しないでください。テストに合格した結果によって、「ゾーンごとに 1 つのレプリカ」は、patch コマンドから引き継いだ前提ではなく、検証済みの事実になります。

シナリオをもう一度実行して比較する

ワークスペースで、同じターゲットゾーンと同じ 5 分間の期間で、 コンピューティングゾーンダウン シナリオをもう一度実行します。
モニターを視聴します。ターゲットノードは依然として NotReady の状態となり、その store-front レプリカも一緒に停止しますが、ストアフロントは、存続しているゾーンにあるレプリカによって処理され、引き続き応答し続けます。検証対象の主張はゾーン障害の間も可用性が維持されることであり、これはモニターの継続的な履歴によって証明されます。これは、失われたリクエストがゼロであることを意味するのではなく、また、モニターが終始途切れのない正常状態を示しているということでもありません。 Azure Load Balancer が残りの正常なレプリカに収束する間、短時間のサービス中断が発生する可能性があります。実行結果を見ると、収束時に一時的な変動が見られますが、これはサービス中断の期間にわたって続く停止ではありません。コンバージェンスにかかる時間は環境によって異なるため、一定の時間を前提にせず、モニターの状態遷移履歴を使って、一時的な異常と継続的な障害を見分けてください。

単一レプリカのコンポーネントでは、依然として短時間の中断が発生する可能性があります。 RabbitMQ キューのノードがターゲットゾーンにある場合、そのポッドの復旧中は注文送信のパフォーマンスが低下します。次に弱いコンポーネントを見つけ、修正する価値があるかどうかを判断することは、まさにループカオステストが駆動するように設計されています。

シナリオレポートを比較する

ワークスペースで、[ 実行履歴] を選択します。これで、同じシナリオの 2 つの実行が完了しました。
各実行を選択し、[ レポートの生成] を選択します。シャットダウンアクションの両方に [成功] 状態が表示されていることを確認します。つまり、ターゲットゾーンで各実行が見つかり、インスタンスが中断されたことを意味します。アクションに [スキップ] と表示された場合、実行で一致するターゲットが見つかりませんでした。通常の原因は、インフラストラクチャリソースグループやノードのないターゲットゾーンが含まれていないスコープです。詳細については、「Chaos Studioを使用した AKS でのワークロードの回復性のテスト」を参照してください。
アプリケーションの結果が逆であっても、両方のレポートが同じように見える点に注意してください。成功は、障害注入が実行されたことを意味しますが、アプリケーションが正常な状態を保ったことを意味するわけではありません。このレポートは、どのような中断がいつ発生したかを証明します。モニターの遷移履歴は、応答でアプリケーションの動作を証明するものです。この 2 つのペアリングは、実行を証拠に変える方法です。レポートはエラーのタイムスタンプを付け、モニターには修正の前後の違いが表示されます。

回復性レビューの前と後の両方の証拠としてレポートをダウンロードできます。詳細については、シナリオレポートを参照してください。

リソースをクリーンアップする

リソースグループを削除して、クラスター、サンプルアプリケーション、ワークスペースを削除します。クラスターを削除すると、そのインフラストラクチャリソースグループも削除されます。

az group delete --name chaos-demo-rg --yes --no-wait

問題を報告し、機能を要求する

Azure Chaos Studioはオープンで開発されています。バグを報告したり、機能を要求したり、ワークスペース、シナリオ、またはAzure CLI拡張機能について質問したりするには、GitHubの Chaos Studio リポジトリで問題を開きます。問題を提出することで、その進行状況を追跡し、他の顧客からの要求を確認できます。

次のステップ

Chaos Studioを使用して AKS のワークロードの回復性をテストし、実際のワークロードに対してこのテストを実行するための注意事項と解釈のガイダンスについて説明します。
実際のワークロードに対して成功または失敗の目標を設定するには、 Application Insights 可用性テストと、ブラウザータブではなく独自のサービスレベルインジケーターを使用してシナリオを実行します。
チュートリアル: PostgreSQL ゾーンダウンフェールオーバーシナリオを実行すると、同じ停止パターンにデータ層フェールオーバーが追加されます。
Azure Chaos Studioのシナリオでは、完全なシナリオライブラリについて説明します。
Chaos Studio GitHub リポジトリには、このサンプルのデプロイスクリプト (このチュートリアルで使用するモニターと検証スクリプトを含む)、共有可能なカスタムシナリオ、GitHub CopilotからChaos Studioを駆動するための Copilot CLI プラグインがあります。

フィードバック

このページはお役に立ちましたか?

最終更新: 2026-09-05