Você pode economizar até 90% em custos de computação com Spot instances. Veja o que são, por que usá-las e quando vale a pena adotá-las.
Apesar de poderem reduzir seus custos de computação entre 20% e 80% e, de quebra, deixar suas aplicações mais resilientes, as Spot instances (ou Spot VMs no Google Cloud) costumam ser bem menos usadas do que deveriam.
Os motivos vão da natureza pouco previsível desses recursos ao medo de interrupções nos workloads, passando pela complexidade de configurá-los e gerenciá-los. Mas o motivo mais comum para tanta gente fugir das Spot instances é, simplesmente, a falta de familiaridade com elas.
Saber como contornar esses obstáculos aparentes vai ajudar você a destravar uma economia em computação que ainda está parada na mesa.
Nesta série em duas partes, vamos cobrir tudo o que você precisa saber para extrair o máximo das Spot instances.
Na parte um, vamos falar sobre o que são as Spot instances, por que usá-las e quando usá-las. Na parte dois, vamos mostrar como otimizar a utilização das Spot instances com Auto Scaling groups e como maximizar a economia usando o Spot Scaling.
O que são Spot instances?
As Spot instances funcionam mais ou menos como aquelas passagens aéreas baratas para o mesmo dia, que aparecem por causa de cancelamentos de última hora ou assentos não vendidos. Para preencher essas vagas antes da decolagem, as companhias aéreas costumam derrubar bastante o preço.
No caso das instâncias de computação, os provedores de nuvem oferecem capacidade on-demand ociosa por preços bem mais baixos que os das instâncias on-demand — com até 90% de desconto — como forma de aproveitar essa sobra.
Você só precisa definir um preço de lance para a Spot instance — o máximo que está disposto a pagar por hora — e, se o preço Spot (o preço atual no mercado spot) estiver abaixo do seu lance, a instância roda.
Por outro lado, o provedor de nuvem pode retomar as Spot instances com apenas dois minutos de aviso, caso a demanda por instâncias on-demand de preço cheio aumente — o que pode interromper sua aplicação.
Spot instances e passagens aéreas têm em comum a chance de adquirir algo (poder computacional, no primeiro caso, e passagens, no segundo) por um preço bem menor. Só que existe um certo grau de incerteza e risco no meio do caminho: as Spot instances podem ser retomadas se o preço de mercado superar seu lance, e as passagens de última hora podem sumir se outra pessoa comprar antes.
As duas situações mais comuns em que ocorrem interrupções são:
- Quando há um pico de demanda por instâncias on-demand ou reservadas
- Quando os preços Spot ultrapassam o lance (menos provável hoje em dia)
Por que usar Spot instances (dica: não é só pela economia)
Embora a economia em EC2 (de até 80%!) seja sempre apontada como a grande vantagem das Spot instances, ela não é o único benefício.
Usar Spot instances não torna as aplicações mais resilientes por si só, mas, em geral, exige que elas já tenham certo nível de resiliência para lidar bem com as possíveis interrupções desse tipo de instância.
Por exemplo: como aplicações rodando em Spot instances precisam, idealmente, ser arquitetadas para absorver interrupções com elegância, você já deveria tê-las projetado com checkpoints, mecanismos de auto-save ou distribuição de workloads entre várias instâncias.
Dessa forma, sua infraestrutura:
- Lida melhor com oscilações;
- Mantém o desempenho nos horários de pico; e
- Reduz os riscos de possíveis interrupções ou falhas.
Em momentos de pico, as Spot instances podem ser integradas ao seu sistema para absorver o aumento de demanda, garantindo que ele suporte oscilações de tráfego ou de workload sem queda de desempenho.
Com instâncias mais baratas, dá para destinar mais recursos a redundância e failover, e distribuir os workloads entre mais instâncias.
E, se uma instância sofrer uma interrupção, outras podem continuar processando partes do workload, minimizando o impacto de qualquer falha individual. Isso garante que seus workloads migrem para outra instância sem grandes implicações de custo.
Entendendo os EC2 Instance Pools
Para tirar o melhor proveito das AWS Spot instances, é importante entender o conceito de EC2 instance pools. Um EC2 instance pool é a capacidade total de um tipo de instância (por exemplo, m5.xlarge) em uma determinada região.
Quando há capacidade ociosa em um instance pool, essa sobra é chamada de Spot Capacity pool.
Cada família de instância, tamanho de instância, zona de disponibilidade e região tem EC2 instance pools próprios e, portanto, Spot capacity pools próprios também.
Por isso, não dá para colocar "todos os ovos na mesma cesta". Quanto mais pools você acessar, mais diversificada será a sua seleção de instâncias — o que reduz as chances de não haver Spot instances disponíveis para a sua aplicação.
Quando usar Spot instances
De modo geral, as Spot instances são mais indicadas para workloads que:
- São flexíveis;
- Não têm requisitos específicos de horário;
- Podem ser distribuídos / divididos em tarefas executadas em paralelo; e
- Toleram interrupções
Vamos detalhar os casos em que faz sentido adotar Spot instances, mas, antes, aqui vão três perguntas para você descobrir se seus workloads se encaixam nesse modelo:
- Meus workloads são tolerantes a falhas?
Como as Spot instances podem ser interrompidas, os workloads precisam ser projetados para lidar com isso sem causar falhas críticas nem perda de dados. Workloads tolerantes a falhas conseguem continuar rodando ou se recuperar rapidamente quando as instâncias são interrompidas ou encerradas. 2. O workload pode ser parado em menos de 2 minutos? Os workloads precisam poder ser interrompidos em um curto intervalo para evitar perda de dados ou indisponibilidade. Se o seu workload puder ser parado em menos de dois minutos, fica bem mais fácil reagir às interrupções de Spot instances. Por isso, aplicações stateless são uma ótima escolha para Spot instances, já que não armazenam dados de sessão. Isso facilita a migração entre instâncias sem perda de funcionalidade ou de dados, deixando-as resilientes a interrupções. 3. Posso ser flexível quanto a tipos de instância e zonas de disponibilidade? Distribuir seus workloads entre várias instâncias e zonas de disponibilidade reduz a vulnerabilidade a interrupções, diluindo o risco. Lembre-se: capacidade é uma propriedade de um Spot instance pool. Cada tipo de instância em cada zona de disponibilidade é um pool separado. Quando você consegue acessar mais de um pool, o risco de interrupção em todas as capacidades ao mesmo tempo é menor do que em um único pool. Espalhar a carga por várias zonas de disponibilidade diminui a dependência de um único pool, garantindo continuidade mesmo se uma zona enfrentar restrições de capacidade ou picos de preço.
De forma mais específica, vale considerar o uso de Spot instances nas situações a seguir.
Ambientes de teste e CI/CD
Ambientes de teste/desenvolvimento e tarefas de CI/CD geralmente não exigem uptime contínuo, porque são usados de forma intermitente para trabalhar em features específicas ou validar mudanças. Além disso, tarefas de desenvolvimento e teste podem ser reiniciadas, ou pausadas e retomadas (com um pouco de planejamento), sem perda crítica de dados — o que as torna mais tolerantes a interrupções.
Esses workloads costumam ser flexíveis quanto aos requisitos de recursos e se adaptam a diferentes tipos de instância ou zonas de disponibilidade sem comprometer o trabalho em andamento.
Tarefas de processamento em batch
Processamento em batch e jobs de ETL muitas vezes não são críticos quanto ao tempo, e essa flexibilidade combina perfeitamente com Spot instances.
Essas tarefas também podem ser quebradas em unidades menores e independentes, distribuídas entre várias instâncias sem grande impacto caso uma delas seja interrompida.
Assim, a interrupção de uma instância não compromete a conclusão do job inteiro, já que o workload pode ser redistribuído entre as outras instâncias disponíveis. E, caso não haja instâncias disponíveis, os jobs podem ser estruturados para salvar estados intermediários e retomar do último checkpoint em caso de interrupção.
Computação de alto desempenho (HPC) e processamento de big data
Tarefas de computação de alto desempenho envolvem manipular e analisar grandes volumes de dados. As Spot instances fazem sentido para esse tipo de workload porque essas tarefas podem ser distribuídas entre várias instâncias e escalam para cima e para baixo com facilidade.
Esse tipo de processamento costuma ser caro, já que rodar grandes datasets exige bastante recurso computacional. Mas, com Spot instances, o custo por instância cai muito — e, quando se fala em milhares de instâncias, a diferença é enorme.
Servidores web
Servidores web são ótimos candidatos a Spot instances porque normalmente são stateless. Eles geralmente não armazenam dados localmente nem dependem de informações de sessões anteriores e, por isso, podem ser interrompidos sem grande impacto.
Em muitos casos, cada requisição é processada de forma independente, sem depender de informações de sessão armazenadas.
Workloads em containers / Kubernetes
Aplicações em containers costumam ser projetadas para serem stateless, o que as torna boas candidatas a Spot instances.
Como os containers, em geral, não armazenam dados específicos de sessão, novos containers podem subir ou ser encerrados sem afetar o sistema como um todo.
Além disso, como os containers dividem aplicações em unidades menores e independentes, workloads em containers se adaptam com facilidade a diferentes tipos de instância ou zonas de disponibilidade. Essa flexibilidade combina perfeitamente com a natureza variável das Spot instances.
Cobrimos tudo o que você precisa saber sobre Spot instances — do conceito ao aproveitamento prático das vantagens, passando pelos casos de uso em que dá para extrair o máximo desse modelo.
Na parte dois da nossa série, vamos falar sobre os Auto Scaling groups (ASGs), que ajudam você a lidar com interrupções de Spot e otimizar sua utilização, e sobre o Spot Scaling, que simplifica a configuração e o gerenciamento dos ASGs para você maximizar a economia com Spot e a disponibilidade da aplicação.