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

NGINXは高性能で多機能なサーバソフトウェアであり、ウェブサーバやリバースプロキシサーバとして機能します。さらに、NGINXはロードバランサーとしても動作し、クライアントからのリクエストを複数のバックエンドサーバに分散して負荷分散とパフォーマンスの最適化を実現します。NGINXは特に大量の同時リクエスト処理が重要なIoTアプリケーションに適しています。IoTでは多数のデバイスが存在し、高負荷のリクエスト処理が可能なサーバが求められます。EMQXは複数のMQTTサーバからなる分散クラスターアーキテクチャをネイティブにサポートしています。そのため、NGINXをロードバランサーとして、EMQXクラスターを構成することで高可用性とスケーラビリティを確保できます。

本ページでは、NGINXのインストール方法と、MQTTサーバとしてのEMQXクラスター向けにリバースプロキシおよびロードバランス設定を行う方法を紹介します。また、NGINX Plusを用いたEMQXデプロイの最適化方法も解説します。

特長とメリット

NGINXを用いてEMQXクラスターのロードバランスを行うことで、以下のような特長と利点があります。

リバースプロキシサーバとして、NGINXはMQTTサーバ側に位置し、MQTTクライアントを代表してEMQXクラスターへのMQTT接続要求を開始し、EMQXクラスターの応答をMQTTクライアントに返します。この構成により複数のクラスターを隠蔽し、MQTTクライアントには単一のアクセスポイントを提供します。MQTTクライアントはNGINXとだけ通信すればよく、背後のクラスターの数や構成を意識する必要がありません。これによりシステムの保守性とスケーラビリティが向上します。
NGINXはMQTTクライアントとEMQXクラスター間のSSL暗号化接続を終端でき、EMQXクラスターの暗号化・復号負荷を軽減します。これによりパフォーマンス向上、証明書管理の簡素化、セキュリティ強化などの利点があります。
NGINXは柔軟なロードバランス戦略を提供し、クラスター内のどのEMQXノードにリクエストを送るかを制御できます。これによりトラフィックやリクエストの分散が可能となり、パフォーマンスと信頼性が向上します。例えば、スティッキー（sticky）ロードバランスにより同一クライアントのリクエストを同じバックエンドサーバに割り当て、パフォーマンスやセッションの持続性を高められます。

EMQX LB NGINX

クイックスタート

このセクションでは、実際の例を用いたDocker Compose構成を紹介し、NGINXの機能を簡単に検証・テストできます。以下の手順で進めてください。

サンプルリポジトリをクローンし、mqtt-lb-nginxディレクトリに移動します。

bash

git clone https://github.com/emqx/emqx-usage-example
cd emqx-usage-example/mqtt-lb-nginx

Docker Composeでサンプルを起動します。

bash

docker compose up -d

MQTTX CLIを使い、10個のTCP接続を確立してMQTTクライアント接続をシミュレートします。

bash

mqttx bench conn -c 10

NGINXの接続状況とEMQXクライアント接続の分布を確認できます。

以下のコマンドでNGINXの接続監視を表示します。

bash

$ curl http://localhost:8888/status                                
Active connections: 11 
server accepts handled requests
 60 60 65 
Reading: 0 Writing: 1 Waiting: 0

これは現在のアクティブ接続数やサーバのリクエスト処理状況（読み取り、書き込み、待機状態）を示します。

以下のコマンドで各EMQXノードのクライアント接続状況をそれぞれ確認します。

bash

docker exec -it emqx1 emqx ctl broker stats | grep connections.count
docker exec -it emqx2 emqx ctl broker stats | grep connections.count
docker exec -it emqx3 emqx ctl broker stats | grep connections.count

これにより各ノードの接続数とアクティブ接続数が表示され、10接続がクラスター内のノードに均等に分散されていることが確認できます。

bash

connections.count             : 3
live_connections.count        : 3
connections.count             : 4
live_connections.count        : 4
connections.count             : 3
live_connections.count        : 3

以上の手順で、NGINXのロードバランス機能とEMQXクラスター内のクライアント接続分布を検証できます。emqx-usage-example/mqtt-lb-nginx/nginx.confファイルを編集してカスタム設定の検証も可能です。

NGINXのインストールと使用方法

このセクションでは、NGINXの詳細なインストールと使用方法を紹介します。

前提条件

開始前に、以下の3つのEMQXノードからなるクラスターを作成していることを確認してください。EMQXクラスターの作成方法はCreate a Clusterを参照してください。

ノードアドレス	MQTT TCPポート	MQTT WebSocketポート
emqx1-cluster.emqx.io	1883	8083
emqx2-cluster.emqx.io	1883	8083
emqx3-cluster.emqx.io	1883	8083

本ページの例では、単一のNGINXサーバをロードバランサーとして構成し、これら3つのEMQXノードからなるクラスターにリクエストを転送します。

NGINXのインストール

デモではUbuntu 22.04 LTS環境にソースコードからNGINXをインストールします。Dockerやバイナリパッケージでのインストールも可能です。

必要な依存パッケージ

NGINXのコンパイル・インストール前に、以下の依存パッケージがシステムにインストールされていることを確認してください。

GNU CおよびC++コンパイラ
PCRE（Perl Compatible Regular Expressions）ライブラリ
zlib圧縮ライブラリ
OpenSSLライブラリ

Ubuntu環境では以下のコマンドでインストールできます。

bash

sudo apt-get update
sudo apt-get install build-essential libpcre3-dev zlib1g-dev libssl-dev

ソースコードのダウンロード

最新の安定版NGINXはNGINX公式サイトからダウンロード可能です。例：

bash

wget https://nginx.org/download/nginx-1.24.0.tar.gz

コンパイル設定

ダウンロード後、ソースコードを展開し、ディレクトリに移動します。

bash

tar -zxvf nginx-1.24.0.tar.gz
cd nginx-1.24.0

以下のコマンドでコンパイルオプションを設定します。

bash

./configure \
 --with-threads \
 --with-http_stub_status_module \
 --with-http_ssl_module \
 --with-http_realip_module \
 --with-stream \
 --with-stream_ssl_module

上記のうち、--with-http_ssl_moduleはSSL対応追加、--with-streamおよび--with-stream_ssl_moduleはTCPリバースプロキシ対応を追加します。

コンパイル開始

以下のコマンドでコンパイルを開始します。

bash

make

インストール

コンパイル後、以下のコマンドでNGINXをインストールします。

bash

sudo make install

システムのPATHにあるディレクトリにNGINX実行ファイルのシンボリックリンクを作成します。

bash

sudo ln -s /usr/local/nginx/sbin/nginx /usr/local/bin/nginx

使い始め

NGINXの設定ファイルはデフォルトで/usr/local/nginx/conf/nginx.confにあります。本ページの設定例をファイル末尾に追記してください。基本的なNGINX操作コマンドは以下の通りです。

設定ファイルの検証：

bash

sudo nginx -t

設定ファイルが正常ならNGINXを起動：

bash

sudo nginx

稼働中のNGINXに設定変更を反映するには、事前に設定検証を行い、リロードします。

bash

sudo nginx -s reload

NGINXを停止するには：

bash

sudo nginx stop

NGINXのリバースプロキシおよびロードバランス設定

このセクションでは、さまざまなロードバランス要件に応じたNGINX設定方法を説明します。

MQTTのリバースプロキシ設定

クライアントからのMQTT接続要求をリバースプロキシし、バックエンドMQTTサーバに転送するため、NGINX設定ファイルに以下を記述します。

bash

stream {
  upstream mqtt_servers {
    # down: 現在サーバが一時的にロードバランス対象外であることを示す
    # max_fails: 許容される失敗リクエスト数（デフォルトは1）
    # fail_timeout: max_failsに達した際のタイムアウト時間（デフォルト10秒）
    # backup: 非バックアップサーバが全てダウンまたはビジー時にリクエストを受けるバックアップサーバ

    server emqx1-cluster.emqx.io:1883 max_fails=2 fail_timeout=10s;
    server emqx2-cluster.emqx.io:1883 down;
    server emqx3-cluster.emqx.io:1883 backup;
  }

  server {
    listen 1883;
    proxy_pass mqtt_servers;

    # このオプションを有効にする場合、対応するバックエンドリスナーもproxy_protocolを有効にする必要あり
    proxy_protocol on;
    proxy_connect_timeout 10s;
    # デフォルトのキープアライブ時間は10分
    proxy_timeout 1800s;
    proxy_buffer_size 3M;
    tcp_nodelay on;
  }
}

MQTT SSLのリバースプロキシ設定

NGINXでMQTTのTLS接続を終端し、暗号化されたMQTTリクエストをバックエンドMQTTサーバに転送して通信の安全性を確保できます。TCPベースの設定にSSL関連パラメータを追加するだけです。

bash

stream {
  upstream mqtt_servers {
    server emqx1-cluster.emqx.io:1883;
    server emqx2-cluster.emqx.io:1883;
  }

  server {
    listen 8883 ssl;

    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    ssl_certificate /usr/local/nginx/certs/emqx.pem;
    ssl_certificate_key /usr/local/nginx/certs/emqx.key;
    ssl_verify_depth 2;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!MD5;

    # 相互認証を有効にする場合はCA証明書とクライアント証明書検証を追加
    # ssl_client_certificate /usr/local/nginx/certs/ca.pem;
    # ssl_verify_client on;
    # ssl_verify_depth 1;

    proxy_pass mqtt_servers;

    # このオプションを有効にする場合、対応するバックエンドリスナーもproxy_protocolを有効にする必要あり
    proxy_protocol on;
    proxy_connect_timeout 10s;
    # デフォルトのキープアライブ時間は10分
    proxy_timeout 1800s;
    proxy_buffer_size 3M;
    tcp_nodelay on;
  }
}

MQTT WebSocketのリバースプロキシ設定

以下の設定でNGINXがMQTT WebSocket接続をリバースプロキシし、クライアントリクエストをバックエンドMQTTサーバに転送します。server_nameでHTTPのドメイン名またはIPアドレスを指定してください。

EMQX 6.3.0以降では、WebSocketリスナーはデフォルトで転送されたクライアントアドレスヘッダーを読みません。NGINXが設定するX-Forwarded-Forヘッダーを利用するには、各バックエンドEMQXノードのbase.hoconに以下を追加してください。

hocon

listeners.ws.default.websocket.proxy_address_header = "x-forwarded-for"

bash

http {
  upstream mqtt_websocket_servers {
    server emqx1-cluster.emqx.io:8083;
    server emqx2-cluster.emqx.io:8083;
  }

  server {
    listen 80;
    server_name mqtt.example.com;

    location /mqtt {
      proxy_pass http://mqtt_websocket_servers;

      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "Upgrade";

      # キャッシュ無効化
      proxy_buffering off;

      proxy_connect_timeout 10s;
      # WebSocket接続タイムアウト
      # この時間内にデータ交換がなければWebSocket接続は自動切断される（デフォルト60秒）
      proxy_send_timeout 3600s;
      proxy_read_timeout 3600s;

      # リバースプロキシの実IP設定
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header REMOTE-HOST $remote_addr;
      proxy_set_header X-Forwarded-For $remote_addr;
    }
  }
}

TIP

WebSocketの例では、EMQXがproxy_address_header設定時にX-Forwarded-Forヘッダーの最左（最初）の値を読み取るため、X-Forwarded-Forを$remote_addrで上書きしています。このため、$proxy_add_x_forwarded_forは使用しないでください。$proxy_add_x_forwarded_forは既存のX-Forwarded-Forに$remote_addrを追加し、クライアントが偽装可能な値が最左に残るためです。詳細はForwarded Client Addressを参照してください。

MQTT WebSocket SSLのリバースプロキシ設定

NGINXでMQTT WebSocketのTLS接続を終端し、暗号化されたMQTTリクエストをバックエンドMQTTサーバに転送して通信の安全性を確保できます。server_nameでHTTPのドメイン名またはIPアドレスを指定し、WebSocketベースの設定にSSLおよび証明書関連パラメータを追加するだけです。

bash

http {
  upstream mqtt_websocket_servers {
    server emqx1-cluster.emqx.io:8083;
    server emqx2-cluster.emqx.io:8083;
  }

  server {
    listen 443 ssl;
    server_name mqtt.example.com;

    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    ssl_certificate /usr/local/nginx/certs/emqx.pem;
    ssl_certificate_key /usr/local/nginx/certs/emqx.key;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!MD5;

    # 相互認証を有効にする場合はCA証明書とクライアント証明書検証を追加
    # ssl_client_certificate /usr/local/nginx/certs/ca.pem;
    # ssl_verify_client on;

    location /mqtt {
        proxy_pass http://mqtt_websocket_servers;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";

        # リバースプロキシの実IP設定
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header REMOTE-HOST $remote_addr;
        proxy_set_header X-Forwarded-For $remote_addr;

        # キャッシュ無効化
        proxy_buffering off;
    }
  }
}

ロードバランス戦略の設定

NGINXは接続の分散方法を制御する複数のロードバランス戦略を提供します。実際の運用ではサーバ性能やトラフィック要件に応じて適切な戦略を選択することが重要です。以下はupstreamブロック内で設定可能な代表的なNGINXロードバランス戦略です。

ラウンドロビン

デフォルトのロードバランス戦略で、リクエストをバックエンドサーバに順番に均等に分配します。バックエンドサーバの性能がほぼ同等の場合に適しています。

bash

upstream backend_servers {
  server emqx1-cluster.emqx.io:1883;
  server emqx2-cluster.emqx.io:1883;
  server emqx3-cluster.emqx.io:1883;
}

重み付きラウンドロビン

ラウンドロビンに加え、各EMQXノードに異なる重みを割り当ててリクエストの分配比率を調整します。重みの高いサーバがより多くのリクエストを受けます。

bash

upstream backend_servers {
  server emqx1-cluster.emqx.io:1883 weight=3;
  server emqx2-cluster.emqx.io:1883 weight=2;
  server emqx3-cluster.emqx.io:1883 weight=1;
}

IPハッシュ

クライアントのIPアドレスを元にハッシュを計算し、同じクライアントからのリクエストを常に同じバックエンドサーバに割り当てます。

bash

upstream backend_servers {
  ip_hash;
  server emqx1-cluster.emqx.io:1883;
  server emqx2-cluster.emqx.io:1883;
  server emqx3-cluster.emqx.io:1883;
}

最小接続数

現在の接続数が最も少ないサーバにリクエストを割り当て、各サーバの負荷をできるだけ均等にします。サーバ性能に差が大きい場合に適しています。

bash

upstream backend_servers {
  least_conn;
  server emqx1-cluster.emqx.io:1883;
  server emqx2-cluster.emqx.io:1883;
  server emqx3-cluster.emqx.io:1883;
}

NGINX Plusを用いたEMQXデプロイの最適化

このセクションでは、NGINX Plus固有の機能を利用してEMQXデプロイを最適化する方法を紹介します。本ページでコンパイル・インストールしたNGINXでは利用できないため、NGINX Plusの詳細はこちらのドキュメントを参照してください。

MQTTスティッキーセッションロードバランスの設定

「スティッキー」とは、クライアントが再接続した際に同じサーバにルーティングする機能で、セッションの乗っ取りを防ぎます。頻繁に再接続するクライアントや問題のあるクライアントの効率化に役立ちます。

スティッキーを実現するには、サーバが接続要求内のクライアント識別子（通常はクライアントID）を特定する必要があり、ロードバランサーがMQTTパケットを解析します。クライアントIDを取得後、静的クラスターではハッシュでサーバIDに変換したり、ロードバランサーがクライアントIDと宛先ノードIDのマッピングテーブルを保持して柔軟にルーティングします。

以下は設定例です。

bash

mqtt_preread on;

upstream backend_servers {
    hash $mqtt_preread_clientid consistent;
    server emqx1-cluster.emqx.io:1883;
    server emqx2-cluster.emqx.io:1883;
    server emqx3-cluster.emqx.io:1883;
}

上記例は環境に応じて調整が必要な場合があります。設定で使われるモジュール（ip_hashやleast_connなど）はNGINX標準モジュールであり、追加モジュール依存はありません。

クライアントID置換機能の設定

MQTT通信においてセキュリティは重要です。デバイスはシリアル番号などの機密情報をクライアントIDとして使うことが多く、MQTTサーバのデータベースに保存するとリスクがあります。NGINX PlusはクライアントID置換機能を提供し、NGINX Plus設定で指定した別の値にクライアントIDを置換できます。

以下は設定例です。

bash

stream {
    mqtt on;

    server {
        listen 1883 ssl;
        ssl_certificate /etc/NGINX/certs/emqx.pem;
        ssl_certificate_key /etc/NGINX/certs/emqx.key;
        ssl_client_certificate /etc/NGINX/certs/ca.crt;      
        ssl_session_cache shared:SSL:10m;
        ssl_verify_client on;
        proxy_pass 10.0.0.113:1883;
        proxy_connect_timeout 1s;  

        mqtt_set_connect clientid $ssl_client_serial;
    }
}

この例ではクライアントの相互認証を有効にし、クライアントSSL証明書のシリアル番号をユニーク識別子として抽出し、元のクライアントIDを置換しています。$ssl_client_s_dnなど他の値を利用することも可能です。

NGINXパフォーマンスの最適化と監視有効化

このセクションでは、NGINXのパフォーマンスを設定で最適化し、ステータス監視機能を有効にする方法を説明します。

NGINX基本設定の調整

worker_processes：ワーカープロセス数。サーバのCPUコア数に近い値に設定します。ただし多すぎるとリソース競合を招くため注意が必要です。
worker_connections：単一ワーカープロセスが同時に処理可能な最大接続数。OSの最大ファイルディスクリプタ数を超えないように設定してください。

bash

worker_processes auto;

events {
 worker_connections 20480;
}

NGINXのマルチNIC対応による大量接続処理

リバースプロキシではNGINXがクライアントとしてバックエンドEMQXノードに接続します。この場合、単一IPアドレスで約6万の長時間接続が最大です。より多くの接続をサポートするには、複数のNGINXサーバを展開するか、複数IPアドレスを設定します。

以下はNGINX組み込みのsplit_clientsモジュールを使い、クライアントIPアドレスとポート番号に基づき変数$multi_ipを定義して複数IPに分散する例です。使用するIPはローカルで利用可能なものを指定してください。

bash

stream {
 split_clients "$remote_addr$remote_port" $multi_ip {
    20% 10.211.55.5;
    20% 10.211.55.20;
    20% 10.211.55.21;
    20% 10.211.55.22;
    * 10.211.55.23;
  }

  upstream mqtt_servers {
    server emqx1-cluster.emqx.io:1883;
    server emqx2-cluster.emqx.io:1883;
  }

  server {
    listen 1883;

    proxy_pass mqtt_servers;
    proxy_bind $multi_ip;
  }
}

NGINXステータス監視

NGINXのステータス監視を有効にするには、http_stub_status_moduleモジュールがインストールされている必要があります。インストール済みであれば、以下のようにNGINXのステータス監視を有効にできます。

bash

http {
  server {
    listen 8888;

    location /status {
      stub_status on;
      access_log off;
    }
  }
}

http://localhost:8888/status にアクセスするとステータス情報が取得できます。

bash

$ curl http://localhost:8888/status
Active connections: 12
server accepts handled requests
 25 25 60
Reading: 0 Writing: 1 Waiting: 1

付録：主なパラメータの説明

以下は例示した設定で使用される主なパラメータの説明です。これらはバックエンドMQTTサーバへの安定した接続や、NGINX経由でMQTT通信を暗号化・保護し、IoTアプリケーションの通信のプライバシーと整合性を確保するためのベストプラクティスに沿ったものです。

パラメータ名	説明
proxy_protocol	PROXYプロトコルを有効にし、NGINXが接続先にリクエストの先頭に追加のプロキシ情報を付加可能にします。これによりEMQXは実際のクライアントIPを取得できます。
proxy_pass	バックエンドMQTTサーバのアドレスを定義し、クライアントからの全リクエストをここに転送します。
proxy_connect_timeout	バックエンドMQTTサーバへの接続確立タイムアウト。指定時間内に接続できない場合、NGINXは接続を中止します。
proxy_timeout	バックエンドMQTTサーバの応答タイムアウト。指定時間内に応答がない場合、NGINXは接続を切断します。
proxy_buffer_size	バックエンドMQTTサーバから受信したデータを格納するバッファサイズ。大容量のデータストリームに対応するため十分なサイズを確保します。
tcp_nodelay	TCP_NODELAYオプションを有効にし、Nagleアルゴリズムを無効化します。これによりパケット送信のレイテンシを削減し、リアルタイムMQTT通信に有利です。
ssl_session_cache	共有SSLセッションキャッシュを設定。SSLセッションの状態を保存し、クライアント再接続時のハンドシェイク高速化に寄与します。`shared:SSL:10m`はキャッシュ名とサイズ（10MB）を指定。
ssl_session_timeout	SSLセッションのタイムアウトを10分に設定。再利用されないセッションはこの時間後に削除されます。
ssl_certificate	SSL証明書ファイルのパス。サーバの身元証明に使用します。
ssl_certificate_key	SSL証明書に対応する秘密鍵ファイルのパス。
ssl_protocols	許可するSSL/TLSプロトコルのバージョンを指定します。
ssl_ciphers	許可する暗号化アルゴリズム（暗号スイート）を設定。`HIGH:!aNULL:!MD5`は強力な暗号スイートを指定し、空の暗号スイートやMD5を除外します。
ssl_client_certificate	クライアント証明書の検証に使用する認証局（CA）証明書ファイルのパス。
ssl_verify_client	クライアント証明書検証を有効化。`on`に設定するとNGINXはクライアントに有効なSSL証明書の提示を要求します。
ssl_verify_depth	クライアント証明書検証の最大深度を設定。ここでは`1`で、クライアント証明書とCA証明書の1段階のみ検証します。

参考情報

EMQXはNGINXに関する豊富なリソースを提供しています。以下のリンクもご参照ください。

ブログ:

Kubernetes

EMQX Operator

EMQX クラスター管理

API リファレンス

パスワード認証

監視

アクセスコントロール

統合

管理

Prometheus との統合

OpenTelemetry との統合

エンドツーエンドトレース

プラグインカタログ

JT/T 808 ゲートウェイ

GB/T 32960 ゲートウェイ

Volcengine RTC

シナリオ

GPT-Realtime

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

特長とメリット ​

クイックスタート ​

NGINXのインストールと使用方法 ​

前提条件 ​

NGINXのインストール ​

必要な依存パッケージ ​

ソースコードのダウンロード ​

コンパイル設定 ​

コンパイル開始 ​

インストール ​

使い始め ​

NGINXのリバースプロキシおよびロードバランス設定 ​

MQTTのリバースプロキシ設定 ​

MQTT SSLのリバースプロキシ設定 ​

MQTT WebSocketのリバースプロキシ設定 ​

MQTT WebSocket SSLのリバースプロキシ設定 ​

ロードバランス戦略の設定 ​

ラウンドロビン ​

重み付きラウンドロビン ​

IPハッシュ ​

最小接続数 ​

NGINX Plusを用いたEMQXデプロイの最適化 ​

MQTTスティッキーセッションロードバランスの設定 ​

クライアントID置換機能の設定 ​

NGINXパフォーマンスの最適化と監視有効化 ​

NGINX基本設定の調整 ​

NGINXのマルチNIC対応による大量接続処理 ​

NGINXステータス監視 ​

付録：主なパラメータの説明 ​

参考情報 ​

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

特長とメリット

クイックスタート

NGINXのインストールと使用方法

前提条件

NGINXのインストール

必要な依存パッケージ

ソースコードのダウンロード

コンパイル設定

コンパイル開始

インストール

使い始め

NGINXのリバースプロキシおよびロードバランス設定

MQTTのリバースプロキシ設定

MQTT SSLのリバースプロキシ設定

MQTT WebSocketのリバースプロキシ設定

MQTT WebSocket SSLのリバースプロキシ設定

ロードバランス戦略の設定

ラウンドロビン

重み付きラウンドロビン

IPハッシュ

最小接続数

NGINX Plusを用いたEMQXデプロイの最適化

MQTTスティッキーセッションロードバランスの設定

クライアントID置換機能の設定

NGINXパフォーマンスの最適化と監視有効化

NGINX基本設定の調整

NGINXのマルチNIC対応による大量接続処理

NGINXステータス監視

付録：主なパラメータの説明

参考情報