シナリオ
開発環境のアラームは日中は鳴ってても誰か対応するし、夜間に何かあっても翌日対応すればいいから夜間はアラーム止めておきたい。みたいな時に、業務が終わる時間に開発環境用のアラームを無効にして、出勤したら有効化するスケジュールを組むことを想定してみました。
前置き
EventBridge Scheduler用のIAMロール
公式ドキュメントに沿って作っておく
CWアラーム
こんな感じで開発環境用のアラームっぽいのが2つあるとします。
CloudTrail Lake
ログ確認のため有効化しておく。CloudTrailのログが見れれば別な方法でも構わない。EventBridge Scheduler側にはログ確認手段がなさそう。
用語
- Schedule： スケジュールされる実行単位。ジョブとかタスクのような意味合い。
- スケジュールグループ：作成するScheduleをただまとめる論理的なグループ。環境とかクラスタとか任意の単位でグルーピング。デフォルトではDefaultがある。今回は事前に"test-group"という名前で作成したのでそれを選択。
- ターゲット
- テンプレート化されたターゲット(今回は使わない)(以前からある)：SQS、Lambda、Step Functionsなどのコア AWS サービスのグループ全体で共通の API 操作のセットです。たとえば、関数 ARN を提供することで Lambda の Invoke API オペレーションをターゲットにするか、ターゲットのキュー ARN を使用して Amazon SQS の SendMessage オペレーションをターゲットにすることができます
- ユニバーサル ターゲット(今回使う)(New)：多くの AWS サービスに対してより幅広い API 操作を呼び出すことができる、カスタマイズ可能な一連のパラメータです。たとえば、EventBridge スケジューラのユニバーサル ターゲット パラメータ (UTP) を使用して、CreateQueue オペレーションを使用して新しいSQS キューを作成できます。ユニバーサルターゲットのドキュメント
Let's try EventBridge Scheduler
Scheduleの作成
1つ目のSchedule"alarm-disable-test"を作成
EventBridgeの左メニューから"スケジュール"をクリックして、右下辺りの[スケジュールを作成]をクリック
次に以下を入力し、入力したら[次へ]をクリック
スケジュール名：Alarm-disable-test
スケジュールグループ:test-group
フレックスタイムウインドウ：15分
テストなので毎時10分で設定しました。
ターゲットの選択
"すべてのAPI"にチェックを入れて、検索窓に"Cloudwath"と入れて、下に出てきた「CloudWatch」をクリック
"DisableAlarmActions"にチェック
下部に以下の値を入れて、[次へ]をクリック
※2つのアラーム名をdev-*でやってみたけどダメでしたので、ベタ書きしました
{
"AlarmNames": [
"dev-rds-alarm","dev-ec2-alarm"
]
}
作成したスケジュールを確認
同じ手順で2つ目のSchedule"alarm-enable-test"を作成
スケジュール名をalarm-enable-test
毎事30分で設定しました。
実行確認
CWアラームの確認
10分過ぎに2つのアラーム共にDisableになりました。
30分過ぎに2つのアラーム共にEnableになりました。
EventBridge Schedulerの実行結果をCloudTrail確認
"eventSource"や"EventName"にEventBridge Schedulerと分かる文字列が入ってこないので、"userAgent"に入ってくる「AmazonEventBridgeScheduler, aws-sdk-java/2.18.9 Linux/4.14.294-2・・・」の文字列で引っ掛けました。
CloudTrailのログからもスケジュールが実行されAPIコールされたことが確認出来ます。
alarm-disable-testは、毎時10分で、14分に実行
alarm-enable-testは、毎時30分で、37分に実行
フレックスウインドウで15分を設定したので、15分以内に実行されました。
SELECT eventID,eventTime, eventType,eventSource,EventName,userAgent,requestParameters FROM xxxxxxxxxxxxxxxxxxxxx WHERE eventTime > '2022-11-17 02:00:00' AND eventTime < '2022-11-17 08:00:00' AND userAgent like 'AmazonEventBridgeScheduler%' order by eventTime desc;
その他
- Schedule自体の有効無効も出来ます。
- レートベースのスケジュールって面白いですね。
- レートベースのスケジュールは、スケジュールに指定した開始日以降に開始され、スケジュールの終了日まで定義した通常のレートで実行されます。 レートベースのスケジュールを使用して、最も一般的な繰り返しスケジュールのユース ケースを設定できます。 たとえば、ターゲットを 15 分ごと、2 時間ごと、または 5 日に 1 回呼び出すスケジュールが必要な場合は、レートベースのスケジュールを使用してこれを実現できます。 レート式を使用して、レートベースのスケジュールを構成します。
- リトライポリシーとDLQ対応してるので信頼性強
- 公式ドキュメントはこちら
- その他アイデアがありそう
- EC2の定期起動停止
- Redshiftの定期起動停止とか
- RDSからS3への定期エクスポートとか
- CWLをS3に定期ダンプとか
感想
- 設定はめちゃ簡単。なんかSystems Manager感あるw
- AWSの多くのAPIが叩けるのでPrimitiveだけどパワフル！。夢がMoriMori。ここは大っきいメリット
- ログはCloudTrailで確認する仕様は、AWSのAPIを叩いた結果を見る意味だと分かるけど、ジョブスケジューラ(と呼んじゃうけど)側で見れないのは不便。個人的にジョブスケジューラはログが見やすいことが一番大事だと思ってる。ジョブスケジューラで凝ったことしたり作り込むにしてもそれは一時だけど、運用は日々行われて、ジョブスケジューラの運用の大半が平和の確認と失敗時の迅速な把握。それがCloudTrailでログでの確認だと、ログが生々しいので、そのジョブの実行結果の概要が分かるくらいの抽象度で見たい。さらに、ジョブスケジューラを使う人は運用者やアプリ開発者などもいるので、ログをCloudTrailで確認となると彼らにもCloudTrailへの閲覧権限が必要になる。ログの閲覧もジョブスケジューラ利用者の同一権限内に収まるような結合度が欲しい。逆に言うと、既に権限含めてCloudTrailのログを見やすく出来てるなら問題ないけど。
- 贅沢をいれば実行の履歴やトレンドも見れるといい(Jenkinsみたいに..)。