ホーム topics カオス・エンジニアリングとは カオス・エンジニアリングとは
IBM Instanaについて詳しく見る
1と0の文字列を描いたグラフィック

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

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

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

カオス・エンジニアリングが重要なのは、エラーや中断によって組織の勢いが削がれ、ダウンタイムが増える中、貴重な時間を使ってその場で解決策を考えることになるからです。Netflixは、オンプレミスからクラウドに切り替えたときに、このことを身をもって学びました1ibm.com外部のリンク)。2008年、サービス提供が3日間中断される障害が発生しました。これは、ビデオ・ストリーミング運営として変革を行う前のことであり、そうなればこの停止によるコストは飛躍的に高くなっていたでしょう。結果的に、Netflixは混乱を最小限に抑えるためにあらゆる手段を講じることを決定し、ワークフローにカオス・エンジニアリングを導入し始めました。カオス・エンジニアリングの導入により、問題を発生前に特定し、避けられない障害が発生した場合の被害を最小限に食い止めることができます。

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

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

コードの小さな問題でさえ、プログラムの依存関係が異なると、運用環境全体に壊滅的な影響を与える可能性があります。たとえば、金融サービス会社の取引ソフトウェア・システムでエラーが発生すると、数百万ドルの損失が発生する可能性があります3(ibm.com外部のリンク)。組織はすべてのITインシデントを回避することはできないかもしれませんが、カオス管理を使用して、考えられるシナリオと最善の解決策を理解することで、被害を最小限に抑えることができます。

watsonxの概要

IBM Instana Observabilityは、企業全体の誰もが必要なコンテキストを備えた必要なデータに簡単にアクセスし、問題の迅速な防止と修復を実現します。

関連コンテンツ

IBMニュースレターの購読

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

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

カオス・エンジニアリングは、クラウド、特にパブリッククラウドや クラウドネイティブ・アプリケーションを使用している組織にとっても必須です。パブリッククラウドでは、クラウド・プロバイダーとの調整が必要となる停電の問題が発生する可能性があるため、オンプレミスの問題に対処するのとは異なるアプローチが必要となります。

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

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

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

最後に、組織がAPIを介してパートナーと接続することが増えているという事実は、システムの問題が他の組織に波及する可能性があることを意味します。

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

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

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

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

 

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

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

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

カオス・エンジニアリングを利用する組織は、本番環境と本番前環境のどちらでカオス・テストを使用するかを決定する必要があります。カオス・エンジニアリングが本番環境で最も有益である理由はいくつかあります。ライブ環境は、インシデントが顧客体験に及ぼす影響を理解する上で最も正確な環境になります。もう1つの理由は、本番前環境がライブ環境とまったく同じ設定ではない可能性があるため、実験にばらつきが生じることです。

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

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

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

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

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

顧客サービスの向上

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

 

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

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

ダウンタイムの最小化

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

 

拡張性の向上

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

 

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

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

カオス・エンジニアリング製品の詳細はこちら
可観測性 IBM Instana APM

IBMの可観測性ソリューションを使用して、インシデントのより迅速な解決に必要なコンテキストを取得します。

IBM Instanaについて詳しく見る

可観測性 Flexera One with IBM Observability

ソフトウェアの使用とコストを最適化

 

Flexera One with IBM Observabilityの詳細

カオス・エンジニアリングの参考情報 AIOpsとは?

IT 運用のための人工知能(AIOps)がデータと機械学習を使用してITサービス管理を改善および自動化する方法を学ぶ

アプリケーション・パフォーマンス管理とは

アプリケーション・パフォーマンス管理により、ビジネスに影響する前にパフォーマンスの問題を予測して防止できます。

IT運用とは

IT運用とAIOpsは、組織全体のITサービスの管理、提供、サポートを監督および自動化します。

ITサービス管理とは

ITSMとは、組織がユーザーやビジネスに必要な方法でITサービスを確実に機能させるための手段です。

サイト信頼性エンジニアリングとは

サイト信頼性エンジニアリングにより、ITオペレーション・タスクを自動化し、ソフトウェア配信を加速し、ITリスクを最小限に抑えます。

インテリジェントな自動化とは

インテリジェントな自動化は、AIと自動化テクノロジーを組み合わせて、ビジネス内の下位タスクの自動化を実現します。

次のステップ

IBM Instanaは、あらゆるユーザーの利用に適したリアルタイムの可観測性を提供します。可観測性戦略が現在および将来の環境の動的な複雑さに対応できることを検証しながら、価値実現までの時間を短縮します。 モバイルからメインフレームまで、Instanaは250以上のテクノロジーをサポートしており、その数は増え続けています。

IBM Instanaについて詳しく見る デモを予約
脚注

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 $440 Million(ibm.com外部のリンク)New York Times、2012年
4 There Is No Resilience without Chaos, The New Stack(ibm.com外部のリンク)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外部のリンク)ガートナー、2021年10月28日