Base de données dans les nuages: à qui et pourquoi - l'avis des spécialistes de Data Egret

On pense que l'avenir est pour DB as Service. Cela vaut-il la peine pour tout le monde de déclencher un DBA et d'accéder à un cloud public ou de créer un cloud privé sur Docker avec Kubernetes? Trois experts de Data Egret - Alexei Lesovsky, Viktor Yegorov et Andrey Salnikov - sur la chaîne #RuPostgres ont partagé en direct leurs points de vue sur le type de projets auxquels les modèles de cloud sont adaptés.

Le modérateur et le modérateur de la discussion était Nikolay Samokhvalov, fondateur de Postgres.ai et co-fondateur de la communauté RuPostgres.org.



Sous la coupe - transcription de la conversation.

- Aujourd'hui, nous allons parler de Postgres dans les nuages. Et je vais commencer par une question délicate: est-il vrai que vous avez déjà plus de la moitié des clients dans les nuages?

Alexei: Je ne pense pas. Se sent comme moins de la moitié. Chacun est assis dans son propre centre de données ou loue des morceaux de fer.

Mais avant de parler des nuages, définissons les termes. Qu'entendons-nous par «nuages»: Amazon, Google Cloud, DB as Service?

- Je différencierais Postgres dans le cloud, préparé sur une instance Amazon EC2 (ou un analogue de Google), où vous pouvez, en gros, vous connecter via ssh et corriger la configuration, et Postgres sous contrôle (en anglais «managed»), lorsque l'accès direct au niveau du fichier ou pas de ssh, mais il n'y a que la possibilité de se connecter et d'exécuter des requêtes SQL. Ils devraient en principe être examinés séparément. Et ma première question concernait les Postgres gérés.

Alexei: Ces clients représentent nettement moins de la moitié.

Victor: Eh bien, dans le premier cas - quels avantages importants avons-nous du cloud? Quelle est la signification du cloud?

- Dans le premier cas, en utilisant divers outils modernes, tels que patroni et kubernetes (nous en parlerons séparément), vous pouvez obtenir de l'élasticité, des microservices et tout ça. Ce n'est pas la même chose qu'un simple morceau de fer. C'est comme «les animaux de compagnie contre le troupeau» - l'attitude envers le fer quand un animal de compagnie se développe en relation avec les machines virtuelles comme avec un troupeau. Vous ne savez pas déjà quel type de presse-étoupe y est installé. Vous ne les avez pas commandés, vous n'avez pas travaillé avec le fournisseur, vous n'avez pas réfléchi à la topologie. Vous pouvez gagner du temps.

Victor: Oui. À mon avis, le premier cas simplifie simplement le processus d'achat de fer neuf. Vous savez ce dont vous avez besoin: combien de cœurs et de RAM, quels lecteurs. Et vous choisissez une machine virtuelle parmi ce qu'ils vous proposent. C'est rapide. Mais sinon, vous devez toujours configurer et maintenir ce serveur normalement.

- Et que pensez-vous du surcoût ajouté par les machines virtuelles (aux processus à l'intérieur d'une machine virtuelle qui ne sont pas sur du bare metal, des surperformances ou des difficultés d'administration)? Avez-vous mesuré cela?

Alexei: Les frais généraux peuvent être mesurés si vous contrôlez l'hyperviseur. Dans les services publics, ce n'est pas le cas - ce qu'ils donnent, c'est ce que vous utilisez.

Les frais généraux des systèmes de virtualisation habituels qui peuvent être déployés à la maison (KVM, Xen), j'ai mesuré il y a cinq ans, puis il était d'environ 7 à 8%. De plus, cela dépendait des paramètres de la machine virtuelle et de la charge de travail. Par exemple, il y avait beaucoup plus de frais généraux sur Redis et Postgres que sur Unicorn, qui sert les backends de Rails.

Peut-être que maintenant les chiffres sont différents.

- Même 5-7% est un surcoût acceptable par rapport aux avantages dont Victor a parlé.

Et comment modifiez-vous la composition des clients: y a-t-il un mouvement vers des bases gérées?



Alexey: Non. La tendance est plutôt l'inverse. Les gens qui travaillent avec des choses comme RDS manquent de flexibilité pour administrer et gérer. En conséquence, nous obtenons la même attitude «comme aux animaux de compagnie», mais dans les cas EC2.

Victor: Cette situation se profile. Il y a des clients dont les principales bases de production sont très occupées. Naturellement, ils sont placés sur les pièces de fer allouées et sous surveillance constante. Mais lorsque l'entreprise se développe, le développement nécessite un grand nombre d'instances de test et de développement, et elles passent à la virtualisation. C'est-à-dire qu'il s'agit d'un cas hybride: sous des tests et des environnements de développement, du matériel peut être acheté ou des machines virtuelles peuvent être louées. Mais la production reste sur un matériel sérieux normal.

- Amazon RDS est-il utilisé pour cela?

Alexey: Nos clients, au contraire, refusent RDS. La raison, comme je l'ai dit, est le manque de flexibilité dans la gestion.

Les instances se bloquent et, dans certains cas, le problème n'est pas résolu uniquement en louant un morceau de fer plus puissant.

Vous ne pouvez pas résoudre vous-même de nombreux problèmes - uniquement avec l'aide de l'assistance.

- Est-il possible de donner des exemples? Il semblerait que récemment Amazon a acheté OpenSCG - des gars formidables qui auraient dû développer l'expertise interne de Postgres. Et je sais par ma propre expérience qu'il y a un examen. Si vous ouvrez un ticket avec la prise en charge d'Amazon RDS et que vous tombez sur une personne qui ne peut pas vous aider, fermez simplement le ticket et ouvrez-le à nouveau, pour en trouver un plus compétent.

Alexey: OpenSCG est, bien sûr, une équipe de professionnels. Mais acheter une telle équipe ne ferme pas 100% des situations possibles. Il y a des problèmes qui supportent les visages pour la première fois. Cela arrive aussi chez nous.

Sur ce dernier, sur l'une des répliques PostgreSQL 10.6, la charge moyenne du client sur l'hôte a soudainement augmenté de 30 à 40 unités, bien qu'il n'y ait pas de charge. Un tel coup souterrain incompréhensible. Cela n'affecte pas beaucoup, mais l'image même du rebond moyen de la charge est incompréhensible. Et elle agace les administrateurs du client. Nous avons quelques hypothèses, ce qui a provoqué cela, mais nous n'avons pas encore pu les tester, car le système est productif et tout ne peut pas être fait rapidement là-bas.

Et ces «coups clandestins» sortent environ une fois par an, et vous commencez à aborder la tâche de manière créative. Et Amazon RDS est un plus grand nombre d'instances, un plus grand nombre d'installations et de tickets, respectivement, et toutes sortes de situations sont beaucoup plus importantes.



Andrew: Je voudrais ajouter sur la comparaison des instances RDS et EC2.
Nous avions un client avec une production sur RDS. Il a demandé conseil. Dev-circuit était situé dans Microsoft Azure, apparemment, Azure était initialement considéré comme le principal service cloud.

J'ai fait glisser la base de circuits de développement d'Azure vers Amazon dans EC2 pour se rapprocher de la production, et les problèmes de prévision se sont rapprochés de la base de données des produits.

Bien que le serveur EC2 soit deux fois plus simple que sous les instances RDS et que la charge de test soit plus élevée que le produit, dans le circuit de développement après ma configuration, les résultats étaient bien meilleurs que dans Amazon sur l'instance RDS en production.

Je soupçonne qu'en raison du manque d'expertise PostgreSQL au sein de l'entreprise du client, RDS a été utilisé avec la configuration par défaut. Nous tordons tous les paramètres.

En conséquence, le client a été très impressionné. Je me suis tourné vers la direction avec une proposition au lieu de RDS pour prendre et configurer des instances simples.

- Au fait, comment a été mesuré, ce qui est mieux, ce qui est pire?

Andrew: Le client a examiné les paramètres de son application, la rapidité avec laquelle les données ont été téléchargées et traitées.

- Nous réprimandons maintenant RDS, mais il présente d'énormes avantages - il supprime beaucoup de maux de tête associés au déploiement, aux sauvegardes et à la réplication. Êtes-vous d'accord

Andrew: Oui. Et, très probablement, la principale raison pour laquelle le client est resté dans RDS était précisément le manque mentionné d'expertise PostgreSQL. Ils obtiennent tout ce dont ils ont besoin avec RDS, ils paient simplement plus pour les instances.

- En plus d'Amazon RDS, il existe d'autres postgres gérés basés sur le cloud. Avez-vous rencontré, par exemple, le service Yandex?

Andrei: Je suis tombé sur leurs machines virtuelles et je ne les aimais pas vraiment - les disques NVMe ne sont pas très honnêtes là-bas. En fait, il existe des disques connectés sur un réseau.

- Honest NVMe (disques locaux) est également un problème. Google et Amazon ont NVMe, mais les disques sont éphémères. Si vous redémarrez l'instance, vous perdez toutes les données car vous disposez d'une autre machine virtuelle.

Andrei: Ils ont commenté sur moi à Yandex Cloud qu'ils ont honnête NVMe dans DB en tant que service, mais je n'ai pas encore rencontré ce service. Apparemment, il existe une architecture légèrement différente au niveau de la fourniture des ressources.

Ils travaillent très dur sur DB en tant que service, car ils l'utilisent pour leurs services. C'est juste qu'il y a différents points d'entrée pour les clients externes et à usage interne.

- Et qu'en pensez-vous, y a-t-il des perspectives pour les Postgres russes dans le cloud? Va décoller ou ne pas décoller?

Andrew:

Yandex dispose d'une excellente équipe, assez expérimentée, avec une bonne expertise. Je pense qu'ils vont décoller.

Premièrement, ils exploitent eux-mêmes beaucoup de Postgres (plus de 1000 bases de données sur leurs projets), et depuis exploiter, tous les cônes et les points douloureux fonctionneront et se répareront plus rapidement. Je pense que le client recevra un service final d'assez bonne qualité.

Et il existe une demande pour de telles solutions. Prenez une startup qui au début ne peut pas avoir l'expertise nécessaire en Postgres pour diverses raisons: chères, elles ne voient pas l'intérêt, essayez différentes technologies. Pour lui, c'est une bonne solution, car dans ces services, il y a des «rebondissements» limités qui ne devraient pas être déformés, et si cela, je pense, il y aura un support technique.

Certes, Yandex Cloud est encore au début, et peu de fonctionnalités sont présentées pour le moment.

- Nous avons des questions de la salle de chat: que pensez-vous du fait que lors de l'émission de machines virtuelles, quelqu'un peut physiquement s'asseoir sur cette machine (limitation, vol de temps).



Victor: Oui, il y a une telle expérience. Je voulais juste le mentionner. Certains clients ont déployé leurs propres systèmes de virtualisation. De temps en temps, ils demandent à voir un serveur non-produit, et nous voyons une situation incompréhensible: nous n'observons pas les raisons pour lesquelles il devrait se casser sur ce serveur. Ensuite, nous redirigeons les questions vers leurs administrateurs avec une demande pour voir ce qui se passe sur l'hôte.

- Et que faire, y a-t-il un effet similaire sur Amazon? Existe-t-il des méthodes pour déterminer que vous êtes «coincé»? pgbench pour conduire?

Alexei: Je ne m'en souviens pas. Mais la manière habituelle est de déterminer le temps de vol. Sur les graphiques de surveillance, en règle générale, nous ne voyons pas de grandes valeurs.

- Je pense que vous n'aimez pas vraiment Postgres géré. Est-ce dû au fait que RDS prend votre travail?

Alexey: Non. Cela est probablement dû au fait que nous ne l'avons tout simplement pas. Managed Postgres est bon car vous pouvez déployer l'infrastructure en un clic. Tant que vous êtes une startup et que vous ajoutez ou lisez simplement des données sans logique complexe, tout va bien. Et lorsque vous franchissez une certaine ligne, par exemple, vous commencez à exécuter un grand nombre de JOIN, faites du SQL complexe, la tâche se pose pour optimiser les requêtes et RDS cesse d'être suffisant. Cela prend plus de liberté et d'influence, mais les outils disponibles ne vous aident pas à résoudre les problèmes profonds associés à la cession des ressources au sein même de Postgres. Il n'y a que l'occasion d'augmenter la puissance du morceau de fer: payé plus d'argent - reçu.

Andrew: Il n'y a pas tellement d'aversion pour RDS et de peur pour le travail. Le problème est différent. Supposons qu'une startup prenne RDS, il leur donne tout. Mais il n'a pas augmenté son expertise dans Postgres. Ensuite, disons une photo de démarrage. Les charges augmentent - l'écriture et la lecture ont augmenté. En l'absence de son expertise, une startup doit chercher des personnes de côté. Les DBA sévères viennent voir qu'ils ne peuvent plus tirer parti du RDS, mais à partir d'une instance EC2 régulière, il est tout à fait possible d'obtenir plus de performances, comme dans l'exemple que j'ai mentionné plus tôt. Si nous étions autorisés sur RDS, nous pourrions peut-être modifier et améliorer la base de données, mais nous ne l'avons pas fait.

- Le problème d'accès est en cours de résolution. Il existe des Postgres gérés qui fournissent un accès ssh (et même complètement root), par exemple une petite entreprise finlandaise Aiven. Par défaut, ils ne donnent pas d'accès root, mais le fondateur (et je lui ai parlé plusieurs fois) a parlé de sa volonté d'accorder l'accès sur demande.

Andrew: Le problème n'est pas seulement l'accès. Pourquoi sommes-nous mieux avec des glandes pures? Parce que nous avons beaucoup de clients différents et chacun a sa propre infrastructure. Et les infrastructures sont si éloignées que la méthodologie générale qui fonctionne de la même manière partout, nous ne pouvons tout simplement pas. Parce qu'il y a ceux qui ont leur propre matériel, et ils ne peuvent tout simplement pas héberger quelque part (selon certaines de leurs propres règles et restrictions), et il y a ceux qui sont dans les nuages.

- Vous voulez dire que la définition des index non utilisés dépend du morceau de fer? Ou d'autres choses banales?

Andrew: Du point de vue de l'administration, c'est le schéma de la base de données et la définition des index non utilisés que les clouds ne sont pas différents de leur matériel. Tout est unifié.

La différence entre un cloud et un véritable matériel - dans la couche entre la base et spécifiquement le matériel qui se trouve en dessous - est le système d'exploitation et les virtualisations utilisées. Lorsque vous avez de grandes bases de données, il est important pour vous de savoir à quelle vitesse les disques envoient et reçoivent des données, à quel point la mémoire et le processeur sont utilisés efficacement, il est donc extrêmement important de réduire l'influence de cette couche afin que la base de données fonctionne plus efficacement.

- Une autre question du public: qu'en est-il des paramètres du noyau?

Victor: Dans EC2, ces choses sont personnalisables.

- Il existe de nouvelles solutions pour la classe "Postgres gérés" de fournisseurs bien connus, en plus d'Amazon et de Google. Par exemple, Nutanix et SAP ont annoncé en 2018 la création de solutions basées sur Postgres. Ne pensez-vous pas que tous ces gars nous conduisent à l'émergence de certaines décisions qui feront de même, mais uniquement sur votre morceau de fer? Pour que vous puissiez cliquer sur le bouton et déployer le nouveau Postgres, où les sauvegardes et la réplication sont déjà configurées.

Alexei: Il me semble que SAP et d'autres ne sont pas entièrement rentables. Ce sont de grands fournisseurs de fer et de logiciels. Ils fabriquent un produit dans le but de gagner de l'argent. Vendez du support au moins. Par conséquent, nous devons voir comment ils en profiteront. Si un tel modèle de livraison de produits leur est bénéfique, pourquoi pas?

- Je voulais dire un peu différent. Plus précisément, ces gars-là ne publieront rien en open source et donneront gratuitement. Mais ne pensez-vous pas que quelqu'un du plus petit, mais fringant fera quelque chose comme ça? Peut-être que cela se concentrera sur Kubernetes, Operator Framework. Il y a déjà quelques développements que les opérateurs font - Zalando, par exemple. Et ne pensez-vous pas que le RDS basé sur le cloud facilite une transition progressive vers de telles solutions? Nous voyons comment vous pouvez vivre sans grimper dans les configs avec vos mains.

Alexey: Il s'avère que ce n'est pas tout à fait réussi.

Vous aurez tout de même besoin de spécialistes qui surveilleront tout cela et grimperont sous le capot en cas de problème.

Même le très Kubernetes est une machine très complexe, avec de nombreux composants sous le capot. Formellement, ce ne sont que cinq binaires. Mais leur interaction les uns avec les autres est décrite par des volumes de documentation et de nombreuses informations sur les forums de discussion, les newsletters et les groupes Google. C'est-à-dire vous avez toujours besoin d'un spécialiste qui suivra cette cuisine.

De plus, tout cela se développe de manière très dynamique. La compatibilité descendante passe de version en version. C'est-à-dire tout est très instable et instable. Lorsque tout se calme, nous obtiendrons peut-être un produit adapté, stable et fiable. Mais jusqu'à présent, tout n'est pas très.

Victor: Nous commençons à parler du fait que nous avons une couche supplémentaire d'infrastructure qui doit être gérée - pour orchestrer ce Kubernetes.

Je ne suis pas d'accord pour dire qu'il fonctionnera toujours comme par magie d'un simple clic sur un bouton. Il est nécessaire de garder des spécialistes compétents.

Et le second - nos clients s'adaptent constamment aux changements commerciaux. En conséquence, la charge dans la base de données change constamment. Et si nous avons tout léché il y a trois mois, à la suite de quoi toutes les demandes ont fonctionné comme prévu, et tout s'est bien passé, une nouvelle demande peut arriver aujourd'hui ou demain, ou en raison de modifications des données, la demande existante cessera de fonctionner comme il se doit. Et nous devons analyser la situation et entrer dans les paramètres du système. Et c'est cette automatisation qui, me semble-t-il, rend ces instances gérées très difficiles. Lorsque les nuages ​​atteignent un état tel qu'ils s'adapteront également à de telles situations, je ne sais pas. Mais bien que ce soit une partie importante du travail qui doit être fait, il est nécessaire d'adapter les paramètres de la base de données aux changements dans le modèle des demandes entrantes.

Et comme le cloud lui-même est une charge administrative supplémentaire, il est plus facile pour nous lorsque cette couche n’est tout simplement pas là, car nous pouvons nous concentrer sur les problèmes de la base de données.

Si le client veut vivre dans le cloud et possède l'expertise, nous n'avons rien contre. L'essentiel est que nous ayons la possibilité, lorsque la base de données n'est pas très bonne, de grimper (de préférence par ssh), de tout vérifier et d'avoir accès à toutes les statistiques.

Alexey: Pas nécessairement par ssh. Mais dans tous les cas, des outils de diagnostic sont nécessaires. Parce que le diagnostic par email est très long et fastidieux. C'est ennuyeux lorsque vous envoyez un lien de discussion vers une demande à exécuter, le client, en revanche, clique sur ce lien, copie la demande, puis vous copie le résultat ou vous envoie une capture d'écran. C'est tout le temps.

Il est beaucoup plus facile de se connecter et de voir directement, de tester certaines de vos hypothèses et d'agir plus loin.

- Avez-vous des exemples actifs où Kubernetes est déjà utilisé et où Postgres y réside?

Alexei: Malheureusement, non. Mais j'aimerais vraiment. J'aime beaucoup Kubernetes, je suis proche de son concept et de sa philosophie.

À mon avis, Kubernetes est une chose qui encourage les gens à programmer davantage, à créer un produit plus, sans penser à des choses secondaires comme la structure interne de l'infrastructure.

Un rôle similaire était auparavant joué par la POO. Il est apparu et beaucoup de gens se sont intéressés à ce domaine, car la programmation est devenue un peu plus facile. Kubernetes ferme également beaucoup de choses sur lui-même, les cache sous le capot et permet à une personne de se concentrer sur l'aspect créatif et de programmer davantage.

Kubernetes implémente la prise en charge des instances, des foyers et des applications. S'il se bloque soudainement - eh bien, Kubernetes le relancera. C'est-à-dire le développeur et l'administrateur sont exempts de maux de tête et d'un suivi constant. J'aime cette réponse à la situation. Quand quelque chose tombe, il redémarre automatiquement.

, , . — , , . .

– , ?

: , . , . - , . , , Kubernetes. Kubernetes . CNCF . , .

– - kubernetes_ru. github, Kubernetes: . Postgres, .

, , , . , Kubernetes – , . - IT.

– , Amazon Aurora PostgreSQL Serverless ? , , . , . .. .

:

. .

, . , , . : , . , - . .

– . . , , .

: . , . , , – . , , , , .

C'est-à-dire . – , , 70% . . .

, , « », .

– . , , DBA : - , - — , ?

: , , , – DBA, SQL-developer. Oracle SQL-developer, , , , . , Oracle. . DBA , - .

DBA — - «» , .

Kubernetes. , . . , Kubernetes . , volume . C'est-à-dire , . , .

– ?

: .

, . , , . , Postgres ( ). Postgres - . C'est-à-dire (, ), .

, .

, , . . . .

– ?

: - . , , .

, Cassandra. . C'est-à-dire — , Kubernetes.

, , . , , .

C'est-à-dire . DBA, , – . , , - – .

– ?

: . , . , , , Kubernetes . , , , , - - Kubernetes ( ).

: Kubernetes. – patroni. Zalando Kubernetes. , , ( – , Amazon , ). , – . , – . – - Kubernetes.

– RDS. EC2 Postgres . patroni ( https://github.com/zalando/patroni ), .

: , , - high availability.

– . — , ?

: , - .
Zalando DBA, patroni. C'est-à-dire , Kubernetes , DBA .

– . DBA, DBA «» «».

: , . . , , .

– - Kubernetes? ?

: - , . Kubernetes – , . Kubernetes - . . DBA. Kubernetes (, Kubernetes , , ).

- , , - - -.

: ( Kubernetes ), - . , — — . - , , , , , , .

:

. Kubernetes , . , . .

, — . , Postgres- , , . .

: …

– .. : - — dev environment, production – Kubernetes. ...

: latency , , . .

– , . .
, Petersburg HighLoad ++ .

PS Une vidéo complète de la conversation peut être trouvée ici .