カオスエンジニアリング入門｜AWS Fault Injection Service（FIS）で本番障害に強いシステムを検証する実践ガイド

オンプレミスのインフラを長年担ってきたエンジニアなら、「障害訓練」という言葉に覚えがあるはずです。年に一度、深夜に手順書を片手にフェイルオーバーを試す——あの演習です。クラウドに移行してからも、「障害が起きたら手順書通りに対応する」という受け身のアプローチを続けていませんか？

実はクラウド環境には、もっと積極的な手法があります。意図的に障害を注入し、システムの弱点を事前に発見する「カオスエンジニアリング」です。Netflixが「Chaos Monkey」で火をつけ、AWSでは AWS Fault Injection Service（FIS） というマネージドサービスとして提供されています。コンソールから安全に障害注入実験を設計・実行できます。

この記事では、カオスエンジニアリングの考え方から AWS FIS の実践的な使い方、料金体系、実務 Tips まで体系的に解説します。

カオスエンジニアリングとは？（オンプレとの違い・背景）

カオスエンジニアリングとは、本番環境または本番同等の環境に意図的に障害を注入し、システムの耐障害性を事前に検証するエンジニアリング手法です。2011年、Netflixがマイクロサービスの耐障害性を高めるために「Chaos Monkey」を開発したことが起源です。

オンプレ時代の障害対策は、主に以下のアプローチでした。

・冗長化設計: HAクラスタやRAIDで障害時の自動切り替えを実装
・手順書整備: 障害パターンごとの対応手順を文書化
・定期訓練: 年1～2回の計画的なフェイルオーバーテスト

これは有効ですが、決定的な弱点があります。訓練は「計画された障害シナリオ」しか検証できません。実際の本番障害は、予期しないタイミング・予期しない組み合わせで発生します。「手順書通りにやったのにシステムが落ちた」という経験は、多くのインフラエンジニアが持っているはずです。

クラウドではマイクロサービスの依存関係が複雑になり、「ある1サービスの遅延が全体に波及するカスケード障害」のリスクが高まります。これを事前に発見するために、カオスエンジニアリングが有効です。

カオスエンジニアリングの5原則（Principles of Chaos Engineering）は以下の通りです。

AWS Fault Injection Service（FIS）の概要

AWS Fault Injection Service（FIS）は、AWSが提供するマネージドの障害注入サービスです。2021年に「AWS Fault Injection Simulator」としてリリースされ、2023年に現在の名称へ変更されました。略称のFISはそのまま引き継がれています。

主要な障害アクションカテゴリを整理します。

FISの重要な機能として 停止条件（Stop Conditions） があります。CloudWatch アラームがトリガーされたら実験を自動停止できる仕組みで、「実験が想定以上の影響を起こしたら即座にブレーキをかける」ための安全装置です。この自動停止機能があるからこそ、カオスエンジニアリングを本番に近い環境で安全に実施できます。

FISで障害注入実験を実施する基本手順

1. Stop Conditionとなる CloudWatch アラームの準備

実験を始める前に、「緊急停止の仕組み」を先に作ります。たとえば「HTTPエラー率が5%を超えたら実験を停止する」というアラームです。

# AWS CLI で Stop Condition 用のアラームを作成（東京リージョン）
aws cloudwatch put-metric-alarm \
  --alarm-name "FIS-StopCondition-HighErrorRate" \
  --alarm-description "FIS実験の緊急停止条件: 5XX率が5件/分を超えたら停止" \
  --namespace "AWS/ApplicationELB" \
  --metric-name "HTTPCode_Target_5XX_Count" \
  --statistic "Sum" \
  --period 60 \
  --evaluation-periods 1 \
  --threshold 5 \
  --comparison-operator "GreaterThanOrEqualToThreshold" \
  --region ap-northeast-1

2. FIS 用 IAM ロールの作成

FIS が各サービスに対して障害アクションを実行するには、専用の IAM ロールが必要です。

# FIS の信頼ポリシー（trust-policy.json）
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "fis.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}

# ロール作成
aws iam create-role \
  --role-name FISExperimentRole \
  --assume-role-policy-document file://trust-policy.json \
  --region ap-northeast-1

# EC2停止実験に必要な権限をアタッチ（実験内容に合わせて最小権限で）
aws iam create-policy \
  --policy-name FIS-EC2StopPolicy \
  --policy-document '{
    "Version":"2012-10-17",
    "Statement":[{
      "Effect":"Allow",
      "Action":["ec2:StopInstances","ec2:DescribeInstances"],
      "Resource":"*"
    }]
  }'

aws iam attach-role-policy \
  --role-name FISExperimentRole \
  --policy-arn arn:aws:iam::123456789012:policy/FIS-EC2StopPolicy

3. 実験テンプレートの作成と実行

AWSマネジメントコンソールで「AWS FIS」→「実験テンプレートを作成」から進みます。設定項目は以下の通りです。

・アクション: どの障害を注入するか（例: EC2インスタンス停止）
・ターゲット: 対象リソースをタグ・リソースIDなどで絞り込む
・停止条件: 先ほど作成したCloudWatchアラームを指定
・IAMロール: 作成済みのFISExperimentRoleを指定

テンプレートをコードで管理したい場合は、CLI でも作成・実行できます。

# 実験テンプレート（experiment-template.json）
# ステージング環境のWebサーバーEC2を1台停止してAuto Scalingを検証
{
  "description": "WebサーバーEC2停止 - Auto Scaling動作確認",
  "targets": {
    "WebInstances": {
      "resourceType": "aws:ec2:instance",
      "resourceTags": {
        "Environment": "staging",
        "Role": "web"
      },
      "selectionMode": "COUNT(1)"
    }
  },
  "actions": {
    "StopWebInstance": {
      "actionId": "aws:ec2:stop-instances",
      "targets": { "Instances": "WebInstances" }
    }
  },
  "stopConditions": [{
    "source": "aws:cloudwatch:alarm",
    "value": "arn:aws:cloudwatch:ap-northeast-1:123456789012:alarm:FIS-StopCondition-HighErrorRate"
  }],
  "roleArn": "arn:aws:iam::123456789012:role/FISExperimentRole"
}

# テンプレート作成
aws fis create-experiment-template \
  --cli-input-json file://experiment-template.json \
  --region ap-northeast-1

# 実験開始
aws fis start-experiment \
  --experiment-template-id EXTxxxxxxxxxxxxxx \
  --region ap-northeast-1

# 実験の状態確認
aws fis get-experiment \
  --id EXPxxxxxxxxxxxxxx \
  --region ap-northeast-1

実験中は CloudWatch ダッシュボードをリアルタイムで監視します。EC2 が停止してから Auto Scaling が新しいインスタンスを起動するまでの時間、その間のエラー率の変化を記録します。これが「定常状態との乖離」の測定になります。

FISの料金体系（2026年7月時点）

FISの料金は実験で使用したアクション数に基づいて課金されます。

たとえば1回の実験で「EC2停止」「RDSフェイルオーバー」「ECSタスク停止」の3アクションを実行した場合、$0.30の課金です。月に10回の実験で30アクション使用すれば $3.00 程度です。

実務上のコスト感としては、ほとんどのチームで月額 $5 ～ $20 程度に収まります。停止条件を適切に設定しておけば意図しない大規模実験を防げるため、コストが青天井になるリスクは低いです。なお無料利用枠はありません。

応用・実務Tips

ゲームデイ（Game Day）形式で実施する
「ゲームデイ」は、チーム全員が集まって実際に障害を起こし、対応を演じる演習形式です。単なるシステムテストではなく、チームのコミュニケーション・意思決定スピード・手順書の精度を同時に鍛えられます。四半期に1回のペースで実施しているチームが増えています。

「爆発半径」を意識した段階的アプローチ
いきなり本番全体に障害を注入するのは危険です。以下の順序で段階的に進めます。

・フェーズ1 – 開発環境: FISの操作感・影響範囲を低リスクで確認する
・フェーズ2 – ステージング環境: 本番同等のトラフィックパターンで定量的に検証する
・フェーズ3 – 本番（一部）: タグで対象を全体の10～20%のリソースに限定して実施する

サーキットブレーカーの動作を FIS で検証する
マイクロサービスにサーキットブレーカーを実装している場合、FISで依存サービスの遅延を注入してサーキットブレーカーが正しく作動するかを確認できます。「実装したはずなのに本番で機能しなかった」という事態を事前につぶせます。サーキットブレーカーパターンの詳細はサーキットブレーカーパターン入門を参照してください。

SLOと連動した自動停止条件を設計する
実験の停止条件は、システムのSLO（サービスレベル目標）と連動させるのが理想です。たとえば「可用性SLOが99.9%を下回ったら即時停止」というアラームを CloudWatch で定義し、それをFISのStop Conditionに登録します。SLA・SLO・SLIの考え方についてはSLA・SLO・SLIの違いとは？で詳しく解説しています。

実験結果をドキュメントとして蓄積する
実験ごとに「仮説 → 実験手順 → 観測結果 → 改善アクション」をテンプレートで記録します。これがチームの耐障害設計のナレッジベースになり、次の設計判断に活きます。

よくあるトラブルと対処法

IAMロールのアクセス拒否エラーが出る
FISロールに、ターゲットリソースへの操作権限が不足しているケースが多いです。CloudTrail でエラーイベントを確認し、必要なアクション（例: `ec2:StopInstances`、`rds:FailoverDBCluster`）を IAM ポリシーに追加してください。

Stop Conditionが発動しないまま実験が続いた
CloudWatch アラームの評価期間や閾値の設定が甘い場合に起こります。設定を見直すとともに、実験開始前にアラームを手動で「アラーム状態」にして Stop Condition が実際に機能するかを事前確認することを強く推奨します。

実験対象に意図しないリソースが含まれてしまった
ターゲットのタグフィルター設定ミスで、想定外のリソースが対象になるケースがあります。実験テンプレート作成時に「ターゲットプレビュー」機能で対象リソースのリストを必ず確認してから実行してください。

EC2停止後にインスタンスが自動で起動しない
FISの「EC2停止」アクションはインスタンスを「stopped」状態にします。「stopped」後の再起動は Auto Scaling グループが担うため、Auto Scaling の最小キャパシティ設定とヘルスチェック設定を確認してください。

本記事のまとめ

カオスエンジニアリングと AWS FIS の要点を整理します。

オンプレ時代の「障害訓練」の発想を進化させたのがカオスエンジニアリングです。「障害が来たら対応する」から「障害を先に起こして対応力を鍛える」へ——この発想の転換が、クラウドネイティブな信頼性設計の第一歩です。まずはステージング環境でEC2停止実験を1本動かすことから始めてみてください。