AzureのVM起動/終了時にフックかましたくなったので、Azure Metadata ServiceのScheduled Eventsについて調査した。 今回はLinux（CanonicalのUbuntu 16.04 LTS）のみ、かつ確認が面倒なためRebootのみが対象。
前提
- Azureの東日本リージョンで、シングル構成のVMを用意
- Availability Setは未構成
- Scheduled Eventsを有効化済
調査結果
VMが通常稼動しているとき
curl -sS -H Metadata:true http://169.254.169.254/metadata/scheduledevents?api-version=2017-08-01 を実行すると、 即座に 以下のレスポンスが返却される。
{"DocumentIncarnation":0,"Events":[]}
VMのRebootを実施したとき
Azureポータル上からVMのRestartを実施してみた。 検証した中では、Scheduled Eventsへの反映に数秒から十数秒程度かかっていた。
curl -sS -H Metadata:true http://169.254.169.254/metadata/scheduledevents?api-version=2017-08-01 を実行すると、 即座に 以下のレスポンスが返却される。
{"DocumentIncarnation":1,"Events":[{"EventId":"F1B53BF4-85CE-4632-9D74-A9E2F38F5D53","EventStatus":"Scheduled","EventType":"Reboot","ResourceType":"VirtualMachine","Resources":["{virtualMachineName}"],"NotBefore":"Wed, 10 Oct 2018 03:49:39 GMT"}]}
NotBeforeには、Azureポータル上からRestartを実施した時刻から15分後の時刻が格納されていた。 この猶予時間は、EventTypeの種類ごとに定義されていて、FreezeとRebootなら15分、Redeployなら10分となる。 後述のApproveをせずにNotBeforeの時刻に到達すると、VMが実際に再起動される。
何度かScheduled Eventsから取得してみたが、何度でも同じレスポンスが取得できるよう。 そして、該当イベントをApproveするまでは、（上限の時間内で）VMは終了しなかった。
次のリクエストを投げて、該当イベントをApproveすると、その後数秒から十数秒ほどで実際にVMが再起動された。
curl -sS -H Metadata:true http://169.254.169.254/metadata/scheduledevents?api-version=2017-08-01 -d '{"StartRequests":[{"EventId":"F1B53BF4-85CE-4632-9D74-A9E2F38F5D53"}]}'
このとき、レスポンスは空（Content-Length: 0）が返ってきた。
再起動後に再度Scheduled Eventsを取得したところ、以下のようになった。
{"DocumentIncarnation":3,"Events":[]}
まとめ
Scheduled Events、かなり便利だった。 難があるとすれば、ポーリングしなければならない点だけれど、これはAzureのAPIが全体的にポーリングするデザインになっているため、まぁしゃーない。 しかしイベントが取得可能になってから、10分とか15分程度の猶予ができるため、ポーリングでもそこまで問題になることはないかな、という印象。 若干面倒な点は、同じイベントがずっと取れてくるところで、取得する側が既に処理済のイベントかどうか、を判断する必要がありそう。 適用可能なケースだと、かなり有用な機能だと思う。
VMでの挙動で、Scheduled Eventsの動きはおおよそ想像がついたため、今度はVMSSでの挙動を調査したい。
