AWS Fault Injection Service(FIS) でマルチアカウントの障害テストを実施してみた
はじめに
こんにちは。hisadonです。
今回は re:Inventで発表された AWS FaultInjectionService(FIS)のマルチアカウントでの障害テストを試してみた結果をご紹介したいと思います。
AWS Fault Injection Service の概要
AWS Fault Injection Service (FIS)は、Amazon Web Servicesが提供する障害注入サービスです。このサービスは、クラウド環境でのアプリケーションやシステムの耐障害性をテストし、強化することを目的としています。AWS FISを使用することで、開発者やシステム管理者は、実際のサービス運用中に発生しうる様々な故障シナリオを模擬的に発生させ、その影響を観察し、対応策を講じることができます。
メリットは以下になります。
- 障害テストのシミュレーション
AWS FISを使用すると、予め用意されたシナリオを用いてネットワーク遅延、サーバーのダウン、APIレート制限の超過、パーミッションの問題など、多種多様な障害テストを即時始めることができます - カオスエンジニアリングのサポート
カオスエンジニアリングの原則に基づき、本番環境に近い条件下でテストして確認していくことが可能です - 停止機能の提供
テストを行う際は、中止条件も設定可能です。想定外の事が起こった場合でも中止する事ができます - 障害テスト後の回復機能
テスト後にAWS環境が自動でテスト元の状態に戻ります
デメリットとしては、AWS FIS では、他のクラウドへの障害テストが実施できない部分があります。
アップデート内容
この機能により、1 回の FIS 実験を使用して、複数の AWS アカウントにまたがるアプリケーション上で実際の障害シナリオを設定および実行できます。複数のアカウントのリソースをターゲットとする実験を、一元的に設定、監視、レビューすることができます。
今回のアップデートにより、これまで利用アカウントでしか障害テストできませんでしたが、複数アカウントで実施できるようになったようです。
AWS FIS をマルチアカウントで試したアーキテクチャ図
アカウントAからアカウントBへ障害テストを実施します。
障害環境の準備
1.(アカウントB) 障害テストが実施されるアカウントBにてIAMポリシーを作成します。今回は、「EBS ボリュームの I/O オペレーションを停止」テストを想定しているので、以下を設定します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeVolumes"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:PauseVolumeIO"
],
"Resource": "arn:aws:ec2:ap-northeast-1:accountIdA:volume/*"
},
{
"Effect": "Allow",
"Action": [
"tag:GetResources"
],
"Resource": "*"
}
]
}
2.(アカウントB) 障害テストが実施されるアカウントBにてIAMロールを作成していき、カスタム信頼ポリシーを作成します。許可ポリシーには先ほど作成したIAMポリシーを付与します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": [
"arn:aws:iam::accountIdB:role/role_name"
]
}
]
}
3.(アカウントA) AWS FIS を動かすアカウントAにてにてIAMポリシーを作成します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"fis.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
4.(アカウントA) AWS FIS を動かすアカウントAにてIAMロールを作成していき、カスタム信頼ポリシーを作成します。許可ポリシーには先ほど作成したIAMポリシーを付与します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"fis.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
5.(アカウントB) EC2インスタンスを作成します。
Nitro System 上で稼働するEC2インスタンス以外だと実験する際にエラーとなります。
6.(アカウントA) AWS FIS を起動し、「実験テンプレートを作成」を選択します。次にアカウントターゲティングは「複数のアカウント」を選択し、画面遷移後、Descriptionに適当に説明を追加します。
7.(アカウントA) ターゲットを編集し、リソースARNにアカウントBのARNを記述します。
8.(アカウントA) ターゲットアカウントを設定していきます。ここでは手順2で作成していたアカウントBのIAMロールのARNを指定します。
9.(アカウントA) サービスアクセスを設定していきます。ここでは手順4で作成していたIAMロールのARNを指定し、末尾の「実験テンプレートを作成」を選択します。停止条件を設定するにはクロスアカウントでCloudWatchアラームを設定する必要があるようです。https://docs.aws.amazon.com/ja_jp/fis/latest/userguide/multi-account-prerequisites.html#alarms-and-monitoring
障害試験の実施
1.(アカウントB) EC2インスタンスを起動状態にします。
2.(アカウントA) 「実験を開始」を選択します。
3.(アカウントB) 障害が確認できたら成功になります。
まとめ
今回のアップデートにより、マルチアカウント構成での障害テストがしやすくなりました。
複数の障害パターンを1つのAWSアカウントに作成しておき、お客様環境に適用していくことも容易になったんじゃないかと思います。積極的に活用して障害に強い環境を構築していきましょう。