公開日：2021年5月11日最終更新日: 2023年2月9日
AWSでシステムを運用するにあたり、システムの可用性は重要視すべき部分です。クラウドを利用すれば自動的に可用性が高まるのではなく、可用性が高まるような設計や設定が必要です。
そのような可用性を高める設定のひとつに、EC2物理ホストの障害を自動復旧するAuto Recoveryがあります。今回は障害を検知して人力で復旧するのではなく、自動的に復旧するAWSの設定について解説します。
目次 ＜Contents＞
EC2 Auto Recoveryとは
EC2のAuto RecoveryはAmazon CloudWatchのモニタリングサービスのひとつです。アラームを作成し、メトリクス条件から逸脱した場合に指定しておいた動作を実行します。まずはAuto Recoveryの概要を理解しておきましょう。
Auto Recovery（インスタンスの復旧）の概要
Auto Recoveryは正式な名称ではありません。AWSの日本語版の機能では「インスタンスの復旧」との項目で記載があります。ただ、2015年にこちらの機能が発表された際には「Auto Recovery」との名称が利用されました。そのような背景があり、一般的にはAuto Recoveryと呼ばれています。
Auto Recoveryで自動復旧できるのは、AWSのシステムに起因する障害が発生した場合です。例えば「EC2のハードウェア障害」「EC2の電源障害」などです。物理的な部分であり、クラウドサービスを利用する私達には手の施しようがない部分の復旧ができます。
なお、Auto Recoveryを設定しなければ、このようなトラブルが発生した際に手動での復旧作業が必要です。クラウドサービスだからと言って、トラブル発生時に初期設定で自動的に復旧してもらえるわけではないのです。
Auto Recoveryの使い所
Auto Recoveryはハードウェア障害の発生時に自動的にシステムの停止や起動、復旧ができる仕組みです。アプリケーション障害ではなく、インスタンス単位での自動復旧を目的としています。
現在、インスタンスの静止監視だけをCloudWatchで実装し、アラートを検知して手動で運用している企業は多いでしょう。そのような方々は設定に少し手を加えれば自動復旧を実現できます。
Auto Recoveryの設定方法
続いては実際にAuto Recoveryを設定する方法について解説します。Auto Recoveryの設定には大きく分けて以下の手順があります。
それぞれについて具体的な手順を解説します。
Auto Recoveryのアラームの作成
アラームの作成の手順
1まずはCloudWatchのアラームを作成します。最初にCloudWatchコンソールにアクセスしましょう。
2CloudWatchのコンソール画面からアラームの管理画面へと遷移し、「アラームの作成」を押します。
3続いて「メトリクスの選択」を押します。
4メトリクスを「EC2」で検索し「EC2 > インスタンス別メトリクス」を押します。
5メトリクス一覧が表示されますので、「StatusCheckFailed_System」で検索します。
6設定するインスタンスを選択し、「メトリクスの選択」を押します。
Auto Recoveryのメトリクス条件の指定
メトリクスの選択画面が表示されれば、具体的にメトリクスの条件を設定します。設定値はAWSの公式ドキュメント「インスタンスを停止、終了、再起動、または復旧するアラームを作成する」で推奨されている値を参考にします。
今回は以下のように設定してみましょう。
メトリクス条件の指定の手順
- 統計：最小
- 期間：1分
- しきい値の種類：静的
- アラーム条件の定義：より大きい
- しきい値の定義：0
- アラームを実行するデータポイント：2/2
条件の設定が完了すれば「次へ」ボタンを押します。
Auto Recoveryのアクション設定
メトリクス条件を設定したあとはアクション設定をします。
メトリクス条件を逸脱する事象が発生した場合に、どのようなアクションを取るかを設定するわけです。ここでAuto Recoveryの設定をしていきます。
アクション設定の手順
1EC2アクションにおいてまずはアクション状態トリガーを設定します。 今回はメトリクス条件を逸脱した場合のアクションを設定しますので「アラーム状態」を選択します。
そしてAuto Recoveryに該当する「このインスタンスを復旧」にチェックを入れます。
2チェックが入ればページ下部の「次へ」を押します。
3名前と説明の追加が画面が表示されますので、最低限「アラーム名」に名前を入力します。必要に応じてアラームの説明も入力しておくと管理しやすいでしょう。
その後、「次へ」ボタンを押します。
4プレビュー画面が表示されますので、内容に間違いが無いことを確認し、ページ下部の「アラームの作成」を押します。
5以下のとおり新規のアラームが作成されていれば完了です。
Auto Recoveryのアクション設定時の注意点
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でカバーできるのは物理的な障害の自動復旧のみです。アプリの障害などは別に自動復旧の仕組みを作らなければなりません。
お客様が運営するクラウドの監視・保守・運用業務を、ジードが代行いたします。
お客様のご要望に沿って、適切なクラウド選定から設計・構築までを行います。
Azure上で、AI ＋ 機械学習、分析、ブロックチェーン、IoTを開発します。