{"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\/da\/blog\/administrirovanie\/kak-perestat-bespokoitsya-i-nachat-zhit-bez-monolita","title":{"rendered":"S\u00e5dan stopper du med at bekymre dig og begynder at leve uden monolitten","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"S\u00e5dan
\n
\nVi elsker alle historier. Vi kan godt lide at sidde rundt om b\u00e5let og fort\u00e6lle om vores tidligere sejre, kampe eller blot om vores erfaringer.<\/p>\n

I dag er netop en s\u00e5dan dag. Og selvom du m\u00e5ske ikke sidder ved b\u00e5let lige nu, har vi en historie til dig. En historie om, hvordan vi begyndte at arbejde med lagring p\u00e5 Tarantool.<\/p>\n

Engang i vores virksomhed havde vi et par 'monolitter' og et f\u00e6lles 'loft', som disse monolitter langsomt men sikkert n\u00e6rmede sig, hvilket begr\u00e6nsede vores virksomheds v\u00e6kst. Der var en klar forst\u00e5else: En dag ville vi h\u00e5rdt ramme dette loft.
\n<\/a><\/noindex>
\nNu hersker ideologien om at opdele alt og enhver, fra udstyr til forretningslogik. Som et resultat har vi for eksempel to datacentre, der er stort set uafh\u00e6ngige p\u00e5 netv\u00e6rksniveau. Men dengang var alt helt anderledes.<\/p>\n

I dag findes der en masse v\u00e6rkt\u00f8jer og midler til at foretage \u00e6ndringer i form af CI\/CD, K8S osv. I den 'monolitiske' tid havde vi ikke behov for s\u00e5 mange fremmedord. Det var nok blot at rette op p\u00e5 'lagringen' i databasen.<\/p>\n

Men tiden gik fremad, og antallet af foresp\u00f8rgsler steg tilsvarende, hvilket medf\u00f8rte RPS, der til tider oversteg vores kapaciteter. Da vi gik ind p\u00e5 markedet i CIS-landene, faldt belastningen p\u00e5 databasen i den f\u00f8rste monolit aldrig under 90 %, og RPS l\u00e5 p\u00e5 omkring 2400. Og det var ikke blot sm\u00e5 foresp\u00f8rgsler, men store foresp\u00f8rgsler med masser af kontroller og JOINs, der kunne l\u00f8be n\u00e6sten igennem halvdelen af dataene p\u00e5 baggrund af h\u00f8j IO.<\/p>\n

Da der begyndte at komme rigtige udsalg p\u00e5 'Black Friday' \u2014 og Wildberries var en af de f\u00f8rste til at afholde dem i Rusland \u2014 blev situationen meget dyster. For belastningen p\u00e5 s\u00e5danne dage stiger tredobbelt.
\n\u00c5h, disse 'monolitiske tider'! Jeg er sikker p\u00e5, at du ogs\u00e5 har v\u00e6ret ude for noget lignende og stadig ikke forst\u00e5r, hvordan noget s\u00e5dan kunne ske for dig.<\/p>\n

Hvad kan man sige \u2014 mode er ogs\u00e5 en del af teknologierne. For cirka fem \u00e5r siden m\u00e5tte vi genoverveje en af disse modef\u00e6nomener i form af en eksisterende hjemmeside p\u00e5 .NET og MS SQL-server, der n\u00e6nsomt opbevarede al logikken bag hjemmesiden. Den opbevarede det s\u00e5 n\u00e6nsomt, at det viste sig at v\u00e6re en langvarig og besv\u00e6rlig forn\u00f8jelse at nedbryde en s\u00e5dan monolit.
\nEt lille sidespring. <\/p>\n

Til forskellige typer begivenheder siger jeg: \u00abhvis I ikke har sk\u00e5ret i monolitten, s\u00e5 er I ikke vokset!\u00bb Jeg er interesseret i din mening om dette, s\u00e5 skriv venligst din kommentar.<\/p>\n

Og torden bragede<\/h3>\n

\nLad os vende tilbage til vores \u00abb\u00e5l\u00bb. For at fordele belastningen af den \u00abmonolitiske\u00bb funktionalitet besluttede vi at opdele systemet i mikrotjenester baseret p\u00e5 opensource-teknologier. Fordi, i det mindste, s\u00e5 er deres skalerbarhed billigere. Vi havde helt sikkert forst\u00e5else for, at vi skulle skalere (og meget) allerede p\u00e5 det tidspunkt. For p\u00e5 det tidspunkt var vi allerede tr\u00e5dt ind p\u00e5 nabomarkederne, og antallet af registreringer, s\u00e5vel som antallet af ordrer, begyndte at stige endnu mere.<\/p>\n

Efter at have analyseret de f\u00f8rste kandidater til at forlade monolitten for mikrotjenester, inds\u00e5 vi, at i 80 % af tilf\u00e6ldene kom optagelsen i dem 99 % fra back office-systemer, mens l\u00e6sningen kom fra frontlinjen. Dette gjaldt is\u00e6r for et par vigtige subsystemer for os \u2014 brugerdata og systemet til beregning af den endelige pris p\u00e5 varer baseret p\u00e5 information om kundespecifikke rabatter og kuponer.<\/p>\n

Som en bem\u00e6rkning. Det er skr\u00e6mmende at forestille sig i dag, men udover de ovenn\u00e6vnte subsystemer blev ogs\u00e5 produktkataloger, brugerens indk\u00f8bsvogn, s\u00f8gesystemet for produkter, systemet til filtrering af produktkataloger og forskellige anbefalingssystemer fjernet fra vores monolit. For hver enkelt af dem findes der separate klasser af sn\u00e6vert specialiserede systemer, men engang boede de alle i \u00e9n \u201chytte\u201d. <\/p>\n

Vi planlagde straks at flytte oplysninger om vores kunder til et sharderet system. Men flytningen af funktionaliteten til at beregne den endelige pris p\u00e5 varer kr\u00e6vede en god skalerbarhed i l\u00e6sning, da det udgjorde den st\u00f8rste belastning i RPS og var den mest komplekse at udf\u00f8re for databasen (der er involveret meget data i beregningsprocessen). <\/p>\n

Som et resultat af dette fik vi en skema, der passer godt sammen med Tarantool.<\/p>\n

P\u00e5 det tidspunkt blev der valgt driftskemaer for mikrotjenester med flere datacentre p\u00e5 virtuelle og fysiske maskiner. Som vist p\u00e5 billederne blev der anvendt replikeringsvarianter af Tarantool b\u00e5de i master-master- og master-slave-tilstand. <\/p>\n

\"S\u00e5dan
\nArkitektur. Variant 1. Brugerens tjeneste<\/i><\/p>\n

I \u00f8jeblikket er der 24 sharder, hver med 2 instanser (en i hvert datacenter), alle i master-master-tilstand.<\/p>\n

Over the database are applications that access the database replicas. The applications work with Tarantool through our custom library, which implements the Go driver interface for Tarantool. It sees all replicas and can work with the master for reading and writing. Essentially, it implements a replica set model, into which logic for replica selection, retries, a circuit breaker, and rate limiting has been added.<\/p>\n

At the same time, it is possible to configure the replica selection policy per shard. For example, using round-robin.<\/p>\n

\"S\u00e5dan
\nArchitecture. Option 2. Service for calculating the final cost of goods.<\/i><\/p>\n

Several months ago, most requests for calculating the final cost of goods moved to a new service that essentially operates without databases, but some time ago 100% of the requests were handled by a service with Tarantool under the hood.<\/p>\n

The service database consists of 4 masters, to which the synchronizer aggregates data, and each of these masters distributes data to read-only replicas through replication. Each master has about 15 such replicas.<\/p>\n

In both the first and second schemes, if one data center is unavailable, the application can still retrieve data from the second.<\/p>\n

It is worth noting that in Tarantool replication is quite flexible and can be configured at runtime. In other systems, challenges have arisen. For example, changing the parameters max_wal_senders and max_replication_slots in PostgreSQL requires restarting the master, which in some cases can lead to a disruption of connections between the application and the DBMS.<\/p>\n

Seek, and you shall find!<\/h3>\n

\nWhy didn't we do it 'like normal people' and choose a typical approach? It depends on what you consider normal. Many actually make a cluster out of Mongo and spread it across three geo-distributed data centers.<\/p>\n

At that time, we already had two projects on Redis. The first was a cache, and the second was a persistent storage for not overly critical data. We had quite a difficult time with it, partly due to our own mistakes. Sometimes quite large volumes were stored in a key, and every now and then the site faced issues. We used this system in a master-slave configuration, and there were many cases when something happened with the master and replication broke. <\/p>\n

Det vil sige, at Redis er godt til stateless-opgaver, men ikke til stateful. I princippet l\u00f8ste det de fleste opgaver, men kun hvis de var key-value-l\u00f8sninger med et par indekser. Men med Redis var der p\u00e5 det tidspunkt ret store problemer med persistens og replikation. Desuden var der klager over ydeevnen.<\/p>\n

Vi overvejede MySQL og PostgreSQL. Men den f\u00f8rste fik ikke rigtig fat hos os, mens den anden er et ret avanceret produkt, og det ville v\u00e6re uforsvarligt at bygge simple tjenester p\u00e5 det.
\nVi pr\u00f8vede RIAK, Cassandra, endda en grafdatabase. Alt dette er ret nichel\u00f8sninger, der ikke kunne fungere som et generelt v\u00e6rkt\u00f8j til at skabe tjenester.<\/p>\n

I sidste ende landede vi p\u00e5 Tarantool.<\/p>\n

Vi henvendte os til det, da det var i version 1.6. Vi blev interesseret i symbiosen mellem key-value og funktionaliteten af en relationel database. Der er sekund\u00e6re indekser, transaktioner og spaces, som er som tabeller, men ikke simple; man kan gemme forskellige antal kolonner i dem. Men Tarantools killer-feature var de sekund\u00e6re indekser i kombination med key-value og transaktionalitet.<\/p>\n

Det spillede ogs\u00e5 en rolle, at det responsiv russisktalende f\u00e6llesskab var villig til at hj\u00e6lpe i chatten. Vi brugte dette aktivt og levede n\u00e6rmest i chatten. Man skal heller ikke glemme den anst\u00e6ndige persistens uden \u00e5benlyse fejl og problemer. Ser man p\u00e5 vores historie med Tarantool, havde vi mange smertepunkter og fejlsituationer med replikation, men vi har aldrig mistet data p\u00e5 grund af det!<\/p>\n

Implementeringen begyndte sv\u00e6rt.<\/h3>\n

\nP\u00e5 det tidspunkt var vores prim\u00e6re udviklingsstack .NET, som ikke havde en connector til Tarantool. Vi begyndte straks at udvikle noget p\u00e5 Go. Lua fungerede ogs\u00e5 ret godt. Det st\u00f8rste problem p\u00e5 det tidspunkt var debugging: i .NET var det fantastisk, men derefter at dykke ned i en verden af embedded Lua, hvor man ikke har andet end logs til debugging, var vanskeligt. Desuden br\u00f8d replikationen pludselig sammen fra tid til anden, og vi m\u00e5tte fordybe os i strukturen af Tarantool-motoren. Chatten hjalp meget, i mindre grad dokumentationen, og nogle gange kiggede vi p\u00e5 koden. P\u00e5 det tidspunkt var dokumentationen ikke s\u00e6rlig god.<\/p>\n

I l\u00f8bet af flere m\u00e5neder er det lykkedes at f\u00e5 erfaring og opn\u00e5 gode resultater med Tarantool. Vi har dokumenteret standardpraksisser i Git, som har hjulpet med at etablere nye mikrotjenester. For eksempel, n\u00e5r opgaven var at lave en ny mikrotjeneste, kiggede udvikleren p\u00e5 koden fra den standardl\u00f8sning, der l\u00e5 i repositoriet, og det tog ikke mere end en uge at oprette en ny. <\/p>\n

Det var specielle tider. Man kunne i \u00f8vrigt g\u00e5 hen til administratoren ved det n\u00e6rliggende bord og sige: \"Giv mig en virtuel maskine\". Om tredive minutter havde du allerede maskinen. Du selv tilsluttede dig, installerede alt, og der blev sat trafik p\u00e5 den.<\/p>\n

I dag kan det ikke lade sig g\u00f8re: man skal oprette overv\u00e5gning p\u00e5 tjenesten, loggf\u00f8ring, d\u00e6kke funktionaliteten med tests, bestille en virtuel maskine eller en ops\u00e6tning i Kubernetes osv. Generelt set er det bedre, selvom det er l\u00e6ngere og mere besv\u00e6rligt.<\/p>\n

Del og hersk. Hvordan st\u00e5r det til med Lua?<\/h3>\n

\nDer var et stort dilemma: nogle teams kunne ikke p\u00e5lideligt implementere \u00e6ndringer i tjenesten med en stor m\u00e6ngde logik skrevet i Lua. Ofte f\u00f8rte det til, at tjenesten ikke fungerede. <\/p>\n

Det vil sige, at udviklerne forbereder en \u00e6ndring. Tarantool begynder at udf\u00f8re migreringen, mens replikatet stadig k\u00f8rer med den gamle kode; der kommer en form for DDL gennem replikationen, noget andet, og koden bryder simpelthen sammen, fordi det ikke er taget i betragtning. Som f\u00f8lge heraf var opdateringsproceduren for administratorerne beskrevet p\u00e5 et A4-ark: stoppe replikationen, opdatere dette, genstarte replikationen, deaktivere her, opdatere der. Et mareridt! <\/p>\n

Som resultat pr\u00f8ver vi i dag ofte ikke at g\u00f8re noget i Lua. Bare ved hj\u00e6lp af iproto (det bin\u00e6re protokol til kommunikation med serveren), og that's it. M\u00e5ske er det en mangel p\u00e5 viden hos udviklerne, men fra den synsvinkel er systemet komplekst.<\/p>\n

Vi f\u00f8lger ikke altid blindt dette scenarie. I dag har vi ikke sort og hvidt: enten alt p\u00e5 Lua eller alt p\u00e5 Go. Vi forst\u00e5r allerede, hvordan vi kan kombinere, s\u00e5 vi ikke senere f\u00e5r problemer med migreringen.<\/p>\n

Hvor er Tarantool nu?
\nTarantool bruges i tjenesten til beregning af den endelige pris p\u00e5 varer under hensyntagen til rabatkuponer, ogs\u00e5 kaldet \u00abPromotajzer\u00bb. Som n\u00e6vnt tidligere, tr\u00e6kker det sig tilbage: det bliver erstattet af en ny katalogtjeneste med forudberegnede priser, men for et halvt \u00e5r siden blev alle beregninger foretaget i \u00abPromotajzer\u00bb. Tidligere var halvdelen af dens logik skrevet i Lua. For to \u00e5r siden blev tjenesten omdannet til et lager, og logikken blev genisoleret i Go, fordi rabatmekanikken blev lidt \u00e6ndret, og tjenesten manglede ydeevne. <\/p>\n

En af de mest kritiske tjenester er brugerprofilen. Det vil sige, at alle brugere af Wildberries gemmes i Tarantool, og der er omkring 50 millioner. Systemet er shardet efter bruger-ID og spredt over flere datacentre med integration i Go-tjenester.
\nTidligere var \u00abPromotajzer\u00bb f\u00f8rende inden for RPS, og n\u00e5ede op til 6000 foresp\u00f8rgsler. P\u00e5 et tidspunkt havde vi 50-60 instanser. Nu er liderne i RPS - brugerprofilerne, ca. 12 tusinde. Denne tjeneste anvender brugerdefineret sharding med opdeling efter bruger-ID-intervaller. Tjenesten betjener mere end 20 maskiner, men det er for meget; vi planl\u00e6gger at reducere de tildelte ressourcer, fordi 4-5 maskiner er tilstr\u00e6kkeligt.<\/p>\n

Sessiontjenesten er vores f\u00f8rste tjeneste p\u00e5 vshard og Cartridge. Ops\u00e6tningen af vshard og opdateringen af Cartridge kr\u00e6vede en del af vores arbejdstid, men i sidste ende lykkedes det.<\/p>\n

Tjenesten til visning af forskellige bannere p\u00e5 hjemmesiden og i mobilapplikationen var en af de f\u00f8rste, der blev lanceret p\u00e5 Tarantool. Denne tjeneste er bem\u00e6rkelsesv\u00e6rdig, da den er ca. 6-7 \u00e5r gammel, den fungerer stadig, og den har aldrig v\u00e6ret genstartet. Master-master replikation blev anvendt. Der har aldrig v\u00e6ret nogen problemer.<\/p>\n

Der er et eksempel p\u00e5 brugen af Tarantool til funktionen af hurtige optegnelser i lagersystemet for at hurtigt verificere information i nogle tilf\u00e6lde. Vi fors\u00f8gte at bruge Redis til dette form\u00e5l, men dataene i hukommelsen optog mere plads end i Tarantool.<\/p>\n

Tjenesterne til ventelister, klientabonnementer, de nu popul\u00e6re historier og forsinkede varer fungerer ogs\u00e5 med Tarantool. Den sidste service optager cirka 120 GB i hukommelsen. Det er den st\u00f8rste tjeneste blandt de n\u00e6vnte. <\/p>\n

Konklusion<\/h3>\n

\nTakket v\u00e6re sekund\u00e6re indekser i kombination med key-value og transaktionalitet er Tarantool s\u00e6rdeles velegnet til mikrotjenestearkitekturer. Vi stod imidlertid over for vanskeligheder, da vi implementerede \u00e6ndringer i tjenester med meget logik i Lua \u2013 tjenesterne stoppede ofte med at fungere. Vi kunne ikke l\u00f8se dette, og i takt med tiden er vi endt med forskellige kombinationer af Lua og Go: vi ved, hvorn\u00e5r det er bedst at bruge det ene sprog og hvorn\u00e5r det er bedst at bruge det andet.<\/p>\n

Andre artikler om emnet<\/b><\/p>\n