De erros de 13% nas solicitações durante o Black Friday para zero falhas de serviço: economizamos 60% dos custos com servidores graças à implantação em contêineres

No Black Friday do ano passado, nosso serviço de resolução de endereços literalmente entrou em colapso: 13% das solicitações geraram erros de tipo 429, e o nosso departamento de atendimento ao cliente recebeu mais de 300 reclamações de lojistas. Três servidores de backend trabalharam ininterruptamente por 24 horas para superar o pico de tráfego. Naquela época, nosso serviço estava rodando em apenas dois servidores cloud com configurações fixas, e qualquer ajuste de escala era feito manualmente, alterando as configurações dos servidores. Quando os novos instâncias estavam prontos, o pico de tráfego já havia passado.

Primeiro, vamos explicar o que é a implantação em contêineres.

Em outras palavras, é como empacotar todo o seu código, bibliotecas de dependência e arquivos de configuração em um “contêiner” padronizado com tamanho variando de alguns MB a centenas de MB. Assim, não importa em qual servidor o código esteja sendo executado, o ambiente de execução será 100% consistente. O tamanho inicial do nosso image do serviço de resolução de endereços que foi empacotado foi...187MBO processo de pull para iniciar o sistema leva no máximo 10 segundos.

Os 3 principais benefícios que realmente obtivemos

• A automação de escala realmente salvou a situação: neste ano, o tráfego durante o Black Friday aumentou em 3 vezes, e o sistema automaticamente ativou 27 instâncias de contêineres. Após o pico, o número de instâncias foi reduzido para 3, sem nenhuma intervenção humana, e a taxa de erros caiu para menos de 0,1%.
• O bug de incompatibilidade de ambientes desapareceu completamente: o problema misterioso que não apresentava problemas quando executado localmente, mas que causava falhas assim que o sistema era lançado na produção, representava 40% do total de nossos bugs. Depois da migração para os containers, esses problemas não ocorreram mais nem uma vez.
• Custos com servidores reduzidos pela metade: Antes, para suportar os picos de uso, alugávamos 8 servidores de alta configuração o ano todo, com uma taxa de utilização média de apenas 15%. Agora, pagamos de acordo com o uso real, o que resulta em uma economia de 60% nos gastos com servidores ao longo do ano.

Não olhe apenas para os benefícios; esses problemas nós realmente enfrentamos de perto.

Quando começamos a usar o container, para economizar trabalho, armazenamos todos os logs e arquivos temporários dentro dele. No entanto, um instante em que o container foi automaticamente desativado, todos os logs de solicitações dos últimos 3 dias foram perdidos, e levar dois dias inteiros para recuperar esses dados. Outra vez, incluímos muitas dependências desnecessárias no image, o que fez com que o tempo de inicialização aumentasse de 10 segundos para 2 minutos. Quando houve um aumento súbito no tráfego, não conseguimos expandir a capacidade a tempo, e quase tivemos outro problema.

O que mais facilmente é ignorado são os problemas de permissões: inicialmente concedemos aos containers o privilégio de root, o que mais tarde foi explorado por programas de mineração, que consumiram 30% dos recursos do CPU. Demorou uma semana para percebermos isso através dos sistemas de monitoramento.

Pense bem se realmente deve usá-lo.

Se você for parte de uma pequena equipe de pessoas e estiver desenvolvendo uma ferramenta interna cujo tráfego é muito estável, com apenas 1 ou 2 serviços, realmente não há necessidade de se dar ao trabalho de criar algo do zero. Alugar um servidor é a solução mais prática.

Mas se o tráfego do seu serviço for muito instável, você precisar lançar atualizações com frequência, os diferentes membros da equipe estiverem desenvolvendo em ambientes que não se comunicam bem entre si, ou você já estiver se preocupando com o desperdício de recursos em servidores inutilizados, então o deploy em contêineres definitivamente vale a pena que você dedique uma semana para testar.

3 dicas específicas para quem está começando

• Não comece direto com clusters K8S; primeiro use Docker Compose para implementar uma configuração de deploy em um único servidor. Entenda bem os processos de empacotamento, execução e montagem de logs. Foi assim que procedemos nos primeiros 3 meses, e foi mais do que suficiente.
• Ao criar a imagem pela primeira vez, segui o “princípio do mínimo”: incluí apenas as dependências necessárias para a execução do sistema. Utilizando a imagem base Alpine, consegui reduzir o tamanho da imagem em mais da metade.
• Todos os dados e logs gerados devem ser armazenados em volumes de armazenamento externos ao container, e nunca dentro do próprio container. Isso está escrito no início das normas operacionais da sua equipe.

Perguntas comuns

Pergunta: Ninguém na nossa equipe entende sobre contêineres, será que o custo de aprendizado será muito alto?
Para o uso básico, basta gastar 2 dias lendo os documentos de introdução oficiais para fazer funcionar o primeiro serviço. Quanto à configuração mais avançada do cluster, você pode aprender sobre ela quando precisar. Não há problema em aprender isso mais tarde.

Pergunta: Será muito problemático migrar os serviços existentes para containers?
Nossos 3 serviços de backend foram totalmente migrados em uma semana, e a maior parte do tempo foi gasta na organização das dependências; o tempo real gasto para escrever os arquivos Dockerfile foi de menos de 1 dia.