O que indisponibilidade realmente significa

"Zero downtime" é uma afirmação que precisa de uma definição antes de poder ser testada, e a definição útil é mais estreita e mais exigente que a de costume.

Três coisas que as pessoas querem dizer com isso

O site nunca devolve um erro. Essa é a versão mais fraca e a mais fácil de alcançar.

Nenhuma requisição é recusada ou perdida. Essa é mais forte, porque inclui as requisições já em andamento quando o processo antigo recebe o pedido para parar.

Nenhum usuário percebe nada. Essa é a mais forte, e inclui coisas totalmente fora do ciclo de requisição: um formulário que estava aberto, uma página no meio de uma navegação do Turbo, um job em segundo plano feito pela metade.

A maioria das ferramentas de deploy entrega a primeira, promete a segunda e não trata da terceira.

As quatro janelas

Um deploy tem quatro momentos em que algo pode se perder, e eles precisam de respostas diferentes.

As requisições em andamento quando o contêiner antigo recebe a ordem de parar precisam poder terminar.

As requisições que chegam durante a troca precisam que o proxy tenha para onde mandá-las.

Os jobs que estão rodando quando o worker para precisam terminar ou ser repetidos com segurança.

O código antigo encontra um esquema novo. O curso de nível Sênior "Migrations: gh-ost" tratou disso em detalhe.

flowchart TB
  D["um deploy"] --> A["requisições em voo: precisam terminar"]
  D --> B["requisições chegando: o proxy precisa de alvo"]
  D --> C["jobs rodando: terminar ou repetir com segurança"]
  D --> E["código antigo, esquema novo: expandir e contrair"]
  A --> Z["as quatro, ou não é zero indisponibilidade"]
  B --> Z
  C --> Z
  E --> Z

Onde esta aplicação está em cada uma

O proxy cuida da segunda janela. O kamal-proxy mantém o contêiner antigo atendendo até o novo passar no /up, então nunca há um momento sem destino.

O Puma cuida da primeira, e a próxima lição trata de como.

A terceira é a interessante aqui. O plugin :solid_queue roda o supervisor de jobs dentro do Puma, então parar o Puma para o worker de jobs, e o esvaziamento das requisições e o dos jobs são o mesmo desligamento.

A quarta é uma disciplina, não um mecanismo, e é a única que nenhuma ferramenta faz por você.

Por que a definição importa

Um deploy que não devolve erros enquanto mata em silêncio um job feito pela metade não alcançou zero downtime. Ele alcançou zero downtime visível, e a diferença aparece depois como dados errados.

Ser específico sobre quais das quatro janelas você fechou é a habilidade inteira. "Fazemos deploy sem downtime" é uma afirmação. "As requisições em andamento terminam, os jobs são repetidos pelo menos uma vez, e nunca publicamos uma mudança de esquema que quebre código" é uma descrição.

Pontos-chave

• Zero downtime tem três significados, e a maioria das ferramentas entrega o mais fraco e promete o do meio.
• Há quatro janelas: requisições em andamento, requisições chegando, jobs rodando, e código antigo com esquema novo.
• O kamal-proxy fecha a janela das requisições que chegam mantendo o contêiner antigo até o /up passar.
• O Solid Queue dentro do Puma faz do esvaziamento das requisições e dos jobs um só desligamento.
• Zero downtime visível e zero downtime são diferentes, e a diferença aparece depois como dados ruins.