AWS Fault Injection Simulator で始めるカオスエンジニアリング
~ 停止条件で安全な実験を行う
Author : 金森 政雄
こんにちは ! ソリューションアーキテクトの金森政雄です。
以前の投稿 で、AWS Fault Injection Simulator (AWS FIS) を使った、簡単な実験の方法をご紹介しました。
しかし、本番環境で実際に実験を行う際には、障害を注入するだけではなく、何か問題が起こった時にすぐにそれを検知して、実験を停止する仕組みも必要になります。
この投稿では、AWS FIS の停止条件という機能を使って、AWS FIS の実験中に想定外の問題が起こった際に、自動的に実験を停止する方法をハンズオン形式でご紹介します。
今回は下記の作業と実験を通して、停止条件の使い方と動きを学びます。
- CloudFormation でデプロイした EC2 上の PHP アプリケーションを CloudWatch Synthetics を使って死活監視します。
- PHP のアプリケーションが動作している EC2 インスタンスの 80 番ポートへの接続が全て破棄されるブラックホールの状態を作り出す実験を行います
- 上記の実験の停止条件として、CloudWatch Synthetics の死活監視のアラームを指定しておくことで、ユーザーに影響が出ていることを検知すると自動的に実験が停止されることを確認します。
初めに : 停止条件とは
ハンズオンを始める前に、AWS FIS の停止条件 についてご紹介します。停止条件は実験を安全に行うためのガードレールを提供する機能です。具体的には、CloudWatch アラーム を指定し、実験中にそのアラームで指定された閾値を超えた場合に実験を停止することができます。
カオスエンジニアリングの原則 でも「カオスエンジニアには検証による被害が最小限に抑えられていることを確認する責任と義務があります」と書かれているように、特に本番環境の実験においては実験によって被害が発生した場合に、それをすぐに検知して影響を最小限に抑えるためのモニタリングと “赤い大きな停止ボタン” のような実験を停止するための仕組みが必要です。自分たちでそのような仕組みを作ることも可能ですが、AWS FIS の停止条件を使うことで指定した CloudWatch アラームがアラーム状態になった時に自動的に実験を停止することができます。
停止条件に指定する CloudWatch アラームは、API のエラー率やレイテンシーなどシステムの定常状態を示すものを指定することをお勧めします。定常状態について詳しくは こちら の記事をご参照ください。今回のハンズオンでは、CloudWatch Synthetics を使ってシンプルな死活監視を行い、成功率が閾値を下回った場合に実験を停止するようにします。皆さんがご自身のシステムで実験を行う際は、そのシステムのビジネス的な指標も考慮した定常状態を検討し、それをモニタリングできるようにして停止条件に利用すると良いでしょう。
なお、停止条件はあくまで実験を停止するだけの仕組みです。実験を停止するだけで自動的にロールバックできるシステムや実験であれば問題ありませんが、実験の内容によってはロールバックのために追加の手順が必要な場合がありますので注意してください。例えば、EC2 インスタンスを終了する実験の場合、それによって終了されたインスタンスそのものを復旧することはできません。(Auto Scaling を利用している場合、設定に応じて自動的に新しいインスタンスに置き換えられることが期待できます。)
なお、1 つの実験テンプレートについて停止条件は 5 つまで定義することができます。AWS FIS のその他のクォータについては こちら をご参照ください。
ハンズオンの前提条件
このハンズオンは、AWS FIS の基本的な使い方をご存知のであることを前提としています。AWS FISを使ったことがない方は、こちら のハンズオンを先に実施してみてください。 また、下記が前提条件となります。
- AWS アカウントを持っていること。 AWS アカウントがない方は こちら の手順に従って、作成してください (※)。
- AWS にログインした際に、AWS FIS、Amazon EC2、AWS Auto Scaling、AWS Systems Manager、AWS IAM を操作できる権限を持っていること (ハンズオンを円滑に進めるために、AdministratorAccess の IAM ポリシーがセットされた IAM ユーザー / ロールを利用することをお勧めします)
- AWS FIS が利用できるリージョンを利用してください。現在利用できるリージョンは こちら のサービスエンドポイントを参照してください。
- マネジメントコンソールは日本語で設定されていることを前提として手順を記載します。
※AWS アカウントを作成し、IAM の基本的な設定をしていく手順については、「AWS Hands-on for Beginners ハンズオンはじめの一歩: AWS アカウントの作り方 & IAM 基本のキ」を参考にしていただくことをお勧めします。
目次
ご注意
本記事で紹介する AWS サービスを起動する際には、料金がかかります。builders.flash メールメンバー特典の、クラウドレシピ向けクレジットコードプレゼントの入手をお勧めします。
このクラウドレシピ (ハンズオン記事) を無料でお試しいただけます »
毎月提供されるクラウドレシピのアップデート情報とともに、クレジットコードを受け取ることができます。
1. 事前準備
1-1. AWS マネジメントコンソールにログインする
※この手順は一番簡単なメールアドレスとパスワードでログインできる設定で記載しています。MFA を有効 にしていたり、AWS Single Sign On を利用している場合はその手順に従ってください。(パスワードだけの認証を利用されている場合、ぜひ MFA の設定 をご検討ください)
AWS マネジメントコンソール にアクセスします。
IAM ユーザーを選択し、アカウント ID かエイリアスを入力し次へをクリックします。
クリックすると拡大します
ユーザー名とパスワードを入力して、サインイン をクリックします。
クリックすると拡大します
1-2. AWS FIS が実験に利用する IAM ロールを作成する
AWS マネジメントコンソールの上部にある検索ボックス で “iam” と入力し、表示された IAM をクリックします。
クリックすると拡大します
左側のパネルからロールをクリックします。
クリックすると拡大します
ロールを作成 をクリックします。
クリックすると拡大します
ロールの作成画面で AWS サービス → EC2 を選択して次のステップ: アクセス権限ボタンを押します。
(2021 年 11 月 2 日現在、マネジメントコンソールから信頼されたエンティティとして、AWS FIS を選択することはできないため、一時的に EC2 を設定します。この設定は後のステップで変更します。)
クリックすると拡大します
Attach アクセス権限ポリシー の画面で AmazonSSMFullAccess のポリシーを選択して 「次のステップ: タグ」ボタンをクリックします。
(本来、最小権限の法則にしたがって権限を設定すべきですが、このワークショップでは簡単のために広めの権限を設定しています。実際の環境に適用する際は、実験で必要な最小の権限を設計しテンプレートごとに適切なポリシーを持った IAM ロールを設定することを推奨します)
クリックすると拡大します
タグの追加 (オプション) 画面では特に操作は不要です。
次のステップ: 確認 ボタンをクリックします。
クリックすると拡大します
ロール名に AWSFISHandsonRole と入力し、ロールの作成ボタンをクリックします。
クリックすると拡大します
ロールの作成が完了すると、ロール一覧の画面に遷移するので、AWSFIS と入力し、表示される AWSFISHnadosnRole を選択します。
クリックすると拡大します
AWSFISHnadosnRole の概要ページで信頼関係タブを開き、 信頼関係の編集ボタンをクリックします。
クリックすると拡大します
信頼関係の編集ページに表示されるポリシードキュメントの “Service” の値を “ec2.amazonaws.com” から ”fis.amazonaws.com” に変更します。
編集後のポリシードキュメントは下記のようになります。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "fis.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}編集後、信頼ポリシーの更新ボタンをクリックして、ポリシーを更新します。
クリックすると拡大します
信頼されたエンティティが IDプロバイダー fis.amazonaws.com になっていることを確認してください。
クリックすると拡大します
2. 実験の対象になるアプリケーションをデプロイする
実験の対象になる LAMP のアプリケーションを AWS CloudFormation を使ってデプロイします。
2-1. アプリケーションが利用するキーペアを作成する
実験の対象になるアプリケーションをデプロイする際に、キーペアの指定が必要なので、キーペアを作成します。
EC2 のコンソール を開いて、左側のナビゲーションパネルを下にスクロールし、「キーペア」を選択します。
キーペアの一覧ページが表示されるので、「キーペアを作成」ボタンをクリックします。
クリックすると拡大します
「キーペアを作成」画面で、「名前」に「FIS-Handson」と入力してそのほかはデフォルトのまま「キーペアを作成」ボタンをクリックします。
FIS-Handson.pem というファイルがダウンロードされるので、保存してください。
クリックすると拡大します
2-2. 実験の対象になるLAMPスタックをデプロイする
こちらのページ の「基本的な LAMP スタック」の「Launch stack」をクリックします。
クリックすると拡大します
「スタックの作成」画面が表示されるので、デプロイするリージョンを確認して (先ほどキーペアを作成したリージョンと同じリージョンである必要があります) 「次へ」ボタンをクリックします。
クリックすると拡大します
「スタックの詳細を指定」画面で下記を設定して「次へ」ボタンをクリックします。
- スタックの名前 : PHPHelloWorldSample (デフォルトのまま)
- DBName : MyDatabase (デフォルトのまま)
- DBPassword : 任意の値 (英数字のみ可)
- DBRootPassword : 任意の値 (英数字のみ可)
- DBUser : 任意の値
- InstanceType : t2.small
- KeyName : FIS-Handson
- SSHLocation : 0.0.0.0/0
クリックすると拡大します
「スタックオプションの設定」画面はデフォルトのまま「次へ」ボタンをクリックします。
クリックすると拡大します
設定内容をレビューして、問題なければ「スタックの作成」ボタンをクリックして、スタックを作成します。
クリックすると拡大します
ステータスが「CREATE_COMPLETE」になったらデプロイ完了です (数分で完了します)。
クリックすると拡大します
出力タブをクリックして、「WebsiteURL」の値をクリックしてください。
クリックすると拡大します
このような画面が表示されるはずです。
クリックすると拡大します
3. 停止条件に設定する CloudWatch アラームを設定する
停止条件に指定するためのCloudWatch アラームを作成します。今回は、CloudWatch Synthetics の監視状況に応じて実験を停止したいので、CloudWatch Synthetics の Canary を作成するところから始めます。
3-1. CloudWatch Synthetics の Canary を作成する
Amazon CloudWatch のコンソールに移動します。
左側のナビゲーションパネルを「アプリケーションのモニタリング」までスクロールし、「Synthetics Canaries」 を選択します。
Canary の画面で「Canary を作成」ボタンをクリックします。
クリックすると拡大します
「Canary を作成」画面では「設計図を使用する」を選択 (デフォルト) し、「ハートビートのモニタリング」を選びます。
クリックすると拡大します
下にスクロールして、「Canary ビルダー」に下記の値を設定します。
- 名前 : fis-handson
- テストするアプリケーションまたはエンドポイントURL : 2-2 でデプロイしたアプリケーションの URL
- スクリーンショットを撮る : チェックを外す
クリックすると拡大します
下にスクロールし、「スケジュール」で下記の設定をします。
- 継続的に実行 を選択
- Canaryを実行 : “間隔“ を選択
- 頻度 (1~60) : 1 分
- 作成後すぐに開始 をチェック
クリックすると拡大します
そのほかの設定はデフォルトのままにして、「Canary を作成」ボタンをクリックします。
このように、完了するまで待つようにメッセージが表示されますので、完了し、Canary が作成されるのを待ってください。
クリックすると拡大します
3-2. CloudWatch アラームを作成する
左側のナビゲーションパネルで上まで戻り、「すべてのアラーム」を選択します。
クリックすると拡大します
「アラーム一覧」の画面が表示されるので、「アラームの作成」ボタンをクリックします。
クリックすると拡大します
「メトリクスと条件の指定」画面で「メトリクスの選択」 ボタンをクリックします。
クリックすると拡大します
「メトリクスの選択」画面で、「カスタム名前空間」に「CloudWatchSynthetics」のリンクができているはずなので、そちらをクリックします。
クリックすると拡大します
表示されたメトリクスから、「Canary」を選択します。
クリックすると拡大します
表示されたメトリクスから、「CanaryName」 が fis-handson、「メトリクス名」が SuccessPercent のものを選択し、「メトリクスの選択」ボタンをクリックします。
クリックすると拡大します
メトリクスと条件の指定で、下記の設定を行います。
- アカウントID : アカウントのモニタリング中 (デフォルト)
- メトリクス名 : SuccessPercent
- CanaryName : fis-handson (デフォルト)
- 統計 : 平均値
- 期間 : 5 分
クリックすると拡大します
下にスクロールして、「条件」パネルに下記を設定して、「次へ」 ボタンをクリックします。
- しきい値の種類 : 「静的」を選択
- SuccessPercent が次の時... :「以下」を選択
- ...よりも : 50
クリックすると拡大します
「アクションの設定」画面から「SNSトピックの選択」で「新しいトピックの作成」を選択し下記を入力して、「トピックの作成」ボタンをクリックします。
- 新規トピックの作成中... : FIS-Handson-Alarm
- 通知を受け取るEメールエンドポイント... : メールを受け取れるメールアドレス
クリックすると拡大します
少しすると、SNS トピックが作成され、こちらのような画面になります。
クリックすると拡大します
登録したメールアドレスに “AWS Notification - Subscription Confirmation” というタイトルのメールが届くはずですので「Confirm subscription」のリンクをクリックしてください。
クリックすると拡大します
このように Subscription の確認が取れたページが表示されるはずです。
クリックすると拡大します
マネジメントコンソールに戻り、そのほかの設定はデフォルトのまま、下までスクロールして、「次へ」ボタンをクリックします。
「名前と説明を追加」画面に遷移するので、下記を設定して、「次へ」 ボタンをクリックします。
- アラーム名 : FIS-Handson-Alarm
- アラームの説明 : 任意 (空白でも可)
クリックすると拡大します
「プレビューと作成」画面で設定内容を確認し、問題なければ「アラームの作成」ボタンをクリックします。
クリックすると拡大します
アラームが作成されると、しばらく「状態」が「データ不足」と表示されます。
クリックすると拡大します
少し待って、「状態」が「OK」になればアラームの設定は完了です。
クリックすると拡大します
4. 停止条件を設定して実験を行う
準備ができましたので遂に、AWS FIS を使って実験をしていきましょう。
今回は、先ほどデプロイした LAMP 環境の PHP アプリケーションが動作している EC2 インスタンスに 80 番ポートへのトラフィックを全て破棄してしまうブラックホールを設定する実験をおこないます。今回の構成では EC2 インスタンスは 1 台しかありませんので、サービス全体でレスポンスが返らない状態になり、CloudWatch Synthetics を使った死活監視でアラームが発生し、実験を停止する流れを確認します。
4-1. 実験対象のインスタンスに Systems Manager のための IAM ロールを設定する
CloudFormation のコンソール に移動し、「スタック一覧」から、「PHPHelloWorldSample」を選択します。
クリックすると拡大します
PHPHelloWorldSample のスタックの詳細画面に移行するので、「リソース」タブを開き、WebServerInstance の物理 ID のリンクをクリックします。
クリックすると拡大します
インスタンスが表示されるので、選択し、「アクション」 > 「セキュリティ」 >「IAM ロールを変更」を選択します。
クリックすると拡大します
「新しい IAM ロールを作成」のリンクをクリックします
クリックすると拡大します
「ロールを作成」 をクリックします。ロールの作成画面で 「AWS サービス」 →「 EC2」を選択して、「次のステップ: アクセス権限」ボタンを押します。
クリックすると拡大します
Attach アクセス権限ポリシー の画面で 「AmazonSSMFullAccess」の 2 つのポリシーを選択して、「次のステップ: タグ」ボタンをクリックします。
(本来、最小権限の法則にしたがって権限を設定すべきですが、このワークショップでは簡単のために広めの権限を設定しています。実際の環境に適用する際は、実験で必要な最小の権限を設計しテンプレートごとに適切なポリシーを持った IAM ロールを設定することを推奨します)
クリックすると拡大します
タグの追加 (オプション) 画面では特に操作は不要です。
「次のステップ : 確認」ボタンをクリックします。
クリックすると拡大します
ロール名に 「AWSFISHandsonSSMRole」と入力し「ロールの作成」ボタンをクリックします。
クリックすると拡大します
EC2 の IAM ロールを変更画面を表示していたブラウザのタブに戻り、更新ボタンを押してから、作成した「AWSFISHandsonSSMRole 」を選択して、「保存」ボタンをクリックします。
クリックすると拡大します
4-2. 対象のインスタンスに 80 番ポートへのトラフィックを破棄するブラックホールを設定する実験テンプレートを作成する
AWS マネジメントコンソールの上部にある検索ボックス で 「fis」 と入力し、表示された 「AWS FIS」をクリックします。
クリックすると拡大します
表示された AWS FIS の画面で「実験テンプレートを作成」をクリックします。
クリックすると拡大します
実験テンプレートを作成画面で、下記を入力していきます。
- 説明 : 対象のインスタンスの 80 番ポートへの通信を全て破棄するブラックホールを設定します
- この実験で何をするかを説明します。必須項目です。 - 名前 - オプション - : FISHandson-Blackhole-Port80
- ここに設定された値が Name タグに設定され、一覧画面の Name 列 で確認できます。オプションですが、管理しやすさのために設定することをお勧めします。 - IAM ロール : 事前準備で作成した AWSFISHandsonRole
- 実験の実行時に AWS FIS が利用する IAM ロールを設定します。
クリックすると拡大します
ここから、実験の内容となるアクションを定義していくのですが、実際のカオスエンジニアリングにおいては、すでに本番環境でなんらかの障害が発生しているときに実験を開始してしまうと、被害をさらに広めたり、運用担当者を混乱させ復旧や原因調査を難しくしてしまう可能性があります。そのため、実験の開始前にはアプリケーションが定常状態を維持しており、実験が安全に行える状況であることを確認することが推奨されます。
AWS FIS では こちらのアップデート で、アクションを使ってCloudWatch アラームの状態をチェックできるようになりました。この機能を使うことで実際の実験の開始前に、定常状態を示す CloudWatch アラームの状態を確認し、なんらかの問題がある場合は実験を行わないように制御することができます。まずはこの設定をしていきたいと思います。
画面をスクロールし、「アクション」パネルを表示して、「アクションを追加」ボタンをクリックします。
「新しいアクション」 パネルが表示されるので下記を設定して「保存」ボタンをクリックします。
- 名前 : Check-AlarmStatus
- アクションタイプ : aws:cloudwatch:assert-alarm-state
- alarmArns : “FIS-Handson-Alarm“ を選択
- この項目以降はアクションタイプを設定すると表示されます - alarmStates : “OK” を選択
- その他の項目はデフォルトのまま
クリックすると拡大します
「アクションを追加」ボタンをもう一度クリックします。
「新しいアクション」 パネルが表示されるので下記を設定してブラックホールを設定する障害のアクションを定義します。このアクションは Check-AlarmStatus が成功したら実行されるように「次のあと開始」項目を使って設定します。完了後、「保存」ボタンをクリックして保存します。
- 名前 : Blackhole-80Port
- アクションタイプ : aws:ssm:send-command/AWSFIS-Run-Network-Blackhole-Port
- ターゲット : Instances-Target-1 が自動的に設定されます。
- この項目はアクションタイプを設定すると表示され、自動的に値が設定されます。この後の手順でターゲットの設定をしていきます。 - 次のあと開始 - オプション : “Check-AlarmStatus” を選択
- documentArn : 使用しているリージョンに合わせて、 arn:aws:ssm:<region>:document/AWSFIS-Run-Network-Blackhole-Port が自動的に設定されます。これは、このアクションタイプのために AWS が事前に用意した SSM ドキュメントの ARN です。
- documentParameters : {"Protocol":"tcp", "Port":"80", "TrafficType":"ingress", "DurationSeconds":"300", "InstallDependencies":"True"}
- duration : 分 に設定して、10 を入力
- その他の項目はデフォルトのまま
クリックすると拡大します
「ターゲット」パネルに表示された “Instainces-Target-1(aws:ec2:instance)” の「編集」ボタンをクリックします。
クリックすると拡大します
「ターゲットを編集」ダイアログが表示されるので、下記を設定して、「保存」ボタンをクリックします。
- 名前 : InstanceBlackholePort80
- この項目は変更しなくても問題ありませんがわかりやすい名前をつけることを推奨します。 - リソースタイプ : aws:ec2:instance
- (デフォルト値のままです) - ターゲットメソッド : リソース ID を選択
- リソース ID : 4-1 で確認したインスタンスのインスタンス ID を指定します
- 選択モード : ドロップダウンリストから すべて を選択 (デフォルト値のままです)
クリックすると拡大します
スクロールして、「停止条件」パネルで「FIS-Handson-Alarm」を選択します。
クリックすると拡大します
「実験テンプレートを作成」ボタンをクリックします。
クリックすると拡大します
実験テンプレートが作成されます。前回のハンズオン を実施された方は、前回では停止条件が設定されていなかったので表示されていた確認画面が表示されないことに気づかれたかもしれません。
クリックすると拡大します
4-3. 作成した実験テンプレートを使って実験を実行する
「アクション」ドロップダウンを開き、「開始」をリックします。
クリックすると拡大します
「実験を開始」 画面で「新しいタグを追加」ボタンをクリックし表示される項目に下記の値をセットし、「実験を開始」ボタンをクリックします。
- キー : Name
- 値 - オプション : FISHandson-tryStopCondition-run1
※この設定は必須ではありませんが、一覧画面などで実験を識別するために設定することをお勧めします。
クリックすると拡大します
「実験を開始」ダイアログが表示されます。
ここでは誤って実験を開始し、ワークロードに想定外の問題を発生させないための最終確認のため、フォームに「開始」と入力することを求められます。「開始」と入力すると「実験を開始」ボタンが有効化されるので、クリックして実験を開始します。
クリックすると拡大します
実験が正常に開始されると、下記のような画面が表示されます。状態が Initiating であることをご確認ください。
クリックすると拡大します
4-4. 停止条件に指定したアラームが発火し、実験が自動的に停止されることを確認する
少しして、「更新」ボタンをクリックすると、状態が Running になります。
まず、Checck-AlarmStatus が実行され、無事 Completed になると、続いて Blackhole-80Port のアクションが実行され、PHP アプリケーションが動作していたインスタンスへの 80 番ポートへの通信が全て破棄されるようになります。この時点で、デプロイした PHP アプリケーションにアクセスすると、ブラウザがタイムアウトするはずです。
クリックすると拡大します
停止条件に設定したアラームを確認してみましょう。
Amazon CloudWatch のコンソールに移動し、すべてのアラーム > FIS-Handson-Alarm と遷移します。
少しすると、アラームが発火するはずです (もしまだ発火していない場合、何度か更新ボタンを押してみてください)。
また、アラームに設定した SNS を経由して、死活監視失敗を通知するメールが届くはずです。
クリックすると拡大します
アラームが発火したことを確認したら、改めて、AWS FIS の実験の状況を確認しましょう。
こちらのように、実験の「状態」と「Blackhole-80Port アクション」が Stopped になっていることが確認できるはずです。(ステータスが変更されていない場合、「更新」ボタンを押してみてください。)
この状態で、デプロイした PHPアプリケーションにアクセスすると問題なくサイトが表示されるようになっているはずです。
クリックすると拡大します
アラームも確認しましょう。しばらくすると、アラームも解決されて、OK のステータスになるはずです。
クリックすると拡大します
5. 後片付け
リソースを残してしまうことで、AWS の利用料が残らないように今回利用したリソースを削除していきます。
- Amazon CloudWatch コンソールに移動し、アラームと、CloudWatch Synthetics のCanary を削除します。
- すべてのアラーム > FIS-Handson-Alarm を選択し、「アクション」ドロップダウンから「削除」をクリックし、確認ダイアログで「削除」ボタンをクリックします。
- Synthetics Canaries > fis-handson を選択し、「アクション」ドロップダウンから「中止」をクリックし、状態が、停止中から停止になるのを待ちます。その後、「アクション」ドロップダウンから「削除」をクリックし、確認ダイアログで「Delete」 と入力し「削除」ボタンをクリックします。
- Amazon SNS のコンソール に移動し、トピック > FIS-Handson-Alarm を選択し、「削除」ボタンをクリックします。「トピックの削除 Default_CloudWatch_Alarms_Topic」ダイアログで「これを削除」と入力し、「削除」ボタンをクリックしてください。
- AWS FIS のコンソールで実験テンプレートから、FISHandson-Blackhole-Port80 のテンプレートを選択し、「アクション」ドロップダウンから、「実験テンプレートを削除」をクリックし、実験テンプレートを削除ダイアログでフォームに 「delete」と入力し、「実験テンプレートを削除」ボタンをクリックします。
- IAM コンソールでロールを選択し、IAM ロール一覧から、AWSFISHandsonRole を選択し、「削除」ボタンをクリックして表示される 「AWSFISHandsonSSMRole を削除しますか ?」ダイアログのテキスト入力フィールドに 「AWSFISHandsonRole」と入力し、削除ボタンをクリックします。AWSFISHandsonSSMRole も同じ手順を繰り返して削除します。
- CloudFormation のコンソール に移動しPHPHelloWorldSample を選択し、「削除」ボタンをクリックしてテンプレートを削除します。
5. まとめ
このハンズオンでお見せしたように、停止条件を使うことで、実験中に想定外の問題が発生し定常状態を維持できなくなった場合、自動的に実験を停止するように実験を設定することができます。システムが自動的に復旧できる機構を持っていたり実験の内容によっては自動的にロールバックされます。
カオスエンジニアリングのプロセスとしては、問題が起こったときに定常状態を維持できる仮説を立てて、それを検証するために実験を行います。停止条件に定常状態を監視する仕組みを設定していた場合、「停止条件によって実験が停止した」と言うことは「仮説が反証された」ということになるので、仮説通りに定常状態が維持できなかった理由を調査し、改善する必要があります。
このような問題点を見つけて改善していくことで長期的なシステムの改善を実現することがカオスエンジニアリングの目的です。一方で、実際にお客様に影響が発生することはできる限り避けるべきでしょう。今回は停止条件の挙動をわかりやすくするためにサイト全体が停止するシナリオを利用しましたが、実際に皆さんのシステムで実施する際は、爆発半径 (Brast Redius) を考慮して実験を計画したり、本番での実験の前に検証環境で実施するなど、「検証による被害が最小限に抑えられていることを確認」しながら進めていただければと思います。
それでも、想定外の事態が起きた場合に、停止条件をご利用いただくことで、被害を最小限に抑えることができるかもしれません。AWS FIS での実験の際には、ぜひ停止条件を利用することをご検討ください。
筆者プロフィール
金森政雄
アマゾン ウェブ サービス ジャパン合同会社
デベロッパースペシャリスト ソリューションアーキテクト
Web、モバイル向けの自社サービスの開発やクラウドを活用したシステムの請負開発を経験後、パートナーソリューションアーキテクトとして、アマゾン ウェブ サービス ジャパン合同会社に入社。2021 年から DevAx チームとして、開発者の方に向けたイベントやワークショップの提供を中心に活動。
最近の個人的ニュースは家の近くのラーメン屋で、「まさお」という自分の名前と同じメニューがあったこと。
AWS を無料でお試しいただけます