Implementación de versiones Canary con Apache APISIX

En pocas palabras, la idea detrás de los lanzamientos canary es entregar una nueva versión de software solo a una fracción de los usuarios, analizar los resultados y decidir si continuar o no. Si los resultados no están alineados con las expectativas, retroceder; si es así, aumente la cantidad de usuarios expuestos hasta que todos los usuarios se beneficien de la nueva versión.

En esta publicación, me gustaría detallar brevemente esta introducción, explicar diferentes formas de definir la fracción y mostrar cómo ejecutarla con Apache APISIX.

Introducción a los lanzamientos canarios.

El término "canario" proviene de la industria minera del carbón. Durante la minería, no es raro que se liberen gases tóxicos: en un espacio pequeño y cerrado, puede significar una muerte rápida. Peor aún, el gas puede ser inodoro, por lo que los mineros lo respirarían hasta que fuera demasiado tarde para irse. El monóxido de carbono es bastante común en las minas de carbón y no es detectable por los sentidos humanos.

Por esta razón, los mineros trajeron canarios bajo tierra. Si el canario caía muerto repentinamente, había muchas posibilidades de que se hubiera roto esa bolsa de gas y ya era hora de abandonar el lugar.

Hace años, adoptamos este enfoque para lanzar una nueva versión de software. La analogía es la siguiente: los mineros son el equipo de operaciones que implementa la versión, el canario consta de todas las herramientas para medir el impacto de la liberación y el gas es un error (crítico).

La parte más crucial es que debe medir el impacto del lanzamiento, incluidas las tasas de falla, los códigos de estado HTTP, etc., y compararlos con los de la versión anterior. Está fuera del alcance de esta publicación, pero nuevamente, es fundamental si desea beneficiarse de las versiones canary. La segunda parte más importante es la capacidad de retroceder rápidamente si la nueva versión tiene errores.

Lanzamientos canarios frente a indicadores de funciones

Tenga en cuenta que las versiones canary no son la única forma de gestionar el riesgo de publicar código nuevo. Por ejemplo, las marcas de funciones son otra forma popular:

• El enfoque canary ofrece el conjunto completo de funciones en la nueva versión del componente.
• Los indicadores de funciones también implementan el componente, pero los parámetros de configuración dedicados permiten activar y desactivar cada función individualmente.

Los indicadores de funciones representan un enfoque más ágil (en el verdadero sentido de la palabra) hacia las reversiones. Si una característica de cada 10 tiene errores, no es necesario cancelar la implementación de la nueva versión; solo desactivas la función de errores. Sin embargo, este superpoder tiene el costo de una complejidad adicional del código base, independientemente de si depende de productos de terceros o lo implementa usted mismo.

Por otro lado, Canary requiere una canalización de implementación madura para poder implementar y cancelar la implementación a voluntad.

Aproximaciones a las liberaciones canarias

La idea detrás de las versiones canary es permitir que solo una fracción de usuarios acceda a la nueva versión. La mayoría de las definiciones canarias sólo definen "fracción" como un porcentaje de usuarios. Sin embargo, hay más.

El primer paso puede ser permitir que solo los usuarios examinados verifiquen que la implementación en el entorno de producción funciona como se esperaba. En este caso, puede reenviar sólo un conjunto específico de usuarios internos, por ejemplo , evaluadores, a la nueva versión. Si conoces a las personas de antemano y el sistema autentica a los usuarios, puedes configurarlo por identidad; de lo contrario, debe recurrir a alguna forma genérica, por ejemplo , encabezados HTTP - X-Canary: Let-Me-Go-To-v2 .

Recuerde que debemos monitorear los sistemas antiguos y nuevos para detectar discrepancias. Si no aparece nada, es un momento excelente para aumentar el grupo de usuarios reenviados a la nueva versión. Supongo que comes tu propia comida para perros, es decir ; Los miembros del equipo utilizan el software que están desarrollando. Si no tiene, por ejemplo, un sitio de comercio electrónico para automóviles de lujo, puede omitir esta sección.

Para aumentar la fracción de usuarios y al mismo tiempo limitar los riesgos, ahora podemos proporcionar indiscriminadamente la nueva versión a los usuarios internos. Podemos configurar el sistema para reenviar a la nueva versión según la IP del cliente para hacer esto. En una época en la que la gente trabajaba en el sitio, era fácil ya que sus IP estaban en un rango específico. El control remoto no cambia mucho ya que los usuarios probablemente accedan a la red de la empresa a través de una VPN.

Nuevamente, supervise y compare en este punto.

Los nueve metros completos

En este punto, todo debería funcionar como se espera para los usuarios internos, ya sean algunos o todos. Pero así como ningún plan sobrevive al contacto con el enemigo, ningún uso puede imitar toda la diversidad de una carga de trabajo de producción. En definitiva, debemos dejar que los usuarios habituales accedan a la nueva versión, pero de forma controlada, tal y como hemos ido aumentando progresivamente el número de usuarios hasta ahora: empezar con una pequeña fracción, monitorizarla y, si todo está bien, aumentar la fracción. .

Aquí se explica cómo hacerlo con Apache APISIX. Apache APISIX ofrece una arquitectura basada en complementos y proporciona un complemento que satisface nuestras necesidades, es decir, el complemento traffic-split .

El complemento traffic-split se puede utilizar para dirigir dinámicamente partes del tráfico a varios servicios Upstream.

Esto se hace configurando match , que son reglas personalizadas para dividir el tráfico, y weighted_upstreams , que es un conjunto de Upstreams a los que dirigir el tráfico.

-- tráfico dividido

Comencemos con algunos upstreams básicos, uno para cada versión:

 upstreams: - id: v1 nodes: "v1:8080": 1 - id: v2 nodes: "v2:8080": 1

Podemos usar el complemento traffic-split para reenviar la mayor parte del tráfico a v1 y una fracción a v2:

 routes: - id: 1 uri: "*" #1 upstream_id: v1 plugins: traffic-split: rules: - weighted_upstreams: #2 - upstream_id: v2 #3 weight: 1 #3 - weight: 99 #3

1. Definir una ruta general
2. Configurar cómo dividir el tráfico; aquí, pesas
3. Reenvíe el 99% del tráfico a v1 y el 1% a v1. Tenga en cuenta que los pesos son relativos entre sí. Para lograr 50/50, puedes establecer pesos 1 y 1, 3 y 3, 50 y 50, etc.

Nuevamente, monitoreamos todo y nos aseguramos de que los resultados sean los esperados. Luego, podemos aumentar la fracción del tráfico reenviado a v2, por ejemplo :

 routes: - id: 1 uri: "*" upstream_id: v1 plugins: traffic-split: rules: - weighted_upstreams: - upstream_id: v2 weight: 5 #1 - weight: 95 #1

1. Aumentar el tráfico a v2 al 5%

Tenga en cuenta que Apache APISIX recarga los cambios en el archivo anterior cada segundo. Por lo tanto, divide el tráfico casi en tiempo real. Alternativamente, puede utilizar la API de administración para lograr lo mismo.

Lanzamientos más controlados

En lo anterior, pasé de usuarios internos a una fracción de usuarios externos. Quizás liberar a todos los usuarios internos sea un riesgo demasiado grande en su organización y necesite aún más control. Tenga en cuenta que en este caso puede configurar aún más el complemento traffic-split .

 routes: - id: 1 uri: /* upstream_id: v1 plugins: traffic-split: rules: - match: - vars: [["http_X-Canary","~=","Let-Me-Go-To-v2"]] #1 - weighted_upstreams: - upstream_id: v2 weight: 5 - weight: 95

1. Solo divida el tráfico si el encabezado HTTP X-Canary tiene el valor configurado.

El siguiente comando siempre reenvía a v1:

 curl http://localhost:9080

El siguiente comando también reenvía siempre a v1:

 curl -H 'X-Canary: Let-Me-Go-To-v1' http://localhost:9080

El siguiente comando divide el tráfico según los pesos configurados, es decir , 95/5:

 curl -H 'X-Canary: Let-Me-Go-To-v2' http://localhost:9080

Conclusión

Esta publicación explica las versiones canary y cómo se puede configurar una a través de Apache APISIX. Puede comenzar con varias rutas con diferentes prioridades y pasar al complemento traffic-split . Este último incluso se puede configurar aún más para permitir casos de uso más complejos.

El código fuente completo de esta publicación se puede encontrar en GitHub .

Para llegar más lejos:

• Implementación de solución canary release basada en Apache APISIX
• Lanzamiento Canary en Kubernetes con Apache APISIX Ingress
• Lanzamiento fluido de Canary usando el controlador de ingreso APISIX con Flagger