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





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


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) .


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


• Sem autoscaling

• 672 horas de

instâncias EC2

• $302.40 em preços

“on-demand”


• 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


$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.


Escalabilidade Controle de Custos Aumentar Disponibilidade

Obrigado!

Marcelo Leal Enterprise Solutions Architect

Business

Auto scaling