Artem Denisov ( , )
Badoo ndio tovuti kubwa zaidi ya kuchumbiana duniani. Kwa sasa tuna takribani watumiaji milioni 330 waliosajiliwa duniani kote. Lakini ni nini muhimu zaidi katika muktadha wa mazungumzo yetu ya leo ni kwamba tunahifadhi karibu petabytes 3 za picha za watumiaji. Kila siku watumiaji wetu hupakia takriban picha milioni 3,5 mpya, na mzigo wa kusoma unakaribia Maombi elfu 80 kwa sekunde. Hii ni mengi kwa backend yetu, na wakati mwingine kuna ugumu na hii.
Nitazungumzia juu ya muundo wa mfumo huu, ambao huhifadhi na kutuma picha kwa ujumla, na nitaiangalia kutoka kwa mtazamo wa msanidi programu. Kutakuwa na muhtasari mfupi wa jinsi ilivyokua, ambapo nitaelezea hatua kuu, lakini nitazungumza tu kwa undani zaidi juu ya suluhisho ambazo tunatumia sasa.
Sasa hebu tuanze.
Kama nilivyosema, hii itakuwa ya kurudi nyuma, na ili kuianzisha mahali pengine, wacha tuchukue mfano wa kawaida.
Tuna kazi ya kawaida, tunahitaji kukubali, kuhifadhi na kutuma picha za mtumiaji. Katika fomu hii, kazi ni ya jumla, tunaweza kutumia chochote:
- uhifadhi wa kisasa wa wingu,
- suluhisho la sanduku, ambalo pia kuna mengi sasa;
- Tunaweza kusanidi mashine kadhaa katika kituo chetu cha data na kuziwekea diski kuu kuu na kuhifadhi picha hapo.
Badoo kihistoria - mara kwa mara (wakati huo ikiwa changa) - anaishi kwenye seva zake, ndani ya DC zetu wenyewe. Kwa hivyo, chaguo hili lilikuwa bora kwetu.
Tumechukua tu mashine kadhaa, tukaziita "picha", na tukapata kikundi kinachohifadhi picha. Lakini inaonekana kama kuna kitu kinakosekana. Ili yote haya yafanye kazi, tunahitaji kwa namna fulani kuamua kwenye mashine ambayo tutahifadhi picha gani. Na hapa, pia, hakuna haja ya kufungua Amerika.
Tunaongeza sehemu fulani kwenye hifadhi yetu na maelezo kuhusu watumiaji. Huu utakuwa ufunguo wa kugawa. Kwa upande wetu, tuliiita place_id, na kitambulisho cha mahali hapa kinaelekeza mahali ambapo picha za mtumiaji zimehifadhiwa. Tunatengeneza ramani.
Katika hatua ya kwanza, hii inaweza kufanywa hata kwa mikono - tunasema kwamba picha ya mtumiaji huyu aliye na mahali kama hii itatua kwenye seva kama hiyo. Shukrani kwa ramani hii, tunajua kila wakati mtumiaji anapopakia picha, mahali pa kuihifadhi, na tunajua mahali pa kuitoa.
Huu ni mpango mdogo kabisa, lakini una faida kubwa kabisa. Ya kwanza ni kwamba ni rahisi, kama nilivyosema, na ya pili ni kwamba kwa mbinu hii tunaweza kuongeza usawa kwa urahisi kwa kutoa magari mapya na kuyaongeza kwenye ramani. Huna haja ya kufanya kitu kingine chochote.
Ndivyo ilivyokuwa kwetu kwa muda fulani.
Hii ilikuwa karibu 2009. Walileta magari, wakatoa...
Na wakati fulani tulianza kugundua kuwa mpango huu una shida fulani. Je, kuna hasara gani?
Kwanza kabisa, kuna uwezo mdogo. Hatuwezi kubandika diski kuu nyingi kwenye seva moja halisi kama tungependa. Na hili limekuwa tatizo fulani baada ya muda na kwa ukuaji wa hifadhidata.
Na ya pili. Huu ni usanidi usio wa kawaida wa mashine, kwani mashine kama hizo ni ngumu kutumia tena katika vikundi vingine; ni maalum kabisa, i.e. wanapaswa kuwa dhaifu katika utendaji, lakini wakati huo huo na gari kubwa ngumu.
Hii yote ilikuwa ya 2009, lakini, kimsingi, mahitaji haya bado yanafaa leo. Tuna mtazamo wa nyuma, kwa hivyo mnamo 2009 kila kitu kilikuwa kibaya kabisa na hii.
Na hatua ya mwisho ni bei.
Bei ilikuwa ya juu sana wakati huo, na tulihitaji kutafuta njia mbadala. Wale. tulihitaji kwa namna fulani kutumia vyema nafasi katika vituo vya data na seva halisi ambazo haya yote yanapatikana. Na wahandisi wetu wa mfumo walianza utafiti mkubwa ambao walikagua rundo la chaguzi tofauti. Pia waliangalia mifumo ya faili iliyounganishwa kama vile PolyCeph na Luster. Kulikuwa na matatizo ya utendaji na uendeshaji mgumu sana. Walikataa. Tulijaribu kuweka hifadhidata nzima kupitia NFS kwenye kila gari ili kwa namna fulani kuiongeza. Kusoma pia kulikwenda vibaya, tulijaribu suluhisho tofauti kutoka kwa wachuuzi tofauti.
Na mwishowe, tuliamua kutumia kinachojulikana kama Mtandao wa Eneo la Hifadhi.
Hizi ni SHD kubwa ambazo zimeundwa mahususi kwa ajili ya kuhifadhi kiasi kikubwa cha data. Ni rafu zilizo na diski ambazo zimewekwa kwenye mashine za mwisho za pato la macho. Hiyo. tuna aina fulani ya mashine, ndogo kabisa, na SHD hizi, ambazo ni wazi kwa mantiki yetu ya kutuma, i.e. kwa nginx yetu au mtu mwingine yeyote kutuma maombi ya picha hizi.
Uamuzi huu ulikuwa na faida dhahiri. Hii ni SHD. Inalenga kuhifadhi picha. Hii inafanya kazi kwa bei nafuu kuliko kuandaa tu mashine na anatoa ngumu.
Pili pamoja.
Hii ni kwamba uwezo umekuwa mkubwa zaidi, i.e. tunaweza kubeba hifadhi nyingi zaidi katika ujazo mdogo zaidi.
Lakini pia kulikuwa na hasara ambazo zilijitokeza haraka sana. Kadiri idadi ya watumiaji na mzigo kwenye mfumo huu inavyoongezeka, matatizo ya utendaji yalianza kutokea. Na shida hapa ni dhahiri - SHD yoyote iliyoundwa kuhifadhi picha nyingi kwa kiasi kidogo, kama sheria, inakabiliwa na usomaji wa kina. Hii ni kweli kwa hifadhi yoyote ya wingu au kitu kingine chochote. Sasa hatuna hifadhi bora ambayo inaweza kupunguzwa sana, unaweza kuingiza chochote ndani yake, na inaweza kuvumilia usomaji vizuri sana. Hasa usomaji wa kawaida.
Kama ilivyo kwa picha zetu, kwa sababu picha zinaombwa bila kufuatana, na hii itaathiri sana utendaji wao.
Hata kulingana na takwimu za leo, ikiwa tunapata mahali fulani zaidi ya 500 RPS kwa picha kwenye mashine ambayo hifadhi imeunganishwa, matatizo tayari yanaanza. Na ilikuwa mbaya kwa ajili yetu, kwa sababu idadi ya watumiaji inaongezeka, mambo yatazidi kuwa mabaya zaidi. Hii inahitaji kuboreshwa kwa njia fulani.
Ili kuboresha, tuliamua wakati huo, ni wazi, kuangalia wasifu wa mzigo - ni nini, kwa ujumla, kinachotokea, ni nini kinachohitaji kuboreshwa.
Na hapa kila kitu kinacheza mikononi mwetu.
Tayari nilisema kwenye slaidi ya kwanza: tuna maombi elfu 80 ya kusoma kwa sekunde na upakiaji milioni 3,5 tu kwa siku. Hiyo ni, hii ni tofauti ya amri tatu za ukubwa. Ni dhahiri kwamba usomaji unahitaji kuboreshwa na ni wazi jinsi gani.
Kuna hatua moja ndogo zaidi. Maelezo ya huduma ni kwamba mtu anajiandikisha, anapakia picha, kisha anaanza kutazama watu wengine, kama wao, na anaonyeshwa kwa watu wengine. Kisha hupata mwenzi au haipati mwenzi, inategemea jinsi inavyogeuka, na kuacha kutumia huduma kwa muda. Kwa wakati huu, anapoitumia, picha zake ni moto sana - zinahitajika, watu wengi huzitazama. Mara tu anapoacha kufanya hivi, haraka sana yeye huacha kufichuliwa na watu wengine kama alivyokuwa hapo awali, na picha zake karibu hazijaombwa kamwe.
Wale. Tuna seti ndogo sana ya data motomoto. Lakini wakati huo huo kuna maombi mengi kwa ajili yake. Na suluhisho dhahiri kabisa hapa ni kuongeza kashe.
Cache na LRU itasuluhisha shida zetu zote. Tunafanya nini?
Tunaongeza nyingine ndogo mbele ya nguzo yetu kubwa yenye hifadhi, inayoitwa photocaches. Kimsingi hii ni proksi ya akiba tu.
Inafanyaje kazi kutoka ndani? Hapa kuna mtumiaji wetu, hapa kuna uhifadhi. Kila kitu ni sawa na hapo awali. Je, tunaongeza nini kati?
Ni mashine tu iliyo na diski halisi ya ndani, ambayo ni ya haraka. Hii ni pamoja na SSD, kwa mfano. Na aina fulani ya cache ya ndani imehifadhiwa kwenye diski hii.
Je, inaonekana kama nini? Mtumiaji hutuma ombi la picha. NGINX huitafuta kwanza kwenye kashe ya ndani. Ikiwa sivyo, basi proxy_pass kwa hifadhi yetu, pakua picha kutoka hapo na umpe mtumiaji.
Lakini hii ni banal sana na haijulikani nini kinatokea ndani. Inafanya kazi kama hii.
Cache imegawanywa kimantiki katika tabaka tatu. Ninaposema "tabaka tatu", hii haina maana kwamba kuna aina fulani ya mfumo tata. Hapana, hizi ni saraka tatu tu katika mfumo wa faili:
- Hii ni bafa ambapo picha zilizopakuliwa kutoka kwa seva mbadala huenda.
- Hii ni akiba motomoto ambayo huhifadhi picha zilizoombwa kwa sasa.
- Na kache baridi, ambapo picha husukumwa hatua kwa hatua kutoka kwenye kache ya moto wakati maombi machache yanapokuja kwao.
Ili hii ifanye kazi, tunahitaji kwa namna fulani kudhibiti kashe hii, tunahitaji kupanga upya picha ndani yake, nk. Huu pia ni mchakato wa primitive sana.
Nginx anaandika tu kwa RAMDisk access.log kwa kila ombi, ambayo inaonyesha njia ya picha ambayo imetumikia kwa sasa (njia ya jamaa, bila shaka), na ni sehemu gani ilitumiwa. Wale. inaweza kusema "picha 1" na kisha afa, au kashe moto, au kache baridi, au proksi.
Kulingana na hili, tunahitaji kwa namna fulani kuamua nini cha kufanya na picha.
Tuna daemoni ndogo inayoendesha kwenye kila mashine ambayo husoma kumbukumbu hii kila mara na kuhifadhi takwimu za matumizi ya picha fulani kwenye kumbukumbu yake.
Anakusanya tu hapo, huweka vihesabio na mara kwa mara hufanya yafuatayo. Anasonga picha zilizoombwa kwa bidii, ambazo maombi mengi huja, kwenye kashe ya moto, popote walipo.
Picha ambazo zimeombwa mara chache na ambazo hazijaombwa mara kwa mara husukumwa hatua kwa hatua kutoka kwenye kashe ya moto hadi kwenye baridi.
Na tunapoishiwa na nafasi kwenye kashe, tunaanza tu kufuta kila kitu kutoka kwa kashe baridi bila kubagua. Na kwa njia, hii inafanya kazi vizuri.
Ili picha ihifadhiwe mara moja wakati wa kuituma kwa bafa, tunatumia maagizo ya proxy_store na bafa pia ni RAMDisk, i.e. kwa mtumiaji inafanya kazi haraka sana. Hii inahusu mambo ya ndani ya seva ya kache yenyewe.
Swali lililobaki ni jinsi ya kusambaza maombi kwenye seva hizi.
Wacha tuseme kuna nguzo ya mashine ishirini za kuhifadhi na seva tatu za kache (hivi ndivyo ilivyotokea).
Tunahitaji kwa namna fulani kuamua ni maombi gani ni ya picha zipi na mahali pa kuziweka.
Chaguo la kawaida ni Round Robin. Au kufanya hivyo kwa bahati mbaya?
Kwa kweli hii ina shida kadhaa kwa sababu tungekuwa tunatumia kashe vibaya sana katika hali kama hii. Maombi yatatua kwenye mashine kadhaa za nasibu: hapa ilihifadhiwa, lakini kwa inayofuata haipo tena. Na ikiwa yote haya yatafanya kazi, itakuwa mbaya sana. Hata kwa idadi ndogo ya mashine kwenye nguzo.
Tunahitaji kwa njia fulani kuamua bila utata ni seva gani itatua ombi gani.
Kuna njia ya banal. Tunachukua heshi kutoka kwa URL au heshi kutoka kwa ufunguo wetu wa kugawanya, ulio kwenye URL, na kuigawanya kwa idadi ya seva. Je, kazi? Mapenzi.
Wale. Tuna ombi la 2%, kwa mfano, kwa baadhi ya "example_url" itatua kwenye seva kila wakati ikiwa na faharasa "XNUMX", na akiba itatupwa kila mara kadri inavyowezekana.
Lakini kuna shida na kushiriki tena katika mpango kama huo. Kushiriki upya - Ninamaanisha kubadilisha idadi ya seva.
Wacha tufikirie kuwa nguzo yetu ya kache haiwezi tena kustahimili na tunaamua kuongeza mashine nyingine.
Hebu tuongeze.
Sasa kila kitu kinagawanywa sio na tatu, lakini na nne. Kwa hivyo, karibu funguo zote ambazo tulikuwa nazo, karibu URL zote sasa zinaishi kwenye seva zingine. Akiba nzima ilibatilishwa kwa muda mfupi tu. Maombi yote yalianguka kwenye nguzo yetu ya hifadhi, ikawa mbaya, kushindwa kwa huduma na watumiaji wasioridhika. Sitaki kufanya hivyo.
Chaguo hili pia halitufai.
Hiyo. tunapaswa kufanya nini? Ni lazima kwa namna fulani tutumie akiba kwa njia ifaayo, tuweke ombi lile lile kwenye seva hiyo hiyo tena na tena, lakini tuwe sugu kwa kushiriki upya. Na kuna suluhisho kama hilo, sio ngumu sana. Inaitwa hashing thabiti.
Je, inaonekana kama nini?
Tunachukua kazi fulani kutoka kwa ufunguo wa kugawanya na kueneza maadili yake yote kwenye mduara. Wale. katika hatua ya 0, maadili yake ya chini na ya juu huungana. Ifuatayo, tunaweka seva zetu zote kwenye duara moja kwa takriban njia hii:
Kila seva inafafanuliwa na nukta moja, na sekta inayoenda kwa saa moja kwa moja, ipasavyo, inahudumiwa na mwenyeji huyu. Wakati maombi yanatujia, tunaona mara moja kwamba, kwa mfano, ombi A - ina hashi pale - na inatumiwa na seva 2. Ombi B - kwa seva 3. Na kadhalika.
Ni nini hufanyika katika hali hii wakati wa kushiriki tena?
Hatubatilishi kashe nzima, kama hapo awali, na hatubadilishi funguo zote, lakini tunabadilisha kila sekta kwa umbali mfupi ili, kwa kusema, seva yetu ya sita, ambayo tunataka kuongeza, inafaa kwenye nafasi ya bure, na. tunaongeza hapo.
Kwa kweli, katika hali kama hiyo funguo pia hutoka. Lakini wanatoka dhaifu sana kuliko hapo awali. Na tunaona kwamba funguo zetu mbili za kwanza zilibaki kwenye seva zao, na seva ya caching ilibadilika tu kwa ufunguo wa mwisho. Hii inafanya kazi kwa ufanisi kabisa, na ikiwa unaongeza wapangishi wapya kwa kuongezeka, basi hakuna shida kubwa hapa. Unaongeza na kuongeza kidogo kwa wakati, kusubiri hadi cache imejaa tena, na kila kitu kinafanya kazi vizuri.
Swali pekee linabaki na kukataa. Hebu tuchukulie kwamba aina fulani ya gari ni nje ya utaratibu.
Na hatungetaka kuunda upya ramani hii kwa wakati huu, kubatilisha sehemu ya kache, na kadhalika, ikiwa, kwa mfano, mashine iliwashwa tena, na tunahitaji kwa namna fulani maombi ya huduma. Tunaweka akiba moja ya picha kwenye kila tovuti, ambayo hufanya kama mbadala wa mashine yoyote ambayo iko chini kwa sasa. Na ikiwa ghafla moja ya seva zetu haipatikani, trafiki huenda huko. Kwa kawaida, hatuna cache yoyote huko, i.e. ni baridi, lakini angalau maombi ya mtumiaji yanashughulikiwa. Ikiwa hii ni muda mfupi, basi tunaipata kwa utulivu kabisa. Kuna mzigo zaidi kwenye hifadhi. Ikiwa muda huu ni mrefu, basi tunaweza tayari kufanya uamuzi - kuondoa seva hii kutoka kwenye ramani au la, au labda kuibadilisha na nyingine.
Hii ni kuhusu mfumo wa caching. Hebu tuangalie matokeo.
Inaweza kuonekana kuwa hakuna kitu ngumu hapa. Lakini njia hii ya kudhibiti kache ilitupa kiwango cha hila cha karibu 98%. Wale. kati ya maombi haya elfu 80 kwa sekunde, 1600 tu hufikia uhifadhi, na huu ni mzigo wa kawaida kabisa, wanavumilia kwa utulivu, tunayo hifadhi kila wakati.
Tuliweka seva hizi katika DCs zetu tatu, na tukapokea alama tatu za uwepo - Prague, Miami na Hong Kong.
Hiyo. zinapatikana ndani au chini kwa kila moja ya soko letu tunalolenga.
Na kama bonasi nzuri, tulipata proksi hii ya uakibishaji, ambayo CPU haifanyi kazi, kwa sababu haihitajiki sana kutoa yaliyomo. Na huko, kwa kutumia NGINX+ Lua, tulitekeleza mantiki nyingi za matumizi.
Kwa mfano, tunaweza kufanya majaribio ya webp au jpeg inayoendelea (hizi ni miundo ya kisasa inayofaa), kuona jinsi inavyoathiri trafiki, kufanya maamuzi fulani, kuiwezesha kwa nchi fulani, n.k.; tengeneza ukubwa unaobadilika au upunguze picha kwa kuruka.
Hii ni kesi nzuri wakati, kwa mfano, una programu ya rununu inayoonyesha picha, na programu ya rununu haitaki kupoteza CPU ya mteja kwa kuomba picha kubwa na kuibadilisha kwa saizi fulani ili kuisukuma ndani. mtazamo. Tunaweza kubainisha kwa urahisi baadhi ya vigezo katika URL ya masharti ya UPort, na akiba ya picha itabadilisha ukubwa wa picha yenyewe. Kama sheria, itachagua saizi ambayo tunayo kwenye diski, karibu iwezekanavyo na ile iliyoombwa, na kuiuza kwa kuratibu maalum.
Kwa njia, tumetoa rekodi za video zinazopatikana kwa umma za miaka mitano iliyopita ya mkutano wa wasanidi wa mifumo ya upakiaji wa juu. . Tazama, jifunze, shiriki na ujiandikishe .
Tunaweza pia kuongeza mantiki nyingi za bidhaa huko. Kwa mfano, tunaweza kuongeza alama tofauti kwa kutumia vigezo vya URL, tunaweza kutia ukungu, kutia ukungu au picha za pixelate. Huu ndio wakati tunataka kuonyesha picha ya mtu, lakini hatutaki kuonyesha uso wake, hii inafanya kazi vizuri, yote yanatekelezwa hapa.
Tulipata nini? Tulipata alama tatu za uwepo, kiwango kizuri cha ujanja, na wakati huo huo hatuna CPU isiyofanya kazi kwenye mashine hizi. Sasa amekuwa, bila shaka, muhimu zaidi kuliko hapo awali. Tunahitaji kujipa magari yenye nguvu zaidi, lakini inafaa.
Hii inahusu kurudi kwa picha. Kila kitu hapa ni wazi kabisa na dhahiri. Nadhani sikugundua Amerika, karibu CDN yoyote inafanya kazi kwa njia hii.
Na, uwezekano mkubwa, msikilizaji wa kisasa anaweza kuwa na swali: kwa nini usibadili tu kila kitu kwa CDN? Ingekuwa sawa; CDN zote za kisasa zinaweza kufanya hivi. Na kuna sababu kadhaa.
Ya kwanza ni picha.
Hii ni mojawapo ya vipengele muhimu vya miundombinu yetu, na tunahitaji udhibiti mkubwa iwezekanavyo. Ikiwa hii ni aina fulani ya suluhisho kutoka kwa muuzaji wa mtu wa tatu, na huna nguvu yoyote juu yake, itakuwa ngumu kwako kuishi nayo wakati una hifadhidata kubwa, na unapokuwa na mtiririko mkubwa sana. ya maombi ya mtumiaji.
Ngoja nikupe mfano. Sasa, na miundombinu yetu, tunaweza, kwa mfano, katika kesi ya matatizo fulani au chini ya ardhi kugonga, kwenda kwa mashine na fujo kuzunguka huko, kiasi kusema. Tunaweza kuongeza mkusanyiko wa baadhi ya vipimo ambavyo tunahitaji tu, tunaweza kujaribu kwa namna fulani, kuona jinsi hii inavyoathiri grafu, na kadhalika. Sasa takwimu nyingi zinakusanywa kwenye nguzo hii ya kache. Na mara kwa mara tunaiangalia na kutumia muda mrefu kuchunguza kasoro kadhaa. Ikiwa ilikuwa upande wa CDN, itakuwa ngumu zaidi kudhibiti. Au, kwa mfano, ikiwa aina fulani ya ajali hutokea, tunajua kilichotokea, tunajua jinsi ya kuishi nayo na jinsi ya kuondokana nayo. Hili ni hitimisho la kwanza.
Hitimisho la pili pia ni la kihistoria, kwa sababu mfumo umekuwa ukiendelezwa kwa muda mrefu, na kulikuwa na mahitaji mengi ya biashara katika hatua tofauti, na haziingii katika dhana ya CDN.
Na hatua inayofuata kutoka kwa uliopita ni
Hii ni kwa sababu kwenye kache za picha tunayo mantiki nyingi maalum, ambayo haiwezi kuongezwa kila mara unapoomba. Haiwezekani kwamba CDN yoyote itakuongezea baadhi ya vitu maalum kwa ombi lako. Kwa mfano, kusimba URLs ikiwa hutaki mteja aweze kubadilisha kitu. Je, ungependa kubadilisha URL kwenye seva na kuisimba kwa njia fiche, kisha utume baadhi ya vigezo vinavyobadilika hapa.
Je, hii inapendekeza nini? Kwa upande wetu, CDN sio mbadala nzuri sana.
Na kwa upande wako, ikiwa una mahitaji maalum ya biashara, basi unaweza kutekeleza kwa urahisi kile nilichokuonyesha mwenyewe. Na hii itafanya kazi kikamilifu na wasifu sawa wa mzigo.
Lakini ikiwa una aina fulani ya ufumbuzi wa jumla, na kazi sio maalum sana, unaweza kabisa kuchukua CDN kwa usalama. Au ikiwa wakati na rasilimali ni muhimu zaidi kwako kuliko udhibiti.
Na CDN za kisasa zina karibu kila kitu nilichokuambia sasa. Isipokuwa kuongeza au kuondoa baadhi ya vipengele.
Hii ni kuhusu kutoa picha.
Hebu sasa tusogee mbele kidogo katika tafakari yetu ya nyuma na tuzungumze kuhusu kuhifadhi.
2013 ilikuwa inapita.
Seva za akiba ziliongezwa, matatizo ya utendaji yalikwenda mbali. Kila kitu kiko sawa. Seti ya data inaongezeka. Kufikia mwaka wa 2013, tulikuwa na takriban seva 80 zilizounganishwa kwenye hifadhi, na zile zipatazo 40 za akiba katika kila DC. Hii ni terabytes 560 za data kwenye kila DC, i.e. kuhusu petabyte kwa jumla.
Na kwa ukuaji wa hifadhidata, gharama za uendeshaji zilianza kupanda sana. Hii ilimaanisha nini?
Katika mchoro huu unaotolewa - na SAN, na mashine na cache zilizounganishwa nayo - kuna pointi nyingi za kushindwa. Ikiwa tulikuwa tayari kushughulikiwa na kushindwa kwa seva za caching kabla, kila kitu kilikuwa zaidi au chini ya kutabirika na kueleweka, lakini kwa upande wa kuhifadhi kila kitu kilikuwa kibaya zaidi.
Kwanza, Mtandao wa Eneo la Hifadhi (SAN) yenyewe, ambayo inaweza kushindwa.
Pili, imeunganishwa kupitia optics kwa mashine za mwisho. Kunaweza kuwa na matatizo na kadi za macho na plugs za cheche.
Kwa kweli, hakuna wengi wao kama na SAN yenyewe, lakini, hata hivyo, hizi pia ni alama za kutofaulu.
Ifuatayo ni mashine yenyewe, ambayo imeunganishwa na hifadhi. Inaweza pia kushindwa.
Kwa jumla, tuna pointi tatu za kushindwa.
Zaidi ya hayo, pamoja na pointi za kushindwa, kuna matengenezo makubwa ya hifadhi yenyewe.
Huu ni mfumo mgumu wa vipengele vingi, na wahandisi wa mifumo wanaweza kuwa na wakati mgumu wa kufanya kazi nao.
Na hatua ya mwisho, muhimu zaidi. Ikiwa kushindwa kutatokea katika mojawapo ya pointi hizi tatu, tuna nafasi isiyo ya sifuri ya kupoteza data ya mtumiaji kwa sababu mfumo wa faili unaweza kuacha kufanya kazi.
Wacha tuseme mfumo wetu wa faili umevunjwa. Kwanza, urejesho wake unachukua muda mrefu - inaweza kuchukua wiki na kiasi kikubwa cha data. Na pili, mwishowe tunaweza kuishia na rundo la faili zisizoeleweka ambazo zitahitaji kuunganishwa kwa njia fulani kuwa picha za watumiaji. Na tunahatarisha kupoteza data. Hatari ni kubwa sana. Na mara nyingi hali kama hizi zinatokea, na shida zaidi zinatokea katika mlolongo huu wote, hatari hii inaongezeka.
Jambo fulani lilipaswa kufanywa kuhusu hili. Na tuliamua kwamba tunahitaji tu kuhifadhi nakala ya data. Kwa kweli hii ni suluhisho dhahiri na nzuri. Tumefanya nini?
Hivi ndivyo seva yetu ilionekana wakati iliunganishwa kwenye hifadhi hapo awali. Hii ni sehemu moja kuu, ni kifaa cha kuzuia tu ambacho kinawakilisha mlima kwa hifadhi ya mbali kupitia optics.
Tumeongeza sehemu ya pili.
Tuliweka hifadhi ya pili karibu nayo (kwa bahati nzuri, sio ghali sana kwa suala la pesa), na tukaiita kizigeu cha chelezo. Pia imeunganishwa kupitia optics na iko kwenye mashine moja. Lakini tunahitaji kwa namna fulani kusawazisha data kati yao.
Hapa tunatengeneza foleni isiyolingana karibu.
Yeye si busy sana. Tunajua hatuna rekodi za kutosha. Foleni ni jedwali katika MySQL ambapo mistari kama vile "unahitaji kuhifadhi nakala ya picha hii" huandikwa. Kwa mabadiliko yoyote au upakiaji, tunakili kutoka kwa kizigeu kikuu hadi chelezo kwa kutumia kisawazisha au aina fulani tu ya mfanyakazi wa usuli.
Na kwa hivyo kila wakati tuna sehemu mbili thabiti. Hata kama sehemu moja ya mfumo huu itashindwa, tunaweza kubadilisha kizigeu kikuu kila wakati na chelezo, na kila kitu kitaendelea kufanya kazi.
Lakini kwa sababu ya hili, mzigo wa kusoma huongezeka sana, kwa sababu ... kwa kuongeza wateja ambao walisoma kutoka sehemu kuu, kwa sababu wanaangalia kwanza picha hapo (ni hivi karibuni zaidi), na kisha utafute kwenye nakala rudufu, ikiwa hawajaipata (lakini NGINX hufanya hivi tu), mfumo wetu pia ni pamoja na chelezo sasa inasomwa kutoka kwa kizigeu kikuu. Sio kwamba hii ilikuwa kizuizi, lakini sikutaka kuongeza mzigo, kimsingi, kama hivyo.
Na tuliongeza diski ya tatu, ambayo ni SSD ndogo, na kuiita buffer.
Jinsi inavyofanya kazi sasa.
Mtumiaji anapakia picha kwenye bafa, kisha tukio hutupwa kwenye foleni kuonyesha kwamba linahitaji kunakiliwa katika sehemu mbili. Imenakiliwa, na picha huishi kwenye bafa kwa muda (sema, siku), na kisha tu husafishwa kutoka hapo. Hii inaboresha sana uzoefu wa mtumiaji, kwa sababu mtumiaji hupakia picha, kama sheria, maombi huanza mara moja kufuata, au yeye mwenyewe alisasisha ukurasa na kuuburudisha. Lakini yote inategemea programu ambayo hufanya upakiaji.
Au, kwa mfano, watu wengine ambao alianza kujionyesha mara moja hutuma maombi baada ya picha hii. Bado haipo kwenye kashe; ombi la kwanza hutokea haraka sana. Kimsingi ni sawa na kutoka kwa akiba ya picha. Hifadhi ya polepole haihusiki katika hili hata kidogo. Na siku moja baadaye inaposafishwa, tayari imehifadhiwa kwenye safu yetu ya caching, au, uwezekano mkubwa, hakuna mtu anayehitaji tena. Wale. Uzoefu wa watumiaji hapa umekua vizuri sana kwa sababu ya ujanja rahisi kama huo.
Kweli, na muhimu zaidi: tuliacha kupoteza data.
Wacha tuseme tuliacha uwezekano kupoteza data, kwa sababu hatukuipoteza. Lakini kulikuwa na hatari. Tunaona kwamba suluhisho hili ni zuri, lakini ni sawa na kulainisha dalili za tatizo badala ya kulitatua kabisa. Na shida zingine zinabaki hapa.
Kwanza, hii ni hatua ya kutofaulu katika mfumo wa mwenyeji wa mwili yenyewe ambayo mashine hii yote inaendesha; haijaondoka.
Pili, bado kuna shida na SAN, matengenezo yao mazito, nk. Haikuwa kwamba ilikuwa sababu muhimu, lakini nilitaka kujaribu kwa namna fulani kuishi bila hiyo.
Na tulifanya toleo la tatu (kwa kweli, la pili kwa kweli) - toleo la uhifadhi. Ilionekanaje?
Hivi ndivyo ilivyokuwa -
Shida zetu kuu ni ukweli kwamba huyu ni mwenyeji wa mwili.
Kwanza, tunaondoa SAN kwa sababu tunataka kujaribu, tunataka kujaribu diski kuu za ndani pekee.
Hii tayari ni 2014-2015, na wakati huo hali na disks na uwezo wao katika jeshi moja ikawa bora zaidi. Tuliamua kwa nini tusijaribu.
Na kisha tunachukua tu kizigeu chetu cha chelezo na kuihamisha kwa mashine tofauti.
Kwa hivyo, tunapata mchoro huu. Tuna magari mawili ambayo huhifadhi hifadhidata sawa. Wanahifadhi nakala rudufu kabisa na kusawazisha data kwenye mtandao kupitia foleni isiyolingana katika MySQL sawa.
Kwa nini hii inafanya kazi vizuri ni kwa sababu tuna rekodi chache. Wale. ikiwa uandishi ungelinganishwa na kusoma, labda tungekuwa na aina fulani ya mtandao na matatizo. Kuna uandishi mdogo, kusoma sana - njia hii inafanya kazi vizuri, i.e. Sisi mara chache tunakili picha kati ya seva hizi mbili.
Hii inafanyaje kazi, ikiwa unatazama kidogo zaidi kwa undani.
Pakia. Msawazishaji huchagua seva pangishi nasibu na jozi na kupakiwa kwake. Wakati huo huo, kwa kawaida anafanya ukaguzi wa afya na anahakikisha kuwa gari haliingii. Wale. anapakia picha tu kwa seva ya moja kwa moja, na kisha kupitia foleni isiyosawazisha yote inanakiliwa kwa jirani yake. Kwa kupakia kila kitu ni rahisi sana.
Kazi ni ngumu zaidi kidogo.
Lua alitusaidia hapa, kwa sababu inaweza kuwa ngumu kufanya mantiki kama hiyo kwenye vanilla NGINX. Kwanza tunatoa ombi kwa seva ya kwanza, angalia ikiwa picha iko, kwa sababu inaweza kupakiwa, kwa mfano, kwa jirani, lakini bado haijafika hapa. Ikiwa picha iko, hiyo ni nzuri. Mara moja tunampa mteja na, ikiwezekana, kache.
Ikiwa haipo, tunatuma ombi kwa jirani yetu na tumehakikishiwa kulipokea kutoka hapo.
Hiyo. tena tunaweza kusema: kunaweza kuwa na matatizo na utendaji, kwa sababu kuna safari za mara kwa mara za pande zote - picha ilipakiwa, sio hapa, tunafanya maombi mawili badala ya moja, hii inapaswa kufanya kazi polepole.
Katika hali yetu, hii haifanyi kazi polepole.
Tunakusanya rundo la vipimo kwenye mfumo huu, na kiwango cha mahiri cha masharti cha utaratibu kama huu ni takriban 95%. Wale. Bakia ya chelezo hii ni ndogo, na kwa sababu ya hii tumehakikishiwa karibu, baada ya picha kupakiwa, tutaichukua mara ya kwanza na hatutalazimika kwenda popote mara mbili.
Kwa hivyo tuna nini kingine ambacho ni nzuri sana?
Hapo awali, tulikuwa na kizigeu kikuu cha chelezo, na tulisoma kutoka kwao kwa mlolongo. Wale. Tulitafuta kila wakati kwenye kuu kwanza, na kisha kwenye nakala rudufu. Ilikuwa ni hatua moja.
Sasa tunatumia usomaji kutoka kwa mashine mbili mara moja. Tunasambaza maombi kwa kutumia Round Robin. Katika asilimia ndogo ya kesi tunafanya maombi mawili. Lakini kwa ujumla, sasa tuna hisa mara mbili ya kusoma kuliko tulivyokuwa hapo awali. Na mzigo ulipunguzwa sana wote kwenye mashine za kutuma na moja kwa moja kwenye mashine za kuhifadhi, ambazo pia tulikuwa nazo wakati huo.
Kuhusu uvumilivu wa makosa. Kwa kweli, hii ndiyo hasa tulipigania. Kwa uvumilivu wa makosa, kila kitu kiligeuka kuwa nzuri hapa.
Gari moja linaharibika.
Hakuna shida! Mhandisi wa mfumo hawezi hata kuamka usiku, atasubiri hadi asubuhi, hakuna kitu kibaya kitatokea.
Ikiwa hata mashine hii itashindwa, foleni iko nje ya utaratibu, hakuna shida pia, logi itakusanywa tu kwenye mashine ya kuishi, na kisha itaongezwa kwenye foleni, na kisha kwenye gari ambalo litafanya. kuanza kufanya kazi baada ya muda fulani.
Kitu sawa na matengenezo. Tunazima moja ya mashine, kuiondoa kwa mikono kutoka kwa mabwawa yote, inaacha kupokea trafiki, tunafanya aina fulani ya matengenezo, tunahariri kitu, kisha tunairudisha kwa huduma, na nakala rudufu hii hupatikana haraka sana. Wale. kwa siku, muda wa chini wa gari moja hupatikana ndani ya dakika kadhaa. Hii ni kweli kidogo sana. Kwa uvumilivu wa makosa, nasema tena, kila kitu ni baridi hapa.
Je, ni hitimisho gani linaweza kutolewa kutokana na mpango huu wa kupunguzwa kazi?
Tulipata uvumilivu wa makosa.
Rahisi kutumia. Kwa kuwa mashine zina anatoa ngumu za ndani, hii ni rahisi zaidi kutoka kwa mtazamo wa kufanya kazi kwa wahandisi wanaofanya kazi nayo.
Tulipokea posho ya kusoma mara mbili.
Hii ni bonus nzuri sana kwa kuongeza uvumilivu wa makosa.
Lakini pia kuna matatizo. Sasa tunayo maendeleo magumu zaidi ya baadhi ya vipengele vinavyohusiana na hili, kwa sababu mfumo umekuwa 100% hatimaye thabiti.
Lazima, tuseme, katika kazi fulani ya nyuma, tufikirie kila wakati: "Tunaendesha seva gani sasa?", "Je! kweli kuna picha ya sasa hapa?" na kadhalika. Hii, bila shaka, yote imefungwa, na kwa programu ambaye anaandika mantiki ya biashara, ni wazi. Lakini, hata hivyo, safu hii kubwa tata imeonekana. Lakini tuko tayari kustahimili hili kwa kubadilishana na mambo mazuri tuliyopokea kutoka kwayo.
Na hapa tena migogoro kadhaa inatokea.
Nilisema mwanzoni kwamba kuhifadhi kila kitu kwenye anatoa ngumu za ndani ni mbaya. Na sasa nasema kwamba tuliipenda.
Ndiyo, kwa kweli, baada ya muda hali imebadilika sana, na sasa njia hii ina faida nyingi. Kwanza, tunapata operesheni rahisi zaidi.
Pili, inazalisha zaidi, kwa sababu hatuna vidhibiti hivi vya kiotomatiki au viunganisho kwenye rafu za diski.
Kuna idadi kubwa ya mashine huko, na hizi ni diski chache tu ambazo zimekusanywa hapa kwenye mashine kwenye uvamizi.
Lakini pia kuna hasara.
Hii ni takriban mara 1,5 ghali zaidi kuliko kutumia SANs hata kwa bei za leo. Kwa hiyo, tuliamua kutobadilisha kwa ujasiri kundi letu kubwa lote kwenye magari yenye anatoa ngumu za ndani na tukaamua kuacha suluhisho la mseto.
Nusu ya mashine zetu hufanya kazi na anatoa ngumu (vizuri, si nusu - labda asilimia 30). Na mengine ni magari ya zamani ambayo yalikuwa na mpango wa kwanza wa kuhifadhi. Tuliziweka tena, kwa kuwa hatukuhitaji data mpya au kitu kingine chochote, tulihamisha tu vipandikizi kutoka kwa seva pangishi moja hadi mbili.
Na sasa tuna hisa kubwa ya kusoma, na tuliipanua. Ikiwa mapema tuliweka hifadhi moja kwenye mashine moja, sasa tunapanda nne, kwa mfano, kwenye jozi moja. Na inafanya kazi vizuri.
Hebu tuchukue muhtasari mfupi wa kile tulichokamilisha, kile tulichopigania, na ikiwa tulifanikiwa.
Matokeo ya
Tuna watumiaji - kama milioni 33.
Tuna pointi tatu za uwepo - Prague, Miami, Hong Kong.
Zina safu ya caching, ambayo inajumuisha magari yenye disks za haraka za ndani (SSDs), ambayo mashine rahisi kutoka kwa NGINX, access.log yake na daemons za Python huendesha, ambayo hushughulikia haya yote na kusimamia cache.
Ukipenda, uko kwenye mradi wako, ikiwa picha sio muhimu kwako kama zilivyo kwetu, au ikiwa udhibiti wa biashara dhidi ya kasi ya maendeleo na gharama za rasilimali ziko upande mwingine kwako, basi unaweza kuzibadilisha kwa usalama. na CDN, CDN za kisasa wanafanya vizuri.
Inayofuata inakuja safu ya uhifadhi, ambayo tuna vikundi vya jozi za mashine ambazo zinahifadhi nakala, faili zinakiliwa kwa usawa kutoka kwa moja hadi nyingine kila zinapobadilika.
Kwa kuongezea, baadhi ya mashine hizi hufanya kazi na anatoa ngumu za ndani.
Baadhi ya mashine hizi zimeunganishwa kwa SANs.
Na, kwa upande mmoja, ni rahisi zaidi kutumia na kuzalisha zaidi kidogo, kwa upande mwingine, ni rahisi kwa suala la wiani wa uwekaji na bei kwa gigabyte.
Huu ni muhtasari mfupi wa usanifu wa kile tulichopata na jinsi yote yalivyokua.
Vidokezo vichache zaidi kutoka kwa nahodha, rahisi sana.
Kwanza, ikiwa unaamua ghafla kwamba unahitaji haraka kuboresha kila kitu katika miundombinu yako ya picha, pima kwanza, kwa sababu labda hakuna kitu kinachohitaji kuboreshwa.
Ngoja nikupe mfano. Tuna kundi la mashine zinazotuma picha kutoka kwa viambatisho kwenye gumzo, na mpango huo umekuwa ukifanya kazi huko tangu 2009, na hakuna anayeugua. Kila mtu yuko sawa, kila mtu anapenda kila kitu.
Ili kupima, kwanza hutegemea rundo la vipimo, viangalie, na kisha uamue kile ambacho huna furaha nacho na kile kinachohitaji kuboreshwa. Ili kupima hii, tuna zana nzuri inayoitwa Pinba.
Inakuruhusu kukusanya takwimu za kina sana kutoka kwa NGINX kwa kila ombi na misimbo ya majibu, na usambazaji wa nyakati - chochote unachotaka. Ina vifungo kwa kila aina ya mifumo tofauti ya uchambuzi, na kisha unaweza kuiangalia kwa uzuri.
Kwanza tuliipima, kisha tukaiboresha.
Zaidi. Tunaboresha usomaji na kashe, tukiandika kwa kugawa, lakini hii ni hoja dhahiri.
Zaidi. Ikiwa ndio sasa unaanza kuunda mfumo wako, basi ni bora zaidi kufanya picha kama faili zisizoweza kubadilika. Kwa sababu mara moja unapoteza darasa zima la matatizo na uhalali wa cache, na jinsi mantiki inapaswa kupata toleo sahihi la picha, na kadhalika.
Hebu tuseme ulipakia mia, kisha ukaizungusha, uifanye kuwa faili tofauti kimwili. Wale. hakuna haja ya kufikiri: sasa nitahifadhi nafasi kidogo, kuandika kwa faili sawa, kubadilisha toleo. Hii daima haifanyi kazi vizuri na husababisha maumivu ya kichwa mengi baadaye.
Hatua inayofuata. Kuhusu resize juu ya kuruka.
Hapo awali, wakati watumiaji walipakia picha, mara moja tulikata kundi zima la ukubwa kwa matukio yote, kwa wateja tofauti, na wote walikuwa kwenye diski. Sasa tumeacha hii.
Tuliacha saizi kuu tatu tu: ndogo, za kati na kubwa. Tunapunguza tu kila kitu kingine kutoka kwa saizi iliyo nyuma ya ile tuliyoombwa huko Uport, tunafanya tu kiwango cha chini na kumpa mtumiaji.
CPU ya safu ya kache hapa inageuka kuwa ya bei nafuu zaidi kuliko ikiwa tulifanya upya saizi hizi kila mara kwenye kila hifadhi. Wacha tuseme tunataka kuongeza mpya, hii itachukua mwezi - endesha hati kila mahali ambayo ingefanya haya yote kwa uzuri, bila kuharibu nguzo. Wale. Ikiwa una fursa ya kuchagua sasa, ni bora kufanya ukubwa mdogo wa kimwili iwezekanavyo, lakini ili angalau usambazaji fulani ni, sema, tatu. Na kila kitu kingine kinaweza kubadilishwa kwa urahisi kwenye kuruka kwa kutumia moduli zilizotengenezwa tayari. Yote ni rahisi sana na yanapatikana sasa.
Na nakala rudufu ya asynchronous ni nzuri.
Kama mazoezi yetu yameonyesha, mpango huu hufanya kazi vizuri kwa kuchelewesha kunakili faili zilizobadilishwa.
Hoja ya mwisho pia ni dhahiri. Ikiwa miundombinu yako haina shida kama hizo sasa, lakini kuna kitu ambacho kinaweza kuvunja, hakika kitavunjika wakati kitakuwa kidogo zaidi. Kwa hivyo, ni bora kufikiria juu ya hili mapema na sio kupata shida nayo. Hiyo ndiyo yote nilitaka kusema.
mawasiliano
Β»
Β»
Ripoti hii ni nakala ya mojawapo ya hotuba bora zaidi katika kongamano la wasanidi wa mifumo yenye mzigo mkubwa . Imesalia chini ya mwezi mmoja kabla ya kongamano la HighLoad++ 2017.
Tayari tunayo tayari , ratiba sasa inaundwa kikamilifu.
Mwaka huu tunaendelea kuchunguza mada ya usanifu na kuongeza:
- / Igor Vasiliev
- / Dmitry Egorov
- / Anatoly Plaskovsky
- / Roman Shekhovtsov, Alexey Gromatchikov
- / Philip Delgado
Pia tunatumia baadhi ya nyenzo hizi katika kozi yetu ya mtandaoni ya kutengeneza mifumo yenye mzigo mkubwa ni mlolongo wa barua zilizochaguliwa maalum, makala, nyenzo, video. Kitabu chetu cha kiada tayari kina zaidi ya nyenzo 30 za kipekee. Unganisha!
Chanzo: mapenzi.com