はじめに
現在携わっているプロジェクトでは、AWSのEventBridgeを用いたイベント駆動型アプリケーションの開発を行っています。
EventBridgeめっちゃ便利やなあーと思いつつ、「これアプリケーション内でスケジュール管理完結できたりしないのか？そもそもインフラ側から制御することのメリットってなんだ？」といった感じで疑問が頭から湧いてきたわけです。
なので、そんな疑問を自己解決しようという試みでこの記事を書くに至りました。
アプリケーション内でスケジュール管理を行うには
結論、バキバキに実現可能でした^_^
手段は様々あるようですが、今回は面白そうなのでsidekiq-schedulerを用いた方法を試してみようと思います。
sidekiq-schedulerとは
sidekiq-scheduler は、Railsで非同期処理を実行する Sidekiq に、cron形式の定期ジョブ機能を追加する拡張ライブラリです。
OSのcronではなく、Rubyプロセス内でスケジューリングが完結するのがポイント。
👍 特徴まとめ
-
cronライクな表記でジョブを定期実行 -
Sidekiq Web UIから状態確認・手動実行が可能 - OSのcronに依存しないので環境に左右されにくい
実際に動かしてみる
Gemfileに追加
gem 'sidekiq-scheduler'
Jobを作成
class GreekJob
include Sidekiq::Job
def perform
puts "Sidekiqスケジューラが起動しました: #{Time.current}"
puts "Hello!"
end
end
スケジュール定義（YAML）
:schedule:
greek_job:
cron: '*/5 * * * *' # 5分ごとに実行
class: GreekJob
基本的にはこれだけで動くようです。実際にローカルで動かしてみましょう。
おお、確かに５分ごとに動いてる、、すげえ
routes.rbに以下を加え、http://localhost:3000/sidekiq へアクセスすると、Sidekiq Web UIにアクセスできます。
require 'sidekiq/web'
require 'sidekiq-scheduler/web'
authenticate :admin do
mount Sidekiq::Web => '/sidekiq'
end
おお、確かにスケジューリングされていますね。
この画面から手動でジョブを実行したり、無効化したりすることができます。楽しい。
じゃあアプリケーションとインフラ、どっちでイベント管理すればいいんや
このように、アプリケーション内でイベント制御が可能なわけですが、この方法と、EventBridge等を用いたインフラ側からの制御、どのように使い分けるべきなんでしょうか？
観点別にAIに聞いてみました。
| 観点 | アプリ内（Sidekiqなど） | インフラ側（EventBridgeなど） |
|---|---|---|
| 導入の手軽さ | ◎ Rails内で完結し導入しやすい | △ AWSリソースや設定が必要 |
| サービス連携 | △ 同一アプリケーション内に限られる | ◎ Lambda, SQS, SaaSなどと疎結合に連携できる |
| スケーラビリティ | △ Sidekiqサーバー台数に依存 | ◎ サーバレスで自動スケール可能 |
| 再試行・エラーハンドリング | △ 自前でリトライ設計が必要 | ◎ DLQやリトライポリシーが使える |
| モニタリング | ◎ Sidekiq Web UIが使える | ◎ CloudWatchやEventBusの可視化が可能 |
小規模〜中規模のアプリケーションで、処理がアプリ内で完結しているようなケースでは、Sidekiqなどを使ってアプリ側でスケジュール管理する方がシンプルで効率的だと感じました。
一方で、複数のサービスと連携したり、高い信頼性やスケーラビリティが求められるような場合は、EventBridgeのようなインフラ側の仕組みを活用するのが適していると思います。
今回開発しているプロダクトについても、スケーラビリティや信頼性、運用面での効率性を考慮すると、やはりEventBridgeを採用するのが妥当だよなあ〜と改めて感じました。
これは納得( ͡° ͜ʖ ͡°)
おわりに
ここまでお読みいただきありがとうございました。
選択肢がいくつもある中で、実際に比較しながら検討してみることで、納得感のある判断ができるのだと改めて感じました。