こんにちは。
2021/3/16に公開になった、AWS Fault Injection Simulator(AWS FIS) を早速使ってみました。
本日時点では、大阪リージョン、中国の2つの地域を除く、商業 AWS リージョンすべてでの利用が可能とのことです。日本では東京リージョン(ap-northeast-1)で利用できます。
マニュアルはこちらです。
https://docs.aws.amazon.com/fis/latest/userguide/what-is.html
このサービスは、疑似障害や疑似攻撃を稼働中のシステムに与えた際に、どれだけ耐えられるのか、回復力をどれだけ有しているのかを確認する手法「カオスエンジニアリング」が行えるものです。
これまでは、 Chaos Monkey などの OSS ツールや、 Gremlinといった サービスを利用しないとなりませんでした。
ということで、早速試してみました。
始め方
この記事執筆時点では、マネージメントコンソールの検索フォームからはヒットしなかったので、東京リージョンであれば以下のURLからアクセスします。
https://ap-northeast-1.console.aws.amazon.com/fis/home?region=ap-northeast-1
※元ネタはこちら：https://aws.amazon.com/jp/fis/ の「Get started with Fault Injection Simulator」のボタン
略称である、「FIS」で検索するとでてくると教えていただきました！
@hayao_k さん、ありがとうございます！
作業の流れ
以下の流れで AWS 上で稼働しているシステムに対して「実験」という名のシミュレーションを実施します。
- 実験テンプレートの作成
- 実験(の実施)
実験テンプレートでは、どういったトラブルをどの対象に対して実験するのかといった定義を行います。
そして、実際に実験を行い、回復能力を確認するという流れです。
実験テンプレートの作成
AWS FIS のコンソールにアクセスしたら、以下のボタンをクリックして、実験テンプレートの作成に進みます。
まず、この実験の「説明」とIAMロールの設定をします。
IAM ロールは信頼されたエンティティでIDプロバイダーとして「fis.amazonaws.com」を設定するのをお忘れなく！
次に、アクションのエリアでアクション(どんなトラブルなのか)を設定します。
まずは、[アクションの追加]ボタンをクリックします。
アクションの名前、説明、アクションタイプ、複数アクションを定義した場合の順序として「次のあと開始」を設定します。
アクションタイプとしては、現時点では以下が用意されています。
- EC2 インスタンスの再起動(aws:ec2:reboot-instances)
- EC2 インスタンスの停止(aws:ec2:stop-instances)
- EC2 インスタンスの終了(削除)(aws:ec2:terminate-instances)
- ECS のコンテナインスタンスのドレイニング(aws:ecs:daion-container-instances)
- EKS のノードグループインスタンスの削除(aws:eks:terminate-nodegroup-instances)
- AWS サービスの応答をエラーにする(aws:fis:injection-api-internal-error)
- AWS サービスの応答をスロットルエラーにする(aws:fis:injection-api-throttle-error)
- AWS サービスの応答を利用不可エラーにする(aws:fis:injection-api-unavailable-error)
- 実験にWaitを入れる(aws:fis:wait)
- RDS の DB クラスターをフェールオーバーする(aws:rds:failover-db-cluster)
- RDS の DB インスタンスを再起動する(aws:rds-reboot-db-instances)
- SSM ドキュメントを実行する(コマンドを実行する)(aws:ssm:send-command)
- EC2 インスタンスに対して CPU 負荷を与える(aws:ssm:send-command/AWSFIS-Run-CPU-Stress)
- EC2 インスタンス内のプロセスを Kill する(aws:ssm:send-command/AWSFIS-Run-Kill-Process)
- EC2 インスタンスに対してメモリ負荷を与える(aws:ssm:send-command/AWSFIS-Run-Memory-Stress)
- EC2 インスタンスに対してネットワーク負荷を与える(aws:ssm:send-command/AWSFIS-Run-Network-Latency)
今回は、EC2 インスタンスの停止で試してみます。忘れずに右上の「保存」ボタンをクリックします。
選択したアクションタイプに応じて、「アクションパラメータ」も指定できるので確認、設定します。
今回は特に指定なしとします。
EC2 インスタンスに対するアクションを選択したので、ターゲットとして、「Instances-Target-1(aws:ec2:instance)」が設定されています。
「編集」ボタンをクリックして、「実験」対象にするインスタンスを定義します。
リソースID(EC2インスタンスであれば、インスタンスID)を指定するか、各リソースに設定しているタグベースに実験を起こす場合は、「リソースタグとフィルター」を選択し、対象とするタグを指定します。
まずは、リソースIDです。プルダウンをクリックすると、以下の様にリソースタイプに応じたリソースIDが列挙されるので選択します。
リソースタグとフィルターの場合は以下の様に、対象とするタグの内容とさらにヒットした中で対象とする属性パスの内容を指定します。
この例では、Env タグとタグの値として Stg があるものを指定フィルター対象に指定います。
ただ、この設定方法では、Env タグに Stg が指定されてなくても、Envではないタグの値に Stg が指定されていると想定外の動作をすることが予想されるので、タグの設定について仕様を固めるとよいでしょう。
フィルターの使い方については、ここを参照ください。：
https://docs.aws.amazon.com/ja_jp/fis/latest/userguide/targets.html#target-filters
現状は、AWS CLI などで情報を取得してどの情報を基にフィルタリングするかを指定します。
設定したら、「保存」ボタンをクリックします。
停止条件も必要に応じて設定します。この停止条件は、Cloudwatch アラームがトリガーされた場合に実験を停止するといったものです。
例えば本番環境への実験を行うが、サービス提供に支障が出るレベルになったら実験を強制停止するといったことができます。
最後にタグを指定します。
現時点では、この実験の名称を付けるエリアがないので、ここで、Nameタグを設定します。
「実験テンプレートを作成」ボタンをクリックすると、停止条件が未指定の場合、確認のウィンドウが立ち上がります。
今回は実験の実験なので指定していませんが、EC2 インスタンスの停止実験であれば、EC2 インスタンスが停止した旨を伝える Cloudwatch アラームを作成し、停止条件に設定するのがよいと思います。
「作成」と入力して、「実験テンプレートを作成」ボタンをクリックします。
問題なく完成すると、以下の様に「正常に作成されました」となります。
実験(の実施)
ここからは作った実験テンプレートで、実際に EC2 を停止してみます。
実行する実験テンプレートを選択し、アクションメニューから「実験を開始」を選択します。
必要に応じて「実験」にタグを指定することもできます。
「実験」に名前を付けたい場合は、ここで Name タグを設定します。
「実験を開始」ボタンをクリックします。
すると、本当に実行していいの？破壊的なアクションが実行されシステムが壊れてしまうよ？本当にいいの？？と確認が入ります。
本当に問題がなければテキストエリアに「開始」と入力して、「実験を開始」ボタンをクリックします。
すると、実験の状況を示すコンソールに遷移します。
「状態」の箇所やアクションの内容を確認すると、現在どの実験が行われているのかがわかります。
完了すると、以下の様に「Completed」と表示されます。
ちなみに、エラーの場合は「Failed」と表示されます。
実行履歴は、以下の様に確認できます。
まとめ
これまで、AWS 上でカオスエンジニアリングを実施するには、OSS の Chaos Monkey などの Chaos シリーズや、 Gremlin といったサービスをすることが一般的でした。
AWS が自前でこういったサービスを提供してきたことで、より一層、カオスエンジニアリングを実施しやすい環境になってきたのではないでしょうか。
まだ少し粗削りなつくりのところもありますが、特別な エージェントやツールを仕込むことなくマネージメントコンソールから操作ができるのはよいですね。
記載されている会社名、製品名、サービス名、ロゴ等は各社の商標または登録商標です。