はじめに
仕事で AWS Fault Injection Simulator (FIS) を利用するかもしれないので、さわってみました。
LT 会とか、ハンズオンとかのネタにしたいと思ったので投稿です。
AWS FIS のシナリオライブラリから、「EC2 ストレス：メモリ」をハンズオンしていきます。
AWS FIS (Fault Injection Simulator)
FISは、AWS Resilience Hub に含まれカオスエンジニアリングを導入するサービスで、ざっくりと言うと、「AWS で擬似的に障害を発生させる耐障害性テスト」のサービスです。
"カオスエンジニアリング" については、詳しく説明してる Qiita があるので、ページ下部の"参考"をご覧ください。
"カオス"と言っても、パッと想像する「混沌、混乱」ではなく、「カオス理論・力学、あるいは複雑系」のことです。複雑な「分散システムの振るまい」を指していると思います。
シナリオライブラリ
AWS が事前にシナリオを用意してくれてます。
ハンズオン
今回は、EC2 に負荷をかける"ストレステスト"を作成します。
事前準備
IAM ロールの作成
- ロールの作成画面
-
IAM->ロール（左のメニューから） ->ロールの作成ボタン
-
- エンティティの選択
-
エンティティ: AWS のサービス -
ユースケース: EC2
-
- 許可を追加
-
許可ポリシー: 「AmazonSSMManagedInstanceCore」で検索して選択
-
- ロールの作成
-
ロール名: AmazonSSMManagedInstanceCore
-
EC2 インスタンスの作成
- EC2 インスタンスの作成画面
-
EC2->インスタンス（左のメニューから） ->インスタンスを起動ボタン
-
- アプリケーションおよび OS イメージ
-
クイックスタートタブ ->Amazon Linux->Amazon Linux 2023 AMI
-
- インスタンスタイプ
-
インスタンスタイプ: t2.micro
-
- 高度な詳細
-
IAM インスタンスプロフィール: AmazonSSMManagedInstanceCore -
タグ: キー = Name 値 = test-ec2 -
タグ: キー = Ec2StressMemory 値 = Allowed
-
EC2 の接続テスト
"Session Manager" (SSM) で接続できることを確認
EC2 インスタンス -> 接続ボタン（右上から） -> セッションマネージャータブ -> 接続ボタン
SSM で接続エラーになる場合は、EC2 の IAM ロールが正しく設定されている事を確認
シナリオの選択
EC2 ストレス：メモリを選択
テンプレートを指定
アクションとターゲットを指定
既に"アクション"も"ターゲット"もテンプレートとして AWS が作成済み
ターゲットを編集
作成済みの"ターゲット"をクリックして修正
リソースタグに キー : Name 値 : test-ec2 を追加
サービスアクセスの設定
「AWSFaultInjectionSimulatorEC2Access」のポリシーが必要
私は既に作成済みでしたが、本当はここで"新しいロールを作成"になります
オプションの設定
- 停止条件 : 特定の CloudWatch アラームがトリガーされた際に FIS の実行を停止する条件を指定できるらしい
- ログ : 指定することで S3 と CloudWatch にログ出力ができるらしい
実験テンプレートを作成
内容を確認して、実験テンプレートを作成
実験を開始
実験テンプレート -> 対象の実験（1 実験単位のキーは文字の羅列になってます） -> 実験を開始
実行前
実験スタート直前。CPU は 0 %
実行中
CPU が 97 % まで上昇
"PID" が、3220 の「stress-ng-vm」が負荷をかけてます。
実行後（実験停止）
CPU が 0 % に戻りました。
FIS のレポートタブにアクション結果が表示されました。
おわりに
はじめてさわったサービスでしたが、シナリオも用意されているのでサービスを利用するだけであれば、難しく無いと感じました。
ただ、"カオスエンジニアリング"が必要なほど、大きく複雑なシステムを理解して"テストケースを考え"、"テスト結果からの考察"するのは大変だなと感じました。
もう少し、理解を深めて「カオスエンジニアリング」(AWS FIS)の使いどころを考えたいと思います。
参考（感謝）