Amazon SQSとRabbitMQ

はじめに

進歩と最適化は誰でも歓迎します。 今日は、人生をもっと楽にしてくれる素晴らしいこと、つまりキューについてお話したいと思います。 この点でベストプラクティスを実装すると、アプリケーションのパフォーマンスが向上するだけでなく、クラウドコンピューティングスタイルのアーキテクチャに向けてアプリケーションが正常に準備されます。 さらに、クラウドプロバイダーの既製のソリューションを使用しないことは、単に愚かです。

この記事では、中規模および大規模なWebアプリケーションのアーキテクチャーの設計に関して、Amazon Web Servicesを取り上げます。

そのようなアプリケーションのスキームを考えてみましょう。




ニュース、為替レート、株価など、さまざまなタイプのアグリゲーターがそのような組織の例です。

外部データプロバイダーは、処理後にデータベースに保存されるメッセージのストリームを生成します。
Web層を使用するユーザーは、特定の基準（フィルター、グループ化、ソート）に従ってデータベースから情報を選択し、オプションのサンプル処理（さまざまな統計関数）を行います。

Amazonは、最も一般的なアプリケーションコンポーネントを特定しようとし、サービスコンポーネントを自動化して提供します。 現在、このようなサービスは20個以上あり、AWSウェブサイト（ http://aws.amazon.com/products/）で完全なリストを見つけることができます。 ハブには、いくつかの人気のあるサービスを説明する記事がすでにありました。AmazonWeb Servicesについての人気です。 これは主に、自己インストールと構成、さらに高い信頼性と部分的な支払いの必要がないため魅力的です。

AWSを使用する場合、プロジェクトスキームは次のようになります。


間違いなく、このアプローチは需要があり、独自の市場を持っています。 しかし、多くの場合、金融要素に関して疑問が生じます。

1. AWSを使用してどれくらい節約できますか？
2. 同じプロパティでサービスを独立して実装することはできますか？
3. AWSを対応するものから分離する行はどこにありますか？

次に、これらの質問に答えようとします。

1.アナログの概要

比較のために、次のコンポーネントを検討します。

• メッセージ指向ミドルウェア-RabbitMQ
• AWSの上記のサービスの類似物で、SQSと呼ばれます

SQSサービスは、APIリクエストの数+トラフィックに基づいて支払われます
各サービスをより詳細に検討してください。

1.1。 SQS

Amazon SQSは、メッセージキューを作成して操作できるサービスです。 完成したSQSキューを処理するための標準サイクルは次のとおりです。

1. キューにメッセージを送信するには、プロデューサーはそのURLを知っている必要があります。 次に、SendMessageコマンドを使用して、メッセージを追加します。
2. コンシューマは、ReceiveMessagコマンドを使用してメッセージを受信します。
3. メッセージを受信するとすぐに、しばらくの間再受信がブロックされます。
4. メッセージを正常に処理した後、ConsumerはDeleteMessageコマンドを使用してメッセージをキューから削除します。 処理中にエラーが発生した場合、またはDeleteMessageコマンドが呼び出されなかった場合、タイムアウト後にメッセージがキューに返されます。

したがって、1つのメッセージを送信および処理するには、平均で3つのAPI呼び出しが必要です。

SQSを使用すると、API呼び出しの数+リージョン間のトラフィックに対して料金を支払います。 1万回の呼び出しのコストは0.01ドルです。 平均10,000件のメッセージ（x3 API呼び出し）に対して、0.03ドルを支払います。 ここで他の地域の料金を見ることができます。

メッセージ送信サービスを編成するための多数のオプションがあります。

• うさぎ
• Activemq
• Zmq
• Openmq
• 妨害（xmpp）

各オプションには長所と短所があります。 AMQPプロトコルの最も一般的な実装の1つとしてRabbitMQを選択します。

1.2。 うさぎ

1.2.1。 展開スキーム

RabbitMQがインストールされ、デフォルト設定のサーバーは、非常に優れたパフォーマンスを発揮します。 しかし、このバージョンの展開は私たちには適していません。なぜなら、 このノードが落ちた場合、すぐに多くの問題を取得できます。

1. メッセージ内の重要なデータの損失。
2. 生産者に関する情報の「蓄積」。これにより、キューの復元後に消費者が過負荷になる可能性があります。
3. 問題の解決中にアプリケーション全体を停止します。

テストでは、ノード間でキューを複製するアクティブ/アクティブモードで2つのノードを使用します。 RabbitMQの場合、これはミラーキューと呼ばれます。


そのようなキューごとに、キューのコピーが保存されるマスターとスレーブのセットが定義されます。 マスターノードがクラッシュした場合、マスターによってスレーブの1つが選択されます。

このようなキューを作成するには、宣言中に「x-ha-policy」パラメーターを設定します。これは、キューのコピーを保存する場所を示します。 可能な2つのパラメーター値

• all：キューのコピーはクラスターのすべてのノードに保存されます。 新しいノードをクラスターに追加すると、そのノードにコピーが作成されます。
• nodes：「x-ha-policy-params」パラメーターで指定されたノード上にのみコピーが作成されます。

ミラー化されたキューの詳細については、 http ： //www.rabbitmq.com/ha.htmlをご覧ください 。

1.2.2。 パフォーマンス測定技術

前に、テスト環境がどのように編成されるかを調べました。 次に、何をどのように測定するかを見てみましょう。
すべての測定で、m1.smallインスタンス（AWS）が使用されました。

多くの測定を実行します。
特定の値にメッセージを送信する速度、次に受信の速度-それにより、キューの増加に伴うパフォーマンスの低下をチェックします。

1.特定の値にメッセージを送信する速度、次に受信の速度-それにより、キューの増加に伴うパフォーマンスの低下をチェックします。
2. 1つのキューからメッセージを同時に送受信します。
3.異なるキューからのメッセージの同時送受信。
4.キューの非対称負荷：

• a。 受信の最大10倍のスレッドをキューに入れます。
• b。 送信されるよりも10倍多いストリームがキューから受信されます。

5.さまざまなサイズのメッセージを送受信します。

• a。 16バイト。
• b。 1キロバイト。
• c。 64キロバイト（SQSの最大）。

最初のテストを除くすべてのテストは、3段階で実行されます。

1. ウォームアップ2秒。
2. テスト実行15秒。
3. キューのクリーニング。

メッセージ確認

このプロパティは、配信とメッセージ処理を確認するために使用されます。 操作には2つのモードがあります。

• 自動確認-メッセージは受信者に送信された直後に正常に配信されたと見なされます。 このモードでは、1つのメッセージを取得するには、サーバーへの1回の呼び出しで十分です。
• 手動確認-メッセージは、受信者が適切なコマンドを呼び出した後、正常に配信されたと見なされます。 このモードでは、処理後にのみ配信を確認した場合に、メッセージの処理を保証することができます。 このモードでは、サーバーへの2つの呼び出しが必要です。

テストでは、2番目のモードが選択されます。 これは、メッセージ処理がReceiveMessageおよびDeleteMessageの2つのコマンドによって行われるSQSの作業に対応しています。

バッチ処理

接続、認証などを確立するために各メッセージで時間を無駄にしないために、RabbitMQおよびSQSでは、メッセージをバッチで処理できます。 これは、メッセージの送信と受信の両方に使用できます。 なぜなら バッチ処理はRabbitMQとSQSの両方でデフォルトで無効になっていますが、比較にも使用しません。

1.2.3。 試験結果

ロードアンロードテスト

要約結果：

ロードアンロードテスト		msg / s	リクエスト時間
			平均ミリ秒	分、ms	最大ミリ秒	90％、ミリ秒
SQS	消費する	198	25	17	721	28
	プロデューサー	317	16	10	769	20
うさぎ	消費する	1293	3	0	3716	3
	プロデューサー	1875	2	0	14785	0

この表は、SQSがRabbitMQよりもはるかに安定して動作することを示しています。RabbitMQでは、15秒間メッセージを送信するとエラーが発生する可能性があります。 残念ながら、この動作の理由をすぐに見つけることはできませんでした。テストでは、標準設定を厳守しようとしました。 同時に、RabbitMQの平均速度はSQSの平均速度の約6倍であり、クエリの実行時間は数倍遅くなります。

以下は、平均速度と時間の分布を示すグラフです。




一般に、キュー内のメッセージ数が増加してもパフォーマンスが低下することはありません。つまり、受信ノードが落ちたときにキューがボトルネックになることを恐れることはできません。

平行

同時に興味深いスレッドの数に対する作業速度の依存性のテストも興味深いものです。 SQSテストの結果は簡単に予測できます。作業はHTTPプロトコルを介して行われ、ほとんどの場合接続の確立にかかるため、おそらく、次の表に示すように、スレッドの数とともに結果が大きくなります。

SQS msg / s	スレッド
	1	5	10	40
プロデューサー	65	324	641	969
消費する	33	186	333	435

メッセージを送信する1つのリクエストの平均時間は16ミリ秒で、受信は29ミリ秒です。
また、1、5、および10フローの場合、依存関係は線形ですが、最大40フローの増加に伴い、平均速度は送信で50％、受信で30％増加しますが、平均リクエスト時間はそれぞれ43ミリ秒および98ミリ秒増加します。

RabbitMQの場合、速度飽和ははるかに速く、すでに5スレッドで最大に達します。

RabbitMQスレッド		スレッド
		1	5	10	40
プロデューサー	速度、メッセージ/秒	3086	3157	3083	3200
	レイテンシー、ミリ秒	0	1	3	11
消費する	速度、メッセージ/秒	272	811	820	798
	レイテンシー、ミリ秒	3	6	12	51

テスト中に機能が明らかになりました。送信用に1つのスレッドと受信用に1つのスレッドが同時に動作すると、メッセージの受信速度はほぼ0に低下しますが、送信スレッドは最大のパフォーマンスを示します。 テストを繰り返すたびにコンテキストを強制的に切り替えると、送信スループットは低下しますが、クエリ実行時間の上限は大幅に短縮され、問題は解決します。 1スレッド（送信/読み取り）のローカルテストから：11000/25対5000/1000。

さらに、5つのスレッドのいくつかのキューを使用してRabbitMQのテストを実施しました。

うさぎ	キュー
	1	5
プロデューサー	3157	3489
消費する	811	880

複数のキューの速度がわずかに高いことがわかります。 10個のスレッドの要約結果を次の図に示します。


大きさ

このテストでは、送信データのサイズに対する速度の依存性を考慮します。

RabbitMQとSQSの両方は、メッセージサイズの増加に伴い、送信および受信の速度の予想される低下を示しました。 さらに、メッセージのサイズが設定されたRabbitMQのキューはより頻繁に「フリーズ」し、リクエストに応答しません。 これは、これがハードディスクの操作に関連しているという推測を間接的に確認します。

比較速度の結果：


クエリ時間の比較結果：

2.コストと推奨事項の計算

ヨーロッパ地域の1つの小さなインスタンスの推定コスト0.08ドルから、2ノード構成+トラフィックコストのRabbitMQの価格は0.16ドルになります。 SQSでは、10,000メッセージの送受信コストは0.03ドルです。 次の依存関係があります。


1時間あたり6万メッセージは1秒あたり約17メッセージであり、SQSおよびRabbitMQが提供できる速度よりもはるかに遅いです。

したがって、アプリケーションが1秒あたり17メッセージ未満の平均速度を必要とする場合は、SQSが望ましいです。 アプリケーションのニーズが高くなっている場合は、専用メッセージングサーバーへの移行パスを検討する価値があります。

これらの推奨事項は中速でのみ有効であり、負荷変動サイクルの全期間で計算を実行する必要があることを理解することが重要ですが、アプリケーションがSQSがピーク時に許可する速度よりもはるかに高い速度を必要とする場合、これはプロバイダーの変更を検討する機会でもあります

RabbitMQを使用するもう1つの理由は、リクエストのレイテンシの要件である可能性があります。これは、SQSのレイテンシよりも1桁小さいです。

2.1。 RabbitMQソリューションのコストを削減することは可能ですか？

コストを削減するには2つの方法があります。

• クラスターを使用しないでください。
• マイクロインスタンスを使用します。

最初のケースでは、ノードまたはアクティブゾーン全体が落ちた場合にクラスターのHAが失われますが、アプリケーション全体が1つのゾーンのみでホストされている場合、これは怖くありません。
2番目の場合、しばらくの間リソースの使用率が100％に近い場合、マイクロインスタンスはリソースを削減できます。 これは、永続キューが使用されている場合、キューの動作に影響を与える可能性があります。

3.結論

したがって、「どのソリューションを使用すればよいか」という質問に対する明確な答えはないことがわかります。 これはすべて、ウォレットのサイズ、1秒あたりのメッセージ数、これらのメッセージの送信にかかった時間など、多くの要因に依存します。 それでも、この資料のメトリックに基づいて、特定のケースの動作を計算できます。

よろしくお願いします！

この記事は、EPAMクラウドコンピューティングコンピテンシーセンターのために、Maxim Bruner（minim）の研究に基づいて作成および適合されました。