[アップデート] AWS FIS で新しいシナリオとアクションが追加され、より実際の大規模障害に近い障害シミュレーションが実施出来るようになりました #AWSreInvent

いわさです。

AWS re:Invent 2023 中のアップデートの中で AWS FIS （AWS Fault Injection Service）に関するアナウンスがありました。

アナウンスを読んで見ると AZ 障害とクロスリージョン通信の障害に関するシナリオが追加されたようです。

FIS のシナリオとは AWS により提供される事前構成済みの実験テンプレートのことで、シナリオライブラリを通してユーザーは利用することが可能です。

従来はワークロードの AZ 障害に対する回復力などを評価するには AWS FIS の既存のアクション範囲だと評価出来る部分と出来ない部分があったのですが、今回のアップデートで何が変わったのか紹介します。

シナリオが追加されている

冒頭お伝えしたとおり、シナリオライブラリに次の 2 つの新しいシナリオが追加されています。

シナリオ自体の中身は事前定義された実験テンプレートなので、従来に加えて新しいことが実現出来るようになるというものではありません。
便利になるというくらいの位置づけで、従来でもシナリオ内のことは独自で実現可能でした。

新しいアクションがたくさん追加されている

ただし、今回のアップデートのタイミングで実はいくつか新しいアクションが追加されています。
アクションというのは FIS で発生させる障害のことです。

今回新たに以下が追加されています。

アクション	内容
aws:ec2:asg-insufficient-instance-capacity-error	オートスケーリンググループからの新しいインスタンス作成要求に対して容量不足のエラー応答を発生させます。パラメータとしてエラー応答を返す AZ を指定する形となっており、このアクションを使うことで特定 AZ で EC2 が立ち上がらない状態を再現することが出来ます
aws:ec2:api-insufficient-instance-capacity-error	特定の IAM からのインスタンス立ち上げなどを上記と同様にエラーを発生させることが出来ます。例えば ASG 以外で、IAM ロールを使って自動起動を構成している場合に特定 AZ で立ち上げられない状況を再現することができます
aws:network:route-table-disrupt-cross-region-connectivity	特定のサブネットから別のリージョンを含む宛先へのトラフィックをブロックすることができます
aws:network:transit-gateway-disrupt-cross-region-connectivity	指定されたリージョンを宛先とする Transit Gateway のアタッチメントからのトラフィックをブロックします
aws:dynamodb:encrypted-global-table-pause-replication	DynamoDB グローバルテーブルのレプリケーションを一時停止します
aws:s3:bucket-pause-replication	ターゲットのソースバケットから宛先バケットへのレプリケーションを一時停止します
aws:elasticache:interrupt-cluster-az-power	ElastiCache Redis レプリケーショングループの指定されたアベイラビリティーゾーン内のノードを終了します

いくつかのアクションは副作用や注意点があるので利用にあたっては必ずドキュメントを事前に確認するようにしてください。

今回追加されたシナリオは、これらの新しいアクションと、既存のアクションを組み合わせたものとなっています。

AZ Availagility Power Interruption のアクション

Cross-Region Connectivity のアクション

ためしてみた

以前、FIS がネットワーク障害をサポートし始めたときに Auto Scaling Group で障害発生中に EC2 が特定 AZ に偏る現象を再現出来るかを検証しました。

その時は結果としては「出来ない」という検証結果となったのですが、今回のアップデートでこのあたりが出来る様になっている気がします。これを試してみましょう。

「AZ Availagility Power Interruption」から新しい実験テンプレートを作成します。
共有パラメータとして、障害を発生させる AZ と、起動制限を発生させる IAM ロールを指定します。

ターゲットパラメータについてはデフォルトでタグベースでの指定がされています。
タグの設定が可能であれば、障害を発生させるワークロードに対してタグを事前に設定しておきましょう。ここではタグ設定方法は割愛しますが、上記の Advanced parameters の targeting tags を確認すると、どのアクションでどのタグを使うのか確認・変更が可能です。

環境としては Auto Scaling Group を使って 4 台の EC2 インスタンスを 2 つの AZ に分散して起動している状態です。
実験を開始すると stop-instance アクションによって早速障害を発生させる対象として指定した EC2 インスタンスが停止されました。

その後、EC2 インスタンスが影響を受けていない AZ で 4 台稼働していることが確認出来ます。
ついに FIS で AZ の偏りを再現することが出来ました。素晴らしい。

Auto Scaling Group のアクティビティを確認してみると、ASG が起動しようとした時にエラーが検出されていることが確認出来ます。AZ 障害の時ってこういうエラーが発生するのか。

さいごに

本日は AWS FIS で新しいシナリオとアクションが追加され、より実際の大規模障害に近い障害シミュレーションが実施出来るようになったので、早速試してみました。

まだアップデートの伸びしろのあるサービスだと思っていますが、ユーザーが管理出来ない部分に触ることが出来るようなアクションが追加されているので、おもしろいと思います今回のアップデートは。
もっと追加されてほしいですね！

余談ですが、今回のタイミングでいつのまにか AWS Fault Injection Service に名前が変わっていることと、Resilience Hub の中の機能として取り込まれていることに気が付きました。
サービス名の変更は 1 ヶ月前に実施されているようです。