読者です 読者をやめる 読者になる 読者になる

EC2 Auto RecoveryはどのくらいAuto Recoveryなのか

cloudpackエバンジェリストの吉田真吾@yoshidashingo)です。

以下のようなアナウンスがあり、Amazon EC2を自動復旧できるようになったようなので試してみました。
Amazon EC2 Auto Recovery now available in the US East (N. Virginia) Region

今までの自動復旧

1.Auto ScalingでAuto Healingパターン

自動復旧と言えばAuto Scalingを使った方法(最小インスタンス数=1、最大インスタンス数=1などで台数を固定して、必ずその台数が起動しているようにする)が有名です。Auto Scalingの動作として指定したAMIからの起動になるため、ミドルウェアの追加インストールやサービス登録、コンテンツなどを現状正常に稼動しているサーバーと同じ状態にするためには、起動時にcloud-initを使ったりして追加で追いつき作業が必要になることに注意です。

EC2 Auto Recoveryを設定してみる

さて、Auto Healingと似たような機能かなと想定して触ってみたのですが、どうやらそもそも考え方が違いそうなことに気づきましたので、実際に動かして確認してみましょう。

ドキュメント

以下を参照しながら作業します

1. CloudWatch Console でAlerms>Create Alerm>EC2 MetricsのPer-instance Metricsを選択する

f:id:yoshidashingo:20150114140849p:plain

2. StatusCheckFailed_Systemを選択

f:id:yoshidashingo:20150114141113p:plain

3. Minimum, 1minuteでNext押下

f:id:yoshidashingo:20150114142722p:plain

4. 閾値やActionを設定してCreate Alerm押下

f:id:yoshidashingo:20150114142819p:plain

設定はこれで完了

確認してみる

ユーザー操作でStatusCheckFailed_Systemのアラートは発生できない、かつAuto RecoveryはStatusCheckFailed_Systemメトリクスにしか設定できない

以下のとおり「StatusCheckFailed_System」はEC2のシステム側でのステータスチェック(EC2 システムステータスチェック)の値を取るため、ユーザー操作でeth0をdownしたりインスタンスを停止したときには「INSUFFICIENT(情報不足)」になり、アラート状態になりません。

Auto Recovery動作の確認のためにINSUFFICIENTでAuto Recovery発動させる

仕方がないのでINSUFFICIENTでAuto Recoveryアクションが発動するように条件を変更して動作を確認します。

  • インスタンスを停止してINSUFFICIENTに遷移させます

f:id:yoshidashingo:20150115114551p:plain

  • INSUFFICIENTでイベントが発動しました

f:id:yoshidashingo:20150115115029p:plain

ホストの入替えはユーザーから見ると透過的である

本機能のキモは以下のように、ホスト障害が発生したときにSTOP→STARTしてホストの入れ替えをユーザーがやっていたような動作が自動的に行われるという点です。

  • StatusCheckFailed_System(AWS側の問題発生時)にしか設定できない
  • インスタンスID、IPアドレス、インスタンスメタデータ、EBSをそのまま引き継ぐ

つまりEC2 Management Console見ても変化はわからないということです(CloudWatchのHistoryでイベントが確認できます)

よって、Auto Healingとはちょっと使いどころが違うものだなということが分かりました。
実際、Auto HealingのようにAMIから起動するわけではなくライブマイグレーションを行い、直前にEBSに書き込んでおいたファイルもそのままとなるので、コンソール上では復旧がされたこと自体気づきません。
f:id:yoshidashingo:20150115115920p:plain

なんにしても、欲しかったのってこういうヤツですよね。

それにしても、ホスト障害や電源断、XSA-108のようなアレへの対応を考慮すると、デフォルトでAuto Recoveryを設定しておくと幸せになると思います。

おすすめはデフォルトでEC2全台に仕込んでおく(多分)

cloudpackでは、NagiosやSensuで監視しているサーバーのヘルスチェックがNGになった場合に、24時間体制で問題に対応します。その際の基本的な対応フローは以下のように定義されています。

右上の(3)(4)のあたりは単一ホスト障害の可能性を考慮しての再起動やSTOP/STARTなのですが、ここがAuto Recoveryにより置き換えられます。クラウドといえども中身は物理的に存在しているのでこの対応は必要になるのは当然なのですが、Auto Recoveryを全台に仕込んでおけば、ここのフローは全く不要になるはずで、対応工数の削減が期待されます。