Il s'agit d'une courte série que je souhaitais partager depuis longtemps sur les bases du « Cost Optimization » sur AWS.

Commençons ce voyage avec DocumentDB !

N'hésitez pas à 👏 si vous avez aimé ce post ;)

Bon, pour être vraiment honnête, ce titre est un clickbait *.*

Je pourrais certainement écrire quelque chose comme « comment j'ai optimisé les coûts sur notre infrastructure AWS en respectant certaines directives communes fournies dans la documentation », mais c'est beaucoup moins accrocheur, non ?

Peut-être que certains d'entre vous connaissent déjà ces astuces et bonnes pratiques.

Si vous recherchez directement la liste de contrôle que je suggère, faites défiler ici.

Comprendre le coût d'E/S extrêmement délicat du service DocumentDB

Si vous regardez leur page de tarification, elle est divisée par 4 dimensions de coûts, je la résume ici :

• Le prix de l'instance : eh bien ce coût est vite compréhensible : vous payez pour une instance, et la tarification dépendra de ses ressources (CPU, RAM, etc.)
• Coûts de stockage et de stockage de sauvegarde : idem que ci-dessus, c'est assez compréhensible, et on peut suivre et estimer facilement les coûts de ceux-ci, facture AWS par Go stocké. Légitime.
• La partie la plus délicate est l'E/S de la base de données : AWS facturera entre 0,20$ et 0,30$ (selon la région de l'instance) pour 1 million d'E/S !!

Alors, qu'y a-t-il derrière les E/S ?

AWS explique qu'avec le service DocumentDB, vous n'avez pas besoin de provisionner les ressources d'E/S à l'avance, ce qui est plutôt intéressant, car vous n'avez pas de limitations de stockage et vous pouvez facilement gérer une sélection d'opérations d'E/S. Cela semble juste, car vous êtes facturé pour l'utilisation.

AWS décrit dans sa documentation ce qui couvre les opérations d'E/S, il s'agit principalement de toutes les opérations telles que la recherche, l'insertion, la mise à jour et la suppression ou certaines fonctionnalités telles que les flux de modification et les index TTL (durée de vie).

Eh bien, tout ce qui touchera le volume de stockage vous sera facturé.

Attendez, quoi, 0,20 $ par million d'E/S ?

Faisons perdre de l'argent à AWS, tout de suite !

Il y a une phrase dans la documentation d'AWS DocumentDB qui va attirer votre attention (et votre porte-monnaie 💸) :

Une fois, une fois que les données ont été lues à partir du volume de stockage et continuent de résider dans la mémoire, les lectures suivantes des mêmes données n'entraînent pas d'E/S supplémentaires.

Cette phrase est essentielle pour comprendre ce qui se cache derrière les E/S.

Quelles opérations utilisent moins d'E/S ?

Les requêtes qui utilisent un index utiliseront probablement moins d'E/S car vous n'analysez pas tout le stockage de votre collection. Cela consommera certainement des E/S, mais bien moins que l'analyse d'une collection entière.

De plus, la RAM de votre instance doit couvrir la taille de votre index, cela vous permettra de ne pas subir d'E/S supplémentaires.

N'oubliez pas que vous devez respecter certains principes d'utilisation de l'index.

Check-list ✅

Voici mes conseils/liste de contrôle lorsque vous souhaitez optimiser votre utilisation des E/S et réduire vos coûts et améliorer les performances.

Vous verrez que je ne suis pas un génie car je ne fais qu'agréger les informations de la page de documentation AWS DocumentDB avec quelques bonnes pratiques courantes qui ne sont pas strictement applicables à DocumentDB.

Il est toujours bon de se rafraîchir l'esprit avec des principes.

• 🧠 Tout d'abord, rappelez-vous ceci : moins d'E/S = moins cher = meilleures performances, ici tout n'est pas une question de coûts ou de performances, mais les deux choses sont liées.

• ❌ Supprimer les index inutilisés : vous ne savez pas combien coûte un index inutilisé pour une collection chargée. J'ai fait économiser 2 000 $/mois à mon entreprise comme ça 🤌 , en supprimant les index inutilisés. Et il est très facile de suivre les index inutilisés avec cette requête :

  
  

Requête de statistiques d'index

La requête affichera les ops sur le terrain qui correspondent au nombre de fois où votre index est atteint. En fonction de la charge de votre application, veuillez envisager de supprimer l'index inutilisé.

• 🧐 Activez les informations sur les performances et les opérations de profilage : si vous utilisez RDS, vous connaissez peut-être les informations sur les performances , cela vous donne des métriques et des informations très utiles sur les requêtes qui affectent vos performances DocumentDB, et vous pouvez voir rapidement les requêtes qui consomment I /Os opérations (et leur quantité), il est donc très bon de suivre facilement un goulot d'étranglement. Une autre façon de surveiller les requêtes lentes ou les requêtes collscan consiste à activer les opérations de profilage , comme son nom l'indique, il s'agit de profiler pour vous certaines opérations (voici un lien pour obtenir plus d'informations : ), vous pouvez définir un seuil qui mettra sur CloudWatch un journal d'un opération qui prend plus de n ms . Très utile pour suivre le nombre de requêtes qui effectuent COLLSCAN par exemple. Veuillez activer ces deux options car elles sont très utiles !

  
  

• 💾 Regardez toujours d'abord vos données : vous devrez identifier le meilleur champ à haute cardinalité que vous souhaitez indexer, si vous n'êtes pas habitué au concept de cardinalité d'index, la documentation d'AWS DocumentDB est bien expliquée :)

  
  

• 🫠 Evitez les petites collections délicates : si vous prévoyez d'avoir une collection qui aura trois champs dont l'un d'entre eux avec une clé unique, et si vous prévoyez de faire beaucoup de mises à jour/insertions, pensez à la modélisation de votre collection, parce que vos opérations d'E/S vont frapper comme l'enfer et donc votre utilisation d'E/S.

  
  

• ⏱️ Évitez les index TTL, alias time-to-leave : (la plupart du temps) vous pouvez le gérer sans définir d'index time-to-leave, veuillez donc vérifier que le paramètre TTL n'est pas activé sur l'instance ou le cluster.

  
  

• 💡 Expliquez-vous ! Un moyen très simple de vérifier la sélectivité des index du planificateur de requêtes lorsque vous effectuez une nouvelle requête (ou non) consiste à effectuer une opération d' explication avec le paramètre executionStats . Vous serez surpris que certaines requêtes qui, selon vous, atteignent l'index, n'atteignent tout simplement aucun index…

  
  

• ☯️ Ne créez pas d'index pour un champ booléen . Ne le faites pas. Rappelez-vous la cardinalité.

  
  

• ⚖️ Surveillez la taille moyenne d'un objet pour chaque collection que vous avez avec cette commande : db.<mycollection>.stats(1024) Une taille moyenne extrême peut créer rapidement un verrou sur vos requêtes et augmenter les opérations d'E/S car la RAM de votre instance ne suffit pas. Veuillez surveiller de près les objets et ne pas stocker de champs inutiles. Si vous avez besoin de stocker de nombreux champs, envisagez d'optimiser les requêtes en ne sélectionnant pas tous les champs.

  
  

• ⚠️ Sachez que DocumentDB n'est pas MongoDB. Il est principalement compatible avec MongoDB mais ce n'est pas MongoDB car il y a des comportements spécifiques merdiques. Par exemple, si vous souhaitez effectuer une requête avec l'opérateur $regex , vous devrez indiquer `hint()` que vous êtes index, car c'est obligatoire. Les opérateurs d'exclusion n'utiliseront jamais d'index, veuillez donc tenir compte de ces comportements lors de la création ou de l'optimisation de vos index !

  
  

• 👉 Ne faites jamais allusion . À l'exception des cas d'utilisation très spécifiques mentionnés ci-dessus, vous devez éviter l'utilisation de hint , gardez à l'esprit que si le planificateur de requêtes n'élit pas votre index, c'est pour une bonne raison. La plupart du temps, c'est parce que c'est plus long ou équivalent à scanner l'index au lieu de tous les documents de la collection.

• 
  

J'espère que vous apprécierez ces astuces que j'ai apprises en travaillant sur l'optimisation des coûts AWS pour mon entreprise.

Restez à l'écoute pour un autre article !

N'hésitez pas à 👏 si vous avez aimé ce post ;)

PS: si quelque chose semble mal ou malentendu, n'hésitez pas à me contacter en DM.

Également publié ici