Fiz a AWS perder dinheiro - Veja como!

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 ” mas é muito menos cativante, não? “como fiz otimização de custos em nossa infraestrutura AWS respeitando algumas diretrizes comuns fornecidas na documentaçã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: : bem, esse custo é rapidamente compreensível: você paga por uma instância e o preço dependerá de seus recursos (CPU, RAM, etc.) O preço da instância : o mesmo que acima, é bastante compreensível e podemos rastrear e estimar facilmente os custos deles, fatura da AWS por GB armazenado. Legal. Custos de armazenamento e armazenamento de backup : a AWS cobrará entre e (dependendo da região da instância) A parte complicada é o I/O do banco de dados 0,20$ 0,30$ 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? 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. As consultas que usam um índice 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. 🧠 : menos E/S = mais barato = melhor desempenho, aqui não se trata apenas de custos ou desempenho, mas as duas coisas estão ligadas. Em primeiro lugar, lembre-se disso ❌ : você não sabe o quão caro é um índice não utilizado para uma coleção ocupada. 🤌 , excluindo índices não utilizados. E é muito fácil rastrear índices não utilizados com esta consulta: Remova índices não utilizados Fiz minha empresa economizar $ 2.000 / mês assim Consulta de estatísticas de índice A consulta produzirá as 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. ops 🧐 : se você usa o RDS, pode estar ciente dos , 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 , 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 . 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! Ativar e insights de desempenho operações de criação de perfil insights de desempenho Profiling operations n ms 💾 : 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 :) Olhe sempre primeiro para os seus dados 🫠 : 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 coleções pequenas complicadas ⏱️ : (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. Evite TTL, também conhecido como time-to-leave indexes 💡 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 com o parâmetro . Você ficará surpreso ao ver que algumas consultas que você está pensando atingem o índice, mas não atingem nenhum índice... Explique! explicação executionStats ☯️ . Apenas não. Lembre-se da cardinalidade. Não crie um índice para um campo booleano ⚖️ para cada coleção que você possui com este comando: 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. Monitore o tamanho médio de um objeto db. .stats(1024) ⚠️ É 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 , 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! Esteja ciente de que DocumentDB não é MongoDB. $regex 👉 . Exceto pelos casos de uso muito específicos mencionados acima, você deve evitar o uso de , 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. Nunca insinuar hint 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