【カオスエンジニアリング】 仮説バックログ作成ワークショップ@オンライン をやってみた

こんにちは。AWS事業本部のKyoです。

以前告知させていただきましたように、 クラスメソッドでは、New Relic様と合同でカオスエンジニアリングへの取り組みを行っています。

今回はその第一弾として、仮説バックログ作成ワークショップを行いましたのでレポートいたします。

概要

カオスエンジニアリングの実験を行うにあたって重要なのが仮説です。 「事象Xが起こったとしても、定常状態が変化しない」という仮説のもとに実験を行うことになります。※

※実験では、システムのの弱点をあぶり出すことが目的であり、弱点が分かっている場合には実験を行う前にまず改修を行います。

仮説バックログは、仮説を集めて優先順位をつけたものです。

今回はDevelopers.IOについて分析を行い、この事象Xを洗い出すことで、仮説バックログを作成しました。

参加メンバー

クラスメソッドから4名。New Relicから4名。トータル8名でした。

今回はエンジニアがほとんどでしたが、システムのビジネス要件が重要となってくるため、ビジネスサイドのメンバーにも可能な限り参加してもらうと良いと思います。

準備したもの

• システム構成図

AZやスケーリングの有無などもう少し詳細なものを準備できれば良かったと思います。

また、今回は省略しましたが、認識を揃える上で以下も準備すべきであったと思います。

• システムのビジネス要件
• 運用体制

必要時間

トータルで1.5時間程度でした。

ここは参加人数やアーキテクチャによって大分変わりそうです。

今回は、初めての試みであることもあり、「もうこんなに時間経ってる！？」とちょっとギリギリな感じがありました。初回はバッファを見込んでおくと良いかもしれません。

進め方

全員で共同編集できるGoogle スプレッドシートに基本情報、定常状態、仮説バックログの３つのシートを作成しました。

※参加者が同時に編集できるスプレッドシートであれば他のツールでも問題ありません

基本情報、定常状態のシートを作りながら参加者の認識を合わせ、最終的に仮説バックログを作成していきます。

基本情報

システム構成図をはじめ、参加者間で共有しておきたい情報をまとめます。 運用体制やビジネス要件などもこのシートにまとめられると良いと思います。

定常状態

ビジネス要件をモニタリング可能なメトリクスに落とし込む作業です。

これを考える際に、SRE本でも言われているThe Four Golden Signalsを参考にしました。

モニタリングの4つのゴールデンシグナルは、Latency、Traffic、Erros、およびSaturationです。もしシステムから限られたメトリクスしか測定できないのであれば、これらに焦点を当ててみましょう。（意訳）

• Latency
• Traffic
• Errors
• Saturation

Saturationは他と比べるイメージしづらいと思ったので、説明を貼っておきます。

サービスがどの程度「フル」であるか。システムの割合を示す指標で、最も制約の多いリソースを強調します（例：メモリに制約のあるシステムでは、メモリを表示、I/Oに制約のあるシステムでは、I/Oを表示）。多くのシステムでは、100%の利用率を達成する前にパフォーマンスが低下するため、利用率の目標を持つことが不可欠であることに注意してください。

これらをもとに、ユーザ（今回は閲覧者と投稿者を想定）にとって上記のシグナルがどのようなメトリクスで取得できるかを考えます。

決まったメトリクスの一例を示します。

• DevIOの閲覧者のTraffic → New Relic Browserの PageView Count
• DevIOの投稿者のErros → New Relic BrowserのErros

仮説バックログの作成

仮説を構築し、影響度をベースとした優先順位付けを行いました。

仮説の構築

以下の観点から仮説の構築を行いました。

• 過去に起こった事象から集める
• 質問をして集める
  • どのあたりが心配？
  • xxxが起こったら…
  • xxxは止まる可能性があるか
  • 前に問題が起こったことはあるか
  • これが止まったら他にどんな影響がある？

構成図を見ながら少しだけ考える時間をとった後、タイマーをセットし、皆で一斉にスプレッドシートに書きこみを行いました。 ここではブレスト的な感じでとにかく量を出すことを重視しました。

タイマーが鳴った後、出た仮説を順に確認、より具体的なストーリーにブラッシュアップを行いました。

仮説の影響度の見積もり

その後、各仮説の影響度を決めていきます。方法として、今回なプランニングポーカー（見積もりポーカー）を利用しました。

参考: ゲーム感覚で工数見積もり！プランニングポーカーを使ってみました （モノサス様Webサイト）

簡単に言うと、影響度を1-5段階に分け、参加者が「いっせーのーで」で指の本数でシステムへの影響度を示します。

影響度2の場合は以下のような形です。シンプルですね。

ポイントとしては、「リージョン障害は影響度5」のような形で最初に何か基準になるものを最初に決めると良いようです。 プランニングポーカーに対してのアイスブレイクにもなります（私も未経験でした）。

今回は時間の関係で省略しましたが、起こりやすさも同様に検討すると良いと思います。 影響度と起こりやすさが明らかにできれば、以下のグラフにプロットすることで、仮説バックログを俯瞰して見ることができます。

実験のための仮説を選ぶ

作成した仮説バックログの中から実験に使う事象および仮説を選びます。 初めての実験ということで、まずは影響度が低いものを選ぶことにしました。上記のグラフでいうと、左下あたりのイメージですね。

検討の結果、選ばれた事象は、「CloudFrontのキャッシュが不意にクリアされる」です。

よって仮説は、「CloudFrontのキャッシュが不意にクリアされても、Developers.IOの定常状態は変化しない」となります。

一般的にキャッシュクリアはサーバーサイドの負荷上昇に繋がります。実験において、Developers.IOの各種メトリクスはどのように変化するでしょうか。

所感

以上がカオスエンジニアリングの実験のための「仮説バックログ作りワークショップ」でした。

大事だなと感じたことは、以下の２つです。

• 立場が違えば重要視するポイントが変わってくるので、とにかくステークホルダーを巻き込むべし
• アイデアを出すタイプのミーティングは雰囲気作りがカギになってくるので、ファシリテーションは非常に重要（オンラインでは特に！）

次回はこの仮説をもとに実験デザインを行う予定です。

以上、何かのお役に立てれば幸いです。