カオス・エンジニアリングは、本番環境または本番前環境で障害を意図的かつ制御的に引き起こし、その影響を理解し、より良い防御態勢とインシデント・メンテナンス戦略を計画するものです。
組織の重要なアプリケーションやインフラストラクチャーには障害が発生して、顧客にサービスを提供する能力が脅かされる可能性は日々あります。障害の原因は、セキュリティー侵害、構成ミス、サービスの中断など、その問題によって異なります。クラウドにホストされるアプリケーションやデータが増えると、エラーや中断の可能性が高まり、セキュリティーの問題が増加しかねません。
中断に対処する方法の1つはカオス・エンジニアリングです。これは、エンジニアがインスタンスやサービスを終了したり、目的なしにシステムに障害を引き起こしたりするランダムなプロセスではありません。このプロセスによって、将来の潜在的な問題が特定されるため、エンジニアリング・チームは先見的に問題を解決し、今後のライブ環境でそれらを回避することができます。
カオス・エンジニアリングが重要なのは、エラーや中断によって組織の勢いが削がれ、ダウンタイムが増える中、貴重な時間を使って臨機応変に解決策を考えることになるからです。Netflixは、オンプレミスからクラウドに切り替えた1ときにこの概念をじかに学びました。2008年、サービス提供が3日間中断される障害が発生しました。
この停止は、ビデオ・ストリーミング運営として変革を行う前のことであり、そうなればこの停止によるコストは飛躍的に高くなっていたでしょう。結果的に、Netflixは混乱を最小限に抑えるためにあらゆる手段を講じることを決定し、ワークフローにカオス・エンジニアリングを導入し始めました。このプロセスにより、問題を発生前に特定し、避けられない障害が発生した場合の被害を最小限に食い止めることができます。
Netflixは、カオス・モンキー2を開発しました。これは、ITサービスとインフラストラクチャーでランダムなインシデントを作り出すオープンソース・ツールで、自動復旧手順で修正または対処できる弱点を特定してすることを目的としています。カオス・モンキーは、プライベート・データセンターからAmazon Web Services(AWS)に移行する際に、クラウドの信頼性の低さに対応するために実装されました。多くの組織が現在、カオス・モンキーを使用して、カオス・エンジニアリングの実験を行っています。
カオス・エンジニアリングは、組織の本番環境におけるインフラストラクチャーの障害、停止、またはコンポーネントの欠落に対する重要な防御策です。これにより、サイト信頼性エンジニア(SRE)やDevOpsチームの他のメンバーは、サービスの大幅な中断を回避することで、サービスを継続的に提供できます。カオス・エンジニアリングは、脆弱性をよりよく理解し、中断が発生した場合の影響を最小限に抑える方法を理解するのに役立ちます。
コードの小さな問題でさえ、プログラムの依存関係が異なると、運用環境全体に壊滅的な影響を与える可能性があります。例えば、金融サービス会社の取引ソフトウェア・システムでエラーが発生すると、数百万ドルの損失が発生する可能性があります3。
組織はすべてのITインシデントを回避することはできないかもしれませんが、カオス管理を使用して、考えられるシナリオと最善の解決策を理解することで、被害を最小限に抑えることができます。
回復力が高く、デジタル成熟度が高く、ダッシュボードやその他のツールによる可観測性が高い組織は実験を通じて、発生した問題に即座に対応できるため、カオス・エンジニアリングを採用するべきです。この可観測性がない4組織は、カオス・エンジニアリングを通じて作成した実験を解決するのに時間がかかりすぎる場合があります。
カオス・エンジニアリングは、クラウド、特にパブリッククラウドやクラウドネイティブ・アプリケーションを使用している組織にとっても必須です。パブリッククラウドは、クラウド・プロバイダーとの調整が必要となる停止の潜在的な問題を導入します。これは、オンプレミスの問題に対処するアプローチと異なるアプローチを要求します。
Constellation Researchによると5、クラウドを使用する企業は依然として、クラウドとサービス型ソフトウェア(SaaS)がITインシデントに及ぼす影響を考慮せずにそれらのインシデントに対処することがよくあります。
さらに、マイクロサービスの使用が増えるため、システム内で実行されるホストまたはコンテナーの数が増加し、カオス実験を通じて発見および解決できる独自の課題が生じます。複雑さをコード設計からシステム運用に移すことで、複雑さが解消されるわけではありませんが、より高度な自動化が可能になります。
カオス・エンジニアリングは、組織が継続的統合 と継続的デリバリー(CI/CD)パイプラインの速度を高めるのにも役立ちます。Netflixが行ったように6、カオス・エンジニアリングをCI/CDに組み込むことで、組織は継続的な実験を自動化すると同時に、その潜在的な影響をコントロールできます。
最後に、組織がAPIを介してパートナーと接続することが増えているという事実は、システムの問題が他の組織に波及する可能性があることを意味します。カオス・エンジニアリングを導入すれば、組織はアーキテクチャーの弱点を理解して修正し、最終的には将来の障害を予測する能力を生み出すことができます。
カオス・エンジニアリングを成功させれば、組織は顧客に重大な影響を与える技術的な障害を最小限に抑えることができます。カオス・エンジニアリングは、より強固で回復力の強い、より複雑なシステム・アーキテクチャーの構築もサポートします。組織がカオス・エンジニアリングを追求することを決定したら、次のステップは、それを本番前環境で実行するか本番環境で実行するかを決定することです。
DevOpsチームには、カオス・エンジニアリング実験を実行してさまざまなシステム・プロセスをテストするための選択肢が複数あります。
理想的なカオス・エンジニアリング・プロセスを作成するには、組織による大規模な分散システムの確保を可能にする複数の原則が必要です。
カオス・エンジニアリングを採用する組織は、本番環境と本番前環境でカオス・テストを使用するかどうかを決定する必要があります。カオス・エンジニアリングが本番環境で最も有益である理由はいくつかあります。
ライブ環境は、インシデントが顧客体験に及ぼす影響を理解する上で最も正確な環境になります。もう1つの理由は、本番前環境がライブ環境とまったく同じ設定ではない可能性があるため、実験にばらつきが生じることです。
例えば、本番前環境でインシデントが発生した場合、実際の環境と同じトラフィック・レベルでないため、現実的な対応ができない可能性があります。また、その環境と同じセキュリティー設定がされていない可能性があります。
組織によっては、実際のサイトで意図的に問題を引き起こすことを恐れ、本番前サイトまたは開発サイトで実験を実行することがあります。そうすることで、発生した問題がライブ顧客体験に影響するのを確実に防ぎます。顧客体験への影響を軽減するため、組織によっては、本番環境に移行する前に本番前環境でプロセスを把握することから開始します。
組織は、リスク許容度に基づいて、使用する環境を選びます。究極的には、カオス・エンジニアリングは実際の大規模な問題をテストすることを目的としているため、本番環境では、何が起こっているのか、何を修正する必要があるのかを最も正確に把握することができます。
カオス・エンジニアリングは組織にいくつかの重要なメリットをもたらします。
顧客は、企業から購入するサービスの可用性に大きな期待を寄せています。ダウンタイムが発生したり、支払った料金にアクセスできなくなったりすると、顧客満足度に深刻な影響を及ぼし、収益の損失や評判の低下につながる可能性があります。システムをテストして解決策を特定すると、システムが長期間にわたってダウンするリスクが少なくなります。
中断は、不正なコード、サーバーの問題、または外部の脅威によって生じることがあります。後者は、優れたセキュリティー対策を講じていても攻撃を受ける可能性があります。カオス・エンジニアリングを利用すると、悪用されかねない問題の特定に役立つため、組織はパッチや修正プログラムを導入して、サービスの安全性を維持できます。
カオス・エンジニアリングを使用すると、組織は将来発生する問題への対処方法について、より多くの情報に基づく青写真を作成できます。カオス・エンジニアリングを採用する組織は、多くのインシデントに対して具体的な計画を立てているため、迅速な修復とダウンタイムの短縮が可能になります。カオス・エンジニアリングにより、ダウンタイムの短縮7を20%も実現できます。
カオス・エンジニアリングの実験では、システムによってリソースがどのように割り当てられるかを特定します。実験を導入することで、システムがどのように負荷を処理し、どこでボトルネックが発生するのか、または発生する可能性があるかを示すことができます。
カオス・エンジニアリングを活用すると、チームは優れたシステムの回復力と柔軟性をソフトウェアに組み込むことができます。したがって、組織は現在のシステムが問題をどのように処理するかを把握しているため、新しいソフトウェアやソリューションのコーディングによりインテリジェントに取り組むことができます。
CEOたちがサステナビリティーについてどう考えているのかを自分の言葉で語るのが、そしてサステナビリティーをどのようにビジネスに織り込んでいるのかが読めます。
今後3年間に世界を形作ると専門家が予想する7つのビジネス・トレンドと、そのメリットを享受するために行う価値のある7つの挑戦をご覧ください。
Climate Service社がIBMのテクノロジーを利用して財務上の意思決定に気候データをどのように統合したかをご覧ください。
Kraft Heinz社がIBM Garageメソドロジーを利用して製品の提供をどのように迅速化したかをご覧ください。
ビジネスとテクノロジーの変革を融合し、企業の俊敏性を引き出すことで、業務の進め方を刷新します。
AIを核とした人事の再構築とモダナイズにより、より優れたビジネス成果を実現し、従業員の可能性を最大限に引き出します。
コア・プロセス全体にデータ分析、AI、オートメーションを導入するエンド・ツー・エンドのサービスで、財務のパフォーマンスとビジネス価値を解き放ちます。
1 Chaos Engineering: System Resiliency in Practice(ibm.com外部のリンク)、Casey Rosenthal, Nora Jones、2020年。
2 What is Chaos Monkey? Chaos engineering explained(ibm.com外部のリンク)、InfoWorld、2020年5月13日。
3 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日。