待望の機能！AWS Systems Manager Change Calendar でより柔軟な定期処理実行が可能に！！

園部治

2019.12.24

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

園部です。

re:Invent 2019 明けに登場した AWS Systems Manager Change Calendar を取り上げていきたいと思います！待ち望んでいた方も多いのではないでしょうか？

Using AWS Systems Manager Change Calendar to prevent changes during critical events

本題に入る前に、少し前置きを書きたいと思います。（興味のない方はスキップして、次へ進んでください）

今日の巨大化・複雑化したシステムにおいて、定期処理（タスク）の管理は重要な課題の一つです。処理の内容はもちろんのこと、実行環境、処理（タスク）管理、スケジューリングも重要な要素となっています。

実行環境

シェルやスクリプトで作成された処理を実行する環境として EC2 を利用している場合、その実行環境となる EC2 の管理が必要です。冗長性やバックアップ、処理コードの管理（ EC2 上にしかなくてインスタンス削除で紛失なんてことも... ） などの検討が必要となるでしょう。

最近では簡単な処理であれば lambda で実行するのが多くなってきているかと思います。これは、前述の実行環境の管理を AWS にオフロードすることが一つのメリットとなっているためです。 lambda 同様に AWS Systems Manager Automation や RunCommand を利用することでも同様のメリットを得ることが出来ます。

処理（タスク）管理

処理があちこちで実行され結果を確認するために、ログを検索したりメールを追いかけるような運用はなかなか負荷が高いものです。ましてや、野良処理のような管理が出来ていない処理が存在するとトラブルの温床となります。

AWS Systems Manager Maintenance Window に処理の実行を統一することで、処理の一覧性・ステータス（有効/無効）や過去履歴を集中的に管理することが出来ます。

スケジューリング

定期処理なので、実行日時 / 繰り返し実行 / 開始・終了日 / 除外日 / 許可日のように実行するタイミングを柔軟に指定できることが求められることがしばしばあります。特に日本の祝日やビジネスイベント、システムリリースなど、定形外の設定を要求されるケースがあります。

Maintenance Window でも実行日時や繰り返し、開始・終了日を指定することが出来ますが、定形外まで設定するのは困難でした。今回、リリースされた AWS Systems Manager Change Calendar は定形外の部分をサポートするような機能です。

Change Calendar とは？

概要

処理の実行に対して、許可または拒否する期間（イベント）を指定することが出来ます。普段利用するグループウェアなどのカレンダーに予定を追加するイメージで、処理を任意のタイミングで登録・管理する機能ではない点に注意が必要です。

リソースに対して、変更（ Change ）を実行することを許可・拒否することを定義する機能のようです。

仕組み

Change Calendar は以下の2種類のカレンダーをベースに期間を登録していきます。実行される処理は関連付けされたカレンダーから処理の実行可否をチェックした上で、処理を実行します。

  • Open by default: オープン（許可）された状態が標準となり、拒否する期間を明示的に指定します。

※ 引用: Using AWS Systems Manager Change Calendar to prevent changes during critical events

  • Closed by default: クローズ（拒否）された状態が標準となり、許可する期間を明示的に指定します。

※ 引用: Using AWS Systems Manager Change Calendar to prevent changes during critical events

やってみる

検証パターン

  • シナリオ： 毎時実行されている AMI 作成を特定の時間帯のみ停止
  • 処理： AWS-CreateImage ドキュメントをベースに Change Calendar を参照する設定を追加
  • 実行環境: Automation
  • スケジューリング： Maintenance Windows

Change Calendar 作成

AWS Systems Manager >>> カレンダーの変更 >>> create calendar を選択します

任意のカレンダー名と説明を入力します

今回は、「Open by default」 を選択し、 Create calendar を選択します

（処理拒否期間）イベント作成

作成したカレンダーを選択します

Create event を選択します

任意のスケジュールイベント名と説明を入力します

イベント期間とタイムゾーンを指定 >>> Create scheduled event を選択します

カレンダーに登録されました

ドキュメント作成

AWS Systems Manager >>> ドキュメント >>> オートメーションを作成 を選択します

参考とする AWS-CreateImage ドキュメント をベースに作成します。

※ 詳細な手順は割愛しています。

試しに手動で実行してみます。

成功しました。

Maintenace Window 作成

定期的に実行することを想定して、 Maintenace Window で実行します。

AWS Systems Manager >>> メンテナンスウィンドウ >>> メンテナンスウィンドウを作成 を選択します

続いて、タスクを登録します。

先ほど作成した ドキュメントを オートメーションタスクとして登録していきます。

次回実行で、正常に処理が実行されました。

Change Calendar と関連付け

作成したドキュメントに Change Calendar を参照し、処理の実行可否をチェックする内容を追加していきます。

ドキュメントから アクション >>> 新しいバージョンを作成 を選択します

「コンテンツ」 タブから YAML で処理を追加することも可能ですが、わかりやすくするために Document Builder で追加していきます。

ステップを追加 を選択します

新しく ChangeCalendar を参照するステップを追加します

実行可否をコントロールした定期処理実行

検証時間の短縮（毎時を想定していたので...結果が得られるのが1時間後だと少しつらいので、、）

実行可での処理実行

ルーチンで実施されている定期バックアップが実行可能な時間帯で処理を実行します。

以下のコマンドで、現在のカレンダー状況を確認します。

  • 現在はOPEN（実行可）です
  • ステータスが変更されるのは先に追加したイベント開始時刻である 12月24日 22:45 です
$ aws ssm get-calendar-state --calendar-names arn:aws:ssm:ap-northeast-1:************:document/hourly-backup
{
"State": "OPEN",
"AtTime": "2019-12-24T13:31:41Z",
"NextTransitionTime": "2019-12-24T13:45:00Z"
}

メンテナンスウィンドウ の実行時間を変更します（ 毎時0分 >>> 毎時35分 ）

22:35 の実行が成功します

Automation の詳細を確認すると、先ほど追加した Change Calendar を確認する（ CheckCalendarState ） が追加され、成功していることが確認できます。

実行不可での処理実行

定期バックアップを一時的に停止します。イベントは既に登録しているので、Change Calendar のステータスが変更となることを待ちます。

以下のコマンドで、現在のカレンダー状況を確認します。

  • 現在はCLOSED（実行不可）です
  • ステータスが変更されるのは先に追加したイベント終了時刻である 12月24日 23:00 です
$ aws ssm get-calendar-state --calendar-names arn:aws:ssm:ap-northeast-1:************:document/hourly-backup
{
"State": "CLOSED",
"AtTime": "2019-12-24T13:45:52Z",
"NextTransitionTime": "2019-12-24T14:00:00Z"
}

メンテナンスウィンドウ の実行時間を変更します（ 毎時35分 >>> 毎時50分 ）

22:50 の実行が失敗します

Automation の詳細を確認すると、先ほど追加した Change Calendar を確認する（ CheckCalendarState ） が失敗となり、後続の処理が保留となっていることが確認できます。

無事、イベントで定義した時間帯は定期実行を停止することができました。

おまけに カレンダーに登録したイベント期間終了後のステータスを確認します。

$ aws ssm get-calendar-state --calendar-names arn:aws:ssm:ap-northeast-1:************:document/hourly-backup
{
"State": "OPEN",
"AtTime": "2019-12-24T14:00:52Z"
}

さいごに

だいぶ前準備に内容を割いてしまいましたが、実際のイメージをつけるために一から検証を行いました。必要な部分をピックアップして読んでいただけると幸いです。

Change Calendar 含め Systems Manager のサービスが増えてきたことでサービス間の連携が強化され、部分的な活用だけではなく総合的な運用実行環境として利用が可能となってきています。運用環境に課題を抱えている方や部分的にしか使っていなかったという方は改めて Systems Manager での実現性をご確認いただくと、もしかしたら冒頭で述べたような本質的な部分ではない課題から解放されることもあるかもしれません！

AWS