{"id":92806,"date":"2020-08-31T07:42:03","date_gmt":"2020-08-31T05:42:03","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-perestat-bespokoitsya-i-nachat-zhit-bez-monolita"},"modified":"2020-08-31T07:42:03","modified_gmt":"2020-08-31T05:42:03","slug":"kak-perestat-bespokoitsya-i-nachat-zhit-bez-monolita","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/kak-perestat-bespokoitsya-i-nachat-zhit-bez-monolita","title":{"rendered":"Comment arr\u00eater de s'inqui\u00e9ter et commencer \u00e0 vivre sans monolithe","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Comment
\n
\nNous aimons tous les histoires. Nous aimons nous asseoir autour du feu et raconter nos anciennes victoires, combats ou simplement partager notre exp\u00e9rience professionnelle.<\/p>\n

Aujourd'hui est pr\u00e9cis\u00e9ment un de ces jours. M\u00eame si vous n'\u00eates pas autour d'un feu, nous avons une histoire pour vous. L'histoire de la fa\u00e7on dont nous avons commenc\u00e9 \u00e0 travailler avec le stockage sur Tarantool.<\/p>\n

Il \u00e9tait une fois, dans notre entreprise, quelques \u00ab monolithes \u00bb et un \u00ab plafond \u00bb commun qui approchait lentement mais s\u00fbrement ces monolithes, limitant l'essor de notre entreprise, notre d\u00e9veloppement. Nous avions une compr\u00e9hension claire : un jour, nous nous heurterions violemment \u00e0 ce plafond.
\n<\/a><\/noindex>
\nAujourd'hui, l'id\u00e9e de diviser tout et n'importe quoi pr\u00e9vaut, de l'\u00e9quipement \u00e0 la logique m\u00e9tier. Par cons\u00e9quent, nous avons, par exemple, deux centres de donn\u00e9es pratiquement ind\u00e9pendants au niveau r\u00e9seau. \u00c0 l'\u00e9poque, tout \u00e9tait compl\u00e8tement diff\u00e9rent.<\/p>\n

De nos jours, il existe un tas d'outils et de moyens pour apporter des modifications sous la forme de CI\/CD, K8S, etc. \u00c0 l'\u00e9poque \u00ab monolithique \u00bb, nous n'avions pas besoin de tant de mots \u00e9trangers. Il suffisait de modifier simplement la \u00ab petite base \u00bb dans la base de donn\u00e9es.<\/p>\n

Mais le temps avan\u00e7ait, et le nombre de requ\u00eates augmentait avec lui, atteignant parfois des RPS au-del\u00e0 de nos capacit\u00e9s. Lorsque nous sommes entr\u00e9s sur le march\u00e9 des pays de la CEI, la charge sur le processeur de la base de donn\u00e9es du premier monolithe ne descendait pas en dessous de 90 %, tandis que les RPS se maintenaient autour de 2400. Et ce n'\u00e9taient pas de simples requ\u00eates, mais de grosses requ\u00eates avec de nombreuses v\u00e9rifications et JOINs, qui pouvaient parcourir presque la moiti\u00e9 des donn\u00e9es dans un grand I\/O.<\/p>\n

Quand de vraies promotions ont commenc\u00e9 \u00e0 appara\u00eetre pour le \u00ab Black Friday \u00bb, et que Wildberries a \u00e9t\u00e9 parmi les premiers \u00e0 les organiser en Russie, la situation est devenue tr\u00e8s pr\u00e9occupante. En effet, la charge triple ces jours-l\u00e0.
\nOh, ces \u00ab temps monolithiques \u00bb ! Je suis s\u00fbr que vous avez \u00e9galement \u00e9t\u00e9 confront\u00e9 \u00e0 cela, et que vous ne comprenez toujours pas comment cela a pu vous arriver.<\/p>\n

Que peut-on y faire ? La mode touche aussi les technologies. Il y a cinq ans, nous avons d\u00fb repenser l'une de ces modes sous la forme d'un site existant bas\u00e9 sur .NET et MS SQL Server, qui stockait pr\u00e9cieusement toute la logique de fonctionnement du site. Si pr\u00e9cieusement, qu'il s'est av\u00e9r\u00e9 long et assez compliqu\u00e9 de d\u00e9chirer un tel monolithe.
\nPetite digression. <\/p>\n

Lors de divers \u00e9v\u00e9nements, je dis : \u00ab si vous n'avez pas d\u00e9coup\u00e9 le monolithe, cela signifie que vous ne vous \u00eates pas d\u00e9velopp\u00e9 ! \u00bb J'aimerais conna\u00eetre votre avis \u00e0 ce sujet, merci de le partager dans les commentaires.<\/p>\n

Et le tonnerre retentit<\/h3>\n

\nRevenons \u00e0 notre \u00ab feu de camp \u00bb. Pour r\u00e9partir la charge de la fonctionnalit\u00e9 \u00ab monolithique \u00bb, nous avons d\u00e9cid\u00e9 de diviser le syst\u00e8me en microservices bas\u00e9s sur des technologies opensource. Parce que, au minimum, leur mise \u00e0 l'\u00e9chelle est moins co\u00fbteuse. Et nous \u00e9tions pleinement conscients qu'il nous faudrait les faire \u00e9voluer (et pas qu'un peu). En effet, \u00e0 ce moment-l\u00e0, nous avions d\u00e9j\u00e0 r\u00e9ussi \u00e0 entrer sur les march\u00e9s des pays voisins, et le nombre d'inscriptions, tout comme le nombre de commandes, a commenc\u00e9 \u00e0 cro\u00eetre encore plus.<\/p>\n

En analysant les premiers candidats pour passer du monolithe aux microservices, nous avons compris que 80 % des \u00e9critures dans ces syst\u00e8mes provenaient \u00e0 99 % des syst\u00e8mes back office, tandis que les lectures venaient du front office. Cela concernait principalement deux sous-syst\u00e8mes importants pour nous : les donn\u00e9es utilisateur et le syst\u00e8me de calcul du prix final des produits en fonction des informations sur les remises et coupons suppl\u00e9mentaires pour les clients.<\/p>\n

Pour transitionner. Il est difficile de l'imaginer maintenant, mais en plus des sous-syst\u00e8mes mentionn\u00e9s ci-dessus, nos catalogues de produits, le panier utilisateur, le syst\u00e8me de recherche de produits, le syst\u00e8me de filtrage des catalogues de produits et divers syst\u00e8mes de recommandation ont \u00e9galement \u00e9t\u00e9 extraits de notre monolithe. Chacun d'eux a ses propres classes de syst\u00e8mes sp\u00e9cialis\u00e9s, mais autrefois, tous vivaient dans une m\u00eame \u00ab maison \u00bb. <\/p>\n

Nous avons imm\u00e9diatement pr\u00e9vu d'extraire les donn\u00e9es sur nos clients vers un syst\u00e8me de sharding. L'extraction des fonctionnalit\u00e9s pour le calcul du prix final des produits n\u00e9cessitait une bonne scalabilit\u00e9 pour les lectures, car elle cr\u00e9ait la plus grande charge en termes de RPS et \u00e9tait la plus complexe \u00e0 r\u00e9aliser pour la base de donn\u00e9es (beaucoup de donn\u00e9es sont impliqu\u00e9es dans le processus de calcul). <\/p>\n

C'est ainsi qu'est n\u00e9e notre architecture, bien adapt\u00e9e \u00e0 Tarantool.<\/p>\n

\u00c0 l'\u00e9poque, pour faire fonctionner les microservices, nous avons choisi des sch\u00e9mas d'op\u00e9ration avec plusieurs centres de donn\u00e9es sur des machines virtuelles et physiques. Comme illustr\u00e9 dans les images, des variantes de r\u00e9plication Tarantool ont \u00e9t\u00e9 appliqu\u00e9es \u00e0 la fois en mode master-master et master-slave. <\/p>\n

\"Comment
\nArchitecture. Option 1. Service des utilisateurs<\/i><\/p>\n

\u00c0 l'heure actuelle, il y a 24 shards, chacun avec 2 instances (une par centre de donn\u00e9es), toutes en mode master-master.<\/p>\n

Au-dessus de la base de donn\u00e9es se trouvent des applications qui acc\u00e8dent aux r\u00e9pliques de base de donn\u00e9es. Les applications interagissent avec Tarantool via notre biblioth\u00e8que personnalis\u00e9e, qui impl\u00e9mente l'interface du pilote Go pour Tarantool. Elle d\u00e9tecte toutes les r\u00e9pliques et peut travailler avec le ma\u00eetre en lecture et \u00e9criture. Essentiellement, elle met en \u0153uvre un mod\u00e8le de jeu de r\u00e9pliques, dans lequel la logique de s\u00e9lection des r\u00e9pliques, la gestion des nouvelles tentatives, le circuit breaker et le rate limit ont \u00e9t\u00e9 ajout\u00e9s.<\/p>\n

Il est possible de configurer la politique de s\u00e9lection des r\u00e9pliques au niveau du shard. Par exemple, en utilisant un round robin.<\/p>\n

\"Comment
\nArchitecture. Variante 2. Service de calcul du co\u00fbt final d'un produit.<\/i><\/p>\n

Il y a quelques mois, la majorit\u00e9 des demandes concernant le calcul du co\u00fbt final des produits ont \u00e9t\u00e9 transf\u00e9r\u00e9es vers un nouveau service qui fonctionne sans base de donn\u00e9es. Cependant, auparavant, 100 % du traitement \u00e9tait effectu\u00e9 par un service avec Tarantool en arri\u00e8re-plan.<\/p>\n

La base de donn\u00e9es du service consiste en 4 ma\u00eetres, dans lesquels un synchronisateur collecte les donn\u00e9es, et chacun de ces ma\u00eetres distribue les donn\u00e9es \u00e0 des r\u00e9pliques en lecture seule par r\u00e9plication. Chaque ma\u00eetre a environ 15 de ces r\u00e9pliques.<\/p>\n

Dans les deux sch\u00e9mas, en cas d'indisponibilit\u00e9 d'un centre de donn\u00e9es, l'application peut obtenir des donn\u00e9es \u00e0 partir du second.<\/p>\n

Il convient de noter que dans Tarantool, la r\u00e9plication est assez flexible et peut \u00eatre configur\u00e9e en temps r\u00e9el. Dans d'autres syst\u00e8mes, des difficult\u00e9s peuvent survenir. Par exemple, le changement des param\u00e8tres max_wal_senders et max_replication_slots dans PostgreSQL n\u00e9cessite un red\u00e9marrage du ma\u00eetre, ce qui peut parfois entra\u00eener une rupture des connexions entre l'application et le SGBD.<\/p>\n

Cherchez et vous trouverez !<\/h3>\n

\nPourquoi n'avons-nous pas fait \u00ab comme les gens normaux \u00bb, mais avons choisi une m\u00e9thode atypique ? Tout d\u00e9pend de ce que l'on consid\u00e8re comme normal. Beaucoup de gens mettent en place un cluster Mongo et le r\u00e9partissent sur trois centres de donn\u00e9es g\u00e9ographiquement distribu\u00e9s.<\/p>\n

\u00c0 l'\u00e9poque, nous avions d\u00e9j\u00e0 deux projets sur Redis. Le premier \u00e9tait un cache, et le second \u00e9tait un stockage persistant pour des donn\u00e9es pas trop critiques. Avec ce dernier, il \u00e9tait assez difficile de travailler, en partie \u00e0 notre faute. Parfois, des volumes assez importants restaient dans la cl\u00e9, et de temps en temps, le site devenait lent. Nous avons utilis\u00e9 ce syst\u00e8me en mode ma\u00eetre-esclave. Et il y a eu de nombreux cas o\u00f9 quelque chose se passait avec le ma\u00eetre et que la r\u00e9plication \u00e9chouait. <\/p>\n

Cela signifie que Redis est bon pour des t\u00e2ches stateless, et non pour des t\u00e2ches stateful. En principe, il permettait de r\u00e9soudre la plupart des probl\u00e8mes, mais uniquement s'il s'agissait de solutions key-value avec quelques index. Cependant, \u00e0 ce moment-l\u00e0, Redis avait des probl\u00e8mes de persistance et de r\u00e9plication. De plus, des plaintes ont \u00e9t\u00e9 formul\u00e9es concernant ses performances.<\/p>\n

Nous avons envisag\u00e9 MySQL et PostgreSQL. Mais le premier ne s'est pas vraiment implant\u00e9 chez nous, et le deuxi\u00e8me est en soi un produit plut\u00f4t complexe, il serait donc peu judicieux d'y construire des services simples.
\nNous avons essay\u00e9 RIAK, Cassandra, et m\u00eame une base de donn\u00e9es graphique. Tout cela repr\u00e9sente des solutions assez de niche qui ne conviennent pas comme un outil universel g\u00e9n\u00e9ral pour cr\u00e9er des services.<\/p>\n

En fin de compte, nous nous sommes arr\u00eat\u00e9s sur Tarantool.<\/p>\n

Nous nous y sommes int\u00e9ress\u00e9s lorsqu'il \u00e9tait \u00e0 la version 1.6. Nous avons \u00e9t\u00e9 s\u00e9duits par le m\u00e9lange de key-value et des fonctionnalit\u00e9s d'une base de donn\u00e9es relationnelle. Il dispose d'index secondaires, de transactions et de spaces, qui sont comme des tables, mais pas simples, car il est possible d'y stocker un nombre variable de colonnes. Mais la fonctionnalit\u00e9 centrale de Tarantool \u00e9tait les index secondaires combin\u00e9s avec le key-value et la capacit\u00e9 de transaction.<\/p>\n

La communaut\u00e9 russophone r\u00e9active, pr\u00eate \u00e0 aider dans le chat, a \u00e9galement jou\u00e9 un r\u00f4le. Nous en avons profit\u00e9 activement et avons vraiment v\u00e9cu dans le chat. Et il ne faut pas oublier la bonne persistance sans d\u00e9fauts ni erreurs \u00e9vidents. Si l'on regarde notre histoire avec Tarantool, nous avons eu beaucoup de douleurs et de faux pas avec la r\u00e9plication, mais nous n'avons jamais perdu de donn\u00e9es \u00e0 cause de lui !<\/p>\n

L'impl\u00e9mentation a d\u00e9but\u00e9 difficilement.<\/h3>\n

\n\u00c0 l'\u00e9poque, notre stack de d\u00e9veloppement principal \u00e9tait .NET, pour lequel il n'y avait pas de connecteur pour Tarantool. Nous avons imm\u00e9diatement commenc\u00e9 \u00e0 travailler en Go. Avec Lua, c'\u00e9tait \u00e9galement assez bon. Le principal probl\u00e8me \u00e0 ce moment-l\u00e0 \u00e9tait le d\u00e9bogage : avec .NET, tout est parfait, mais ensuite plonger dans le monde de Lua embarqu\u00e9, avec seulement des logs et aucun d\u00e9bogage, \u00e9tait difficile. De plus, la r\u00e9plication \u00e9chouait parfois, il a donc fallu se plonger dans la structure du moteur Tarantool. Le chat a \u00e9t\u00e9 utile, dans une moindre mesure la documentation, et parfois nous avons consult\u00e9 le code. \u00c0 cette \u00e9poque, la documentation \u00e9tait assez m\u00e9diocre.<\/p>\n

Ainsi, pendant plusieurs mois, nous avons r\u00e9ussi \u00e0 accumuler de l'exp\u00e9rience et \u00e0 obtenir des r\u00e9sultats satisfaisants avec Tarantool. Nous avons organis\u00e9 dans git des travaux de r\u00e9f\u00e9rence qui ont aid\u00e9 \u00e0 la cr\u00e9ation de nouveaux microservices. Par exemple, lorsqu'il s'agissait de cr\u00e9er un nouveau microservice, le d\u00e9veloppeur se r\u00e9f\u00e9rerait aux sources de la solution de r\u00e9f\u00e9rence dans le d\u00e9p\u00f4t, et la cr\u00e9ation d'un nouveau ne prenait pas plus d'une semaine. <\/p>\n

C'\u00e9taient des temps particuliers. On pouvait, par exemple, s'approcher de l'administrateur au bureau voisin et demander : \u00ab Donne-moi une machine virtuelle \u00bb. Environ trente minutes plus tard, la machine \u00e9tait d\u00e9j\u00e0 \u00e0 toi. Tu te connectais, tu installais tout, et on te redirigeait le trafic.<\/p>\n

Aujourd'hui, cela ne fonctionne plus ainsi : il faut installer un syst\u00e8me de surveillance pour le service, tenir un journal, couvrir les fonctionnalit\u00e9s avec des tests, commander une machine virtuelle ou une installation dans Kubernetes, etc. En g\u00e9n\u00e9ral, cela sera mieux, m\u00eame si c'est plus long et plus compliqu\u00e9.<\/p>\n

Diviser pour r\u00e9gner. Comment \u00e7a se passe avec Lua ?<\/h3>\n

\nIl y avait un dilemme s\u00e9rieux : certaines \u00e9quipes ne parvenaient pas \u00e0 d\u00e9ployer des modifications de mani\u00e8re fiable dans un service avec beaucoup de logique en Lua. Souvent, cela \u00e9tait accompagn\u00e9 d'une non-fonctionnalit\u00e9 du service. <\/p>\n

C'est-\u00e0-dire que les d\u00e9veloppeurs pr\u00e9parent une modification. Tarantool commence \u00e0 effectuer une migration, tandis que la r\u00e9plique a encore l'ancien code ; un DDL arrive par r\u00e9plication, quelque chose d'autre, et le code s'effondre simplement parce que cela n'est pas pris en compte. En cons\u00e9quence, la proc\u00e9dure de mise \u00e0 jour des administrateurs \u00e9tait not\u00e9e sur une feuille A4 : arr\u00eater la r\u00e9plication, mettre \u00e0 jour cela, relancer la r\u00e9plication, d\u00e9connecter ici, mettre \u00e0 jour l\u00e0. Un vrai cauchemar ! <\/p>\n

En fin de compte, nous essayons le plus souvent de ne rien faire en Lua. Simplement via iproto (protocole binaire pour interagir avec le serveur), et c'est tout. C'est peut-\u00eatre un manque de connaissances des d\u00e9veloppeurs, mais de ce point de vue, le syst\u00e8me est complexe.<\/p>\n

Nous ne suivons pas toujours ce sc\u00e9nario \u00e0 la lettre. Aujourd'hui, nous n'avons pas de noir et de blanc : soit tout en Lua, soit tout en Go. Nous comprenons d\u00e9j\u00e0 comment combiner les deux pour ne pas rencontrer de probl\u00e8mes de migration ensuite.<\/p>\n

O\u00f9 trouve-t-on maintenant Tarantool ?
\nTarantool est utilis\u00e9 dans le service de calcul du prix final des produits en tenant compte des coupons de r\u00e9duction, connu sous le nom de \u00abPromoteur\u00bb. Comme mentionn\u00e9 pr\u00e9c\u00e9demment, il est maintenant sur le point d'\u00eatre remplac\u00e9 : un nouveau service de catalogue avec des prix pr\u00e9-calcul\u00e9s prend le relais, mais il y a encore six mois, tous les calculs \u00e9taient effectu\u00e9s dans le \u00abPromoteur\u00bb. Auparavant, la moiti\u00e9 de sa logique \u00e9tait \u00e9crite en Lua. Il y a deux ans, le service a \u00e9t\u00e9 transform\u00e9 en stockage, et la logique a \u00e9t\u00e9 r\u00e9\u00e9crite en Go, car la m\u00e9canique des remises a l\u00e9g\u00e8rement chang\u00e9 et le service manquait de performance. <\/p>\n

L'un des services les plus critiques est le profil utilisateur. Cela signifie que tous les utilisateurs de Wildberries sont stock\u00e9s dans Tarantool, et ils sont environ 50 millions. Syst\u00e8me partitionn\u00e9 par ID utilisateur, r\u00e9parti sur plusieurs centres de donn\u00e9es avec des int\u00e9grations sur des services Go.
\nAuparavant, le \u00abPromoteur\u00bb \u00e9tait le leader en RPS, atteignant jusqu'\u00e0 6000 requ\u00eates. \u00c0 un moment donn\u00e9, nous avions 50-60 instances. Actuellement, le leader en RPS est le profil utilisateur, avec environ 12000 requ\u00eates. Ce service utilise un sharding personnalis\u00e9 avec une r\u00e9partition par plages d'ID utilisateur. Il g\u00e8re plus de 20 machines, mais c'est trop, nous pr\u00e9voyons de r\u00e9duire les ressources allou\u00e9es, car 4-5 machines suffisent.<\/p>\n

Le service de sessions est notre premier service sur vshard et Cartridge. La configuration de vshard et la mise \u00e0 jour de Cartridge ont n\u00e9cessit\u00e9 un certain investissement en temps, mais au final, tout a fonctionn\u00e9.<\/p>\n

Le service pour l'affichage de diff\u00e9rentes banni\u00e8res sur le site et dans l'application mobile \u00e9tait l'un des premiers \u00e0 sortir directement sur Tarantool. Ce service est remarquable car il a environ 6-7 ans, il est toujours en service et n'a jamais \u00e9t\u00e9 red\u00e9marr\u00e9. Une r\u00e9plication master-master a \u00e9t\u00e9 utilis\u00e9e. Rien ne s'est jamais cass\u00e9.<\/p>\n

Il existe un exemple d'utilisation de Tarantool pour la fonctionnalit\u00e9 de r\u00e9pertoires rapides dans le syst\u00e8me d'entrep\u00f4t, afin de v\u00e9rifier rapidement certaines informations. Nous avons essay\u00e9 d'utiliser Redis pour cela, mais les donn\u00e9es en m\u00e9moire prenaient plus de place que dans Tarantool.<\/p>\n

Les services de file d'attente, d'abonnements clients, de stories tendance et de produits en attente fonctionnent \u00e9galement avec Tarantool. Le dernier service occupe environ 120 Go en m\u00e9moire. C'est le service le plus volumineux parmi ceux mentionn\u00e9s. <\/p>\n

Conclusion<\/h3>\n

\nGr\u00e2ce aux index secondaires combin\u00e9s avec le key-value et la gestion des transactions, Tarantool est id\u00e9al pour les architectures bas\u00e9es sur des microservices. Cependant, nous avons rencontr\u00e9 des difficult\u00e9s lors du d\u00e9ploiement de modifications dans des services contenant une logique complexe en Lua : ces services cessaient souvent de fonctionner. Nous n'avons pas r\u00e9ussi \u00e0 surmonter ce probl\u00e8me et avec le temps, nous avons trouv\u00e9 diff\u00e9rentes combinaisons de Lua et de Go : nous savons o\u00f9 il convient d'utiliser l'un ou l'autre langage.<\/p>\n

Suggestions de lecture suppl\u00e9mentaires<\/b><\/p>\n