Estratégias de Lançamento de API com API Gateway
December 22, 2022
Depois de separar adequadamente implantação e lançamento, o próximo passo é escolher mecanismos para controlar o lançamento progressivo de funcionalidades. É essencial selecionar uma estratégia de lançamento que permita reduzir o risco em produção. Por mais que você teste uma nova versão da sua API antes do lançamento, o teste real ocorre quando você finalmente a coloca em frente aos clientes.
Podemos reduzir esse risco realizando um teste ou experimento com uma pequena fração do tráfego e verificando o resultado. Quando o resultado é bem-sucedido, o lançamento para todo o tráfego é acionado. Estratégias específicas se adequam melhor a determinados cenários e exigem diferentes graus de serviços e infraestrutura adicionais. Neste post, exploraremos 3 estratégias populares de lançamento de API que utilizam um API Gateway atualmente.
Por que usar um API Gateway na implantação de APIs
Um dos benefícios de migrar para uma arquitetura baseada em API é a capacidade de iterar rapidamente e implantar novas alterações em nossos serviços. Também temos o conceito de tráfego e roteamento estabelecido com um API Gateway para a parte modernizada da arquitetura. O API Gateway fornece estágios que permitem ter várias APIs implantadas por trás do mesmo gateway e é capaz de realizar atualizações in-loco sem tempo de inatividade. O uso de um API Gateway permite aproveitar os diversos recursos de gerenciamento de API do serviço, como autenticação, limitação de taxa, observabilidade (métricas importantes para APIs), versionamento múltiplo de APIs e gerenciamento de implantação em estágios (implantar uma API em vários estágios, como dev, teste, stage e prod).
Soluções de API Gateway de código aberto (Apache APISIX e Traefik), Service Mesh (Istio e Linkerd) são capazes de realizar divisão de tráfego e implementar funcionalidades como Canary Release e Blue-Green deployment. Com o teste canário, você pode examinar criticamente uma nova versão de uma API selecionando apenas uma pequena parte da sua base de usuários. Cobriremos o lançamento canário na próxima seção.
Lançamento Canário
Um lançamento canário introduz uma nova versão da API e direciona uma pequena porcentagem do tráfego para o canário. Em gateways de API, a divisão de tráfego possibilita a migração gradual do tráfego de uma versão de um serviço de destino para outra. Por exemplo, uma nova versão, v1.1, de um serviço pode ser implantada ao lado da versão original, v1.0. O deslocamento de tráfego permite que você teste ou lance seu novo serviço inicialmente direcionando apenas uma pequena porcentagem do tráfego do usuário, digamos 1%, para v1.1, e depois migrando todo o tráfego para o novo serviço ao longo do tempo.
Isso permite que você monitore o novo serviço, procure por problemas técnicos, como aumento de latência ou taxas de erro, e verifique o impacto desejado nos negócios, como um aumento em indicadores-chave de desempenho, como a taxa de conversão de clientes ou o valor médio de checkout de compras. A divisão de tráfego permite que você execute testes A/B ou multivariados, dividindo o tráfego destinado a um serviço de destino entre várias versões do serviço. Por exemplo, você pode dividir o tráfego 50/50 entre suas versões v1.0 e v1.1 do serviço de destino e ver qual desempenha melhor em um período específico. Saiba mais sobre o recurso de divisão de tráfego no Apache APISIX Ingress Controller.
Quando apropriado, os lançamentos canários são uma excelente opção, pois a porcentagem de tráfego exposta ao canário é altamente controlada. A compensação é que o sistema deve ter um bom monitoramento em vigor para identificar rapidamente um problema e reverter, se necessário (o que pode ser automatizado). Este guia mostra como usar Apache APISIX e Flagger para implementar rapidamente uma solução de lançamento canário.
Espelhamento de Tráfego
Além de usar a divisão de tráfego para executar experimentos, você também pode usar o espelhamento de tráfego para copiar ou duplicar o tráfego e enviá-lo para um local adicional ou uma série de locais. Frequentemente, com o espelhamento de tráfego, os resultados das solicitações duplicadas não são retornados ao serviço chamador ou ao usuário final. Em vez disso, as respostas são avaliadas fora de banda para verificar a correção, como comparar os resultados gerados por um serviço refatorado e existente, ou observar uma seleção de propriedades operacionais enquanto uma nova versão do serviço processa a solicitação, como latência de resposta ou CPU necessária.
O uso do espelhamento de tráfego permite que você faça um "lançamento escuro" de serviços, onde o usuário é mantido no escuro sobre o novo lançamento, mas você pode observar internamente o efeito desejado.
A implementação do espelhamento de tráfego na borda dos sistemas tornou-se cada vez mais popular ao longo dos anos. O APISIX oferece o plugin proxy-mirror para espelhar solicitações de clientes. Ele duplica o tráfego online real para o serviço de espelhamento e permite uma análise específica do tráfego online ou do conteúdo da solicitação sem interromper o serviço online.
Blue-Green
O Blue-green geralmente é implementado em um ponto da arquitetura que usa um roteador, gateway ou balanceador de carga, por trás do qual está um ambiente completo azul e um ambiente verde. O ambiente azul atual representa o ambiente ativo atual, e o ambiente verde representa a próxima versão da pilha. O ambiente verde é verificado antes de ser alternado para o tráfego ativo, e no momento do lançamento, o tráfego é alternado de azul para verde. O ambiente azul agora está "desligado", mas se um problema for detectado, é uma reversão rápida. A próxima alteração iria de verde para azul, oscilando desde o primeiro lançamento em diante.
O Blue-green funciona bem devido à sua simplicidade e é uma das melhores opções de implantação para serviços acoplados. Também é mais fácil gerenciar serviços persistentes, embora você ainda precise ter cuidado em caso de reversão. Ele também requer o dobro de recursos para poder rodar em paralelo ao ambiente ativo.
Gerenciamento de Tráfego com Argo Rollouts
As estratégias discutidas agregam muito valor, mas o próprio rollout é uma tarefa que você não gostaria de ter que gerenciar manualmente. É aqui que uma ferramenta como Argo Rollouts é valiosa para demonstrar praticamente algumas das preocupações discutidas.
Usando o Argo, é possível definir um Rollout CRD (Custom Resource Definition) que representa a estratégia que você pode adotar para lançar um novo canário da sua API. Um CRD permite que o Argo estenda a API do Kubernetes para suportar comportamentos de rollout. CRDs são um padrão popular com Kubernetes e permitem que o usuário interaja com uma API com a extensão para suportar diferentes funcionalidades.
Você pode usar o Apache APISIX e o Apache APISIX Ingress Controller para gerenciamento de tráfego com Argo Rollouts. Este guia mostra como integrar ApisixRoute com Argo Rollouts, usando-o como um balanceador de carga round-robin ponderado.
Resumo
Com o aumento da abordagem de Entrega Progressiva, e também dos requisitos avançados dentro da Entrega Contínua antes disso, ter a capacidade de separar a implantação e o lançamento de serviços (e a API correspondente) é uma técnica poderosa. A capacidade de lançar serviços de forma canária e utilizar recursos de divisão e espelhamento de tráfego do API Gateway pode fornecer uma vantagem competitiva ao seu negócio, tanto na mitigação de riscos de um lançamento ruim quanto na compreensão mais eficaz das necessidades dos seus clientes.