Les signes que votre architecture de base de données doit être améliorée

La plupart des problèmes de base de données ne s’annoncent pas comme « la base est le problème ». Ils apparaissent sous forme de lenteur applicative que l’équipe attribue au framework, de déploiements devenus risqués pour des raisons que personne n’a nommées, de factures d’hébergement mensuelles qui montent plus vite que l’usage, et d’un schéma d’incidents qui finissent tous, quand on regarde vraiment, par remonter à la couche de données. Au moment où quelqu’un dit « attends, est-ce un problème de base ? », l’équipe a souvent passé des semaines à chasser la mauvaise correction.

Cet article est une liste de travail des symptômes qui veulent généralement dire que l’architecture de base de données demande de l’attention, et de ce que chacun signifie en pratique. Il s’associe à l’article sur les erreurs de conception de bases, qui catalogue les choix de conception de schéma à l’origine de la plupart de ces symptômes ; ici, l’angle est diagnostique, écrit pour qu’une équipe puisse reconnaître le pattern dans sa propre production avant que le coût ne s’accumule.

Une page qui se chargeait en 200 ms le trimestre dernier se charge en deux secondes ce trimestre. Rien n’a changé dans le code applicatif ; les données derrière ont grossi. L’équipe ajoute un cache, le symptôme se cache une semaine, le cache rate un mardi et la lenteur revient, cette fois avec un thundering herd.

Ce que cela veut généralement dire : une requête qui était rapide à dix mille lignes ne l’est plus à trois cent mille, parce que l’index dont elle avait besoin n’a jamais existé (ou ne correspond plus à la requête que l’application envoie maintenant). Le premier réflexe est souvent d’ajouter du matériel ou de passer à l’horizontal ; la correction la moins chère est presque toujours de regarder le slow-query log, de trouver l’instruction fautive, et de concevoir le bon index. Si une requête fait un scan complet sur un million de lignes, aucune scalabilité horizontale ne la sauvera.

Un changement de schéma qui devrait être une migration d’une ligne est désormais un projet. L’équipe écrit un feature flag, prépare un script de backfill, planifie une fenêtre de maintenance, et met quelqu’un d’astreinte pour la mise en production. Ajouter une colonne à une table active est le genre de chose que l’équipe évite à moins que ce ne soit absolument nécessaire.

Ce que cela veut généralement dire : la table a atteint une taille où des migrations naïves verrouillent la production trop longtemps, et l’équipe n’a pas encore construit (ou formalisé) la discipline des migrations en ligne. Cela peut aussi signifier un enchevêtrement de schéma : trop de parties de l’application lisent ou écrivent dans les mêmes tables, donc tout changement a un large rayon d’impact. La correction est en partie opérationnelle (outillage de migration en ligne, patterns de backfill, déploiements de colonnes derrière feature flag) et en partie architecturale (frontières de modules plus claires sur la couche de données, moins d’état partagé mutable).

Le modèle de post-mortem a commencé à avoir une section « base de données » qui se remplit plus souvent qu’avant. Épuisement des connexions, contention de verrous, retard de réplication, requêtes lentes qui bloquent les rapides. Des incidents différents en surface, la même famille de cause racine en dessous.

Ce que cela veut généralement dire : la base opère plus près de ses limites que l’équipe ne le réalise. Les connexions ne sont pas correctement poolées, des requêtes longues bloquent les courtes, une charge d’écriture concurrence le trafic de lecture sur la même primaire, ou le working set a grossi au-delà de ce qui tient confortablement en RAM. La correction commence par la mesure (indicateurs de saturation, latence p99 des requêtes, temps d’attente de verrou) et continue avec l’échelle ennuyeuse de scalabilité de base : index, pooling, répliques de lecture, cache à la frontière, les choses traitées dans la couche opérationnelle.

Le tableau de bord exécutif qui montre les chiffres du trimestre passé met quatre-vingt-dix secondes à s’afficher. Le rapport opérationnel que l’équipe utilise tous les lundis est exporté en tableur parce que le requêter en direct est trop lent. Une vue « temps réel » s’avère avoir cinq minutes de retard, puis dix, puis une demi-heure.

Ce que cela veut généralement dire : la charge analytique tourne sur la même base, et contre le même schéma, que la charge opérationnelle, et le schéma n’a pas été conçu pour des requêtes analytiques. Des jointures sur des tables normalisées qui vont bien pour l’accès transactionnel deviennent des agrégations coûteuses pour le reporting, et elles entrent en concurrence pour les ressources avec le trafic face à l’utilisateur. La correction, c’est de séparer le chemin de lecture pour l’analytique : une réplique de lecture, une vue matérialisée, ou un store analytique dédié alimenté par change data capture. Essayer de rendre le schéma opérationnel rapide pour les deux est généralement la manière dont les deux finissent lents.

L’équipe produit veut savoir combien d’utilisateurs ont fait Y dans les 30 derniers jours. La réponse demande deux ingénieurs, trois jours, un script sur mesure et un tableur pour trianguler. Chaque variante de la question demande le même effort. Le tableau de bord qui devait faire remonter ce genre de chose a été dépriorisé parce que « les données ne sont pas structurées pour ça ».

Ce que cela veut généralement dire : les données sont structurées pour les écritures, pas pour les lectures. D’importants changements d’état ne sont pas capturés sous forme d’événements, d’importantes entités ne sont pas modélisées comme des tables de premier plan, d’importants attributs vivent dans des colonnes JSON non typées où l’application les lit mais où l’analyste ne peut pas. La correction passe en partie par faire remonter les événements que le métier veut réellement compter (souvent comme un journal d’événements à côté des tables opérationnelles) et en partie par reconnaître que le modèle analytique est une préoccupation de conception séparée du modèle transactionnel.

La facture d’hébergement de la base a doublé en douze mois. La croissance utilisateur a été de quarante pour cent. L’équipe a la même taille, le périmètre de fonctionnalités est globalement le même, et pourtant la ligne base de données ne cesse de monter.

Ce que cela veut généralement dire : les index ont proliféré sans discipline, les enregistrements soft-supprimés ont gonflé des tables dont aucune requête ne tire bénéfice, les colonnes JSON contiennent des logs qui auraient dû être archivés, et le working set grossit parce que rien n’est archivé. Parfois cela veut dire qu’une stratégie de réplique de lecture manquante force la primaire à faire un travail qu’elle ne devrait pas ; parfois cela veut dire qu’une seule mauvaise requête consomme l’essentiel du coût. La correction commence par l’attribution des coûts (quelles tables, quelles requêtes, quelle charge) avant d’ajouter la moindre capacité.

Les ingénieurs application passent sprint après sprint sur du « travail de performance » dans la couche application (lazy loading, code splitting, optimisation de rendu) pendant que le budget de temps de réponse est mangé par la base en dessous. Personne côté application n’a accès au slow-query log, ni ne sait lire un plan EXPLAIN, et la base est traitée comme une boîte noire que l’équipe plateforme possède et que l’équipe produit utilise.

Ce que cela veut généralement dire : la capacité diagnostique et la propriété de la couche données ne sont pas là où le travail se fait. L’équipe va continuer à travailler sur la mauvaise couche jusqu’à ce que quelqu’un rende la base mesurable pour les personnes qui écrivent les requêtes. La correction est en partie culturelle (alphabétisation base de données dans l’équipe applicative, alertes de requêtes lentes qui réveillent la bonne personne, revues d’EXPLAIN en revue de code) et en partie outillage (monitoring de requêtes que l’ingénieur application peut lire sans introduction).

Une base qui demande de l’attention architecturale envoie rarement un message clair. Elle envoie six messages différents, étouffés, dans différentes parties de l’organisation, que l’équipe doit reconnaître comme connectés. La discipline n’est pas d’attendre un incident assez grave pour que la réponse soit évidente ; c’est de garder ce catalogue en tête, de nommer les symptômes quand ils apparaissent, et de traiter chacun comme un vrai signal plutôt que comme quelque chose à contourner.

Le contexte plus large, dont les décisions de conception de schéma et de scalabilité opérationnelle qui produisent ces symptômes, est rassemblé dans le cluster systèmes de données et performance. Et lorsque la question passe de « voyons-nous l’un de ces symptômes » à « nous reconnaissons le pattern et il nous faut maintenant quelqu’un pour concevoir la stratégie d’index, le chemin de migration ou la séparation du chemin de lecture qui le corrige », c’est exactement ce sur quoi mon accompagnement architecture de base de données et performance est centré.