Amazon/楽天のブラックフライデーで例年通り散財した、@kojiisdです。 
今回、光学30倍ズーム、という謳い文句に惹かれて、10年ぶりくらいにパナソニックのコンデジを買ってしまいました。
これから写真を撮るのが楽しみになりそうです（＾＾
みなさんは散財しましたか？
さて、アクロクエストでは、エンジニアたちが仕事の中で気になっていたことを調査・検討・検証した際に、
その内容を社内勉強会でフィードバックしています。
今月は12月ということで、そのような調べたことを、アドベントカレンダーとしてブログに公開していくことにしました～！
初日はタイトルにもあるとおり、「Amazon EventBridge Schedulerの使いどころを整理してみた」です。
Amazon EventBridge Schedulerとは
AWSでイベント／スケジュールドリブンな処理の管理、というとAmazon EventBridgeが代表的ですが、先日、スケジュール機能に特化したAmazon EventBridge Schedulerが発表されました。
スケジュールベースのイベントトリガ管理を行う場合、従来のEventBridgeでは、Rulesという機能を使ってcronやrateを使用しつつ処理実行のタイミングを指定していましたが、以下のような制約がありました。
1. UTCベースのスケジュール指定が必要（誤ってJSTのつもりで時刻を設定してしまって、失敗した苦い経験ないですか？私はあります）
2. 実行できる機能は20程度のAWSサービスのみ
これらのスケジュール指定方法、実行サービスの幅などが広がったのがEventBridge Schedulerになります。
EventBridge Rulesとの比較は主に以下のようになっています。（抜粋）
| Amazon EventBridge Scheduler | Amazon EventBridge Rules | |
| スケジュール上限 | アカウント毎に100万 | アカウント内リージョン毎に300 |
| イベント実行スループット | 秒間1,000トランザクション | 秒間5トランザクション |
| 指定可能なターゲット | AWS SDKを使用した270以上のサービスと6,000以上のAPI | 20以上のターゲット |
| 時刻指定方法とタイムゾーン | at(), cron(), rate()に対応 すべてのタイムゾーンとDST（サマータイム）に対応 |
cron(), rate()に対応 タイムゾーンはUTCのみ、DSTはサポート外 |
| 1回限りのスケジュール | 指定可能 | 指定不可 |
| ウィンドウ時間を指定した設定 | 指定可能 | 指定不可 |
参考：Introducing Amazon EventBridge Scheduler | AWS Compute Blog
これを見ただけでも、より細かなスケジュール設定が可能になった、ということがわかりますね。
ちなみに従来のEventBridge Rulesでも、スケジュールベースのイベント作成はできますが、現在AWSコンソールにアクセスすると、下図のようにEventBridge Schedulerへの遷移を促されるので、今後スケジュールドリブンなトリガ管理はEventBridge Scheduler、イベントドリブンなトリガ管理はEventBridge Rules、と棲み分けがされていくかもしれないですね。
また、特に今回、大きな機能追加になりそうなものは以下かな、と感じました。
EventBridge Schedulerの特長的な機能追加
詳細を挙げればキリがないですが、私として気になった大きな機能追加は主に以下の3点ですね。
1. ウィンドウ時間（フレックスタイムウィンドウ）の指定が可能になった
予定した起動時刻に対して、指定した時間内の任意のタイミングに処理を起動させることが可能になりました。
これにより、同時刻に大量の処理が発生してしまいAWSのクォータ（制限）に引っかかりにくくすることができるようになりました。
例：12:00起動に設定してフレックスタイムウィンドウを15分と指定すると、12:00 - 12:15の間のどこかで実行されることになります。
2. 1回限りのスケジュールの指定が可能になった
今までのEventBridgeでは、基本的に「定期処理」または「イベントドリブンな処理」での指定が必要でした。
今回のリリースで、単発の実行のみを行う設定が可能になりました。（EventBridge Rulesでも1回限りの指定をするような小技はありますが、Rulesのスケジュールドリブンなイベント管理はあくまで「定期実行」が考え方のベースになっています。）
これにより、1度のみ実行すれば十分、というようなユースケースに対応することができるようになりました。
EventBridge Schedulerの使いどころを整理してみた
これらの機能追加を踏まえて、今回のサービスリリースで、どんなことが可能になりそうか、整理してみました。
1. 毎日、運用中のサービスの状態チェックを行う
2. 「1回限りの実行」を使用し、夜間のデータ移行処理を実行する
3. 短期間で、大量の処理を分散させて終わらせる
4. 業務時間外のEC2サーバーへのアクセスを制御する
1. 毎日、運用中のサービスの状態チェックを行う
運用しているサービスの状態チェックは、定期的に行っていると思います。このような定期的な処理は、従来のEventBridge Rulesでも指定可能でしたが、もちろんEventBridge Schedulerでも実現が可能です。EventBridge Schedulerでは、実行タイミングの指定時に、タイムゾーンの指定が可能になっているので、毎回UTCに変換した時刻を考える必要もなくなります。（従来のEventBridge Rulesでは、時刻指定の際にはUTCのタイムゾーンが固定で指定されていました。）
2. 「1回限りの実行」を使用し、夜間のデータ移行処理を実行する
サービスの更改などによるデータ移行が必要になった場合、基本的にサービスに影響を出さないように、夜間に実施するケースが多いですが、EventBridge Schedulerで1回限りの実行イベントを定義すれば、夜間の指定した時間帯にデータ移行処理を実行することが可能になります。
3. 短期間で、大量の処理を分散させて終わらせる
例えばLambdaで実施される処理を大量に並列で実行し、短期間で結果を得たい、というユースケースの場合、分割の粒度や実行タイミング、並列度を考えながら、Step Functionsを組むことがあると思います。
この場合、前処理のLambdaはどうしても実装が必要になってしまいますし、メイン処理も同時タイミングでの実行はサービスへの負荷が上がってしまい、サービスの運用に影響を出す恐れがあるため、実行タイミングにばらつきを発生させるよう、Step Functionsの設定で並列度を調整したり、場合によってはメイン処理のLambdaにWait処理を入れることがあると思います。
このようなユースケースの場合、フレックスタイムウィンドウを使って処理を分散させることが可能になります。
定期的なスケジュールの選択の上で、フレックスタイムウィンドウを「１時間」に設定すれば、指定した「毎日1時（JST）～2時」の間のいずれかで実行するイベントの作成が可能になり、ばらつきを制御する苦労から解放されます。
4. 業務時間外のEC2サーバーへのアクセスを制御する
たとえばEC2サーバーで運用している社内サービスが以下の要件で稼働しているとします。
1. 業務時間中は、Webアクセスはすべて受け付ける。
2. 業務時間外は、メンテナンス用のIPアドレス以外からのアクセスを遮断する。
このような場合、今まではLambdaによりEC2のセキュリティグループを定期的に変更する処理の実装が必要でした。EventBridge Schedulerを利用すると、EC2のModifyInstanceAttribute APIを直接コールするように設定することで、Lambdaの実装なしに要件を満たすことが可能となります。
まとめ
今回、Amazon EventBridge Schedulerの用途について整理をしてみました。スケジュールドリブンなイベント管理の機能強化により、
さらに効率的にサービスの開発や運用ができそうですね。私もより深く調べて、活用していきたいと思います。
Acroquest Technologyでは、キャリア採用を行っています。
- ディープラーニング等を使った自然言語／画像／音声／動画解析の研究開発
- Elasticsearch等を使ったデータ収集／分析／可視化
- マイクロサービス、DevOps、最新のOSSやクラウドサービスを利用する開発プロジェクト
- 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
