Con la puerta de enlace nativa de la nube, ahorramos un 38% en los costos de procesamiento de tráfico, pero casi arruinamos la cadena de suministro de productos frescos en Europa durante el Black Friday.

La reunión de análisis del gran evento del Black Friday de la semana pasada acaba de terminar, y nuestro equipo de tres personas encargado del backend de distribución de productos frescos en Europa todavía está preocupado: el día de la preventa, el 17% de las solicitudes de cadena de frío se devolvieron directamente con un error (429), lo que duplicó el número de quejas de los usuarios, y casi arruinamos el gran evento anual que habíamos estado preparando durante tres meses.

El problema surgió debido al uso de un gateway API tradicional durante dos años: establecimos un umbral de throttling común para dos interfaces clave, la resolución de direcciones y la reserva de la cadena de frío. El día del Black Friday, las solicitudes de resolución de direcciones se sobrepasaron, llenando completamente el cupo del gateway y impidiendo que las solicitudes de reserva pudieran ingresar. Siempre pensamos que cambiar de gateway era algo que solo los equipos grandes necesitaban considerar, pero después de este problema, nos dimos cuenta de que los gateways nativos en la nube podrían ser una opción más rentable para equipos más pequeños.

¿Qué es exactamente un gateway nativo de la nube?

En una frase: es la entrada de tráfico que opera dentro de un clúster K8s, y no es necesario alquilar servidores por separado para su implementación.Solo te preocupas por las reglas de enrutamiento y las estrategias de limitación de tráfico; el resto, como la elasticidad de los recursos y las actualizaciones de operación y mantenimiento, lo maneja el proveedor de servicios en la nube.La versión que estamos utilizando ahora puede soportar 20,000 solicitudes por segundo en un único instante, por lo que no es necesario realizar una planificación de capacidad por adelantado.

Los tres beneficios reales que obtuvimos después del cambio

Después del fallo del día de la preventa, tardamos 3 días en migrar a la puerta de enlace nativa de la nube. El día de la competencia principal del Black Friday no volvimos a tener problemas de bloqueo erróneo por throttling, y además hubo tres beneficios inesperados:

• El costo disminuyó directamente: antes alquilamos dos servidores de 4 núcleos 8G para ejecutar la puerta de enlace tradicional, más un operador y mantenimiento que pasaba 8 horas al mes para actualizar la versión, calculando el costo mensual de 1200 euros. Ahora la puerta de enlace nativa en la nube paga de acuerdo con el volumen de llamadas, que solo cuesta 740 euros al mes.Se ahorra directamente un 38% en los costos de procesamiento de tráfico.
• Finalmente entendí cómo funciona la estrategia de limitación de tráfico: el gateway anterior solo podía establecer umbrales de limitación de tráfico para todas las interfaces de manera global, pero ahora podemos definir reglas independientes para diferentes escenarios de negocio. Por ejemplo, podemos establecer que la interfaz de resolución de direcciones permita un máximo de 5000 solicitudes por segundo; incluso si esta interfaz es sobrecargada, no afectará las interfaces de pago o reserva que vengan después.
• El tiempo de handshake de HTTPS se ha reducido directamente a la mitad: anteriormente, nuestro certificado SSL se encontraba en nuestro propio servidor de gateway, lo que causaba retrasos de hasta 200 ms en las conexiones de usuarios de diferentes regiones de Europa. Ahora, los proveedores de servicios en la nube han almacenado el certificado en nodos de edge, lo que permite reducir los retrasos en la mayoría de las solicitudes a menos de 80 ms.

No te apresures a subir al coche, ya hemos pasado por esos dos problemas.

No se trata de que los gateways nativos de la nube sean únicamente ventajas; durante el proceso de implementación también encontramos dos problemas que casi nos obligaron a volver a empezar todo desde cero:

El primer problema es el retraso en el arranque en frío. Después de realizar las pruebas de carga el primer día, descubrimos que, después de 10 minutos sin solicitudes, el tiempo de respuesta de la primera oleada de solicitudes aumentaba repentinamente a más de 300 ms. Más tarde nos dimos cuenta de que las instancias elásticas del proveedor de servicios en la nube se iniciaban según se necesitaba, y era necesario establecer un número mínimo de instancias reservadas para las interfaces principales; de lo contrario, era muy probable que se produjeran tiempos de espera excesivos debido a un aumento repentino en el tráfico en momentos de inactividad.

El segundo punto son las limitaciones de los plugins personalizados. Anteriormente, escribimos nuestro propio plugin para la verificación de firmas de solicitudes y lo ejecutábamos en un gateway tradicional. Solo cuando lo cambiamos nos dimos cuenta de que el gateway nativo en la nube solo soportaba plugins en formato WebAssembly. Tuvimos que pasar dos días modificando el código para hacer la adaptación. Si tienes mucha lógica personalizada, es mejor que revises primero el rango de soporte de los plugins proporcionados por el fabricante.

¿Debería cambiarse o no? Basta con mirar estos dos criterios de juicio.

La situación en la que deberías cambiar es:

• El equipo tiene menos de 5 desarrolladores de backend y no cuenta con personal dedicado a operaciones y mantenimiento; no queremos dedicar tiempo al mantenimiento y actualización de los servidores de gateway.
• Las fluctuaciones en el tráfico son muy grandes; por ejemplo, durante las promociones, el tráfico puede ser de 3 a 10 veces mayor que el habitual. No queremos alquilar un montón de servidores de antemano, ya que de lo contrario se desperdiciaría dinero mientras están desocupados.

Situaciones en las que no deberías cambiar:

• Los requisitos de cumplimiento son especialmente estrictos; todo el tráfico debe pasar por servidores que tú mismo puedas controlar, y no se permite que utilice los nodos públicos de los proveedores de servicios en la nube.
• Tu gateway cuenta con mucha lógica personalizada y especial que los gateways nativos en la nube disponibles en el mercado no soportan. Modificarlo por tu cuenta resultaría más costoso que mantener el gateway tú mismo.

Tres pequeños consejos para quienes empiezan por primera vez

• No es necesario realizar el cambio completo de inmediato; primero dirijamos el 10% del tráfico al gateway nativo de la nube durante una semana y monitoremos si hay algún problema. Si todo está bien, entonces procederemos con la migración del tráfico completo. Al principio, comenzamos por cambiar la interfaz de resolución de direcciones, y solo después de asegurarnos de que no había problemas, continuamos con la migración del resto del tráfico.
• Es esencial establecer un número mínimo de instancias para las interfaces principales; no ahorre ese dinero. Ahora hemos reservado 2 instancias permanentes para cada una de las interfaces clave de reserva y pago en la cadena de frío, y ya no hemos tenido problemas de demoras al iniciar el servicio.
• No es necesario comprar la versión más avanzada; para la mayoría de las pequeñas y medianas empresas, las funciones de la versión básica son más que suficientes. La versión básica que estamos utilizando ahora no requiere costo adicional para un volumen de tráfico inferior a 20,000 solicitudes por segundo (QPS).

La última respuesta a la pregunta que más se ha hecho dentro del equipo es: ¿Se podría quedar atado a un proveedor de servicios en la nube?

Nuestra conclusión es: para un equipo de desarrollo backend de menos de 10 personas,La mejora en la eficiencia que se obtiene al estar vinculado con un proveedor de servicios en la nube es mucho mayor que el costo de construir todos los componentes desde cero.Cuando realmente llegue el momento de cambiar de proveedor de servicios en la nube y sea necesario realizar la migración, tendrás la energía suficiente para hacerlo. No te preocupes por eso ahora.