Nginx Proxy Managerでプロキシサービス負荷分散を構成する方法

NginxProxyManager (NPM) は、Nginx をベースとした強力なリバースプロキシ管理ツールであり、その直感的な Web インターフェースで多くのユーザーに愛されています。NPM 自体は主に単一のバックエンドサービスのプロキシ管理に使用されますが、Nginx のカスタム設定機能を巧みに組み合わせることで、強力な負荷分散機能も実現できます。

この記事では、カスタム Nginx 設定ファイルの変更・追加と、NginxProxyManager のダッシュボードにある「Custom Nginx Configuration」設定を組み合わせて、プロキシサービスに負荷分散を設定する方法を詳しく説明します。ここでは、この方法に焦点を当て、他の実装方法には触れません。

## 1. 事前準備

設定を開始する前に、以下の準備が完了していることを確認してください。

*   **NginxProxyManager がインストールされ、正常に動作していること**：Docker または直接インストールで利用できます。
*   **複数のバックエンドサービスインスタンス**：同じサービスを提供するバックエンドサーバーが少なくとも 2 つ以上必要です（例：異なる IP またはポートで実行されている Web アプリケーションインスタンス）。
*   **NPM のデータディレクトリへのアクセス権**：NPM コンテナ内の `/data/nginx/` ディレクトリにアクセスできる必要があります。通常、Docker ボリュームのマウントで実現されます。

## 2. 方案のコア操作

この方案の核心的な考え方は以下の通りです。
1.  NPM のデータディレクトリ内に、1 つ以上の「アップストリームサーバーグループ」（`upstream`）を定義するカスタム Nginx 設定ファイルを作成します。
2.  NPM のプロキシホスト設定で、「Custom Nginx Configuration」オプションを利用して、リクエストをカスタムアップストリームサーバーグループにプロキシします。

### 2.1. カスタムアップストリームサーバー設定ファイルの作成

まず、NPM の Nginx 設定ディレクトリ内に、負荷分散のためのアップストリームサーバーグループを定義するカスタムファイルを作成する必要があります。

1.  **NPM データディレクトリへのアクセス**：
    通常、NPM の Nginx 設定は、Docker コンテナ内の `/etc/nginx/conf.d/` または `/data/nginx/` にあります。永続化と管理の容易さのため、NPM はカスタム設定を `/data/nginx/custom/` ディレクトリから読み込みます。

    NPM を Docker で実行している場合、ボリュームマウントでこのディレクトリにアクセスできます。例えば、NPM コンテナがローカルの `./npm_data` ディレクトリをコンテナ内の `/data` にマウントしている場合、`./npm_data/nginx/custom/` パス下にファイルを作成する必要があります。

2.  **設定ファイルの作成または変更**：
    `/data/nginx/custom/` ディレクトリ内に、例えば `http_upstream.conf` という名前の新しい `.conf` ファイルを作成します。

    ```bash
    # 例：ホストマシン上で、npm_data がマウントディレクトリの場合
    cd /path/to/your/npm_data/nginx/custom/
    touch http_upstream.conf
    ```

3.  **`http_upstream.conf` ファイルの編集**：
    お好みのテキストエディタで `http_upstream.conf` を開き、以下の内容を追加します。

    ```nginx
    # 'my_backend_servers' という名前のアップストリームサーバーグループを定義
    upstream server_cluster {
        # バックエンドサーバー 1：IP アドレスとポート、重み 5
        server 192.168.1.100:8080 weight=5 max_fails=3 fail_timeout=30s;
        # バックエンドサーバー 2：IP アドレスとポート、重み 3
        server 192.168.1.101:8080 weight=3 max_fails=3 fail_timeout=30s;
        # バックエンドサーバー 3：IP アドレスとポート、デフォルト重み 1
        server 192.168.1.102:8080;
        # 予備サーバー：すべてのプライマリサーバーが利用不可の場合、このサーバーにトラフィックが転送されます
        # server 192.168.1.103:8080 backup;
        # 利用不可としてマーク：一時的なメンテナンスによく使用されます
        # server 192.168.1.104:8080 down;

        # 負荷分散アルゴリズム（オプション、デフォルトはラウンドロビン）：
        # round-robin (デフォルト)
        # least_conn; # 最少接続数
        # ip_hash;    # クライアント IP に基づくハッシュ、セッションスティッキーを実現
        # hash $request_uri consistent; # URI に基づくハッシュ
    }

    # 他に負荷分散が必要なサービスがある場合は、さらに upstream ブロックを定義できます
    # upstream server_cluster {
    #     server 192.168.1.200:9000;
    #     server 192.168.1.201:9000;
    # }
    ```

    **パラメータの説明**：
    *   `upstream my_backend_servers { ... }`：`my_backend_servers` という名前のアップストリームサーバーグループを定義します。この名前は NPM のカスタム設定で使用されます。
    *   `server IP:PORT`：バックエンドサーバーの IP アドレスとポートを指定します。
    *   `weight=N`：サーバーの重みを設定します。重みが大きいほど、Nginx はそのサーバーに多くのリクエストを転送します。デフォルトの重みは 1 です。
    *   `max_fails=N`：`fail_timeout` の間に、Nginx がバックエンドサーバーとの通信に N 回失敗した場合、そのサーバーは利用不可と見なされます。デフォルトは 1 です。
    *   `fail_timeout=Ns`：N 秒間にサーバーの失敗回数が `max_fails` に達した場合、そのサーバーは利用不可とマークされ、`fail_timeout` 時間後に再度試行されます。デフォルトは 10 秒です。
    *   `backup`：サーバーを予備サーバーとしてマークします。すべての非 `backup` サーバーが利用不可になった場合にのみ、`backup` サーバーにリクエストが転送されます。
    *   `down`：サーバーを永続的に利用不可としてマークします。通常、特定のサーバーを一時的に無効にするために使用されます。
    *   **負荷分散アルゴリズム**：
        *   `round-robin` (デフォルト)：リクエストを順番に各サーバーにディストリビュートします。
        *   `least_conn`：現在接続数が最も少ないサーバーにリクエストを送信します。
        *   `ip_hash`：クライアント IP アドレスのハッシュ値に基づいてリクエストをサーバーにディストリビュートし、同じクライアントからのリクエストが常に同じサーバーに送信されるようにして、セッションスティッキーを実現します。

### 2.2. NginxProxyManager でプロキシホストを設定する

次に、NPM の Web インターフェースで新しいプロキシホストを作成し、「Custom Nginx Configuration」機能を利用して、定義済みのアップストリームサーバーグループを参照します。

1.  **NginxProxyManager にログイン**：
    NPM の Web インターフェースを開き、ログインします。

2.  **新しいプロキシホストを追加**：
    「Proxy Hosts」ページに移動し、「Add Proxy Host」をクリックします。

3.  **「Details」タブを入力**：
    *   **Domain Names**：このプロキシ経由でアクセスしたいサービスの名前を入力します（例：`myapp.example.com`）。
    *   **Scheme**：バックエンドサービスがリッスンしているプロトコルに応じて `http` または `https` を選択します。
    *   **Forward Hostname / IP**：**ここではプレースホルダーを入力するだけで十分です。例えば `127.0.0.1`。** 「Custom Nginx Configuration」で実際の転送先を上書きするため、ここの設定は有効になりませんが、NPM はこのフィールドの入力を必須とします。
    *   **Forward Port**：**同様にプレースホルダーを入力します。例えば `80`。**
    *   必要に応じて `Cache Assets`、`Block Common Exploits`、`Websockets Support` などのオプションにチェックを入れます。

4.  **「SSL」タブを設定**：
    ドメイン名と証明書の状況に応じて SSL 証明書を設定します。Let's Encrypt の自動申請を使用することをお勧めします。

5.  **「Advanced」を設定**：
    これは最も重要なステップです。Advanced タブで、`Custom Nginx Configuration` を見つけ、このテキストボックスに以下の Nginx 設定コードを入力します。

    ```nginx
    location / {
        proxy_pass http://server_cluster;
    
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
    ```

    **説明**：
    *   `proxy_pass http://my_backend_servers;`：このディレクティブは、このプロキシホストに到達するすべてのリクエストを、`my_backend_servers` という名前のアップストリームサーバーグループに転送するように Nginx に指示します。Nginx は、`http_upstream.conf` で定義した負荷分散アルゴリズムとサーバーリストに基づいてディストリビュートします。
    *   `proxy_set_header ...`：これらのディレクティブは HTTP リクエストヘッダーを設定し、バックエンドサーバーがクライアントの実際の IP アドレス、元のリクエストドメイン名、プロトコルなどの情報を正しく認識できるようにします。これは、ログ記録、セキュリティポリシー、および一部のアプリケーションの正常な動作に不可欠です。

6.  **プロキシホストを保存**：
    「Save」ボタンをクリックしてプロキシホストの設定を保存します。NPM は自動的に Nginx 設定を再読み込みし、変更を有効にします。

### 2.3. 負荷分散設定の検証

設定が完了したら、負荷分散が正常に機能していることを検証する必要があります。

1.  **ドメイン名にアクセス**：
    ブラウザで設定したドメイン名（例：`http://myapp.example.com` または `https://myapp.example.com`）にアクセスします。

2.  **バックエンドサーバーの応答を確認**：
    バックエンドサービスがそのサーバーの識別子（例：サーバー IP、ホスト名、またはユニークなページコンテンツ）を表示できる場合、ページを複数回リフレッシュして、リクエストが異なるバックエンドサーバーにディストリビュートされているかを確認します。

3.  **NginxProxyManager のログを確認**：
    NPM のログを確認し、設定エラーがないことを確認します。

4.  **バックエンドサーバーのログ**：
    バックエンドサーバーのアクセスログを確認し、リクエストが NginxProxyManager からのものであり、リクエストが異なるサーバーにディストリビュートされていることを確認します。

## 4. まとめと注意点

上記の手順により、NginxProxyManager でプロキシサービスの負荷分散を正常に設定できました。この方法は、NPM の管理インターフェースの利便性と、Nginx の低レベル設定の柔軟性を最大限に活用しています。

**注意点**：
*   **セッションスティッキー（Session Stickiness）**：アプリケーションがユーザーセッションを特定のバックエンドサーバーへの接続に維持する必要がある場合（例：ユーザーがログインした後、同じサーバーにアクセスする必要がある）、`ip_hash` 負荷分散アルゴリズムを使用するか、アプリケーションレベルでセッション共有（Redis の使用など）を実装する必要があるかもしれません。
*   **ヘルスチェック**：Nginx の `max_fails` と `fail_timeout` は基本的なヘルスチェック機能を提供します。特定の URL の応答内容をチェックするような、より高度なヘルスチェックが必要な場合は、他のツールやより複雑な Nginx 設定を組み合わせる必要があるかもしれません。
*   **設定の更新**：`http_upstream.conf` ファイルを変更した後、NPM は自動的に Nginx 設定を再読み込みしません。NPM の Web インターフェースに移動し、いずれかのプロキシホストを編集して保存する（実際には何も変更しない）必要があります。これにより、NPM はすべての Nginx 設定を再読み込みします。または、Docker を直接操作している場合は、NPM コンテナを再起動できます。

> 他に何か方案はありますか？