Comparativa de soluciones de gestión de API de NGINX, Kong y Amazon: ¿ofrecen API en tiempo real?

La velocidad es clave en el panorama digital actual, donde los consumidores pueden pasarse fácilmente a la competencia si el rendimiento de tu aplicación es demasiado lento. En última instancia, la velocidad de una aplicación depende de unas API ágiles, robustas y adaptables, y uno de los factores críticos para la capacidad de respuesta de las API es la latencia que introduce la puerta de enlace de API. Sin embargo, no todas las puertas de enlace de API ofrecen el mismo rendimiento.

Esta realidad se nos hizo patente el pasado otoño, cuando un cliente de NGINX —una empresa destacada del sector del crédito al consumo— nos habló de la creciente importancia del rendimiento de las API «en tiempo real», a medida que cada vez más aplicaciones y otros componentes necesitan comunicarse para ofrecer la experiencia digital que esperan los usuarios. Nos complació enormemente saber que NGINX Plus era la única puerta de enlace de API que lograba las latencias ultrarrápidas que necesitaba el cliente, de tan solo 10 milisegundos (ms). Muchos otros clientes, como Capital One, también nos han contado cómo redujeron la latencia y mejoraron el rendimiento utilizando NGINX Open Source o NGINX Plus como puerta de enlace de API.

Decidimos analizar más a fondo el ecosistema de las API e intentar averiguar qué hace que una API sea «en tiempo real». Basándonos en varios factores, determinamos que una API en tiempo real debe procesar las llamadas a la API de extremo a extremo en menos de 30 ms en todos los percentiles hasta el 99 incluido (lo que significa que, de media, solo 1 llamada de cada 100 tarda más de 30 ms).

Comparación de soluciones de gestión de API

Nuestras propias pruebas demuestran sistemáticamente que es fácil lograr un rendimiento de las 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 las llamadas a las API y el módulo de gestión de API de NGINX Controller 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 entendemos que quizá no quiera fiarse solo de nuestra palabra. Por eso encargamos a GigaOm, una empresa independiente de investigación y análisis técnico, que realizara una evaluación comparativa objetiva y transparente de nuestra solución de gestión de API y de otras soluciones populares del mercado: dos soluciones que, al igual que NGINX, pueden implementarse en las instalaciones o en la nube, Apigee y Kong Enterprise, y dos ofertas en la nube totalmente gestionadas, Amazon API Gateway y Kong Cloud.

En este blog resumimos los resultados de las pruebas de GigaOm (adelanto: NGINX Plus proporcionó las API en tiempo real en todas las condiciones probadas, mientras que las demás soluciones no lo hicieron). Para conocer todos los detalles sobre las soluciones, la metodología de las pruebas y los resultados, póngase en contacto con un miembro de nuestro equipo.

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

Resumen de la comparativa de rendimiento

GigaOm utilizó la herramienta de pruebas de carga HTTP Vegeta para generar solicitudes (llamadas a la API) y midió la latencia —el tiempo que tardaba en devolverse la respuesta a una llamada a la API— que introducía la puerta de enlace de API con distintos números de solicitudes por segundo (RPS), lo que GigaOm denomina «tasas de ataque». GigaOm realizó pruebas con tasas de ataque que comenzaban en 1.000 RPS y aumentaban progresivamente a 5.000, 10.000, 20.000, y así sucesivamente, hasta que Vegeta notificaba códigos de estado de error. Cada prueba duró 60 segundos y se repitió 3 veces. Como se muestra en los gráficos siguientes, GigaOm registró las latencias en los percentiles 50, 90, 95, 99, 99,9 y 99,99, así como la latencia más alta observada durante la prueba (Máx. en los gráficos).

Resultados: NGINX frente a Kong Enterprise

GigaOm realizó dos pruebas comparativas entre NGINX Plus (implementado mediante NGINX Controller) y Kong Node (implementado mediante Kong Enterprise). En la primera prueba, había un único nodo de trabajo (una instancia de NGINX Plus o Kong Node). En la segunda, había tres nodos de trabajo con balanceo de carga mediante NGINX Open Source en modo Round‑Robin. (GigaOm recalca que utilizar NGINX Open Source como balanceador de carga no supuso ninguna ventaja para NGINX Plus y que incluso Kong lo recomienda como balanceador de carga para las instancias de Kong Node agrupadas en clústeres).

Como se muestra en los siguientes gráficos, la diferencia de latencia entre NGINX y Kong es insignificante hasta el percentil 99, momento a partir del cual la latencia de Kong comienza a crecer exponencialmente. En el percentil 99,99, la latencia de Kong es, respectivamente, tres y dos veces superior a la de NGINX en las dos pruebas comparativas.

El percentil 99 es un valor mínimo razonable para considerar que una API funciona en tiempo real, pero GigaOm señala que, en implementaciones reales, 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 presentar una distribución multimodal a lo largo del tiempo, y los picos más altos representan «contratiempos» en los tiempos de respuesta.

Estos parones son importantes. Si la mediana del tiempo de respuesta o de la latencia es inferior a 30 ms, pero se producen parones de 1 segundo o latencias superiores, en realidad se genera un efecto acumulativo en la experiencia de los usuarios posteriores. Por ejemplo, si acude al autoservicio de un restaurante de comida rápida donde la mediana del tiempo de espera para recibir la comida es de 1 minuto, probablemente consideraría que ofrece una buena experiencia al cliente. Sin embargo, ¿qué ocurre si el cliente que está delante de usted tiene un problema con su pedido y se tarda 10 minutos en resolverlo? En realidad, su tiempo de espera sería de 11 minutos. Como su solicitud entró en la cola después del parón, el retraso del percentil 99,99 también puede convertirse en su retraso.

El efecto negativo de las latencias inusualmente altas en los percentiles superiores cobra aún más importancia en las aplicaciones distribuidas, donde una sola solicitud de cliente puede generar varias llamadas posteriores a una API. Por ejemplo, supongamos que una solicitud de cliente genera 10 llamadas a la API de un subsistema con una probabilidad del 1 % de responder lentamente. Se puede demostrar matemáticamente que, como resultado, existe una probabilidad de casi el 10 % de que la solicitud del cliente se vea afectada por una respuesta lenta. Para obtener más información sobre los cálculos, consulte ¿Quién ha movido la latencia de mi percentil 99?

La figura 1 muestra los resultados para una tasa de ataque de 30.000 RPS con un único nodo de trabajo. En el percentil 99,99, la latencia de Kong es más de 3 veces superior a la de NGINX y supera el umbral de 30 ms para las API en tiempo real. En cambio, NGINX Plus logra una latencia apta para aplicaciones en tiempo real en todos los percentiles; incluso su latencia más alta registrada (Máx.), de 13 ms, es inferior a la mitad del umbral para aplicaciones en tiempo real.

Figura 1. NGINX Controller y Kong Enterprise a 30.000 RPS con 1 nodo

La figura 2 muestra resultados muy similares para la prueba de rendimiento 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 vuelve a sufrir un enorme pico de latencia en el percentil 99,99, alcanzando esta vez una latencia aproximadamente dos veces superior a la de NGINX. Al igual que en la primera prueba de rendimiento, NGINX se mantiene por debajo del umbral de tiempo real de 30 ms en todos los percentiles.

Figura 2. NGINX Controller y Kong Enterprise a 30.000 RPS con 3 nodos

Otra forma de evaluar el rendimiento de una puerta de enlace de API consiste en determinar el máximo de RPS que puede procesar con un 100 % de éxito (sin errores 5xx ni 429 [Too Many Requests]), manteniendo una latencia inferior a 30 ms en todos los percentiles, tanto en la configuración de un solo nodo como en la de tres nodos. La figura 3 muestra que, según este criterio, NGINX admite un 50 % más de RPS que Kong: 30 000 frente a 20 000.

Figura 3. Rendimiento máximo alcanzado sin errores

Resultados: NGINX frente a Kong Cloud y Amazon API Gateway

En el tercer conjunto de pruebas de rendimiento, GigaOm comparó NGINX Plus con Kong Cloud y Amazon API Gateway. GigaOm subraya que una comparación directa resulta muy problemática, ya que Kong Cloud y Amazon API Gateway son soluciones SaaS totalmente gestionadas, mientras que NGINX Controller es una solución PaaS que actualmente no está disponible como SaaS. En concreto, ninguna de las soluciones SaaS revela el tipo de instancia, la potencia de procesamiento, la memoria ni las capacidades de red que utiliza. Por tanto, GigaOm tuvo que hacer la mejor estimación posible de los ajustes comparables que debía aplicar a NGINX Plus.

Incluso dejando de lado la comparación con NGINX Plus, resulta evidente de inmediato que las ofertas SaaS no pueden proporcionar API en tiempo real en ninguno de los percentiles analizados, ni siquiera con 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 SaaS ya supera en más de 7 veces el umbral de 30 ms; en el percentil 99,99, supera dicho umbral en más de un 8000 %. La conclusión evidente es que no hay ninguna situación en la que Kong Cloud o Amazon API Gateway alcancen una tasa de éxito del 100 % con una latencia inferior a 30 ms.

Figura 4. NGINX Controller, Amazon API Gateway y Kong Cloud a 5000 RPS con 1 nodo

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

En resumen, NGINX es la única solución probada por GigaOm que cumplió los estándares de procesamiento de API en tiempo real, con una latencia inferior a 30 ms en todos los percentiles. Kong Enterprise alcanza un rendimiento en tiempo real en el percentil 99, pero su latencia aumenta considerablemente en percentiles superiores, por lo que resulta poco adecuada 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 considerarse una solución en tiempo real.

El informe de GigaOm confirma tanto los resultados de nuestras pruebas de rendimiento anteriores como lo que nos cuentan nuestros clientes. NGINX Plus es la puerta de enlace de API más rápida del mercado y la única solución de API capaz de mantener una latencia inferior a 30 ms en todos los percentiles. Además, si se combina con NGINX Controller, se obtiene acceso a una solución de gestión de API con una arquitectura única en la que, gracias a una cuidadosa separación, el plano de control de gestión de API (NGINX Controller) no afecta en absoluto al rendimiento del plano de datos de la puerta de enlace de API (NGINX Plus).

Puede probar el rendimiento de sus propias API con nuestra herramienta de medición de latencia rtapi. Pruébela y póngase en contacto con nosotros para hablar sobre cómo podemos ayudarle a hacer que sus API funcionen en tiempo real.

---