この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
1つのEC2に対して障害があった際やインスタンスに異常が発生した場合に、CloudWatchアラームを使って自動復旧する仕組みを実装する機会があったので、調査した内容をまとめておきます。
オートリカバリーとオートヒーリングの違い
自動的に復旧させる仕組みとして出てくるのは、オートリカバリーとオートヒーリングという言葉です。
この2つの違いについては以下エントリで分かりやすく解説されていますのでここでは簡単に説明します。
オートリカバリー(CloudWatchアラームによる復旧)
CloudWatchアラームから復旧アクションを実行することで、EC2インスタンスを新しいホストへ置き換える自動復旧の仕組みのことです。(復旧=オートリカバリー)
復旧アクションによって置き換えられたインスタンスはインスタンスID等同じ値になります。
復旧されたインスタンスは、インスタンス ID、プライベート IP アドレス、Elastic IP アドレス、すべてのインスタンスメタデータを含め、元のインスタンスと同じです。
これは手動で停止>起動とした場合にも同じ動作になります。設定方法については後述します。
オートヒーリング(Auto Scalingによるインスタンス数の維持)
オートヒーリングは復旧アクションとは異なり、AutoScalingグループでステータスチェックに失敗したEC2を削除して、新しいEC2を起動し直す動きをします。この時新しく起動されたEC2は当たり前ですがインスタンスID等は違う値で設定されることになります。
Auto Scalingは負荷に対してのスケールアウトのイメージが強いですが、希望する台数を維持するためのオートヒーリング機能としても利用できるということですね。
ここで設定するAuto Scalingグループは希望する容量・最小・最大をすべて同じ台数に設定する必要があります。Auto ScalingでEC2を再作成するので、利用するイメージを最新に保つことが可能であれば選択肢になります。
Auto Scaling グループで固定数のインスタンスを維持する - Amazon EC2 Auto Scaling
CloudWatchアラームから実行する復旧と再起動
CloudWatchアラームからEC2に対して実行できるアクションには、復旧の他に再起動があります。ここの復旧と先ほど説明したオートリカバリーは同じ意味です。
この2つの使い分けについては、AWSのヘルスチェックを理解する必要があります。
AWSがEC2に実施しているヘルスチェック
EC2を起動すると、AWSではEC2に対して2つのヘルスチェックを行います。コンソールからEC2 > ステータスチェック を確認してみると、以下2つのチェックが行われていることを確認できます。ステータスチェックに表示されている2/2のチェックに合格しましたはこの2つのチェック項目のことですね。
- システムステータスのチェック
- インスタンスステータスのチェック
それぞれのチェックで何をみているのかを確認していきます。
システムステータスのチェック
AWSの基盤側で問題が発生してインスタンスが落ちてしまった場合にチェックしてくれるものです。システムステータスのチェックが失敗する原因例としては以下のものがあります。
- ネットワーク接続の喪失
- システム電源の喪失
- 物理ホストのソフトウェアの問題
- ネットワーク到達可能性に影響する、物理ホスト上のハードウェアの問題
システムステータスのチェックが失敗した場合は、AWSが問題を解決するのを待つか、新しいホストで起動し直す必要があります。
インスタンスステータスのチェック
こちらは逆にAWSの基盤の問題ではなく、個々のインスタンスのソフトウェアやネットワークで問題がないかをチェックしてくれるものです。インスタンスステータスのチェックが失敗する原因例としては以下のものがあります。
- 失敗したシステムステータスチェック
- 正しくないネットワークまたは起動設定
- メモリの枯渇
- 破損したファイルシステム
- 互換性のないカーネル
インスタンスステータスチェックが失敗した場合は、再起動やインスタンスの設定変更を実施して問題に対応する必要があります。
再起動アクション追加のドキュメントを確認してみると、以下の記載がありました。
インスタンスのヘルスチェックが失敗した場合に推奨されます（システムのヘルスチェックが失敗した場合には、復旧アラームアクションが推奨されます）。
このことからも、CloudWatchアラームの 復旧 と 再起動 は以下のように使い分けるのが必要だとわかります。
- システムステータスのチェック失敗→復旧
- インスタンスステータスのチェック→再起動
どちらもチェックしている項目が違うため、自動復旧の仕組みを導入したい場合は別々にCloudWatchアラームを追加する必要がありそうです。
CloudWatchアラームの設定
実際にCloudWatchアラームを設定してみます。アクションを実行させたいEC2を選択し、 アクション > モニタリングとトラブルシューティング > CloudWatchアラームの管理 を選択します。
CloudWatchアラームは復旧用と再起動用に分けて作成します。ただし同時にアクションが実行されてしまう場合を考慮して以下を設定します。
再起動と復旧アクション間で不具合が発生するのを回避するには、再起動アラームと復旧アラームを同じ検査期間に設定するのを避けます。復旧アラームを各 1 分間の 2 つの評価期間に設定し、再起動アラームを各 1 分間の 3 つの評価期間に設定することをお勧めします。
復旧アクションを追加
復旧では1分間に２回の評価として、以下のパラメータで作成します。
- アラームアクション：
復旧 - Group samples by：
最小 - Type of data to sample：
ステータスチェックの失敗：システム - 連続した期間：
2 - 期間：
1分
復旧アクションを指定する場合、インスタンスタイプなどに制限があるため以下のドキュメントで確認して下さい。
Amazon CloudWatch アラームへの復旧アクションの追加
再起動アクションの追加
再起動アクションの場合は1分間に3回の評価として、以下のパラメータで作成します。
- アラームアクション：
復旧 - Group samples by：
最小 - Type of data to sample：
ステータスチェックの失敗：システム - 連続した期間：
3 - 期間：
1分
復旧と再起動のアラームをそれぞれ作成することで、システムステータスとインスタンスステータスを監視し、自動復旧するCloudWatchアラームを実装することができました。
システムステータスのチェックはAWS基盤の障害が起きないと確認できないのですが、以下エントリでそれを検証してくれていますので是非ご参照ください。
まとめ
EC2の自動修復についてまとめてみました。Auto Scalingで利用できるイメージを用意できる場合はオートヒーリング。Auto Scalingを利用しない場合はCloudWatchアラームを使用した復旧/再起動を実装するのが良いのかなーと考えています。どのような障害を想定するのか、利用環境や監視体制を踏まえて、どれを採用するのか検討してみて下さい。
ご参考
AWSドキュメント
- インスタンスのステータスチェック - Amazon Elastic Compute Cloud
- EC2 インスタンスを停止、終了、再起動、または復旧するアラームを作成する - Amazon CloudWatch
15
