🥇Jak jsme přežili prudký nárůst pracovní zátěže x10 při práci na dálku a jaké jsme z toho vyvodili závěry

Dobrý den, Habr! Posledních pár měsíců žijeme ve velmi zajímavé situaci a rád bych se podělil o náš příběh škálování infrastruktury. Během této doby SberMarket vzrostl v počtu objednávek 4krát a spustil službu v 17 nových městech. Prudký růst poptávky po dodávkách potravin si vyžádal rozšíření naší infrastruktury. Přečtěte si o nejzajímavějších a nejužitečnějších závěrech pod řezem.

Jmenuji se Dima Bobylev, jsem technický ředitel SberMarket. Protože toto je první příspěvek na našem blogu, řeknu pár slov o sobě a společnosti. Loni na podzim jsem se zúčastnil soutěže pro mladé vůdce Runet. Pro soutěž I napsal povídku o tom, jak my ve SberMarket vidíme vnitřní kulturu a přístup k rozvoji služeb. A přestože se mi nepodařilo vyhrát soutěž, formuloval jsem si pro sebe základní principy rozvoje IT ekosystému.

Při řízení týmu je důležité pochopit a najít rovnováhu mezi tím, co podnik potřebuje, a potřebami každého jednotlivého vývojáře. Nyní SberMarket roste 13krát ročně, což ovlivňuje produkt, což vyžaduje, aby neustále zvyšoval objem a tempo vývoje. Navzdory tomu věnujeme vývojářům dostatek času na předběžnou analýzu a kvalitní kódování. Formovaný přístup pomáhá nejen při vytváření fungujícího produktu, ale také při jeho dalším škálování a vývoji. V důsledku tohoto růstu se SberMarket již stal lídrem mezi službami rozvozu potravin: denně doručíme asi 18 tisíc objednávek, ačkoli na začátku února jich bylo asi 3500 XNUMX.

Jednoho dne klient požádal kurýra SberMarket, aby mu doručil potraviny bezkontaktně - přímo na balkón

Ale pojďme ke specifikům. Během několika posledních měsíců jsme aktivně škálovali infrastrukturu naší společnosti. Tato potřeba byla vysvětlena vnějšími a vnitřními faktory. Spolu s rozšiřováním zákaznické základny vzrostl počet připojených prodejen z 90 na začátku roku na více než 200 v polovině května. Byli jsme samozřejmě připraveni, rezervovali jsme hlavní infrastrukturu a navíc jsme počítali s možností vertikálního i horizontálního škálování všech virtuálních strojů hostovaných v cloudu Yandex. Praxe však ukázala: "Všechno, co se může pokazit, se pokazí." A dnes se chci podělit o nejzajímavější situace, které se během těchto týdnů staly. Doufám, že naše zkušenosti budou pro vás užitečné.

Slave je v plné bojové pohotovosti

Ještě před začátkem pandemie jsme čelili nárůstu počtu požadavků na naše backend servery. Trend objednávání potravin na rozvoz domů začal nabírat na síle a se zavedením prvních sebeizolačních opatření kvůli COVID-19 pracovní zátěž během dne dramaticky narostla. Bylo potřeba rychle uvolnit hlavní servery hlavní databáze a přenést některé požadavky na čtení na replikované servery (slave).

Na tento krok jsme se předem připravili a na takový manévr již byly spuštěny 2 podřízené servery. Používaly se hlavně pro dávkové úlohy generování informačních kanálů pro výměnu dat s partnery. Tyto procesy vytvořily další zátěž a byly zcela správně vyřazeny z rovnice o několik měsíců dříve.

Protože replikace probíhala na Slave, drželi jsme se konceptu, že aplikace s nimi mohly pracovat pouze v režimu pouze pro čtení. Plán obnovy po havárii předpokládal, že v případě katastrofy bychom mohli jednoduše připojit Slave místo Master a přepnout všechny požadavky na zápis a čtení na Slave. Chtěli jsme však také použít repliky pro potřeby analytického oddělení, takže servery nebyly zcela přepnuty do stavu pouze pro čtení, ale každý hostitel měl vlastní sadu uživatelů a někteří měli práva zápisu pro ukládání mezivýsledků výpočtů.

Do určité úrovně zatížení jsme měli dostatek masteru pro zápis i čtení při zpracování http požadavků. V polovině března, právě když se Sbermarket rozhodl zcela přejít na práci na dálku, začalo naše RPS exponenciálně růst. Stále více našich klientů se dostávalo do sebeizolace nebo pracovalo z domova, což ovlivnilo naše ukazatele pracovní zátěže.

Výkon „master“ již nestačil, a tak jsme začali přenášet některé z nejtěžších požadavků na čtení do repliky. Pro transparentní směrování požadavků na zápis na master a čtení požadavků na slave jsme použili rubínový drahokam "Chobotnice" Vytvořili jsme speciálního uživatele s postfixem _readonly bez práv zápisu. Kvůli chybě v konfiguraci jednoho z hostitelů však některé požadavky na zápis odešly na podřízený server jménem uživatele, který měl příslušná práva.

Problém se neprojevil hned, protože... zvýšená zátěž zvýšila zpoždění otroků. Nekonzistentnost dat byla zjištěna ráno, když po nočních importech otroci „nestihli“ pána. Přičítali jsme to vysoké zátěži na samotnou službu a dovozy spojené se spuštěním nových prodejen. Odesílání dat s mnohahodinovým zpožděním však bylo nepřijatelné a přešli jsme procesy na druhý analytický slave, protože mělоvětší zdroje a nebyl zatížen požadavky na čtení (tím jsme si vysvětlili nedostatek zpoždění replikace).

Když jsme přišli na důvody „rozšíření“ hlavního otroka, analytický už selhal ze stejného důvodu. Navzdory přítomnosti dvou dalších serverů, na které jsme plánovali přenést zátěž v případě selhání masteru, se kvůli nešťastné chybě ukázalo, že v kritickou chvíli nebyl žádný dostupný.

Protože jsme ale nevyhazovali pouze databázi (restorative v té době trvalo asi 5 hodin), ale i snímek hlavního serveru, podařilo se nám repliku spustit do 2 hodin. Pravda, poté jsme se po dlouhou dobu potýkali s převalováním protokolu replikace (protože proces běží v režimu s jedním vláknem, ale to je úplně jiný příběh).

Závěr: Po takovém incidentu se ukázalo, že je nutné opustit praxi omezování psaní pro uživatele a prohlásit celý server pouze pro čtení. S tímto přístupem není pochyb o tom, že repliky budou dostupné v kritických časech.

Optimalizace i jednoho náročného dotazu může obnovit život databáze

Přestože katalog na webu neustále aktualizujeme, požadavky, které jsme odeslali na Slave servery, umožnily mírné zpoždění od Master. Doba, během které jsme objevili a odstranili problém otroků „náhle opuštění vzdálenosti“, byla víc než jen „psychologická bariéra“ (během této doby mohly být aktualizovány ceny a klienti by viděli zastaralá data) a byli jsme nuceni přepněte všechny požadavky na hlavní databázový server. Ve výsledku byl web pomalý... ale aspoň fungoval. A zatímco se Slave zotavoval, nezbývalo nám nic jiného než optimalizace.

Zatímco se Slave servery zotavovaly, minuty pomalu ubíhaly, Master zůstával přetížený a my jsme vložili veškeré své úsilí do optimalizace aktivních úloh podle „Paretova pravidla“: vybrali jsme TOP požadavky, které generují většinu zátěže, a začali ladit. . To bylo provedeno přímo za chodu.

Zajímavým efektem bylo, že nabité MySQL reagovalo i na nepatrné zlepšení procesů. Optimalizace několika dotazů, které produkovaly pouze 5 % celkového zatížení, již ukázala znatelné zatížení procesoru. Výsledkem bylo, že jsme byli schopni poskytnout přijatelnou zásobu zdrojů pro Master, aby mohl pracovat s databází a získat potřebný čas na obnovu replik.

Závěr: I malá optimalizace vám umožní „přežít“ pod přetížením několik hodin. To nám stačilo na obnovu serverů s replikami. Mimochodem, technickou stránku optimalizace dotazů probereme v některém z následujících příspěvků. Takže se prosím přihlaste k odběru našeho blogu, pokud to považujete za užitečné.

Organizovat sledování výkonu partnerských služeb

Zpracováváme objednávky od zákazníků, a proto naše služby neustále interagují s API třetích stran - to jsou brány pro odesílání SMS, platební platformy, směrovací systémy, geokodér, Federální daňová služba a mnoho dalších systémů. A když zátěž začala rapidně narůstat, začali jsme narážet na omezení API našich partnerských služeb, o kterých jsme dříve ani neuvažovali.

Neočekávané překročení kvót partnerských služeb může vést k výpadkům vašich vlastních. Mnoho rozhraní API blokuje klienty, kteří překračují limity, a v některých případech může příliš mnoho požadavků přetížit produkci partnera.

Když například rostl počet dodávek, doprovodné služby nezvládaly úkoly s jejich distribucí a určením tras. V důsledku toho se ukázalo, že objednávky byly provedeny, ale služba, která vytvořila trasu, nefungovala. Je třeba říci, že naši logistici dokázali za těchto podmínek téměř nemožné a jasná souhra týmu pomohla kompenzovat dočasné výpadky služeb. Je ale nereálné takový objem zakázek neustále ručně zpracovávat a po nějaké době bychom se potýkali s nepřijatelnou mezerou mezi objednávkami a jejich realizací.

Byla přijata řada organizačních opatření a sehraná práce týmu pomohla získat čas na domluvení nových podmínek a čekání na modernizaci služeb od některých partnerů. Existují další API, která se mohou pochlubit vysokou výdrží a nehoráznými sazbami v případě vysokého provozu. Na začátku jsme například použili jedno známé mapovací API pro určení adresy výdejního místa. Ale na konci měsíce jsme dostali uklizený účet za téměř 2 miliony rublů. Poté se rozhodli jej rychle vyměnit. Nebudu se zapojovat do reklamy, ale řeknu, že naše náklady se výrazně snížily.

Závěr: Je nutné sledovat provozní podmínky všech partnerských služeb a mít je na paměti. I když se dnes zdá, že jsou pro vás „s velkou rezervou“, neznamená to, že zítra se nestanou překážkou růstu. A samozřejmě je lepší si finanční podmínky zvýšených požadavků na službu domluvit předem.

Někdy se ukáže, že "Potřebujete více zlata"(c) nepomůže

Jsme zvyklí na „gagy“ v hlavní databázi nebo na aplikačních serverech, ale při škálování se mohou objevit problémy tam, kde nebyly očekávány. Pro fulltextové vyhledávání na webu používáme engine Apache Solr. Jak se zatížení zvyšovalo, zaznamenali jsme snížení doby odezvy a zatížení procesoru serveru již dosáhlo 100 %. Co by mohlo být jednodušší - dejme kontejneru se Solrem více zdrojů.

Místo očekávaného zvýšení výkonu server jednoduše „umřel“. Okamžitě se načetl na 100 % a reagoval ještě pomaleji. Zpočátku jsme měli 2 jádra a 2 GB RAM. Rozhodli jsme se udělat to, co obvykle pomáhá – dali jsme serveru 8 jader a 32 GB. Všechno se mnohem zhoršilo (jak a proč přesně vám řekneme v samostatném příspěvku).

Během pár dní jsme přišli na spletitost této problematiky a dosáhli optimálního výkonu s 8 jádry a 32 GB. Tato konfigurace nám dnes umožňuje pokračovat ve zvyšování zátěže, což je velmi důležité, protože růst není jen v klientech, ale i v počtu připojených prodejen – za 2 měsíce se jejich počet zdvojnásobil.

Závěr: Standardní metody jako „přidat více železa“ ne vždy fungují. Při škálování jakékoli služby tedy musíte dobře rozumět tomu, jak využívá zdroje, a předem otestovat její fungování v nových podmínkách.

Bezstavové je klíčem ke snadnému horizontálnímu škálování

Obecně platí, že náš tým se řídí známým přístupem: služby by neměly mít vnitřní stav (bezstavové) a měly by být nezávislé na prostředí provádění. To nám umožnilo vyrovnat se s nárůstem zatížení jednoduchým horizontálním škálováním. Ale měli jsme jednu výjimku - handler pro dlouhé úkoly na pozadí. Podílel se na odesílání e-mailů a SMS, zpracování událostí, generování zdrojů, importu cen a zásob a zpracování obrázků. Stalo se, že to záviselo na místním úložišti souborů a bylo v jediné kopii.

Když se zvýšil počet úloh ve frontě procesoru (a to se přirozeně stalo s nárůstem počtu objednávek), omezujícím faktorem se stal výkon hostitele, na kterém byl procesor a úložiště souborů. V důsledku toho se zastavila aktualizace sortimentu a cen, zasílání upozornění uživatelům a mnoho dalších kritických funkcí, které uvízly ve frontě. Tým Ops rychle migroval úložiště souborů na síťové úložiště podobné S3, což nám umožnilo získat několik výkonných strojů pro škálování procesoru úloh na pozadí.

Závěr: Pravidlo bez státní příslušnosti musí být dodržováno u všech složek bez výjimky, i když se zdá, že „tady rozhodně neodoláme“. Je lepší věnovat trochu času správné organizaci provozu všech systémů, než narychlo přepisovat kód a opravovat přetíženou službu.

7 zásad pro intenzivní růst

Navzdory dostupnosti dodatečné kapacity jsme v procesu růstu šlápli na několik chyb. Za tuto dobu se počet objednávek zvýšil více než 4krát. Nyní již dodáváme více než 17 000 objednávek denně v 62 městech a plánujeme geografické rozšíření ještě dále – v první polovině roku 2020 se očekává spuštění služby v celém Rusku. Abychom se vyrovnali s rostoucí pracovní zátěží, s ohledem na naše již plné kužely, vyvinuli jsme 7 základních principů pro práci v podmínkách neustálého růstu:

Řízení incidentů. V Jire jsme vytvořili nástěnku, kde se každý incident promítne do podoby lístku. To pomůže při skutečném stanovení priorit a provádění úloh souvisejících s incidenty. Koneckonců, v podstatě není děsivé dělat chyby, ale je děsivé dělat chyby dvakrát při stejné příležitosti. Pro případy, kdy se incidenty opakují dříve, než se podaří napravit příčinu, by měly být připraveny pokyny k akci, protože v době velkého zatížení je důležité reagovat rychlostí blesku.
Sledování požadované pro všechny prvky infrastruktury bez výjimky. Díky němu jsme byli schopni předvídat růst zátěže a správně vybrat „úzká místa“ pro prioritizaci eliminace. S největší pravděpodobností se při vysoké zátěži rozbije nebo začne zpomalovat vše, na co jste nikdy nepomysleli. Proto je nejlepší vytvořit nová upozornění ihned po výskytu prvních incidentů, abyste je mohli monitorovat a předvídat.
Správná upozornění prostě nutné, když se zatížení prudce zvýší. Nejprve musí nahlásit, co přesně je rozbité. Za druhé, upozornění by nemělo být mnoho, protože velké množství nekritických upozornění vede k úplnému ignorování všech upozornění.
Aplikace musí být bez státní příslušnosti. Jsme přesvědčeni, že by z tohoto pravidla neměly existovat žádné výjimky. Potřebujeme úplnou nezávislost na běhovém prostředí. K tomu můžete ukládat sdílená data do databáze nebo třeba přímo do S3. Ještě lépe dodržujte pravidla. https://12factor.net. Během prudkého nárůstu času prostě neexistuje způsob, jak optimalizovat kód a vy se budete muset vyrovnat se zátěží přímým zvýšením výpočetních zdrojů a horizontálním škálováním.
Kvóty a plnění externích služeb. S rychlým růstem může nastat problém nejen ve vaší infrastruktuře, ale také v externí službě. Nejotravnější je, když se to nestane kvůli selhání, ale kvůli dosažení kvót nebo limitů. Externí služby by se tedy měly škálovat stejně dobře jako vy.
Oddělte procesy a fronty. To velmi pomáhá, když dojde k zablokování jedné z bran. Nesetkali bychom se s prodlevami v přenosu dat, pokud by plné fronty na odesílání SMS nezasahovaly do výměny notifikací mezi informačními systémy. A bylo by jednodušší zvýšit počet pracovníků, kdyby pracovali odděleně.
Finanční reality. Když dojde k prudkému nárůstu datových toků, není čas přemýšlet o tarifech a předplatném. Musíte si je ale pamatovat, zvláště pokud jste malá firma. Vlastníkovi jakéhokoli API, stejně jako vašemu poskytovateli hostingu, může vzniknout velký účet. Je tedy třeba pečlivě číst smlouvy.

Závěr

Ne bez ztrát, ale přežili jsme tuto etapu a dnes se snažíme dodržovat všechny nalezené zásady a každý stroj má schopnost snadno zvýšit x4 výkon, aby se vyrovnal s nějakými nečekanými událostmi.

V následujících příspěvcích se podělíme o naše zkušenosti s vyšetřováním snížení výkonu v Apache Solr a také o optimalizaci dotazů a o tom, jak interakce s Federální daňovou službou pomáhá společnosti ušetřit peníze. Přihlaste se k odběru našeho blogu, ať vám nic neuteče, a řekněte nám v komentářích, zda jste měli podobné potíže při růstu návštěvnosti.