Spot By NetApp análise da utilização do Elasticgroup na Convenia

Nesse post tenho como objetivo contar um pouco de como está sendo a utilização da Spot by NetApp. Importante analisar que a Spot tem um monte de produtos voltados para cloud, nesse post vou analisar apenas o Elasticgroup que é o produto da Spot voltado para gerenciar as instâncias EC2, similar ao AutoScalingGroup(ASG) da AWS.

OBS: Sempre que me referir a "Spot" com inicial maiúscula estou me referindo à empresa SpotByNetapp e sempre que eu me referir a "spot" com inicial minúscula estou me referindo ao tipo de instancia spot da AWS

Na Convenia já utilizávamos instâncias spot para todo serviço que não fossem crítico e admitissem interrupções. No mês da black friday utilizamos exclusivamente instâncias “On Demand” para evitar interrupções massivas devido ao esgotamento da oferta spot, esse foi o resultado:

No gráfico acima existe um spike de custo em dezembro causado pela utilização das instancias "On Demand". Após analisar o custo fizemos uma reunião de post mortem e decidimos avaliar o Elasticgroup da Spot que promete fallback para “on demand” caso a oferta spot se esgote.

De inicio posso dizer que gostamos de resultado final e passamos todos as instâncias para serem gerenciadas pelo Elasticgroup.

Como foi a integração??

Sempre que precisamos testar qualquer coisa dentro da Convenia fazemos uma POC com algum serviço interno para entender realmente os pontos negativos e positivos, e foi isso que fizemos.

O primeiro passo para integração é fazer a ligação da conta da Spot com a sua conta da AWS seguindo o passo a passo na própria documentação da Spot, esse passo apesar de muito bem explicado contém algumas etapas, caso haja dúvida na implantação ou mesmo em relação as possibilidades que a Spot pode trazer sugiro uma conversa com o pessoal da RealCloud que nos ajudou bastante a entender os produtos da spot e entender como fazer essa migração.

Após linkar a conta da AWS com a Spot seguimos um wizard que importa as configurações do AutoScalingGroup da aws para um Elasticgroup dentro da spot. Apenas isso foi necessário para ter as instancias sendo gerenciadas pela Spot, após a criação do Elastic group podemos inativar o nosso AutoScalingGroup(setando a capacidade desejada, mínima e máxima para 0) ou mesmo remove-lo.

No nosso caso, fazer essa migração para o primeiro serviço durou cerca de uma hora. Continuamos monitorando para ver como o Elasticgroup faria as trocas de instancias para conseguir mais saving e fizemos mais alguns testes para forçar refresh de instancias e interrupções para entender como ele lida com isso, na nossa experiência não tivemos nem uma surpresa, simplesmente não perde em nada para o ASG da AWS, ainda tem algumas funcionalidades a mais como vou falar mais para frente.

Um outro ponto importante que vale ressaltar durante a integração é que a RealCloud nos acompanhou durante todo o processo, e o billing começou a rodar apenas após a integração de todos os serviços.

Quais as vantagens da adoção da Spot?

A resposta lógica para essa pergunta seria custo mas vou começar falando das coisas que não tem haver com custo, o custo vamos analisar mais profundamente no próximo tópico, então seguem as outras vantagens:

Fallback para “On Demand”: Esse é um dos principais motivadores para a adoção na minha opinião, é muito difícil prever a oferta spot com eficiência, a AWS promete avisar sobre interrupções com 2 minutos de antecedência, dessa forma é possível construir automações para lidar com a interrupção mas eu particularmente não gosto de lidar com isso artesanalmente. O que acabamos fazendo é manter as instancias mais críticas com “On Demand”. Poder confiar que o Elasticgroup vai fazer o fallback corretamente te permite spotizar até as instancias mais críticas e evita que você faça a loucura de voltar todas as instancias para “On Demand” nas vesperas de uma black friday causando aquele spike de custo mostrado no inicio.

Abaixo os logs do Elasticgroup fazendo a substituição de instancias spot pot "On Demand":

5/21/2023, 5:30 AM, INFO, Updating group
5/21/2023, 5:30 AM, INFO, Falling back to on-demand, no spot instances could be launched.
5/21/2023, 5:30 AM, INFO, Scheduling action: [scale] ( , scaleTargetCapacity: 5 , scaleMinCapacity: 5 , scaleMaxCapacity: 8)
5/21/2023, 5:30 AM, INFO, Instances: [i-01b3bc7d84018f540,i-0762fba5e0348ef70,i-0d204f6f3e1b6a9a5,i-04182456095d6e21d] have been launched. Reason: Group update
5/21/2023, 5:30 AM, INFO, Updating Group Succeed
5/21/2023, 5:31 AM, INFO, Instance [i-0d204f6f3e1b6a9a5,i-01b3bc7d84018f540,i-04182456095d6e21d,i-0762fba5e0348ef70] successfully registered to load balancer: rh-live-core-84
5/21/2023, 5:31 AM, INFO, Instance [i-0d204f6f3e1b6a9a5,i-01b3bc7d84018f540,i-04182456095d6e21d,i-0762fba5e0348ef70] successfully registered to load balancer: rh-live-internal-core-84

Scheduled scalling: O Elasticgroup nos permite definir alguns schedulers no formato de cron para escalar as maquinas em determinados horários. Na Convenia deixamos no mínimo duas instancias rodando para os serviços principais durante o dia e por ser um sistema muito focado no publico brasileiro, o tráfego cai bastante durante a noite, nesse caso podemos configurar esse scheduler para desligar as instancias redundantes pela madrugada, trazendo um saving ainda maior

Simplicidade na organização de recursos: Para manter práticas do CodeReview e manter uma padronização mínima dos serviços utilizamos o terraform. Geralmente ao criar o autoscaling dentro da AWS acabamos criando uma serie de recursos avulsos, como scaling policies, asg attachments entre outros. Ao adicionar o recurso de Elasticgroup no nosso terraform notamos uma boa simplificação visto que o Elasticgroup é um único recursão que aglomera todas as funcionalidades, no final trocamos diversos recursos do terraform por apenas um.

Abaixo um exemplo real de um Elasticgroup criado pelo terraform na Convenia:

resource "spotinst_elastigroup_aws" "core_webserver_live_asg" {
  name = "core_webserver_live_asg"
  spot_percentage = 100
  orientation = "balanced"
  draining_timeout = 120
  fallback_to_ondemand = true
  desired_capacity = 5
  min_size = 5
  max_size = 8
  capacity_unit = "instance"

  scaling_target_policy {
    policy_name = "CPU track scaling"
    namespace = "AWS/EC2"
    metric_name = "CPUUtilization"
    statistic = "average"
    unit = "percent"
    target = 70
    cooldown = 120
  }

  instance_types_ondemand = "t3.small"
  instance_types_spot = [
    "t3.small",
    "t3a.small",
  ]

  subnet_ids = [var.subnet_1, var.subnet_2, var.subnet_3, var.subnet_4]
  product = "Linux/UNIX"

  target_group_arns = [
    aws_alb_target_group.core_live_target_group.arn,
    aws_alb_target_group.core_internal_live_target_group.arn
  ]

  security_groups = [aws_security_group.core_instance.id]
  enable_monitoring = false
  ebs_optimized = false
  image_id = data.vault_generic_secret.swarm_base_image.data["image_id"]
  ebs_block_device {
    device_name = "/dev/sda1"
    delete_on_termination = true
    volume_size = "32"
    volume_type = "gp3"
  }

  user_data = base64encode(templatefile("user_data.sh", {swarm_token = var.swarm_token}))

  tags {
    key = "Workload"
    value = "live-core"
  }

  tags {
    key = "Name"
    value = "live-core-webserver-elasticgroup"
  }

  iam_instance_profile = "my-super-secret-policy arn"
  health_check_type = "TARGET_GROUP"
  health_check_grace_period = 300

  scheduled_task {
    is_enabled = true
    task_type = "scale"
    cron_expression = "0 23 * * *"
    scale_target_capacity = 1
    scale_min_capacity = 1
    scale_max_capacity = 3
  }

  scheduled_task {
    is_enabled = true
    task_type = "scale"
    cron_expression = "30 8 * * *"
    scale_target_capacity = 5
    scale_min_capacity = 5
    scale_max_capacity = 8
  }

  region = "us-east-1"

  lifecycle {
    ignore_changes = [
      desired_capacity,
    ]
  }
}

Custo sobre o saving: Talvez esse seja uma dos principais atrativos na venda dos serviços pela Spot, o modelo de billing da Spot é sobre o seu saving logo não existe a possibilidade de você pagar por algo que você não vai ter, retorno garantido! Se seu billing não diminui você não paga nada.

Esses foram algumas das vantagens que notamos nessa migração mas confesso que a Convenia não utiliza todo o poder da Spot, ainda existe possibilidade para spotizar instancias statefull entre outras coisas, independente do seu case acho difícil acreditar que a Spot não tem alguma solução que possa trazer algum tipo de saving, quanto maior o seu sistema(em quantidade de maquinas) mais passa a fazer sentido essa adoção.

Mas e o Custo??

O principal motivador para a adoção da Spot é redução de custos, essa é a bandeira deles! A Convenia tem uma infra relativamente pequena e para quantificar esse saving adequadamente precisamos nos atentar a alguns detalhes.

Como mostrado no gráfico de billing acima, que contém apenas custo “On Demand e Spot”, em setembro de 2022 e abril de 2023 o custo permanece mais ou menos no mesmo patamar, isso é bom pois nesses últimos meses nossa infra cresceu um pouco, spotizar as instancias críticas que antes não eram spot nos permitiu esse resultado.

A spot tem um custo sobre o saving: nossa conta da spot varia em torno de 130 Bidens. Quando adicionamos esse custo ao valor mensal mostrado no billing da aws notamos que a conta de abril de 2023 supera um pouco a conta de setembro de 2022, isso se deve ao crescimento da nossa infra nesses meses mas mesmo sem esse crescimento não acredito que o saving teria sido expressivo a ponto de justificar a adoção da Spot apenas por custo. Importante notar que quanto maior for a sua infra maior é a justificativa para a adoção, talvez a Convenia não tenha tido resultados tão expressivos pelo tamanho da infra e pelo fato de já utilizar Instancias spot para alguns serviços, claro que o saving poderia ser ainda maior se spotizarmos as instancias statfull que temos.

Nosso total de desconto devido a instancias spot ficavam em torno de 65%, a taxa de Spot é de 28% sobre esse saving de 65 mas o que ninguem conta é que para uma empresa brasileira utilizando a Spot teremos algumas impostos que somados com a taxa da Spot podem arranhar os 40% desse saving.

Outra detalhe muito importante que é radicalmente negligenciado é o custo da mão de obra, por mais que a integração seja simples, trocar os ASGs massivamente pelo Elasticgroup exige uma validação mínima além de um acompanhamento para ver se está funcionando como previsto e se está atingindo o saving previsto, no fim o time vai morrer com alguns dias em cima dessa integração e mão de obra é caro!

Conclusão

No final, analisando o conjunto de vantagens e desvantagens julgo como positiva a utilização da Spot, se tivesse que julgar apenas a redução de custo com computing já não faria tanto sentido, mas ter um fallback para “on demand” automático, simples e confiável é a maior das vantagens para min, visto que não vamos ver spikes de custo nas épocas de black friday, o que já compensaria o preço pago pelo serviço da spot.

Essa conclusão de custo é muito particular da Convenia que tem uma infra relativamente pequena e já era bem espotizada antes. Conforme o crescimento da empresa acredito que o saving proporcionado passa a ser cada vez mais relevante. No aws summit de 2022 o Nubank mostrou um pouco do case deles de utilização da Spot, com o volume deles a spotização pode trazer um valor absurdo de custos, pra quem quiser ver esse case mais de perto só ver aqui no youtube