AWS は、ユーザーがアプリケーションの耐性をテストできるように、クラウド サービスに意図的な障害を導入するように設計された障害注入シミュレーター (FIS) を展開しました。
カオス エンジニアリングは、フェイルオーバー システムなどが期待どおりに動作するかどうかは実際の停止が発生するまで管理者にはわからないという原則に従って、障害発生時に実際に何が起こるかを発見するのに役立ちます。
また、応答が遅いサービス、不正なデータに遭遇したサービス、メモリ不足に陥ったサービスなどの影響をテストするためにも使用できます。これは、大惨事を回避するだけでなく、その結果とそれがビジネスに及ぼす潜在的な影響を測定することを目的としています。
AWS 障害注入シミュレーターの 1-2-3 – ただし、サービスの範囲は限定されています
AWS 障害シミュレーションサービス (FSS) は、昨年末に同社の仮想 re:Invent カンファレンスで発表され、現在は利用可能となっているが、最初のバージョンでは範囲が限られている。
対象となるサービスは、EC2（仮想マシンインスタンス）、ECS（コンテナ）、EKS（Kubernetes）、RDS（リレーショナルデータベース）です。FSSを使用するには、AWSが「実験」と呼ぶもの、つまり実験を実行できる実験テンプレートを作成する必要があります。
実験には、reboot-instance や inject-api-internal-error などのアクションと、特定の VM インスタンスや EKS ノードグループなどのターゲットがあります。SSM ドキュメントと呼ばれる AWS Systems Manager コマンドドキュメントを YAML または JSON 形式で指定することで、最大限の柔軟性が得られますが、作成が面倒で、ターゲットリソースに SSM エージェントが必要です。
レグが試してみる
AWS RDS（リレーショナルデータベースサービス）上のMySQLデータベースを対象とした小規模な実験を設定したところ、いくつか問題に直面しました。アクションの範囲が限られており、実験作成コンソールではどのアクションがどのサービスに適用されるのかが示されていませんでした。データベースの応答が遅い状態をシミュレートするために「待機」遅延を挿入しようとしたところ、「このターゲットにはアクションが関連付けられていません」というエラーが発生しました。そこで、アクションを「データベースインスタンスの再起動」に変更したところ、問題なく動作しました。また、AWS Identity and Access Managementのロールとポリシーに関するお決まりの複雑さもありました。
混沌はあなたにとって良いことだ、と最初の「カオスエンジニアリングの現状」レポートは述べている
続きを読む
これらすべてが完了後、実験は成功しましたが、その前にいくつかの警告が表示されました。ダイアログには「この実験はAWSリソースに破壊的なアクションを実行する可能性があります」と表示され、「ベストプラクティスと計画ガイドラインを確認する」ように促されました。
前述のガイドラインに従ってこのページに進むと、それほどわかりやすくはありませんが、「まず計画フェーズを完了し、試作環境またはテスト環境でテストを実施する」ことが提案されています。
また、実験をCloudWatchモニタリング（別のAWSサービス）にリンクさせて停止条件を設定し、何か問題が発生した場合に早期に終了できるようにすることが強く推奨されました。AWSは、新たに熱心に実験に取り組む人々が予想以上に混乱を引き起こすことを懸念しているようです。
自分が何をしているのか本当に分かっていますか？AWSがリスクを警告
サービスの料金は1アクションあたり0.10ドル/分で、実験用にプロビジョニングされた追加リソースがある場合は、その費用も加算されます。ほぼすべてのAWSサービスと同様に、FIS APIが用意されており、DevOpsパイプラインの一部としてFIS実験を実行することも可能になります。
AWSリソースにおけるカオスエンジニアリングは、EC2インスタンスのcronジョブ内の自作スクリプトや、Gremlinのようなサードパーティの専門家が提供するサービスなど、他の手段でも実行できることは注目に値します。AWSによる初期の取り組みは、専門家にとってそれほど大きな負担にはならないでしょう。しかし、AWSテクニカルエバンジェリストのジェフ・バー氏によると、「2021年を通して、さらに多くのサービスとアクションのサポートを追加していく予定です」とのことなので、近いうちに改善が期待できます。®
