ブログTOP > IT・技術関連 > 【AWS】CloudWatch機能を利用したAutoRecoveryについて解説

【AWS】CloudWatch機能を利用したAutoRecoveryについて解説

IT・技術関連更新日：2024.09.05

エンジニア採用

【AWS】CloudWatch機能を利用したAutoRecoveryについて解説

AWSのCloudWatchから設定出来るAuto Recovery機能

AWSは、クラウド環境を自分たちで好きなように構築出来ます。

ただし、サーバー環境を導入しているとどうしても障害はつきもので、常にサーバーの状態を監視して、システムが安全に動作していることを確認しておく必要があります。

自身で構築したサーバー環境やシステムであれば、アラート検知機能を有効にするためにログに特定の文字列を出力するなどして、自身で障害の発生を検知することを検討出来ます。

ただし、物理ホスト上で発生する基盤障害は違います。いつ、何の原因でどのように発生するかわかりません。そして基盤障害は、原因調査及び復旧に長時間かかることが多いです。

このような課題に対し、AWSでは物理ホスト上で発生した基盤障害を自動的に検知して復旧までしてくれる機能が存在します。

AWSのAutoRecovery機能とはどのような機能なのか

AWSのAuto Recovery機能は、EC2インスタンスが存在する基盤上で障害が発生した場合に、EC2インスタンスを自動的に復旧してくれる機能です。

AWS上のEC2インスタンスのCloudWatchアラームの管理から設定出来ます。

復旧時には、インスタンスID、プライベートIPアドレス、ElasticIPアドレス、インスタンスメタデータが元のインスタンスと同じデータで復旧されます。

Auto Recoveryではどのような場合に復旧してくれるか

Auto Recoveryにおいては、AWSのEC2インスタンスが存在する基盤上でStatus Check Failed（System）を検知した際に、稼働していた‎アベイラビリティーゾーン（以下AZ）内に復旧されます。

Status Check Failed（System）を検知する要因は下記の通りです。
・ネットワーク接続の喪失
・システム電源の喪失
・物理ホストのソフトウェアの問題
・ネットワーク到達可能性に影響を及ぼす物理ホスト上のハードウェアの問題

これらの障害が基盤上で検知された場合に、Auto Recoveryは起動し、復旧処理を行います。

ただし、EC2インスタンス内で発生するStatus Check Failed（Instance）では実行されません。これはEC2インスタンスの中での問題であり、基盤障害で発生したシステムアラートとは異なるからです。

Auto Recovery機能の設定方法について解説する

Auto Recoveryの設定手順は下記の通りです。

・EC2インスタンス一覧を開きます。
・設定したいインスタンスの「アラームの状態」列の＋をクリックします。
・「アラームを作成」を選択します。（インスタンスIDが間違っていないことを確認してください。）
・アラームアクションをオンにします。
・アラームアクションのプルダウンから、「復旧」を選択します。
・Type of data to sampleのプルダウンから、「失敗したステータスチェック：システム」を選択します。
・作成ボタンをクリックします。

これでAuto Recoveryが実行されるようになります。ただし、作成したアラームを実行して試すことは出来ません。

Auto RecoveryはAWSの基盤で発生した障害を検知するための機能です。任意でAWSの基盤上で障害を発生させることは出来ません。

CloudWatchからAuto Recoveryの設定手順

Auto Recoveryを設定するにあたって下記の条件があります。

1．インスタンスタイプが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のいずれか
２．VPC内で実行される
３．defaultまたはdedicatedインスタンステナンシーを使用する
４．EBSボリュームのみ持っている

設定時にそれぞれの要件に対し、AWS上のどこを確認すればよいか解説していきます。

1．の設定確認箇所
インスタンス概要欄の「インスタンスタイプ」を参照してください。
インスタンスタイプの先頭2文字が、1に含まれていることが条件となります。

2．の設定確認箇所
インスタンス概要欄の「VPC ID」を参照してください。
VPC IDが振られていることが条件となります。

3．の設定箇所確認
ホストとプレイスメントグループ欄の「テナンシー」を参照してください。
defaultまたはdedicatedが設定されていることが条件となります。

4．の設定箇所確認
インスタンスタイプによって、EBSボリュームを持つインスタンスと持たないインスタンスが存在します。EC2インスタンス選択後、アクション項目で、「インスタンスの設定」、「インスタンスタイプを変更」の順にクリックしてください。
インスタンスタイプの変更画面では、現在のインスタンスタイプが選択されており、EBSに最適化にチェックが入っているインスタンスであることが条件となります。

Auto Recoveryの設定確認及び編集・削除方法について

Auto Recoveryが設定出来たかどうかの確認手順及び、編集・削除手順について解説していきます。

AWSのClowdWatchサービスから作成したアラームを確認することが出来ます。サービス検索でCloudWatchと入力し、検索してください。

CloudWatch機能のアラーム一覧画面に遷移し、作成したアラームをクリックします。

アラーム詳細が表示されますので、下記操作をすることで、編集及び削除することが可能となります。
・「アクション」、「編集」をクリックすると、このアラーム内容の編集が可能になります。
・「アクション」、「削除」をクリックすると、このアラーム内容が削除されます。

編集及び削除する際は、必ず、編集及び削除したいアラーム名と一致するか、インスタンスIDが対象のインスタンスであるかを確認してから実行するようにしてください。

Auto Recovery機能が機能しなかった事象について解説する

Auto Recoveryは基盤障害発生時に復旧してくれる機能ですが、その復旧先の基盤に障害が発生している場合、正しく復旧されなかったケースが過去にありました。

以下、2019年の東京リージョン障害で発生した事象について解説します。

東京リージョン障害では何が起きたか？

2019年8月に発生した冷却制御システムのバグにより、東京リージョンの内の一つのAZで障害が発生しました。

EC2サーバーが停止し、EBSボリュームのパフォーマンスも低下した状態になりました。これはネットワーク到達可能性に影響を及ぼす、物理ホスト上のハードウェア障害にあたります。

この時、Auto Recoveryの設定が行われていたEC2インスタンスで自動復旧処理が実行されましたが、復旧先のAZがまだ復旧しておらず、EC2インスタンスを作成出来ないため失敗となりました。

結局のところEC2インスタンスは自動で復旧せず、ストレージ障害復旧後に手動でEC2インスタンスを開始するよう、アカウント管理者あてに指示メールが送信されました。

AWSの基盤障害に備えたシステム設計について検討する

Auto Recoveryを利用していても、東京リージョンで発生したような問題がおきた場合、AWSのサービスとしてだけでは対処出来ないことがわかります。

東京リージョンでの障害は1つの事例とし、AWSでは過去に様々な障害が発生し、それらの障害に対し、様々な処置を実施しています。

過去事例を元に、どのような障害が発生するのか、どのような設計が適切か、運用方法はどうすれば適切かを検討しながら、高い可用性で稼働するシステム構成を考えていきましょう。

この記事の監修者・著者

株式会社オープンアップITエンジニアAWSパートナー/Salesforce認定コンサルティングパートナー認定企業

ITエンジニア派遣サービス事業を行っています。AWSやSalesforceなど専門領域に特化したITエンジニアが4,715名在籍し、常時100名以上のITエンジニアの即日派遣が可能です。

・2021年：AWS Japan Certification Award 2020 ライジングスター of the Year 受賞
・2022年3月：人材サービス型 AWSパートナー認定
・AWS認定資格保有者数1,154名（2024年6月現在）
・Salesforce認定コンサルティングパートナー
・Salesforce認定資格者276名在籍（2024年5月現在）
・LPIC＋CCNA 認定資格者：472 名（2024年6月時点）