ロードバランサーの設定

ロードバランサー（LB）は複数のネットワークコンポーネント間で負荷を分散し、リソースの使用を最適化することで、過負荷によるシステム障害を回避します。LBはEMQXの必須コンポーネントではありませんが、以下のような明確なシステム上の利点をもたらします。

• EMQXの負荷を分散し、単一ノードの過負荷を回避する；
• クライアントの設定を簡素化し、クライアントはLBにのみ接続すればよく、クラスター内のスケーリングを意識する必要がない；
• TLS/SSL終端によりEMQXクラスターの負荷を軽減する；
• クラスターの前面にLBを配置することで不要なトラフィックを遮断し、EMQXクラスターを悪意のある攻撃から保護してセキュリティを向上させる。

本節では、EMQXにおけるLBの設定方法について解説します。

デプロイメントアーキテクチャ

本節では、3つの異なるロードバランサーのデプロイメントアーキテクチャを紹介します。

TCPロードバランサー

LBを設定したEMQXクラスターでは、LBが受信したTCPトラフィックを処理し、受け取ったMQTT接続要求やメッセージを異なるEMQXノードに振り分けます。典型的なデプロイメントアーキテクチャは以下の通りです。

TLS終端とロードバランサー

SSL/TLSが有効な場合は、LBでSSL/TLS接続を終端することを推奨します。つまり、クライアントとLB間はSSL/TLSで保護し、LBとEMQXノード間はTCP接続を使用することで、EMQXクラスターのパフォーマンスを最大化します。アーキテクチャは以下の通りです。

ハイブリッドデプロイメント

クラウドサービスプロバイダーのLBを接続および負荷分散層として利用したいが、TLS終端に対応していない、またはプロキシプロトコルなどのTLS機能が不足している場合は、ハイブリッドデプロイメントを選択できます。具体的には、EMQXの前にHAProxyやNGINXを配置してSSL/TLS接続を終端します。

EMQXで直接TLS接続を処理するよりも、この方法のほうがより高いパフォーマンス効果が得られます。デプロイメントアーキテクチャは以下の通りです。

負荷分散デプロイメントクラスターに加えて、DNSラウンドロビンを用いてEMQXクラスターに直接接続する方法もあります。これはすべてのノードをDNSラウンドロビンリストに追加し、デバイスがドメイン名またはIPアドレスリスト経由でクラスターにアクセスする方法です。ただし、DNSラウンドロビンは本番環境での利用は一般的に推奨されません。

実IPおよびTLS証明書情報の取得

LBをデプロイした後、EMQXは通常、クライアントの実際の送信元IPやTLS証明書情報を取得する必要があります。そのためには、LBでプロキシプロトコルの設定を有効にするか、実IPを取得するための関連設定を有効にする必要があります。

LBでプロキシプロトコルを有効にした場合、EMQXの該当リスナーでもproxy_protocol設定を有効にする必要があります。例えば、TCP 1883リスナーの場合、設定ファイルに以下を追加します。

listeners.tcp.default {
  bind = "0.0.0.0:1883"
  max_connections = 1024000

  proxy_protocol = true
}

LBでのプロキシプロトコル有効化方法については、各LBのドキュメントを参照してください。プロキシプロトコルをサポートしないLB製品でも、バックエンドサービスが実際のクライアントIPを取得できる場合があります。ご利用のLBやクラウドサービスプロバイダーの要件に応じて適切に設定してください。

クライアントTLS証明書情報

プロキシプロトコルv2は、ロードバランサーからEMQXのTCPリスナーへクライアントTLS証明書の一部情報（Common Name（CN）やSubjectなど）を転送できます。ただし、証明書のSubject Alternative Names（SANs）は転送されません。

cert_san.*の値からクライアント属性を初期化するには、TLS接続がEMQXで終端され、クライアントがEMQXのTLSリスナーに証明書を提示する必要があります。ロードバランサーでTLSを終端すると、SAN値はEMQXに渡されません。ロードバランサーがTLS接続を終端せずにEMQXに転送する場合、クライアント証明書はEMQXに提示され、EMQXはSANを抽出できます。設定の詳細は証明書のSubject Alternative Namesからクライアント属性を初期化するを参照してください。

LB製品の選定

現在、多くのLB製品が存在し、オープンソース版や商用版、さらにパブリッククラウドプロバイダーのロードバランシングサービスも利用可能です。

パブリッククラウド向けLB製品：

クラウドプロバイダー	SSL終端対応	プロキシプロトコル対応	LB製品
AWS	対応	対応	https://aws.amazon.com/elasticloadbalancing/?nc1=h_ls
Azure	不明	不明	https://azure.microsoft.com/en-us/products/load-balancer/
Google Cloud	対応	対応	https://cloud.google.com/load-balancing

プライベートクラウド向けLB製品：

オープンソースLB	SSL終端対応	プロキシプロトコル対応	ドキュメント/URL
HAProxy	対応	対応	https://www.haproxy.com/solutions/load-balancing.html
NGINX	対応	対応	https://www.nginx.com/solutions/load-balancing/

以降の2ページでは、プライベートにデプロイしたLBサーバーを例に、EMQXクラスターの設定およびロードバランシング方法を紹介します。

• NGINXによるEMQXクラスターのロードバランス
• HAProxyによるEMQXクラスターのロードバランス