share facebook facebook2 twitter menu hatena pocket slack

2015.01.19 MON

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

吉田 真吾

WRITTEN BY吉田 真吾

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

ドキュメント

以下を参照しながら作業します
Recover Your Instance – Amazon Elastic Compute Cloud

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

Amazon EC2 Auto Recovery: 設定手順(1)

2. StatusCheckFailed_Systemを選択

Amazon EC2 Auto Recovery: 設定手順(2)

3. Minimum, 1minuteでNext押下

Amazon EC2 Auto Recovery: 設定手順(3)

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

Amazon EC2 Auto Recovery: 設定手順(4)
設定はこれで完了

確認してみる

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

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

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

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

  • インスタンスを停止してINSUFFICIENTに遷移させます
    Amazon EC2 Auto Recovery: Auto Recovery動作の確認(1)
  • INSUFFICIENTでイベントが発動しました
    Amazon EC2 Auto Recovery: Auto Recovery動作の確認(2)

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

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

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

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

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

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


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

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

EC2の障害復旧フロー – cloudpack(クラウドパック)

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

元記事はこちらです。
EC2 Auto RecoveryはどのくらいAuto Recoveryなのか

吉田 真吾

吉田 真吾