Em vez disso, este post é sobre como implantamos um serviço Java altamente sofisticado, um serviço pesado que é desenvolvido ativamente diariamente, para milhares de servidores em nossos 7 data centers ao redor do mundo.

Então qual é o problema? Não é suficiente pegar uma lista de servidores, obter a versão para implantar e executá-la com uma ferramenta de automação como a ansible? 

Bem, não é tão simples quanto parece. Este serviço atende às recomendações e responde a centenas de milhares de solicitações por segundo. O serviço precisa ser rápido - tão rápido que seu p95 deve ficar abaixo de 500 milissegundos por solicitação. O que significa que não podemos ter nenhum tempo de inatividade, ou mesmo permitir respostas mais lentas.

Além disso, é essencial evitar a instalação de uma versão com defeito. Uma versão defeituosa pode levar a tempo de inatividade ou desempenho degradado, o que pode resultar diretamente em perda de receita. Por esse motivo, temos vários gateways de teste durante o desenvolvimento - para ajudar a evitar uma versão ruim. No entanto, com base em nossa experiência, às vezes quando o software atende à produção, coisas inesperadas (ruins) acontecem - e precisamos estar prontos para evitar isso. Outro requisito importante é implantar durante o horário comercial, quando a maioria dos engenheiros estará disponível para ajudar caso algo dê errado. 

Então, como fazemos isso? 

Etapa 1: hoje é dia de implantação?

A primeira coisa que queremos fazer é verificar se hoje é um dia de implantação. O requisito é implantar durante o horário de trabalho; portanto, se for um fim de semana ou feriado, pularemos a implantação.

Etapa 2: a versão de hoje é válida?

É um dia de implantação e queremos saber que o código é válido e não causará problemas de produção. É por isso que nosso primeiro passo é o teste canário . Nesta fase, implantamos a nova versão em uma única máquina em cada um dos nossos 7 centros de dados em todo o mundo. Depois que o serviço estiver pronto, deixamos que ele funcione com tráfego real por uma hora. Durante essa hora, reunimos várias métricas- do servidor recém-implantado, bem como de um servidor com a versão antiga. Esses servidores devem ter as mesmas especificações de hardware; além disso, também reiniciamos a versão antiga para garantir que os ambientes sejam o mais iguais possível. Quando a hora acabar, comparamos os resultados. Cada métrica tem um limite bem definido. Se as métricas recém-coletadas estiverem dentro dos limites desses limites, podemos continuar para o próximo estágio. Se a nova versão se comportar mal, paramos, alertamos os desenvolvedores relevantes e analisamos os problemas. Após as análises, ainda podemos ir de qualquer maneira: interromper a implantação (acontecerá automaticamente) ou aprovar manualmente.

Etapa 3: verificação do data center - parte 1

A nova versão parece estar correta - pelo menos o que podemos verificar em 1 hora - e decidimos continuar com a implantação. No entanto, ainda queremos 'jogar pelo seguro'. Entre no estágio 3: verificação do centro de dados. Começamos a implantar lentamente em apenas um de nossos data centers. O primeiro data center é cuidadosamente escolhido pelos engenheiros de produção. Ele precisa estar fora do horário de pico nessa área geográfica específica, mas ainda tem tráfego suficiente para que possamos verificar. 

O procedimento de implantação em um único data center é assim:

1. Obtenha a lista de servidores a serem implantados
2. Calcular o tamanho do lote do servidor (veja abaixo)
3. Para cada servidor no lote
   1. Silenciar todos os alertas
   2. Pare a versão antiga e remova-a
   3. Instale a nova versão
   4. Iniciar o serviço
   5. Verifique se o serviço foi iniciado corretamente
   6. Anular todos os alertas
4. Execute uma verificação em lote para verificar várias métricas do domínio
5. Aguarde um minuto para o próximo lote do servidor
6. Repita até que nenhum servidor seja deixado

Quando a implantação no data center termina, entramos na fase de validação - mas primeiro, vamos voltar ao cálculo do lote do servidor.

Vamos fazer algumas contas

Como mencionado acima, quando implantamos a nova versão, não queremos afetar nossa capacidade de atender solicitações no tempo de resposta apropriado (= 500 milissegundos). Portanto, desenvolvemos uma fórmula que nos dirá quantos servidores podemos tirar do pool do data center sem causar "ruído". A fórmula fica assim:

Onde:

• X é a quantidade de servidores que podemos parar no momento.
• S é a quantidade total de servidores em funcionamento no datacenter.
• Rtotal é a quantidade total de solicitações no datacenter.
• RTavg é o tempo médio de resposta por solicitação.
• RTmax é o limite crítico para o tempo de resposta.
• Threads é a quantidade de threads que usamos por servidor.

Quando obtemos o X, normalizamos para que não paremos muitos servidores fora do horário de pico - ou poucos servidores nos horários de pico.

 Cálculo do tamanho do lote de 3 a 10 de junho

Etapa 3: verificação do data center - parte 2

OK - implantamos o primeiro data center e agora queremos validar se ele se comporta corretamente. Pausamos a implantação por uma hora e realizamos várias verificações. Os importantes são:

• Verifique se o tempo de resposta não aumentou.
• Verifique se os logs do servidor não contêm erros incomuns. 

Essas métricas são monitoradas periodicamente, independentemente do fluxo de implantação. Para detectar problemas de produção mais rapidamente, integramos essas verificações ao fluxo.

Qualquer problema que surgir neste momento gera um alerta e pausa o fluxo, até que seja aprovado manualmente ou seja anulado manual ou automaticamente.

Etapa 4: Nova versão para todos

Quando obtemos a “luz verde” da primeira implantação e verificação do data center, o fluxo continuará automaticamente a implantar o restante dos data centers em paralelo. 

Entregue valor e qualidade em 6 etapas

Deseja criar seu próprio processo de implantação? Sugerimos implementar as seguintes etapas:

1. Teste seu código continuamente - embora ainda não tenha sido mencionado, a revisão do código é obrigatória e os testes de unidade e integração são uma parte crucial da validação do código.
2. Colete métricas - tanto para a implantação quanto para o serviço de produção - o tempo todo.
3. Crie um processo que possa validar o novo código em produção com dados / tráfego reais. Compare com as métricas que você coleta.
4. Defina o ritmo adequado para a implantação - você provavelmente deseja que seja dinâmico. Descubra o ritmo certo para suas necessidades específicas.
5. Valide continuamente que o novo código não quebra nada.
6. Melhorar continuamente. 

Tecnologia utilizada

Uma observação sobre as ferramentas que usamos para criar o fluxo. O serviço é escrito em Java e compactado como rpm. A lógica do fluxo de implantação é escrita com o pipeline do Jenkins , principalmente o Groovy, com algumas chamadas para comandos do shell ( yum install, por exemplo). Usamos Grafana e Prometheus para monitoramento e métricas.

Máxima comunicação com proteção ao extremo? Avance Network: A verdadeira rede social junte-se a nós