[OpsJAWS] EC2イベントの監視

EC2イベント監視の目的

EC2インスタンスまたはインスタンスが稼働する物理ホストに対して計画的メンテナンス作業を行うことがある。予定されたメンテナンスイベントは、ユーザーで任意の時間帯に先行して実施することができるため、ユーザーは予定されているイベントが無いか定期的に監視を行い、イベントを検知したらシステムの停止可能な時間帯にメンテナンスを先行して行う運用が望ましい。メンテナンス作業により、稼働中のEC2インスタンスに影響がある場合は、イベントという形でAWSアカウントのメールアドレス宛に通知される。 

(メール例)

 

• EC2イベントの監視

EC2のメンテナンスイベントは、メールによる通知以外にもManagement Console、AWS CLI/APIによる確認が可能である。メールによる通知だけに頼ると見逃してしまうリスクがあるため、定期的にCLI/APIを実行してメンテナンスイベント有無を監視することが望ましい。

メンテナンスイベント監視に使用するCLI/APIはそれぞれ下記となる。

• API：DescribeInstanceStatus
• CLI ：describe-instance-status

出力として、イベントの種類、イベントの説明、イベント予定時間帯が得られる。

例えば、CLIで下記のように実行すると、System Rebootが計画されているEC2インスタンス情報が取得できる。なお、イベントが計画されていない場合は何も出力されない。 

（コマンド例）

event.codeには、イベントの種類に応じて、それぞれ下記の値が入る。

• instance-reboot
• system-reboot
• system-maintenance
• instance-retirement
• instance-stop

イベントの種類についての詳細はこちらを参照。

• EC2イベント検知後の対応

イベントを検知した場合の対応方法としては、下記の3通りが考えられる。

1．何もしない

Muti-AZ構成のシステムの場合、片方のAZのEC2インスタンスにメンテナンスが入ったとしても、システムとしては停止しないため、特段の対応が不要となる。その他、メンテナンス対象が、開発用インスタンスや、スケジュールされた時間帯のどこでメンテナンスされても困らない場合は、そのまま運用を続けることも選択肢の1つとなる。

2．利用者でEC2インスタンスのStop/Startを実施

EC2インスタンスのroot deviceタイプがEBSの場合、利用者の任意のタイミングで事前にStop/Startすることが望ましい。Stop/StartによりEC2インスタンスが稼働する物理ホストが、メンテナンス対象のものから、メンテナンス対象外のものに変わることにより、イベントをクリアすることが可能なためである。

3．最新のAMIにより代替インスタンスをLaunch

EC2インスタンスのroot deviceタイプがインスタンスストアボリュームの場合、Stop/Startすることはできないので、事前に代替インスタンスをLaunchしておき、それに現行のEC2インスタンスから必要データを取得して移行しておくことが望ましい。これによりAWS側によりEC2インスタンスがStopされても代替インスタンスの方でシステムが稼働可能となる。

実際にシステムが本番運用に入ると、システムのアーキテクチャによっては停止できる時間帯は限られてくるため、上記のようにイベントの監視を導入した上で、インスタンス別にイベント検知後の対応方法まで合わせて初期段階で設計しておくことが望ましい。

その他運用カテゴリはこちらを参照。