EventBridge Schedulerは、LambdaやStepFunctions、CodePipeline等の定期実行を簡単に設定できます。
定期実行するバッチの起動で利用されている方も多いでしょう。
最初の設定時以外でEventBridge Schedulerがエラーになることは少ないため、再試行や監視について設定を忘れられることもあります。
今回は、この再試行や監視について簡単に紹介します。
エラー処理
発生するエラー
EventBridge SchedulerはスケジュールにしたがってAWSサービスのAPIを呼び出すサービスです。
しかし、何らかの事情でAPIの呼び出しに失敗することがあります。
ここで、EventBridge SchedulerでエラーになるのはAPI呼び出し失敗であることに注意してください。
たとえば、EventBridge SchedulerからのLambdaの呼び出しは通常は非同期実行です。
EventBridge SchedulerはinvokeAPIを呼び出しますが、非同期呼び出しのため実際の実行とは関係なくAPIは成功を返します。
この後にLambdaで起動失敗やエラーが発生する場合もありますが、それはEventBridge Schedulerには関係ありません。
APIの呼び出しに失敗するのは、たとえば以下のような場合です。
- AWSの障害
- スロットリングによる制限
- 設定ミス等の利用者側の問題
AWSは稼働率100%を保証しているわけではありませんし、各サービスやAPIにはクォータが存在します。
そのため、AWSのAPI呼び出しも失敗することがあることを念頭に置く必要があります。
権限の設定ミスや呼び出し先の設定ミスは呼び出しが失敗する分かりやすい理由です。
最初にテストして問題が無くても、ターゲットの名前変更や削除により後からエラーになる場合もあるかと思います。
再試行とDLQ
EventBridge Schedulerは、API呼び出しに失敗しときに自動的に再試行します。これはEventBridgeルールでも同じです。
デフォルトでは、24時間の間に最大185回の再試行を試みます。これは設定可能な値の最大値です。
（ただし、設定ミスに起因するような自動的に回復しないエラーでは再試行が行われないようです）
再試行については新規作成時にも設定項目がありますし、後からでも設定の変更を行うことができます。
再試行について設定可能な項目は、『イベントの最大経過時間』と『再試行回数』です。
再試行間隔は指定できず、エクスポネンシャルバックオフによって次の再試行までの待機時間が決定されます。
最大経過時間のデフォルトが24時間というのは大きく感じることがあります。
再試行を何回してくれてもいいのですが、忘れた頃に動かれても困ることがありますし、時間に制約のあるバッチもあります。
実行するバッチの事情にあわせて設定する必要があるでしょう。
DLQ（デッドレターキュー）を設定することも可能です。
SQSのキューを設定すると、再試行でも成功しなかったときにイベント情報をキューに登録してくれます。
これにより、独自のリカバリ処理を行うことが可能です。
監視
先に書いた通り、EventBridge SchedulerはAPI呼び出しに100%成功するわけではありません。
そのため、再試行の設定を適切に行った上で、それに失敗した場合には検知して対処することを考える必要があります。
スケジュールグループ
EventBridge Schedulerのスケジュールを作成するときに、あらかじめ作成しておいたスケジュールグループを選択します。
最初からdefaultグループが用意されており、デフォルトではこのグループが選択されます。
スケジュールグループ自体に設定できる項目は名前とタグのみで、スケジュールグループ自体が動作に影響することはありません。
しかし、監視の上では重要です。CloudWatchメトリクスは個々のスケジュール単位でなくスケジュールグループ単位で出力されます。
一見するとスケジュールグループ単位での監視は不便ですが、1つのバッチに対して複数スケジュールを設定したい時は便利です。
1つのバッチに対して複数スケジュールを設定するのは、たとえば以下のようなスケジュールで実行したい時です。
- 月曜～金曜の日中帯は10分間隔で実行する
- 月曜～金曜の夜間帯は30分間隔で実行する
- 土日は1時間間隔で実行する
1つのcron式で表現はできず、複数のスケジュールを登録します。
スケジュールグループのないEventBridgeルールのときは、監視もそれぞれのスケジュールに対して実施する必要がありました。
現在は、1つのスケジュールグループに整理することでそのスケジュールグループを監視するだけで済むようになっています。
CloudWatchメトリクス
CloudWatch SchedulerはCloudWatchメトリクスへ情報を出力しています。
先に書いた通り、ディメンションはスケジュールグループです。
CloudWatchアラームを設定する上でもっとも重要なものはInvocationDroppedCountかと思います。
これにより、再試行を諦めて最終的に実行できなかったことを検知できます。
他にも、ターゲット呼び出し失敗（TargetErrorCount）を直接知ることもできます。
また、EventBridge Scheduler自体のクォータによるスロットリングによる呼び出し抑制（InvocationThrottleCount）、ターゲットサービスのスロットリングによる呼び出し失敗（TargetErrorThrottledCount）もそれぞれメトリクスが設定されています。
これらにより、いつどのように失敗したかを大まかに知ることもことも可能です。
また、DLQを設定している場合はDLQへの配信失敗（InvocationsFailedToBeSentToDeadLetterCount）も監視できます。
DLQを使っている場合はこちらの監視も検討してください。
CloudTrail
EventBridge Schedulerのドキュメントには、モニタリングの項目にCloudTrailもあります。
こちらのドキュメント自体はCloudTrailに関する一般的な記載がある程度です。
CloudTrailのログを保存しておけば、以下のようなことを確認できるかと思います。
- スケジュールの削除や設定変更
- EventBridge Schedulerからターゲットの呼び出し
スケジュールの作成や設定変更、削除といった操作はもちろんCloudTrailに残ります。
誰が設定の変更や削除を行ったか追跡ができます。
EventBridge Schedulerが実際に他のサービスを呼び出したときの記録もCloudTrailに残ります。
CloudTrailで確認すると、実行ロールにAssumeRoleしたあとにサービスのAPI呼び出しを行っているのがわかるかと思います。
これにより、呼び出し失敗時の具体的なエラーを確認することが可能です。
まとめ
AWSのサービスは100%稼働することが保証されているわけではなく、エラー時に再試行することが必要です。
そのため、AWSのサービスにも再試行の設定をできるところが多くあります。
正しく設定するためには、どのような時に、どこで再試行が行われるか知っている必要があります。
また、同時に再試行にも失敗したことを検知することも考える必要があります。
いくらLambdaの再試行やエラー検知を行っても、Lambdaを呼び出す側でエラーになっていたら意味がありません。
エラーになることは滅多にないとは思いますが、EventBridge Schedulerについても再試行や監視を忘れないでいただければと思います。
