F5 NGINX PLUS

F5 NGINX Plus: ロード バランシング

サーバ、クライアント、プロキシ間でのネットワーク トラフィックの分散は、お客様の満足度を高め、インフラストラクチャを最適化する上で重要です。NGINX Plusの高パフォーマンスのロード バランシングにより、スケールアウトして冗長性を確保し、再始動を必要とせずにインフラストラクチャを動的に再設定し、Global Server Load Balancing (GSLB)、セッション パーシステンス、アクティブ ヘルス チェックを利用できます。NGINX PlusはHTTPトラフィックの他に、TCP、UDP、gRPCのロードバランシングも行います。

NGINXとNGINX Plusのロードバランシングによりアプリケーションをスケールアウト
NGINXとNGINX Plusのロードバランシングによりアプリケーションをスケールアウト

HTTPロードバランシング

NGINX PlusはHTTPトラフィックのロードバランシング時に、各HTTP接続を終了し、各リクエストを別個に処理します。SSL/TLS暗号化を解除し、リクエストを検査して操作し、レート制限を使用してリクエストをキューに入れ、ロード バランシング ポリシーを選択することができます。

パフォーマンスを強化するために、NGINX Plusではさまざまな最適化をHTTPトランザクションに自動的に適用できます。最適化には、HTTPプロトコルのアップグレード、keepaliveの最適化、変換(コンテンツ圧縮や応答キャッシュなど)などがあります。

NGINX PlusではHTTPトラフィックのロード バランシングも簡単にできます。

http {
    upstream my_upstream {
        server server1.example.com;
        server server2.example.com;
    }

    server {
        listen 80;
        location / {
            proxy_set_header Host $host;
            proxy_pass http://my_upstream;
        }
    }
}

最初にserverディレクティブを使用して仮想サーバを指定し、次にトラフィックをlistenするポートを指定します。locationブロックを使用してクライアント リクエストのURLを照合し、proxy_set_headerディレクティブを使用してHostヘッダを設定し、リクエストをアップストリーム グループに転送するためにproxy_passディレクティブを組み込みます(upstreamブロックにより、NGINX Plusがトラフィックのロードバランシングを行うサーバが定義されます)。

詳しくは、NGINXとNGINX Plusを使用したロード バランシングの概要をご覧ください。

TCPおよびUDPのロード バランシング

NGINX Plusでは、MySQLなどのTCPアプリケーションと、DNSやRADIUSなどのUDPアプリケーションのロード バランシングも実行できます。TCPアプリケーションの場合、NGINX PlusはTCP接続を終了してからバックエンドへの新しい接続を作成します。

stream {
    upstream my_upstream {
        server server1.example.com:1234;
        server server2.example.com:2345;
    }

    server {
        listen 1123 [udp];
        proxy_pass my_upstream;
    }
}

この設定はHTTPの設定に似ています。serverディレクティブを使用して仮想サーバを指定し、ポートでトラフィックをlistenし、リクエストをupstreamグループに転送(proxy_pass)します。

TCPとUDPのロード バランシングについて詳しくは、NGINX Plus Admin Guideをご覧ください。

ロード バランシング方式

NGINX Plusでは、HTTP、TCP、UDPロード バランシングのためのさまざまなアプリケーション ロード バランシング手法がサポートされています。すべての手法では、必要に応じて各アップストリーム サーバに割り当てることができるweightが考慮されています。

  • ラウンド ロビン(デフォルト) – リクエストをアップストリーム サーバ間で順に分散します。
  • 最小接続数 – アクティブな接続の数が最も少ないサーバにリクエストを転送します。
  • 最短時間 – 応答時間とアクティブな接続の数を組み合わせた計算に基づいて、負荷が最も少ないサーバにリクエストを転送します。NGINX Plusでのみ利用できます。
  • ハッシュ – 指定されたキー(クライアントのIPアドレス、リクエストURLなど)に基づいてリクエストを分散します。NGINX Plusではオプションで、アップストリーム サーバのセットが変更される場合の負荷の再分散を最小限に抑えるため、必要に応じてコンシステント ハッシュを適用できます。
  • IPハッシュ(HTTPのみ) – クライアントIPアドレスの最初の3つのオクテットに基づいてリクエストを分散します。
  • ランダムな2択 – 2つのサーバをランダムに選択し、アクティブな接続の数が少ないサーバにリクエストを送信します(最小接続数方式)。NGINX Plusでは最小接続数方式も使用できます。

NGINX Plusでの接続の制限

NGINX PlusとアップストリームのHTTPサーバまたはTCPサーバの間で確立される接続の数、またはUDPサーバとのセッションの数を制限できます。サーバとの接続またはセッションの数が、定義されている制限を超えると、NGINX Plusは新しい接続またはセッションの確立を停止します。

以下の設定スニペットでは、webserver1の接続制限は250、webserver2の接続制限は150です。queueディレクティブで、NGINX Plusがオペレーティング システムのlistenキューに最大30秒間格納する超過接続の最大数を指定します。この数を超えるリクエストはドロップされます。

upstream backend {
    zone backends 64k;
    queue 750 timeout=30s;

    server webserver1 max_conns=250;
    server webserver2 max_conns=150;
}

サーバのアクティブな接続の数がこの制限を下回ると、NGINX Plusはキューからサーバに接続を送信します。トラフィックが急増する状況でも、接続制限により、クライアント リクエストが一貫して予測可能な方法で処理されるようになります。

セッション パーシステンス

ユーザ セッションを識別して1つのセッション内のすべてのリクエストを同一のアップストリーム サーバに送信するようにNGINX Plusを設定できます。これは、アプリケーション サーバに状態がローカルに保存される場合に重要です。進行中のユーザ セッションが別のサーバに送信されると致命的なエラーが発生するからです。セッション パーシステンスにより、1つのクラスタ内でアプリケーションが情報を共有することになり、パフォーマンスが向上する可能性があります。

NGINX Open Sourceでサポートされているハッシュベースのセッション パーシステンス(ハッシュおよびIPハッシュのロード バランシング方式を参照)の他に、NGINX PlusではCookieベースのセッション パーシステンス(sticky cookieなど)もサポートされています。NGINX Plusはアップストリーム グループから特定のクライアントへの最初の応答にセッションCookieを追加し、応答を生成したサーバを確実に識別します。後続のクライアント リクエストにはこのCookieが含まれ、NGINX PlusはこのCookieを使用してリクエストを同じアップストリーム サーバにルーティングします。

upstream backend {
    server webserver1;
    server webserver2;

    sticky cookie srv_id expires=1h domain=.example.com path=/;
}

上記の例では、NGINX Plusは、リクエストを処理したサーバを示すsrv_idというCookieを最初のクライアント応答に挿入します。後続のリクエストに同じCookieが含まれている場合、NGINX Plusはそのリクエストを同じサーバに転送します。

NGINX Plusではスティッキー ラーンとスティッキー ルート パーシステンス方式もサポートされています。

注: Cookieベースのセッション パーシステンスは、NGINX Plusでのみ利用できます。

アクティブ ヘルス チェック

デフォルトではNGINXはアップストリーム サーバからの応答に対して基本的なチェックを実行し、可能であれば失敗したリクエストを再試行します。NGINX Plusでは、アウトオブバンド アプリケーション稼働状況チェック(合成トランザクションとも呼ばれます)と、新しいサーバや復元されたサーバをロード バランシングされたグループにグレースフルに追加するスロースタート機能が追加されています。

これらの機能により、NGINX Plusはさまざまな問題を検出、回避できるため、HTTPアプリケーションとTCP/UDPアプリケーションの信頼性が大きく向上します。

upstream my_upstream {
	zone my_upstream 64k;
	server server1.example.com slow_start=30s;
}

server {
    # ...
    location /health {
        internal;
        health_check interval=5s uri=/test.php match=statusok;
        proxy_set_header Host www.example.com;
        proxy_pass http://my_upstream
    }
}

match statusok {
    # Used for /test.php health check
    status 200;
    header Content-Type = text/html;
    body ~ "Server[0-9]+ is alive";
}

上記の例ではNGINX Plusが/test.phpのリクエストを5秒間隔で送信します。matchブロックで、アップストリーム サーバが正常であると判断されるために応答が満たす必要がある条件(ステータス コード200 OKと、応答本文にServerN is aliveというテキストが含まれていること)が定義されます。

注: アクティブ ヘルス チェックはNGINX Plusでのみ利用できます。

DNSを使用したサービス検出

デフォルトでは、NGINX Plusサーバは開始時にDNS名を解決し、解決した値を永続的にキャッシュします。serverディレクティブとresolveパラメータでアップストリーム サーバのグループを識別するときにexample.comのようなドメイン名を使用すると、NGINX Plusは定期的にドメイン名の解決を繰り返します。関連付けられているIPアドレスのリストが変更されると、NGINX Plusは即時に変更後のサーバ グループでロード バランスを開始します。

DNS SRVレコードを使用するようにNGINX Plusを設定するには、resolverディレクティブと、server ディレクティブのservice=httpパラメータを以下のように指定します。

resolver 127.0.0.11 valid=10s;

upstream service1 {
    zone service1 64k;
    server service1 service=http resolve;
}

上記の例では、NGINX Plusがドメイン名service1の解決を再試行するために127.0.0.11 (組み込みDocker DNSサーバ)に対するクエリを10秒間隔で実行します。

注: DNSを使用したサービス検出は、NGINX Plusでのみ利用できます。

NGINX Plus API

NGINX Plusには、1つのAPIエンドポイントを持つRESTful APIが含まれています。NGINX Plus APIを使用すれば、アップストリーム設定やキー値ストアの更新をダウンタイムなしで実行中に行うことができます。

以下の設定スニペットでは、/apiエンドポイントへの読み取り/書き込みアクセスを有効にするapiディレクティブが指定されています。

upstream backend {
    zone backends 64k;
    server 10.10.10.2:220 max_conns=250;
    server 10.10.10.4:220 max_conns=150;
}

server {
    listen 80;
    server_name www.example.org;

    location /api {
        api write=on;
    }
}

上記の例のようにAPIを有効にすると、次のcurlコマンドを使用して既存のアップストリーム グループに新しいサーバを追加できます。このコマンドはPOSTメソッドとJSONエンコーディングを使用してサーバのIPアドレスを192.168.78.66に設定し、そのweightを200に設定し、同時接続の最大数を150に設定します(versionは、参照ドキュメントに指定されているようにAPIの現行のバージョン番号に置き換えます)。

$ curl -iX POST -d '{"server":"192.168.78.66:80","weight":"200","max_conns":"150"}' http://localhost:80/api/version/http/upstreams/backend/servers/

すべてのbackendアップストリーム サーバの完全な設定をJSON形式で表示するには、次のコマンドを実行します。

$ curl -s http://localhost:80/api/version/http/upstreams/backend/servers/ | python -m json.tool
	{
      "backup": false,
      "down": false,
      "fail_timeout": "10s",
      "id": 0,
      "max_conns": 250,
      "max_fails": 1,
      "route": "",
      "server": "10.10.10.2:220",
      "slow_start": "0s",
      "weight": 1
      },
      {
      "backup": false,
      "down": false,
      "fail_timeout": "10s",
      "id": 1,
      "max_conns": 150,
      "max_fails": 1,
      "route": "",
      "server": "10.10.10.4:220",
      "slow_start": "0s",
      "weight": 1
      },
      {
      "backup": false,
      "down": false,
      "fail_timeout": "10s",
      "id": 2,
      "max_conns": 200,
      "max_fails": 1,
      "route": "",
      "server": "192.168.78.66:80",
      "slow_start": "0s",
      "weight": 200
      }

既存のアップストリーム サーバの設定を変更するには、内部IDを使用してサーバを指定します。内部IDは上記の出力のidフィールドに示されています。次のコマンドではPATCHメソッドを使用してサーバをID 2で再設定し、サーバのIPアドレスを設定し、ポートで192.168.78.55:80をリッスンし、weightを500に設定し、接続制限を350に設定します。

$ curl -iX PATCH -d '{"server":"192.168.78.55:80","weight":"500","max_conns":"350"}' http://localhost:80/api/version/http/upstreams/backend/servers/2

NGINX Plus APIのSwagger (OpenAPI仕様)ドキュメント全体にはhttps://demo.nginx.com/swagger-ui/からアクセスできます。

注: NGINX Plus APIはNGINX Plusでのみ利用できます。

次のステップ