paint-brush
Otimização dramática de custos da AWS em 5 etapas (como economizamos 80%)por@oqtacore
461 leituras
461 leituras

Otimização dramática de custos da AWS em 5 etapas (como economizamos 80%)

por OQTACORE8m2023/08/11
Read on Terminal Reader

Muito longo; Para ler

Esta é a história de como reduzimos nossos custos da AWS em 80% em pouco menos de duas semanas.
featured image - Otimização dramática de custos da AWS em 5 etapas (como economizamos 80%)
OQTACORE HackerNoon profile picture
0-item
1-item

Esta é a história de como reduzimos nossos custos da AWS em 80% em pouco menos de duas semanas.

AWS é uma loja de doces para desenvolvedores

Preciso começar com uma introdução. Usamos a AWS desde 2018 para todos os nossos projetos e ela fez milagres para nós. Somos uma equipe totalmente distribuída e ter nosso próprio data center em algum lugar do mundo seria problemático. É muito mais fácil alugar recursos da AWS e pular todas as despesas de capital.

Negociar a compra de novos servidores com o CFO? Não! Gastar milhares incontrolavelmente na AWS? Conte comigo!


O problema com a AWS é que os desenvolvedores podem basicamente criar quaisquer recursos sem precisar aprová-los com nosso departamento financeiro. Com os data centers tradicionais, esse não é o caso — comprar um servidor adicional exigiria obter uma fatura da loja e pedir ao departamento financeiro para pagar por ela.


Então, basicamente, a base do problema é que, com a AWS, os desenvolvedores podem comprar os recursos na quantidade que quiserem e quando quiserem.

O que fizemos para reduzir os custos da AWS?

Não somos uma grande empresa e nossos custos da AWS são um pouco mais altos do que US$ 7.000 por mês em todas as contas da AWS. Além disso, vale ressaltar que hospedamos apenas estandes de DEV e QA, pois os estandes de PROD são pagos por nossos clientes. Nossos recursos são principalmente máquinas de desenvolvimento individuais, bancos de dados de teste e vários recursos personalizados para projetos de pesquisa, como Kinesis Firehose, Sage Maker, etc. Portanto, temos muitos recursos aleatórios que são difíceis de categorizar, estruturar, prever e controlar.


Então, como lidamos com a redução de nossos custos da AWS?


Primeiro , começamos a olhar para o Explorador de custos e identificamos os itens mais caros:

  • Encontramos um Bitcoin Node que estava em execução nos últimos quatro meses e custava US$ 600/mês, pois exigia um grande SSD com velocidade adicional provisionada. Fizemos uma pequena pesquisa sobre Bitcoin Ordinals e não removemos a máquina.

    Resolução: arquivamos o volume (custa US$ 6/mês) e encerramos a VM.

    Economia: US$ 594/mês


  • Encontramos uma máquina GPU Nvidia Tesla que custa US$ 531/mês. Nós o usamos até hoje para experimentos generativos de IA. Estamos pensando em construir nosso próprio aplicativo que gere texto para vídeo, então precisamos dessa máquina.

    Resolução: moveu o volume para uma instância spot.

    Economia: US$ 360/mês


  • Não é a mais cara, mas a descoberta mais surpreendente foi que esquecemos de remover um estande de demonstração-PROD em uma das regiões não utilizadas onde implantamos nossos scripts terraform para testar o lançamento do PROD “do zero”.

    Economia: $340/mês.


  • Muitos itens menores.
    Resoluções: variam.
    Economia: $ 1700 / mês


Em segundo lugar , começamos a mover tudo o que era possível para detectar instâncias. Este é um procedimento simples. Para uma máquina individual, você precisa desligá-la, desanexar o volume (lembre-se de anotar o caminho de montagem) e, em seguida, encerrar a máquina. Em seguida, você cria uma nova instância local (não importa qual AMI, apenas certifique-se de que a arquitetura da CPU seja compatível com o volume anterior). Depois que a instância spot for criada, desconecte (e não se esqueça de excluir!) o novo volume e anexe o volume anterior no mesmo caminho de montagem que estava na máquina original. Para ambientes Beanstalk, é mais simples — apenas alteramos as configurações de capacidade para utilizar apenas instâncias pontuais.


Economia: US$ 1.000/mês


Em terceiro lugar , limpamos os baldes S3 não utilizados (fizemos alguns bots de negociação automática que acumularam muitos dados de streaming). E configure a remoção automática de dados em vários baldes S3, para que não armazenemos dados de negociação por mais de um ano, pois eles se tornam completamente obsoletos e inúteis.


Economia: US$ 300/mês


Quarto , reduzimos alguns recursos. É uma questão de verificar a CPU e a RAM consumidas e, se observarmos menos de 50% de uso constante, baixamos o nível.


Economia: US$ 300/mês (seria 3x mais em instâncias sob demanda)


Quinto , configuramos o desligamento automático em máquinas individuais. Criamos várias funções lambda para diferentes tipos de tarefas: desligar uma VM SageMaker Jupyter após 1 hora de inatividade, desligar VMs individuais, DEV e QA representam o período noturno quando ninguém está trabalhando. Essas funções lambda são executadas em eventos cloudwatch diariamente. Existem lambdas para habilitar estandes de DEV e QA, bem como para facilitar o processo.


Economia: US$ 500/mês


Além disso, implementamos algumas soluções menores para economia adicional, mas elas não são abordadas neste artigo.


Até agora, economizamos cerca de $ 5.500 de nossa conta mensal de $ 7.000, o que representa cerca de 80% de todos os custos! Eu sabia que estávamos gastando demais com a AWS, mas nunca soube que era tanto. Ao longo do ano, isso significa cerca de $ 66.000 em economia.

Como as organizações abordam a otimização dos custos da nuvem?

Depois de ter nossa própria experiência com otimização de custos de nuvem, entendi como é importante rastrear cuidadosamente os custos de nuvem. Basicamente, a otimização de custos da nuvem pode economizar o suficiente para impulsionar os negócios se você colocar o dinheiro economizado em marketing. Ou você pode retirá-lo como dividendos e comprar um carro novo. A soma é grande e há muitas coisas que podem ser feitas com ela.


Uma vez que está fora de questão que a otimização de custos de nuvem é um esforço absolutamente necessário, como as empresas abordam isso? Vamos pensar em formas de implementar a gestão de resíduos na nuvem, das mais simples às mais avançadas.

1. Comprar apenas máquinas virtuais

Você pode abordar o problema da maneira mais tradicional possível. Negue as inúmeras possibilidades oferecidas pela AWS e apenas restrinja seus desenvolvedores de comprar máquinas EC2.


SQS? Não. DynamoDB? Não. Basta usar máquinas virtuais EC2 e instalar tudo nelas.


Prós:

  • Você pode prever muito bem os gastos, pois há uma taxa fixa para cada tipo de EC2 VM

  • Os desenvolvedores encherão as máquinas disponíveis com o software de que precisam. Assim como em um data center físico tradicional no local, aumentando assim a eficácia do gasto de dinheiro


Contras:

  • Você perde os benefícios do escalonamento automático

  • Seus desenvolvedores perdem tempo implementando coisas que já existem

  • Você sente falta de atualizações automáticas de software que seriam aplicadas automaticamente


Em suma, não é uma boa estratégia trabalhar com a nuvem como se você apenas alugasse hospedagem no GoDaddy.

2. Revise cada solicitação

E se você permitir que os desenvolvedores usem e dimensionem quaisquer recursos, mas eles tenham que negociá-los com o departamento especial que controla os custos? Os desenvolvedores não têm seus próprios direitos para comprar/dimensionar recursos, mas podem pedir a uma pessoa especial para comprar/dimensionar um recurso para eles.


Digamos que um desenvolvedor precise de um terminal Kinesis Firehose (sim, mencionei um serviço do qual você provavelmente nem ouviu falar). Seria uma tarefa simples para o desenvolvedor explicar o que deseja ao controlador? E então o desenvolvedor também deve explicar o raciocínio por trás do dimensionamento e provavelmente até provar que a escolha da arquitetura é boa e não é um desperdício em termos de gerenciamento de custos.


Ao fornecer um exemplo específico, pode-se ver que simplesmente não funciona dessa maneira. Só funcionaria se a equipe de gerenciamento de custos fosse composta por especialistas.


E isso é apenas a ponta do iceberg. Agora considere:


  • Um recurso tornando-se desnecessário devido à mudança arquitetônica

  • Um desenvolvedor deixando o trabalho e não removendo os recursos que usou para seus propósitos de desenvolvimento individual

  • Uma emergência quando um recurso precisa ser dimensionado rapidamente para evitar problemas de negócios


Prós:

  • Os desenvolvedores podem utilizar o máximo de benefícios dos recursos gerenciados pela AWS

  • Os gastos são bem controlados


Contras:

  • O desperdício de nuvem ainda pode vir de recursos desnecessários não removidos
  • A equipe de gerenciamento de custos precisa de um alto nível de conhecimento da AWS
  • O nível de burocracia pode prejudicar os negócios

3. Contrate uma equipe de FinOps

Uma maneira mais avançada seria realmente encontrar e contratar especialistas na AWS que controlariam os gastos. Eles podem usar as ferramentas fornecidas pela AWS para controlar os gastos imediatamente. Tem:


  • um explorador de custos

  • um subsistema de marcação

  • instâncias reservadas

  • planos de poupança

  • anomalias de custo

  • muito mais


Essas ferramentas não são fáceis de usar e exigem pessoal bem treinado que saiba o que fazer com elas. No entanto, você pode realmente começar a controlar seus custos de nuvem. Essa abordagem requer não apenas ferramentas e trabalhadores altamente qualificados, mas também uma estrutura na qual a equipe trabalhe: verificações periódicas de recursos subutilizados, procedimentos de redução e limpeza, entre outros.


Uma equipe que é basicamente DevOps com uma abordagem financeiramente consciente é chamada de FinOps.


Prós:

  • Os desenvolvedores têm todo o poder da AWS

  • Pequena sobrecarga de burocracia para os desenvolvedores

  • A equipe financeira tem total controle sobre os gastos em vários aspectos: por projeto, por equipe, etc.

  • Os desenvolvedores consomem recursos de forma consciente


Contras:

  • Requer pessoal altamente qualificado que ainda nem existe, então você precisa treinar um
  • Vulnerável ao fator humano
  • O tempo de reação é tão rápido quanto o período entre os check-ups — uma máquina EC2 não utilizada pode permanecer ligada por 1 a 2 semanas ou mais

4. Use um software de gerenciamento de resíduos na nuvem

Depois de pensar seriamente em contratar (ou aumentar sua própria) equipe FinOps, você também deve considerar um software de otimização de custos de nuvem de terceiros, como o Infinops. É o membro automático da equipe FinOps que trabalha 24 horas por dia, 7 dias por semana e não é suscetível a erros humanos. Esse software controla automaticamente sua nuvem para recursos subutilizados e outras formas conhecidas de economia, como:


  • Usando instâncias pontuais

  • Usando instâncias reservadas

  • Reduzindo o número de clusters OpenSearch no ambiente de controle de qualidade

  • Desativando VMs pessoais para a noite

  • Desligamento automático de VMs caras do SageMaker com Jupyter

  • etc


Todas essas dicas vêm automaticamente, pois seu sistema é constantemente verificado em busca de alterações. E esse conselho pode economizar até 80% de sua conta mensal . Isso geralmente significa economizar pelo menos dezenas de milhares de dólares ao longo do ano.


Prós:

  • Ótima ferramenta para a equipe FinOps

  • Ajuda FinOps iniciantes com técnicas de otimização

  • Reduz o fator humano

  • Impõe revisões periódicas do consumo de recursos

  • Impõe tags, gerenciamento de ciclo de vida, etc.

  • Permite rastrear várias contas da AWS de uma só vez


Contras:

  • Tem seu próprio custo (geralmente muito menos do que economiza)


Concluindo , gostaria de dizer que gerenciar os custos da AWS pode ser complicado. A economia de 80% da empresa mostra que é possível gastar menos com as mudanças certas. Esteja você definindo limites de recursos, obtendo aprovações, usando equipes de especialistas ou ferramentas automatizadas, é essencial ficar de olho nas despesas. Afinal, usar a nuvem deve facilitar as coisas, não encarecê-las.