o problema
Um serviço interativo tem um orçamento curto: por volta de 100 milissegundos, a resposta parece parte do gesto do usuário; acima disso, parece uma espera. O que mudou entre os anos 1990 e 2013 é o que cabe dentro desse orçamento. Conectividade melhor e computação em escala de galpão permitiram serviços que consultam conjuntos de dados de vários terabytes, espalhados por milhares de servidores, e ainda assim respondem em dezenas de milissegundos. A busca do Google atualizando resultados enquanto a pessoa digita — prevendo a consulta pelo prefixo, executando a busca e mostrando o resultado — é o exemplo que os autores usam. Dispositivos de realidade aumentada, com o protótipo do Google Glass no horizonte da época, prometiam demandas computacionais ainda maiores com a mesma exigência de continuidade.
O problema é que essa aritmética não fecha por média. Manter a cauda da distribuição de latência baixa fica mais difícil conforme o sistema cresce em tamanho e complexidade, e conforme a utilização sobe. Um episódio temporário de latência alta é irrelevante num sistema de porte moderado: ele acontece em um servidor, atinge poucas requisições, some na média. Em escala grande, esse mesmo episódio passa a dominar o desempenho do serviço inteiro. A razão é estrutural — se uma resposta ao usuário depende de muitas partes, basta uma delas estar num mau momento para a resposta inteira estar. Otimizar o caso comum não ajuda: o caso comum já estava rápido.
a ideia
Dean e Barroso propõem tratar isso pela analogia mais produtiva disponível: a computação tolerante a falhas. Ninguém constrói um serviço confiável exigindo que cada componente seja confiável; constrói-se um todo confiável a partir de partes que falham, com redundância e com mecanismos que absorvem a falha individual. A proposta é fazer o mesmo com tempo em vez de correção: construir um todo previsivelmente responsivo a partir de partes cuja latência é imprevisível. Sistemas assim são chamados de tolerantes à cauda de latência — tail-tolerant.
O deslocamento é de expectativa, antes de ser de técnica. Parar de perguntar por que aquele servidor demorou e passar a assumir que algum servidor sempre vai demorar, sempre por um motivo diferente, e que a arquitetura precisa continuar entregando dentro do orçamento mesmo assim. O artigo cataloga as causas comuns desses episódios e descreve técnicas que reduzem a severidade deles ou mitigam o impacto no desempenho do sistema como um todo.
O ganho econômico vem junto e é a parte que costuma convencer quem paga a conta. Como muitas dessas técnicas se apoiam em recursos que já foram implantados para tolerância a falhas, o custo adicional tende a ser pequeno. E elas permitem levar a utilização do sistema para cima sem alongar a cauda — ou seja, evitam o superprovisionamento, que é a forma cara e silenciosa de comprar um percentil alto decente.
o que isso custou
A palavra do próprio resumo é mitigar. As técnicas reduzem a severidade dos episódios ou o impacto deles; não removem as causas. A variabilidade continua lá — no compartilhamento de recursos, na complexidade do sistema, no que quer que apareça no catálogo — e o que se compra é uma camada que a absorve. Quem esperava eliminar o problema na raiz não vai encontrar isso aqui.
O baixo custo adicional também vem qualificado: vale em muitos casos, não em todos, e depende de já existir redundância paga por outro motivo. Um sistema sem essa infraestrutura prévia paga a redundância inteira. E o resumo anuncia as técnicas sem nomeá-las — a lista está nas seis páginas da Communications of the ACM, não na porta de entrada.
onde isso aparece hoje
O vocabulário do artigo virou o vocabulário padrão de operação: falar em percentil 99 em vez de média, e tratar isso como meta de serviço, é a herança direta dessa forma de olhar. Enxergar a cauda numa requisição que se abre em centenas de chamadas exige rastreamento distribuído, que no Google já existia com o Dapper e virou item de infraestrutura obrigatório fora dele. A mesma preocupação reaparece em camadas específicas — SILK trata exatamente de picos de latência causados por trabalho de fundo em bancos LSM. E a premissa de partida, a de que o computador é o galpão inteiro e não a máquina, é a linha que Barroso vinha desenvolvendo desde Web Search for a Planet.