Artem Denisov ( , )
A Badoo a világ legnagyobb társkereső oldala. Jelenleg körülbelül 330 millió felhasználónk van világszerte. De ami a mai beszélgetés szempontjából sokkal fontosabb, az az, hogy körülbelül 3 petabájt felhasználói fénykép van tárolva nálunk. Naponta körülbelül 3,5 millió új fénykép kerül feltöltésre a felhasználóink által, és az olvasási terhelés körülbelül 80 ezer lekérdezés másodpercenként. Ez elég sok a backend számára, és néha nehézségeink adódnak vele.
Beszélni fogok a rendszer tervezéséről, amely a fényképeket tárolja és szolgáltatja az egészben, és bemutatom a fejlesztők nézőpontját. A fejlődéséről egy rövid visszatekintést fogok adni, ahol a legfontosabb mérföldköveket kiemelem, de a részletekben már csak azokról a megoldásokról fogok beszélni, amelyeket jelenleg használunk.
Most pedig kezdjük el.
Ahogy már mondtam, ez egy visszatekintés lesz, és hogy legyen mivel kezdeni, nézzük meg a legbanálisabb példát.
Van egy közös feladatunk, el kell fogadnunk, tárolnunk és ki kell adnunk a felhasználók fényképeit. Így ez a feladat általános, bármilyen megoldást használhatunk:
- modern felhő alapú tárolót,
- dobozos megoldásokat, amelyekből most is rengeteg van;
- beállíthatunk több gépet a saját adatközpontunkban, nagy merevlemezekkel, és ott tárolhatjuk a fényképeket.
A Badoo történelmileg — most is, és akkor is (amikor ez csak kezdődött) — a saját szerverein működik, a saját adatközpontjainkban. Ezért számunkra ez az opció volt az optimális.
Egyszerűen vettünk néhány gépet, elneveztük őket «photos»-nak, és lett egy klaszterünk, ami a fényképeket tárolja. De úgy tűnik, valami hiányzik. Ahhoz, hogy mindez működjön, valamilyen módon meg kell határoznunk, hogy melyik gépen mely fényképeket fogunk tárolni. És itt sem kell felfedezni Amerikát.
Hozzáadunk a felhasználói információkat tartalmazó tárolónkhoz egy mezőt. Ez lesz a shardolási kulcs. A mi esetünkben ezt place_id-nak neveztük el, és ez az id jelöli a helyet, ahol a felhasználók fényképei tárolva vannak. Térképeket készítünk.
Az első szakaszban ezt akár manuálisan is el lehet végezni – azt mondjuk, hogy ennek a felhasználónak a fényképe ezzel a helyszínnel egy ilyen szerverre fog érkezni. Ennek a térképnek köszönhetően mindig tudjuk, mikor tölt fel a felhasználó egy fényképet, hova kell azt menteni, és tudjuk, honnan kell átadni.
Ez egy teljesen triviális séma, de elég jelentős előnyei vannak. Az első – ahogyan már mondtam, hogy egyszerű, a második pedig az, hogy ezzel a megközelítéssel könnyen vízszintesen skálázhatunk, egyszerűen új gépek bevonásával és ezek hozzáadásával a térképhez. Másra nincs szükség.
Így telt az idő nálunk.
Ez valamikor 2009 körül történt. Jöttek a gépek, szállították őket...
És egy idő után észrevettük, hogy ennek a sémának bizonyos hátrányai vannak. Milyen hátrányok?
Elsősorban a korlátozott kapacitás. Egy fizikai szerverre nem tudunk annyi merevlemezt beszorítani, mint szeretnénk. Ez idővel és a dataset növekedésével problémát jelentett.
Másodszor. Ez egy atypikus gépkonfiguráció, mivel ezeket a gépeket nehezen lehet újrahasználni más klaszterekben, elég specifikusak, azaz teljesítményben gyengéknek kell lenniük, de közben nagy merevlemezzel rendelkezniük.
Ez mind 2009-re vonatkozik, de ezek az igények alapvetően ma is aktuálisak. Van retrospektívánk, ezért 2009-ben igazán nem volt minden rendben ezzel kapcsolatban.
És az utolsó pont – az ár.
Akkoriban az ár nagyon borsos volt, és alternatívákat kellett keresnünk. Vagyis jobban kellett hasznosítani a helyet az adatközpontokban és magukat a fizikai szervereket, amelyeken mindez elhelyezkedett. A rendszer mérnökeink nagy kutatásba kezdtek, amely során számos különböző lehetőséget áttekintettek. Fájlklaszterező rendszereket néztek, mint a PolyCeph és Lustre. Ott teljesítményproblémák voltak, és elég nehéz volt az üzemeltetés. Lemondtak róla. Megpróbálták az egész datasetet NFS-en keresztül csatlakoztatni minden géphez, hogy így valahogy skálázzanak. Az olvasással is problémák adódtak, különböző megoldásokat próbálgattak különböző beszállítóktól.
Végül pedig arra állapodtunk meg, hogy elkezdtük használni a úgynevezett Storage Area Network-ot.
Ezek olyan nagy SHD-k, amelyek kifejezetten nagy mennyiségű adat tárolására vannak kialakítva. Ezek olyan lemezekből álló polcok, amelyek végtermék-kiadó gépekre vannak csatlakoztatva optikán keresztül. Így tehát van egy viszonylag kicsi gépcsoportunk, és ezek a SHD-k átláthatóak a kiadási logikánk számára, azaz a nginx-ünk vagy bárki más számára, és kiszolgálják az ezekkel a fényképekkel kapcsolatos kéréseket.
Ennek a megoldásnak voltak nyilvánvaló előnyei. Ez egy SHD. Kifejezetten fotók tárolására lett tervezve. Ez olcsóbbá válik, mintha egyszerűen beállítanánk gépeket merevlemezekkel.
A második előny.
Az, hogy a kapacitás sokkal nagyobbá vált, tehát sokkal több tárolóhelyet tudunk elhelyezni sokkal kisebb térfogatban.
De hátrányok is voltak, amelyek meglehetősen gyorsan napvilágra kerültek. A felhasználók és a rendszerre nehezedő terhelés növekedésével teljesítménybeli problémák kezdtek jelentkezni. A probléma itt meglehetősen nyilvánvaló - bármely SHD, amelyet sok fénykép tárolására terveztek kis térfogatban, általában szenved az intenzív olvasástól. Ez valójában érvényes bármely felhőalapú tárolóra vagy bármilyen dologra. Jelenleg nem létezik olyan ideális tároló, amely végtelenül skálázható lenne, amelybe bármit be lehetne dugni, és nagyon jól elviselné az olvasást. Különösen a véletlenszerű olvasásokkal.
Ahogyan a fényképeink esetében is, mert a fényképeket nem sorozatosan kérik le, és ez nagyon erősen befolyásolja a teljesítményüket.
Már a mai adatok alapján is, ha már több mint 500 RPS esik ki a fényképekhez egy gépen, amelyhez a tároló csatlakozik, már problémák kezdődnek. Ez számunkra elég rossz volt, mert a felhasználók száma növekszik, és minden csak rosszabbodnia kell. Ezt valahogy optimalizálni kell.
Az optimalizálás érdekében akkor úgy döntöttünk, hogy nyilvánvalóan megnézzük a terhelési profilt - mi történik egyáltalán, mit kell optimalizálni.
És itt minden a kezünkre játszik.
Az első dián már említettem: 80 ezer olvasási kérésünk van másodpercenként, mindössze 3,5 millió feltöltés mellett naponta. Tehát ez három nagyságrend különbség. Nyilvánvaló, hogy az olvasást kell optimalizálni, és gyakorlatilag világos, hogyan.
Van még egy kis részlet. A szolgáltatás jellege olyan, hogy az ember regisztrál, feltölt egy fotót, majd aktívan nézi más embereket, lájkolja őket, és őt is aktívan mutatják másoknak. Aztán talál magának párt, vagy nem talál párt, ahogy alakul, és egy időre abbahagyja a szolgáltatás használatát. Abban a pillanatban, amikor ő használja, a fotói nagyon keresettek – sok ember nézi őket. Amint abbahagyja, elég gyorsan kiesik a korábbi intenzív megjelenítésekből mások számára, és a fotói iránti kereslet gyakorlatilag megszűnik.
Ezért nekünk nagyon kicsi, forró adatállományunk van. De e mögött rengeteg kérés áll. És egyértelmű megoldásként felmerül, hogy hozzá kellene adni egy cache-t.
Az LRU cache megoldja minden problémánkat. Mit teszünk?
Hozzáadunk a nagy tároló klaszterünk elé még egy viszonylag kis méretűt, amit fotókészletnek (photoscache) nevezünk. Ez lényegében csak egy cache proxy.
Hogyan működik ez belülről? Itt van a felhasználónk, itt a tároló. Minden úgy, mint régen. Mit adunk hozzá közéjük?
Ez egyszerűen egy gép, amelynek fizikailag helyi diszkje van, ami gyors. Ez SSD, mondjuk. És ezen a diszken tárolunk valamilyen lokális cache-t.
Hogyan néz ez ki? A felhasználó kér egy fotót. Az NGINX először a helyi cache-ben keresi. Ha ott nincs, akkor proxy_pass-on keresztül azonnal a tárolóra hivatkozik, letölti onnan a fényképet, és átadja azt a felhasználónak.
De ez nagyon egyszerűen és érthetetlenül hangzik, hogy mi történik belül. Ez körülbelül így működik.
A cache logikailag három rétegre van osztva. Amikor azt mondom, hogy „három réteg”, ez nem jelenti, hogy ott bonyolult rendszer lenne. Nem, ez papíron csupán három mappa a fájlrendszerben:
- Ez a buffer, ahová a proxy-ból éppen feltöltött fényképek kerülnek.
- Ez a forró cache, amelyben aktívan keresett fényképek találhatók.
- És a hideg cache, ahová a fényképeket fokozatosan kiszorítják a forróból, amikor kevesebb kérés érkezik hozzájuk.
Ahhoz, hogy ez működjön, valamilyen módon kezelni kell ezt a cache-t, át kell helyezni fényképeket benne stb. Ez is egy nagyon primitív folyamat.
Az Nginx minden egyes kérésről feljegyzi az access.log-ot a RAMDisk-re, amelyben megadja a fénykép elérési útját, amelyet éppen kiszolgált (természetesen relatív útvonal), és azt is, hogy milyen szegmenssel kezelték. Tehát ott lehet írva, hogy „fotó 1”, majd jöhet a puffertároló, a forró cache, a hideg cache vagy a proxy.
Ez alapján valahogy meg kell hoznunk a döntést, hogy mi történjen a fényképpel.
Minden gépen fut egy kis daemon, amely folyamatosan olvassa ezt a logot, és a saját memóriájában tárolja a különféle fényképek felhasználási statisztikáit.
Csak összegyűjti az adatokat, számlálókat vezet, és időközönként végrehajtja a következő lépéseket. Az aktívan kért fényképeket, amelyekre sok kérés érkezik, áthelyezi a forró cache-be, függetlenül attól, hogy hol helyezkednek el.
Azokat a fényképeket, amelyeket ritkán kérnek és egyre ritkábban kérnek, fokozatosan kiszorítja a forró cache-ből a hidegbe.
És amikor a cache-ben elfogy a hely, egyszerűen mindent elkezdünk törölni a hideg cache-ből válogatás nélkül. Ez egyébként jól működik.
Ahhoz, hogy a fénykép azonnal tárolódjon a proxyzálás során a puffertárolóba, a proxy_store direktívát használjuk, és a puffertároló is RAMDisk, tehát a felhasználónak ez nagyon gyorsan működik. Ez a cache szerver belső működésével kapcsolatban.
Nyitott kérdés maradt, hogyan osszuk el a kéréseket ezek között a szerverek között.
Tegyük fel, hogy van egy húsz tároló gépből álló klaszter és három cache szerver (így alakult).
Valamilyen módon meg kell határoznunk, hogy mely kérés melyik fénykéhez tartozik és hova irányítsuk őket.
A legegyszerűbb lehetőség a Round Robin. Vagy véletlenszerűen kell ezt csinálni?
Ez nyilvánvalóan számos hátránnyal jár, mert ebben az esetben nagyon hatékonytalanul fogjuk használni a cache-t. A kérések véletlenszerű gépekre fognak érkezni: itt cache-elték, a szomszédos gépen pedig már nincs meg. És ha működik, akkor is nagyon rosszul fog működni. Még egy kis gépsor esetén is.
Valamilyen módon egyértelműen meg kell határoznunk, hogy melyik szerverre irányítsunk egy adott kérést.
Van egy egyszerű módszer. Kivesszük az URL hash-ét vagy a shard key hash-ét, amely az URL-ben található, és osztjuk a szerverek számával. Működni fog? Működni fog.
Tehát nálunk százszázalékos kérés van, például egy „example_url” mindig a „2” azonosítójú szerverre érkezik, és a cache folyamatosan a lehető legjobban hasznosul.
De egy probléma merül fel a re-sharding során. Re-sharding — itt az a lényeg, hogy megváltoztatjuk a szerverek számát.
Tegyük fel, hogy a cache-ünk nem bírja a terhelést, és úgy döntöttünk, hogy hozzáadunk még egy gépet.
Hozzáadjuk.
Most már nem háromra, hanem négyre osztunk. Így szinte minden kulcsunk, ami korábban volt, szinte minden URL most más szervereken éli életét. Az összes cache azonnal érvénytelenítve lett. Minden kérés a cluster-storage-unkra zúdult, ami miatt túlterhelt lett, leállt a szolgáltatás, és elégedettlen felhasználók keletkeztek. Ezt nem akarjuk.
Ez a megoldás nekünk sem felel meg.
Tehát mit kell tennünk? Valahogy hatékonyan kell használnunk a cache-t, folyamatosan egy kérésnek ugyanarra a szerverre kell landolnia, de ugyanakkor rezilienseknek kell lennünk a re-shardinggal szemben. Van ilyen megoldás, nem is olyan bonyolult. Ezt hívják következetes hashelésnek.
Hogy néz ez ki?
Fogunk egy funkciót a shard-azonosítóból, és elkenjük minden értékét egy körön. Tehát a 0 pontban belső és külső minimumai találkoznak. Ezután ezen a körön helyezzük el az összes szerverünket körülbelül így:
Minden szervert egy pont határoz meg, és az a szektor, amely az óramutató járásával megegyező irányban halad felé, természetesen ebből a hosztból szolgálja ki. Amikor kérdéseink érkeznek, azonnal látjuk, hogy például az A kérés — ennek ilyen a hash értéke — és a 2-es szervert szolgálja ki. A B kérés — a 3-as szervert. És így tovább.
Mit történik ebben a helyzetben re-shardingkor?
Nem érvénytelenítjük az összes cache-t, mint korábban, és nem mozdítjuk el az összes kulcsot, hanem az egyes szektorokat kis távolságokra mozdítjuk el úgy, hogy a szabaddá vált helyre, úgymond, beférjen a hatodik szerverünk, amit hozzá szeretnénk adni, és odadugjuk.
Természetesen ilyen helyzetben a kulcsok is eltolódnak. De sokkal gyengébben, mint korábban. Azt látjuk, hogy az első két kulcsunk a saját szerverein maradt, és csak az utolsó kulcs esetében változott a gyorsítótárazó szerver. Ez elég hatékonyan működik, és ha fokozatosan adsz hozzá új hosztokat, akkor nagy problémát nem okoz. Fokozatosan adsz hozzá, várod, hogy a gyorsítótár megint megteljen, és minden jól működik.
Az egyetlen kérdés a meghibásodásoknál merül fel. Tegyük fel, hogy van egy gép, ami meghibásodott.
És nem szeretnénk ebben a pillanatban újragenerálni ezt a térképet, érvényteleníteni a gyorsítótár egy részét, és így tovább, ha például a gép újraindult, és valahogy meg kellene szolgálnunk a kéréseket. Csak egy tartalék fényképező gyorsítótárat tartunk minden helyszínen, ami bármely gép helyettesítésére szolgál, ami most meghibásodott. Ha hirtelen egy szerverünk elérhetetlenné válik, a forgalom oda megy. Ekkor természetesen nincs ott semmilyen gyorsítótár, tehát hideg, de legalább a felhasználói kérések feldolgozva vannak. Ha ez egy rövid időtartam, akkor ezt teljesen nyugodtan átvészeljük. Csak a tárolóra megnövekedett terhelés jut. Ha pedig hosszú intervallumról van szó, akkor már döntést hozhatunk arról, hogy eltávolítjuk-e ezt a szervert a térképről vagy sem, esetleg helyettesítjük-e egy másikkal.
Ez a gyorsítótárazó rendszerrel kapcsolatos. Nézzük meg az eredményeket.
Első pillantásra nem tűnik bonyolultnak. De ez a cache-kezelési módszer körülbelül 98%-os találati arányt adott nekünk. Azaz ebből a napi 80 ezer kérésből csupán 1600 jut el a tárolókhoz, és ez teljesen normális terhelés, amelyet nyugodtan elviselnek, mindig van tartalékunk.
Ezeket a szervereket három DC-nkben helyeztük el, és három jelenlétet kaptunk – Prága, Miami és Hongkong.
Így többé-kevésbé lokálisan helyezkednek el a célpiacainkhoz.
Ráadásul kaptunk egy gyorsítótárazó proxyt, ahol a CPU valójában kihasználatlan, mert a tartalom kiszolgálásához nem szükséges annyira. És ott az NGINX+ Lua segítségével nagyon sok hasznos logikát megvalósítottunk.
Például kísérletezhetünk a webp vagy a progresszív jpeg formátumokkal (ezek hatékony, modern formátumok), figyelve, hogy ez hogyan befolyásolja a forgalmat, döntéseket hozva, például különböző országok számára aktiválva; dinamikusan átméretezni vagy válogatni a fényképeket menet közben.
Ez egy jó use case, amikor például van egy mobilalkalmazásunk, amely fényképeket mutat, és a mobilalkalmazás nem szeretné, hogy a kliens CPU-ját felhasználja egy nagy fénykép lekérésére és annak későbbi átméretezésére, hogy betehesse a nézetbe. Egyszerűen dinamikusan megadhatjuk az URL-ben bizonyos paramétereket az UPort-ban, és a fotók cache-e automatikusan átméretezi a fényképet. Általában a legjobban illeszkedő méretet választja, amely fizikailag ott van a lemezen, legközelebb a kért mérethez, és lekicsinyíti azt a konkrét koordinátákra.
Egyébként közzétettük az elmúlt öt év fejlesztői konferenciáiról készült videofelvételeket nyilvánosan. . Nézd meg, tanulmányozd, oszd meg, és iratkozz fel a .
Továbbá sok terméklogikát is hozzáadhatunk. Például az URL paraméterei szerint különböző vízjeleket adhatunk hozzá, elmoshatjuk a fényképeket, homályosíthatjuk vagy pixellel fedhetjük el. Amikor meg akarunk mutatni egy emberi fényképet, de nem akarjuk, hogy az arca látható legyen, ez jól működik, minden meg van valósítva itt.
Mit kaptunk? Három jelenlétet, jó találati arányt, és mellette a CPU-nk nem pihen ezeken a gépeken. Most már a CPU fontosabbá vált, mint korábban. Erősebb gépeket kell beszereznünk, de ez megéri.
Ami a fényképek szállítását illeti. Itt minden elég világos és nyilvánvaló. Azt hiszem, nem fedeztem fel Amerikát, így működik gyakorlatilag minden CDN.
Valószínűleg a tapasztalt hallgatónak felmerülhetett a kérdés: miért ne vegyük egyszerűen és cseréljük le mindent CDN-re? Nagyjából ugyanazt kaptuk volna, minden modern CDN képes erre. És itt több ok is van.
Az első — a fényképek.
Ez az infrastruktúránk egyik kulcsfontosságú pillére, és minél nagyobb ellenőrzést szeretnénk felette. Ha ez egy harmadik féltől származó megoldás, és nincs hatalmunk felette, elég nehéz lesz ezzel együtt élni, amikor nagy adathalmazon van, és amikor nagyon nagy felhasználói kérés áradat van.
Példa következik. Jelenleg, a saját infrastruktúránkon, például ha bármilyen probléma vagy földalatti zörej merül fel, be tudunk lépni a gépre, és hibakeresést tudunk végezni, mondhatni. Hozzáadhatunk olyan metrikák gyűjtését, amelyek csak nekünk fontosak, kísérletezésre is van lehetőségünk, figyeljük, hogy ez hogyan hat a grafikonokra stb. Jelenleg nagyon sok statisztikát gyűjtünk erről a gyorsítótár-klaszterről. Időnként ránézünk, és sokáig kutatunk különböző anomáliákat. Ha ez a CDN oldalon lenne, sokkal nehezebb lenne ellenőrizni. Vagy például, ha valamilyen baleset történik, tudjuk, mi történt, tudjuk, hogyan éljünk vele, és hogyan küzdjünk meg vele. Ez az első következtetés.
A második következtetés inkább történelmi, mert a rendszer már régóta fejlődik, és sokféle üzleti követelmény volt különböző szakaszokban, és nem mindig férnek bele a CDN koncepciójába.
A korábbiakból következő pont –
Ez az, hogy a fotógyorsítók esetén sok specifikus logikánk van, amelyet nem mindig lehet kérésre hozzáadni. Valószínűleg egyetlen CDN sem fog kérésedre egyedi dolgokat hozzáadni. Például URL-ek titkosítása, ha nem akarod, hogy az ügyfél módosíthassa azokat. Ha szeretnéd megváltoztatni az URL-t a szerveren, és titkosítani, majd dinamikus paramétereket adni ide.
Milyen következtetés adódik? A mi esetünkben a CDN nem egy túlságosan jó alternatíva.
A te esetében, ha vannak specifikus üzleti követelményeid, akkor bátran megvalósíthatod ugyanezt, amit megmutattam neked. Ez hasonló terhelési profil mellett remekül fog működni.
De ha van egy általános megoldásod, és a feladat nem túl specifikus, akkor nyugodtan választhatsz CDN-t. Vagy ha számodra sokkal fontosabb az idő és az erőforrások, mint a kontroll.
A modern CDN-ek gyakorlatilag mindent tartalmaznak, amiről most beszéltem. Kivéve néhány plusz-mínusz funkciót.
Ez a fényképek kiadásáról szól.
Most pedig egy kicsit lépjünk előre a visszatekintésünkben, és beszéljünk a tárolásról.
2013-ban.
A cache server has been added, and performance issues are gone. Everything is fine. The dataset is growing. By 2013, we had about 80 servers connected to the storages, and about 40 cache servers in each data center. That's 560 terabytes of data for each data center, or about a petabyte in total.
With the growth of the dataset, operational costs began to rise sharply. How did this manifest?
In this scheme, shown here—with the SAN, its connected machines, and caches—there are many points of failure. While we have previously managed the failure of cache servers, which are more or less predictable and understandable, the situation on the storage side was much worse.
Firstly, the Storage Area Network (SAN) itself can fail.
Secondly, it connects to the endpoint machines via optical fiber. There may be problems with optical cards and switches.
There are certainly fewer of these than with the SAN itself, but nevertheless, they are also points of failure.
Next, there's the machine that connects to the storage. It can also fail.
So we have three points of failure.
Additionally, besides the points of failure, maintaining the storage itself is complex.
It's a complicated multi-component system, and systems engineers often struggle with it.
Lastly, the most critical point: if any of these three points fails, there is a non-zero probability of losing user data, as the file system may become corrupted.
Suppose the file system is corrupted. Its recovery takes a long time—up to a week with substantial data volumes. Moreover, we are likely to end up with a heap of unknown files that need to be matched somehow to users' photos. We risk losing data. The risk is quite high. The more often such situations occur, and the more problems arise in this chain, the greater this risk becomes.
Something had to be done about this. We decided that we needed to back up the data. This is actually an obvious solution and a good one. What did we do?
This is what our server that was connected to the storage looked like before. It had one main partition, that is simply a block device, which actually represents a mount on remote storage via optical fiber.
We simply added a second partition.
Mellett felállítottunk egy második tárolót (szerencsére nem drága), és backup-partícióként neveztük el. Ez is optikán keresztül csatlakozik, ugyanazon a gépen található. De valahogy szinkronizálnunk kell az adatokat közöttük.
Itt egyszerűen létrehozunk egy aszinkron sorozatot mellé.
Nem nagyon terhelt. Tudjuk, hogy kevés bejegyzésünk van. A sorozat csupán egy táblázat a MySQL-ben, amelybe olyan sorok íródnak, mint 'el kell menteni ezt a fényképet'. Bármilyen változás vagy feltöltés esetén másolunk a fő partícióról a backupra aszinkron módon vagy valamilyen háttérmunkával.
Így mindig két konzisztens partíciónk van. Még ha a rendszer egyik része meghibásodik is, mindig válthatunk a fő és a backup partíció között, és minden folytatódik.
De emiatt jelentősen megnövekszik az olvasási terhelés, mivel a felhasználók, akik a fő partícióról olvasnak (mivel ott frissebb a kép), először ott nézik meg a képet, majd keresnek a backup-on, ha nem találtak (de ezt már az NGINX végzi), és ezen kívül a backup rendszerünk is olvas a fő partícióról. Ez nem feltétlenül szűk keresztmetszet, de nem akartuk feleslegesen növelni a terhelést.
Így hozzáadtunk egy harmadik lemezt, amely egy kis SSD, és buffernek neveztük el.
Most hogyan működik ez.
A felhasználó feltölt egy fotót a bufferbe, majd egy esemény kerül a sorba arról, hogy azt két partícióra kell másolni. Az másolódik, és a fénykép egy ideig (mondjuk egy nap) a bufferben él, majd csak azután törlődik. Ez nagymértékben javítja a felhasználói élményt, mivel a felhasználó feltölti a fényképet, és jellemzően azonnal érkeznek rá a kérések, vagy ő maga frissíti az oldalt. De mindez függ az alkalmazástól, amely végrehajtja a feltöltést.
Vagy például, ha más emberek, akikhez elkezdte mutatni, azonnal küldenek kéréseket a fénykép után. A cache-ben még nincs, az első kérés nagyon gyorsan történik. Alapvetően ez hasonló a fénykép cache-hez. A lassú tároló egyáltalán nem vesz részt ebben. Aztán egy nap múlva, amikor törlésre kerül, addigra már vagy cache-elve lett a cache rétegünkben, vagy már valószínűleg senkinek sincs szüksége rá. Tehát a felhasználói élmény nagymértékben javult ezeknek az egyszerű manipulációknak köszönhetően.
Nos, és a legfontosabb: megálltunk az adatok elvesztésével.
Mondhatni, hogy megálltunk potenciálisan adatokat veszítani, mivel különösebben nem vesztettünk el. De a veszély megvolt. Látjuk, hogy ez a megoldás természetesen jó, de egy kicsit olyan, mintha a probléma tüneteit simítanánk el, ahelyett, hogy véglegesen megoldanánk. Néhány probléma megmaradt.
Először is, ez egy hibapont a fizikai hosztnál, amelyen az egész gépezet működik, ez nem tűnt el.
Másodszor, megmaradtak a SAN-okkal kapcsolatos problémák, azok nehéz karbantartása stb. Ez nem volt kritikus tényező, de szerettem volna megpróbálni, hogyan tudnánk élni ezek nélkül.
A harmadik verziót készítettük el (valójában a második verziót) – a tartalékverziót. Hogyan nézett ez ki?
Ez volt, ami volt –
Fő problémáink a fizikai hosszal kapcsolatosak.
Először is, eltávolítjuk a SAN-okat, mert kísérletezni szeretnénk, csak lokális merevlemezeket szeretnénk kipróbálni.
Ez már 2014-2015, és akkoriban a merevlemezek helyzete és kapacitása egyetlen hoszton sokkal jobb lett. Úgy döntöttünk, miért ne próbálnánk ki.
A következő lépés, hogy fizikailag áthelyezzük a backup területünket egy külön gépre.
Így kapunk egy ilyen sémát. Két gépünk van, amelyek azonos adatállományokat tárolnak. Teljes mértékben tartalékolják egymást, és az adatokat egy hálózaton keresztül szinkronizálják egy aszinkron soron keresztül ugyanabban a MySQL-ben.
Ez azért működik jól, mert kevés a felvétel. Tehát ha a felvétel arányos lenne az olvasással, talán lenne némi hálózati túlterhelésünk és problémáink. Kevés a felvétel, sok az olvasás – ez a módszer jól működik, így elég ritkán másoljuk a fényképeket a két szerver között.
Hogyan működik ez, ha egy kicsit részletesebben megnézzük.
Feltöltés. A terheléselosztó egyszerűen véletlenszerűen választ ki hosztokat a párból és végzi a feltöltést. Eközben természetesen végzi az állapotellenőrzéseket, hogy megbizonyosodjon arról, hogy a gép nem esett ki. Így csak aktív szerverre tölt fájlokat, majd az aszinkron soron keresztül másolja azokat a szomszédjára. A feltöltés teljesen egyszerű.
A feladat egy kicsit bonyolultabb.
Itt a Lua segített nekünk, mert a vanilla NGINX-en nehézkesebb ezt a logikát megvalósítani. Először a első szerverhez küldünk egy kérést, hogy megnézzük, van-e fotó ott, mert potenciálisan feltölthették például a szomszédhoz, és ide még nem érkezett meg. Ha a fotó ott van, az jó. Azonnal átadjuk az ügyfélnek, és lehet, hogy gyorsítótárazunk.
Ha nincs, egyszerűen egy kérést küldünk a szomszédnak, ahonnan garantáltan megkapjuk.
Tehát megint lehet mondani: problémák lehetnek a teljesítménnyel, mert a folyamatos round trip-ek – a fotót feltöltötték, itt nincs, két kérést küldünk egy helyett, ez lassan kell hogy működjön.
A mi helyzetünkben ez nem működik lassan.
Sok metrikát gyűjtünk e rendszer alapján, és ennek a mechanizmusnak a feltételezett találati aránya körülbelül 95%. Azaz a backup késése kicsi, és ennek köszönhetően gyakorlatilag garantáltan, miután a fotó fel lett töltve, egyből megszerezzük, és nem kell kétszer oda-vissza menni.
Így mit nyertünk még, ami nagyon menő?
Régebben fő backup-partícióink voltak, és onnan sorban olvastunk. Azaz mindig először az alapból kerestünk, majd a backup-ból. Ez egy lépés volt.
Most párhuzamosan olvasunk két gépről. Round Robin-nal osztjuk el a kéréseket. Kis százalékban kétszer küldünk kérést. De a teljesítményünk most kétszer akkora olvasási kapacitással rendelkezik, mint korábban. És a terhelés jelentősen csökkent, mind az adás gépeken, mind a tárolókon, amik akkoriban szintén voltak.
Ami az elérhetőséget illeti. Valójában ezért küzdöttünk a legfőképpen. Az elérhetőséggel itt minden nagyszerűen működött.
Az egyik gép meghibásodik.
Nincs semmi probléma! A rendszertechnikusnak éjszaka még fel sem kell kelnia, várhat reggelig, semmi ijesztő nem történik.
Még ha a gép meghibásodásakor a sor is leáll, akkor sincs probléma, a napló először a működő gépen halmozódik fel, majd második lépésben a sorban, és aztán arra a gépre, amelyik egy idő után újra üzembe lép.
Ugyanaz a karbantartással. Egyszerűen lekapcsolunk egy gépet, manuálisan eltávolítjuk az összes poolból, leáll a forgalma, végezünk egy kis karbantartást, módosítunk valamit, majd visszaállítjuk a működésbe, és ez a backup elég gyorsan utoléri magát. Tehát, ha egy gép egy napot áll, a leállás körülbelül néhány perc alatt bepótolható. Ez tényleg nagyon kevés. A hibatűréssel, ahogy már mondtam, itt minden nagyszerű.
Milyen következtetéseket vonhatunk le ebből a tartalékos rendszerről?
Hibatűrést kaptunk.
Egyszerűbb üzemeltetés. Mivel a gépeken helyi merevlemezek vannak, ez sokkal kényelmesebb a mérnökök számára, akik ezzel dolgoznak.
Kettős tartalékot kaptunk az olvasásra.
Ez nagyon jó bónusz a hibatűréshez.
De vannak problémák is. Most sokkal bonyolultabb fejleszteni olyan funkciókat, amelyek kapcsolódnak ehhez, mert a rendszer 100%-ban véglegesen konzisztens lett.
Folyamatosan gondolkodnunk kell például egy háttérfeladatban: „Melyik szerveren futunk most?”, „Biztosan van itt aktuális fotó?” stb. Ez természetesen mind becsomagolva van, és a programozó, aki a üzleti logikát írja, számára átlátható. De ennek ellenére egy nagy bonyolult réteg jelent meg. De készen állunk erre, cserébe azokért az előnyökért, amiket kaptunk.
Itt is újabb konfliktus lép fel.
Először azt mondtam, hogy minden a helyi merevlemezeken való tárolás rossz. Most viszont azt mondom, hogy tetszik ez nekünk.
Igen, valóban, az idő múlásával a helyzet jelentősen megváltozott, és ma ennek a megközelítésnek sok előnye van. Egyrészt sokkal egyszerűbb üzemeltetést kapunk.
Másrészt ez teljesítményesebb, mert nincsenek automatikus vezérlők és csatlakozások a tárolókhoz.
Ott hatalmas gépcsarnok van, itt viszont csak néhány lemez, ami konkrétan itt a gépen RAID-be van állítva.
De vannak hátrányai is.
Ez körülbelül másfél szorosába kerül, mint a SAN-ok használata, még a mai árak mellett is. Ezért úgy döntöttünk, hogy nem merünk teljesen átállni a helyi merevlemezes gépekre a nagy klaszterünkből, és inkább egy hibrid megoldást választottunk.
A gépek fele nálunk merevlemezekkel működik (hát, nem fele – kb. 30 százalék). A fennmaradó rész pedig régi gépek, amelyeken korábban az első tartalékolási séma volt. Csak újra csatlakoztattuk őket, mivel nekünk nincsenek új adatok, vagy bármi más, csak a mountokat áthelyeztük egy fizikai gazdáról kettőre.
Így nagy tárhely-olvasási kapacitásunk lett, és összevontuk. Ha korábban egy géphez egy tárolót csatlakoztattunk, most egy párhoz négyet csatlakoztatunk, például. És ez normálisan működik.
Összefoglaljuk, hogy mi valósult meg, miért küzdöttünk, és sikerült-e.
Összegzés
33 millió felhasználónk van.
Három jelenlétünket részlegesen Prágában, Miami-ban és Hongkongban alakítottuk ki.
Ezekben található a cache réteg, ami gyors helyi SSD-kkel rendelkező gépeket tartalmaz, ahol egyszerű NGINX rendszer működik, az access.log-jaival és Python démonokkal, amelyek mindezt feldolgozzák és kezelik a cache-t.
Ha szeretné, a saját projektjében, ha a fényképek nem olyan kritikusak Önnek, mint számunkra, vagy ha a trade-off a kontroll és a fejlesztési sebesség között Önnek más irányba billen, akkor nyugodtan helyettesítheti CDN-nel, a modern CDN-ek ezt jól csinálják.
Ezután jön a tárolási réteg, ahol a pár gépből álló klaszterek találhatók, amelyek egymást tartalékolják, és minden változáskor aszinkron módon másolják a fájlokat egyik gépről a másikra.
Ezeknek a gépeknek egy része helyi merevlemezekkel működik.
Ezeknek a gépeknek egy része SAN-hoz csatlakozik.
Egyrészt ez kényelmesebb üzemeltetés szempontjából és valamivel produktívabb, másrészt a densitás és a gigabyte-ra eső ár szempontjából is kényelmes.
Ez egy rövid áttekintés az architektúráról, amit kaptunk, és arról, hogyan fejlődött mindez.
Még néhány egyszerű tanács a főnöktől.
Először is, ha hirtelen úgy dönt, hogy mindenáron javítani kell az infrafotóin, először mérje fel, mert lehet, hogy semmit sem kell javítani.
Hozok egy példát. Van egy klaszterünk, amely a chat-ekben az attachment-ből fényképeket ad, és ott még mindig a 2009-es rendszer működik, és senki sem szenved ettől. Mindenkinek jó, mindenki elégedett.
Ahhoz, hogy mérni tudjunk, először is állítsunk be egy csomó metrikát, nézzük meg őket, és csak ezután döntsétek el, hogy miben vagytok elégedetlenek, mit kellene javítani. Ahhoz, hogy ezt mérhessük, van egy klassz eszközünk, ami a Pinba névre hallgat.
Ez lehetővé teszi, hogy nagyon részletes statisztikákat gyűjtsünk az NGINX-től minden egyes kérésről és válaszkódról, a válaszidők eloszlásáról - mindent, amit csak szeretnél. Számos analitikai rendszerhez vannak kötődései, így ezeket szép módon át tudod nézni.
Először mérjünk - aztán javítsunk.
Továbbá. Az olvasást a cache optimalizálásával, a írást pedig shardinggal végezzük, de ez nyilvánvaló dolog.
Továbbá. Ha most kezded el építeni a rendszeredet, sokkal jobb, ha a fényképeket immutable fájlokként kezeljük. Így elveszíted az egész sorozatnyi problémát a cache invalidálásával, azzal kapcsolatban, hogy a logikának hogyan kell megtalálni a megfelelő fénykép verzióját, és így tovább.
Tegyük fel, hogy feltöltöttél egy képet, majd elforgattad azt, ügyelj arra, hogy ez egy fizikailag más fájl legyen. Vagyis nem kell gondolkodnod azon, hogy most spórolok egy kis helyet, ugyanabba a fájlba írom, megváltoztatom a verziót. Ez mindig rosszul működik, és sok fejtörést okoz később.
Következő pont. Az azonnali méretezés.
Korábban, amikor a felhasználók fényképeket töltöttek fel, azonnal rengeteg különböző méretet vágtunk le minden eshetőségre, különböző klienseknek, és ezek mind a lemezen voltak. Most már ezt elhagytuk.
Csak három alapméretet hagytunk meg: kicsi, közepes és nagy. Minden más méretet egyszerűen lecsökkentünk abból a méretből, amelyet az Uport kérdezett, csak legyártjuk a lecsökkentett verziót és átadjuk a felhasználónak.
A cache-elt réteg CPU-ja itt sokkal olcsóbb, mint ha folyamatosan újragenerálnánk ezeket a méreteket minden egyes tárolón. Tegyük fel, hogy újat szeretnénk hozzáadni, ez egy hónapot jelent - különböző helyeken végig kell futtatni egy scriptet, ami mindezt szépen elvégzi anélkül, hogy a klasztert leállítaná. Vagyis, ha van lehetőséged most választani, érdemes minél kevesebb fizikai méretet létrehozni, de hogy legyen valamilyen eloszlás, mondjuk három. Minden egyéb méretet egyszerűen azonnal átméretezünk a meglévő modulok segítségével. Ez most már nagyon egyszerű és elérhető.
Az inkrementális aszinkron biztonsági mentés jó dolog.
Gyakorlatunk alapján ez a rendszer nagyszerűen működik a módosított fájlok késleltetett másolásával.
Az utolsó pont szintén nyilvánvaló. Ha jelenleg nincsenek ilyen problémák az infrastruktúrájában, de van valami, ami tönkremehet, az biztosan tönkremegy, amikor egy kicsit többet bír el. Ezért érdemes előre gondolkodni és elkerülni a problémákat. Ennyit a részemről.
Kapcsolat
»
»
Ez a dokumentum a legjobb előadások egyikének a konferencia fejlesztői magas terhelésű rendszerek témájában történt átirata . Kevesebb mint egy hónap van hátra a HighLoad++ 2017 konferenciáig.
Már kész van nálunk , jelenleg aktívan formuláljuk az ütemtervet.
Idén továbbra is az architektúrák és skálázódás témáját kutatjuk:
- / Игорь Васильев
- / Дмитрий Егоров
- / Анатолий Пласковский
- / Роман Шеховцов, Алексей Громатчиков
- / Филипп Дельгядо
Néhány ilyen anyagot online kurzusunkhoz is felhasználunk, amely a magas terhelésű rendszer fejlesztéséről szól. — egy speciálisan összeválogatott levelek, cikkek, anyagok, videók sorozata. Már most több mint 30 egyedi anyag található a tankönyvünkben. Csatlakozzon!
Forrás: habr.com
