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

2023年8月3日

カオス・エンジニアリングは、本番環境または本番前環境で障害を意図的かつ制御的に引き起こし、その影響を理解し、より良い防御態勢とインシデント・メンテナンス戦略を計画するものです。

組織の重要なアプリケーションやインフラストラクチャーには障害が発生して、顧客にサービスを提供する能力が脅かされる可能性は日々あります。障害の原因は、セキュリティー侵害、構成ミス、サービスの中断など、その問題によって異なります。クラウドにホストされるアプリケーションやデータが増えると、エラーや中断の可能性が高まり、セキュリティーの問題が増加しかねません。

中断に対処する方法の1つはカオス・エンジニアリングです。これは、エンジニアがインスタンスやサービスを終了したり、目的なしにシステムに障害を引き起こしたりするランダムなプロセスではありません。このプロセスによって、将来の潜在的な問題が特定されるため、エンジニアリング・チームは先見的に問題を解決し、今後のライブ環境でそれらを回避することができます。

カオス・エンジニアリングが重要なのは、エラーや中断によって組織の勢いが削がれ、ダウンタイムが増える中、貴重な時間を使って臨機応変に解決策を考えることになるからです。Netflixは、オンプレミスからクラウドに切り替えた1ときにこの概念をじかに学びました。2008年、サービス提供が3日間中断される障害が発生しました。

この停止は、ビデオ・ストリーミング運営として変革を行う前のことであり、そうなればこの停止によるコストは飛躍的に高くなっていたでしょう。結果的に、Netflixは混乱を最小限に抑えるためにあらゆる手段を講じることを決定し、ワークフローにカオス・エンジニアリングを導入し始めました。このプロセスにより、問題を発生前に特定し、避けられない障害が発生した場合の被害を最小限に食い止めることができます。

Netflixは、カオス・モンキー2を開発しました。これは、ITサービスとインフラストラクチャーでランダムなインシデントを作り出すオープンソース・ツールで、自動復旧手順で修正または対処できる弱点を特定してすることを目的としています。カオス・モンキーは、プライベート・データセンターからAmazon Web Services(AWS)に移行する際に、クラウドの信頼性の低さに対応するために実装されました。多くの組織が現在、カオス・モンキーを使用して、カオス・エンジニアリングの実験を行っています。

カオス・エンジニアリングは、組織の本番環境におけるインフラストラクチャーの障害、停止、またはコンポーネントの欠落に対する重要な防御策です。これにより、サイト信頼性エンジニア(SRE)やDevOpsチームの他のメンバーは、サービスの大幅な中断を回避することで、サービスを継続的に提供できます。カオス・エンジニアリングは、脆弱性をよりよく理解し、中断が発生した場合の影響を最小限に抑える方法を理解するのに役立ちます。

コードの小さな問題でさえ、プログラムの依存関係が異なると、運用環境全体に壊滅的な影響を与える可能性があります。例えば、金融サービス会社の取引ソフトウェア・システムでエラーが発生すると、数百万ドルの損失が発生する可能性があります3

組織はすべてのITインシデントを回避することはできないかもしれませんが、カオス管理を使用して、考えられるシナリオと最善の解決策を理解することで、被害を最小限に抑えることができます。

トラック上を転がるボールの3Dデザイン

最新のAIニュース + インサイト 


AIやクラウドなどについて、専門家が厳選したインサイトやニュースを、Thinkニュースレターで毎週お届けします。

カオス・エンジニアリングがメリットになる組織

回復力が高く、デジタル成熟度が高く、ダッシュボードやその他のツールによる可観測性が高い組織は実験を通じて、発生した問題に即座に対応できるため、カオス・エンジニアリングを採用するべきです。この可観測性がない4組織は、カオス・エンジニアリングを通じて作成した実験を解決するのに時間がかかりすぎる場合があります。

カオス・エンジニアリングは、クラウド、特にパブリッククラウドやクラウドネイティブ・アプリケーションを使用している組織にとっても必須です。パブリッククラウドは、クラウド・プロバイダーとの調整が必要となる停止の潜在的な問題を導入します。これは、オンプレミスの問題に対処するアプローチと異なるアプローチを要求します。

Constellation Researchによると5、クラウドを使用する企業は依然として、クラウドとサービス型ソフトウェア(SaaS)がITインシデントに及ぼす影響を考慮せずにそれらのインシデントに対処することがよくあります。

さらに、マイクロサービスの使用が増えるため、システム内で実行されるホストまたはコンテナーの数が増加し、カオス実験を通じて発見および解決できる独自の課題が生じます。複雑さをコード設計からシステム運用に移すことで、複雑さが解消されるわけではありませんが、より高度な自動化が可能になります。

カオス・エンジニアリングは、組織が継続的統合 と継続的デリバリー(CI/CD)パイプラインの速度を高めるのにも役立ちます。Netflixが行ったように6、カオス・エンジニアリングをCI/CDに組み込むことで、組織は継続的な実験を自動化すると同時に、その潜在的な影響をコントロールできます。

最後に、組織がAPIを介してパートナーと接続することが増えているという事実は、システムの問題が他の組織に波及する可能性があることを意味します。カオス・エンジニアリングを導入すれば、組織はアーキテクチャーの弱点を理解して修正し、最終的には将来の障害を予測する能力を生み出すことができます。

カオス・エンジニアリングを成功させれば、組織は顧客に重大な影響を与える技術的な障害を最小限に抑えることができます。カオス・エンジニアリングは、より強固で回復力の強い、より複雑なシステム・アーキテクチャーの構築もサポートします。組織がカオス・エンジニアリングを追求することを決定したら、次のステップは、それを本番前環境で実行するか本番環境で実行するかを決定することです。

AI Academy

ビジネス向け生成AIの台頭

生成AIの発展と現在のビジネスへの影響について学びます。

カオス・エンジニアリングの実験のタイプ

DevOpsチームには、カオス・エンジニアリング実験を実行してさまざまなシステム・プロセスをテストするための選択肢が複数あります。

  • 遅延の取り込み:DevOpsチームは、意図的にネットワーク接続の遅延や障害をエミュレートするシナリオを作成できます。これには、ネットワークの遅延や応答時間の低下が含まれます。
  • 障害の取り込み:システムに意図的にエラーを導入し、それが他の依存システムにどのような影響を与えるか、サービスが中断するかどうかを判断できます。障害の取り込み例には、ディスク障害の誘発、プロセスの終了、ホストのシャットダウン、電力や温度の上昇の導入などがあります。障害の取り込みにより、組織に何かが起こった場合にシステム全体の障害を引き起こす可能性がある単一障害点を特定できます。
  • 負荷の生成:通常の運用を大幅に超える大きなトラフィック・レベルを送信することで、意図的にシステムにストレスをかけます。これにより、サイト信頼性エンジニア(SRE)がシステム内のボトルネックを理解し、よりスケーラブルなシステムを構築できるようになります。
  • カナリア・テスト:少人数のユーザーに新製品や新機能をリリースすることで、不具合やバグがあっても一部の訪問者にしか影響せず、残りの訪問者は既存のWebサイト・エクスペリエンスにアクセスすることができます。

 

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

理想的なカオス・エンジニアリング・プロセスを作成するには、組織による大規模な分散システムの確保を可能にする複数の原則が必要です。

  • システムを理解する:これには、システム全体、新たに現れるその特性や機能、トポロジー、アーキテクチャー、依存関係、定常状態の動作、出力応答、特性(可用性、遅延、スループットなど)に関する包括的な知識が含まれます。
  • 失敗を受け入れる:ソフトウェア・エンジニアにとって、インシデントの発生を防ぐように設計されているにもかかわらず、インシデントの発生を許容するのは、最初は矛盾しているように思えます。ただし、IT サービスでは中断が必ず発生するため、組織のチームが勤務時間外後、何時間も経ってから対応したり、これまでその問題に直面したことがないといった状況にあうよりも、管理された環境で中断を体験し、解決策を先見的に見つける方がベターです。
  • 定常状態の動作を確立する:まず、エンジニアリング・チームは、実験によって定常状態が受ける影響を比較できるように、システムが正常に動作しているときの動作を定義する必要があります。
  • 現実世界のインシデントを特定する:カオス・エンジニアリングの実験は、ありそうもない状況を作り出すのではなく、日常起こり得ることにできるだけ近づける必要があります。ネットワークやインフラストラクチャーの障害、不正なコード、電源の問題、トラフィックの過負荷などが発生する可能性があります。
  • GameDayを実施する:カオス・エンジニアリングでは、GameDayで環境を調査できます。GameDayでは、特定の日に複数のテストを行い、リソースを最大限に活用して、できるだけ多くの問題を特定して解決します。
  • 自動化を利用する:あらゆる規模の組織が、手作業では手間がかかりすぎる実験を自動化することで、カオス・エンジニアリングを利用できます。これにより、カオス・エンジニアリング・プロセス中のITチームの負担が一部軽減されます。実験の設計、障害の挿入、インフラストラクチャーのプロビジョニングは、組織が自動化できる実験の側面です。
  • 爆発半径に注意せよ:カオス・エンジニアは、顧客への実害ができるだけ小さくなるよう、爆発半径を最小化することに細心の注意を払わなければなりません。爆発半径を最小化するには、次のような方法があります。
    • サービスのサブセットをターゲットにする:カオス・エンジニアリングは、特に本番環境においては、組織のサービスを根本的に混乱させてはなりません。サービスの特定のサブセットをターゲットにすることで、インシデント発生時の影響を最小限に抑え、システム全体の停止を確実に阻止できます。
    • 実験を有限時間の間実行する:実験には開始と終了が必要です。この実験のポイントは、インシデントを長期間放置して実行するのではなく、インシデントを作成して解決することです。
    • ピーク・トラフィックを避けて実験を実行する:組織は、インシデント発生時に大容量のトラフィックがシステムに与える影響を具体的に測定しようとしている場合を除き、ピーク時間中に実験を実行することを避けるように努める必要があります。
    • 開発環境で実験を実行する:顧客体験サービスの中断を防ぐ最も簡単な方法は、本番前の環境で実行することです。ただし、これは条件が本番環境とは異なることを意味し、何が起こっているかについて誤ったイメージを与える可能性があります。これを最小限に抑えるには、本番前環境と本番環境が可能な限り相互にミラーリングされるようにします。
    • すべてのコンポーネントを実験する:組織のシステムは継続的に変化するため、カオス実験は決して終わりません。「すべて」をテストすることも目標にする必要があります。すべてのコンポーネント、レイヤー、サービス、プロセス全体にわたるそれらの依存関係を調べます。

本番環境と本番前環境

カオス・エンジニアリングを採用する組織は、本番環境と本番前環境でカオス・テストを使用するかどうかを決定する必要があります。カオス・エンジニアリングが本番環境で最も有益である理由はいくつかあります。

ライブ環境は、インシデントが顧客体験に及ぼす影響を理解する上で最も正確な環境になります。もう1つの理由は、本番前環境がライブ環境とまったく同じ設定ではない可能性があるため、実験にばらつきが生じることです。

例えば、本番前環境でインシデントが発生した場合、実際の環境と同じトラフィック・レベルでないため、現実的な対応ができない可能性があります。また、その環境と同じセキュリティー設定がされていない可能性があります。

組織によっては、実際のサイトで意図的に問題を引き起こすことを恐れ、本番前サイトまたは開発サイトで実験を実行することがあります。そうすることで、発生した問題がライブ顧客体験に影響するのを確実に防ぎます。顧客体験への影響を軽減するため、組織によっては、本番環境に移行する前に本番前環境でプロセスを把握することから開始します。

組織は、リスク許容度に基づいて、使用する環境を選びます。究極的には、カオス・エンジニアリングは実際の大規模な問題をテストすることを目的としているため、本番環境では、何が起こっているのか、何を修正する必要があるのかを最も正確に把握することができます。

カオス・エンジニアリングのメリット

カオス・エンジニアリングは組織にいくつかの重要なメリットをもたらします。

顧客サービスの向上

顧客は、企業から購入するサービスの可用性に大きな期待を寄せています。ダウンタイムが発生したり、支払った料金にアクセスできなくなったりすると、顧客満足度に深刻な影響を及ぼし、収益の損失や評判の低下につながる可能性があります。システムをテストして解決策を特定すると、システムが長期間にわたってダウンするリスクが少なくなります。

データ・セキュリティーの向上

中断は、不正なコード、サーバーの問題、または外部の脅威によって生じることがあります。後者は、優れたセキュリティー対策を講じていても攻撃を受ける可能性があります。カオス・エンジニアリングを利用すると、悪用されかねない問題の特定に役立つため、組織はパッチや修正プログラムを導入して、サービスの安全性を維持できます。

ダウンタイムの最小化

カオス・エンジニアリングを使用すると、組織は将来発生する問題への対処方法について、より多くの情報に基づく青写真を作成できます。カオス・エンジニアリングを採用する組織は、多くのインシデントに対して具体的な計画を立てているため、迅速な修復とダウンタイムの短縮が可能になります。カオス・エンジニアリングにより、ダウンタイムの短縮7を20%も実現できます。

拡張性の向上

カオス・エンジニアリングの実験では、システムによってリソースがどのように割り当てられるかを特定します。実験を導入することで、システムがどのように負荷を処理し、どこでボトルネックが発生するのか、または発生する可能性があるかを示すことができます。

将来のソフトウェア開発に情報を提供する

カオス・エンジニアリングを活用すると、チームは優れたシステムの回復力と柔軟性をソフトウェアに組み込むことができます。したがって、組織は現在のシステムが問題をどのように処理するかを把握しているため、新しいソフトウェアやソリューションのコーディングによりインテリジェントに取り組むことができます。

関連ソリューション
ビジネス・コンサルティング・サービス

ビジネスとテクノロジーの変革を融合し、企業の俊敏性を引き出すことで、業務の進め方を刷新します。

    ビジネス・コンサルティング・サービスの詳細はこちら
    人事・人材トランスフォーメーション・コンサルティング

    AIを核とした人事の再構築とモダナイズにより、より優れたビジネス成果を実現し、従業員の可能性を最大限に引き出します。

    人事トランスフォーメーション・サービスを見る
    金融コンサルティング・サービス

    コア・プロセス全体にデータ分析、AI、オートメーションを導入するエンド・ツー・エンドのサービスで、財務のパフォーマンスとビジネス価値を解き放ちます。

      財務ソリューションはこちら
      次のステップ

      戦略と働き方を再構築することで、ビジネスを成長させ、変革を実現します。

      ビジネス戦略サービスの詳細はこちら 人工知能サービスの詳細はこちら
      脚注

      1 Chaos Engineering: System Resiliency in Practice(ibm.com外部のリンク)、Casey Rosenthal, Nora Jones、2020年。
      What is Chaos Monkey? Chaos engineering explained(ibm.com外部のリンク)、InfoWorld、2020年5月13日。
      Knight Capital Says Trading Glitch Cost It USD 440 Million(ibm.com外部のリンク)、New York Times、2012年。
      4 There Is No Resilience without Chaos(ibm.com外部のリンク)、The New Stack、2023年4月13日。
      5 Incident Management in the Cloud Era(ibm.com外部のリンク)、Constellation Research、2023年。
      6 ChAP: Chaos Automation Platform(ibm.com外部のリンク)、Netflixブログ、2017年7月26日。
      7 The I&O Leader’s Guide to Chaos Engineering(ibm.com外部のリンク)、Gartner、2021年10月28日。