カオスエンジニアリングとは？入門、定義、その他

カオスエンジニアリングの詳細と、カオスエンジニアリングが開発サイクルを次のレベルへ引き上げる方法についてご紹介します。

ソフトウェアやシステムの開発は、イノベーションと未知なるものを解決するための訓練です。ソフトウェアやシステムは、さまざまな意見やスキルを持つ人間（多くの場合、複数の人間）によって作られているため、誤りを犯す可能性があります。特にマイクロサービスの推進により、テクノロジーはより分散し、より複雑になっています。一人の人間がシステム全体についてエンドツーエンドの知識を持つことは稀です。

状況認識に関する軍事用語「戦争の霧」と同様に、現代の開発では、変更の全体的な影響を理解することが難しくなっています（開発の霧ですね）。システムが常に利用可能であることを求めるユーザーの期待と相まって、システムの堅牢性と回復力を未知の領域に対してテストすることは、まさに「未知」であるといえます。

カオスエンジニアリングは、アプリケーションとインフラのスタック全体に障害を発生させ、エンジニアが動作を検証し、障害がユーザーに現れないように調整することで、未知の問題に対処することを支援します。カオスエンジニアリングは、site reliability engineering（SRE）の高まりと相まって、ありえないことがもたらす影響を計算しようとするものです。

カオスの歴史

サイト信頼性エンジニアに人気のある読み物は、Nicholas Talebの「The Black Swan: The Impact of the Highly Improbable」（2007年）です。Taleb氏は、この本の中でブラックスワンの比喩を紹介しています。Taleb氏は、ブラックスワンの事象を、突然の自然災害や、著書出版当時のビジネスでは、Googleの驚異的で前例のない成功などに分類しています。ブラックスワン現象には3つの特徴があります。予測不可能であること、その影響が大きいこと、そして、それが終わった後、ブラックスワンのランダム性が低く見えるような説明を考案することです。

開発という霧の中にいると、コンピューター科学者のPeter Deutschが主張した「分散コンピューティングの誤謬」に陥りがちです。ネットワークは信頼できる」「遅延はゼロ」「帯域は無限」「管理者は一人しかいない」などが代表的な誤りです。このような誤りを突き詰めれば、サービスは一貫性を持ち、常に利用可能であることになります。しかし、未知のものを開発するときは、このことを忘れてしまいがちです。

例えば、オブジェクトの保存にAmazon S3に依存するような機能を構築しているとします。複雑な処理を行うサービスの機能を構築しており、最終的な出力がS3にオブジェクトを書き込んだり更新したりする場合、エンジニアとしてS3があることを前提にするかもしれません。私たちは機能を上下に分けてテストし、S3部分にはあまり洗練されていないテストカバレッジを提供します。Amazon Web Servicesは2017年にS3が障害に見舞われ、自らブラックスワンのような事象を起こしました。そこにあると想定していたものが（パフォーマンス／書き込みSLAを下げても）なく、分散コンピューティングの誤謬が私たちに襲いかかったのです。

S3の停止は、私たちがスタックのあらゆる部分に触れることを確認することに光を当てるのに本当に役立ちました。たとえ私たちが触れる部分が明白に見えないとしても、おそらく分散コンピューティングの誤謬に関する私たちの認識や霧が原因でしょう。カオスエンジニアリングとカオス実験は、制御されたカオスをもたらし、私たちはこの種の事象を振り払うことができます。

カオスエンジニアリングとは？

カオスエンジニアリングとは、システムに意図的に障害を発生させ、回復力を測定する科学です。他の科学的手法と同様、カオスエンジニアリングは実験や仮説に焦点を当て、その結果をコントロール（定常状態）と比較します。分散システムにおけるカオスエンジニアリングの典型的な例は、ランダムなサービスを停止させて、アイテムがどのように反応し、ユーザージャーニーにどのような不利益が現れるかを見ることです。

アプリケーションの実行に必要なもの（計算、ストレージ、ネットワーク、アプリケーションインフラ）を横断的に捉え、そのスタックの一部に障害や乱流状態を注入することは、有効なカオスエンジニアリングの実験となります。ネットワークの飽和やストレージの突然の揮発や容量不足は、テクノロジー業界ではよく知られた失敗ですが、カオスエンジニアリングでは、これらの失敗をはるかに制御してテストすることが可能です。影響を受ける可能性のあるインフラストラクチャーの範囲が広いため、カオスエンジニアリングのユーザーと実践者は、アプリケーション/インフラストラクチャーのスタックをサポートするほぼ全ての人になる可能性があります。

カオスエンジニアリングは誰が使っているのか？

カオスエンジニアリングの実験には、複数の利害関係者が存在する可能性があります。なぜなら、カオスエンジニアリングが扱う技術や判断は広範囲に及ぶからです。爆発範囲（テストや実験で影響を受けるもの）が広ければ広いほど、より多くの利害関係者が関与することになります。

アプリケーションスタック（計算、ネットワーク、ストレージ、アプリケーションインフラ）のどの領域で、対象となるインフラがどこに存在するかによって、それらのチームの関係者が関与する可能性があります。

爆発半径が小さく、実行中のコンテナでテストできる場合、アプリケーション開発チームはコンテナからの脱走を恐れることなくテストできます。ワークロードやインフラの爆発範囲が広い場合（例えば、Kubernetesインフラのテスト）、プラットフォームエンジニアリングチームが関与する可能性が高いです。未知のものに対するカバレッジを提供することが、Chaosテストを実行し、弱点を探すことの核心的な理由です。

なぜカオステストを行うのか？

特に大規模な分散システム、複雑なシステム、マイクロサービスの実装では、開発の霧はかなり現実的なものです。アプリケーションの観点からは、個々のマイクロサービスは個別にテストされ、設計通りに動作していると判断されるかもしれません。通常のモニタリング技術では、個々のサービスが健全であると判断されるかもしれません。

マイクロサービスのパターンでは、１つのリクエストが複数のサービスを経由して、ユーザーや他のサービスが要求したものを満たすために集約されたレスポンスを得ることができます。サービス間の全リモートリクエストは、追加のインフラストラクチャーを通過し、異なるアプリケーションの境界を横断し、全てが失敗する可能性があります。

もし、些細なサービスやインフラがSLA（サービスレベルアグリーメント）内で応答しなかった場合、システムの能力やユーザーの旅はどのような影響を受けるのでしょうか？これこそが、カオスエンジニアリングが解決しようとしている問題なのです。カオスエンジニアリングの実験結果は、より弾力性のあるシステムを作るために取り組まれます。

カオスエンジニアリングの原理

「Principles of Chaos Engineering」は、カオスエンジニアリングの主な目標と原則を説明した優れたマニフェストです。カオスエンジニアリングの原則は、さらに、科学的手法に類似した4つの実践方法に分類されます。ただし、科学的方法とは異なり、システムが安定していることを前提とし、その上で分散を探します。定常状態を中断するのが難しいほど、システムの信頼性と頑健性は高くなります。 

ベースラインの定義から始める（Steady-State）

正常/定常とは何かを知ることは、逸脱/進行を検出する上で非常に重要です。何をテストしているかによりますが、応答時間などの優れた指標を持つことや、一定の時間内にユーザージャーニーを完了できるなどのより高いレベルの目標を持つことは、正常性を測るよい指標となります。実験における定常状態とは、対照群のことです。

定常状態を維持するための仮説 

科学的手法に反して、ある仮説が常に正しいと仮定すると、あまり余裕がなくなります。カオスエンジニアリングは、堅牢で安定したシステムに対して実行され、アプリケーションの障害やインフラの障害などの欠陥を見つけようとするように設計されています。カオスエンジニアリングを非定常なシステムに対して実行しても、それらのシステムは既に信頼性が低く、不安定であることが知られているので、あまり価値はありません。

変数・実験の導入 

科学実験と同様に、カオスエンジニアリングでは、実験に変数を導入し、システムがどのように反応するかを確認します。これらの実験は、アプリケーションの4つの柱（コンピュート、ネットワーク、ストレージ、アプリケーションインフラ）のうちの1つ以上に影響を与える実際の障害シナリオを表しています。障害とは、例えば、ハードウェアの故障やネットワークの遮断などが考えられます。

仮説の反証を試みる 

仮説が定常状態であれば、定常状態からの変動や混乱（対照群と実験群の差）があれば、安定性の仮説が否定されることになります。このように、着目すべき点が明確になったことで、修正や設計変更を行い、より堅牢で安定したシステムを作ることができるようになりました。

カオスエンジニアリングの原則を実践することで、カオスエンジニアリング実験を実施する際の設計上の注意点やベストプラクティスがいくつか見えてきます。

カオスエンジニアリングのベストプラクティス

カオスエンジニアリング、あるいはあらゆるテストを実施する際には、３つの柱があります。１つ目は十分なカバレッジを確保すること、２つ目は実験を頻繁に行い、本番と同じように実行すること、そして３つ目は爆発半径を最小にすることです。

想定される故障の頻度・影響度をカバーすること

ソフトウェアでは、100%のテストカバレッジを達成することはできません。カバレッジの構築には時間がかかるし、全ての特定のシナリオを考慮することは夢物語なのです。カバレッジは、最もインパクトのあるものをテストするように働きかけています。カオスエンジニアリングでは、ストレージが使用できないといった重大な影響を与える項目や、ネットワークの飽和やネットワーク障害のような多く発生する可能性のある項目に対するテストがそれに当たります。

パイプラインでの継続的な実験の実行

ソフトウェア、システム、インフラは変化します。そして、それぞれの状態や健康状態は、かなり急速に変化します。実験を行うのに適した場所は、CI/CDパイプラインの中です。CI/CDパイプラインは、変更が行われるときに実行されます。変更の潜在的な影響を測定するには、変更がパイプラインの中で信頼醸成の旅を始めているときほどよいタイミングはありません。

本番さながらの実験

本番環境でのテストについて恐ろしいほど考えているように、本番環境はユーザーがいる環境であり、トラフィックの急増/負荷が現実のものとなっています。本番システムの堅牢性/耐障害性を完全にテストするには、本番環境でカオスエンジニアリングの実験を行うことで、必要な知見を得ることができます。

ブラスト半径の最小化

科学の名の下に生産を落とすことはできないので、カオスエンジニアリング実験の爆発半径を制限することは、責任ある行為です。識別したいことを教えてくれる小さな実験に集中しましょう。範囲とテストに重点を置きましょう。例えば、2つの特定のサービス間のネットワーク遅延がそうです。Game Dayの計画は、爆発半径と何に焦点を当てるべきかを計算するのに役立ちます。

これらのベストプラクティスにより、カオスエンジニアリングは、負荷テストとは異なる学問分野であるといえます。

カオスエンジニアリングと負荷テストの違いとは？

確かに、負荷はそれ自体でカオスをもたらすことがあります。私たちは一般的に、複数の部分で弾力的になるようにシステムを設計します（負荷に対応するために、追加の計算ノード、ネットワークノード、永続化ノード、アプリケーションノードをスピンアップさせます）。これは、全てが同じタイミングまたは適切なタイミングで立ち上がり、負荷に先んじることができると仮定してのことです。

コンピューターサイエンスの世界では、Thundering Herd問題は新しい問題ではなく、より分散アーキテクチャに移行するにつれて、より一般的に顕在化するものです。例えば、マシンレベルでは、多数のプロセスがキックオフされ、別のプロセスがボトルネック（新しいプロセスのうちの1つだけを処理する能力）になることがサンダーリングヘルドの問題です。分散アーキテクチャでは、メッセージングシステムが一度に大量のメッセージ／イベントを取り込むことができても、それらのメッセージを処理/維持することがボトルネックになることがThundering Herdになるかもしれません。もし、メッセージであふれかえったら、Thundering Herdの登場です。 

負荷テストは、確かにストレスの一種として雷鳴の群れに備えるのに役立つでしょう。しかし、システムの一部がなかったり、ゲームに遅れたりした場合はどうなるでしょうか？そこで登場するのがカオスエンジニアリングです。カオスエンジニアリングなしでは、カスケード故障のテストは非常に困難です。カスケード故障とは、ある部分の故障が他の部分の故障の引き金になることで、歴史的には電力網と同じような意味合いを持っています。分散システムにおいては、単一障害点を見つけ、アプリケーションやインフラが障害に対処できるよう十分に堅牢であることを確認することです。

カオスエンジニアリングツール

カオスエンジニアリングの周りには、多くの進歩や道具があります。Awesome Chaos Engineeringリストでは、優れた技術リソースを見つけることができます。また私たちは、上位のカオスエンジニアリングツールの詳細をまとめました。このリストは、カオスエンジニアリングを構築したカオステストツールや、カオスエンジニアリングをより簡単に利用できるようにする新しいプラットフォームへのオマージュです。

Harness Chaos Engineering

Harnessでは、開発者が計画外のダウンタイムに積極的に対処できるようにする必要性を認識していました。そこで、エンジニアリングおよび信頼性チームがプロアクティブに信頼性を向上させるためのソリューションとして、Harness Chaos Engineeringを発表しました。Harness Chaos Engineeringは、DevOpsチームとソフトウェア信頼性エンジニアリング（SRE）チームが協力してカオステストを実施し、デプロイメントにおける信頼性の問題を特定することを可能にします。カオスエンジニアリングツールが提供する機能により、開発者は、頻繁に行われない手動GameDayテストで信頼性のスナップショットを取得する代わりに、パイプラインで継続的に信頼性を検証することが可能になります。

CI/CDパイプラインの試行錯誤

システムの信頼性を高めるための新しい方法が普及し始めた今、CI/CDパイプラインは信頼性を高めるための手順を組織化するのに最適な場所です。カオスエンジニアリングの実験は、CI/CDパイプラインで実行するのに適しています。

カオス実験の結果をデプロイに反映させたり、低環境にデプロイする場合は、Harnessを実験や他の自動テストのオーケストレーターとして機能させたりすることが可能です。

Harnessがお手伝いします

Harnessのソフトウェアデリバリープラットフォームは、信頼性を高めるステップをオーケストレーションするために作られた、非常に堅牢なプラットフォームです。どんな実験でもそうですが、カオスエンジニアリングの柱は、ベースラインを持つことです。あなたがSREチームのような、あなた自身が書いたのではない何十ものアプリケーションのカバレッジを持つチームに新しく参加したと想像してください。カオステストを初めて実行するには、アプリケーションと関連するインフラを分離するか、新しいディストリビューションをスピンアップして、本番環境に影響を与えないように実験する必要があります。

アプリケーションを堅牢なパイプラインでデプロイしていない場合、別の分離されたデプロイメントを作成することは、通常のアプリケーションのデプロイの波と同じように苦痛になる可能性があります。カオスエンジニアリングの成熟度に合わせて、カオステストは必須のカバレッジとみなされ、判定や障害対策のためのHarness Workflowに統合することは、慣習的に簡単なことです。

カオスエンジニアリングツールについてもっと知りたいですか？私たちの記事を読んでください。

この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。