Bonjour, habitants de Khabrovsk. Les cours du premier groupe du cours commencent aujourd'hui . À cet égard, nous aimerions vous raconter comment s'est déroulé le webinaire ouvert sur ce cours.
В nous avons parlé des défis auxquels les bases de données SQL sont confrontées à l'ère du cloud et de Kubernetes. En parallèle, nous avons regardé comment les bases de données SQL s’adaptent et mutent sous l’influence de ces enjeux.
Le webinaire a eu lieu , Google Cloud Practice Delivery Manager chez EPAM Systems.
Quand les arbres étaient petits...
Rappelons d'abord comment le choix des SGBD a commencé à la fin du siècle dernier. Cependant, cela ne sera pas difficile, car le choix d'un SGBD à cette époque commençait et se terminait Oracle.
À la fin des années 90 et au début des années 2, il n’y avait pratiquement aucun choix en matière de bases de données industrielles évolutives. Oui, il y avait IBM DBXNUMX, Sybase et quelques autres bases de données qui allaient et venaient, mais en général, elles n'étaient pas si visibles dans le contexte d'Oracle. En conséquence, les compétences des ingénieurs de cette époque étaient en quelque sorte liées au seul choix qui existait.
Oracle DBA devait être capable de :
- installer Oracle Server à partir du kit de distribution ;
- configurer le serveur Oracle :
- init.ora;
- auditeur.ora;
- créer:
- espaces de table ;
- régimes;
- utilisateurs;
— effectuer une sauvegarde et une restauration ;
— effectuer une surveillance;
— gérer les demandes sous-optimales.
Dans le même temps, il n'y avait aucune exigence particulière de la part d'Oracle DBA :
- être capable de choisir le SGBD optimal ou une autre technologie pour stocker et traiter les données ;
- fournir une haute disponibilité et une évolutivité horizontale (cela n'a pas toujours été un problème de DBA) ;
- bonne connaissance du domaine, de l'infrastructure, de l'architecture des applications, du système d'exploitation ;
- charger et décharger des données, migrer des données entre différents SGBD.
En général, si nous parlons du choix à l'époque, cela ressemble au choix dans un magasin soviétique à la fin des années 80 :
Notre temps
Depuis, bien sûr, les arbres ont poussé, le monde a changé, et c’est devenu quelque chose comme ceci :
Le marché des SGBD a également changé, comme le montre clairement le dernier rapport de Gartner :
Et ici, il convient de noter que les nuages, dont la popularité ne cesse de croître, ont occupé leur niche. Si nous lisons le même rapport Gartner, nous verrons les conclusions suivantes :
- De nombreux clients sont sur le point de migrer leurs applications vers le cloud.
- Les nouvelles technologies apparaissent pour la première fois dans le cloud et il n’est pas certain qu’elles migreront un jour vers une infrastructure non cloud.
- Le modèle de tarification par répartition est devenu monnaie courante. Tout le monde veut payer uniquement pour ce qu’il consomme, et ce n’est même pas une tendance, mais simplement un constat.
Quoi maintenant
Aujourd'hui, nous sommes tous dans le cloud. Et les questions qui se posent à nous sont des questions de choix. Et c'est énorme, même si l'on ne parle que du choix des technologies SGBD au format On-premises. Nous proposons également des services gérés et SaaS. Ainsi, le choix devient chaque année plus difficile.
Outre les questions de choix, il y a aussi des facteurs limitants:
- prix. De nombreuses technologies coûtent encore de l’argent ;
- compétences. Si l'on parle de logiciel libre, alors la question des compétences se pose, puisque le logiciel libre nécessite des compétences suffisantes de la part des personnes qui le déploient et l'exploitent ;
- fonctionnel. Tous les services disponibles dans le cloud et construits, par exemple, même sur le même Postgres, n'ont pas les mêmes fonctionnalités que Postgres sur site. C’est un facteur essentiel qu’il faut connaître et comprendre. De plus, ce facteur devient plus important que la connaissance de certaines capacités cachées d'un seul SGBD.
Ce qui est attendu de DA/DE maintenant :
- bonne compréhension du domaine et de l'architecture des applications ;
- la capacité de sélectionner correctement la technologie SGBD appropriée, en tenant compte de la tâche à accomplir ;
- la capacité de sélectionner la méthode optimale pour mettre en œuvre la technologie sélectionnée dans le contexte des limitations existantes ;
- capacité à effectuer le transfert et la migration de données ;
- capacité à mettre en œuvre et à exploiter les solutions sélectionnées.
Exemple ci-dessous basé sur GCP montre comment fonctionne le choix de l'une ou l'autre technologie pour travailler avec les données en fonction de leur structure :
Veuillez noter que PostgreSQL n'est pas inclus dans le schéma, car il est masqué sous la terminologie Cloud SQL. Et lorsque nous arrivons à Cloud SQL, nous devons à nouveau faire un choix :
Il convient de noter que ce choix n'est pas toujours clair, les développeurs d'applications sont donc souvent guidés par l'intuition.
Total:
- Plus on avance, plus la question du choix devient pressante. Et même si vous regardez uniquement GCP, les services gérés et SaaS, alors une certaine mention du SGBDR n'apparaît qu'à la 4ème étape (et là Spanner est à proximité). De plus, le choix de PostgreSQL apparaît dans la 5ème étape, et à côté il y a aussi MySQL et SQL Server, c'est-à-dire il y a beaucoup de tout, mais il faut choisir.
- Nous ne devons pas oublier les restrictions sur fond de tentations. En gros, tout le monde veut une clé, mais c'est cher. En conséquence, une requête typique ressemble à ceci : "S'il vous plaît, faites-nous un Spanner, mais pour le prix de Cloud SQL, vous êtes des professionnels !"
Que faire?
Sans prétendre être la vérité ultime, disons ce qui suit :
Nous devons changer notre approche de l’apprentissage :
- il ne sert à rien d’enseigner de la même manière qu’avant les DBA ;
- la connaissance d'un produit ne suffit plus ;
- mais en connaître des dizaines au niveau d'un est impossible.
Vous devez savoir non seulement et non combien coûte le produit, mais :
- cas d'utilisation de son application ;
- différentes méthodes de déploiement ;
- avantages et inconvénients de chaque méthode ;
- produits similaires et alternatifs pour faire un choix éclairé et optimal et pas toujours en faveur d'un produit familier.
Vous devez également être capable de migrer des données et comprendre les principes de base de l'intégration avec ETL.
Cas réel
Dans un passé récent, il était nécessaire de créer un backend pour une application mobile. Au moment où les travaux ont commencé, le backend avait déjà été développé et était prêt à être mis en œuvre, et l'équipe de développement a passé environ deux ans sur ce projet. Les tâches suivantes ont été définies :
- créer du CI/CD ;
- revoir l'architecture ;
- mettre tout cela en opération.
L'application elle-même était constituée de microservices et le code Python/Django a été développé à partir de zéro et directement dans GCP. En ce qui concerne le public cible, il était supposé qu'il y aurait deux régions - les États-Unis et l'UE, et le trafic serait distribué via l'équilibreur de charge global. Toutes les charges de travail et charges de travail de calcul ont été exécutées sur Google Kubernetes Engine.
Quant aux données, il y avait 3 structures :
- Stockage en ligne;
- Magasin de données;
- Cloud SQL (PostgreSQL).
On peut se demander pourquoi Cloud SQL a été choisi ? À vrai dire, une telle question a provoqué une sorte de pause gênante ces dernières années - on a le sentiment que les gens sont devenus timides à l'égard des bases de données relationnelles, mais ils continuent néanmoins à les utiliser activement ;-).
Dans notre cas, Cloud SQL a été choisi pour les raisons suivantes :
- Comme mentionné, l'application a été développée à l'aide de Django et dispose d'un modèle pour mapper les données persistantes d'une base de données SQL vers des objets Python (Django ORM).
- Le framework lui-même prenait en charge une liste assez limitée de SGBD :
- PostgreSQL ;
- MariaDB ;
- MySQL ;
- Oracle
- SQLite.
En conséquence, PostgreSQL a été choisi dans cette liste de manière plutôt intuitive (enfin, ce n’est pas vraiment à Oracle de choisir).
Ce qui manquait:
- l'application n'a été déployée que dans 2 régions, et une 3ème est apparue en projet (Asie) ;
- La base de données était située dans la région nord-américaine (Iowa) ;
- de la part du client, il y avait des inquiétudes quant à d'éventuels délais d'accès d'Europe et d'Asie et interruptions en service en cas d'indisponibilité du SGBD.
Malgré le fait que Django lui-même puisse travailler avec plusieurs bases de données en parallèle et les diviser en lecture et écriture, il n'y avait pas tellement d'écriture dans l'application (plus de 90 % sont en lecture). Et en général, et en général, s'il était possible de faire lecture-réplique de la base principale en Europe et en Asie, ce serait une solution de compromis. Eh bien, qu'est-ce qu'il y a de si compliqué là-dedans ?
La difficulté était que le client ne voulait pas renoncer à utiliser les services gérés et Cloud SQL. Et les capacités de Cloud SQL sont actuellement limitées. Cloud SQL prend en charge la haute disponibilité (HA) et le réplica en lecture (RR), mais le même RR n'est pris en charge que dans une seule région. Après avoir créé une base de données dans la région américaine, vous ne pouvez pas créer de réplica en lecture dans la région européenne à l'aide de Cloud SQL, bien que Postgres lui-même ne vous empêche pas de le faire. La correspondance avec les employés de Google n'a abouti à rien et s'est terminée par des promesses du style "nous connaissons le problème et y travaillons, un jour le problème sera résolu".
Si nous énumérons brièvement les fonctionnalités de Cloud SQL, cela ressemblera à ceci :
1. Haute disponibilité (HA) :
- au sein d'une même région ;
- via la réplication de disque ;
- Les moteurs PostgreSQL ne sont pas utilisés ;
- contrôle automatique et manuel possible - failover/failback ;
- Lors du basculement, le SGBD est indisponible pendant plusieurs minutes.
2. Lire la réplique (RR) :
- au sein d'une même région ;
- pose chaude;
- Réplication en streaming PostgreSQL.
De plus, comme c'est l'habitude, lors du choix d'une technologie, vous êtes toujours confronté à certains limitations:
- le client ne souhaitait pas créer d'entités et utiliser IaaS, sauf via GKE ;
- le client ne souhaite pas déployer PostgreSQL/MySQL en libre-service ;
- Eh bien, en général, Google Spanner serait tout à fait approprié sans son prix, cependant, Django ORM ne peut pas fonctionner avec, mais c'est une bonne chose.
Compte tenu de la situation, le client a reçu une question complémentaire : « Pouvez-vous faire quelque chose de similaire pour que ce soit comme Google Spanner, mais qu'il fonctionne également avec Django ORM ? »
Option de solution n°0
La première chose qui me vient à l'esprit :
- restez dans CloudSQL ;
- il n'y aura aucune réplication intégrée entre les régions sous quelque forme que ce soit ;
- essayez d'attacher une réplique à un Cloud SQL existant par PostgreSQL ;
- lancez une instance PostgreSQL quelque part et d'une manière ou d'une autre, mais au moins ne touchez pas au maître.
Hélas, il s'est avéré que cela ne peut pas être fait, car il n'y a pas d'accès à l'hôte (c'est dans un projet complètement différent) - pg_hba et ainsi de suite, et il n'y a pas non plus d'accès sous superutilisateur.
Option de solution n°1
Après une réflexion plus approfondie et compte tenu des circonstances antérieures, la ligne de pensée a quelque peu changé :
- Nous essayons toujours de rester dans CloudSQL, mais nous passons à MySQL, car Cloud SQL by MySQL dispose d'un maître externe, qui :
— est un proxy pour MySQL externe ;
- ressemble à une instance MySQL ;
- inventé pour migrer des données depuis d'autres cloud ou sur site.
Étant donné que la configuration de la réplication MySQL ne nécessite pas d'accès à l'hôte, tout fonctionnait en principe, mais c'était très instable et peu pratique. Et quand nous sommes allés plus loin, c'est devenu complètement effrayant, car nous avons déployé toute la structure avec terraform, et tout à coup il s'est avéré que le maître externe n'était pas pris en charge par terraform. Oui, Google a une CLI, mais pour une raison quelconque, tout fonctionnait ici de temps en temps - parfois c'est créé, parfois ce n'est pas créé. Peut-être parce que la CLI a été inventée pour la migration de données externes, et non pour les répliques.
En fait, à ce stade, il est devenu clair que Cloud SQL n’était pas du tout adapté. Comme on dit, nous avons fait tout ce que nous pouvions.
Option de solution n°2
Comme il n'était pas possible de rester dans le cadre Cloud SQL, nous avons essayé de formuler des exigences pour une solution de compromis. Les exigences se sont avérées être les suivantes :
- travailler dans Kubernetes, utilisation maximale des ressources et capacités de Kubernetes (DCS, ...) et GCP (LB, ...);
- manque de lest dû à un tas de choses inutiles dans le cloud comme le proxy HA ;
- la possibilité d'exécuter PostgreSQL ou MySQL dans la région HA principale ; dans d'autres régions - HA du RR de la région principale plus sa copie (pour plus de fiabilité) ;
- multi master (je ne voulais pas le contacter, mais ce n'était pas très important)
.
À la suite de ces demandes, pSGBD et options de liaison appropriés:
- MySQL Galera ;
- CafardDB ;
- Outils PostgreSQL
:
- pgpool-II ;
— Patroni.
MySQL Galera
La technologie MySQL Galera a été développée par Codership et est un plugin pour InnoDB. Particularités :
- multi-maître ;
- réplication synchrone ;
- lecture à partir de n'importe quel nœud ;
- enregistrement sur n'importe quel nœud ;
- mécanisme HA intégré ;
- Il existe une carte Helm de Bitnami.
CockroachDB
D'après la description, la chose est absolument explosive et est un projet open source écrit en Go. Le principal participant est Cockroach Labs (fondé par des personnes de Google). Ce SGBD relationnel a été initialement conçu pour être distribué (avec une mise à l'échelle horizontale prête à l'emploi) et tolérant aux pannes. Ses auteurs de la société ont souligné l'objectif de « combiner la richesse des fonctionnalités SQL avec l'accessibilité horizontale familière aux solutions NoSQL ».
Un bonus intéressant est la prise en charge du protocole de connexion post-gress.
pgpool
Il s'agit d'un module complémentaire à PostgreSQL, en fait, une nouvelle entité qui reprend toutes les connexions et les traite. Il possède son propre équilibreur de charge et analyseur, sous licence BSD. Cela offre de nombreuses opportunités, mais semble quelque peu effrayant, car la présence d'une nouvelle entité pourrait devenir la source de quelques aventures supplémentaires.
patroni
C'est la dernière chose sur laquelle mes yeux se sont posés, et il s'est avéré que ce n'était pas en vain. Patroni est un utilitaire open source, qui est essentiellement un démon Python qui vous permet de maintenir automatiquement des clusters PostgreSQL avec différents types de réplication et de changement automatique de rôle. La chose s'est avérée très intéressante, car elle s'intègre bien au cuber et n'introduit aucune nouvelle entité.
Qu’as-tu choisi au final ?
Le choix n'a pas été facile :
- CockroachDB - du feu, mais sombre ;
- MySQL Galera - pas mal non plus, il est utilisé dans de nombreux endroits, mais MySQL ;
- pgpool — beaucoup d'entités inutiles, une intégration médiocre avec le cloud et les K8 ;
- patroni - excellente intégration avec K8, pas d'entités inutiles, s'intègre bien avec GCP LB.
Ainsi, le choix s'est porté sur Patroni.
résultats
Il est temps de résumer brièvement. Oui, le monde de l’infrastructure informatique a considérablement changé, et ce n’est que le début. Et si avant les nuages n’étaient qu’un autre type d’infrastructure, tout est désormais différent. De plus, des innovations dans les nuages apparaissent constamment, elles apparaîtront et, peut-être, elles n'apparaîtront que dans les nuages et alors seulement, grâce aux efforts des startups, elles seront transférées vers le On-premise.
Quant à SQL, SQL vivra. Cela signifie que vous devez connaître PostgreSQL et MySQL et être capable de travailler avec eux, mais il est encore plus important de pouvoir les utiliser correctement.
Source: habr.com