はじめに
目的
本記事はAWS Fault Injection Service（FIS）をわかりやすく解説するために作成しました。FISの基本概念から実践的な使い方、注意点まで順を追って説明します。クラウド上でシステムの耐障害性（レジリエンス）を高めたい方に役立つ内容です。
対象読者
- クラウド運用や開発に携わるエンジニア
- システムの可用性を改善したいチームリーダー
- カオスエンジニアリングに興味がある方
専門用語はできるだけ避け、導入検討の初期段階の方でも理解しやすく書いています。
本章で学べること
- 記事全体の目的と流れ
- 各章で扱うテーマの概要
これにより、自分に必要な章をすぐに見つけられます。
記事の構成と読み方
第2章からFISの具体的な説明を始めます。基礎→実践→運用と進みますので、初めての方は順に読むことをおすすめします。既に使い慣れている方は、興味のある章だけ参照しても問題ありません。
AWS FISとは何か
概要
AWS Fault Injection Service（FIS）は、意図的に障害を発生させてシステムの回復力を確認するためのマネージドサービスです。カオスエンジニアリングの考え方をクラウド上で手軽に実践できます。たとえば、サーバーを止めたり、データベースを再起動したり、ストレージの遅延を発生させるなど、多様な障害を模擬できます。
特長
- マネージド型なので初期構築が簡単で、既存のAWSリソースに対してすぐに実験を行えます。具体例：数分で実験ファイルを作成して実行できます。
- 制御と可視化がしやすく、失敗条件や実験の時間をあらかじめ設定できます。これにより本番環境でのリスクを抑えながら検証できます。
- 権限管理や安全装置（ターゲットの制限、停止条件）を組み合わせて、安全に運用できます。
典型的な利用シーン
- システム障害時の自動復旧処理の検証
- 障害検出アラートや監視設定の有効性確認
- ピーク時の耐障害性テスト（負荷が高い時の挙動確認）
誰が使うか
インフラ運用者や開発チーム、SRE（サイト信頼性エンジニア）が中心です。特に可用性や復旧時間を重要視するサービスで有効です。
注意点（簡単に）
実験はリスクが伴うため、スコープの明確化、関係者通知、ロールバック手順の準備が必要です。権限設定を厳格にして誤操作を防ぎましょう。
FISの基本構成要素と用語解説
はじめに
FIS（Fault Injection Service）でよく出る言葉を分かりやすく整理します。実際の運用を想定した例を交えて説明しますので、初めてでもイメージしやすいです。
主要用語の定義
-
ターゲット（Target）
障害を与える対象です。例：特定のEC2インスタンス、RDS、ロードバランサーなど。ターゲットはタグやリソースIDで指定します。 -
アクション（Action）
ターゲットに対して行う障害操作です。例：インスタンス停止、ネットワーク遅延の注入、CPU負荷の発生など。アクションは実行時間やパラメータを設定できます。 -
実験テンプレート（Experiment Template）
複数のターゲットとアクション、実行条件（継続時間や停止条件）をまとめた設計図です。たとえば「3台のWebサーバーから1台を停止し、残りに負荷をかける」といった構成を定義します。 -
実験（Experiment）
テンプレートに基づいて障害を実際に発生させるプロセスです。ログやメトリクスを確認しながら実行します。
実験の流れ（簡単な手順）
- ターゲットを決める（例：prod環境のWebサーバー群）
- アクションを選ぶ（例：1台停止、ネットワーク遅延）
- テンプレートにまとめる（実行時間・停止条件を設定）
- 実験を実行し、監視とログで影響を確認する
実践例
- フェイルオーバー確認：RDSを一時停止して自動フェイルオーバー動作を確認
- スケール試験：一部のEC2に高負荷をかけてオートスケーリングの応答を見る
安全対策（運用での注意）
- 事前にバックアップや監視を準備する
- 停止条件やロールバックを必ず設定する
- 本番で実行する場合は時間帯や影響範囲を周知する
どんな障害注入ができるか（アクション例）
概要
AWS FISは多様な障害注入アクションを提供します。実際の運用に近い障害を手軽に再現でき、システムの耐障害性を確認できます。
主なアクション例
- EC2の停止・再起動
- 単一インスタンスや複数インスタンスを停止してフェイルオーバーを確認します。例：プライマリを停止して自動復旧やロードバランス動作を確認する。
- EBSのI/O遅延・I/Oエラー注入
- ストレージ遅延やエラーを再現し、アプリのリトライやタイムアウト挙動を評価します。
- ECSタスクの強制停止
- 特定サービスのタスクを落とし、コンテナオーケストレーションの再スケジューリングを観察します。
- RDSインスタンスのリブート
- データベース再起動やフェイルオーバーの動作確認に使います。読み取りレプリカや接続再試行の検証に有用です。
- ネットワーク遮断・遅延・パケットロス
- サービス間通信が途絶えたときの動作を確認します。遅延を加えてタイムアウトやスループットの劣化を確認する例が多いです。
- AZ単位の障害模擬
- 特定アベイラビリティゾーンのリソースを対象に停止を行い、冗長構成の効果を検証します。
実行方法と注意点
アクションは管理コンソールやAWS CLIで設定できます。IAMで実行権限を限定し、フェイルセーフ（停止条件や影響範囲の最小化）を必ず設定してください。初回はステージング環境で小さく試し、影響を監視しながら段階的に広げると安全です。
実験レポートと可視化
概要
2024年のアップデートで、FISは実験レポートの自動生成に対応しました。実験アクションの要約、CloudWatchダッシュボードからのアプリケーション応答、レジリエンステストのエビデンスが一つのレポートで得られます。これにより障害注入の結果を素早く可視化・共有でき、監査やナレッジ共有に役立ちます。
自動生成レポートに含まれる主な項目
- 実験のメタ情報：実施日時、実験テンプレート名、実行ID、実行者（IAMロール）
- アクション要約：投入した障害とターゲット・期間
- 監視データの抜粋：CloudWatchから取得したレスポンスタイム、エラー率、スループットのグラフ
- ログ参照：関連するログのサンプル行（リンク付き）
- 成否判定・注記：実験中に発見した問題点や影響範囲
可視化で見るべきポイント（具体例）
- ベースラインと実験ウィンドウを同じグラフに重ねる：応答時間の変化が一目で分かります。
- エラー率とスループットを並べて表示：エラー増加がトラフィック変化によるものか判断できます。
- リソースメトリクス（CPU・メモリ・ネットワーク）を短い粒度で確認：スパイクの発生源を特定しやすくなります。
実務での活用例
- 監査用エビデンス：実行IDやタイムスタンプが入るので、後で証跡として提示できます。
- ナレッジ共有：レポートをS3にエクスポートしてチームで閲覧、もしくはSlackへ要約を自動投稿します。
- 改善サイクル：レポートで原因を特定し、実装改善→再実験で効果検証を回します。
簡単なチェックリスト（実験後）
- レポートの実行IDとタイムスタンプを確認する。
- ベースラインと比較して主要メトリクスの変化を評価する。
- 関連ログの抜粋を確認し、想定外の例外を記録する。
- 監査用にレポートをS3に保存しアクセス権を設定する。
- チームへ要点を共有し、必要な改善アクションをまとめる。
補足（運用上の注意）
自動生成レポートは便利ですが、取得するメトリクスの粒度やログの保存期間によって証跡の精度が変わります。実験前に監視の設定を見直しておくと、より有用なレポートが得られます。
FISの料金体系
料金モデル
AWS FISは従量課金制です。基本は「アクションの実行時間（分）×$0.10」です。実験で複数のアクションを同時に実行した場合、それぞれのアクション分が合算されます。初期費用や最低料金は発生しません。追加アカウントで実験する場合は、各アカウント分が同じ単価で加算されます。
別途かかるコスト
CloudWatch LogsやS3にログを保存すると、それぞれの標準的な保存・転送の料金が発生します。さらに、FISのアクションが呼び出す他サービス（例：EC2、Lambda、SNSなど）は通常の利用料が別途発生します。
コスト試算の簡単な例
・1つのアクションを5分実行、1アカウント：5分×$0.10＝$0.50
・3つのアクションを各5分、1アカウント：15分×$0.10＝$1.50
・同じ構成を4アカウントで実行：15分×4×$0.10＝$6.00
ログ保存やデータ転送は別途となります。
コスト抑制のポイント
・実験時間を短くする（短いサンプルで検証）
・対象を絞って実行（全ノードではなく代表系のみ）
・ログレベルや保持期間を見直す
・非本番環境でまず実行してから本番へ移行
請求はAWSの請求ダッシュボードに表示され、「AWS Fault Injection Simulator」や関連サービスの項目で確認できます。低コストで反復試験しやすい仕組みです。
FISのユースケース・実践事例
1) 本番障害の予行演習（大規模シナリオ）
実運用で起きうる複数障害を再現し、手順やチーム連携を確認します。例：EC2大量停止＋RDS接続遅延で復旧手順やオートスケーリングの挙動を検証します。
2) マルチアカウント・マルチAZ耐障害性テスト
複数アカウントやAZにまたがる構成を対象に、障害に強い設計かを確認します。フェイルオーバーやデータ整合性の検証に役立ちます。
3) ネットワーク分断・サブネット障害の模擬
NACLやセキュリティグループを使ったネットワーク遮断で、サービスの切り分けやルーティングの堅牢性を確認します。カナリア環境で段階的に実施できます。
4) ストレージ性能劣化（EBS I/O）のシミュレーション
I/O遅延やエラーを模擬して、バックアップ・リカバリ手順やアプリの耐障害性を検証します。スナップショット運用も併せて確認します。
5) インシデント対応訓練と観測性検証
アラート・ダッシュボードを実際の障害で検証し、ランブックの有効性やログの足りなさを洗い出します。
実践時は小さな範囲で段階的に実施し、アクセス権限とコストに注意してください。
FISの始め方・操作方法
概要
AWS FISはコンソールとAWS CLIの両方で操作できます。基本は「実験テンプレート」を作り、対象リソース・アクション・実行順序を定義し、適切なIAMロールで実行します。
前提準備
- AWSアカウントとFISを使う権限
- 実験で影響を受けるリソースの識別
- 実験用のIAMロール（信頼関係と必要な権限を付与）
コンソールでの手順（簡潔）
- AWSマネジメントコンソールで「Fault Injection Simulator」に移動
- 実験テンプレートを作成→名前・説明を入力
- 実行対象（タグやリソースID）を指定
- アクション（例：インスタンスの停止、ネットワーク遅延）を追加
- タイミングや順序、停止条件を設定
- IAMロールを選択して保存→実行ボタンで開始
CLIでの手順（例）
- テンプレートをJSONで定義し、aws fis create-experiment-template コマンドで登録
- 登録後、aws fis start-experiment で開始
IAMロール設定のポイント
- 実験実行に必要な最小権限を付与
- 信頼ポリシーでfis.amazonaws.comを許可
- ログ出力先（CloudWatch/S3）への書き込み権限を付与
実行と監視
- コンソールの実験画面で進行状況を確認
- CloudWatchやログで影響範囲を監視し、必要なら即時停止
トラブル対処のヒント
- 実験前にステージング環境で検証
- ロールやリソース指定ミスはエラーの元
- 変更を小さく・短時間で行う
注意点とベストプラクティス
本番で実験する前の準備
本番での障害実験は必ず計画的に行います。影響範囲を明確にし、目標（何を検証するか）と許容するダウンタイムを決めます。小さな範囲から始め、段階的に拡大する「カナリア方式」を採用してください。
安全策（ガードレール）を設定する
CloudWatchアラームやX-Rayで重要指標（レイテンシ、エラー率、スループット）を監視します。アラームで自動中止やロールバックをトリガーする設定を必ず入れてください。FISのゾーンオートシフトやAbort条件を活用すると安全です。
ロールバックと復旧計画
事前に復旧手順と責任者を決めます。スナップショット、AMI、RDSのポイントインタイム復元などを準備し、手順はRunbookにまとめます。短時間で復旧できる手順をテストしておきます。
スコープと権限管理
実験は最小権限のIAMロールで実行します。対象リソースをタグや条件で限定し、誤操作のリスクを下げます。テンプレートのバージョン管理とレビューも行ってください。
運用上の注意点
メンテナンスウィンドウやビジネス影響の少ない時間帯に実施します。関係者へ事前通知し、観測ダッシュボードと連絡手段を用意します。ログは長期間保管して事後分析に使います。
最新情報・今後の展望
現状（2024年以降）
FISは新しいアクション追加やレポート機能の強化が続いています。AWS re:Inventや公式ブログで機能追加や事例が随時紹介され、運用チームが実践しやすい形で進化しています。
注目ポイント（具体例で説明）
- 新アクションの追加：ネットワーク遅延や部分的なサービス停止など、より現実に近い障害を簡単に試せるようになっています。たとえば特定サブネットへの遅延付与といった実験が行えます。
- レポート強化：実験結果の可視化が進み、失敗箇所や影響範囲を短時間で把握できます。これにより復旧手順の検証が効率化します。
- テンプレートとガードレール：よく使う実験をテンプレ化し、許可範囲を制限するガードレールを設定できます。安全に運用しながら学習できます。
今後に期待すること
観測ツールや自動復旧とさらに連携し、オーケストレーションや提案機能が強化される見込みです。したがって、障害対応の自動化とナレッジ共有が一層進みます。
情報の追い方と実践アドバイス
最新情報はAWS re:Inventや公式ブログを定期的に確認してください。まずはステージング環境で小さな実験から始め、成功事例を社内で共有することをお勧めします。
