Artem Denisov ( , )
Badoo minangka situs kencan paling gedhe ing donya. Saiki kita duwe udakara 330 yuta pangguna pangguna ing saindenging jagad. Nanging sing luwih penting ing konteks obrolan kita saiki yaiku kita nyimpen sekitar 3 petabyte foto pangguna. Saben dina pangguna kita ngunggah udakara 3,5 yuta foto anyar, lan beban maca kira-kira 80 ewu panjalukan saben detik. Iki cukup akeh kanggo backend kita, lan kadhangkala ana kangelan karo iki.
Aku bakal ngomong babagan desain sistem iki, sing nyimpen lan ngirim foto ing umum, lan aku bakal ndeleng saka pangembang. Bakal ana retrospektif ringkes babagan cara ngembangake, ing ngendi aku bakal njelasake tonggak utama, nanging aku mung bakal ngomong kanthi luwih rinci babagan solusi sing saiki digunakake.
Saiki ayo miwiti.
Kaya sing dakkandhakake, iki bakal dadi retrospektif, lan kanggo miwiti ing endi wae, ayo njupuk conto sing paling umum.
Kita duwe tugas umum, kita kudu nampa, nyimpen lan ngirim foto pangguna. Ing wangun iki, tugas umum, kita bisa nggunakake apa wae:
- panyimpenan awan modern,
- solusi kothak, sing saiki uga akeh;
- Kita bisa nyiyapake sawetara mesin ing pusat data lan sijine hard drive gedhe lan nyimpen foto ing kana.
Badoo historis - saiki lan banjur (ing wektu nalika isih cilik) - manggon ing server dhewe, ing DC kita dhewe. Mulane, pilihan iki optimal kanggo kita.
Kita mung njupuk sawetara mesin, diarani "foto", lan entuk klompok sing nyimpen foto. Nanging misale jek ana sing ilang. Supaya kabeh iki bisa digunakake, kita kudu nemtokake apa mesin sing bakal disimpen foto. Lan ing kene uga ora perlu mbukak Amerika.
Kita nambah sawetara lapangan menyang panyimpenan kanthi informasi babagan pangguna. Iki bakal dadi kunci sharding. Ing kasus kita, kita diarani place_id, lan id panggonan iki nuduhake panggonan ing ngendi foto pangguna disimpen. Kita nggawe peta.
Ing tataran kapisan, iki bisa uga ditindakake kanthi manual - kita ujar manawa foto pangguna kanthi papan kasebut bakal mlebu ing server kasebut. Thanks kanggo peta iki, kita tansah ngerti nalika pangguna upload foto, ngendi kanggo nyimpen, lan kita ngerti ngendi kanggo menehi saka.
Iki minangka skema sing ora pati penting, nanging nduweni kaluwihan sing cukup signifikan. Sing pertama yaiku prasaja, kaya sing dakkandhakake, lan sing nomer loro yaiku kanthi pendekatan iki, kita bisa kanthi gampang skala horisontal kanthi ngirim mobil anyar lan ditambahake menyang peta. Sampeyan ora perlu nindakake apa-apa liyane.
Mangkono uga kanggo kita sawetara wektu.
Iki kira-kira taun 2009. Dheweke ngirim mobil, ngirim ...
Lan ing sawetara titik kita wiwit sok dong mirsani sing rencana iki duwe cacat tartamtu. Apa kekurangane?
Kaping pisanan, ana kapasitas winates. Kita ora bisa cram minangka akeh hard drive menyang siji server fisik kaya kita pengin. Lan iki wis dadi masalah tartamtu saka wektu lan karo wutah saka dataset.
Lan kapindho. Iki minangka konfigurasi mesin sing ora khas, amarga mesin kasebut angel digunakake maneh ing sawetara klompok liyane, cukup spesifik, yaiku. padha kudu banget ing kinerja, nanging ing wektu sing padha karo hard drive gedhe.
Iki kabeh kanggo 2009, nanging, ing asas, syarat iki isih relevan dina. Kita duwe retrospektif, mula ing taun 2009 kabeh pancen ala.
Lan titik pungkasan yaiku rega.
Rega banget tajem ing wektu iku, lan kita kudu goleki sawetara alternatif. Sing. kita kudu nggunakake spasi ing pusat data lan server fisik sing kabeh iki dumunung. Lan insinyur sistem kita miwiti sinau gedhe ing ngendi dheweke mriksa macem-macem pilihan. Dheweke uga ndeleng sistem file clustered kayata PolyCeph lan Lustre. Ana masalah kinerja lan operasi cukup angel. Dheweke ora gelem. Kita nyoba masang kabeh set data liwat NFS ing saben mobil supaya bisa nggedhekake. Maca uga ora apik, kita nyoba macem-macem solusi saka vendor sing beda.
Lan ing pungkasan, kita mutusake nggunakake sing disebut Storage Area Network.
Iki minangka SHD gedhe sing dirancang khusus kanggo nyimpen data sing akeh. Padha rak karo disk sing dipasang ing mesin output optik final. Iku. kita duwe sawetara jenis blumbang mesin, cukup cilik, lan SHDs iki, kang transparan kanggo logika ngirim kita, i.e. kanggo nginx kita utawa wong liya kanggo ngladeni panjaluk foto kasebut.
Kaputusan iki nduweni kaluwihan sing jelas. Iki SHD. Tujuane kanggo nyimpen foto. Iki luwih murah tinimbang mung nglengkapi mesin kanthi hard drive.
Kapindho plus.
Iki sing kapasitas wis dadi luwih gedhe, i.e. kita bisa nampung panyimpenan luwih akeh ing volume sing luwih cilik.
Nanging ana uga kekurangan sing muncul kanthi cepet. Nalika jumlah pangguna lan beban ing sistem iki saya tambah, masalah kinerja wiwit muncul. Lan masalah kene cukup ketok - sembarang SHD dirancang kanggo nyimpen akeh foto ing volume cilik, minangka aturan, nandhang sangsara saka maca intensif. Iki bener kanggo panyimpenan maya utawa liya-liyane. Saiki kita ora duwe panyimpenan sing cocog sing bisa diukur tanpa wates, sampeyan bisa ngemot apa wae, lan bakal ngidini maca kanthi apik. Utamane maca santai.
Kaya ing foto kita, amarga foto dijaluk ora konsisten, lan iki bakal mengaruhi kinerja.
Malah miturut tokoh dina, yen kita njaluk nang endi wae luwih saka 500 RPS kanggo foto ing mesin kang panyimpenan wis disambungake, masalah wis diwiwiti. Lan cukup ala kanggo kita, amarga jumlah pangguna saya tambah akeh, kahanan bakal saya tambah elek. Iki kudu dioptimalake piye wae.
Kanggo ngoptimalake, kita mutusake ing wektu kasebut, kanthi jelas, ndeleng profil beban - apa, umume, kedadeyan, apa sing kudu dioptimalake.
Lan ing kene kabeh main ing tangan kita.
Aku wis ngomong ing slide pisanan: kita duwe 80 ewu panjaluk maca saben detik kanthi mung 3,5 yuta unggahan saben dina. Tegese, iki bedane telung urutan gedhene. Cetha yen maca kudu dioptimalake lan praktis jelas kepiye carane.
Ana siji titik cilik liyane. Spesifik layanan kasebut yaiku yen wong ndhaptar, ngunggah foto, banjur wiwit aktif ndeleng wong liya, kaya wong-wong mau, lan ditampilake kanthi aktif marang wong liya. Banjur ketemu jodho utawa ora ketemu jodho, iku gumantung carane dadi metu, lan mandheg nggunakake layanan kanggo nalika. Ing wektu iki, nalika dheweke nggunakake, foto-fotone panas banget - lagi dikarepake, akeh sing ndeleng. Sanalika dheweke mandheg nindakake iki, kanthi cepet dheweke ilang saka akeh paparan marang wong liya kaya sadurunge, lan fotone meh ora tau dijaluk.
Sing. Kita duwe dataset panas cilik banget. Nanging ing wektu sing padha ana akeh panjalukan kanggo dheweke. Lan solusi sing jelas banget yaiku nambah cache.
Cache karo LRU bakal ngrampungake kabeh masalah kita. Apa sing kita tindakake?
Kita nambah siji liyane relatif cilik ing ngarepe kluster gedhe karo panyimpenan, kang disebut photocaches. Iki ateges mung proxy caching.
Kepiye cara kerjane saka njero? Punika pangguna kita, punika panyimpenan. Kabeh padha karo sadurunge. Apa kita nambah ing antarane?
Iku mung mesin karo disk lokal fisik, kang cepet. Iki karo SSD, contone,. Lan sawetara jinis cache lokal disimpen ing disk iki.
Apa sing katon? Pangguna ngirim panjalukan kanggo foto. NGINX nggoleki pisanan ing cache lokal. Yen ora, banjur mung proxy_pass menyang panyimpenan kita, download foto saka ing kono lan wenehake menyang pangguna.
Nanging siji iki banget banal lan ora jelas apa sing kedadeyan ing njero. Kerjane kaya iki.
Cache kasebut sacara logis dipérang dadi telung lapisan. Nalika aku ngomong "telung lapisan", iki ora ateges ana sawetara jenis sistem Komplek. Ora, iki mung telung direktori ing sistem file:
- Iki minangka buffer ing ngendi foto sing diunduh saka proxy go.
- Iki minangka cache panas sing nyimpen foto sing saiki aktif dijaluk.
- Lan cache kadhemen, ngendi foto sing mboko sithik di-push metu saka cache panas nalika kurang panjalukan teka kanggo wong-wong mau.
Kanggo nindakake iki, kita kudu ngatur cache iki, kita kudu ngatur maneh foto kasebut, lsp. Iki uga proses banget primitif.
Nginx mung nulis menyang RAMDisk access.log kanggo saben panyuwunan, sing nuduhake path menyang foto sing saiki wis dilayani (path relatif, mesthi), lan partisi sing dilayani. Sing. bisa ngomong "foto 1" lan banjur salah siji buffer, utawa cache panas, utawa cache kadhemen, utawa proxy.
Gumantung iki, kita kudu mutusake apa sing kudu ditindakake karo foto kasebut.
Kita duwe daemon cilik sing mlaku ing saben mesin sing terus maca log iki lan nyimpen statistik babagan panggunaan foto tartamtu ing memori.
Dheweke mung nglumpukake ana, nyimpen counters lan periodik nindakake ing ngisor iki. Dheweke mindhah foto sing dijaluk kanthi aktif, sing ana akeh panjaluk, menyang cache panas, ing endi wae.
Foto-foto sing jarang dijaluk lan wis jarang dijaluk mboko sithik metu saka cache panas menyang sing adhem.
Lan nalika kita kehabisan papan ing cache, kita mung miwiti mbusak kabeh saka cache kadhemen tanpa pilih-pilih. Lan kanthi cara iki, iki bisa dianggo kanthi apik.
Supaya foto bisa langsung disimpen nalika proxy menyang buffer, kita nggunakake proxy_store direktif lan buffer uga RAMDisk, i.e. kanggo pangguna kerjane cepet banget. Iki gegayutan karo internal server caching dhewe.
Pitakonan sing isih ana yaiku carane nyebarake panjalukan ing server kasebut.
Ayo dadi ngomong ana klompok rong puluh mesin panyimpenan lan telung server caching (iki kedaden).
We kudu piye wae nemtokake panjalukan kanggo kang foto lan ngendi kanggo nampa wong.
Pilihan sing paling umum yaiku Round Robin. Utawa ora sengaja?
Iki temenan duwe sawetara cacat amarga kita bakal nggunakake cache banget inefficiently ing kahanan kuwi. Panyuwunan bakal ndharat ing sawetara mesin acak: ing kene cache, nanging ing sabanjure ora ana maneh. Lan yen kabeh iki bisa, iku bakal ala banget. Malah karo nomer cilik mesin ing kluster.
We kudu piye wae unambiguously nemtokake server kanggo nampa request.
Ana cara banal. Kita njupuk hash saka URL utawa hash saka kunci sharding, sing ana ing URL, lan dibagi kanthi jumlah server. Bakal bisa? bakal.
Sing. kita duwe panjalukan 2%, contone, kanggo sawetara "example_url" bakal tansah nampa ing server karo indeks "XNUMX", lan cache bakal terus-terusan dibuwang sabisa.
Nanging ana masalah karo resharding ing rencana kuwi. Resharding - Maksudku ngganti jumlah server.
Ayo nganggep manawa kluster caching ora bisa ngatasi lan kita mutusake kanggo nambah mesin liyane.
Ayo nambah.
Saiki kabeh ora bisa dibagi dadi telu, nanging papat. Mangkono, meh kabeh kunci sing digunakake, meh kabeh URL saiki manggon ing server liyane. Cache kabeh ora valid mung sedhela. Kabeh panjalukan tiba ing kluster panyimpenan kita, dadi ora sehat, gagal layanan lan pangguna ora marem. Aku ora pengin nglakoni.
Pilihan iki uga ora cocog karo kita.
Iku. apa sing kudu kita lakoni? Kita kudu piye wae nggunakake efisien cache, nampa request padha ing server padha maneh lan maneh, nanging tahan kanggo resharding. Lan ana solusi kasebut, ora rumit. Iki diarani hashing konsisten.
Wujudipun kados pundi?
Kita njupuk sawetara fungsi saka tombol sharding lan nyebar kabeh nilai ing bunder. Sing. ing titik 0, nilai minimal lan maksimum konvergen. Sabanjure, kita nyelehake kabeh server ing bunder sing padha kanthi cara iki:
Saben server ditetepake dening siji titik, lan sektor sing dadi clockwise kanggo iku, patut, dilayani dening inang iki. Nalika panjalukan teka, kita langsung weruh, contone, request A - wis hash ana - lan dilayani dening server 2. Request B - dening server 3. Lan sateruse.
Apa sing kedadeyan ing kahanan iki sajrone resharding?
Kita ora mbatalake kabeh cache, kaya sadurunge, lan ora ngganti kabeh tombol, nanging kita mindhah saben sektor kanthi jarak sing cendhak supaya, kanthi relatif, server kaping enem, sing pengin ditambahake, cocog karo papan sing bebas, lan kita nambah ing kono.
Mesthi, ing kahanan kaya mengkono tombol uga pindhah metu. Nanging dheweke metu luwih lemah tinimbang sadurunge. Lan kita weruh yen loro tombol pisanan tetep ing server, lan server caching diganti mung kanggo tombol pungkasan. Iki cukup efisien, lan yen sampeyan nambah host anyar kanthi bertahap, mula ora ana masalah gedhe ing kene. Sampeyan nambah lan nambah sethitik ing wektu, ngenteni nganti cache kebak maneh, lan kabeh bisa uga.
Pitakonan mung tetep karo nolak. Ayo nganggep manawa ana jinis mobil sing rusak.
Lan kita ora bakal pengin regenerate peta iki ing wayahe, invalidate bagean saka cache, lan ing, yen, contone, mesin rebooted, lan kita kudu piye wae panjalukan layanan. Kita mung nyimpen siji cache foto serep ing saben situs, sing tumindak minangka panggantos kanggo mesin apa wae sing saiki mudhun. Lan yen dumadakan salah sawijining server ora kasedhiya, lalu lintas bakal ana. Alamiah, kita ora duwe cache ana, i.e. iku kadhemen, nanging paling panjalukan pangguna lagi diproses. Yen interval sing cendhak, mula kita ngalami kanthi tenang. Ana mung liyane beban ing panyimpenan. Yen interval iki dawa, mula kita wis bisa nggawe keputusan - mbusak server iki saka peta utawa ora, utawa bisa uga ngganti karo liyane.
Iki babagan sistem caching. Ayo katon ing asil.
Kayane ora ana sing rumit ing kene. Nanging cara ngatur cache iki menehi tingkat trick kira-kira 98%. Sing. saka iki 80 ewu panjalukan saben detik, mung 1600 tekan panyimpenan, lan iki mbukak rampung normal, padha calmly keno iku, kita tansah duwe cadangan.
Kita nyelehake server kasebut ing telung DC, lan nampa telung titik kehadiran - Prague, Miami lan Hong Kong.
Iku. padha luwih utawa kurang lokal dumunung kanggo saben target pasar kita.
Lan minangka bonus sing apik, kita entuk proxy caching iki, ing endi CPU ora aktif, amarga ora dibutuhake kanggo ngladeni konten. Lan ing kana, nggunakake NGINX + Lua, kita ngetrapake akeh logika utilitarian.
Contone, kita bisa eksprimen karo webp utawa jpeg progresif (iki format modern efektif), ndeleng carane iku mengaruhi lalu lintas, nggawe sawetara pancasan, ngaktifake kanggo negara tartamtu, etc.; nggawe ukuran dinamis utawa potong foto kanthi cepet.
Iki minangka kasus panggunaan sing apik nalika, contone, sampeyan duwe aplikasi seluler sing nampilake foto, lan aplikasi seluler ora pengin mbuang CPU klien kanggo njaluk foto gedhe lan banjur ngowahi ukurane menyang ukuran tartamtu supaya bisa nyurung menyang. tampilan. Kita mung bisa kanthi dinamis nemtokake sawetara paramèter ing URL kondisional UPort, lan cache foto bakal ngowahi ukuran foto kasebut. Minangka aturan, bakal milih ukuran sing kita duwe fisik ing disk, sabisa kanggo sing dijaluk, lan downsell ing koordinat tartamtu.
Miturut cara, kita wis nggawe rekaman video sing kasedhiya kanggo umum sajrone limang taun pungkasan konferensi para pangembang sistem beban dhuwur . Nonton, sinau, nuduhake lan langganan .
Kita uga bisa nambah akeh logika produk ing kana. Contone, kita bisa nambah watermarks beda nggunakake parameter URL, kita bisa blur, blur utawa pixelate foto. Iki nalika kita pengin nuduhake foto wong, nanging kita ora pengin nuduhake pasuryan, iki bisa uga, kabeh wis dileksanakake kene.
Apa sing kita entuk? We entuk telung titik ngarsane, tingkat trick apik, lan ing wektu sing padha kita ora duwe CPU nganggur ing mesin iki. Dheweke saiki wis dadi, mesthi, luwih penting tinimbang sadurunge. Kita kudu menehi mobil sing luwih kuwat, nanging pancen pantes.
Iki gegayutan karo bali foto. Kabeh ing kene cukup jelas lan jelas. Aku ora nemokake Amerika, meh kabeh CDN bisa digunakake kanthi cara iki.
Lan, paling kamungkinan, pamireng sing canggih bisa uga duwe pitakonan: kenapa ora mung ngganti kabeh menyang CDN? Bakal meh padha; kabeh CDN modern bisa nindakake iki. Lan ana sawetara alasan.
Sing pertama yaiku foto.
Iki minangka salah sawijining titik penting ing infrastruktur kita, lan kita butuh kontrol sing bisa ditindakake. Yen iki sawetara jenis solusi saka vendor pihak katelu, lan sampeyan ora duwe daya liwat, iku bakal cukup angel kanggo sampeyan manggon karo nalika sampeyan duwe dataset gedhe, lan nalika sampeyan duwe aliran gedhe banget. saka panjalukan pangguna.
Ayo kula menehi conto. Saiki, kanthi infrastruktur, kita bisa, umpamane, yen ana masalah utawa ketukan lemah, pindhah menyang mesin lan kekacoan ing kono, kanthi relatif. Kita bisa nambah koleksi sawetara metrik sing mung kita butuhake, kita bisa nyoba piye wae, ndeleng carane iki mengaruhi grafik, lan liya-liyane. Saiki akeh statistik sing diklumpukake ing kluster caching iki. Lan kita periodik katon ing lan nglampahi dangu njelajah sawetara anomali. Yen ana ing sisih CDN, bakal luwih angel dikontrol. Utawa, contone, yen ana sawetara kacilakan, kita ngerti apa sing kedadeyan, kita ngerti carane urip lan carane ngatasi. Iki minangka kesimpulan pisanan.
Kesimpulan kapindho uga rada sajarah, amarga sistem wis berkembang kanggo dangu, lan ana akeh syarat bisnis beda ing macem-macem orane tumrap sekolah, lan padha ora tansah pas karo konsep CDN.
Lan titik sing nderek saka sing sadurunge yaiku
Iki amarga ing caches foto kita duwe akèh logika tartamtu, kang ora bisa tansah ditambahake ing request. Ora mungkin CDN bakal nambah sawetara barang khusus kanggo sampeyan miturut panjaluk sampeyan. Contone, enkripsi URL yen sampeyan ora pengin klien bisa ngganti soko. Apa sampeyan pengin ngganti URL ing server lan ndhelik, banjur ngirim sawetara paramèter dinamis ing kene.
Apa kesimpulan iki menehi saran? Ing kasus kita, CDN dudu alternatif sing apik banget.
Lan ing kasus sampeyan, yen sampeyan duwe syarat bisnis tartamtu, sampeyan bisa kanthi gampang ngetrapake apa sing daktuduhake dhewe. Lan iki bakal bisa digunakake kanthi becik karo profil beban sing padha.
Nanging yen sampeyan duwe sawetara jenis solusi umum, lan tugas ora banget tartamtu, sampeyan bisa kanthi aman njupuk CDN. Utawa yen wektu lan sumber daya luwih penting kanggo sampeyan tinimbang kontrol.
Lan CDN modern duwe meh kabeh sing dakkandhakake saiki. Kajaba plus utawa minus sawetara fitur.
Iki babagan menehi foto.
Ayo saiki maju sethithik ing retrospektif lan ngomong babagan panyimpenan.
2013 wis liwati.
Server cache ditambahake, masalah kinerja ilang. Kabeh apik. Dataset saya akeh. Ing taun 2013, ana 80 server sing disambungake menyang panyimpenan, lan udakara 40 cache ing saben DC. Iki 560 terabyte data ing saben DC, i.e. kira-kira petabyte total.
Lan kanthi wutah saka dataset, biaya operasi wiwit mundhak akeh. Apa tegese iki?
Ing diagram iki sing digambar - karo SAN, karo mesin lan caches disambungake menyang - ana akeh titik gagal. Yen kita wis ngatasi kegagalan server caching sadurunge, kabeh bisa ditebak lan bisa dingerteni, nanging ing sisih panyimpenan kabeh luwih elek.
Sepisanan, Storage Area Network (SAN) dhewe, sing bisa gagal.
Kapindho, disambungake liwat optik menyang mesin pungkasan. Bisa uga ana masalah karo kertu optik lan busi.
Mesthine, ora akeh kaya SAN dhewe, nanging, iki uga dadi titik kegagalan.
Sabanjure yaiku mesin dhewe, sing disambungake menyang panyimpenan. Bisa uga gagal.
Secara total, kita duwe telung titik kegagalan.
Salajengipun, saliyane titik-titik kegagalan, ana pangopènan sing abot ing panyimpenan kasebut.
Iki minangka sistem multi-komponen sing rumit, lan insinyur sistem bisa angel nggarap.
Lan pungkasan, titik paling penting. Yen ana kegagalan ing salah siji saka telung titik kasebut, kita duwe kemungkinan ora nol kanggo kelangan data pangguna amarga sistem file bisa nabrak.
Ayo kita ngomong sistem file kita rusak. Sepisanan, Recovery njupuk wektu dawa - iku bisa njupuk minggu karo jumlah akeh data. Lan kaping pindho, ing pungkasan kita bakal entuk akeh file sing ora bisa dingerteni sing kudu digabungake dadi foto pangguna. Lan kita resiko kelangan data. Resiko cukup dhuwur. Lan luwih kerep kahanan kaya mengkono, lan luwih akeh masalah sing muncul ing kabeh rantai iki, luwih dhuwur risiko iki.
Ana sing kudu ditindakake babagan iki. Lan kita mutusake yen mung kudu nggawe serep data. Iki bener solusi sing jelas lan apik. Apa sing wis kita lakoni?
Iki kaya server kita nalika disambungake menyang panyimpenan sadurunge. Iki salah siji bagean utama, iku mung piranti pamblokiran sing bener makili gunung kanggo panyimpenan remot liwat optik.
Kita mung nambah bagean kapindho.
We diselehake panyimpenan kapindho ing jejere (begjanipun, iku ora larang ing syarat-syarat dhuwit), lan disebut partisi serep. Iki uga disambungake liwat optik lan dumunung ing mesin sing padha. Nanging kita kudu piye wae nyinkronake data ing antarane.
Ing kene kita mung nggawe antrian asinkron ing cedhak.
Dheweke ora sibuk banget. Kita ngerti kita ora duwe cathetan sing cukup. Antrian mung tabel ing MySQL ing ngendi baris kaya "sampeyan kudu nggawe serep foto iki" ditulis. Kanthi owah-owahan utawa upload, kita nyalin saka partisi utama menyang serep nggunakake asynchronous utawa mung sawetara jenis buruh latar mburi.
Lan kanthi mangkono kita tansah duwe rong bagean sing konsisten. Sanajan salah siji bagéan saka sistem iki gagal, kita bisa tansah ngganti partisi utama karo serep, lan kabeh bakal terus bisa.
Nanging amarga iki, beban maca mundhak banget, amarga ... saliyane kanggo klien sing maca saka bagean utama, amarga padha pisanan katon ing foto ana (luwih anyar ana), lan banjur goleki ing serep, yen padha ora ketemu (nanging NGINX mung nindakake iki), sistem kita uga plus serep saiki maca saka pemisahan utama. Iku ora sing iki bottleneck, nanging aku ora pengin nambah mbukak, ateges, kaya sing.
Lan kita nambahake disk katelu, yaiku SSD cilik, lan diarani buffer.
Cara kerjane saiki.
Pangguna ngunggah foto menyang buffer, banjur acara dibuwang menyang antrian sing nuduhake yen kudu disalin dadi rong bagean. Disalin, lan foto urip ing buffer kanggo sawetara wektu (ngomong, dina), lan mung banjur diresiki saka ing kono. Iki banget nambah pengalaman pangguna, amarga pangguna ngunggah foto, minangka aturan, panjaluk langsung diwiwiti, utawa dheweke dhewe nganyari kaca kasebut lan nyegerake. Nanging kabeh gumantung ing aplikasi sing nggawe upload.
Utawa, contone, wong liya sing wiwit nuduhake awake langsung ngirim panjalukan sawise foto iki. Iki durung ana ing cache; panjalukan pisanan kedadeyan kanthi cepet. Ateges padha saka cache foto. Panyimpenan alon ora melu ing kabeh iki. Lan nalika dina mengko wis diresiki, iku wis salah siji cache ing lapisan caching kita, utawa, paling kamungkinan, ora ana sing perlu maneh. Sing. Pengalaman pangguna ing kene saya tambah apik amarga manipulasi sing prasaja.
Inggih, lan sing paling penting: kita mandheg ilang data.
Ayo ngomong kita mandheg duweni potensi kelangan data, amarga kita ora kelangan. Nanging ana bebaya. We ndeleng sing solusi iki, mesthi, apik, nanging sethitik kaya smoothing metu gejala masalah, tinimbang mecahaken iku rampung. Lan sawetara masalah tetep ana ing kene.
Kaping pisanan, iki minangka titik kegagalan ing bentuk host fisik dhewe sing kabeh mesin iki mlaku; durung ilang.
Sareh, isih ana masalah karo SAN, pangopènan abot, etc. Iku ora iku faktor kritis, nanging aku wanted kanggo nyoba kanggo piye wae manggon tanpa iku.
Lan kita nggawe versi katelu (nyatane, kaloro nyatane) - versi reservasi. Apa sing katon kaya?
Iki sing dadi-
Masalah utama kita yaiku kasunyatan manawa iki minangka host fisik.
Kaping pisanan, kita mbusak SAN amarga kita pengin eksprimen, kita pengin nyoba mung hard drive lokal.
Iki wis 2014-2015, lan ing wektu sing kahanan karo disk lan kapasitas ing siji host dadi luwih apik. Kita mutusake kenapa ora nyoba.
Banjur kita mung njupuk partisi serep lan transfer fisik menyang mesin sing kapisah.
Mangkono, kita entuk diagram iki. Kita duwe rong mobil sing nyimpen set data sing padha. Padha gawe serep saben liyane lan nyinkronake data liwat jaringan liwat antrian bedo ing MySQL padha.
Napa iki bisa dianggo kanthi apik amarga kita duwe sawetara cathetan. Sing. yen nulis padha iso dibandhingke kanggo maca, mbok menawa kita bakal duwe sawetara jenis nduwur sirah jaringan lan masalah. Ana tulisan cilik, akeh maca - cara iki bisa dianggo kanthi apik, yaiku. Kita jarang nyalin foto ing antarane loro server kasebut.
Carane ora iki bisa, yen katon sethitik liyane ing rinci.
Upload. Balance mung milih host acak kanthi pasangan lan upload menyang. Ing wektu sing padha, dheweke kanthi alami mriksa kesehatan lan mesthekake yen mobil ora tiba. Sing. dheweke upload foto mung kanggo server urip, lan banjur liwat antrian bedo iku kabeh disalin kanggo pepadhamu. Kanthi upload kabeh iku arang banget prasaja.
Tugase rada angel.
Lua mbantu kita ing kene, amarga bisa angel nggawe logika kasebut ing vanilla NGINX. We pisanan nggawe panjalukan kanggo server pisanan, ndeleng yen foto ana, amarga duweni potensi bisa diunggahaké, contone, kanggo pepadhamu, nanging durung teka kene. Yen foto ana, sing apik. Kita langsung menehi menyang klien lan, bisa uga, cache.
Yen ora ana, kita mung njaluk panjaluk marang tanggane lan dijamin bakal nampa.
Iku. maneh kita bisa ngomong: ana uga masalah karo kinerja, amarga ana lelungan babak pancet - foto diunggahaké, iku ora kene, kita nggawe loro panjalukan tinimbang siji, iki kudu alon-alon.
Ing kahanan kita, iki ora bisa alon-alon.
Kita ngumpulake akeh metrik ing sistem iki, lan tingkat cerdas kondisional mekanisme kasebut kira-kira 95%. Sing. Lag saka serep iki cilik, lan amarga iki kita meh dijamin, sawise foto wis diunggahaké, kita bakal njupuk pisanan lan ora kudu pindhah menyang ngendi wae kaping pindho.
Dadi apa maneh kita entuk sing apik tenan?
Sadurunge, kita duwe partisi serep utama, lan kita maca saka urutan kasebut. Sing. Kita tansah nggolèki ing utama pisanan, lan banjur ing serep. Iku salah siji pamindhahan.
Saiki kita nggunakake maca saka rong mesin sekaligus. We disebaraké panjalukan nggunakake Round Robin. Ing persentasi cilik saka kasus kita nggawe loro panjalukan. Nanging sakabèhé, saiki kita duwe saham maca kaping pindho tinimbang sadurunge. Lan beban iki suda banget ing mesin ngirim lan langsung ing mesin panyimpenan, sing uga ana ing wektu kasebut.
Minangka kanggo toleransi fault. Bener, iki sing utamane kita geluti. Kanthi toleransi fault, kabeh dadi apik ing kene.
Siji mobil mogok.
Ora masalah! Insinyur sistem bisa uga ora tangi ing wayah wengi, dheweke bakal ngenteni nganti esuk, ora ana sing bakal kelakon.
Yen sanajan mesin iki gagal, antrian wis rusak, ora ana masalah, log mung bakal diklumpukake dhisik ing mesin urip, banjur ditambahake ing antrian, banjur menyang mobil sing bakal pindhah menyang operasi sawise sawetara wektu.
Bab sing padha karo pangopènan. Kita mung mateni salah siji mesin, kanthi manual narik metu saka kabeh pools, iku mandheg nampa lalu lintas, kita nindakake sawetara jenis pangopènan, kita ngowahi soko, banjur bali menyang layanan, lan serep iki keno munggah cukup cepet. Sing. saben dina, downtime siji mobil keno munggah ing sawetara menit. Iki pancene sithik banget. Kanthi toleransi fault, Aku ngandika maneh, kabeh iku kelangan kene.
Apa kesimpulan sing bisa dijupuk saka skema redundansi iki?
Kita entuk toleransi kesalahan.
Gampang digunakake. Wiwit mesin duwe hard drive lokal, iki luwih trep saka sudut pandang operasional kanggo para insinyur sing nggarap.
Kita nampa sangu maca pindho.
Iki bonus apik banget saliyane toleransi fault.
Nanging ana uga masalah. Saiki kita duwe pangembangan sing luwih rumit babagan sawetara fitur sing ana gandhengane, amarga sistem kasebut dadi 100% pungkasane konsisten.
Kita kudu, ujar, ing sawetara proyek latar mburi, terus-terusan mikir: "Server apa sing kita lakoni saiki?", "Apa ana foto saiki ing kene?" lsp. Iki, mesthine, kabeh wis dibungkus, lan kanggo programer sing nulis logika bisnis, transparan. Nanging, Nanging, lapisan Komplek gedhe iki wis katon. Nanging kita wis siyap kanggo nyelehake munggah karo iki minangka ijol-ijolan kanggo barang sing ditampa saka iku.
Lan ing kene maneh sawetara konflik muncul.
Aku ngandika ing awal sing nyimpen kabeh ing hard drive lokal ala. Lan saiki aku ngomong yen kita seneng.
Ya, pancen, suwe-suwe kahanan wis owah akeh, lan saiki pendekatan iki duwe akeh kaluwihan. Kaping pisanan, kita entuk operasi sing luwih gampang.
Kapindho, luwih produktif, amarga kita ora duwe pengontrol otomatis iki utawa sambungan menyang rak disk.
Ana jumlah ageng mesin ana, lan iki mung sawetara disk sing nglumpuk kene ing mesin menyang gropyokan.
Nanging ana uga kekurangan.
Iki kira-kira 1,5 kaping luwih larang tinimbang nggunakake SAN sanajan ing rega saiki. Mula, kita mutusake ora kanthi kendel ngowahi kabeh kluster gedhe dadi mobil kanthi hard drive lokal lan mutusake ninggalake solusi hibrida.
Setengah saka mesin kita bisa nganggo hard drive (uga, ora setengah - mbokmenawa 30 persen). Lan liyane minangka mobil lawas sing duwe skema reservasi pisanan. Kita mung remounted wong, amarga kita ora perlu data anyar utawa liyane, kita mung dipindhah gunung saka siji host fisik kanggo loro.
Lan kita saiki duwe stock akeh maca, lan kita ditambahi. Yen sadurunge kita dipasang siji panyimpenan ing siji mesin, saiki kita dipasang papat, contone, ing siji pasangan. Lan kerjane apik.
Ayo njupuk ringkesan ringkes babagan apa sing wis kita lakoni, apa sing kita perjuangake, lan apa kita sukses.
Hasil
Kita duwe pangguna - nganti 33 yuta.
Kita duwe telung titik kehadiran - Prague, Miami, Hong Kong.
Padha ngemot lapisan caching, kang kasusun saka mobil karo disk lokal cepet (SSD), kang machinery prasaja saka NGINX, akses.log lan Python daemons mbukak, kang proses kabeh iki lan ngatur cache.
Yen sampeyan pengin, sampeyan ana ing proyek sampeyan, yen foto ora kritis kanggo sampeyan kaya kanggo kita, utawa yen kontrol trade-off mungsuh kacepetan pembangunan lan biaya sumber daya ing arah liyane kanggo sampeyan, sampeyan bisa kanthi aman ngganti karo CDN, CDNs modern padha nindakake uga.
Sabanjure ana lapisan panyimpenan, ing ngendi kita duwe klompok pasangan mesin sing serep saben liyane, file disalin kanthi ora sinkron saka siji menyang liyane saben diganti.
Kajaba iku, sawetara mesin iki bisa digunakake karo hard drive lokal.
Sawetara mesin iki disambungake menyang SAN.
Lan, ing tangan siji, iku luwih trep kanggo nggunakake lan sethitik liyane produktif, ing tangan liyane, iku trep ing Kapadhetan panggonan seko lan rega saben gigabyte.
Iki minangka ringkesan ringkes babagan arsitektur apa sing kita entuk lan kepiye kabeh dikembangake.
A sawetara tips liyane saka kapten, banget prasaja.
Pisanan, yen sampeyan ujug-ujug mutusake yen sampeyan kudu cepet-cepet nambah kabeh ing prasarana foto, ukur dhisik, amarga bisa uga ora ana sing kudu didandani.
Ayo kula menehi conto. We duwe kluster mesin sing ngirim foto saka lampiran ing chats, lan rencana wis makarya ana wiwit 2009, lan ora ana kang nandhang sangsara marga saka iku. Kabeh wong apik, kabeh seneng kabeh.
Kanggo ngukur, gantungake metrik dhisik, delengen, banjur mutusake apa sing sampeyan ora seneng lan apa sing kudu ditambahake. Kanggo ngukur iki, kita duwe alat keren sing diarani Pinba.
Ngidini sampeyan ngumpulake statistik sing rinci banget saka NGINX kanggo saben panjaluk lan kode respon, lan distribusi kaping - apa wae sing dikarepake. Nduwe ikatan karo macem-macem sistem analytics sing beda-beda, banjur sampeyan bisa ndeleng kabeh kanthi apik.
Pisanan kita ngukur, banjur nambah.
Salajengipun. Kita ngoptimalake maca nganggo cache, nulis nganggo sharding, nanging iki minangka titik sing jelas.
Salajengipun. Yen sampeyan lagi miwiti mbangun sistem, iku luwih apik kanggo nggawe foto minangka file immutable. Amarga sampeyan langsung kelangan kabeh kelas masalah karo invalidation cache, karo carane logika kudu nemokake versi bener saka foto, lan ing.
Contone, sampeyan ngunggah satus, banjur muter, nggawe file kasebut dadi file sing beda. Sing. ora perlu mikir: saiki aku bakal ngirit papan sing sithik, tulis menyang file sing padha, ganti versi. Iki mesthi ora bisa digunakake lan nyebabake akeh ngelu mengko.
Titik sabanjure. Babagan ngowahi ukuran kanthi cepet.
Sadurunge, nalika pangguna ngunggah foto, kita langsung ngethok pirang-pirang ukuran kanggo kabeh kesempatan, kanggo klien sing beda-beda, lan kabeh ana ing disk. Saiki kita wis nilar iki.
Kita mung ninggalake telung ukuran utama: cilik, medium lan gedhe. Kita mung nyuda kabeh liyane saka ukuran sing ana ing mburi sing dijaluk ing Uport, kita mung nggawe downscale lan menehi pangguna.
CPU lapisan caching kene dadi luwih murah tinimbang yen kita terus-terusan regenerasi ukuran kasebut ing saben panyimpenan. Ayo dadi ngomong kita pengin nambah anyar, iki bakal njupuk sasi - mbukak script nang endi wae sing bakal nindakake kabeh iki rapi, tanpa numpes kluster. Sing. Yen sampeyan duwe kesempatan kanggo milih saiki, iku luwih apik kanggo nggawe minangka sawetara ukuran fisik sabisa, nanging supaya ing paling sawetara distribusi, ngomong, telung. Lan kabeh liya bisa diowahi ukurane kanthi cepet nggunakake modul sing wis siap. Kabeh iku gampang banget lan bisa diakses saiki.
Lan serep asinkron tambahan apik.
Kaya sing wis ditampilake praktik, skema iki bisa digunakake kanthi tundha nyalin file sing diganti.
Titik pungkasan uga ketok. Yen prasarana sampeyan saiki ora duwe masalah kaya ngono, nanging ana sing bisa rusak, mesthi bakal rusak nalika dadi luwih sithik. Mulane, luwih becik mikir babagan iki sadurunge lan ora ngalami masalah. Mung kuwi sing dakkarepake.
Kontak
»
»
Laporan iki minangka transkrip salah sawijining pidato sing paling apik ing konferensi para pangembang sistem beban dhuwur . Kurang saka sasi nganti konferensi HighLoad ++ 2017.
Kita wis siap , jadwal saiki lagi aktif dibentuk.
Taun iki kita terus njelajah topik arsitektur lan skala:
- / Igor Vasiliev
- / Dmitry Egorov
- / Anatoly Plaskovsky
- / Roman Shekhovtsov, Alexey Gromatchikov
- / Philip Delgado
Kita uga nggunakake sawetara bahan kasebut ing kursus pelatihan online babagan ngembangake sistem beban dhuwur minangka rantai surat, artikel, materi, video sing dipilih khusus. Buku teks kita wis ngemot luwih saka 30 bahan unik. Nyambung!
Source: www.habr.com