Réduire les coûts d'AWS / DocumentDB / MongoDB / Lambda

Cet article est le premier d'une série d'articles consacrées à l'optimisation de vos coûts de serveurs. Ce premier article s'adresse aux développeurs mais aussi au non-développeurs pouvant travailler dans le milieu de la tech, comme des CEO ou CFO cherchant à comprendre pourquoi ils paient si cher leurs serveurs.

Pour visualiser plus simplement les implications qu'entraine une mauvaise architecture, ou des mauvaises requetes dans votre code, je vais commencer par une métaphore et si vous êtes sur cet article c'est parce que vous êtes peut-être dans cette situation.

La métaphore de la bibliothécaire:

• La bibliothécaire c'est votre serveur

• Vos requêtes c'est ce que vous demandez à la bibliothécaire

• Et la bibliothèque votre base de données évidemment

Ce que vous faite peut-être, métaphoriquement:

• Vous demandez à la bibliothécaire de chercher un livre parmi 10 millions ce qui prend forcément plus de temps (malgré le meilleur classement du monde) que de chercher parmi 1 millions (DATA INUTILE et/ou MAL COLLECTIONNÉE/INDEXÉE)

• En plus vous lui demandez des livres pour au final ne même pas les lire (REQUETE INUTILE)

• Après vous lui redemandez un livre que vous avez demandez déjà avant, donc normalement elle devrait le retrouver plus facilement vu que vous lui avez déjà demandé (LE CACHE) mais vous demandez tellement mille trucs que cette mémoire ne peut pas marcher

• Elle est encore en train de chercher ce que vous lui avez demandé avant que vous lui redemandez entre chose (SATURATION DU CPU) du coup elle sature donc elle travaille moins bien

• Et (là j'ai pas la métaphore exacte) mais plus elle a des livres en attentes d'être recherchés et plus vous payez aussi (FONCTIONS LAMBDA QUI DURENT)

• Et certainement que pour combler, à un moment vous avez cru avoir besoin de 3 bibliothécaires! Mais vous les mettez tous en burn-out quand même!

Et tout ça crée un effet domino (pas exponentiel mais quand même), qui peut faire que 30% de requêtes inutiles finissent par mutiplier en fait votre facture par 2, 3 ou 5. Oui oui.

Cet article à vraiment pour but de dégrossir globalement le sujet, de vous donner de quoi réfléchir, chaque cas est différents et les solutions peuvent être multiples et feront l'objet de différents articles pour chaque spécifique sujet.

Le problème principal que vous allez rencontrer est que vous avez déjà une structure en place, qui est maintenant complexe, qui fait tourner tout votre système et la transition vers un tout niveau système ultra-optimisé semble impossible puisque vous ne pouvez pas prendre le risque de tout changer et parfois il est compliqué d'estimer si le temps humain que vous aller prendre est plus rentable que tout simplement payer chers vos serveurs.

Mais si vous êtes sur cet article vous êtes peut-être encore qu'au début de votre croissance et c'est pour ça que vous commencez à vous rendre compte d'un problème et quand le mois prochain vous ferez encore 10-20% de croissance alors avec l'effet domino votre facture va augmenter elle peut-être augmenter de 15-30%.

On va d'abord commencer par un premier listing, un premier check-up à faire, de choses simple à verifier et pouvant être fait sans risque sur votre logiciel en production, des choses vraiment banales mais qui arrivent quand même très souvent, parce que lorsqu'on monte un projet, son MVP, on va vite et on ne pense pas optimisation dès la base (ce qui est normal) mais vous tirez peut-être une balle dans le pied de votre marge qui va continuer de vous suivre tant que vous vous en occupez pas. Et si vous faites 30% de croissance de votre chiffre d'affaire mais que votre marge diminue au fur et à mesure alors what's the point?

Le deuxième listing mènera vers plusieurs sujets d'optimisations plus poussées et il sera ensuite le fruit de votre reflexion de savoir à quel moment et comment les mettre en place.

La base:

1. Si vous avez vraiment une facture qui semble totalement décoléré de ce qu'elle devrait être il faut déjà passer TOUT votre code en revu. Faites-vous des requêtes qui retournent beaucoup trop de données alors que vous n'en avez pas besoins?

2. Avez-vous stocké avec le temps des données qui n'ont plus aucune utilité aujourd'hui? Vous pouvez peut-être en supprimer une grande partie et vous avez vos back-ups si un jour le besoin de ressortir ces data reviennent

3. Vos instances font-elle la bonne taille? Si votre instance est trop petite elle peut vous sembler couter moins cher en frais fixe mais tout le reste est décuplé.

4. Vos instances sont-elle h24 utiles et 7j/7 ? Vous avez peut-être un logiciel utilisé seulement beaucoup en semaine ou seulement en journée, ce n'est pas du tout une technique de "crevard" de les couper, c'est la base! Pour rappel sur 365 jours dans l'année il y en a 100 c'est le week-end!

5. Avez-vous créé des index? En avez-vous créé trop? Pas assez? Il n'y a pas de réponse facile sans connaitre votre structure et vos besoins mais il faut bien comprendre que rien n'est gratuit, quand vous créez un index vous copiez votre base de données donc vous allez chercher plus vite ça c'est sur mais lorsque vous écrivez alors vous écrivez plusieurs fois dans chaque index

Besoin d'aide pour réduire vos coûts AWS?