Implementando versões Canary com Apache APISIX

Em poucas palavras, a ideia por trás dos lançamentos canário é entregar uma nova versão de software para apenas uma fração dos usuários, analisar os resultados e decidir se deve prosseguir ou não. Se os resultados não estiverem alinhados com as expectativas, retroceda; se forem, aumente o número de usuários expostos até que todos os usuários se beneficiem da nova versão.

Neste post, gostaria de detalhar brevemente esta introdução, explicar diferentes formas de definir a fração e mostrar como executá-la com Apache APISIX.

Introdução aos lançamentos canário

O termo "canário" tem origem na indústria de mineração de carvão. Durante a mineração, não é incomum liberar gases tóxicos: em um espaço pequeno e fechado, isso pode significar morte rápida. Pior ainda, o gás pode ser inodoro, então os mineiros o respirariam até que fosse tarde demais para partir. O monóxido de carbono é bastante comum nas minas de carvão e não é detectável pelos sentidos humanos.

Por esta razão, os mineiros trouxeram canários para o subsolo. Se o canário caísse morto de repente, havia grandes chances de que tal bolsa de gás tivesse sido rompida e já era hora de deixar o local.

Anos atrás, trouxemos essa abordagem para lançar uma nova versão de software. A analogia é a seguinte: os mineradores são a equipe de operações que implanta a versão, o canário consiste em todas as ferramentas para medir o impacto do lançamento e o gás é um bug (crítico).

A parte mais importante é que você precisa medir o impacto do lançamento, incluindo taxas de falha, códigos de status HTTP, etc., e compará-los com os da versão anterior. Está fora do escopo desta postagem, mas, novamente, é fundamental se você quiser se beneficiar dos lançamentos canário. A segunda parte mais importante é a capacidade de reverter rapidamente se a nova versão apresentar bugs.

Lançamentos Canary vs. sinalizadores de recursos

Observe que as versões canário não são a única maneira de gerenciar o risco de lançar novo código. Por exemplo, sinalizadores de recursos são outra forma popular:

• A abordagem canário oferece o conjunto completo de recursos na nova versão do componente
• Os sinalizadores de recursos também implantam o componente, mas parâmetros de configuração dedicados permitem ativar e desativar cada recurso individualmente

Os sinalizadores de recursos representam uma abordagem mais ágil (no verdadeiro sentido da palavra) em relação às reversões. Se um dos 10 recursos apresentar bugs, você não precisará remover a implantação da nova versão; você apenas desativa o recurso de buggy. No entanto, esse superpoder tem o custo de uma complexidade adicional de base de código, independentemente de você confiar em produtos de terceiros ou implementá-los sozinho.

Por outro lado, o canary requer um pipeline de implantação maduro para poder implantar e cancelar a implantação à vontade.

Abordagens para lançamentos canário

A ideia por trás dos lançamentos canário é permitir que apenas uma fração dos usuários acesse a nova versão. A maioria das definições canário define apenas "fração" como uma porcentagem de usuários. No entanto, há mais do que isso.

A primeira etapa pode ser permitir que apenas usuários verificados verifiquem se a implantação no ambiente de produção funciona conforme o esperado. Neste caso, você poderá encaminhar apenas um conjunto específico de usuários internos, por exemplo , testadores, para a nova versão. Se você conhece as pessoas com antecedência e o sistema autentica os usuários, você pode configurá-lo por identidade; caso contrário, você precisará recorrer a alguma forma genérica, por exemplo , cabeçalhos HTTP - X-Canary: Let-Me-Go-To-v2 .

Lembre-se de que devemos monitorar os sistemas antigos e novos para analisar as discrepâncias. Se nada aparecer, é um excelente momento para aumentar o pool de usuários encaminhados para a nova versão. Presumo que você coma sua própria comida de cachorro, ou seja ; os membros da equipe usam o software que estão desenvolvendo. Se você não tem, por exemplo, um site de comércio eletrônico para carros de luxo, pode pular esta seção.

Para ampliar a fração de usuários e ao mesmo tempo limitar os riscos, podemos agora fornecer indiscriminadamente a nova versão aos usuários internos. Podemos configurar o sistema para encaminhar para a nova versão com base no IP do cliente para fazer isso. Numa época em que as pessoas trabalhavam no local, era fácil, pois seus IPs estavam em uma faixa específica. O remoto não muda muito, já que os usuários provavelmente acessam a rede da empresa por meio de uma VPN.

Novamente, monitore e compare neste ponto.

Todas as nove jardas

Neste ponto, tudo deve funcionar conforme o esperado para os usuários internos, sejam alguns ou todos. Mas assim como nenhum plano sobrevive ao contato com o inimigo, nenhum uso pode imitar toda a diversidade de uma carga de trabalho de produção. Resumindo, precisamos deixar que usuários regulares acessem a nova versão, mas de forma controlada, assim como aumentamos gradativamente o número de usuários até agora: comece com uma pequena fração, monitore e se estiver tudo bem, aumente a fração .

Veja como fazer isso com Apache APISIX. Apache APISIX oferece uma arquitetura baseada em plugin e fornece um plugin que atende às nossas necessidades, ou seja, o plugin traffic-split .

O plug-in traffic-split pode ser usado para direcionar dinamicamente partes do tráfego para vários serviços Upstream.

Isso é feito configurando match , que são regras personalizadas para divisão de tráfego, e weighted_upstreams que é um conjunto de Upstreams para direcionar o tráfego.

- divisão de tráfego

Vamos começar com alguns upstreams básicos, um para cada versão:

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

Podemos usar o plugin traffic-split para encaminhar a maior parte do tráfego para v1 e uma fração para 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. Defina uma rota abrangente
2. Configure como dividir o tráfego; aqui, pesos
3. Encaminhe 99% do tráfego para v1 e 1% para v1. Observe que os pesos são relativos entre si. Para atingir 50/50, você pode definir os pesos 1 e 1, 3 e 3, 50 e 50, etc.

Novamente, monitoramos tudo e garantimos que os resultados sejam os esperados. Então, podemos aumentar a fração do tráfego encaminhado para v2, por exemplo :

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

1. Aumente o tráfego para v2 para 5%

Observe que o Apache APISIX recarrega as alterações no arquivo acima a cada segundo. Conseqüentemente, você divide o tráfego quase em tempo real. Alternativamente, você pode usar a API Admin para conseguir o mesmo.

Lançamentos mais controlados

Acima, mudei de usuários internos para uma fração de usuários externos. Talvez liberar para todos os usuários internos seja um risco muito grande para sua organização e você precise de ainda mais controle. Observe que você pode configurar ainda mais o plugin traffic-split neste caso.

 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. Divida o tráfego apenas se o cabeçalho HTTP X-Canary tiver o valor configurado.

O seguinte comando sempre encaminha para v1:

 curl http://localhost:9080

O comando a seguir também sempre encaminha para v1:

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

O comando a seguir divide o tráfego de acordo com os pesos configurados, ou seja , 95/5:

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

Conclusão

Esta postagem explicou as versões canary e como você pode configurá-las por meio do Apache APISIX. Você pode começar com várias rotas com prioridades diferentes e passar para o plugin traffic-split . Este último pode ainda ser configurado para permitir casos de uso mais complexos.

O código-fonte completo desta postagem pode ser encontrado no GitHub .

Ir adiante:

• Implementação de solução de lançamento canário baseada em Apache APISIX
• Lançamento Canary no Kubernetes com Apache APISIX Ingress
• Liberação suave do Canary usando APISIX Ingress Controller com Flagger