FISでEC2のStatusCheckFailedを疑似発生させてみた

はじめに

こんにちは。コンサルティング部の津谷です。
皆さんは、CloudWatchを使ってアラート作成はやっておりますでしょうか。
本番環境システムで何かアラートが発生した場合に、SNS経由で本当に通知されるかを事前にテストしておくと安心ですね。疑似障害を発生させることで、環境を再現して挙動をテストすることがAWSサービスでできるのです。今回はAWS FIS（Fault Injection Simulator Service）という耐障害性テストツールを利用してみたいと思います。FISの情報に関してはこちらをご参照ください。

StatusCheckFailedでアラートを上げたい

StatusCheckFailedで疑似アラートを挙げられるの？という疑問が業務中に発生しました。メトリクスへの理解がAWS側の基盤障害や、OS等のインスタンス内障害といったものだったのでテストなんかできるのかと、気になったので調査しました。

公式ドキュメントにサポートアクションが記載されています。まずは内容を確認してみましょう。
https://docs.aws.amazon.com/ja_jp/fis/latest/userguide/fis-actions-reference.html#ec2-actions-reference

StatusCheckFailedには３種類のステータス項目があります。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html
それぞれの項目ごとに確認してみました。

• StatusCheckFailed_System
  AWS側のハードウェア障害なので、疑似的に問題発生させる手段がありません。

• StatusCheckFailed_Instance
  こちらは実施する手段があります。インスタンスのOS内のステータスを確認する項目で、NICにARPプロトコルでアドレス解決を実行してヘルス状態を見ています。そのため、NICを一時的に無効化することで疑似アラートを発生させることが可能です。
  復旧は、再起動することでネットワーク設定が初期化され、NICも自動で有効化できます。

• StatusCheckFailed_AttachedEBS
  こちらもアタッチしているボリュームを停止させ、アラームを発生させることができます。
  こちらはインスタンスがEBSボリュームに到達可能か、I/O操作を完了できるかを確認する項目です。
  FISでI/Oを一時停止できるテンプレートアクションが用意されているので、フォールトを挿入することで実施可能です。ただしこの時に使っているメトリクスはNitroベースのインスタンスしかサポートしていないので条件付きになります。Nitroベースのインスタンスは以下のインスタンスタイプが対象になります。
  https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/instance-types.html

まとめると、NitroベースのインスタンスはFISで疑似的にアラートを発生させられるということですね。Nitroベース対応でないインスタンスはNICの一時無効化とかで対応するしかないですね。

検証してみた

NitroベースのEC2を作成してみます。

インスタンス名は「test-nitro」、AMIは「Amazon Linux 2023 kernel-6.1 AMI」、インスタンスタイプは「t3.nano」を選択しました。t2はNitro対応していないので注意です。

ステータスチェックタブを確認すると、「アタッチ済みのEBSステータスチェック」の項目がありました。

FISで疑似障害を発生させた後で、StatusCheckFailedをアラート状態にし、SNSでメール通知したいと思います。
アラートを作成します。集約間隔を5分にしており、エラー閾値の平均が0.99<=の状態でアラート発生させます。

通知先はSNSトピックを指定し、サブスクリプションは自分のメールアドレス宛にしておきます。

次にFISの設定をしていきます。
実験テンプレートを作成していきましょう。
説明は「StatusCheckFailed_AttachedEBSを疑似的に発生させる」とし、
名前は「test」にしています。
実験タイプは「このAWSアカウント」を指定します。

次にアクションとターゲットを指定します。
アクションは実際にどういう疑似障害を起こすかを設定します。

アクションタイプは「aws:ebs:pause-volime-io」を選択します。
このアクションはターゲットEBSボリュームのI/Oオペレーションを1時停止します。
名前は「test-stop-volume-io」とします。Durationはアクションの継続時間のことですが「5分間」とします。
ISO 8601 形式の文字列なので、PT5Mという表記になるようです。

アクションのターゲットも指定します。

名前は「test-target」にします。
ターゲットは「リソースID」を指定します。
今回は、「test-nitro」インスタンスに付与しているルートボリュームのI/Oを一時停止させようと思います。

サービスへのアクセスは自動で作成されるサービスロールを使うことにします。

停止条件ですが、「test-nitro」に設定したステータスチェックのアラートが発砲したら停止するものとします。
一応、5分間のフォールトインジェクションが終わるか、コンソール上から「実験を停止」を押下することもできます。

動作確認

実験テンプレートを作成したら、「実験を開始」を押下します。

開始すると、アクションの立ちあがりが「Running」で、テストが完了すると「Completed」になりました。

EC2のステータスチェックをしてみます。
メトリクスの統計は5分間隔の平均なのでアラートまで上がりきりませんでした。
なので、15分で再実行してみました。テンプレートは複製してそのまま使えるので、便利です。

15分まってみるとどうやらアラート発砲してそうです。

メールを確認すると届いていました。

さいごに

FISは初めて使ってみたのですが、想定シナリオからテンプレートを作ると、複数のアクションの組み合わせが自動で作成され自分でカスタマイズできます。作りこみをすれば限りなく本番環境の障害再現に近くなりますね。障害テストとして、使っていきたいツールだと思いました。
皆さんもぜひ使ってみてください。