はじめに
第2回の記事では、AWS Fault Injection Simulator（FIS）を利用してAmazon EC2（EC2）にカオスを挿入する方法を紹介しながら、FISがどのように「システムに対して安全にカオスの挿入を行う上で考慮すべき観点」に対応しているかを説明しました。
本記事では、Amazon Elastic Container Service（Amazon ECS）のFargate起動タイプで構成されたシステムに対してFISでカオスを挿入する方法を紹介します。
前提条件
実験対象システム
実験の対象システムとして、Amazon ECS と AWS Fargate を利用した Twelve-Factor Apps の開発で紹介されているサンプルソリューションを利用します。ブログ内のCloudFormationを利用して展開を行うのですが、何点か注意があります。
- CloudFormationのEnvironmentNameパラメーターでprodを指定すると、CodePiplineに追加のステージが作成されるため、試しで利用する場合はprod以外の値にした方がよいでしょう
- 利用しているpythonライブラリの依存関係の問題で、サンプルソリューションをそのままで動かすことはできません。以下のファイルの内容を下記のように編集したうえで、CodePipelineのTwelve-Factor-App-Pipelineを再実行して、再デプロイを行うようにしてください
Flask==1.1.1 boto3==1.17.12 jinja2<3.1.0 itsdangerous==2.0.1 werkzeug==2.0.3
正常性検知アラートの設定
前回の記事では、CloudWatch synthetic monitoringでの正常性監視によって定常状態を定義していましたが、今回はApplication Load Balancer（ALB）のレスポンスコードを用いて定常状態を定義します。メトリクスの数式に基づく CloudWatch アラームの作成を参考に、下記のような総リクエスト内のエラーリクエスト数の割合を示すErrorRateを定義します。一度も発生していないメトリクスは設定することができないため、もし下記のメトリクスが表示されていないようであれば、次項で説明する疑似リクエスト作成の対応を実施後、改めてErrorRateの定義を行っていただければと思います。
- ErrorRate = (HTTPCode_Target_4XX_Count+HTTPCode_Target_5XX_Count)/RequestCount
このErrorRateを1分間で評価するようにしておき、全リクエストのうちエラーとなるリクエスト数が10％以上となった場合に、アラームを発報するように設定しておきます。
疑似リクエストの生成
今回は実際の利用者を模した疑似リクエストを作成し、システムに負荷がかかった状態で、カオスの挿入を行いたいと思います。疑似リクエストはAWS での分散負荷テストを用いて作成します。CloudFormationテンプレートを実行すると、負荷テストの設定が行えるようになります。下記のように設定を行い、負荷テスト中に実験を行うようにします。
| 項目 | 設定値 | 補足 |
|---|---|---|
| Task Count | 1 | |
| Concurrency | 5 | あまり多くの負荷をかけると今回のシステムはリクエストの処理が追いつかなくなるため、同時実行は5としておきます |
| Region | ap-northeast-1 | 負荷テストソリューションを配置したリージョンを選択します |
| Ramp Up | 1 minutes | 極力早く最大負荷にしたいため、1分を指定します |
| Hold For | 10 minutes | 実験時間よりも長くなるようにしておきます |
| Run Now | 選択 | スケジュール実行を選んでも構いません |
| Include Live Data | チェック | 負荷の状態をリアルタイムで確認しておきたいので選択しておきます |
| Test Type | Single HTTP endpoint | |
| HTTP endpoint under test | サンプルソリューションのhelloエンドポイント（CloudFormationの出力セクションのLoadBalancerDNSの値） | helloエンドポイントはDynamoDBへの接続処理も確認できるため、正常性確認時のURLとして最適です |
| HTTP Method | GET | - |
