AWS Fault Injection Simulatorを使った回復力のテスト

Pulisher : Cloud Technology Center チュ・ジェビン
Description : AWS Fault Injection SimulatorでExperiment templateを定義して、特定のAWSサービスに障害が発生する動作を検証するモニタリングセッション

はじめに

Fault Injectionテストとは、システムに障害シナリオを強制的に構成して堅牢性を確認することです。

システムが堅牢であるということは、システム障害のリスクにさらされた状況で、これを安全(safe)に維持するシナリオが正しく動作するということです。

Fault Injectionテストをクラウドのマネージドインフラストラクチャに適用するとはどういうことでしょうか。 そして、実際にどのように実行する必要があり、どのような課題に直面しているのでしょうか。

このような疑問から、AWS FISサービスに関するセッションを申し込みました。

セッションの概要紹介

AWS Fault Injection SimulatorでExperiment templateを定義します。これにより、特定のAWSサービスに障害になる動作を命令して反応を観察します。対象となる可能性があるサービスが何であり、彼らに命令できる行動はどのようなものか、その結果を観察する方法は何であるかを勉強することができます。

AWS Fault Injection SimulatorのExperiment

AWS Fault Injection SimulatorのExperimentはサービスを対象として構成するのですが、対象サービスとなる可能性があるものが画像に表示されています。例えば、RDS DBクラスターが2つのAZに渡って配置されていますが、1つのAZが故障する状況を想定した実験を構成することができます。

実験は特定の条件(CloudWatch Alarm)が満たされると終了します。この状況でDBクラスターが特定のThreshold期間だけうまく動作していることを確認することができるようです。

動作方法

AWS Fault Injection Simulatorの動作方式は他のテストフレームワークで提供するユニット/統合テスト構成と似ています。上の図のように、サーバーレスラムダ関数で失敗テストを実行するため、カスタムで作ったWrapper層を作ります。

そして、関数の入力または出力部分を修正して欲しいほど来ない入/出力をシミュレーションすることが可能です。

今回の図はAWS Fault Injection Simulator実験が動作する構造を示しています。前の章の表と比較してみると、AWS Fault Injection Simulator実験のActionでSSMドキュメントを指定することが可能です。

ここにラムダ関数内の特定の関数に混線を追加して特定の(ランダム)比率でエラーシナリオを構築することができ、すごいカスタマイズの余地を追加することができます。

CICDを使用した障害発生時のエラーの復旧

CI/CDの流れにも介入して失敗シナリオを流し込む様子です。このシナリオは、CodePipelineのデプロイ先が失敗用EC2になるようにすることで、このパイプラインの実行自体が失敗することをCloud Watch Alarmで検証すれば、今回のFault Injectionテストが成功することになります。

一方、サービスAPIの呼び出しがExperimentのActionになることができるという点もキャッチできる部分です。

オンプレミス上のサーバーもFault Injectionテストの対象にすることができます。対象サーバーにはSSM Agentがインストールされ、SSM Documentを実行できる必要があります。CPU、memory、diskの状況に対するFaultを生成するスクリプトを実行してみます。

AZ 失敗を想定した場合

FISで最も面白かったシナリオは、AZの失敗を想定できる点でした。 特定のAZが死んだと仮定して、ALBの負荷分散経路が生きている方に決定され、ユーザートラフィックが正しく転送されるかどうかを確認するシナリオです。

セッションを終えて

AWS Fault Injection Simulatorのセッションを聞いてみると、他のテストフレームワークと似たような感覚で使えるツールだと思いました。Given-When-ThenがAWSインフラストラクチャ-失敗ActionとTarget-CloudWatch Alarmと対応しないのでしょうか。

私が感じたAWS Fault Injection Simulatorの特徴的なメリットは一つでした。AWS CLIスクリプトだけではシステムが失敗する「偽の状況」を作ることができませんが、AWS Fault Injection Simulatorでは可能だということです。