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   », mais c'est beaucoup moins accrocheur, non ? « comment j'ai optimisé les coûts sur notre infrastructure AWS en respectant certaines directives communes fournies dans la documentation  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 :    : 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.) Le prix de l'instance    : 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. Coûts de stockage et de stockage de sauvegarde    : AWS facturera entre   et   (selon la région de l'instance)  La partie la plus délicate est l'E/S de la base de données 0,20$ 0,30$ 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 ?    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. Les requêtes qui utilisent un index   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.  🧠   : 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. Tout d'abord, rappelez-vous ceci  ❌   : vous ne savez pas combien coûte un index inutilisé pour une collection chargée.   🤌 , en supprimant les index inutilisés. Et il est très facile de suivre les index inutilisés avec cette requête :  Supprimer les index inutilisés J'ai fait économiser 2 000 $/mois à mon entreprise comme ça  Requête de statistiques d'index  La requête affichera les   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é. ops  🧐   : si vous utilisez RDS, vous connaissez peut-être   , 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   , 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   . 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 ! Activez   et  les informations sur les performances les opérations de profilage les informations sur les performances les opérations de profilage n ms  💾   : 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 :) Regardez toujours d'abord vos données  🫠   : 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. Evitez les petites collections délicates  ⏱️   : (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. Évitez les index TTL, alias time-to-leave  💡   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'   avec le paramètre   . Vous serez surpris que certaines requêtes qui, selon vous, atteignent l'index, n'atteignent tout simplement aucun index… Expliquez-vous ! explication executionStats  ☯️   . Ne le faites pas. Rappelez-vous la cardinalité. Ne créez pas d'index pour un champ booléen  ⚖️   pour chaque collection que vous avez avec cette commande :   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. Surveillez la taille moyenne d'un objet db.<mycollection>.stats(1024)  ⚠️   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   , 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 ! Sachez que DocumentDB n'est pas MongoDB. $regex  👉   . À l'exception des cas d'utilisation très spécifiques mentionnés ci-dessus, vous devez éviter l'utilisation de   , 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. Ne faites jamais allusion hint  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

Amazon

Read My Stories

Buy Me a Coffee

Software Engineer/AWS Architect

Cet audio est produit dans la langue originale de l'histoire !

Trop long; Pour lire

Make resilience your competitive advantage

J'ai fait perdre de l'argent à AWS - Voici comment !

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Comment améliorer votre flux de travail par 10 : 17 applications essentielles

Créer des produits cryptographiques centrés sur l'utilisateur : l'importance des retours clients

La fuite de l'invite du système Claude Sonnet 3.5 : une analyse médico-légale

Naviguer sur les eaux : développer des applications RAG de qualité production avec des lacs de données

Comment améliorer votre flux de travail par 10 : 17 applications essentielles

Créer des produits cryptographiques centrés sur l'utilisateur : l'importance des retours clients

La fuite de l'invite du système Claude Sonnet 3.5 : une analyse médico-légale

Naviguer sur les eaux : développer des applications RAG de qualité production avec des lacs de données

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps