scheduled jobs custom clock processes
scheduled-jobs-custom-clock-processes
多くのアプリケーションは、定期的にジョブを実行する必要があります。たとえば、リモートAPIへ5分ごとにポーリングする。または毎晩深夜に報告メールを送信するなどの処理です。歴史的にcronが使用されますが、Herokuのように水平方向にスケーラブルな環境には向いていません。。より強力で柔軟なソリューションではクロックのプロセスです。
クロック·プロセスは、指定した間隔でスケジュール実行するための軽量なシングルトンプロセスを実行するためにプロセス modelを利用しています。バックグラウンドと組み合わせるときに、ジョブスケジューリングは非常にクリーンで拡張可能なアプローチとなります。
ジョブのスケジューリングと、ジョブの実行は関連していますが、独立したタスクです。ジョブのスケジューリングからジョブの実行を分離することで、各コンポーネントの責任が明確に定義され、その結果、構造化された管理しやすいシステムとなることが保証されます。
ジョブスケジューラーは実行のためでなく、バックグラウンド処理へキューするためだけに利用します。バックグラウンドワーカーは、スケジューラから別のプロセスを通じて作業を受けとります。
適切に分離されたスケジューリングと実行コンポーネントが独立してスケールすることが可能です。重複したスケジューリングや、複雑なロックロジックを避けるために、スケジューリングジョブは単一のコンポーネントによって実行されるべきです。しかし、バックグラウンドワーカーは必要であればスケールすることが可能です。
簡単なスケジューリング間隔（毎日、毎時、毎10分など）のジョブの場合はスケジューラアドオンを使用することができます。これは、単純な繰り返しジョブについては十分な無料のツールです。
しかし、多くの特定の実行間隔（一日三回、二時間ごと、あるいは5秒ごと）を定義する必要があるアプリケーションでは、ジョブをスケジュールするためのカスタム·クロック·プロセスを実装する必要があります。
Beyond the ability to specify a custom schedule, a clock process has the additional benefit of being defined as part of the process model - consistent with other logical application components. This simplifies testing, reduces external dependencies and increases environment parity between development and production.
他の論理的なアプリケーション·コンポーネントと一致する - カスタムスケジュールを指定する能力を超えて、クロック·プロセスは、[プロセスモデル]（プロセスモデル）の一部として定義されている追加の利点があります。これはテストを簡素化し、外部依存関係と増加[環境パリティ]（http://www.12factor.net/dev-prod-parity）の開発と生産の間を減らすことができます。
カスタムスケジュールはその能力だけでなく、プロセスモデルとして定義されるという利点があります。すなわち他の論理的なアプリケーションコンポーネントと同じようにみなされます。テストの単純化、外部依存の低下と、開発環境と本番環境の 環境同化を増大させます。
Custom clock implementations vary greatly by language. However, as part of an application's process model, defining a clock process is very simple. Here is the Procfile for a typical Node.js application.
web: node web.js
worker: node worker.js
clock: node clock.js
Conceptually, the contents of clock.js are immaterial. What is important is that the clock.js process is responsible only for determining what jobs to run at what interval and for scheduling those jobs to be run in the background.
The background worker defined in worker.js is then responsible for receiving and immediately executing the scheduled work.
As previously mentioned, the clock component should be a singleton process to avoid scheduling duplicate jobs and the need for complicated locking logic. Once deployed to Heroku simply scale the clock process to a single dyno.
:::term
$ heroku ps:scale clock=1
Scaling 'clock' processes... done, now running 1
The `worker` process may need additional dynos if the scheduled jobs represent a material increase in processing. At the very least one `worker` dyno will need to be running to receive and execute scheduled jobs.
There are many libraries and services that allow you to implement scheduled jobs in your applications. Some concrete examples of scheduled job implementations in various languages include:
| Language/framework | Reference |
|---|---|
| Ruby/Rails |