Este artigo contém alguns padrões comuns para ajudar os engenheiros a trabalhar com serviços de grande escala acessados por milhões de usuários.
Na experiência do autor, esta não é uma lista exaustiva, mas na verdade efetivo conselho. Então, vamos começar.
Traduzido com suporte .
Primeiro nível
As medidas listadas abaixo são relativamente simples de implementar, mas têm um impacto elevado. Se você ainda não experimentou, ficará surpreso com as melhorias significativas.
Infraestrutura como código
A primeira parte do conselho é implementar a infraestrutura como código. Isso significa que você deve ter uma forma programática de implantar toda a infraestrutura. Parece complicado, mas na verdade estamos falando do seguinte código:
Implantação de 100 máquinas virtuais
- com Ubuntu
- 2 GB de RAM cada
- eles terão o seguinte código
- com esses parâmetros
Você pode rastrear alterações em sua infraestrutura e revertê-las rapidamente usando o controle de versão.
O modernista que há em mim diz que você pode usar o Kubernetes/Docker para fazer tudo isso, e ele está certo.
Além disso, você pode fornecer automação usando Chef, Puppet ou Terraform.
Integração e entrega contínuas
Para criar um serviço escalável, é importante ter um pipeline de construção e teste para cada solicitação pull. Mesmo que o teste seja muito simples, pelo menos garantirá que o código que você implanta seja compilado.
Cada vez nesta fase você responde à pergunta: meu assembly compilará e passará nos testes, é válido? Isso pode parecer um nível baixo, mas resolve muitos problemas.
Não há nada mais bonito do que ver esses carrapatos
Para esta tecnologia você pode avaliar Github, CircleCI ou Jenkins.
Balanceadores de carga
Portanto, queremos executar um balanceador de carga para redirecionar o tráfego e garantir carga igual em todos os nós ou que o serviço continue em caso de falha:
Um balanceador de carga geralmente faz um bom trabalho na distribuição do tráfego. A melhor prática é desequilibrar para não ter um único ponto de falha.
Normalmente, os balanceadores de carga são configurados na nuvem que você usa.
RayID, ID de correlação ou UUID para solicitações
Você já encontrou um erro de aplicativo com uma mensagem como esta: "Algo deu errado. Salve este ID e envie para nossa equipe de suporte"?
Um identificador exclusivo, ID de correlação, RayID ou qualquer uma das variações é um identificador exclusivo que permite rastrear uma solicitação durante todo o seu ciclo de vida. Isso permite rastrear todo o caminho da solicitação nos logs.
O usuário faz uma solicitação ao sistema A, então A entra em contato com B, que entra em contato com C, armazena em X e então a solicitação é retornada para A
Se você se conectasse remotamente a máquinas virtuais e tentasse rastrear o caminho da solicitação (e correlacionar manualmente quais chamadas estão sendo feitas), você ficaria louco. Ter um identificador exclusivo torna a vida muito mais fácil. Esta é uma das coisas mais simples que você pode fazer para economizar tempo à medida que seu serviço cresce.
Nível médio
Os conselhos aqui são mais complexos que os anteriores, mas as ferramentas certas facilitam a tarefa, proporcionando retorno do investimento mesmo para pequenas e médias empresas.
Registro centralizado
Parabéns! Você implantou 100 máquinas virtuais. No dia seguinte, o CEO chega e reclama de um erro que recebeu ao testar o serviço. Ele informa o ID correspondente de que falamos acima, mas você terá que examinar os registros de 100 máquinas para encontrar aquela que causou o travamento. E precisa ser encontrado antes da apresentação de amanhã.
Embora pareça uma aventura divertida, é melhor garantir que você possa pesquisar todas as revistas em um só lugar. Resolvi o problema de centralização de logs usando a funcionalidade integrada da pilha ELK: ela oferece suporte à coleta de logs pesquisáveis. Isso realmente ajudará a resolver o problema de encontrar um periódico específico. Como bônus, você pode criar gráficos e outras coisas divertidas como essa.
Funcionalidade da pilha ELK
Agentes de monitoramento
Agora que seu serviço está instalado e funcionando, você precisa ter certeza de que ele funciona perfeitamente. A melhor maneira de fazer isso é executar vários agentes, que funcionam em paralelo e verificam se funciona e se as operações básicas são executadas.
Neste ponto você verifica isso a construção em execução é boa e funciona bem.
Para projetos de pequeno e médio porte, recomendo o Postman para monitorar e documentar APIs. Mas, em geral, você só quer ter certeza de que tem uma maneira de saber quando ocorreu uma interrupção e ser notificado em tempo hábil.
Escalonamento automático dependendo da carga
É muito simples. Se você tiver uma VM atendendo solicitações e ela estiver se aproximando de 80% de uso de memória, você poderá aumentar seus recursos ou adicionar mais VMs ao cluster. A execução automática destas operações é excelente para alterações elásticas de potência sob carga. Mas você deve sempre ter cuidado com quanto dinheiro gasta e estabelecer limites razoáveis.
Com a maioria dos serviços em nuvem, você pode configurá-los para escalonamento automático usando mais servidores ou servidores mais poderosos.
Sistema experimental
Uma boa maneira de implementar atualizações com segurança é testar algo para 1% dos usuários por uma hora. É claro que você já viu esses mecanismos em ação. Por exemplo, o Facebook mostra uma cor diferente para partes do público ou altera o tamanho da fonte para ver como os usuários percebem as mudanças. Isso é chamado de teste A/B.
Até mesmo o lançamento de um novo recurso pode ser iniciado como um experimento e então determinado como lançá-lo. Você também pode “lembrar” ou alterar a configuração dinamicamente com base na função que está causando degradação em seu serviço.
nível avançado
Aqui estão algumas dicas que são bastante difíceis de implementar. Provavelmente você precisará de um pouco mais de recursos, então uma empresa de pequeno ou médio porte terá dificuldade em administrar isso.
Implantações azul-verde
Isso é o que chamo de maneira “Erlang” de desdobramento. Erlang tornou-se amplamente utilizado quando surgiram as companhias telefônicas. Softswitches começaram a ser usados para rotear chamadas telefônicas. O principal objetivo do software nesses switches era não interromper chamadas durante as atualizações do sistema. Erlang tem uma ótima maneira de carregar um novo módulo sem travar o anterior.
Esta etapa depende da presença de um balanceador de carga. Vamos imaginar que você tem a versão N do seu software e deseja implantar a versão N+1.
Você poderia basta interromper o serviço e lançar a próxima versão em um horário que funcione para seus usuários e obter algum tempo de inatividade. Mas suponha que você tenha realmente condições rigorosas de SLA. Portanto, SLA 99,99% significa que você pode ficar offline apenas em 52 minutos por ano.
Se você realmente deseja atingir esses indicadores, precisará de duas implantações ao mesmo tempo:
- aquela que está agora (N);
- próxima versão (N+1).
Você diz ao balanceador de carga para redirecionar uma porcentagem do tráfego para a nova versão (N+1) enquanto monitora ativamente as regressões.
Aqui temos uma implantação N verde que funciona bem. Estamos tentando migrar para a próxima versão desta implantação
Primeiro, enviamos um pequeno teste para ver se nossa implantação N+1 funciona com uma pequena quantidade de tráfego:
Finalmente, temos um conjunto de verificações automatizadas que eventualmente executamos até que nossa implantação seja concluída. Se você muito muito cuidado, você também pode salvar sua implantação N para sempre para uma reversão rápida em caso de regressão incorreta:
Se você quiser ir para um nível ainda mais avançado, deixe tudo na implantação azul-verde ser executado automaticamente.
Detecção de anomalias e mitigação automática
Dado que você tem registro centralizado e boa coleta de logs, você já pode definir metas mais altas. Por exemplo, preveja falhas proativamente. As funções são rastreadas em monitores e em logs e vários diagramas são construídos - e você pode prever antecipadamente o que dará errado:
Depois que as anomalias são detectadas, você começa a examinar algumas das pistas que o serviço fornece. Por exemplo, um aumento na carga da CPU pode indicar que um disco rígido está falhando, enquanto um aumento nas solicitações pode indicar que você precisa aumentar a escala. Este tipo de dados estatísticos permite tornar o serviço proativo.
Com esses insights, você pode escalar em qualquer dimensão e alterar de forma proativa e reativa as características de máquinas, bancos de dados, conexões e outros recursos.
É isso!
Esta lista de prioridades evitará muitos problemas se você estiver criando um serviço em nuvem.
O autor do artigo original convida os leitores a deixarem seus comentários e fazerem alterações. O artigo é distribuído como código aberto, pull requests do autor .
O que mais ler sobre o assunto:
Fonte: habr.com