Artem Denisov ( , )
Badoo je největší seznamka na světě. V současnosti máme asi 330 milionů registrovaných uživatelů po celém světě. Co je ale v kontextu našeho dnešního rozhovoru mnohem důležitější, je to, že ukládáme asi 3 petabajty uživatelských fotografií. Každý den naši uživatelé nahrávají asi 3,5 milionu nových fotografií a zatížení čtením je přibližně 80 tisíc požadavků za sekundu. To je pro náš backend docela hodně a někdy jsou s tím potíže.
Budu mluvit o designu tohoto systému, který obecně ukládá a odesílá fotografie, a podívám se na to z pohledu vývojáře. Bude krátká retrospektiva, jak se to vyvíjelo, kde nastíním hlavní milníky, ale podrobněji budu mluvit jen o řešeních, která aktuálně používáme.
Nyní začneme.
Jak jsem řekl, bude to retrospektiva, a abychom to někde začali, vezměme si ten nejčastější příklad.
Máme společný úkol, potřebujeme přijímat, ukládat a odesílat uživatelské fotografie. V této podobě je úkol obecný, můžeme použít cokoliv:
- moderní cloudové úložiště,
- krabicové řešení, kterých je nyní také hodně;
- V našem datovém centru můžeme nastavit několik strojů a umístit na ně velké pevné disky a ukládat tam fotografie.
Badoo historicky – dnes i tehdy (v době, kdy bylo teprve v plenkách) – žije na svých vlastních serverech, uvnitř našich vlastních DC. Proto pro nás byla tato varianta optimální.
Právě jsme vzali několik strojů, nazvali je „fotografie“ a dostali jsme cluster, který ukládá fotografie. Ale zdá se, že něco chybí. Aby toto vše fungovalo, musíme si nějak určit, na jakém stroji budeme ukládat jaké fotografie. A tady také není potřeba otevírat Ameriku.
Do našeho úložiště přidáváme pole s informacemi o uživatelích. Toto bude shardovací klíč. V našem případě jsme to nazvali place_id a toto id místa ukazuje na místo, kde jsou uloženy fotografie uživatelů. Vyrábíme mapy.
V první fázi to lze dokonce provést ručně - říkáme, že fotografie tohoto uživatele s takovým místem přistane na takovém serveru. Díky této mapě vždy víme, kdy uživatel nahraje fotku, kam ji uložit a víme, odkud ji dát.
Jedná se o naprosto triviální schéma, které má však poměrně značné výhody. Prvním je, že je to jednoduché, jak jsem řekl, a druhým, že s tímto přístupem můžeme snadno horizontálně škálovat pouhým dodáním nových aut a jejich přidáním na mapu. Nemusíte dělat nic jiného.
Tak to u nás nějakou dobu bylo.
To bylo kolem roku 2009. Dodali auta, dodali...
A v určitém okamžiku jsme si začali všímat, že toto schéma má určité nevýhody. Jaké jsou nevýhody?
V první řadě je omezená kapacita. Nemůžeme na jeden fyzický server nacpat tolik pevných disků, kolik bychom chtěli. A to se postupem času a s růstem datasetu stalo určitým problémem.
A za druhé. Jedná se o atypickou konfiguraci strojů, protože takové stroje je obtížné znovu použít v některých jiných clusterech, jsou zcela specifické, tzn. měly by být výkonově slabé, ale zároveň s velkým pevným diskem.
To bylo vše pro rok 2009, ale v zásadě jsou tyto požadavky aktuální i dnes. Máme retrospektivu, takže v roce 2009 bylo s tímhle všechno úplně špatné.
A posledním bodem je cena.
Cena byla v té době velmi strmá a museli jsme hledat nějaké alternativy. Tito. potřebovali jsme nějak lépe využít jak prostor v datových centrech, tak fyzické servery, na kterých je toto vše umístěno. A naši systémoví inženýři zahájili rozsáhlou studii, ve které zhodnotili spoustu různých možností. Podívali se také na clusterové souborové systémy, jako je PolyCeph a Luster. Vyskytly se problémy s výkonem a docela obtížná obsluha. Odmítli. Snažili jsme se namontovat celý soubor dat přes NFS na každé auto, abychom jej nějak zvětšili. Čtení také šlo špatně, zkoušeli jsme různá řešení od různých prodejců.
A nakonec jsme se rozhodli pro využití tzv. Storage Area Network.
Jedná se o velké SHD, které jsou speciálně navrženy pro ukládání velkého množství dat. Jsou to police s disky, které se montují na finální optické výstupní stroje. Že. máme jakýsi fond strojů, docela malý, a tyto SHD, které jsou transparentní pro naši odesílací logiku, tzn. aby náš nginx nebo kdokoli jiný obsluhoval žádosti o tyto fotografie.
Toto rozhodnutí mělo zjevné výhody. Toto je SHD. Je zaměřen na ukládání fotografií. Vychází to levněji než pouhé vybavení strojů pevnými disky.
Druhé plus.
Tím je kapacita mnohem větší, tzn. můžeme pojmout mnohem více úložného prostoru v mnohem menším objemu.
Ale byly tu i nevýhody, které se objevily docela rychle. Jak rostl počet uživatelů a zatížení tohoto systému, začaly se objevovat problémy s výkonem. A problém je zde zcela zřejmý - jakýkoli SHD určený k ukládání mnoha fotografií v malém objemu zpravidla trpí intenzivním čtením. To ve skutečnosti platí pro jakékoli cloudové úložiště nebo cokoli jiného. Teď nemáme ideální úložiště, které by bylo nekonečně škálovatelné, dalo by se do něj nacpat cokoliv a velmi dobře by snášelo čtení. Zejména příležitostné čtení.
Stejně jako je tomu u našich fotografií, protože fotografie jsou požadovány nedůsledně a to velmi ovlivní jejich výkon.
I podle dnešních čísel, pokud někde dostaneme více než 500 RPS pro fotografie na počítači, ke kterému je připojeno úložiště, problémy již začínají. A bylo to pro nás dost špatné, protože počet uživatelů roste, věci se budou jen zhoršovat. To je potřeba nějak optimalizovat.
Abychom optimalizovali, rozhodli jsme se tehdy samozřejmě podívat na profil zatížení - co se obecně děje, co je třeba optimalizovat.
A tady nám všechno hraje do karet.
Už jsem řekl v prvním snímku: máme 80 tisíc požadavků na čtení za sekundu s pouhými 3,5 miliony uploadů za den. To znamená, že se jedná o rozdíl tří řádů. Je zřejmé, že čtení je potřeba optimalizovat a je prakticky jasné jak.
Je tu ještě jeden malý bod. Specifika služby jsou taková, že se člověk zaregistruje, nahraje fotku, pak se začne aktivně dívat na ostatní lidi, líbí se jim a je aktivně ukazován ostatním lidem. Pak si najde partnera nebo nenajde partnera, záleží, jak to dopadne, a přestane službu na chvíli používat. V tuto chvíli, kdy to používá, jsou jeho fotografie velmi horké - jsou žádané, prohlíží si je spousta lidí. Jakmile to přestane dělat, docela rychle vypadne z tolika vystavení ostatním lidem jako předtím a jeho fotografie nejsou téměř nikdy požadovány.
Tito. Máme velmi malý horký datový soubor. Zároveň je na něj ale spousta žádostí. A zcela zřejmým řešením je zde přidání mezipaměti.
Cache s LRU vyřeší všechny naše problémy. Co to děláme?
Před náš velký cluster s úložištěm přidáváme ještě jeden relativně malý, kterému se říká fotocache. Toto je v podstatě pouze cachovací proxy.
Jak to funguje zevnitř? Zde je náš uživatel, zde je úložiště. Všechno je stejné jako předtím. Co přidáme mezi?
Je to prostě stroj s fyzickým lokálním diskem, který je rychlý. To je například u SSD. A na tomto disku je uložena nějaká místní mezipaměť.
Jak to vypadá? Uživatel odešle žádost o fotografii. NGINX jej nejprve hledá v místní mezipaměti. Pokud ne, pak jednoduše proxy_pass do našeho úložiště, stáhněte si odtud fotografii a dejte ji uživateli.
Ale tohle je velmi banální a není jasné, co se děje uvnitř. Funguje to nějak takhle.
Cache je logicky rozdělena do tří vrstev. Když říkám „tři vrstvy“, neznamená to, že existuje nějaký složitý systém. Ne, toto jsou podmíněně pouze tři adresáře v systému souborů:
- Toto je vyrovnávací paměť, kam se ukládají fotografie právě stažené z proxy.
- Toto je horká mezipaměť, která ukládá aktuálně aktivně požadované fotografie.
- A cold cache, kde se fotky postupně vytlačují z horké cache, když na ně přijde méně požadavků.
Aby to fungovalo, musíme tuto keš nějak spravovat, musíme v ní přeskládat fotky atd. To je také velmi primitivní proces.
Nginx jednoduše zapíše do RAMDisk access.log pro každý požadavek, ve kterém uvede cestu k fotografii, kterou aktuálně obsluhoval (samozřejmě relativní cestu), a který oddíl byl obsloužen. Tito. může to být „fotka 1“ a pak buď vyrovnávací paměť, horká mezipaměť, studená vyrovnávací paměť nebo proxy.
Podle toho se musíme nějak rozhodnout, co s fotkou uděláme.
Na každém počítači běží malý démon, který neustále čte tento protokol a ukládá do paměti statistiky o použití určitých fotografií.
Prostě tam sbírá, nechává si počítadla a pravidelně dělá následující. Aktivně vyžádané fotografie, o které je mnoho požadavků, přesouvá do horké keše, ať jsou kdekoli.
Fotografie, které jsou požadovány zřídka a byly požadovány méně často, jsou postupně vytlačovány z horké mezipaměti do studené.
A když nám dojde místo v mezipaměti, jednoduše začneme bez rozdílu vše ze studené mezipaměti mazat. A mimochodem, tohle funguje dobře.
Aby se fotografie při proxyování do bufferu hned uložila, použijeme direktivu proxy_store a buffer je zároveň RAMDisk, tzn. pro uživatele to funguje velmi rychle. To se týká vnitřních částí samotného mezipaměti serveru.
Zbývající otázkou je, jak distribuovat požadavky na tyto servery.
Řekněme, že existuje shluk dvaceti úložných strojů a tří cachovacích serverů (takto se to stalo).
Musíme nějak určit, které požadavky jsou na které fotky a kam je umístit.
Nejběžnější možností je Round Robin. Nebo to udělat náhodou?
To má samozřejmě řadu nevýhod, protože bychom v takové situaci používali cache velmi neefektivně. Požadavky přistanou na některých náhodných počítačích: zde byly uloženy do mezipaměti, ale na dalším už tam nejsou. A pokud to všechno bude fungovat, bude to velmi špatné. I s malým počtem strojů v clusteru.
Potřebujeme nějak jednoznačně určit, kterému serveru přistane který požadavek.
Existuje banální způsob. Vezmeme hash z URL nebo hash z našeho shardingového klíče, který je v URL, a vydělíme ho počtem serverů. Bude pracovat? Vůle.
Tito. Máme 2% požadavek, například pro nějakou „example_url“ vždy přistane na serveru s indexem „XNUMX“ a cache bude neustále co nejlépe likvidována.
V takovém schématu je ale problém s reshardingem. Resharding - mám na mysli změnu počtu serverů.
Předpokládejme, že náš cachovací cluster již nezvládá a rozhodneme se přidat další stroj.
Přidejme.
Nyní je vše dělitelné ne třemi, ale čtyřmi. Takže téměř všechny klíče, které jsme měli, téměř všechny adresy URL nyní žijí na jiných serverech. Celá keš byla jednoduše na okamžik znehodnocena. Všechny požadavky padly na náš cluster úložiště, došlo k jeho špatnému stavu, selhání služby a nespokojení uživatelé. Nechci to dělat.
Ani tato varianta nám nevyhovuje.
Že. co bychom měli dělat? Musíme nějakým způsobem efektivně využívat mezipaměť, přikládat stejný požadavek na stejný server znovu a znovu, ale být odolní vůči reshardingu. A existuje takové řešení, není to tak složité. Říká se tomu konzistentní hašování.
Jak to vypadá?
Vezmeme nějakou funkci ze shardovacího klíče a rozložíme všechny jeho hodnoty na kruh. Tito. v bodě 0 se jeho minimální a maximální hodnoty sbíhají. Dále umístíme všechny naše servery do stejného kruhu přibližně tímto způsobem:
Každý server je definován jedním bodem a sektor, který k němu směřuje ve směru hodinových ručiček, je obsluhován tímto hostitelem. Když k nám přijdou požadavky, hned vidíme, že například požadavek A – má tam hash – a obslouží ho server 2. Žádost B – server 3. A tak dále.
Co se stane v této situaci během reshardingu?
Nezneplatníme celou mezipaměť jako dříve a neposouváme všechny klíče, ale posuneme každý sektor o kousek, aby se relativně vzato náš šestý server, který chceme přidat, vešel do volného místa a přidáme to tam.
Samozřejmě se v takové situaci vysunou i klávesy. Ale stěhují se mnohem slabší než předtím. A vidíme, že naše první dva klíče zůstaly na jejich serverech a server pro ukládání do mezipaměti se změnil pouze u posledního klíče. To funguje docela efektivně a pokud přidáváte nové hostitele postupně, pak zde není žádný velký problém. Postupně přidáváte a přidáváte, čekáte, až se cache zase zaplní, a vše funguje dobře.
Otázkou zůstává pouze odmítnutí. Předpokládejme, že nějaké auto je mimo provoz.
A opravdu bychom v tuto chvíli nechtěli tuto mapu regenerovat, zneplatnit část mezipaměti a tak dále, pokud by byl například počítač restartován a my bychom potřebovali nějak obsluhovat požadavky. Jednoduše uchováváme jednu záložní mezipaměť fotografií na každém místě, která slouží jako náhrada za jakýkoli počítač, který je aktuálně mimo provoz. A pokud se náhle některý z našich serverů stane nedostupným, provoz jde tam. Přirozeně tam nemáme žádnou cache, tzn. je zima, ale alespoň se zpracovávají požadavky uživatelů. Pokud se jedná o krátký interval, tak to prožíváme úplně v klidu. Jen je větší zatížení úložiště. Pokud je tento interval dlouhý, můžeme se již rozhodnout - tento server z mapy odstranit nebo ne, případně jej nahradit jiným.
Jde o systém ukládání do mezipaměti. Podívejme se na výsledky.
Zdálo by se, že zde není nic složitého. Ale tato metoda správy mezipaměti nám poskytla trik asi 98%. Tito. z těchto 80 tisíc požadavků za vteřinu dosáhne úložiště jen 1600 a to je úplně normální zátěž, klidně to vydrží, máme vždy rezervu.
Tyto servery jsme umístili do tří našich DC a získali jsme tři body přítomnosti – Praha, Miami a Hong Kong.
Že. jsou víceméně lokálně umístěny na každém z našich cílových trhů.
A jako příjemný bonus jsme dostali tuto cachovací proxy, na které je CPU vlastně nečinné, protože není tolik potřeba k obsluze obsahu. A tam jsme pomocí NGINX+ Lua implementovali spoustu utilitární logiky.
Můžeme například experimentovat s webp nebo progresivním jpegem (to jsou efektivní moderní formáty), vidět, jak to ovlivňuje návštěvnost, dělat nějaká rozhodnutí, povolit to pro určité země atd.; dynamicky měnit velikost nebo ořezávat fotografie za běhu.
To se hodí, když máte například mobilní aplikaci, která zobrazuje fotografie, a mobilní aplikace nechce plýtvat CPU klienta žádostí o velkou fotografii a následnou změnou velikosti na určitou velikost, aby se dala do pohled. Můžeme jednoduše dynamicky zadat některé parametry v podmíněné URL UPort a mezipaměť fotografií sama změní velikost fotografie. Zpravidla vybere velikost, kterou fyzicky máme na disku, co nejblíže požadované, a prodá ji v konkrétních souřadnicích.
Mimochodem, veřejně jsme zpřístupnili videozáznamy posledních pěti ročníků konference vývojářů vysoce zátěžových systémů . Sledujte, učte se, sdílejte a odebírejte .
Můžeme tam také přidat spoustu produktové logiky. Můžeme například přidávat různé vodoznaky pomocí parametrů URL, fotografie můžeme rozmazávat, rozmazávat nebo pixelovat. To je, když chceme ukázat fotku člověka, ale nechceme ukázat jeho obličej, to funguje dobře, vše je implementováno zde.
co jsme dostali? Máme tři body přítomnosti, dobrou rychlost triků a zároveň na těchto strojích nemáme nečinný CPU. Nyní se stal samozřejmě důležitějším než dříve. Musíme si dát silnější auta, ale stojí to za to.
To se týká vracení fotografií. Vše je zde zcela jasné a zřejmé. Myslím, že jsem neobjevil Ameriku, téměř každá CDN funguje tímto způsobem.
A s největší pravděpodobností by si sofistikovaný posluchač mohl položit otázku: proč prostě nezměnit všechno na CDN? Bylo by to přibližně stejné; všechny moderní CDN to umí. A důvodů je celá řada.
První jsou fotografie.
To je jeden z klíčových bodů naší infrastruktury a potřebujeme nad ním co největší kontrolu. Pokud se jedná o nějaký druh řešení od dodavatele třetí strany a nemáte nad ním žádnou moc, bude pro vás docela obtížné s ním žít, když máte velkou datovou sadu a když máte velmi velký tok požadavků uživatelů.
Dovolte mi uvést příklad. Nyní s naší infrastrukturou můžeme například v případě nějakých problémů nebo podzemních nárazů jít ke stroji a relativně vzato se tam makat. Můžeme přidat sbírku některých metrik, které jen potřebujeme, můžeme nějak experimentovat, vidět, jak to ovlivní grafy a tak dále. Nyní se o tomto clusteru mezipaměti shromažďuje mnoho statistik. A pravidelně se na to díváme a trávíme dlouhou dobu zkoumáním některých anomálií. Pokud by to bylo na straně CDN, bylo by to mnohem těžší ovládat. Nebo když se například stane nějaká nehoda, víme, co se stalo, víme, jak s tím žít a jak to překonat. Toto je první závěr.
Druhý závěr je také spíše historický, protože systém se vyvíjel dlouhou dobu a v různých fázích bylo mnoho různých obchodních požadavků, které ne vždy zapadají do konceptu CDN.
A pointa, která vyplývá z předchozího je
Je to proto, že na keškách fotografií máme hodně specifickou logiku, kterou nelze vždy na požádání přidat. Je nepravděpodobné, že by vám nějaká síť CDN na vaši žádost přidala nějaké vlastní věci. Například šifrování URL, pokud nechcete, aby klient mohl něco změnit. Chcete změnit adresu URL na serveru a zašifrovat ji a poté sem odeslat nějaké dynamické parametry?
Jaký závěr to naznačuje? V našem případě není CDN příliš dobrou alternativou.
A ve vašem případě, pokud máte nějaké specifické obchodní požadavky, pak můžete docela snadno implementovat to, co jsem vám sám ukázal. A to bude fungovat perfektně s podobným profilem zatížení.
Ale pokud máte nějaké obecné řešení a úkol není příliš konkrétní, můžete zcela bezpečně vzít CDN. Nebo pokud jsou pro vás čas a zdroje důležitější než kontrola.
A moderní CDN mají téměř vše, o čem jsem vám teď řekl. S výjimkou plus mínus některých funkcí.
Tady jde o rozdávání fotek.
Posuňme se nyní v naší retrospektivě trochu dopředu a povíme si něco o skladování.
2013 ubíhal.
Byly přidány servery pro ukládání do mezipaměti, problémy s výkonem zmizely. Vše je v pořádku. Dataset roste. V roce 2013 jsme měli asi 80 serverů připojených k úložišti a asi 40 mezipaměti v každém DC. Jedná se o 560 terabajtů dat na každém DC, tzn. celkem asi petabajt.
A s růstem datasetu začaly výrazně růst provozní náklady. co to mělo znamenat?
V tomto nakresleném diagramu - se SAN, s připojenými stroji a mezipamětí - je mnoho bodů selhání. Pokud jsme již dříve řešili selhání cachovacích serverů, vše bylo víceméně předvídatelné a srozumitelné, ale na straně úložiště bylo vše mnohem horší.
Zaprvé samotná Storage Area Network (SAN), která může selhat.
Za druhé je optikou připojen ke koncovým strojům. Mohou nastat problémy s optickými kartami a zapalovacími svíčkami.
Samozřejmě jich není tolik jako u samotné SAN, ale i to jsou body selhání.
Následuje samotný stroj, který je napojen na úložiště. Může také selhat.
Celkově máme tři body selhání.
Dále, kromě bodů selhání, je zde náročná údržba samotného úložiště.
Jedná se o složitý vícesložkový systém a systémoví inženýři s ním mohou mít problém pracovat.
A poslední, nejdůležitější bod. Pokud dojde k selhání v kterémkoli z těchto tří bodů, máme nenulovou šanci na ztrátu uživatelských dat, protože může dojít k selhání systému souborů.
Řekněme, že náš souborový systém je nefunkční. Jednak jeho obnova trvá dlouho – při velkém množství dat může trvat i týden. A za druhé, nakonec s největší pravděpodobností skončíme u hromady nesrozumitelných souborů, které bude potřeba nějak spojit do uživatelských fotografií. A riskujeme ztrátu dat. Riziko je poměrně vysoké. A čím častěji k takovým situacím dochází a čím více problémů v celém tomto řetězci vzniká, tím je toto riziko vyšší.
S tím se muselo něco udělat. A rozhodli jsme se, že stačí zálohovat data. To je vlastně samozřejmé a dobré řešení. Co jsme udělali?
Takto vypadal náš server, když byl předtím připojen k úložišti. Toto je jedna hlavní sekce, je to jen blokové zařízení, které ve skutečnosti představuje držák pro vzdálené úložiště přes optiku.
Právě jsme přidali druhou sekci.
Vedle něj jsme umístili druhé úložiště (naštěstí to není tak drahé, pokud jde o peníze), a nazvali jsme to záložní oddíl. Je také připojen přes optiku a je umístěn na stejném stroji. Potřebujeme ale data mezi nimi nějak synchronizovat.
Zde jednoduše vytvoříme asynchronní frontu poblíž.
Není moc zaneprázdněná. Víme, že nemáme dostatek záznamů. Fronta je pouze tabulka v MySQL, ve které jsou zapsány řádky jako „potřebujete zálohovat tuto fotografii“. Při jakékoli změně nebo nahrání zkopírujeme z hlavního oddílu do zálohy pomocí asynchronního nebo jen nějakého pracovníka na pozadí.
A tak máme vždy dvě konzistentní sekce. I když jedna část tohoto systému selže, vždy můžeme změnit hlavní oddíl se zálohou a vše bude fungovat dál.
Ale kvůli tomu se zátěž čtení značně zvyšuje, protože... kromě klientů, kteří čtou z hlavní sekce, protože se tam nejprve podívají na fotku (tam je novější), a pak ji hledají v záloze, pokud ji nenašli (ale NGINX to prostě dělá), náš systém je také plus záloha nyní čte z hlavního oddílu. Ne, že by to byla překážka, ale nechtěl jsem zvyšovat zátěž v podstatě jen tak.
A přidali jsme třetí disk, což je malé SSD, a nazvali jsme ho vyrovnávací paměť.
Jak to teď funguje.
Uživatel nahraje fotografii do vyrovnávací paměti, poté je do fronty vhozena událost, která indikuje, že je třeba ji zkopírovat do dvou sekcí. Zkopíruje se a fotografie zůstane nějakou dobu ve vyrovnávací paměti (řekněme jeden den) a teprve poté je odtud vymazána. To výrazně zlepšuje uživatelský zážitek, protože uživatel nahraje fotografii, zpravidla okamžitě začnou následovat požadavky, nebo sám aktualizoval stránku a obnovil ji. Vše ale závisí na aplikaci, která nahrávání provádí.
Nebo třeba další lidé, kterým se začal ukazovat, po této fotce okamžitě posílají žádosti. Ještě není v mezipaměti, první požadavek nastane velmi rychle. V podstatě to samé jako z fotokeše. Pomalé ukládání se v tom vůbec nehraje. A když je o den později vyčištěn, je již buď uložen do mezipaměti v naší mezipaměti, nebo jej s největší pravděpodobností již nikdo nepotřebuje. Tito. Uživatelská zkušenost se zde díky takovým jednoduchým manipulacím velmi dobře rozrostla.
No a hlavně: přestali jsme ztrácet data.
Řekněme, že jsme přestali potenciálně ztratit data, protože jsme je ve skutečnosti neztratili. Ale hrozilo nebezpečí. Vidíme, že toto řešení je samozřejmě dobré, ale je to trochu jako vyhlazení příznaků problému, místo jeho úplného vyřešení. A některé problémy zde zůstávají.
Za prvé, toto je bod selhání v podobě samotného fyzického hostitele, na kterém celá tato mašinérie běží; nezmizel.
Za druhé, stále existují problémy se SAN, jejich náročná údržba atd. zůstává. Ne že by to byl kritický faktor, ale chtěl jsem se pokusit nějak žít bez toho.
A udělali jsme třetí verzi (ve skutečnosti druhou) - rezervační verzi. jak to vypadalo?
Tohle to bylo -
Naše hlavní problémy jsou s tím, že se jedná o fyzického hostitele.
Za prvé, odstraňujeme SAN, protože chceme experimentovat, chceme vyzkoušet pouze místní pevné disky.
To už je rok 2014-2015 a v té době se situace s disky a jejich kapacitou v jednom hostiteli výrazně zlepšila. Rozhodli jsme se, proč to nezkusit.
A pak jednoduše vezmeme náš záložní oddíl a fyzicky jej přeneseme na samostatný počítač.
Tak dostáváme tento diagram. Máme dvě auta, která ukládají stejné datové sady. Vzájemně se kompletně zálohují a synchronizují data přes síť prostřednictvím asynchronní fronty ve stejném MySQL.
Proč to funguje dobře, je to, že máme málo záznamů. Tito. kdyby bylo psaní srovnatelné se čtením, možná bychom měli nějakou síťovou režii a problémy. Píše se málo, čte se – tato metoda funguje dobře, tzn. Fotografie mezi těmito dvěma servery kopírujeme jen zřídka.
Jak to funguje, když se podíváte trochu podrobněji.
Nahrát. Balancér jednoduše vybere náhodné hostitele s párem a nahraje do něj. Zároveň samozřejmě provádí zdravotní kontroly a hlídá, aby auto nevypadlo. Tito. nahraje fotky pouze na živý server a pak se to vše přes asynchronní frontu zkopíruje jeho sousedovi. S nahráváním je vše velmi jednoduché.
Úkol je trochu obtížnější.
Zde nám pomohla Lua, protože na vanilkovém NGINX může být obtížné vytvořit takovou logiku. Nejprve uděláme požadavek na první server, podíváme se, jestli tam fotka je, protože by se potenciálně dala nahrát třeba sousedovi, ale zatím sem nedorazila. Pokud tam ta fotka je, tak je to dobře. Okamžitě jej předáme klientovi a případně uložíme do mezipaměti.
Pokud tam není, jednoduše požádáme souseda a zaručeně jej odtamtud dostaneme.
Že. opět můžeme říci: mohou nastat problémy s výkonem, protože dochází k neustálým okružním jízdám - fotografie byla nahrána, není zde, podáváme dva požadavky místo jednoho, mělo by to fungovat pomalu.
V naší situaci to pomalu nefunguje.
V tomto systému shromažďujeme spoustu metrik a podmíněná chytrá míra takového mechanismu je asi 95 %. Tito. Prodleva této zálohy je malá a díky tomu máme téměř jistotu, že po nahrání fotografie ji pořídíme napoprvé a nebudeme muset nikam chodit dvakrát.
Takže co dalšího máme opravdu skvělého?
Dříve jsme měli hlavní zálohovací oddíl a z nich jsme četli postupně. Tito. Vždy jsme nejprve hledali na hlavním, a pak na záložním. Byl to jeden pohyb.
Nyní využíváme čtení ze dvou strojů najednou. Žádosti distribuujeme pomocí Round Robin. V malém procentu případů podáváme dvě žádosti. Celkově však nyní máme dvakrát více čtených zásob než dříve. A značně se snížila zátěž jak na odesílacích strojích, tak přímo na skladovacích strojích, které jsme v té době také měli.
Co se týče odolnosti proti chybám. Vlastně o to jsme hlavně bojovali. S odolností proti chybám zde vše dopadlo skvěle.
Jedno auto se porouchá.
Žádný problém! Systémový inženýr se možná ani v noci neprobudí, počká do rána, nic zlého se nestane.
Pokud i když tento stroj selže, fronta je mimo provoz, také nejsou žádné problémy, protokol se jednoduše nashromáždí nejprve na živém stroji a poté se přidá do fronty a poté na auto, které bude po nějaké době uvést do provozu.
To samé s údržbou. Jednoduše vypneme jeden ze strojů, ručně ho vytáhneme ze všech poolů, přestane přijímat provoz, uděláme nějakou údržbu, něco upravíme, pak to vrátíme do provozu a tato záloha se celkem rychle stihne. Tito. za den se prostoj jednoho vozu dožene během několika minut. To je opravdu velmi málo. S odolností proti chybám, znovu říkám, je zde vše v pohodě.
Jaké závěry lze vyvodit z tohoto schématu redundance?
Máme odolnost vůči chybám.
Snadné použití. Vzhledem k tomu, že stroje mají lokální pevné disky, je to z provozního hlediska pro inženýry, kteří s nimi pracují, mnohem pohodlnější.
Dostali jsme dvojnásobný příspěvek na čtení.
To je velmi dobrý bonus kromě odolnosti proti chybám.
Jsou tu ale i problémy. Nyní máme mnohem složitější vývoj některých funkcí, které s tím souvisí, protože systém se stal nakonec 100% konzistentním.
Musíme, řekněme, při nějaké práci na pozadí neustále přemýšlet: "Na jakém serveru teď běžíme?", "Opravdu je tady aktuální fotka?" atd. To je samozřejmě vše zabaleno a pro programátora, který píše obchodní logiku, je to transparentní. Ale přesto se objevila tato velká komplexní vrstva. Ale jsme připraveni se s tím smířit výměnou za dobroty, které jsme od toho dostali.
A zde opět vzniká nějaký konflikt.
Na začátku jsem řekl, že ukládat vše na místní pevné disky je špatné. A teď říkám, že se nám to líbilo.
Ano, skutečně, postupem času se situace hodně změnila a nyní má tento přístup mnoho výhod. Za prvé, získáme mnohem jednodušší ovládání.
Za druhé, je to produktivnější, protože nemáme tyto automatické řadiče nebo připojení k policím disků.
Je tam obrovské množství strojů a to je jen pár disků, které se tady na stroji skládají do nájezdu.
Existují však i nevýhody.
To je i při dnešních cenách přibližně 1,5krát dražší než použití SAN. Rozhodli jsme se proto směle nepřestavovat celý náš velký cluster na auta s lokálními pevnými disky a rozhodli jsme se opustit hybridní řešení.
Polovina našich strojů pracuje s pevnými disky (no, polovina ne – pravděpodobně 30 procent). A zbytek jsou stará auta, která mívala první rezervační schéma. Jednoduše jsme je znovu připojili, protože jsme nepotřebovali nová data ani nic jiného, jednoduše jsme přesunuli připojení z jednoho fyzického hostitele na dva.
A nyní máme velkou zásobu čtení a rozšířili jsme ji. Jestliže jsme dříve montovali jedno úložiště na jeden stroj, nyní na jeden pár namontujeme například čtyři. A funguje to dobře.
Pojďme si krátce shrnout, co se nám podařilo, za co jsme bojovali a zda se nám to podařilo.
Výsledky
Máme uživatele – celých 33 milionů.
Máme tři body přítomnosti – Praha, Miami, Hong Kong.
Obsahují cachovací vrstvu, kterou tvoří auta s rychlými lokálními disky (SSD), na kterých běží jednoduchá mašinérie od NGINX, jeho access.log a démoni Python, kteří toto vše zpracovávají a spravují cache.
Pokud si přejete, jste ve svém projektu, pokud pro vás fotografie nejsou tak důležité jako pro nás, nebo pokud je kompromis kontroly oproti rychlosti vývoje a nákladů na zdroje pro vás opačným směrem, můžete jej bezpečně nahradit s CDN, moderní CDN se jim daří dobře.
Dále přichází vrstva úložiště, na které máme shluky dvojic strojů, které se vzájemně zálohují, soubory se asynchronně kopírují z jednoho do druhého, kdykoli se změní.
Některé z těchto strojů navíc pracují s místními pevnými disky.
Některé z těchto strojů jsou připojeny k sítím SAN.
A na jedné straně je pohodlnější a o něco produktivnější, na druhé straně je výhodný z hlediska hustoty umístění a ceny za gigabajt.
To je takový stručný přehled architektury toho, co jsme dostali a jak se to všechno vyvíjelo.
Ještě pár tipů od kapitána, velmi jednoduchých.
Za prvé, pokud se náhle rozhodnete, že potřebujete nutně vylepšit vše ve své fotoinfrastruktuře, nejprve změřte, protože snad není potřeba nic vylepšovat.
Dovolte mi uvést příklad. Máme shluk strojů, které posílají fotky z příloh v chatech a tam to schéma funguje od roku 2009 a nikdo tím netrpí. Všichni jsou v pohodě, všem se líbí všechno.
Chcete-li měřit, nejprve pověsit spoustu metrik, podívat se na ně a pak se rozhodnout, s čím nejste spokojeni a co je třeba zlepšit. Abychom to mohli měřit, máme skvělý nástroj s názvem Pinba.
Umožňuje vám shromažďovat velmi podrobné statistiky z NGINX pro každý kód požadavku a odpovědi a rozložení časů – cokoliv chcete. Má vazby na všechny druhy různých analytických systémů a pak se na to můžete krásně podívat.
Nejprve jsme to změřili, pak jsme to vylepšili.
Dále. Optimalizujeme čtení pomocí mezipaměti, zápis pomocí shardingu, ale to je zřejmý bod.
Dále. Pokud právě začínáte budovat svůj systém, pak je mnohem lepší vytvářet fotografie jako neměnné soubory. Protože okamžitě přijdete o celou třídu problémů s neplatností mezipaměti, s tím, jak má logika najít správnou verzi fotky a tak dále.
Řekněme, že jste jich nahráli sto, pak je otočili a vytvořili z nich fyzicky odlišný soubor. Tito. není třeba přemýšlet: teď ušetřím trochu místa, zapíšu to do stejného souboru, změním verzi. To vždy nefunguje dobře a způsobuje později spoustu bolestí hlavy.
Další bod. O změně velikosti za chodu.
Dříve, když uživatelé nahráli fotku, okamžitě jsme nařezali spoustu velikostí pro všechny příležitosti, pro různé klienty a všechny byly na disku. Nyní jsme od toho upustili.
Nechali jsme pouze tři hlavní velikosti: malá, střední a velká. Jednoduše zmenšujeme všechno ostatní z velikosti, která je za tou, o kterou jsme byli požádáni v Uportu, jednoduše provedeme zmenšení a předáme to uživateli.
CPU cachovací vrstvy se zde ukazuje jako mnohem levnější, než kdybychom tyto velikosti neustále obnovovali na každém úložišti. Řekněme, že chceme přidat nový, bude to trvat měsíc – všude spusťte skript, který by to všechno dělal úhledně, aniž by zničil cluster. Tito. Pokud máte možnost si vybrat hned, je lepší udělat co nejméně fyzických velikostí, ale tak, aby alespoň nějaká distribuce byla řekněme tři. A vše ostatní lze jednoduše měnit za běhu pomocí připravených modulů. To vše je nyní velmi snadné a dostupné.
A přírůstkové asynchronní zálohování je dobré.
Jak naše praxe ukázala, toto schéma funguje skvěle se zpožděným kopírováním změněných souborů.
Poslední bod je také zřejmý. Pokud vaše infrastruktura nyní nemá takové problémy, ale existuje něco, co se může rozbít, určitě se to rozbije, až to bude trochu víc. Proto je lepší na to myslet předem a nemít s tím problémy. To je vše, co jsem chtěl říct.
Kontakty
»
»
Tato zpráva je přepisem jednoho z nejlepších projevů na konferenci vývojářů vysoce zátěžových systémů . Do konference HighLoad++ 2017 zbývá necelý měsíc.
Už to máme připravené , harmonogram se nyní aktivně tvoří.
V letošním roce pokračujeme ve zkoumání tématu architektur a škálování:
- / Igor Vasiliev
- / Dmitrij Egorov
- / Anatoly Plaskovsky
- / Roman Shekhovtsov, Alexey Gromatchikov
- / Philip Delgado
Některé z těchto materiálů používáme také v našem online školení o vývoji systémů s vysokou zátěží je řetězec speciálně vybraných dopisů, článků, materiálů, videí. Naše učebnice již obsahuje více než 30 unikátních materiálů. Připojit!
Zdroj: www.habr.com