19 coisas úteis sobre o Elastic Load Balancer

1. Protocolos suportados pelo ELB

Atualmente são suportados: HTTP, HTTPS, SSL e TCP. As portas TCP suportadas são: 25, 80, 443 e a faixa 1024-65535.

2. Algoritmos suportados pelo ELB

Atualmente o AWS ELB só suporta Round Robin e Sticky Session. No Round Robin cada requisição é tratada de forma independente e encaminhada para a instância que estiver com a menor carga. No algoritmo Sticky Session, é feita uma associação de sessão entre o cliente e a instância que o estiver atendendo. Novos clientes são distribuídos de forma equilibrada entre as instâncias, mas depois que um determinado cliente começa a ser atendido por uma instância, ele será enviada para ela até acabar a sessão ou até que a instância fique fora do ar.

É possível que outros algoritmos de balanceamento venham a ser suportados no futuro.

3. O ELB não monitora o consumo de recursos das instâncias

O ELB faz basicamente uma distribuição equivalente de requisições entre as instâncias, mas ele não é capaz de avaliar se uma instância específica está mais ou menos sobrecarregada que as outras. Portanto, é uma má idéia colocar atrás do ELB instâncias de tamanhos diferentes, pois a utilização delas não será ótima.

4. Os timeouts do ELB são de 60 segundos

Este tempo de timeout pode ser um problema caso haja uma geração de relatórios, arquivos para download ou qualquer requisição que leve mais do que 60 segundos do lado do servidor para iniciar a transmissão de dados da resposta. Se você estiver em um cenário assim, pode ser necessário o envio de algum dado pelo socket aberto para garantir que a conexão não fique idle até atingir o timeout.

5. Os ELBs foram concebidos para alta disponibilidade e podem ser inadequados com uma única instância

Qualquer balanceador de carga em sua essência serve para balancear as requisições de clientes entre múltiplos servidores que irão atendê-los. Por isso, caso você tenha uma única instância é possível que o ELB esteja trazendo custos que não justificam seu uso. Um ELB custa no mínimo US$ 0,025 por hora (nas regiões dos EUA), o que significa US$ 18 mensais se você usá-lo o mês inteiro. Caso você esteja numa topologia com uma única instância, considere a possibilidade de usar algo como Apache, nginx ou Varnish para atuar como proxy na frente do servidor de aplicações.

6. O ELB é multi-zona, não multi-região

Os ELBs criados valem apenas dentro das zonas da mesma região. Se você tiver instâncias em múltiplas regiões, terá que usar algum elemento adicional para lidar com todas as instâncias. O Route 53 pode ser usado para lidar com failover de DNS e encaminhar as requisições para um DNS secundário. Esta arquitetura permitiria que você tivesse uma topologia multi-zona em uma região primária e fizesse fallback para uma região secundária em caso de falha, sem downtime para usuários finais.

7. O ELB não é um proxy reverso

O ELB faz somente distribuição de carga entre instâncias. Funcionalidades como cacheamento de requisições ou aceleração de carregamento ficam para componentes como o Varnish ou nginx.

8. O ELB não disponibiliza logs de nada

É isso mesmo 🙂

9. O ELB não foi concebido para picos de acesso abruptos

O ELB foi desenhado para lidar com infinitas requisições concorrentes por segundo, contanto que o padrão de crescimento não seja tão acelerado. Uma abordagem possível num cenário de campanha de marketing ou qualquer acesso modo avalanche é fazer um pré-aquecimento dos ELBs se for viável, ou então usar uma outra forma de balanceamento.

10. O ELB pode ser pré-aquecido sob demanda

Entrando em contato com o suporte da Amazon, é possível “pré-configurar” os ELBs para lidar com um volume muito alto de acessos, caso isto esteja vinculado a um evento previsível e iniciado pelo dono do ELB.

11. Portais como a Globo.com geralmente usam balanceadores físicos em vez de ELBs

Dependendo das características de acesso e da topologia da infraestrutura, pode fazer muito sentido ter um balanceador em hardware em vez do Elastic Load Balancer. Fornecedores como F5 e Radware oferecem balanceadores que chegam a passar de US$ 1 Mi e possuem uma capacidade altíssima de atendimento de requisições.

12. O ELB não oferece IP fixo para seus balanceadores

Dependendo das preferências de segurança da empresa isto pode trazer dificuldades, pois às vezes deseja-se configurar regras especiais para o IP do balanceador. Nestes cenários seria necessária uma abordagem de balanceamento usando HAProxy ou nginx dentro de instâncias EC2 com Elastic IPs.

13. O ELB frequentemente concentra em uma mesma zona de disponibilidade as requisições originadas em um mesmo IP

Este comportamento aparece com frequência durante testes de carga, portanto recomendamos a execução dos testes a partir de múltiplos IPs de origem. Caso você tenha uma grande corporação com múltiplos usuários acessando uma determinada aplicação a partir de um único IP de saída, é importante avaliar se o uso do ELB será mesmo adequado ou se pode trazer problemas.

14. O ELB não consegue balancear analisando padrões de URL

Diferentemente de alguns proxies reversos, o ELB não consegue analisar padrões de URL como meuservidor.com/app1 e meuservidor.com/apps2. O ELB balanceia apenas baseado no host do servidor, e no protocolo acessado. Se for necessário balancear considerando URLs deve ser usado um balanceador rodando em uma instância EC2.

15. O ELB pode facilmente suportar mais de 20 mil requisições concorrentes por segundo

O ELB foi desenhado para suportar infinitas requisições por segundo, crescendo de uma maneira não tão abrupta, como mencionamos nos itens 8 e 9. Em um benchmark feito pela RightScale, foi observado que o ELB facilmente conseguia atender a mais de 20 mil requisições concorrentes por segundo, o que é suficiente para suportar aplicações muito intensas. Porém, se estivermos falando da página inicial de um grande portal como Globo.com, UOL, R7 ou outros, possivelmente ele não conseguirá escalar tão rapidamente caso surja uma avalanche de requisições.

16. O ELB serve para hospedar um único certificado SSL e compartilhá-lo entre múltiplas instâncias

Em vez de configurar múltiplos certificados dentro de instâncias e possivelmente ter que comprar múltiplos certificados, podemos configurar um único certificado no ELB e ele poderá ser usado por múltiplos servidores de forma transparente.

17. Monitorando o ELB

Não temos acessos aos logs do ELB e a única forma de monitorá-lo é através do CloudWatch.

18. O ELB faz health checks frequentes e pode desligar e ligar instâncias automaticamente

Uma das características mais interessantes do ELB é que ele continuamente monitora as instâncias com health checks HTTP/HTTPS ou TCP/UDP. Se estivermos usando um grupo de autoscaling com regras bem definidas para número mínimo e máximo de instâncias, o ELB consegue disparar automaticamente comandos para ligar ou desligar instâncias de acordo com as políticas dos grupos de autoscaling.

19. O ELB é por padrão tolerante a falhas e escalável

O ELB por padrão utiliza múltiplos agentes para fazer o balanceamento e ele consegue aumentar e diminuir a quantidade destes de acordo com a carga. Avaliando as possibilidade equivalentes com HAProxy ou nginx rodando em instâncias EC2, provavelmente o ELB será bem mais prático e barato do que eles para fazer o balanceamento com alta disponibilidade e de forma escalável.

Gostou do conteúdo? Tem alguma dúvida? Entre em contato com nossos Especialistas Mandic Cloud, ficamos felizes em ajudá-lo.