Une maison hantée d’horreurs NoSQL

Halloween est cette période effrayante de l’année où le voile entre le monde bien ordonné de DevOps et le sombre vide chthonien de dev/null est le plus mince. C’est alors que les singes du chaos règnent en maître et que les ingénieurs en fiabilité du site verrouillent les portes et verrouillent les volets.

Aujourd’hui, nous allons partager avec vous des histoires d’horreur NoSQL réelles que les ingénieurs de ScyllaDB ont vues et observées dans le monde des systèmes distribués. Mais soyez prévenus ! Ce que vous êtes sur le point de lire peut vous faire frémir au plus profond de vos cœurs très hyperthreadés.

C’était une nuit sombre et orageuse…

Imaginez que vous êtes un utilisateur en production, s’attendant à une évolutivité et à une stabilité de niveau entreprise, des nœuds se plaignant frénétiquement sont « terminés »… et puis vous vous réveillez en sueurs froides en réalisant que vous n’avez provisionné que des instances ponctuelles !!!

Ou qu’un jour, vous avez une colonne booléenne, mais réalisez tardivement lorsque vous créez un index secondaire que vous venez de créer des téraoctets de données divisés en deux énormes partitions !!!

Imaginez que vous ayez l’idée de pousser votre application cliente avec un maximum de parallélisme. Parallélisme illimité ! « Ils m’ont traité de fou ! Mais je vais leur montrer ! Mwah hah hah!” Ce n’est qu’alors que vous découvrez comment le parallélisme illimité crée une spirale de la mort, générant une file d’attente où la latence de la requête finale est égale à sa propre latence plus la somme des latences de toutes les requêtes en retard dans la file d’attente !

Ensuite, il y a eu le temps où la pauvre âme utilisait le même disque pour les données que le lecteur OS/root.

Sauvez-vous tant que vous le pouvez

Malheureusement, il est déjà trop tard pour certains développeurs. Ils se sont plongés dans des situations cauchemardesques dont leur santé mentale ne peut jamais se remettre complètement, même si leurs données l’ont été. Pourtant, il n’est pas trop tard pour vous, cher lecteur, pour réfléchir à la manière d’éviter le même sort.

Ne créez jamais un énorme produit cartésien en concaténant plusieurs conditions IN dans une seule requête. Ce chemin ne mène qu’à la folie !

Méfiez-vous également de cette âme inoffensive de l’informatique qui « veut juste fermer les instances inutilisées », mais finit par tuer vos instances de production ! (Ce était juste un accident, n’est-ce pas ?)

Vous avez toujours voulu avoir ce succès viral. Et vous l’obtenez enfin. Mais alors les utilisateurs… Ils ne s’arrêteront pas ! Ils. Seulement. Garder. À venir! Tous ciblant cette partition chaude.

Alors, « ah-hah! » tu penses. Vous allez simplement reconcevoir votre base de données pour avoir un cache devant elle. Cette fois, vous le jure, les choses seront différentes ! Ensuite, le cache se désynchronise avec la base de données !

Peut-être que la catastrophe frappe. Une panne catastrophique. Mais « Pas de panique ! » vous dites à votre équipe : « Nous gardons religieusement des sauvegardes. » Ils se détendent un peu. Jusqu’à ce que tout le monde se rende compte qu’il n’a jamais eu assez de temps pour tester les sauvegardes ou élaborer des procédures précises sur la façon de restaurer !

Le sentiment lorsque vous découvrez que votre déploiement multi-AZ a en fait été effectué au sein de la même AZ.

N’ouvrez pas cette porte au sous-sol !

Il y a beaucoup plus d’histoires de malheur au fond des tranchées de NoSQL. Voici quelques autres brefs exemples de ce que NE PAS à faire:

• L’EBS n’est pas une panacée. Devinez quoi? Vous avez reçu un e-mail indiquant que votre stockage de bloc a été effacé
• Souhaiter DROP_TABLE n’avait plus de saisie semi-automatique et que vous mettiez le doigt sur un régime ?
• Sélectionner un facteur de réplication plus petit, penser que cela fait un très bon plan d’épargne jusqu’à ce qu’il ne soit pas… DU TOUT !
• Gardez votre base de données sur une instance ponctuelle pour réaliser des économies, jusqu’à ce que vous découvriez qu’elle présente également des inconvénients.
• Nécromancie des données. Parce que la résurrection des données avec un arbre de fusion structuré en journaux est aussi effrayante que la résurrection des morts.
• Utilisation abusive de l’attribut TTL (Time To Live), soit en le définissant sur « 0 » et en ne supprimant jamais aucune donnée (euh-oh – stockage gonflé !) mes données sont-elles parties ??)