SQSとRabbitMQ
処理用のキューを作成する必要があります。キュー自体は比較的少量です。 1時間あたり約1,000回の書き込みが発生する場合があります。各タスクの実行にはそれぞれ約1分かかり、アイテムがキューに追加されるとすぐに処理されます。
Amazon SQSのような既製のものの代わりにRabbitMQを実装したい理由はありますか？アプリケーションがSQSのようなものではなく独自のキューシステムを必要とする理由は何ですか？
まず、Amazon SQSは擬似キューであり、すべてのメッセージ（キューに到達した場合）の配信は保証されますが、通常はキューで発生するFIFO形式ではありません。
メッセージの順序が重要であり、キューをFIFOのように動作させたい場合、Amazon SQSのドキュメントには、Amazon SQSからのメッセージがアプリケーションロジックでこれを処理することが記載されています順不同であなたに連絡します。
これと比較して、私が知る限り、RabbitMQでワーカーキューを実装できます。これにより、アプリケーションレベルでキューメッセージシーケンスを実装する必要がなくなった場合、これはより望ましいオプションになります。
どちらを選択するかを決定するのに役立ついくつかの要素を次に示します。
上記のキューメッセージシーケンス。
RabbitMQを使用して独自のサーバーをセットアップできますが、Amazon SQSの場合はできないため、ここでコストがかかります。
独自のサーバーをセットアップするには、隅について手を触れないように、主題に関する十分な知識が必要です。これはAmazon SQSには当てはまりません。すぐに使い始めることができます。
独自のRabbitMQサーバーは、Amazon SQSの場合とは異なり、メンテナンスコストの削減を意味します。
更新：
- Amazon SQSは、FIFOキューをサポートするようになりました。
SQSはRabbitMQよりも私の好みです。その理由は次のとおりです。
- SQSはマネージドサービスです。したがって、管理、セキュリティ、監視などを含むメッセージングシステムの実行の運用面について心配する必要はありません。Amazonがこれを行い、何か問題が発生した場合にサポートを提供します。
- SQSは弾力性があり、非常に大きなレート/ボリュームに拡張できます（AWSによる無制限;））
- SQSの可用性には多くの9が含まれており、Amazonによってサポートされています。これは、アプリケーションで心配する必要のないものです。
ただし、RabbitMQは、通常、テストから数万のTPSで、putsおよびgetの応答時間を短縮できます。 SQSがそのようなスループットを提供するには、複数のインスタンスを水平にスケールアップする必要があります。 5ms未満のputsを探している場合、RabbitMQは、1000秒間のTPSでのSQSテストから20ms-30ms近くのRutbitMQよりもわずかに高い時間を見ているため、検討するオプションかもしれません。
メッセージングインフラストラクチャをActiveMQからSQSに移行しただけで、これ以上満足することはできません。クラウドで独自のActiveMQクラスターを維持するよりも安価であることがわかりました。
お役に立てれば！それがどうなるか教えてください。
私は実際に両方とも商業環境で合理的に使用しました。
簡単な答えは、特定のコーナーケースがない限り、AWS SQSを使用することをお勧めします。 （簡単な要約のために下にスキップできます）
コーディング（タイ）：RabbitMQとAWS SQSの両方がライブラリを確立し、多くの例があります。
可視性タイムアウト（SQS）：SQSがRabbitMQを提供することの1つは、可視性タイムアウトのより広い概念です。 RabbitMQでは、コンシューマーがアックする前に死んだ場合、メッセージはキューに戻されます。ただし、SQSには、特定の呼び出し元に関連付けられていない可視性タイムアウトのより広い概念があります。そのため、作業単位を開始し、大きなタイムアウト（最大12時間）で可視性を設定し、切断し、別のワーカーを終了させて確認することができます。私の設計では、これを広範囲に活用し、追加のサービス/ストレージを排除して、潜在的に大きな「進行中」のペイロードを管理します。
デッドレター処理（RabbitMQ-「うさぎ」による）SQSは、デッドレターキュー（別のキュー）にメッセージをダンプする「リドライブポリシー」と呼ばれる基本的なデッドレター処理を提供します。これは基本的なもので、メッセージ数の概念しかありません。 RabbitMQには、有効期限が切れたときにDLEにプッシュされるメッセージを提供するDead Letter Exchangeがあります。しかし、これは「サービスとメッセージを監視していない場合、メッセージが期限切れになると、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はFIFO API呼び出し100万ドルあたり0.01ドルの追加コストでサポート（100万APIあたり0.05ドル対0.04ドル-割引前）を導入しました。使用を選択できます） FIFOかどうか。FIFO以外の場合、重複メッセージが表示されることはほとんどありません。
ストレージ（SQS）：AWSはストレージに課金しませんが、14日間の制限があります。 RabbitMQでは、ピークストレージ容量と追加のバッファを必要とするディスクスペースを割り当て、拡張、管理する必要があります。それは単なる頭痛の種です。
メトリック（SQS）：SQSは、すぐに使用可能なメトリックを提供します。また、AWSに追加することもできますが、それだけの作業です。
Local dev（tie）：ほとんどの近代的な店は地元の環境を好む。現在、RabbitMQおよびSQSのドッカーを許可するいくつかのオプションがあります。
高スループット/非常に大きなメッセージ（RabbitMQ-並べ替え）SQS> 1000リクエスト/秒をプッシュすると、SQSのレイテンシが上がります。それを回避するためのいくつかの戦略があります。しかし、ほとんどの作業を複数のキューに分割できるため、これらのケースは非常にまれです。しかし、100k/secが必要なこれらのタイプのケースでは、Kafka=の方が良いと思います。（私の仕事ではKafkaも使用します）遅延が少なく、1秒あたり1000件以上のリクエストを必要とする単一の作業単位があります。
概要：AWSに参加してAQSとの結婚を希望する場合、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.