NGINX Plusサイジングガイド：テスト方法

NGINX | 2016年11月29日

今年初めにNGINX Plusのパフォーマンスをベンチマークし、ベアメタルサーバーへの導入に向けたサイジングガイドを作成しました。NGINX Open SourceとNGINX Plusは、レイヤー7ロードバランシング（別名：アプリケーションロードバランシング）に広く使用されています。

［編集者 – NGINX Plusの機能、およびハードウェアのコストとパフォーマンスの変化を反映するため、サイジングガイドを定期的に更新しています。上記のリンクから、常に最新版のガイドをご覧いただけます。

WebサーバーとしてのNGINXおよびNGINX Plusのパフォーマンスについては、「NGINXおよびNGINX Plus Webサーバーのパフォーマンステスト」を参照してください。]

サイジングガイドでは、さまざまなサイズのサーバーでNGINX Plusを実行した場合に期待できるパフォーマンスと、ハードウェアの推定コストについて説明しています。このガイドを使用すると、NGINX Plusの導入環境に適した仕様を策定し、すぐに余分なコストが発生する過剰なプロビジョニングや、パフォーマンス上の問題を引き起こして長期的なコスト増につながる可能性があるプロビジョニング不足を、可能な限り回避できます。

サイジングガイドには大きな関心が寄せられており、お客さまをはじめ、F5の結果を再現したいと考える方々から、使用した手法について多くの質問をいただいています。このブログ記事では、サイジングガイドに掲載した結果を得るために実施したテストの概要を紹介します。使用したトポロジー、実施したテスト、サイジングガイドに掲載した価格の調査方法について説明します。

注記：このサイジングガイドはNGINX Plus向けに作成しましたが、NGINX Plusのサブスクリプションがなくても誰でもテストを再現できるよう、テストにはNGINX Open Sourceを使用しました。このテストではNGINX Plusの拡張機能を使用していないため、NGINX Open SourceとNGINX Plusの結果は同じです。NGINX Open Sourceバージョン1.9.7は、おおむね相当しますNGINX Plus Release 7に。

ただし、テストトポロジーにおいてリバースプロキシとバックエンドWebサーバーを明確に区別するため、前者をNGINX Plus、後者をNGINX (Open Source)と表記します。

トポロジー

すべてのテストは、シンプルなフラット構成のレイヤー2ネットワーク上で、2本の40 GbEリンクを介して相互接続した3台の独立したマシンを使用して実施しました。

NGINX Plusのパフォーマンステストには、標準的なバックツーバックツーバック構成を使用しました

クライアントマシンからトラフィックを生成するために、wrk（ab（ApacheBench）に類似したパフォーマンステストツール）を使用しました。図に示すように、すべてのトラフィックはNGINX Plusのリバースプロキシに送信され、そこからNGINX Open SourceのWebサーバーバックエンドに接続が転送されました。

使用したハードウェア

テストには、以下のハードウェアを使用しました。

マシン CPU ネットワークメモリクライアント 2x Intel(R) Xeon(R) CPU E5‑2699 v3 @ 2.30GHz、36物理コア（または72 HTコア） 2x Intel XL710 40GbE QSFP+ (rev 01) 16 GBリバースプロキシ 2x Intel(R) Xeon(R) CPU E5‑2699 v3 @ 2.30GHz、36物理コア（または72 HTコア） 4x Intel XL710 40GbE QSFP+ (rev 01) 16 GBWebサーバー 2x Intel(R) Xeon(R) CPU E5‑2699 v3 @ 2.30GHz、36物理コア（または72 HTコア） 2x Intel XL710 40GbE QSFP+ (rev 01) 16 GB

使用ソフトウェア

テストには、以下のソフトウェアを使用しました。

クライアントマシンで実行したバージョン4.0.0の「wrk」を使用して、NGINXがプロキシするトラフィックを生成しました。インストールには、こちらの「手順」を使用しました。
NGINX Open Sourceバージョン1.9.7は、リバースプロキシマシンとWebサーバーマシンで稼働しました。こちらのnginx.orgの公式リポジトリから、以下の手順に従ってインストールしました。
Ubuntu Linux 14.04.1は、3台すべてのマシンで稼働していました。

テスト方法

CPU数を変えて、NGINX Plusリバースプロキシサーバーのパフォーマンスをテストしました。NGINX Plusのworkerプロセスは1つのCPUを使用するため、CPU数ごとのパフォーマンスを測定する目的でworkerプロセス数を変更し、workerプロセスを2、4、8と増やしながらテストを繰り返しました。NGINXアーキテクチャの概要については、F5のブログをご覧ください。

注記：workerプロセスの数を手動で設定するには、worker_processesディレクティブを使用します。デフォルト値はautoです。この値を指定すると、NGINX PlusはCPUの数を検出し、CPUごとに1つのworkerプロセスを実行します。

パフォーマンス指標

以下の指標を測定しました。

1秒あたりのリクエスト数（RPS） – HTTPリクエストの処理能力を測定します。テストでは、各クライアントがキープアライブ接続を介して1 KBのファイルをリクエストします。リバースプロキシは各リクエストを処理し、別のキープアライブ接続を介してWebサーバーに転送します。
1秒あたりのSSL/TLSトランザクション数（TPS） – 新しいSSL/TLS接続を処理する能力を測定します。テストでは、各クライアントが一連のHTTPSリクエストを送信し、リクエストごとに新しい接続を使用します。リバースプロキシはリクエストを解析し、確立済みのキープアライブ接続を介してWebサーバーに転送します。Webサーバーは各リクエストに対して0バイトのレスポンスを返します。
スループット – NGINX PlusがHTTP経由で1 MBのファイルを配信する際に維持できるスループットを測定します。

テストの実行

すべてのクライアントトラフィックの生成には、wrkを以下のオプションで使用しました。

The -cオプションでは、作成するTCP接続数を指定します。今回のテストでは、50 接続に設定しました。
The -dオプションでは、トラフィックを生成する時間を指定します。各テストは3分間実行しました。
The -tオプションでは、作成するスレッド数を指定します。テストでは、スレッドを1つに指定しました。

各CPUの性能を最大限に引き出すため、単一のtasksetプロセスを1つのCPUに固定できるwrkを使用しました。この方法では、wrkのスレッド数を増やすよりも一貫性の高い結果が得られます。

1秒あたりのリクエスト数

1秒あたりのリクエスト数（RPS）を測定するため、次のスクリプトを実行しました。

for i in `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; do    taskset -c $i wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address/1kb.bin &
done

このテストでは、CPUごとにwrkを1つずつ、クライアントマシン上で合計36個起動しました。各プロセスは50個のTCP接続を確立し、それらの接続を介して1 KBのファイルを3分間（180秒）継続的にリクエストしました。

1秒あたりのSSL/TLSトランザクション数

1秒あたりのSSL/TLSトランザクション数（TPS）を測定するため、次のスクリプトを実行しました。

for i in `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; do    taskset -c $i wrk -t 1 -c 50 -d 180s -H 'Connection: close' https://Reverse-Proxy-Server-IP-address/0kb.bin &
done

このテストでは、-c、-d、-tに前のテストと同じ値を使用しますが、SSL/TLS接続の処理に重点を置いているため、次の2つの重要な点が異なります。

クライアントはリクエストごとに接続を確立して切断します（-Hオプションにより、Connection: close HTTPヘッダーが設定されます）。
リクエストされたファイルのサイズは1 KBではなく0（ゼロ）バイトです。

スループット

スループットを測定するため、次のスクリプトを実行しました。

for i in `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; do    taskset -c $i wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address/1mb.bin &
done

最初のテストとの唯一の違いは、ファイルサイズを1 MBに増やした点です。さらに大きなファイルサイズ（10 MB）を使用しても、全体的なスループットは向上しないことがわかりました。

複数のネットワークカード

テストでは複数のネットワークカードを使用しました。次のようにスクリプトを若干変更することで、2枚のカードにトラフィックが均等に分散されるようにしました。

for i in `seq 0 $((($(getconf _NPROCESSORS_ONLN) - 1)/2))`; do    n=`echo $(($i+number-of-CPUs/2))`;
    taskset -c $i ./wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address-1/1kb.bin &
    taskset -c $n ./wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address-2/1kb.bin &
done

価格

コア数ごとのパフォーマンス値を取得した後、最後に、対応する仕様のサーバーのコストを算出しました。テストで使用したIntelハードウェアと同等の仕様を持つDell PowerEdgeサーバーの価格を使用しています。以下の付録には、各サーバーの完全な部品表に加え、リバースプロキシとWebサーバーの両方について、完全なNGINX構成を掲載しています。

付録

Dellハードウェア構成

サイジングガイドに記載されている価格は、以下のDellハードウェア構成を対象としています。

注記：記載されている仕様と価格のサーバーモデルは、テスト実施時点では入手可能でしたが、今後変更される可能性があります。

サーバーモデル仕様価格Dell PowerEdge R230 CPU：2コア Intel Core I3 6100 3.7GHz、2C/4T
RAM：4 GB
HDD：500 GB
NIC：Intel X710 2×10 Gbe $1,200CPU：Intel® Xeon® E3‑1220 v5 3.0GHz、4C/8T
RAM：4 GB
HDD：500 GB
NIC：Intel XL710 2×40 Gbe $1,400Dell PowerEdge R430 CPU：Intel® Xeon® E5‑2630 v3 2.4GHz、8C/16T
RAM：4 GB
HDD：500 GB
NIC：Intel XL710 2×40 Gbe $2,200CPU：2x Intel® Xeon® E5‑2630 v3 2.4GHz、8C/16T
RAM：8 GB
HDD：500 GB
NIC：Intel XL710 2×40 Gbe $3,000Dell PowerEdge R630 CPU：2x Intel® Xeon® E5‑2697A v4 2.6GHz、16C/32T
RAM：8 GB
HDD：500 GB
NIC：Intel XL710 2×40 Gbe $8,000CPU：2x Intel® Xeon® E5‑2699 v3 2.3GHz、18C/36T
RAM：8 GB
HDD：500 GB
NIC：Intel XL710 2×40 Gbe $11,000

NGINX Plusリバースプロキシ設定

NGINX Plusのリバースプロキシでは、次の設定を使用しました。keepalive_timeoutディレクティブとkeepalive_requestsディレクティブがそれぞれ2組あることに注意してください。

SSL/TLS TPSテストでは、NGINX Plusが1秒あたりに処理できるSSL/TLS接続数を測定することが目的であるため、接続が1つのリクエストの間だけ維持されるように、両方のディレクティブの値を設定しました。また、SSL/TLSセッションキャッシュも無効にしました。
RPSテストでは、接続が可能な限り長く維持されるように、各ディレクティブを調整しました。

それ以外はごく標準的なリバースプロキシサーバー構成で、NGINX Plusはproxy_passディレクティブを使用してWebサーバーにプロキシします。

user                 nginx;worker_processes     auto;
worker_rlimit_nofile 10240;
pid                  /var/run/nginx.pid;

events {
    worker_connections 10240;
    accept_mutex       off;
    multi_accept       off;
}

http {
    access_log    off;
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for" "$ssl_cipher" '
                    '"$ssl_protocol" ';

    sendfile on;

    # RPS tests
    keepalive_timeout  300s;     
    keepalive_requests 1000000;

    # SSL/TLS TPS tests
    #keepalive_timeout  0;  
    #keepalive_requests 1; 
  
    upstream webserver {
        server Web-Server-IP-address;
    }

    server {
        listen 80;
        listen 443 ssl backlog=102400 reuseport;

        ssl_certificate     /etc/nginx/ssl/rsa-cert.crt;
        ssl_certificate_key /etc/nginx/ssl/rsa-key.key;
        ssl_session_tickets off;
        ssl_session_cache   off;

        root /var/www/html;
            location / {
                proxy_pass http://webserver;
            }
        }
    }
}

NGINX Webサーバーの設定

以下の設定は、NGINXのWeb Serverで使用したものです。/var/www/html/から静的ファイルを配信するよう、rootディレクティブで設定しています。静的ファイルはddを使用して生成しました。この例では、内容がすべてゼロの1 KBファイルを作成します。

dd if=/dev/zero of=1kb.bin bs=1KB count=1

設定内容：

user                 nginx;
worker_processes     auto;
worker_rlimit_nofile 10240;
pid                  /var/run/nginx.pid;

events {
    worker_connections 10240;
    accept_mutex       off;
    multi_accept       off;
}

http {
    access_log   off;
    include      /etc/nginx/mime.types;
    default_type application/octet-stream;

    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for" "$ssl_cipher" '
                    '"$ssl_protocol" ';

    sendfile on;

    keepalive_timeout  300s;     
    keepalive_requests 1000000;

    server {
        listen 80;
        root /var/www/html;
    }
}