Base de données native Kubernetes : TiDB Vs. DataStax Astra DB

A look at two databases that have made claims to the Kubernetes native label: TiDB and DataStax Astra DB.

La révolution du cloud computing a inspiré et bénéficié de multiples tendances interdépendantes. La disponibilité d'une infrastructure de cloud public en libre-service a contribué à l'adoption d'architectures de microservices et de pratiques DevOps, y compris l'automatisation et l'observabilité.

La tendance à la conteneurisation et à l'orchestration des conteneurs a conduit à l'adoption généralisée de Kubernetes comme environnement de gestion des applications cloud natives.

Mais l'un des domaines à la traîne de cette révolution a été les données et l'infrastructure de données. Pendant trop longtemps, les données ont vécu en dehors de Kubernetes, ce qui a entraîné beaucoup d'efforts et de complexité supplémentaires pour les développeurs lors du déploiement d'applications cloud natives.

Un axiome souvent répété dans les premières années de Kubernetes était qu'il n'était pas encore prêt pour les charges de travail avec état. Heureusement, un changement majeur a été tranquillement en cours et a atteint un point de maturité.

La transformation s'est d'abord produite lentement, en commençant par des efforts pour conteneuriser les bases de données existantes. Cela fonctionnait relativement bien dans les petites bases de données qui s'exécutaient sur un seul nœud de calcul ou dans les bases de données conçues dans un monde natif du cloud, comme Apache Cassandra et DynamoDB, mais des défis subsistaient.

Au cours des deux à trois dernières années, une nouvelle génération de bases de données a émergé. Ces bases de données "natives Kubernetes" ont été conçues dès le départ pour fonctionner sur ce système d'orchestration open source.

Ici, nous définirons les qualités qui rendent une base de données native Kubernetes et les avantages de l'adoption d'une base de données native Kubernetes. Pour ce faire, nous allons examiner deux bases de données revendiquant le label natif Kubernetes : TiDB et DataStax Astra DB.

MySQL natif Kubernetes avec TiDB

Examinons d'abord une base de données à accent relationnel : TiDB (abréviation de Titanium Database). TiDB est un système open source construit par PingCAP qui fournit une base de données compatible MySQL et une base de données en colonnes pour prendre en charge le traitement transactionnel et analytique hybride (appelé HTAP, en abrégé).

Comme le montre la figure 1 ci-dessous, TiDB a une conception de microservice. La couche de requête TiDB, les bases de données MySQL TiKV, les bases de données en colonnes TiFlash, les nœuds Spark et la gestion des métadonnées sont chacun déployés en tant que microservices évolutifs dans leurs clusters. Cette conception sépare le travail intensif en calcul du travail intensif en stockage, car les couches de requête et de base de données sont indépendamment évolutives.

Un engagement critique pris par les créateurs de TiDB était que la base de données ne fonctionne que sur Kubernetes.

Est-ce suffisant pour le rendre natif de Kubernetes ?

Creusons un peu plus profondément.

Tout d'abord, TiDB est déployé et géré par un opérateur Kubernetes à l'aide de ressources personnalisées (CRD). Les CRD TiDB incluent le TiDBCluster, qui vous permet de spécifier la mise à l'échelle et la configuration de chaque microservice et la manière dont les composants de la couche de base de données utilisent le stockage via les volumes persistants Kubernetes. Des CRD supplémentaires sont utilisés pour déployer des outils de surveillance et gérer des tâches opérationnelles telles que la sauvegarde et la restauration.

TiDB dispose également d'une extension de planificateur facultative qui s'interface avec le planificateur K8s par défaut pour prendre des décisions de planification plus sensibles aux applications. Cet accent mis sur l'utilisation des fonctionnalités Kubernetes existantes lorsqu'elles sont disponibles est la marque d'une base de données native Kubernetes.

Cassandre native Kubernetes avec DataStax Astra DB

Maintenant, regardez une autre base de données native Kubernetes et notez quelques similitudes et différences.

Cassandra est une base de données NoSQL hautement évolutive qui a été l'une des premières à prétendre être native du cloud, mais à quoi ressemble le déploiement de Cassandra dans Kubernetes ?

DataStax Astra DB est une version de Cassandra qui a été intégrée aux microservices, comme le montre la figure 2.

Comme TiDB, la base de données comprend des microservices concernés par le traitement des requêtes et le stockage des données, ainsi que des services de contrôle d'identité et d'accès, de réparation des données et de sauvegarde/restauration.

Les services de données sont particulièrement intéressants dans leur utilisation du stockage , avec les volumes persistants Kubernetes utilisés uniquement pour la mise en cache et le stockage objet utilisé pour la persistance à plus long terme. La séparation du compactage dans son service permet à ce traitement intensif de calcul de se produire en arrière-plan sans affecter les performances des services de données desservant le trafic de lecture et d'écriture.

Astra DB est proposé en tant que service géré disponible dans plusieurs régions cloud. Chaque région contient un plan de données composé des services mentionnés ci-dessus, gérés par un opérateur Kubernetes, ainsi que des services d'infrastructure, dont la pile Kube-Promethus pour l'observabilité et etcd pour la gestion des métadonnées.

Les plans de données sont gérés par un plan de contrôle qui peut s'exécuter dans un ou plusieurs clouds pour gérer les comptes clients et les bases de données et provisionner les clusters Kubernetes dans de nouvelles régions.

Un nouvel aspect d'Astra DB est son architecture multi-tenant dans laquelle plusieurs bases de données utilisateur peuvent partager les mêmes microservices et infrastructure de support, réduisant ainsi l'économie unitaire pour les utilisateurs à plus petite échelle.

Au fur et à mesure que les utilisateurs développent leurs applications, ils peuvent passer à des ressources dédiées pour obtenir des performances optimales à grande échelle, le tout sur une base « pay-as-you-go ».

Principes de la base de données native Kubernetes

Sur la base de nos observations sur TiDB et Astra DB, nous pouvons tirer quelques idées de ce qui rend une base de données Kubernetes native. Beaucoup d'entre eux correspondent à une liste de principes pour les données natives du cloud, que j'ai décrites dans un article précédent :

• Architecture de microservice composable : premièrement, une base de données divisée en microservices constitutifs permet à chaque service d'être mis à l'échelle indépendamment. Certains types de traitement à forte intensité de calcul peuvent même être réduits à zéro pour une véritable solution sans serveur, en particulier lorsqu'ils sont combinés à une conception mutualisée.
• Traiter le calcul, le réseau et le stockage comme des produits : les microservices composés d'une base de données native Kubernetes doivent utiliser au maximum les API Kubernetes pour gérer les ressources fondamentales des applications cloud natives : ressources de calcul telles que StatefulSets et déploiements pour gérer les charges de travail, le sous-système de volume persistant pour le stockage , l'entrée Kubernetes et les services pour exposer l'accès réseau aux données et plus encore. Cela inclut l'exploitation des fonctionnalités déjà présentes dans Kubernetes, telles que etcd pour la gestion des métadonnées, au lieu d'apporter des composants avec des fonctionnalités de duplication.
• Tirez parti des meilleures pratiques de Kubernetes : le fait de suivre des modèles communs pour les applications Kubernetes apportera de nombreux avantages opérationnels, par exemple, en exposant des contrôles de vivacité et de préparation sur chaque microservice pour aider à la disponibilité et en exposant des métriques via l'API Prometheus PromQL pour l'observabilité . Par défaut, Kubernetes lui-même donne un excellent exemple que les bases de données doivent suivre pour savoir comment être sécurisées : utiliser les secrets Kubernetes pour distribuer les informations d'identification de sécurité, exposer uniquement les ports nécessaires, etc.
• Gestion déclarative via des opérateurs : une base de données native Kubernetes doit incarner les principes Kubernetes de gestion déclarative via des opérateurs et des ressources personnalisées, plutôt que de s'appuyer sur des interfaces utilisateur et des CLI de gestion de base de données héritées. Si nécessaire, les points d'extension Kubernetes, tels que les extensions de planificateur, peuvent être utilisés pour ajouter un comportement spécifique à l'application . L'objectif est une séparation nette de la fonctionnalité du plan de données (gestion des données) de la fonctionnalité du plan de contrôle (gestion de la base de données).

Les bases de données et autres infrastructures de données qui adoptent fidèlement ces principes apporteront des avantages, notamment des performances élevées pour un coût optimal à toutes les échelles , une complexité opérationnelle réduite entraînant une mise sur le marché plus rapide et des solutions conformes aux normes répondant aux exigences actuelles de haute disponibilité et de sécurité.

L'avenir de l'infrastructure de données native Kubernetes

De nombreux progrès restent à faire, et ils ne se limitent pas aux seules bases de données. Les principes natifs de Kubernetes peuvent être appliqués à d'autres types d'infrastructure de données, notamment le streaming, l'analyse et l'apprentissage automatique.

Les solutions natives de Kubernetes continueront de faire des progrès dans les déploiements multicluster et multicloud pour évoluer à l'échelle mondiale et adopteront les principes de multitenancy et sans serveur pour une meilleure optimisation des coûts.

Kubernetes lui-même peut être amélioré en ajoutant plus de flexibilité aux StatefulSets et en prenant en charge la fédération multicluster.

La clé du progrès continu est une collaboration ouverte. La communauté Data on Kubernetes est un groupe très actif de geeks de données réunissant des créateurs d'applications gourmandes en données et l'infrastructure qui les prend en charge.

Rejoignez-nous pour discuter d'idées telles que le développement d'opérateurs réutilisables capables de gérer plusieurs bases de données ou la définition d'un ensemble commun de CRD pour des concepts tels que la sauvegarde/restauration et le chargement de données. Ensemble, nous continuerons à repousser l'horizon du cloud computing pour le bénéfice de tous.

Apprenez-en plus sur les bases de données natives de Kassandra et bien plus encore lors du sommet numérique Cassandra Forward le 14 mars 2023.

Cet article est basé sur le chapitre 7, « La base de données native Kubernetes », du livre O'Reilly « Managing Cloud Native Data on Kubernetes » de Jeff Carpenter et Patrick McFadin.

[

Par Jeff Carpenter, DataStax

Jeff Carpenter a travaillé comme ingénieur logiciel et architecte dans plusieurs secteurs et comme défenseur des développeurs chez DataStax, aidant les ingénieurs à réussir avec Apache Cassandra. Il est impliqué dans plusieurs projets open source dans les écosystèmes Cassandra et Kubernetes, notamment Stargate et K8ssandra. Il est co-auteur des livres O'Reilly "Cassandra : The Definitive Guide" et "Managing Cloud Native Data on Kubernetes".