Railsでワーカープロセスを整理する最良の方法は何ですか？

Question

スケジュールや実行時に、いくつかのパラメータを使ってバックグラウンドプロセスとして実行するコードがあります。共通の要素は、それらがディスパッチ処理の外側で実行されるが、Rails環境へのアクセス（およびおそらく渡されたパラメータ）が必要であるということです。

これを整理するにはどうすればよいのでしょうか？特定のプラグインや宝石を使用したい場合は、便利な理由を説明してください。あなたが使用するプラグインをリストアップするだけではありません。

Answer 1

多くの追加のインフラストラクチャを維持したくないということが重要なので、Rails以外で実行されるデータベース対応のキューを使用しました。

私の場合、background_jobとdelayed_jobを使用しました。 background_jobでは、作業員はcronで実行されていたので、デーモン管理はありませんでした。 delayed_jobでは、私はHerokuを使用しており、そのことについて心配しています。

delayed_jobを使用すると、バックグラウンドワーカーが実行する必要がある引数を多く渡すことができます。

Delayed::Job.enqueue(MyJob.new(param[:one], param[:two], param[:three]) 

私はcronを経由script/runnerを使用してからはさておき、スケジュール上のものを実行しているに良い解決策を見つけていない（私はそれが簡単にコードをテストするために見つけるためのRakeタスク上script/runnerを使用することを好みます）。

私は、特定のRailsリクエストへのアクセスを必要とする定期的にスケジュールされたバックグラウンドプロセスを持つ必要がなかったので、あまり問題はありませんでした。

私は、より多くの機能を備えた他のよりクーラーなシステムがあることは知っていますが、これは私にとってはうまくいきました。そして、管理するための新しいサービスをたくさん設定するのを避けるのに役立ちます。

Answer 2

リクエストを受け取り、Webサービスを使用していくつかの外部システムを呼び出す必要があるシステムがあります。これらの要求の中には、ユーザーが待つよりも時間がかかるものがあり、これらの要求を処理するエンタープライズキューイングシステム（activemq）を使用しています。

私はこのためにActiveMessagingプラグインを使用しています。これによりリクエストを整列させてリクエストデータにアクセスできる非同期処理用のキューに置くことができますが、レスポンスを待つ場合はポーリングサービスを作成する必要があります。

私はRyan BatesのrailscastをStarling and Worklingに見ましたが、彼らは有望に見えますが、私はそれらを使用していません。

Answer 3

定期的にスケジュールされたタスクについては、レーキタスクを使用します。シンプルで、簡単にテストし、理解しやすく、Rails環境とうまく統合できます。その後、必要な間隔でcronジョブを使ってこれらのレーキタスクを実行します（私は文法が少ししかないので、これらのジョブを管理するためにwheneverを使用します）。

Answer 4

非同期ジョブを実行する目的でデータベースに残るdelayed_jobとbackground_jobのような宝石は本当に好きではありません。それはちょうど私にとっては汚いようです。一時的なものはデータベースに属しません。

大規模なスケーラビリティの必要がない場合でも、私は非同期タスクを処理するためのメッセージキューのファンです。メッセージキューは複雑なシステムにとって理想的な「lingua franca」です。メッセージキューでは、ほとんどの場合、構築している技術や言語に制限はありません。統合が常に大きな苦痛である「エンタープライズ」環境では、並行性の低いメッセージキューの使用のメリットはおそらく最も顕著です。さらに、非同期ワークフローに複数のステップが含まれる場合は、メッセージキューが理想的です。 RabbitMQは私の個人的なお気に入りです。

たとえば、検索エンジンを構築するシナリオを考えてみましょう。インデックスに登録するURIを送信できます。当然のことながら、要求に応じてページを取得して索引付けすることは望ましくありません。つまり、メッセージキューの周りに構築します。フォームの送信先はURIを取り、それをインデックスに登録するメッセージキューにスローします。次の利用可能なスパイダプロセスは、キューからURIをポップし、ページを取得し、すべてのリンクを見つけ出し、未知の場合はキューに戻し、コンテンツをキャッシュします。最後に、キャッシュされたコンテンツを処理するインデクサプロセス用の新しいメッセージが2番目のキューにプッシュされます。 Indexerプロセスは、そのメッセージをキューからポップし、キャッシュされたコンテンツを索引付けします。過度に単純化された検索エンジンはたくさんの作業ですが、あなたはその考えを得ています。

実際のデーモンは、私自身のライブラリ（ChainGang）には部分的ですが、実際はKernel.fork（）のラッパーで、セットアップとティアダウンのコードを処理するのに便利な場所です。それはまだあまり行われていません。デーモンの部分は、メッセージキューよりもはるかに重要ではありません。

Rails環境に関しては、読者のための練習として残した方がよいでしょう。なぜなら、メモリ使用量は長期実行プロセスの重要な要素になるからです。あなたはあなたがする必要のないものをロードしたくない。ちなみに、これはDataMapperがActiveRecordのバットを確実にキックする1つの領域です。環境の初期化は十分に文書化されており、依存関係の数が大幅に少なくなり、キット全体とキャブドールが大幅に現実的になります。

私がcron + rakeについて気に入らないことの1つは、レーキが実質的に標準出力に印刷されることが保証され、cronジョブが出力を生成する場合にcronが過度に混乱する傾向があることです。私はすべてのcronタスクを適切な名前のディレクトリに入れて、それらをラップするレーキタスクを作成して、手動で実行するのは簡単です。レーキがこれを行うのは残念です。なぜなら、依存関係を利用するという選択肢が本当に好きだからです。いずれにしても、cronを介してスクリプトを実行するのではなく、スクリプトを直接参照するだけです。

私は現在、非同期プロセスに大きく依存するWebアプリケーションを構築中です。私は、Railsを使用しないことを非常に嬉しく思っています。