paint-brush
Fiz a AWS perder dinheiro - Veja como!por@paulelie
2,769 leituras
2,769 leituras

Fiz a AWS perder dinheiro - Veja como!

por Paul-Élie5m2022/07/29
Read on Terminal Reader
Read this story w/o Javascript

Muito longo; Para ler

Esta é uma pequena série que eu queria compartilhar há muito tempo sobre os fundamentos da “Otimização de Custos” na AWS. O custo de I/O do serviço DocumentDB está entre 0,20$ e 0,30$ por 1 milhão de I/Os. O preço da instância é rapidamente compreensível: você paga por uma instância e o preço dependerá de seus recursos (CPU, RAM etc.) Custos de armazenamento e armazenamento de backup**: iguais aos anteriores, é bastante compreensível e podemos rastrear e estimar facilmente os custos deles por GB armazenado.

Company Mentioned

Mention Thumbnail
featured image - Fiz a AWS perder dinheiro - Veja como!
Paul-Élie HackerNoon profile picture


Esta é uma pequena série que eu queria compartilhar há muito tempo sobre os fundamentos da “Otimização de Custos” na AWS.


Vamos começar esta jornada com o DocumentDB !


Não hesite em 👏 se gostou deste post ;)


Ok, para ser honesto, este título é clickbait *.*


Eu definitivamente poderia escrever algo como “como fiz otimização de custos em nossa infraestrutura AWS respeitando algumas diretrizes comuns fornecidas na documentação ” mas é muito menos cativante, não?

Talvez alguns de vocês já conheçam esses truques e boas práticas.


Se você está procurando diretamente a lista de verificação que estou sugerindo, role aqui.

Entenda o custo de E/S complicado do serviço DocumentDB

Se você olhar para a página de preços deles, ela é dividida por 4 dimensões de custos, eu a resumo aqui:

  • O preço da instância : bem, esse custo é rapidamente compreensível: você paga por uma instância e o preço dependerá de seus recursos (CPU, RAM, etc.)
  • Custos de armazenamento e armazenamento de backup : o mesmo que acima, é bastante compreensível e podemos rastrear e estimar facilmente os custos deles, fatura da AWS por GB armazenado. Legal.
  • A parte complicada é o I/O do banco de dados : a AWS cobrará entre 0,20$ e 0,30$ (dependendo da região da instância) por 1 milhão de I/O!!

Então, o que está por trás do I/O?


A AWS explica que, com o serviço DocumentDB, você não precisa provisionar recursos de I/O com antecedência, o que é interessante, porque você não tem limitações de armazenamento e pode lidar facilmente com uma seleção de operações de I/O. Parece justo, já que você cobra pelo uso.


A AWS descreve em sua documentação o que cobre as operações de E/S, principalmente todas as operações como localizar, inserir, atualizar e excluir ou alguns recursos como fluxos de mudança e índices TTL (time to live).

Bem, tudo o que atingir o volume de armazenamento será cobrado de você.


Espere, o que, 0,20 $ por milhão de E/S?

Vamos fazer a AWS perder dinheiro, agora mesmo!

Há uma frase na documentação do AWS DocumentDB que vai chamar sua atenção (e carteira 💸):

Uma vez que os dados foram lidos do volume de armazenamento e continuam a residir na memória, as leituras subsequentes dos mesmos dados não incorrem em E/S adicionais.

Essa frase é a chave para entender o que está por trás das E/Ss.

Quais operações usam menos E/S?


As consultas que usam um índice provavelmente usarão menos E/S, pois você não está verificando todo o armazenamento de sua coleção. Certamente consumirá E/S, mas muito menos do que digitalizar uma coleção inteira.


Além disso, a RAM de sua instância precisa cobrir o tamanho do índice, o que permitirá que você não incorra em E/S adicionais.


Tenha em mente que você precisa respeitar alguns princípios com o uso do índice.

Lista de verificação ✅

Aqui está meu conselho/lista de verificação quando você deseja otimizar seu uso de E/S, reduzir seus custos e melhorar o desempenho.


Você verá que não sou um gênio, pois apenas agrego informações da página de documentação do AWS DocumentDB com algumas práticas recomendadas comuns que não são estritamente aplicáveis ao DocumentDB.


É sempre bom refrescar nossas mentes com princípios.


  • 🧠 Em primeiro lugar, lembre-se disso : menos E/S = mais barato = melhor desempenho, aqui não se trata apenas de custos ou desempenho, mas as duas coisas estão ligadas.

  • Remova índices não utilizados : você não sabe o quão caro é um índice não utilizado para uma coleção ocupada. Fiz minha empresa economizar $ 2.000 / mês assim 🤌 , excluindo índices não utilizados. E é muito fácil rastrear índices não utilizados com esta consulta:


db.collection.aggregate([{$indexStats:{}}]);


Consulta de estatísticas de índice


A consulta produzirá as ops de campo que correspondem ao número de vezes que seu índice é atingido. Dependendo da carga do seu aplicativo, considere remover o índice não utilizado.


  • 🧐 Ativar insights de desempenho e operações de criação de perfil : se você usa o RDS, pode estar ciente dos insights de desempenho , ele fornece algumas métricas e informações muito úteis sobre as consultas que estão atingindo o desempenho do DocumentDB e você pode ver rapidamente as consultas que consomem I /Os operações (e a quantidade delas), então é muito bom rastrear facilmente um gargalo. Outra forma de monitorar consultas lentas ou consultas collscan é ativando Profiling operations , como o nome sugere, é o perfil de algumas operações para você (aqui está um link para obter mais informações: ), você pode definir um limite que colocará no CloudWatch um log de um operação que está demorando mais de n ms . Muito útil para rastrear a quantidade de consultas que estão realizando COLLSCAN por exemplo. Por favor, ative ambas as opções, pois elas são muito valiosas!


  • 💾 Olhe sempre primeiro para os seus dados : você precisará identificar o melhor campo de alta cardinalidade que deseja indexar, se você não está acostumado com o conceito de cardinalidade do índice, a documentação do AWS DocumentDB está bem explicada :)


  • 🫠 Evite coleções pequenas complicadas : se você planeja ter uma coleção que terá três campos com um deles com uma chave única e se planeja realizar muitas atualizações/inserções, considere a modelagem de sua coleção, porque suas operações de I/O vão atingir como o inferno e, portanto, seu uso de I/O.


  • ⏱️ Evite TTL, também conhecido como time-to-leave indexes : (na maioria das vezes) você pode lidar com isso sem definir um time-to-leave index, então verifique se o parâmetro TTL não está habilitado na instância ou cluster.


  • 💡 Explique! Uma maneira muito simples de verificar a seletividade do índice do planejador de consulta quando você está fazendo uma nova consulta (ou não) é realizar uma operação de explicação com o parâmetro executionStats . Você ficará surpreso ao ver que algumas consultas que você está pensando atingem o índice, mas não atingem nenhum índice...


  • ☯️ Não crie um índice para um campo booleano . Apenas não. Lembre-se da cardinalidade.


  • ⚖️ Monitore o tamanho médio de um objeto para cada coleção que você possui com este comando: db.<mycollection>.stats(1024) Um tamanho médio extremo pode criar rapidamente um bloqueio em suas consultas e aumentar as operações de I/Os porque a RAM de sua instância não é suficiente. Por favor, monitore objetos de perto e não armazene campos desnecessários. Se precisar armazenar muitos campos, considere otimizar as consultas não selecionando todos os campos.


  • ⚠️ Esteja ciente de que DocumentDB não é MongoDB. É principalmente compatível com o MongoDB, mas não é o MongoDB, pois existem alguns comportamentos específicos de merda. Por exemplo, se você deseja realizar uma consulta com o operador $regex , você precisará `hint()` seu índice, pois é obrigatório. Os operadores de exclusão nunca usarão nenhum índice, portanto, considere esses comportamentos ao criar ou otimizar seus índices!


  • 👉 Nunca insinuar . Exceto pelos casos de uso muito específicos mencionados acima, você deve evitar o uso de hint , lembre-se de que, se o planejador de consultas não eleger seu índice, é por um bom motivo. Na maioria das vezes é porque é mais longo ou equivalente a digitalizar o índice em vez de todos os documentos da coleção.


Espero que você aprecie esses truques que aprendi enquanto trabalhava no AWS Cost Optimization para minha empresa.


Fique ligado para outro post!

Não hesite em 👏 se gostou deste post ;)

PS: se algo parecer errado ou mal-entendido, não hesite em me enviar um DM.


Também publicado aqui