Artem Denisov ( , )
Badoo je najväčšia zoznamka na svete. V súčasnosti máme okolo 330 miliónov registrovaných používateľov po celom svete. Čo je však v kontexte nášho dnešného rozhovoru oveľa dôležitejšie, je, že ukladáme približne 3 petabajty používateľských fotografií. Každý deň naši používatelia odovzdajú približne 3,5 milióna nových fotografií a zaťaženie čítaním je približne 80 tisíc žiadostí za sekundu. To je pre náš backend dosť veľa a niekedy sú s tým problémy.
Budem hovoriť o dizajne tohto systému, ktorý ukladá a odosiela fotografie všeobecne, a pozriem sa na to z pohľadu vývojára. O tom, ako sa to vyvíjalo, bude krátka retrospektíva, kde načrtnem hlavné míľniky, ale podrobnejšie poviem len o riešeniach, ktoré momentálne používame.
Teraz začnime.
Ako som povedal, toto bude retrospektíva a aby sme to niekde začali, uveďme si najbežnejší príklad.
Máme spoločnú úlohu, potrebujeme prijímať, ukladať a odosielať fotografie používateľov. V tejto forme je úloha všeobecná, môžeme použiť čokoľvek:
- moderné cloudové úložisko,
- krabicové riešenie, ktorých je teraz tiež veľa;
- V našom dátovom centre môžeme nastaviť niekoľko strojov a umiestniť na ne veľké pevné disky a ukladať tam fotografie.
Badoo historicky – teraz aj vtedy (v čase, keď bolo ešte len v plienkach) – žije na vlastných serveroch, v našich vlastných DC. Preto bola táto možnosť pre nás optimálna.
Práve sme vzali niekoľko strojov, nazvali sme ich „fotografie“ a dostali sme klaster, ktorý ukladá fotografie. Zdá sa však, že niečo chýba. Aby toto všetko fungovalo, musíme si nejako určiť, na akom stroji budeme ukladať aké fotografie. A tu tiež nie je potrebné otvárať Ameriku.
Do nášho úložiska pridávame nejaké pole s informáciami o používateľoch. Toto bude kľúč shardingu. V našom prípade sme to nazvali place_id a toto id miesta ukazuje na miesto, kde sú uložené fotografie používateľov. Vyrábame mapy.
V prvej fáze to možno urobiť aj ručne - hovoríme, že fotografia tohto používateľa s takýmto miestom pristane na takomto serveri. Vďaka tejto mape vždy vieme, kedy používateľ nahrá fotku, kam ju uložiť a vieme odkiaľ ju dať.
Toto je úplne triviálna schéma, ale má dosť významné výhody. Prvým je, že je to jednoduché, ako som už povedal, a druhým, že s týmto prístupom môžeme ľahko horizontálne škálovať jednoduchým dodaním nových áut a ich pridaním na mapu. Nemusíte robiť nič iné.
Tak to bolo u nás nejaký čas.
Bolo to okolo roku 2009. Dodali autá, dodali...
A v určitom okamihu sme si začali všimnúť, že táto schéma má určité nevýhody. Aké sú nevýhody?
V prvom rade je obmedzená kapacita. Nemôžeme na jeden fyzický server vtesnať toľko pevných diskov, koľko by sme chceli. A to sa postupom času a s rastom datasetu stalo istým problémom.
A po druhé. Ide o atypickú konfiguráciu strojov, keďže takéto stroje je ťažké opätovne použiť v niektorých iných klastroch, sú dosť špecifické, t.j. mali by byť výkonovo slabé, no zároveň s veľkým pevným diskom.
To bolo všetko pre rok 2009, ale v zásade sú tieto požiadavky aktuálne aj dnes. Máme retrospektívu, takže v roku 2009 bolo s týmto všetko úplne zlé.
A posledným bodom je cena.
Cena bola v tom čase veľmi vysoká a museli sme hľadať nejaké alternatívy. Tie. potrebovali sme nejako lepšie využiť priestor v dátových centrách aj fyzické servery, na ktorých je toto všetko umiestnené. A naši systémoví inžinieri začali veľkú štúdiu, v ktorej preskúmali množstvo rôznych možností. Pozreli sa aj na klastrované súborové systémy ako PolyCeph a Luster. Vyskytli sa problémy s výkonom a dosť náročná obsluha. Odmietli. Snažili sme sa namontovať celý súbor údajov cez NFS na každé auto, aby sme ho nejako zväčšili. Čítanie tiež išlo zle, skúšali sme rôzne riešenia od rôznych predajcov.
A nakoniec sme sa dohodli na používaní takzvanej Storage Area Network.
Ide o veľké SHD, ktoré sú špeciálne navrhnuté na ukladanie veľkého množstva dát. Sú to police s diskami, ktoré sa montujú na finálne optické výstupné stroje. To. máme akýsi súbor strojov, celkom malý, a tieto SHD, ktoré sú transparentné pre našu logiku odosielania, t.j. aby náš nginx alebo ktokoľvek iný obsluhoval žiadosti o tieto fotografie.
Toto rozhodnutie malo zjavné výhody. Toto je SHD. Je zameraná na ukladanie fotografií. Vychádza to lacnejšie ako jednoduché vybavenie strojov pevnými diskami.
Druhé plus.
Ide o to, že kapacita sa značne zväčšila, t.j. môžeme umiestniť oveľa viac úložného priestoru v oveľa menšom objeme.
Ale boli tu aj nevýhody, ktoré sa objavili pomerne rýchlo. Ako rástol počet používateľov a zaťaženie tohto systému, začali sa objavovať problémy s výkonom. A problém je tu celkom zrejmý - každý SHD určený na ukladanie mnohých fotografií v malom objeme spravidla trpí intenzívnym čítaním. V skutočnosti to platí pre akékoľvek cloudové úložisko alebo čokoľvek iné. Teraz nemáme ideálne úložisko, ktoré by bolo nekonečne škálovateľné, dalo by sa doň napchať čokoľvek a veľmi dobre by znášalo čítanie. Najmä príležitostné čítanie.
Ako je to aj v prípade našich fotografií, pretože fotografie sú požadované nekonzistentne a to výrazne ovplyvní ich výkon.
Dokonca aj podľa dnešných údajov, ak niekde dostaneme viac ako 500 RPS pre fotografie na počítači, ku ktorému je pripojené úložisko, problémy už začínajú. A bolo to pre nás dosť zlé, pretože počet používateľov rastie, veci sa budú len zhoršovať. Toto treba nejako optimalizovať.
Aby sme mohli optimalizovať, rozhodli sme sa vtedy, samozrejme, pozrieť sa na profil zaťaženia – čo sa vo všeobecnosti deje, čo treba optimalizovať.
A tu nám všetko hrá do karát.
Už som povedal na prvej snímke: máme 80 3,5 žiadostí o čítanie za sekundu s iba XNUMX miliónmi nahrávaní za deň. To znamená, že ide o rozdiel troch rádov. Je zrejmé, že čítanie treba optimalizovať a je prakticky jasné ako.
Je tu ešte jeden malý bod. Špecifiká služby sú také, že sa človek zaregistruje, nahrá fotografiu, potom sa začne aktívne pozerať na iných ľudí, páči sa im a aktívne sa zobrazuje iným ľuďom. Potom si nájde partnera alebo nenájde partnera, závisí to od toho, ako to dopadne, a na chvíľu prestane službu používať. V tejto chvíli, keď ho používa, sú jeho fotografie veľmi horúce – sú žiadané, prezerá si ich veľa ľudí. Len čo s tým prestane, celkom rýchlo prestane byť vystavený iným ľuďom ako predtým a jeho fotografie sa takmer nikdy nepožadujú.
Tie. Máme veľmi malý horúci súbor údajov. Zároveň je však na neho veľa žiadostí. A úplne samozrejmým riešením je pridanie vyrovnávacej pamäte.
Cache s LRU vyrieši všetky naše problémy. Čo robíme?
Pred náš veľký zhluk s úložiskom pridávame ešte jeden relatívne malý, ktorý sa nazýva fotoskrýše. Toto je v podstate iba server proxy na ukladanie do vyrovnávacej pamäte.
Ako to funguje zvnútra? Tu je náš používateľ, tu je úložisko. Všetko je ako predtým. Čo pridáme medzi?
Je to len stroj s fyzickým lokálnym diskom, ktorý je rýchly. To je napríklad pri SSD. A na tomto disku je uložená akási lokálna vyrovnávacia pamäť.
Ako to vyzerá? Používateľ odošle žiadosť o fotografiu. NGINX ho najprv hľadá v lokálnej vyrovnávacej pamäti. Ak nie, potom jednoducho proxy_pass do nášho úložiska, stiahnite si odtiaľ fotografiu a dajte ju používateľovi.
Ale toto je veľmi banálne a nie je jasné, čo sa deje vo vnútri. Funguje to nejako takto.
Cache je logicky rozdelená do troch vrstiev. Keď hovorím „tri vrstvy“, neznamená to, že existuje nejaký zložitý systém. Nie, toto sú podmienečne iba tri adresáre v súborovom systéme:
- Toto je vyrovnávacia pamäť, kam idú fotografie práve stiahnuté z proxy.
- Toto je horúca vyrovnávacia pamäť, ktorá ukladá aktuálne aktívne požadované fotografie.
- A studená vyrovnávacia pamäť, kde sa fotografie postupne vytláčajú z horúcej vyrovnávacej pamäte, keď na ne príde menej požiadaviek.
Aby to fungovalo, musíme túto kešku nejako spravovať, musíme v nej preusporiadať fotografie atď. Toto je tiež veľmi primitívny proces.
Nginx jednoducho pri každej požiadavke zapíše do RAMDisk access.log, v ktorom uvedie cestu k fotografii, ktorú aktuálne obslúžil (samozrejme, relatívnu cestu) a ktorý oddiel bol obsluhovaný. Tie. môže to byť „fotka 1“ a potom buď vyrovnávacia pamäť, horúca vyrovnávacia pamäť, studená vyrovnávacia pamäť alebo proxy.
Podľa toho sa musíme nejako rozhodnúť, čo s fotkou urobíme.
Na každom počítači máme spusteného malého démona, ktorý neustále číta tento protokol a ukladá do pamäte štatistiky o používaní určitých fotografií.
Jednoducho tam zbiera, uchováva počítadlá a pravidelne robí nasledovné. Aktívne žiadané fotografie, o ktoré je veľa žiadostí, presúva do hot cache, nech sú kdekoľvek.
Fotografie, ktoré sú žiadané zriedkavo a boli žiadané menej často, sa postupne vytláčajú z horúcej vyrovnávacej pamäte do studenej.
A keď nám dôjde miesto vo vyrovnávacej pamäti, jednoducho začneme z studenej vyrovnávacej pamäte všetko bez rozdielu mazať. A mimochodom, toto funguje dobre.
Na to, aby sa fotografia hneď pri proxyovaní do buffera uložila, použijeme direktívu proxy_store a buffer je zároveň RAMDisk, t.j. pre užívateľa to funguje veľmi rýchlo. Týka sa to vnútorných častí samotného servera vyrovnávacej pamäte.
Zostávajúca otázka je, ako distribuovať požiadavky na tieto servery.
Povedzme, že existuje zhluk dvadsiatich úložných strojov a troch vyrovnávacích serverov (takto sa to stalo).
Musíme nejako určiť, ktoré požiadavky sú na ktoré fotografie a kde ich máme umiestniť.
Najbežnejšou možnosťou je Round Robin. Alebo to urobiť náhodou?
To má samozrejme niekoľko nevýhod, pretože v takejto situácii by sme používali vyrovnávaciu pamäť veľmi neefektívne. Požiadavky pristanú na niektorých náhodných počítačoch: tu boli uložené do vyrovnávacej pamäte, ale na ďalšom už tam nie sú. A ak toto všetko bude fungovať, bude to veľmi zlé. Dokonca aj s malým počtom strojov v klastri.
Musíme nejako jednoznačne určiť, na ktorý server prijmeme ktorú požiadavku.
Existuje banálny spôsob. Zoberieme hash z adresy URL alebo hash z nášho shardingového kľúča, ktorý je v URL, a vydelíme ho počtom serverov. Bude pracovať? Will.
Tie. Máme 2% požiadavku, napríklad pre nejakú „example_url“ vždy pristane na serveri s indexom „XNUMX“ a vyrovnávacia pamäť sa bude neustále likvidovať čo najlepšie.
V takejto schéme je ale problém s preshardingom. Resharding – mám na mysli zmenu počtu serverov.
Predpokladajme, že náš cachovací klaster už nezvláda a rozhodneme sa pridať ďalší stroj.
Pridajme.
Teraz je všetko deliteľné nie tromi, ale štyrmi. Takže takmer všetky kľúče, ktoré sme mali, takmer všetky adresy URL teraz žijú na iných serveroch. Celá vyrovnávacia pamäť bola na chvíľu znehodnotená. Všetky požiadavky padli na náš klaster úložiska, došlo k poruche, zlyhaniu služby a nespokojným používateľom. Nechcem to robiť.
Táto možnosť nám tiež nevyhovuje.
To. Čo by sme mali urobiť? Musíme nejakým spôsobom efektívne využívať vyrovnávaciu pamäť, prikladať rovnakú požiadavku na ten istý server znova a znova, ale byť odolní voči reshardingu. A existuje také riešenie, nie je to také zložité. Hovorí sa tomu konzistentné hashovanie.
Ako to vyzerá?
Vezmeme nejakú funkciu z kľúča sharding a rozložíme všetky jeho hodnoty na kruh. Tie. v bode 0 sa jeho minimálne a maximálne hodnoty zbližujú. Ďalej umiestnime všetky naše servery do rovnakého kruhu približne týmto spôsobom:
Každý server je definovaný jedným bodom a sektor, ktorý k nemu smeruje v smere hodinových ručičiek, je obsluhovaný týmto hostiteľom. Keď k nám prídu požiadavky, hneď vidíme, že napríklad požiadavka A – má tam hash – a obsluhuje ju server 2. Požiadavka B – server 3. A tak ďalej.
Čo sa stane v tejto situácii počas reshardingu?
Neznehodnocujeme celú vyrovnávaciu pamäť ako doteraz a neposúvame všetky kľúče, ale posúvame každý sektor o kúsok tak, aby sa do voľného miesta vošiel, relatívne povedané, náš šiesty server, ktorý chceme pridať a pridáme to tam.
Samozrejme, v takejto situácii sa vysunú aj klávesy. Ale sťahujú sa oveľa slabšie ako predtým. A vidíme, že naše prvé dva kľúče zostali na ich serveroch a server vyrovnávacej pamäte sa zmenil iba na posledný kľúč. Funguje to pomerne efektívne a ak pridávate nových hostiteľov postupne, nie je tu žiadny veľký problém. Postupne pridávate a pridávate, počkáte, kým sa cache opäť naplní a všetko funguje dobre.
Jedinou otázkou zostáva odmietnutie. Predpokladajme, že nejaký druh auta je mimo prevádzky.
A naozaj by sme nechceli túto mapu v tejto chvíli regenerovať, zneplatniť časť vyrovnávacej pamäte a tak ďalej, ak by sa napríklad počítač reštartoval a my by sme potrebovali nejakým spôsobom obsluhovať požiadavky. Na každom mieste jednoducho uchovávame jednu záložnú vyrovnávaciu pamäť fotografií, ktorá slúži ako náhrada za akýkoľvek počítač, ktorý je momentálne mimo prevádzky. A ak sa náhle stane jeden z našich serverov nedostupným, prevádzka ide tam. Prirodzene, nemáme tam žiadnu cache, t.j. je zima, ale aspoň sa spracúvajú požiadavky používateľov. Ak ide o krátky interval, tak to prežívame úplne pokojne. Len je viac zaťažený úložný priestor. Ak je tento interval dlhý, môžeme sa už rozhodnúť - odstrániť tento server z mapy alebo nie, prípadne ho nahradiť iným.
Ide o systém ukladania do vyrovnávacej pamäte. Pozrime sa na výsledky.
Zdalo by sa, že tu nie je nič zložité. Ale táto metóda správy vyrovnávacej pamäte nám poskytla trik asi 98%. Tie. z tychto 80 tisic poziadaviek za sekundu sa do ulozenia dostane len 1600 a to je uplne bezna zataz, kludne to vydrzia, vzdy mame rezervu.
Tieto servery sme umiestnili do troch našich DC a získali sme tri body prítomnosti – Praha, Miami a Hong Kong.
To. sú viac-menej lokálne umiestnené na každom z našich cieľových trhov.
A ako príjemný bonus sme dostali túto cachovaciu proxy, na ktorej je CPU vlastne nečinné, pretože nie je až tak potrebné na obsluhu obsahu. A tam sme pomocou NGINX+ Lua implementovali veľa utilitárnej logiky.
Môžeme napríklad experimentovať s webp alebo progresívnym jpegom (to sú efektívne moderné formáty), vidieť, ako to ovplyvňuje návštevnosť, robiť nejaké rozhodnutia, povoliť to pre určité krajiny atď.; dynamicky meniť veľkosť alebo orezávať fotografie za behu.
Hodí sa to vtedy, keď máte napríklad mobilnú aplikáciu, ktorá zobrazuje fotografie a mobilná aplikácia nechce plytvať CPU klienta na vyžiadanie veľkej fotografie a jej následného zmenšovania na určitú veľkosť, aby sa vtlačila do výhľad. Môžeme jednoducho dynamicky špecifikovať niektoré parametre v podmienenej URL UPort a vyrovnávacia pamäť fotografií sama zmení veľkosť fotografie. Spravidla vyberie veľkosť, ktorú fyzicky máme na disku, čo najbližšie k žiadanej a v konkrétnych súradniciach ju predá.
Mimochodom, verejne sme sprístupnili videozáznamy posledných piatich ročníkov konferencie vývojárov vysokozáťažových systémov . Sledujte, učte sa, zdieľajte a odoberajte .
Môžeme tam pridať aj veľa logiky produktu. Môžeme napríklad pridávať rôzne vodoznaky pomocou parametrov URL, fotografie môžeme rozmazávať, rozmazávať či pixelovať. Toto je, keď chceme ukázať fotografiu osoby, ale nechceme ukázať jej tvár, funguje to dobre, všetko je tu implementované.
čo sme dostali? Získali sme tri body prítomnosti, dobrú rýchlosť trikov a zároveň na týchto strojoch nemáme nečinný procesor. Teraz sa, samozrejme, stal dôležitejším ako predtým. Musíme si dať silnejšie autá, ale stojí to za to.
Týka sa to vrátenia fotografií. Všetko je tu celkom jasné a zrejmé. Myslím, že som neobjavil Ameriku, takmer každá CDN funguje týmto spôsobom.
A s najväčšou pravdepodobnosťou si sofistikovaný poslucháč môže položiť otázku: prečo jednoducho nezmeniť všetko na CDN? Bolo by to približne rovnaké; všetky moderné siete CDN to dokážu. A existuje niekoľko dôvodov.
Prvým sú fotografie.
Toto je jeden z kľúčových bodov našej infraštruktúry a potrebujeme nad ňou čo najväčšiu kontrolu. Ak je to nejaký druh riešenia od dodávateľa tretej strany a nemáte nad ním žiadnu moc, bude pre vás dosť ťažké s ním žiť, keď máte veľkú množinu údajov a keď máte veľmi veľký tok. požiadaviek používateľov.
Uvediem príklad. Teraz, s našou infraštruktúrou, môžeme napríklad v prípade nejakých problémov alebo podzemných nárazov ísť k stroju a pomotať sa tam, relatívne povedané. Môžeme pridať kolekciu niektorých metrík, ktoré potrebujeme, môžeme nejako experimentovať, vidieť, ako to ovplyvňuje grafy atď. Teraz sa o tomto klastri ukladania do vyrovnávacej pamäte zhromažďuje veľa štatistík. A pravidelne sa na to pozeráme a trávime dlhý čas skúmaním niektorých anomálií. Ak by to bolo na strane CDN, bolo by to oveľa ťažšie ovládať. Alebo ak sa napríklad stane nejaká nehoda, vieme, čo sa stalo, vieme s tým žiť a ako to prekonať. Toto je prvý záver.
Druhý záver je tiež skôr historický, pretože systém sa vyvíjal dlhú dobu a v rôznych fázach existovalo veľa rôznych obchodných požiadaviek, ktoré nie vždy zapadajú do konceptu CDN.
A pointa, ktorá vyplýva z predchádzajúceho je
Je to preto, že na fotocache máme veľa špecifickej logiky, ktorú nie je možné vždy pridať na požiadanie. Je nepravdepodobné, že niektoré CDN vám na vašu žiadosť pridá nejaké vlastné veci. Napríklad šifrovanie URL, ak nechcete, aby klient mohol niečo zmeniť. Chcete zmeniť adresu URL na serveri a zašifrovať ju a potom sem poslať nejaké dynamické parametre.
Aký záver to naznačuje? V našom prípade CDN nie je veľmi dobrou alternatívou.
A vo vašom prípade, ak máte nejaké špecifické obchodné požiadavky, môžete celkom jednoducho implementovať to, čo som vám ukázal. A to bude perfektne fungovať s podobným profilom zaťaženia.
Ak však máte nejaké všeobecné riešenie a úloha nie je príliš konkrétna, môžete si CDN úplne bezpečne vziať. Alebo ak sú pre vás čas a zdroje dôležitejšie ako kontrola.
A moderné CDN majú takmer všetko, o čom som vám teraz hovoril. S výnimkou plus-mínus niektorých funkcií.
Ide o rozdávanie fotografií.
Posuňme sa teraz v našej retrospektíve trochu dopredu a povedzme si niečo o skladovaní.
Uplynul rok 2013.
Boli pridané servery s vyrovnávacou pamäťou, problémy s výkonom zmizli. Všetko je v poriadku. Dataset rastie. V roku 2013 sme mali približne 80 serverov pripojených k úložisku a približne 40 serverov s vyrovnávacou pamäťou v každom DC. Ide o 560 terabajtov dát na každom DC, t.j. celkovo asi petabajt.
A s rastom datasetu začali výrazne rásť prevádzkové náklady. čo to malo znamenať?
V tomto diagrame, ktorý je nakreslený - so SAN, s pripojenými strojmi a vyrovnávacími pamäťami - je veľa bodov zlyhania. Ak sme už predtým riešili výpadok cachovacích serverov, všetko bolo viac-menej predvídateľné a pochopiteľné, no na strane úložiska bolo všetko oveľa horšie.
Po prvé, samotná sieť SAN (Storage Area Network), ktorá môže zlyhať.
Po druhé, je pripojený cez optiku ku koncovým strojom. Môžu sa vyskytnúť problémy s optickými kartami a zapaľovacími sviečkami.
Samozrejme, nie je ich toľko ako pri samotnej SAN, ale aj tak sú to body zlyhania.
Nasleduje samotný stroj, ktorý je pripojený k úložisku. Môže tiež zlyhať.
Celkovo máme tri body zlyhania.
Ďalej, okrem bodov zlyhania, je tu náročná údržba samotného úložiska.
Ide o komplexný viaczložkový systém a systémoví inžinieri s ním môžu mať problém pracovať.
A posledný, najdôležitejší bod. Ak dôjde k zlyhaniu v ktoromkoľvek z týchto troch bodov, máme nenulovú šancu na stratu používateľských údajov, pretože môže dôjsť k zlyhaniu systému súborov.
Povedzme, že náš súborový systém je poškodený. Po prvé, jeho obnova trvá dlho – pri veľkom množstve dát môže trvať aj týždeň. A po druhé, nakoniec s najväčšou pravdepodobnosťou skončíme s kopou nezrozumiteľných súborov, ktoré bude potrebné nejako spojiť do používateľských fotografií. A riskujeme stratu dát. Riziko je dosť vysoké. A čím častejšie sa takéto situácie stávajú a čím viac problémov v celom tomto reťazci vzniká, tým je toto riziko vyššie.
S tým bolo treba niečo urobiť. A rozhodli sme sa, že stačí zálohovať dáta. Toto je vlastne jasné a dobré riešenie. čo sme urobili?
Takto vyzeral náš server, keď bol predtým pripojený k úložisku. Toto je jedna hlavná časť, je to len blokové zariadenie, ktoré v skutočnosti predstavuje držiak pre vzdialené ukladanie cez optiku.
Práve sme pridali druhú časť.
Vedľa neho sme umiestnili druhé úložisko (našťastie to nie je také drahé z hľadiska peňazí) a nazvali sme ho záložným oddielom. Je tiež pripojený cez optiku a nachádza sa na rovnakom stroji. Ale musíme medzi nimi nejako synchronizovať dáta.
Tu jednoducho vytvoríme asynchrónny rad v blízkosti.
Nie je veľmi zaneprázdnená. Vieme, že nemáme dostatok záznamov. Fronta je len tabuľka v MySQL, v ktorej sú napísané riadky ako „potrebujete zálohovať túto fotografiu“. Pri akejkoľvek zmene alebo nahrávaní kopírujeme z hlavného oddielu do zálohy pomocou asynchrónneho alebo len nejakého pracovníka na pozadí.
A tak máme vždy dve konzistentné sekcie. Aj keď jedna časť tohto systému zlyhá, vždy môžeme zmeniť hlavný oddiel pomocou zálohy a všetko bude fungovať ďalej.
Ale kvôli tomu sa zaťaženie čítania výrazne zvyšuje, pretože... okrem klientov, ktorí čítajú z hlavnej sekcie, pretože si tam fotku najprv pozrú (tam je novšia) a potom ju hľadajú v zálohe, ak ju nenašli (ale NGINX to robí), náš systém je tiež plus záloha teraz číta z hlavného oddielu. Nie že by to bola prekážka, ale nechcel som zvýšiť záťaž v podstate len tak.
A pridali sme tretí disk, čo je malý SSD disk, a nazvali sme ho vyrovnávacou pamäťou.
Ako to funguje teraz.
Používateľ odovzdá fotografiu do vyrovnávacej pamäte, potom sa do frontu vhodí udalosť, ktorá naznačuje, že ju treba skopírovať do dvoch sekcií. Skopíruje sa a fotografia zostane nejaký čas vo vyrovnávacej pamäti (povedzme deň) a až potom sa odtiaľ vymaže. To výrazne zlepšuje používateľskú skúsenosť, pretože používateľ odovzdá fotografiu, spravidla okamžite začnú nasledovať požiadavky, alebo sám aktualizoval stránku a obnovil ju. Všetko však závisí od aplikácie, ktorá nahrávanie vykonáva.
Alebo napríklad iní ľudia, ktorým sa začal ukazovať, po tejto fotke okamžite posielajú žiadosti. Zatiaľ nie je vo vyrovnávacej pamäti, prvá požiadavka nastane veľmi rýchlo. V podstate to isté ako z foto kešky. Pomalé ukladanie do toho vôbec nezasahuje. A keď je o deň neskôr vyčistený, je už buď uložený do vyrovnávacej pamäte na našej vrstve vyrovnávacej pamäte, alebo ho s najväčšou pravdepodobnosťou už nikto nepotrebuje. Tie. Používateľská skúsenosť sa tu vďaka takýmto jednoduchým manipuláciám veľmi dobre rozrástla.
No a čo je najdôležitejšie: prestali sme strácať dáta.
Povedzme, že sme sa zastavili potenciálne stratiť dáta, pretože sme ich naozaj nestratili. Ale hrozilo nebezpečenstvo. Vidíme, že toto riešenie je, samozrejme, dobré, ale je to trochu ako vyhladenie symptómov problému, namiesto jeho úplného vyriešenia. A niektoré problémy tu zostávajú.
Po prvé, toto je bod zlyhania vo forme samotného fyzického hostiteľa, na ktorom beží celá táto mašinéria; nezmizol.
Po druhé, stále existujú problémy so sieťami SAN, ich náročná údržba atď. Nebolo to tak, že by to bol kritický faktor, ale chcel som sa pokúsiť nejako žiť bez toho.
A urobili sme tretiu verziu (v skutočnosti druhú) - rezervačnú verziu. Ako to vyzeralo?
Toto to bolo -
Naše hlavné problémy sú s tým, že ide o fyzického hostiteľa.
Po prvé, odstraňujeme siete SAN, pretože chceme experimentovať, chceme vyskúšať iba lokálne pevné disky.
To je už rok 2014-2015 a vtedy sa situácia s diskami a ich kapacitou v jednom hostiteľovi výrazne zlepšila. Rozhodli sme sa, prečo to neskúsiť.
A potom jednoducho vezmeme náš záložný oddiel a fyzicky ho prenesieme na samostatný počítač.
Tak dostaneme tento diagram. Máme dve autá, ktoré uchovávajú rovnaké súbory údajov. Vzájomne sa úplne zálohujú a synchronizujú dáta cez sieť prostredníctvom asynchrónneho frontu v rovnakom MySQL.
Prečo to funguje dobre, je to, že máme málo záznamov. Tie. ak by bolo písanie porovnateľné s čítaním, možno by sme mali nejakú sieťovú réžiu a problémy. Málo sa píše, veľa číta – tento spôsob funguje dobre, t.j. Fotografie medzi týmito dvoma servermi kopírujeme len zriedka.
Ako to funguje, ak sa pozriete trochu podrobnejšie.
Nahrať. Balancér jednoducho vyberie náhodných hostiteľov s párom a nahrá do neho. Zároveň samozrejme robí zdravotné prehliadky a dáva pozor, aby auto nevypadlo. Tie. odovzdáva fotografie iba na živý server a potom sa prostredníctvom asynchrónneho frontu všetko skopíruje jeho susedovi. S nahrávaním je všetko veľmi jednoduché.
Úloha je trochu náročnejšia.
Tu nám pomohla Lua, pretože na vanilkovom NGINX môže byť ťažké urobiť takú logiku. Najprv zadáme požiadavku na prvý server, pozrieme sa, či tam fotka je, pretože potenciálne by sa dala nahrať napríklad susedovi, ale ešte sem nedorazila. Ak je tam fotka, tak je to dobre. Okamžite ho dávame klientovi a prípadne ho ukladáme do vyrovnávacej pamäte.
Ak tam nie je, jednoducho požiadame nášho suseda a zaručene to odtiaľ dostaneme.
To. opäť môžeme povedať: môžu sa vyskytnúť problémy s výkonom, pretože neustále dochádza k okružným cestám - fotografia bola nahraná, nie je tu, namiesto jednej robíme dve požiadavky, malo by to fungovať pomaly.
V našej situácii to pomaly nefunguje.
V tomto systéme zhromažďujeme množstvo metrík a podmienená inteligentná miera takéhoto mechanizmu je približne 95 %. Tie. Oneskorenie tejto zálohy je malé a vďaka tomu máme takmer istotu, že po nahratí fotografie ju spravíme na prvý krát a nebudeme musieť nikam chodiť dvakrát.
Takže čo máme ešte tak skvelé?
Predtým sme mali hlavný záložný oddiel a čítali sme z nich postupne. Tie. Vždy sme najskôr hľadali na hlavnom, až potom na záložnom. Bol to jeden pohyb.
Teraz využívame čítanie z dvoch strojov naraz. Žiadosti distribuujeme pomocou Round Robin. V malom percente prípadov podávame dve žiadosti. Celkovo však máme teraz dvakrát toľko čítania ako predtým. A značne sa znížila záťaž ako na odosielacích strojoch, tak aj priamo na skladovacích strojoch, ktoré sme v tom čase tiež mali.
Čo sa týka odolnosti voči chybám. Vlastne, o toto sme hlavne bojovali. S toleranciou chýb tu všetko dopadlo na výbornú.
Jedno auto sa pokazí.
Žiaden problém! Systémový inžinier sa možno ani v noci nezobudí, počká do rána, nič zlé sa nestane.
Ak aj keď tento stroj zlyhá, rad je mimo prevádzky, nie sú žiadne problémy, protokol sa jednoducho najskôr nahromadí na živom stroji a potom sa pridá do poradia a potom do auta, ktoré bude po určitom čase uviesť do prevádzky.
To isté s údržbou. Jednoducho vypneme jeden zo strojov, ručne ho vytiahneme zo všetkých bazénov, prestane prijímať prevádzku, urobíme nejakú údržbu, niečo upravíme, potom ho vrátime do prevádzky a táto záloha sa celkom rýchlo dobehne. Tie. za deň výpadok jedného auta dobehne v priebehu niekoľkých minút. Toto je naozaj veľmi málo. S toleranciou chýb, opakujem, tu je všetko v pohode.
Aké závery možno vyvodiť z tejto schémy prepúšťania?
Máme toleranciu chýb.
Jednoduché použitie. Keďže stroje majú lokálne pevné disky, je to z prevádzkového hľadiska oveľa pohodlnejšie pre inžinierov, ktorí s nimi pracujú.
Dostali sme dvojnásobný príspevok na čítanie.
To je veľmi dobrý bonus popri odolnosti voči chybám.
Ale sú tu aj problémy. Teraz máme oveľa komplexnejší vývoj niektorých funkcií, ktoré s tým súvisia, pretože systém sa stal nakoniec 100% konzistentným.
Musíme, povedzme, pri nejakej práci na pozadí neustále premýšľať: "Na akom serveri teraz bežíme?", "Naozaj je tu aktuálna fotografia?" atď. Toto je, samozrejme, všetko zabalené a pre programátora, ktorý píše obchodnú logiku, je to transparentné. Ale napriek tomu sa objavila táto veľká komplexná vrstva. Ale sme pripravení to strpieť výmenou za dobroty, ktoré sme z toho dostali.
A tu opäť vzniká nejaký konflikt.
Na začiatku som povedal, že ukladať všetko na lokálne pevné disky je zlé. A teraz hovorím, že sa nám to páčilo.
Áno, skutočne, časom sa situácia veľmi zmenila a teraz má tento prístup mnoho výhod. Po prvé, získame oveľa jednoduchšiu obsluhu.
Po druhé, je to produktívnejšie, pretože nemáme tieto automatické ovládače ani pripojenia k policiam diskov.
Je tam obrovské množstvo strojov a to je len pár diskov, ktoré sa tu na stroji poskladajú do nájazdu.
Existujú však aj nevýhody.
To je aj pri dnešných cenách približne 1,5-krát drahšie ako používanie SAN. Preto sme sa rozhodli smelo neprerobiť celý náš veľký klaster na autá s lokálnymi pevnými diskami a rozhodli sme sa opustiť hybridné riešenie.
Polovica našich strojov pracuje s pevnými diskami (no, nie polovica – pravdepodobne 30 percent). A zvyšok sú staré autá, ktoré mali prvú rezervačnú schému. Jednoducho sme ich znova namontovali, keďže sme nepotrebovali nové dáta ani nič iné, jednoducho sme presunuli pripojenia z jedného fyzického hostiteľa na dva.
A teraz máme veľkú zásobu čítania a rozšírili sme ju. Ak sme predtým namontovali jedno úložisko na jeden stroj, teraz na jeden pár namontujeme napríklad štyri. A funguje to dobre.
Poďme si v krátkosti zhrnúť, čo sa nám podarilo, za čo sme bojovali a či sa nám to podarilo.
Výsledky
Máme používateľov – až 33 miliónov.
Máme tri body prítomnosti – Praha, Miami, Hong Kong.
Obsahujú cachovaciu vrstvu, ktorú tvoria autá s rýchlymi lokálnymi diskami (SSD), na ktorých beží jednoduchá mašinéria od NGINX, jeho access.log a démoni Python, ktorí toto všetko spracovávajú a spravujú cache.
Ak si želáte, ste vo svojom projekte, ak pre vás fotografie nie sú také dôležité ako pre nás, alebo ak je kompromis kontroly oproti rýchlosti vývoja a nákladov na zdroje pre vás opačným smerom, môžete ho bezpečne nahradiť s CDN, moderné CDN sa im darí dobre.
Nasleduje úložná vrstva, na ktorej máme zhluky párov strojov, ktoré sa navzájom zálohujú, súbory sa asynchrónne kopírujú z jedného do druhého vždy, keď sa zmenia.
Navyše, niektoré z týchto strojov pracujú s lokálnymi pevnými diskami.
Niektoré z týchto počítačov sú pripojené k sieťam SAN.
A na jednej strane je to pohodlnejšie a o niečo produktívnejšie, na druhej strane je to výhodné z hľadiska hustoty umiestnenia a ceny za gigabajt.
Toto je taký stručný prehľad architektúry toho, čo sme dostali a ako sa to všetko vyvíjalo.
Niekoľko ďalších tipov od kapitána, veľmi jednoduchých.
Po prvé, ak sa zrazu rozhodnete, že potrebujete súrne vylepšiť všetko vo svojej fotoinfraštruktúre, najprv zmerajte, pretože snáď už netreba nič vylepšovať.
Uvediem príklad. Máme zhluk strojov, ktoré posielajú fotky z príloh v chatoch a tá schéma tam funguje od roku 2009 a nikto tým netrpí. Všetci sú v pohode, každému sa všetko páči.
Ak chcete merať, najprv si zaveste veľa metrík, pozrite sa na ne a potom sa rozhodnite, s čím nie ste spokojní a čo je potrebné zlepšiť. Aby sme to mohli merať, máme skvelý nástroj s názvom Pinba.
Umožňuje vám zbierať veľmi podrobné štatistiky z NGINX pre každú požiadavku a kód odpovedí a rozloženie časov – čokoľvek chcete. Má väzby na všetky druhy rôznych analytických systémov a potom sa na to môžete krásne pozrieť.
Najprv sme to zmerali, potom sme to vylepšili.
Ďalej. Optimalizujeme čítanie pomocou vyrovnávacej pamäte, zápis pomocou shardingu, ale to je zrejmé.
Ďalej. Ak práve začínate budovať svoj systém, potom je oveľa lepšie vytvárať fotografie ako nemenné súbory. Pretože okamžite prídete o celú triedu problémov s neplatnosťou cache, s tým, ako má logika nájsť správnu verziu fotografie atď.
Povedzme, že ste ich nahrali sto, potom ste to otočili, aby to bol fyzicky odlišný súbor. Tie. nie je potrebné premýšľať: teraz ušetrím trochu miesta, zapíšem ho do rovnakého súboru, zmením verziu. Toto vždy nefunguje dobre a neskôr spôsobuje veľa bolestí hlavy.
Ďalší bod. O zmene veľkosti za behu.
Predtým, keď používatelia odovzdali fotografiu, okamžite sme vyrezali veľa veľkostí na všetky príležitosti, pre rôznych klientov a všetky boli na disku. Teraz sme od toho upustili.
Ponechali sme len tri hlavné veľkosti: malú, strednú a veľkú. Jednoducho zmenšujeme všetko ostatné z veľkosti, ktorá je za tou, o ktorú nás požiadali v Uporte, jednoducho urobíme zmenšenie a dáme to používateľovi.
CPU vrstvy vyrovnávacej pamäte sa tu ukazuje ako oveľa lacnejšie, ako keby sme tieto veľkosti neustále obnovovali na každom úložisku. Povedzme, že chceme pridať nový, bude to trvať mesiac – všade spustite skript, ktorý by to všetko urobil úhľadne, bez zničenia klastra. Tie. Ak máte možnosť si vybrať hneď, je lepšie urobiť čo najmenej fyzických veľkostí, ale tak, aby aspoň nejaké rozloženie boli povedzme tri. A všetko ostatné sa dá jednoducho meniť za behu pomocou hotových modulov. Všetko je teraz veľmi jednoduché a dostupné.
A prírastkové asynchrónne zálohovanie je dobré.
Ako ukázala naša prax, táto schéma funguje skvele s oneskoreným kopírovaním zmenených súborov.
Posledný bod je tiež zrejmý. Ak vaša infraštruktúra teraz nemá takéto problémy, ale existuje niečo, čo sa môže zlomiť, určite sa to pokazí, keď bude trochu viac. Preto je lepšie na to myslieť vopred a nemať s tým problémy. To je všetko, čo som chcel povedať.
kontakty
»
»
Táto správa je prepisom jedného z najlepších prejavov na konferencii vývojárov vysoko zaťažených systémov . Do konferencie HighLoad++ 2017 zostáva menej ako mesiac.
Už to máme pripravené , harmonogram sa teraz aktívne tvorí.
Tento rok pokračujeme v skúmaní témy architektúr a škálovania:
- / Igor Vasiliev
- / Dmitrij Egorov
- / Anatolij Plaskovskij
- / Roman Shekhovtsov, Alexey Gromatchikov
- / Philip Delgado
Niektoré z týchto materiálov používame aj v našom online školiacom kurze o vývoji systémov s vysokou záťažou je reťazec špeciálne vybraných listov, článkov, materiálov, videí. Naša učebnica už obsahuje viac ako 30 unikátnych materiálov. Pripojte sa!
Zdroj: hab.com