BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ アーティクル カオステストで、見えない課題からアプリケーションのレジリエンスを改善する

カオステストで、見えない課題からアプリケーションのレジリエンスを改善する

キーポイント

  • カオステストは、単体レベル、統合レベル、そしてシステムレベルで利用できるシステムの、整合性をテストするための統制されたアプローチ(disciplined approach)だ。

  • カオステストには、仮説の構築、現実世界の様々な出来事、本番環境での実験、自動化、爆発半径の限定など、明確な原則がある。

  • カオステストは、生のデータストリームからのみ表面化する僅かなシナリオを特定するなど、ビジネスとテスターに​​多くのメリットをもたらすが、いくつかのデメリットとリスクもある。例えば、本番環境でのテストでは、サービス中断や、システム停止の可能性がある。

  • カオステストは、システムのごく一部で行う必要があり、システムの信頼性が高まるにつれて、爆発半径を拡大できる。

  • カオステストを行うためには、経営陣が決断を下す必要があり、テストに何を求めているか、またそれに伴うリスクを、彼らは前もって把握しておく必要がある。

 

ソフトウェアがより複雑になり、マイクロサービスと分散インフラストラクチャが台頭するにつれて、システム障害を制御することは非常に難しくなっている。従来、インフラはオンプレミスで開発・管理されていたため、システム管理者はとても簡単に保守できた。現在では、システムがグローバルに分散されたインフラストラクチャで管理されているため、システムにどのような障害が発生するかを予測することは困難だ。

カオステストは、レジリエンスを構築するためにアプリケーションシステムを中断および破壊する行為だ。通常、これは本番システムで行われるため、実行には非常に神経を使う。

この記事では、Netflixが提唱するカオステストの原則を列挙した。読者は、カオステストが提供するメリットとデメリットを理解できるはずだ。そうすることで、カオステストを行うかどうかの判断材料となる。また、リスクに対するすべてのメリットを考慮して、カオステストを行うために経営陣を説得すべき理由も説明した。

カオステスト(chaos testing)とは?

カオステストは、予期せぬダウンタイムやネガティブなユーザー体験となる前に、与えられた環境で積極的にシミュレーションし、障害を特定することで、システムの整合性をテストする高度に統制されたアプローチだ。

あるいは、意図的な障害や故障のシナリオを導入し、ランダムな障害に直面した際、システムがどのように振る舞うかを検証する分散型ソフトウェアのテスト手法と定義できる。 これらの障害は、アプリケーションが予期しない応答をしたり、ハードウェア圧力がかかって中断したりする原因となる。

一例を挙げよう。ある銀行の顧客に勤務しているとき、1 日に 1 回発生する不具合に遭遇した。毎日、数秒間、サイトが応答しなくなり、画面に次のエラーが表示された。「銀行のウェブサイトがダウンしています。動作していません。」数秒後、再び正常に応答しはじめた。この不具合はステージング環境では再現できなかったが、リリースのたびに本番環境で報告された。

本番システムを注意深く監視する必要があることを顧客に納得してもらい、カオステストを使用した。まず最初に、トラフィックがもっとも少ないと報告された日曜日の午前 0 時から午前 4 時の間にテストを実行することにした。1つずつランダムにサービスを停止し、システム全体への影響を観察していった。やがて、サードパーティのAPI-Bからデータフィードを得ているAPI-Aがあるとわかり、それは既存テストの範囲外であった。API-A を詳しく調べたところ、1 日 1 回、API-B からのデータの受信に 31 秒のタイムラグがあるとわかった。我々はサードパーティにこの不具合を調査するよう依頼し、調査結果を彼らに伝えた。その結果、彼らのサーバーがAM時間から正午を控えたPM時間に移行する際に、API-Bがちょうど31秒間ハングアップし、API-Aを待たせてしまい、最終的にシステムのハングアップにつながるとわかった。

外部コードやその依存性を考慮せず、自分たちのアプリケーションだけにフォーカスしてテストしていたということは、とても勉強になった。 我々は戦略を修正し、テスト計画にカオステストを組み込んだ。

カオステストの原則

カオスエンジニアリングは、5つの主要な原則で構成されている。

  1. 定常状態を識別する
    「定常状態」を定義する必要がある。つまり、通常の挙動を示す測定可能なシステム出力として管理する必要がある (ほとんどは誤差 1%を大幅に下回る)。

  2. システムが定常状態を維持すると仮定する
    いったん定常状態が決まれば、それが対照条件・実験条件のどちらでも継続するという仮定が必要だ。

  3. ユーザーへの影響を最小限に抑える
    カオステストでは、積極的にシステムを破壊したり中断させたりすることが目標だが、ユーザーへの悪影響を最小限に抑える方法で行うことが重要だ。チームは全てのテストが特定の領域にフォーカスしていることを確認する責任があり、必要に応じてインシデント対応の準備ができるようになることだ。

  4. カオスを導入する
    システムが機能し、チームの準備が整い、影響範囲が限定されていることに確信が持てたら、カオステストアプリケーションが実行できる。サーバーのクラッシュ、ハードウェアの誤動作、ネットワークの切断など、さまざまな変数を導入して現実世界のシナリオをシミュレートしてみよう。非本番環境でテストすることをお勧めする。本番稼働バージョンやアクティブユーザーに直接影響を与えることなく、サービスやアプリケーションがこれらのイベントにどのように反応するかを監視できるからだ。

  5. 監視と繰り返し
    カオスエンジニアリングで重要なのは、一貫してテストを行い、カオスを導入することで、システム内の弱点をピンポイントで突き止めることだ。カオスエンジニアリングの目的は、上記2.で確立した仮説を反証し、その過程でより信頼性の高いシステムを構築することだ。

カオステストのテストピラミッド

長年にわたり、IT業界は、設計・構築・運用規模において、かなり劇的な変化を遂げている。その結果、より複雑なシステムが開発されることになる。こういった積み重ねが、大規模な分散システムで、より多くの障害を引き起こすことになる。

カオスエンジニアリングの目的は、コンピュータシステムの未知の脆弱性や、これまで予期していなかった結果について、組織に啓蒙・周知することだ。これらの複雑なテスト手順における主な焦点は、組織でコントロールできないような障害が発生する前に、本番環境で起こりえる隠れた問題を特定することだ。それができてはじめて、障害対応チームはシステムの弱点に対処し、システム全体のフォールトトレランスとレジリエンスを強化できる。したがって、カオステストはさまざまなレベルで実行されている。

典型的なテストピラミッドは、通常3つの領域のテストで構成される。

  1. 単体レベル
    単体テストの主な目的は、ひとつひとつのコンポーネントにおいて、具体的に期待される動作を診断することだ。テスト対象のコンポーネントは、カオスエンジニアリングチームがモックを使用してその動作を制御している間、従来の依存関係から切り離す必要がある。最悪のケースを想定し、期待される動作と照らし合わせてテストする。

  2. 統合レベル
    個々のコンポーネントは互いに影響し合うので、統合テストではコンポーネント間の相互作用と相互関係に焦点が当たる。エンジニアは、個々のコンポーネントの単体テストが成功した後に、これらのテストを自動的に実行するのが理想的だ。このような統合テストは、複雑なアプリケーションやシステムの安定状態であったり、一般的な運用指標を判断するのにとても有用だ。

  3. システムレベル
    システムテストでは、特に最悪なケースの障害シナリオによるストレスが増大した場合に、コンピューターシステム全体がどのように反応するかを積極的に見極める。現実世界の事象と本番環境がつながってはじめて、障害対応チームは、ひとつひとつのコンポーネントの定常状態の挙動と、アーキテクチャ全体の統合プロトコルとを、明確に判断できる。

カオステストのメリット・デメリット

メリット:

テストでアプリケーションの限界を知ることは、開発チームとビジネス全体に多くのメリットをもたらす。健全でしっかりと管理されたカオスエンジニアリングの実践メリットは、以下のとおりだ。

  1. レジリエンスと信頼性の向上
    カオステストは、ソフトウェアがストレス下でどのように機能し、またどうすればより高いレジリエンスになるかについて、組織の知見を強化してくれる。

  2. イノベーションの加速
    カオステストから得られる知見は、開発者に還元され、開発者はソフトウェアの安定性を高めるために設計変更を行い、結果として製品品質を改善できる。

  3. 高度なコラボレーション
    メリットがあるのは開発者だけではない。技術グループ全体が、レスポンスの短縮やより良いコラボレーションにつながる見識を得ることができる。

  4. 素早いインシデント対応
    どのような障害シナリオが起こりえるのかを知ることで、障害対応チームは、問題解決、修復、およびインシデント対応を迅速化できる。

  5. 顧客満足度の改善
    レジリエンスの向上とレスポンスの短縮は、ダウンタイムの減少につながる。開発チームとSREチームからのより高度なイノベーションと協力により、効率的、かつ高いパフォーマンスで素早く新しい顧客ニーズを満たす、優れたソフトウェアをもたらす。

  6. ビジネス成果を押し上げる
    カオステストは、Time-to-value(TtV)の短縮、時間・コスト・リソースの節約、そしてより良い収益を生み出すことで、組織の競争力を高めることができる。

ソフトウェアのレジリエンスが高ければ高いほど、顧客は動揺や失望を感じることなく、サービスを享受できる。

デメリット:

カオステストのメリットは明らかだが、慎重に実施する必要がある。主な懸念事項と課題は以下のとおりだ。

  1. 不必要なダメージ
    カオステストの大きな懸念は、不必要なダメージを与える可能性があることだ。カオスエンジニアリングは、正当なテストの許容範囲を超えてしまい実際の損失につながる可能性がある。アプリケーションの見えない脆弱性を暴き出すためのコストを抑えるには、指定された爆発半径を超えるようなテストは避けるべきだ。目的は、障害の原因を突き止めるために、爆発半径をコントロールすることだ。

  2. オブザーバビリティ(可観測性)の欠如
    包括的なオブザーバビリティがなければ、重大な依存関係とそうでないものを把握することは難しいかもしれない。また、可視性が欠如していると、チームが問題に対して正確な根本原因を特定することが難しくなり、修復計画が複雑になる可能性がある。

  3. システムの開始状態が不明確
    もう1つの課題は、テストを実行する前にシステムの開始状態をはっきりと把握することだ。これがはっきりしていないと、チームはテストの本当の効果を理解するのが難しくなる。これではカオステストの効果は低下し、下流のシステムがより大きなリスクにさらされる可能性がある。

カオステストについて上層部を説得する

カオステストは、あらゆる失敗がシステム全体の停止につながる恐れのある新しいアプローチだ。したがって、カオステストの実行において上司を説得することは非常に重要となる。そのためにできることは次のとおりだ。

  1. 上司への啓蒙
    生物学者のアンリ・ラボリットは1976年にこう書いている。「未知の体験に直面すると、人は3つの選択しかできない : 戦う・何もしない・逃げる」。カオステストというテーマはまだ新しく、認知度も低いので、生理的に拒絶されないよう、上司が自分のペースでカオステストの概念を知るようにすることが大切だ。カオステストに関する面白い資料や、社内外のソーシャルネットワークを共有することから始めると良いだろう。
  1. 適切なストーリーを伝える
    上司を啓蒙したら、あなたの考えるストーリーを上司の懸念、疑問、または反論にすり合わせる必要がある。感情に訴えかけよう。感情は意思決定の大きな要素だ。もっとも分かりやすい感情は恐怖、大規模な障害によって収益に影響が出ることへの恐怖だ。例えば、5分間の停止は、Google/Alphabet で約 100 万ドル、Netflix で約 10 万ドル、さらにApple では約 300 万ドルの利益に相当する。

画像ソース

さらにインシデントが発生しているときこそ、自分の手駒を前進させる、すなわち将来のインシデントでの影響を抑えるための新しいプラクティス、これを提案するために、躊躇なくチャンスを利用するべきだ。

最適な方法の1つはレジリエンス、つまり困難な状況から素早く復旧する力について語ることだ。

カオステストを計画する際の注意事項

カオステストは新しい概念だが、知らず知らずのうちに、我々はカオステストを実行できる考え方を常にしていたし、実行することもあった。そこには独自の原則、利点、および落とし穴がある。だが計画を策定する前に、これらのテストを実施することのメリット・デメリットを天秤にかけることを、すべてのチームにアドバイスしたい。これらの破壊的なテストから何を得たいのか、はっきりさせておく必要がある。上司の許可を得て、なぜこのテストが重要なのかを説得しよう。納得してもらえたら、テストの爆発半径を決めて、計画を立てよう。システムのモニタリングを行い、十分な観察下におく必要がある。基本的には、始める前に多くの準備が必要となる。正しい準備がなされ、目的がはっきりしていれば、これらのテストは多くの貴重な知見を与えてくれるだろう。

作者について

この記事に星をつける

おすすめ度
スタイル

BT