監視を設計し、DR の方式も選んだ。図の上では、切り替えも通知も正しく動くはずです。けれども「本当にその順で動くのか」は、実際に壊れるまで分かりません。障害の当日に初めて確かめるのは、いちばん高くつくやり方です。かといって本番を勝手に壊せば、上司や顧客に説明がつきません。この記事は、その間を埋める AWS Fault Injection Service（FIS）を、部品と安全弁の考え方から説明します。
この記事の結論
- FIS は、実際の AWS リソースに計画した障害を注入し、アプリの反応を観察するマネージドサービスで、カオスエンジニアリングの実行基盤です。
- 実験テンプレートは「アクション（何をする）・ターゲット（どれに）・停止条件（どこで止める）」の設計図で、実験はこのテンプレートから走ります。
- 停止条件は CloudWatch アラームで、定常状態（レイテンシなど）を数値で決めて初めて置けます。止まった実験は再開できません。
- 実際のリソースに実際の操作をするので、先に仮説を書き、本番の前にプレ本番で試します。
- 監視設計（SLO）と DR 設計（RTO・RPO）を「確かめる」側の部品として位置づけると、使いどころが見えます。
FIS とは何か｜「壊れ方を計画して確かめる」サービス
AWS Fault Injection Service（FIS）は、AWS のワークロードに対して障害を意図的に注入する実験を、マネージドで実行するサービスです。公式ドキュメントは、障害注入の実験を通じてアプリの性能・可観測性・回復性を改善するためのものと位置づけています。
考え方の名前はカオスエンジニアリングです。「本番で何が起きるか分からない」ことを減らすために、起きうる障害をあらかじめ決めて小さく起こし、システムがどう反応するかを観察します。ランダムに壊すことが目的ではなく、壊れ方を計画して、設計の想定と実際のずれを見つけることが目的です。
FIS が担うのは「注入して、安全に止める」部分です。何を観察して合否を決めるかは、あなたの監視（CloudWatch のメトリクスやアラーム）が担います。だから監視設計が先に要ります。
READ ALSO — 実務向け・段3 基盤
監視設計｜何を見るかは SLO から逆算する。4つのシグナルと、アラームを鳴らす基準の決め方
なぜ壊すのか｜設計図と実際の挙動のずれを、障害より先に見つける
冗長構成や DR は、構成図の上では「AZ が1つ落ちても動く」「リージョンを切り替えられる」と書けます。ところが実際には、次のようなずれが起きがちです。
- 切り替えを前提にしたタイムアウトやリトライの設定が、想定より長い
- アラームの閾値が緩く、劣化を検知するのが遅い
- 通知は飛ぶが、誰が何を見るかが決まっていない
これらは図を眺めても見つかりません。障害が起きてから見つかると、それがそのまま事故になります。事故の形をした問題を、事故になる前に自分の手で再現して見つけるのが、わざと壊す理由です。
AWS の Well-Architected フレームワークの信頼性の柱にも、信頼性をテストするという考え方があります。FIS はその実行手段の1つとして、公式ドキュメントから案内されています。柱の全体像は別の記事で扱っています。
READ ALSO — 学習中向け・段2 構成
AWS Well-Architected フレームワークとは｜6つの柱・設計原則・レンズを「問いの集まり」として使う
実験テンプレートの部品｜アクション・ターゲット・停止条件
FIS の実験は、実験テンプレートから走ります。テンプレートは実験の設計図で、主に3つを決めます。
THREE PARTSテンプレートの3部品
実験テンプレートはアクション・ターゲット・停止条件で決まる
-
アクション
何をするか
例: インスタンスの停止、API エラー
決める: 起こす障害の種類
-
ターゲット
どのリソースにか
例: 小さく絞った対象
決める: 影響の範囲
-
停止条件
どこで止めるか
例: CloudWatch アラーム
決める: 打ち切りの数字
| 部品 | 決めること | 考え方 |
|---|---|---|
| アクション | どんな障害を起こすか | インスタンスの停止、API エラーの注入など。種類の一覧は公式で確認する |
| ターゲット | どのリソースに起こすか | 範囲を絞る。最初は小さく選ぶ |
| 停止条件 | どこで実験を打ち切るか | CloudWatch アラームで、定常状態の崩れを検知する |
アクションの種類はサービスごとに多く、更新もあるので、この記事では網羅しません。公式のアクション一覧を見て、自分の構成で試したい障害に合うものを選びます。
大事なのは、3つを揃えて初めてテンプレートが成り立つ点です。「何を壊すか」だけ決めて「どこで止めるか」が空のまま走らせることは、設計図の時点で避けます。
CHECK 1ここまでの確認
FIS の実験テンプレートを構成する3つの要素は何か?
答えと解説
答え: 1. アクション・ターゲット・停止条件
テンプレートは「何をするか（アクション）」「どのリソースにか（ターゲット）」「どこで止めるか（停止条件）」を決める設計図です。「実験テンプレートの部品」の章を読み直してください。
停止条件はなぜ CloudWatch アラームか｜定常状態を数字で決める
停止条件は、実験が想定より悪い方へ進んだときに自動で打ち切る安全弁です。公式ドキュメントでは、停止条件は CloudWatch アラームとして指定します。アラームの状態が条件に当たると、FIS は実験を止めます。
ここで必要になるのが定常状態の定義です。定常状態とは、「いつもこの範囲なら正常」とみなす状態のことです。たとえばリクエストの遅延、エラー率、正常に応答している台数などを、数字で決めます。
- 定常状態を数字にする（例: 遅延がこの範囲なら正常）
- その範囲を外れたら発報するアラームを作る
- そのアラームを停止条件に指定する
こうして、「許容を超えたら人の判断を待たずに止まる」実験が作れます。つまり停止条件が置けるかどうかは、定常状態を数字で決められているかどうかで決まります。数字が無いと、止めどころも無いからです。
注意点が1つあります。停止条件で止まった実験は再開できません。原因を確かめ、閾値や範囲を見直して、新しく作り直して走らせます。
練習問題でも、計画的な障害注入と安全装置の組み合わせは、FIS の実験テンプレートで CloudWatch アラームを停止条件に指定する形が正解の考え方です。ここまでの内容と同じです。
CHECK 2ここまでの確認
遅延が定常状態の許容値を超えた時点で、実験を自動で終わらせたい。何を指定する?
答えと解説
答え: 2. 閾値を定常状態から決めた CloudWatch アラームを停止条件にする
止めどころは、定常状態を数字で決めたアラームに置きます。人の判断を待たずに止まるための安全弁です。「停止条件はなぜ CloudWatch アラームか」の章に戻ってください。
実験の進め方｜仮説・プレ本番・本番の順と、記録の残し方
FIS は実際のリソースに実際の操作をします。公式ドキュメントも、実験を事前に計画し、まず本番以外の環境で試すことを勧めています。進め方は、次のループに落とすと説明しやすくなります。
EXPERIMENT LOOP実験の回し方
仮説を先に書き、注入して観察し、直してまた回す
実験
プレ本番から
- 定常状態を決める
- 仮説を書く
- 注入する
- 観察する
- 直す
- 定常状態を決める: 何が正常かを数字にする
- 仮説を書く: 「AZ 内のインスタンスを止めても、この範囲で応答し続ける」のように、結果を先に言葉にする
- 注入する: テンプレートから実験を走らせる。停止条件は必ず付ける
- 観察する: 仮説どおりだったか、アラームは想定どおりに鳴ったか、通知は届いたかを見る
- 直す: ずれがあれば設計を直し、また実験する
順番は プレ本番 → 本番 です。最初から本番に当てるのではなく、範囲を小さくして、本番に近い環境で挙動を確かめます。本番で実験する場合も、影響を受ける範囲と時間帯を決め、関係者に知らせたうえで行います。
記録も成果物です。仮説・テンプレートの内容・結果・見つかったずれと直した点を残すと、次の人が同じ実験を再現できます。ずれが障害として現れたときには、ポストモーテムの材料にもなります。
READ ALSO — 実務向け・段3 基盤
ポストモーテムとは何か｜障害のあとに「誰のせいか」ではなく「なぜ起きたか」を残す振り返りの型
CHECK 3ここまでの確認
初めて FIS を使うとき、いきなり本番で走らせるのが勧められないのはなぜか?
答えと解説
答え: 2. 実際のリソースに実際の操作をするため、先に計画を書いてプレ本番で試すのが望ましいから
FIS は模擬ではなく実リソースに作用します。仮説と範囲を決め、プレ本番で挙動を見てから本番へ進みます。「実験の進め方」の章を読み直してください。
他の確かめ方との違いは何か｜DR 訓練・負荷試験・FIS の使い分け
「確かめる」手段は FIS だけではありません。何を確かめたいかで使い分けます。
DR DRILL VS FIS確かめる対象の違い
DR 訓練は人と手順を、FIS は構成の反応を確かめる
DR 訓練
手順と人の動き
- 手順書どおりに復旧できるか
- 切り替えの判断と連絡
FIS
構成の反応
- 部品が止まっても持ちこたえるか
- アラームが想定どおり鳴るか
| 手段 | 確かめるもの | 向いている問い |
|---|---|---|
| DR 訓練 | 手順と人の動き | 切り替えの手順書どおりに、担当者が復旧できるか |
| 負荷試験 | 量に対する余裕 | 負荷が増えたとき、どこで遅くなるか |
| FIS | 障害に対する構成の反応 | 部品が止まったとき、自動で持ちこたえるか |
3つは競合せず、補い合います。FIS で構成の自動の反応を確かめたうえで、DR 訓練で人が動く部分を確かめる、という順が自然です。DR の方式選びと訓練は次の記事で扱います。
READ ALSO — プロフェッショナル向け・段4 設計
災害対策（DR）の設計｜RTO と RPO から4つの方式を選び、訓練で確かめる
よくある誤解｜「本番を壊すサービス」ではなく、止めどころを決めて壊すもの
説明を求められたときの、よくある誤解を整理します。
FIS で避けたいこと
- 仮説も定常状態も決めずに、「とりあえず壊してみる」
- 停止条件を付けない、または意味のない閾値のアラームを付ける
- 初回からいきなり本番で走らせる
- 結果を記録せず、直した点を残さない
- 「本番を壊す乱暴なサービスでは？」 → 範囲・時間・停止条件を先に決めて起こすもので、止めどころの無い破壊ではありません。
- 「壊れなければ成功？」 → 仮説どおりに動いたと分かることも成果です。ずれが見つかれば、障害の前に直せたことになります。
- 「監視が無くても使える？」 → 注入はできても、判定できません。停止条件にも監視が要ります。
料金は、公式ドキュメントではアクションの実行時間（分）と対象アカウント数で決まると説明されています。金額は変わりうるため、公式の料金ページで確認してください。
Cloudory 執筆者（AWS 認定 全冠）
FIS を使うかどうかより先に、「何を正常とみなすか」を数字で言えるかが問われます。監視設計を済ませているなら、次の一手は小さな実験を1本、プレ本番で計画することです。
参照ソース
- AWS Fault Injection Service とは（公式ドキュメント） — FIS の定義、実験テンプレート・アクション・ターゲット・停止条件の概念、事前の計画と本番以外での試行の推奨、料金の決まり方の根拠に使った
- FIS の停止条件（公式ドキュメント） — 停止条件が CloudWatch アラームであること、定常状態の定義、停止した実験は再開できないことの根拠に使った
- Test reliability（AWS Well-Architected 信頼性の柱） — 信頼性をテストするという考え方への導線として参照した（詳細は書いていない）
