Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.
© 2014 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or i...
Tópicos que veremos hoje…
• Introdução ao “Auto Scaling”
• Benefícios da utilização do Auto Scaling
• Controlar tempo de r...
Oportunidades de utilização do Auto Scaling
Lançar instâncias EC2 a partir
de templates reutilizáveis
Escalar conforme nec...
Cenários Comuns
• Agendar um único “scale out” e flip para produção
• Acompanhar ciclos diários, semanais, ou mensais
• Pr...
Novidades no Auto Scaling
Melhor Integração
• Suporte na console EC2
• Agendar politicas de escalonamento
em templates Clo...
Por que Auto Scaling?
Escalabilidade Controle de CustosAumentar disponibilidade
The Weather Company
• Segundo canal de
televisão mais visto nos
EUA
• 85% das empresas
aéreas dos EUA
dependem das suas
pr...
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 ma...
30.000
Estações
Pessoais
Source: Wunderground, Inc. 2013
Por que Auto Scaling?
Por que Auto Scaling?
Por que Auto Scaling?
Por que Auto Scaling?
Hurricane Sandy
Antes da Migração – Modelo IT Tradicional não escala bem
Servidores
(110 Servidores)
Média de Carga de CPU Tempo de respos...
Escalar para garantir performance
consistente durante alta demanda
Por que Auto Scaling?
Escalabilidade Controle de Custos
Aumentar
Disponibilidade
“iba e AWS - Aumento de disponibilidade, autonomia,
gerência, capacidade de entrega e o melhor, com redução
significativa ...
O Desafio
• Migrar de uma infraestrutura convencional para a
nuvem da Amazon um produto digital que exige
alta disponibili...
Papel da AWS e Benefícios alcançados
• Tivemos uma redução de ~60% de custos
em relação a infraestrutura anterior;
• Tripl...
Por que Auto Scaling?
Escalabilidade Controle de CustosAumentar Disponibilidade
Um pouco sobre nossa aplicação
• Ruby on Rails
• Unicorn
• Ensinamos
Matemática às
crianças!
Estratégias utilizadas
Escalabilidade com
alarmes
CloudWatch
Escalabilidade
agendada
(onetime, recorrente)
Carga de trabalho perfeita para utilização do
Auto Scaling
Escalando com alarmes do CloudWatch
O que é um alarme?
• Métricas no
CloudWatch
• Acima ou abaixo de
um limite, um alarme
é acionado
• O qual pode disparar
um...
Testes de performance para criar um “baseline”
• Descobrir o número ideal de
processos “workers” por servidor
– Poucos e g...
Testes de Performance
Identificar o ponto para escalar
“Breaking point” foi cerca de 400 usuários por servidor
Nosso primeiro metodo para identificar os
pontos de escalabilidade
• Provisionar uma quantidade
estática de servidores que...
Um pouco de matemática – Identificar as variáveis
Independente
• Usuários simultâneos
Dependente
• Utilização de CPU
• Uti...
Mais matemática…
• Cerca de 1600 usuários por hora
• O que é cerca de 27 por minuto
• Sabemos que nós conseguimos
sustenta...
Mais matemática – Quando escalar?
• Sabemos (dos nossos testes) que leva
cerca de 5 minutos para um novo nó estar
online
•...
Equações de ponto de escalabilidade
𝑠𝑐𝑎𝑙𝑖𝑛𝑔 𝑝𝑜𝑖𝑛𝑡 = 𝑢𝑠𝑢á𝑟𝑖𝑜𝑠 𝑚á𝑥. 𝑝𝑜𝑟 𝑛ó − (𝑢𝑠𝑢á𝑟𝑖𝑜𝑠 𝑎𝑑𝑖𝑐. 𝑝𝑜𝑟 𝑚𝑖𝑛. ∗ 𝑡𝑒𝑚𝑝𝑜 𝑎𝑡é 𝑜𝑛𝑙𝑖𝑛𝑒)
𝑠𝑐...
Quanto escalar?
• O mínimo que podemos escalar é 1 nó por AZ, de
outra forma ficaríamos sem redundância
• Para nós, isto s...
Avaliação de nossas descobertas
• No mundo real, “sobrou” recursos
escalando a partir de 53%
• Nosso teste de performance ...
Escalonamento agendado
Aceleração na carga não é constante
Contador de requisições para um período de 24 horas
Não podemos utilizar apenas um modelo
• Escalar muito agressivamente
– Provisionar mais que o necessário:
aumenta o custo
...
“Bounciness and steepness”
• Adicionar pontos de
escalonamento agendado
para eliminar “bounciness”
• Escalabilidade agenda...
Curva de escalabilidade antes…
minmin
min
min
min
…e depois
min
min
min
min
min
Colocando tudo junto…
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...
O custo de NÃO escalar
• Sem autoscaling
• 672 horas de
instâncias EC2
• $302.40 em preços
“on-demand”
O custo de NÃO escalar
• Auto Scaling
quatro vezes por
dia
• 360 horas de
instâncias EC2
• $162 em preços
“on-demand”
• Ec...
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-d...
O custo de NÃO escalar
$302/dia
$162/dia
$122/dia
Curva da demanda alinhada com a curva de utilização…
…e uma (geralmente) curva de tempo de resposta mais constante
Auto Scaling nos permitiu uma grande economia;
Com um pouco de matemática, a flexibilidade da
AWS nos permitiu economizar ...
Por que Auto Scaling?
Escalabilidade Controle de CustosAumentar Disponibilidade
Obrigado!
Marcelo Leal
Enterprise Solutions Architect
Auto scaling
Próxima SlideShare
Cargando en…5
×

Auto scaling

1.185 visualizaciones

Publicado el

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

Publicado en: Empresariales
  • Sé el primero en comentar

Auto scaling

  1. 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. 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. 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. 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. 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. 6. Por que Auto Scaling? Escalabilidade Controle de CustosAumentar disponibilidade
  7. 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. 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. 9. 30.000 Estações Pessoais Source: Wunderground, Inc. 2013
  10. 10. Por que Auto Scaling?
  11. 11. Por que Auto Scaling?
  12. 12. Por que Auto Scaling?
  13. 13. Por que Auto Scaling? Hurricane Sandy
  14. 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. 15. Escalar para garantir performance consistente durante alta demanda
  16. 16. Por que Auto Scaling? Escalabilidade Controle de Custos Aumentar Disponibilidade
  17. 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. 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. 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. 20. Por que Auto Scaling? Escalabilidade Controle de CustosAumentar Disponibilidade
  21. 21. Um pouco sobre nossa aplicação • Ruby on Rails • Unicorn • Ensinamos Matemática às crianças!
  22. 22. Estratégias utilizadas Escalabilidade com alarmes CloudWatch Escalabilidade agendada (onetime, recorrente)
  23. 23. Carga de trabalho perfeita para utilização do Auto Scaling
  24. 24. Escalando com alarmes do CloudWatch
  25. 25. 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
  26. 26. 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
  27. 27. Testes de Performance
  28. 28. Identificar o ponto para escalar “Breaking point” foi cerca de 400 usuários por servidor
  29. 29. 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
  30. 30. 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
  31. 31. 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
  32. 32. 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))
  33. 33. Equações de ponto de escalabilidade 𝑠𝑐𝑎𝑙𝑖𝑛𝑔 𝑝𝑜𝑖𝑛𝑡 = 𝑢𝑠𝑢á𝑟𝑖𝑜𝑠 𝑚á𝑥. 𝑝𝑜𝑟 𝑛ó − (𝑢𝑠𝑢á𝑟𝑖𝑜𝑠 𝑎𝑑𝑖𝑐. 𝑝𝑜𝑟 𝑚𝑖𝑛. ∗ 𝑡𝑒𝑚𝑝𝑜 𝑎𝑡é 𝑜𝑛𝑙𝑖𝑛𝑒) 𝑠𝑐𝑎𝑙𝑖𝑛𝑔 𝑝𝑜𝑖𝑛𝑡 = 400 − (27 ∗ 5) 𝑠𝑐𝑎𝑙𝑖𝑛𝑔 𝑝𝑜𝑖𝑛𝑡 = 265 usuários por nó 𝑠𝑐𝑎𝑙𝑖𝑛𝑔 𝑝𝑜𝑖𝑛𝑡 = 𝑢𝑠𝑢á𝑟𝑖𝑜𝑠 𝑝𝑜𝑟 𝑛ó ∗ 𝑐𝑝𝑢 𝑝𝑜𝑟 𝑢𝑠𝑢á𝑟𝑖𝑜 𝑠𝑐𝑎𝑙𝑖𝑛𝑔 𝑝𝑜𝑖𝑛𝑡 = 265 ∗ .2 𝑠𝑐𝑎𝑙𝑖𝑛𝑔 𝑝𝑜𝑖𝑛𝑡 = 53% cpu por nó 𝑐𝑝𝑢 𝑛𝑜𝑑𝑒 = 𝑢𝑠𝑢á𝑟𝑖𝑜𝑠 𝑛𝑜𝑑𝑒 ∗ 𝑐𝑝𝑢 𝑢𝑠𝑢á𝑟𝑖𝑜
  34. 34. 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
  35. 35. 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.
  36. 36. Escalonamento agendado
  37. 37. Aceleração na carga não é constante Contador de requisições para um período de 24 horas
  38. 38. 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
  39. 39. “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
  40. 40. Curva de escalabilidade antes… minmin min min min
  41. 41. …e depois min min min min min
  42. 42. Colocando tudo junto…
  43. 43. 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
  44. 44. O custo de NÃO escalar • Sem autoscaling • 672 horas de instâncias EC2 • $302.40 em preços “on-demand”
  45. 45. 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
  46. 46. 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
  47. 47. O custo de NÃO escalar $302/dia $162/dia $122/dia
  48. 48. Curva da demanda alinhada com a curva de utilização…
  49. 49. …e uma (geralmente) curva de tempo de resposta mais constante
  50. 50. 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.
  51. 51. Por que Auto Scaling? Escalabilidade Controle de CustosAumentar Disponibilidade
  52. 52. Obrigado! Marcelo Leal Enterprise Solutions Architect

×