【AWSサービス基礎編】　 AWS Fault Injection Service で障害注入実験を実施する

概要

AWS Fault Injection Service（FIS）は、AWS 上のワークロードに対して制御された障害を注入し、システムの回復力をテストするためのマネージドサービスです。カオスエンジニアリングの手法を AWS 環境で手軽に実践できます。

本番環境で障害が発生した際にシステムが適切に回復できるかは、実際に障害を起こしてみなければわかりません。FIS を使うことで、EC2 インスタンスの停止、ネットワーク遅延の発生、API エラーの注入といった障害シナリオを安全に実行し、システムの弱点を事前に特定できます。

本記事では、FIS の実験テンプレートを作成し、EC2 インスタンスに対する障害注入実験を体験します。

この記事のメリット

AWS Fault Injection Service の基本概念とカオスエンジニアリングの考え方を理解できる
実験テンプレートの構成要素（アクション、ターゲット、停止条件）を把握できる
マネジメントコンソールから実験テンプレートを作成する手順を習得できる
EC2 インスタンスの停止という障害シナリオを実際に実行・確認できる
停止条件を使った安全な実験の管理方法を体験できる

キャラクター紹介

クラウド資格実践ラボの基礎学習記事では、ルクシーちゃんと代表の土肥が対話形式で AWS 認定試験で必要な知識をハンズオンとともに解説していくブログです。これからこのブログを案内する2人を紹介します。

ルクシーちゃん

クラウド資格に挑戦中の好奇心旺盛なナビゲーター。初学者目線で「これってなんだろう？」と素朴な疑問を投げかけ、知識を引き出していく役どころ。難しい内容も、ルクシーちゃんと一緒なら一歩ずつ理解できると思います！

土肥（とひ）

株式会社Luxyの代表であり同社の元エンジニア。これまでオンプレとAWS環境のインフラを担当。AWS認定資格の学習で得た知識をハンズオンとともに解説するのが得意。直近では新人の教育なども行っており、これから技術を学ぼうという方が納得できるように解説できることに喜びを感じているとのこと。

技術解説

カオスエンジニアリングとは

Luxyちゃん

とひさん、「カオスエンジニアリング」って名前からして怖いんですけど、一体どういうものなんですか？

土肥

名前はちょっと物騒だけど、やってることはすごく理にかなってるんだ。本番環境に近い条件で、わざと障害を起こしてシステムの回復力を確かめる手法だよ。

Luxyちゃん

わざと障害を起こすんですか…？それって大丈夫なんですか？

土肥

むしろ、本番で突然障害が起きて慌てるよりも、事前にテストしておいた方が安全だよね。具体的には、こういうステップで進めるんだ。

定常状態の仮説を立てる（例: インスタンスが1台停止してもサービスは継続する）
障害を注入して仮説を検証する
結果を分析し、システムを改善する

Luxyちゃん

なるほど、「たぶん大丈夫」を「実際に確認した」に変えるための手法なんですね！

土肥

そのとおり。障害が発生しても正常に動作し続けるシステムを作るためには、実際に試してみるのが一番確実なんだ。

AWS Fault Injection Service とは

Luxyちゃん

カオスエンジニアリングの考え方はわかりました。それを AWS でやるためのサービスが FIS ということですか？

土肥

そうだよ。AWS FIS はカオスエンジニアリングを AWS 環境で手軽に実践できるマネージドサービスなんだ。事前に「実験テンプレート」を定義しておいて、それに基づいて障害を注入して影響を観察する仕組みだよ。

Luxyちゃん

どんな障害を起こせるんですか？

土肥

かなり幅広いよ。対応する主な障害シナリオをまとめるとこんな感じだね。

カテゴリ	障害シナリオの例
EC2	インスタンスの停止、再起動、API エラーの注入
ECS	タスクの停止
EKS	Pod の削除、ノードグループのインスタンス終了
RDS	フェイルオーバーの強制実行、インスタンスの再起動
ネットワーク	ネットワーク遅延・パケットロスの注入
Systems Manager	CPU ストレス、メモリストレスの発生

Luxyちゃん

EC2 だけじゃなくて、ECS や RDS、ネットワークまでカバーしてるんですね！

土肥

そうなんだ。AWS の主要なサービスに対して障害を注入できるから、いろんなパターンの耐障害性テストができるよ。

実験テンプレートの構成要素

Luxyちゃん

さっき出てきた「実験テンプレート」って、具体的にはどういう構成になっているんですか？

土肥

実験テンプレートは3つの要素で構成されるんだ。「アクション」「ターゲット」「停止条件」の3つだよ。

要素	説明
アクション	実行する障害の種類と設定（例: EC2 インスタンスの停止、持続時間）
ターゲット	障害を注入する対象リソース（タグやリソースIDで指定）
停止条件	実験を自動停止する条件（CloudWatch アラームなど）

Luxyちゃん

「何をするか」「どこにするか」「いつ止めるか」の3つをセットで定義するわけですね！

土肥

いい整理だね。この3つを組み合わせることで、安全に制御された障害実験ができるんだ。それぞれもう少し詳しく見ていこう。

アクション

Luxyちゃん

まず「アクション」について教えてください。

土肥

アクションは実験で実行する具体的な障害注入操作のことだよ。FIS にはあらかじめたくさんのアクションが用意されていて、すぐに使えるんだ。代表的なものを挙げるとこんな感じだね。

aws:ec2:stop-instances — EC2 インスタンスを停止する
aws:ec2:reboot-instances — EC2 インスタンスを再起動する
aws:ec2:send-spot-instance-interruptions — スポットインスタンスの中断通知を送信する
aws:rds:failover-db-cluster — RDS クラスターのフェイルオーバーを実行する

Luxyちゃん

aws:サービス名:操作 っていう命名規則になっているんですね。わかりやすいです！

土肥

そうそう。名前を見れば何をするアクションかすぐわかるようになっているよ。

ターゲット

Luxyちゃん

次に「ターゲット」ですが、障害を注入する対象はどうやって決めるんですか？

土肥

ターゲットの指定方法は2種類あるんだ。

タグによる指定: 特定のタグを持つリソースを対象にする（例: Environment=test）
リソースIDによる指定: 特定のインスタンスIDを直接指定する

Luxyちゃん

タグで指定すると、複数のリソースがまとめて対象になったりしますか？

土肥

なるよ。しかもタグベースで指定する場合、対象リソースの中からランダムにN個を選択する設定も可能なんだ。例えば「このタグが付いたインスタンス10台のうち、ランダムに3台だけ停止する」みたいなこともできるよ。

Luxyちゃん

より実際の障害に近い状況を再現できるわけですね！

停止条件

Luxyちゃん

障害を注入するのはわかりましたが、実験が暴走して本当にシステムが壊れたらどうするんですか？

土肥

いい質問だね。そのための「停止条件」だよ。これは実験中にシステムへの影響が想定を超えた場合に、実験を自動停止するための安全装置なんだ。

Luxyちゃん

具体的にはどうやって止めるんですか？

土肥

CloudWatch アラームを指定しておいて、アラーム状態になったら実験を自動的に中止する仕組みだよ。例えば「エラー率が5%を超えたら即停止」みたいな条件を設定できるんだ。

Luxyちゃん

ちゃんと安全弁があるんですね。これなら安心して実験できそうです！

土肥

そうだね。カオスエンジニアリングは「制御された実験」であることが大事で、停止条件はその制御の要なんだ。

実践

前提条件

リージョン: ap-northeast-1（東京）
障害注入対象の EC2 インスタンスが1台起動済みであること
対象インスタンスにタグ FISTarget = true が設定されていること

リソース種別	リソース名	用途
FIS 実験テンプレート	`stop-ec2-experiment`	EC2 インスタンス停止の実験定義
IAM ロール	`FISExperimentRole`	FIS がリソースを操作するための権限