Rails プロジェクトを継承したばかりで、その前は典型的な 'nix サーバー上にありました。クライアントのためにherokuに移動することが決定され、バックグラウンドプロセスを機能させるのは私次第です. 現在、Everything を使用して毎日のイベント (電子メールなど) をスケジュールし、起動時に遅延ジョブ キューを起動します。
Heroku は、時計仕掛けを使用したカスタム クロック プロセスのドキュメントの例を提供しています。この例をいつでも使用できますか? 私が遭遇する可能性のある落とし穴はありますか？別のワーカー dyno を作成する必要がありますか?
はい-HerokuのCedarスタックを使用すると、好きなように実行できます。
シーダースタックの基本的な構成要素はダイノです。各dynoは、アプリケーションのエフェメラルコピー、512 MBのRAM、および大量の共有CPU時間を取得します。Web dynoは、HerokuがHTTPリクエストを送信する場所であるため、環境変数で指定されたポートにHTTPサーバーをバインドすることが期待されます$PORTが、それ以外のWebdynoは他のタイプのdynoと同じです。
アプリケーションは、でさまざまなコンポーネントを定義することにより、さまざまなコンポーネントを実行する方法をHerokuに指示しますProcfile。（Procfileを使用したプロセスタイプの宣言とスケーリングを参照してください。）Clock Processesの記事は、ワーカー（つまり非Web）dynoを使用して任意の基準に基づいて作業をキューに入れるパターンを示しています。ここでも、ここで好きなことを行うことができます。Procfileで定義するだけで、Herokuが問題なく実行します。クロックプロセス（24時間365日wheneverなど）を使用する場合は、ダイノ全体（$ 0.05 /時間）を使用して、作業のスケジュールを設定するだけです。
あなたの場合、WheneverからHerokuSchedulerに切り替えることを検討します。スケジューラは基本的にHerokuが実行するcronであり、crontabエントリは「dynoをスピンアップしてこのコマンドを実行する」ものです。追加のダイノには1時間あたり0.05ドルを支払うことになりますが、時計とワーカーのセットアップとは異なり、実際に実行に費やした時間に対してのみ支払うことになります。定期的なタスクを定常状態のWeb+ワーカーのトラフィックから明確に分離し、通常は大幅に安価です。
警告の唯一の他の言葉は、分散システムで定期的なタスクを実行することは複雑であり、複雑な障害モードを持っているということです。一部のプラットフォームインシデント（EC2の大規模な停止に対応）により、2つの同時クロックプロセスや重複したスケジューラーの実行などが発生しました。連続して実行する必要があること（1日に1回メールを送信するなど）を行う場合は、RDBMSロックで保護し、実際に毎日の仕事から23時間経過していることを再確認することを検討してください。