Zenn
🚴🏻‍♀️

【AWS Fault Injection Simulator】AWSの基礎を学ぼう 特別編

2021/05/16に公開
AWS
#
感想
#
handson
tech

概要

「AWS エバンジェリストシリーズ　AWSの基礎を学ぼう」で”AWSの基礎を学ぼう 特別編　最新サービスをみんなで触ってみる はじめてのカオスエンジニアリング”というイベントに参加した感想ページです。

「AWS エバンジェリストシリーズ　AWSの基礎を学ぼう」とは

AWS エバンジェリストシリーズ　AWSの基礎を学ぼう

以下、Connpassページより引用

Amazon Web Services (AWS)は現在200を超えるサービスを提供し、日々サービスの拡充を続けています。
このAWS エバンンジェリストシリーズでは週次でAWSのサービスをひとつづつ取り上げながらその基礎を説明していく 初心者、中級者をターゲットとした講座です。午後の仕事前にスキルアップを一緒にしませんか？
注意点 登壇者による発表内容はアマゾン ウェブ サービス ジャパンとして主催しているものではなく、コミュニティ活動の一環として勉強会の主催を行っているものです。

毎週ありがとうございます！

内容

座学＆再整理

AWS （FIS）Fault Injection Simulatorって何？

AWS Fault Injection Simulator とは
AWS ワークロードで障害挿入実験を実行できるマネージド型サービスです。障害挿入は、カウスエンジニアリングの原則に基づいています。これらの実験では、破壊的なイベントを作成してアプリケーションを強調するため、アプリケーションがどのように応答するか確認することができます。この情報を使用してアプリケーションのパフォーマンスと回復性を向上させ、期待どおりに動作させることができます。

AWS FISの対象サービス

現時点での対象サービスは以下です。

  • Amazon Elastic Compute Cloud (Amazon EC2)
  • Amazon Elastic Container Service (Amazon ECS)
  • Amazon Elastic Kubernetes サービス (Amazon EKS)
  • Amazon リレーショナルデータベースサービス（Amazon RDS）

AWS FISの対象サービス

AWS FIS は、AWS サービス全体で特定のタイプのターゲットに対して事前設定されたアクションを提供します。AWS FIS アクションには次の識別子があります。ということで洗い出しと私の解釈

EC2関連

  • aws:ec2:reboot-instances　⇨　インスタンスリブート
  • aws:ec2:stop-instances　⇨　インスタンス停止
  • aws:ec2:terminate-instances　⇨　インスタンス削除

ECS関連

  • aws:ecs:drain-container-instances　⇨　インスタンスのドレイン（新規タスクが配置されない）

EKS関連

  • aws:eks:terminate-nodegroup-instances　⇨　ノードが乗るインスタンス削除

FIS関連

  • aws:fis:inject-api-internal-error　⇨　AWSサービスに対して内部エラーを起こす
  • aws:fis:inject-api-thorottle-error　⇨　AWSサービスに対してthrottleエラーを起こす
  • aws:fis:inject-api-unavailable-error　⇨　AWSサービスに対して利用不可エラーを起こす
  • aws:fis:wait　⇨　指定期間Wait状態になる

DB関連

  • aws:rds:failover-db-cluster　⇨　failoverさせる
  • aws:rds:reboot-db-instances　⇨　インスタンスリブート

SSM関連

  • aws:ssm:send-command　⇨　SSMでコマンド発行
  • aws:ssm:send-command/AWSFIS-Run-CPU-Stress　⇨　SSMでコマンド発行してCPU負荷を上げる
  • aws:ssm:send-command/AWSFIS-Run-Kill-Process　⇨　SSMでコマンド発行してプロセスを殺す
  • aws:ssm:send-command/AWSFIS-Run-Memory-Stress　⇨　SSMでコマンド発行してメモリ負荷をあげる
  • aws:ssm:send-command/AWSFIS-Run-Network-Latency　⇨　SSMでコマンド発行してネットワークを遅延させる

お試し

aws:ssm:send-command/AWSFIS-Run-CPU-Stressをやってみる

実験テンプレートで作成していく。

アクションの設定

  • 名前 : 任意設定

  • アクションタイプ : aws:ssm:send-command/AWSFIS-Run-CPU-Stress

  • ターゲット : instances-Target-1(後に詳細設定)

  • documentArn : arn:aws:ssm:ap-northeast-1::document/AWSFIS-Run-CPU-Stress

  • documentParameters : {"DurationSeconds":"30", "InstallDependencies":"True"}

  • duration : 2

  • documentArnはアクションタイプを選択すれば自動的に入ります。

  • documentParametersはここから流用しています。

ターゲットの設定

  • 名前 : 任意設定（アクションで自動作成される）
  • リソースタイプ : aws:ec2:instance
  • ターゲットメソッド : リソースタグとフィルター
  • 選択モード : すべて
  • リソースタグ : 起動しているEC2に紐づくTAGを選択

FIS実行結果

30秒経過すると先にアクションが終わるが、FISはRunningとなる

2分経過すると先にアクションが終わるが、FISも終わる
アクションパラメタのDurationはモニターの時間でしかない。

vmstat実行結果

vmstatで見るとCPU使用率100%に上がっているのは30秒

CloudWatch実行結果

短期間過ぎるためか、CloudWatchは最大値にしても100%で拾われていない。

感想

ツールとして

FISの範囲ではないですが、CPU負荷テストとして0% or 100%ではなく 80%ぐらいを狙えるツールが欲しいなぁと感じました（欲）
しかし、簡単に運用テストとしてインスタンス落としたり、failoverをさせることが出来るので、実運用として試してみたいと感じました。

仕組み・文化として

運用テストは実施しているけどPJメンバーが考えることなので、外部チームからブラックテスト的にAWSが準備したFISの対象サービスでFault Injectionが出来るような仕組み・文化を作ることが必要かな

Discussion