Evaluación comparativa de soluciones de gestión de API de NGINX, Kong y Amazon: ¿Entregan API en tiempo real?

Velocidad: es clave en el panorama digital actual, donde los consumidores pueden cambiar fácilmente a un competidor si el rendimiento de su aplicación es demasiado lento. La velocidad de la aplicación está determinada en última instancia por API receptivas, saludables y adaptables, y uno de los factores críticos en la capacidad de respuesta de la API es la latencia introducida por su puerta de enlace API. Pero no todas las puertas de enlace API funcionan al mismo nivel.

Ese punto quedó claro el otoño pasado cuando un cliente de NGINX (un actor importante en la industria del crédito al consumo) nos comentó sobre la creciente importancia del rendimiento de la API en "tiempo real" a medida que más y más aplicaciones y otros componentes necesitan comunicarse para brindar la experiencia digital que esperan los usuarios. Nos sentimos muy satisfechos de saber que NGINX Plus era el único API gateway que lograba las latencias de API ultrarrápidas (tan bajas como 10 milisegundos (ms)) que el cliente necesitaba. Muchos otros clientes , como Capital One , también han compartido con nosotros cómo redujeron la latencia y mejoraron el rendimiento con NGINX Open Source o NGINX Plus como su puerta de enlace API.

Decidimos analizar más a fondo el ecosistema API y tratar de descubrir qué hace que una API sea “en tiempo real”. Con base en una serie de factores, determinamos que una API en tiempo real debe procesar llamadas de API de extremo a extremo en menos de 30 ms en cada percentil hasta el 99 (lo que significa que, en promedio, solo 1 llamada de cada 100 demora más de 30 ms).

Comparación de soluciones de gestión de API

Nuestras propias pruebas demuestran constantemente que es fácil lograr un rendimiento de API en tiempo real con nuestra solución de gestión de API, que combina NGINX Plus como puerta de enlace de API para procesar llamadas de API y el módulo de gestión de API del controlador NGINX para gestionar tanto las instancias de NGINX Plus como sus API a medida que las define, publica, gestiona y supervisa durante todo su ciclo de vida.

Pero comprendemos que quizás usted no quiera confiar solo en nuestras palabras. Por eso, encargamos a GigaOm , una empresa independiente de investigación y análisis técnico, una evaluación comparativa objetiva y transparente de nuestra solución de gestión de API y otras soluciones populares en el mercado: dos soluciones que, como NGINX, se pueden implementar en las instalaciones o en la nube, Apigee y Kong Enterprise , y dos ofertas de nube completamente administradas, Amazon API Gateway y Kong Cloud.

En este blog resumimos los resultados de las pruebas de GigaOm (spoiler: NGINX Plus entregó API en tiempo real en todas las condiciones probadas, y las otras soluciones no lo hicieron). Para obtener todos los detalles sobre las soluciones, la metodología de pruebas y los resultados, póngase en contacto con un miembro de nuestro equipo .

Nota:  El acuerdo de licencia de usuario final (EULA) de Apigee prohíbe la publicación de resultados de pruebas sin el permiso expreso de Google, por lo que lamentablemente ni el informe ni este blog incluyen información sobre Apigee.

Descripción general del punto de referencia

GigaOm utilizó la herramienta de prueba de carga HTTP Vegeta para generar solicitudes (llamadas API) y midió cuánta latencia (la cantidad de tiempo que tardaba en devolver la respuesta a una llamada API) introducía la puerta de enlace API en distintas cantidades de solicitudes por segundo (RPS), lo que GigaOm denomina "tasas de ataque". GigaOm realizó pruebas con tasas de ataque que comenzaban en 1000 RPS y aumentaban hasta 5000, 10 000, 20 000, y así sucesivamente, hasta que Vegeta informó códigos de estado de error. Cada prueba duró 60 segundos y se repitió 3 veces. Como se muestra en los gráficos a continuación, GigaOm capturó las latencias en los percentiles 50, 90, 95, 99, 99,9 y 99,99 y también registró la latencia más larga observada durante la ejecución de la prueba ( Máx. en los gráficos).

Resultados: NGINX frente a. Kong Enterprise

GigaOm realizó dos evaluaciones comparativas entre NGINX Plus (implementado usando NGINX Controller) y Kong Node (implementado usando Kong Enterprise). En el primer punto de referencia, había un único nodo de trabajo (una instancia de NGINX Plus o Kong Node). En el segundo, había tres nodos de trabajo equilibrados en carga por NGINX Open Source en modo Round-Robin. (GigaOm enfatiza que el uso de NGINX Open Source como balanceador de carga no creó una ventaja para NGINX Plus, e incluso Kong lo recomienda como el balanceador de carga para usar en instancias de Kong Node en clúster).

Como se muestra en los siguientes gráficos, la diferencia de latencia entre NGINX y Kong es insignificante hasta el percentil 99, punto en el que la latencia de Kong comienza a crecer exponencialmente. En el percentil 99,99, la latencia de Kong es el triple o el doble que la de NGINX en los dos puntos de referencia respectivamente.

El percentil 99 es un valor mínimo decente para definir una API como en tiempo real, pero GigaOm señala que en implementaciones del mundo real es "extremadamente importante" mantener una latencia baja en percentiles más altos, como el 99,9 y el 99,99. El informe explica:

Los resultados de latencia tienden a ser multimodales a lo largo del tiempo, y los picos más altos representan “contratiempos” en los tiempos de respuesta.

Estos contratiempos importan. Si el tiempo de respuesta o latencia promedio es menor a 30 ms, pero hay contratiempos de latencias de 1 segundo o más, en realidad hay un efecto acumulativo en la experiencia posterior del usuario. Por ejemplo, si visitas un restaurante de comida rápida donde el tiempo de espera promedio para la comida es de 1 minuto, probablemente pensarías que fue una buena experiencia para el cliente. Sin embargo, ¿qué pasa si el cliente que está frente a usted tiene un problema con su pedido y tarda 10 minutos en resolverlo? El tiempo de espera en realidad sería de 11 minutos. Debido a que su solicitud llegó en línea después del contratiempo, el retraso del percentil 99,99 retrasado también puede convertirse en su retraso.

El efecto negativo de latencias inusualmente grandes en percentiles altos se vuelve aún más significativo en aplicações distribuidas donde una sola solicitud de cliente puede generar múltiples llamadas API posteriores. Por ejemplo, supongamos que 1 solicitud de cliente crea 10 llamadas API a un subsistema con un 1 % de probabilidad de responder lentamente. Se puede demostrar matemáticamente que, como resultado, hay casi un 10 % de probabilidad de que la solicitud de un cliente se vea afectada por una respuesta lenta. Para obtener más detalles sobre las matemáticas, consulte ¿Quién movió mi latencia del percentil 99?

La figura 1 muestra los resultados de la tasa de ataque de 30 000 RPS con un solo nodo de trabajo. En el percentil 99,99, la latencia de Kong es más de 3 veces la de NGINX y supera el umbral de 30 ms para las API en tiempo real. Por el contrario, NGINX Plus logra una latencia en tiempo real en cada percentil; incluso su latencia más alta registrada ( Máx. ) de 13 ms es menos de la mitad del umbral de tiempo real.

La figura 2 muestra resultados muy similares para el punto de referencia con tres nodos de trabajo, también con una tasa de ataque de 30 000 RPS. Curiosamente, Kong supera a NGINX en los percentiles 99 y 99,9, pero una vez más sufre un enorme pico de latencia en el percentil 99,99, esta vez alcanzando una latencia que es aproximadamente el doble de la de NGINX. Al igual que en el primer punto de referencia, NGINX se mantiene por debajo del umbral de tiempo real de 30 ms en todos los percentiles.

Otra forma de medir el rendimiento de una puerta de enlace de API es determinar los RPS máximos que puede procesar con un 100 % de éxito (sin 5xx o429 [Demasiadas solicitudes ] errores) y una latencia por debajo de 30 ms en todos los percentiles, tanto para las configuraciones de un solo nodo como de tres nodos. La figura 3 muestra cómo con esta medida, NGINX mantiene un RPS un 50 % superior al de Kong: 30.000 contra 20.000.

Resultados: NGINX frente a. Kong Cloud y Amazon API Gateway

En el tercer conjunto de puntos de referencia, GigaOm comparó NGINX Plus con Kong Cloud y Amazon API Gateway. GigaOm enfatiza que una comparación directa es altamente problemática porque Kong Cloud y Amazon API Gateway son ofertas SaaS completamente administradas, mientras que NGINX Controller es una oferta PaaS y actualmente no está disponible como SaaS. En particular, ninguna de las ofertas de SaaS revela el tipo de instancia, la potencia de cómputo, la memoria o las capacidades de red que utiliza. Por lo tanto, GigaOm tuvo que hacer una estimación aproximada de las configuraciones comparables para NGINX Plus.

Incluso dejando de lado la comparación con NGINX Plus, queda inmediatamente claro que las ofertas de SaaS no pueden entregar API en tiempo real en ninguno de los percentiles probados, incluso en la segunda tasa de ataque más baja (5000 RPS) que se muestra en la Figura 4. En el percentil 50, la latencia de las ofertas de SaaS ya es más de 7 veces el umbral de 30 ms; en el percentil 99,99, supera ese umbral en más del 8000 %. La implicación obvia es que no existen condiciones bajo las cuales Kong Cloud o Amazon API Gateway logren un éxito del 100 % con una latencia inferior a 30 ms.

Validación de NGINX como la única solución API en tiempo real

En resumen, NGINX es la única solución probada por GigaOm que cumplió con los estándares de procesamiento de API en tiempo real, logrando menos de 30 ms de latencia en cada percentil. Kong Enterprise alcanza un rendimiento en tiempo real en el percentil 99, pero su latencia aumenta significativamente en percentiles más altos, lo que lo hace inadecuado para entornos de producción que requieren incluso un volumen moderado de procesamiento de API en tiempo real. Ninguna de las soluciones SaaS probadas puede categorizarse como en tiempo real.

El informe de GigaOm valida tanto nuestros puntos de referencia anteriores como lo que escuchamos de nuestros clientes. NGINX Plus es la puerta de enlace API más rápida del mercado y la única solución API capaz de mantener una latencia de menos de 30 ms en todos los percentiles. Y si lo combina con NGINX Controller, obtiene acceso a una solución de administración de API con una arquitectura única en la que, debido a un desacoplamiento cuidadoso, no hay impacto alguno en el rendimiento del plano de datos de la puerta de enlace de API (NGINX Plus) del plano de control de administración de API (NGINX Controller).

Puede probar el rendimiento de su propia API con nuestra herramienta de medición de latencia rtapi . Pruébelo y póngase en contacto con nosotros para analizar cómo podemos ayudarle a hacer que sus API sean en tiempo real.