稼働中のEBS-backed EC2インスタンスがCloudWatchのrecoverに対応する条件を満たすことを確認済みである。StatusCheckFailed_Systemが継続して1となる基盤側障害に対して、通知とインスタンスの復旧を行いたい。
アラームは対象InstanceIdの1分Minimumが0を超える条件、EvaluationPeriods=2、DatapointsToAlarm=2で作成済みである。SNSトピックと確認済みの通知購読も準備してある。 TreatMissingData=missingで、アクションに必要な権限も準備済みである。
このアラームへ設定する適切なアクションを2つ選べ。
対応条件を確認したインスタンスのStatusCheckFailed_Systemアラームに、SNS通知とEC2 recoverを接続する。
詳細解説
欠損データはSystemチェック失敗の証拠ではない。EC2アクションはALARMを実行条件にし、観測不能を根拠にrecoverを起動しない。
rebootは同じホストでの再起動であり、基盤障害に対するrecoverの移行と同じ処理ではない。
対応条件を満たすインスタンスのシステムチェック失敗に対し、別ハードウェアへの復旧を試みられる。
CloudWatchのrecoverはStatusCheckFailed_Systemだけに対応し、ゲスト側のインスタンスチェックを対象にする設計ではない。
監視条件を満たしたとき、確認済みの購読を通して運用者へ状態を通知できる。
公式資料で確認する
以下の項目を公式資料の記述と照合して確認します。
公式資料でrecoverの対応条件、対象チェック、1分Minimumの2/2評価、復旧後に維持される情報を確認する。
参考にした公式資料
確認できる内容
SystemチェックのrecoverとInstanceチェック向けのrebootを区別し、通知と復旧を別アクションとして説明できる。
理解のポイント
- SNS通知
- EC2 recover action
- StatusCheckFailed_System
確認時の注意
- 確認環境: AWS公式SOA-C03試験ガイドとAWS公式ドキュメントの確認
- AWS公式SOA-C03試験ガイドと各サービスの公式ドキュメントを確認する。
基礎のおさらい
障害の種類とアクションを合わせる
StatusCheckFailed_Systemは基盤側、StatusCheckFailed_Instanceはゲスト側の問題を調べる信号である。今回のrecoverはSystemチェックの失敗を対象にし、対応条件・稼働状態・権限を確認してSNSとrecoverを別々に設定する。EC2アクションはALARMを実行条件とし、欠損データは推奨のTreatMissingData=missingで扱う。INSUFFICIENT_DATAは観測不足であり、基盤障害や正常状態の証拠ではない。
復旧とアプリ復旧を確認する
CloudWatchアクションによるrecoverは別ハードウェアへの復旧を試み、途中でインスタンスが再起動する。インスタンスID・IPアドレス・EBSは維持されるが、RAMとinstance store上のデータは失われる。同じホストでのrebootとは異なり、recoverも成功やアプリの正常を保証しない。アラーム／アクション履歴、EC2の状態チェック、サービスの疎通で結果を確認する。