Gestion de schéma avec Skeema

Remarque : Ce message provient de l'équipe d'ingénierie de SendGrid. Pour plus d'articles d'ingénierie technique comme celui-ci, consultez notre blogroll technique.

La gestion des schémas de base de données va d'un Far West que tout le monde peut "faire en direct" dans le processus de production à un processus de révision en plusieurs étapes et en plusieurs équipes en cascade où un seul individu oint peut toucher la base de données de production.

Au fur et à mesure que les données contenues dans les bases de données relationnelles deviennent plus précieuses pour une entreprise et que la disponibilité de la base de données devient plus importante pour l'entreprise, des barrières aux changements potentiels de rupture de schéma apparaissent.

Au début, les administrateurs de base de données (DBA) sont devenus les gardiens de la base de données afin de protéger la base de données contre les mauvaises choses. Mais avoir un DBA à l'ancienne entre les développeurs et la base de données de leur application peut entraîner un ralentissement significatif du cycle de développement d'une application, créer des silos de développement et d'opérations et générer des frictions entre les équipes.

Dans le monde actuel axé sur le développement de micro-services, les développeurs doivent être capables de gérer eux-mêmes les changements de schéma de base de données, car il s'agit de leurs données et ils sont responsables en dernier ressort des performances et de la disponibilité de l'application. Les administrateurs de base de données et les équipes opérationnelles doivent fournir des outils et des conseils appropriés pour aider les équipes de développement à devenir propriétaires de leur base de données.

Comment nous gérons le schéma

Notre processus de gestion de schéma actuel utilise un référentiel Git unique pour stocker le schéma initial de tous nos clusters de bases de données et contient toutes les modifications ultérieures apportées à ce schéma au fur et à mesure que des modifications/créations et suppressions de tables individuelles sont appliquées :

• Un développeur effectue une modification de schéma localement et génère une instruction alter/create/drop et l'ajoute en tant que demande d'extraction à une branche d'intégration.
• Un ensemble de tickets Jira pour l'équipe des opérations de données est créé pour examiner et appliquer les modifications de schéma à nos environnements de test/préparation et de production.
• Un membre de l'équipe des opérations de données examine la modification demandée et applique la modification à l'environnement de test/de staging et fusionne le PR avec la branche d'intégration.
• Le développeur demandeur teste le changement dans nos environnements de test/de mise en scène et approuve le changement à mettre en production.
• Enfin, Data Operations fusionne la branche d'intégration avec master et applique le changement de schéma à l'environnement de production.

Compte tenu de la valeur des données stockées dans nos bases de données et du désir que ces bases de données fonctionnent bien tout le temps, nous avons opté pour cette séquence byzantine d'événements pour nous protéger de nous-mêmes.

Protéger la base de données est une chose, mais ce processus introduit plusieurs obstacles pour apporter des modifications de schéma de manière fiable et efficace :

• L'examen et la modification du schéma se produisent à une cadence deux fois par semaine et peuvent facilement dérailler car plusieurs équipes travaillent sur différentes bases de données, toutes dans le même référentiel Git et tout le monde dépend d'un membre de l'équipe des opérations de données pour examiner et apporter des modifications à divers environnements.
• Le fait d'avoir un seul référentiel pour tous les schémas de base de données relationnelle peut entraîner des processus de publication difficiles. Une modification apportée à un schéma qui est prêt pour la production ne peut pas passer en production s'il existe d'autres modifications de schéma qui ne sont pas prêtes à être poussées en production mais qui restent en attente de tests supplémentaires.
• L'équipe des opérations de données, qui est une petite équipe, devient un goulot d'étranglement en essayant de gérer quel changement peut et ne peut pas aller en production et quand. Les conflits d'horaires et la disponibilité du personnel peuvent vraiment ralentir la publication de nouvelles fonctionnalités ou de correctifs pour les applications actuelles.
• Nous appliquons manuellement ces modifications aux systèmes de production à l'aide de commentaires dans les demandes d'extraction et les tickets Jira ; Parfois, le copier-coller peut mal tourner.

Entrez Skeema (et quelques aides)

Afin de supprimer ces obstacles au processus, de rendre les changements de schéma moins sujets aux erreurs humaines, de permettre aux développeurs de gérer le schéma de leur propre application et d'augmenter potentiellement la vitesse de développement, l'équipe des opérations de données a déployé beaucoup d'efforts pour automatiser et rationaliser la gestion des schéma de la base de données.

Nous avons automatisé l'application des changements de schéma du développement local à la production en utilisant nos outils existants, Git, Buildkite CI et pt-online-schema-change, avec l'ajout d'un autre, Skeema.

L'idée est de diviser notre référentiel de schémas de base de données monolithique en référentiels de schémas individuels, un par cluster de base de données, et de permettre aux développeurs d'apporter leurs propres modifications de schéma dans un environnement qui leur est familier. Nous souhaitons également mettre en place des garde-corps sains pour aider les développeurs à rechercher une assistance supplémentaire pour apporter des modifications de schéma importantes, complexes ou potentiellement destructrices.

Skeema est un outil CLI qui gère le schéma MySQL de manière déclarative à l'aide de SQL.

Il peut générer le langage de définition de données (DDL) pour chaque table d'une base de données et exporter le DDL vers un système de fichiers local pour l'intégration avec un référentiel de suivi via Git. Skeema peut comparer les fichiers SQL d'un référentiel Git à une base de données MySQL en direct et afficher ces différences sous forme d'instructions DDL.

Il peut également être configuré pour utiliser l'outil pt-online-schema-change de Percona et formater la commande pt-online-schema-change nécessaire pour faire correspondre le schéma de la base de données MySQL en cours d'exécution au schéma défini dans le référentiel Git.

Skeema est également capable de gérer le schéma dans plusieurs environnements, tels que local, test et production avec différentes configurations dans chacun. Et enfin, il peut facilement être adapté à un flux de travail basé sur des demandes d'extraction.

La création de référentiels de schémas de base de données MySQL individuels décomposera notre référentiel Git db-schema monolithique actuel et permettra aux développeurs d'équipes distinctes de gérer le schéma MySQL de leur application dans leur propre référentiel au lieu d'un référentiel partagé (db-schema).

Avoir un référentiel séparé pour chaque schéma de base de données permettra une plus grande autonomie à l'équipe de développement d'applications. Cela élimine le besoin de coordonner toutes les modifications de schéma selon un calendrier rigide et permet de déplacer les modifications vers la production selon les souhaits de l'équipe d'application.

Un composant essentiel de l'automatisation de ce processus est le pipeline CI de Buildkite. Nous avons créé un pipeline qui :

• Vérifie les erreurs de syntaxe SQL
• Crée un serveur MySQL de test en utilisant la branche principale actuelle du schéma de la base de données et teste l'application des modifications dans la demande d'extraction (PR)
• Vérifiez les différences et appliquez les changements PR à notre environnement de test MySQL
• Vérifiez les différences et appliquez les modifications PR à notre environnement de staging et générez des statistiques de table à partir de l'environnement de production

Les statistiques de sortie de production sont la taille de la table sur le disque et le nombre de lignes estimé. Ces statistiques peuvent aider à déterminer si la modification du schéma peut entraîner un certain niveau d'interruption de service et peut nécessiter un traitement spécial. Une fois le PR fusionné avec le master, le pipeline buildkite vérifie les différences entre la branche master et ce qui s'exécute en production.

Si les différences correspondent aux modifications attendues du PR, le développeur peut débloquer cette dernière étape et Skeema applique les modifications au cluster de base de données MySQL de production. Chacune de ces étapes est une étape bloquante qui nécessite l'approbation de l'équipe d'ingénierie responsable de la modification demandée avant de passer à l'étape suivante.

En ce qui concerne les barrières de sécurité, nous avons configuré Skeema pour qu'il n'autorise pas les changements de schéma destructeurs en production par défaut.

Les modifications destructives sont autorisées dans nos environnements de test et de mise en scène.

Nous avons également configuré Skeema pour utiliser pt-online-schema-change pour effectuer des modifications de schéma. Il s'agit du même outil de changement de schéma que l'équipe DataOps connaît et qu'il utilise chez SendGrid depuis de nombreuses années. Nous avons développé un ensemble d'options raisonnables pour que pt-online-schema-change annule ses modifications si la réplication prend du retard ou si les threads actifs dans la base de données deviennent excessifs.

Avoir Skeema configuré de cette manière supprime les erreurs potentielles d'avoir des étapes manuelles pour l'application et le codage manuel des commandes pt-online-schema-change par les membres de l'équipe DataOps.

Avec l'ajout de garde-corps programmatiques, les équipes individuelles peuvent être responsables de la gestion de leurs schémas de base de données MySQL et de l'application de ces modifications aux environnements de pré-production et de production avec une sécurité relative. Si les barrières de sécurité sont atteintes, la modification du schéma échouera et sera annulée. Les raisons de l'échec de la modification du schéma sont affichées dans les journaux de génération pour un examen supplémentaire.

Permettre aux développeurs de piloter leurs modifications du test local sur un ordinateur portable à la production améliore considérablement l'autonomie des développeurs et la propriété de la base de données qui prend en charge leur application. L'automatisation et l'intégration de Skeema dans notre processus de gestion de base de données MySQL couvrent facilement environ quatre-vingt-dix pour cent de nos tâches générales de gestion des changements de schéma.

La plupart des modifications de schéma concernent l'ajout de colonnes, la modification des champs d'énumération, la modification des valeurs par défaut et l'ajout d'index. Les dix pour cent restants des modifications de schéma concernent des cas particuliers de tables volumineuses, de bases de données très actives ou de tables partitionnées. À ce jour, Skeema ne s'occupe pas encore d'apporter des modifications de schéma aux tables partitionnées, mais j'entends que c'est un ajout souvent demandé et le développeur de Skeema demande activement de l'aide pour implémenter cette fonctionnalité.

La combinaison de Git, de pt-online-schema-change, de Skeema et d'un pipeline CI Buildkite apporte un processus de programmation fiable, reproductible aux changements de schéma de base de données MySQL. Il permet aux développeurs de gérer en toute sécurité le schéma de leurs bases de données et de contrôler la rapidité avec laquelle les fonctionnalités et les correctifs sont déployés en production.

L'inclusion de garde-fous appropriés dans les fichiers de configuration pour Skeema et pt-online-schema change, fournit une mesure de confiance pour les développeurs mettant en œuvre des changements de schéma et donne des informations précieuses sur les façons possibles de procéder au changement de schéma si ces garde-fous sont touchés.

L'équipe des opérations de données reste disponible pour aider les dix pour cent de cas restants auxquels ce processus ne peut pas être appliqué et travaillera sur des outils supplémentaires pour améliorer ce processus à l'avenir.