Auto scaling
-
Upload
amazon-web-services-latin-america -
Category
Business
-
view
751 -
download
2
description
Transcript of Auto scaling
© 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
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
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
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
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
Por que Auto Scaling?
Escalabilidade Controle de Custos Aumentar disponibilidade
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
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
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 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
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 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.
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.
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) .
Por que Auto Scaling?
Escalabilidade Controle de Custos Aumentar 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 uma ação de Auto Scaling
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
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 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
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
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
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))
Equações de ponto de escalabilidade
𝑠𝑐𝑎𝑙𝑖𝑛𝑔 𝑝𝑜𝑖𝑛𝑡 = 𝑢𝑠𝑢á𝑟𝑖𝑜𝑠 𝑚á𝑥. 𝑝𝑜𝑟 𝑛ó − (𝑢𝑠𝑢á𝑟𝑖𝑜𝑠 𝑎𝑑𝑖𝑐. 𝑝𝑜𝑟 𝑚𝑖𝑛. ∗ 𝑡𝑒𝑚𝑝𝑜 𝑎𝑡é 𝑜𝑛𝑙𝑖𝑛𝑒)
𝑠𝑐𝑎𝑙𝑖𝑛𝑔 𝑝𝑜𝑖𝑛𝑡 = 400 − (27 ∗ 5)
𝑠𝑐𝑎𝑙𝑖𝑛𝑔 𝑝𝑜𝑖𝑛𝑡 = 265 usuários por nó
𝑠𝑐𝑎𝑙𝑖𝑛𝑔 𝑝𝑜𝑖𝑛𝑡 = 𝑢𝑠𝑢á𝑟𝑖𝑜𝑠 𝑝𝑜𝑟 𝑛ó ∗ 𝑐𝑝𝑢 𝑝𝑜𝑟 𝑢𝑠𝑢á𝑟𝑖𝑜 𝑠𝑐𝑎𝑙𝑖𝑛𝑔 𝑝𝑜𝑖𝑛𝑡 = 265 ∗ .2 𝑠𝑐𝑎𝑙𝑖𝑛𝑔 𝑝𝑜𝑖𝑛𝑡 = 53% cpu por nó
𝑐𝑝𝑢
𝑛𝑜𝑑𝑒=
𝑢𝑠𝑢á𝑟𝑖𝑜𝑠
𝑛𝑜𝑑𝑒∗
𝑐𝑝𝑢
𝑢𝑠𝑢á𝑟𝑖𝑜
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
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.
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”: 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
“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
Curva de escalabilidade antes…
min min
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
simultâneos
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”
• Economia de 46%
vs sem autoscaling
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
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 ainda mais,
alinhando nossa curva de demanda com a curva
de utilização.
Por que Auto Scaling?
Escalabilidade Controle de Custos Aumentar Disponibilidade
Obrigado!
Marcelo Leal Enterprise Solutions Architect