Os requisitos: ter uma solução prática que funcione para a nuvem ou qualquer tipo de ambiente onde não haja acesso a balanceadores de carga de hardware, protocolos BGP e todas essas coisas.
O número de solicitação de receita de um aplicativo é desconhecido, mas deve ser alto o suficiente para atender a uma expectativa de aumento de carga sem medo.
Vamos encontrar um aplicativo com natureza semelhante de carga, por exemplo, loja de registro e aplicativo de pesquisa. Eu encontrei um .
O que eles querem:
- Equilibre a carga entre os colecionadores
- Ofereça tolerância a falhas, permitindo que continuemos ingerindo dados se um dos coletores morrer ou estiver com problemas
- Escala horizontalmente com o crescimento em nossos volumes de log
O que eles tentaram e aprenderam sobre o ELB:
- Não funciona como esperado
- Problemas de latência devido ao aumento de carga
- Não há instalações de monitoramento suficientes
- Excesso de limitação (portas abertas e número de protocolos)
Por que eles escolheram com o Route53:
- "O round robin é um balanceamento de carga bem básico, mas funciona bem para nós do ponto de vista da eficiência"
- "Aproveitamos as verificações de integridade de failover do Route 53".
- "Se houver um problema com um colecionador, o Route 53 o tirará automaticamente do serviço; nossos clientes não verão qualquer impacto."
- Não é necessário pré-aquecimento com o roteador 53
Route 53 turned out to be the best way for Loggly to take advantage of
our high-performance collectors given our huge log volumes,
unpredictable variations, and constant growth in our business. It
aligns with the collectors’ core purposes: To collect data at network
line speed with zero loss, and it allows us to benefit from the
elasticity of all of the AWS services we use at Loggly.
Esse exemplo em particular mostra que em alguns cenários (coletor de logs, serviço de anúncios ou similar) o balanceador de carga é redundante e "solução de round-robin de verificação de integridade de DNS" faz seu trabalho muito bem.
Vamos ver o que da AWS diz sobre o failover de DNS :
With DNS Failover, Route 53 can detect an outage of your website and
redirect your end users to alternate or backup locations that you
specify. Route 53 DNS Failover relies on health checks-regularly
making Internet requests to your applications endpoints from multiple
locations around the world-to determine whether each endpoint of your
application is up or down.
Essa técnica também torna o ELB (não obrigatório, apenas para uma nota) mais robusto, novamente é baseado em RR + Health Check:
Route 53 DNS Failover handles all of these failure scenarios by
integrating with ELB behind the scenes. Once enabled, Route 53
automatically configures and manages health checks for individual ELB
nodes.
Vamos agora ver como funciona nos bastidores. A pergunta óbvia é como lidar com o armazenamento em cache do DNS:
However, DNS caching can still be a problem here (see our previous
post where "long tail" problem is covered) if TTL is not respected by
all layers between your client and Route 53. You could then apply a
"cache busting" technique: send a request to a unique domain
("http://<unique-id>.<your-domain>")
e defina um recurso curinga
Record "*.<your-domain>" to match it.
Algolia introduziu "tentativa de cliente estratégia ", que funciona muito bem se o seu cliente (JS no seu caso) pode lidar com isso:
We ended up implementing a basic retry strategy in our API clients.
Each API client was developed to be able to access three different
machines. Three different DNS records represented each user:
USERIDID-1.algolia.io, USERID-2.algolia.io andUSERID-3.algolia.io. Our
first implementation was to randomly select one of the records and
then retry with a different one in case of failure.