DevOpsナレッジハブ
DevOpsナレッジハブ

RabbitMQクラスタリング: セットアップ、設定、およびベストプラクティス

RabbitMQクラスタリングで、スケーラブルで回復力のあるメッセージングの力を解き放ちましょう。このガイドでは、ノードタイプ、ネットワークパーティション、データ同期などの必須概念を網羅しています。RabbitMQクラスタをセットアップする方法、ポリシーを使用して高可用性（HA）キューを設定する方法、そして堅牢なデプロイメントと管理のためのベストプラクティスを実装する方法をステップバイステップで学びます。耐障害性のあるメッセージ駆動型アプリケーションの構築を目指す開発者やオペレーターに最適です。

31 ビュー

RabbitMQクラスタリング：セットアップ、設定、およびベストプラクティス

RabbitMQは、アプリケーション間の非同期通信を促進する、強力で柔軟なメッセージブローカーです。単一のRabbitMQインスタンスでも多くのユースケースに対応できますが、複雑なシステムや高可用性が求められるシステムでは、クラスタリングが非常に大きなメリットをもたらします。RabbitMQをクラスタ化することで、複数のRabbitMQノードを単一の論理ユニットにまとめることができ、負荷分散、耐障害性の向上、スケーラビリティの強化が実現します。

本記事では、RabbitMQクラスタリングの基本概念、異なるノードタイプ、ネットワーク分断への対応方法、データ同期のメカニズムについて解説します。その後、堅牢なクラスタ環境をセットアップおよび設定するための手順を段階的に示し、最後に安定性とパフォーマンスを確保するための必須のベストプラクティスを紹介します。

RabbitMQクラスタリングの理解

A RabbitMQクラスタとは、協調して動作する1つ以上のRabbitMQノードの集まりです。これらのノードは情報を共有し、単一の統一されたメッセージブローカーとして機能することを可能にします。効果的なセットアップと管理のためには、クラスタのコアコンポーネントと動作を理解することが不可欠です。

ノードタイプ

クラスタ内のRabbitMQノードは、主に2つのタイプに分類されます。

  • ミラー化キュー（クラシック）/ 高可用性（HA）キュー（ポリシーベース）: これらは耐障害性を実現するための主要なメカニズムです。キューがミラー化されるか高可用性として設定されると、その内容はクラスタ内の複数のノードに複製されます。あるノードが失敗した場合、キューのレプリカを持つ別のノードが引き継ぎ、メッセージの可用性を保証します。HAキューはポリシーを介して設定され、クラシックミラーキューよりも柔軟性を提供する現代的なアプローチです。
  • 非ミラー化キュー: これらのキューは、宣言されたノード上にのみ存在します。そのノードが利用できなくなった場合、他の対策（例：プロデューサー確認と再試行、慎重なコンシューマー設計による永続メッセージなど）が講じられていない限り、そのキュー上のメッセージは失われます。

ネットワーク分断

ネットワーク分断は、ネットワークの問題によりクラスタ内のノードが互いに通信できなくなったときに発生します。これにより、ノード群がクラスタの残りの部分が失敗したと認識する状況が生じる可能性があります。RabbitMQは、キューのタイプに応じて分断への対応が異なります。

  • HAキュー: 分断が発生した場合、HAキューのリーダーレプリカを持つノードは動作を継続します。マイノリティパーティション内の他のノードは、分断が修復されるまで、そのキューへの接続を受け付けるのを停止します。これにより、メッセージが分断の両側に独立して書き込まれる可能性のあるスプリットブレインシナリオを防ぎます。
  • クラシックミラーキュー: HAキューと同様に、クラシックミラーキューのマイノリティパーティションは動作を停止します。

データ同期と一貫性

RabbitMQクラスタでは、一部のメタデータ（交換機やキューの定義、ユーザー資格情報、仮想ホストの設定など）がすべてのノードに複製されます。ただし、メッセージコンテンツは主に、キューのミラーリングまたはHAポリシーを介して管理されます。

  • メタデータ同期: いずれかのノードで交換機やキューを宣言すると、その定義はクラスタ内の他のすべてのノードに伝播されます。これにより、すべてのノードがトポロジの一貫したビューを持つことが保証されます。
  • メッセージ同期（ミラーリング/HA経由）: ミラー化またはHAキューの場合、RabbitMQは、そのようなキューに発行されたメッセージがそのミラーノードに複製されることを保証します。リーダーレプリカが発行とコンシュームを処理し、その状態がミラーと同期されます。

RabbitMQクラスタのセットアップ

RabbitMQクラスタのセットアップには、複数のRabbitMQインスタンスが互いを認識し、通信できるように設定することが含まれます。最も一般的な方法は、erlang.cookie ファイルを使用することです。

前提条件:

  • RabbitMQをインストールする複数のサーバーまたは仮想マシン。
  • すべてのサーバー間のネットワーク接続。
  • すべてのノードへのRabbitMQのインストール（バージョン互換性を確認してください）。

手順:

  1. 全ノードへのRabbitMQのインストール: 各サーバーで、お使いのオペレーティングシステムに応じた公式のRabbitMQインストールガイドに従ってください。

  2. Erlang Cookieの設定:
    Erlang Cookieは、通信のためにクラスタ内のすべてのノードが共有しなければならない秘密鍵です。これは、RabbitMQプロセスを実行しているユーザー（通常はrabbitmqまたはroot）のホームディレクトリにある.erlang.cookieというファイルに保存されます。

    • 最初のノード（ノードA）で:
      強力でランダムなCookieを生成します。uuidgenやopenssl rand -hex 16などのコマンドを使用できます。
      bash # opensslを使用した例 openssl rand -hex 16 | sudo tee /var/lib/rabbitmq/.erlang.cookie sudo chown rabbitmq:rabbitmq /var/lib/rabbitmq/.erlang.cookie sudo chmod 600 /var/lib/rabbitmq/.erlang.cookie
      異なる場合は、/var/lib/rabbitmq/をRabbitMQのデータディレクトリに置き換えてください。

    • 後続のノード（ノードB、ノードCなど）で:
      RabbitMQサービスを停止します。
      bash sudo systemctl stop rabbitmq-server
      ノードAから.erlang.cookieファイルをノードBの対応する場所にコピーします（ノードCなども同様）。所有者とパーミッションが同一であることを確認してください。
      bash # ノードBで、ファイルをコピーした後 sudo chown rabbitmq:rabbitmq /var/lib/rabbitmq/.erlang.cookie sudo chmod 600 /var/lib/rabbitmq/.erlang.cookie

  3. 全ノードでのRabbitMQの起動:
    全ノードでRabbitMQサービスを起動します。クラスタへの参加者として機能する最初のノードは最後に起動するのが良い習慣です。
    bash sudo systemctl start rabbitmq-server

  4. ノードのクラスタへの参加:
    いずれかのノード（例：ノードA）を初期ノードとして選択します。その後、後続の各ノード（例：ノードB）で、それをノードAに参加させます。

    • ノードBで:
      bash sudo rabbitmqctl join_cluster rabbit@node-a
      node-aをノードAのホスト名に置き換えてください。ノードBからホスト名が解決可能であることを確認してください。 DNSが信頼できない場合は、完全なネットワーク名（例：[email protected]）を指定する必要がある場合があります。

    • ノードCで:
      bash sudo rabbitmqctl join_cluster rabbit@node-a

    • 重要な注意点: デフォルトでは、join_clusterはノードをクラスタの一部にしますが、そのキューと交換機は保持します。「