Google Cloud でのカオス エンジニアリング: 原則、実践、開始方法

※この投稿は米国時間 2025 年 10 月 14 日に、Google Cloud blog に投稿されたものの抄訳です。

エンジニアであれば誰でも、完璧な復元力を持つシステムを夢見ます。完璧にスケーリングし、優れたユーザー エクスペリエンスを提供し、決してダウンしないシステムです。このような復元力のあるシステムを構築する鍵が、障害を回避することではなく、意図的に障害を引き起こすことだとしたらどうでしょうか。カオス エンジニアリングの世界へようこそ。ここでは、管理された環境でシステムにカオス（障害）を導入して、システムにストレステストを行います。ダウンタイムが数百万ドルの損失につながり、評判が瞬く間に失墜する時代において、最も革新的な企業としては、災害が起こるのをただ待っているだけではいけません。災害を意図的に引き起こし、その結果として生じる障害から学び、本番環境で混乱が起こる前に混乱に対する免疫を獲得して行くのです。

カオス エンジニアリングはあらゆる種類のシステムに役立ちますが、特にクラウドベースの分散システムに有効です。最新のアーキテクチャは、モノリシックなシステムからマイクロサービス ベースのシステムへと進化し、多くの場合、数百から数千のサービスで構成されています。このように複雑なサービス依存関係は、複数の障害点をもたらします。また、従来のテスト方法では、あらゆる障害モードを予測することは、不可能ではなくても、困難です。これらのアプリケーションをクラウドにデプロイすると、複数のアベイラビリティ ゾーンとリージョンにデプロイされます。クラウド環境は分散性が高く、多数のサービスが共存しているため、障害の発生する可能性が高くなっています。

良くある誤解ですが、クラウド環境ではアプリケーションには自ずと復元力があるので、テストは不要であるというものがあります。クラウド プロバイダは、クラウド プロダクトに対してさまざまなレベルの復元力と SLA を提供していますが、これだけではビジネス アプリケーションが保護されるとは限りません。アプリケーションがフォールト トレラントになるように設計されていない場合や、クラウド サービスが常に利用可能であることを前提としている場合、依存している特定のクラウド サービスが利用できなくなると、アプリケーションは動作しなくなります。

手短に言えば、カオス エンジニアリングは、担当者にとって最悪の「もしも」のシナリオを想定し、それに対する対応を十分にリハーサルできるようにします。カオス エンジニアリングは、システムを破壊すること（いわばカオスなエンジニアリング）ではありません。カオス エンジニアリングは、管理された条件下とはいえ、すでにカオスを乗り切った経験から得られる冷静な自信を持って本番環境のインシデントに対処できるチームを構築することです。

Google Cloud の Professional Service Organization（PSO）エンタープライズ アーキテクチャ チームは、アプリケーション開発、クラウド移行、エンタープライズ アーキテクチャなど、お客様のクラウド変革の取り組みについてコンサルティングを行い、実践的な専門知識を提供しています。また、クラウド環境向けの復元力のあるアーキテクチャの設計についてアドバイスする際には、カオス エンジニアリングの原則とプラクティス、およびサイト信頼性エンジニアリング（SRE）のプラクティスを定期的に紹介しています。

シリーズの最初になるこのブログ投稿では、カオス エンジニアリングの基本、つまりカオス エンジニアリングとは何か、そのコアとなる原則と要素について説明します。次に、クラウドで分散アプリケーションを実行しているチームにとって、カオス エンジニアリングが特に役立ち、重要である理由を説明します。最後に、これを活用開始する方法と、その他のリソースについて説明します。

カオス エンジニアリングについて

カオス エンジニアリングは、Netflix が 2010 年に考案した手法です。AWS 環境の複雑度が上がる中、より復元力と信頼性が高いシステムを構築する必要性に対処するため、「Chaos Monkey」を作り出し、普及させました。同じ頃、Google は障害復旧テスト（DiRT）を導入しました。これにより、Google のビジネス、システム、データの継続的て、自動的な障害対策、対応、復旧が可能になりました。Google Cloud の PSO チームでは、お客様が SRE プラクティスの一環として DiRT を実装できるよう、さまざまなサービスを提供しています。これらのサービスには、Google Cloud で動作するアプリケーションやシステムで DiRT を実行する方法に関するトレーニングも含まれています。中心となるコンセプトは単純です。管理された障害を意図的にシステムに導入して、脆弱性を特定し、その復元力を評価し、全体的な信頼性を高めるというものです。

予防的な手法であるカオス エンジニアリングにより、組織はシステム内の弱点を、大規模なサービス停止や障害につながる前に特定できます。ここで言うシステムには、技術的なコンポーネントだけでなく、組織の人員やプロセスまでも含まれます。カオス エンジニアリングでは、管理された、実際の停止状態を導入することで、システムの堅牢性、復元可能性、フォールト トレランスをテストできます。このアプローチによって担当者は潜在的な脆弱性を発見できるため、システムは予期しないイベントに対処し、ストレス下でもスムーズに機能し続けることができます。

カオス エンジニアリングの原則と実践

カオス エンジニアリングは、これを実施すべき理由に関する一連の基本原則によって導かれ、また実践は実施すべき内容を定めます。

カオス エンジニアリングの原則は次のとおりです。

1. 定常状態に関する仮説を立てる: 停止を引き起こすアクションを開始する前に、システムにとっての「正常」な状態がどのようなものかを決定する必要があります。これは一般に「定常状態仮説」と呼ばれます。
2. 現実世界の状況を再現する: カオステストでは、本番環境でシステムが遭遇する可能性のある現実的な障害シナリオをエミュレートします。
3. 本番環境でテストを実行する: カオス エンジニアリングは、実際のトラフィックと、依存関係の両方がある本番環境でのみ復元力の正確な全体像を把握できるという信念にしっかりと根ざしています。これが、カオス エンジニアリングと従来のテストの違いです。
4. テストの自動化: 復元力テストを、一度限りのテストではなく、継続的なプロセスの一部にします。
5. 影響範囲を特定する: 本番環境システムへの悪影響を最小限に抑えるために、テストは綿密に設計する必要があります。そのためには、テストが顧客や他のアプリケーション、サービスに与える影響に基づいて、アプリケーションとサービスをさまざまな階層に分類する必要があります。

これらの原則を確立したら、カオス エンジニアリングのテストを実施する際に次の手法に従います。

1. 定常状態を定義する: 注目する特定の指標（レイテンシ、スループットなど）を特定し、それらのベースラインを確立します。
2. 仮説を立てる: これは、テスト可能な単一のステートメントを作成する手法です。たとえば、「このコンテナ Pod を削除しても、ユーザーのログインには影響しない」などです。仮説は通常、お客様のユーザー ジャーニーを特定し、そこからテスト シナリオを導き出すことで作成されます。
3. 管理された環境を使用する: カオス エンジニアリングの原則の一つに、テストは本番環境で実行する必要があるというものがありますが、まずは小規模に始め、非本番環境でテストを実行し、学び、調整してから、徐々に本番環境に範囲を拡大するようにしてください。
4. 障害の注入: これは、システムに直接（VM の削除、データベース インスタンスの停止など）または環境に間接的に（ネットワーク ルートの削除、ファイアウォール ルールの追加など）障害を注入して、停止状態を引き起こす手法です。
5. テストの実行を自動化する: カオス エンジニアリングを再現可能でスケーラブルなプラクティスとして確立するには、自動化が不可欠です。これには、障害注入に自動ツールを使用すること（CI/CD パイプラインの一部にするなど）や、自動ロールバック メカニズムを使用することが含まれます。
6. 行動につながるインサイトを導き出す: カオス エンジニアリングを使用する主な目的は、システムの脆弱性に関するインサイトを導き出し、それによって復元力を高めることです。これには、テスト結果の厳密な分析、弱点と改善すべき点の特定、関連チームへのテスト結果の周知が含まれ、これによってその後のテスト設計とシステム強化を行います。

つまり、カオス エンジニアリングは、単にシステムを壊すことが目的ではなく、システムの限界を理解し、それらに事前に対処することで、より復元力の高いシステムを構築することが目的です。

カオス エンジニアリングの要素

カオス エンジニアリング テストで使用するコア要素は、次の 5 つの原則から導き出されます。

• テスト: カオス テストは、システムに障害を発生させてその応答を確認する、意図的で事前に計画された手順で構成されます。
• 定常状態仮説: 定常状態仮説は、評価対象のシステムのベースラインとなる運用状態、つまり「正常」な動作を定義します。
• アクション: アクションは、テスト対象のシステムに対して実行される具体的なオペレーションを表します。
• プローブ: プローブは、テスト中にシステム内で定義された条件を観察するメカニズムを提供します。
• ロールバック: テストでは、テスト中に実装された変更を元に戻すように設計された一連のアクションが組み込まれる場合があります。

カオス エンジニアリングを開始する

カオス エンジニアリングと、クラウド環境でカオス エンジニアリングを使用する理由について理解を深めたら、次のステップとして、独自の開発環境で実際に試してみましょう。

市場には複数のカオス エンジニアリング ソリューションがあります。有料のプロダクトもあれば、オープンソースのフレームワークもあります。すぐに始めるには、Chaos Toolkit をカオス エンジニアリング フレームワークとして使用することをおすすめします。

Chaos Toolkit は、Python で記述されたオープンソースのフレームワークです。モジュール式のアーキテクチャが提供されており、他のライブラリ（「ドライバ」とも呼ばれます）をプラグインして、カオス エンジニアリングのテストを拡張できます。たとえば、Google Cloud、Kubernetes、その他多くのテクノロジーの拡張ライブラリがあります。Chaos Toolkit は Python ベースの開発者ツールであるため、まず Python 環境を構成します。Chaos Toolkit のテストの優れた例と、その手順については、こちらをご覧ください。

最後に、Google Cloud のお客様とエンジニアがアプリケーションにカオス テストを導入できるように、特に Google Cloud のための一群のカオス エンジニアリング レシピを作成しました。各レシピには、特定の Google Cloud サービスにカオスを導入する特定のシナリオを収めています。たとえば、あるレシピでは Google Cloud の内部または外部アプリケーション ロードバランサの背後で実行されているアプリケーション/サービスにカオスを導入し、また別のレシピでは ToxiProxy という別の Chaos Toolkit 拡張機能を利用して、Cloud Run で実行されているアプリケーションと Cloud SQL データベースに接続するアプリケーション間のネットワーク停止をシミュレートします。

Google Cloud 環境にカオス エンジニアリングを導入する方法を学ぶための、手順ガイド、スクリプト、サンプルコードを含むレシピの完全なコレクションは、GitHub にあります。今後の投稿では、Google Cloud 環境に障害を導入する方法など、カオス エンジニアリングの手法を取り上げますので、ご期待ください。

-Parag Doshi、キー エンタープライズ アーキテクト