Databases et SLA
Lorsque l'on parle de SLA, il faut réfléchir à ce que cela signifie pour vous. Il est facile de déployer plusieurs instances d'une application et de mettre en place un load-balancer. Mais que se passe-t-il lorsque celui-ci est en panne ?
Au niveau de l'application, nous avons des tonnes de solutions pour augmenter la disponibilité. Mais votre SLA n'est égal qu'à la disponibilité de la partie la plus faible de votre architecture. Trop souvent, c'est la base de données !
HA et Tolérance aux pannes
Il convient tout d'abord de clarifier les différences entre la haute disponibilité et la tolérance aux pannes.
Les systèmes à haute disponibilité sont conçus pour garantir une reprise rapide en cas de problème.
La tolérance aux pannes, quant à elle, est conçue pour que vous n'ayez pas besoin de récupérer. Le système assure la continuité du service quoi qu'il arrive.
Donc, tout système tolérant aux pannes est hautement disponible, mais l'inverse n'est pas vrai!
SLA en temps compréhensible
Comme vous pouvez le voir ici, si votre base de données nécessite un temps d'arrêt d'une heure par mois pour la maintenance, vous ne pouvez pas prétendre être disponible à 99,9 %. 1 heure par mois équivaut à 12 heures par an. Dans cet exemple, il s'agit d'un temps d'arrêt planifié, auquel il faut donc ajouter tout problème survenant au cours de l'année.
Si nous revenons à la définition de la Haute Disponibilité, vous pouvez facilement comprendre qu'avec tout système utilisant une instance primaire répliquée sur une ou plusieurs répliques, il est difficile d'obtenir une SLA vraiment élevée. La gestion du basculement et du retour à la normale nécessitera souvent des opérations manuelles qui vont vite allonger le temps de retour à la normale.
Vous pouvez trouver de nombreux outils capables de gérer les bascules en cas de problème. Mais il s'agit toujours d'un outil tiers qui vient s'ajouter à votre base de données. Qu'est-ce que cela signifie lorsque l'outil n'est pas capable de reconnaître correctement un split-brain ? Que se passe-t-il pour vos clients si la réplication est à la traîne lors de la bascule sur une critique ? Ces outils vont demander eux aussi de la maintenance et un suivi dans le temps. En cas de mise à jour de cet outil tiers, quel est l'impact sur votre base de données ? Devrez-vous la mettre hors-ligne ?
Pour garantir une bonne gestion de ces cas, vous mettrez certainement en place des contrôles humains. Si vous visez une disponibilité de 99,999 %, ce qui représente environ 5 minutes d'indisponibilité par an, vous devez disposer d'une stratégie d'astreinte très rapide ! La nuit, le temps nécessaire pour se lever, se connecter au système et acquitter le problème sera certainement supérieur à ces 5 minutes... et rien n'aura encore été fait pour résoudre l'incident.
C'est pourquoi, lorsque l'on vise une SLA très élevée, il est préférable de se concentrer sur les systèmes tolérants aux pannes.
Base de données tolérante aux pannes
Pour être tolérant aux pannes, il faut être prêt avec des données répliquées. Un système tolérant aux pannes est disponible ET ne manque jamais les modifications de données qu'il aura validé. Il s'agit d'une grande différence par rapport à un système à haute disponibilité, dans lequel certaines modifications peuvent être perdues lors d'une défaillance.
Dans le contexte d'une base de données, cela signifie que vous devez répliquer les données sur plusieurs nœuds pour vous assurer que tout est stocké et disponible à plusieurs endroits. À première vue, cela semble facile. Mais lorsqu'on examine les détails, il devient très difficile de s'assurer que toutes les répliques obtiennent exactement la même valeur à chaque fois. C'est encore plus difficile lorsque vous essayez d'appliquer la conformité ACID pour les transactions.
De nombreuses solutions n'offrent pas de capacité de tolérance aux pannes. La solution HA consiste à répliquer un serveur primaire sur une ou plusieurs répliques. Vous pouvez utiliser certains outils pour réduire au maximum le décalage, mais vos répliques sont toujours à la traîne et vous ne pouvez pas être strictement cohérent entre le primaire et les répliques.
Les solutions NoSQL fournissent souvent des mécanismes de réplication et prétendent être tolérantes aux pannes. Mais la réplication est principalement un processus asynchrone qui peut simplement échouer. Et ce n'est pas grave ! Lorsque les solutions NoSQL sont apparues, le principe de cohérence à terme est devenu un sujet de discussion important afin d'appréhender où et quand utiliser ces solutions. Ce principe est conçu pour garantir les performances, la cohérence n'étant plus une priorité.
La tolérance aux pannes est l'atout majeur de Cockroach DB, et c'est même l'origine du nom de l'outil. Tout comme les cafards ont une incroyable capacité de survie , Cockroach DB apporte des capacités de tolérance aux pannes uniques via un design conçu pour ces cas. On peut presque voir la scalabilité offerte par Cockroach comme un effet de bord de la tolérance aux pannes voulue et pensée dès le début dans la conception.
Conclusion
Cockroach a une conception unique qui garantit des transactions sérialisables et tolérante aux pannes. Lorsqu'une application fonctionnant avec Cockroach reçoit un accusé de réception de commit, quoi qu'il puisse arriver dans votre système, la transaction est sauvegardée et la cohérence est garantie, même avec des réplications distribuées dans le monde entier.
La stratégie de déploiement multi-régions peut vous permettre de survivre facilement à toute panne d'une région d'un CSP ou d'un data-center.
Toutes les solutions ne sont pas égales car elles ne visent pas à résoudre le même problème. Si vous cherchez quelque chose de rapide, qui peut tolérer l'incohérence, le NoSQL est une bonne solution. Si votre entreprise peut se permettre des SLA de 99,9 % ou moins, une solution SQL standard convient.
Dès que vous envisagez une plus grande disponibilité ou une cohérence stricte, il est préférable de vous concentrer sur la tolérance aux pannes ; et c'est là que Cockroach DB va être le plus pertinent. Cockroach DB évitera de nombreux problèmes dus à des erreurs de développement ou à une mauvaise compréhension du niveau d'isolation d'une transaction et fournira un système prévu pour résister aux pannes. Le nom de la base de données n'est pas seulement amusant, il est aussi intentionnel !