Ahoj Habr! Posledných pár mesiacov žijeme vo veľmi zaujímavej situácii a rád by som sa podelil o náš príbeh škálovania infraštruktúry. Počas tejto doby SberMarket vzrástol v objednávkach 4-krát a spustil službu v 17 nových mestách. Explozívny rast dopytu po dodávke potravín si vyžiadal rozšírenie našej infraštruktúry. Prečítajte si o najzaujímavejších a najužitočnejších záveroch pod rezom.
Volám sa Dima Bobylev, som technický riaditeľ SberMarket. Keďže toto je prvý príspevok na našom blogu, poviem pár slov o sebe a o spoločnosti. Minulú jeseň som sa zúčastnil súťaže pre mladých vodcov Runet. Pre súťaž I o tom, ako my v SberMarket vnímame internú kultúru a prístup k rozvoju služieb. A hoci sa mi nepodarilo vyhrať súťaž, sformuloval som si pre seba základné princípy rozvoja IT ekosystému.
Pri riadení tímu je dôležité pochopiť a nájsť rovnováhu medzi tým, čo podnik potrebuje, a potrebami každého jednotlivého vývojára. Teraz SberMarket rastie 13-krát z roka na rok, čo ovplyvňuje produkt, čo si vyžaduje, aby neustále zvyšoval objem a tempo vývoja. Napriek tomu venujeme vývojárom dostatok času na predbežnú analýzu a kvalitné kódovanie. Formovaný prístup pomáha nielen pri vytváraní funkčného produktu, ale aj pri jeho ďalšom škálovaní a vývoji. V dôsledku tohto rastu sa SberMarket už stal lídrom medzi službami doručovania potravín: denne doručíme asi 18 tisíc objednávok, hoci začiatkom februára ich bolo asi 3500 XNUMX.
Jedného dňa klient požiadal kuriéra SberMarket, aby mu doručil potraviny bezkontaktne - priamo na balkón
Ale prejdime ku konkrétnostiam. Počas niekoľkých posledných mesiacov sme aktívne škálovali infraštruktúru našej spoločnosti. Táto potreba bola vysvetlená vonkajšími a vnútornými faktormi. Spolu s rozširovaním zákazníckej základne vzrástol počet prepojených predajní z 90 na začiatku roka na viac ako 200 do polovice mája. Samozrejme, boli sme pripravení, rezervovali sme hlavnú infraštruktúru, plus sme rátali s možnosťou vertikálneho a horizontálneho škálovania všetkých virtuálnych strojov hostovaných v cloude Yandex. Prax však ukázala: "Všetko, čo sa môže pokaziť, sa pokazí." A dnes sa chcem podeliť o najzaujímavejšie situácie, ktoré sa udiali počas týchto týždňov. Dúfam, že naše skúsenosti budú pre vás užitočné.
Slave je v plnej bojovej pripravenosti
Ešte pred začiatkom pandémie sme čelili nárastu počtu požiadaviek na naše backend servery. Trend objednávania potravín na donášku domov začal naberať na obrátkach a so zavedením prvých samoizolačných opatrení v dôsledku COVID-19 pracovná záťaž počas dňa dramaticky narástla. Bolo potrebné rýchlo uvoľniť hlavné servery hlavnej databázy a preniesť niektoré požiadavky na čítanie na replikované servery (slave).
Na tento krok sme sa vopred pripravili a na takýto manéver už boli spustené 2 podriadené servery. Používali sa hlavne na dávkové úlohy generovania informačných kanálov na výmenu údajov s partnermi. Tieto procesy vytvorili dodatočnú záťaž a boli celkom správne vyňaté z rovnice pred pár mesiacmi.
Keďže replikácia prebiehala na Slave, držali sme sa konceptu, že aplikácie s nimi môžu pracovať iba v režime len na čítanie. Plán obnovy po havárii predpokladal, že v prípade katastrofy by sme mohli jednoducho namontovať Slave namiesto Master a prepnúť všetky požiadavky na zápis a čítanie na Slave. Chceli sme však použiť repliky aj pre potreby analytického oddelenia, takže servery neboli úplne prepnuté do stavu len na čítanie, ale každý hostiteľ mal vlastnú množinu používateľov a niektorí mali práva na zápis na uloženie medzivýsledkov výpočtov.
Do určitej úrovne zaťaženia sme mali dostatok mastera na zápis aj čítanie pri spracovaní http požiadaviek. V polovici marca, práve keď sa Sbermarket rozhodol úplne prejsť na prácu na diaľku, začalo naše RPS rásť exponenciálne. Čoraz viac našich klientov sa izolovalo alebo pracovalo z domu, čo ovplyvnilo naše ukazovatele pracovného zaťaženia.
Výkon „mastera“ už nestačil, a tak sme začali prenášať niektoré z najťažších požiadaviek na čítanie do repliky. Na transparentné smerovanie požiadaviek na zápis na master a čítanie požiadaviek na slave sme použili rubínový klenot “" Vytvorili sme špeciálneho používateľa s postfixom _readonly bez práv na zápis. Ale kvôli chybe v konfigurácii jedného z hostiteľov sa niektoré požiadavky na zápis dostali na podriadený server v mene používateľa, ktorý mal príslušné práva.
Problém sa neprejavil hneď, pretože... zvýšené zaťaženie zvýšilo oneskorenie otrokov. Nekonzistentnosť údajov sa zistila ráno, keď po nočných dovozoch otroci „nestihli“ pána. Pripísali sme to vysokému zaťaženiu samotnej služby a dovozu spojenému so spustením nových predajní. Odosielanie údajov s viachodinovým oneskorením však bolo neprijateľné a procesy sme prešli na druhý analytický podriadený počítač, pretože malоväčšie zdroje a nebol zaťažený požiadavkami na čítanie (takto sme si vysvetlili nedostatok oneskorenia replikácie).
Keď sme prišli na dôvody „šírenia“ hlavného otroka, analytický už zlyhal z rovnakého dôvodu. Napriek prítomnosti dvoch ďalších serverov, na ktoré sme plánovali preniesť záťaž v prípade zlyhania mastera, sa kvôli nešťastnej chybe ukázalo, že v kritickom momente nie sú dostupné žiadne.
Ale keďže sme nevykopali len databázu (restorative vtedy trvalo asi 5 hodín), ale aj snímku hlavného servera, podarilo sa nám spustiť repliku do 2 hodín. Je pravda, že potom sme čelili tomu, že protokol replikácie sa prevalil na dlhú dobu (pretože proces beží v režime s jedným vláknom, ale to je úplne iný príbeh).
Záver: Po takomto incidente sa ukázalo, že je potrebné opustiť prax obmedzovania zápisu pre používateľov a vyhlásiť celý server iba na čítanie. S týmto prístupom nie je pochýb o tom, že repliky budú dostupné v kritických časoch.
Optimalizácia aj jedného náročného dotazu môže obnoviť databázu k životu
Aj keď katalóg na stránke neustále aktualizujeme, požiadavky, ktoré sme posielali na Slave servery, umožnili mierne oneskorenie od Master. Čas, počas ktorého sme objavili a odstránili problém otrokov „náhleho odchodu z diaľky“, bol viac ako len „psychologická bariéra“ (v tomto čase mohli byť ceny aktualizované a klienti by videli neaktuálne údaje) a boli sme nútení prepnite všetky požiadavky na hlavný databázový server. Tým pádom bola stránka pomalá... ale aspoň fungovala. A kým sa Slave zotavoval, nemali sme inú možnosť ako optimalizáciu.
Kým sa Slave servery zotavovali, minúty pomaly ubiehali, Master zostal preťažený a my sme všetko svoje úsilie venovali optimalizácii aktívnych úloh podľa „Paretovho pravidla“: vybrali sme TOP požiadavky, ktoré generujú väčšinu záťaže a začali sme ladiť. . Toto sa robilo priamo za chodu.
Zaujímavým efektom bolo, že MySQL nabitý do kapacity reagoval aj na mierne zlepšenie procesov. Optimalizácia niekoľkých dopytov, ktoré vyprodukovali iba 5 % z celkového zaťaženia, už ukázala značné zaťaženie procesora. Výsledkom bolo, že sme boli schopní poskytnúť prijateľnú zásobu zdrojov pre Master na prácu s databázou a získať potrebný čas na obnovu replík.
Záver: Aj malá optimalizácia vám umožní „prežiť“ pri preťažení niekoľko hodín. To nám stačilo na obnovenie serverov s replikami. Mimochodom, technickú stránku optimalizácie dotazov rozoberieme v jednom z nasledujúcich príspevkov. Preto sa prihláste na odber nášho blogu, ak to považujete za užitočné.
Zorganizujte monitorovanie výkonu partnerských služieb
Spracovávame objednávky od zákazníkov, a preto naše služby neustále interagujú s API tretích strán - to sú brány na odosielanie SMS, platobné platformy, smerovacie systémy, geokóder, Federálna daňová služba a mnoho ďalších systémov. A keď zaťaženie začalo rýchlo rásť, začali sme narážať na obmedzenia API našich partnerských služieb, o ktorých sme predtým ani neuvažovali.
Neočakávané prekročenie kvót partnerských služieb môže viesť k výpadkom vašich vlastných. Mnoho rozhraní API blokuje klientov, ktorí prekračujú limity, a v niektorých prípadoch môže príliš veľa požiadaviek preťažiť produkciu partnera.
Keď napríklad rástol počet dodávok, sprievodné služby nezvládali úlohy súvisiace s ich distribúciou a určovaním trás. V dôsledku toho sa ukázalo, že objednávky boli urobené, ale služba, ktorá vytvorila trasu, nefungovala. Treba povedať, že naši logistici dokázali za týchto podmienok takmer nemožné a jasná súhra tímu pomohla kompenzovať dočasné výpadky služieb. Je ale nereálne stále manuálne spracovávať takýto objem objednávok a po určitom čase by sme sa stretli s neprijateľnou medzerou medzi objednávkami a ich realizáciou.
Prijalo sa množstvo organizačných opatrení a koordinovaná práca tímu pomohla získať čas, kým sme sa dohodli na nových podmienkach a čakali na modernizáciu služieb od niektorých partnerov. Existujú aj iné API, ktoré sa môžu pochváliť vysokou výdržou a poburujúcou mierou v prípade vysokej návštevnosti. Na začiatku sme napríklad použili jedno známe mapovacie API na určenie adresy miesta doručenia. Ale na konci mesiaca sme dostali uprataný účet za takmer 2 milióny rubľov. Potom sa ho rozhodli rýchlo vymeniť. Nebudem sa zapájať do reklamy, ale poviem, že naše výdavky sa výrazne znížili.
Záver: Je nevyhnutné sledovať prevádzkové podmienky všetkých partnerských služieb a mať ich na pamäti. Aj keď sa dnes zdá, že sú pre vás „s veľkou rezervou“, neznamená to, že zajtra sa nestanú prekážkou rastu. A samozrejme je lepšie si vopred dohodnúť finančné podmienky zvýšených požiadaviek na službu.
Niekedy sa ukáže, že ""(c) nepomôže
Sme zvyknutí na „gagy“ v hlavnej databáze alebo na aplikačných serveroch, no pri škálovaní sa môžu objaviť problémy tam, kde sa neočakávali.Na fulltextové vyhľadávanie na stránke používame engine Apache Solr. Keď sa zaťaženie zvyšovalo, zaznamenali sme zníženie času odozvy a zaťaženie procesora servera už dosiahlo 100 %. Čo by mohlo byť jednoduchšie - dajme kontajneru so Solr viac zdrojov.
Namiesto očakávaného zvýšenia výkonu server jednoducho „zomrel“. Okamžite sa načítal na 100 % a reagoval ešte pomalšie. Spočiatku sme mali 2 jadrá a 2 GB RAM. Rozhodli sme sa urobiť to, čo zvyčajne pomáha – dali sme serveru 8 jadier a 32 GB. Všetko sa zhoršilo (presne vám povieme ako a prečo v samostatnom príspevku).
V priebehu niekoľkých dní sme prišli na zložitosť tejto problematiky a dosiahli sme optimálny výkon s 8 jadrami a 32 GB. Táto konfigurácia nám dnes umožňuje pokračovať vo zvyšovaní záťaže, čo je veľmi dôležité, pretože rast nie je len v klientoch, ale aj v počte pripojených predajní – za 2 mesiace sa ich počet zdvojnásobil.
Záver: Štandardné metódy ako „pridať viac železa“ nie vždy fungujú. Pri škálovaní akejkoľvek služby teda musíte dobre rozumieť tomu, ako využíva zdroje a vopred otestovať jej fungovanie v nových podmienkach.
Bezstavové je kľúčom k jednoduchému horizontálnemu škálovaniu
Vo všeobecnosti sa náš tím riadi známym prístupom: služby by nemali mať interný stav (bezstavové) a mali by byť nezávislé od prostredia vykonávania. To nám umožnilo vyrovnať sa s rastom zaťaženia jednoduchým horizontálnym škálovaním. Mali sme však jednu výnimku - obsluhu pre dlhé úlohy na pozadí. Zaoberal sa odosielaním e-mailov a sms správ, spracovávaním udalostí, generovaním informačných kanálov, importovaním cien a zásob a spracovaním obrázkov. Stalo sa, že to záviselo od lokálneho úložiska súborov a bolo v jedinej kópii.
Keď sa zvýšil počet úloh vo fronte procesora (a to sa prirodzene stalo s nárastom počtu objednávok), limitujúcim faktorom sa stal výkon hostiteľa, na ktorom sa nachádzal procesor a úložisko súborov. V dôsledku toho sa zastavila aktualizácia sortimentu a cien, odosielanie upozornení používateľom a mnoho ďalších dôležitých funkcií, ktoré uviazli v rade. Tím Ops rýchlo migroval úložisko súborov na sieťové úložisko podobné S3, čo nám umožnilo získať niekoľko výkonných strojov na škálovanie procesora úloh na pozadí.
Záver: Pravidlo bez štátnej príslušnosti sa musí dodržiavať pre všetky zložky bez výnimky, aj keď sa zdá, že „tu rozhodne neodoláme“. Je lepšie stráviť trochu času správnou organizáciou prevádzky všetkých systémov, než unáhlene prepisovať kód a opraviť preťaženú službu.
7 zásad pre intenzívny rast
Napriek dostupnosti dodatočných kapacít sme v procese rastu nastúpili na viacero chýb. Za tento čas sa počet objednávok zvýšil viac ako 4-krát. Už teraz doručujeme viac ako 17 000 objednávok denne v 62 mestách a plánujeme geografické rozšírenie ešte viac – v prvej polovici roku 2020 sa očakáva spustenie služby v celom Rusku. Aby sme sa vyrovnali s rastúcim pracovným zaťažením, berúc do úvahy naše už plné kužele, vyvinuli sme 7 základných princípov pre prácu v podmienkach neustáleho rastu:
- Riadenie incidentov. V Jire sme vytvorili tabuľu, kde sa každý incident odzrkadlí vo forme lístka. Pomôže to pri určovaní priorít a vykonávaní úloh súvisiacich s incidentom. Koniec koncov, v podstate nie je desivé robiť chyby, ale je desivé robiť chyby dvakrát pri tej istej príležitosti. Pre prípady, keď sa incidenty opakujú skôr, ako sa podarí napraviť príčinu, by mali byť pripravené pokyny na akciu, pretože v čase veľkého zaťaženia je dôležité reagovať rýchlosťou blesku.
- monitorovanie potrebné pre všetky prvky infraštruktúry bez výnimky. Práve vďaka nemu sme dokázali predvídať rast záťaže a správne vybrať „úzke miesta“ pre prioritizáciu eliminácie. S najväčšou pravdepodobnosťou sa pri vysokej záťaži pokazí alebo začne spomaľovať všetko, na čo ste nikdy nepomysleli. Preto je najlepšie vytvárať nové výstrahy ihneď po výskyte prvých incidentov, aby ste ich mohli monitorovať a predvídať.
- Správne upozornenia jednoducho nevyhnutné, keď sa zaťaženie prudko zvýši. Najprv musia nahlásiť, čo presne je pokazené. Po druhé, nemalo by existovať veľa upozornení, pretože množstvo nekritických upozornení vedie k úplnému ignorovaniu všetkých upozornení.
- Aplikácie musia byť bez štátnej príslušnosti. Sme presvedčení, že z tohto pravidla by nemali existovať žiadne výnimky. Potrebujeme úplnú nezávislosť od runtime prostredia. K tomu si môžete ukladať zdieľané dáta do databázy alebo napríklad priamo do S3. Ešte lepšie je dodržiavať pravidlá.. Počas prudkého nárastu času jednoducho neexistuje spôsob, ako optimalizovať kód a budete sa musieť vyrovnať so záťažou priamym zvýšením výpočtových zdrojov a horizontálnym škálovaním.
- Kvóty a výkon externých služieb. S rýchlym rastom môže nastať problém nielen vo vašej infraštruktúre, ale aj v externej službe. Najnepríjemnejšia vec je, keď sa to nestane kvôli zlyhaniu, ale kvôli dosiahnutiu kvót alebo limitov. Externé služby by sa teda mali škálovať rovnako ako vy.
- Oddelené procesy a fronty. To veľmi pomáha, keď je jedna z brán zablokovaná. K oneskoreniam pri prenose dát by sme sa nestretli, keby do výmeny notifikácií medzi informačnými systémami nezasahovali plné fronty na odosielanie SMS. A bolo by jednoduchšie zvýšiť počet pracovníkov, keby pracovali oddelene.
- Finančná realita. Keď dôjde k prudkému nárastu dátových tokov, nie je čas myslieť na tarify a predplatné. Treba si ich však zapamätať, najmä ak ste malá firma. Vlastníkovi akéhokoľvek rozhrania API, ako aj vášmu poskytovateľovi hostingu, môže vzniknúť veľký účet. Treba si preto pozorne prečítať zmluvy.
Záver
Nie bez strát, ale prežili sme túto etapu a dnes sa snažíme dodržiavať všetky nájdené zásady a každý stroj má schopnosť ľahko zvýšiť výkon x4, aby sa vyrovnal s nejakými neočakávanými udalosťami.
V nasledujúcich príspevkoch sa podelíme o naše skúsenosti s vyšetrovaním zníženia výkonu v Apache Solr a tiež sa porozprávame o optimalizácii dopytov a o tom, ako interakcia s Federálnou daňovou službou pomáha spoločnosti šetriť peniaze. Prihláste sa na odber nášho blogu, aby vám nič neušlo, a povedzte nám v komentároch, či ste mali podobné problémy počas rastu návštevnosti.
Do prieskumu sa môžu zapojiť iba registrovaní užívatelia. Prosím.
Zažili ste niekedy spomalenie/pokles prevádzky v dôsledku prudkého zvýšenia zaťaženia v dôsledku:
-
55,6%Neschopnosť rýchlo pridať výpočtové zdroje10
-
16,7%Obmedzenia infraštruktúry poskytovateľa hostingu3
-
33,3%Obmedzenia rozhraní API tretích strán6
-
27,8%Porušenie bezštátnych princípov ich aplikácií5
-
88,9%Neoptimálny kód vlastných služieb16
Hlasovalo 18 užívateľov. 6 užívateľov sa zdržalo hlasovania.
Zdroj: hab.com