LASSIC Media らしくメディア
カオスエンジニアリングを外注で始める進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- カオスエンジニアリングとは、意図的に障害を注入してシステムの弱点を先に見つける予防的な手法です。
- 実験には定常状態の定義・仮説設定・ブラストラディウスの最小化という設計上の原則があります。
- 外注する場合は委託範囲の切り分けと、SLI/SLOやオブザーバビリティとの連携が成果を左右します。
目次
カオスエンジニアリングとは — 障害を注入して弱点を先に見つける手法
カオスエンジニアリングとは、本番環境に近い環境でシステムに意図的な障害を注入し、その挙動を観察することで耐障害性を検証する実験的な手法を指します*1。Netflixのエンジニアが中心となって整理した「Principles of Chaos Engineering」は、この分野を「本番環境での乱流状態に耐える システムの能力への確信を構築するため、システムに対して実験を行う分野」と定義しています*1。障害が起きてから対応する事後対応ではなく、障害が起きる前に弱点を洗い出す予防的なアプローチである点が特徴です。
Principles of Chaos Engineeringは、この手法の基本ステップを「定常状態の定義」「制御群と実験群の両方で定常状態が継続するという仮説の設定」「現実世界のイベントを反映した変数の導入」「制御群と実験群の定常状態の差異の検証」という4段階で整理しています*1。実験を1回きりで終える検証ではなく、仮説を立てて障害を注入し挙動を観察し設計を見直すという反復のプロセスとして運用する点が要点です。
従来の障害テストとの違い
従来の障害テスト（フォールトインジェクションテスト）は、既知の単一障害点に対して事前に定義したシナリオを検証する手法として使われてきました。特定のコンポーネントを停止させたときに想定した挙動になるかを確認する、いわば「決められた質問に答える」検証です。
一方でカオスエンジニアリングは、Principles of Chaos Engineeringが示すとおり「本番環境での実験実施」と「継続的な自動化」を前提とする点で異なります*1。同資料は「実際のトラフィックパターンの中でのみ信頼性のある検証が可能」であり、「手動実験は持続不可能であるため、自動化・継続実行が必須」と述べています*1。ステージング環境の限定的なテストで終わらせず、本番相当の環境で継続的に実験を回し続けることで、想定していなかった障害パターンも発見しやすくなります。
つまり従来の障害テストは「既知のリスクへの備え」を確認する工程であり、カオスエンジニアリングは「未知の弱点」を能動的に発見する工程だといえます。両者は排他的ではなく、既存の障害テストの延長線上に、より広い探索範囲を持つ実験を継続的に積み重ねる位置づけになります。
実験設計の原則 — 定常状態・仮説・ブラストラディウス
実験を設計するうえでは、Principles of Chaos Engineeringが挙げる5つの高度な原則を踏まえる必要があります*1。第一に「定常状態の仮説構築」です。同資料は「その出力の短期間の測定値が、システムの定常状態の代理指標を構成する」と説明しており*1、スループットやエラー率など測定可能な指標を通常時の基準値として定めることが出発点になります。
第二に「現実世界のイベントの導入」です。ハードウェア障害・ネットワーク切断・トラフィックの急増など、実際に発生し得るイベントを変数として反映します*1。第三に「本番環境での実験実施」、第四に「継続的な自動化」であり、前述のとおり実運用に近い条件下で繰り返し実行することが信頼性の高い検証につながります*1。
第五の原則が「ブラストラディウスの最小化」です。ブラストラディウス（障害注入が影響を及ぼす範囲）を小さく設定し、顧客への悪影響を抑える責任を実験の設計者が負うという考え方です*1。実務上は、影響範囲を一部のトラフィックやインスタンスに限定し、異常を検知した時点で即座に実験を停止するロールバック条件をあらかじめ組み込みます。この設計を誤ると、検証のための実験自体が予期しない障害を引き起こす可能性があるため、最初の実験ほど影響範囲を狭く設定することが欠かせません。
代表的な障害シナリオと注入方法の種類
カオスエンジニアリングで注入する障害シナリオには、いくつかの代表的な種類があります。インスタンスやコンテナを意図的に停止させる障害、通信経路にレイテンシ（応答の遅延）を発生させる障害、依存する外部サービスやAPIへの接続を遮断する障害などが代表例です。Gremlin社が提供するプラットフォームのドキュメントでは、高CPU使用率の発生・ネットワークレイテンシ・パケット損失・依存サービスの喪失などが障害注入の対象として挙げられています*2。
これらの障害注入を支援するツールには複数の種類があります。Netflixが公開した「Chaos Monkey」はインスタンスをランダムに停止させる仕組みとして知られ、カオスエンジニアリングという分野の起点になったツールの一つです*2。Gremlinはインスタンス停止やレイテンシ注入などの障害を制御された条件下で実行するための商用プラットフォームを提供しています*2。
AWSが提供する「AWS Fault Injection Service（FIS）」は、コントロールされたフォールトインジェクション実験を実行するフルマネージドサービスです*3。同サービスの説明では「従来のテストで見過ごされた弱点を見つける」ことを目的とし、事前構築済みのシナリオを使って実験を実行できるとされています*3。また「特定の条件を定義」しておくことで、異常検知時に実験を停止・ロールバックする制御が可能な点も特徴です*3。これらのツールはいずれも一長一短があり、対象システムの構成やクラウド環境によって適した選択肢が変わるため、どれか一つが常に優れているとは言えません。
障害シナリオを選ぶ際は、自社システムで過去に実際に発生したインシデントの傾向を出発点にすることが実務的です。過去に依存サービスの障害で影響が広がった経験があるなら、依存サービス遮断のシナリオを優先する、といった形でシナリオの優先順位を組み立てます。
カオスエンジニアリングを内製で進める難易度
カオスエンジニアリングを内製で進めるには、対象システムのアーキテクチャ全体を把握した上で、どこにどのような障害を注入すれば意味のある検証になるかを設計するスキルが必要です。具体的には、依存関係の全体像を把握する設計理解、障害注入ツールを本番相当環境に組み込む実装スキル、異常検知時に即座に実験を止める監視・ロールバック体制の3つが求められます。
実験の設計を誤ると、実務上の影響は小さくありません。ブラストラディウスの設定を誤り本番環境で想定より広い範囲に障害を伝播させると、実験そのものが顧客影響を伴う障害になり得ます。監視体制が整っていない状態で本番実験を始めると、異常の検知が遅れ、影響が拡大した後で気づくという事態も起こり得ます。
また、カオスエンジニアリングは一度実験して終わりにするものではなく、継続的に繰り返す運用が前提です*1。システム構成が変わるたびに実験シナリオを見直し、検知したロールバック条件が実態に合っているかを定期的に検証する体制が必要になります。専門パートナーに設計を依頼した場合との違いは、障害注入ツールの選定パターンやブラストラディウス設計の実践知識を最初から持っている点にあります。内製で一から試行錯誤する場合は、最初の実験設計でやり直しが発生しやすく、本番実験を安定して回せる体制が定着するまでに複数回の見直しを要します。
外注する場合の委託範囲と発注側の準備
カオスエンジニアリングの導入を外注する場合、委託範囲は主に4つの工程に分けられます。第一に既存システムの依存関係調査による実験対象・障害シナリオの選定、第二に障害注入ツールの選定と本番相当環境への組み込み、第三にブラストラディウスとロールバック条件を含む実験計画の設計、第四に実験結果の評価と耐障害性改善の提案です。
発注側が準備しておくべき情報としては、対象システムのアーキテクチャ図と依存サービスの一覧、過去のインシデント発生履歴、現行の監視・アラート体制の状況、実験の実施を許可できる時間帯や範囲の特定が挙げられます。これらが整理されているほど、委託先は障害シナリオの絞り込みと実験計画の設計を早く進められます。
| 委託工程 | 委託先が担う作業 | 発注側が準備する情報 |
|---|---|---|
| 対象・シナリオ選定 | 依存関係調査と障害シナリオの提案 | アーキテクチャ図・依存サービス一覧 |
| ツール選定・組み込み | 障害注入ツールの選定と実装 | 現行の監視・アラート体制の状況 |
| 実験計画の設計 | ブラストラディウス・ロールバック条件の設計 | 過去のインシデント発生履歴 |
| 結果評価・改善提案 | 実験結果の分析と耐障害性改善の提案 | 実験実施を許可できる時間帯・範囲 |
委託範囲を決める際は、実験計画の設計だけを外部パートナーに依頼し、実際の実験実行・監視は社内チームが担う形にすることもできます。設計フェーズに専門知識を借りることで、自社にノウハウを蓄積しながら初回実験の手戻りを避けられます。
SLI/SLO・オブザーバビリティとの関係
カオスエンジニアリングは、SLI（サービスレベル指標）・SLO（サービスレベル目標）やオブザーバビリティ（システムの内部状態を外部から観測できる状態、監視基盤の整備によって実現される）と組み合わせて運用することで効果を発揮します。実験によってシステムの挙動を観察するには、そもそも通常時の定常状態を数値で捉えられている必要があるためです。
Principles of Chaos Engineeringが定義する「定常状態」は、まさにSLIとして計測される指標そのものです*1。SLI/SLOの設計が先に整っていれば、カオスエンジニアリングの実験で「定常状態からどの程度ずれたか」を客観的な数値で評価できます。逆にSLI/SLOが定まっていない状態で障害注入を行うと、実験結果が「なんとなく問題があった」という定性的な感触にとどまり、改善の優先順位付けに使いにくくなります。
同様に、オブザーバビリティが整っていなければ、障害注入後にシステム内部でどのような挙動が起きたかを追跡できません。ログ・メトリクス・トレースが十分に整備された環境であるほど、カオスエンジニアリングの実験結果から具体的な改善点を特定しやすくなります。導入の優先順位としては、オブザーバビリティとSLI/SLOの土台を先に整え、その上でカオスエンジニアリングによる能動的な検証を積み重ねる進め方が実務的です。
まとめ — 予防的な信頼性テストを始める3つの軸
本稿では、カオスエンジニアリングの定義・実験設計の原則と、外注を検討する際の委託範囲・発注準備を整理しました。要点を3つに集約すると次の通りです。第一に、カオスエンジニアリングは障害が起きる前に弱点を能動的に見つける予防的な手法であり、仮説設定・障害注入・観察・改善を反復するプロセスとして運用します。第二に、実験設計では定常状態の仮説構築とブラストラディウスの最小化が特に重要で、影響範囲を小さく保ちながら本番相当の環境で継続的に検証を積み重ねます。第三に、外注する場合は対象・シナリオ選定から結果評価まで4工程に委託範囲を切り分け、SLI/SLOやオブザーバビリティの整備状況を発注前に整理しておくことが成果を左右します。
よくある質問
カオスエンジニアリングは本番環境でなければ実施できませんか。
ステージング環境でも実施できますが、Principles of Chaos Engineeringは実際のトラフィックパターンの中でのみ信頼性のある検証が可能だとしています*1。最初はステージングで手順を確認し、ブラストラディウスを小さく設定した上で段階的に本番環境へ移行する進め方が実務的です。
従来の障害テストと何が違うのですか。
従来の障害テストは既知の単一障害点を事前定義したシナリオで確認する検証です。カオスエンジニアリングは本番相当の環境で継続的に実験を繰り返し、未知の弱点を能動的に発見する点が異なります*1。
ブラストラディウスとは何ですか。
ブラストラディウスとは、障害注入の実験が影響を及ぼす範囲を指します。Principles of Chaos Engineeringは、この範囲を最小化し顧客への悪影響を抑える責任を実験の設計者が負うべきだとしています*1。最初の実験ほど対象範囲を狭く設定することが、導入時に踏まえておくべき前提です。
どのツールを使えばよいですか。
Chaos Monkey・Gremlin・AWS Fault Injection Serviceなど複数の種類があり、対応する障害シナリオやクラウド環境との親和性がそれぞれ異なります*2*3。どれか一つが常に優れているわけではなく、自社システムの構成と過去のインシデント傾向に合わせて選ぶことが実務的です。
SLI/SLOを設計していないとカオスエンジニアリングは始められませんか。
始めること自体は可能ですが、定常状態を数値で捉えられていないと実験結果の評価が定性的な感触にとどまりやすくなります。SLI/SLOやオブザーバビリティの土台を先に整えたうえで実験を積み重ねる進め方が効果的です。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Principles of Chaos Engineering「Principles of Chaos Engineering」（https://principlesofchaos.org/）
- *2 出典：Gremlin, Inc.「Chaos Engineering」（https://www.gremlin.com/chaos-engineering）
- *3 出典：Amazon Web Services「AWS Fault Injection Service」（https://aws.amazon.com/jp/fis/）
