こんにちは。AWS CLIが好きな福島です。
今回は、AWS Fault Injection Simulator(以降、FIS)について調べる機会があっため、ブログにアウトプットいたします。
はじめに
用語の整理
FISを理解する上で把握したほうがいいと思った2つの用語を記載します。
カオスエンジニアリング
Netflix 社がクラウド上で分散したアプリケーションを構築していく中でスタートした、 本番環境に意図的に障害を注入し、その影響を観察する実験を通して、システムの可用性、信頼性を高めていく取り組みです。
【AWS グラレコ解説】カオスエンジニアリングで本当にカオスにならないための進め方をグラレコで解説 - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
補足(カオスエンジニアリングが登場した背景)
システムを構築後、単体テストや結合テストなどを実施しますが、 そこで確認できるテストは、既知の状態(予測可能なこと)を確認することしかできないです。
ただ、本番稼働後は、様々な外的要因により予測不可能なことが起こり得るため、障害が発生してしまいます。 そこで、予測不可能なことに対処できるよう、カオスエンジニアリングという取り組みが登場しました。
フォールトインジェクション
システムに意図的に障害 (フォールト)を注入 (インジェクション)するテスト手法となります。 つまり、カオスエンジニアリングを行うための1つの手法ということになります。
FISの概要
FISとは
AWSのリソースに対して、フォールトインジェクションが行えるマネージドサービスとなります。
FISの用語
FISで出てくる用語は以下の通りとなります。
①実験テンプレート
実験(フォールトインジェクション)を行うために必要なテンプレートになります。 ②～④の設定を定義します。
②アクション
発生させる障害・ターゲットおよび各障害に固有のパラメータを定義します。 アクションを連結させることも可能です。
③ターゲット
各アクションを実行するターゲットの指定します。 リソースIDやタグ、独自のフィルタリングが可能です。
④停止条件
実験を停止する条件を設定します。 具体的には、実験を停止する条件として、CloudWatchアラームを利用します。
⑤実験
①を使い、フォールトインジェクションを行うこと指します。
FISでサポートされているリソース
- Amazon Elastic Compute Cloud（Amazon EC2）
- Amazon Elastic Container Service（Amazon ECS on EC2）
- Amazon Elastic Kubernetes Service（Amazon EKS on EC2）
- Amazon Relational Database Service（Amazon RDS）
アクション
FIS
ターゲットに指定したIAMロールを利用したec2系API操作をエラーにできます。
- aws:fis:inject-api-internal-error
- aws:fis:inject-api-throttle-error
- aws:fis:inject-api-unavailable-error
アクションを連結させる場合、間にwaitを挟むことができます。
- aws:fis:wait
CloudWatch
アラームが予期された状態（OK、ALARM、またはINSUFFICIENT_DATA）にあることを確認後、後続のアクションを実行できます。
- aws:cloudwatch:assert-alarm-state
EC2
ターゲットに指定したEC2を再起動・停止・削除ができます。
- aws:ec2:reboot-instances
- aws:ec2:stop-instances
- aws:ec2:terminate-instances
ターゲットに指定したスポットインスタンスを中断できます。
- aws:ec2:send-spot-instance-interruptions
ECS(on EC2)
指定した割合のEC2のステータスをDRAININGに(新規タスクをEC2にデプロイしなく)できます。
- aws:ecs:drain-container-instances
EKS(on EC2)
指定した割合のEC2を終了します。
- aws:eks:terminate-nodegroup-instance
RDS
ターゲットに指定したRDSのフェイルオーバーや再起動ができます。
- aws:rds:failover-db-cluster
- aws:rds:reboot-db-instances
Systems Manager
Systems Manager Agentが導入されたインスタンスに対して、事前に定義されたSSMドキュメント(CPU,Memory,ID,Networkに負荷を与えること等)を実行できます。
- aws:ssm:send-command/AWSFIS-Run-CPU-Stress
- aws:ssm:send-command/AWSFIS-Run-IO-Stress
- aws:ssm:send-command/AWSFIS-Run-Kill-Process
- aws:ssm:send-command/AWSFIS-Run-Memory-Stress
- aws:ssm:send-command/AWSFIS-Run-Network-Blackhole-Port
- aws:ssm:send-command/AWSFIS-Run-Network-Latency
- aws:ssm:send-command/AWSFIS-Run-Network-Latency-Sources
- aws:ssm:send-command/AWSFIS-Run-Network-Packet-Loss
- aws:ssm:send-command/AWSFIS-Run-Network-Packet-Loss-Sources
Systems Manager Agentが導入されたインスタンスに対して、カスタムしたドキュメントを実行できます。 例えば、AMIまたはCFnテンプレートの作成と削除、S3バケットの削除、AWS Lambda関数の呼び出し等、さまざまな一般的なタスクを実行できます。
- aws:ssm:start-automation-execution
FISを利用するにあたって
FISを利用するにあたって参考となるAWSドキュメントと動画があったため、ご興味がある方は参照ください。
基本原則とガイドライン
https://docs.aws.amazon.com/fis/latest/userguide/getting-started-planning.htmlカオスエンジニアリングで本当にカオスにならないための進め方をグラレコで解説
https://aws.amazon.com/jp/builders-flash/202110/awsgeek-fault-injection-simulator/?awsf.filter-name=*all明日から始める!! Chaos Engineering 始め方ガイド(AWS-57) https://www.youtube.com/watch?v=9M13W0sYgks
ざっくり記載すると、
- 実験の対象は、まずは、テスト環境から開始する
- システムが機能しているかを判断するための指標(ビジネスKPIやそれらに関連する値)を決める
- 指標を観測できる仕組みを準備する
- 実験前に「こうなるはず」だが確証がない仮説を立てる(確証があるものは実験しない)
- 「発生頻度」×「潜在的な影響範囲」を基に実験内容の優先度を決める
- 実験後に指標を観測し、仮説と結果を振り返り評価する
- 評価を行い、システムの改善を行う
という感じかなと思います。
終わりに
今回は、AWS Fault Injection Simulator(以降、FIS)について調べたため、ブログにアウトプットしました。 どなたかのお役に立てれば幸いです。
