Auto scaling
3 gostaram1,412 visualizações
O documento apresenta um guia sobre a implementação de auto scaling na AWS, destacando seus benefícios como aumento de disponibilidade, controle de custos e melhoria na performance de aplicações. Ele inclui casos de sucesso de empresas que migraram para a nuvem, como a The Weather Company e a IBA, além de estratégias para otimizar o processo de escalabilidade. Também são abordados testes de performance e como escalonar dinamicamente com base em demandas variáveis.
Auto scaling
- 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
- 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
- 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
- 41. Curva de escalabilidade antes… minmin min min min
- 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