Analyse comparative des solutions de gestion des API de NGINX, Kong et Amazon : Fournissent-ils des API en temps réel ?

La rapidité est essentielle dans le paysage numérique actuel, où les consommateurs peuvent facilement passer à un concurrent si les performances de votre application sont trop lentes. La vitesse des applications dépend en fin de compte des API réactives, saines et adaptables, et l’un des facteurs critiques de la réactivité des API est la latence introduite par votre passerelle API. Mais toutes les passerelles API ne fonctionnent pas au même niveau.

Ce point nous a été rappelé l’automne dernier lorsqu’un client de NGINX – un acteur majeur du secteur du crédit à la consommation – nous a parlé de l’importance croissante des performances des API « en temps réel », car de plus en plus d’applications et d’autres composants doivent communiquer pour offrir l’expérience numérique attendue par les utilisateurs. Nous avons été très heureux d’apprendre que NGINX Plus était la seule passerelle API capable d’atteindre les latences API ultra-rapides – aussi faibles que 10 millisecondes (ms) – dont le client avait besoin. De nombreux autres clients , tels que Capital One , ont également partagé avec nous comment ils ont réduit la latence et amélioré le débit avec NGINX Open Source ou NGINX Plus comme passerelle API.

Nous avons décidé d’examiner de plus près l’écosystème des API et d’essayer de comprendre ce qui fait qu’une API est « en temps réel ». Sur la base d’un certain nombre de facteurs, nous avons déterminé qu’une API en temps réel doit traiter les appels d’API de bout en bout en moins de 30 ms à chaque centile jusqu’au 99e (ce qui signifie qu’en moyenne, seulement 1 appel sur 100 prend plus de 30 ms).

Comparaison des solutions de gestion des API

Nos propres tests montrent systématiquement qu'il est facile d'obtenir des performances API en temps réel avec notre solution de gestion des API, qui combine NGINX Plus comme passerelle API pour le traitement des appels API et le module de gestion des API NGINX Controller pour gérer à la fois les instances NGINX Plus et vos API lorsque vous les définissez, les publiez, les gérez et les surveillez tout au long de leur cycle de vie.

Mais nous comprenons que vous ne souhaitiez peut-être pas nous croire sur parole. Nous avons donc mandaté GigaOm , un cabinet indépendant de recherche et d'analyse technique, pour réaliser une analyse comparative objective et transparente de notre solution de gestion d'API et d'autres solutions populaires sur le marché : deux solutions qui, comme NGINX, peuvent être déployées sur site ou dans le cloud, Apigee et Kong Enterprise , et deux offres cloud entièrement gérées, Amazon API Gateway et Kong Cloud.

Dans ce blog, nous résumons les résultats des tests de GigaOm (spoiler : NGINX Plus a fourni des API en temps réel dans toutes les conditions testées, contrairement aux autres solutions. Pour tous les détails sur les solutions, la méthodologie de test et les résultats, contactez un membre de notre équipe .

Note: Le contrat de licence d’utilisateur final (CLUF) d’Apigee interdit la publication des résultats des tests sans l’autorisation expresse de Google. Malheureusement, ni le rapport ni ce blog n’incluent d’informations sur Apigee.

Aperçu de l'indice de référence

GigaOm a utilisé l'outil de test de charge HTTP Vegeta pour générer des requêtes (appels API) et a mesuré la latence (le temps nécessaire pour renvoyer la réponse à un appel API) introduite par la passerelle API à différents nombres de requêtes par seconde (RPS), que GigaOm appelle « taux d'attaque ». GigaOm a effectué des tests avec des taux d'attaque commençant à 1 000 RPS et augmentant jusqu'à 5 000, 10 000, 20 000, et ainsi de suite jusqu'à ce que Vegeta signale des codes d'état d'erreur. Chaque test a duré 60 secondes et a été répété 3 fois. Comme le montrent les graphiques ci-dessous, GigaOm a capturé les latences aux 50e, 90e, 95e, 99e, 99,9e et 99,99e percentiles et a également enregistré la latence la plus longue observée pendant l'exécution du test ( Max dans les graphiques).

Résultats: NGINX contre Entreprise Kong

GigaOm a réalisé deux tests comparant NGINX Plus (déployé à l'aide de NGINX Controller) et Kong Node (déployé à l'aide de Kong Enterprise). Dans le premier benchmark, il y avait un seul nœud de travail (une instance de NGINX Plus ou Kong Node). Dans le deuxième cas, trois nœuds de travail étaient équilibrés en charge par NGINX Open Source en mode Round-Robin. (GigaOm souligne que l'utilisation de NGINX Open Source comme équilibreur de charge n'a pas créé d'avantage pour NGINX Plus, et même Kong le recommande comme équilibreur de charge à utiliser pour les instances Kong Node en cluster.)

Comme le montrent les graphiques suivants, la différence de latence entre NGINX et Kong est négligeable jusqu’au 99e percentile, auquel cas la latence de Kong commence à croître de manière exponentielle. Au 99,99e percentile, la latence de Kong est respectivement le triple ou le double de celle de NGINX dans les deux benchmarks.

Le 99e percentile est une valeur minimale décente pour définir une API comme étant en temps réel, mais GigaOm note que dans les déploiements réels, il est « extrêmement important » de maintenir une faible latence à des percentiles plus élevés comme le 99,9e et le 99,99e. Le rapport explique :

Les résultats de latence ont tendance à être multimodaux au fil du temps, les sommets des pics représentant des « hoquets » dans les temps de réponse.

Ces hoquets sont importants. Si le temps de réponse médian ou la latence est inférieur à 30 ms, mais qu'il y a des ratés de 1 seconde ou plus de latence, il y a en fait un effet cumulatif sur l'expérience utilisateur ultérieure. Par exemple, si vous visitez un service de restauration rapide au volant où le temps d'attente moyen pour la nourriture est d'une minute, vous penseriez probablement qu'il s'agit d'une bonne expérience client. Mais que se passe-t-il si le client en face de vous a un problème avec sa commande et qu'il faut 10 minutes pour le résoudre ? Votre temps d’attente serait en réalité de 11 minutes. Étant donné que votre demande est arrivée après le hoquet, le retard du 99,99e centile retardé peut également devenir votre retard.

L’effet négatif des latences inhabituellement élevées à des centiles élevés devient encore plus significatif dans les applications distribuées où une seule demande client peut en fait générer plusieurs appels d’API en aval. Par exemple, supposons qu’une requête client crée 10 appels d’API vers un sous-système avec une probabilité de 1 % de répondre lentement. Il peut être démontré mathématiquement qu'il y a donc près de 10 % de probabilité que la demande d'un client soit affectée par une réponse lente. Pour plus de détails sur les mathématiques, voir Qui a déplacé ma latence du 99e percentile ?

La figure 1 illustre les résultats pour un taux d’attaque de 30 000 RPS avec un seul nœud de travail. Au 99,99e percentile, la latence de Kong est plus de 3 fois supérieure à celle de NGINX et dépasse le seuil de 30 ms pour les API en temps réel. En revanche, NGINX Plus atteint une latence en temps réel à chaque centile : même sa latence la plus élevée enregistrée ( Max ) de 13 ms est inférieure à la moitié du seuil en temps réel.

La figure 2 montre des résultats très similaires pour le benchmark avec trois nœuds de travail, également au taux d'attaque de 30 000 RPS. Il est intéressant de noter que Kong surpasse NGINX aux 99e et 99,9e percentiles, mais souffre une fois de plus d’un énorme pic de latence au 99,99e percentile, atteignant cette fois une latence environ deux fois supérieure à celle de NGINX. Comme dans le premier benchmark, NGINX reste en dessous du seuil de 30 ms en temps réel à tous les centiles.

Une autre façon d'évaluer les performances d'une passerelle API consiste à déterminer le RPS maximal qu'elle peut traiter avec 100 % de réussite (aucun 5xx ou429 [Trop de requêtes] erreurs) et une latence inférieure à 30 ms à tous les centiles, pour les configurations à un seul nœud et à trois nœuds. La figure 3 montre comment, selon cette mesure, NGINX maintient un RPS 50 % plus élevé que Kong : 30 000 contre 20 000.

Résultats: NGINX contre Kong Cloud et Amazon API Gateway

Dans la troisième série de tests, GigaOm a comparé NGINX Plus à Kong Cloud et Amazon API Gateway. GigaOm souligne qu'une comparaison directe est très problématique car Kong Cloud et Amazon API Gateway sont des offres SaaS entièrement gérées, tandis que NGINX Controller est une offre PaaS et n'est actuellement pas disponible en SaaS. En particulier, aucune offre SaaS ne révèle le type d’instance, la puissance de calcul, la mémoire ou les capacités réseau qu’elle utilise. GigaOm a donc dû faire une estimation des paramètres comparables à effectuer pour NGINX Plus.

Même en mettant de côté la comparaison avec NGINX Plus, il est immédiatement clair que les offres SaaS ne peuvent pas fournir d’API en temps réel à aucun des centiles testés, même au deuxième taux d’attaque le plus bas (5 000 RPS) illustré dans la figure 4. Au 50e percentile, la latence des offres SaaS est déjà plus de 7 fois supérieure au seuil de 30 ms ; au 99,99e percentile, elle dépasse ce seuil de plus de 8 000 %. L’implication évidente est qu’il n’existe aucune condition dans laquelle Kong Cloud ou Amazon API Gateway atteignent 100 % de réussite avec une latence inférieure à 30 ms.

Validation de NGINX comme seule solution API en temps réel

En résumé, NGINX est la seule solution testée par GigaOm qui répond aux normes de traitement d’API en temps réel, atteignant moins de 30 ms de latence à chaque centile. Kong Enterprise atteint des performances en temps réel au 99e percentile, mais sa latence augmente considérablement aux percentiles plus élevés, ce qui le rend inadapté aux environnements de production qui nécessitent même un volume modéré de traitement d'API en temps réel. Aucune des solutions SaaS testées ne peut être classée comme étant en temps réel.

Le rapport GigaOm valide à la fois nos analyses comparatives précédentes et ce que nous entendons de nos clients. NGINX Plus est la passerelle API la plus rapide du marché et la seule solution API capable de maintenir une latence inférieure à 30 ms à tous les centiles. Et si vous l'associez à NGINX Controller, vous obtenez l'accès à une solution de gestion d'API à l'architecture unique où, grâce à un découplage minutieux, il n'y a aucun impact sur les performances du plan de données de la passerelle API (NGINX Plus) du plan de contrôle de gestion des API (NGINX Controller).

Vous pouvez tester vos propres performances API avec notre outil de mesure de latence rtapi . Découvrez-le et contactez-nous pour discuter de la manière dont nous pouvons vous aider à rendre vos API en temps réel.