はじめに
連載「クラウドネイティブ時代の実践カオスエンジニアリング」では、カオスエンジニアリングの概要や求められる背景、実践的な障害挿入の仕方や気を付けておきたい注意点などについて、エンタープライズシステムの設計開発に長年従事してきた現場エンジニアの視点から解説しました。
こうしたカオスエンジニアリングを効率的かつ安全に実施するためには、システムに関する多岐にわたる知識や経験が必要とされていましたが、クラウドベンダーからカオスエンジニアリングの実施をサポートするマネージドサービスが続々とリリースされてきており、カオスエンジニアリングの未経験者であっても簡単に挑戦しやすい状況が生まれています。
しかしながら、システム停止時の影響が大きいエンタープライズのシステムに対しては、前述のようなカオスの挿入にはハードルを感じる方々も多いかと思います。
本連載では、これからクラウドを活用したシステムを開発するエンジニアの皆様に向けて、AWSのFault Injection SimulatorおよびAzureのChaos Studioの2つのサービスを扱います。システムに対してどれだけ安全にカオスエンジニアリングを実施できるかという観点での比較や、実際にカオスの挿入を行う際に気を付けておくべき設定などについて、エンタープライズシステムの設計開発に長年従事してきた現場エンジニアが生の声をお届けします。
本連載のゴール
- AWSのFault Injection SimulatorおよびAzureのChaos Studioの2つのサービスについて、安全なカオスエンジニアリングを実施できるという観点での特徴を理解する。
- AWSのFault Injection Simulatorを使って基本的なパターンでのカオスエンジニアリングができる。
- AzureのChaos Studioを使って基本的なパターンでのカオスエンジニアリングができる。
対象読者
- 業務系システムの開発者・インフラ担当者
- アプリケーション開発の経験がある人
カオスエンジニアリングが求められる背景
DevOpsの流行もあり、追加開発を重ねていくシステムが増えています。長く追加開発を続けていくと、プログラム規模の増加やキーマンの離任といったことが起こりがちです。そうした状況だと各種モジュールの詳細仕様を把握しきれないままシステムが動作し続け、ある時何かのきっかけで大きな障害を起こしてしまうこともあり得ます。
カオスエンジニアリングはこうした追加開発を行っているシステムに効果が高く、強制的な障害（カオス）の挿入により、未知の情報（リトライ機構の実装漏れやモジュール間の想定していない依存関係など）を明らかにできます。
以前はカオスエンジニアリングの実施には、システムに関する多岐にわたる知識や経験が必要とされていましたが、クラウドベンダーからカオスエンジニアリングの実施をサポートするマネージドサービスが続々とリリースされてきており、未経験者でもカオスエンジニアリングに対するハードルは下がってきています。
ただしシステムに対して安全にカオスの挿入を行うには、考慮すべき観点があります。
システムに対して安全にカオスの挿入を行う上で考慮すべき観点
筆者が考慮すべき観点として考えているのは下記3点です。
- 定常状態の定義
- 影響範囲の限定
- 実験管理の負荷
定常状態の定義
単純な指標（たとえばHTTPステータスが200など）でしか定常状態を定義できないと、システムの状況を大雑把にしか把握できません。システムの状況を細やかに把握するため、さまざまな視点で定常状態を定義できる指標が用意されているかというのは非常に重要です。加えて、定常状態から外れているかを検知する方法が多数存在することも重要になります。
影響範囲の限定
システムへの安全なカオス挿入時にもっとも重要となるのが、影響範囲をコントロールすることです。この方法がどれだけ用意されているのかは安全なカオスエンジニアリングを実践する上で非常に重要です。
実験管理の負荷
カオスエンジニアリングは多くの関係者を巻き込んで実施していくことになるため、実験実施の承認、実験結果の管理や共有が適切に実施できないと、システム稼働への影響を与えるような実験を実施してしまう可能性があります。安全性を高めるためには、実験管理を効率的に実施できる仕組みが用意されていることが重要になります。
