本内容は「Comparing NGINX Performance in Bare Metal and Virtual Environments 」ブログを翻訳したものです。

＜目次＞

はじめに

COVID-19の流行により、パブリッククラウドの導入が爆発的に増加していますが、企業はパブリッククラウドとオンプレミス（プライベートデータセンターなど）の両環境を使用するハイブリッドクラウドも採用しています。
 
このハイブリッド・アプローチにより、企業は自社のニーズに最も適した環境でシステムを展開することができます。例えば、企業が機密性の高いデータを扱うミッションクリティカルなアプリケーション通信はオンプレミス環境で展開する一方で、WebホスティングやIoTなどのエッジサービスなど、コアネットワークインフラへのアクセスが限定的なアプリケーション通信にはパブリッククラウドを活用することが考えられます。
 
オンプレミスを選んだ場合も、さらにベアメタルまたは仮想（ハイパーバイザー）環境での実行を選択することができます。パフォーマンスとスケーリングのニーズを満たす最適かつ最も手頃なオンプレミスソリューションを決定するために、2つの環境でのNGINXパフォーマンスを比較するサイジングガイドを提供します。
 
※サイジングガイドについては以下をご参照ください。

ベアメタル環境
Sizing Guide for Deploying NGINX Plus on Bare Metal Servers
https://www.nginx.com/resources/datasheets/nginx-plus-sizing-guide/
 
仮想（ハイパーバイザー）環境
Sizing Guide for Deploying NGINX Plus in Virtualized Environments
https://www.nginx.com/resources/datasheets/nginx-plus-sizing-guide-virtualized-environments/
 
このブログでは、サイジングガイドで公開されている値に到達するためにNGINXをどのようにテストしたかについて説明します。お客様の多くはKubernetesでアプリをデプロイしているため、Rancher Kubernetes Engine（RKE）プラットフォームでのNGINX Ingress Controllerのテストについても説明し、その結果（※後述の資料参照）を従来のオンプレミスアーキテクチャで実行するNGINXと比較する方法についても説明します。
 
※以下資料をご参照ください。
 
・NGINX Ingress Controller
https://www.nginx.com/resources/datasheets/nginx-ingress-controller-kubernetes/

テスト方法

2つのアーキテクチャを使用し、異なる環境でのNGINXのパフォーマンスを測定し、比較しました。それぞれのアーキテクチャで、2つの主要なメトリクス、RPS（requests per second）とTPS（SSL/TLS transactions per second）を測定しました。詳細については、以下リンク先資料を参照ください。
 
https://www.nginx.com/blog/comparing-nginx-performance-bare-metal-and-virtual-environments/#Metrics-Collected

従来のオンプレミス型アーキテクチャ

テスト対象のNGINX(画像内のSUT)は、ベアメタル環境のハイパーバイザーで上で動作しています。負荷計測ツール(IXIA)を使用し、どちらの条件でも4台のIxiaクライアントがリクエストを生成し、それを受けたNGINXが4台のIxia Webサーバーに負荷分散しています。なお、Webサーバーは、各リクエストに対して128バイトのファイルを応答します。

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

• Ixia クライアントと Web サーバーは、負荷計測の専用HWである「Axia Xcellon-Ultra™ XT80v2」を使用し、同じく専用の負荷計測ソフトウェアであるIxLoad上に配置
• 両条件の NGINX は（画像内のSUT）では、Intel 製 NIC を搭載した PowerEdge サーバ上でCentOS 7上に配置
• ハイパーバイザーは、VMWare ESXiバージョン7.0.0を使用

上記のテスト時に使用したNGINXの設定ファイルは以下リンク先から参照可能です。
 
https://gist.github.com/nginx-gists/b52ea661c2f205fa0d519d66fd65a34c

Kubernetes アーキテクチャ

テスト対象のNGINX(画像内のSUT)は、Rancher Kubernetes Engine（RKE）ベアメタルプラットフォーム上で動作するNGINXオープンソースがベースのNGINX Ingress Controllerです。4台のIxiaクライアントがリクエストを生成し、NGINX Ingress ControllerがバックエンドのKubernetesデプロイメントであるWebサーバーに向け送信しています。（リクエストに対しては1KBのファイル応答をします）

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

• Ixiaクライアントは、負荷計測の専用HWである「Axia Xcellon-Ultra™ XT80v2」を使用し、同じく専用の負荷計測ソフトウェアであるIxLoad 上に配置。オンプレミス環境時と異なり、Kubernetes環境でテストしていたため、IxiaのWebサーバーは不要となります
• NGINX（画像内のSUT）とバックエンドアプリケーションをホストするノードの両OSはCentOS 7。NGINX とバックエンドアプリケーションは、Intel NICを搭載した2つの別々のPowerEdgeサーバーノード上で稼働
• NGINX Ingress Controllerのバージョンは1.11.0

上記のテスト時に使用したNGINX Ingress ControllerをベアメタルRKEにデプロイするためのYAMLファイルは以下リンク先から参照可能です。
 
https://gist.github.com/nginx-gists/b52ea661c2f205fa0d519d66fd65a34c

収集したメトリクス

テストの結果、以下2つの指標を得ました。

• RPS（Requests per second） - NGINXが1秒間に処理できるリクエストの数で、一定期間の平均値。Ixiaクライアントからのリクエストはhttpを使用
• SSL/TLS transactions per second (TPS) - NGINX が 1 秒間に確立して提供できる新しい HTTPS 接続の数。Ixia クライアントからのリクエストは https で、暗号鍵のサイズは 2048 ビットで RSA を使用し、Perfect Forward Secrecy を使用

Ixia クライアントは新規に一連のHTTPSリクエストを送信、NGINX は TLS によるセキュアな接続を確立し、バックエンドにリクエストをプロキシしました。

パフォーマンス分析

以降の表は、割り当てるCPUのコア数を変えながらオンプレミスとKubernetes両方のアーキテクチャで計測したRPSとSSL TPSの値を説明しています。

従来のオンプレミス型アーキテクチャ

ベアメタル上のNGINXの性能は、利用可能なCPUの数が8個になるまで直線的に上昇します。8 コア以上の場合、Ixia クライアントが NGINX の処理をあふれさせる（CPU 使用率 100%に達する）だけのリクエストを生成できなかったため、これ以上のコア数でのテストは行えませんでした。
 
仮想環境では、ベアメタルと比較してわずかではありますが、性能が劣化することがわかりました。ハイパーバイザー内のCPU命令は、ベアメタル上の同じ命令よりも多くのクロックサイクルを必要とし、これがさらなるオーバーヘッドを誘発します。

Kubernetesアーキテクチャ

KubernetesにおけるNGINX Ingress Controllerのパフォーマンスは、コア数を8個まで拡張するにつれて直線的にスケールします。
 
次の表の結果を従来のアーキテクチャの結果と比較すると、KubernetesでNGINXを（NGINX Ingress Controllerとして）実行すると、（RPSとして測定した）リクエストの処理などネットワークに依存する操作のパフォーマンスが大幅に劣化することがわかります。これは、他のサービスへの接続に使用されるコンテナのネットワークスタックに起因します。
 
一方、SSL/TLSハンドシェイクのようなCPU負荷の高い処理では、従来の環境とKubernetes環境の間で性能差がないことがわかります。
 
さらに、HyperThreading（HT）を有効にすると、TPSが約10%向上することも確認できました。

まとめ

以下は、NGINXが最適に動作する環境と、選択した環境でのパフォーマンス影響を理解するための重要なポイントです。

• （テストではRPSとして測定した）アプリケーションインフラがネットワークに依存する操作を実行している場合、従来のベアメタル環境でNGINXを実行することがパフォーマンスにとって最適です。KubernetesでNGINX Ingress Controllerを実行すると、コンテナのネットワークスタックのために、ネットワークに依存する操作のパフォーマンスで大きなコストが発生します。
• ハイパーバイザーは、ネットワークおよびCPU依存の操作の両方で、わずかですが測定可能なパフォーマンスのコストをもたらします（RPSはベアメタル値の約80％です）。
• （テストではTPSとして測定した）アプリケーションインフラがCPU依存の操作を実行している場合、従来の環境とKubernetes環境のNGINXの間に性能差はほとんどありません。
• 本テストでは、ハイパースレッディングにより、暗号化のような並列化可能なCPU依存の操作のパフォーマンスがおよそ10%向上しました。

より多くの情報が必要な場合は、以下のサイトを参照いただくか弊社までお気軽にお問い合わせください。
https://docs.nginx.com/nginx/

BIG-IPのリプレースについてはこちらから