Voici un extrait du chapitre 1 de Performance de la base de données à l'échelle (un livre Open Access disponible gratuitement). Suivez les aventures hautement fictives de Joan avec quelques défis de performance de base de données trop réels. Vous rirez. Vous pleurerez. Vous vous demanderez comment nous avons transformé cette « histoire cheesy » en un livre profondément technique. Performance de la base de données à l'échelle Attirée par des mots-clés impressionnants tels que « cloud hybride », « sans serveur » et « avant tout », Joan a rapidement rejoint une nouvelle entreprise et a commencé à saisir leur pile de technologie. Son premier projet a récemment commencé une transition de leur mise en œuvre interne d’un système de base de données, qui s’est avéré ne pas évoluer au même rythme que le nombre de clients, à l’une des solutions de gestion de base de données standard de l’industrie. les garanties connues dans le monde SQL. acide En raison de quelques nouvelles lois sur la protection des données qui ont tendance à apparaître chaque année aujourd'hui, le conseil d'administration de la société a décidé qu'ils allaient maintenir leur propre centre de données, au lieu d'utiliser l'un des fournisseurs de cloud populaires pour stocker des informations sensibles. À un niveau très élevé, le produit principal de l’entreprise n’était composé que de deux couches : Le frontend, le point d’entrée pour les utilisateurs, qui fonctionne réellement dans leurs propres navigateurs et communique avec le reste du système pour échanger et persister des informations. Le tout-else, communément connu sous le nom de « backend », mais comprend en fait les équilibreurs de charge, l’authentification, l’autorisation, les couches de cache multiples, les bases de données, les sauvegardes, etc. La première tâche introductive de Joan était de mettre en œuvre un service très simple pour recueillir et résumer diverses statistiques de la base de données, et d’intégrer ce service avec l’ensemble de l’écosystème, de sorte qu’il collecte des données de la base de données en temps réel et permet aux équipes DevOps d’inspecter les statistiques en direct. Pour impressionner la direction et les rassurer que l'embauche de Joan a été leur meilleure décision ce trimestre, Joan a décidé de livrer une mise en œuvre de preuve de concept le premier jour!La politique inexprimée de l'entreprise était d'écrire du logiciel dans Rust, alors elle a saisi le premier pilote pour leur base de données à partir d'une brève recherche crates.io et s'est assise à son hackathon auto-organisé. La journée s'est déroulée très bien, avec l'écosystème axé sur l'ergonomie de Rust offrant une expérience de développement supérieure. Mais ensuite Joan a effectué ses premiers tests de fumée sur un système réel. L'incrédulité s'est transformée en déception et en impuissance quand elle a réalisé que chaque troisième demande (en moyenne) s'est terminée par une erreur, même si l'ensemble du groupe de bases de données a déclaré être dans un état sain et opérationnel. Malheureusement, le chauffeur Joan a choisi avec hâte pour la base de son travail, bien que l'open-source en lui-même, n'était qu'un mince enveloppe sur précompilé, code C hérité, sans source à trouver. Il a fait une devinette éduquée que le Dans la base de données utilisée par l'entreprise, les clés sont hachées aux demandes de route ultérieures vers les nœuds appropriés.Si une valeur hachée est calculée de manière incorrecte, une demande peut être redirigée vers le mauvais nœud qui peut la refuser et renvoyer une erreur à la place. par Wireshark Le bug doit être dans la mise en œuvre de la clé de hash Incapable de vérifier la réclamation en raison du manque de code source, Joan a décidé d’aller sur une voie plus simple – abandonner le pilote initialement choisi et réimplémenter la solution sur l’un des pilotes open-source officiellement pris en charge par le fournisseur de la base de données, avec une base d’utilisateurs solide et un calendrier de sortie régulièrement mis à jour. Le journal de Joan des leçons apprises, partie I Les leçons initiales comprennent : Choisissez un pilote avec soin.Il est au cœur de la performance, de la robustesse et de la fiabilité de votre code. Les conducteurs ont aussi des bugs, et il est impossible de les éviter. À moins qu'il n'y ait une bonne raison, préférez le conducteur officiellement pris en charge (le cas échéant); Les pilotes open source ont des avantages : ils ne sont pas seulement vérifiés par la communauté, mais permettent également une inspection approfondie de son code, et même la modification du code des pilotes pour obtenir encore plus d’informations pour le débogage. Il est préférable de faire confiance aux pilotes avec un calendrier de sortie bien établi car ils sont plus susceptibles de recevoir des correctifs de bugs (y compris pour les vulnérabilités de sécurité) dans un délai raisonnable. Wireshark est un excellent outil open-source pour l'interprétation de paquets réseau; essayez-le si vous voulez regarder sous le capot de votre programme. La tâche d'introduction a finalement été terminée avec succès, ce qui a préparé Joan à recevoir sa première tâche réelle. Le Tuning Armé de l'expérience acquise en travaillant sur la tâche d'introduction, Joan a commencé à planifier comment s'approcher de sa nouvelle tâche: une application mal comportementale.L'une des applications a notoriquement causé des problèmes de stabilité pour l'ensemble du système, perturbant d'autres charges de travail chaque fois qu'elle a rencontré des problèmes. Ce service particulier était responsable de l'injection de données sauvegardées du système hérité dans la nouvelle base de données. Parce que l'entreprise n'était pas dans une grande hâte, l'application a été écrite avec une faible concurrence à l'esprit pour avoir une faible priorité et ne pas interférer avec les charges de travail des utilisateurs. Malheureusement, une fois tous les jours quelque chose a continué à déclencher une anomalie. L'application normalement pacifique semblait essayer d'effectuer une attaque de déni de service sur sa propre base de données, l'inondant de demandes jusqu'à ce que le backend soit suffisamment surchargé pour causer des problèmes pour d'autres parties de l'écosystème. Alors que Joan regardait les mesures présentées dans un tableau de bord Grafana, suggérant clairement que le taux de requêtes générées par cette application a commencé à augmenter autour du moment de l'anomalie, elle s'est demandée comment sur Terre cette charge de travail pouvait se comporter de la sorte. Étant donné que la collaboration a été fortement promue comme l’une des « fondations de l’esprit et de la culture » de l’entreprise lors des sessions d’embarquement avec un entraîneur sur place, elle a décidé qu’il était préférable de discuter de la question avec son collègue, Tony. « Regardez, Tony, je ne peux pas envelopper ma tête autour de cela », a-t-elle expliqué. « Ce service n’envoie pas de nouvelles demandes quand 100 d’entre elles sont déjà en vol. Et regardez ici dans les journaux : 100 demandes en cours, l’une a renvoyé une erreur de délai, et... » elle s’est arrêtée, étonnée à sa propre épiphanie. « Ok, merci Tony, tu es un cher – le meilleur jamais ! », a-t-elle conclu et est retournée pour réparer le code. Patois de caoutchouc L’observation qui a conduit à la découverte de la cause principale était assez simple : la demande n’a pas réellement *retourné* une erreur de délai parce que le serveur de base de données n’a jamais renvoyé une telle réponse. La demande a simplement été qualifiée comme déterminée par le conducteur, et rejetée. Mais le seul fait que le conducteur n’attend plus une réponse à une demande particulière ne signifie pas que la base de données est terminée le traitement! Avec cette connaissance, il est facile d’imaginer qu’une fois que 100 demandes sont épuisées du côté client, l’application pourrait penser à tort qu’elles ne sont plus en cours et soumettre heureusement 100 demandes supplémentaires à la base de données, augmentant le nombre total de demandes en vol (c’est-à-dire concurrentes) à 200. Le journal de Joan des leçons apprises, partie 2 Les leçons continuent : Les délais du côté client sont pratiques pour les programmeurs, mais ils peuvent mal interagir avec les délais du côté serveur. Règle du pouce: faites les délais du côté client environ deux fois plus longtemps que ceux du côté serveur, sauf si vous avez une raison extrêmement bonne de le faire. Certains pilotes peuvent être en mesure d'émettre un avertissement s'ils détectent que le délai du côté client est plus petit que celui du côté serveur, ou même de modifier le délai du côté serveur pour correspondre, mais en général, il est préférable de vérifier deux fois. L'inspection des journaux et des tableaux de bord est utile pour enquêter sur de tels cas, alors assurez-vous que les outils d'observation sont disponibles à la fois dans le cluster de base de données et pour toutes les applications client. points bonus pour le suivi distribué, comme l'intégration OpenTelemetry. Avec les délais du côté client correctement modifiés, l'application s'étouffait beaucoup moins fréquemment et dans une moindre mesure, mais elle n'était toujours pas un citoyen parfait dans le système distribué. Il a occasionnellement choisi un nœud de base de données de victimes et a continué à le déranger avec trop de demandes, tout en ignorant le fait que sept autres nœuds étaient considérablement moins chargés et pouvaient également aider à gérer la charge de travail. À d'autres moments, sa concurrence a été rapportée à être exactement 200% plus grande que prévu par la configuration. Chaque fois que les deux anomalies convergaient dans le temps, le mauvais nœud était incapable de gérer toutes les demandes qu'il était bombardé avec, et a dû abandonner formaté et tenu raisonnablement à jour, a aidé Joan à soulager ces douleurs aussi. Le mdbook Le premier problème était simplement une mauvaise configuration de la politique d'équilibrage de charge non par défaut, qui a trop essayé de sélectionner le nœud de base de données «le moins chargé» parmi tous les nœuds disponibles, basé sur des heuristiques et des statistiques occasionnellement mises à jour par la base de données elle-même. Malheureusement, cette politique était également « le meilleur effort » et s’appuyait sur le fait que les statistiques provenant de la base de données étaient toujours légitimes – mais un nœud de base stressé pouvait devenir si surchargé qu’il n’envoyait pas de statistiques mises à jour à temps! Cela a conduit le pilote à croire faussement que ce serveur particulier n’était pas vraiment occupé du tout. Joan a décidé que cette configuration était une optimisation prématurée qui s’est avérée être un pistolet, alors elle a juste restauré la politique par défaut originale, qui a fonctionné comme prévu. Le deuxième problème (doublement temporaire de la concurrence) a été causé par une autre erreur de configuration: une politique de réinitialisation spéculative excessive. Après avoir attendu une période de temps préconfigurée sans recevoir une reconnaissance de la base de données, les pilotes réinitialiseraient spéculativement une demande pour maximiser ses chances de succès. Ce mécanisme est très utile pour augmenter le taux de réussite des demandes. Cependant, si la demande initiale réussit également, cela signifie que la demande spéculative a été envoyée en vain. Afin d'équilibrer les avantages et les inconvénients, la réinitialisation spéculative devrait être configurée pour ne pas réinitialiser les demandes si elle est très probable que la demande initiale a échoué. Autrement, comme dans le cas de Joan, Whew, rien ne donne une hâte à l'endorphine et à la dopamine simultanées comme une séance de débogage de qualité qui se termine par un succès étonnant (à l'exception de l'écriture d'une histoire cheesy dans un livre profondément technique, bien sûr). La fin . Si vous l'avez fait jusqu'ici et que vous ne pouvez pas obtenir assez d'histoires de performance de base de données, regardez ce qui est arrivé au pauvre vieux Patrick dans " « Et si vous appréciez ce sens de l’humour, voyez Piotr. . Editor’s note: Une histoire de performances de base de données : les Fedoras verts malheureux de Patrick Nouveau livre sur l'écriture de blogs d'ingénierie
