カオスエンジニアリング実践 - AWS Fault Injection Simulator で耐障害性を検証する

カオスエンジニアリングの必要性と FIS の役割

本番環境の障害は予測不能なタイミングで発生します。EC2 インスタンスの突然の停止、AZ の障害、ネットワークの遅延増大、データベースのフェイルオーバーなど、これらの障害に対してシステムが正しく動作するかを事前に検証するのがカオスエンジニアリングです。Netflix が開発した Chaos Monkey に端を発するこの手法は、意図的に障害を注入してシステムの耐障害性を検証します。AWS Fault Injection Simulator (FIS) は 2021 年にリリースされたマネージドのカオスエンジニアリングサービスで、AWS リソースに対する障害注入を安全かつ制御された方法で実行します。自前でカオスエンジニアリングツールを構築・運用する必要がなく、AWS サービスとのネイティブ統合により、EC2・ECS・EKS・RDS・ElastiCache・Systems Manager など幅広いリソースに障害を注入できます。

この分野について体系的に学びたい方は、関連書籍 (Amazon) も参考になります。

実験テンプレートの設計

FIS の実験は実験テンプレートで定義します。テンプレートはアクション (何をするか)、ターゲット (どのリソースに対して)、停止条件 (いつ中止するか) の 3 要素で構成されます。アクションの例として、aws:ec2:stop-instances (EC2 の停止)、aws:ec2:send-spot-instance-interruptions (スポット中断のシミュレーション)、aws:ssm:send-command (SSM 経由の CPU/メモリストレス)、aws:ecs:stop-task (ECS タスクの停止)、aws:rds:failover-db-cluster (Aurora のフェイルオーバー)、aws:fis:inject-api-internal-error (AWS API のエラー注入) があります。 ```json { "description": "EC2 インスタンス停止実験", "targets": { "ec2Instances": { "resourceType": "aws:ec2:instance", "resourceTags": {"Environment": "dev"}, "selectionMode": "COUNT(1)" } }, "actions": { "stopInstances": { "actionId": "aws:ec2:stop-instances", "parameters": {"startInstancesAfterDuration": "PT5M"}, "targets": {"Instances": "ec2Instances"} } }, "stopConditions": [ {"source": "aws:cloudwatch:alarm", "value": "arn:aws:cloudwatch:ap-northeast-1:123:alarm:high-error-rate"} ], "roleArn": "arn:aws:iam::123:role/FISExperimentRole" } ``` ターゲットの selectionMode で対象リソースの選択方法を制御します。COUNT(1) は 1 つだけ、PERCENT(50) は 50% のリソースを対象にします。タグベースのフィルタリングで実験対象を限定できます。

安全な実験の進め方

カオスエンジニアリングで最も重要なのは安全性の確保です。FIS は複数の安全機構を提供します。停止条件 (Stop Conditions) は CloudWatch アラームを監視し、エラー率やレイテンシが閾値を超えた場合に実験を自動停止します。これにより、実験が本番サービスに過度な影響を与えることを防ぎます。IAM ロールで実験の権限を最小限に制限し、実験対象外のリソースへの影響を防止します。実験の段階的な拡大も重要なプラクティスです。まず dev 環境で小規模な実験 (1 インスタンスの停止) から始め、結果を検証してから対象を拡大します。次に stg 環境で本番に近い条件で実験し、最終的に本番環境で限定的な実験を実施します。実験前に仮説を立てること (「1 台の EC2 が停止しても ALB が自動的にトラフィックを振り分け、エラー率は 1% 以下に収まるはず」) も重要で、仮説が外れた場合はシステムの改善ポイントが明確になります。

実践的な実験シナリオ

代表的な実験シナリオを紹介します。AZ 障害のシミュレーションでは、特定の AZ 内の EC2 インスタンスを一斉に停止し、マルチ AZ 構成の Auto Scaling が正しく動作するかを検証します。ネットワーク遅延の注入では、SSM 経由で tc (traffic control) コマンドを実行し、特定のインスタンスのネットワークレイテンシを増加させます。マイクロサービス間の通信がタイムアウトやリトライで正しく処理されるかを確認できます。RDS フェイルオーバーでは、Aurora クラスターのフェイルオーバーを実行し、アプリケーションが新しいライターエンドポイントに自動的に接続し直すかを検証します。スポットインスタンスの中断シミュレーションでは、2 分前の中断通知を模擬し、アプリケーションのグレースフルシャットダウンが正しく動作するかを確認します。料金は実験のアクション実行時間 1 分あたり 0.10 USD で、5 分間の実験であれば 0.50 USD です。

さらに詳しく知りたい方は、関連書籍 (Amazon) で理解を深められます。

まとめ - FIS の活用指針

AWS Fault Injection Simulator は、カオスエンジニアリングをマネージドサービスとして提供し、システムの耐障害性を安全に検証するためのツールです。停止条件による自動停止、IAM による権限制限、段階的な実験拡大により、安全にカオスエンジニアリングを実践できます。まず dev 環境で EC2 の停止やネットワーク遅延の注入から始め、システムの弱点を発見・改善するサイクルを回すことを推奨します。障害は必ず起きるという前提に立ち、事前に検証しておくことで、本番障害時の影響を最小限に抑えられます。