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