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

Red Hat OpenShift Container Platform (OCP) は、最も人気のあるマネージド Kubernetes プラットフォームの 1 つであり、競合他社と同様に、OCP には、ユーザーがすぐに使い始めることができるようにデフォルトのトラフィック管理ツールが含まれています。 HAProxyに基づくOCP ルーターは、OCP クラスターのデフォルトのエントリ ポイントです。 HTTP および WebSocket トラフィックの負荷分散が可能で、ルーターとアプリケーション インスタンス間の TLS 終端と TLS をサポートし、パススルー モードで TLS 接続の負荷分散を行うことができます。

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

パフォーマンス テストを実施するときは、ツールのパフォーマンスを評価するために次の 2 つの要素を考慮します。

• 要因1: 動的デプロイメントのレイテンシ結果

  動的展開におけるエンドユーザー エクスペリエンスを測定するための最も効果的なメトリックは、レイテンシのパーセンタイル分布であることがわかりました。 システムによって追加されるレイテンシが大きくなると、ユーザー エクスペリエンスへの影響も大きくなります。 また、ユーザーエクスペリエンスの真の姿を把握するには、分布の上位パーセンタイルのレイテンシも含める必要があることもわかりました。詳細については、 パフォーマンス結果 セクション NGINX と HAProxy: クラウドでのユーザーエクスペリエンスのテスト 私たちのブログで。

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

  テスト対象のシステムが動的デプロイメントで遅延を引き起こす場合、通常は、システムが動的リロードを処理できず、タイムアウトやエラーが発生することが原因です。

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

早速、興味深い部分に移り、結果を確認してみましょう。 テストのトポロジと方法の詳細については、以下を参照してください。

上で説明したように、パフォーマンスを評価する際には、レイテンシとタイムアウト/エラーという 2 つの要素を考慮します。

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

次のグラフが示すように、NGINX Ingress Controller はテスト全体を通じてレイテンシをほとんど追加せず、99.999 パーセンタイルで最大値 700 ミリ秒未満に達しました。 対照的に、OCP ルーターはかなり低いパーセンタイルでレイテンシを追加し、レイテンシは指数関数的に増加し、99.99 パーセンタイルで 25,000 ミリ秒 (25 秒) を少し超える程度で横ばいになりました。 これは、クラスタ環境の変更が頻繁に適用され、負荷がかかった場合、ルータによってユーザー エクスペリエンスが低下する可能性があることを示しています。

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

上記で観察された遅延は、タイムアウトとエラーに起因する可能性があります。OCP ルーターは 260 の接続タイムアウトと 85 のソケット読み取りエラーを生成しましたが、NGINX Ingress コントローラーでは何も生成されませんでした。 他のパフォーマンス テストでも確認したように ( 「動的 Kubernetes クラウド環境での NGINX Ingress コントローラーのパフォーマンス テスト」を参照)、ルーターのタイムアウトとエラーは、HAproxy が動的リロードを処理する方法によって発生します。 NGINX Plus ベースのNGINX Ingress Controller は、エンドポイントが変更されたときにNGINX Plus API を使用して NGINX 構成を動的に更新するため、タイムアウトやエラーは発生しません。

テストの設定と方法

トポロジのテスト

テスト対象システム (SUT) として、NGINX Ingress Controller と OpenShift Router の両方で同じテストを実行しました。 SUT はクライアントからの TLS 1.3 接続を終了し、クライアント要求を別の接続を介してバックエンド展開に転送しました。

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

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

TLS 暗号化には、 2048 ビットのキー サイズと Perfect Forward Secrecy を備えた RSA を使用しました。

バックエンドアプリケーションからの各応答は、 約1KB 基本的なサーバーメタデータと の 200 わかりました HTTP ステータス コード。

テスト方法

クライアントの展開

wrk2 (バージョン 4.0.0) を使用して、クライアント マシンで次のスクリプトを実行し、1 秒あたり 1000 リクエスト (RPS、 -Rオプションで設定) の一定スループットで 60 秒間 ( -dオプションで設定) テストを実行しました。

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

使用されるSUTソフトウェア

• OpenShift Platform バージョン 4.8 (デフォルトで HAProxy ベースのルーターを含む)
• NGINX Ingress コントローラー バージョン 1.11.0 (NGINX Plus R22)

バックエンドのデプロイメント

次のスクリプトを使用してバックエンド レプリカの数を定期的に増減し、バックエンド アプリケーションの動的デプロイメントでテスト実行を実施しました。 これは動的な OpenShift 環境をエミュレートし、NGINX Ingress コントローラーまたは OCP ルーターがエンドポイントの変更にどれだけ効果的に適応するかを測定します。

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

結論

マイクロサービス手法を採用している企業のほとんどは、これまで以上に高い頻度で CI/CD パイプラインを通じて新しい開発を推進しています。 このため、エンドユーザー エクスペリエンスを中断することなく、これらの新しい方法論に合わせて機能とパフォーマンスが拡張されるデータ プレーンを活用することが重要です。 最適なエンドユーザー エクスペリエンスを実現するには、あらゆる状況下ですべてのクライアント接続の低レイテンシを一貫して実現する必要があります。

パフォーマンス結果に基づくと、NGINX Ingress Controller は、開発の反復と改善の必要性が高いコンテナ化された環境で最適なエンドユーザー エクスペリエンスを提供します。

開始するには、 NGINX Ingress Controller の無料トライアルをダウンロードし、 NGINX Ingress Operator を使用してデプロイする方法を確認してください。