ある CloudOps エンジニアは、基幹業務アプリケーションを実行する Amazon EC2 インスタンスの自動復旧を構成しています。インスタンスステータスチェックの失敗でインスタンスを再起動するアラームと、システムステータスチェックの失敗でインスタンスを復旧するアラームを作成し、どちらも評価期間の数を 3 にしました。物理ホストの障害が発生したとき、インスタンスは復旧される前に再起動され、サービスのダウンタイムが長くなりました。 サービスのダウンタイムを短くするために、CloudOps エンジニアは何をすべきですか。
再起動と復旧のアラームが競合して復旧が遅れる状態を直す
インスタンスを復旧するアラームの評価期間の数を 2 に変更する。インスタンスを再起動するアラームは 3 のままにする。
公式は、再起動のアラームと復旧のアラームに同じ評価期間の数を設定すると競合が起きるとして、再起動は 1 分を 3 回、復旧は 1 分を 2 回にすることを推奨しています。
物理ホストの障害では 2 つのステータスチェックが同時に失敗しうるため、復旧側を 2 回にすると先に条件を満たした復旧アクションが起動し、インスタンスは正常なハードウェアへ移されます。復旧後もインスタンス ID・プライベート IP アドレス・Elastic IP アドレス・アタッチ済みの Amazon EBS ボリュームは保持されます。
インスタンスを復旧するアラームの期間を 1 分から 30 秒に変更する。インスタンスを再起動するアラームは 1 分のままにする。
復旧の側が先に条件を満たすようにするという方向は正しく、期間を縮めれば判定までの時間は短くなります。
しかし 30 秒のような 1 分未満の期間が意味を持つのは、StorageResolution を 1 にして発行した高解像度メトリクスだけです。ステータスチェックのメトリクスは 1 分ごとに記録されるため、データの来ない期間が生まれ、公式が警告するとおりアラームは INSUFFICIENT_DATA に落ちやすくなります。復旧が起動しない時間が生まれます。
インスタンスを再起動するアラームのメトリクスを、システムステータスチェックに変更する。
再起動アクションは EC2 のインスタンス単位のメトリクスであれば設定でき、この変更自体は受け付けられます。しかし再起動は OS 側の問題に対する対処で、システムステータスチェックが示すのは AWS 側の基盤の問題です。変更すると OS 側の問題を検知するアラームがなくなります。
評価期間の数は 3 のままにする。
2 つのアラームは同じ 3 回のままなので、競合も残ります。
インスタンスを再起動するアラームのメトリクスを、システムステータスチェックに変更する。
システムステータスチェックの失敗で再起動が動く構成自体は受け付けられます。しかし再起動は OS の再起動と同じで、インスタンスは問題のある物理ホストの上で動き続けます。再起動しても基盤の問題は解消せず、OS 側の問題を検知するアラームもなくなります。
インスタンスを復旧するアラームは削除する。
復旧のアラームを消せば、2 つのアクションが競合することはなくなります。ただしシステムステータスチェックが示す AWS 側の基盤の問題に対処するのは、インスタンスを別のホストへ移す復旧 (recover) です。
EC2 のステータスチェックとアラームアクションの組み合わせは定番の出題です。
・システムステータスチェック (StatusCheckFailed_System) は AWS 側の基盤の問題を示し、対処は復旧 (recover) です。インスタンスステータスチェック (StatusCheckFailed_Instance) は OS 側の問題を示し、対処は再起動 (reboot) です。復旧アクションは StatusCheckFailed_Instance には設定できず、公式は復旧をシステムステータスチェックと組み合わせるものとして案内しています。
・両方を併用するときは、評価期間の数を同じにしないよう公式が推奨しています。同じ数だと競合し、推奨値は再起動が 1 分を 3 回・復旧が 1 分を 2 回です。
・復旧後もインスタンス ID・プライベート IP アドレス・Elastic IP アドレス・アタッチ済みの EBS ボリュームは保持され、メモリ上のデータは失われます。