【AWSでカオスエンジニアリング】AWS Fault Injection SimulatorでEC2にカオスを挿入する

AWSとAzureのマネージドサービスで実践カオスエンジニアリング　第2回

　本連載では、AWSやMicrosoft Azureが提供するカオスエンジニアリングのマネージドサービスの特徴を紹介しつつ、実際のカオスエンジニアリングの実践方法をご紹介します。今回は、AWS Fault Injection Simulatorについて、利用方法と対応している機能について紹介します。

はじめに

　前回の記事では、筆者が考える「システムに対して安全にカオスの挿入を行う上で考慮すべき観点」として「定常状態の定義」「影響範囲の限定」「実験管理の負荷」の3点を紹介しました。

　本記事では、AWS Fault Injection Simulatorを利用してAmazon EC2（EC2）にカオスを挿入する方法について説明します。さらに、FISの導入手順を紹介するなかで、紹介する機能が前述した3つの観点のどれに対応しているかについても併せて紹介します。

　以下は、前回紹介した観点のリストから、FISが持たない機能を除外したものとなります。

1. 定常状態の定義
   1. 定常状態を定義する方法
   2. 異常状態の検知方法
2. 影響範囲の限定
   1. カオス挿入の対象の選定方法
   2. ロールバック機能
3. 実験管理の負荷
   1. 実験の記録
   2. 実験のコード管理
   3. 実験の共有

前提条件

　実験対象のシステムは、下記のようにElastic Load Balancing（ELB）の配下にEC2を2台Multi-AZで構成しています。EC2障害からの自動復旧を実現するため、Auto Scaling Groupも利用しています。Auto Scaling Groupでは希望の容量、最小の容量、最大の容量をすべて2に設定しておきます。

　このシステムに対してCloudWatch synthetic monitoringによる正常性監視をしています。

　CloudWatch synthetic monitoringは、1分間隔でシステムのトップページにリクエストしており、下記条件をすべて満たすことで正常と判断します。

1. 30分内のHTTP Statusが200だった場合のリクエスト数／30分の総リクエスト数（30回）≧90％
2. 30分内のリクエストのレスポンスが返却されるまでにかかった時間の90％タイル値≦3000ms

実験内容

　実験では2台のうち1台のEC2が停止したとしても、利用者が継続してシステムを利用し続けることができることを確認します。

　FISでは異常状態を定義することで、逆説的に定常状態を定義するため、「前述した2つのCloudWatch synthetic monitoringがアラーム状態とならないこと」を定常状態として定義します。

　実験の大枠が決まったところで、さっそく具体的な実験の設定の方法を見ていきましょう。