Como reduzimos em 2/3 nossos custos apenas mudando nossa estratégia de uso do S3
Há dois anos aproximadamente, lançava-mos nossa primeira versão do nosso motor de busca da Maxmilhas usando gRPC ( ficou curioso, fizemos um relato nesse artigo aqui). Com esse buscador, superamos algumas metas, entre elas não tivemos mais problemas com persistência de dados pois optamos usar o AWS S3 como storage, isso fez que superássemos nossos limites em relação a IOPS e disponibilidade. Entretanto, essa decisão de arquitetura nos deixou em média uns 10% mais caros em relação ao modelo anterior que era uma modelagem orientada a documentos, com o adicional de não termos mais restrições em relação a escrita e leitura.
Antes de prosseguir, acho importante entender o porquê decidimos usar o S3.
Quando entrei na Maxmilhas já estávamos esbarrando nos limites de IOPs de nosso banco Mongo do antigo motor de buscas e estávamos em estudos com outras soluções, mas sempre entrávamos em um impasse, podíamos ter elasticidade mas com um custo pouco maior, ou teríamos que gerenciar esse banco de dados mas lidaríamos com os riscos dessa decisão, que envolvia o famoso teorema de CAP, não apenas na perspectiva de custos. Com isso decidimos usar o S3, pois melhor se encaixava em nosso cenário e me garantia a maior disponibilidade em relação a qualquer outro modelo, mas isso tinha um custo.
Depois da decisão tomada, revisamos ela algumas vezes ao longo desses 2 anos, porém esbarrávamos sempre em Storage ou IOPS. E era algo até então insolúvel. Ao menos era até que começamos a estudar onde e como estávamos gastando com S3. E a partir disso, enxergamos que poderíamos economizar 2/3 do nosso custo apenas mudando a estratégia de persistência da aplicação.
Para efeito comparativo, nosso maior custo em S3, estava em Request Tier 1:
Isso queria dizer que, nosso maior custo não era storage como imaginávamos, ou leitura, e sim o como escrevíamos no S3.
Para entender a precificação do S3, resumidamente o quadrante Tier1, refere-se a escrita, Tier2, refere-se a leitura, DataTransfer-In/Out refere-se a custo de transferência pra internet e o TimedStorage-ByteHrs que refere-se a custo GB armazenado por hora. Para mais detalhes dessa classificação, recomendo explorar a documentação.
E essa informação borbulhou na minha cabeça, pois apenas mudando nosso modelo poderíamos gerar uma economia de 2/3, bastaria reduzir nossa escrita de novos arquivos sem mexer no volume de escrita. Ou seja revisando a modelagem que gerava mais de um arquivo, mudamos a modelagem pra usar um arquivo apenas.
Mas a tese de que era possível foi posta em prova, e não fosse o apoio e confiança do time, certamente não teríamos revisitado ou ao menos testado esse cenário que se confirmou. Hoje podemos dizer que não temos mais limites de IOPS e também em termos de eficiência de custos, estamos melhores que a versão anterior da nossa busca.
Lições aprendida:
- Revise sua arquitetura se algo te incomoda, seja por custo ou por performance;
- Tente entender como é precificado os serviços que você usa, isso pode influenciar em algumas decisões técnicas;
- Não desista, as vezes é preciso bater a cabeça algumas vezes até acertar, faz parte do jogo;
