Como descrito noutras partes deste livro, a Google desenvolveu ao longo dos anos uma série de técnicas para o funcionamento de sistemas confiáveis. Algumas destas técnicas são particularmente bem adaptadas ao lançamento de produtos em segurança. Também oferecem vantagens durante o funcionamento regular do serviço, mas é particularmente importante acertá-las durante a fase de lançamento.

Lançamentos graduais e encenados

Um adágio da administração do sistema é “nunca mude um sistema em funcionamento”. Qualquer mudança representa risco, e o risco deve ser minimizado de modo a assegurar a confiabilidade de um sistema. O que é verdade para qualquer sistema pequeno é duplamente verdade para sistemas altamente replicados, distribuídos globalmente como os geridos pela Google.

Muito poucos lançamentos no Google são da variedade “push-button”, em que lançamos um novo produto num momento específico para que o mundo inteiro o utilize. Ao longo do tempo, a Google desenvolveu uma série de padrões que nos permitem lançar produtos e características gradualmente e assim minimizar o risco; ver A Collection of Best Practices for Production Services.

Quase todas as atualizações dos serviços da Google procedem gradualmente, de acordo com um processo definido, com etapas de verificação adequadas intercaladas. Um novo servidor poderá ser instalado em algumas máquinas num único datacenter e observado durante um período de tempo definido. Se tudo parecer bem, o servidor é instalado em todas as máquinas num único datacenter, observado novamente, e depois instalado em todas as máquinas globalmente. As primeiras fases de uma implantação são normalmente chamadas “canários” – uma alusão a canários transportados pelos mineiros para uma mina de carvão para detectar gases perigosos. Os nossos servidores canários detectam efeitos perigosos do comportamento do novo software sob tráfego real de usuários.

Os testes canários são um conceito incorporado em muitas das ferramentas internas da Google utilizadas para fazer alterações automáticas, bem como para sistemas que alteram ficheiros de configuração. Ferramentas que gerem a instalação de novo software normalmente observam o servidor recém-iniciado durante algum tempo, certificando-se de que o servidor não trava ou se comporta  mal. Se a alteração não passar o período de validação, é automaticamente revertida.

O conceito de lançamentos graduais se aplica até mesmo a softwares que não são executados nos servidores do Google. Novas versões de um aplicativo Android podem ser lançadas de forma gradual, em que a versão atualizada é oferecida a um subconjunto das instalações para atualização. A percentagem de instâncias atualizadas aumenta gradualmente ao longo do tempo até atingir 100%. Este tipo de implementação é particularmente útil se a nova versão resultar em tráfego adicional para os servidores backend nos datacenters do Google. Desta forma, podemos observar o efeito nos nossos servidores à medida que lançamos gradualmente a nova versão e detectamos problemas antecipadamente.

O sistema de convite é outro tipo de implementação gradual. Frequentemente, em vez de permitir inscrições gratuitas para um novo serviço, apenas um número limitado de usuários é autorizado a se inscrever por dia. As inscrições de taxa limitada são frequentemente associadas a um sistema de convites, no qual um usuário pode enviar um número limitado de convites a amigos.

Estruturas de Feature Flag

O Google aumenta frequentemente os testes pré-lançamento com estratégias que mitigam o risco de uma interrupção. Um mecanismo para lançar mudanças lentamente, permitindo a observação do comportamento total do sistema sob cargas de trabalho reais, pode pagar pelo seu investimento de engenharia em confiabilidade, velocidade de engenharia, e tempo de colocação no mercado. Estes mecanismos têm-se mostrado particularmente úteis nos casos em que os ambientes de teste realistas são impraticáveis, ou para lançamentos particularmente complexos, cujos efeitos podem ser difíceis de prever.

Além disso, nem todas as mudanças são iguais. Por vezes, simplesmente se pretende verificar se um pequeno ajuste na interface do usuário melhora a experiência dos seus usuários. Tais pequenas alterações não devem envolver milhares de linhas de código ou um processo de lançamento pesado. Poderá querer testar centenas de tais alterações em paralelo.

Finalmente, por vezes se quer descobrir se uma pequena amostra de usuário gosta de utilizar um protótipo inicial de uma nova funcionalidade difícil de implementar. Não se quer passar meses de esforço de engenharia para fortalecer uma nova funcionalidade para atender a milhões de usuários, apenas para descobrir que a funcionalidade é um fracasso.

Para acomodar os cenários anteriores, vários produtos Google criaram estruturas de Feature Flag. Algumas dessas estruturas foram criadas para lançar gradualmente novas funcionalidades de 0% a 100% dos usuários. Sempre que um produto introduzia uma tal estrutura, a própria estrutura era reforçada tanto quanto possível para que a maioria de seus aplicativos não precisassem de qualquer envolvimento da LCE. Tais estruturas satisfazem geralmente os seguintes requisitos:

• Fazer muitas mudanças em paralelo, cada uma em poucos servidores, usuários, entidades, ou datacenters 
• Aumentar gradualmente para um grupo maior mas limitado de usuários, normalmente entre 1 e 10 por cento
• Tráfego direto através de diferentes servidores dependendo dos usuários, sessões, objetos, e/ou localizações
• Tratar automaticamente a falha dos novos caminhos de código por concepção, sem afetar os usuários 
• Reverter de forma independente cada uma dessas alterações imediatamente no caso de bugs graves ou efeitos secundários
• Medir até que ponto cada alteração melhora a experiência do usuário 

Os quadros de estruturas de feature flag do Google dividem-se em duas classes gerais:

• As que facilitam principalmente melhorias na interface do usuário 
• Aqueles que suportam mudanças arbitrárias no lado do servidor e na lógica empresarial

A estrutura mais simples de feature flag para alterações de interface de usuário num serviço sem estado é um reescritor de carga útil HTTP em servidores de aplicativos frontend, limitado a um subconjunto de cookies ou outro atributo de pedido/resposta HTTP semelhante. Um mecanismo de configuração pode especificar um identificador associado aos novos caminhos de código e ao âmbito da alteração (por exemplo, intervalos de módulos hash cookies), listas brancas, e listas negras.

Os serviços estatais tendem a limitar as feature flags a um subconjunto de identificadores únicos de usuários com sessão iniciada ou às entidades reais do produto acessadas, tais como a identificação de documentos, folhas de cálculo, ou objetos de armazenamento. Em vez de reescrever as cargas úteis HTTP, os serviços estatais são mais propensos a substituir ou reencaminhar pedidos para servidores diferentes, dependendo da alteração, conferindo a capacidade de testar uma lógica empresarial melhorada e novas características mais complexas.

Lidar com o Comportamento Abusivo do Cliente

O exemplo mais simples de comportamento abusivo do cliente é um erro de julgamento das taxas de atualização. Um novo cliente que sincroniza a cada 60 segundos, em oposição a cada 600 segundos, causa 10 vezes a carga no serviço. O comportamento de nova tentativa tem uma série de armadilhas que afetam os pedidos iniciados pelo usuário, bem como os pedidos iniciados pelo cliente. Tomemos o exemplo de um serviço que está sobrecarregado e que, por isso, está falhando em algumas solicitações: se os clientes tentarem novamente as solicitações com falha, eles adicionarão carga a um serviço já sobrecarregado, resultando em mais tentativas e ainda mais solicitações. Em vez disso, os clientes precisam reduzir a frequência das tentativas, normalmente adicionando um atraso exponencialmente crescente entre tentativas, além de considerarem cuidadosamente os tipos de erros que justificam uma nova tentativa. Por exemplo, um erro de rede geralmente justifica uma nova tentativa, mas um erro 4xx HTTP (que indica um erro do lado do cliente) normalmente não o justifica.

A sincronização intencional ou inadvertida de pedidos automatizados num rebanho estrondoso (muito semelhante aos descritos nos capítulos Programação Periódica Distribuída com Cron e Pipelines de Processamento de Dados) é outro exemplo comum de comportamento abusivo do cliente. Um desenvolvedor de aplicativo de telefone pode decidir que 2 da manhã é um bom momento para baixar atualizações, porque o usuário provavelmente está dormindo e não será incomodado pelo download. No entanto, esse design resulta em uma enxurrada de solicitações ao servidor de download às 2 da manhã todas as noites e quase nenhuma solicitação em nenhum outro momento. Em vez disso, cada cliente deve escolher a hora para este tipo de pedido de forma aleatória.

A aleatoriedade também precisa ser injetada noutros processos periódicos. Para voltar às tentativas anteriormente mencionadas: tomemos o exemplo de um cliente que envia um pedido, e quando se depara com uma falha, faz a tentativa após 1 segundo, depois 2 segundos, depois 4 segundos, e assim por diante. Sem aleatoriedade, um breve pico de pedido que leva a um aumento da taxa de erro poderia repetir-se devido a tentativas após 1 segundo, depois 2 segundos, depois 4 segundos, e assim por diante. A fim de equilibrar estes eventos sincronizados, cada atraso precisa ser agitado (ou seja, ajustado por uma quantidade aleatória).

A capacidade de controlar o comportamento de um cliente a partir do lado do servidor provou ser uma ferramenta importante no passado. Para um aplicativo em um dispositivo, esse controle pode significar instruir o cliente a fazer check-in periodicamente com o servidor e baixar um arquivo de configuração. O arquivo pode habilitar ou desabilitar determinados recursos ou definir parâmetros, tais como a frequência com que o cliente sincroniza ou a frequência com que volta a testar.

A configuração do cliente pode até habilitar uma funcionalidade totalmente nova voltada para o usuário. Ao hospedar o código que dá suporte à nova funcionalidade no aplicativo do cliente antes de ativar esse recurso, reduzimos bastante o risco associado a um lançamento. O lançamento de uma nova versão torna-se muito mais fácil se não precisarmos manter pistas de lançamento paralelas para uma versão com a nova funcionalidade versus sem a funcionalidade. Isto é particularmente verdade se não estivermos lidando com uma única peça de nova funcionalidade, mas sim com um conjunto de funcionalidades independentes que podem ser lançadas em horários diferentes, o que implicaria manter uma explosão combinatória de versões diferentes. 

Ter este tipo de funcionalidade adormecida também facilita o aborto de lançamentos quando são descobertos efeitos adversos durante uma implementação. Nesses casos, podemos simplesmente desligar a funcionalidade, iterar, e lançar uma versão atualizada do aplicativo. Sem este tipo de configuração de cliente, teríamos de fornecer uma nova versão do aplicativo sem a funcionalidade, e atualizar o aplicativo em todos os telefones dos usuários.

Comportamento de sobrecarga e testes de carga

As situações de sobrecarga são um modo de falha particularmente complexo, pelo que merecem atenção adicional. O sucesso em fuga é normalmente a causa mais bem-vinda de sobrecarga quando um novo serviço é lançado, mas existem inúmeras outras causas, incluindo falhas de equilíbrio de carga, interrupções de máquinas, comportamento sincronizado do cliente, e ataques externos.

Um modelo ingênuo pressupõe que a utilização de CPU numa máquina que forneça um determinado serviço é linearmente dimensionada com a carga (por exemplo, número de pedidos ou quantidade de dados processados), e uma vez esgotada a CPU disponível, o processamento torna-se simplesmente mais lento. Infelizmente, os serviços raramente se comportam desta forma ideal no mundo real. Muitos serviços são muito mais lentos quando não são carregados, geralmente devido ao efeito de vários tipos de caches, tais como caches de CPU, caches JIT, e caches de dados específicos do serviço. À medida que a carga aumenta, há normalmente uma janela em que o uso e a carga da CPU no serviço correspondem linearmente, e os tempos de resposta permanecem na sua maioria constantes.

A dada altura, muitos serviços atingem um ponto de não linearidade à medida que se aproximam da sobrecarga. Nos casos mais benignos, os tempos de resposta começam simplesmente a aumentar, resultando numa experiência degradada do usuário, mas não necessariamente causando uma interrupção (embora uma dependência lenta possa causar erros visíveis ao usuário na stack, devido à ultrapassagem dos prazos de RPC). Nos casos mais drásticos, um serviço fica completamente bloqueado em resposta a uma sobrecarga.

Para citar um exemplo específico de comportamento de sobrecarga: um serviço registra informações de depuração em resposta a erros de backend. Verificou-se que a informação de depuração de registro era mais cara do que o tratamento da resposta de backend num caso normal. Portanto, à medida que o serviço se tornava sobrecarregado e temporizava as respostas backend dentro da sua própria stack RPC, o serviço gastava ainda mais tempo da CPU a registrar estas respostas, temporizando entretanto mais pedidos até que o serviço parasse completamente. Nos serviços executados na Máquina Virtual Java (JVM), um efeito semelhante de travamento é às vezes chamado de “GC (recolha de lixo) de trituração”. Neste cenário, a gestão da memória interna da máquina virtual corre em ciclos cada vez mais próximos, tentando liberar memória até que a maior parte do tempo da CPU seja consumido pela gestão da memória.

Infelizmente, é muito difícil prever desde os primeiros princípios como um serviço irá reagir à sobrecarga. Portanto, os testes de carga são uma ferramenta inestimável, tanto por razões de confiabilidade como de planejamento da capacidade, e os testes de carga são necessários para a maioria dos lançamentos.