São Paulo
Elastic Load Balancing:
Melhores PráticasDamian Traverso - Solutions Architect
28 Maio, 2015 | São Paulo
O Elastic Load Balancing distribui
automaticamente o tráfego de entrada dos
aplicativos em várias instâncias do Amazon EC2
Elástico Seguro Integrado Custo-benefício
Instância
EC2
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
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
Arquitetura
us-w
est-
1b
Amazon
Route 53
VPC ELB VPC Cliente
Instância
EC2
Instância
EC2
ELB
ELB
sa
-ea
st-
1a
sa
-ea
st-
1b
Protocolos
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
Os Health Checks evitam
encaminhar tráfego para
instâncias com falhas
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
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
O Idle Timeout permite fechar as conexões inativas no
balanceador de carga
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
15s
3s
3s15s
3s
9s
ELBInstâncias
EC2
Amazon
S3
Amazon
RDS
Amazon
SWF
Idle Timeouts
Use múltiplasZonas de Disponibilidade (AZs)
us-w
est-
1b
VPC ELB VPC Cliente
Instância
EC2
Instância
EC2
ELB
ELB
sa
-ea
st-
1a
sa
-ea
st-
1b
Amazon
Route 53
Múltiplas Zonas de Disponibilidade
us-w
est-
1b
VPC ELB VPC Cliente
Instância
EC2ELB
ELB
sa
-ea
st-
1a
sa
-ea
st-
1b
Amazon
Route 53
Múltiplas Zonas de Disponibilidade
Sempre associe duas ou mais subnets em
differentes zonas com o seu balanceador de
carga
Usar múltiplas Zonas de Disponibilidade pode introduzir
alguns desafios
Req
uest
Co
un
t
Time
Tráfego mal equilibrado
VPC ELB VPC Cliente
Instância
EC2
Instâncias
EC2
ELB
ELB
sa
-ea
st-
1a
sa
-ea
st-
1b
Amazon
Route 53
Capacidade das instâncias mal equilibrada
VPC ELB VPC Cliente
Instância
EC2
Instâncias
EC2
ELB
ELB
sa
-ea
st-
1a
sa
-ea
st-
1b
Amazon
Route 53
Cross-Zone
Req
uest
Co
un
t
Time
Cross-Zone Enabled
Tráfego mal equilibrado
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
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
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
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
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
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
@awscloud thank-you #AWS for making it so
easy to prevent #sslv3 #poodleattack Only
took about 3 clicks of my mouse.“”@granticini
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
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
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
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
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
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
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
• 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
“Everything fails all the time”Werner Vogels, CTO, Amazon.com
Esteja preparado para fazer nada!
Mitigação IsolamentoRestaurar a
redundância
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
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
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
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
“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
Os Desafios
• Monitorar custos do LB
• Automatizar tarefas para desligar infraestrutura ociosa
• Diagnóstico de melhores práticas para o LB
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
Obrigado!!
São Paulo