Eu muitas vezes apontei as instâncias EC2 Spot como um recurso que só teria alguma utilidade se implementada em escala mundial.

A menos que você tem uma enorme quantidade de poder computacional e uma infinidade de clientes espalhados por todos os fusos horários do mundo, com uma grande variedade de cargas de trabalho, você simplesmente não terá variações constantes na oferta e procura (resultando em alterações nos preços) que são necessárias para criar um verdadeiro mercado.

Um lembrete rápido: as instâncias Spot permitem que você economize até 90% (quando comparado com os preços On-Demand), dando lances para a capacidade EC2. As instâncias serão executadas sempre que o seu lance for superior ao preço corrente, e pode ser terminada (com um aviso de dois minutos), na presença de lances mais altos para a mesma capacidade (determinado por região, zona de disponibilidade e tipo de instância).

Uma vez que as instâncias Spot vão e vem, é preciso prestar atenção na sua estratégia de lance e no seu modelo de persistência, a fim de maximizar o valor que você obterá delas. Olhando de outra forma, estruturando sua aplicação no caminho certo, você pode gerar uma economia de até 90% (ou, se você tiver um orçamento apertado, você pode obter 10x mais capacidade computacional). Esta é uma posição muito interessante para você, como arquiteto de nuvem para sua organização. Você pode exercitar suas habilidades técnicas para reduzir os custos da capacidade computacional em direção a zero, ao fazer aplicações sensíveis ao preço e mais tolerante a falhas. Domine os prós e contras das instâncias Spot e você (e sua organização) irão sair ganhando!

A tendência é clara

Ao olhar para trás na história do EC2 – desde o lançamento de instâncias individuais sob demanda, e em seguida, instâncias Spot, contêineres e fleets Spot –, a tendência é bastante clara: você deve prestar atenção em casos individuais de longa duração e aos preços de lista. Você pode agora pensar em coleções de instâncias, com um tempo de vida indeterminado, rodando com o melhor preço possível, como determinado pela oferta e demanda dentro de pools de capacidade individual (grupos de instâncias que compartilham os mesmos atributos). Esta nova maneira de pensar pode libertar você de alguns velhos padrões de pensamento e pode abrir a porta para algumas formas novas e intrigantes para obter enormes quantidades de capacidade computacional rápida e barata, para que você possa construir aplicações muito legais a um preço que você pode pagar.

Gostaria de salientar que há uma situação ganha-ganha quando se trata da Spot. Você (e seus clientes) ganham obtendo poder computacional a um preço mais econômico possível em um determinado ponto no tempo. A Amazon ganha porque nossa frota de servidores (veja a página de Infraestrutura Global da AWS para uma lista de locais) é mantida ocupada fazendo o trabalho produtivo. A alta utilização melhora a nossa estrutura de custos, e também tem um benefício ambiental.

Práticas recomendadas Spot

Ao longo dos próximos meses, com muita ajuda da equipe da EC2 Spot, estou planejando compartilhar algumas das práticas recomendadas para o uso das Instâncias Spot. Muitas dessas práticas serão apoiados com exemplos reais, que os nossos clientes têm compartilhado conosco; estes não são exercícios teóricos ou acadêmicos. Hoje eu gostaria de lançar a série descrevendo brevemente algumas das práticas recomendadas.

Vamos definir o conceito de um pool de capacidade um pouco mais detalhadamente. Como mencionei acima, uma pool de capacidade é um conjunto de instâncias EC2 disponíveis que partilham a mesma região, zona de disponibilidade, sistema operacional (Linux / Unix ou Windows), e tipo de instância. Cada pool de capacidade EC2 tem a sua própria disponibilidade (o número de instâncias que podem ser lançados em qualquer momento particular no tempo) e seu próprio preço, conforme determinado pela oferta e demanda. Como você pode ver, os aplicativos que podem ser executados em mais de um pool de capacidade estão em melhor posição para acessar consistentemente uma capacidade de computação mais econômica. Note que a capacidade em um pool é compartilhada entre instâncias On-Demand e instâncias Spot, assim que os preços Spot podem subir na medida que haja um aumento na demanda para instâncias Spot ou um aumento dos pedidos de instâncias On-Demand.

Aqui estão algumas das práticas recomendadas para você começar:

Construir aplicações sensíveis ao preço – Como disse antes: a computação em nuvem é uma combinação de um modelo de negócio e uma tecnologia. Você pode escrever código (e projetar sistemas) que são sensíveis ao preço, e que tem o potencial de tornar o orçamento na nuvem da sua organização muito melhor. Esta é uma nova área para um monte de tecnólogos; meu conselho para você é para esticar a descrição do seu trabalho (e seu modelo interno de quem você é e o que seu trabalho envolve) para incluir projetos para redução de custos.

Você pode começar a passar algum tempo investigando (ou construindo algumas ferramentas utilizando a API do EC2 ou o AWS Command Line Interface – CLI) toda a gama pools de capacidade que estão disponíveis para você dentro da região, ou regiões, que você usa para executar seu aplicativo. Preços elevados e um alto grau de variação de preços ao longo do tempo indicam que muitos de seus concorrentes concorrem por capacidade no mesmo pool. Procure pools que têm preços mais baixos e preços mais estáveis (atuais e históricos) para encontrar pechinchas e taxas de interrupção mais baixas.

Verifique a histórico de preços – É possível acessar o histórico dos preços em uma base por pool de 90 dias (3 meses). Instâncias que são atualmente muito populares entre os nossos clientes (as R3 como eu as descrevo) tendem a ter preços Spot um pouco mais voláteis. As gerações mais antigas (incluindo c1.8xlarge, m1.small,cr1.8xlarge, e cc2.8xlarge) tendem a ser muito mais estáveis. Em geral, escolher as gerações de instâncias mais antigas irá resultar em preços líquidos mais baixos e em menos interrupções.

Use vários pools de capacidade – Muitos tipos de aplicativos podem ser executados (ou podem ser facilmente adaptado para funcionar) em vários pools de capacidade. Por ter a capacidade de executar em vários pools, você reduzir a sensibilidade do seu aplicativo a picos de preços que afetam um pool ou dois (em geral, há pouquíssima correlação entre os preços em diferentes pools de capacidade). Por exemplo, se você executar em cinco diferentes pools suas oscilações de preços e interrupções podem ser cortados em 80%.

Uma abordagem de alta qualidade para esta prática recomendada pode resultar em múltiplas dimensões da flexibilidade e acesso a muitos pools de capacidade. Você pode executar em múltiplas zonas de disponibilidade (bastante simples com o Auto Scaling e o Spot Fleet API) ou você pode executar em diferentes tamanhos de instâncias dentro da mesma família (o Amazon EMR tem este comportamento). Por exemplo, seu aplicativo pode descobrir em quantos CPUs ele está em execução e, em seguida, lançar segmentos de trabalho suficientes para manter todos eles ocupados.

A adesão a esta prática recomendada também implica que você deve se esforçar para utilizar quantidades aproximadamente iguais da capacidade em cada pool; isto tenderá a minimizar o impacto das mudanças de capacidade e preços Spot.

Para saber mais, leia sobre as instâncias Spot na documentação do EC2.

Fique ligado

Como disse antes, este é um post introdutório e temos muito mais ideias e códigos reservados para vocês! Se tiver comentários, ou se você gostaria de contribuir com as suas próprias dicas sobre o Spot para esta série, por favor me envie no e-mail: awseditor@amazon.com.

***

Artigo escrito por Hugo Tanzarella. 

Este artigo faz parte do AWSHUB, rede de profissionais AWS gerenciado pelo iMasters.