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を選択する
2. StatusCheckFailed_Systemを選択
3. Minimum, 1minuteでNext押下
4. 閾値やActionを設定してCreate Alerm押下
設定はこれで完了
確認してみる
ユーザー操作でStatusCheckFailed_Systemのアラートは発生できない、かつAuto RecoveryはStatusCheckFailed_Systemメトリクスにしか設定できない
以下のとおり「StatusCheckFailed_System」はEC2のシステム側でのステータスチェック（EC2 システムステータスチェック）の値を取るため、ユーザー操作でeth0をdownしたりインスタンスを停止したときには「INSUFFICIENT（情報不足）」になり、アラート状態になりません。
Auto Recovery動作の確認のためにINSUFFICIENTでAuto Recovery発動させる
仕方がないのでINSUFFICIENTでAuto Recoveryアクションが発動するように条件を変更して動作を確認します。
- インスタンスを停止してINSUFFICIENTに遷移させます
- INSUFFICIENTでイベントが発動しました
ホストの入替えはユーザーから見ると透過的である
本機能のキモは以下のように、ホスト障害が発生したときにSTOP→STARTしてホストの入れ替えをユーザーがやっていたような動作が自動的に行われるという点です。
- StatusCheckFailed_System（AWS側の問題発生時）にしか設定できない
- インスタンスID、IPアドレス、インスタンスメタデータ、EBSをそのまま引き継ぐ
つまりEC2 Management Console見ても変化はわからないということです（CloudWatchのHistoryでイベントが確認できます）
よって、Auto Healingとはちょっと使いどころが違うものだなということが分かりました。
実際、Auto HealingのようにAMIから起動するわけではなくライブマイグレーションを行い、直前にEBSに書き込んでおいたファイルもそのままとなるので、コンソール上では復旧がされたこと自体気づきません。
なんにしても、欲しかったのってこういうヤツですよね。
それにしても、ホスト障害や電源断、XSA-108のようなアレへの対応を考慮すると、デフォルトでAuto Recoveryを設定しておくと幸せになると思います。
おすすめはデフォルトでEC2全台に仕込んでおく（多分）
cloudpackでは、NagiosやSensuで監視しているサーバーのヘルスチェックがNGになった場合に、24時間体制で問題に対応します。その際の基本的な対応フローは以下のように定義されています。
右上の(3)(4)のあたりは単一ホスト障害の可能性を考慮しての再起動やSTOP/STARTなのですが、ここがAuto Recoveryにより置き換えられます。クラウドといえども中身は物理的に存在しているのでこの対応は必要になるのは当然なのですが、Auto Recoveryを全台に仕込んでおけば、ここのフローは全く不要になるはずで、対応工数の削減が期待されます。
