Estrategias de Lanzamiento de API con API Gateway
December 22, 2022
Una vez que hayas separado adecuadamente el despliegue y la liberación, el siguiente paso es elegir mecanismos para controlar la liberación progresiva de funciones. Es esencial seleccionar una estrategia de liberación que te permita reducir el riesgo en producción. Porque no importa cuánto pruebes una nueva versión de tu API antes de su liberación, la prueba real ocurre cuando finalmente la pones frente a los clientes.
Podemos reducir este riesgo realizando una prueba o experimento con una pequeña fracción del tráfico y verificando el resultado. Cuando el resultado es exitoso, se activa la liberación a todo el tráfico. Estrategias específicas se adaptan mejor a ciertos escenarios y requieren diferentes grados de servicios e infraestructura adicionales. En esta publicación, exploraremos 3 estrategias populares de liberación de API que utilizan un API Gateway en la actualidad.
Por qué usar un API Gateway en el despliegue de API
Un beneficio de migrar a una arquitectura basada en API es que podemos iterar rápidamente y desplegar nuevos cambios en nuestros servicios. También tenemos el concepto de tráfico y enrutamiento establecido con un API Gateway para la parte modernizada de la arquitectura. El API Gateway proporciona etapas que te permiten tener múltiples API desplegadas detrás del mismo gateway y es capaz de realizar actualizaciones en el lugar sin tiempo de inactividad. Usar un API Gateway te permite aprovechar las numerosas funciones de gestión de API del servicio, como autenticación, limitación de tasa, observabilidad (métricas importantes para las API), control de versiones múltiples de API y gestión de despliegues por etapas (desplegar una API en múltiples etapas como dev, test, stage y prod).
Las soluciones de API Gateway de código abierto (Apache APISIX y Traefik), Service Mesh (Istio y Linkerd) son capaces de realizar división de tráfico e implementar funcionalidades como Canary Release y Blue-Green deployment. Con las pruebas canary, puedes realizar un examen crítico de una nueva versión de una API seleccionando solo una pequeña porción de tu base de usuarios. Cubriremos la liberación canary en la siguiente sección.
Liberación Canary
Una liberación canary introduce una nueva versión de la API y dirige un pequeño porcentaje del tráfico a la canary. En los API gateways, la división de tráfico permite cambiar o migrar gradualmente el tráfico de una versión de un servicio objetivo a otra. Por ejemplo, una nueva versión, v1.1, de un servicio puede desplegarse junto a la original, v1.0. El cambio de tráfico te permite realizar pruebas canary o liberar tu nuevo servicio al principio solo enrutando un pequeño porcentaje del tráfico de usuarios, digamos 1%, a v1.1, y luego cambiando todo tu tráfico al nuevo servicio con el tiempo.
Esto te permite monitorear el nuevo servicio, buscar problemas técnicos, como un aumento en la latencia o las tasas de error, y buscar el impacto comercial deseado, como un aumento en los indicadores clave de rendimiento como la tasa de conversión de clientes o el valor promedio de compra. La división de tráfico te permite ejecutar pruebas A/B o multivariadas dividiendo el tráfico destinado a un servicio objetivo entre múltiples versiones del servicio. Por ejemplo, puedes dividir el tráfico 50/50 entre tus versiones v1.0 y v1.1 del servicio objetivo y ver cuál funciona mejor durante un período de tiempo específico. Aprende más sobre la función de división de tráfico en el Ingress Controller de Apache APISIX.
Cuando es apropiado, las liberaciones canary son una excelente opción, ya que el porcentaje de tráfico expuesto a la canary está altamente controlado. El compromiso es que el sistema debe tener un buen monitoreo para poder identificar rápidamente un problema y revertirlo si es necesario (lo cual puede automatizarse). Esta guía te muestra cómo usar Apache APISIX y Flagger para implementar rápidamente una solución de liberación canary.
Espejo de tráfico
Además de usar la división de tráfico para ejecutar experimentos, también puedes usar el espejo de tráfico para copiar o duplicar el tráfico y enviarlo a una ubicación adicional o a una serie de ubicaciones. Frecuentemente, con el espejo de tráfico, los resultados de las solicitudes duplicadas no se devuelven al servicio que llama o al usuario final. En su lugar, las respuestas se evalúan fuera de banda para verificar su corrección, como comparar los resultados generados por un servicio refactorizado y el existente, o se observan una selección de propiedades operativas mientras una nueva versión del servicio maneja la solicitud, como la latencia de respuesta o el uso de CPU.
Usar el espejo de tráfico te permite realizar una "liberación oscura" de servicios, donde el usuario no sabe sobre la nueva liberación, pero puedes observar internamente el efecto deseado.
Implementar el espejo de tráfico en el borde de los sistemas se ha vuelto cada vez más popular en los últimos años. APISIX ofrece el plugin proxy-mirror para reflejar las solicitudes de los clientes. Duplica el tráfico en línea real al servicio de espejo y permite un análisis específico del tráfico en línea o del contenido de la solicitud sin interrumpir el servicio en línea.
Blue-Green
Blue-green generalmente se implementa en un punto de la arquitectura que utiliza un enrutador, gateway o balanceador de carga, detrás del cual se encuentra un entorno completo blue y un entorno green. El entorno blue actual representa el entorno en vivo actual, y el entorno green representa la próxima versión de la pila. El entorno green se verifica antes de cambiar al tráfico en vivo, y al momento de la liberación, el tráfico se cambia de blue a green. El entorno blue ahora está "apagado", pero si se detecta un problema, es una reversión rápida. El próximo cambio iría de green a blue, oscilando desde la primera liberación en adelante.
Blue-green funciona bien debido a su simplicidad y es una de las mejores opciones de despliegue para servicios acoplados. También es más fácil gestionar servicios persistentes, aunque aún debes tener cuidado en caso de una reversión. También requiere el doble de recursos para poder ejecutar en frío en paralelo al entorno actualmente activo.
Gestión de tráfico con Argo Rollouts
Las estrategias discutidas añaden mucho valor, pero el despliegue en sí es una tarea que no querrías tener que gestionar manualmente. Aquí es donde una herramienta como Argo Rollouts es valiosa para demostrar prácticamente algunas de las preocupaciones discutidas.
Usando Argo, es posible definir un Rollout CRD (Definición de Recurso Personalizado) que representa la estrategia que puedes tomar para desplegar una nueva canary de tu API. Un CRD permite a Argo extender la API de Kubernetes para soportar el comportamiento de despliegue. Los CRD son un patrón popular con Kubernetes, y permiten al usuario interactuar con una API con la extensión para soportar diferentes características.
Puedes usar Apache APISIX y el Ingress Controller de Apache APISIX para la gestión de tráfico con Argo Rollouts. Esta guía te muestra cómo integrar ApisixRoute con Argo Rollouts usándolo como un balanceador de carga de round-robin ponderado.
Resumen
Con el auge del enfoque de Entrega Progresiva, y también los requisitos avanzados dentro de la Entrega Continua antes de esto, tener la capacidad de separar el despliegue y la liberación del servicio (y la API correspondiente) es una técnica poderosa. La capacidad de liberar servicios en canary y hacer uso de las funciones de división y espejo de tráfico del API Gateway puede proporcionar una ventaja competitiva a tu negocio tanto en la mitigación de riesgos de una mala liberación como en la comprensión más efectiva de los requisitos de tus clientes.