Neste documento, o framework de arquitetura do Google Cloud fornece práticas recomendadas para executar serviços de maneira confiável. Você verá como implantar atualizações, executar serviços em ambientes de produção e testar falhas. A arquitetura da confiabilidade precisa cobrir todo o ciclo de vida do serviço, não apenas o design de software.
Escolha bons nomes para aplicativos e serviços
Evite usar nomes de código internos em arquivos de configuração de produção, porque eles podem ser confusos, especialmente para funcionários mais novos, o que pode aumentar o tempo de minimização (TTM) de interrupções. Na medida do possível, escolha bons nomes para todos os seus aplicativos, serviços e recursos essenciais do sistema, como VMs, clusters e instâncias de banco de dados, sujeitos aos respectivos limites de nome. Um bom nome descreve a finalidade da entidade. são precisas, específicas e diferenciadas; e é significativo para todos que os veem. Um bom nome evita acrônimos, codinomes, abreviações e terminologia potencialmente ofensiva e não cria uma resposta pública negativa mesmo que seja publicado externamente.
Implementar lançamentos progressivos com testes canário
Alterações globais instantâneas em binários de serviço ou configurações são arriscadas. Lance novas versões de executáveis e alterações de configuração gradualmente. Comece com um escopo pequeno, como algumas instâncias de VM em uma zona, e expanda o escopo gradualmente. Reverta rapidamente se a alteração não tiver o desempenho esperado ou afetar negativamente os usuários em qualquer estágio do lançamento. Seu objetivo é identificar e solucionar bugs quando eles afetam apenas uma pequena parte do tráfego do usuário, antes de lançar a alteração globalmente.
Configure um sistema de teste canário que esteja ciente das alterações do serviço e faça uma comparação A/B das métricas dos servidores alterados com os demais. O sistema deve sinalizar um comportamento inesperado ou anômalo. Se o desempenho da alteração não for o esperado, o sistema de teste canário deverá interromper automaticamente as implementações. Os problemas podem ser claros, como erros do usuário, ou sutis, como aumento de uso da CPU ou sobrecarga de memória.
É melhor parar e reverter na primeira dica de problemas e diagnosticar problemas sem a pressão de tempo de uma interrupção. Depois que a alteração for aprovada no teste canário, propague-a gradualmente para escopos maiores, como para uma zona completa e depois para uma segunda zona. Aguarde o sistema alterado lidar com volumes gradualmente maiores de tráfego do usuário para expor bugs latentes.
Para mais informações, consulte Implantação de aplicativos e estratégias de testes.
Distribuir o tráfego para promoções e lançamentos programados
Eventos promocionais, como vendas que começam em uma hora definida, incentivam muitos usuários a se conectarem ao serviço simultaneamente. Diante desses casos, crie um código de cliente para distribuir o tráfego por alguns segundos. Use atrasos aleatórios antes de iniciar as solicitações.
Também é possível pré-aquecer o sistema. Ao pré-aquecer o sistema, você envia o tráfego do usuário previsto com antecedência para garantir que ele funcione conforme o esperado. Isso evita picos de tráfego instantâneos que possam travar os servidores no horário de início programado.
Automatizar a criação, o teste e a implantação
Elimine o esforço manual do processo de lançamento com o uso de pipelines de integração contínua e entrega contínua (CI/CD). Realize testes e implantação de integração automatizados. Por exemplo, crie um processo de CI/CD moderno com o GKE.
Para mais informações, consulte integração contínua, entrega contínua, automação de teste e automação de implantação..
Design para segurança
Projete suas ferramentas operacionais para rejeitar configurações potencialmente inválidas. Detecte e alerte quando uma versão de configuração estiver vazia, parcial ou truncada, corrompida, logicamente incorreta ou inesperada ou não for recebida dentro do tempo esperado. As ferramentas também precisam rejeitar versões de configuração muito diferentes da versão anterior.
Não permitir alterações ou comandos com um escopo muito amplo que sejam potencialmente destrutivos. Esses comandos amplos podem ser "Revogar permissões para todos os usuários", "Reiniciar todas as VMs nesta região" ou "Reformatar todos os discos nesta zona". Essas alterações só devem ser aplicadas se o operador adicionar sinalizações de linha de comando de substituição de emergência ou configurações de opção ao implantar a configuração.
As ferramentas precisam exibir a amplitude do impacto de comandos arriscados, como o número de VMs que a mudança afeta, e exigir confirmação explícita do operador antes de a ferramenta continuar. Também é possível usar recursos para bloquear recursos essenciais e impedir a exclusão acidental ou não autorizada, como os bloqueios da política de retenção do Cloud Storage.
Testar a recuperação de falhas
Teste regularmente seus procedimentos operacionais para se recuperar de falhas no serviço. Sem testes regulares, os procedimentos podem não funcionar quando você precisar deles no caso de uma falha real. Os itens a serem testados periodicamente incluem failover regional, formas de reverter uma versão e restaurar dados de backups.
Realizar testes de recuperação de desastres
Assim como nos testes de recuperação de falhas, não espere por um desastre. Teste e verifique periodicamente seus procedimentos e processos de recuperação de desastres.
É possível criar uma arquitetura de sistema para fornecer alta disponibilidade (HA, na sigla em inglês). Essa arquitetura não se sobrepõe totalmente à recuperação de desastres (DR), mas geralmente é necessário considerar a HA quando você pensa em valores de objetivo de tempo de recuperação (RTO, na sigla em inglês) e objetivo de ponto de recuperação (RPO, na sigla em inglês).
A HA ajuda você a alcançar ou exceder um nível acordado de desempenho operacional, como tempo de atividade. Ao executar cargas de trabalho de produção no Google Cloud, é possível implantar uma instância de espera passiva ou ativa em uma segunda região. Com essa arquitetura, o aplicativo continuará a fornecer serviços da região não afetada se houver um desastre na região principal. Para mais informações, consulte Como arquitetar a recuperação de desastres para interrupções na nuvem.
Praticar engenharia de caos
Considere o uso da engenharia de caos em suas práticas de teste. Introduza falhas reais em diferentes componentes dos sistemas de produção sob carga em um ambiente seguro. Essa abordagem ajuda a garantir que não haja um impacto geral no sistema porque o serviço processa falhas corretamente em cada nível.
As falhas que você injeta no sistema podem incluir tarefas com falha, erros e tempos limite em RPCs ou reduções na disponibilidade de recursos. Use a injeção de falhas aleatórias para testar falhas intermitentes (oscilação) nas dependências de serviço. Geralmente, esses comportamentos são difíceis de detectar e mitigar na produção.
A engenharia do caos garante que o efeito desses testes seja minimizado e contido. Trate esses testes como prática para interrupções reais e use todas as informações coletadas para melhorar sua resposta de interrupção.
A seguir
- Criar alertas eficientes (próximo documento desta série)
Explore outras categorias no Framework de arquitetura, como design do sistema, excelência operacional e segurança, privacidade e conformidade.