AWSの障害シミュレーション機能であるFault Injection Service(以降FIS)に、先日AZ障害を想定したシナリオがリリースされました。
これまでFISの事は知っていたものの触ったは無かったのですが、AZ障害は業務でもよく話に出てきますので今後のテストで使えるかもと思い試してみました。
現在EKSの管理を業務で行っている事もあり、EKSの障害という想定で試してみました！
FISの基礎知識
まずFISで使われるオブジェクトについて簡単に解説します。
- 実験
- 障害テスト自体を指します
- 実験テンプレート
- どのリソースにどの様な障害を発生させるか等の仕様を定義したオブジェクトです
- シナリオライブラリ
- EC2インスタンス障害やEKS Pod削除等、AWSが用意しているプリセットの実験テンプレートです
障害テスト実施までの流れは以下になります。
- 実験テンプレートを作成する
- 実験を開始する
実験テンプレートは1から自分で作成も可能ですし、シナリオライブラリから作成する事も可能です。
今回は後者のシナリオライブラリを利用してテンプレート作成しました。
シナリオ1.EKSワーカーノード単一障害
まずはじめに、EKSワーカーノード(EC2)の単一障害のシナリオを作って実験してみます。
実験テンプレートを作成
FIS画面の左側にあるシナリオライブラリをクリックします。
AWSが用意している障害シナリオが一覧で表示されます。
EC2ストレス:インスタンス障害にチェックを付けて、Create template with scenarioボタンをクリックします。
すると実験テンプレート作成画面に移ります。
デフォルトの内容からほとんど修正する必要は無いのですが、リソースタグだけ修正します。
というのもEC2ストレス:インスタンス障害は障害を発生させる対象のEC2インスタンスを以下のインスタンスタグで識別する様になっています。
| キー | 値 |
|---|---|
| Ec2InstanceFailure | Allowed |
もちろん対象EC2インスタンスにこのリソースタグを付与するでも良いのですが、今回は既に付与されている以下のリソースタグを指定する様に実験テンプレートの方を修正します。
| キー | 値 |
|---|---|
| eks:nodegroup-name | my-eks-nodegroup |
ターゲットとして登録されているTaggedInstancesをクリックします。
ターゲットを編集ポップアップが表示されます。
上述のリソースタグで修正して保存ボタンをクリックします。
実験テンプレートの名前はNameタグで付ける事ができます。
ここまで設定したら実験テンプレートを作成ボタンをクリックします。これで実験テンプレート作成完了です。結構簡単ですね！
実験開始！
作成した実験テンプレートを使って早速実験してみます。
左側の実験テンプレートを選択して、今回作成した実験テンプレートを選択し、実験を開始ボタンをクリックします。
すると実験を開始画面が表示されます。実験を開始ボタンをクリックします。
今度は実験を開始ポップアップが表示されます。障害を発生させてサービスに影響を与えてしまうかもしれない事もあり、本当に実行するの？と何回も聞かれますね。。。
今回は検証環境ですので躊躇無く進めます。
フィールドに開始の文字を記載した後実験を開始ボタンをクリックします。
これでやっと実験開始です。
実験が開始されました！実験テンプレート内で設定されたアクションであるStopActionがRunningになっています。
EKSワーカーノードの状態を見てみます。おぉ、ちゃんとワーカーノードが停止になっていますね！
しばらくしたら、ワーカーノードが1台起動してきました。EKSクラスタのノードグループがちゃんと仕事をしています。実験成功です！
シナリオ2.AZ障害
ではいよいよ本題のAZ障害を発生させてみます。
といっても流れはEC2障害とほぼ変らずです。
実験テンプレートを作成
シナリオライブラリから今回はAZの可用性:電源の中断にチェックを入れてCreate template with scenarioボタンをクリックします。
実験テンプレート作成画面に移りますが、先程のEC2障害と比較してたくさんのアクションとターゲットが設定されています。
AZ障害時に発生するであろう複数リソースの障害を同時に発生させるシナリオになっています。
便利ですね～
デフォルトですと各ターゲットのリソースタグには以下が付与されていました。
| キー | 値 |
|---|---|
| AzImpairmentPower | IceAsg |
障害対象のリソースとこのタグを合わせる必要がありますので、今回はEC2インスタンスとAutoScalingGroupのターゲットで以下に変更しました。
| キー | 値 |
|---|---|
| eks:nodegroup-name | my-eks-nodegroup |
また属性パスで以下を設定が設定されていましたので、デフォルトではap-northeast-1aが停止になる様です。
これを設定変更すれば障害対象のAZを指定できますね。
| キー | 値 |
|---|---|
| Placement.AvailabilityZone | ap-northeast-1a |
後はEC2障害と同様の際と同様に実験テンプレートを作成ボタンをクリックして実験テンプレートを作成します。
実験開始！
いよいよAZ障害発生させます。
実験開始の流れはEC2障害と同じなので割愛しますね。
実験テンプレート内に設定された複数のアクションが同時にRunningになっています。
RDSやElasticache等は今回作成していないのでSkippedになっています。
ap-northeast-1aで起動していたワーカーノードが2台落ちて、、
代りにap-northeast-1cで2台ワーカーノードが自動で起動してきました。
こちらも実験成功です！
おわりに
今回はFISを用いてEKSクラスタのAZ障害のシミュレーションを実施してみました。
これまでAZ障害は当然基盤構成で考慮はしないといけないものの、中々テストが難しいと業務で常々思っていましたが、FISを使う事でそれがお手軽に行えましたので感動しています！
業務でも使っていきたいなと思いました！