2021年02月25日 ウェビナー「はじめてのカオスエンジニアリング:Gremlin」のQAを公開します

2021.02.26

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

2021年02月25日 クラスメソッド株式会社主催「はじめてのカオスエンジニアリング:Gremlin」 でご参加頂いた方から頂戴した質問とその回答を公開します。

Q. Agentのインストールが必須条件ということでしょうか?Lambdaにアタックすることはかのうでしょうか?

A. ホストやコンテナへの攻撃にはAgentのインストールが必要です。Lambdaについては利用プログラミング言語がJavaの場合に限りますが攻撃が可能です。

Gremlinが用意しているライブラリを組み込むことで、AWS Lambdaへの障害の注入が可能です。

https://www.gremlin.com/docs/application-layer/libraries/

以下の様な攻撃が可能です。

  • インバウンド HTTP トラフィック

    アプリケーションのインバウンド HTTP トラフィックに影響を与えます。

  • アウトバウンド HTTP トラフィック

    アプリケーションの HTTP クライアントに影響を与えます。

  • Amazon DynamoDB トラフィック

    アプリケーションのAmazon DynamoDB クライアントに影響を与えます。

  • カスタムトラフィックタイプ

    カスタムトラフィックタイプを作成し影響を与えます。

https://www.gremlin.com/docs/application-layer/trafficcoordinates/

Q. 既存の障害検知との連携(ケア)はどうすればいいでしょうか。

A. 既存監視サービスによる障害検知・アラートも含めてシステムの信頼性を検証することも重要であると考えます。

本番障害とGremlinによる障害を区別するために、Gremlinによる攻撃の前に周知する仕組み(CI/CDに組み込んでいる場合は利用しているチャットツールへGremlinの攻撃が開始されることを通知する 等)を用意することが1つの案となります。

Q. テストに失敗した場合、最悪インフラの構成見直しまで手戻りが発生すると思いますが、経験上テストの実施タイミングはテストフェーズが最適でしょうか。もっと早いタイミングで実施した経験や知見などはありますか?

A. テストフェーズに限らず継続してGremlinを使ったシステムの信頼性の検証が必要になると考えます

お客様の開発の進め方にもよりますが、特定のフェーズに限定せず、APIを利用してCI/CDにGremlinによる攻撃を組み込み日々の開発業務で持続的に検証していくことが効果的であると考えます。

開発、テスト、ステージングと段階を踏んで検証を進め、最終的には本番環境でも継続して検証をすることが重要です。

GremlinはシンプルなWebUIとわかりやすいドキュメントが用意されているため、特定の環境やフェーズによらずスムーズに利用を開始できます。

Q. サーバの攻撃シナリオで、CPU100%と指定していたが、実際にNewRelicを参照したときにCPU利用率は60%くらいだったと記憶しております。実際にサーバのCPU100%になっていないのは、Gremlinの仕様上、仕方ないのでしょうか。

A. Gremlinによる攻撃中はCPU使用率が100%に到達している期間があります。

今回のデモンストレーション中にお見せしたNewRelicのグラフは、一定期間の平均値を表示していたため約60%程度のCPU使用率となっていました。

NewRelicのグラフをGremlinによる攻撃を実施していた1分間に拡大すると、CPU使用率が100%に到達している期間を確認できます。

デモンストレーション中に誤った説明をしてしまい、申し訳ありません。