Artjoms Deņisovs ( , )
Badoo ir pasaulē lielākā iepazīšanās vietne. Šobrīd mums ir aptuveni 330 miljoni reģistrētu lietotāju visā pasaulē. Taču mūsu šodienas sarunas kontekstā daudz svarīgāk ir tas, ka mēs glabājam aptuveni 3 petabaitus lietotāju fotoattēlu. Katru dienu mūsu lietotāji augšupielādē aptuveni 3,5 miljonus jaunu fotoattēlu, un lasīšanas slodze ir aptuveni 80 tūkstoši pieprasījumu sekundē. Mūsu aizmugursistēmai tas ir diezgan daudz, un dažreiz ar to rodas grūtības.
Es runāšu par šīs sistēmas dizainu, kas saglabā un nosūta fotoattēlus kopumā, un aplūkošu to no izstrādātāja viedokļa. Būs īsa retrospekcija par to, kā tas attīstījās, kur izklāstīšu galvenos pavērsienus, bet sīkāk runāšu tikai par risinājumiem, kurus šobrīd lietojam.
Tagad sāksim.
Kā jau teicu, šī būs retrospekcija, un, lai kaut kur to sāktu, ņemsim visizplatītāko piemēru.
Mums ir kopīgs uzdevums, mums ir jāpieņem, jāuzglabā un jānosūta lietotāju fotogrāfijas. Šajā formā uzdevums ir vispārīgs, mēs varam izmantot jebko:
- moderna mākoņkrātuve,
- kastes risinājums, kuru arī tagad ir daudz;
- Mēs varam uzstādīt vairākas mašīnas mūsu datu centrā un ievietot tajās lielus cietos diskus un uzglabāt fotoattēlus.
Badoo vēsturiski — gan tagad, gan tad (laikā, kad tas bija tikai sākumstadijā) — dzīvo uz saviem serveriem, mūsu pašu DC. Tāpēc šis variants mums bija optimāls.
Mēs tikko paņēmām vairākas mašīnas, nosaucām tās par “fotogrāfijām”, un mēs ieguvām kopu, kurā tiek glabāti fotoattēli. Bet šķiet, ka kaut kā pietrūkst. Lai tas viss izdotos, mums kaut kā jānosaka, uz kuras mašīnas kuras fotogrāfijas glabāsim. Un arī šeit nevajag Ameriku atvērt.
Mēs savai krātuvei pievienojam lauku ar informāciju par lietotājiem. Šī būs sadalīšanas atslēga. Mūsu gadījumā mēs to saucām par place_id, un šis vietas ID norāda uz vietu, kur tiek glabāti lietotāju fotoattēli. Mēs veidojam kartes.
Pirmajā posmā to var izdarīt pat manuāli - mēs sakām, ka šī lietotāja fotoattēls ar šādu vietu nonāks šādā serverī. Pateicoties šai kartei, mēs vienmēr zinām, kad lietotājs augšupielādē fotoattēlu, kur to saglabāt, un mēs zinām, no kurienes to dot.
Šī ir absolūti triviāla shēma, taču tai ir diezgan ievērojamas priekšrocības. Pirmais ir tas, ka tas ir vienkārši, kā jau teicu, un otrs ir tas, ka ar šo pieeju mēs varam viegli mērogot horizontāli, vienkārši piegādājot jaunas automašīnas un pievienojot tās kartei. Jums nekas cits nav jādara.
Tā tas bija pie mums kādu laiku.
Tas bija ap 2009. gadu. Viņi piegādāja automašīnas, piegādāja ...
Un kādā brīdī mēs sākām pamanīt, ka šai shēmai ir zināmi trūkumi. Kādi ir trūkumi?
Pirmkārt, ir ierobežota jauda. Mēs nevaram vienā fiziskajā serverī sabāzt tik daudz cieto disku, cik mēs vēlētos. Un tā laika gaitā un līdz ar datu kopas pieaugumu ir kļuvusi par noteiktu problēmu.
Un otrais. Šī ir netipiska iekārtu konfigurācija, jo šādas iekārtas ir grūti atkārtoti izmantot dažos citos klasteros, tās ir diezgan specifiskas, t.i. tiem jābūt vājiem veiktspējas ziņā, bet tajā pašā laikā ar lielu cieto disku.
Tas viss bija par 2009. gadu, bet principā šīs prasības ir aktuālas arī šodien. Mums ir retrospekcija, tāpēc 2009. gadā ar šo viss bija pilnīgi slikti.
Un pēdējais punkts ir cena.
Toreiz cena bija ļoti augsta, un mums vajadzēja meklēt alternatīvas. Tie. mums vajadzēja kaut kā labāk izmantot gan vietu datu centros, gan fiziskos serverus, uz kuriem tas viss atrodas. Un mūsu sistēmu inženieri sāka plašu pētījumu, kurā viņi pārskatīja virkni dažādu iespēju. Viņi arī aplūkoja kopu failu sistēmas, piemēram, PolyCeph un Luster. Bija darbības problēmas un diezgan sarežģīta darbība. Viņi atteicās. Mēs mēģinājām katrai automašīnai uzstādīt visu datu kopu, izmantojot NFS, lai to kaut kā palielinātu. Arī lasīšana gāja slikti, izmēģinājām dažādus risinājumus no dažādiem pārdevējiem.
Un galu galā mēs izmantojām tā saukto Storage Area Network.
Tie ir lieli SHD, kas ir īpaši paredzēti liela datu apjoma glabāšanai. Tie ir plaukti ar diskiem, kas ir uzstādīti gala optiskās izvades mašīnās. Tas. mums ir kaut kāds mašīnu kopums, diezgan mazs, un šie SHD, kas ir caurspīdīgi mūsu sūtīšanas loģikai, t.i. lai mūsu nginx vai kāds cits apkalpotu šo fotoattēlu pieprasījumus.
Šim lēmumam bija acīmredzamas priekšrocības. Tas ir SHD. Tas ir paredzēts fotoattēlu glabāšanai. Tas ir lētāk nekā vienkārši iekārtu aprīkošana ar cietajiem diskiem.
Otrais pluss.
Tas ir, ka jauda ir kļuvusi daudz lielāka, t.i. mēs varam uzņemt daudz vairāk krātuves daudz mazākā apjomā.
Bet bija arī trūkumi, kas parādījās diezgan ātri. Pieaugot lietotāju skaitam un šīs sistēmas slodzei, sāka rasties veiktspējas problēmas. Un problēma šeit ir diezgan acīmredzama - jebkurš SHD, kas paredzēts daudzu fotoattēlu glabāšanai nelielā apjomā, parasti cieš no intensīvas lasīšanas. Tas faktiski attiecas uz jebkuru mākoņkrātuvi vai jebko citu. Tagad mums nav ideālas krātuves, kas būtu bezgalīgi mērogojama, tajā varētu iebāzt jebko, un tā ļoti labi panes rādījumus. Īpaši gadījuma lasījumi.
Tāpat kā mūsu fotogrāfiju gadījumā, jo fotogrāfijas tiek pieprasītas nekonsekventi, un tas lielā mērā ietekmēs to veiktspēju.
Pat saskaņā ar šodienas skaitļiem, ja mēs kaut kur iegūstam vairāk nekā 500 RPS fotoattēliem ierīcē, kurai ir pievienota krātuve, problēmas jau sākas. Un mums tas bija pietiekami slikti, jo lietotāju skaits aug, viss tikai pasliktināsies. Tas ir kaut kā jāoptimizē.
Lai optimizētu, nolēmām toreiz, acīmredzot, apskatīt slodzes profilu - kas vispār notiek, kas jāoptimizē.
Un šeit viss spēlē mūsu rokās.
Es jau teicu pirmajā slaidā: mums ir 80 tūkstoši lasīšanas pieprasījumu sekundē un tikai 3,5 miljoni augšupielādes dienā. Tas ir, šī ir trīs lieluma kārtu atšķirība. Ir skaidrs, ka lasīšana ir jāoptimizē un ir praktiski skaidrs, kā.
Ir vēl viens mazs punkts. Pakalpojuma specifika ir tāda, ka cilvēks reģistrējas, augšupielādē fotoattēlu, pēc tam sāk aktīvi skatīties uz citiem cilvēkiem, viņiem patīk un tiek aktīvi parādīts citiem cilvēkiem. Pēc tam viņš atrod dzīvesbiedru vai neatrod, tas ir atkarīgs no tā, kā tas izrādīsies, un uz laiku pārtrauc izmantot pakalpojumu. Šobrīd, kad viņš to izmanto, viņa fotogrāfijas ir ļoti karstas - tās ir pieprasītas, tās skatās ļoti daudz cilvēku. Tiklīdz viņš pārtrauc to darīt, viņš diezgan ātri izstājas no tik daudz citu cilvēku saskarsmes kā iepriekš, un viņa fotogrāfijas gandrīz nekad netiek pieprasītas.
Tie. Mums ir ļoti maza karstā datu kopa. Bet tajā pašā laikā viņam ir daudz pieprasījumu. Un pilnīgi acīmredzams risinājums šeit ir pievienot kešatmiņu.
Kešatmiņa ar LRU atrisinās visas mūsu problēmas. Ko mēs darām?
Mēs pievienojam vēl vienu salīdzinoši mazu mūsu lielajam klasterim ar krātuvi, ko sauc par foto kešatmiņām. Tas būtībā ir tikai kešatmiņas starpniekserveris.
Kā tas darbojas no iekšpuses? Šeit ir mūsu lietotājs, šeit ir krātuve. Viss ir tāpat kā iepriekš. Ko mēs pievienojam pa vidu?
Tā ir tikai mašīna ar fizisku lokālo disku, kas ir ātra. Tas ir, piemēram, ar SSD. Un šajā diskā ir saglabāta sava veida lokālā kešatmiņa.
Kā tas izskatās? Lietotājs nosūta fotoattēlu pieprasījumu. NGINX vispirms to meklē vietējā kešatmiņā. Ja nē, vienkārši proxy_pass uz mūsu krātuvi, lejupielādējiet fotoattēlu no turienes un nododiet to lietotājam.
Bet šis ir ļoti banāls un nav skaidrs, kas notiek iekšā. Tas darbojas apmēram šādi.
Kešatmiņa ir loģiski sadalīta trīs slāņos. Kad es saku “trīs slāņi”, tas nenozīmē, ka pastāv kaut kāda sarežģīta sistēma. Nē, tie nosacīti ir tikai trīs failu sistēmas direktoriji:
- Šis ir buferis, kurā tiek ievietoti fotoattēli, kas tikko lejupielādēti no starpniekservera.
- Šī ir karstā kešatmiņa, kurā tiek glabāti pašlaik aktīvi pieprasītie fotoattēli.
- Un aukstā kešatmiņa, kur fotogrāfijas pamazām tiek izstumtas no karstās kešatmiņas, kad uz tām nāk mazāk pieprasījumu.
Lai tas darbotos, mums ir kaut kā jāpārvalda šī kešatmiņa, jāpārkārto tajā esošie fotoattēli utt. Tas ir arī ļoti primitīvs process.
Nginx vienkārši ieraksta RAMDisk access.log katram pieprasījumam, kurā tas norāda ceļu uz fotoattēlu, kuru tas pašlaik ir apkalpojis (protams, relatīvais ceļš) un kuru nodalījumu tas tika apkalpots. Tie. tas var rakstīt “foto 1” un pēc tam buferis, vai karstā kešatmiņa, vai aukstā kešatmiņa, vai starpniekserveris.
Atkarībā no tā mums kaut kā jāizlemj, ko darīt ar fotoattēlu.
Mums katrā mašīnā darbojas neliels dēmons, kas pastāvīgi nolasa šo žurnālu un saglabā atmiņā statistiku par noteiktu fotogrāfiju izmantošanu.
Viņš tur vienkārši savāc, glabā skaitītājus un periodiski veic sekojošo. Viņš pārvieto aktīvi pieprasītās fotogrāfijas, kurām ir daudz pieprasījumu, uz karsto kešatmiņu, lai kur tās atrastos.
Fotoattēli, kas tiek pieprasīti reti un ir kļuvuši pieprasīti retāk, tiek pakāpeniski izstumti no karstās kešatmiņas aukstajā.
Un, kad kešatmiņā pietrūkst vietas, mēs vienkārši sākam bez izšķirības dzēst visu no aukstās kešatmiņas. Un, starp citu, tas darbojas labi.
Lai fotoattēls tiktu saglabāts uzreiz, kad to ievieto starpniekserverī buferī, mēs izmantojam proxy_store direktīvu un buferis ir arī RAMDisk, t.i. lietotājam tas darbojas ļoti ātri. Tas attiecas uz paša kešatmiņas servera iekšējiem elementiem.
Atlikušais jautājums ir par to, kā sadalīt pieprasījumus šajos serveros.
Pieņemsim, ka ir divdesmit krātuves mašīnu kopa un trīs kešatmiņas serveri (tā tas notika).
Mums kaut kā jānosaka, kuri fotoattēli ir pieprasīti un kur tos nosūtīt.
Visizplatītākā iespēja ir Round Robin. Vai arī izdari to nejauši?
Tam acīmredzami ir vairāki trūkumi, jo šādā situācijā mēs kešatmiņu izmantotu ļoti neefektīvi. Pieprasījumi nonāks dažās nejaušās mašīnās: šeit tas tika saglabāts kešatmiņā, bet nākamajā vairs nav. Un, ja tas viss darbosies, tas būs ļoti slikti. Pat ar nelielu skaitu mašīnu klasterī.
Mums kaut kā nepārprotami jānosaka, kuram serverim kuru pieprasījumu nosūtīt.
Ir banāls veids. Mēs ņemam jaucējkodu no URL vai jaucējkodu no mūsu sadalīšanas atslēgas, kas atrodas vietrādī URL, un sadalām to ar serveru skaitu. Strādās? gribas.
Tie. Mums ir 2% pieprasījums, piemēram, kādam “example_url” tas vienmēr nonāks serverī ar indeksu “XNUMX”, un kešatmiņa tiks pastāvīgi atbrīvota pēc iespējas labāk.
Bet šādā shēmā ir problēma ar atkārtotu sadalīšanu. Pārdalīšana — es domāju serveru skaita maiņu.
Pieņemsim, ka mūsu kešatmiņas klasteris vairs nevar tikt galā, un mēs nolemjam pievienot citu mašīnu.
Papildināsim.
Tagad viss dalās nevis ar trīs, bet četri. Tādējādi gandrīz visas atslēgas, kas mums bija agrāk, gandrīz visi URL tagad atrodas citos serveros. Visa kešatmiņa vienkārši uz brīdi tika atzīta par nederīgu. Visi pieprasījumi nonāca mūsu krātuves klasterī, kļuva slikti, pakalpojuma kļūme un neapmierināti lietotāji. Es nevēlos to darīt.
Arī šis variants mums neder.
Tas. ko mums vajadzētu darīt? Mums kaut kā efektīvi jāizmanto kešatmiņa, atkal un atkal jānosūta viens un tas pats pieprasījums tajā pašā serverī, taču jābūt izturīgam pret atkārtotu sadalīšanu. Un ir tāds risinājums, tas nav tik sarežģīts. To sauc par konsekventu jaukšanu.
Kā tas izskatās?
Mēs paņemam kādu funkciju no sadalīšanas atslēgas un visas tās vērtības izklājam uz apļa. Tie. punktā 0 tā minimālās un maksimālās vērtības saplūst. Tālāk mēs visus savus serverus ievietojam vienā lokā aptuveni šādā veidā:
Katru serveri nosaka viens punkts, un sektoru, kas iet uz to pulksteņrādītāja virzienā, attiecīgi apkalpo šis resursdators. Kad pie mums pienāk pieprasījumi, mēs uzreiz redzam, ka, piemēram, pieprasījums A - tur ir hash - un to apkalpo serveris 2. Pieprasījums B - serveris 3. Un tā tālāk.
Kas šajā situācijā notiek atkārtotas sadalīšanas laikā?
Mēs neatklājam visu kešatmiņu, kā iepriekš, un nepārvietojam visus taustiņus, bet mēs pārvietojam katru sektoru nelielā attālumā, lai, nosacīti runājot, mūsu sestais serveris, kuru vēlamies pievienot, ietilptu brīvajā vietā un mēs to tur pievienojam.
Protams, šādā situācijā izkustas arī atslēgas. Bet viņi iziet daudz vājāk nekā iepriekš. Un mēs redzam, ka mūsu pirmās divas atslēgas palika viņu serveros, un kešatmiņas serveris mainījās tikai pēdējai atslēgai. Tas darbojas diezgan efektīvi, un, ja pakāpeniski pievienojat jaunus saimniekdatorus, šeit nav lielu problēmu. Pamazām pievienojat un pievienojat, pagaidiet, līdz kešatmiņa atkal ir pilna, un viss darbojas labi.
Vienīgais jautājums paliek par atteikumiem. Pieņemsim, ka kāda veida automašīna ir izgājusi no ierindas.
Un mēs šobrīd negribētu reģenerēt šo karti, padarīt nederīgu daļu no kešatmiņas un tā tālāk, ja, piemēram, iekārta ir pārstartēta un mums kaut kādā veidā ir jāizpilda pakalpojumu pieprasījumi. Mēs vienkārši glabājam vienu rezerves fotoattēlu kešatmiņu katrā vietnē, kas darbojas kā aizstājējs jebkurai ierīcei, kas pašlaik nedarbojas. Un, ja pēkšņi kāds no mūsu serveriem kļūst nepieejams, trafika notiek tur. Protams, mums tur nav nekādas kešatmiņas, t.i. ir auksts, bet vismaz lietotāju pieprasījumi tiek apstrādāti. Ja tas ir īss intervāls, tad mēs to piedzīvojam pilnīgi mierīgi. Tikai krātuvē ir vairāk slodzes. Ja šis intervāls ir garš, tad jau varam pieņemt lēmumu – noņemt šo serveri no kartes vai nē, vai varbūt aizstāt ar citu.
Tas attiecas uz kešatmiņas sistēmu. Apskatīsim rezultātus.
Šķiet, ka šeit nav nekā sarežģīta. Bet šī kešatmiņas pārvaldības metode mums deva aptuveni 98%. Tie. no šiem 80 tūkstošiem pieprasījumu sekundē tikai 1600 sasniedz krātuvi, un tā ir pilnīgi normāla slodze, viņi to mierīgi iztur, mums vienmēr ir rezerve.
Mēs ievietojām šos serverus trīs no mūsu DC un saņēmām trīs klātbūtnes punktus — Prāgā, Maiami un Honkongā.
Tas. tie vairāk vai mazāk atrodas katrā mūsu mērķa tirgū.
Un kā jauku bonusu dabūjām šo kešatmiņas starpniekserveri, uz kura CPU faktiski ir dīkstāvē, jo satura apkalpošanai tas nav tik vajadzīgs. Un tur, izmantojot NGINX+ Lua, mēs ieviesām daudz utilitāras loģikas.
Piemēram, mēs varam eksperimentēt ar webp vai progresīvo jpeg (tie ir efektīvi mūsdienu formāti), redzēt, kā tas ietekmē trafiku, pieņemt dažus lēmumus, iespējot noteiktām valstīm utt.; dinamiski mainiet fotoattēlu izmērus vai apgrieziet tos.
Tas ir labs pielietojums, ja, piemēram, jums ir mobilā lietojumprogramma, kas parāda fotoattēlus, un mobilā lietojumprogramma nevēlas tērēt klienta centrālo procesoru, lai pieprasītu lielu fotoattēlu un pēc tam mainītu tā izmērus, lai to ievietotu. skats. Mēs varam vienkārši dinamiski norādīt dažus parametrus UPort nosacījuma URL, un fotoattēlu kešatmiņa mainīs paša fotoattēla izmēru. Parasti tas izvēlēsies izmēru, kas mums fiziski atrodas diskā, pēc iespējas tuvāk pieprasītajam un pārdos to noteiktās koordinātēs.
Starp citu, esam padarījuši publiski pieejamus pēdējo piecu gadu augstas slodzes sistēmu izstrādātāju konferences video ierakstus . Skatieties, mācieties, kopīgojiet un abonējiet .
Mēs tur varam pievienot arī daudz produkta loģikas. Piemēram, mēs varam pievienot dažādas ūdenszīmes, izmantojot URL parametrus, mēs varam aizmiglot, aizmiglot vai pikselēt fotogrāfijas. Tas ir tad, kad mēs vēlamies parādīt cilvēka fotoattēlu, bet mēs nevēlamies parādīt viņa seju, tas darbojas labi, tas viss šeit ir ieviests.
Ko mēs saņēmām? Mēs saņēmām trīs klātbūtnes punktus, labu triku ātrumu, un tajā pašā laikā mums šajās iekārtās nav dīkstāves CPU. Tagad viņš, protams, ir kļuvis svarīgāks nekā agrāk. Mums ir jādod sev spēcīgākas automašīnas, bet tas ir tā vērts.
Tas attiecas uz fotogrāfiju atgriešanu. Šeit viss ir diezgan skaidrs un skaidrs. Es domāju, ka es neatklāju Ameriku, gandrīz jebkurš CDN darbojas šādā veidā.
Un, visticamāk, izsmalcinātam klausītājam varētu rasties jautājums: kāpēc gan nemainīt visu uz CDN? Tas būtu apmēram tas pats; visi mūsdienu CDN to var izdarīt. Un tam ir vairāki iemesli.
Pirmā ir fotogrāfijas.
Šis ir viens no mūsu infrastruktūras galvenajiem punktiem, un mums ir nepieciešama pēc iespējas lielāka kontrole pār to. Ja tas ir sava veida risinājums no trešās puses piegādātāja un jums nav nekādas varas pār to, jums būs diezgan grūti ar to sadzīvot, ja jums ir liela datu kopa un ja jums ir ļoti liela plūsma. lietotāju pieprasījumu.
Ļaujiet man sniegt jums piemēru. Tagad ar savu infrastruktūru mēs varam, piemēram, kaut kādu problēmu vai pazemes klauvējienu gadījumā aiziet pie mašīnas un tur nosacīti izjaukt. Mēs varam pievienot tikai mums nepieciešamo metriku kolekciju, mēs varam kaut kā eksperimentēt, redzēt, kā tas ietekmē grafikus un tā tālāk. Tagad par šo kešatmiņas kopu tiek vākta liela statistika. Un mēs periodiski to aplūkojam un pavadām ilgu laiku, pētot dažas anomālijas. Ja tas būtu CDN pusē, to būtu daudz grūtāk kontrolēt. Vai, piemēram, ja notiek kāda nelaime, mēs zinām, kas noticis, zinām, kā ar to sadzīvot un kā to pārvarēt. Šis ir pirmais secinājums.
Arī otrs secinājums ir diezgan vēsturisks, jo sistēma ir izstrādāta ilgu laiku, un dažādos posmos bija daudz dažādu biznesa prasību, kas ne vienmēr iekļaujas CDN koncepcijā.
Un punkts, kas izriet no iepriekšējā, ir
Tas ir tāpēc, ka fotoattēlu kešatmiņās mums ir daudz specifiskas loģikas, ko ne vienmēr var pievienot pēc pieprasījuma. Maz ticams, ka kāds CDN pēc jūsu pieprasījuma jums pievienos dažas pielāgotas lietas. Piemēram, vietrāžu URL šifrēšana, ja nevēlaties, lai klients varētu kaut ko mainīt. Vai vēlaties mainīt URL serverī un šifrēt to, un pēc tam nosūtīt šeit dažus dinamiskos parametrus.
Kādu secinājumu tas liek domāt? Mūsu gadījumā CDN nav ļoti laba alternatīva.
Un jūsu gadījumā, ja jums ir kādas konkrētas biznesa prasības, tad jūs varat diezgan viegli īstenot to, ko es jums parādīju pats. Un tas lieliski darbosies ar līdzīgu slodzes profilu.
Bet, ja jums ir kāds vispārīgs risinājums un uzdevums nav ļoti specifisks, varat pilnīgi droši izmantot CDN. Vai arī laiks un resursi jums ir svarīgāki par kontroli.
Un mūsdienu CDN ir gandrīz viss, par ko es jums teicu tagad. Izņemot plus vai mīnus dažas funkcijas.
Tas ir par fotoattēlu dāvināšanu.
Tagad pavirzīsimies nedaudz uz priekšu savā retrospekcijā un runāsim par uzglabāšanu.
2013. gads pagāja.
Tika pievienoti kešatmiņas serveri, veiktspējas problēmas pazuda. Viss ir kārtībā. Datu kopa pieaug. 2013. gadā mums bija aptuveni 80 serveru, kas bija savienoti ar krātuvi, un aptuveni 40 serveru, kas tika saglabāti kešatmiņā katrā DC. Tas ir 560 terabaiti datu katrā DC, t.i. kopā apmēram petabaitu.
Pieaugot datu kopai, darbības izmaksas sāka ievērojami pieaugt. Ko tas nozīmēja?
Šajā diagrammā, kas ir uzzīmēta ar SAN, ar tai pievienotām mašīnām un kešatmiņām, ir daudz atteices punktu. Ja jau iepriekš bijām tikuši galā ar kešatmiņas serveru kļūmēm, viss bija vairāk vai mazāk paredzams un saprotams, bet uzglabāšanas pusē viss bija daudz sliktāk.
Pirmkārt, ir pats krātuves tīkls (SAN), kas var neizdoties.
Otrkārt, tas caur optiku ir savienots ar gala mašīnām. Var būt problēmas ar optiskajām kartēm un aizdedzes svecēm.
Protams, to nav tik daudz kā pašā SAN, taču tie tomēr ir arī neveiksmes punkti.
Tālāk ir pati iekārta, kas ir savienota ar krātuvi. Tas var arī neizdoties.
Kopumā mums ir trīs neveiksmes punkti.
Turklāt papildus atteices punktiem tiek veikta nopietna pašas krātuves apkope.
Šī ir sarežģīta daudzkomponentu sistēma, un sistēmu inženieriem var būt grūti ar to strādāt.
Un pēdējais, vissvarīgākais punkts. Ja kādā no šiem trim punktiem rodas kļūme, mums ir nulle iespēja zaudēt lietotāja datus, jo failu sistēma var avarēt.
Pieņemsim, ka mūsu failu sistēma ir bojāta. Pirmkārt, tā atkopšana aizņem ilgu laiku - ar lielu datu apjomu tas var aizņemt nedēļu. Un, otrkārt, galu galā mēs, visticamāk, nonāksim pie nesaprotamu failu gūzmas, kas būs kaut kā jāapvieno lietotāju fotogrāfijās. Un mēs riskējam zaudēt datus. Risks ir diezgan augsts. Un jo biežāk šādas situācijas notiek un jo vairāk problēmu rodas visā šajā ķēdē, jo lielāks ir šis risks.
Kaut kas bija jādara lietas labā. Un mēs nolēmām, ka mums vienkārši jādublē dati. Tas patiesībā ir acīmredzams un labs risinājums. Ko mēs esam izdarījuši?
Šādi izskatījās mūsu serveris, kad tas iepriekš bija savienots ar krātuvi. Šī ir viena no galvenajām sadaļām, tā ir tikai bloka ierīce, kas faktiski attēlo attālās glabāšanas stiprinājumu, izmantojot optiku.
Mēs tikko pievienojām otru sadaļu.
Mēs novietojām tai blakus otru krātuvi (par laimi, tā nav tik dārga naudas izteiksmē) un nosaucām to par rezerves nodalījumu. Tas ir arī savienots ar optiku un atrodas tajā pašā mašīnā. Bet mums ir kaut kā jāsinhronizē dati starp tiem.
Šeit mēs vienkārši izveidojam asinhronu rindu tuvumā.
Viņa nav ļoti aizņemta. Mēs zinām, ka mums nav pietiekami daudz ierakstu. Rinda ir tikai tabula MySQL, kurā ir rakstītas tādas rindas kā “jums ir jādublē šis fotoattēls”. Veicot jebkādas izmaiņas vai augšupielādi, mēs kopējam no galvenā nodalījuma uz dublējumu, izmantojot asinhronu vai tikai kādu fona darbinieku.
Tādējādi mums vienmēr ir divas konsekventas sadaļas. Pat ja kāda šīs sistēmas daļa neizdodas, mēs vienmēr varam mainīt galveno nodalījumu ar rezerves kopiju, un viss turpinās darboties.
Taču tādēļ lasīšanas slodze stipri palielinās, jo... papildus klientiem, kuri lasa no galvenās sadaļas, jo viņi vispirms apskata tur esošo fotoattēlu (tur tas ir jaunāks) un pēc tam meklē to dublējumkopijā, ja viņi to nav atraduši (bet NGINX tikai to dara), mūsu sistēma ir arī plus dublējums, ko tagad nolasa no galvenā nodalījuma. Nav tā, ka tas bija sašaurinājums, bet es nevēlējos palielināt slodzi būtībā tieši tāpat.
Un mēs pievienojām trešo disku, kas ir mazs SSD, un nosaucām to par buferi.
Kā tas darbojas tagad.
Lietotājs augšupielādē fotoattēlu buferī, pēc tam rindā tiek iemests notikums, kas norāda, ka tas ir jākopē divās sadaļās. Tas tiek kopēts, un fotoattēls kādu laiku (teiksim, dienu) atrodas buferī un tikai pēc tam tiek notīrīts no turienes. Tas ievērojami uzlabo lietotāja pieredzi, jo lietotājs augšupielādē fotoattēlu, kā likums, nekavējoties sāk sekot pieprasījumi, vai arī viņš pats atjaunināja lapu un atsvaidzina to. Bet tas viss ir atkarīgs no lietojumprogrammas, kas veic augšupielādi.
Vai, piemēram, citi cilvēki, kuriem viņš sāka sevi parādīt, nekavējoties nosūta pieprasījumus pēc šīs fotogrāfijas. Tas vēl nav kešatmiņā; pirmais pieprasījums notiek ļoti ātri. Būtībā tas pats, kas no fotoattēlu kešatmiņas. Lēna uzglabāšana šajā gadījumā vispār nav saistīta. Un, kad dienu vēlāk tas tiek iztīrīts, tas jau ir vai nu kešatmiņā mūsu kešatmiņas slānī, vai, visticamāk, nevienam vairs nav vajadzīgs. Tie. Lietotāju pieredze šeit ir ļoti labi augusi, pateicoties tik vienkāršām manipulācijām.
Nu, un pats galvenais: mēs pārstājām zaudēt datus.
Pieņemsim, ka mēs apstājāmies potenciāli zaudēt datus, jo mēs tos īsti nezaudējām. Bet bija briesmas. Mēs redzam, ka šis risinājums, protams, ir labs, taču tas ir nedaudz kā problēmas simptomu izlīdzināšana, nevis tās pilnīga atrisināšana. Un šeit paliek dažas problēmas.
Pirmkārt, tas ir neveiksmes punkts paša fiziskā saimniekdatora veidā, uz kura darbojas visa šī iekārta; tas nav pazudis.
Otrkārt, joprojām ir problēmas ar SAN, paliek to smagā apkope utt. Nebija tā, ka tas bija kritisks faktors, bet es gribēju mēģināt kaut kā iztikt bez tā.
Un mēs taisījām trešo variantu (faktiski otro) - rezervācijas variantu. Kā tas izskatījās?
Lūk, kas tas bija -
Mūsu galvenās problēmas ir fakts, ka šis ir fizisks saimnieks.
Pirmkārt, mēs noņemam SAN, jo mēs vēlamies eksperimentēt, mēs vēlamies izmēģināt tikai vietējos cietos diskus.
Šis ir jau 2014.-2015. gads, un toreiz situācija ar diskiem un to ietilpību vienā resursdatorā kļuva daudz labāka. Mēs nolēmām, kāpēc gan nepamēģināt.
Un tad mēs vienkārši paņemam savu rezerves nodalījumu un fiziski pārsūtām to uz atsevišķu mašīnu.
Tādējādi mēs iegūstam šo diagrammu. Mums ir divas automašīnas, kas glabā vienas un tās pašas datu kopas. Viņi pilnībā dublē viens otru un sinhronizē datus tīklā, izmantojot asinhrono rindu tajā pašā MySQL.
Kāpēc tas darbojas labi, jo mums ir maz ierakstu. Tie. ja rakstīšana būtu salīdzināma ar lasīšanu, iespējams, mums būtu kāda veida tīkla pārslodze un problēmas. Ir maz rakstīšanas, daudz lasīšanas - šī metode darbojas labi, t.i. Mēs reti kopējam fotoattēlus starp šiem diviem serveriem.
Kā tas darbojas, ja paskatās nedaudz sīkāk.
Augšupielādēt. Balansētājs vienkārši atlasa nejaušus saimniekdatorus ar pāri un augšupielādē tajā. Tajā pašā laikā viņš dabiski veic veselības pārbaudes un rūpējas, lai automašīna neizkristu. Tie. viņš augšupielādē fotoattēlus tikai tiešā serverī, un pēc tam caur asinhrono rindu tas viss tiek kopēts viņa kaimiņam. Ar augšupielādi viss ir ļoti vienkārši.
Uzdevums ir nedaudz grūtāks.
Lua mums palīdzēja šeit, jo var būt grūti izveidot šādu loģiku uz vaniļas NGINX. Vispirms uzdodam pieprasījumu pirmajam serverim, paskatāmies, vai bilde tur ir, jo potenciāli tā varētu tikt augšupielādēta, piemēram, kaimiņam, bet vēl šeit nav nonākusi. Ja fotogrāfija ir tur, tas ir labi. Mēs to nekavējoties nododam klientam un, iespējams, saglabājam kešatmiņā.
Ja tā nav, mēs vienkārši iesniedzam pieprasījumu savam kaimiņam un garantēti to saņemsim no turienes.
Tas. atkal varam teikt: var būt problēmas ar veiktspēju, jo ir nepārtraukti braucieni turp un atpakaļ - fotogrāfija tika augšupielādēta, tā šeit nav, mēs veicam divus pieprasījumus viena vietā, šim vajadzētu strādāt lēnām.
Mūsu situācijā tas nedarbojas lēni.
Mēs šajā sistēmā apkopojam virkni metrikas, un šāda mehānisma nosacītā viedā likme ir aptuveni 95%. Tie. Šī dublējuma nobīde ir neliela, un tāpēc mums ir gandrīz garantēts, ka pēc fotoattēla augšupielādes mēs to paņemsim pirmo reizi un nekur nebūs jādodas divreiz.
Tātad, kas vēl mums ir patiešām foršs?
Iepriekš mums bija galvenais rezerves nodalījums, un mēs tos lasījām secīgi. Tie. Mēs vienmēr vispirms meklējām galvenajā un pēc tam dublējumkopijā. Tā bija viena kustība.
Tagad mēs izmantojam nolasīšanu no divām iekārtām vienlaikus. Mēs izplatām pieprasījumus, izmantojot Round Robin. Nelielā daļā gadījumu mēs iesniedzam divus pieprasījumus. Bet kopumā mums tagad ir divreiz vairāk lasāmvielu nekā iepriekš. Un slodze tika stipri samazināta gan sūtīšanas mašīnām, gan tieši uzglabāšanas mašīnām, kas arī mums tajā laikā bija.
Kas attiecas uz kļūdu toleranci. Patiesībā par to mēs galvenokārt cīnījāmies. Ar kļūdu toleranci šeit viss izdevās lieliski.
Viena automašīna sabojājas.
Nekādu problēmu! Sistēmas inženieris var pat nepamosties naktī, viņš nogaidīs līdz rītam, nekas slikts nenotiks.
Ja pat tad, ja šī iekārta sabojājas, rinda nav kārtībā, arī nav nekādu problēmu, žurnāls vienkārši tiks uzkrāts vispirms dzīvajā mašīnā, un tad tas tiks pievienots rindai un pēc tam automašīnai, kas pēc kāda laika sāciet darboties.
Tas pats ar apkopi. Mēs vienkārši izslēdzam vienu no mašīnām, manuāli izvelkam to no visiem baseiniem, tas pārstāj saņemt trafiku, mēs veicam kaut kādu apkopi, mēs kaut ko rediģējam, tad atgriežam to servisā, un šī rezerves kopija diezgan ātri panāk. Tie. dienā vienas automašīnas dīkstāve pienāk pāris minūšu laikā. Tas tiešām ir ļoti maz. Ar kļūdu toleranci vēlreiz saku, šeit viss ir forši.
Kādus secinājumus var izdarīt no šīs atlaišanas shēmas?
Mums ir kļūdu tolerance.
Viegli izmantot. Tā kā iekārtām ir lokālie cietie diski, tas ir daudz ērtāk no darbības viedokļa inženieriem, kuri ar to strādā.
Mēs saņēmām dubultu lasīšanas pabalstu.
Tas ir ļoti labs bonuss papildus kļūdu tolerancei.
Bet ir arī problēmas. Tagad mums ir daudz sarežģītāka dažu ar to saistīto funkciju izstrāde, jo sistēma galu galā ir kļuvusi 100% konsekventa.
Mums, teiksim, kaut kādā fona darbā pastāvīgi jādomā: "Kādā serverī mēs tagad strādājam?", "Vai šeit tiešām ir aktuāls fotoattēls?" utt. Tas, protams, viss ir iesaiņots, un programmētājam, kurš raksta biznesa loģiku, tas ir caurspīdīgs. Bet tomēr šis lielais kompleksais slānis ir parādījies. Bet mēs esam gatavi to paciest apmaiņā pret labumiem, ko no tā saņēmām.
Un te atkal rodas kāds konflikts.
Es jau sākumā teicu, ka visu glabāt vietējos cietajos diskos ir slikti. Un tagad es saku, ka mums patika.
Jā, patiešām, laika gaitā situācija ir ļoti mainījusies, un tagad šai pieejai ir daudz priekšrocību. Pirmkārt, mēs iegūstam daudz vienkāršāku darbību.
Otrkārt, tas ir produktīvāk, jo mums nav šo automātisko kontrolleru vai savienojumu ar disku plauktiem.
Tur ir milzīgs daudzums tehnikas, un tie ir tikai daži diski, kas tiek samontēti šeit uz mašīnas reidā.
Bet ir arī trūkumi.
Tas ir aptuveni 1,5 reizes dārgāk nekā SAN izmantošana pat par mūsdienu cenām. Tāpēc mēs nolēmām visu savu lielo kopu drosmīgi nepārveidot par automašīnām ar vietējiem cietajiem diskiem un nolēmām atstāt hibrīda risinājumu.
Puse no mūsu mašīnām strādā ar cietajiem diskiem (labi, nevis puse - iespējams, 30 procenti). Un pārējās ir vecas automašīnas, kurām agrāk bija pirmā rezervācijas shēma. Mēs tos vienkārši pārmontējām, jo mums nebija vajadzīgi jauni dati vai kaut kas cits, mēs vienkārši pārvietojām stiprinājumus no viena fiziskā resursdatora uz diviem.
Un tagad mums ir liels lasāmvielu krājums, un mēs to paplašinājām. Ja agrāk uz vienas mašīnas uzstādījām vienu krātuvi, tad tagad, piemēram, uz viena pāra montējam četras. Un tas darbojas labi.
Ņemsim īsu kopsavilkumu par paveikto, par ko cīnījāmies un vai mums tas izdevās.
Rezultāti
Mums ir lietotāji – veseli 33 miljoni.
Mums ir trīs klātbūtnes punkti - Prāga, Maiami, Honkonga.
Tie satur kešatmiņas slāni, kas sastāv no automašīnām ar ātriem vietējiem diskiem (SSD), uz kuriem darbojas vienkāršas iekārtas no NGINX, tās access.log un Python dēmoni, kas to visu apstrādā un pārvalda kešatmiņu.
Ja vēlies, esi savā projektā, ja fotogrāfijas tev nav tik kritiskas kā mums vai ja kompromisa kontrole pret izstrādes ātrumu un resursu izmaksām tev ir otrā virzienā, tad vari tās droši nomainīt ar CDN, mūsdienu CDN tie darbojas labi.
Tālāk nāk krātuves slānis, kurā mums ir mašīnu pāru kopas, kas dublē viens otru, faili tiek asinhroni kopēti no viena uz otru ikreiz, kad tie mainās.
Turklāt dažas no šīm mašīnām darbojas ar vietējiem cietajiem diskiem.
Dažas no šīm iekārtām ir savienotas ar SAN.
Un, no vienas puses, tas ir ērtāk lietojams un nedaudz produktīvāks, no otras puses, tas ir ērti izvietojuma blīvuma un gigabaita cenas ziņā.
Šis ir tik īss pārskats par arhitektūru, ko mēs ieguvām un kā tas viss attīstījās.
Vēl daži kapteiņa padomi, pavisam vienkārši.
Pirmkārt, ja pēkšņi nolemjat, ka jums steidzami jāuzlabo viss jūsu foto infrastruktūrā, vispirms izmēriet, jo, iespējams, nekas nav jāuzlabo.
Ļaujiet man sniegt jums piemēru. Mums ir mašīnu kopa, kas čatos sūta fotogrāfijas no pielikumiem, un shēma tur darbojas kopš 2009. gada, un neviens no tā necieš. Visiem ir labi, visiem viss patīk.
Lai veiktu mērījumus, vispirms pakariniet virkni rādītāju, apskatiet tos un pēc tam izlemiet, ar ko neesat apmierināts un kas ir jāuzlabo. Lai to izmērītu, mums ir foršs rīks ar nosaukumu Pinba.
Tas ļauj apkopot ļoti detalizētu statistiku no NGINX par katru pieprasījumu un atbildes kodiem, kā arī laiku sadalījumu — ko vien vēlaties. Tas ir saistīts ar visdažādākajām analītikas sistēmām, un tad jūs varat to visu skaisti aplūkot.
Vispirms izmērījām, tad uzlabojām.
Tālāk. Mēs optimizējam lasīšanu, izmantojot kešatmiņu, rakstīšanu ar sadalīšanu, taču tas ir acīmredzams.
Tālāk. Ja jūs tikai tagad sākat veidot savu sistēmu, daudz labāk ir izveidot fotoattēlus kā nemainīgus failus. Jo jūs uzreiz zaudējat veselu problēmu klasi ar kešatmiņas nederīgumu, ar to, kā loģikai vajadzētu atrast pareizo fotoattēla versiju utt.
Pieņemsim, ka augšupielādējāt simtu, pēc tam to pagriezāt un izveidojāt tā, lai tas būtu fiziski atšķirīgs fails. Tie. nav jādomā: tagad es ietaupīšu nedaudz vietas, ierakstīšu to tajā pašā failā, mainīšu versiju. Tas vienmēr nedarbojas labi un vēlāk rada daudz galvassāpes.
Nākamais punkts. Par izmēru maiņu lidojumā.
Iepriekš, kad lietotāji augšupielādēja fotoattēlu, mēs nekavējoties izgriezām veselu kaudzi izmēru visiem gadījumiem, dažādiem klientiem, un tie visi bija diskā. Tagad mēs no tā esam atteikušies.
Mēs atstājām tikai trīs galvenos izmērus: mazu, vidēju un lielu. Mēs vienkārši samazinām visu pārējo no izmēra, kas ir aiz tā, kas mums tika lūgts Uportā, mēs vienkārši samazinām mērogu un piešķiram to lietotājam.
Kešatmiņas slāņa CPU šeit izrādās daudz lētāks nekā tad, ja mēs pastāvīgi atjaunotu šos izmērus katrā krātuvē. Pieņemsim, ka mēs vēlamies pievienot jaunu, tas prasīs mēnesi — visur palaidiet skriptu, kas to visu darītu kārtīgi, neiznīcinot klasteri. Tie. Ja jums ir iespēja izvēlēties tagad, labāk ir izgatavot pēc iespējas mazāk fizisko izmēru, bet tā, lai vismaz kāds sadalījums būtu, teiksim, trīs. Un visu pārējo var vienkārši mainīt lidojuma laikā, izmantojot gatavus moduļus. Tagad tas viss ir ļoti vienkārši un pieejams.
Un inkrementāla asinhronā dublēšana ir laba.
Kā liecina mūsu prakse, šī shēma lieliski darbojas ar aizkavētu mainīto failu kopēšanu.
Pēdējais punkts arī ir acīmredzams. Ja jūsu infrastruktūrai tagad nav šādu problēmu, bet ir kaut kas, kas var salūzt, tas noteikti salūzīs, kad to kļūs nedaudz vairāk. Tāpēc labāk par to padomāt iepriekš un nepiedzīvot problēmas ar to. Tas ir viss, ko es gribēju pateikt.
Kontakti
»
»
Šis ziņojums ir vienas no labākajām runām augstas slodzes sistēmu izstrādātāju konferencē . Līdz HighLoad++ 2017 konferencei atlicis mazāk nekā mēnesis.
Mums tas jau ir gatavs , grafiks šobrīd tiek aktīvi veidots.
Šogad mēs turpinām izpētīt arhitektūras un mērogošanas tēmu:
- / Igors Vasiļjevs
- / Dmitrijs Jegorovs
- / Anatolijs Plaskovskis
- / Romāns Šehovcovs, Aleksejs Gromačikovs
- / Filips Delgado
Mēs arī izmantojam dažus no šiem materiāliem mūsu tiešsaistes apmācību kursā par augstas slodzes sistēmu izstrādi ir īpaši atlasītu vēstuļu, rakstu, materiālu, video virkne. Mūsu mācību grāmatā jau ir vairāk nekā 30 unikālu materiālu. Pievienojieties!
Avots: www.habr.com