EC2物理ホストの障害を自動復旧するためのAuto Recovery

AWSでシステムを運用するにあたり、システムの可用性は重要視すべき部分です。クラウドを利用すれば自動的に可用性が高まるのではなく、可用性が高まるような設計や設定が必要です。

そのような可用性を高める設定のひとつに、EC2物理ホストの障害を自動復旧するAuto Recoveryがあります。今回は障害を検知して人力で復旧するのではなく、自動的に復旧するAWSの設定について解説します。

Auto Recoveryとは

EC2のAuto RecoveryはAmazon CloudWatchのモニタリングサービスのひとつです。アラームを作成し、メトリクス条件から逸脱した場合に指定しておいた動作を実行します。まずはAuto Recoveryの概要を理解しておきましょう。

概要

Auto Recoveryは正式な名称ではありません。AWSの日本語版の機能では「インスタンスの復旧」との項目で記載があります。ただ、2015年にこちらの機能が発表された際には「Auto Recovery」との名称が利用されました。そのような背景があり、一般的にはAuto Recoveryと呼ばれています。

Auto Recoveryで自動復旧できるのは、AWSのシステムに起因する障害が発生した場合です。例えば「EC2のハードウェア障害」「EC2の電源障害」などです。物理的な部分であり、クラウドサービスを利用する私達には手の施しようがない部分の復旧ができます。

なお、Auto Recoveryを設定しなければ、このようなトラブルが発生した際に手動での復旧作業が必要です。クラウドサービスだからと言って、トラブル発生時に初期設定で自動的に復旧してもらえるわけではないのです。

使い所

Auto Recoveryはハードウェア障害の発生時に自動的にシステムの停止や起動、復旧ができる仕組みです。アプリケーション障害ではなく、インスタンス単位での自動復旧を目的としています。

現在、インスタンスの静止監視だけをCloudWatchで実装し、アラートを検知して手動で運用している企業は多いでしょう。そのような方々は設定に少し手を加えれば自動復旧を実現できます。

Auto Recoveryの設定方法

続いては実際にAuto Recoveryを設定する方法について解説します。Auto Recoveryの設定には大きく分けて以下の手順があります。

それぞれについて具体的な手順を解説します。

アラームの作成

1まずはCloudWatchのアラームを作成します。最初にCloudWatchコンソールにアクセスしましょう。

2CloudWatchのコンソール画面からアラームの管理画面へと遷移し、「アラームの作成」を押します。

3続いて「メトリクスの選択」を押します。

4メトリクスを「EC2」で検索し「EC2 > インスタンス別メトリクス」を押します。

5メトリクス一覧が表示されますので、「StatusCheckFailed_System」で検索します。

6設定するインスタンスを選択し、「メトリクスの選択」を押します。

メトリクス条件の指定

メトリクスの選択画面が表示されれば、具体的にメトリクスの条件を設定します。設定値はAWSの公式ドキュメント「インスタンスを停止、終了、再起動、または復旧するアラームを作成する」で推奨されている値を参考にします。
今回は以下のように設定してみましょう。

  • 統計:最小
  • 期間:1分

  • しきい値の種類:静的
  • アラーム条件の定義:より大きい
  • しきい値の定義:0
  • アラームを実行するデータポイント:2/2

条件の設定が完了すれば「次へ」ボタンを押します。

アクション設定

メトリクス条件を設定したあとはアクション設定をします。メトリクス条件を逸脱する事象が発生した場合に、どのようなアクションを取るかを設定するわけです。ここでAuto Recoveryの設定をしていきます。

1EC2アクションにおいてまずはアクション状態トリガーを設定します。
今回はメトリクス条件を逸脱した場合のアクションを設定しますので「アラーム状態」を選択します。
そしてAuto Recoveryに該当する「このインスタンスを復旧」にチェックを入れます。

2チェックが入ればページ下部の「次へ」を押します。

3名前と説明の追加が画面が表示されますので、最低限「アラーム名」に名前を入力します。必要に応じてアラームの説明も入力しておくと管理しやすいでしょう。

その後、「次へ」ボタンを押します。

4プレビュー画面が表示されますので、内容に間違いが無いことを確認し、ページ下部の「アラームの作成」を押します。

5以下のとおり新規のアラームが作成されていれば完了です。

設定時の注意点

Auto Recoveryは対応しているインスタンスタイプが指定されています。公式ドキュメントでは「インスタンスタイプであるA1、C3、C4、C5、C5a、C5n、C6g、Inf1、 M3、M4、M5、M5a、M5n、M5zn、M6g、 P3、R3、R4、R5、R5a、R5b、R5n、R6g、 T2、T3、T3a、X1、X1eのいずれかを使用する」と記載があります。

また、ボリュームはEBSボリュームのみを持っていて、インスタンスストアボリュームは設定しないとの条件があります。この条件を満たしていない場合、以下のような表示となりAuto Recoveryが設定できませんので注意しましょう。

<注意点>

このように「インスタンスの復旧」が選択できない場合は、注意点のどちらかが影響している可能性があります。インスタンスタイプとボリュームの設定を確認してみましょう。条件を満たせない場合は自動化が難しくなります。

Auto RecoveryとAuto Healingの違い

Auto Recoveryと間違えられやすいサービスにAuto Healingがあります。これらの違いを簡単にまとめておきます。

Auto Recovery Auto Healing
実装サービス CloudWatch Auto Scaling
実行タイミング メトリクスの条件を逸脱 Auto Scalingのヘルスチェックに失敗
動作内容 異なる物理ホストでインスタンスを再起動 停止インスタンスの置き換え

Auto HealingはAuto Scalingの機能です。Auto Scalingで起動するインスタンス数を自動的に設定した数で動作させてくれます。例えば4台で設定したにも関わらず「3台起動、1台エラー」との状態になっていれば、エラーの1台を自動的に復旧してくれます。

Auto Recoveryは今回ご説明したとおり、1台のインスタンスを監視して自動復旧する仕組みです。Auto Scalingのように複数台を1つの設定で監視するものではありませんので、誤った認識を持たないようにしておきましょう。

まとめ

Auto ScalingはEC2インスタンスを起動する物理ホストに障害が起こった場合に、自動的にインスタンスを復旧してくれる仕組みです。生死監視をするだけではなく、異なった物理ホストにインスタンスをマイグレーションしてくれるのです。

なお、Auto Scalingでカバーできるのは物理的な障害の自動復旧のみです。アプリの障害などは別に自動復旧の仕組みを作らなければなりません。

クラウドの運用代行や導入、開発は20年の実績をもつジードにご相談ください

お問い合わせ・お見積もりのご依頼はお気軽に

  • 24時間受付けております メールでお問い合わせ
  • 受付:月〜金曜/9:00~18:00(土日祝除く) 電話:028-610-7555
Scroll to top