一般的なネットワーク機能 (メッセージング、ウォールなど) を備えた Rails アプリのリリースが近づいています。要求/応答サイクルからタスクをオフロードするために、ある種のバックグラウンド処理 (おそらく Bj) を使用したいと考えています。
これは、ユーザーが電子メールで友人を招待して参加したり、電子メールで通知したりする場合に発生します。
モデルを使用してこれらの招待と通知をデータベースにドロップし、x 分ごとにワーカー プロセスで処理する必要があるのか 、それともメッセージと招待をそこに保存して Amazon SQS を使用する必要があるのか わかりません。私のワーカーは、処理のために Amazon SQS からそれを取得します (招待/通知を送信します)。
Amazon のアプローチではデータベースから負荷がかかりますが、そこからメッセージを取得するのは遅いと思います。
どう思いますか？
あなたのタイトルには、Rails のパフォーマンスに問題があると書かれていますが、これを確実に知っていますか? 質問の残りの部分から、将来のパフォーマンスの問題の可能性を予測しようとしているように思えます。パフォーマンスの問題に賢明に対処する唯一の方法は、アプリケーションを公開してプロファイリングすることです。そうすることで、実際のパフォーマンスの問題が何であるかに関する経験的なデータが得られます。
Amazon SQS は無料ではなく、それを使用するとほぼ確実にアプリケーションが複雑になるという事実を考えると、データベースの負荷が問題になる場合は、Amazon SQS に移行します。問題が発生する前に推測しようとしないでください。アプリが公開されると、さまざまな問題に直面する可能性が高く、その中にはおそらく考慮していないものもあります。
重要な点は、バックグラウンド処理を使用することを既に決定しているということです。これは正しい決定です。瞬時ではない処理は、Rails の要求/応答サイクルに属していないため、Rails がブロックされるためです。処理する。必要に応じて、後でいつでも Amazon でスケーリングできます。
アプリはすでに Amazon EC2 でホストされていますか? SQS を使用できるようにするためだけに、既存のアプリを AWS に移行することはおそらくないでしょうが、Amazon のインフラストラクチャを既に使用している場合は、SQS が最適な選択肢です。もちろん、独自のメッセージング システム (RabbitMQ など) をセットアップすることもできますが、SQS を使用することで、心配する必要があることが 1 つ少なくなります。
Delay_jobやbackground_jobなど、Rails アプリにバックグラウンド処理を追加するオプションはたくさんありますが、私の個人的なお気に入りはWorklingです。ジョブの実際の実装を変更することなく、さまざまなバックグラウンド ランナーをプラグインできる優れた抽象化レイヤーを提供します。
SQS クライアントを追加する Workling フォークを維持しています。いくつかの欠点があります (詳細については、コメントまたは私のブログ投稿を参照してください) が、全体として、前回のスタートアップではうまく機能しました。
別の Ruby (非 Rails) プロジェクトにも SQS を使用しましたが、一般的に信頼性が高く、十分に高速であることがわかりました。James が上で指摘したように、一度に最大 10 個のメッセージを読み取ることができるので、絶対にそうする必要があります (私の Workling SQS クライアントはこれを行い、メッセージをローカルにバッファリングします)。
必要がなければ、アプリケーションを過度に複雑にしたくないという John Topley の意見に同意します。とはいえ、こういう判断は早い方がいい場合もあるのですが、最初から高負荷を想定しているのでしょうか？これを既存のユーザーベースに展開していますか、それとも離陸する可能性があるかどうかわからない公開サイトですか?
最初から大量のトラフィックを処理する必要があることがわかっている場合は、これが適切なステップになる可能性があります。SQS を使用するためにお金を使いたくない場合は、RabbitMQ などの無料のキュー ソリューションを検討してください。
私は現在、SQS を介して月に数百万のメッセージをプッシュしており、かなりうまく機能しています。時々ダウンしたり遅くなったりすることを計画していることを確認してください。そのため、いくつかの再試行機能と指数バックオフで作業する必要があります。良い点の 1 つは、一度に 10 個のメッセージを取得できることです。これにより、キューを処理する速度が向上します。1 つの要求を使用して 10 個のメッセージを取得し、1 つずつ処理できます。
Amazon SQS は優れたサービスですが、次の点が重要になる場合を除きます。
これらのいずれかが重要である場合は、StormMQ、RabbitMQ、または onlinemq.com などの実際のエンタープライズ MQ サービスを検討する必要があります。
このブログシリーズは、Amazon SQS と StormMQ を何の抵抗もなく比較しているので、興味深いものでした: http://blog.stormmq.com/2011/01/06/apples-and-oranges-performance/
EC2 への移行に問題がある場合は、onlinemq.com などの他のサービスを使用できます。