[Gremlin] あなたの会社にカオスエンジニアリングを実装する方法の紹介です

#カオスエンジニアリング

#Gremlin

森亮介

2020.11.09

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

Gremlin社のリソースに組織内にカオスエンジニアリングとGremlinを実装するためのガイドが提供されているのでご紹介します。

内容

カオスエンジニアリングのための組織の準備
Gremlinをシステムに導入する
カオス実験を安全かつ自信を持って作成し,実行する
Gremlinをエンジニアリングチームのワークフローに統合する
CI/CDパイプラインの一部としてカオス実験を自動化する

カオスエンジニアリングのための組織の準備

カオスエンジニアリングの目標は、アプリケーションやシステムがどのように障害を処理するかをテストし、アプリケーションやシステムの信頼性を向上させることです。何の指示も監督もなしに無作為に実験を行っても、実行可能な結果は得られず、システムを不必要なリスクに晒してしまうことになります。

より良い手順は、

1.達成したい目的とKPIを定義する

達成したい目的はビジネスユニットによって異なる(経営陣、エンジニアリングチーム).

経営陣は長期的な目標に関心を持つことがほとんど。

- 新製品の立ち上げを成功させる
- 顧客満足度や製品の使用率を低下させる可能性のある、コストのかかる有害なダウンタイムを回避する
- 保守作業や手戻り作業、技術的負債を削減する

など。

エンジニアリングチームは短期的な運用目標に関心を持つことが多い。

- ダウンタイムとインシデント解決に費やす時間を制限する
- 変更による障害の発生率を減らす
- 信頼性を積極的にテストすることでアプリケーションのデプロイ速度を向上させる

など。

組織にとってどのような目標が重要であるかを考えることがだいじ。

もし、どの目標を設定すればいいかわからない場合は、過去１年間に経験したインシデントがヒントになる。

チームに以下のような質問をしてみましょう。

インシデントの性質は何か？ハードウェアの障害だったか？下流の依存関係の問題か？チームメンバーによる事故か？
どのようなシステムが影響を受けたか？一時的に利用できなくなったり、完全にオフラインになったりしましたか？通常のサービスに復旧するまでにどのくらいの時間がかかりましたか？
顧客への影響は？顧客はダウンタイムやデータ損失を経験しましたか？カスタマサポートチームはチケットの増加に対応しましたか？
レスポンスチームは、どのくらいの速さでインシデントを警告しましたか？それは自動監視ソリューションによって検出されましたか、それとも誰かが気付きましたか？オンコールの準備ができていましたか、それともレスポンスチームを緊急招集する必要がありましたか？
インシデントを解決するのにどのくらいの時間がかかりましたか？障害を解決または緩和する自動化されたシステムがありましたか？バックアップからのリストアが必要でしたか？
問題はどのように解決されましたか？その場しのぎの修正で、本番環境にしか存在しないものでしたか、それとも修正をコードベースにマージしましたか？修正を文書化しましたか？
その結果、どのような組織変更が行われましたか? このインシデントの責任者はいましたか? 将来的に問題が発生しないようにするためのポリシーは実施されましたか?

未回答のままになっていたり、チームが回答するのに苦労した質問に焦点を当てる。

2.初期実験の対象とするシステムを選択し、優先順位をつける

目的とKPIが分かったら、それらのKPIに直接影響を与えるインフラの部分を特定する必要がある(ここでGremlinを使ってカオス実験を行います)。実験を行い、KPIがどのように変化するかを確認することで、より効果的に修正を計画し、実施することができます。

過去1年以内にインシデントを経験した場合、そのインシデントを再現することから始める
- 関与したシステム（またはそのテスト/ステージングに相当するシステム）を特定し、インシデントの原因となった状況
最も多くの顧客に影響を与えたもの、最も多くの時間外アラートが発生したもの、または解決に最も費用がかかったものを選択する
ビジネスにとって重要なシステムをターゲットにすることが推奨されている

何から始めればわからない場合は、以下の記事で紹介した信頼性を測定するツールを使い一番評価が低かったサービスを選択するのも良い。

3.目標に向かっての進捗状況を追跡するのに役立つメトリクスを特定し、追跡する

目的に向かっているかどうかを判断するには、システムの内部状態を測定して追跡する必要がある。アウトプットに基づいたシステムの内部動作の測定値であるオブザーバビリティを使用することで可能。

※ オブザーバビリティとは

オブザーバビリティ・データを収集することで、パフォーマンス、キャパシティ、スループットなど、システムのさまざまな属性を定量化することができるようになる。現在のシステムがどのように動作しているかを理解するのに役立つだけでなく、過去のデータと比較して、システムが時間の経過とともにどのように変化してきたかを知ることができます。

ビジネス指向の目標には、以下のようなビジネス効率と顧客満足度に関連したメトリクスが含まれます。

ネット・プロモーター・スコア（NPS）とソーシャル・プロモーター・スコア（SPS）
- 顧客が当社のサービスにどれだけ満足しているか、また、顧客が当社を宣伝する可能性がどれだけ高いか。
Meaningful availability
- お客様が当社のサービスの可用性をどのように認識しているか
Recovery Time Objective (RTO) および Recovery Point Objective (RPO)
- 災害後の復旧にかかる時間と、障害が発生した場合に損失を許容できるデータ量

エンジニアリング指向の目標については、以下のようなアプリケーションとインフラストラクチャの健全性に関連したメトリクスに焦点を当てます.

サービスレベル目標
- システムの長期的な可用性の目標レベル。これらは、顧客が期待すべきサービスの標準を定義するのに役立つため、エンジニアリングチームとビジネスの両方にとって重要な指針となります。
ゴールデンシグナル
- レイテンシ、トラフィック、エラー率、およびリソースの飽和度。
平均故障間時間（MTBF）
- 故障間の平均時間。MTBFが低いということは、システムが頻繁に障害を起こしていることを示しています。
平均検出までの時間（MTTD）
- インシデントが実際に開始されてから検出されるまでの時間の平均的なギャップ。MTTDが低いということは、効果的なモニタリング戦略が確立されており、問題に迅速に気づくことができることを意味します。
平均解決までの時間（MTTR）
- インシデントの開始から解決までの時間の平均的なギャップ。MTTRが低いということは、チームがインシデントの検出と解決に効果的であることを意味します。

4.カオス実験を実行するためのチームの準備

カオスエンジニアリングの実践はエンジニアリングチームが主だが、組織の他のすべての部分を巻き込んでいる。

システムに障害が発生すると、社内のユーザーや顧客など、そのシステムを使用するすべての人に影響を与えるリスクがある
全く意図しない種類の障害を引き起こす可能性がある

テストしているシステムの所有者を実験の設計と実行に参加させ、システムが故障した場合に利用できるようにすることが重要。組織全体に拡大していく中で、サポートチーム、エグゼクティブチーム（特に CTO）、開発者支援チームなど、実験の影響を受ける可能性のあるエンジニア以外のチームにも情報を提供すべきである。

このプロセスの進め方がわからない場合は，組織内でカオスエンジニアリングを推進するためのガイドを読んでください。

Gremlinをシステムに導入する

カオス実験の実行は、ランダムなシステムに対してランダムな攻撃を実行するのと同じくらい単純ではないので、実験は慎重で制御されたプロセスで行われなければいけない。

実験を開発する時は、

1.仮説を立てます
- 例) CPU使用量が増加しても、リクエストのスループットは一貫している
2.可能な限り最小の爆風半径を定義します
- 爆風半径にはテストの影響を受けるすべてのコンポーネントが含まれます
- 可能な限り最小の爆風半径から始めることを強くお勧めします。カオス実験の実行に慣れてきたら、爆風半径を大きくして、より多くのコンポーネントを含むようにすることができます
3.インフラストラクチャを監視
- 仮説について結論を出すのに役立つメトリクスを決定
- ベースラインを確立するためにテスト前に測定を行い、テスト中にそれらのメトリクスを記録することで、予想される変化と予想外の変化の両方を監視することができます
4.実験を実行
- 実験を開始する前に、実験を停止し、導入した変更を元に戻す方法があることを確認することがだいじ
5.データを分析し、結論を出します
- 仮説が正しいのかそうでないのか、結果を利用してシステムの障害点に対処し、実験を洗練させる。

以上のフローに従いましょう。

そして、実験対象のシステムにGremlinクライアントをインストールします。

最初の実験では、実験の一部としてテストする予定のシステムにのみ、Gremlinクライアントをインストールすることをお勧めします。使用に慣れてきたら、クライアントをインフラストラクチャの残りの部分にデプロイします。

カオス実験を安全かつ自信を持って作成し,実行する

実験の概要を説明し、システムにGremlinをデプロイしたところで、実験の実行方法を説明します。ベースラインを確立する、攻撃を実行する、結果を分析する、ソリューションを実装した後に実験を繰り返す、という4つのアクションに焦点を当てます。

ベースラインを確立する
- 実験中にシステムがどのように変化したかを測定するには、システムが現在どのように動作しているかを理解する必要がある
- 通常の負荷下でのターゲットシステムから関連するメトリクスを収集する。これが比較のベースラインとなります
- モニタリングソリューションを使おう(Zabbix,Datadog,New Relicなど)
攻撃を実行
- Gremlinのウェブアプリには、攻撃とシナリオという2つの方法で実験を実行する方法がある
- 攻撃とは、計算リソースを消費したり、システムをシャットダウンしたり、ネットワークパケットを落としたりするなど、システムに障害を注入する方法
- シナリオは攻撃の集合体で、タイトル、説明、仮説、および詳細な結果とともに保存することが可能
  - 攻撃の実行方法をより細かく制御でき、複雑な障害を再現することができる
  - 同じ実験を繰り返したり、時間の経過とともにシステムがどのように振る舞うかを観察することができる
  - スケジューリングも可能
- 攻撃の実行に合わせてメトリクスを記録し、可能であれば、関連するKPIをリアルタイムで監視する
- 攻撃がシステムに予期せぬ問題を引き起こしている場合（反応しなくなったなど）、Gremlinウェブアプリの右上隅にある Halt ボタンを使用してテストを停止する
- 失敗したカオス実験でさえ信頼性の重要な指標となるため、この結果を必ず記録する
結果を分析する
- 実験から得られたデータを使って、観察結果を仮説と比較して結論を出す
- 将来的に問題が発生しないようにすることを目標に、以下のような質問に取り組む
  - システムは予想通りに動作しましたか？
  - フェイルセーフシステムがある場合、それらは意図した通りに動作しましたか？
  - 実験の結果、どのような新しいバグが発見されましたか？
  - アラートシステムはどのくらいの速さで問題を検出し、通知しましたか？この時間は、サービスレベル目標（SLO）に照らして許容範囲内ですか？
  - 観測性ツールは、主要なメトリクスをどの程度追跡しましたか？ノイズを減らしたり、より意味のあるデータを収集するために何か変更がありますか？以前のインシデントを再現している場合、その結果は、我々が経験したものとどの程度密接に一致していますか？
  - 実験後、システムは自動的に正常な状態に戻りましたか、それとも手動での介入が必要でしたか？
- 収集した観測データと実験から得られた洞察をエンジニアに提供することで、信頼性向上のための効果的な意思決定を行うためのリソースをエンジニアに提供することができます
実験を繰り返す
- 修正プログラムを実装したら、その修正プログラムが根本的な問題に対応していることを確認するために、実験を繰り返します
  - システムが攻撃に耐えられた場合は、攻撃の規模（深刻度）を大きくすることを検討
  - 爆発半径を増やすことも検討(クラスタ化されたシステム、オートスケーリングシステム、負荷分散されたシステムをテストする場合に特に有効)
- これらの結果に基づいて、システムと実験を改良し続けりゅ
- 攻撃に耐える能力に自信が持てたら、通常のテストの一環として実験を定期的に実行し始める
  - Gremlin APIを使って自動化することが可能
  - Gremlinをプリプロダクションパイプラインに完全に統合し、通常のテスト方法と並行してカオス実験を実行し、本番環境にデプロイした後に実験を繰り返して信頼性を検証することができる

Gremlinをエンジニアリングチームのワークフローに統合する

カオスエンジニアリングを早期に導入するための鍵は，安全に，小規模から始めることです。エンジニアリングチーム全体を同時にカオスエンジニアリングに導入するのではなく、1つのチームから始めるとよい。 Gremlinによるカオス実験で、システムの問題を発見して修正したり、エンジニアリングチームが停止に対応するために使用できるランブックを開発したりしてください。

システムが障害にどのように反応するかを理解し、チームがこれらの障害に対応するための計画を持っていることを確認したら、FireDrill（避難訓練)の実行を開始します.

※ FireDrill

実世界の障害に対してチームとランブックの両方をテストするために設計された段階的なインシデント。

チームがインシデント対応プロセスに慣れるのに役立ち、実際の本番インシデント時の対応時間と平均解決時間（MTTR）を短縮できる
新入社員をトレーニングし、適切なツールを使用できるようにし、ランブックに従うことができるようにする機会でもある。
毎月または四半期ごとに FireDrillを実施することで、チームを定期的にテストし、チームの自己満足を防ぐことができます

1つのチームで成功を証明したら、他のチームでもこのプロセスを繰り返します。

最初に始めるのに最適なのは、先ほどテストしたシステムに依存するチーム
- 最初の実験をデータベースチームで行った場合、バックエンドのWebチームでGameDayを行う
- 両方の機能を横断して実験を実行したりすることを奨励
- 経験豊富なチームが成熟していないチームを指導することを可能にし、組織全体がカオスエンジニアリングに心を開くのに役立つことが多い

CI/CDパイプラインの一部としてカオス実験を自動化する

もし本番前の環境（テスト環境やステージング環境など）でしかカオス実験を行っていないのであれば、カオスエンジニアリングの真価を十分に引き出していないことになります。

本番環境での実験が必要な理由
- プリプロダクションは本番環境を正確に再現できない。アーキテクチャや使用パターンのわずかな違いでさえ、アプリケーションの動作が劇的に異なることがあり、その違いを完全に再現することは不可能である。
- 創発的な動作は、特に複雑なシステムでは時間の経過とともに発生します。プリプロダクションではこれらを再現できないだけでなく、常に予測することもできません。
- 本番は顧客が使用しているものです

本番環境での実験となると、チームがリスクを回避するのは当然のことで、慎重かつ戦略的にアプローチしなければなりません。

本番環境でのテスト戦略
- ブルーグリーンデプロイメント
  - 2つの同一の本番環境を並べて実行し、1つはフェイルオーバーとして動作します。
- カナリア型デプロイメント
  - 新しいデプロイメントや実験を、全ユーザーに展開する前に、一部のユーザーやインフラストラクチャに限定しています。
- ダークローンチ
  - ユーザーのトラフィックをライブシステムから別のシステムにコピーします。これにより、実際のトラフィックを使用して実験を行うことができますが、そのトラフィックを提供するシステムに影響を与えることはありません