awsで疑似障害を実践！FIS活用の具体手法解説

2025 11/29

2025/11/29

はじめに

本書は、AWS環境で実際の障害を模した疑似障害テストの方法を丁寧に解説します。中心となるのはAWS Fault Injection Service（FIS）を用いた耐障害性の検証です。実運用に近い条件で問題を発見し、改善につなげることを目的としています。

本書の目的

FISの基本を理解し、安全に実験を実施できるようにする
EC2のStatusCheckFailedに対する対応手順を明確にする
実験テンプレート、アラート、複数シナリオ、NACLを使ったサブネット障害まで実践的に示す

想定読者と前提条件

AWSの基礎知識（EC2、VPC、CloudWatch）がある方
実験はテスト環境または影響範囲を管理できる環境で行う想定です

注意点と安全対策

本番での実行は慎重に行ってください。必ずバックアップやロールバック手順を準備してください。
アクセス権限や実行時間を限定し、影響範囲を事前に確認してください。

本書の構成

第2章以降でFISの概念、EC2の状態異常、テンプレート作成、アラート設定、複数シナリオ、仮説検証、NACLによるサブネット障害を順に解説します。各章で実例と手順を示し、最後に改善サイクルへつなげます。

AWS Fault Injection Service（FIS）の基本概念と目的

概要

AWS Fault Injection Service（FIS）は、本番のサービスを直接壊すことなく、障害を疑似的に発生させて耐障害性を確認するサービスです。たとえばEC2インスタンスの停止やRDSの再起動を短時間だけ行い、システムの挙動や監視の動作を観察します。担当者の手順確認や運用アラートの検証にも使えます。

目的

主な目的は次のとおりです。
– 障害時のシステム挙動を事前に把握する
– 監視や通知（例：SNS経由のアラート）が正しく機能するか検証する
– 運用手順やオンコール対応の訓練を実施する

期待できる効果

具体的には、障害発生時の復旧時間短縮、誤検知の削減、手順書の改善が期待できます。たとえば停止したEC2が自動で置き換わるか、ロードバランサーがトラフィックを別インスタンスへ振り分けるかを確認できます。

実施時の注意点

テスト範囲を明確にして影響範囲を限定すること
スナップショットやバックアップを用意しておくこと
関係者へ事前周知しロールバック手順を確立すること

具体例（短い）

開発環境でEC2の停止を試す
SNS通知が来るかを確認する
手順書に基づき復旧を実施し所要時間を計測する

これらを通じて、実際の障害発生時でも落ち着いて対応できる体制を作ります。

EC2のStatusCheckFailedの種類と疑似障害対応

概要

EC2のStatusCheckFailedには主に3種類の項目があります。原因と特性が異なるため、障害試験での扱い方も変わります。ここでは種類ごとの説明と、疑似的にアラートを発生させる方法を具体例とともに説明します。

1. StatusCheckFailed_System

AWS側のハードウェアやネットワーク問題を示します。これはホスト層の問題なので、ユーザー側で安全に疑似障害を発生させる手段がありません。実験ではこの項目の挙動を観察対象とし、影響を受けたときの復旧手順やDR設計を検証します。

2. StatusCheckFailed_Instance

インスタンスのOSやドライバの障害を示します。NICを一時的に無効化する（例：eth0をdownにする）ことで疑似的にアラートを発生させられます。具体的にはSSHで接続し、ネットワークを切るコマンドを実行して観測します。アプリケーションレベルのタイムアウトや再接続挙動も確認しましょう。

3. StatusCheckFailed_AttachedEBS

EBSボリュームのI/O問題を示します。EBSのI/Oを一時停止することで疑似障害を作れます。例えば、FISでボリュームのI/Oを制限する実験や、インスタンス内でsyncやブロック操作を行って遅延を発生させる方法があります。データ整合性に注意して実施してください。

Nitroベースのインスタンスの特性

NitroベースはFISなどによる擬似検出が比較的可能です。ホスト機能が分離されているため、特定の操作でStatusCheckFailed_InstanceやAttachedEBSを再現しやすくなります。実験前にインスタンスタイプの挙動を把握しておきましょう。

実施上の注意と推奨

本番環境での試験はリスクが高いので、まずステージングで実施してください。
障害試験ではログとメトリクスを同時に収集し、復旧手順を検証します。
EBSやネットワーク操作はデータ損失の可能性があるため、バックアップを取ってから行ってください。

FISを使用した実験テンプレートの構築

概要

FISで疑似障害を実施するには、実験テンプレートを作成します。テンプレートは説明・名前、実験タイプ、実行するアクション、対象リソース、実行権限をまとめた設計図です。

準備

実験を行うアカウントとリージョンを確認します。
対象リソースはタグやIDで明確に分けます。ステージング環境で先に試してください。

実装手順（主要3ステップ）

実験テンプレートの作成
名前と説明を入力し、実験タイプは「このAWSアカウント」を選びます。分かりやすい名前と目的を記載してください。
アクションの指定
例：EBSのI/Oを止める場合は “aws:ebs:pause-volume-io” を指定し、duration を3600（秒）などで設定します。アクションごとにパラメータを正しく与えてください。
ターゲットリソースの指定
リソースはタグ、インスタンスID、リソースタイプで指定します。曖昧な指定は避け、安全のため少数のインスタンスに限定します。

権限とロール

FISが操作するためのIAMロールを用意します。ロールには実行するアクションに必要な権限（例：EBS操作、EC2操作）と、FISがそのロールを引き受けるための信頼ポリシーを設定します。

安全対策とテスト

まずステージングで短時間（例：60秒）で実行して挙動を確認します。十分に確認できたら本番向けに時間や範囲を調整します。
CloudWatchアラームや自動復旧設定に影響が出る場合があるため、事前に連携を確認してください。

運用上の注意点

実験は必ず計画と通知を行ってから実施してください。
テンプレートはバージョン管理し、変更履歴を残します。

アラート設定とSNS通知の構成

概要

疑似障害テストで確実に通知を受け取るため、アラートとSNSを正しく構成します。ここでは集約間隔（period）を5分に設定し、メトリクスの平均(Average)が0.99以下になったときにアラートを上げる手順を説明します。

CloudWatchアラームの設定手順

対象メトリクスを選択します（例：アプリのエラーレートやカスタムメトリクス）。
集約間隔（Period）を300秒（5分）に設定します。
統計は「Average」を選びます。
条件は「Average <= 0.99」に設定してアラームを発生させます。
必要に応じて評価期間（Evaluation Periods）を1〜3回にして誤検知を減らします。

SNSトピックとサブスクリプション

SNSでトピックを作成します（例：fis-alerts）。
トピックにサブスクリプションを追加し、ProtocolにEmail、Endpointに自分のメールアドレスを指定します。
送られてくる確認メールのリンクをクリックしてサブスクリプションを確定します。
CloudWatchアラームの通知先に作成したSNSトピックを指定します。

動作確認の流れ

FISで疑似障害を実行します。
メトリクスが悪化してAverageが0.99以下になれば、CloudWatchがALARM状態になります。
SNSが通知を配信し、登録メールに着信があることを確認します。

注意点

通知が届かない場合、SNSの配信ログやメールの迷惑メールフォルダを確認してください。
アクセス権限として、CloudWatchとSNSに対するPut/Publish/Subscribe権限が必要です。
テスト後は不要なアラームやサブスクリプションを削除しておくとコストと通知の混乱を防げます。

複数の障害シナリオテスト

概要

AWS FISは単一障害だけでなく、複数の障害を組み合わせて試験できます。本章では、代表的な2つのシナリオと実行時の注意点を丁寧に説明します。

シナリオ①：ECSタスク1台停止（単一サーバ障害）

目的：1台のタスク停止でサービスが継続することを確認します。手順は、FISテンプレートで対象をECSタスク（タグで絞る）にし、タスク停止アクションを1回実行します。期待値は別AZのタスクが補完して稼働し続けることです。検証はELBのヘルス、レスポンスタイム、タスク数で行います。

シナリオ②：AZ障害（特定サブネットの通信遮断）

目的：特定AZ（例：az-c）の通信を遮断してマルチAZ冗長性を検証します。FISアクションにaws:network:disrupt-connectivityを使い、対象はECS用サブネット（az-c）に設定、実行時間は5分（300秒）にします。実行前に対象リソースをタグで限定し、停止条件（CloudWatchアラーム）を設定してください。

実行上の注意点

まずステージングで短時間から実行し、本番は夜間や影響範囲が小さい時間帯に行います。
モニタリングはCloudWatchとSNS通知で即時確認します。自動停止ルールを必ず入れてください。
複合試験（タスク停止＋ネット遮断）は順番や同時実行で影響が大きくなるため、段階的に行います。

検証ポイント

タスクの再配置・自動復旧
レイテンシ、エラー率、スループットの変化
データ整合性やセッション継続性

以上を守れば、安全に複数障害シナリオの検証が行えます。

障害試験の仮説検証と改善サイクル

1. 仮説の立て方

試験前に「障害発生時に期待するシステムの振る舞い」を具体化します。例：RDSのフェイルオーバー時、アプリは5秒以内に再接続される、あるいはECSタスク停止でALBはトラフィックを別タスクへ即座に流す、などです。

2. 試験実施と観察項目

FIS等でシナリオを実行し、以下を確認します。ログ（接続エラー、タイムアウト）、監視指標（CPU、レスポンスタイム、HTTP5xx）、ユーザ側の可用性（エラーレート、遅延）。DBフェイルオーバー中の接続切断回数や、ECSのタスク再起動時間を特に見ます。

3. 仮説と結果の差異分析

観察結果を仮説と照合します。期待どおりでなければ原因を切り分けます（例：接続プールの設定、ヘルスチェック閾値、DNS TTLが長い等）。小さな差異も見逃さず記録します。

4. 改善案の検討と実装

原因ごとに対策を優先付けします。設定変更（接続タイムアウト短縮、ヘルスチェックの頻度調整）、アーキテクチャ改善（コネクションリトライ実装、冗長構成の追加）や運用面（Runbook更新、オンコール訓練）を組み合わせます。

5. 再試行と学習のループ

改善後に同じシナリオを再実行し効果を確認します。このサイクルを定期的に回すことで確実に耐障害性を高めます。小さな実験を積み重ねることが重要です。

NACLを利用したサブネット障害の実装

概要

AWS FISでNACL（ネットワークACL）を利用すると、サブネット単位で通信を遮断できます。ただし、サブネット内や同一AZ内の通信は残る場合があり、ALBのヘルスチェックが通ってターゲットが“生きている”と判断されることがあります。動作特性を理解して試験を設計してください。

実装手順（簡潔）

対象サブネットのCIDRと用途を確認します（ECSタスク、ALB、NAT等）。
新しいNACLを作成し、全トラフィックを拒否するルール（例: 0.0.0.0/0をDENY）を追加します。NACLはステートレスなので、入出力両方のルールが必要です。
NACLを対象サブネットに関連付けて通信を遮断します。FISを使う場合は、NACLの差し替えを自動化するアクションを用意します。