2. Tópicos que veremos hoje…
• Introdução ao “Auto Scaling”
• Benefícios da utilização do Auto Scaling
• Controlar tempo de resposta das aplicações e utilização dos recursos
• Sustentar demanda cíclica e eventos metereológicos inesperados
• Aumentar Disponibilidade
• Controle de Custos
• Testes de performance para estabelecer estratégias de escalabilidade
• Tratar variações abruptas na demanda e “bounciness”
• Controle de Custos
AWS
The Weather
Channel
iba
Dreambox
3. Oportunidades de utilização do Auto Scaling
Lançar instâncias EC2 a partir
de templates reutilizáveis
Escalar conforme necessário
automaticamente
Substituição automática de
instâncias e manutenção de
capacidade EC2
4. Cenários Comuns
• Agendar um único “scale out” e flip para produção
• Acompanhar ciclos diários, semanais, ou mensais
• Provisionar capacidade dinamicamente, baseando-se em
consumo de CPU, memória, nr. de requisições, tamanho
da fila, nr. de usuários, etc.
• Adicionar “tag” às instâncias automaticamente
• Substituir instâncias que falham (checagem ELB ou EC2)
• Balancear automaticamente instâncias em múltiplas zonas
de disponibilidade.
Preparar para o lançamento
Ajustar capacidade
Estar pronto para picos
Simplificar alocação de Custos
Manter capacidade estável
Implementar Multi-AZ
5. Novidades no Auto Scaling
Melhor Integração
• Suporte na console EC2
• Agendar politicas de escalonamento
em templates CloudFormation
• ELB connection draining
• Anexar IP’s púbilicos
automaticamente em VPC
• Spot + Auto Scaling
Mais APIs
• Criar grupos com base em instâncias em
execução
• Criar configurações de lançamento com
base em instâncias em execução
• Anexar instâncias em execução ao grupo
• Descrever limites de conta para grupos e
configurações de lançamento
6. Por que Auto Scaling?
Escalabilidade Controle de CustosAumentar disponibilidade
7. The Weather Company
• Segundo canal de
televisão mais visto nos
EUA
• 85% das empresas
aéreas dos EUA
dependem das suas
previsões
• 163 milhões de
visitantes únicos entre
TV e web
8. Wunderground Radar e
Mapas
100 milhões de hits em um dia
1 bilhão “data points” por dia
Migração do sistema de radar de mapeamento em tempo real
wunderground.com para nuvem AWS
14. Antes da Migração – Modelo IT Tradicional não escala bem
Servidores
(110 Servidores)
Média de Carga de CPU Tempo de resposta HTTP
(~6000 ms)
Tempo de resposta HTTP
(5-15ms)
Servidores
(de 110 para 170 Instâncias)
Média de Carga de CPU
Depois da Migração - Wunderground Aplicação Radar
16. Por que Auto Scaling?
Escalabilidade Controle de Custos
Aumentar
Disponibilidade
17. “iba e AWS - Aumento de disponibilidade, autonomia,
gerência, capacidade de entrega e o melhor, com redução
significativa de custos”
“Escolhemos a AWS por
ser a opção com maior
gama de produtos e
serviços do mercado.
Eles possuem casos
conhecido de sucesso e
isso gera confiança”
- Luis Barrionuevo, CTO
do iba
• O iba é a loja (e-commerce) mais
completa de publicações digitais do
Brasil, contando com mais de 20 mil
títulos entre e-books, revistas e jornais
digitais.
• É uma empresa do Grupo Abril,
responsável pela plataforma de venda e
entrega de conteúdo digital da própria
editora e parceiros.
18. O Desafio
• Migrar de uma infraestrutura convencional para a
nuvem da Amazon um produto digital que exige
alta disponibilidade, possui importante audiência e
é parte do core business na Diretoria de Negócios
Digitais;
• Como reduzir nossos custos com data center e
aumentar a disponibilidade da plataforma?
• Estávamos em um momento que ocorriam muitos
projetos paralelos originados na área de produtos e
instabilidades na plataforma afetariam diretamente
nosso processo de migração;
• Substituição de hosts físicos e de grande porte de
banco de dados e cache para instancia EC2.
19. Papel da AWS e Benefícios alcançados
• Tivemos uma redução de ~60% de custos
em relação a infraestrutura anterior;
• Triplicamos a nossa capacidade de
entrega.
• Aumentamos nosso SLA e nossa nova
meta é de 99,90% de disponibilidade;
• Aplicação do auto scaling no ambiente de
produção e desativação dos ambientes de
desenvolvimento (dev, QA, Stage e CI) .
20. Por que Auto Scaling?
Escalabilidade Controle de CustosAumentar Disponibilidade
21.
22. Um pouco sobre nossa aplicação
• Ruby on Rails
• Unicorn
• Ensinamos
Matemática às
crianças!
26. O que é um alarme?
• Métricas no
CloudWatch
• Acima ou abaixo de
um limite, um alarme
é acionado
• O qual pode disparar
uma ação de Auto
Scaling
27. Testes de performance para criar um “baseline”
• Descobrir o número ideal de
processos “workers” por servidor
– Poucos e gera desperdício de
recursos
– Muitos e a performance sofre com
aumento da carga
• Conseguir a carga máxima
apropriada por servidor
– Nossos testes de performance
medem a quantidade de usuários
simultâneos
• Achar o “Chokepoint“ (limite)
– Para nós, isto foi utilização de CPU
29. Identificar o ponto para escalar
“Breaking point” foi cerca de 400 usuários por servidor
30. Nosso primeiro metodo para identificar os
pontos de escalabilidade
• Provisionar uma quantidade
estática de servidores que nós
sabemos que conseguem
sustentar a carga de pico
• Ajustar os alarmes para
escalabilidade (para cima/para
baixo) com base no aumento e
diminuição de carga
observados
• Funcionou, mas foi super
ineficiente, tanto no tempo
quanto dinheiro gasto
31. Um pouco de matemática – Identificar as variáveis
Independente
• Usuários simultâneos
Dependente
• Utilização de CPU
• Utilização de Memória
• I/O de Disco
• I/O de Rede
32. Mais matemática…
• Cerca de 1600 usuários por hora
• O que é cerca de 27 por minuto
• Sabemos que nós conseguimos
sustentar um máximo de cerca de
400 usuários por servidor,
utilizando 80% de CPU
• O que é cerca de 0.2% de uso de
CPU por usuário
33. Mais matemática – Quando escalar?
• Sabemos (dos nossos testes) que leva
cerca de 5 minutos para um novo nó estar
online
• Estamos adicionando 27 usuários por
minuto
• O que significa que temos que começar a
lançar novos nodos quando estamos com
cerca de 135 usuários ( 27 x 5 ) por nó
faltando para chegar ao máximo
• O que é cerca de 53% de utilização:
(80% - (0.2% * 135))
34. Equações de ponto de escalabilidade
𝑠𝑐𝑎𝑙𝑖𝑛𝑔 𝑝𝑜𝑖𝑛𝑡 = 𝑢𝑠𝑢á𝑟𝑖𝑜𝑠 𝑚á𝑥. 𝑝𝑜𝑟 𝑛ó − (𝑢𝑠𝑢á𝑟𝑖𝑜𝑠 𝑎𝑑𝑖𝑐. 𝑝𝑜𝑟 𝑚𝑖𝑛. ∗ 𝑡𝑒𝑚𝑝𝑜 𝑎𝑡é 𝑜𝑛𝑙𝑖𝑛𝑒)
𝑠𝑐𝑎𝑙𝑖𝑛𝑔 𝑝𝑜𝑖𝑛𝑡 = 400 − (27 ∗ 5)
𝑠𝑐𝑎𝑙𝑖𝑛𝑔 𝑝𝑜𝑖𝑛𝑡 = 265 usuários por nó
𝑠𝑐𝑎𝑙𝑖𝑛𝑔 𝑝𝑜𝑖𝑛𝑡 = 𝑢𝑠𝑢á𝑟𝑖𝑜𝑠 𝑝𝑜𝑟 𝑛ó ∗ 𝑐𝑝𝑢 𝑝𝑜𝑟 𝑢𝑠𝑢á𝑟𝑖𝑜
𝑠𝑐𝑎𝑙𝑖𝑛𝑔 𝑝𝑜𝑖𝑛𝑡 = 265 ∗ .2
𝑠𝑐𝑎𝑙𝑖𝑛𝑔 𝑝𝑜𝑖𝑛𝑡 = 53% cpu por nó
𝑐𝑝𝑢
𝑛𝑜𝑑𝑒
=
𝑢𝑠𝑢á𝑟𝑖𝑜𝑠
𝑛𝑜𝑑𝑒
∗
𝑐𝑝𝑢
𝑢𝑠𝑢á𝑟𝑖𝑜
35. Quanto escalar?
• O mínimo que podemos escalar é 1 nó por AZ, de
outra forma ficaríamos sem redundância
• Para nós, isto significa mais 800 usuários de
capacidade em 5 minutos, mais que suficiente para
suportar nossa taxa de adicionar 1600 usuários por
hora
• Adicionando 800 usuários de capacidade a cada 5
minutos, nós podemos suportar 9600 usuários
adicionais por hora
36. Avaliação de nossas descobertas
• No mundo real, “sobrou” recursos
escalando a partir de 53%
• Nosso teste de performance foi um pouco
mais pesado que o mundo real
• Números oriundos do seu teste de
performance são tão apurados quanto a
simulação de tráfego que você configurou
nos testes de performance.
38. Aceleração na carga não é constante
Contador de requisições para um período de 24 horas
39. Não podemos utilizar apenas um modelo
• Escalar muito agressivamente
– Provisionar mais que o necessário:
aumenta o custo
– “Bounciness”: adicionamos mais
do que precisamos e temos que
em seguida desprovisionar, o que
aumenta o custo
• Escalar de maneira insuficiente
– Performance ruim
– Indisponibilidade devido a falta de
capacidade
40. “Bounciness and steepness”
• Adicionar pontos de
escalonamento agendado
para eliminar “bounciness”
• Escalabilidade agendada
para os pontos de queda
abrupta da curva de
demanda
• Deixar a escalabilidade
dinâmica cuidar das
escalabilidade mais linear
44. O custo de NÃO escalar
• Nossa curva de
utilização
• Mínimo cerca de 5
usuários
simultâneos
• Max cerca de
10,000 usuários
simultâneos
45. O custo de NÃO escalar
• Sem autoscaling
• 672 horas de
instâncias EC2
• $302.40 em preços
“on-demand”
46. O custo de NÃO escalar
• Auto Scaling
quatro vezes por
dia
• 360 horas de
instâncias EC2
• $162 em preços
“on-demand”
• Economia de 46%
vs sem autoscaling
47. O custo de NÃO escalar
• Autoscaling quando
necessário, 12
vezes/dia
• 272 horas de
instância EC2
• $122.40 em preços
on-demand
• Economia de 24% vs
escalar 4 vezes/dia
• Economia de 60% vs
SEM autoscaling
48. O custo de NÃO escalar
$302/dia
$162/dia
$122/dia
51. Auto Scaling nos permitiu uma grande economia;
Com um pouco de matemática, a flexibilidade da
AWS nos permitiu economizar ainda mais,
alinhando nossa curva de demanda com a curva
de utilização.
52. Por que Auto Scaling?
Escalabilidade Controle de CustosAumentar Disponibilidade