Escolher uma estratégia de implantação

Doze instâncias EC2 estão atrás de um Application Load Balancer. Você tem uma AMI nova que corrige um bug de log e, sem você saber, traz um driver de banco que vaza conexões sob carga. Em uns 40 minutos, o pool vai esgotar e as requisições vão começar a dar timeout.

Todas as estratégias de implantação desta lição entregam essa mesma AMI quebrada. O que elas mudam é quantas pessoas são afetadas antes de você perceber, e quanto tempo leva para desfazer. É disso que o assunto trata.

As duas perguntas por trás de toda estratégia

Tire o vocabulário do caminho e sobram 2 decisões.

Você muda os servidores que já tem, ou constrói servidores novos? Mudar o que já existe é barato e não deixa nada para onde voltar. Construir novos custa um segundo conjunto de capacidade e te dá uma versão conhecida ainda rodando enquanto você avalia a nova.

Quando a versão nova está viva, quanto tráfego chega nela de uma vez? Todo, uma fração crescente, ou uma fatia pequena e fixa que você escolheu arriscar.

Cada estratégia com nome é uma resposta específica a essas 2 perguntas. Quando você enxerga isso, os nomes deixam de ser uma lista para decorar e viram coordenadas.

All at once: a estratégia que você ganha de graça

Pare a aplicação em todo lugar, instale a versão nova, suba de novo. É o que um yum update seguido de restart faz numa frota, e é o que você tem por padrão quando ninguém configura nada.

É a mais rápida e a mais barata. Nada de instâncias extras, nada de encanamento de tráfego, nada de esperar batches. Para um worker de lote noturno, um ambiente de desenvolvimento ou uma ferramenta interna de uma instância só com janela de manutenção acordada, ela é a resposta certa e qualquer outra coisa é overengineering.

O preço é que existe uma janela em que nada atende, e o rollback é uma segunda implantação. Se suas 12 instâncias levam 4 minutos cada para reiniciar, desfazer uma release ruim custa mais 4 minutos fora do ar, além do tempo que você levou para perceber. Nada na estratégia foi desenhado para te ajudar a perceber.

Rolling: trocar tempo de implantação por disponibilidade

Divida a frota em batches e atualize um batch por vez. As instâncias do batch atual saem do load balancer, são atualizadas, passam por health check e voltam antes de o próximo batch começar.

Faça as contas naquelas 12 instâncias com batch de 25 por cento:

• O batch tem 3 instâncias, então são 4 batches.
• Enquanto um batch está fora, 9 instâncias atendem tráfego. Isso é 75 por cento de capacidade.
• O tempo total é mais ou menos 4 vezes (tempo de atualização mais tempo de health check), então uma implantação de 4 minutos por batch roda por 16 minutos em vez de 4.

Esse número de 75 por cento é a restrição de projeto, e é onde os times se machucam. Se 12 instâncias foram dimensionadas para o pico, então 9 instâncias no pico ficam 25 por cento curtas, e a própria implantação causa o pico de latência. O tamanho do batch não é uma configuração de conveniência, é uma decisão de capacidade que precisa valer na sua hora mais cheia, não na média.

A correção, quando dá para pagar, é subir um batch extra antes e encerrar ele no final. Você nunca cai abaixo de 100 por cento de capacidade em serviço, paga por 3 instâncias extras durante 16 minutos, e a implantação leva um batch a mais.

Agora a parte que subestimam. Durante a maior parte de uma implantação rolling, as duas versões estão atendendo requisições reais. As instâncias dos batches concluídos respondem com a versão nova enquanto os batches pendentes respondem com a antiga, e o load balancer não faz distinção. É tentador ler "gradual" como "seguro", mas gradual é exatamente o que cria a janela mista. Se a versão nova grava um registro num formato que a antiga não consegue interpretar, a implantação rolling não reduz o estrago: ela estica o período em que o estrago é possível.

O rollback segue o mesmo formato: para desfazer, você roda a frota de novo. Não existe ponteiro para mover, porque a versão antiga foi sobrescrita em todo lugar onde a implantação já passou.

Immutable e blue/green: construir primeiro, trocar depois

A alternativa é parar de tocar em servidores que estão rodando. Suba um conjunto novo e completo a partir da configuração nova, deixe ele se provar com health checks, e só então aposente os originais.

Immutable é essa ideia aplicada a um grupo de instâncias. Se o conjunto novo nunca fica saudável, você encerra ele e as instâncias originais seguem intactas, porque nunca foram modificadas. Uma implantação immutable que falha custa dinheiro e 20 minutos perdidos, e custa zero aos seus usuários.

Blue/green é a mesma ideia aplicada a um ambiente inteiro. Blue é a produção. Green é uma cópia paralela completa rodando a versão nova: instâncias próprias, target group próprio, health checks próprios. Quando o green parece certo, você move o ponteiro de tráfego do blue para o green. O blue continua rodando, ocioso, pelo tempo que você quiser manter um caminho de rollback.

O ponteiro é o truque inteiro, e o mecanismo dele decide a velocidade com que você desfaz:

Como o blue continua rodando, o rollback é mover um ponteiro em vez de reconstruir, e é isso que "rollback rápido" significa no vocabulário da prova. A conta é direta: durante a janela de implantação você paga por 2 ambientes completos.

Canary e linear: um dial no lugar do interruptor

Canary e linear não são formas diferentes de construir a versão nova. Elas assumem que você já construiu, exatamente como no blue/green, e mudam só o último passo: em vez de mover todo o tráfego de uma vez, você move uma fração controlada.

Canary move em 2 incrementos. Uma porcentagem pequena, digamos 10 por cento, vai para a versão nova. Você segura ali por um tempo definido enquanto observa taxa de erro e latência. Se os números se sustentam, os 90 por cento restantes vão atrás.

Linear move em passos iguais em intervalos iguais: 10 por cento a cada 2 minutos até tudo migrar.

O que você compra é uma medição. Health checks dizem que o processo está escutando numa porta; um canary diz que requisições reais de usuários reais estão sendo respondidas certo. O custo é que alguns usuários encontram o bug, por desenho, e a implantação passa a durar o tempo da sua janela de avaliação.

Ou seja, um canary só vale a pena quando 2 coisas são verdade: chega tráfego suficiente na fatia do canary para produzir um sinal legível, e você já decidiu de antemão qual métrica e qual limiar encerram a implantação. Um canary de 1 por cento num serviço com 20 requisições por minuto te dá umas 3 requisições para raciocinar. Isso é teatro, não evidência.

Aqui está a fronteira que a prova cutuca. Blue/green e canary rodam 2 ambientes, então contar ambientes não separa os dois. Blue/green minimiza por quanto tempo alguém fica exposto a uma versão ruim, tornando a troca instantânea e reversível. Canary minimiza quantas pessoas ficam expostas, segurando a maior parte do tráfego enquanto você observa. Um é interruptor, o outro é dial.

A comparação que importa

Leia a tabela como uma lista de preços. Capacidade é dinheiro. Exposição é impacto no usuário. Velocidade de rollback é o tempo que você passa atendendo uma versão que já sabe estar ruim. Você sempre paga com pelo menos um dos três.

Escolher uma

A decisão costuma ser forçada por uma restrição, não por preferência, então comece pelas restrições:

• Janela de manutenção é aceitável. All at once. É mais rápido e mais barato, e a sofisticação não compra nada.
• Zero downtime, sem orçamento para capacidade extra. Rolling. Dimensione o batch para a frota restante aguentar o pico.
• Capacidade total exigida o tempo todo, com algum orçamento. Rolling com batch extra, ou immutable.
• Rollback precisa ser medido em segundos. Blue/green, ou suas variantes com deslocamento de tráfego. Nada que reconstrua capacidade alcança esse patamar.
• Você precisa de evidência de tráfego real antes de se comprometer. Canary ou linear, com métrica e limiar nomeados.

Uma restrição passa por cima de todas as outras: 2 versões da aplicação conseguem rodar ao mesmo tempo? Se não conseguem, rolling, canary e linear estão fora da mesa, independente de orçamento, e a escolha fica entre uma janela de manutenção e uma troca blue/green.

A parte que nenhuma delas resolve

Blue/green costuma ser descrito como rollback sem risco, e para código de aplicação stateless isso é quase verdade. No momento em que estado entra na conta, deixa de ser, e é daí que vêm os incidentes reais.

O banco de dados normalmente é compartilhado. O green quase nunca ganha uma cópia própria dos dados de produção, porque uma cópia ficaria desatualizada na hora. Então blue e green falam com o mesmo banco, e qualquer mudança de schema vale para os dois. Mande uma migration que remove uma coluna que o código antigo lê e o caminho de rollback some: voltar para o blue passa a significar voltar para um código que não consegue consultar o próprio banco.

A disciplina é tornar mudanças de schema retrocompatíveis e separá-las do código que precisa delas. Adicione a coluna nova e comece a gravar nela enquanto o código antigo ignora. Implante o código que lê ela. Só depois que a versão nova estiver provada, numa release posterior, remova a coluna antiga. Mais lento, e mantém o ponteiro com significado.

Dados gravados durante a janela não voltam. Se o green atende por 10 minutos e grava 4.000 linhas em um formato novo, mover o ponteiro para o blue restaura o código antigo e deixa aquelas 4.000 linhas exatamente onde estão. Rollback de tráfego não é rollback de dados.

Estado de sessão precisa morar fora das instâncias. Um usuário no meio de um checkout no blue que cai no green precisa que a sessão dele exista lá. Se as sessões ficam na memória da instância, todas essas estratégias derrubam clientes no meio da transação, e a configuração de stickiness do load balancer só esconde isso até a instância sumir.

Vale dizer o engano com todas as letras, porque ele sobrevive ao primeiro blue/green da maioria das pessoas: uma troca instantânea de tráfego não é um desfazer instantâneo. Ela desfaz roteamento. Ela não desfaz gravações, migrations, conteúdo de cache nem mensagens já publicadas numa fila.

Dicas de prova

• "Implantação mais rápida" ou "um curto período de indisponibilidade é aceitável" aponta para all at once. É a resposta certa com mais frequência do que os candidatos esperam, porque eles leem simples como errado.
• "Sem downtime e sem custo adicional" é rolling. Acrescentar "precisa manter capacidade total o tempo todo" é o que transforma em rolling com batch adicional.
• "Reverter rapidamente" ou "voltar imediatamente se houver problema" significa que a versão antiga precisa continuar rodando: blue/green, ou um deslocamento de tráfego por peso. Qualquer resposta que reimplante a versão anterior está descrevendo um rollback lento.
• "Testar com uma pequena porcentagem do tráfego de produção" é canary. "Deslocar tráfego em incrementos iguais em intervalos iguais" é linear. As palavras que distinguem são porcentagem e incrementos, não o número de ambientes.
• Um cenário que menciona troca de DNS ou de CNAME e depois reclama que alguns usuários ainda chegam na versão antiga está testando TTL e cache de resolver, não falha de serviço.
• Fique atento a um detalhe de banco escondido numa questão de blue/green. Uma migration de schema na mesma release é a armadilha, e a resposta certa costuma ser tornar a mudança retrocompatível ou rodar ela como um passo anterior separado.
• Uma implantação immutable que falha deixa as instâncias originais atendendo. Uma rolling que falha deixa você com uma mistura de versões. Questões sobre o estado depois da falha estão testando exatamente essa diferença.

Leve uma frase desta lição: a estratégia que você escolhe é uma declaração sobre quanto você aceita gastar para encurtar o intervalo entre entregar uma versão ruim e conseguir desfazer. Você paga em dinheiro (um segundo ambiente), em tempo (um rollout mais lento) ou em usuários (alguém encontra o bug). Não existe opção que não pague nada.

A próxima lição transforma cada um desses formatos na configuração específica da AWS que o produz, que é onde a prova mora de verdade: porcentagens de instance refresh, update policies do CloudFormation, estratégias de implantação do ECS, aliases do Lambda e blue/green gerenciado do RDS.