はじめに
PJにおいて、システムインフラを構築した後は、構築したインフラ基盤の動作確認を実施するケースが殆どかと思います。
基盤テストでは、単にアプリケーションの動作確認のみではなく、システムの運用を支える各種運用・監視・検知・セキュリティ等の様々な機能のテストを網羅的に実施する必要があります。
更に、基盤運用における運用テストの中では、上記機能を利用した運用上のプロセスや手順確認を実施する必要があります。
上記のような基盤テストや運用テストでは、以下のようなシーンが想定されます。
・システム障害を疑似的に起こして、監視や通知機能が正常に動作するかを確認したい。
・システム障害発生時の復旧手順やプロセスの確認のために疑似的に障害を起こしたい。
上記のようなシーンで使えるサービス、それが「AWS FIS（Fault Injection Simulator）」です。
FISとは？
FISとは、AWS環境において、特定の障害を疑似的に発生させることが出来るサービスです。
カオスエンジニアリングの原則に基づき、システムの耐障害性やパフォーマンスを向上させることを目的としています。AWS FIS を使用することで、障害条件をシミュレーションし、アプリケーションやシステムがどのように動作するかをテストできます。
カオスエンジニアリングは本番または本番前環境で意図的かつ制御的に障害を発生させ、その影響を分析し、システムの回復力や耐障害性を高める手法です
AWSとして検証済みの疑似障害として以下のようなシナリオを提供しています。
試しに、一番最初の「AZの可用性：電源の中断」を押下して、「シナリオを利用してテンプレートの作成」を押下してみます。
すると、「アクションとターゲットの指定」セクションにて、以下のような形で疑似障害の一連のプロセスにて発生させるアクションをマネージドに定義してくれます。
今回は、FISを利用して、検証用に作成したEC2サーバに疑似的にCPU負荷をかけてCloudWatchアラームを発火させてみます。
ハンズオン
事前準備
検証用のEC2の作成
検証用にEC2サーバを作成します。
最小インスタンスタイプで問題ありません。
以下に注意します。
- インターネットと疎通可能なVPC・サブネットに配置
FISでは裏側でSSM RunCommandを実行します。
そのため、SSMとEC2のSSMエージェントが通信出来るようにする必要があります。
今回はSSMエンドポイントを作成しないため、インターネット経由でSSMと通信します。
（今回は一時的な検証のため、デフォルトVPC内のサブネットに作成すればOKだと思います）
- インスタンスのIAMロールでSSMの権限を付与
SSM権限を付与します。マネージドポリシー（AmazonSSMManagedInstanceCore）で問題ありません。
CloudWatch Alermの作成
FISを利用して発火させるCloudWatch Alermを作成します。（今回のシナリオでは作成しなくても良いですが、実運用を想定してアラームを作成します）
実運用では、インスタンスに障害が発生後、CloudWatch Alermを発火させ、SNSトピックへの通知や障害の自動対応プロセスを開始させると思いますが、今回は後続のアクションは定義せず、アラート状態に遷移させるだけにします。
CPU利用率を3分おきに観測し、70％を超えた際に、アラートを発火させる設定にします。
FISの作成
シナリオライブラリより、「EC2ストレス：CPU」を選択して、「シナリオを使用してテンプレートを作成」を選択します。
説明と名前を入力します。（デフォルトで説明・名前が入力されているため、適宜編集します。）
「アクションとターゲットを指定」では、シナリオに応じて事前定義されたアクションが既に設定された状態で表示されます。
今回はEC2へのCPU負荷をかけるテストなので、CPU負荷を5分間かけるssm runcommandが3つ設定されています。
必要に応じて適宜アクションを選択して、パラメータを修正します。
ターゲットを選択し、今回CPU負荷をかけるEC2サーバーを選択します。
ターゲットでは、事前準備にて作成したEC2サーバーを選択します。
EC2を選択する際、何故かリソースIDでは表示されなかったため、リソースタグでNameにて指定しました。
ターゲットにて複数リソースを選択することで、特定のリソース群に対して、一括で疑似障害を発生させることも可能です。
（リージョン障害やAZ障害の疑似発生の際など）
FISが利用するIAMロールを指定します。
今回は「実験テンプレート用の新しいロールを作成する」を選択します。
その他設定を実施します。
停止条件として、CloudWatch Alermを使用して、一定のメトリクスに到達した際実験を停止することが出来ます。
今回は特に設定しません。
ログやレポートの出力先を適宜選択します。
最後に確認画面で確認し、問題なければ実験テンプレートを作成を押下します。
障害テストの実施
では、早速作成した実験テンプレートを利用して障害テストを実施してみましょう。
作成したテンプレートを選択し、「実験を開始」を押下します。
実験を開始すると、以下のように実験のステータスがInisiate→Runningに変化します。
アクションの概要から設定しているアクションを確認することが可能で、ステータスにポイントすると実行中のSSM RunCommandに遷移することが出来ます。
SSM RunCommandのコンソールからも実行状況が確認出来ます。
暫く待機の後、CloudWatch Alermも確認してみましょう。
CPU負荷がかかって80％を超えているため、アラーム状態になっていることが分かると思います。
全てのアクションが正常に終了すると、実験のステータスが「Completed」に遷移します。
レポートを見てみましょう。
実施した実験の日時・アクション・ターゲット等の詳細がPDFでダウンロード可能となっています。
まとめ
今回はFISを触ってみました。
こういったサービスがあることを知っているだけでも、基盤テストや運用テストをかなり効率的に進めることが出来る印象です。
AWSで事前検証・定義済みのシナリオを利用するという点でもシナリオの妥当性に安心感があるかと思います。
今後機会があったら積極的に利用していこうと思います。