Lahat tayo mahilig sa kwento. Gusto naming umupo sa paligid ng apoy at pag-usapan ang aming mga nakaraang tagumpay, laban, o simpleng karanasan sa trabaho.
Ngayon ay ganoong araw lang. At kahit wala ka sa sunog ngayon, may kwento kami para sa iyo. Ang kwento kung paano kami nagsimulang magtrabaho kasama ang storage sa Tarantool.
Noong unang panahon, ang aming kumpanya ay may ilang "monolith" at isang "ceiling" para sa lahat, kung saan ang mga monolith na ito ay dahan-dahan ngunit tiyak na lumalapit, na nililimitahan ang paglipad ng aming kumpanya, ang aming pag-unlad. At nagkaroon ng malinaw na pag-unawa: isang araw ay tatamaan natin nang husto ang kisameng ito.
Ito na ngayon ang nangingibabaw na ideolohiya ng paghihiwalay ng lahat at lahat, mula sa kagamitan hanggang sa lohika ng negosyo. Bilang resulta, kami, halimbawa, ay may dalawang DC na halos independyente sa antas ng network. At pagkatapos ang lahat ay ganap na naiiba.
Ngayon, maraming mga tool at tool para sa paggawa ng mga pagbabago sa anyo ng CI/CD, K8S, atbp. Sa panahon ng "monolitik", hindi namin kailangan ng napakaraming banyagang salita. Ito ay sapat na upang itama lamang ang "imbakan" sa database.
Ngunit umusad ang oras, at ang bilang ng mga kahilingan ay sumulong kasama nito, kung minsan ay kumukuha ng RPS na lampas sa aming mga kakayahan. Sa pagpasok ng mga bansang CIS sa merkado, ang pag-load sa database processor ng unang monolith ay hindi bumaba sa ibaba 90%, at ang RPS ay nanatili sa antas ng 2400. At ang mga ito ay hindi lamang maliliit na tagapili, ngunit mabigat na mga query na may isang grupo ng mga tseke at JOIN na maaaring tumakbo sa halos kalahati ng data laban sa background ng malaking IO.
Nang magsimulang lumitaw sa eksena ang ganap na mga benta ng Black Friday - at ang Wildberries ay isa sa mga unang humawak sa kanila sa Russia - naging ganap na malungkot ang sitwasyon. Pagkatapos ng lahat, ang pagkarga sa gayong mga araw ay tumataas nang tatlong beses.
Oh, ang mga "monolitikong panahon" na ito! Sigurado ako na nakaranas ka ng katulad na bagay, at hindi mo pa rin maintindihan kung paano ito maaaring mangyari sa iyo.
Ano ang maaari mong gawin - ang fashion ay likas sa teknolohiya. Mga 5 taon na ang nakalilipas, kinailangan naming pag-isipang muli ang isa sa mga mod na ito sa anyo ng isang umiiral na site sa .NET at MS SQL server, na maingat na nag-imbak ng lahat ng lohika ng site mismo. Iniingatan ko ito nang maingat na ang paglalagari ng gayong monolith ay naging isang mahaba at hindi madaling kasiyahan.
Ang isang maliit na digression.
Sa iba't ibang mga kaganapan, sinasabi ko: "kung hindi ka nakakita ng isang monolith, kung gayon hindi ka lumaki!" Interesado ako sa iyong opinyon sa bagay na ito, mangyaring isulat ito sa mga komento.
Isang Tunog ng Kulog
Balik tayo sa ating "bonfire". Upang ipamahagi ang load ng "monolithic" functionality, nagpasya kaming hatiin ang system sa mga microservice batay sa mga opensource na teknolohiya. Dahil, sa pinakamababa, mas mura sila sa sukat. At mayroon kaming 100% na pag-unawa na kailangan naming sukatin (at marami). Pagkatapos ng lahat, sa oras na iyon posible na makapasok sa mga merkado ng mga kalapit na bansa, at ang bilang ng mga pagpaparehistro, pati na rin ang bilang ng mga order, ay nagsimulang lumago nang mas malakas.
Nang masuri ang mga unang kandidato para sa pag-alis mula sa monolith patungo sa mga microservice, napagtanto namin na 80% ng mga nakasulat sa kanila ay mula sa mga back office system, at pagbabasa mula sa front office. Una sa lahat, may kinalaman ito sa ilang mahahalagang subsystem para sa amin - data ng user at isang sistema para sa pagkalkula ng panghuling halaga ng mga produkto batay sa impormasyon tungkol sa mga karagdagang diskwento at kupon ng customer.
Naka-indent. Ngayon ay nakakatakot isipin, ngunit bilang karagdagan sa mga nabanggit na subsystem, ang mga katalogo ng produkto, isang shopping cart ng gumagamit, isang sistema ng paghahanap ng produkto, isang sistema ng pag-filter para sa mga katalogo ng produkto, at iba't ibang uri ng mga sistema ng rekomendasyon ay inalis din sa aming monolith. Para sa pagpapatakbo ng bawat isa sa kanila, may mga hiwalay na klase ng makitid na iniangkop na mga sistema, ngunit noong unang panahon lahat sila ay nanirahan sa isang "bahay".
Agad naming binalak na ilipat ang data tungkol sa aming mga kliyente sa sharded system. Ang pag-alis ng functionality para sa pagkalkula ng huling halaga ng mga kalakal ay nangangailangan ng mahusay na scalability para sa pagbabasa, dahil ito ay lumikha ng pinakamalaking RPS load at ang pinakamahirap na ipatupad para sa database (maraming data ang kasangkot sa proseso ng pagkalkula).
Bilang resulta, nakabuo kami ng isang pamamaraan na angkop sa Tarantool.
Sa oras na iyon, para sa pagpapatakbo ng mga microservice, napili ang mga scheme para sa pagtatrabaho sa ilang mga data center sa virtual at hardware machine. Tulad ng ipinapakita sa mga figure, ang mga pagpipilian sa pagtitiklop ng Tarantool ay inilapat sa parehong master-master at master-slave mode.
Arkitektura. Pagpipilian 1. Serbisyo ng gumagamit
Sa kasalukuyang panahon, mayroong 24 shards, bawat isa ay may 2 instance (isa para sa bawat DC), lahat ay nasa master-master mode.
Sa ibabaw ng database ay ang mga application na nag-a-access ng mga replika ng database. Gumagana ang mga application sa Tarantool sa pamamagitan ng aming custom na library, na nagpapatupad ng interface ng driver ng Tarantool Go. Nakikita niya ang lahat ng mga replika at maaaring makipagtulungan sa master upang magbasa at magsulat. Sa esensya, ipinapatupad nito ang replica set model, na nagdaragdag ng lohika para sa pagpili ng mga replika, pagsasagawa ng mga muling pagsubok, isang circuit breaker at isang limitasyon sa rate.
Sa kasong ito, posibleng i-configure ang patakaran sa pagpili ng replika sa konteksto ng mga shards. Halimbawa, roundrobin.
Arkitektura. Pagpipilian 2. Serbisyo para sa pagkalkula ng huling halaga ng mga kalakal
Ilang buwan na ang nakalilipas, karamihan sa mga kahilingan para sa pagkalkula ng pangwakas na halaga ng mga kalakal ay napunta sa isang bagong serbisyo, na, sa prinsipyo, ay gumagana nang walang mga database, ngunit ilang oras na ang nakalipas lahat ay naproseso ng 100% ng isang serbisyo na may Tarantool sa ilalim ng hood.
Binubuo ang database ng serbisyo ng 4 na master kung saan kinokolekta ng synchronizer ang data, at bawat isa sa mga master ng replikasyon na ito ay namamahagi ng data sa mga readonly na replika. Ang bawat master ay may humigit-kumulang 15 tulad ng mga replika.
Alinman sa una o sa pangalawang scheme, kung ang isang DC ay hindi magagamit, ang application ay maaaring makatanggap ng data sa pangalawa.
Ito ay nagkakahalaga ng pagpuna na ang pagtitiklop sa Tarantool ay medyo nababaluktot at maaaring i-configure sa runtime. Sa ibang mga sistema, lumitaw ang mga paghihirap. Halimbawa, ang pagbabago ng max_wal_senders at max_replication_slots na mga parameter sa PostgreSQL ay nangangailangan ng pag-restart ng wizard, na sa ilang mga kaso ay maaaring humantong sa pagkaputol ng mga koneksyon sa pagitan ng application at ng DBMS.
Maghanap at makikita mo!
Bakit hindi natin ito ginawa "tulad ng mga normal na tao", ngunit pumili ng hindi tipikal na paraan? Depende ito sa kung ano ang itinuturing na normal. Maraming tao ang karaniwang gumagawa ng isang kumpol mula sa Mongo at ikinakalat ito sa tatlong geo-distributed na DC.
Sa oras na iyon, mayroon na kaming dalawang proyekto ng Redis. Ang una ay isang cache, at ang pangalawa ay isang patuloy na imbakan para sa hindi masyadong kritikal na data. Medyo mahirap sa kanya, partly through our fault. Minsan medyo malalaking volume ang nasa susi, at paminsan-minsan ang site ay nagiging masama. Ginamit namin ang system na ito sa master-slave na bersyon. At maraming mga kaso kung saan may nangyari sa master at nasira ang pagtitiklop.
Iyon ay, ang Redis ay mabuti para sa mga walang estado na gawain, hindi mga stateful. Sa prinsipyo, pinapayagan nitong lutasin ang karamihan sa mga problema, ngunit kung ang mga ito ay mga solusyon sa key-value na may isang pares ng mga index. Ngunit si Redis sa oras na iyon ay medyo malungkot sa pagtitiyaga at pagtitiklop. Bilang karagdagan, may mga reklamo tungkol sa pagganap.
Naisip namin ang tungkol sa MySQL at PostgreSQL. Ngunit ang una sa paanuman ay hindi nahuli sa amin, at ang pangalawa ay isang medyo sopistikadong produkto sa sarili nito, at hindi nararapat na bumuo ng mga simpleng serbisyo dito.
Sinubukan namin ang RIAK, Cassandra, kahit isang graph database. Ang lahat ng ito ay mga medyo angkop na solusyon na hindi angkop para sa papel na ginagampanan ng isang pangkalahatang unibersal na tool para sa paglikha ng mga serbisyo.
Sa huli kami ay nanirahan sa Tarantool.
Binalingan namin ito noong nasa bersyon 1.6 ito. Interesado kami dito sa pamamagitan ng symbiosis ng key-value at ang functionality ng isang relational database. May mga pangalawang index, transaksyon at puwang, ito ay tulad ng mga talahanayan, ngunit hindi simple, maaari kang mag-imbak ng iba't ibang bilang ng mga haligi sa kanila. Ngunit ang pamatay na tampok ng Tarantool ay mga pangalawang index na pinagsama sa key-value at transactionality.
Ang tumutugon na komunidad na nagsasalita ng Ruso, na handang tumulong sa chat, ay gumanap din ng isang papel. Aktibong ginamit namin ito at direktang nakatira sa chat. At huwag kalimutan ang tungkol sa disenteng paulit-ulit na walang halatang mga pagkakamali at pagkakamali. Kung titingnan mo ang aming kasaysayan sa Tarantool, nagkaroon kami ng maraming sakit at pagkabigo sa pagtitiklop, ngunit hindi kami nawalan ng data dahil sa kasalanan nito!
Ang pagpapatupad ay nagsimula sa isang mahirap na simula
Noong panahong iyon, ang aming pangunahing development stack ay .NET, kung saan walang connector para sa Tarantool. Agad kaming nagsimulang gumawa ng isang bagay sa Go. Naging maayos din ito kay Lua. Ang pangunahing problema sa oras na iyon ay sa pag-debug: sa .NET ang lahat ay mahusay sa ito, ngunit pagkatapos nito ay mahirap na plunge sa mundo ng naka-embed na Lua, kapag wala kang pag-debug maliban sa mga log. Bilang karagdagan, sa ilang kadahilanan, ang pagtitiklop ay pana-panahong nasira, kaya kinailangan kong suriin ang istraktura ng makina ng Tarantool. Nakatulong ang chat dito, at sa mas maliit na lawak, ang dokumentasyon; minsan tinitingnan namin ang code. Sa oras na iyon, ang dokumentasyon ay kaya-kaya.
Kaya, sa paglipas ng ilang buwan, nakuha ko ang aking ulo sa paligid at makakuha ng mga disenteng resulta mula sa pagtatrabaho sa Tarantool. Nag-compile kami ng mga reference development sa git na nakatulong sa pagbuo ng mga bagong microservice. Halimbawa, kapag lumitaw ang isang gawain: upang lumikha ng isa pang microservice, tiningnan ng developer ang source code ng reference na solusyon sa repository, at tumagal ng hindi hihigit sa isang linggo upang lumikha ng bago.
Ito ay mga espesyal na panahon. Karaniwan, maaari kang pumunta sa admin sa susunod na talahanayan at magtanong: "Bigyan mo ako ng virtual machine." Makalipas ang halos tatlumpung minuto ay nasa iyo na ang sasakyan. Ikinonekta mo ang iyong sarili, na-install ang lahat, at ipinadala sa iyo ang trapiko.
Ngayon hindi na ito gagana: kailangan mong magdagdag ng pagsubaybay at pag-log sa serbisyo, saklawin ang pag-andar gamit ang mga pagsubok, mag-order ng virtual machine o paghahatid sa Kuber, atbp. Sa pangkalahatan, ito ay magiging mas mahusay sa ganitong paraan, bagaman ito ay mas magtatagal at magiging mas mahirap.
Hatiin at tuntunin. Anong meron kay Lua?
Nagkaroon ng malubhang problema: ang ilang mga koponan ay hindi mapagkakatiwalaang maglunsad ng mga pagbabago sa isang serbisyo na may maraming lohika sa Lua. Ito ay madalas na sinamahan ng serbisyo na hindi gumagana.
Iyon ay, ang mga developer ay naghahanda ng ilang uri ng pagbabago. Sinimulan ng Tarantool ang paglipat, ngunit ang replica ay nasa lumang code; Ang ilang DDL o iba pang bagay ay dumarating doon sa pamamagitan ng pagtitiklop, at ang code ay nahuhulog lamang dahil hindi ito isinasaalang-alang. Bilang isang resulta, ang pamamaraan ng pag-update para sa mga administrator ay inilatag sa A4 sheet: itigil ang pagtitiklop, i-update ito, i-on ang pagtitiklop, i-off dito, i-update doon. bangungot!
Bilang isang resulta, ngayon ay madalas naming sinusubukan na walang gawin sa Lua. Gumamit lamang ng iproto (isang binary protocol para sa pakikipag-ugnayan sa server), at iyon na. Marahil ito ay isang kakulangan ng kaalaman sa mga developer, ngunit mula sa puntong ito ng view ang system ay kumplikado.
Hindi namin palaging bulag na sinusunod ang script na ito. Ngayon ay wala kaming black and white: alinman sa lahat ay nasa Lua, o lahat ay nasa Go. Naiintindihan na natin kung paano natin pagsasamahin ang mga ito para hindi tayo mauwi sa mga problema sa paglilipat mamaya.
Nasaan na ang Tarantool?
Ginagamit ang Tarantool sa serbisyo para sa pagkalkula ng huling halaga ng mga kalakal na isinasaalang-alang ang mga kupon ng diskwento, na kilala rin bilang "Promoter". Gaya ng sinabi ko kanina, magre-retire na siya: pinapalitan siya ng bagong serbisyo ng catalog na may mga pre-calculated na presyo, ngunit anim na buwan na ang nakalipas lahat ng kalkulasyon ay ginawa sa Promotizer. Dati, kalahati ng lohika nito ay nakasulat sa Lua. Dalawang taon na ang nakalilipas, ang serbisyo ay ginawang isang pasilidad ng imbakan, at ang lohika ay muling isinulat sa Go, dahil ang mekanika ng mga diskwento ay nagbago ng kaunti at ang serbisyo ay kulang sa pagganap.
Ang isa sa mga pinaka-kritikal na serbisyo ay ang profile ng gumagamit. Ibig sabihin, lahat ng mga user ng Wildberries ay naka-store sa Tarantool, at may humigit-kumulang 50 milyon sa kanila. Isang system na hinati ng user ID, na ipinamahagi sa ilang DC na konektado sa mga serbisyo ng Go.
Ayon sa RPS, ang Promoter ay dating nangunguna, umabot sa 6 na libong kahilingan. Sa isang punto mayroon kaming 50-60 na kopya. Ngayon ang nangunguna sa RPS ay mga profile ng user, mga 12 libo. Gumagamit ang serbisyong ito ng custom sharding, na hinati sa mga hanay ng mga user ID. Ang serbisyo ay nagsisilbi ng higit sa 20 mga makina, ngunit ito ay masyadong marami; plano naming bawasan ang inilalaan na mga mapagkukunan, dahil ang kapasidad ng 4-5 na mga makina ay sapat na para dito.
Ang serbisyo ng session ay ang aming unang serbisyo sa vshard at Cartridge. Ang pag-set up ng vshard at pag-update ng Cartridge ay nangangailangan ng ilang pagsisikap mula sa amin, ngunit sa huli lahat ay gumana.
Ang serbisyo para sa pagpapakita ng iba't ibang mga banner sa website at sa mobile application ay isa sa mga unang inilabas nang direkta sa Tarantool. Ang serbisyong ito ay kapansin-pansin sa katotohanan na ito ay 6-7 taong gulang, ito ay gumagana pa rin at hindi kailanman na-reboot. Ginamit ang master-master replication. Walang nasira.
Mayroong isang halimbawa ng paggamit ng Tarantool para sa mabilis na paggana ng sanggunian sa isang warehouse system upang mabilis na suriin ang impormasyon sa ilang mga kaso. Sinubukan naming gamitin ang Redis para dito, ngunit ang data sa memorya ay tumagal ng mas maraming espasyo kaysa sa Tarantool.
Gumagana rin sa Tarantool ang mga serbisyo ng waiting list, mga subscription ng kliyente, kasalukuyang naka-istilong kwento at mga ipinagpaliban na produkto. Ang huling serbisyo sa memorya ay tumatagal ng humigit-kumulang 120 GB. Ito ang pinakakomprehensibong serbisyo sa itaas.
Konklusyon
Salamat sa mga pangalawang index na pinagsama sa key-value at transactionality, ang Tarantool ay angkop na angkop para sa mga microservice-based na arkitektura. Gayunpaman, nakatagpo kami ng mga paghihirap nang ilunsad ang mga pagbabago sa mga serbisyo na may maraming lohika sa Lua - ang mga serbisyo ay madalas na huminto sa paggana. Hindi namin ito nalampasan, at sa paglipas ng panahon ay nakarating kami sa iba't ibang kumbinasyon ng Lua at Go: alam namin kung saan gagamitin ang isang wika at kung saan gagamitin ang isa pa.
Ano pa ang mababasa sa paksa
- Paglikha ng isang high-load na application mula sa simula gamit ang Tarantool
- Pinagkakatiwalaang lider na pinili sa Tarantool Cartridge
- Telegram channel Tarantool na may mga balita tungkol sa produkto
- Talakayin ang Tarantool sa community chat
Pinagmulan: www.habr.com