O documento discute as melhores práticas para o uso do Elastic Load Balancing (ELB) da Amazon em ambientes EC2, enfatizando a importância de distribuições de carga, verificações de saúde, timeouts e otimizações de DNS. Ele também menciona a necessidade de associar múltiplas zonas de disponibilidade para garantir alta disponibilidade e resiliência, além de detalhar a configuração de SSL e monitoramento através do CloudWatch. Sugestões para automatização de tarefas e gerenciamento de custos também são apresentadas.

1. São Paulo

2. Elastic Load Balancing:
Melhores Práticas
Damian Traverso - Solutions Architect
28 Maio, 2015 | São Paulo

3. O Elastic Load Balancing distribui
automaticamente o tráfego de entrada dos
aplicativos em várias instâncias do Amazon EC2

4. Elástico Seguro Integrado Custo-benefício

5. Instância
EC2

6. ELB
Instância
EC2
Instância
EC2
Instância
EC2
Um Balanceador de
Carga é utilizado para
distribuir requisições
entrantes entre
múltiplas instâncias
EC2

7. EC2-Classic
• Distribui a carga entre instâncias
no EC2 clássico
• Suporta únicamente endereços IP
públicos
• Não é possível controlar o
Security Group (firewall)
EC2-VPC
• Distribui a carga entre instâncias
dentro duma VPC
• Suporta endereços IPs privados e
públicos
• Controle total sobre o Security
Group do ELB
• Fortemente integrado com a VPC
e as subnets onde foi criado

8. Arquitetura

9. us-west-1b
Amazon
Route 53
VPC ELB VPC Cliente
Instância
EC2
Instância
EC2
ELB
ELB
sa-east-1asa-east-1b

10. Protocolos

11. TCP/SSL
• Cada conexão entrante do cliente está
associada a uma conexão do backend
• Não ocorrem modificações nos
cabeçalhos
• O Proxy Protocol acrescenta o
endereço IP de origem, junto com o
endereço IP de destino e porta da
requisição
• O algoritmo Round Robin é utilizado
para o encaminhamento das requisições
HTTP/HTTPS
• A conexão cliente é terminada no
balanceador de carga, mas é servida de
um pool de conexões com o back-end
• Os cabeçalhos HTTP podem ser
modificados
• O cabeçalho X-Forwarded-For contém o
endereço IP do cliente
• O algoritmo Least Outstanding
Requests é utilizado para o
encaminhamento das requisições
• Suporte de Sticky Session disponível

12. Os Health Checks evitam
encaminhar tráfego para
instâncias com falhas

13. Health Checks
Instância
EC2
Instância
EC2
Instância
EC2
Os Health Checks
garantem que o
tráfego seja
deslocado da
instância que não
esteja respondendo
ELB

14. Health Checks
Suporta checks TCP e HTTP
Capacidade de personalizar a
frequência e o tempo máximo de espera
Servidor back-end precisa retornar 2xx
É muito importante considerar a
profundidade e a precisão das
checagens

15. O Idle Timeout permite fechar as conexões inativas no
balanceador de carga

16. Idle Timeouts
Período de tempo que uma conexão ociosa/inativa deve ser
mantida aberta.
Essa propiedade se aplica para ambas as conexões: do
cliente e do back-end.
Padrão é de 60 segundos, mas pode ser definido entre 1 e
3,600 segundos.
Os tempos de espera devem diminuir à medida que se
aprofunda nas camadas da aplicação

17. 15s
3s
3s15s
3s
9s
ELB
Instâncias
EC2
Amazon
S3
Amazon
RDS
Amazon
SWF
Idle Timeouts

18. Use múltiplas
Zonas de
Disponibilidade (AZs)

19. us-west-1b
VPC ELB VPC Cliente
Instância
EC2
Instância
EC2
ELB
ELB
sa-east-1asa-east-1b
Amazon
Route 53
Múltiplas Zonas de Disponibilidade

20. us-west-1b
VPC ELB VPC Cliente
Instância
EC2
ELB
ELB
sa-east-1asa-east-1b
Amazon
Route 53
Múltiplas Zonas de Disponibilidade

21. Sempre associe duas
ou mais subnets em
differentes zonas com o
seu balanceador de
carga

22. Usar múltiplas Zonas de
Disponibilidade pode introduzir
alguns desafios

23. RequestCount
Time
Tráfego mal equilibrado

24. VPC ELB VPC Cliente
Instância
EC2
Instâncias
EC2
ELB
ELB
sa-east-1asa-east-1b
Amazon
Route 53
Capacidade das instâncias mal equilibrada

25. VPC ELB VPC Cliente
Instância
EC2
Instâncias
EC2
ELB
ELB
sa-east-1asa-east-1b
Amazon
Route 53
Cross-Zone

26. RequestCount
Time
Cross-Zone Enabled
Tráfego mal equilibrado

27. Cross-Zone
O ELB absorve o impacto do cache de DNS nos clientes.
Elimina os desequilíbrios na utilização das instâncias back-
end.
As requisições são distribuídas uniformemente entre as
Zonas de Disponibilidade
Verifique os limites de conexão nos servidores
backend antes de ativá-lo
Não é cobrado o tráfego entre AZs efetuado
pelo ELB

28. Cada balanceador de carga pode possuir múltiples registros
DNS
O algoritmo Round Robin é utilizado para distribuir carga
entre Zonas de Disponibilidade
Os registros DNS podem mudar ao longo do
tempo, nunca utilice endereços IP
Depois de ser removido do DNS, os endereços
IP são drenados e colocado em quarentena
até por 7 dias.
Comprendendo os DNS

29. Otimização de DNS
// Create a wildcard CNAME or ALIAS in Route 53.
*.example.com ALIAS … elb-12345.us-east-1.elb.amazon.com
*.example.com CNAME elb-12345.us-east-1.elb.amazon.com
// prepend random content for each lookup made by the application.
PROMPT> dig +short 25a8ade5-6557-4a54-a60e-8f51f3b195d1.example.com
192.0.2.1
192.0.2.2
O cache de DNS nos clientes e nos ISPs pode fazer com que
os mesmos acessem sempre um único endereço IP
Registre um ‘wildcard’ CNAME ou ALIAS no Amazon Route 53

30. Suporte para SSL e HTTPS.
Suporte para os mais recentes ciphers e protocolos,
incluindo Elliptical Curve Ciphers e Perfect Forward
Secrecy.
Capacidade de personalizar totalmente os ciphers e
protocolos a serem utilizados por cada balanceador de
carga.
SSL Negotiation Suites são fornecidas para remover a
complexidade de seleção de ciphers e protocolos.
Offloading de SSL

32. Fornecem uma seleção de ciphers e protocolos que aderem às mais
recentes e melhores práticas da indústria.
Permite equilibrar as melhores práticas de segurança com a
capacidade do cliente para negociar uma conexão. Foram geradas
usando o tráfego da própria Amazon.com.
Lançado em uma cadência regular ou quando
novas vulnerabilidades são publicados.
Padrão para todos os novos balanceadores
de carga.
SSL Negotiation Policies

33. Em 24 horas, 62% dos
balanceadores de carga foram
migrados para a última SSL
Negotiation Policy, desativando o
protocolo SSLv3.
Mitigação da vulnerabilidade POODLE

34. @awscloud thank-you #AWS for making it so
easy to prevent #sslv3 #poodleattack Only
took about 3 clicks of my mouse.“
”@granticini

35. Para cada balanceador de carga são fornecidas 13
métricas de CloudWatch
Fornece uma visão detalhada sobre a saúde do
balanceador de carga e da pilha de aplicações.
Alarmes de CloudWatch podem ser configurados para
notificar, ou tomar medidas, no caso de qualquer
métrica sair do padrão
Todas as métricas são fornecidas com granularidade
de 1 minuto.
Métricas do Amazon CloudWatch

36. Contagem da quantidade de instâncias
operantes em cada zona de disponibilidade.
A causa mais comum são os Health Checks
excedendo o tempo limite de espera.
Pode testar fazendo repetidas requisições
contra a instância back-end a partir de outra
instância EC2.
Sempre procure a dimensão por Zona de
Disponibilidade.
HealthyHostCount

37. Mede o tempo decorrido em segundos após uma requisição deixar o
balanceador de carga, até que a resposta seja recebida.
Usando as funcões de min, avg e max; o CloudWatch
pode fornecer limites superiores e inferiores
da latência.
Pode investigar tempos de requisições individuais
usando os logs de acesso do ELB.
Latência

38. Quantidade de requisições que não puderam ser enviadas para as
instâncias back-end.
Cada nó do ELB consegue enfileirar até 1024 requisições, depois disso vai
retornar erro 503
Muitas vezes pode ser causado por não conseguir
abrir conexões com a instância de back-end.
Normalmente, é um sinal de uma aplicação
com poucos recursos (baixa escala)
SurgeQueue e Spillovers

39. Qualquer métrica do balanceador de carga pode ser usada para disparar
eventos do AutoScaling
Permitem remidensionar a capacidade dinamicamente, baseando-se na
visão do ELB da aplicação
Importante considerar todas as métricas ao usar
Autoscaling. Pode não estar ciente de outros
recursos que estão no limite
CloudWatch e AutoScaling

40. Fornecem informações detalhadas sobre cada requisição processada pelo
balanceador de carga.
Inclui o tempo da requisição, o endereço IP do cliente, latências,
caminho (request path), e as respostas do servidor.
São entregues em um bucket do Amazon S3 a
cada 5 ou 60 minutos.
Access Logs

41. ELB VPC
ELB
ELB
ELB Amazon S3
Os logs são indexados
por data, mas também
incluem o endereço IP
do nó do ELB
Access Logs

42. • timestamp
• elb name
• client:port
• backend:port
• request_processing_time
• backend_processing_time
• response_processing_time
• elb_status_code
• backend_state_code
• received_bytes
• sent_bytes
• “request”
2014-02-15T23:39:43.945958Z my-test-loadbalancer
192.168.131.39:2817 10.0.0.0.1 0.000073 0.001048 0.000057
200 200 0 29 "GET http://www.example.com:80/HTTP/1.1"
Access Logs

43. “Everything fails all the time”
Werner Vogels, CTO, Amazon.com

44. Esteja preparado para fazer nada!

45. Mitigação Isolamento
Restaurar a
redundância

46. Todos os balanceadores de carga estão dimensionados para lidar com a
perda de uma única zona de disponibilidade.
Os Health Checks do Amazon Route 53 desviam o tráfego
da Zona de disponibilidade que esteja falhando
O desvio é concluído dentro de 150 segundos.
Não existem outras dependências externas
Mitigação

47. Outras zonas não devem ser afeitadas pela falha
Evite dependências entre zonas.
Tenha cuidado com o trabalho gerado como resultado
do evento.
Nesse ponto, deveria estar operando com
capacidade reduzida, mas estável.
Isolamento

48. Os responsáveis pelos Healths Checks
executam o mesmo volume de atividade se
os endpoints estiverem operantes ou não.
Constant Work
tim
e
System activity
Time to react
Quando nada estiver falhando, o volume
de chamadas de API é zero. Quando a
falha ocorre, o volume de chamadas de
API tem picos.
tim
e
System activity
Time to react
Work on Failure

49. Restaurar o sistema de volta a plena capacidade.
Evite colocar carga adicional no sistema, apressando esta etapa.
Certifique-se que os recursos recuperados são
deixados em um estado consistente.
Recuperação completa quando terminar.
Restaurar a redundância

51. “Ajudamos os clientes AWS a cortar custos,
automatizar tarefas repetitivas, backup e a
melhorar a segurança.”
• Cloud8 é parceiro de tecnologia
e possui um produto que ajuda
na gestão do AWS estendendo
as funcionalidades
“O AWS é uma
plataforma completa
capaz de trazer ganhos
significativos de capital
e produtividade.”
- Renato Weiner,
CIO/Founder Cloud8

52. Os Desafios
• Monitorar custos do LB
• Automatizar tarefas para desligar infraestrutura ociosa
• Diagnóstico de melhores práticas para o LB

53. Solução
• Custos:
– relatórios detalhados e alertas;
• Automatizar tarefas:
– Agendamento de conexão e desconexão de instância ao LB;
– Desligamento ou downgrade de infra ociosa fora do horário comercial;
• Diagnóstico de melhores práticas para o LB:
– CrossZone habilitado
– Connection Draining
– Protocolos e Cyphers inseguros

54. Obrigado!!

55. São Paulo