Planification de capacité pour les bases de données

Remarque : ce billet est inspiré du récent billet de Julia Evans sur la planification des capacités.

SGBDR

Tout d'abord, établissons quelques règles de base. Oui… cet article est destiné à ceux d'entre nous qui utilisent MySQL avec un seul écrivain à la fois et 2 répliques en lecture ou plus. Une grande partie de ce dont je vais parler ici s'applique différemment, voire pas du tout, aux banques de données en cluster multi-écrivains, bien que celles-ci comportent également leur propre ensemble de compromis et de mises en garde. Alors… votre kilométrage variera certainement.

Cependant, cet article de blog S'APPLIQUERA, que vous utilisiez des hôtes physiques auto-hébergés ou que vous soyez dans AWS où vous pouvez utiliser des instances réservées de type magique et un provisionnement quasi instantané. Être dans « le cloud » ne vous empêchera pas de connaître les capacités et les limites de votre infrastructure et ne vous dispensera pas de cette responsabilité envers votre équipe et vos clients.

Partage

J'en ai déjà couvert de grands traits dans l'un de mes articles précédents, je me suis principalement concentré là-bas sur les avantages du partage fonctionnel ou horizontal. Oui, c'est une condition préalable absolue, car ce que vous utilisez pour accéder à la couche de base de données décidera de la flexibilité dont vous disposez pour évoluer.

Si vous êtes une toute nouvelle entreprise, vous n'aurez peut-être pas besoin de partitionnement fonctionnel le premier jour, mais si vous espérez (et je suppose que vous le faites) grandir, ne vous enfermez pas dans un ORM open source qui ne vous permettra pas de vous diviser. vos données sur une base fonctionnelle sur toute la ligne. Des points bonus si vous ne démarrez pas non plus votre entreprise avec toutes vos données relationnelles dans un seul schéma.

Possibilité de diviser les lectures et les écritures

C'est quelque chose que vous devrez être capable de faire, mais pas nécessairement appliquer comme une règle de pierre. Il y aura des cas d'utilisation où une écriture doit être lue très peu de temps après et où la tolérance pour des choses comme le décalage/la cohérence éventuelle est faible. C'est acceptable, mais dans les mêmes applications, vous aurez également des scénarios de lectures qui peuvent tolérer une période plus longue de cohérence éventuelle. Lorsque de telles lectures sont en volume, voulez-vous vraiment que ce volume revienne à votre seul auteur s'il n'est pas vraiment nécessaire ? Rendez-vous service et assurez-vous que vous pourrez contrôler l'utilisation d'une adresse IP en lecture ou en écriture dans votre code.

Passons maintenant au processus de réflexion sur la planification de la capacité réelle… Un cluster de bases de données ne suit pas, que dois-je faire ?

Déterminer le goulot d'étranglement du système

• Êtes-vous bloqué sur les écritures ou les lectures ?
• Le problème présente-t-il un CPU élevé?
• Présente-t-il une capacité d'E/S ?
• Est-ce un retard croissant sur les répliques sans coupable de requête de lecture claire ?
• C'est des serrures ?
• Comment puis-je même savoir de quoi il s'agit?

Chacun d'entre eux peut être un poste en soi. Le point que j'essaie de faire valoir est que vous devez être familiarisé avec votre système et les métriques spécifiques à la base de données pour pouvoir déterminer quel élément est le goulot d'étranglement.

Vous avez besoin d'une ligne de base

Assurez-vous toujours que vous disposez de métriques système de base disponibles pour visualiser au moins quelques semaines en arrière. De nombreux outils le permettent (Cacti, Munin, Graphite…etc). Une fois que vous savez à quelle métrique système vous êtes principalement lié, vous devez établir des valeurs de référence et de crête. Sinon, déterminer si votre problème actuel est un bogue provenant d'une nouvelle application par rapport à une croissance réelle sera beaucoup plus sujet aux erreurs que vous ne le souhaiteriez.

Cependant, les métriques de base du serveur ne peuvent pas aller aussi loin - à un moment donné, vous constaterez que vous avez également besoin de métriques contextuelles. Les performances des requêtes et les performances perçues côté application vous indiqueront ce que l'application considère comme un temps de réponse aux requêtes. Il existe de nombreux outils pour faire ce suivi lourd de contexte. Certains sont open source comme Anemometer et des outils commerciaux comme Vivid Cortex (nous les utilisons chez SendGrid. Voyez-nous en parler ici.) Même le simple fait de suivre ces métriques du point de vue de l'application et de les lancer en tant que métriques statsd sera une bonne première étape. Mais, dès le début, vous devez vous habituer au fait que ce que votre application perçoit est ce que vos clients perçoivent. Et vous devez d'abord trouver un moyen de savoir.

Découvrez les modèles de trafic de votre entreprise

Êtes-vous une entreprise susceptible de connaître des pics extrêmes certains jours de la semaine (par exemple, marketing) ? Avez-vous des lancements réguliers qui triplent ou quadruplent votre trafic comme les jeux ? Ce genre de questions déterminera la marge de manœuvre réservée que vous devez conserver ou si vous devez investir dans une croissance élastique.

Déterminer le ratio des chiffres bruts de trafic par rapport à la capacité utilisée

C'est simplement la réponse à "Si nous n'avons fait aucune optimisation de code, combien d'e-mails/ventes/utilisateurs en ligne/peu importe" pouvons-nous servir avec les instances de base de données que nous avons actuellement ?

Idéalement, il s'agit d'une valeur spécifique qui fait des calculs pour planifier la croissance d'une année une simple équation mathématique. Mais la vie n'est jamais idéale et cette valeur variera en fonction de la saison ou de facteurs heureux complètement externes comme l'inscription d'un nouveau client majeur. Dans les premières startups, ce nombre est une cible qui évolue plus rapidement, mais il devrait se stabiliser à mesure que l'entreprise passe des premiers jours à une entreprise plus établie avec des modèles de croissance commerciale plus prévisibles.

Dois-je vraiment acheter plus de machines ?

Vous devez trouver un moyen de déterminer s'il s'agit vraiment de capacité - je dois diviser les écritures pour prendre en charge une charge d'écriture plus simultanée ou ajouter plus de répliques en lecture - vs. goulot d'étranglement des performances basé sur le code (cette nouvelle requête d'un déploiement récent peut vraiment avoir ses résultats mis en cache dans quelque chose de moins cher et ne pas battre autant la base de données).

Comment tu fais ça? Vous devez vous familiariser avec vos requêtes. La petite étape pour cela est une combinaison d'innotop, de slow log et de pt-query-digest de Percona Toolkit. Vous pouvez automatiser cela en envoyant les journaux de base de données vers un emplacement central et en automatisant la partie résumé.

Mais ce n'est pas non plus tout, les journaux lents consomment beaucoup de performances si vous abaissez trop leur seuil. Si vous pouvez vivre avec un échantillonnage moins sélectif, vous devrez détecter l'intégralité des conversations entre l'application et le magasin de données. Dans les pays open source, vous pouvez aller aussi basique que tcpdump ou vous pouvez utiliser des produits hébergés comme Datadog, New Relic ou VividCortex.

Passer un coup de téléphone

La planification de la capacité peut être à 90 % scientifique et à 10 % artistique, mais ces 10 % ne doivent pas signifier que nous ne devons pas nous efforcer d'obtenir autant d'image que possible. En tant qu'ingénieurs, nous pouvons parfois nous concentrer sur les 10 % manquants et ne pas réaliser que si nous faisions le travail, ces 90 % peuvent nous permettre d'avoir une meilleure idée de la santé de notre pile, une utilisation plus efficace de notre temps en optimisant les performances et la capacité de planification. augmente prudemment, ce qui aboutit finalement à un bien meilleur retour sur investissement pour nos produits.