Artem Denisov ( , )
A Badoo a világ legnagyobb társkereső oldala. Jelenleg mintegy 330 millió regisztrált felhasználónk van világszerte. De ami sokkal fontosabb a mai beszélgetésünk keretében, hogy körülbelül 3 petabájtnyi felhasználói fotót tárolunk. Naponta mintegy 3,5 millió új fotót töltenek fel felhasználóiink, az olvasási terhelés pedig kb 80 ezer kérés másodpercenként. Ez elég sok a háttérrendszerünknek, és néha nehézségek adódnak ezzel.
Ennek a rendszernek a felépítéséről fogok beszélni, ami tárolja és küldi a képeket általában, és fejlesztői szemszögből nézem. Ennek alakulásáról lesz egy rövid visszatekintés, ahol felvázolom a főbb mérföldköveket, de csak a jelenleg használt megoldásokról beszélek bővebben.
Most pedig kezdjük.
Mint mondtam, ez egy visszatekintés lesz, és hogy valahol elkezdjük, vegyük a leggyakoribb példát.
Közös feladatunk van, felhasználói fotókat kell elfogadnunk, tárolnunk, küldenünk. Ebben a formában a feladat általános, bármit használhatunk:
- modern felhőalapú tárolás,
- dobozos megoldás, amiből most is sok van;
- Adatközpontunkban több gépet is beállíthatunk, és nagy merevlemezeket rakhatunk rájuk, és ott tárolhatjuk a fényképeket.
A Badoo történelmileg - most is, akkor is (akkor még gyerekcipőben járt) - a saját szerverein él, saját DC-inkben. Ezért ez a lehetőség volt számunkra az optimális.
Most vettünk több gépet, „fotóknak” neveztük őket, és kaptunk egy klasztert, amely fotókat tárol. De úgy tűnik, valami hiányzik. Ahhoz, hogy mindez működjön, valahogy meg kell határoznunk, hogy melyik gépen melyik fotókat tároljuk. És itt sem kell megnyitni Amerikát.
Tárhelyünkhöz hozzáadunk néhány mezőt a felhasználók adataival. Ez lesz a felosztási kulcs. Esetünkben ezt place_id-nek hívtuk, és ez a helyazonosító arra a helyre mutat, ahol a felhasználói fényképeket tárolják. Térképeket készítünk.
Az első szakaszban ezt akár manuálisan is meg lehet tenni - azt mondjuk, hogy egy ilyen hellyel rendelkező felhasználó fényképe egy ilyen szerveren landol. Ennek a térképnek köszönhetően mindig tudjuk, hogy a felhasználó mikor tölt fel egy fényképet, hová mentheti azt, és tudjuk, honnan adjuk.
Ez egy teljesen triviális rendszer, de meglehetősen jelentős előnyei vannak. Az első az, hogy egyszerű, mint mondtam, a második pedig az, hogy ezzel a megközelítéssel könnyen átméretezhetünk vízszintesen, egyszerűen szállítunk új autókat, és hozzáadjuk őket a térképhez. Nem kell mást tenned.
Nálunk is így volt ez egy ideig.
Ez 2009 körül volt. Autókat szállítottak, szállítottak...
És egy ponton elkezdtük észrevenni, hogy ennek a rendszernek vannak bizonyos hátrányai. Mik a hátrányai?
Először is korlátozott a kapacitás. Nem zsúfolhatunk annyi merevlemezt egy fizikai szerverre, amennyit szeretnénk. És ez idővel és az adatkészlet növekedésével bizonyos problémává vált.
És a második. Ez a gépek atipikus konfigurációja, mivel az ilyen gépeket nehéz újra felhasználni néhány más klaszterben, meglehetősen specifikusak, pl. teljesítményükben gyengének kell lenniük, de ugyanakkor nagy merevlemezzel.
Mindez 2009-re vonatkozott, de ezek a követelmények elvileg ma is érvényesek. Van egy visszatekintésünk, így 2009-ben teljesen rossz volt ezzel minden.
És az utolsó pont az ár.
Az ár akkoriban nagyon meredek volt, és keresnünk kellett néhány alternatívát. Azok. valahogy jobban ki kellett használnunk mind az adatközpontok terét, mind a fizikai szervereket, amelyeken mindez található. Rendszermérnökeink pedig egy nagy tanulmányba kezdtek, amelyben áttekintettek egy csomó különböző lehetőséget. Megvizsgálták a fürtözött fájlrendszereket is, mint például a PolyCeph és a Luster. Voltak teljesítményproblémák és elég nehézkes a működés. Megtagadták. Megpróbáltuk a teljes adatkészletet NFS-en keresztül felszerelni minden egyes autóra, hogy valahogy felnagyíthassuk. Az olvasás is rosszul ment, különböző gyártóktól különböző megoldásokat próbáltunk ki.
És végül az úgynevezett Storage Area Network használatában döntöttünk.
Ezek nagyméretű SHD-k, amelyeket kifejezetten nagy mennyiségű adat tárolására terveztek. Ezek lemezes polcok, amelyeket a végső optikai kimeneti gépekre szerelnek fel. Hogy. van valamiféle gépkészletünk, elég kicsi, és ezek az SHD-k, amelyek a küldési logikánk számára transzparensek, pl. nginxünknek vagy bárki másnak, hogy kiszolgálja ezeket a fényképeket.
Ennek a döntésnek nyilvánvaló előnyei voltak. Ez az SHD. Célja a fényképek tárolása. Ez olcsóbb, mint a gépeket egyszerűen merevlemezzel szerelni.
Második plusz.
Ez az, hogy sokkal nagyobb lett a kapacitás, i.e. sokkal több tárhelyet tudunk elhelyezni sokkal kisebb térfogatban.
De voltak olyan hátrányok is, amelyek elég gyorsan megjelentek. Ahogy a felhasználók száma és a rendszer terhelése nőtt, a teljesítményproblémák kezdtek jelentkezni. És a probléma itt teljesen nyilvánvaló - minden SHD, amelyet sok fénykép kis mennyiségben történő tárolására terveztek, általában szenved az intenzív olvasástól. Ez igaz minden felhőalapú tárolásra vagy bármi másra. Most nincs ideális tárhelyünk, ami végtelenül skálázható lenne, bármit bele lehetne rakni, és nagyon jól tűri a leolvasást. Főleg a hétköznapi olvasmányok.
Ahogy a mi fotóink esetében is, mert a képeket nem következetesen kérik, és ez nagyban befolyásolja a teljesítményüket.
Még a mai adatok szerint is, ha valahol több mint 500 RPS-t kapunk egy olyan gépen, amelyhez tároló van csatlakoztatva, máris elkezdődnek a problémák. Nekünk pedig elég rosszul esett, mert nő a felhasználók száma, a helyzet csak romlani fog. Ezt valahogy optimalizálni kell.
Az optimalizálás érdekében akkoriban úgy döntöttünk, hogy megnézzük a terhelési profilt - mi történik általában, mit kell optimalizálni.
És itt minden a mi kezünkre játszik.
Már az első diában mondtam: 80 ezer olvasási kérésünk van másodpercenként, mindössze napi 3,5 millió feltöltéssel. Vagyis ez három nagyságrendnyi különbség. Nyilvánvaló, hogy az olvasást optimalizálni kell, és gyakorlatilag világos, hogyan.
Van még egy apró pont. A szolgáltatás sajátosságai olyanok, hogy egy személy regisztrál, feltölt egy fényképet, majd elkezd aktívan nézni más embereket, kedvelni őket, és aktívan megmutatják másoknak. Aztán talál vagy nem, attól függ, hogyan alakul, és egy időre abbahagyja a szolgáltatás használatát. Ebben a pillanatban, amikor használja, nagyon dögösek a fotói - keresettek, sokan nézik őket. Amint abbahagyja ezt, elég gyorsan kiesik a többi embernek való kitettségből, mint korábban, és szinte soha nem kérik a fotóit.
Azok. Nagyon kicsi forró adatkészletünk van. De ugyanakkor rengeteg kérés érkezik hozzá. És itt egy teljesen kézenfekvő megoldás a gyorsítótár hozzáadása.
Egy gyorsítótár az LRU-val minden problémánkat megold. Mit csinálunk?
Hozzáadunk még egy viszonylag kicsivel a nagy, tárolóval ellátott klaszterünk elé, amit photocache-nek neveznek. Ez lényegében csak egy gyorsítótárazó proxy.
Hogyan működik belülről? Itt a felhasználónk, itt a tárhely. Minden ugyanaz, mint régen. Mit adjunk hozzá?
Ez csak egy gép egy fizikai helyi lemezzel, ami gyors. Ilyen például az SSD. És ezen a lemezen valamilyen helyi gyorsítótár található.
Hogy néz ki? A felhasználó fényképezési kérelmet küld. Az NGINX először a helyi gyorsítótárban keresi. Ha nem, akkor egyszerűen proxy_pass a tárhelyünkre, onnan töltse le a fotót és adja át a felhasználónak.
De ez nagyon banális, és nem világos, mi történik odabent. Valahogy így működik.
A gyorsítótár logikailag három rétegre oszlik. Amikor azt mondom, hogy „három réteg”, ez nem azt jelenti, hogy létezik valamiféle összetett rendszer. Nem, ez feltételesen csak három könyvtár a fájlrendszerben:
- Ez egy puffer, ahová a proxyról letöltött fényképek kerülnek.
- Ez egy gyorsítótár, amely az aktuálisan aktívan kért fényképeket tárolja.
- És egy hideg gyorsítótár, ahol a fényképek fokozatosan kiszorulnak a forró gyorsítótárból, amikor kevesebb kérés érkezik hozzájuk.
Ahhoz, hogy ez működjön, valahogy kezelni kell ezt a gyorsítótárat, át kell rendezni a benne lévő fényképeket stb. Ez is egy nagyon primitív folyamat.
Az Nginx egyszerűen minden kérésnél ír a RAMDisk access.log-ba, amelyben jelzi a jelenleg kiszolgált fénykép elérési útját (természetesen a relatív elérési utat), és azt, hogy melyik partíciót szolgálták ki. Azok. lehet, hogy „fotó 1”, majd egy puffer, vagy egy forró gyorsítótár, egy hideg gyorsítótár, vagy egy proxy.
Ennek függvényében valahogy el kell döntenünk, mit tegyünk a fényképpel.
Minden gépen fut egy kis démon, amely folyamatosan olvassa ezt a naplót, és tárolja a memóriájában az egyes fényképek használatáról szóló statisztikákat.
Egyszerűen ott gyűjt, tartja a számlálókat, és rendszeresen elvégzi a következőket. Az aktívan kért fotókat, amelyekre sok kérés érkezik, áthelyezi a gyorsítótárba, bárhol is legyenek.
A ritkán kért és ritkábban kért fotók fokozatosan kiszorulnak a forró gyorsítótárból a hidegbe.
És ha elfogy a hely a gyorsítótárban, egyszerűen elkezdünk mindent válogatás nélkül törölni a hideg gyorsítótárból. És mellesleg ez jól működik.
Annak érdekében, hogy a fotó a pufferbe proxyzáskor azonnal mentésre kerüljön, a proxy_store direktívát használjuk és a puffer is egy RAMDisk, azaz. a felhasználó számára nagyon gyorsan működik. Ez magának a gyorsítótárazó szervernek a belső elemeire vonatkozik.
A fennmaradó kérdés az, hogyan lehet a kéréseket elosztani ezeken a szervereken.
Tegyük fel, hogy van egy húsz tárológépből álló klaszter és három gyorsítótárazó szerver (ez így történt).
Valahogy meg kell határoznunk, hogy mely fényképekhez milyen kérések érkeznek, és hova kell őket küldeni.
A legáltalánosabb lehetőség a Round Robin. Vagy véletlenül csinálja?
Ennek nyilvánvalóan számos hátránya van, mert ilyen helyzetben nagyon nem hatékonyan használnánk a gyorsítótárat. A kérések néhány véletlenszerű gépen landolnak: itt gyorsítótárban volt, de a következőn már nincs meg. És ha mindez működik, az nagyon rossz lesz. Még akkor is, ha kevés gép van a fürtben.
Valahogy egyértelműen meg kell határoznunk, hogy melyik szerver melyik kérést küldje le.
Van egy banális módszer. A hash-t az URL-ből, vagy a hash-t a sharding kulcsunkból, amely az URL-ben található, elosztjuk a szerverek számával. Működni fog? Akarat.
Azok. Van egy 2%-os kérésünk, például valamilyen „example_url” esetén mindig a „XNUMX” indexű szerveren landol, és a gyorsítótárat a lehető legjobban folyamatosan ártalmatlanítják.
De van egy probléma az újrafelosztással egy ilyen rendszerben. Resharding – a szerverek számának változtatására gondolok.
Tegyük fel, hogy a gyorsítótárazási fürtünk már nem tud megbirkózni, és úgy döntünk, hogy hozzáadunk egy másik gépet.
Tegyük hozzá.
Most minden nem hárommal, hanem néggyel osztható. Így szinte az összes kulcs, amivel korábban rendelkeztünk, szinte az összes URL más szervereken él. Az egész gyorsítótár egy pillanatra érvénytelenné vált. Minden kérés a tárhelyfürtünkre esett, rosszullét, szolgáltatáshiba és elégedetlen felhasználók lettek. Nem akarom ezt csinálni.
Ez a lehetőség sem felel meg nekünk.
Hogy. Mit tehetünk? Valahogyan hatékonyan ki kell használnunk a gyorsítótárat, ugyanazt a kérést újra és újra el kell juttatnunk ugyanazon a szerveren, de ellenállnunk kell az újrafelosztásnak. És van ilyen megoldás, nem olyan bonyolult. Ezt konzisztens hash-nek hívják.
Hogy néz ki?
Vegyünk néhány függvényt a sharding kulcsból, és az összes értékét szétterítjük a körön. Azok. a 0 pontban annak minimális és maximális értéke konvergál. Ezután az összes szerverünket ugyanabba a körbe helyezzük, körülbelül így:
Minden szervert egy pont határoz meg, és a hozzá tartozó szektort ennek megfelelően ez a gazdagép szolgálja ki. Amikor megérkeznek hozzánk a kérések, azonnal látjuk, hogy például az A kérés - van egy hash - és a 2. szerver szolgálja ki. A B kérés - a 3. szerver. És így tovább.
Mi történik ebben a helyzetben az újraaprózás során?
Nem érvénytelenítjük a teljes gyorsítótárat, mint korábban, és nem toljuk el az összes billentyűt, hanem minden szektort egy kis távolságra eltolunk, hogy viszonylagosan a hatodik szerverünk, amelyet hozzá szeretnénk adni, beleférjen a szabad helyre, és oda adjuk.
Természetesen ilyen helyzetben a kulcsok is kimozdulnak. De sokkal gyengébben mozdulnak ki, mint korábban. És azt látjuk, hogy az első két kulcsunk a szervereiken maradt, és a gyorsítótárazó szerver csak az utolsó kulcsnál változott. Ez meglehetősen hatékonyan működik, és ha fokozatosan ad hozzá új gazdagépeket, akkor nincs nagy probléma. Egyszerre hozzáadsz és adsz hozzá, megvárod, amíg újra megtelik a gyorsítótár, és minden jól működik.
A kérdés csak az elutasításban marad. Tételezzük fel, hogy valamilyen autó nem működik megfelelően.
És ebben a pillanatban nem igazán szeretnénk ú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 újraindították a gépet, és valahogy szervizkéréseket kell intéznünk. Egyszerűen minden oldalon tartunk egy biztonsági mentési fénykép-gyorsítótárat, amely helyettesíti a jelenleg leállított gépeket. És ha hirtelen valamelyik szerverünk elérhetetlenné válik, a forgalom oda megy. Természetesen ott nincs gyorsítótárunk, pl. hideg van, de legalább a felhasználói kérések feldolgozása folyamatban van. Ha ez egy rövid intervallum, akkor azt teljesen nyugodtan éljük meg. Csak több terhelés van a tárhelyen. Ha ez az intervallum hosszú, akkor már dönthetünk - eltávolítjuk ezt a szervert a térképről vagy sem, esetleg lecseréljük egy másikra.
Ez a gyorsítótárazási rendszerről szól. Nézzük az eredményeket.
Úgy tűnik, hogy itt nincs semmi bonyolult. De ez a gyorsítótár-kezelési módszer körülbelül 98%-os trükkarányt adott nekünk. Azok. ebből a másodpercenkénti 80 ezer kérésből csak 1600 éri el a tárhelyet, és ez teljesen normális terhelés, nyugodtan kibírják, mindig van tartalékunk.
Ezeket a szervereket három DC-nkban helyeztük el, és három jelenléti pontot kaptunk - Prágában, Miamiban és Hong Kongban.
Hogy. többé-kevésbé helyileg találhatók minden egyes célpiacunkon.
Szép bónuszként pedig megkaptuk ezt a cache proxyt, amin a CPU tulajdonképpen tétlen, mert nincs rá annyira szükség a tartalom kiszolgálásához. És ott, az NGINX+ Lua használatával, sok haszonelvű logikát implementáltunk.
Például kísérletezhetünk webp-vel vagy progresszív jpeg-el (ezek hatékony modern formátumok), megnézhetjük, hogyan befolyásolja a forgalmat, meghozhatunk néhány döntést, engedélyezhetjük bizonyos országok számára, stb.; dinamikus átméretezés vagy vágás menet közben.
Ez akkor jó, ha például van egy mobilalkalmazása, amely fényképeket jelenít meg, és a mobilalkalmazás nem akarja pazarolni a kliens CPU-ját arra, hogy kérjen egy nagy képet, majd átméretezze azt egy bizonyos méretre, hogy benyomja. a kilátás. Egyszerűen dinamikusan megadhatunk néhány paramétert az UPort feltételes URL-ben, és a fotógyorsítótár átméretezi magát a fényképet. Általában kiválasztja azt a méretet, amely fizikailag a lemezen van, a lehető legközelebb a kért mérethez, és meghatározott koordinátákban értékesíti.
Egyébként nyilvánosan elérhetővé tettük a nagy terhelésű rendszerek fejlesztői konferenciájának elmúlt öt évének videófelvételeit. . Nézd, tanulj, oszd meg és iratkozz fel .
Sok terméklogikát is hozzáadhatunk ott. Például URL-paraméterek segítségével különböző vízjeleket adhatunk hozzá, fotókat elmoshatunk, elmoshatunk vagy pixelesíthetünk. Ilyenkor szeretnénk egy emberről fényképet mutatni, de nem az arcát, ez jól működik, itt minden megvalósul.
Mit kaptunk? Három jelenléti pontot kaptunk, jó trükkarányt, ugyanakkor nincs tétlen CPU ezeken a gépeken. Mostanra természetesen fontosabb lett, mint korábban. Erősebb autókat kell adnunk magunknak, de megéri.
Ez a fényképek visszaküldésére vonatkozik. Itt minden egészen világos és egyértelmű. Azt hiszem, nem én fedeztem fel Amerikát, szinte minden CDN így működik.
És a legvalószínűbb, hogy egy kifinomult hallgatónak felmerülhet a kérdés: miért nem változtat meg mindent CDN-re? Körülbelül ugyanez lenne; minden modern CDN képes erre. És ennek számos oka van.
Az első a fényképek.
Ez infrastruktúránk egyik kulcspontja, és a lehető legnagyobb ellenőrzésre van szükségünk felette. Ha ez egy harmadik féltől származó megoldás, és nincs hatalma felette, akkor meglehetősen nehéz lesz vele élni, ha nagy adatkészlettel rendelkezik, és ha nagyon nagy az adatfolyama. felhasználói kérésekből.
Hadd mondjak egy példát. Most a mi infrastruktúránkkal például valamilyen probléma vagy földalatti kopogtatás esetén oda tudunk menni a géphez és ott relatíve kavarni. Hozzáadhatjuk néhány olyan mérőszám gyűjteményét, amelyre csak szükségünk van, kísérletezhetünk valahogy, megnézhetjük, hogyan hat ez a grafikonokra stb. Most sok statisztikát gyűjtenek erről a gyorsítótárazási fürtről. Időnként megnézzük, és hosszú időt töltünk azzal, hogy feltárunk néhány anomáliát. Ha a CDN oldalon lenne, sokkal nehezebb lenne irányítani. Vagy például, ha valamilyen baleset történik, tudjuk, mi történt, tudjuk, hogyan kell együtt élni vele, és hogyan lehet túllépni rajta. Ez az első következtetés.
A második következtetés is inkább történeti, mert a rendszer már régóta fejlődik, és a különböző szakaszokban sokféle üzleti követelmény volt, amelyek nem mindig illeszkednek a CDN koncepciójába.
A lényeg pedig az előzőből következik
Ennek az az oka, hogy a fotógyorsítótáraknál sok speciális logikánk van, amelyet nem mindig lehet kérésre hozzáadni. Nem valószínű, hogy bármely CDN hozzáadna néhány egyedi dolgot az Ön kérésére. Például URL-ek titkosítása, ha nem szeretné, hogy az ügyfél módosítson valamit. Meg akarja változtatni az URL-t a szerveren és titkosítani szeretné, majd ide küldeni néhány dinamikus paramétert.
Milyen következtetést sugall ez? Esetünkben a CDN nem túl jó alternatíva.
És az Ön esetében, ha konkrét üzleti követelményei vannak, akkor teljesen nyugodtan végrehajthatja azt, amit mutattam. És ez tökéletesen működik hasonló terhelési profillal.
De ha van valamilyen általános megoldása, és a feladat nem túl konkrét, akkor teljesen nyugodtan használhat CDN-t. Vagy ha az idő és az erőforrások fontosabbak számodra, mint a kontroll.
A modern CDN-ek pedig szinte mindent tartalmaznak, amiről most meséltem. Néhány funkció kivételével.
Ez a fotók átadásáról szól.
Lépjünk most egy kicsit előre a visszatekintésünkben, és beszéljünk a tárolásról.
2013 elmúlt.
Gyorsítótárazó szerverek kerültek hozzáadásra, a teljesítményproblémák megszűntek. Minden rendben. Az adatkészlet növekszik. 2013-ban körülbelül 80 szerverünk volt a tárolóhoz csatlakoztatva, és körülbelül 40 gyorsítótárazó szerverünk volt minden DC-ben. Ez minden DC-n 560 terabájt adat, azaz. összesen körülbelül egy petabájt.
Az adatkészlet növekedésével pedig a működési költségek jelentősen emelkedni kezdtek. Mit jelentett ez?
Ezen a diagramon, amelyet megrajzoltunk - SAN-nal, gépekkel és gyorsítótárral csatlakoztatva - sok hibapont van. Ha már korábban foglalkoztunk a cache szerverek meghibásodásával, akkor többé-kevésbé minden kiszámítható és érthető volt, de a tárolási oldalon minden sokkal rosszabb volt.
Először is ott van maga a Storage Area Network (SAN), amely meghibásodhat.
Másodszor, optikán keresztül csatlakozik a véggépekhez. Problémák adódhatnak az optikai kártyákkal és a gyújtógyertyákkal.
Természetesen nincs belőlük annyi, mint magában a SAN-ban, de ennek ellenére ezek is kudarcpontok.
Következő maga a gép, ami a tárolóhoz van kötve. Az is megbukhat.
Összességében három kudarcpontunk van.
Ezenkívül a meghibásodási pontokon túl magát a tárolót is nagymértékben karbantartják.
Ez egy összetett többkomponensű rendszer, és a rendszermérnökök nehezen dolgozhatnak vele.
És az utolsó, legfontosabb pont. Ha e három pont bármelyikén hiba lép fel, nullától eltérő esélyünk van a felhasználói adatok elvesztésére, mert a fájlrendszer összeomolhat.
Tegyük fel, hogy a fájlrendszerünk elromlott. Először is, a helyreállítás hosszú időt vesz igénybe - nagy mennyiségű adat esetén egy hétig is eltarthat. Másodszor pedig a végén nagy valószínűséggel egy rakás érthetetlen fájlhoz jutunk, amelyeket valahogyan felhasználói fényképekké kell majd kombinálni. És fennáll az adatvesztés kockázata. A kockázat meglehetősen magas. És minél gyakrabban fordulnak elő ilyen helyzetek, és minél több probléma merül fel ebben az egész láncban, annál nagyobb ez a kockázat.
Valamit tenni kellett ez ellen. És úgy döntöttünk, hogy csak biztonsági másolatot kell készítenünk az adatokról. Ez valójában egy kézenfekvő és jó megoldás. Mit tettünk?
Így nézett ki a szerverünk, amikor korábban csatlakozott a tárolóhoz. Ez az egyik fő rész, ez csak egy blokkeszköz, amely valójában egy tartót jelent az optikán keresztüli távoli tároláshoz.
Most adtunk hozzá egy második részt.
Elhelyeztünk mellé egy második tárolót (szerencsére nem olyan drága pénzben), és tartalék partíciónak hívtuk. Optikán keresztül is csatlakozik, és ugyanazon a gépen található. De valahogy szinkronizálnunk kell az adatokat közöttük.
Itt egyszerűen aszinkron sort készítünk a közelben.
Nem túl elfoglalt. Tudjuk, hogy nincs elég rekordunk. A várólista csak egy táblázat a MySQL-ben, amelybe olyan sorok vannak írva, mint „biztonsági másolatot kell készíteni erről a fényképről”. Bármilyen változtatás vagy feltöltés esetén a fő partícióról a biztonsági másolatba másolunk egy aszinkron vagy csak valamilyen háttérmunkás segítségével.
Így mindig két következetes szakaszunk van. Még ha ennek a rendszernek egy része meghibásodik, a fő partíciót mindig módosíthatjuk biztonsági mentéssel, és minden tovább fog működni.
De emiatt az olvasási terhelés nagyon megnő, mert... azon klienseken kívül, akik a fő részből olvasnak, mert először ott nézik meg a fotót (ott frissebb), és utána keresik a biztonsági másolatban, ha nem találták meg (de az NGINX csak ezt csinálja), a rendszerünk egy plusz biztonsági másolat is, amelyet most a fő partícióról olvas. Nem arról van szó, hogy ez szűk keresztmetszet volt, de lényegében nem akartam növelni a terhelést, csak úgy.
És hozzáadtunk egy harmadik lemezt, ami egy kis SSD, és puffernek neveztük el.
Hogyan működik most.
A felhasználó feltölt egy fotót a pufferbe, majd egy esemény kerül a sorba, jelezve, hogy azt két részre kell másolni. Másolódik, és a fotó egy ideig (mondjuk egy napig) a pufferben él, és csak ezután törlődik onnan. Ez nagyban javítja a felhasználói élményt, mivel a felhasználó feltölt egy fényképet, általában azonnal követni kezdik a kérések, vagy ő maga frissítette és frissítette az oldalt. De minden a feltöltést végző alkalmazástól függ.
Vagy például más emberek, akiknek elkezdte megmutatni magát, azonnal kéréseket küldenek a fénykép után. Még nincs a gyorsítótárban, az első kérés nagyon gyorsan megtörténik. Lényegében ugyanaz, mint a fotógyorsítótárból. A lassú tárolás ebben egyáltalán nem játszik szerepet. És amikor egy nappal később megtisztítják, akkor már vagy gyorsítótárazott a gyorsítótárazási rétegünkön, vagy valószínűleg már nincs rá szüksége senkinek. Azok. A felhasználói élmény itt nagyon jól nőtt az ilyen egyszerű manipulációknak köszönhetően.
Nos, és ami a legfontosabb: abbahagytuk az adatvesztést.
Mondjuk megálltunk potenciálisan elveszítjük az adatokat, mert valójában nem veszítettük el. De volt veszély. Látjuk, hogy ez a megoldás természetesen jó, de kicsit olyan, mintha a probléma tüneteit elsimítanánk, ahelyett, hogy teljesen megoldaná. És néhány probléma itt is marad.
Először is, ez egy kudarc pont maga a fizikai gazdagép formájában, amelyen ez az egész gépezet fut; ez nem tűnt el.
Másodszor, továbbra is gondok vannak a SAN-okkal, a nehéz karbantartásuk stb. Nem mintha kritikus tényező lenne, de meg akartam próbálni valahogy élni nélküle.
És elkészítettük a harmadik verziót (valójában a másodikat) - a foglalási verziót. Hogy nézett ki?
ez volt az...
A fő problémáink azzal a ténnyel vannak, hogy ez egy fizikai gazda.
Először is eltávolítjuk a SAN-okat, mert kísérletezni akarunk, csak helyi merevlemezeket akarunk kipróbálni.
Ez már 2014-2015, és akkoriban sokkal jobb lett a helyzet a lemezekkel és azok kapacitásával egy gazdagépben. Úgy döntöttünk, miért nem próbáljuk ki.
Ezután egyszerűen vesszük a tartalék partíciónkat, és fizikailag áthelyezzük egy külön gépre.
Így ezt a diagramot kapjuk. Két autónk van, amelyek ugyanazokat az adatkészleteket tárolják. Teljesen biztonsági másolatot készítenek egymásról, és szinkronizálják az adatokat a hálózaton keresztül egy aszinkron soron keresztül ugyanabban a MySQL-ben.
Ez azért működik jól, mert kevés rekordunk van. Azok. ha az írás összehasonlítható lenne az olvasással, akkor talán valamiféle hálózati többletköltség és problémánk lenne. Kevés az írás, sok az olvasás - ez a módszer jól működik, i.e. Ritkán másolunk fényképeket a két szerver között.
Hogyan működik ez, ha egy kicsit részletesebben megvizsgálja.
Feltöltés. A kiegyenlítő egyszerűen kiválasztja a véletlenszerű gazdagépeket egy párral, és feltölti azokat. Ugyanakkor természetesen egészségügyi ellenőrzéseket végez, és gondoskodik arról, hogy az autó ne essen ki. Azok. fotókat csak egy élő szerverre tölt fel, majd egy aszinkron soron keresztül mindezt átmásolják a szomszédjába. A feltöltéssel minden rendkívül egyszerű.
A feladat egy kicsit nehezebb.
Lua itt segített nekünk, mert nehéz lehet ilyen logikát létrehozni a vanília NGINX-en. Először az első szerverhez intézünk egy kérést, nézzük meg, hogy ott van-e a fotó, mert potenciálisan fel lehet tölteni például a szomszédhoz, de még nem érkezett meg ide. Ha ott van a fotó, az jó. Azonnal odaadjuk az ügyfélnek, és esetleg gyorsítótárba helyezzük.
Ha nincs, akkor egyszerűen csak kérünk a szomszédunkhoz, és onnan garantáltan megkapjuk.
Hogy. ismét elmondhatjuk: gondok lehetnek a teljesítménnyel, mert állandó az oda-vissza utak - a kép fel lett töltve, nincs itt, egy helyett kettőt kérünk, ennek lassan mennie kell.
A mi helyzetünkben ez nem működik lassan.
Egy csomó mérőszámot gyűjtünk össze ezen a rendszeren, és egy ilyen mechanizmus feltételes intelligens aránya körülbelül 95%. Azok. Ennek a mentésnek kicsi a lemaradása, és ennek köszönhetően szinte garantált, hogy a fotó feltöltése után először készítjük el és nem kell kétszer menni sehova.
Szóval mi van még, ami igazán klassz?
Korábban a fő mentési partíciónk volt, és sorban olvastunk belőlük. Azok. Először mindig a főben kerestünk, majd a tartalékban. Egy mozdulat volt.
Most egyszerre két gépről olvasunk. A kéréseket a Round Robin segítségével terjesztjük. Az esetek kis százalékában két kérést is benyújtunk. Összességében azonban most kétszer annyi olvasnivaló áll rendelkezésünkre, mint korábban. És nagyon lecsökkent a terhelés mind a küldő gépeken, mind a közvetlenül a tárológépeken, amivel akkoriban is rendelkeztünk.
Ami a hibatűrést illeti. Valójában elsősorban ezért küzdöttünk. Hibatűréssel itt minden remekül alakult.
Egy autó elromlik.
Nincs mit! Egy rendszermérnök lehet, hogy fel sem ébred éjjel, kivár reggelig, semmi rossz nem fog történni.
Ha még akkor is, ha ez a gép meghibásodik, a sor nem működik, akkor sincs probléma, a napló egyszerűen felhalmozódik először az élő gépen, majd hozzáadódik a sorhoz, majd az autóhoz, amely egy idő után működésbe lép.
Ugyanez a helyzet a karbantartással. Egyszerűen kikapcsoljuk az egyik gépet, manuálisan kihúzzuk az összes medencéből, abbahagyja a forgalom fogadását, csinálunk valami karbantartást, szerkesztünk valamit, majd visszatesszük szervizbe, és ez a mentés elég hamar utoléri. Azok. naponta egy autó leállása néhány percen belül utoléri. Ez tényleg nagyon kevés. Hibatűréssel, ismét mondom, itt minden menő.
Milyen következtetéseket lehet levonni ebből a redundancia-sémából?
Hibatűréssel rendelkezünk.
Könnyen kezelhető. Mivel a gépek helyi merevlemezzel rendelkeznek, ez üzemeltetési szempontból sokkal kényelmesebb a vele dolgozó mérnökök számára.
Dupla olvasási pótlékot kaptunk.
Ez egy nagyon jó bónusz a hibatűrés mellett.
De vannak problémák is. Most egy sokkal összetettebb fejlesztés áll előttünk néhány ehhez kapcsolódó funkcióból, mert a rendszer végül 100%-os konzisztenssé vált.
Mondjuk valamilyen háttérmunkában állandóan azon kell gondolkodnunk, hogy „mi szerveren futunk most?”, „Valóban van itt aktuális fotó?” stb. Ez persze mind fel van csomagolva, és az üzleti logikát író programozó számára ez átlátható. De ennek ellenére megjelent ez a nagy összetett réteg. De készek vagyunk beletörődni, cserébe a tőle kapott finomságokért.
És itt ismét felmerül némi konfliktus.
Az elején mondtam, hogy rossz mindent helyi merevlemezen tárolni. És most azt mondom, hogy tetszett.
Igen, valóban, az idő múlásával a helyzet sokat változott, és most ennek a megközelítésnek számos előnye van. Először is sokkal egyszerűbb műveletet kapunk.
Másodszor, termelékenyebb, mert nem rendelkezünk ilyen automata vezérlőkkel vagy lemezpolcokkal való kapcsolattal.
Hatalmas mennyiségű gép van ott, és ez csak néhány lemez, amiket itt a gépen raknak össze egy raidbe.
De vannak hátrányai is.
Ez még a mai árakon is megközelítőleg másfélszer drágább, mint a SAN-ok használata. Ezért úgy döntöttünk, hogy nem alakítjuk át bátran a teljes nagy klaszterünket helyi merevlemezes autókká, és úgy döntöttünk, hogy elhagyjuk a hibrid megoldást.
Gépeink fele merevlemezzel működik (na jó, nem a fele – valószínűleg 30 százalék). A többi pedig régi autó, amelyen korábban az első foglalási rendszer volt. Egyszerűen újracsatlakoztattuk őket, mivel nem volt szükségünk új adatokra vagy semmi másra, egyszerűen áthelyeztük a rögzítőket egy fizikai gazdagépről kettőre.
És most már hatalmas olvasmánykészlettel rendelkezünk, és ezt bővítettük. Ha korábban egy tárolót szereltünk fel egy gépre, most például négyet egy párra. És jól működik.
Vegyünk egy rövid összefoglalót arról, hogy mit értünk el, miért küzdöttünk, és hogy sikerült-e.
Eredményei
Vannak felhasználóink – akár 33 millióan.
Három jelenléti pontunk van - Prága, Miami, Hong Kong.
Tartalmaznak egy gyorsítótárazási réteget, ami gyors helyi lemezes (SSD) autókból áll, amelyeken az NGINX egyszerű gépei, annak access.log és Python démonjai futnak, amelyek mindezt feldolgozzák és a gyorsítótárat kezelik.
Ha szeretné, benne van a projektjében, ha a fotók nem olyan kritikusak az Ön számára, mint nekünk, vagy ha a kompromisszum a fejlesztési sebességgel és az erőforrás-költségekkel ellentétes irányba mutat, akkor nyugodtan lecserélheti őket. CDN-nel a modern CDN-ek jól működnek.
Következik a tárolóréteg, amelyen géppárokból álló fürtök vannak, amelyek biztonsági másolatot készítenek egymásról, a fájlok aszinkron módon másolódnak egyikről a másikra, amikor változnak.
Ezenkívül néhány ilyen gép helyi merevlemezekkel működik.
Néhány ilyen gép SAN-hoz van csatlakoztatva.
És egyrészt kényelmesebb a használata és egy kicsit termelékenyebb, másrészt kényelmes az elhelyezési sűrűség és a gigabájt ár szempontjából.
Ez egy ilyen rövid áttekintés az építészetről, amit kaptunk, és hogyan fejlődött az egész.
Még néhány tipp a kapitánytól, nagyon egyszerűek.
Először is, ha hirtelen úgy dönt, hogy sürgősen javítania kell mindent a fotóinfrastruktúrán, először mérje meg, mert talán semmit sem kell javítani.
Hadd mondjak egy példát. Van egy gépcsoportunk, amely chaten küldi a csatolmányokból fotókat, és ott 2009 óta működik a séma, és senki sem szenved tőle. Mindenki jól van, mindenkinek minden tetszik.
A méréshez először függesszen fel egy csomó mérőszámot, nézze meg őket, majd döntse el, hogy mivel nem elégedett, és min kell javítani. Ennek mérésére van egy Pinba nevű remek eszközünk.
Lehetővé teszi, hogy nagyon részletes statisztikákat gyűjtsön az NGINX-től minden egyes kérés- és válaszkódhoz, valamint az idők eloszlásához – amit csak akar. Mindenféle analitikai rendszerhez kötődik, és akkor szépen meg lehet nézni az egészet.
Először megmértük, majd javítottuk.
További. Az olvasást gyorsítótárral optimalizáljuk, az írást szilánkolással, de ez nyilvánvaló.
További. Ha most kezdi el építeni a rendszerét, akkor sokkal jobb, ha fényképeket készít megváltoztathatatlan fájlként. Mert azonnal elveszít egy egész osztály problémát a gyorsítótár érvénytelenítésével, azzal, hogy a logika hogyan találja meg a fénykép megfelelő verzióját, és így tovább.
Tegyük fel, hogy feltöltött százat, majd elforgatta, és úgy tette, hogy fizikailag más fájl legyen. Azok. nem kell gondolkodni: most megspórolok egy kis helyet, beírom ugyanabba a fájlba, megváltoztatom a verziót. Ez mindig nem működik jól, és később sok fejfájást okoz.
Következő pont. A menet közbeni átméretezésről.
Korábban, amikor a felhasználók feltöltöttek egy fotót, azonnal egy csomó méretet vágtunk minden alkalomra, különböző kliensekre, és mindegyik a lemezen volt. Most ezt feladtuk.
Csak három fő méretet hagytunk meg: kicsi, közepes és nagy. Egyszerűen lekicsinyítjük az összes többit attól a mérettől, amely mögött az Uportnál kérték, egyszerűen elvégezzük a lekicsinyítést és megadjuk a felhasználónak.
A gyorsítótárazási réteg CPU-ja itt sokkal olcsóbbnak bizonyul, mintha ezeket a méreteket folyamatosan újragenerálnánk minden tárolón. Tegyük fel, hogy szeretnénk hozzáadni egy újat, ez egy hónapot vesz igénybe – mindenhol futtasson egy szkriptet, amely mindezt szépen, a fürt tönkretétele nélkül teszi. Azok. Ha most van lehetőséged választani, akkor érdemes minél kevesebb fizikai méretet készíteni, de úgy, hogy legalább valamilyen eloszlás mondjuk három legyen. És minden más egyszerűen átméretezhető menet közben a kész modulok segítségével. Most mindez nagyon egyszerű és elérhető.
És az inkrementális aszinkron biztonsági mentés jó.
Ahogy a gyakorlatunk megmutatta, ez a séma kiválóan működik a megváltozott fájlok késleltetett másolásakor.
Az utolsó pont is nyilvánvaló. Ha az infrastruktúrájában most nincsenek ilyen gondok, de van valami, ami eltörhet, akkor biztosan elromlik, ha egy kicsit több lesz. Ezért jobb ezt előre átgondolni, és nem tapasztalni ezzel kapcsolatos problémákat. Csak ennyit akartam mondani.
Kapcsolat
»
»
Ez a jelentés a nagy terhelésű rendszerek fejlesztőinek konferenciáján elhangzott egyik legjobb beszéd átirata . Kevesebb, mint egy hónap van hátra a HighLoad++ 2017 konferenciáig.
Már készen is vagyunk , a menetrend most aktívan alakul.
Ebben az évben folytatjuk az architektúrák és a méretezés témakörének feltárását:
- / Igor Vasziljev
- / Dmitrij Egorov
- / Anatolij Plaszkovszkij
- / Roman Sehovcov, Alekszej Gromacsikov
- / Philip Delgado
Ezen anyagok egy részét a nagy terhelésű rendszerek fejlesztéséről szóló online tanfolyamunkon is felhasználjuk egy speciálisan kiválasztott levelek, cikkek, anyagok, videók lánca. Tankönyvünk már több mint 30 egyedi anyagot tartalmaz. Csatlakozz!
Forrás: will.com