カオスエンジニアリングは、システムに制御された障害などを与え、想定したサービスの振る舞いが維持されるかを実験で確かめる取り組みです。「一部が故障しても処理を続けられる」という設計上の仮説を、観測できる結果に照らして検証します。
企業が初めて取り組む際は、対象を限定した検証環境で、仮説・影響範囲・停止条件・復旧方法を先に決めるところから始めましょう。本記事では、実施責任者と検証担当者が合意する項目を整理します。
カオスエンジニアリングで確かめること
基本となるのは、正常時の状態を測定可能な指標で定義し、障害を与えてもその状態が維持されるかを確かめる流れです。Principles of Chaos Engineeringでは、定常状態の定義、仮説の設定、現実の事象の導入、仮説の反証という手順を示しています。指標には、処理量・エラー率・応答時間などを使います。出典：Principles of Chaos Engineering
例えば「アプリケーションの一部が停止しても、利用者のリクエストは別の処理先へ渡る」という仮説なら、サーバーが停止した事実だけでは判断できません。リクエストの成功率や応答時間を、障害の前後で比較する必要があります。
負荷試験・復元テストとの使い分け
計画を立てる際は、次のように「今回答えたい問い」で整理すると、成果物を決めやすくなります。この分類は本記事での実務上の整理であり、試験同士の範囲は重なります。
| 試験の観点 | 今回答えたい問いの例 | 残す結果の例 |
|---|---|---|
| 負荷試験 | リクエストが増えたとき、どこまで処理できるか | 負荷量と応答時間・エラー率の関係 |
| 復元テスト | バックアップから必要なデータを戻せるか | 復元後の整合性、所要時間 |
| カオスエンジニアリング | 一部が故障しても、想定したサービス状態を保てるか | 仮説、与えた障害、利用者側の指標、復旧結果 |
最初の実験では、検証したい仮説を一つに絞りましょう。負荷量と障害の種類を同時に変えるより、条件を固定して一つずつ確かめる計画から始めます。
最初の実験は検証環境で範囲を区切る
Google Cloudは、小さく非本番環境で始め、学習・調整しながら本番へ範囲を広げる進め方を示しています。出典：Google Cloud
着手前には、対象のリソース名だけでなく、接続先も確認してください。検証環境という名前であっても、外部APIや共有データベースが実業務につながっていないかを点検します。
- 対象：環境、サービス、リソースID、台数を明記する。
- 除外：本番、共有基盤、外部サービスなど、影響を与えない対象を列挙する。
- データ：検証用データを使い、実際の注文・通知・課金が発生する経路を外す。
- 時間：開始時刻、障害を与える上限時間、復旧確認の終了予定を分ける。
- 権限：対象への操作権限と、実験を停止する権限を確認する。
環境やトラフィックの違いでシステムの挙動は変わります。検証環境での結果をそのまま本番全体の保証とせず、構成・データ量・依存先などの差分を結果に添えてください。出典：実験環境に関する原則
仮説は「障害・期待する状態・観測方法」で書く
以下は計画を具体化するための記入例です。数値は実測値や推奨基準ではありません。自社の平常値と許容範囲に置き換えてください。後続の確認表と担当分担も、本記事の編集上の提案です。
検証環境のアプリケーション2台のうち1台を最大60秒停止しても、固定した検証リクエストに対する成功率が99%以上、応答時間の95パーセンタイルが1秒以下に収まる。
ここでは、対象API、リクエスト数、成功の定義、計測間隔も併記します。実験前の通常運転で条件を満たすことを確認し、実験中と復旧後にも同じ方法で測ります。
仮説を満たさないときは、時刻をそろえた記録から、切り替えの遅れ、処理の失敗、依存先の応答などを調べます。障害を与えられたことと、仮説を検証できたことを分けて記録するのが要点です。
停止条件と復旧完了の条件は別に決める
実験を止める操作と、サービスを元の状態に戻す作業を同一視しないことが重要です。
AWS Fault Injection Service（AWS FIS）では、CloudWatchアラームを停止条件として設定し、その条件が発火すると実験を停止します。停止した実験は再開できません。出典：AWS FISの停止条件
ただし、すべての障害操作が取り消せるわけではありません。AWSの資料では、操作後に状態を戻すpost actionに対応しない操作もあり、terminateしたEC2インスタンス自体は回復できないと説明しています。また、停止操作時に未完了のpost actionがある場合は、その完了後に実験が停止します。出典：AWS FISのアクション、実験の停止
実施計画には、少なくとも次の三つを別欄で残しましょう。
| 判断 | 記入する内容 |
|---|---|
| 自動停止 | 監視指標、閾値、評価期間、欠測時の扱い、停止対象 |
| 手動停止 | 想定外の対象への影響、監視不能、担当者との連絡断などの条件と停止担当者 |
| 復旧完了 | 障害設定の解除、必要な再起動・再作成、利用者側の指標とデータ整合性の確認 |
仮説が成立したかを判定する基準と、影響を制限する停止基準も区別します。両者を同じ値にする場合でも、監視の評価期間を含めて記載してください。監視間隔や停止処理の所要時間を踏まえ、許容できる影響範囲に収まる設計かを事前に確認します。
通知先と初動の整理には、監視アラートの設計も参照できます。
実施前に埋める障害実験の計画表
次の表を、実施責任者・操作担当・監視担当で確認します。停止操作や復旧方法に未確認の欄が残る場合は、実験開始を見送り、その確認を先に行う運用にしましょう。
| 項目 | 記入欄 |
|---|---|
| 業務上の問い | 継続させたい利用者の操作：＿＿ |
| 仮説 | ＿＿が故障しても、＿＿を維持する |
| 正常時の状態 | 指標・平常値・測定条件：＿＿ |
| 対象と除外 | 環境・リソースID・最大台数・除外対象：＿＿ |
| 与える障害 | 操作・強度・上限時間・解除方法：＿＿ |
| 成立の判定 | 指標・閾値・評価期間：＿＿ |
| 自動停止 | アラーム・動作確認結果：＿＿ |
| 手動停止 | 条件・操作方法・担当者・代行者：＿＿ |
| 復旧 | 戻す手順・必要権限・完了条件：＿＿ |
| 記録 | 開始／停止時刻・対象・ログ・指標の保存先：＿＿ |
| 実施判断 | 責任者・実施時間帯・中止時の連絡先：＿＿ |
ツールの選定は、この表を埋めてから進められます。対象の障害を再現できるかに加え、対象の絞り込み、停止条件、操作履歴、復旧方法を確認してください。
結果は改善と再検証につなげる
実験後は「今回の条件で仮説が成立した」「成立しなかった」「観測不足で判定できなかった」を分けます。指標を取得できなかった場合に、問題が見えなかったことを成功扱いしないようにします。
想定外の挙動があれば、観測した事実と原因の仮説を分け、改善担当者と再検証条件を記録しましょう。整理の手順は、障害の振り返り方も参考になります。
検証を外部へ委託する場合、自社は業務上の許容範囲と実施判断を持ち、委託先とは実験設計・操作・監視・復旧の担当を合意します。成果物には、実験計画だけでなく、対象と実施時刻、観測結果、復旧確認、未検証の条件を含めてください。
最初に決めるべきことは、「何を壊すか」だけではありません。何を維持したいのか、どこで止めるのか、どう戻ったと判断するのかまで決まれば、障害耐性を確かめる実験として実施可否を判断できます。