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

今年初めにNGINX Plusのパフォーマンスをベンチマークし、 サイズガイド ベアメタル サーバーに展開する場合。 NGINX Open Source と NGINX Plus は、アプリケーション ロード バランシングとも呼ばれるレイヤー 7 ロード バランシングに広く使用されています。

[編集者– NGINX Plus の機能とハードウェアのコストおよびパフォーマンスの変更を反映するために、サイジング ガイドを定期的に更新します。 上記のリンクは常に最新のガイドへのリンクです。

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

サイジング ガイドでは、さまざまなサーバー サイズで NGINX Plus を実行した場合に期待できるパフォーマンスと、ハードウェアの推定コストについて説明します。 サイジング ガイドを使用すると、NGINX Plus のデプロイメントを適切に指定し、すぐにコストがかかる過剰なプロビジョニングや、パフォーマンスの問題が発生し、長期的にはコストがかかる不足のプロビジョニングを可能な限り回避できます。

お客様や、私たちの結果を再現することに関心のある方々から、サイズガイドへの関心や、使用した方法論に関する質問が数多く寄せられています。 このブログ投稿では、サイズ設定ガイドに示されている結果を達成するために実行したテストの概要を説明します。 使用したトポロジ、実行したテスト、サイズガイドに記載されている価格の算出方法について説明します。

注記： 私たちは NGINX Plus 専用のサイジング ガイドを開発しましたが、NGINX Plus サブスクリプションがなくても誰でもテストを再現できるように、テストには NGINX Open Source を使用しました。 テストでは NGINX Plus の拡張機能は使用されない為、NGINX Open Source と NGINX Plus の結果は同じになります。 NGINX オープンソース バージョン 1.9.7 は、NGINX Plus リリース 7 にほぼ相当します。

ただし、テスト トポロジでリバース プロキシとバックエンド Web サーバーをより適切に区別するために、前者については NGINX Plus、後者については NGINX (オープン ソース) と呼びます。

トポロジー

すべてのテストは、シンプルでフラットなレイヤー 2 ネットワーク内のデュアル 40 GbE リンクで接続された 3 台の個別のマシンを使用して実行されました。

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

使用されるハードウェア

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

使用ソフトウェア

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

• クライアント マシン上で実行されているwrkバージョン 4.0.0 が、NGINX がプロキシするトラフィックを生成しました。 これらの手順に従ってインストールしました。
• NGINX Open Source バージョン 1.9.7 は、リバース プロキシおよびWeb サーバーマシンで実行されました。 これらの手順に従って、 nginx.orgの公式リポジトリからインストールしました。
• Ubuntu Linux 14.04.1 は3 台のマシンすべてで実行されました。

テスト方法

さまざまな数の CPU を使用して、NGINX Plus リバース プロキシ サーバーのパフォーマンスをテストしました。 1 つの NGINX Plusワーカープロセスは 1 つの CPU を消費するため、異なる数の CPU のパフォーマンスを測定するために、ワーカープロセスの数を変えて、2 つのワーカー プロセス、4 つのワーカープロセス、8 つのワーカー プロセスなどでテストを繰り返しました。 NGINX アーキテクチャの概要については、ブログをご覧ください。

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

パフォーマンス指標

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

• 1 秒あたりのリクエスト数 (RPS) – HTTP リクエストを処理する能力を測定します。 私たちのテストでは、各クライアントはキープアライブ接続を介して 1 KB のファイルのリクエストを送信します。 リバース プロキシは各要求を処理し、別のキープアライブ接続を介してWeb サーバーに転送します。
• 1 秒あたりの SSL/TLS トランザクション数 (TPS) – 新しい SSL/TLS 接続を処理する能力を測定します。 私たちのテストでは、各クライアントはそれぞれ新しい接続で一連の HTTPS リクエストを送信します。 リバース プロキシはリクエストを解析し、確立されたキープアライブ接続を介してWeb サーバーに転送します。 Web サーバーは、リクエストごとに 0 バイトの応答を返します。
• スループット– HTTP 経由で 1 MB のファイルを提供するときに NGINX Plus が維持できるスループットを測定します。

テストの実行

すべてのクライアント トラフィックを生成するために、次のオプションを指定したwrk を使用しました。

• -cオプションは、作成する TCP 接続の数を指定します。 テストでは、これを 50 接続に設定しました。
• -dオプションは、トラフィックを生成する期間を指定します。 テストはそれぞれ 3 分間実行しました。
• -tオプションは、作成するスレッドの数を指定します。 単一のスレッドを指定しました。

各 CPU を完全に実行するために、単一のwrkプロセスを CPU に固定できるタスクセットを使用しました。 この方法は、 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 ごとに 1 つのwrkのコピーが生成され、クライアント マシンでは合計 36 個のコピーが生成されました。 各コピーは 50 個の TCP 接続を作成し、それらを介して 3 分間 (180 秒) にわたって 1 KB のファイルを継続的に要求しました。

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

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 ハードウェア構成に対するものです。

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

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 サーバーで使用されました。 rootディレクティブで設定されたとおりに、 /var/www/html/から静的ファイルを提供します。 静的ファイルは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;
    }
}

NGINX Plus を実際にお試しいただくには、今すぐ30 日間の無料トライアルを開始するか、弊社にお問い合わせの上、使用事例についてご相談ください。