RabbitMQアクティブ-パッシブクラスタをデプロイするためのステップバイステップガイド

RabbitMQの高可用性には、互いに通信できる2台以上のサーバーだけでは不十分です。共有メタデータのためのクラスタリング、メッセージ可用性のためのレプリケートされたキュー、そしてクライアントのための明確なフェイルオーバーパスが必要です。

このガイドでは、アクティブ-パッシブスタイルのデプロイメントのRabbitMQ側を示します。クライアントのフェイルオーバーは通常、ロードバランサー、DNS変更、サービスディスカバリー、またはRabbitMQ外部で管理される仮想IPから行われます。

アクティブ-パッシブクラスタの前提条件

設定を開始する前に、すべての対象クラスタノード（ノードA - アクティブ、ノードB - パッシブ）で以下の前提条件が満たされていることを確認してください。

互換性のあるソフトウェアバージョン: ノード間でRabbitMQサーバーとErlang/OTPのバージョンを揃えてください。実際には、RabbitMQの文書化されたローリングアップグレードパスに従わない限り、すべてのノードで同じRabbitMQバージョンを実行してください。
ネットワークアクセス可能性: ノードは、クライアントが使用するAMQPポート、クラスタリングに使用する分散ポート、および有効にした管理ポートやTLSポートを介して通信できる必要があります。
ホスト解決: すべてのノードで/etc/hostsファイル（またはDNS）を設定し、各ノードが他のすべてのノードのホスト名を確実に解決できるようにします。
クッキーの一貫性: Erlangの「マジッククッキー」はすべてのノードで同一である必要があります。これはノードがクラスタリングのために互いに信頼するために重要です。

クッキーの一貫性を確立する

Erlangクッキーは、ノードが安全に通信できるかどうかを決定します。最初に初期化されたノードから他のすべてのノードにコピーする必要があります。

ノードA（最初のノード）:

クッキーファイル（通常は/var/lib/rabbitmq/.erlang.cookieまたは~/.erlang.cookie、インストール方法によって異なります）を見つけ、その内容をコピーします。

ノードB（および後続のノード）:

RabbitMQサービスを停止します:
```
sudo systemctl stop rabbitmq-server
```

既存のクッキーファイルをノードAからコピーした内容で置き換え、正しいパーミッション（通常は400）を確保します。

# 例: echoを使用（必要に応じて内容を置き換えてください）
echo "YOUR_LONG_COOKIE_STRING" | sudo tee /var/lib/rabbitmq/.erlang.cookie
sudo chmod 400 /var/lib/rabbitmq/.erlang.cookie

ノードBでサービスを開始します:
```
sudo systemctl start rabbitmq-server
```

ステップ1: ホスト名とネットワークの設定

ノードAとノードBの両方のホストファイルが、それらのホスト名を正しくマッピングしていることを確認します。

例: /etc/hosts（両方のサーバー）:

192.168.1.10   rabbitmq-node-a
192.168.1.11   rabbitmq-node-b

ステップ2: 最初のクラスタノード（アクティブ）の初期化

ノードAが最初のプライマリノードとなり、ここでクラスタが最初に確立されます。

ノードAでサービスを開始します（まだ実行されていない場合）:
```
sudo systemctl start rabbitmq-server
```
ステータスの確認: ノードが正しく実行されていることを確認します。
```
rabbitmqctl status
```

ステップ3: 2番目のノード（パッシブ）をクラスタに参加させる

次に、ノードBにノードAが率いるクラスタに参加するよう指示します。

ノードBでRabbitMQアプリケーションを停止します（Erlangノードは利用可能なままにします）:
```
sudo rabbitmqctl stop_app
```
ノードBのローカル状態をリセットします（すでにスタンドアロンノードとして初期化されている場合）:
```
sudo rabbitmqctl reset
```
参加コマンド: ノードBで参加コマンドを実行し、ピアとしてノードAのホスト名を指定します。
```
sudo rabbitmqctl join_cluster rabbit@rabbitmq-node-a
```
ヒント: /etc/hostsで定義されたホスト名を使用してください。
ノードBでRabbitMQアプリケーションを開始します:
```
sudo rabbitmqctl start_app
```

ステップ4: クラスタ形成の確認

ノードAにログインし、両方のノードが互いを認識していることを確認します。

rabbitmqctl cluster_status

期待される出力スニペット:

running_nodesの下にrabbitmq-node-aとrabbitmq-node-bの両方が表示されるはずです。

Cluster status of node rabbit@rabbitmq-node-a ...
[{nodes,[{disc,[rabbit@rabbitmq-node-a,rabbit@rabbitmq-node-b]}]},
 {running_nodes,[rabbit@rabbitmq-node-a,rabbit@rabbitmq-node-b]},
 ...
]

ステップ5: キューの高可用性の設定

標準のRabbitMQクラスタリングは、ユーザー、交換機、バインディング、ポリシーなどのメタデータを共有します。メッセージがノード障害に耐えるようにするには、キューコンテンツにレプリケートされたキュータイプが必要です。

最新のRabbitMQデプロイメントでは、レプリケートされた永続キューにクォーラムキューを使用してください。従来のミラーリングされたキューは、古いRabbitMQリリースでha-modeポリシーを使用していましたが、そのアプローチは非推奨となり、新しいメジャーバージョンから削除されました。

クォーラムキューの宣言

アプリケーションから、またはrabbitmqadminを使用してクォーラムキューを宣言できます。この例では、永続的なクォーラムキューを作成します:

rabbitmqadmin declare queue name=orders durable=true arguments='{"x-queue-type":"quorum"}'

2ノードのラボでは、クォーラムキューは実行できますが、1つのノードの損失に耐えて過半数を維持することはできません。本番環境では、クォーラムキューに少なくとも3つのRabbitMQノードを使用し、1つのノードが障害を起こしてもキューが過半数を維持できるようにしてください。

ステップ6: フェイルオーバーのテスト

クラスタの準備ができたと判断する前に、クライアントが使用するパスをテストします:

いくつかの永続的なテストメッセージをクォーラムキューにパブリッシュします。
sudo rabbitmqctl stop_appでアクティブノードのRabbitMQアプリケーションを停止します。
クライアントがロードバランサー、DNSターゲット、またはサービスディスカバリー設定を介して再接続することを確認します。
生存しているノードからテストメッセージをコンシュームします。
sudo rabbitmqctl start_appで停止したアプリケーションを再起動し、rabbitmqctl cluster_statusを確認します。

最終的なポイント

RabbitMQクラスタリングはブローカーメタデータを共有しますが、キューの可用性はキュータイプとクライアントのフェイルオーバー設計に依存します。レプリケートされた永続キューにはクォーラムキューを使用し、実際のフォールトトレランスのために少なくとも3つのノードを維持し、アプリケーションが使用するのと同じ接続パスでフェイルオーバーをテストしてください。