定期実行は『当たり前すぎて落とし穴が多い』領域
cron で動くバッチが本番運用で問題になるパターンは尽きません。本記事では編集部の視点で、スケジュールジョブの設計と運用を公開情報をもとに整理します。キューシステム設計 もご参考に。
主要な選択肢
(1) サーバの cron：シンプルだが冗長性なし。(2) k8s CronJob：宣言的・冗長性あり。(3) AWS EventBridge Scheduler：サーバーレス・1分単位。(4) Temporal / Inngest：ワークフローエンジン。(5) GitHub Actions / Vercel Cron：軽量・公開URL ベース。料金・機能は最新の公式情報をご確認ください。
冗長性とSPOF回避
(1) cron をサーバ1台で運用は SPOF。(2) k8s CronJob の concurrencyPolicy：Forbid/Replace。(3) Leader Election：複数インスタンスで1台のみ実行。(4) EventBridge は冗長性内蔵。(5) 重複実行を冪等性で許容。冪等性設計 も合わせて。
失敗とリトライ
(1) 失敗の検知：終了コード/ログ。(2) リトライ回数の上限。(3) バックオフ。(4) DLQ 相当：何度も失敗するジョブの隔離。(5) アラート：連続失敗で通知。
タイムゾーンの罠
(1) UTC で書くのが安全。(2) JST 0時実行には UTC 15時。(3) サマータイム：国際展開で要注意。(4) cron は秒指定不可：1分単位。(5) EventBridge は秒対応。
長時間処理のジョブ
(1) 分割する：細かいタスクに。(2) Temporal/Step Functions：状態管理を任せる。(3) chunked 処理：1万件ずつ等。(4) 進捗保存：再開可能に。(5) 監視：1時間以上停滞したらアラート。キューシステム設計 も合わせて。
監視と可観測性
(1) Heartbeat 監視：Healthchecks.io 等。(2> ジョブ実行ログ：構造化で集約。(3) SLO 設定：成功率と所要時間。(4) 異常時の即時アラート。(5) 履歴の保管：監査要件。ログ管理実践 も合わせて。
失敗しがちなパターン
(1) cron が静かに死んでいる：誰も気付かない。(2) 同時2回起動でデータ重複。(3) 長時間処理がタイムアウト。(4) タイムゾーン取違い。(5) 本番のみの環境変数で開発で動かない。対策は、(1)heartbeat 監視、(2)concurrencyPolicy、(3)分割+進捗保存、(4)UTC 統一、(5)環境別設定の標準化、です。