Red Hat OpenShift Container Platform (OCP) は、最も人気のあるマネージド Kubernetes プラットフォームの一つで、競合他社と同様に、OCP にはユーザーがすぐに使い始められるように、デフォルトのトラフィック管理ツールが用意されています。OCP Router（HAProxyベース）は、OCPクラスタのデフォルトのエントリーポイントです。HTTP および WebSocket トラフィックの負荷分散、TLS 終端、およびルーターとアプリケーション・インスタンス間の 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 ) を、テスト中にアップストリーム（バックエンド）サーバーの数を増減させる動的な展開で性能テストを実施してみました。
性能テストを行う際、ツールの性能を評価するために二つの要素に着目しています。
-
要因1：ダイナミックデプロイメントにおけるレイテンシーの結果
動的な展開におけるエンドユーザー・エクスペリエンスの測定に最も効果的な指標は、レイテンシー・パーセンタイル分布であることがわかっています。システムによってレイテンシーが増加すればするほど、ユーザーエクスペリエンスに影響が出ます。また、ユーザー・エクスペリエンスを正確に把握するためには、分布の上位パーセンタイルにおけるレイテンシーを含める必要があることも分かっています。詳細な説明については、「NGINX および HAProxy のパフォーマンス結果」のセクションを参照してください。また、ブログの NGINX and HAProxy: Testing User Experience in the Cloud のパフォーマンス結果のセクションを参照してください。
-
要因2：タイムアウトとエラー
テスト対象のシステムが動的な展開で遅延を引き起こす場合、一般的にはシステムが動的な再ロードの処理に問題があり、タイムアウトやエラーが発生することが原因です。
パフォーマンステスト結果
それでは早速、興味深い結果を確認してみましょう。テストのトポロジーと方法については後述します。
前述したように、パフォーマンスを評価する際には、レイテンシーとタイムアウト/エラーの二つの要素を考慮します。
要因1：レイテンシーのパーセンタイル分布
以下のグラフが示すように、NGINX Ingress Controllerはテストを通してごくわずかな遅延を追加しただけで、99.999パーセンタイルでは最大700ms未満に達しました。一方、OCP Router では、かなり低いパーセンタイルで遅延が発生し、99.99 パーセンタイルでは 25,000ms（25 秒）強で頭打ちになるまで指数関数的に遅延が増加しました。これは、クラスタ環境の変更が頻繁に適用され、負荷が高い場合、ルーターはユーザーエクスペリエンスを低下させる可能性があることを示しています。
要因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の暗号化にはRSAを使用し、鍵長は2048ビット、Perfect Forward Secrecyを使用しました。
バックエンドアプリケーションからの各レスポンスは、約1KBの基本的なサーバーメタデータと200 OKのHTTPステータスコードで構成されています。
テスト方法
クライアントの配備
wrk2（バージョン4.0.0）を用いて、クライアントマシン上で以下のスクリプトを実行し、1000リクエスト/秒（RPS、-Rオプションで設定）の一定のスループットで60秒間（-dオプションで設定）テストを実行しました。
./wrk -t 2 -c 50 -d 60s -R 1000 -L https://ingress-URL:443/SUTのデプロイメント
- HAProxyベースのルーターをデフォルトで含む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を使用してOCPに導入してください。
