VMSSに対する実験
実験の準備
第1回の記事の「カオスエンジニアリングのプロセス」に則り、実験を計画します。一般的に、最低でも下記について検討が必要になります。
- 定常状態の定義
- 実験実施時の仮説（実験の内容）
- 影響範囲の限定方法
- 異常終了時の復旧方法
今回のシステムではそれぞれの項目に対して以下のように決定したとします。
| # | 項目 | 内容 |
|---|---|---|
| 1 | 定常状態 | トップページへのhttpリクエストのレスポンスが200である |
| 2 | 仮説 | VMSS内のVMが1台停止したとしてても定常状態を維持する（1台停止後、5分間待機する） |
| 3 | 影響範囲の限定方法 | 停止するVMを指定する |
| 4 | 異常終了時の復旧方法 | 停止したVMSS内のVMを起動する |
上記の条件での実験をChaos Toolkitで実現する場合、下記の実験ファイル（experiment.json）を作成します。
{
"version": "1.0.0",
"title": "...",
"description": "...",
"tags": [
"azure",
"VMSS"
],
"configuration": {
"azure_subscription_id": "xxxx"
},
"secrets": {
"azure": {
"client_id": "xxxx",
"client_secret": "xxxx",
"tenant_id": "xxxx"
}
},
"steady-state-hypothesis": {
"title": "Services are all available and healthy",
"probes": [
{
"type": "probe",
"name": "service-must-still-respond",
"tolerance": 200,
"provider": {
"type": "http",
"verify_tls": false,
"url": "https://xxxx"
}
}
]
},
"method": [
{
"name": "stop-vmss",
"type": "action",
"provider": {
"type": "python",
"module": "chaosazure.vmss.actions",
"func": "stop_vmss",
"arguments": {
"filter": "where resourceGroup=='your resource group name' and name=='your vmss name'",
"instance_criteria": [ {"name": "your vmss instance name"} ]
},
"secrets": [
"azure"
],
"config": [
"azure_subscription_id"
]
},
"pauses": {
"after": 300
}
}
],
"rollbacks": [
{
"name": "restart-vmss",
"type": "action",
"provider": {
"type": "python",
"module": "chaosazure.vmss.actions",
"func": "restart_vmss",
"arguments": {
"filter": "where resourceGroup=='your resource group name' and name=='your vmss name'",
"instance_criteria": [ {"name": "your vmss instance name"} ]
},
"secrets": [
"azure"
],
"config": [
"azure_subscription_id"
]
}
}
]
}
実験ファイルの作成にあたり、気をつけるポイントは以下のとおりです。
1. steady-state-hypothesis
steady-state-hypothesisでは、定常状態の定義を行います。今回のシステムではロードバランサーのエンドポイントへのリクエストでHTTPステータスコードが200で返ってくるとしています。現時点ではChaos ToolkitのビルトインでサポートされているHTTPレスポンスの確認はHTTP HeaderやBodyの情報だけとなっており、レスポンスタイム（1秒以内など）を指標とした定常状態の定義はできません。
2. method
methodには、カオスとして挿入したいアクションを設定します。chaosazureに用意されているActionでは、filterやinstance_criteriaを利用して、カオスの対象を細かく指定することが可能です。指定しない場合はランダムに対象を選択されてしまうため、想定外の事象が起きる確率を下げるためにも、これらを指定します。
3. rollbacks
rollbacksでは、定常状態を満たさなくなった場合に復旧させる処理を記載します。実験の実行時にrollback-strategyオプションを利用することで、どのような条件の時に記載した処理を実行するかを指定が可能です。
実験の実施
執筆時点でのchaosazure version 0.10.0は、AzureのVMSSのAPIの仕様変更を反映できておらず、そのままでは実行時に下記エラーが発生します。
failed: AttributeError: 'ItemPaged' object has no attribute 'advance_page'
そのため、chaosazure/vmss/fetcher.pyの修正を行う必要があります。
68行目～76行目をコメントアウトし、以下のコードを追加します。
for item in pages:
vmss_instances.append(item)
上記の修正が完了したら、下記コマンドで実験を行います。
chaos run ./experiment.json --hypothesis-strategy continously --hypothesis-frequency=20 --rollback-strategy=deviated
コマンドのオプションについて、以下のような設定が可能です。
1. hypothesis-strategy
定期的に定常状態を満たすかを確認したいため、「continously」を指定します。その他のオプションは下記をご参照ください。
2. hypothesis-frequency
定常状態をチェックする間隔を指定します。Azure Loadbalancerはデフォルトで作成した場合、5秒間隔／2回連続で正常性チェックに失敗するとバックエンドのVMが異常状態と判断します。それよりも短い間隔で定常状態のチェックを行うと、異常状態VMへ通信が届いてしまい、Chaos Toolkitでの正常状態チェックに失敗し、実験が異常終了してしまうため、余裕を持って20秒間隔を指定しています。
3. rollback-strategy
実験時に定常状態を満たさなくなった場合に限り、ロールバックを実行する「deviated」を指定します。
下記のように表示されれば、実験は成功です。定常状態をチェックするタイミングによっては実験に失敗することもあるかと思いますので、その場合は何度か実験を試行してください。
Experiment ended with status: completed
次回予告
次回は、Azure Web Appsに対するChaos Toolkitによるカオスの挿入方法について紹介します。
