Apresentações do AWS Summit Sao Paulo 2014. Baixe o conteúdo preparado por nossos especialistas para auxiliá-lo na jornada para a nuvem.

1. © 2014 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in part without the express consent of Amazon.com, Inc.
Melhorando a disponibilidade e reduzindo
custos utilizando Auto Scaling
Marcelo Leal
Enterprise Solutions Architect

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

9. 30.000
Estações
Pessoais
Source: Wunderground, Inc. 2013

10. Por que Auto Scaling?

11. Por que Auto Scaling?

12. Por que Auto Scaling?

13. Por que Auto Scaling?
Hurricane Sandy

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

15. Escalar para garantir performance
consistente durante alta demanda

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

22. Um pouco sobre nossa aplicação
• Ruby on Rails
• Unicorn
• Ensinamos
Matemática às
crianças!

23. Estratégias utilizadas
Escalabilidade com
alarmes
CloudWatch
Escalabilidade
agendada
(onetime, recorrente)

24. Carga de trabalho perfeita para utilização do
Auto Scaling

25. Escalando com alarmes do CloudWatch

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

28. Testes de Performance

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.

37. Escalonamento agendado

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

41. Curva de escalabilidade antes…
minmin
min
min
min

42. …e depois
min
min
min
min
min

43. Colocando tudo junto…

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

49. Curva da demanda alinhada com a curva de utilização…

50. …e uma (geralmente) curva de tempo de resposta mais constante

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

53. Obrigado!
Marcelo Leal
Enterprise Solutions Architect