Artem Denisov ( , )
Ang Badoo ay ang pinakamalaking dating site sa mundo. Sa kasalukuyan, mayroon kaming humigit-kumulang 330 milyong rehistradong gumagamit sa buong mundo. Ngunit ang mas mahalaga sa konteksto ng aming pag-uusap ngayon ay ang pag-imbak namin ng humigit-kumulang 3 petabytes ng mga larawan ng user. Araw-araw ang aming mga user ay nag-a-upload ng humigit-kumulang 3,5 milyong mga bagong larawan, at ang pag-load ng pagbabasa ay tungkol sa 80 libong mga kahilingan bawat segundo. Ito ay medyo marami para sa aming backend, at kung minsan ay may mga paghihirap dito.
Pag-uusapan ko ang tungkol sa disenyo ng system na ito, na nag-iimbak at nagpapadala ng mga larawan sa kabuuan, at titingnan ito mula sa punto ng view ng developer. Magkakaroon ng maikling retrospective sa kung paano ito nabuo, kung saan ilalarawan ko ang mga pangunahing milestone, ngunit tatalakayin ko lang nang mas detalyado ang tungkol sa mga solusyon na kasalukuyang ginagamit namin.
Ngayon magsimula tayo.
Tulad ng sinabi ko, ito ay magiging isang retrospective, at upang simulan ito sa isang lugar, gawin natin ang pinakakaraniwang halimbawa.
Mayroon kaming isang karaniwang gawain, kailangan naming tanggapin, iimbak at ipadala ang mga larawan ng gumagamit. Sa form na ito, ang gawain ay pangkalahatan, maaari naming gamitin ang anuman:
- modernong cloud storage,
- isang boxed solution, kung saan marami na rin ngayon;
- Maaari kaming mag-set up ng ilang machine sa aming data center at maglagay ng malalaking hard drive sa mga ito at mag-imbak ng mga larawan doon.
Ang Badoo sa kasaysayan - parehong ngayon at noon (sa panahong ito ay nasa pagkabata pa lamang) - ay nakatira sa sarili nitong mga server, sa loob ng sarili nating mga DC. Samakatuwid, ang pagpipiliang ito ay pinakamainam para sa amin.
Kumuha lang kami ng ilang machine, tinawag silang "mga larawan", at nakakuha kami ng cluster na nag-iimbak ng mga larawan. Pero parang may kulang. Upang gumana ang lahat ng ito, kailangan nating matukoy kung aling makina ang iimbak natin kung aling mga larawan. At dito rin, hindi na kailangang buksan ang America.
Nagdaragdag kami ng ilang field sa aming storage na may impormasyon tungkol sa mga user. Ito ang magiging susi ng sharding. Sa aming kaso, tinawag namin itong place_id, at ang place id na ito ay tumuturo sa lugar kung saan iniimbak ang mga larawan ng user. Gumagawa kami ng mga mapa.
Sa unang yugto, maaari pa itong gawin nang manu-mano - sinasabi namin na ang isang larawan ng user na ito na may ganoong lugar ay mapupunta sa naturang server. Salamat sa mapa na ito, lagi naming alam kapag nag-upload ng larawan ang isang user, kung saan ito ise-save, at alam namin kung saan ito ibibigay.
Ito ay isang ganap na maliit na pamamaraan, ngunit ito ay may lubos na makabuluhang mga pakinabang. Ang una ay ito ay simple, tulad ng sinabi ko, at ang pangalawa ay na sa diskarteng ito ay madali nating mai-scale nang pahalang sa pamamagitan lamang ng paghahatid ng mga bagong kotse at pagdaragdag ng mga ito sa mapa. Hindi mo na kailangang gumawa ng anumang bagay.
Ganyan kami sa ilang panahon.
Ito ay mga 2009. Naghatid sila ng mga sasakyan, naghatid...
At sa ilang mga punto sinimulan naming mapansin na ang pamamaraan na ito ay may ilang mga kawalan. Ano ang mga disadvantages?
Una sa lahat, may limitadong kapasidad. Hindi kami makakapagsiksik ng maraming hard drive sa isang pisikal na server hangga't gusto namin. At ito ay naging isang tiyak na problema sa paglipas ng panahon at sa paglaki ng dataset.
At pangalawa. Ito ay isang hindi tipikal na pagsasaayos ng mga makina, dahil ang mga naturang makina ay mahirap gamitin muli sa ilang iba pang mga kumpol; ang mga ito ay medyo tiyak, i.e. dapat silang mahina sa pagganap, ngunit sa parehong oras na may malaking hard drive.
Ito ay lahat para sa 2009, ngunit, sa prinsipyo, ang mga kinakailangang ito ay may kaugnayan pa rin ngayon. Mayroon kaming retrospective, kaya noong 2009 lahat ay ganap na masama dito.
At ang huling punto ay ang presyo.
Napakataas ng presyo noong panahong iyon, at kailangan naming maghanap ng ilang alternatibo. Yung. kailangan naming kahit papaano ay mas mahusay na magamit ang parehong espasyo sa mga data center at ang mga pisikal na server kung saan matatagpuan ang lahat ng ito. At sinimulan ng aming mga system engineer ang isang malaking pag-aaral kung saan sinuri nila ang isang grupo ng iba't ibang mga opsyon. Tiningnan din nila ang mga clustered file system tulad ng PolyCeph at Lustre. Nagkaroon ng mga problema sa pagganap at medyo mahirap na operasyon. Tumanggi sila. Sinubukan naming i-mount ang buong dataset sa pamamagitan ng NFS sa bawat kotse upang kahit papaano ay mapalaki ito. Mahina rin ang pagbabasa, sinubukan namin ang iba't ibang solusyon mula sa iba't ibang vendor.
At sa huli, nagkasundo kami sa paggamit ng tinatawag na Storage Area Network.
Ang mga ito ay malalaking SHD na partikular na idinisenyo para sa pag-imbak ng malalaking halaga ng data. Ang mga ito ay mga istante na may mga disk na naka-mount sa panghuling optical output machine. yun. mayroon kaming ilang uri ng pool ng mga makina, medyo maliit, at ang mga SHD na ito, na malinaw sa aming lohika sa pagpapadala, i.e. para sa aming nginx o sinumang iba pa upang maghatid ng mga kahilingan para sa mga larawang ito.
Ang desisyong ito ay may malinaw na mga pakinabang. Ito ay SHD. Ito ay naglalayong mag-imbak ng mga larawan. Ito ay gumagana nang mas mura kaysa sa simpleng pagbibigay ng mga makina na may mga hard drive.
Pangalawang plus.
Ito ay ang kapasidad ay naging mas malaki, i.e. maaari kaming tumanggap ng mas maraming storage sa mas maliit na volume.
Ngunit mayroon ding mga disadvantages na lumitaw nang medyo mabilis. Habang dumarami ang bilang ng mga user at load sa system na ito, nagsimulang lumitaw ang mga problema sa performance. At ang problema dito ay medyo halata - anumang SHD na idinisenyo upang mag-imbak ng maraming mga larawan sa isang maliit na dami, bilang isang panuntunan, ay naghihirap mula sa masinsinang pagbabasa. Totoo ito para sa anumang cloud storage o anumang bagay. Ngayon, wala kaming perpektong storage na walang katapusan na nasusukat, maaari mong ilagay ang anumang bagay dito, at matitiis nito ang mga pagbabasa. Lalo na ang mga kaswal na pagbabasa.
Tulad ng kaso sa aming mga larawan, dahil ang mga larawan ay hinihiling nang hindi pare-pareho, at ito ay lubos na makakaapekto sa kanilang pagganap.
Kahit na ayon sa mga numero ngayon, kung makakakuha tayo ng higit sa 500 RPS para sa mga larawan sa isang makina kung saan nakakonekta ang storage, nagsisimula na ang mga problema. At ito ay sapat na masama para sa amin, dahil ang bilang ng mga gumagamit ay lumalaki, ang mga bagay ay lalala lamang. Kailangang ma-optimize ito kahit papaano.
Upang mag-optimize, nagpasya kami sa oras na iyon, malinaw naman, upang tingnan ang profile ng pag-load - kung ano, sa pangkalahatan, ang nangyayari, kung ano ang kailangang i-optimize.
At dito naglalaro ang lahat sa ating mga kamay.
Nasabi ko na sa unang slide: mayroon tayong 80 thousand reading requests per second na may 3,5 million uploads lang kada araw. Iyon ay, ito ay isang pagkakaiba ng tatlong mga order ng magnitude. Malinaw na ang pagbabasa ay kailangang i-optimize at ito ay halos malinaw kung paano.
May isa pang maliit na punto. Ang mga detalye ng serbisyo ay tulad na ang isang tao ay nagrerehistro, nag-upload ng isang larawan, pagkatapos ay nagsimulang aktibong tumingin sa ibang mga tao, tulad nila, at aktibong ipinapakita sa ibang mga tao. Pagkatapos ay nakahanap siya ng kapareha o hindi nakakahanap ng kapareha, depende ito kung paano ito lumalabas, at huminto sa paggamit ng serbisyo nang ilang sandali. Sa sandaling ito, kapag ginamit niya ito, ang kanyang mga larawan ay napakainit - ang mga ito ay in demand, maraming tao ang tumitingin sa kanila. Sa sandaling huminto siya sa paggawa nito, mabilis siyang nawala sa mas maraming pagkakalantad sa ibang tao gaya ng dati, at halos hindi na hinihiling ang kanyang mga larawan.
Yung. Mayroon kaming napakaliit na mainit na dataset. Pero at the same time maraming nagre-request sa kanya. At isang ganap na halatang solusyon dito ay ang magdagdag ng cache.
Ang isang cache na may LRU ay malulutas ang lahat ng aming mga problema. Anong gagawin natin?
Nagdaragdag kami ng isa pang medyo maliit sa harap ng aming malaking kumpol na may imbakan, na tinatawag na mga photocache. Ito ay mahalagang isang caching proxy lamang.
Paano ito gumagana mula sa loob? Narito ang aming gumagamit, narito ang imbakan. Ang lahat ay katulad ng dati. Ano ang idaragdag natin sa pagitan?
Ito ay isang makina lamang na may pisikal na lokal na disk, na mabilis. Ito ay may SSD, halimbawa. At ang ilang uri ng lokal na cache ay nakaimbak sa disk na ito.
Anong itsura? Nagpapadala ang user ng kahilingan para sa isang larawan. Hinahanap muna ito ng NGINX sa lokal na cache. Kung hindi, proxy_pass lang sa aming storage, i-download ang larawan mula doon at ibigay ito sa user.
Ngunit ang isang ito ay napaka-banal at ito ay hindi malinaw kung ano ang nangyayari sa loob. Ito ay gumagana ng isang bagay tulad nito.
Ang cache ay lohikal na nahahati sa tatlong mga layer. Kapag sinabi kong "tatlong layer", hindi ito nangangahulugan na mayroong ilang uri ng kumplikadong sistema. Hindi, ito ay may kondisyong tatlong direktoryo lamang sa file system:
- Isa itong buffer kung saan kaka-download lang ng mga larawan mula sa isang proxy.
- Ito ay isang mainit na cache na nag-iimbak ng kasalukuyang aktibong hiniling na mga larawan.
- At isang malamig na cache, kung saan ang mga larawan ay unti-unting itinutulak palabas ng mainit na cache kapag mas kaunting mga kahilingan ang dumating sa kanila.
Para gumana ito, kailangan nating pamahalaan sa anumang paraan ang cache na ito, kailangan nating muling ayusin ang mga larawan sa loob nito, atbp. Ito rin ay isang napaka-primitive na proseso.
Sumulat lamang ang Nginx sa RAMDisk access.log para sa bawat kahilingan, kung saan ipinapahiwatig nito ang landas sa larawan na kasalukuyang inihahatid nito (siyempre, kamag-anak na landas), at kung aling partition ang inihatid. Yung. maaaring sabihin ang "larawan 1" at pagkatapos ay alinman sa isang buffer, o isang mainit na cache, o isang malamig na cache, o isang proxy.
Depende dito, kailangan nating magpasya kung ano ang gagawin sa larawan.
Mayroon kaming maliit na daemon na tumatakbo sa bawat makina na patuloy na nagbabasa ng log na ito at nag-iimbak ng mga istatistika sa paggamit ng ilang mga larawan sa memorya nito.
Nangongolekta lang siya doon, pinapanatili ang mga counter at pana-panahong ginagawa ang mga sumusunod. Inilipat niya ang aktibong hiniling na mga larawan, kung saan maraming mga kahilingan, sa mainit na cache, nasaan man sila.
Ang mga larawang bihirang hinihiling at hindi gaanong hiniling ay unti-unting itinutulak palabas ng mainit na cache patungo sa malamig.
At kapag naubusan kami ng espasyo sa cache, sinisimulan lang naming tanggalin ang lahat mula sa malamig na cache nang walang pinipili. At sa pamamagitan ng paraan, ito ay gumagana nang maayos.
Upang ang larawan ay ma-save kaagad kapag ini-proxy ito sa buffer, ginagamit namin ang proxy_store na direktiba at ang buffer ay isang RAMDisk din, i.e. para sa gumagamit ito ay gumagana nang napakabilis. Ito ay may kinalaman sa mga internal ng caching server mismo.
Ang natitirang tanong ay kung paano ipamahagi ang mga kahilingan sa mga server na ito.
Sabihin nating mayroong isang kumpol ng dalawampung storage machine at tatlong caching server (ganito ang nangyari).
Kailangan nating matukoy kung aling mga kahilingan ang para sa kung aling mga larawan at kung saan ilalagay ang mga ito.
Ang pinakakaraniwang opsyon ay Round Robin. O gawin ito nang hindi sinasadya?
Ito ay malinaw na may ilang mga disadvantages dahil gagamitin namin ang cache nang hindi epektibo sa ganoong sitwasyon. Darating ang mga kahilingan sa ilang random na makina: dito ito na-cache, ngunit sa susunod ay wala na ito. At kung ang lahat ng ito ay gagana, ito ay magiging napakasama. Kahit na may maliit na bilang ng mga makina sa kumpol.
Kailangan nating matukoy nang malinaw kung aling server ang hiling.
Mayroong isang banal na paraan. Kinukuha namin ang hash mula sa URL o ang hash mula sa aming sharding key, na nasa URL, at hinahati namin ito sa bilang ng mga server. Magtatrabaho? Will.
Yung. Mayroon kaming 2% na kahilingan, halimbawa, para sa ilang "example_url" palagi itong mapupunta sa server na may index na "XNUMX", at ang cache ay patuloy na itatapon hangga't maaari.
Ngunit may problema sa resharding sa gayong pamamaraan. Resharding - Ang ibig kong sabihin ay pagpapalit ng bilang ng mga server.
Ipagpalagay natin na ang aming caching cluster ay hindi na makayanan at nagpasya kaming magdagdag ng isa pang makina.
Dagdagan natin.
Ngayon ang lahat ay nahahati hindi sa tatlo, ngunit sa apat. Kaya, halos lahat ng mga susi na mayroon kami noon, halos lahat ng mga URL ay nakatira na ngayon sa iba pang mga server. Ang buong cache ay nawalan ng bisa sa isang sandali. Ang lahat ng mga kahilingan ay nahulog sa aming storage cluster, ito ay naging masama, serbisyo ay nabigo at hindi nasisiyahan sa mga user. Ayokong gawin yun.
Ang pagpipiliang ito ay hindi rin angkop sa amin.
yun. ano ang dapat nating gawin? Dapat kahit papaano ay gumawa tayo ng mahusay na paggamit ng cache, ilagay ang parehong kahilingan sa parehong server nang paulit-ulit, ngunit maging lumalaban sa resharding. At may ganoong solusyon, hindi ganoon kakomplikado. Ito ay tinatawag na pare-parehong pag-hash.
Ano ang hitsura nito?
Kumuha kami ng ilang function mula sa sharding key at ikinakalat ang lahat ng mga halaga nito sa bilog. Yung. sa punto 0, ang pinakamababa at pinakamataas na halaga nito ay nagtatagpo. Susunod, inilalagay namin ang lahat ng aming mga server sa parehong bilog sa humigit-kumulang sa ganitong paraan:
Ang bawat server ay tinukoy ng isang punto, at ang sektor na napupunta sa clockwise dito, nang naaayon, ay inihahatid ng host na ito. Kapag ang mga kahilingan ay dumating sa amin, agad naming makikita na, halimbawa, humiling ng A - mayroon itong hash doon - at ito ay inihahatid ng server 2. Kahilingan B - ng server 3. At iba pa.
Ano ang nangyayari sa sitwasyong ito sa panahon ng resharding?
Hindi namin pinawalang-bisa ang buong cache, tulad ng dati, at hindi inililipat ang lahat ng mga susi, ngunit inililipat namin ang bawat sektor sa isang maikling distansya upang, medyo nagsasalita, ang aming ikaanim na server, na nais naming idagdag, ay umaangkop sa libreng espasyo, at idagdag namin ito doon.
Siyempre, sa ganoong sitwasyon ang mga susi ay gumagalaw din. Ngunit lumayo sila nang mas mahina kaysa dati. At nakita namin na ang aming unang dalawang key ay nanatili sa kanilang mga server, at ang caching server para lamang sa huling key ay nagbago. Ito ay gumagana nang mahusay, at kung magdagdag ka ng mga bagong host nang paunti-unti, walang malaking problema dito. Magdadagdag at magdagdag ka ng paunti-unti, maghintay hanggang mapuno muli ang cache, at gumana nang maayos ang lahat.
Ang tanging tanong ay nananatili sa mga pagtanggi. Ipagpalagay natin na ang ilang uri ng sasakyan ay wala sa ayos.
At hindi talaga namin nais na muling buuin ang mapa na ito sa sandaling ito, i-invalidate ang bahagi ng cache, at iba pa, kung, halimbawa, ang makina ay na-reboot, at kailangan naming kahit papaano ang mga kahilingan sa serbisyo. Nag-iingat lang kami ng isang backup na cache ng larawan sa bawat site, na nagsisilbing kapalit ng anumang makina na kasalukuyang naka-down. At kung biglang naging hindi available ang isa sa aming mga server, pupunta doon ang trapiko. Naturally, wala kaming anumang cache doon, i.e. malamig, ngunit hindi bababa sa mga kahilingan ng gumagamit ay pinoproseso. Kung ito ay isang maikling agwat, pagkatapos ay nararanasan namin ito ng ganap na mahinahon. Mas marami lang ang load sa storage. Kung mahaba ang agwat na ito, maaari na tayong gumawa ng desisyon - tanggalin ang server na ito sa mapa o hindi, o marahil ay palitan ito ng isa pa.
Ito ay tungkol sa caching system. Tingnan natin ang mga resulta.
Mukhang walang kumplikado dito. Ngunit ang pamamaraang ito ng pamamahala ng cache ay nagbigay sa amin ng trick rate na humigit-kumulang 98%. Yung. sa 80 libong mga kahilingan sa bawat segundo na ito, 1600 lamang ang nakakaabot sa imbakan, at ito ay isang ganap na normal na pagkarga, mahinahon nilang tinitiis ito, palagi kaming may reserba.
Inilagay namin ang mga server na ito sa tatlo sa aming mga DC, at nakatanggap ng tatlong punto ng presensya - Prague, Miami at Hong Kong.
yun. ang mga ito ay higit pa o mas kaunting lokal na matatagpuan sa bawat isa sa aming mga target na merkado.
At bilang isang magandang bonus, nakuha namin ang caching proxy na ito, kung saan ang CPU ay talagang idle, dahil hindi ito kinakailangan upang maghatid ng nilalaman. At doon, gamit ang NGINX+ Lua, nagpatupad kami ng maraming utilitarian logic.
Halimbawa, maaari tayong mag-eksperimento sa webp o progresibong jpeg (ito ang mga epektibong modernong format), tingnan kung paano ito nakakaapekto sa trapiko, gumawa ng ilang desisyon, paganahin ito para sa ilang partikular na bansa, atbp.; gumawa ng dynamic na pagbabago ng laki o i-crop ang mga larawan sa mabilisang.
Ito ay isang magandang usecase kapag, halimbawa, mayroon kang isang mobile application na nagpapakita ng mga larawan, at ang mobile application ay hindi nais na sayangin ang CPU ng kliyente sa paghiling ng isang malaking larawan at pagkatapos ay baguhin ang laki nito sa isang tiyak na laki upang itulak ito sa ang view. Maaari naming dynamic na tukuyin ang ilang mga parameter sa kondisyong URL ng UPort, at babaguhin ng cache ng larawan ang larawan mismo. Bilang isang patakaran, pipiliin nito ang laki na pisikal na mayroon tayo sa disk, na mas malapit hangga't maaari sa hiniling, at i-downsell ito sa mga partikular na coordinate.
Sa pamamagitan ng paraan, gumawa kami ng mga pampublikong pag-record ng video sa huling limang taon ng kumperensya ng mga developer ng mga high-load system . Manood, matuto, magbahagi at mag-subscribe sa .
Maaari din tayong magdagdag ng maraming lohika ng produkto doon. Halimbawa, maaari kaming magdagdag ng iba't ibang mga watermark gamit ang mga parameter ng URL, maaari naming i-blur, i-blur o i-pixelate ang mga larawan. Ito ay kapag gusto naming ipakita ang isang larawan ng isang tao, ngunit hindi namin nais na ipakita ang kanyang mukha, ito ay gumagana nang maayos, lahat ito ay ipinatupad dito.
Ano ang nakuha namin? Nakakuha kami ng tatlong punto ng presensya, isang mahusay na rate ng trick, at sa parehong oras ay wala kaming idle na CPU sa mga makinang ito. Siya ngayon ay naging, siyempre, mas mahalaga kaysa dati. Kailangan nating bigyan ang ating sarili ng mas malakas na mga kotse, ngunit sulit ito.
Ito ay may kinalaman sa pagbabalik ng mga litrato. Ang lahat dito ay medyo malinaw at halata. Sa palagay ko ay hindi ko natuklasan ang Amerika, halos anumang CDN ay gumagana sa ganitong paraan.
At, malamang, maaaring may tanong ang isang sopistikadong tagapakinig: bakit hindi na lang baguhin ang lahat sa CDN? Ito ay halos pareho; lahat ng modernong CDN ay maaaring gawin ito. At may ilang mga dahilan.
Ang una ay mga litrato.
Ito ay isa sa mga pangunahing punto ng aming imprastraktura, at kailangan namin ng mas maraming kontrol dito hangga't maaari. Kung ito ay isang uri ng solusyon mula sa isang third-party na vendor, at wala kang anumang kapangyarihan dito, magiging mahirap para sa iyo na mamuhay dito kapag mayroon kang malaking dataset, at kapag mayroon kang napakalaking daloy. ng mga kahilingan ng gumagamit.
Bigyan kita ng isang halimbawa. Ngayon, sa aming imprastraktura, maaari naming, halimbawa, sa kaso ng ilang mga problema o mga katok sa ilalim ng lupa, pumunta sa makina at magkagulo doon, medyo nagsasalita. Maaari naming idagdag ang koleksyon ng ilang mga sukatan na kailangan lang namin, maaari kaming mag-eksperimento kahit papaano, tingnan kung paano ito nakakaapekto sa mga graph, at iba pa. Ngayon maraming mga istatistika ang nakolekta sa caching cluster na ito. At pana-panahon nating tinitingnan ito at gumugugol ng mahabang panahon sa pagtuklas ng ilang mga anomalya. Kung ito ay nasa panig ng CDN, magiging mas mahirap kontrolin. O, halimbawa, kung may nangyaring aksidente, alam natin kung ano ang nangyari, alam natin kung paano mamuhay kasama nito at kung paano ito malalampasan. Ito ang unang konklusyon.
Ang pangalawang konklusyon ay medyo makasaysayan din, dahil ang sistema ay umuunlad sa mahabang panahon, at mayroong maraming iba't ibang mga kinakailangan sa negosyo sa iba't ibang yugto, at hindi sila palaging magkasya sa konsepto ng CDN.
At ang punto na sumusunod mula sa nauna ay
Ito ay dahil sa mga cache ng larawan mayroon kaming maraming partikular na lohika, na hindi palaging maidaragdag kapag hiniling. Malamang na ang anumang CDN ay magdagdag ng ilang mga custom na bagay sa iyo sa iyong kahilingan. Halimbawa, ang pag-encrypt ng mga URL kung ayaw mong mabago ng kliyente ang isang bagay. Gusto mo bang baguhin ang URL sa server at i-encrypt ito, at pagkatapos ay magpadala ng ilang mga dynamic na parameter dito.
Anong konklusyon ang iminumungkahi nito? Sa aming kaso, ang CDN ay hindi isang napakagandang alternatibo.
At sa iyong kaso, kung mayroon kang anumang partikular na pangangailangan sa negosyo, madali mong maipatupad ang ipinakita ko sa iyo mismo. At ito ay ganap na gagana sa isang katulad na profile ng pag-load.
Ngunit kung mayroon kang ilang uri ng pangkalahatang solusyon, at ang gawain ay hindi masyadong tiyak, maaari mong ganap na ligtas na kumuha ng CDN. O kung ang oras at mga mapagkukunan ay mas mahalaga sa iyo kaysa sa kontrol.
At ang mga modernong CDN ay may halos lahat ng sinabi ko sa iyo ngayon. Maliban sa plus o minus ilang mga tampok.
Ito ay tungkol sa pagbibigay ng mga larawan.
Sumulong tayo ngayon nang kaunti sa ating retrospective at pag-usapan ang tungkol sa storage.
Lumipas ang 2013.
Naidagdag ang mga server ng pag-cache, nawala ang mga problema sa pagganap. Maayos ang lahat. Ang dataset ay lumalaki. Noong 2013, mayroon kaming humigit-kumulang 80 server na nakakonekta sa storage, at humigit-kumulang 40 na naka-cache sa bawat DC. Ito ay 560 terabytes ng data sa bawat DC, i.e. tungkol sa isang petabyte sa kabuuan.
At sa paglaki ng dataset, nagsimulang tumaas nang malaki ang mga gastos sa pagpapatakbo. Ano ang ibig sabihin nito?
Sa diagram na ito na iginuhit - na may isang SAN, na may mga makina at mga cache na konektado dito - mayroong maraming mga punto ng pagkabigo. Kung napag-usapan na namin ang kabiguan ng mga server ng pag-cache dati, ang lahat ay higit pa o hindi gaanong nahuhulaan at nauunawaan, ngunit sa bahagi ng imbakan ang lahat ay mas masahol pa.
Una, mayroong Storage Area Network (SAN) mismo, na maaaring mabigo.
Pangalawa, ito ay konektado sa pamamagitan ng optika sa mga end machine. Maaaring may mga problema sa mga optical card at spark plugs.
Siyempre, hindi kasing dami ng mga ito gaya ng sa SAN mismo, ngunit, gayunpaman, ito rin ay mga punto ng kabiguan.
Susunod ay ang makina mismo, na konektado sa imbakan. Maaari rin itong mabigo.
Sa kabuuan, mayroon tayong tatlong punto ng kabiguan.
Dagdag pa, bilang karagdagan sa mga punto ng pagkabigo, mayroong mabigat na pagpapanatili ng imbakan mismo.
Ito ay isang kumplikadong multi-component system, at ang mga system engineer ay maaaring mahirapang magtrabaho dito.
At ang huli, pinakamahalagang punto. Kung may maganap na pagkabigo sa alinman sa tatlong puntong ito, mayroon kaming hindi zero na pagkakataong mawala ang data ng user dahil maaaring mag-crash ang file system.
Sabihin nating sira ang aming file system. Una, ang pagbawi nito ay tumatagal ng mahabang panahon - maaari itong tumagal ng isang linggo na may malaking halaga ng data. At pangalawa, sa huli ay malamang na magtatapos tayo sa isang bungkos ng mga hindi maintindihan na mga file na kailangang isama sa mga larawan ng user. At nanganganib kaming mawalan ng data. Ang panganib ay medyo mataas. At kung mas madalas ang mga ganitong sitwasyon ay nangyayari, at mas maraming problema ang lumitaw sa buong chain na ito, mas mataas ang panganib na ito.
May kailangang gawin tungkol dito. At napagpasyahan namin na kailangan lang naming i-backup ang data. Ito ay talagang isang malinaw na solusyon at isang mahusay. Ano'ng nagawa natin?
Ito ang hitsura ng aming server noong nakakonekta ito sa storage dati. Ito ay isang pangunahing seksyon, isa lamang itong block device na aktwal na kumakatawan sa isang mount para sa malayuang imbakan sa pamamagitan ng optika.
Nagdagdag lang kami ng pangalawang seksyon.
Naglagay kami ng pangalawang storage sa tabi nito (sa kabutihang palad, hindi ito ganoon kamahal sa mga tuntunin ng pera), at tinawag itong backup na partition. Ito ay konektado din sa pamamagitan ng optika at matatagpuan sa parehong makina. Ngunit kailangan nating i-synchronize ang data sa pagitan nila.
Dito lang kami gumagawa ng asynchronous na pila sa malapit.
Hindi siya masyadong busy. Alam namin na wala kaming sapat na mga rekord. Ang queue ay isang talahanayan lamang sa MySQL kung saan nakasulat ang mga linya tulad ng "kailangan mong i-back up ang larawang ito". Sa anumang pagbabago o pag-upload, kinokopya namin mula sa pangunahing partition patungo sa backup gamit ang isang asynchronous o ilang uri lang ng background worker.
At kaya palagi kaming may dalawang pare-parehong seksyon. Kahit na nabigo ang isang bahagi ng system na ito, maaari naming palaging baguhin ang pangunahing partition gamit ang isang backup, at ang lahat ay patuloy na gagana.
Ngunit dahil dito, tumataas nang husto ang reading load, dahil... bilang karagdagan sa mga kliyente na nagbabasa mula sa pangunahing seksyon, dahil tinitingnan muna nila ang larawan doon (mas bago doon), at pagkatapos ay hanapin ito sa backup, kung hindi nila ito natagpuan (pero ginagawa lang ito ng NGINX), ang aming system ay isa ring plus backup na ngayon ay nagbabasa mula sa pangunahing partition. Ito ay hindi na ito ay isang bottleneck, ngunit hindi ko nais na dagdagan ang load, mahalagang, tulad na lamang.
At nagdagdag kami ng ikatlong disk, na isang maliit na SSD, at tinawag itong buffer.
Paano ito gumagana ngayon.
Ang user ay nag-a-upload ng larawan sa buffer, pagkatapos ay isang kaganapan ang itinapon sa queue na nagpapahiwatig na kailangan itong kopyahin sa dalawang seksyon. Ito ay kinopya, at ang larawan ay naninirahan sa buffer nang ilang oras (sabihin, isang araw), at pagkatapos lamang ay na-purged mula doon. Ito ay lubos na nagpapabuti sa karanasan ng gumagamit, dahil ang gumagamit ay nag-upload ng isang larawan, bilang isang panuntunan, ang mga kahilingan ay agad na nagsisimulang sundin, o siya mismo ang nag-update ng pahina at nag-refresh nito. Ngunit ang lahat ay nakasalalay sa application na gumagawa ng pag-upload.
O, halimbawa, ang ibang mga tao kung saan nagsimula siyang magpakita ng kanyang sarili ay agad na nagpadala ng mga kahilingan pagkatapos ng larawang ito. Wala pa ito sa cache; ang unang kahilingan ay nangyayari nang napakabilis. Talagang kapareho ng mula sa isang cache ng larawan. Ang mabagal na pag-iimbak ay hindi kasangkot dito. At kapag napurga na ang isang araw, naka-cache na ito sa aming layer ng caching, o, malamang, wala nang nangangailangan nito. Yung. Ang karanasan ng gumagamit dito ay lumago nang husto dahil sa mga simpleng manipulasyon.
Well, at ang pinakamahalaga: tumigil kami sa pagkawala ng data.
Sabihin na nating huminto tayo potensyal mawalan ng data, dahil hindi talaga namin ito nawala. Ngunit may panganib. Nakikita namin na ang solusyon na ito ay, siyempre, mabuti, ngunit ito ay isang maliit na tulad ng pagpapakinis ng mga sintomas ng problema, sa halip na lubusang lutasin ito. At ang ilang mga problema ay nananatili dito.
Una, ito ay isang punto ng pagkabigo sa anyo ng mismong pisikal na host kung saan tumatakbo ang lahat ng makinarya na ito; hindi ito nawala.
Pangalawa, may mga problema pa rin sa mga SAN, nananatili ang kanilang mabigat na maintenance, atbp. Ito ay hindi na ito ay isang kritikal na kadahilanan, ngunit nais kong subukan na kahit papaano ay mabuhay nang wala ito.
At ginawa namin ang ikatlong bersyon (sa katunayan, ang pangalawa sa katunayan) - ang bersyon ng reserbasyon. Ano ang hitsura nito?
Ito ay kung ano ito ay -
Ang aming mga pangunahing problema ay ang katotohanan na ito ay isang pisikal na host.
Una, inaalis namin ang mga SAN dahil gusto naming mag-eksperimento, gusto naming subukan ang mga lokal na hard drive lang.
Ito ay 2014-2015 na, at sa oras na iyon ang sitwasyon sa mga disk at ang kanilang kapasidad sa isang host ay naging mas mahusay. Nagpasya kami kung bakit hindi subukan ito.
At pagkatapos ay kunin lang namin ang aming backup na partition at pisikal na inilipat ito sa isang hiwalay na makina.
Kaya, nakukuha namin ang diagram na ito. Mayroon kaming dalawang kotse na nag-iimbak ng parehong mga dataset. Sila ay nagba-back up nang buo sa isa't isa at nagsi-synchronize ng data sa network sa pamamagitan ng isang asynchronous na pila sa parehong MySQL.
Kung bakit ito gumagana nang maayos ay dahil kakaunti ang mga rekord namin. Yung. kung ang pagsusulat ay maihahambing sa pagbabasa, marahil magkakaroon tayo ng ilang uri ng network overhead at mga problema. Mayroong maliit na pagsusulat, maraming pagbabasa - gumagana nang maayos ang pamamaraang ito, i.e. Bihira kaming kumopya ng mga larawan sa pagitan ng dalawang server na ito.
Paano ito gumagana, kung titingnan mo nang mas detalyado.
Mag-upload. Pinipili lang ng balancer ang mga random na host na may isang pares at mag-upload dito. Kasabay nito, natural siyang nagsasagawa ng mga pagsusuri sa kalusugan at tinitiyak na hindi mahuhulog ang sasakyan. Yung. nag-a-upload lang siya ng mga larawan sa isang live na server, at pagkatapos ay sa pamamagitan ng isang asynchronous na pila, lahat ito ay kinopya sa kanyang kapitbahay. Sa pag-upload, ang lahat ay napakasimple.
Ang gawain ay medyo mas mahirap.
Tinulungan kami ni Lua dito, dahil maaaring mahirap gumawa ng ganoong lohika sa vanilla NGINX. Humihiling muna kami sa unang server, tingnan kung nandoon ang larawan, dahil posibleng ma-upload ito, halimbawa, sa isang kapitbahay, ngunit hindi pa dumarating dito. Kung nandoon ang litrato, mabuti iyon. Agad naming ibinibigay ito sa kliyente at, posibleng, i-cache ito.
Kung wala ito, humihiling lang kami sa aming kapitbahay at garantisadong matatanggap mula doon.
yun. muli nating masasabi: maaaring may mga problema sa pagganap, dahil may mga pare-parehong round trip - na-upload ang larawan, wala dito, gumagawa kami ng dalawang kahilingan sa halip na isa, dapat itong gumana nang dahan-dahan.
Sa aming sitwasyon, hindi ito gumagana nang mabagal.
Kinokolekta namin ang isang grupo ng mga sukatan sa system na ito, at ang conditional smart rate ng naturang mekanismo ay humigit-kumulang 95%. Yung. Ang lag ng backup na ito ay maliit, at dahil dito halos garantisado kami, pagkatapos ma-upload ang larawan, kukunin namin ito sa unang pagkakataon at hindi na kailangang pumunta kahit saan nang dalawang beses.
Kaya ano pa ang mayroon tayo na talagang cool?
Dati, mayroon kaming pangunahing backup na partition, at nagbasa kami mula sa kanila nang sunud-sunod. Yung. Palagi kaming naghanap muna sa pangunahing, at pagkatapos ay sa backup. Ito ay isang galaw.
Ngayon ginagamit namin ang pagbabasa mula sa dalawang makina nang sabay-sabay. Namamahagi kami ng mga kahilingan gamit ang Round Robin. Sa isang maliit na porsyento ng mga kaso, gumawa kami ng dalawang kahilingan. Ngunit sa pangkalahatan, mayroon na kaming dalawang beses na mas maraming stock ng pagbabasa kaysa dati. At ang pagkarga ay lubhang nabawasan kapwa sa mga sending machine at direkta sa mga storage machine, na mayroon din kami noong panahong iyon.
Tungkol naman sa fault tolerance. Actually, ito ang pangunahing pinaglaban namin. Sa fault tolerance, naging maganda ang lahat dito.
Nasira ang isang sasakyan.
Walang problema! Maaaring hindi man lang magigising ang isang system engineer sa gabi, maghihintay siya hanggang umaga, walang masamang mangyayari.
Kung mabigo man ang makinang ito, wala sa ayos ang pila, wala ring problema, maiipon lang muna ang log sa buhay na makina, at pagkatapos ay idaragdag ito sa pila, at pagkatapos ay sa kotse na pumunta sa operasyon pagkatapos ng ilang oras.
Parehong bagay sa pagpapanatili. Pinapatay lang namin ang isa sa mga makina, manu-manong hinugot ito sa lahat ng pool, huminto ito sa pagtanggap ng trapiko, gumagawa kami ng ilang uri ng maintenance, nag-e-edit kami ng isang bagay, pagkatapos ay ibinalik namin ito sa serbisyo, at ang backup na ito ay mabilis na nakakakuha. Yung. bawat araw, ang downtime ng isang kotse ay umaabot sa loob ng ilang minuto. Ito ay talagang napakaliit. With fault tolerance, sabi ko ulit, cool ang lahat dito.
Anong mga konklusyon ang maaaring makuha mula sa redundancy scheme na ito?
Nagkaroon kami ng fault tolerance.
Madaling gamitin. Dahil ang mga makina ay may mga lokal na hard drive, ito ay mas maginhawa mula sa isang operational point of view para sa mga inhinyero na nagtatrabaho dito.
Nakatanggap kami ng double reading allowance.
Ito ay isang napakagandang bonus bilang karagdagan sa fault tolerance.
Ngunit mayroon ding mga problema. Ngayon ay mayroon kaming mas kumplikadong pag-unlad ng ilang mga tampok na nauugnay dito, dahil ang system ay naging 100% sa kalaunan ay pare-pareho.
Dapat nating, sabihin, sa ilang trabaho sa background, patuloy na isipin: "Anong server ang pinapatakbo natin ngayon?", "Mayroon ba talagang kasalukuyang larawan dito?" atbp. Ito, siyempre, ay nakabalot, at para sa programmer na nagsusulat ng lohika ng negosyo, ito ay malinaw. Ngunit, gayunpaman, lumitaw ang malaking kumplikadong layer na ito. Pero handa kaming tiisin ito kapalit ng mga goodies na natanggap namin mula dito.
At dito muli lumitaw ang ilang salungatan.
Sinabi ko sa simula na ang pag-iimbak ng lahat sa mga lokal na hard drive ay masama. At ngayon sinasabi ko na nagustuhan namin ito.
Oo, sa katunayan, sa paglipas ng panahon ang sitwasyon ay nagbago ng maraming, at ngayon ang diskarte na ito ay may maraming mga pakinabang. Una, nakakakuha kami ng mas simpleng operasyon.
Pangalawa, ito ay mas produktibo, dahil wala kaming mga awtomatikong controllers o koneksyon sa mga istante ng disk.
Mayroong isang malaking halaga ng makinarya doon, at ito ay ilan lamang sa mga disk na naka-assemble dito sa makina para sa isang pagsalakay.
Ngunit may mga dehado rin.
Ito ay humigit-kumulang 1,5 beses na mas mahal kaysa sa paggamit ng mga SAN kahit na sa mga presyo ngayon. Samakatuwid, nagpasya kaming hindi matapang na i-convert ang aming buong malaking kumpol sa mga kotse na may mga lokal na hard drive at nagpasyang mag-iwan ng hybrid na solusyon.
Kalahati ng aming mga makina ay gumagana sa mga hard drive (well, hindi kalahati - marahil 30 porsiyento). At ang natitira ay mga lumang kotse na dating may unang reservation scheme. Ni-remount lang namin ang mga ito, dahil hindi namin kailangan ng bagong data o anumang bagay, inilipat lang namin ang mga mount mula sa isang pisikal na host patungo sa dalawa.
At mayroon na kaming malaking stock ng pagbabasa, at pinalawak namin ito. Kung mas maaga ay nag-mount kami ng isang imbakan sa isang makina, ngayon ay nag-mount kami ng apat, halimbawa, sa isang pares. At ito ay gumagana nang maayos.
Kunin natin ang maikling buod ng ating mga nagawa, kung ano ang ating ipinaglaban, at kung tayo ay nagtagumpay.
Mga resulta ng
Mayroon kaming mga gumagamit - kasing dami ng 33 milyon.
Mayroon kaming tatlong punto ng presensya - Prague, Miami, Hong Kong.
Naglalaman ang mga ito ng layer ng caching, na binubuo ng mga kotse na may mabilis na mga lokal na disk (SSD), kung saan tumatakbo ang mga simpleng makinarya mula sa NGINX, ang access.log nito at mga Python daemon, na nagpoproseso ng lahat ng ito at namamahala sa cache.
Kung gusto mo, ikaw ay nasa iyong proyekto, kung ang mga larawan ay hindi kasing kritikal para sa iyo gaya ng para sa amin, o kung ang trade-off na kontrol laban sa bilis ng pag-unlad at mga gastos sa mapagkukunan ay nasa kabilang direksyon para sa iyo, maaari mo itong ligtas na palitan sa isang CDN, ang mga modernong CDN ay mahusay ang kanilang ginagawa.
Susunod ay ang storage layer, kung saan mayroon kaming mga kumpol ng mga pares ng machine na nagba-back up sa isa't isa, ang mga file ay asynchronous na kinokopya mula sa isa't isa sa tuwing nagbabago ang mga ito.
Bukod dito, gumagana ang ilan sa mga makinang ito sa mga lokal na hard drive.
Ang ilan sa mga makinang ito ay konektado sa mga SAN.
At, sa isang banda, ito ay mas maginhawang gamitin at medyo mas produktibo, sa kabilang banda, ito ay maginhawa sa mga tuntunin ng densidad ng pagkakalagay at presyo bawat gigabyte.
Ito ay isang maikling pangkalahatang-ideya ng arkitektura ng kung ano ang nakuha namin at kung paano nabuo ang lahat.
Ilang tips pa mula sa kapitan, napakasimple.
Una, kung bigla kang magpasya na kailangan mong pagbutihin ang lahat sa iyong imprastraktura ng larawan, sukatin muna, dahil marahil ay walang kailangang pahusayin.
Bigyan kita ng isang halimbawa. Mayroon kaming isang kumpol ng mga makina na nagpapadala ng mga larawan mula sa mga attachment sa mga chat, at ang scheme ay gumagana doon mula noong 2009, at walang sinuman ang naghihirap mula dito. Lahat ay maayos, lahat gusto ang lahat.
Upang sukatin, magsabit muna ng isang grupo ng mga sukatan, tingnan ang mga ito, at pagkatapos ay magpasya kung ano ang hindi ka nasisiyahan at kung ano ang kailangang pagbutihin. Upang sukatin ito, mayroon kaming isang cool na tool na tinatawag na Pinba.
Pinapayagan ka nitong mangolekta ng napakadetalyadong istatistika mula sa NGINX para sa bawat kahilingan at mga code ng pagtugon, at pamamahagi ng mga oras - kahit anong gusto mo. Mayroon itong mga binding sa lahat ng uri ng iba't ibang mga sistema ng analytics, at pagkatapos ay maaari mong tingnan ang lahat nang maganda.
Una naming sinukat ito, pagkatapos ay pinagbuti namin ito.
Dagdag pa. Ino-optimize namin ang pagbabasa gamit ang cache, pagsusulat gamit ang sharding, ngunit ito ay isang malinaw na punto.
Dagdag pa. Kung ngayon ka pa lang nagsisimulang buuin ang iyong system, mas mainam na gawin ang mga larawan bilang hindi nababagong mga file. Dahil agad kang nawalan ng isang buong klase ng mga problema sa invalidation ng cache, kung paano dapat mahanap ng logic ang tamang bersyon ng larawan, at iba pa.
Sabihin nating nag-upload ka ng isang daan, pagkatapos ay inikot ito, gawin itong isang pisikal na kakaibang file. Yung. hindi na kailangang mag-isip: ngayon ay magse-save ako ng kaunting espasyo, isulat ito sa parehong file, baguhin ang bersyon. Ito ay palaging hindi gumagana nang maayos at nagiging sanhi ng maraming pananakit ng ulo mamaya.
Susunod na punto. Tungkol sa resize on the fly.
Dati, kapag nag-upload ng larawan ang mga user, agad naming pinutol ang isang buong bungkos ng laki para sa lahat ng okasyon, para sa iba't ibang kliyente, at lahat sila ay nasa disk. Ngayon ay tinalikuran na namin ito.
Nag-iwan lamang kami ng tatlong pangunahing sukat: maliit, katamtaman at malaki. Ibinababa lang namin ang lahat ng iba pa mula sa laki na nasa likod ng hiniling sa amin sa Uport, ginagawa lang namin ang downscale at ibibigay ito sa user.
Ang CPU ng layer ng pag-cache dito ay lumalabas na mas mura kaysa sa kung patuloy nating binago ang mga laki na ito sa bawat imbakan. Sabihin nating gusto nating magdagdag ng bago, aabutin ito ng isang buwan - magpatakbo ng script sa lahat ng dako na gagawin ang lahat ng ito nang maayos, nang hindi sinisira ang cluster. Yung. Kung mayroon kang pagkakataon na pumili ngayon, mas mahusay na gumawa ng kaunting pisikal na sukat hangga't maaari, ngunit upang ang hindi bababa sa ilang pamamahagi ay, sabihin, tatlo. At lahat ng iba pa ay maaaring i-resize sa mabilisang gamit ang mga yari na module. Ang lahat ng ito ay napakadali at naa-access ngayon.
At ang incremental asynchronous backup ay mabuti.
Tulad ng ipinakita ng aming kasanayan, mahusay ang pamamaraang ito sa naantalang pagkopya ng mga binagong file.
Ang huling punto ay halata din. Kung ang iyong imprastraktura ay walang ganoong mga problema ngayon, ngunit mayroong isang bagay na maaaring masira, ito ay tiyak na masira kapag ito ay naging mas kaunti. Samakatuwid, mas mahusay na pag-isipan ito nang maaga at hindi makaranas ng mga problema dito. Yun lang ang gusto kong sabihin.
mga contact
Β»
Β»
Ang ulat na ito ay isang transcript ng isa sa mga pinakamahusay na talumpati sa kumperensya ng mga developer ng mga high-load system . Wala pang isang buwan ang natitira bago ang HighLoad++ 2017 conference.
Nakahanda na kami , ang iskedyul ay aktibong nabuo na ngayon.
Sa taong ito, patuloy naming ginalugad ang paksa ng mga arkitektura at pag-scale:
- / Igor Vasiliev
- / Dmitry Egorov
- / Anatoly Plaskovsky
- / Roman Shekhovtsov, Alexey Gromatchikov
- / Philip Delgado
Ginagamit din namin ang ilan sa mga materyal na ito sa aming online na kurso sa pagsasanay sa pagbuo ng mga high-load system ay isang hanay ng mga espesyal na napiling mga titik, artikulo, materyales, video. Ang aming aklat-aralin ay naglalaman na ng higit sa 30 natatanging materyales. Kumonekta!
Pinagmulan: www.habr.com