翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

継続的なカオスエンジニアリング実験のライフサイクル

前のセクションで説明したように、さまざまな方法でカオスエンジニアリング実験を実装できます。いずれの場合も、有意義なカオス実験を構築するための鍵は、アプリケーション、過去のインシデント、実装された修復を理解し、レジリエンスやセキュリティなどの調査すべき領域を明確に理解することです。アプリケーションに関する知識は、アプリケーションの潜在的な弱点に関する仮説を策定し、障害が挿入されたときに検出、修復、復旧する方法を理解するのに役立ちます。

カオス実験のライフサイクルには、以下のステップが含まれます。

これらのステップを図に示し、以下のセクションで説明します。

目標を定義し、期待を設定する

各実験の前に、目標と期待が具体的、測定可能、達成可能、関連性があり、期限があることを確認してください。以下を明確に定義します。

ターゲットアプリケーションを選択する

カオスエンジニアリングは強力な手法ですが、価値を最大化するには慎重に優先順位を付ける必要があります。カオスエンジニアリングの取り組みの焦点を決めるときは、まずビジネスの重要なサービスを考慮してください。ソフトウェア開発ライフサイクルステージを繰り返して、まずテスト環境で障害を挿入するようチームに依頼します。ビジネスクリティカルなアプリケーションは、収益、カスタマーエクスペリエンス、コアオペレーションに直接関連しています。これらのサービスのカオス実験では、対処されていない場合、組織、および潜在的に市場全体に大きな影響を与える可能性のある脆弱性を発見できます。例えば、まず取引システムや注文システムなどの顧客向けサービスに焦点を当てます。これらの中央サービスに優先順位を付けると、投資ごとに最大限の保護が提供されます。

重要なサービスの後は、データベース、メッセージキュー、ネットワーク、共有サービス APIs などの基本的なコンポーネントを確認します。これらは組織全体の共有コンポーネントまたはサービスとして使用される可能性があるため、障害が発生すると広範な問題が発生します。インフラストラクチャサービスのレジリエンスを確認することで、依存するアプリケーションがその上位にとどまらないという確信が得られます。例えば、Kafka クラスターを破壊するカオスエンジニアリング実験では、ダウンストリームアプリケーションの耐障害性について多くのことが明らかになります。システムインフラストラクチャは直接顧客向けではありませんが、カオスエンジニアリングの主なターゲットです。

人、プロセス、施設情報、サードパーティーの依存関係のメンタルギャップをマッピングすることを忘れないでください。これらは、組織の影響許容度目標と一致しない場合、大きな中断を引き起こす可能性があります。カオスエンジニアリングの ROI の測定の詳細については、戦略ドキュメント「戦略的必要性としてのカオスエンジニアリングへの投資」の「カオスエンジニアリングの ROI の定量化」を参照してください。

次の図は、さまざまなサービスの階層でカオス実験を実行するための投資収益率を示しています。

メンタルマップの整列 (アプリケーション検出)

アドホック実験やゲームデーを実行するときは、アプリケーションの詳細のマッピングに焦点を当てたホワイトボードセッションを開催して、アプリケーション検出プロセスを開始します。(カオスパイプラインで実験を実行する場合、ターゲットアプリケーションを定義することで、そのメンタルマップを既に調整しています）。メンタルギャップを理解するための適切なアプローチは、最も経験の浅いチームメンバーが最初にアプリケーションの図を描き、さらに上級のスタッフメンバーに図に徐々に追加するように依頼することです。これにより、経験レベル間の理解のギャップが明らかになります。

この図は、アプリケーションの直接のアップストリームとダウンストリームの両方の依存関係と、重要なサードパーティーの統合を示しています。アプリケーションを介したリクエストの予想されるフローに整合性があることを確認します。主要なワークフローとユーザージャーニーをマッピングして、顧客がアプリケーションをどのように使用しているかを明確にします。シーケンス図を使用してこの情報をキャプチャすることを検討してください。

この共同セッションの後、チームはアプリケーション、その重要な依存関係、モニタリング能力の共有メンタルモデルを持ち、潜在的なカオス実験を進めるかキャンセルするかを情報に基づいて決定するためのリスクを理解する必要があります。

アプリケーションの既知の問題に対処する

カオスエンジニアリング実験は、アプリケーションの欠陥をプロアクティブに表面化するように設計されています。レイテンシーの増加、サーバーの再起動、アベイラビリティーゾーンの電源障害などの障害を挿入することで、アプリケーションの現実的な中断を許容する能力を検証できます。ただし、このプロセスでは、ターゲットアプリケーションの基盤となるレベルの安定性と正常性を前提としています。すでに問題のあるアプリケーションでカオス実験を実行すると、より深い問題を隠すリスクがあります。

カオスエンジニアリングを行う前に、チームはアプリケーションの既知の欠陥、バグ、パフォーマンスの問題を解決する必要があります。

仮説と実験を定義する

アプリケーションまたは組織内の他のアプリケーションに中断を引き起こした過去のインシデントは、カオス実験のアイデアの優れたソースとして機能します。たとえば、以前の停止は設定エラーや回復力パターンの欠落によってトリガーされましたか? インシデント履歴を確認し、カオス実験を通じて現実世界の障害の根本原因を再生することは、将来同様の問題に対する回復力を開発する効果的な方法です。

実験概念のもう 1 つの貴重なソースは、アプリケーションに最も精通しているエンジニア、アーキテクト、オペレーターから直接取得できます。チームメンバーがアプリケーションを大幅に中断する可能性のある架空の障害シナリオを送信できるようにすると、インサイダーの知識に基づいてアイデアを収集できます。その後、アプリケーションチームは、提案されたシナリオのうち、潜在的な影響が最も大きいシナリオや、未知のリスクが最も大きいシナリオを評価できます。このような高リスクであまり理解されていないシナリオのカオス実験をターゲットにすると、重要な学習が生成され、将来の問題を防ぐことができます。

3 つ目のアイデアは、レジリエンスモデリングを実行して、特定されたビジネス上の損失につながる状況を予測することにあります。レジリエンスモデリングの演習には、レジリエンスモデルを構築するためのコンポーネントベースのアプローチと、システムベースのアプローチがあります。コンポーネントベースのアプローチでは、「コンポーネント x が極端に負荷がかかっている、または障害が発生したときにどうなるか」という質問をします。次に、レジリエンスモデルを開発するチームは、このようなシナリオが広範なアプリケーションに与える影響を推測し、シナリオの影響を検出して軽減するために現在実施されているモニタリングと予防的コントロールを特定します。または、システムベースのアプローチはトップダウンプロセスに従って、「ウェブストアフロントが古いインベントリレベルを表示している」など、アプリケーションの望ましくない状態を強調し、アプリケーションチームに、アプリケーションがこの方法で動作する原因となる条件を予測するよう依頼します。

実験の運用準備を確保する

オブザーバビリティに関する セクションで前述したように、アプリケーションとその動作に対する悪影響を測定するには、定量化可能な指標が必要です。アプリケーションの動作を測定できるため、悪影響がアプリケーションに影響を与えたかどうか、どの程度影響したかを判断できます。

アプリケーションに影響を与えるかどうかを理解する最善の方法は、その定常状態を測定することです。定常状態は、通常のオペレーションがどのように見えるかを測定し、通常、特定のアプリケーションのビジネスおよびクライアントエクスペリエンス指標と一致します。次のステップに進む前に、影響を理解するためのオブザーバビリティがあることを確認し、実験が期待どおりに実行されない場合に備えて、メカニズムをロールバックする準備を整えてください。

制御された実験とシナリオを実行する

では AWS、本番環境のアプリケーションで最初のカオス実験を行うことはお勧めしません。カオス実験の目的は、アプリケーションがストレスの多い条件下でどのように動作するかについて新しいことを学ぶことです。実験中にアプリケーションの動作が予測できない可能性があるため、本番環境で初めて実験を実行すると、顧客に影響を与える可能性があります。したがって、実際のユーザーに影響を与える可能性を最小限に抑えた低レベルの環境で最初のカオス実験を常に実行し、アプリケーションが挿入されたアクションを吸収、適応、回復できることを確認してから、環境を反復する必要があります。

付録に記載されている実験計画ドキュメントと同様に、主要な詳細をキャプチャしたドキュメントを使用して、各実験を徹底的に計画します。含める重要なフィールドには、定常状態の定義、仮説、障害挿入の方法などがあります。カオス実験の計画、実行、分析は、単一のアーティファクトでカバーできます。

実験の書面による計画を確定したら、ドキュメントで概説されている計画された中断を挿入するために必要なコードを用意します。

実験中に潜在的な影響を把握するには、オブザーバビリティメカニズムが設定されていることを確認します。実験レポートなどの AWS FIS 実験結果を自動的にキャプチャする方法がまだない場合は、実行時にメモを取るチームメンバーを特定し、ダッシュボードのスクリーンショットをキャプチャして、実験を通じてチームを主導します。

学習と微調整

各実験が終わったら、チームとして協力してカオス実験を確認し、検討します。責任のない考え方を維持するために意識的に取り組みます。目標は、責任を割り当てるのではなく、最大限の学習を引き出すことに集中したオープンで建設的な対話を持つことです。

まず、実験の定常状態の定義と仮説を確認します。アプリケーションは期待どおりに動作しましたか? 仮定を無効にした驚きはありましたか? 実験中にアプリケーションがどのように反応したか、良い点と悪い点の両方について観察します。メトリクス、ログ、スクリーンショットなど、収集されたデータは、何が起こったのかを正確に説明する必要があります。

このデータレビューには、判断ではなく好奇心を持ってアプローチし、学習に基づいてアプリケーション設計、ドキュメント、モニタリング、またはその他の機能を改善できる領域を特定します。これらのアクション項目は、アプリケーションの耐障害性を高めるために、フォローアッププロジェクトとしてキャプチャされます。

この責任のないアプローチにより、何がうまくいかず、どのように修正できるかについて率直に話し合うことができます。関与するすべての人から肯定的なインテントを引き受け、良い成果に向けて取り組んでいたと信頼します。共有目標は、継続的な学習と適応による組織の成長と進歩です。建設的で非難のない方法で実施されるカオス実験レビューは、チームが貴重なインサイトを得るための安全なスペースを提供し、アプリケーションと組織の信頼性と回復性を長期的に高めます。焦点は、人々ではなく学習に留まります。チーム全体に学習内容を分散するには、実験結果レポートを一元的に公開し、他のユーザーがそこから学習できるように結果をアドバタイズします。