パフォーマンステスト

NGINXおよびNGINX Plus Webサーバーのパフォーマンステスト

※本記事は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スループットを分析しました。予算とパフォーマンスのニーズに合わせ、現在と将来を見越したトラフィックを処理するために必要なハードウェアの仕様決定に、ぜひこのブログの情報をお役立てください。

NGINX Plus 対 F5 BIG-IP:価格・性能比較

※本記事はNGINX,Inc.のブログ記事「NGINX Plus vs. F5 BIG‑IP: A Price‑Performance Comparison」を和訳した内容となります。
【URL】
https://www.nginx.com/blog/nginx-plus-vs-f5-big-ip-a-price-performance-comparison/

最近、AppNexusIgnitionOneをはじめとする多くのお客様が、主流のハードウェアであるアプリケーション デリバリー コントローラー(以下ADCと表記)アプライアンスをNGINX Plusに置き換え、多大なコスト削減と大幅なパフォーマンス向上を実現しています。他にも巨大なWeb資産を持つ複数の企業が、ADC機能のソフトウェア実装(SSL / TLS暗号化のような、歴史的にハードウェア集約の機能だったものを含む)を行い、必要とする作業負荷に対し、十分以上に速いということを証明しています。

当社はベアメタルサーバー上で、NGINX Plusのパフォーマンスを測定した各種テストの結果(英語)に基づき、NGINXサイジングガイド(英語)を発行しました。
この記事では、これらのパフォーマンス計測値を3つのサイズで、F5ハードウェア アプライアンス
の公開計測値と比較します。

私たちのテストによれば、汎用ハードウェアで動くNGINX PlusはF5 BIG-IPアプライアンスの性能を満たすか、しばしば凌駕しつつ、最大83%のコスト削減を達成しています。

ハードウェアADCをNGINX Plusに置き換える方法の詳細については、以下のリソースを
参照してください。

ブログの投稿

移行ガイド

このブログでは、次の3つの単純で明白なパフォーマンス指標を比較します。

  • HTTPリクエスト/秒(RPS)
  • SSL / TLSトランザクション/秒(TPS)
  • HTTPスループット

各指標の詳細は、「パフォーマンス指標」の項を参照してください。

F5アプライアンスの数値は、公表されたデータシート(英語)ものと、2つのデータ元(CDW(英語)とCarahsoft(英語))の価格情報から、NGINX Plusのパフォーマンス数値はサイジングガイドのものを使っています。NGINX Plusのハードウェア費用は、テスト結果を達成したIntelハードウェアと同じ仕様のDell PowerEdgeサーバーの定価に基づいています。

注:表に記載されている費用は、記事の公開時点のもので、変更される可能性があります。

では、さっそく調査結果を見てみましょう。

NGINX Plus 対 F5 BIG-IP 2000S

以下の表では、F5のエントリーレベルのアプリケーション デリバリー コントローラーであるF5 BIG-IP 2000Sと、2つの異なるベアメタルサーバー上で動作するNGINX Plusを比較しています。

  • DellのPowerEdge R230 4コア Intel®Xeon®E3-1220 V5 3.0GHzのCPUと Intel XL710 2×40
    GbE NIC
  • DellのPowerEdge R430 8コア Intel®Xeon®プロセッサー E5-2630 V3 2.4GHzのCPUとIntel XL710 2×40 GbE NIC

NGINX Plusはスループットに人為的な上限を課していません。つまり、購入したハードウェアの全性能を使用することになります。

NGINX Plus 対 F5 BIG-IP 5050S

以下の表では、中規模のBIG-IPアプライアンスであるF5 BIG-IP 5050Sと、同等サイズのベアメタルサーバー、デュアル16コアIntel®Xeon®E5-2697A v4 2.6GHz CPUおよびIntel XL710 2×40 Gbe NIC搭載のDell PowerEdge R630 上で動作するNGINX Plus とを比較しています。

NGINX Plus 対 F5 BIG-IP 11050

以下の表では、ハイエンドのBIG-IPアプライアンスF5 BIG-IP 11050 と2つのNGINX Plusインスタンス、それぞれがデュアル18コア Intel®Xeon®E5-2699 v3 2.3GHz CPUとIntel XL710 2×40Gbe NICを搭載したDell PowerEdge R630で動作するものを比較しています。 1つのNGINX Plusインスタンスは1秒間に最大120万件のリクエストを処理できるため、2インスタンスではおおむねBIG-IP 11050とほぼ同じ性能となり、毎秒最大250万件のリクエストを処理できます。

最新のSSL / TLS要件のレポート結果

現在のSSL / TLSベストプラクティスに従って、楕円曲線ディフィー・ヘルマン鍵共有(Ephemeral Elliptic Curve Diffie-Hellman:以下ECDHEと表記)、AES、およびSHA384を使用するECDHE-RSA-AES256-GCM-SHA384暗号スイートを使い、NGINX PlusのSSL / TLSトランザクション/秒(以下TPSと表記)を計測しました。また、F5データシートの性能値との有効な比較のため、RSA 2048ビットキーを使用しました。

この暗号は秘密鍵が漏洩された場合でも、今、暗号化されたトラフィックがキャプチャーされても、後から解読できないようにするPerfect Forward Secrecy(以下PFSと表記)を提供します。PFSは現在のセキュリティー環境において、「必須」となっています。たとえば、AppleはiOS9アプリがPFSを使用して通信することを義務づけています。

F5は、データシートのパフォーマンステストで使用している暗号は明らかにしておらず、また以前のF5ベンチマークでは、パフォーマンス上不利になるPFSが使用されていませんでした。F5は、ほとんどのプラットフォームで、ソフトウェアECDHE暗号を実装しています。

お読みいただく際には、異なる暗号を使うと、セキュリティーとスピードの間でトレードオフが生じる場合に、SSLのパフォーマンスを比較することの課題についてはご留意ください。

結論

当社のお客様は、ハードウェアアプライアンスから同等のNGINX Plusソリューションに切り替える際、大幅なコスト削減を行えたとしています。また、私たちのパフォーマンス測定と価格分析はこれを裏付けています。私たちが調べたシンプルなユースケースでは、1年目で80%から84%のコスト削減が見られました。

NGINX Plusはどう違うのでしょうか?ソフトウェアにハードウェアをバンドルしていませんし、当社のソフトウェアには人為的なパフォーマンス制限を課していません。自社のニーズに対し最も費用対効果の高いハードウェアを、自由に選択してください。社内規格に適合しないハードウェアを受け入れるよう強制するものではありませんし、2〜3年後に発生する可能性のあるトラフィック増加やアプリケーションの複雑化を見越して、過剰なハードウェアを今、見積もっておく必要もありません。

最後に、複数利用のハードウェア ロードバランサーのコストに対しては、アプリケーション全体でNGINX Plusサブスクリプションを取得できます。アプリケーション価格、お客様のアプリケーション全体、つまりロード・バランシング、キャッシング、ウェブやメディアサービスなど、また本番、テスト、開発環境全体すべてをサポートする無制限のNGINX Plusインスタンスをお使いいただけます。NGINXサポートチームのエキスパートが支援するアプリケーション配信スタック全体で、標準的で信頼できるテクノロジーを使用したなら、
運用とアプリケーションの配信コストにどのような影響があるでしょうか?

NGINX Plusのパフォーマンスを評価するには、すぐに無料の30日間のトライアルを開始するか、ライブデモをご依頼ください

付録 テストの詳細

このコスト比較を作成するため使用したデータは、複数のデータ元から集めたものです。

  • NGINX Plusのテストは、すべてそれぞれ36コアのCPUを1つ搭載した3台のサーバーを使用して行いました。サーバーは、標準的なクライアント→プロキシ→サーバー・トポロジーで構成されていました。
  • 異なる数のCPUコアで計測値を取るために、使用するCPUコアの数を変更しています。
  • BIG-IPアプライアンスのハードウェア仕様とパフォーマンス値は、F5 BIG-IPのデータシートから得られたものです(自分たちでF5ハードウェアのテストはしていません)。

NGINX Plusのベンチマークに使用したハードウェアは、Intel社より貸与いただきました。テストの実行方法の詳細については、このブログを参照してください。

パフォーマンス指標

このレポートでは、以下のパフォーマンス指標を比較しています。

  • 1秒当たりリクエスト(RPS)  – HTTP要求を処理する能力を測定します。NGINX Plusのテストでは、クライアントはkeepalive接続でリクエストを送信します。NGINX Plusは各リクエストを処理し、別のkeepalive接でWebサーバーに転送します。
  • SSL / TLS 1秒当たりトランザクション(TPS)  – 新しいSSL / TLS接続を処理する能力を測定します。NGINX Plusのテストでは、クライアントは新しい接続で、一連のHTTPSリクエストを送信します。NGINX Plusは各リクエストを解析し、別の確立されたkeepalive接でWebサーバーに転送します。Webサーバーは、各リクエストに対して0バイトの応答を返します。
  • スループット  – HTTP経由で大容量のファイルを処理する場合に発生するスループットを測定します。

ご使用の環境でNGINX Plusがどのように機能するかを確認するには、今すぐ無料の30日間のトライアル開始するか、ライブデモをご依頼ください。