AWSとAzureのマネージドサービスの実装状況の比較
以下の観点に基づき、記事執筆時点（2022年6月）での各サービスの実装状況を見ていきます。
-
定常状態の定義
- 定常状態を定義する方法
- 異常状態の検知方法
-
影響範囲の限定
- 事前シミュレーション機能
- カオス挿入の対象の選定方法
- ロールバック機能
-
実験管理の負荷
- 実験の記録
- 実験のコード管理
- 実験の共有
- 実験からの示唆
定常状態の定義
AWS、Azureのどちらもまず異常状態を定義し、その異常状態でなければ定常状態であるという逆説的に定常状態を定義する実装です。どちらも異常状態は監視サービスを利用して検知する方式となり、定常状態の定義に関する機能はほぼ同一です。
| 観点 | AWS Fault Injection Simulator（FIS） | Azure Chaos Studio |
|---|---|---|
| 定常状態の定義方法 | 異常状態を定義することで逆説的に定常状態を定義する。 | Chaos Studioの機能として定常状態を定義できず、Azure Monitor等の他の監視サービスにて異常状態を定義する。 |
| 異常状態の検知方法 | 異常状態の定義はCloudWatchアラームで表現が可能なものであればなんでもよい。 異常状態は最大で5つまで指定可能である。 |
異常状態の定義はAzure Monitor等の監視サービスで表現が可能なものであればなんでもよい。 |
影響範囲の限定
AWSでは、元の状態に戻すロールバックが可能な実験の場合、ロールバックを設定しないと実験ができない仕様とすることで影響範囲の限定ができる特徴を持っています。一方Azureでは、実験を行う側（Chaos Studio）と実験の対象側（仮想マシンなど）の双方でアクセス権付与を明示的に行わないと実験ができない仕様とすることで影響範囲の限定ができる特徴を持っています。
システム規模が大きくなるにつれ想定外の状況になる可能性も高くなるため、シミュレーションできる機能があると望ましいと筆者は考えていましたが、どちらも該当する機能は現時点ではありません。
| 観点 | AWS Fault Injection Simulator（FIS） | Azure Chaos Studio |
|---|---|---|
| 事前シミュレーション機能 | 事前シミュレーションは不可である。 | 事前シミュレーションは不可である。 |
| カオス挿入の対象の選定方法 | AWSリソースIDを指定することで厳密にカオス注入の対象を選定可能である。 上記に加えてタグによるターゲット選定やリソース属性を指定したフィルタリングでのターゲット選定も可能である。 |
Chaos Studioの実験作成時に対象のリソースを指定するだけでなく、対象のリソース（たとえばVMなど）からもChaos Studioの実験にアクセス権を付与し、相互に設定しなければ実験が実行できないようにしている。 |
| ロールバック機能 | インスタンスの停止やインスタンへの負荷掛けや一時的なネットワーク不通などの実験以前の状態に戻すことが可能なアクション（カオスの注入）に関しては、必ずロールバックを設定しなければ、実験として登録することができない。実験終了時に実験以前の状態に戻すロールバックが自動実施される。 | Chaos Studioの機能としてはロールバックはなく、別の仕組みを用意する必要がある。 |
実験管理の負荷
AWS、Azureのどちらも実験結果を保存し、後から参照することが可能です。また実験をコードとして管理でき、実験を他者と共有する仕組みも備えており、実験管理に関する機能はほぼ同一です。
影響のある実験を安易に行われないようにするための承認ワークフローや実験結果から示唆を提示してくれる機能があると望ましいと筆者は考えていましたが、どちらも該当する機能は現時点ではありません。
| 観点 | AWS Fault Injection Simulator（FIS） | Azure Chaos Studio |
|---|---|---|
| 実験の記録 | 実験ごとに一意のIDが付与され、過去の実験は最大120日間保持される。 実験の詳細として、どのリソースに対してどのようなカオス注入を行ったかやその結果について確認することができる。 CloudWatch LogsまたはS3に実験時のログを保存することができる。 |
実験の詳細として、どのリソースに対してどのようなカオス注入を行ったかやその結果について確認することができる。 実行ログをChaos Studio外に保存することは不可であるが、実験を削除しない限り無期限に保存される。 |
| 実験のコード管理 | 実験自体の管理ではなく、実験のもととなるテンプレートをCloudFormationにてコード管理することが可能である。 | ARM Templateにて管理が可能である。 |
| 実験の共有 | IAMにてFISの権限を付与することで、複数人で実験テンプレートや結果を共有が可能である。 実験テンプレートはjson形式でエクスポート／インポートすることが可能なため、別AWS環境でも再利用が可能である。 |
IAMにてChaos Studioの権限を付与することで、複数人で結果を共有することが可能である。 |
| 承認フロー | FISの機能だけで承認フローは持っていない。そのためStep Functions等を利用し、別途作り込むことで実現が可能である。 | Chaos Studioの機能だけで承認フローは持っていない。Azure Logic AppsからChaos Studioを呼び出し、Azure Logic Appsにて承認フローを組み込むことで実現が可能である。 |
| 実験からの示唆 | 実験結果を受けて、FISから推奨事項などが提示されることはない。 | 実験結果を受けて、Chaos Studio から推奨事項などが提示されることはない。 |
次回予告
実際にAWS Fault InjectionおよびAzure Chaos Studioを利用して、AWSおよびAzure環境へのカオス挿入の方法について紹介します。
