Concrete Logo
Hamburger button

(2+2) Computação mais barata, um guia rápido de precificação AWS EC2

  • Blog
  • 3 de Junho de 2014
Share

Já tem alguns anos que passamos na Concrete a trabalhar com Times Ágeis, e a valorizar os princípios de Lean Startup. Como consequência direta, infraestrutura passou a ser uma fonte constante de impedimentos e frustração.
Foi natural buscar uma solução para estes problemas em IaaS (Infrastructure as a service).

Começamos a testar opções em Cloud e eventualmente nos aproximamos da Amazon com a AWS (Amazon Web Services). Os times gostaram, e com nossa aproximação, acabamos por nos tornar os primeiros parceiros da AWS na America Latina em 2009.

Foi assim que usar AWS passou a ser obrigatório nas entregas. É a diferença entre começar o desenvolvimento hoje, com qualquer ambiente que seja necessário, ou começar algum dia, dependendo do quanto já descobrimos que é necessário e quanto de capacidade já temos disponível. E é claro, a diferença em time-to-market é gritante, e a diferença de satisfação pessoal de todos os envolvidos nem dá para falar.

Indo além disso, existe a questão do quanto pagamos por nossa infraestrutura, a que dá apoio a nossos desenvolvedores. Com o tempo, demos adeus aos nossos pequenos CPDs e nossos racks de máquinas, e fizemos isso com redução de custo (Custo Total), mesmo utilizando o mais simples no EC2, máquinas On Demand (sob demanda). https://aws.amazon.com/ec2/pricing/

É claro que, o hardware em si já fica mais barato. E além disso não precisamos ficar como babysitters de computador.

O primeiro passo é fácil e já gera economia, mas é apenas o começo e há muito mais ganhos e muito mais camadas para garimpar.

Uma das grandes inseguranças de quem visitou nosso stand durante o último AWS Summit brazuca (27-05-2014 São Paulo) era justamente sobre a precificação. Como usar AWS e como “comprar” EC2 de forma eficaz foi um tema recorrente, e foi isso que me motivou a escrever esse post e resumir a história.

AWS Summit 2014

On Demand

Começando pelo básico: On Demand. É bastante simples, você paga por cada hora utilizada (ou fração).
Ou seja, utilizou 0:10 minutos, paga por 1 hora.
Utilizou por 10 dias, 2 horas e 32 minutos, paga 243 horas (24 x 10 + 2 + 1).
Utilizou por 30 dias, paga por 720 horas. (24 x 30)

Reserved Instances

O passo 2 são as reservas de instância (Reserved Instances).
É fundamental compreender que reservas de instância não tem relação direta com as instâncias que você está utilizando. Ou seja, na hora de iniciar ou parar uma instância, nada amarra uma reserva a esta instância ou associa uma a outra diretamente.
Se a sua reserva de instância for do mesmo tipo de hardware e na mesma zona (Availability Zone) que a instância que você está usando, a associação é feita automaticamente.
Se houver um número diferente de reservas de instância e máquinas, a cobrança de cada máquina correspondente será feita com o rateio da sua instância reservada.
Antes de entrar no detalhe do rateio, é importante entender para que serve a instância reservada e quais são os diferentes tipos.

A reserva de instância tem duas funções. Para o cliente da AWS é uma oportunidade de reduzir seus custos em médio/longo prazo e ao mesmo tempo, transformar OPEX em CAPEX se isso fizer sentido em seu negócio. Ou seja, você paga um valor adiantado para reservar uma capacidade operacional no futuro. Como se estivesse comprando efetivamente uma máquina.
Para a AWS isso também é positivo pois dá a eles uma visão de médio e longo prazo para que eles planejem o gerenciamento e a capacidade de cada Datacenter.
Por exemplo: Na região de São Paulo uma máquina linux m1.small custa nesse momento $0.058/hora (USD) On Demand. Isso equivale a $509.52/ano (USD) ou aproximadamente $42.46/mês.
Fazendo uma reserva de instância medium de 1 ano, pagamos $142.00 dólares adiantados como reserva de hardware (que pode ser considerado CAPEX), mas a AWS cobrará menos (que On Demand) por hora $0.024. Com isso, o valor anual passa para $352.84/ano ou aproximadamente $29.41/mês uma redução de 30%.
Na metade do ano já chegamos ao payback do investimento inicial.

RetornoReserva

Periodos de Instâncias Reservadas

É importante entender como funciona cada tipo de Instância Reservada e como escolher.
Existem hoje 3 tipos de reserva com 2 períodos diferentes. Os tipos de reserva são light, medium e heavy e os períodos são de 1 ano ou 3 anos.
A distinção dos períodos é fácil. O investimento inicial será maior para o periodo maior, e o payback demora mais para ser alcançado. Em compensação, o valor efetivo por hora se torna menor. Traduzindo, as reservas de 3 anos são mais baratas (por hora de processamento), mas se você usar a máquina por 1 ano apenas, a reserva de 1 ano será mais vantajosa.

3 Anos vs. 1 Ano

Como dá para ver, a reserva de 3 anos medium de uma m1.small linux em São Paulo passa a ser mais barata que a de 1 ano a partir da metade do segundo ano de uso.

Tipos de Instâncias Reservadas

Os tipos de reserva de instâncias são desenhados para se tornar mais baratos em perfis de uso diferentes. Depende tipicamente, do percentual de tempo no periodo escolhido (1 ou 3 anos) que sua máquina vai ficar ligada.
Como diz o próprio nome, o uso light corresponde a um uso leve, ou seja, a máquina fica ligada por pouco tempo durante o período. O heavy é para máquinas que vão ficar o tempo todo ligadas, e o medium é o intermediário.
Lembre-se, a reserva não tem relação direta com a instância efetivamente ligada.
Existe apenas uma correspondência das condições em que as máquinas vão ficar com o melhor preço.
Se por exemplo, você for utilizar uma máquina por apenas 10% do tempo no periodo de 1 ano, o menor custo será em On Demand sem fazer reserva de instância.
Se o seu uso for the 50% em 1 ano, o mais barato será a medium.
Dica: no periodo de 1 ano pule as reservas light. Os melhores valores efetivos normalmente passam direto da On Demand para medium.
Visualmente, os pontos ótimos de economia ficam tipicamente assim:

Pontos Otimos

Ponto de Atenção para Tipo de Reserva de Instância

As Reserved Instances light e medium são muito similares. Muda-se o valor do investimento inicial e o valor cobrado por hora pela máquina. Ou seja, você só paga pelas horas utilizadas de computação.
A reserva heavy é diferente. Na heavy, você paga o valor inicial, e se paga por todas as horas do mês, não importando se a máquina ficou ligada ou não.
Nas reservas light e medium, sua invoice mensal exibirá as horas utilizadas das suas máquinas com um valor de hora descontado.
Na reserva heavy não é assim. Haverá 2 linhas de cobrança. Uma com todas as horas do mês de acordo com a taxa da utilização heavy, e outra com a sua máquina em que as horas efetivamente utilizadas aparecem com valor $0.

Pode parecer uma distinção pequena, mas na prática, você precisa ter uma boa certeza do uso da sua máquina para que a reserva heavy compense.
Digamos que você comece sua arquitetura utilizando como base uma máquina m1.medium, e mais tarde resolva trocar para c3.xlarge.
Se fosse tiver feito a reserva heavy, continuará pagando pela m1.medium todos os meses. Na prática, a heavy funciona como se você fosse dono dessa máquina por 1 ou 3 anos. Se você usar ou não, continua pagando.

Se existe um sentimento de que sua arquitetura está estabilizada, use a heavy. Caso contrário, espere para ter certeza, ou simplesmente utilize uma reserva medium.
A reserva heavy tipicamente exige mais de 90% de uso do tempo para ser mais barata que a reserva medium.
Pense que o uso heavy é para aquela máquina que de qualquer maneira, por bem ou por mal, tem que estar sempre lá ligada 24x7x365.

No momento, não é possível no Brasil revender sua Reserva de Instância, ainda que você possa comprar as reservas de instâncias de terceiros no Marketplace da AWS. Se fosse possível revender as reservas de instância, o problema da certeza na reserva heavy estaria eliminado. Hoje, para fazer uma revenda das reservas é necessário ter um Tax ID norte-americano e uma conta bancária lá.

Disponibilidade de Reservas de Instâncias

A AWS disponibiliza uma certa quantidade de reservas de instância e de máquinas spot em cada zona de disponibilidade (de modo rudimentar, cada zona de disponibilidade corresponde a um Datacenter diferente).
Antes de subir suas instâncias, verifique se a zona de disponibilidade na qual pretende subir as instâncias possui reservas disponíveis para contratar. Isso é particularmente importante na Virgínia onde o uso do EC2 é maior.
Por exemplo, digamos que você possa subir suas instâncias nas zonas East 1a, 1b e 1c. Se na 1c não houver reservas de instâncias disponíveis, é sinal de que o Datacenter correspondente a 1c está mais próximo de sua capacidade máxima.
Suba suas máquinas em alguma das outras zonas de disponibilidade da região e faça a reserva de instâncias assim que possível.

Rateio

O rateio da cobrança não é complexo para entender, mas na prática pode gerar alguma confusão, ainda mais se você tiver multiplas contas agregadas. Mas vamos ao mais simples;
Uma instância reservada te dá um desconto, hora a hora, em todas as máquinas daquele tipo e zona.
Digamos que você tenha 1 reserva de instância por 1 ano medium para uma máquina linux m1.medium na região Asia 1 (Tokyo).
O valor On Demand no momento para essa máquina é de $0.122/hora.
Manter apenas uma instância ligada nos primeiros 15 dias do mês faz com que o valor da hora dessa máquina caia para $0.048/hora durante estes 15 dias.
Se nos outros 15 dias do mês, uma outra máquina igual ficar ligada na mesma zona, cada máquina receberá metade deste desconto. Ou seja, $0.085/hora.
A máquina que ficou ligada apenas nos últimos 15 dias do mês terá o valor por hora de $0.085, e é isso que aparecerá no relatório para essa máquina.
Para a primeira máquina, o valor por hora será a média, ou seja, 15 dias a $0.048/hora e 15 dias a $0.085/hora, ou seja $0.0665/hora.
Com muitas reservas de instância e muitas máquinas, pode ficar difícil relacionar o número por hora visto no relatório com os valores do On Demand ou da hora da reserva, mas a lógica usada é sempre essa. Os valores são rateados hora a hora.

Repare ainda que, se durante 1 hora nenhuma máquina estiver ligada que seja compatível com essa reserva (m1.medium Asia 1), a sua reserva de instância fica sem uso nessa hora e você a perde. Entretanto, se no momento seguinte você escalar e se utilizar de 10 máquinas simultâneas, as 10 receberão um desconto rateado nessa hora.

Instâncias Spot

Quando iniciamos uma instância em spot, do ponto de vista lógico, essa instância em nada difere de uma instância On Demand. A variação fica na forma de aquisição.
Uma instância spot é uma instância em que pagamos pela hora de execução como se fosse um leilão.
Ao requisitar a máquina, especificamos o valor máximo pelo qual queremos pagar por uma hora da instância. Se o valor que queremos pagar for maior que o valor atual “de mercado” da instância, recebemos uma máquina. Se o valor atual for maior, não recebemos a máquina.
Veja nesse post como funciona a sequência de requisição de uma máquina spot.
É bom que fique claro, uma instância comprada em spot é exatamente igual a uma instância comprada On Demand. A AWS separa um conjunto de máquinas para vender em spot e manter um equilibrio em sua capacidade ociosa, mas fora isso, tudo o que você roda em uma máquina On Demand, você pode rodar em uma máquina Spot.

Cristie's Auction (1808)

Cristie’s Auction (1808)

A verdadeira diferença está justamente na forma de compra e na garantia de entrega.

Em uma máquina On Demand, a máquina fica reservada para você, e a única forma de você perder essa máquina (ao menos temporariamente) é se houver algum tipo de defeito no seu hardware (isso ainda existe lá por baixo).
Com uma máquina spot, os valores flutuam, e se o valor de mercado ficar maior que o valor que você está disposto a pagar, você perde o controle da máquina imediatamente. Como se alguém tivesse tirado ela da tomada. E essa máquina é entregue a alguém que se mostrou disposto a pagar mais por ela.

Ainda assim, a máquina comprada em spot é usualmente muito mais barata que a máquina On Demand. Podemos até mostrar, partindo da premissa que existe disponibilidade de máquinas On Demand, que o preço da máquina spot não deveria nunca passar o preço On Demand sob as mesmas condições.

Tenho certeza que esse método de compra já gerou e ainda vai gerar muitas teses de doutorado em Teoria dos Jogos. Na prática, hoje, para o tipo correto de uso, as máquinas spot são a forma mais barata de compra.
Por exemplo, uma máquina m3.xlarge linux na Europa (Irlanda) custa hoje On Demand $0.308/hora (USD). Essa mesma máquina, nesse exato momento, ao comprarmos em spot custa $0.0401/hora.
Repare, exatamente a mesma máquina pode ser comprada por hora em um valor 80% menor.
E ele também será naturalmente menor que o preço da máquina On Demand, mesmo que fizessemos uma reserva heavy de 3 anos. Que hoje está em $0.091/hora.

Ainda assim, corremos o risco de perder essa máquina a qualquer momento, digamos que alguém resolva bater o recorde de calculo de digitos de π exatamente nesse dia. Isso pode provocar uma alta de preços e você pode perder sua máquina. Seria muito ruim se isso acontecesse com seu banco de dados principal, ou se o seu site saisse do ar, mesmo que por pouco tempo. Nesse casos, uma máquina On Demand e uma reserva heavy não tem risco e também tem um preço muito bom.

No final, todo tipo de processamento da qual você pode temporariamente abrir mão vai se enquadrar perfeitamente nesse tipo de compra.
Alguns exemplos podem ser:

  • Testes Automatizados
  • Trabalhos em Batch em geral
  • Computação Científica
  • Encoding de Video ou Audio
  • etc

Ou seja, tarefas opcionais das quais você pode abrir mão, tarefas que você pode rodar mais tarde e a sensibilidade de tempo é menor, tarefas que podem rodar mais rápido com poder computacional extra, ou simplesmente se você não puder pagar por uma computação mais cara (em alguns casos, simulações científicas ficariam simplesmente caras demais).

Espero que com isso o básico de precificação tenha ficado mais claro. Agora vamos ao básico de uso dos recursos, e de como sua arquitetura pode te ajudar a economizar também.

Escalando Verticalmente

O procedimento para escalar verticalmente na AWS é relativamente simples. Desligamos a máquina que estamos usando, por exemplo, uma m1.small e religamos utilizando um outro tamanho, como por exemplo uma m1.medium.

É como se você tivesse trocado seu hardware por um maior.
E nesse caso, você pode também diminuir, o que equivaleria a revender seu servidor grande e comprar um menor, economizando na troca.

O caso de uso é simples, imagine que a utilização do seu sistema esteja crescendo dia a dia, como no gráfico abaixo.

Crescimento Regular

Você não precisa advinhar quantos usuários vai ter ou qual vai ser a sua carga, e poderá aumentar sua capacidade conforme vê que precisa crescer.
No gráfico abaixo, você pode ver o crescimento de uma máquina m1.small para uma m1.medium.

Vertical

Repare que esse gráfico mostra como em uma abordagem antiga, precisaríamos comprar uma máquina equivalente a uma m1.medium desde o início do projeto. Se nos primeiros 6 meses de projeto precisavamos apenas de uma m1.small, a economia com essa escalada vertical é a diferença entre a m1.medium e a m1.small durante estes 6 meses. Veja abaixo:

Economia Vertical

Outra condição indicada para se utilizar a escala vertical é sobre uma sazonalidade relativamente previsível.
Como exemplo, uma plataforma de comércio eletrônico que não escale bem na horizontal, pode precavidamente ser escalada verticalmente em momentos críticos, como nas proximidades dos dias das Mães, no Black Friday, Natal, etc.

Veja essa ilustração de um uso sazonal, aumentando e diminuindo durante o ano.

Sazonalidade

Nesse caso, ao nos aproximarmos de um período sazonal com mais expectativa de uso podemos fazer uma janela para subir uma máquina nova maior.

Sazonalidade Vertical

É claro que a escalabilidade vertical poderia ser utilizada na oscilação diária. O que complica é que temos a necessidade de desligar a máquina para poder religá-la com outro tamanho. É possível, mas nesse caso, o ideal é utilizar uma escala horizontal.

Escalando Horizontalmente

A idéia da escala horizontal é de agregar mais máquinas que possam responder aos clientes de forma paralela.
A grande vantagem sobre a escala vertical é que não temos downtime algum para acrescentar mais poder de processamento.
Sua desvantagem (relativa) é que as aplicações precisam ser desenhadas de forma que a escalabilidade horizontal seja possível.
Por exemplo, usualmente não podemos mais guardar arquivos nos discos locais de cada servidor, e nem mesmo em seus discos EBS. Fica melhor para as soluções utilizarem o S3 de forma a unificar os arquivos de cada servidor que trabalha em paralelo.

Com a escala horizontal, podemos aproximar bem mais a necessidade do uso e a capacidade disponível, momento a momento (similar a transformação em um sinal em digital utilizando a transformada de Fourier).

Colocamos o CloudWatch para monitorar nossas máquinas e então sinalizar condições de transição ao autoscaling group. Com isso, sempre que a demanda sobe, adicionamos mais máquinas para fazer o atendimento de nosso serviço. E quando a demanda diminui, podemos diminuir em conjunto também.

Veja nestes gráfico como ficaria uma cobertura de demanda intensa diária utilizando autoscaling. Nessa escala temos cerca de 36 horas, com o vale do gráfico representando o período noturno.

Auto Scaling Diario

Repare que começamos o gráfico com um pico de uso dos sistemas e com 5 instâncias ligadas. Conforme a demanda diminui, vamos automaticamente desligando instâncias. O número de instâncias vai gradativamente diminuindo para 4, 3, 2, até atingir o mínimo de 1 instância ligada.

Dependendo de como é a curva de uso dos seus sistemas, a escalabilidade horizontal tem um pontencial enorme de economia. Muitas vezes sendo até mais significativa que todas as outras que citei até aqui.

Cuidado com os Impostos

Ainda que exista alguma incerteza na cabeça de muitas pessoas sobre a incidência de impostos na contratação dos serviços da AWS diretamente no exterior, lembre-se:
Se você está contratando a AWS, você é responsável pelo recolhimento dos impostos apropriados, mesmo que esteja pagando via cartão de crédito.
Pagar com o cartão não significa, por exemplo, que não se deveria recolher IRRF sobre o valor remetido ao exterior.
Leão
Se quiser evitar esse risco, ou essa dúvida, contrate um dos parceiros brasileiros da Amazon. Estes poderão te dar uma nota fiscal brasileira e te evitar aborrecimentos, além de, é claro, poder te ajudar na gestão ou execução dos serviços.

Última Dica

Use a calculadora da Amazon para fazer simulações e se familiarizar com todas as opções. Só com o uso e o tempo isso vai se tornar natural: https://calculator.s3.amazonaws.com/index.html
E se precisar de ajuda… chame a gente 😉