カオスエンジニアリングはDRプランをどう強化するか

次の教訓になってしまうような大規模なサービス停止のニュースを生まないようにしましょう。

「期待は戦略ではありません。」この言葉は、カオスエンジニアリングの核となる哲学を体現しています。私たちは、ビジネスがコストのかかるサービス停止に見舞われることがないようにと、ただ座して願っているわけにはいきません。カオスエンジニアリングをディザスターリカバリー（DR）テストに追加して今すぐ行動し、最悪の事態に備えることが不可欠です。

クラウドネイティブの世界では、カオスエンジニアリングは企業にとって必要不可欠です。それにより、自然災害、サイバー攻撃、予期せぬテクノロジー障害など、複数の原因から発生する一般的な破壊的事象に備えることができます。カオスエンジニアリングは、既に災害対策を行っている企業でも、始めたばかりの企業でも、チームに事前準備のための特別なレイヤーを提供できます

インシデントのコスト

サービスの中断はあらゆる業界で発生します。こうした停止はほとんどの場合において比較的短時間ですが、大規模な場合は、組織の収益や評判に大きな影響を与えることになります。ここで、ニュースとビジネスに対して非常に望ましくない影響をもたらした最近の事例をいくつかご紹介します。

• 2023 年１月、連邦航空局（FAA）では NOTAM（Notice to Air Missions）システムで問題が生じました。おそらく破損したデータベースファイルが原因で、国内・米国到着・米国発着の３万2000便のフライトが遅れました。米国の航空会社と影響を受けた旅行者への損害は計り知れません。また、FAAの評判に対する損害も大きく、一部の議員はFAAの活動に対する調査を求めました。
• 2022年12月、Southwest Airlinesは12月21日から31日までの1万6700便のフライトのキャンセルにつながる機能停止を経験しました。Southwestの停止には多数の要因がありましたが、時代遅れのコンピューターシステムが大きな要因となったことは間違いありません。Southwest Airlinesの株価は事件直後に急落し、航空会社は影響を受けた少なくとも １人の乗客から訴えられました。会社の提出書類によると、航空会社は停止により８億2500万ドルもの損失を被りました。
• 2021年12月、Amazon Web Services（AWS）では、Netflix、Slack、AmazonのRing、DoorDashなど、米国内の多数のビジネスに影響を与える複数のサービス停止がありました。このうち最初の障害は、自動化ソフトウェアの不具合により予期せぬ動作が発生し、その後AWSのネットワーク機器を圧迫して東海岸のコンピューターシステムに影響を与えたものです。停止の影響は広範囲に及んで、Google、Disney Plus、Venmoなどの企業に影響を与えました。

次なるニュースにならないように：ディザスターリカバリープランを作成する

大規模な計画外停止を回避するためには、今すぐディザスターリカバリーへの積極的なアプローチをとることが必要です。その第一歩として、ディザスターリカバリープラン（DRP）を作成します。DRPの導入は、技術・人・プロセスを包含する包括的な作業です。これらを組み合わせることで、効率的なリカバリーを実現するためのプレーブックとなります。

効果的なDRPを作成する上で重要なことは、エンジニアリングチームがビジネスリーダーと協力して、リソースを重要度の高い順にリストアップし、それらに関連する潜在的な障害ポイントをリストすることが含まれます（ビジネスインパクト分析とも呼ばれます）。次に、障害をシミュレートし、理論上の復旧順序（自動または手動）を検証する必要があります。

Harnessでは、サービスマップ作成のベストプラクティスを導入しています。これは、コンポーネントの重要度、インシデント履歴、コードまたはバイナリコンポーネント、関連する依存関係を含む基礎的なインフラコンポーネントの理解を含みます。最もシンプルな形として、サービスマップはデータベース、キャッシュ、メッセージブローカー、依存関係などの技術スタックの概要を示す必要があります。これにより、チームはシステムのアーキテクチャーを理解し、どのようなカオス試験を行うべきかを理解できます。

カオステストのメトリクスから洞察を得る

カオステストの利点の１つは、特定の重要なメトリクスの正確な理解が得られることです。

クラウドネイティブの世界におけるDRには、従来のアクティブ-パッシブモデルと、現在広く導入されているアクティブ-アクティブモデルの両方があり、クロスゾーンやクロスリージョンレプリカを採用したアプリケーション配置トポロジーを導入しています。上記における両方のDRモデルで、カオステストから得られる結果またはメトリクスは異なります。

• アクティブ-アクティブモデルでは、アップタイム／可用性とパフォーマンス（QPS、レイテンシー）が最大の関心事となります。これらは、エラーバジェットの消尽が限界内に収まっているかどうかを評価するのに役立ちます。
• Googleの４つのGolden Signals（レイテンシー、トラフィック、エラー、サチュレーション）は、SLIやSLOに代表される先行指標となり、エラーバジェットが制限内に収まっているかどうかを評価するのに役立つとされています。
• アクティブとパッシブの場合、MTTR（mean-time-to-recovery）やTTM（time-to-mitigate）が最重要視されます。これらは、復旧時間目標（RTO）や復旧時点目標（RPO）が達成されているかどうかを測るのに役立ちます。
• 平均故障検出時間（MTTD）や、観測可能性（プラットフォーム内のアラート、ログ、その他のデバッグ補助の効率）に関するその他の予測など、注目すべき共通の属性もあります。

DRPの一部としてのカオス試験は、多くの場合、複数のステークホルダーが参加するゲームデー（ファイアードリルとも呼ばれます）として実施されます。このゲームデーで実施されるカオスシナリオは、復旧経路が固まるにつれて爆風半径の構成が大きくなっていくことが予想されます。

Harness Chaos Engineeringで、ITのDRを継続的レジリエンスに進化させよう

カオスエンジニアリングは、計画外のダウンタイムに伴う財務的・風評的な影響を最小限に抑えることができます。また開発者は、本番インシデントの火消しではなく、ソフトウェアデリバリーに集中できます。

カオス試験は、従来の単体テスト、統合テスト、システムテストの枠を超え、実際の生産環境でのランダムな失敗をより忠実に再現するものです。この現実的な環境は、システムがどのように動作するかを理解し、アプリケーションやインフラに存在する弱いリンクを理解し、コストのかかるダウンタイムを防止するレジリエンスを積極的に作り出せるようにします。

Harness Chaos Engineering（CE）モジュールは、エンジニアリングチームと信頼性チームが計画外のダウンタイムのリスクを回避するのに役立ちます。システムの弱点を特定し、意図的に障害シナリオ（カオス）を作成して信頼性を向上するのに役立ちます。

カオスエンジニアリングの導入は、かつてないほど簡単になりました。組織がこのプラクティスを導入し、信頼性を向上する方法を確認したい場合は、 Harness CEのデモをリクエストするか、 SaaSトライアルを今すぐ開始してください！

この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。