NGINXを使用したロード・バランシングの設定

NGINXのインストール

ロード・バランシングにNGINXを使用するには、まずソフトウェアをインストールし、環境を構成する必要があります。

各サーバーにnginxパッケージをインストールします。
```
sudo dnf install nginx
```
目的の構成によっては、さらにモジュールのインストールが必要になる場合があります。nginx-all-modulesメタパッケージは、すべてのパッケージをインストールします。パッケージ・マネージャで使用可能なモジュールの完全なリストを表示するには、次のコマンドを使用します。
```
sudo dnf search nginx-mod*
```
TCP/UDPロード・バランシングを実行する場合は、nginx-mod-streamモジュール・パッケージをインストールする必要があります。
NGINXで処理するサービスまたはポートへのアクセスを有効にします。

たとえば、次のように、ポート80で着信TCPリクエストを受け入れます。
```
sudo firewall-cmd --zone=zone --add-port=80/tcp
```
```
sudo firewall-cmd --permanent --zone=zone --add-port=80/tcp
```
SELinuxがシステムで強制モードに設定されている場合、NGINXが構成済のバックエンド・サーバーにHTTPトラフィックをリレーできるようにするルールを追加します。
```
sudo setsebool httpd_can_network_relay on
```
サーバーでnginxサービスを有効にして起動します。
```
sudo systemctl enable --now nginx
```
NGINX構成を変更した場合は、nginxサービスを再ロードします。
```
sudo systemctl reload nginx
```

NGINX構成ディレクティブ

NGINX構成は複数のファイルにまたがり、異なる構成ディレクティブを指定して構成変数の値を設定できます。構成は/etc/nginxに格納されます。基本構成は/etc/nginx/nginx.confに格納されますが、サイト固有の構成は/etc/nginx/conf.d/の個別のファイル内に作成される傾向があります。通常、サイト構成では、ファイル名に完全なドメイン名を使用する傾向があり、.conf接尾辞が必要です。

これらの例では、構成には次の一般的な形式があります。

http {
  server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    location / {
       root /usr/share/nginx/html/example.com;
       index index.html;
    }
  }
}

前述の例は、Webルート・ディレクトリ/usr/share/nginx/html/example.comのコンテンツを提供するWebサーバーのHTTPサーバー構成を示しています。

次の構成ディレクティブは、ロード・バランシングの構成に便利です。

http, https, stream

設定を適用するプロトコルを定義します。ロード・バランサへのTLS接続にはhttpsを使用し、一般的なTCP/UDPトラフィックにはstreamを使用します。

server

選択したプロトコルに対して指定したポートからの受信トラフィックを処理する方法を定義します。

IPv4用に少なくとも1つのリスニング・ポートを構成するには、listenキーワードを使用します。

listen 80;

IPv6インタフェースでリスニングするには、ポート番号の前に[::]:ディレクティブを追加します。次に例を示します。

listen [::]:80

listen行を複製して、server{}ブロックに複数のポートを指定できます。

server_nameキーワードを使用して、サーバーが応答するホスト名またはドメイン名を定義します。この値を指定しない場合、構成は受信接続に適用されますが、構成定義が競合しないように、/etc/nginx/nginx.conf内のデフォルト・サーバー構成をコメント・アウトする必要がある場合があります。

location

locationディレクティブは、サーバー上の受信リクエストに応じてパス・マッピングおよび動作を定義します。少なくとも、値/で示されるWebルートの値が必要です。この動作は、場所ブロック内で値を設定することによって定義されます。

たとえば、サーバー上のディレクトリのコンテンツを提供する単純なWebサーバーを構成するには、rootキーワードを使用して、コンテンツがあるディレクトリを指定します。

proxy_passディレクティブは、リバース・プロキシ・サービスの実装に使用できます。トラフィックは、アップストリーム・ディレクティブで定義されているように、指定されたサーバーまたはサーバー・グループにプロキシ設定されます。

たとえば、次のように、ポート9090のwebsrv1.example.comでホストされているWebサイトにインバウンドHTTPトラフィックをプロキシ設定します。

server {
  location / {
    proxy_pass http://websvr1.example.com:9090
  }
}

また、定義されたupstream名を参照して、サーバー・グループを指定することもできます。

upstream

upstreamディレクティブは、コンテンツが格納され、proxy_passディレクティブで使用できる1つ以上のサーバーのグループを定義するために使用されます。たとえば、backendというサーバーのアップストリーム・グループを次のように作成できます。

upstream backend {
    server server1.example.com;
    server server2.example.com;
    server server3.example.com;
  }

このグループを使用するには、proxy_passディレクティブを指定します。

proxy_pass http://backend

アップストリーム・ディレクティブは、ロード・バランシングの方法およびアルゴリズムの制御に使用される主要な構成コンポーネントです。詳細は、http://nginx.org/en/docs/http/ngx_http_upstream_module.htmlを参照してください。

NGINXを使用したラウンド・ロビン・ロード・バランシングの構成

NGINXで使用されるデフォルトのロード・バランシングの方法は、ラウンド・ロビン方式です。この方法は、定義されたグループ内の各サーバーにトラフィックを順番にプロキシ設定します。

/etc/nginx/conf.d/example.com.confでロード・バランサの構成ファイルを作成します。example.comは、インバウンド・トラフィックが送られる外部ドメインの名前です。このファイルには次の内容が含まれています。

http
{
  upstream backend {
    server server1.example.com;
    server server2.example.com;
    server server3.example.com;
  }

  server {
    listen 80;
    server_name example.com
                  www.example.com;
    location / {
      proxy_pass  http://backend;
    }
  }
}

upstream backend構成ブロックで、環境内のバックエンド・サーバーをリストします。たとえば、server1.example.comを、完全修飾ドメイン名またはWebサーバー・インスタンスのホスト名に置き換えます。

ロード・バランシングされたサービスでパブリックに使用するドメイン名を使用して、server_nameディレクティブを設定します。たとえば、会社のドメインに一致するようにexample.comとwww.example.comを置き換えます。

必要に応じて、各エントリの末尾にmax_failsやfail_timeoutなどのフェイルオーバー・オプションを追加して、いずれかのサーバーがオフラインになった場合に自己回復性を追加できます。

構成が有効であることを確認したら、パブリック対応サーバーおよびバックエンド・サーバーでNGINXを再ロードして有効にします。

sudo systemctl reload nginx

重み付けラウンド・ロビン・ロード・バランシングとNGINXの使用

物理的な場所が異なるサーバーやハードウェア・リソースが異なるサーバーを使用する場合は、レイテンシが少なく、より多くの負荷を処理できるサーバーにより多くのトラフィックを割り当てるようにNGINXを構成できます。この方法は、重み付けラウンド・ロビン方式と呼ばれます。

重み付けラウンド・ロビン構成は、NGINXサイト構成ファイルのサーバー・グループ・セクションの各エントリの最後にweight値を追加することで構成できます。最も遅いサーバーの重みを1に設定し、その設定と比較して他のサーバーの重みを設定します。

次の例に、サーバーがベース・サーバーの負荷を複数回処理する方法を示します。あるサーバーは2倍の量のトラフィックを受信し、別のサーバーは4倍の量のトラフィックを受信します。

upstream backend {
    server server1.example.com weight=1;
    server server2.example.com weight=2;
    server server3.example.com weight=4;
}

NGINXを再ロードして新しい構成を適用します。

sudo systemctl reload nginx

最少接続ロード・バランシングとNGINXの使用

最少接続のロード・バランシング方式は、アプリケーション・インスタンスの負荷を自動的に制御するために使用されます。ここでは、主に、他のリクエストよりも異なるインバウンド・リクエストの処理に時間がかかる場合があります。

最少接続のロード・バランシング方式を使用している場合、NGINXは常に、アクティブなリクエスト数が最も少ないサーバーに新しい受信リクエストを送ります。このロード・バランシング戦略は、ビジー状態のサーバーを新しいリクエストで過負荷にならないようにし、負荷を処理できる他のサーバーをアイドル状態のままにすることを目的としています。

サーバー・グループ構成の一部としてleast-connディレクティブを指定することで、NGINXの最少接続のロード・バランシング方式をアクティブ化できます。次に例を示します。

upstream backend {
    least_conn;
    server server1.example.com;
    server server2.example.com;
    server server3.example.com;
}

NGINXを再ロードして新しい構成を適用します。

sudo systemctl reload nginx

NGINXのセッション永続性の追加

Webアプリケーションのロード・バランシングを実行する場合、インバウンド・リクエストを処理する同じバックエンド・サーバーが同じソースに対して引き続き実行されるようにします。この構成は、WebサイトまたはWebサービスでリクエスト間のログイン・セッションを保持したり、既存のリクエストを取り消したり、大規模なバックエンド・トランザクションの進行状況を監視する必要がある場合に重要です。

この動作を実現するには、サーバー・グループ構成の一部としてip_hashディレクティブを指定して、NGINXのIPハッシュ方式をアクティブ化します。次に例を示します。

upstream backend {
    ip_hash;
    server server1.example.com;
    server server2.example.com;
    server server3.example.com;
}

NGINXを再ロードして新しい構成を適用します。

sudo systemctl reload nginx