Il s'est historiquement établi que l'industrie informatique se divise en deux camps conditionnels : ceux qui sont "pour" et ceux qui sont "contre". Et les sujets de débat peuvent être absolument arbitraires. Quel est le meilleur système d'exploitation : Windows ou Linux ? Sur un smartphone, Android ou iOS ? Stocker tout dans le cloud ou le transférer sur des dispositifs RAID froids et mettre les disques dans un coffre-fort ? Les développeurs PHP ont-ils le droit de se faire appeler programmeurs ? Ces débats sont parfois d'une nature purement existentielle et ne reposent sur aucune autre base, à part l'intérêt sportif.
Il se trouve qu'avec l'apparition des conteneurs et de toute cette cuisine que nous aimons tant avec Docker et le Kubernetes supposé, les débats "pour" et "contre" l'utilisation de nouvelles possibilités dans divers domaines de backend ont commencé. (Précisons d'emblée que, bien que Kubernetes soit souvent cité comme orchestrateur dans ce raisonnement, le choix de cet outil en particulier n'est pas fondamental. N'importe quel autre outil que vous jugez plus pratique et familier peut être substitué à celui-ci.)
Et, on pourrait penser qu'il s'agissait d'un simple débat entre deux côtés d'une même médaille. Tout aussi inutile et implacable que l'éternelle rivalité entre Windows et Linux, où des personnes sensées existent quelque part au milieu. Cependant, dans le cas de la conteneurisation, tout n'est pas si simple. Dans de tels débats, il n'y a généralement pas de partie droite, mais dans le cas de "utiliser" ou "ne pas utiliser" des conteneurs pour le stockage des bases de données, tout devient sens dessus dessous. Car, dans un certain sens, tant les partisans que les adversaires de cette approche ont raison.
Côté lumineux
Décrire brièvement l'argumentation du Côté lumineux en une phrase : "Eh, 2019 est dehors !" Cela peut sembler du populisme, sans aucun doute, mais en approfondissant la question, il y a ses avantages. C'est ce que nous allons explorer maintenant.
Imaginons que vous ayez un grand projet web. Il a pu être initialement construit sur la base d'une approche microservices, ou bien il y est arrivé par un chemin évolutif à un moment donné — cela n'a pas vraiment d'importance, en fait. Vous avez réparti votre projet en différents microservices, configuré l'orchestration, l'équilibrage de charge, le scaling. Et maintenant, en toute tranquillité, vous sirotez un mojito dans un hamac pendant les effets de Habr au lieu de redémarrer des serveurs tombés. Mais dans toutes ces actions, il faut être cohérent. Très souvent, seul le code de l'application elle-même est containerisé. Et qu'avons-nous d'autre en plus du code ?
C'est exact, les données. Le cœur de tout projet ce sont ses données : cela peut être une base de données typique comme MySQL, Postgre, MongoDB, ou des stockages utilisés pour la recherche (ElasticSearch), et des stockages clé-valeur pour le caching — par exemple, redis, etc. Pour le moment, nous ne parlerons pas des solutions de backend problématiques où la base de données échoue à cause de requêtes mal écrites, mais nous discuterons plutôt de la mise en place de la résilience de cette base de données sous la charge des clients. En effet, lorsque nous containerisons notre application et lui permettons de se redimensionner librement pour traiter n'importe quel nombre de requêtes entrantes, cela augmente inévitablement la charge sur la base de données.
En fait, le canal d'accès à la base de données et le serveur sur lequel elle fonctionne deviennent le goulot d'étranglement dans notre magnifique backend containerisé. Le principal objectif de la virtualisation par conteneur est la mobilité et la flexibilité de la structure, permettant d'organiser la répartition de la charge de pointe sur toute l'infrastructure disponible de la manière la plus efficace possible. Ainsi, si nous ne containerisons pas et ne déployons pas tous les éléments du système sur un cluster, nous commettons une très grave erreur.
Il est beaucoup plus logique de clusteriser non seulement l'application elle-même, mais aussi les services chargés du stockage des données. Lors de la clusterisation et du déploiement de serveurs web indépendants qui répartissent la charge entre eux dans k8s, nous résolvons déjà le problème de synchronisation des données — comme les commentaires sur les publications, pour prendre l'exemple d'un média ou d'une plateforme de blog. Nous avons de toute façon une représentation interne du cluster, même si elle est virtuelle, de la base de données en tant que ExternalService. La question est que la base de données elle-même n'est pas encore clusterisée — les serveurs web déployés dans le cluster obtiennent les informations sur les changements de notre base de données statique qui fonctionne séparément.
Vous sentez un piège ? Nous utilisons k8s ou Swarm pour répartir la charge et éviter que le principal serveur web, mais nous ne faisons pas cela pour la base de données. Mais si la base de données tombe, alors il n'y a aucun sens dans notre infrastructure clusterisée — à quoi bon des pages web vides qui renvoient une erreur d'accès à la base de données ?
C'est pourquoi il est nécessaire de clusteriser non seulement les serveurs web, comme c'est généralement fait, mais aussi l'infrastructure de la base de données. Ce n'est qu'ainsi que nous pouvons garantir une structure pleinement fonctionnelle, mais à la fois indépendante, qui travaillera ensemble. Même si la moitié de notre backend "s'effondre" sous la charge, l'autre moitié survivra, et le système de synchronisation de la base de données entre eux dans le cluster ainsi que la possibilité d'une scalabilité infinie et de déploiement de nouveaux clusters aidera à atteindre rapidement les capacités nécessaires — tant qu'il y a des racks dans le centre de données.
De plus, le modèle de base de données distribué en clusters permet de déplacer cette base de données là où elle est nécessaire ; si nous parlons d'un service global, il est assez illogique d'avoir un cluster web quelque part près de San Francisco tout en dirigeant les paquets vers la base de données en Russie et de retour.
De plus, la conteneurisation de la base de données permet de construire tous les éléments du système à un même niveau d'abstraction. Ce qui, en retour, rend possible la gestion de ce système directement depuis le code, par les développeurs, sans avoir besoin d'impliquer activement les administrateurs. Les développeurs ont pensé qu'il leur fallait une base de données distincte pour un nouveau sous-projet — facile ! ils ont écrit un fichier yaml, l'ont chargé dans le cluster et c'est prêt.
Et bien sûr, l'exploitation interne est simplifiée de manière significative. Dites-moi, combien de fois avez-vous fermé les yeux lorsque qu'un nouveau membre de l'équipe a tenté d'accéder à la base de données en production ? Celle que vous avez, au fait, est unique et tourne justement en ce moment ? Bien sûr, nous sommes tous des adultes ici, et quelque part, nous avons une sauvegarde récente, et plus loin - derrière l'étagère avec les concombres de grand-mère et les vieux skis - une autre sauvegarde, peut-être même sur un stockage froid, parce qu'un jour, votre bureau a déjà brûlé. Mais quand même, chaque nouvel ajout à l'équipe ayant accès à l'infrastructure de production et, bien sûr, à la base de données en production, c'est un seau de valium pour tout le monde. Qui sait, peut-être que ce novice est malhabile ? Terrifiant, n'est-ce pas ?
La conteneurisation et, en fait, la topologie physique distribuée de la base de données de votre projet aident à éviter de tels moments de stress. Vous ne faites pas confiance au débutant ? D'accord ! Créons-lui un cluster à lui pour travailler et déconnectons-le des autres clusters de la base de données - la synchronisation se fera uniquement par poussée manuelle et activation synchronisée de deux clés (une pour le leader, l'autre pour l'administrateur). Et tout le monde est heureux.
Il est maintenant temps de se transformer en opposants à la clusterisation des bases de données.
Côté Obscur
En réfléchissant à pourquoi il ne faut pas conteneuriser la base de données et continuer à l'exploiter sur un système central le serveur, ne tombons pas dans la rhétorique des orthodoxes et dans des affirmations comme « nos ancêtres faisaient tourner les bases de données sur du matériel, et nous le ferons ! » Au lieu de cela, essayons d'imaginer une situation dans laquelle la conteneurisation apporterait vraiment des dividendes significatifs.
Soyons d'accord, les projets qui nécessitent réellement une base dans un conteneur peuvent être comptés sur les doigts d'une main même d'un fraiseur moyen. Dans la plupart des cas, même l'utilisation de k8s ou de Docker Swarm est redondante - ces outils sont souvent employés en raison de l'engouement général pour ces technologies et des conseils d'en haut pour tout passer dans le cloud et les conteneurs. Oui, parce que c'est à la mode et que tout le monde le fait.
Dans au moins la moitié des cas, utiliser Kubernetes ou simplement Docker pour un projet est excessif. Le problème, c'est que toutes les équipes ou entreprises de sous-traitance engagées pour gérer l'infrastructure du client ne se rendent pas compte de cela. Pire encore, lorsque les conteneurs sont imposés parce qu'ils coûtent un certain montant au client.
En fait, il est communément admis que la mafia Docker/Kubernetes écrase littéralement les clients qui confient ces questions d'infrastructure à la sous-traitance. Pour travailler avec des clusters, il faut des ingénieurs capables de le faire et qui comprennent l'architecture de la solution mise en place. Nous avons déjà décrit notre cas avec le publication Republic — là, nous avons formé l'équipe du client à travailler dans le contexte de Kubernetes, et tout le monde était satisfait. Et c'était honnête. Souvent, les 'implémenteurs' de Kubernetes prennent l'infrastructure du client en otage — car maintenant, seuls eux comprennent comment tout fonctionne, alors que le client n'a pas de spécialistes.
Et maintenant imaginez que nous confions non seulement la partie serveur web à la sous-traitance, mais aussi la gestion de la base de données. Nous avons dit que la base de données est le cœur, et perdre le cœur est fatal pour tout organisme vivant. En gros, les perspectives ne sont pas les meilleures. Donc, au lieu du Kubernetes à la mode, de nombreux projets devraient simplement ne pas hésiter à investir dans un tarif normal chez AWS, qui résoudrait tous leurs problèmes de charge sur leur site/projet. Mais AWS n'est plus à la mode, et les apparences sont plus importantes que l'argent — malheureusement, c'est aussi le cas dans le domaine de l'informatique.
D'accord. Peut-être que la mise en cluster est réellement nécessaire pour le projet, mais si tout est clair avec les applications sans état, comment alors assurer une connectivité réseau adéquate pour une base de données en cluster?
Lorsque nous parlons d'une solution d'ingénierie sans couture, qui est ce que représente la transition vers k8s, notre principale préoccupation est la réplique des données dans une base de données clusterisée. Certaines SGBD sont au départ assez conciliantes quant à la distribution des données entre leurs différentes instances. D'autres, en revanche, ne sont pas si accueillants. Et souvent, le principal critère pour choisir un SGBD pour notre projet n'est pas tant sa capacité à se répliquer avec des coûts matériels et d'ingénierie minimaux. Surtout si le projet n'était pas initialement prévu comme microservices, mais a simplement évolué dans cette direction.
Nous pensons qu'il n'est pas nécessaire de parler de la vitesse des disques réseau — ils sont lents. C'est-à-dire que, s'il y a besoin, nous n'avons pas la possibilité de relancer une instance de SGBD ailleurs, par exemple là où il y a plus de puissance processeur ou de mémoire vive disponible. Nous allons rapidement atteindre la limite de performance du sous-système de disques virtualisés. En conséquence, le SGBD doit être attaché à son propre ensemble de machines personnelles, situées à proximité directe. Sinon, il faut trouver un moyen de synchroniser séparément les données assez rapidement vers les réserves prévues.
Pour continuer sur le sujet des systèmes de fichiers virtuels : les volumes Docker, malheureusement, ne sont pas sans problème. Dans l'ensemble, pour une tâche telle que le stockage fiable à long terme des données, il faudrait se contenter de schémas techniques aussi simples que possible. L'ajout d'une nouvelle couche d'abstraction entre le système de fichiers du conteneur et celui de l'hôte parent constitue déjà un risque en soi. Mais quand, en plus, des difficultés surgissent dans le système de conteneurisation concernant la transmission des données entre ces couches, c'est vraiment problématique. À l'heure actuelle, la plupart des problèmes connus et progressifs semblent être éradiqués. Mais vous comprenez, plus le mécanisme est complexe, plus il est susceptible de se briser.
À la lumière de toutes ces « aventures », il est beaucoup plus avantageux et simple de garder la base de données à un seul endroit. Même si vous avez besoin de la conteneuriser, laissez-la fonctionner de manière autonome et passez par une passerelle de répartition pour établir une connexion simultanée avec une base de données qui ne sera lue et écrite qu'une seule fois, à un seul endroit. Cette approche réduit la probabilité d'erreurs et de désynchronisations au minimum.
Où voulons-nous en venir ? Au fait que la conteneurisation de la base de données n'est pertinente que là où il y a un vrai besoin. On ne peut pas emballer une base SaaS complète et la faire fonctionner comme si vous aviez une vingtaine de microservices — ça ne fonctionne pas ainsi. Et il est crucial de comprendre cela.
Au lieu d'une conclusion
Si vous attendez une réponse claire à la question « virtualiser ou non la base de données », nous sommes désolés : elle n'existe pas ici. Parce qu'à la création de toute solution d'infrastructure, il faut se guider non pas par la mode et le progrès, mais avant tout, par le bon sens.
Il existe des projets pour lesquels les principes et outils liés à Kubernetes s'appliquent parfaitement, et dans de tels projets, il y a une certaine harmonie, au moins dans le domaine du backend. Et puis il y a des projets qui nécessitent non pas la conteneurisation, mais une infrastructure serveur normale, car ils ne peuvent tout simplement pas être redimensionnés selon un modèle de cluster microservices, sinon ils échoueront.
Source : habr.com
