D'une manière ou d'une autre, historiquement, l'industrie informatique est divisée en deux camps conditionnels, quelle que soit la raison : ceux qui sont « pour » et ceux qui sont « contre ». De plus, l'objet des litiges peut être totalement arbitraire. Quel système d'exploitation est le meilleur : Win ou Linux ? Sur un smartphone Android ou iOS ? Devez-vous tout stocker dans les nuages ou le mettre sur un stockage RAID froid et mettre les vis dans un coffre-fort ? Les personnes PHP ont-elles le droit d’être appelées programmeurs ? Ces conflits sont parfois de nature exclusivement existentielle et n’ont d’autre fondement que l’intérêt sportif.
Il se trouve qu'avec l'avènement des conteneurs et toute cette cuisine bien-aimée avec docker et k8 conditionnels, les débats « pour » et « contre » l'utilisation de nouvelles capacités dans divers domaines du backend ont commencé. (Réservons à l'avance que même si Kubernetes sera le plus souvent indiqué comme orchestrateur dans cette discussion, le choix de cet outil particulier n'a pas d'importance fondamentale. Au lieu de cela, vous pouvez le remplacer par tout autre qui vous semble le plus pratique et le plus familier. .)
Et, semble-t-il, il s’agirait d’un simple différend entre les deux faces d’une même médaille. Aussi insensé et impitoyable que l'éternelle confrontation entre Win et Linux, dans laquelle des personnes adéquates existent quelque part au milieu. Mais dans le cas de la conteneurisation, tout n’est pas si simple. Habituellement, dans de tels litiges, il n'y a pas de bon côté, mais dans le cas de « l'utilisation » ou de la « non-utilisation » de conteneurs pour stocker des bases de données, tout bascule. Car dans un certain sens, les partisans comme les opposants de cette approche ont raison.
Côté lumineux
L’argument de Light Side peut être brièvement décrit en une seule phrase : « Bonjour, 2k19 est par la fenêtre ! » Cela ressemble bien sûr à du populisme, mais si l’on examine la situation en détail, cela a ses avantages. Trions-les maintenant.
Disons que vous avez un grand projet Web. Il aurait pu être initialement construit sur la base d'une approche de microservice, ou à un moment donné, il y est parvenu par un chemin évolutif - ce n'est pas très important, en fait. Vous avez dispersé notre projet en microservices distincts, mis en place l'orchestration, l'équilibrage de charge et la mise à l'échelle. Et maintenant, la conscience tranquille, vous sirotez un mojito dans un hamac pendant les effets habra au lieu de relever les serveurs tombés. Mais dans toutes vos actions, vous devez être cohérent. Très souvent, seule l’application elle-même (le code) est conteneurisée. Qu’avons-nous d’autre à part le code ?
C'est vrai, les données. Le cœur de tout projet réside dans ses données : il peut s'agir soit d'un SGBD typique - MySQL, Postgre, MongoDB, soit d'un stockage utilisé pour la recherche (ElasticSearch), d'un stockage clé-valeur pour la mise en cache - par exemple, redis, etc. Actuellement, nous ne le sommes pas. nous parlerons des options d'implémentation backend tordues lorsque la base de données plante en raison de requêtes mal écrites, et nous parlerons plutôt de garantir la tolérance aux pannes de cette même base de données sous la charge du client. Après tout, lorsque nous conteneurisons notre application et lui permettons d'évoluer librement pour traiter un nombre illimité de requêtes entrantes, cela augmente naturellement 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 s'exécute deviennent le chas de l'aiguille dans notre magnifique backend conteneurisé. Dans le même temps, le motif principal de la virtualisation des conteneurs est la mobilité et la flexibilité de la structure, qui nous permettent d'organiser le plus efficacement possible la répartition des pics de charge sur l'ensemble de l'infrastructure dont nous disposons. Autrement dit, si nous ne conteneurisons pas et ne déployons pas tous les éléments existants du système dans le cluster, nous commettons une très grave erreur.
Il est beaucoup plus logique de regrouper non seulement l'application elle-même, mais également les services chargés de stocker les données. En regroupant et en déployant des serveurs Web qui fonctionnent de manière indépendante et répartissent la charge entre eux dans les k8, nous résolvons déjà le problème de la synchronisation des données - les mêmes commentaires sur les publications, si nous prenons comme exemple une plate-forme de média ou de blog. Dans tous les cas, nous disposons d’une représentation intra-cluster, voire virtuelle, de la base de données en tant que ExternalService. Le problème est que la base de données elle-même n'est pas encore clusterisée - les serveurs Web déployés dans le cube obtiennent des informations sur les modifications de notre base de données de combat statique, qui tourne séparément.
Sentez-vous un piège ? Nous utilisons k8s ou Swarm pour répartir la charge et éviter de planter le serveur Web principal, mais nous ne le faisons pas pour la base de données. Mais si la base de données tombe en panne, alors toute notre infrastructure en cluster n'a aucun sens : à quoi servent les pages Web vides qui renvoient une erreur d'accès à la base de données ?
C'est pourquoi il est nécessaire de regrouper non seulement les serveurs Web, comme cela se fait habituellement, mais également l'infrastructure des bases de données. Ce n'est qu'ainsi que nous pourrons garantir une structure qui fonctionne pleinement au sein d'une seule équipe, tout en étant indépendante les unes des autres. De plus, même si la moitié de notre backend « s'effondre » sous la charge, le reste survivra, et le système de synchronisation des bases de données entre elles au sein du cluster et la possibilité d'évoluer et de déployer sans cesse de nouveaux clusters aideront à atteindre rapidement la capacité requise - si seulement il y avait des racks dans le centre de données.
De plus, le modèle de base de données distribué en clusters vous permet d'amener cette même base de données là où elle est nécessaire ; Si nous parlons d'un service mondial, il est alors tout à fait illogique de créer un cluster Web quelque part dans la région de San Francisco et d'envoyer en même temps des paquets lors de l'accès à une base de données dans la région de Moscou et inversement.
De plus, la conteneurisation de la base de données vous permet de construire tous les éléments du système au même niveau d'abstraction. Ce qui, à son tour, permet de gérer ce même système directement à partir du code, par les développeurs, sans la participation active des administrateurs. Les développeurs pensaient qu'un SGBD distinct était nécessaire pour le nouveau sous-projet - c'est simple ! j'ai écrit un fichier yaml, je l'ai téléchargé sur le cluster et vous avez terminé.
Et bien entendu, le fonctionnement interne est grandement simplifié. Dites-moi, combien de fois avez-vous fermé les yeux lorsqu'un nouveau membre de l'équipe a mis la main dans la base de données de combat pour le travail ? Lequel, en fait, est le seul que vous possédez et qui tourne en ce moment ? Bien sûr, nous sommes tous des adultes ici, et quelque part nous avons une nouvelle sauvegarde, et encore plus loin - derrière l'étagère avec les concombres et les vieux skis de grand-mère - une autre sauvegarde, peut-être même dans une chambre froide, car votre bureau a déjà pris feu une fois. Mais tout de même, chaque introduction d'un nouveau membre de l'équipe ayant accès à l'infrastructure de combat et, bien sûr, à la base de données de combat est un seau de validol pour tout le monde. Eh bien, qui le connaît, un débutant, peut-être qu'il est croisé ? C'est effrayant, vous en conviendrez.
La conteneurisation et, en fait, la topologie physique distribuée de la base de données de votre projet permettent d'éviter de tels moments de validation. Vous ne faites pas confiance à un débutant ? D'ACCORD! Donnons-lui son propre cluster avec lequel travailler et déconnectons la base de données des autres clusters - synchronisation uniquement par push manuel et rotation synchrone de deux clés (une pour le chef d'équipe, l'autre pour l'administrateur). Et tout le monde est content.
Et maintenant, il est temps de se muer en opposants au clustering de bases de données.
Côté obscur
En expliquant pourquoi cela ne vaut pas la peine de conteneuriser la base de données et de continuer à l’exécuter sur un serveur central, nous ne nous abaisserons pas à la rhétorique des orthodoxies et aux déclarations telles que « les grands-pères géraient les bases de données sur du matériel, et nous aussi ! Essayons plutôt de trouver une situation dans laquelle la conteneurisation rapporterait réellement des dividendes tangibles.
D'accord, les projets qui nécessitent vraiment une base dans un conteneur ne peuvent pas être comptés sur les doigts d'une main par le meilleur opérateur de fraiseuse. Pour la plupart, même l'utilisation de K8 ou de Docker Swarm elle-même est redondante - on a très souvent recours à ces outils en raison du battage médiatique général des technologies et de l'attitude du « tout-puissant » en la personne des sexes pour tout pousser dans le nuages et conteneurs. Eh bien, parce que maintenant c'est à la mode et tout le monde le fait.
Dans au moins la moitié des cas, utiliser Kubernetis ou simplement Docker sur un projet est redondant. Le problème est que toutes les équipes ou sociétés d’externalisation engagées pour maintenir l’infrastructure du client n’en sont pas conscientes. C’est pire quand les conteneurs sont imposés, car cela coûte une certaine quantité de pièces au client.
En général, il existe une opinion selon laquelle la mafia des dockers/cubes écrase bêtement les clients qui sous-traitent ces problèmes d'infrastructure. Après tout, pour travailler avec des clusters, nous avons besoin d'ingénieurs capables et comprenant généralement l'architecture de la solution implémentée. Nous avons déjà décrit notre cas avec la publication Republic - nous y avons formé l'équipe du client pour qu'elle travaille dans les réalités de Kubernetis, et tout le monde était satisfait. Et c'était convenable. Souvent, les « exécutants » de K8 prennent l'infrastructure du client en otage - car maintenant eux seuls comprennent comment tout fonctionne là-bas ; il n'y a pas de spécialistes du côté du client.
Imaginez maintenant que de cette manière nous externalisons non seulement la partie serveur web, mais également la maintenance de la base de données. Nous avons dit que la BD est le cœur et que la perte du cœur est mortelle pour tout organisme vivant. Bref, les perspectives ne sont pas des meilleures. Ainsi, au lieu du battage médiatique Kubernetis, de nombreux projets ne devraient tout simplement pas se soucier du tarif normal pour AWS, ce qui résoudra tous les problèmes de charge sur leur site/projet. Mais AWS n'est plus à la mode et les frimeurs valent plus que l'argent - malheureusement, dans l'environnement informatique aussi.
D'ACCORD. Peut-être que le projet a vraiment besoin d'un clustering, mais si tout est clair avec les applications sans état, comment pouvons-nous organiser une connectivité réseau décente pour une base de données en cluster ?
Si nous parlons d'une solution d'ingénierie transparente, ce qu'est la transition vers k8s, alors notre principal casse-tête est la réplication des données dans une base de données en cluster. Certains SGBD sont initialement assez fidèles à la répartition des données entre leurs instances individuelles. Beaucoup d’autres ne sont pas aussi accueillants. Et bien souvent, le principal argument dans le choix d'un SGBD pour notre projet n'est pas la capacité de le répliquer avec des coûts de ressources et d'ingénierie minimes. Surtout si le projet n'était pas initialement prévu comme un microservice, mais évoluait simplement dans cette direction.
Nous pensons qu'il n'est pas nécessaire de parler de la vitesse des lecteurs réseau : ils sont lents. Ceux. Nous n'avons toujours pas de réelle opportunité, si quelque chose se produit, de redémarrer une instance de SGBD quelque part où il y a plus, par exemple de puissance de processeur ou de RAM libre. Nous aborderons très rapidement les performances du sous-système de disque virtualisé. En conséquence, le SGBD doit être connecté à son propre ensemble personnel de machines situées à proximité immédiate. Ou il est nécessaire de refroidir séparément une synchronisation des données suffisamment rapide pour les réserves supposées.
Poursuivant le sujet des systèmes de fichiers virtuels : les volumes Docker, malheureusement, ne sont pas sans problèmes. En général, en matière de stockage fiable de données à long terme, j'aimerais me contenter des schémas les plus simples techniquement. Et ajouter une nouvelle couche d’abstraction du FS du conteneur au FS de l’hôte parent est un risque en soi. Mais lorsque le fonctionnement du système de support de conteneurisation rencontre également des difficultés de transmission des données entre ces couches, alors c’est vraiment un désastre. À l’heure actuelle, la plupart des problèmes connus de l’humanité progressiste semblent avoir été éradiqués. Mais vous l’aurez compris, plus le mécanisme est complexe, plus il se casse facilement.
À la lumière de toutes ces « aventures », il est beaucoup plus rentable et plus facile de conserver la base de données au même endroit, et même si vous devez conteneuriser l'application, laissez-la s'exécuter seule et, via la passerelle de distribution, recevez une communication simultanée avec le base de données, qui ne sera lue et écrite qu’une seule fois et au même endroit. Cette approche réduit au minimum le risque d'erreurs et de désynchronisation.
Vers quoi mène-t-on ? De plus, la conteneurisation des bases de données est appropriée là où il existe un réel besoin. Vous ne pouvez pas remplir une base de données complète d’applications et la faire tourner comme si vous disposiez de deux douzaines de microservices – cela ne fonctionne pas de cette façon. Et cela doit être clairement compris.
Au lieu de sortie
Si vous attendez une conclusion claire « virtualiser ou non la base de données », alors nous vous décevrons : elle ne sera pas là. Car lors de la création d'une solution d'infrastructure, il ne faut pas se laisser guider par la mode et le progrès, mais avant tout par le bon sens.
Il existe des projets pour lesquels les principes et les outils fournis avec Kubernetis s'adaptent parfaitement, et dans de tels projets, la paix règne au moins dans le domaine du backend. Et il y a des projets qui n'ont pas besoin de conteneurisation, mais d'une infrastructure de serveur normale, car ils ne peuvent fondamentalement pas être adaptés au modèle de cluster de microservices, car ils tomberont.
Source: habr.com