【要約】GitHub Actionsのcronは何分遅れる？実運用で気づいたCloud Schedulerとの違い [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者が業務自動化のためにGitHub Actionsのcron機能を利用した際、実行タイミングの不正確さに直面した。運用開始直後から、以下の技術的課題が顕在化した。
- ・指定時刻から30分以上の遅延が頻発し、実行タイミングの予測が困難である。
- ・GitHubの共有インフラが高負荷になると、ジョブがキューに溜まり、実行が大幅に遅れる。
- ・タイムゾーンがUTC固定であるため、JSTへの変換が必要となり、設定の複雑さが増す。
- ・高負荷時には、キューに登録されたジョブの一部が削除されるリスクも存在する。
// Approach
実行精度の問題を解決するため、開発者はGoogle Cloudのマネージドサービスを用いた構成へ移行した。具体的には、以下のステップでアーキテクチャを再構築した。
- ・Cloud Schedulerを用いて、指定時刻に直接HTTPリクエストを送信する仕組みを構築した。
- ・リクエストを受けたCloud Run Jobがコンテナを実行するアーキテクチャを採用した。
- ・Dockerfileによるコンテナ化、Artifact Registryへのプッシュ、Cloud Run Jobの登録という手順を踏んだ。
- ・Cloud Schedulerのタイムゾーン指定機能を活用し、JSTでの直接設定を実現した。
- ・これにより、共有キューによる待ち時間を排除し、ダイレクトな実行経路を確保した。
// Result
Cloud Schedulerを用いた構成により、実行タイミングの劇的な改善を実現した。検証の結果、以下の成果が得られた。
- ・GitHub Actionsでは30分以上の遅延が発生していたが、Cloud Schedulerでは約1分程度の誤差に収まった。
- ・タイムゾーンをJSTで直接指定できるため、運用管理の負荷が軽減された。
- ・実行タイミングが予測可能となり、厳密な時間管理が求められるバッチ処理への適用が可能となった。
- ・設定の簡便さと精度のトレードオフを明確にし、用途に応じた使い分けの指針を得た。
Senior Engineer Insight
> 定期実行タスクの選定において、単なる「手軽さ」は運用フェーズでのリスクとなる。GitHub Actionsのcronは、インフラの共有特性上、実行時刻の保証ができない。これは、業務時間に基づいたデータ集計や通知などの「時間依存のワークフロー」において致命的な欠陥となり得る。一方、Cloud Scheduler + Cloud Run Jobは、スケーラビリティと予測可能性を両立している。コストと構築工数のトレードオフを理解した上で、ミッションクリティカルなバッチには後者を選択すべきである。