NGINX Ingress ControllerとRed Hat OpenShift Routerのパフォーマンステスト

NGINX | 2022年1月10日

Red Hat OpenShift Container Platform（OCP）は、最も広く利用されているマネージドKubernetesプラットフォームの1つです。競合製品と同様に、ユーザーがすぐに利用を開始できるよう、デフォルトのトラフィック管理ツールが用意されています。OCPのデフォルトのエントリポイントは、OCP Router（HAProxyベース）です。HTTPおよびWebSocketトラフィックの負荷分散、TLS終端、Routerとアプリケーションインスタンス間のTLSをサポートするほか、パススルーモードでTLS接続の負荷分散も行えます。

お客さまからは、「Routerを無料で利用できるのに、なぜOpenShiftでNGINX Ingress Controllerを使用する必要があるのですか」とよく尋ねられます。「OpenShiftにエンタープライズグレードのIngress Controllerが必要な理由」では、GigaOmのゲストブロガーであるMax Mortillaro氏が、NGINX Ingress Controllerを使用する理由として、高度なトラフィック管理、使いやすさ、JWT検証、WAF統合といった定性的なメリットを紹介しています。しかし、この問いには定量的な観点から答えることも重要です。そこで、OCP環境において、RouterとNGINX PlusベースのNGINX Ingress Controller（nginxinc/kubernetes-ingress）のパフォーマンステストを実施しました。テストでは、アップストリーム（バックエンド）サーバーの数を増減させる動的なデプロイメントを使用しました。

パフォーマンステストでは、ツールの性能を評価するために、次の2つの要素を確認します。

要素1：動的デプロイメントのレイテンシ結果動的デプロイメントにおけるエンドユーザーエクスペリエンスの測定には、レイテンシのパーセンタイル分布が最も効果的な指標であると考えています。システムによって追加されるレイテンシが大きいほど、ユーザーエクスペリエンスへの影響も大きくなります。また、ユーザーエクスペリエンスを正確に把握するには、分布の上位パーセンタイルのレイテンシも含める必要があります。詳しくは、F5ブログの「パフォーマンス結果」セクション（「NGINXとHAProxy：クラウドにおけるユーザーエクスペリエンスのテスト」）をご覧ください。
要因2：タイムアウトとエラー動的デプロイメントでテスト対象のシステムがレイテンシーを引き起こす場合、通常は動的な再読み込みを適切に処理できず、タイムアウトやエラーが発生していることが原因です。

パフォーマンステスト結果

さっそく注目の結果を確認しましょう。テストのトポロジーと方法の詳細については、この後で説明します。

前述のとおり、パフォーマンスの評価では、レイテンシとタイムアウト／エラーという2つの要素を考慮します。

要因1：レイテンシのパーセンタイル分布

以下のグラフが示すように、NGINX Ingress Controllerによってテスト全体で追加されたレイテンシはごくわずかで、99.999パーセンタイルでも最大700 ms未満でした。一方、OCP Routerでは比較的低いパーセンタイルからレイテンシが加わり、その後指数関数的に増加し、99.99パーセンタイルで25,000 ms（25秒）をわずかに超えたところで横ばいになりました。この結果は、負荷がかかっている状態でクラスター環境への変更が頻繁に適用されると、Routerによってユーザーエクスペリエンスが低下する可能性があることを示しています。

要因2：タイムアウトとエラー

上記のレイテンシーは、タイムアウトとエラーに起因します。OCP Routerでは260件の接続タイムアウトと85件の読み取りソケットエラーが発生しましたが、NGINX Ingress Controllerではいずれも発生しませんでした。他のパフォーマンステスト（「動的なKubernetesクラウド環境におけるNGINX Ingress Controllerのパフォーマンステスト」を参照）でも確認されているように、Routerのタイムアウトとエラーは、HAproxyによる動的リロードの処理方法が原因です。NGINX PlusベースのNGINX Ingress Controllerでは、エンドポイントの変更時にNGINX Plus APIを使用してNGINXの設定を動的に更新するため、タイムアウトやエラーは発生しません。

テスト環境と方法

テストトポロジー

NGINX Ingress ControllerとOpenShift Routerのそれぞれを被試験システム（SUT）として、同じテストを実施しました。SUTはクライアントからのTLS 1.3接続を終端し、別の接続を介してクライアントリクエストをバックエンドデプロイメントに転送しました。

クライアントは、OpenShiftクラスターと同じLAN上にある、CentOS 7を実行する別のマシンでホストされていました。

SUTとバックエンドのデプロイメントは、VMware vSphere 6.7.0.45100上でホストされているOCPクラスターで実行されました。

TLS暗号化には、2,048ビットの鍵長を持つRSAとPerfect Forward Secrecyを使用しました。

バックエンドアプリケーションからの各レスポンスは、約1 KBの基本的なサーバーメタデータと、HTTPステータスコード「200 OK」で構成されていました。

テスト方法

クライアントのデプロイ

クライアントマシンでwrk2（バージョン4.0.0）を使用して次のスクリプトを実行し、毎秒1,000リクエスト（RPS、-dオプションで設定）の一定のスループットで、60秒間（-Rオプションで設定）テストを行いました：

./wrk -t 2 -c 50 -d 60s -R 1000 -L https://ingress-url:443/

使用したSUTソフトウェア

HAProxyベースのRouterをデフォルトで含むOpenShift Platformバージョン 4.8
NGINX Ingress Controllerバージョン1.11.0（NGINX Plus R22）

バックエンドのデプロイ

バックエンドアプリケーションを動的にデプロイし、以下のスクリプトを使用してバックエンドレプリカ数を定期的に増減させるテストを実施しました。これにより、動的なOpenShift環境を再現し、NGINX Ingress ControllerまたはOCP Routerがエンドポイントの変更にどの程度効果的に適応できるかを測定しました。

while [ 1 -eq 1 ]
do
  oc scale deployment nginx-backend --replicas=4  
  sleep 10 
  oc scale deployment nginx-backend --replicas=2
  sleep 10
done

まとめ

マイクロサービスの手法を採用する企業の多くは、これまで以上に高い頻度で新たな開発成果をCI/CDパイプラインに投入しています。そのため、エンドユーザーエクスペリエンスを損なうことなく、こうした新しい手法に合わせて機能とパフォーマンスを拡張できるデータプレーンを活用することが不可欠です。最適なエンドユーザーエクスペリエンスを実現するには、あらゆる状況で、すべてのクライアント接続に一貫して低レイテンシを提供する必要があります。

パフォーマンス結果から、NGINX Ingress Controllerは、開発の反復と改善が強く求められるコンテナ環境において、最適なエンドユーザーエクスペリエンスを提供することがわかります。

まず、NGINX Ingress Controllerの無料トライアルをダウンロードし、NGINX Ingress Operatorを使用したデプロイ方法をご確認ください。