Amazon MQ はApache ActiveMQ Classic とRabbitMQ用のマネージドメッセージブローカーサービスで、AWS上でのメッセージブローカーのセットアップ、運用、管理を簡素化する。最近AWSは、より高い可用性とデータの安全性のために設計された複製タイプであるクォーラムキューを、Amazon MQ for RabbitMQでサポートすることを発表した。
RabbitMQのクォーラムキューは、Raftコンセンサスアルゴリズムに基づいた耐久性のある複製されたFIFOキューを実装する最新のキュータイプである。Raftコンセンサス・アルゴリズムは、分散システム全体で状態の複製ログを管理するためのプロトコルであり、ログ・エントリーの順序とコミットメントを調整するリーダーを選出することで、一貫性と信頼性を確保する。
LinkedInの投稿で、ソリューションアーキテクトのSaineshwar Bageri氏はこう説明している。
クォーラムキューは、高いデータ可用性とセキュリティを確保するためのレプリケーション機能を提供します。キューはRabbitMQノード間でキューデータを複製でき、ノードが故障した場合でもキューが実行できることを保証します。クォーラムキューでは、メッセージはPersistenceのためにディスクに書き込まれます。クォーラムキューを使用するには、少なくとも3ノードクラスタが必要です。
/filters:no_upscale()/news/2024/07/quorum-queues-amazon-rabbitmq/en/resources/1Quorum%20Queues-1722083330673.jpg)
(出典：LinkedInの投稿）
RabbitMQのドキュメントでは、キューは以下のように説明されている。
クォーラムキューは、より安全で、より単純で、明確に定義された障害処理のセマンティクスを提供するように設計されており、ユーザーがシステムを設計および運用する際に理解しやすいはずです。
さらに、AWS Computeブログの投稿で、Amazon MQのシニアプロダクトマネージャーであるVignesh Selvam氏と、Amazon MQのシニアソフトウェア開発エンジニアであるSimon Unge氏は次のように書いている。
クォーラムキューは、従来のミラーキューよりも速くネットワーク障害を検出し、素早く回復できるため、メッセージブローカー全体の回復力が向上します。
開発者は、バージョン3.13以上のRabbitMQブローカーで「x-queue-type」パラメータを「quorum」と明示的に指定することで、クォーラムキューを使用できる。同社は、ホスト内部でデフォルトですべてのキューがクォーラムキューとして作成されるように、デフォルトのvhostキュータイプを「quorum」に変更することを推奨している。
RabbitMQキューコンソール（出典：AWS Computeブログポスト）
クォーラムキューは、データの耐久性とフォールトトレランスが重要なシナリオに適している。しかし、一時的な使用は想定しておらず、一時的なキューや排他的なキューはサポートしていないため、レプリケートされていないキューには推奨されない。
さらに、クォーラムキューは短いほど性能が向上する。開発者は、キューの総メモリ使用量を制限するために、ポリシーやキュー引数を使用して、キューの最大長を設定できる（max-length、max-length-bytes）。
他のメッセージブローカーは、特に一貫性とフォールトトレランスが重要な分散システムにおいて、信頼性を高めるためにクォーラム機構を使用している。例えば、Apache Kafkaは、メッセージの耐久性のために主にログベースのアプローチを使用しているブローカーであるが、信頼性と一貫性を高めるためにクォーラムベースのレプリケーションをサポートできる。もう一つの例はApache Pulsarで、BookKeeperによって管理されるメッセージストレージに分散台帳を使用し、データの一貫性と耐久性のためにクォーラムベースのレプリケーションをサポートしている。最後に、NATS Streaming（現在はNATS JetStreamの一部）は、メッセージの耐久性とフォールトトレランスを確保するためにクォーラムベースのレプリケーションをサポートしている。
Amazon MQ for Rabbit MQのクォーラムキューの詳細については、ドキュメントページを参照されたい。