Gremlinの攻撃シナリオの紹介 [Chaos Engineering]

システムに対して負荷テストを行うときはテストシナリオを作成して実行することがほとんどだと思います。 シナリオテストができるツールではJMeterが有名ではないでしょうか。 シナリオを作っておくことにより過去に行った負荷を再現でき、テストの自動化にも役に立ちます。

過去記事でもご紹介したシステムに障害を挿入するための攻撃をシミュレートできるFaaS(Failure as a Service)の Gremlinでも攻撃のシナリオを作成、実行することが可能です。

本記事ではGremlinで推奨されているシナリオのご紹介をしていきたいと思います。

シナリオについて

Docからの引用

シナリオは、タイトル、説明、仮説、および詳細な結果を使用して定義する一連のグレムリン攻撃です。シナリオを作成して構成すると、爆発半径（攻撃に含まれるホストの数）と規模（攻撃の強さ）が拡大する一連の攻撃が実行されます。シナリオを実行するたびに、観察を簡単に記録できます。 シナリオは、システムに影響を与えた過去の停止を再現するために使用できます。また、一連の攻撃を自動化して、カオスエンジニアリング実験の爆風半径を反復的に拡大するために使用できます。

構成要素として

• 名前
• 説明
  • テストしているサービス、シナリオのユースケース、またはそのシナリオを使用する場合とそうでない場合を含めると役立つ
• 仮説
  • シナリオ内で一連の攻撃が実行されたときに、アプリケーションまたは環境がどのように動作するかを予想
• 攻撃
  • CPU,Shutdown,Latencyなどの攻撃を追加
  • シナリオに含めることができる攻撃タイプは1つだけ
  • シナリオに追加する各攻撃の間に5秒の遅延が追加されます。この遅延は、秒、分、または時間の任意の数に設定可能
• 対象
  • タグを使用してシナリオ内の攻撃のターゲットを選択

があります。

参考

攻撃の種類: https://www.gremlin.com/docs/infrastructure-layer/attacks/#resource-gremlins

シナリオ実行の監視と結果

シナリオを実行すると、視覚化されてリアルタイムで監視が可能です。 実験の効果をすばやく確認し、将来の参照のために結果を保存することもできます。

推奨シナリオ紹介

Docからの引用

推奨シナリオは、実際の障害モードをテストするため、または例として使用してニーズに合わせてカスタマイズするために作成された、事前構成されたシナリオです。推奨シナリオには、名前、説明、仮説、および攻撃構成があります。攻撃したいターゲットを追加するだけです。

Validate Auto-Scaling(自動スケーリングを検証する)

CPU使用率を増やして、自動スケーリングが適切に構成されていることをテストします。

攻撃タイプはCPU

環境例

EC2のCPU使用率をメトリックスを元にインスタンス数を増減するAutoScaling Groupを使用したシステム

仮説

CPU使用率が上昇し設定されたしきい値に達する/CPU使用率が低下すると、アクティブなインスタンスが増減します。 ユーザーセッションは、エラーをスローせずにアクティブのままになります。

Prepare for Host Failure(ホスト障害へ備える)

一定の割合のホストをシャットダウンして結果を観察することにより、クラウドベースのインスタンスを採用する準備をします

攻撃タイプはShutdown

環境例

AWSやGCPなどのパブリッククラウドのインスタンス, VMwareの仮想マシン, 物理サーバーを利用したシステム

仮説

ホストが故障したり、シャットダウンしたり、オフラインになったりしても、ユーザーが影響に気づくことなくワークロードが分散され、エラーが発生することはありません。

Unreliable Networks(信頼できないネットワーク)

増加するホストに2秒の遅延が追加されるため、クライアントが問題なく応答し続けることを検証できます

攻撃タイプはLatency

環境例

マイクロサービスアーキテクチャを使用したシステム(頻繁にAPIコールが起こる)

仮説

ホストの数が増えてくるとレイテンシーが加算されるため、本サービスを利用しているクライアントはエラーが発生することなく対応し続けます。

Unavailable Dependency(利用できない依存関係)

システムで使用しているサービスの1つまたは多くが断続的または応答を停止した場合、アプリケーションは正常に失敗しますか？ 一度に1つのサービスをテストすることから始めます

攻撃タイプはBlackhole

環境例

コンテンツ(画像、動画など)をS3に置いて配信しているシステム、外部/内部のAPIコールを行っているシステム

仮説

依存関係が利用できない場合、ユーザーエクスペリエンスは正常に失敗します。機能が低下し、必須ではない依存関係ではユーザーには透過的に表示され、依存関係が必須であった場合は関連するエラーが表示されます。

Region Evacuation(リージョンの避難と災害復旧の準備)

災害対策を実証できるように、リージョンへのブラックホールトラフィックを実施する

攻撃タイプはBlackhole

環境例

メインで使用しているAWSリージョン以外のDR環境を持っているシステム

仮説

リージョンが利用できなくなると、トラフィックは指定された利用可能なリージョンにフェイルオーバーし、自動または手動でトリガーされます。 これらのリージョンは、ユーザーにエラーを発生させることなく、増加したトラフィックを処理します。

DNS Outage(DNSの停止)

内部または外部のDNSトラフィックをブロックして、単一障害点を特定できるようにします

攻撃タイプはDNS

環境例

DNS問い合わせが必要なシステム(サーバーを利用している)

仮説

プライマリDNSに障害が発生した場合、ユーザーはエラーなしでアプリケーションにアクセスできます。

Monitoring & Alerting Verification

重要なシステムの監視と警告が期待どおりに機能することを検証します

攻撃タイプはCPU

環境例

障害発生時にアラートを飛ばしている、システムに関連する様々なメトリクスをモニタリングしているシステム

仮説

GremlinがCPU攻撃を実行すると、監視ダッシュボードでCPUのスパイクを確認できるようになります。CPUスパイクの異常について通知されます。ダッシュボードでCPUの増加を確認します。

On-Call Training

エンジニアがオンコールになるようにトレーニングします。

環境例

ホストがシャットダウンした際、しかるべきエンジニアに通知して復旧できる体制を作っているシステム

仮説

このシナリオを実行すると、ホストがシャットダウンします。このシナリオは、オンコールトレーニングプログラムの最初のステップとして使用します。

最後に

Gremlinが提供している攻撃シナリオをご紹介しました。 これらを自分たち専用にカスタマイズすることも可能となっているので、Chaos Engineeringを実施するときの助けになるかと思います。

また、今回は書いていないですが、Kubernetes環境への攻撃シナリオも用意されています。 別の機会にでもやってみた記事等して投稿できればと思っています。

広告