Heroku で Appoxy SimpleWorker を見つけたとき、delayed_job をアプリで起動して実行しようとしていました。
Appoxy によると、これは超並列であり、ワーカーをスケールアップおよびスケールダウンしてコストを最小限に抑えます。ただし、HireFire の場合、delayed_job も同じように思えます。これが私の質問です:あなたなら、delayed_job + HireFire と SimpleWorker のどちらを選びますか? （なぜ？）
https://github.com/tobi/delayed_job
http://hirefireapp.com/
http://addons.heroku.com/simple_worker
現在、私のアプリは小さいです。音量が小さく、しばらくの間、アプリの数が異常に多くなることはありません。
両方のサービスの創設者から直接回答を得られると期待できる場所が他にあるでしょうか? マイケルとトラヴィスに感謝！
こんにちは（HireFireの作者です）
サービスの違いに関する情報を提供しようと思います。それがあなたの決定に役立つかどうかはわかりませんが、少なくともそれは何かです!
どちらのソリューションも異なるアプローチをとります。HireFire は、必要に応じて Heroku Web とワーカー dyno をスケーリングするだけです。既存のコードベースを変更する必要はありません。遅延ジョブを通常どおり使用するだけです。デプロイ時に Heroku のプラットフォームでスラッグとしてコンパイルされるため、別の環境/プラットフォーム用のコードを送信/作成する必要はありません。また、新しい Web またはワーカー dyno がスピンアップすると、スラッグが使用され、すぐに実行されます (すべてのENV 変数 / 設定。
SimpleWorker と比較した場合の HireFire の欠点は、HireFire が Heroku 固有であることです。したがって、Heroku からたとえば EngineYard や VPS/Dedicated ボックスに切り替えた場合、HireFire は機能しませんが、SimpleWorker は Heroku に厳密に関連付けられていないため機能します。ただし、PaaS 以外のプラットフォームでホストするのはおそらく非常に安価であるため (比較すると)、自動スケーリングは必ずしも必要ではありません。
私は HireFire を開発する前は SimpleWorker の顧客でしたが、個人的に気に入らなかったのは、コードベースの一部を SimpleWorker にプッシュし、Rails 環境にロードし、サーバーの場所からデータベースに再接続して、また、ジョブをクラウドに送信するたびに API 要求 (?) を実行します (ただし、現在は変更されている可能性があるため、確認するために自分で確認することをお勧めします。私にとってのようにあなたにとっての問題です）。私にとっては、新しいジョブクラスを追加したいたびに面倒/試行錯誤が多すぎて、実行中heroku ps:workers 1または実行中にアプリと宝石からすべての個々のコードをジョブクラスファイル自体にロードする必要がありました。heroku ps:scale worker=2アプリ全体がすでに Heroku でスラッグとしてコンパイルされているため、ENV 変数を含めてそれを使用するだけなので、ローカルで実行する場合とまったく同じように、1 つまたは 2 つのワーカーを即座にスピンアップし、コード ベースに変更を加えることなく処理を開始します。およびその他の設定/アドオンであり、高速にスピンアップします。
HireFireでは、hirefireapp gemを Gemfile に追加し、Heroku アカウント/アプリケーションを HireFire Web インターフェイスに追加し、スケーリングのニーズをカスタマイズし、アプリケーションを Heroku にデプロイするだけです。アプリケーションは常に監視され、管理/調整されます (1 分以内)。
HireFire には、ジョブとそのステータス (実行中/終了/失敗/など) のテーブルを備えた洗練されたインターフェイスはありません (もちろん、各アプリの Web/ワーカー dyno とキューに入れられたジョブの現在の量の概要があります。カスタマイズ可能なスケーリング設定)、実際にはそのような機能を提供するのはワーカー ライブラリの仕事です。私が知っている遅延ジョブには、HireFire に関連付けられていない、使用できる (オープン ソースの) 1 つまたは 2 つの小さな管理インターフェイスがあります。SimpleWorker はホストされたサービスであり、ワーカー ライブラリでもあるため、Web インターフェイスも提供します。
HireFire には、ワーカー dyno だけでなく、Web dyno もスケーリングする機能があります。
Heroku と SimpleWorker の両方が私の理解では秒単位で比例配分されているため、どちらのサービスも多くのジョブを並行して処理することができます。したがって、10 個のワーカー dyno を 6 秒間スピンアップしても、1 つを 60 秒間スピンアップしても、コストに違いはありません (またはほとんどありません)。
私は HireFire を自分でリリースした後、SimpleWorker を使用していません。これはかなり前のことです。そのため、SimpleWorker が最近提供するものや、それ以降プロセスが単純化されているかどうかはわかりません。現時点ではまだ有効です。
お役に立てれば！
こんにちは (SimpleWorker の創設者)、
Michael は非常にうまくまとめましたが、Heroku Worker と SimpleWorker の違いをいくつか追加します。HireFire とは限りません。
欠点は、完全な Rails 環境を実行していないため、SimpleWorker を使用するにはもう少し検討が必要なことです。ワーカーは、別のシステムで実行されている個別のエンティティ (実際のシステム) と考える必要があります。バックグラウンドでメールを送信したり、フロントエンドからいくつかのものをあちこちにオフロードしたりするなどの単純なことには、おそらく Heroku ワーカーが適しています。大規模なバッチ ジョブ、スケジューリング、実行時間の長いジョブを実行する場合、ジョブの可視性を高めたい場合などは、SimpleWorker を試してみてください。
ところで、最近いくつかの新しいビデオを公開したので、それがどのように機能し、どれほど簡単に使用できるかがわかります: http://www.simpleworker.com/how_it_works/videos
それが役立つことを願っています! また、SimpleWorker についてご不明な点がございましたら、お気軽にお問い合わせください。
私は遅延ジョブを使用し、データベースにdelayed_jobsがあるかどうかに基づいてherokuワーカーをスケーリングするために使用するrakeタスクを持っています:
namespace :heroku do
namespace :workers do
desc "stop heroku workers"
task :stop do
p ['stopping workers for', CONFIG['heroku_project']]
Heroku::Client.new(ENV['HEROKU_EMAIL'], ENV['HEROKU_PASSWORD']).set_workers(CONFIG['heroku_project'], 0)
end
desc "start heroku workers"
task :start do
p ['starting workers for', CONFIG['heroku_project']]
Heroku::Client.new(ENV['HEROKU_EMAIL'], ENV['HEROKU_PASSWORD']).set_workers(CONFIG['heroku_project'], 1)
end
desc "starts workers if the are items in the queue, otherwise, stops them."
task :check_queue => :environment do
p ["Env: ", Rails.env]
count = DelayedJob.find_pending.count
p ['Pending delayed jobs: ', count]
if count > 0
Rake::Task['heroku:workers:start'].invoke
else
Rake::Task['heroku:workers:stop'].invoke
end
end
end
end
スケジューラ アドオンを使用すると、10 分ごとにワーカーをチェックしてコストを抑えることができます。
私がこのソリューションを気に入っているのは、DelayedJob (私はよく知っています) を使用できるからです。別のプラグインやサード パーティを使用するのではなく、Heroku のコストを制限し、基本的に使用した分だけを支払う単純な rake タスクが 1 つあれば十分です。