EC2 で NServiceBus を正常に実行するには、さまざまな方法があります。どのオプションを使用するかを選択するには、コスト、スケーラビリティ、および運用上のオーバーヘッドのバランスを考慮する必要があります。
MSMQ
NServiceBus は MSMQ を使用する EC2 で正常に動作しますが、注意が必要な障害がいくつかあります。主な問題は、EC2 インスタンスのコンピューター名/DNS 名が再起動のたびに変わることです。メッセージをサブスクライブするときと同様に、エンドポイントにメッセージを送信するときにコンピューター名が使用されるため、これは問題です。このオーバーヘッドを克服する簡単なオプションの 1 つは、エラスティック IP をインスタンスにアタッチし、その DNS 名を使用することです。利点は、これを行うのが非常に簡単であることです。欠点は、デフォルトで 5 つの Elastic IP しか与えられないことです。あなたはもっと頼むことができます.Amazonは通常、追加のElastic IPを配布することにかなり寛大です. また、スケーリングの方法も制限されます。たとえば、AWS のエラスティック スケーリング機能に単純にプラグインすることはできません。また、バックアップに対処する必要があります。
メッセージングを使用したいが、本当にクレイジーな SLA がなく、マシンをすばやくスケールアップおよびダウンする必要がなく、大量のメッセージに対処する必要がない場合は、このオプションを選択します。これは、ほとんどのプロジェクトに当てはまります。
アマゾン SQS
SQS のカスタム トランスポートを作成できます。SQS リモート キューで NSB を使用する利点は、可用性の高いキューを取得できることです。EC2 インスタンスでキューを管理する必要がなく、バックアップについて心配する必要もありません。このアプローチでは、エラスティック スケーリングを活用することも簡単です。欠点は、読み取りごとに $$$ の費用がかかることです。そのため、MSMQ や RabbitMQ と同じ速度で読み取ることは経済的に実現可能ではない可能性があります。ただし、この問題は、ロング ポーリングのサポートと、1 回の呼び出しで多くのメッセージをダウンロードする機能によって軽減されます。 . もう 1 つの欠点は、DTC を使用した分散トランザクションがサポートされていないことです。NServiceBus 5 以降を使用している場合は、ここで説明されているように、トランスポートに Outbox パターンを実装できます。、メッセージが引き続き 1 回だけ処理されるようにします。それ以外の場合は、エンドポイントとハンドラーに冪等性ソリューションが配置されていることを確認する必要があります。各エンドポイントのポーリング間隔を調整することで、速度とコストを調整できます。また、しばらくメッセージを受信していない場合にポーリング間隔を減らすバックオフ戦略を使用することもできます。SQS には小さなサイズ制限 (256 K) があるため、メッセージのサイズについても心配する必要があります。ほとんどのメッセージではこれをヒットしません。
読み取り/書き込み速度が問題にならない場合は、このオプションを選択しますが、キューイング インフラストラクチャの運用サポートについて心配する必要はありません。
RabbitMQ
個人的に EC2 で RabbitMQ を試したことはありませんが、簡単に検索すると、EC2 インスタンスで RabbitMQ を起動して実行する方法に関する記事がいくつか見つかりました。上記のリンクで説明されているように、成熟した RabbitMQ トランスポートが利用可能であり、NServiceBus バージョン 5 の時点でメッセージの 1 回限りの処理が保証されています。これは SQS よりも運用コストが低く、MSMQ よりもクラスター化が容易であると聞いています。最後に、MSMQ と同様に、バックアップ戦略を考え出す必要があります (おそらくスナップショットを使用します)。
混合
1 つのキューイング システムを選択する必要があるとは誰も言いません。高可用性を必要とするエンドポイントに SQS を使用でき、$$$ を支払うことを気にせず、システムの残りの部分に MSMQ / RabbitMQ を使用できます。