※本記事はNGINX,Inc.のブログ記事「Testing the Performance of NGINX and NGINX Plus Web Servers」を和訳したものです。
Webサイトを成功させるには、パフォーマンスが非常に重要です。低速のサイトを使いたい人なんていませんから。
2004年のオープンソースのリリース以来、NGINXは高性能Webサイトの代名詞となっています。世界のトップ100,000サイトの63％、そして世界中の4億900万サイトがNGINXで動いています。でも、実際NGINXはどのくらいうまく機能していますか？リーズナブルな価格で最高のパフォーマンスを発揮するハードウェア構成は何でしょうか？
これらの質問に答えるため、リバースプロキシとWebサーバーという2つの構成について、ラボでパフォーマンステストを行いました。リバースプロキシのパフォーマンスの数値は、「ベアメタルサーバー用のNGINX Plusサイジングガイド」（英語）に掲載し、Nginx社のブログ「NGINX Plusサイジングガイド（英語）：どのようにテストしたか」でテストの詳細を説明しています。
これらの記事を公開してから、基礎となるテスト結果に関するより具体的な情報に対して多くのリクエストを頂きました。この記事では、ライブHTTP接続とHTTPS接続の1秒あたりの要求数（以後RPSと表記）と1秒あたりの接続数（以後CPSと表記）の詳細なパフォーマンス数値をご紹介します。また、Webサーバーとして動作するNGINX用の50個の専用チャネルのHTTPスループットを公開します。この結果は、コミュニティー版のNGINXソフトウェアとNGINX Plusの両方にあてはまります。
この情報が、予算とパフォーマンス要件を考慮しつつ、現在から将来を見据えてWebアプリケーションのトラフィックを処理するために必要なハードウェア仕様を決めるときに、お役に立てば幸いです。
テストの概要
使用したテスト設定は、クライアントとWebサーバーの間にリバースプロキシがないことを除けば、前述の「NGINX Plusサイジングガイド：どのようにテストしたか（英語）」
の設定とほぼ同じです。シンプルでフラットなレイヤ2ネットワークのデュアルポート 40-GbEリンクで接続された2つの別々のマシンを使用して、すべてのテストを行いました。
テストで異なる数のCPUをシミュレートするために、NGINXワーカープロセスの数を変更しました。デフォルトでは、実行を開始するNGINXワーカープロセスの数は、NGINXが実行されているマシンで使用可能なCPUの数と同じです。/etc/nginx/nginx.confファイル内のworker_processesディレクティブの値を変更し、NGINXサービスを再起動することによって、実行中のNGINXワーカープロセスの数を変更できます。
クライアントトラフィックがHTTPSで保護されているテストでは、次の暗号化パラメータを使用しました。
- ECDHE-RSA-AES256-GCM-SHA384暗号
- 2,048ビットRSAキー
- 暗号のECDHEで示されている完全なforward secrecy
- OpenSSL 1.0.1f
使用ハードウェア
クライアントマシンとWebサーバーマシンの両方のテストで、以下のハードウェアを使用しました。
- CPU：2xインテル（R）Xeon（R）CPU E5-2699 v3 @ 2.30GHz、36（72 HT）コア
- ネットワークアダプター：インテルXL710 デュアルポート 40GbE QSFP +（rev 01）
- メモリー：16 GB
使用ソフトウェア
テストには次のソフトウェアを使用しました。
- クライアントマシン上で実行するバージョン4.0.0 のwrkは、NGINXがプロキシしたトラフィックを生成します。インストールは、これらの手順に従って行いました。
- コミュニティー版のNGINXソフトウェアのバージョン1.9.7がWebサーバーマシン上で動作します。インストールは、これらの指示に従って、nginx.orgの公式リポジトリから行いました。
- Ubuntu Linux 14.04.1は、クライアントマシンとWebサーバーマシンの両方で動作します。
パフォーマンス計測と分析
テストから得られた、パフォーマンスの数値は下記の通りです。
1秒あたりのリクエスト数
1秒あたりの要求数（RPS）は、HTTPリクエストを処理する能力を測定します。それぞれのリクエストは、クライアントマシンからNGINX Webサーバーに送信されます。テストは、暗号化されていないHTTPと、暗号化されたHTTPSトラフィックの両方に対して行いました。
パフォーマンステストの一般的な習慣に従って、4つの標準ファイルサイズを使用しています。
- 0 KBは、302エラーコードなどのデータを伴わない「空の」HTTPリクエストまたはレスポンスをシミュレートします。
- 1 KBは、小さなCSSやJavaScriptファイルのサイズ、または小さなアイコンなどの非常に小さいイメージのサイズです。
- 10 KBは、大きなコードファイル、大きなアイコン、小さな画像ファイルに近いものです。
- 100 KBは大きなコードファイルと他の大きなファイルを表します。
少量のHTTPリクエストを発行すると、1秒あたりのリクエスト数が増え、総スループットが低下します。大量のHTTPリクエストを発行すると、1回のリクエストで大量のファイル転送が開始されるため、完了までにかなりの時間がかかり、1秒あたりのリクエスト数とスループットが低下します。
HTTP要求のRPS
以下の表とグラフは、HTTPリクエストの数を、異なるCPU数とリクエストサイズごとにキロバイト（KB）単位で示しています。
大規模なHTTPリクエスト（テストでは10および100 KBサイズのもの）は断片化され、処理に時間がかかります。その結果、大きいサイズのリクエストになればなるほど、グラフ内の線はより傾きが平坦になっています。
予算とパフォーマンスの選択肢を検討するとき、CPU数が16を超えると、線の傾きが変化することに注意してください。32個のCPUを搭載したサーバーは、1 KBおよび10 KBのリクエストサイズの場合、36個のCPUを搭載したサーバーと同等以上の性能を発揮しました。最終的には、リソースの競合がCPUの追加によるプラスの影響を上回ります。これは、HTTPトラフィック向けの一般的な4〜8コアのサーバー構成では、CPUを合計16個に増やすことがもっとも効果的かもしれず、32個の使用だとそこまでではなく、36個に増やすメリットはさらに少ないか、ほとんどないということを示唆しています。とはいえテストでの事実が、あなたにとっての有用性とは違うかもしれないのは、いつものことですが。
HTTPS要求のRPS
HTTPS RPSは、同じプロビジョニングされたベアメタルハードウェアのHTTP RPSよりも低くなります。これは、マシン間で送信されるデータを保護するために必要なデータの暗号化と復号化の計算コストが高いためです。
上記状況にも関わらず、プロセッサーの高速化とメモリー管理の向上を実現したIntelアーキテクチャーの進歩のおかげで、専用のハードウェア暗号化デバイスと比べ、CPUによる暗号化タスクのソフトウェア性能は絶え間なく向上しています。
16CPUの場合、HTTPSの1秒あたりの接続数は、HTTPの約4分の1減程度ですが、いわば「問題にハードウェアを投げ込んで」CPUを追加するなら、HTTPよりも効果的です・・・最大36CPUまでは、より一般的に使用されるファイルサイズのため。
1秒あたりの接続数
1秒あたりの接続数（以後CPSと表記）は、リクエストを行ったクライアントに対し、新しいTCP接続を行うNGINXの能力を測定します。クライアントは一連のHTTPまたはHTTPSリクエストを、それぞれ新しい接続で送信します。NGINXはリクエストを解析し、各リクエストに対して0バイトの応答を返します。リクエストが満たされた後、接続は閉じられます。
注：このテストのHTTPSの変形は、SSLトランザクション/秒 （SSL TPS）と呼ばれることがよくあります。
HTTPリクエストの1秒あたりの接続数
以下の表とグラフは、異なるCPU数でのHTTPリクエストに対するCPSを示しています。
HTTPS要求に対する1秒あたりの接続数
以下の表とグラフは、HTTPSリクエストのCPSを示しています。
タイミングの制約のため、32CPUではテストを行っていません。
スループット
以下のテストでは、NGINXが180秒間を超えて持続できるHTTPリクエスト（Gbps単位）のスループットを測定します。
雑記
テストと結果に関して、何点かメモをしておきます。
- 本テストCPUでは、ハイパースレッディングが利用できました。つまり、ハイパースレッディングCPUの全容量を使用するため、追加のNGINXワーカープロセスを実行できたということです。ここで報告したテストではハイパースレッディングは有効にしませんでしたが、別のテストで使用すると、パフォーマンスが向上しました。ハイパースレッディングによって、SSL TPSが約50％も改善したことは特筆すべき点です。
- ここに示した数字はOpenSSL 1.0.1です。また、OpenSSL 1.0.2でテストし、2倍のパフォーマンス向上を確認しました。OpenSSL 1.0.1は、まだ幅広く使用されていますが、より良いセキュリティとより良いパフォーマンスのために、OpenSSL 1.0.2に移行することをお勧めします。
- 楕円曲線暗号（ECC）もテストしましたが、ここで示した結果はRSAを使用しています。暗号化の場合、ECCは消費電力の効率化が必要なモバイル向けに展開されることが多く、RSAはECCよりもはるかに広く使用されています。標準的なRSA証明書と比較して、ECCでは2倍から3倍のパフォーマンス向上が見られたため、EECの実装を検討することをお勧めします。
OpenSSL 1.0.2への移行とECCへの移行の組み合わせで、非常に強力なパフォーマンス改善をもたらすかもしれません。さらに現在、4CPUまたは8CPUサーバーを使用していて、16CPU（または、SSL用に32CPU）に移行した場合、ここでのテスト結果が示すように、非常に劇的な改善を達成することができるかもしれません。
結論
ライブHTTPおよびHTTPS接続でのRPSおよびCPSのパフォーマンステスト結果と、50の専用チャネルでのHTTPスループットを分析しました。予算とパフォーマンスのニーズに合わせ、現在と将来を見越したトラフィックを処理するために必要なハードウェアの仕様決定に、ぜひこのブログの情報をお役立てください。