Resolvimos el error que aparecía durante la gran promoción del 429 utilizando el gateway de Kubernetes, y además ahorramos un 30% en los costos de servidores.

El mes pasado, durante el Black Friday, nuestro equipo estuvo a punto de colapsar:El 13% de las solicitudes de resolución de direcciones de usuarios son rechazadas directamente con el código de error 429.Después de investigar durante medio día, se descubrió que las reglas de throttling asignadas individualmente a cada microservicio eran demasiado estrictas. Como resultado, el tráfico en el módulo de consulta de logística aumentó tres veces, y los recursos disponibles para otros servicios no pudieron ser utilizados debido a la sobrecarga.

Antes siempre pensábamos que el gateway de Kubernetes era un componente complejo que solo utilizaban las grandes empresas, hasta que nos vimos obligados a implementarlo debido a un problema que surgió. Todo el proceso llevó menos de una semana, y el resultado fue mucho mejor de lo que esperábamos.

¿Qué es exactamente un gateway de Kubernetes?

En otras palabras, es la entrada de tráfico unificada para todo tu clúster de Kubernetes; todas las solicitudes externas llegan primero aquí y luego son redirigidas a los servicios backend correspondientes. La versión open source que utilizamos puede soportar hasta 12,000 solicitudes por segundo con un solo instante, por lo que los equipos pequeños no necesitan preocuparse por cuellos de botella de rendimiento.

Los 3 beneficios reales que hemos obtenido

Lo primero que llama la atención es que, finalmente, no es necesario configurar las reglas de limitación de tráfico de forma individual para cada servicio. Antes, durante las grandes promociones, teníamos que modificar los umbrales de limitación de tráfico de siete u ocho microservicios, y si se omitía uno, surgían problemas. Ahora, la limitación de tráfico se realiza de manera dinámica en el nivel del gateway, lo que permite que los recursos de los servidores disponibles se distribuyan automáticamente hacia los módulos con mayor carga de trabajo. Como resultado, durante la gran promoción de Navidad, el número de errores de tipo 429 disminuyó drásticamente, hasta cero.

El segundo beneficio es la reducción de costos. Anteriormente, para soportar los picos de carga, asignamos 2 servidores de respaldo adicionales a cada uno de los 3 servicios principales, lo que resultaba en una tasa de utilización de recursos del 20% la mayor parte del tiempo. Ahora que el gateway puede realizar el equilibrio de carga automáticamente, hemos reducido la cantidad de servidores en 6 unidades, y hemos calculado que los costos mensuales en la nube han disminuido un 30%.

El tercero es evitar que el backend tenga que modificar repetidamente lógicas comunes como el manejo de cross-domain y la autenticación. Antes, cada vez que se lanzaba un nuevo servicio, el backend tenía que escribir el código de validación JWT de nuevo; ahora, con solo configurar una regla a nivel de gateway, todo se resuelve. Esto nos permite a los tres desarrolladores del backend liberar al menos media jornada semanal para trabajar en código de negocio.

No te limites a escuchar solo los beneficios; estos dos problemas los hemos experimentado de primera mano.

El primer problema es que la configuración predeterminada del tiempo de espera es muy inadecuada. Ya el primer día de lanzamiento, detectamos que el 5% de las solicitudes de resolución de direcciones se estaban demorando debido a tiempo de espera. Después de investigar durante un buen rato, descubrimos que el tiempo de espera predeterminado del gateway era de 30 segundos, mientras que nuestro servicio de resolución de direcciones tardaba hasta 40 segundos en completarse. Una vez que modificamos las reglas, el problema se resolvió inmediatamente. Antes de lanzar el servicio, es esencial verificar uno por uno los umbrales de tiempo de espera en cada una de las interfaces de tu propio negocio.

El segundo error es no intentar incorporar todas las funciones de golpe. Al principio, queríamos activar de una vez las funciones de registro de logs, control de tráfico (throttling), WAF (Web Application Firewall) y lanzamiento en modo gris (grayscale release), pero cometimos un error en la configuración que causó la interrupción del servicio en todo el clúster durante 20 minutos. Más tarde, comenzamos activando solo la ruta y el control de tráfico, y después de tres días de funcionamiento estable, agregamos gradualmente las demás funciones sin tener más problemas.

¿Deberíamos usarlo o no? Nuestro criterio para tomar la decisión es muy simple.

Situaciones en las que es adecuado utilizar:

• El número de tus microservicios ya ha superado los 5, y cada vez que modificas la configuración general, tienes que hacer ajustes en varios lugares.
• Con frecuencia se enfrentan picos de tráfico, y no es posible realizar una asignación flexible de recursos entre los diferentes servicios.
• El equipo de back-end tiene menos de 5 personas y no quieren desperdiciar tiempo escribiendo lógica general repetidamente.

Situaciones en las que no vale la pena complicarse:

• Solo tienes dos microservicios, y el tráfico ha sido constante y estable durante todo el tiempo. El uso de NGINX para la redirección no presenta ningún problema en estos momentos.
• Ninguno en todo el equipo entiende los fundamentos de Kubernetes; no intenten forzar la implementación de nuevas tecnologías solo por seguir la tendencia.

Dos consejos realmente útiles para un pequeño equipo que está empezando por primera vez

No hay necesidad de preocuparse por la elección de la solución; para equipos pequeños, simplemente pueden utilizar APIsIX o Kong, que son open source. Disponen de documentación completa y, en caso de problemas, generalmente se pueden encontrar soluciones al buscar en la web. No es necesario comprar la versión comercial, ya que la versión gratuita ofrece funcionalidades más que suficientes.

Antes de lanzar el servicio, dirija el 10% del tráfico a la nueva versión durante 24 horas para verificar si hay casos de tiempo de espera excesivo o solicitudes interceptadas por error. Solo cuando no haya problemas, transfiera todo el tráfico a la nueva versión de una vez. No transfiera todo el tráfico de inmediato.

Para terminar, respondiendo a una pregunta frecuente: ninguno de los tres desarrolladores de backend había investigado específicamente sobre los gateways antes, pero construimos el sistema en solo 2 días utilizando los documentos oficiales. Realmente no es tan complicado como podría parecer.