Test des performances du contrôleur d'entrée NGINX et du routeur Red Hat OpenShift

Red Hat OpenShift Container Platform (OCP) est l'une des plateformes Kubernetes gérées les plus populaires et, comme ses concurrents, OCP inclut des outils de gestion du trafic par défaut pour aider les utilisateurs à démarrer rapidement. Le routeur OCP – basé sur HAProxy – est le point d’entrée par défaut des clusters OCP. Il peut équilibrer la charge du trafic HTTP et WebSocket, prend en charge la terminaison TLS et TLS entre le routeur et les instances d'application, et peut équilibrer la charge des connexions TLS en mode relais.

Les clients nous demandent souvent : « Pourquoi devrais-je utiliser NGINX Ingress Controller dans OpenShift alors que le routeur est disponible gratuitement ? » Dans Pourquoi vous avez besoin d'un contrôleur d'entrée de qualité entreprise sur OpenShift , le blogueur invité Max Mortillaro de GigaOm partage quelques raisons qualitatives pour lesquelles vous pourriez vouloir utiliser NGINX Ingress Controller : gestion avancée du trafic, facilité d'utilisation, validation JWT et intégration WAF. Mais il est également important de répondre à cette question d'un point de vue quantitatif, c'est pourquoi nous avons testé les performances du routeur et du contrôleur d'entrée NGINX basé sur NGINX Plus ( nginxinc/kubernetes-ingress ) dans l'environnement OCP, dans un déploiement dynamique dans lequel nous avons augmenté et diminué le nombre de serveurs en amont (backend) pendant le test.

Lorsque nous effectuons des tests de performance, nous examinons deux facteurs pour évaluer les performances des outils :

• Facteur 1 : Résultats de latence pour les déploiements dynamiques

  Nous constatons que la mesure la plus efficace pour mesurer l’expérience de l’utilisateur final dans un déploiement dynamique est la distribution des centiles de latence. Plus la latence ajoutée par un système est importante, plus l'expérience utilisateur est affectée. Nous avons également constaté que pour obtenir une image fidèle de l'expérience utilisateur, les latences aux centiles supérieurs de la distribution doivent être incluses ; pour une explication détaillée, consultez la section Résultats de performances de NGINX et HAProxy : Tester l'expérience utilisateur dans le Cloud sur notre blog.

• Facteur 2 : Délais d'attente et erreurs

  Lorsqu'un système testé provoque une latence dans un déploiement dynamique, c'est généralement parce que le système a du mal à gérer les rechargements dynamiques, rencontre des délais d'attente ou des erreurs.

Résultats des tests de performance

Passons directement à la partie intéressante et examinons les résultats. Les détails sur la topologie et la méthode de test suivent.

Comme indiqué ci-dessus, nous prenons en compte deux facteurs lors de l’évaluation des performances : la latence et les délais d’attente/erreurs.

Facteur 1 : Distribution des percentiles de latence

Comme l’illustre le graphique suivant, NGINX Ingress Controller a ajouté une latence négligeable tout au long du test, atteignant un maximum de moins de 700 ms au 99,999e percentile. En revanche, le routeur OCP a ajouté de la latence à des percentiles assez faibles, et la latence a augmenté de manière exponentielle jusqu'à atteindre un plateau à un peu plus de 25 000 ms (25 secondes) au 99,99e percentile. Cela démontre que, sous charge et alors que des modifications dans l'environnement du cluster sont appliquées fréquemment, le routeur peut entraîner une mauvaise expérience utilisateur.

Facteur 2 : Délais d'attente et erreurs

La latence observée ci-dessus peut être attribuée aux délais d’attente et aux erreurs : le routeur OCP a produit 260 délais d’attente de connexion et 85 erreurs de socket de lecture, tandis que NGINX Ingress Controller n’en a produit aucun. Comme nous l'avons vu avec d'autres tests de performances (voir Tests de performances des contrôleurs d'entrée NGINX dans un environnement cloud Kubernetes dynamique ), les délais d'attente et les erreurs du routeur sont causés par la façon dont HAproxy gère les rechargements dynamiques. Le contrôleur d'entrée NGINX basé sur NGINX Plus ne provoque pas de délais d'attente ni d'erreurs, car il utilise l' API NGINX Plus pour mettre à jour dynamiquement la configuration NGINX lorsque les points de terminaison changent.

Configuration et méthodologie des tests

Topologie des tests

Nous avons effectué les mêmes tests sur le contrôleur d’entrée NGINX et sur le routeur OpenShift comme système testé (SUT). Le SUT a mis fin aux connexions TLS 1.3 du client et a transmis la demande du client via une connexion distincte au déploiement backend.

Le client était hébergé sur une machine distincte exécutant CentOS 7, située sur le même réseau local que le cluster OpenShift.

Le déploiement SUT et backend s'est exécuté dans un cluster OCP hébergé sur VMware vSphere 6.7.0.45100.

Pour le cryptage TLS, nous avons utilisé RSA avec une taille de clé de 2048 bits et Perfect Forward Secrecy.

Chaque réponse de l'application backend comprenait environ 1 Ko de métadonnées de base du serveur, ainsi que les200 OK Code d'état HTTP.

Méthodologie de test

Déploiement du client

En utilisant wrk2 (version 4.0.0), nous avons exécuté le script suivant sur la machine cliente, en exécutant le test pendant 60 secondes (défini avec l'option -d ) à un débit constant de 1000 requêtes par seconde (RPS, défini avec l'option -R ) :

./wrk -t 2 -c 50 -d 60s -R 1000 -L https:// url-d'entrée :443/

Logiciel SUT utilisé

• Version 4.8 de la plateforme OpenShift, qui inclut le routeur basé sur HAProxy par défaut
• Contrôleur d'entrée NGINX version 1.11.0 (NGINX Plus R22)

Déploiement du backend

Nous avons effectué des tests avec un déploiement dynamique de l'application backend, en utilisant le script suivant pour augmenter et diminuer périodiquement le nombre de répliques backend. Cela émule un environnement OpenShift dynamique et mesure l'efficacité avec laquelle le contrôleur d'entrée NGINX ou le routeur OCP s'adapte aux changements de point de terminaison.

pendant que [ 1 -eq 1 ]
faire
déploiement à grande échelle oc nginx-backend --replicas=4 
sommeil 10 
déploiement à grande échelle oc nginx-backend --replicas=2
sommeil 10
terminé

Conclusion

La plupart des entreprises qui adoptent des méthodologies de microservices poussent les nouveaux développements via leurs pipelines CI/CD à des fréquences plus élevées que jamais. Pour cette raison, il est essentiel de tirer parti d’un plan de données qui évolue avec ces nouvelles méthodologies en termes de capacités et de performances, sans perturber l’expérience de l’utilisateur final. Offrir une expérience optimale à l’utilisateur final implique de garantir systématiquement une faible latence pour toutes les connexions client, dans toutes les circonstances.

Sur la base des résultats de performances, le contrôleur d’entrée NGINX offre une expérience utilisateur optimale dans les environnements conteneurisés où le besoin d’itérer et d’améliorer le développement est élevé.

Pour commencer, téléchargez une version d’essai gratuite du contrôleur d’entrée NGINX et découvrez comment effectuer le déploiement à l’aide de l’ opérateur d’entrée NGINX .