Papers
Globally Distributed Content Delivery
John Dilley, Bruce Maggs, Jay Parikh, Harald Prokop, Ramesh Sitaraman, Bill Weihl · IEEE Internet Computing, vol. 6, no. 5 (Sept-Oct 2002), pp. 50-58, 2002
O problema: flash crowds e os limites de cluster, espelhamento e multihoming
O artigo parte do problema do flash crowd: quando um site fica popular, a carga de requisições pode sobrecarregar algum ponto da cadeia, seja o servidor web de frente, o equipamento de rede, a banda ou, em sites mais avançados, a infraestrutura transacional de back-end. O resultado é queda do site ou tempos de resposta altos, o que se traduz em perda de receita e imagem. A Akamai nasceu de uma pesquisa no MIT sobre esse problema, partindo da observação de que servir conteúdo de um único local cria problemas de escalabilidade, confiabilidade e desempenho. Os autores revisam as abordagens existentes: clustering local, espelhamento (clusters em poucos locais) e multihoming (vários ISPs). Nenhuma resolve tudo. É difícil escalar clusters para milhares de servidores; no multihoming o BGP não converge rápido quando uma conexão falha; e o espelhamento exige sincronizar os espelhos. Além disso, as três exigem capacidade ociosa: o cluster precisa aguentar o pico (que pode ser uma ordem de grandeza acima da média), cada conexão do multihoming precisa carregar todo o tráfego e cada espelho precisa suportar a carga inteira, o que pode mais que dobrar o custo inicial de infraestrutura. Caches proxy independentes ajudam, mas, segundo o texto, suas taxas de acerto tendem a ser baixas (25 a 40 por cento), em parte por causa do conteúdo dinâmico.
A ideia central: servidores de borda e o mapeamento via DNS
A resposta da Akamai é servir as requisições a partir de um número variável de servidores substitutos da origem (surrogate origin servers) na borda da Internet. Na época do artigo, o sistema usava mais de 12.000 servidores em mais de 1.000 redes. O princípio é direcionar cada cliente ao servidor que seja ao mesmo tempo o mais próximo, disponível e provável de ter o conteúdo. Próximo depende de topologia e dinâmica dos links (menor RTT e menor perda de pacotes). Disponível depende de carga e banda do servidor e do data center. Provável depende de quais servidores guardam o conteúdo de cada cliente: se todos servissem tudo, como num DNS round-robin, disco e memória seriam consumidos pelos objetos mais populares. Por isso o sistema distribui o conteúdo pelo número mínimo de servidores em cada site. Esse direcionamento chama-se mapeamento (mapping) e usa um sistema DNS dinâmico e tolerante a falhas, que resolve o hostname conforme o serviço pedido, a localização do usuário e o estado da rede. A resolução passa por servidores DNS de topo (top-level), que delegam a servidores de baixo nível (low-level) no local mais próximo do cliente. Os TTLs são curtos (de alguns segundos a um minuto na resolução final), para permitir redirecionar clientes quando as condições mudam.
Critérios de mapeamento, hashing consistente e monitoramento
Para mapear uma requisição a um servidor, os name servers da Akamai combinam critérios: o serviço pedido (não mandar um stream QuickTime a um servidor que só atende HTTP), a saúde do servidor, sua carga (CPU, disco e rede), as condições de rede (baixa perda de pacotes e banda suficiente no data center), a localização do cliente e se o servidor provavelmente tem o conteúdo, o que é decidido por um algoritmo de hashing consistente. Para conhecer a topologia, agentes da Akamai trocam mensagens BGP como pares de certos roteadores de borda, e o número de saltos entre sistemas autônomos serve como medida grosseira de distância, combinada com dados vivos como traceroute. O monitoramento alimenta o balanceamento: cada servidor reporta sua carga a uma aplicação de monitoramento, que informa o DNS local. Se a carga passa de um limiar, o DNS atribui parte do conteúdo a mais servidores; passando de outro limiar, o IP do servidor deixa de ser devolvido aos clientes. Agentes que simulam usuários baixando objetos medem falhas e tempos de download e permitem detectar e suspender data centers ou servidores problemáticos automaticamente. O monitoramento também alimenta relatórios em tempo quase real sobre o conteúdo servido.
Conteúdo dinâmico na borda: ESI, conexões divididas e controle de conteúdo
Proxy caches comuns não conseguem cachear conteúdo dinâmico, por exemplo uma página estática que inclui um anúncio personalizado por perfil. Para isso a Akamai usa Edge Side Includes (ESI), uma tecnologia que monta conteúdo dinâmico nos servidores de borda. Semelhante a linguagens de include do lado do servidor, o ESI acrescenta recursos de tolerância a falhas (para quando a origem está indisponível) e integra um motor XSLT. O provedor divide a página em fragmentos com cacheabilidade independente; eles ficam como objetos separados no cache da borda e são montados dinamicamente a cada requisição, de modo que só fragmentos não cacheáveis ou expirados são buscados na origem. Em sites dinâmicos estudados (portais e sites financeiros), o artigo relata redução de banda de origem de 95 a 99 por cento. Para objetos não cacheáveis, o servidor de borda divide a conexão TCP em duas, cliente-borda e borda-origem, o que pode acelerar a resposta porque a borda reage mais rápido a perda de pacotes. Quanto à consistência de objetos cacheáveis, usam-se TTLs ou URLs versionadas, e os servidores aceitam purgas sob demanda. O artigo também trata de autorização, verificação de integridade antes de servir cada bloco de resposta, visibilidade de logs e faturamento.
Confiabilidade, desafios operacionais e legado
Os autores listam desafios de construir e operar o sistema. Em escalabilidade: monitorar dezenas de milhares de servidores distribuídos com o mínimo de banda, gerar novos mapas a cada poucos segundos sem somar atraso ao DNS (os cálculos do servidor ideal são feitos offline, sem fazer o usuário esperar), lidar com informação incompleta ou desatualizada, isolar clientes uns dos outros e agregar logs para faturamento. Em confiabilidade: o princípio é eliminar pontos únicos de falha. Parte dos equipamentos de uma grande rede falha todo mês, então é preciso detectar falhas e retirar unidades de serviço. O DNS detecta falhas rapidamente e entrega novos IPs; para resolvers com respostas em cache, a resolução pode devolver vários IPs ou um servidor vivo no site pode assumir o IP do falho. A replicação é massiva, tanto para entrega de conteúdo quanto para DNS. O software não pode ser atualizado de forma atômica, então é implantado em estágios e duas versões coexistem na rede. A conclusão aponta o próximo passo: rodar aplicações na borda, com desafios de visibilidade, isolamento (sandbox) entre aplicações de clientes e distribuição de dados, base conceitual do edge computing atual.
Veja as ideias em ação
Pratique na escola de System Design os desenhos que usam este paper.