SQSとRabbitMQ

処理用のキューを作成する必要があります。キュー自体は比較的少量です。1時間あたり約1,000回の書き込みがある可能性があります。各タスクの実行にはそれぞれ約1分かかる場合があり、アイテムがキューに追加されるとほぼすぐに処理されます。

Amazon SQSのような既成のものではなく、RabbitMQを実装したい理由はありますか？アプリケーションがSQSのようなものではなく独自のキューイングシステムを必要とする理由は何ですか？

まず、Amazon SQSは疑似キューです。つまり、すべてのメッセージの配信（キューに到達した場合）は保証されますが、通常はキューで発生するFIFO方式ではありません。

メッセージの順序が重要で、キューをFIFO方式で機能させたい場合、Amazon SQSのドキュメントには、Amazon SQSからのメッセージが順番どおりに届かないため、アプリケーションロジックでこれを処理するように記載されています。

これと比較して、私が知る限り、RabbitMQにワーカーキューを実装できます。これにより、アプリケーションレベルでキューメッセージシーケンスを実装する必要がなくなる場合は、これがより望ましいオプションになります。

どちらを選択するかを決めるのに役立ついくつかの要素を次に示します。

1. 上記のようにメッセージシーケンスをキューに入れます。

2. RabbitMQを使用して独自のサーバーをセットアップできますが、Amazon SQSの場合はセットアップできないため、ここでコストがかかります。

3. 独自のサーバーをセットアップするには、コーナーをそのままにしないように、主題に関する十分な知識が必要になります。これはAmazonSQSには当てはまりません。これは、開始するのが非常に早いためです。

4. 独自のRabbitMQサーバーは、Amazon SQSの場合とは異なり、将来のメンテナンスコストを意味します。

更新：

1. AmazonSQSがFIFOキューをサポートするようになりました。

SQSはRabbitMQよりも私の好みです。理由は次のとおりです。

1. SQSはマネージドサービスです。したがって、管理、セキュリティ、監視など、メッセージングシステムの実行の運用面について心配する必要はありません。Amazonがこれを行い、問題が発生した場合にサポートを提供します。
2. SQSは弾力性があり、非常に大きなレート/ボリュームに拡張できます（AWSによると無制限;））
3. SQSの可用性には、多くの9が含まれており、Amazonによってサポートされています。これは、アプリケーションで心配することが1つ少なくなります。

ただし、RabbitMQは、通常、私のテストから数万TPSで、プットとゲットの応答時間を短縮する可能性があります。SQSがそのようなスループットを提供するには、複数のインスタンスで水平方向にスケールアップする必要があります。したがって、5ミリ秒未満のプットを探している場合は、RabbitMQよりもわずかに高い1000秒のTPSでのSQSテストから20ミリ秒から30ミリ秒近くのプット時間が見られたため、RabbitMQを検討するオプションになる可能性があります。

メッセージングインフラストラクチャをActiveMQからSQSに移行したばかりであり、これ以上満足することはできません。独自のActiveMQクラスターをクラウドで維持するよりも安価であることがわかりました。

お役に立てれば！どうなるか教えてください。

私は実際に両方を商業環境で合理的に使用しました。

簡単な答えは、特定のコーナーケースがない限り、AWSSQSを使用することをお勧めします。（簡単な要約については、一番下までスキップできます）

コーディング（タイ）：RabbitMQとAWS SQSはどちらも、ライブラリと多くの例を確立しています。

可視性タイムアウト（SQS）：SQSがRabbitMQに対して提供するものの1つは、可視性タイムアウトのより広い概念です。RabbitMQでは、コンシューマーが失敗する前に死亡した場合、メッセージはキューに戻されます。ただし、SQSには、特定の発信者に関連付けられていない、可視性タイムアウトのより広い概念があります。したがって、作業単位を開始し、大きなタイムアウト（最大12時間）で可視性を設定し、切断し、別のワーカーに終了させて​​、それを確認することができます。私の設計では、これを広範囲に活用し、追加のサービス/ストレージを排除して、潜在的に大きな「進行中」のペイロードを管理します。

デッドレター処理（RabbitMQ-「うさぎ」による）SQSは、メッセージをデッドレターキュー（別のキュー）にダンプする「リドライブポリシー」と呼ばれる基本的なデッドレター処理を提供します。これは基本的なものであり、メッセージ数の概念しかありません。RabbitMQにはDeadLetter Exchangeがあり、メッセージの有効期限が切れるとDLEにプッシュされます。しかし、これは、「サービスを監視しておらず、メッセージの有効期限が切れると、DLEに到達する」という考えとしては議論の余地があります。引数カウンターが直感的であることがわかったので、RabbitMQにとってはわずかな勝利です。サービスではなくキューを監視するのはなぜですか？（どちらかといえば、それは逆です）

管理（SQS）：SQSへの管理はありません。API呼び出しの料金を支払うだけです。OS /アプリのセキュリティパッチ、スケール（ノードの追加）、ディスクなどの通常の問題はすべてAWSチームによって処理されます。また、FedRampに準拠しています（政府が使用するため）。それは本当に「セットアップして忘れる」システムです。RabbitMQは通常のOS /サービスパッチ、AMI、クラスタリング、セキュリティ強化などを必要としますが、非常にまれですが、AMIがダウンしたり、場合によっては移動する必要があるため、すぐにクラスタリングが必要になります。SQSは、これらすべての頭痛の種を取り除きます。

コスト（SQS）：1回のSQS API呼び出しに、「最大10メッセージ/ 256kサイズのバッチ」を含めることができます。「ロングポーリング」により、コストを大幅に削減できます。さらに、メッセージ圧縮のような戦略があり、数十（数百以上と主張するものもあります）のメッセージを単一のペイロードで送信して、コストをさらに削減できます。そしてこれは、人々が問題の監視/パッチ適用/修正に費やす時間を検討する前です。SQSは、アイドル状態であるかのように「pocプロジェクト」にも最適で、コストはかかりません。

FIFO（TIE）：2016年、AWSは約$ 0.01 /百万のAPI呼び出しの追加コストでFIFOサポートを導入しました（$ 0.05対$ 0.04 /百万のAPIすべて-割引前）。FIFOを使用するかどうかを選択できます。非FIFOの場合、メッセージが重複することはめったにありません。

ストレージ（SQS）：AWSはストレージに課金しませんが、14日間の制限があります。RabbitMQでは、ピークストレージ容量と追加のバッファーを必要とするディスクスペースを割り当て、拡張、および管理する必要があります。それはただより多くの頭痛の種です。

メトリクス（SQS）：SQSはすぐに使用できるメトリクスを提供します。それらをAWSに追加することもできますが、それはさらに手間がかかります。

ローカル開発者（ネクタイ）：ほとんどの現代の店はローカル環境を好む。現在、RabbitMQとSQSのドッカーを許可するいくつかのオプションがあります。

高スループット/非常に大きなメッセージ（RabbitMQ-一種）SQSを1000リクエスト/秒以上プッシュすると、SQSのレイテンシーが増加します。それを回避するためのいくつかの戦略があります。しかし、ほとんどの作業は複数のキューに分割できるため、これらのケースは非常にまれです。しかし、100k /秒が必要なこのような場合には、Kafkaの方が優れていると思います。（私の仕事でもKafkaを使用しています）低レイテンシで1000回以上のリクエスト/秒を必要とする単一の作業ユニットを持つことはめったにありません。*この説明については、以下を参照してください

概要：AWSに参加し、SQSと結婚する意思がある場合、SQSは非常に簡単です。しかし、考慮すべき重要なことがあるので、読み進める必要があります。

RabbitMQ（およびその他のキュー）の古典的な戦略は、特定の種類の作業用に最適化されたいくつかの種類のキューを作成することです。次に、これらの各キューを微調整し、同様の作業を少数の（多くの場合、サイズが非常に大きい）キューにグループ化します。SQSには管理オーバーヘッドがないため、実際には各作業に専用キューを割り当てることをお勧めします。そうすることで、拡張が可能になるだけでなく、キューの飽和（キューを飽和させて他のワーカーを溺死させる不快な作業）、作業のより良いビュー（デフォルトのメトリック）なども排除されます。

新しい戦略により、私のチームは作業がどのように分散されているかをよりよく把握できるようになりました。「より多くの負荷のためにインスタンスをアップグレードする」時代は終わりました。過去には、他のサービスに副作用を引き起こす原因不明の大きなスパイクが見られたり、累積数がほぼ正しいように見えると推測されたりしていました。トラフィックが分離されたので、以前は気づかなかった多くの問題を実際に発見し、トラフィックの量がどこに向かっているのかを明確に説明できます。メトリックスとツールを実装することは非常に可能ですが、SQSはこれらすべてをすぐに提供します。

RabbitMQを真剣に検討する必要がある素晴らしいケースがまだあります

- Very large legacy code base that uses RabbitMQ with extensive tooling and knowledgeable support staff
- Messages that needs to be in the same work stream for > 14 days
- Very large messages that has very low latency requirements with it
- Cloud agnostic code base requirements. If you must run your code on other platforms (e.g. Azure/Google/bare metal), then SQS is not an option
- Large volume of data for a single pipeline that can't be broke up and other solutions (e.g. Kafka) are not viable. But at a super large volume, Kafka is a lot faster. While SQS will push large payloads to S3, you are now incurring additional cost.

コストに敏感な場合、AmazonSQSはおそらくより高価になります。おそらく、RabbitMQサーバーをどこかでホストする必要があるためだと思います。SQSは、最初の100万件のリクエストを無料で提供し、その後、100万件のリクエストごとに$ 0.4を請求します。ただし、長いポーリングを有効にする、つまりreceive_message_wait_timeを20秒に設定することで、SQSでコストを削減するための秘訣があります。これは、メッセージが20秒ごとにのみ送信されることを意味するのではなく、キューが空の場合（20秒ごと）にSQSが「リクエスト」を請求しないことを意味します。

1時間あたり1000リクエストを使用する場合、1か月あたり744000を見ています。無料枠内では無料で、階層外では約0.74 * $ 0.4 = $ 0.2976です。待機時間を有効にすることで、おそらくさらに減らすことができます。したがって、あなたの場合、ほとんどのホスティングは最低5ドル以上から始まるため、SQSは実際には安くなる可能性があります（AWSからのEC2無料利用枠がない場合）。RMQは約128MBのRAMの起動のみを推奨しているため、最小のオプションで問題ありません。

SQSの方がはるかにユーザーフレンドリーで、RabbitMQの方が技術的だと思います。

更新：

実際、AWS Simple Notification Serviceは、プッシュベースであるため、つまりポーリングではないため、必要なものに適していることがわかりましたhttps://stackoverflow.com/a/13692720/5403449