お手軽カオスエンジニアリング!! AWS Fault Injection Simulator

Yujin Nakano

Published in

MICIN Developers

9 min readMay 13, 2021

こんにちは！みなさん，AWSは使っていますか？

AWSで「システムを構築したけどこれはシステム障害に強いのかなぁ」なんて気になること，しばしばあると思います．自分たちで検証できたら安心して開発を進められますよね!今回はそんな時に役立つツールを紹介します．

AWS Fault Injection Simulator

今年に入ってから，AWSはAWSリソースに対してカオスエンジニアリングを支援するFault Injection Simulator（FIS)というツールを提供開始しました．こちら，試してみた系の記事はいっぱいあるのですが，触れられてない機能もたくさんあるのでこちらにまとめました！

本記事の対象者

カオスエンジニアリングに興味ある人
FISを使ったことがない人
FISを試してみたものの，ネット上のやってみた系の小さい実験ぐらいしか試せていない人
FISのリファレンスを見ると蕁麻疹が出る人

AWS Fault Injection Simulator とは

FISはカオスエンジニアリングのためのツールです．カオスエンジニアリングとは詳しくはこちらで詳しく述べられているような，わざと本番環境に擬似障害を起こし，復旧をさせることによって「このシステムは本当に障害が起こった時に耐えれるの？」っていう疑問を検証するものです．

FISのアクション一覧とその挙動

EC2アクション

EC2再起動（aws:ec2:reboot-instances）
EC2停止（aws:ec2:stop-instances)
EC2終了 ( aws:ec2:terminate-instances )

ECSアクション

ターゲットクラスター上の基になる Amazon EC2 インスタンスの指定した割合を排出する(aws:ecs:drain-container-instances)

EKSアクション

指定割合のクラスタインスタンスを終了(aws:eks:terminate-nodegroup-instance)

インスタンスの集合体であるEKSから指定割合のプロセスを終了させることができる．

RDSアクション

RDSをフェイルオーバ(aws:rds:failover-db-cluster)
RDS再起動(aws:rds:reboot-db-instances)

RDSをフェールオーバさせる(待機系に切り替え）,RDSのマルチA-Z化は必須
RDSの再起動

※フェイルオーバは無料利用枠だと利用できないので注意

障害インジェクションアクション

APIスロットルエラー(aws:fis:inject-api-throttle-error)
API内部エラー(aws:fis:inject-api-internal-error)
API使用不可エラー(aws:fis:inject-api-unavailable-error)

指定したロールを使って何かにアクセスする時，指定の割合でエラーを起こすことができる．例えばEC2がRDSにアクセスするためのロールを一時的に使用不可にさせることができたり，何回かに一回のアクセスで失敗させたりすることができる．エラーの種類は以上の3つ．

待機アクション

待機(aws:fis:wait)

アクションを複数連続実行する場合などに指定時間待機させることができる．

SSMアクション

EC2コマンド送信(aws:ssm:send-command)

EC2にセッションマネージャのエージェントソフト導入が必須
EC2に任意のコマンドを実行させたり，プロセスをキルしたり，CPU等に負荷をかけることができる．

今回やってみたこと

シンプルなEC2とRDSの構成で実験

カオスエンジニアリングとは分散システムをテストするためのもの です .

今回はRDS,EC2を使う環境として，今回はwordpressの環境を構築してみました.（これでも分散システムと呼べるかは怪しいですが,EC2単体で成立するシステムじゃないので採用します）

wordpressの記事等の情報をRDSに保存し，EC2にwebサーバを構築するシンプルなシステムです．(詳細略)

※再現用のリポジトリがあるので，本記事末をご覧ください．

簡単説明

Nginx, webサーバソフト
Wordpress,webサーバ上に設置することで楽々お洒落サイトを構築できるソフト
RDS リモートの場所にあるMySQLのDB
上記の最低限のシステムを構築しただけで，障害時復旧用のプログラムや，状態監視等は一切設定していない．

前提条件

AWSのIAMユーザはrootユーザ(Administrator Access) or こちらのステップ 1のポリシーがアタッチされている.
FIS 実行時用にこちらのステップ2のポリシー，ポリシーを使ったロールが新しく用意されている.

実験1

RDSが突然再起動，直後，EC2も再起動する．

実験1の結果

1枚目が開始前，2枚目がおそらくRDSが再起動しているからか，リンクをクリックしても遷移しない．3枚目がその後で，EC2が再起動して webサーバが落ちた．

図4. 左画像が通常動作時．中央がRDS再起動時，右画像がEC2再起動時のブラウザ画面

その後，EC2が復活してもwordpressが死んでしまった

(nginxとphpの再起動を手入力で復活)

これより，EC2が落ちてしまうと，ウェブサーバのプロセスをリカバリーする様に構築していないため，自動で回復してくれないことがわかる．

実験2

1. EC2に超高負荷な状態がかかったらどうなる？

(CPU , memory負荷，ネットワーク遅延)

図6.全てSSMアクション左がCPU負荷，中央がネットワーク負荷，右がメモリ負荷

2.直後にwordpressのバックエンドが落ちたらどうなる？(プロセスキル )

実験2の結果

遅延は若干感じたが，接続数 1なので，大して負荷による差異は感じなかった．wordpressのバックエンド(php-fpmプロセス)が落とされたので，実験1のwordpressが死んでnginxのエラー画面(図5)が出た．

ちなみに，負荷データは様々な場所に反映される(EC2監視画面，Cloudwatch等)ので，そちらを分析するのも有意義である．

運用に備える

各機能がわかったところで，次はきっとどうすればこのツールを使いこなせるのか疑問になると思います.

実験テンプレートにして何回も実行できるのはなぜか．わざわざ障害を起こす意義はどこにあるのか．これらは意味があります．

そのため，カオスエンジニアリング初学者(自分も含めて),FISが作られた背景であるカオスエンジニアリングがどんなものであるかざっくり把握するための記事をこのMICIN Developersのブログにて作成しているので，是非参考にしていただけると幸いです．

AWS FISの使い方に悩む人のために

AWS FISの紹介記事はちょくちょく転がっているのに ,そもそもカオスエンジニアリングについて知見がないからどうやって運用に組み込めばいいかわからないって人，多いですよね．…

medium.com

再現用素材

こちら！！！ ( coded by terraform , githubに飛びます)

RDSの設定だけは直接wp-config.php（/usr／share/nginx/html直下）をいじる必要があるので(コードの書きようでは行けるが時間の無駄） , こちらを参考にしながらアクセスしてみるといいかと思います.変更箇所は以下のみです．

(都合上，terraformで実行する際,AWSのクレデンシャル情報の設定，DBのパスワード変更(任意),サイトURLの取得は各自で行ってください.)

//** WordPress のためのデータベース名 */ 
define('DB_NAME', 'mydb'); 
/** MySQL データベースのユーザー名 */ 
define('DB_USER', 'foo'); 
/** MySQL データベースのパスワード */ 
define('DB_PASSWORD', 'foobarbaz'); 
/** MySQL のホスト名 */ 
define('DB_HOST', RDSのエンドポイント！(要確認));