この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは。AWS事業本部のKyoです。
前回のブログで告知した、本ブログDevelopers.IO（以下DevIO）でのカオス実験を実施したのでレポートします。
今回の実験はカオスエンジニアリングにおける「Gameday」ですが、現在Gamedayという言葉が従来よりも広い意味で使われているため、「カオス実験」と表記しています。
実験のゴール
カオスエンジニアリングの事例は世の中にいくつか出ていますが、ほとんどが海外の話です。 そこで、やってみるの精神のもと、自分たちで実際にやってみて想定と違った部分、改善点などの情報を集め、自分たちなりの方法論を作りたいと思いました。今回は初回ということで、肩ならし的な意味も含め以下をゴールとしました。
- 現在の体制（チーム、システムともに）で、安全に実験を行えることの確認＆参加者の経験値獲得
実験概要
実施日時
- 2020/8/31 15:00 - 16:00
- 操作自体は15min程度 （障害注入〜現状回復）
実験の流れ
予定時刻にGoogle Meetsにて集合、以下の流れで実験を行いました。
- 実験のゴールと実験概要の確認
- 仮説の確認
- New Relicダッシュボードの確認
- Slackで開始通知
- AWS CLIにてキャッシュクリア（Invalidation）
- New Relicダッシュボードの確認
- Slackで終了通知
- ふりかえり
情報の共有
New Relic社との合同プロジェクトなので、双方からアクセスしやすいSlackチャンネルに情報を集約しました。また補助的にGoogle Docsも利用しました。
- Classmethod, New Relicの合同Slackのnotifyチャンネル
- New Relicからのアラートも設定済み
ロール
オライリーのカオス本に従って、参加メンバーから以下のロールをアサインしました。今回は小規模な実験であったため、兼務もアリとしました。
- Designer/Facilitator（ファシリテーター）
- 実験のデザインおよびディスカッションをリード
- Commander（障害注入役）
- 障害注入の操作を実行
- Scribe（書記役）
- 実験の開始と終了および発生している事象についてSlack等のコミュニケーションツールでメモ
- Observer （メトリクス観測役）
- 関連するグラフを見て、グループの他のメンバーと共有
- Correspondent（アラート監視役）
- アラートを監視し、現在の待機メンバーが実験の発生と予想される影響を認識していることを確認
※名称の和訳は個人の解釈です。
仮説
DevIO フロントエンドのCloudFront（下図の赤枠中）のキャッシュが不意にクリアされても顧客満足度（Apdex）に影響は10％未満、その影響も10-20秒程度でベースラインまで回復する。
なお、対象のCloudFrontの前段のEC2はNginxが動作しており、キャッシュを保持しています。そのため、影響はかなり小さいことを想定していました。
DevIOのアーキテクチャの詳細については以下をご覧ください。
Apdexの概念や主要なビジネスメトリクスとして選択した理由については以下も参照ください。
想定される影響
- フロントエンド
- トラフィックの10%に満たないレベルで、ページ応答速度が1-1.5秒程度低下
- インフラ
- CloudFront、API Gateway、Lambdaの実行数が微増
- WordPressのELB応答時間が少し劣化（Lambda経由で叩かれるWordPressのAPIが遅いため）
- （至らない筈だが）DB過負荷となったら、DB Load、Lambdaの実行時間が悪化
非常時のロールバック方法
- 低リスクな実験のためロールバック方法はなし
- キャッシュは10-20秒で回復
- 不測の事態に備えてブログ運営チームは待機しておく
実験方法
AWS CLIによるキャッシュクリア
AWS CLIを用いて以下のコマンドで行いました。また、出力結果は記録しておきました。
CloudFront create-invalidation
New Relic ダッシュボードでの関連メトリクスの経時的変化を確認
ApdexやCloudFrontのエラーレートなど関連項目一式をダッシュボードにまとめておきました。
結果
キャッシュクリアを15:19に実施しているため、以下の画像では15:20にカーソルを合わせています。
また、値の振れ幅を示すため前後1時間も合わせて表示しています。
まずは主たるメトリクスとなるApdexからです。
前後1時間のデータを加味して考えると、変化はないと判断できます。
LambdaのInvocationsについても見てみます。
こちらも変化は見られませんでした。
考察とふりかえり
変則的なYWT法で行いました。5分ほど時間をとって、「やったこと」、「わかったこと」、「気になったこと」について参加者全員で一斉にGoogle Docsに書き込みました。
やった
- DevIOフロントエンド CloudFrontのキャッシュクリア
- New Relicによる影響の観測
わかった
- 簡単で良いので実験についての認識合わせのための説明はたぶん必要（ドキュメントになってるとなお良い）
- 仮説が真であることが示された（キャッシュクリアは顧客満足度に影響しない）
- CloudFrontのキャッシュの役割は意外とない
- Lambdaの実行回数はそんなに変わらなかった
- Lambdaの実行時のエラーとキャッシュクリアは相関がなかった
気になった
- 事象を起こす対象が正しいことを直前に確認するのが難しかった
- 対象が本当に正しいかダブルチェックする必要がある
- フロントのNginxのキャッシュの具合がきになったので、素早く知りたい
- フロントのNginxが再起動（もしくはインスタンス入れ替え）してキャッシュがクリアされたときの、CloudFront以降の挙動が知りたい
- 実施前に仮説上New Relicのどの部分がどう反応するかアタリを付けたい
- 事前の設計セッションを丁寧に
- できるだけ広くのメンバーが参加したほうがいい？
- 多角的に検証する方法を準備できればよいと思った
- 可能であれば事前に評価する項目を洗い出しておくとよい
- CloudFrontのキャッシュが本当にクリアされているのか気になった。
- AWS マネジメントコンソールで目視
- 「絶対に変化するもの効果があるもの」が必要だと思った
- スループットとLambdaの実行回数の比率が気になった
- リクエスト数と記事の偏り具合が気になった
- キャッシュクリア前後でキャッシュなしの記事へのリクエストがどれくらいなのか気になった。
- ロールのアサインは考えた方がいいかも？ロールによっては一人で複数もつと大変
結論
DevIOフロントエンドのCloudFrontのキャッシュが不意にクリアされても顧客満足度に影響しない
所感
今回の実験によってDevIOは「不意にフロントエンドのCloudFrontのキャッシュがクリアされる」という障害に対して自信が持てるようになりました。
ただし、これは今回検証した条件においてのみです。ふりかえりの中で出てきた「Nginxがキャッシュを十分に保持していない状況」や「ハイトラフィックな状況」ではまた違う結果かもしれません。 これらについても状況を作り出し、システムの挙動を実験的に知ることができるのがカオスエンジニアリングの面白さだと思います。
以下についてはやってみて感じたことです。
それぞれのメトリクスの関係性をもう少し強くイメージできていればよかったと感じました。ダッシュボードを作ってはいたのですが、メトリクスの関係性などについて参加者間で共通認識を持てる形の補足があると良いと思いました。
実験系自体が成り立っていることを示すためのコントロールを設定できないか、というところを詰めてみたいと思いました。
ロールについても、自分が進行を行う「Designer/Facilitator」と障害注入を実施する「Commander」を兼ねたのは少し大変に感じました。できればこれらには別の担当をアサインすると良いと思いました。
初回の実験として、注入する障害を小さいものにしたことは正解であったと思います。今回の学びを取り入れながら次回はもう少しインパクトのある障害注入を行ってみたいと考えています。
おわりに
AWS Well-Architected Frameworkでも推奨されるようになったカオスエンジニアリング、まずは小さな仮説から実験を考えてみてはいかがでしょうか？
0
