From inevitable overprovisioning to the “on-demand” tax: why DynamoDB is bloody hard to cost-control récemment avec l’objectif spécifique d’aider les clients potentiels de ScyllaDB à comprendre le vrai coût de l’exécution de DynamoDB. Maintenant, si vous faites un pas en arrière et regardez mon objectif, cela n’a pas beaucoup de sens, n’est-ce pas? Calculateur de coûts DynamoDB Naïvement, c’est ce que j’ai pensé au début.Mais alors, j’ai commencé à déchiffrer le fonctionnement interne des calculs de coûts de DynamoDB.À ce moment-là, j’ai réalisé qu’il y a beaucoup de raisons pour lesquelles les équipes finissent par payer des centaines de milliers (si ce n’est des millions) de dollars pour exécuter DynamoDB à l’échelle. La chose principale que j'ai trouvée: DynamoDB est facile à adopter, mais sanglant difficile à contrôler. Mon collègue Guilherme et moi Mais si vous n’avez pas le temps de regarder, continuez à lire pour découvrir les principales découvertes. Un webinaire sur ces lignes Vous avez probablement déjà entendu des termes tels que les unités de capacité de lecture et les unités de capacité d'écriture, et obtenez le verbe de "Vous payez pour ce que vous utilisez" en termes de nombre de lectures et d'écriture. L’écriture de DynamoDB coûte cher... Si vous regardez , vous verrez qu'une unité de demande de lecture (RRU) coûte 0,125 $ par million d'unités, et une unité de demande d'écriture (WRU) coûte 0,625 $ par million d'unités. Donc, l'écriture est 5 fois plus chère que la lecture. Je ne connais pas la raison technique exacte, mais il est certainement quelque chose à voir avec le chemin d'écriture étant plus lourd (durabilité, cohérence, indexation, etc.) et peut-être un peu de tête. 5x semble un peu sur le côté raide pour les bases de données et l'un des premiers pièges d'un point de vue de coût. Vous pouvez facilement vous trouver dépenser un ordre de magnitude plus si votre charge de travail est écriture lourde, en particulier en mode Prix de la capacité à la demande En parlant de quoi... voici l’autre mode: Comme son nom l'indique, cela signifie que vous pouvez spécifier combien vous allez utiliser (même si vous ne l'utilisez pas), et espérons payer un peu moins. Vérifions le ratio cependant. Une unité de capacité de lecture (RCU) coûte $0.00013 par RCU et une unité de capacité d'écriture (WCU) coûte $0.00065, de sorte que l'écriture est étonnamment 5 fois plus chère que la lecture. Ainsi, même en mode provisoire, vous payez toujours une pénalité de 5x sur l'écriture. Ainsi, c'est important, en particulier pour les charges de travail d'écriture de haut volume. Aucune réduction prévue sur l'écriture pour vous! Capacité prévue Vous ne fournissez pas de demandes, vous fournissez des tarifs... Voici le résultat: les unités de capacité fournies sont mesurées par seconde, pas par million de demandes, comme dans le cas de la demande. Cela m'a d'abord frappé.Pourquoi ne pas simplement fournir le nombre total de demandes?Mais du point de vue d'AWS, cela a un sens commercial parfait. N opérations par seconde, que vous utilisiez cette capacité ou non. La capacité à gérer Donc, si votre trafic est éclaté, ou si vous êtes au-dessus de l'approvisionnement pour éviter le déchargement de la demande (plus sur ceci en un peu), vous payez essentiellement pour la capacité inutile. Mettez simplement, vous achetez une capacité soutenue, même si vous n'en avez besoin que de temps en temps. Capacité réservée... Donc, voici l'accord: si vous réservez de la capacité, vous pariez en avance pour espérer économiser un peu plus tard. Si vous êtes sûr de votre utilisation de base, AWS vous donne la possibilité de réserver la capacité DynamoDB, tout comme avec EC2 ou RDS. Il s’agit d’un engagement prépayé de 1 ou 3 ans, où vous verrouillez un taux fixe de lecture et d’écriture par seconde. Un gotcha : il n’y a pas d’option partielle à l’avance ; il s’agit de payer pleinement ou de s’éloigner. Regardons un simple cas d’utilisation pour comparer les modèles de prix... Supposons que votre charge de travail soit en moyenne de 10 000 lectures/sec et 10 000 écritures/sec sur une heure. Prix à la demande : Écrit: $22.50 / h ... 10,000 * 3600 * 0.625 / 1M Lire: $4.50 / h ... 10000 * 3600 * 0.125 / 1M (5x moins cher que d’habitude) Tarifs provisoires (non réservés) : Écrit: $6.50 / h ... 10.000 * $0.00065 Lire: $1.30 / h ... 10 000 * $0.00013 Disponible avec 1 an de réservation : Écriture : ~$2.99 / heure Résultats de recherche : ~$0.59/hr « Où est la mathématique réservée ? » je vous entends. Vous prenez le prix réservé pour 100 WCUs ($0.0128/h) et RCUs ($0.0025/h), diviser par 730 heures dans un mois, diviser par 12 mois dans une année, diviser à nouveau par 100 unités, multiplier par votre taux nécessaire... puis le rouler, pleurer un peu, et coller dans le meme « Math lady ». Mon point est : Provisionné est ~3.4x moins cher que sur demande Réservé est ~7.5x moins cher que sur demande On-demand est pour les gens qui aiment payer trop, ou qui détestent la prévision La TVA, pour : AWS recommande sur demande Des modèles de trafic qui évoluent au fil du temps Charges de travail spiky ou batchy faible utilisation (déclin à zéro ou en dessous de 30% du pic) Ce qui est fondamentalement chaque charge de travail de la vie réelle - au moins pour les clients de ScyllaDB. Alors oui, attendez-vous à payer une prime pour cette flexibilité à moins que votre trafic ne ressemble à une vague de synthèse de manuels et que vous ayez une boule de cristal. Ce n’est pas la taille de l’article, mais c’est... Voici un autre piège. c'est celui que vous ne pouvez pas frapper jusqu'à ce que vous utilisiez de vraies données d'application ... à ce moment-là, vous le regretterez immédiatement. Dans DynamoDB, vous ne payez pas seulement par opération; vous payez par morceau de données transférées. Les Writes sont facturés par 1KB (Write Request Units ou WRUs) Les lectures sont facturées par 4KB (unités de requête de lecture ou RRUs) Donc, si vous écrivez un élément de 1.1KB, c'est 2 WRUs. Écrivez un élément de 3KB? Encore 3 WRUs, chaque 1KB (ou partie de celui-ci) est compté. Les lectures fonctionnent de la même manière, juste à des limites de 4KB. Lire un élément de 1KB? 1 RRU. Lire un élément de 4.1KB? C'est 2 RRUs. N'est-ce pas amusant d'arrondir? Je suis sûr qu'il existe de fortes raisons techniques pour ces limites. Vous pouvez voir le piège ici. Combinez cela avec le coût de 5x d'une écriture par rapport à une lecture, et les choses peuvent devenir désagréables rapidement, surtout si votre taille d'élément dépasse ces seuils sans que vous ne vous en rendiez compte. Il est probablement OK si vous avez une taille d'élément fixe dans votre schéma, mais certainement pas OK avec les types de cas d'utilisation que nous voyons chez ScyllaDB. Par exemple, les clients peuvent avoir niché des champs JSON ou Blob qui peuvent se rétrécir ou croître avec l'utilisation. Et rappelez-vous, c'est la taille réelle de l'élément, pas seulement la taille Exagérer, parce que vous devez... Un autre point douloureux, et une omission déviante de la propre calculatrice d’AWS, est la nécessité de surprovisionner lors de l’utilisation de la capacité provisoire. Cela semble contre-intuitif, mais vous êtes forcé de surprovisionner – non pas parce que vous voulez, mais parce que DynamoDB vous punit si vous ne le faites pas. Si vous glissez au-delà de la capacité prévue, vous J'aime la clarté de ce type de message d'exception. Je n'aime pas ce qu'il fait réellement, cependant: demande de gouttelage. qui conserve la capacité de lecture et d'écriture inutilisée. mais au-delà de cela, votre application échoue. ProvisionsException 300s fenêtre de capacité de brise Ainsi, la meilleure façon de contrer cela est la surprovision. Par combien? Cela garantit une réponse « cela dépend ». Mais cela dépend de votre type de charge de travail. Nous avons ajouté cette fonctionnalité à notre calculateur afin que vous puissiez dynamiquement surprovisionner par un pourcentage, juste pour facturer les coûts supplémentaires à votre charge de travail. Évidemment, ces coûts peuvent s’ajouter rapidement parce que dans la pratique, vous payez pour le pic même si vous opérez dans le trou. Si vous ne fournissez pas une capacité suffisamment élevée, vos sommets risquent d’être écrasés, vous donnant des échecs face au client au pire moment possible. Avant de bouger sur... S'il y a un thème récurrent ici, c'est ceci: le prix de DynamoDB n'est pas intrinsèquement faux. Vous payez pour ce que vous utilisez. Que ce soit : Le multiplicateur de coût d'écriture 5x 7.5x multiplicateur de coût à la demande Taux par seconde provisoire Arrondissement punitif et limites artificielles des tailles d'éléments Ou simplement le besoin de surapprovisionnement pour éviter la plantation du visage pendant la charge de pointe ...Vous devez constamment deviner votre architecture pour rester en avance sur les éclats de coûts. L’ironie? DynamoDB est marqué comme « sans serveur » et « entièrement géré », mais vous finissez par gérer les mathématiques de capacité, les erreurs d’échappement, les niveaux de prix arcane et la gymnastique du débit infini.Après avoir observé de nombreuses prévisions de feuilles de calcul de nos clients (et les exportations d’AWS Cost Explorer) pour DynamoDB, même les équipes matures exécutant des systèmes à grande échelle n’ont aucune idée du coût... jusqu’à ce qu’il soit trop tard. C’est pourquoi nous avons construit une calculatrice qui modèle les charges de travail réelles, pas seulement les moyennes, car la première étape pour fixer les coûts est de comprendre d’où elles viennent. dans , Je parcours quelques exemples du monde réel de clients qui ont changé de DynamoDB à ScyllaDB pour montrer l'impact réel des modèles de trafic, des tailles d'éléments, des caches et des topologies multi-régions. à . Mon prochain blog post Sauter à l'avant et modéliser vos propres charges de travail calculateur.scylladb.com Modèlez vos propres charges de travail DynamoDB sur notre nouveau calculateur de coûts À propos de Tim Koopmans Tim a été impliqué dans toutes les formes d'ingénierie au cours des dernières décennies avec une tendance à la fiabilité et à la sécurité.En 2013, il a fondé Flood IO; une plate-forme de test de performance distribuée.Après son acquisition, il a apprécié l'élargissement du produit, de l'entreprise et de l'équipe avant de passer à d'autres efforts liés à la performance.
