Артем Денисов ( , )
Бадоо је највећи светски сајт за упознавање. Тренутно имамо око 330 милиона регистрованих корисника широм света. Али оно што је много важније у контексту нашег данашњег разговора јесте да чувамо око 3 петабајта корисничких фотографија. Сваког дана наши корисници постављају око 3,5 милиона нових фотографија, а оптерећење читања је отприлике 80 хиљада захтева у секунди. Ово је доста за наш бацкенд, а понекад има потешкоћа са овим.
Говорићу о дизајну овог система, који складишти и шаље фотографије уопштено, и погледаћу га са тачке гледишта програмера. Биће кратка ретроспектива о томе како се развијао, где ћу изнети главне прекретнице, али ћу само детаљније говорити о решењима која тренутно користимо.
Сада да почнемо.
Као што рекох, ово ће бити ретроспектива, а да бисмо је негде започели, узмимо најчешћи пример.
Имамо заједнички задатак, треба да прихватимо, чувамо и шаљемо корисничке фотографије. У овом облику, задатак је општи, можемо користити било шта:
- модерно складиште у облаку,
- решење у кутији, којих сада такође има много;
- Можемо поставити неколико машина у наш дата центар и ставити велике чврсте дискове на њих и тамо чувати фотографије.
Бадоо историјски – и сада и тада (у време када је био тек у повојима) – живи на сопственим серверима, унутар наших ДЦ-ова. Стога је ова опција била оптимална за нас.
Управо смо узели неколико машина, назвали их „фотографије“ и добили смо кластер који чува фотографије. Али изгледа да нешто недостаје. Да би све ово функционисало, треба некако да одредимо на којој машини ћемо које фотографије чувати. И овде, такође, не треба отварати Америку.
Додамо неко поље у наше складиште са информацијама о корисницима. Ово ће бити кључ за шардирање. У нашем случају смо га назвали плаце_ид, а овај ид места указује на место где се чувају фотографије корисника. Правимо карте.
У првој фази, то се чак може урадити и ручно - кажемо да ће фотографија овог корисника са таквим местом слетети на такав сервер. Захваљујући овој мапи, увек знамо када корисник постави фотографију, где да је сачува и знамо одакле да је дамо.
Ово је апсолутно тривијална шема, али има прилично значајне предности. Први је да је једноставан, као што сам рекао, а други је да са овим приступом можемо лако хоризонтално скалирати једноставним испоруком нових аутомобила и додавањем на мапу. Не морате ништа друго да радите.
Тако нам је било неко време.
Ово је било око 2009. Испоручили су аутомобиле, испоручили...
И у неком тренутку смо почели да примећујемо да ова шема има одређене недостатке. Који су недостаци?
Пре свега, постоји ограничен капацитет. Не можемо да нагурамо онолико чврстих дискова на један физички сервер колико бисмо желели. И ово је постало одређени проблем током времена и са растом скупа података.
И друго. Ово је нетипична конфигурација машина, јер је такве машине тешко поново користити у неким другим кластерима, прилично су специфичне, тј. требало би да имају слабе перформансе, али у исто време са великим чврстим диском.
Све је то било за 2009. годину, али, у принципу, ови захтеви су и данас актуелни. Имамо ретроспективу, па је 2009. године са овим све било потпуно лоше.
И последња тачка је цена.
Цена је у то време била веома висока и морали смо да тражимо неке алтернативе. Оне. требало је да некако боље искористимо и простор у дата центрима и физичке сервере на којима се све ово налази. Наши системски инжењери започели су велику студију у којој су прегледали гомилу различитих опција. Такође су разматрали кластеризоване системе датотека као што су ПолиЦепх и Лустер. Било је проблема са перформансама и прилично тешког рада. Одбили су. Покушали смо да монтирамо цео скуп података преко НФС-а на сваки аутомобил како бисмо га некако повећали. Читање је такође прошло лоше, испробали смо различита решења различитих произвођача.
И на крају смо се одлучили за коришћење такозване Стораге Ареа Нетворк.
Ово су велики СХД дискови који су посебно дизајнирани за складиштење великих количина података. То су полице са дисковима који се монтирају на машине за финални оптички излаз. То. имамо некакав скуп машина, прилично мали, и ови СХД-ови, који су транспарентни за нашу логику слања, тј. да би наш нгинк или било ко други испунио захтеве за ове фотографије.
Ова одлука је имала очигледне предности. Ово је СХД. Намењен је чувању фотографија. Ово је јефтиније од једноставног опремања машина чврстим дисковима.
Други плус.
То је да је капацитет постао много већи, тј. можемо да сместимо много више простора за складиштење у много мањој запремини.
Али било је и недостатака који су се појавили прилично брзо. Како су број корисника и оптерећење на овом систему расли, почели су да се јављају проблеми са перформансама. А проблем је овде сасвим очигледан - сваки СХД дизајниран за складиштење много фотографија у малом обиму, по правилу, пати од интензивног читања. Ово заправо важи за било које складиште у облаку или било шта друго. Сада немамо идеално складиште које би било бесконачно скалабилно, у њега бисте могли да убаците било шта и одлично би толерисало читање. Нарочито обична читања.
Као што је случај са нашим фотографијама, јер се фотографије траже недоследно, а то ће у великој мери утицати на њихов учинак.
Чак и према данашњим бројкама, ако добијемо негде више од 500 РПС за фотографије на машини на коју је повезано складиште, проблеми већ почињу. И било нам је довољно лоше, јер број корисника расте, ствари ће се само погоршавати. Ово треба некако оптимизовати.
Да бисмо оптимизовали, одлучили смо тада, очигледно, да погледамо профил оптерећења - шта се, уопште, дешава, шта треба оптимизовати.
И овде нам све иде на руку.
Већ сам рекао на првом слајду: имамо 80 хиљада захтева за читање у секунди са само 3,5 милиона отпремања дневно. То јест, ово је разлика од три реда величине. Очигледно је да читање треба оптимизовати и практично је јасно како.
Постоји још једна мала тачка. Специфичности услуге су такве да се особа региструје, поставља фотографију, затим почиње да активно гледа друге људе, лајкује их и активно се показује другим људима. Онда нађе партнера или не нађе партнера, зависи како ће испасти, и престане да користи услугу на неко време. У овом тренутку, када га користи, његове фотографије су веома вруће - тражене су, много људи их гледа. Чим престане то да ради, прилично брзо престаје да буде толико изложен другим људима као што је био раније, а његове фотографије се готово никада не траже.
Оне. Имамо веома мали скуп врућих података. Али у исто време има много захтева за њега. И потпуно очигледно решење овде је додавање кеша.
Кеш меморија са ЛРУ ће решити све наше проблеме. Шта ми радимо?
Додамо још један релативно мали испред нашег великог кластера са складиштем, који се зове фотокеш. Ово је у суштини само проки за кеширање.
Како то функционише изнутра? Овде је наш корисник, овде је складиште. Све је исто као и пре. Шта додајемо између?
То је само машина са физичким локалним диском, који је брз. Ово је са ССД-ом, на пример. И нека врста локалне кеш меморије се чува на овом диску.
Како то изгледа? Корисник шаље захтев за фотографију. НГИНКС га прво тражи у локалном кешу. Ако не, онда једноставно проки_пасс у наше складиште, преузмите фотографију одатле и дајте је кориснику.
Али овај је врло баналан и нејасно је шта се дешава унутра. Ради отприлике овако.
Кеш меморија је логично подељена на три слоја. Када кажем „три слоја“, то не значи да постоји нека врста сложеног система. Не, ово су условно само три директоријума у систему датотека:
- Ово је бафер у који иду фотографије које су управо преузете са проксија.
- Ово је врућа кеш меморија која чува тренутно активно тражене фотографије.
- И хладни кеш, где се фотографије постепено истискују из вруће кеш меморије када им стигне мање захтева.
Да би ово функционисало, морамо некако да управљамо овим кешом, морамо да преуредимо фотографије у њему итд. Ово је такође веома примитиван процес.
Нгинк једноставно уписује у РАМДиск аццесс.лог за сваки захтев, у којем указује на путању до фотографије коју је тренутно сервирао (релативна путања, наравно) и којој партицији је испоручена. Оне. може да пише „фотографија 1“, а затим или бафер, или врућа кеш меморија, или хладна кеш меморија, или прокси.
У зависности од тога, морамо некако одлучити шта ћемо са фотографијом.
Имамо мали демон који ради на свакој машини који стално чита овај дневник и чува статистику о коришћењу одређених фотографија у својој меморији.
Он једноставно скупља тамо, држи бројаче и периодично ради следеће. Он премешта активно тражене фотографије, за које има много захтева, у врући кеш, где год да се налазе.
Фотографије које се ретко траже и ређе траже постепено се гурају из врућег кеша у хладни.
А када нам понестане простора у кешу, једноставно почињемо да бришемо све из хладног кеша неселективно. И успут, ово добро функционише.
Да би фотографија била сачувана одмах приликом проксија у бафер, користимо директиву проки_сторе и бафер је такође РАМДиск, тј. за корисника ради веома брзо. Ово се тиче унутрашњости самог сервера за кеширање.
Преостало питање је како дистрибуирати захтеве преко ових сервера.
Рецимо да постоји кластер од двадесет машина за складиштење и три сервера за кеширање (тако се то догодило).
Морамо некако да одредимо који су захтеви за које фотографије и где да их сместимо.
Најчешћа опција је Роунд Робин. Или то урадите случајно?
Ово очигледно има бројне недостатке јер бисмо у таквој ситуацији користили кеш веома неефикасно. Захтеви ће слетети на неке насумичне машине: овде је био кеширан, али на следећем више га нема. А ако све ово успе, биће веома лоше. Чак и са малим бројем машина у кластеру.
Морамо некако недвосмислено да одредимо на ком серверу ћемо који захтев.
Постоји баналан начин. Узимамо хеш са УРЛ-а или хеш из нашег кључа за шардирање, који се налази у УРЛ-у, и делимо га бројем сервера. Ће радити? Ће.
Оне. Имамо 2% захтев, на пример, за неки „екампле_урл“ увек ће слетети на сервер са индексом „XNUMX“, а кеш ће се стално одлагати на најбољи могући начин.
Али постоји проблем са поновним шардањем у таквој шеми. Ресхардинг - мислим на промену броја сервера.
Претпоставимо да наш кеш кластер више не може да се носи и одлучујемо да додамо још једну машину.
Да додамо.
Сада је све дељиво не са три, већ са четири. Дакле, скоро сви кључеви које смо некада имали, скоро сви УРЛ-ови сада живе на другим серверима. Цео кеш је поништен само на тренутак. Сви захтеви су пали на наш складишни кластер, постало му је лоше, квар услуге и незадовољни корисници. Не желим то да радим.
Ни ова опција нам не одговара.
То. шта да радимо? Морамо на неки начин ефикасно користити кеш, слати исти захтев на исти сервер изнова и изнова, али бити отпорни на поновно шардирање. И постоји такво решење, није тако компликовано. То се зове доследно хеширање.
Како то изгледа?
Узимамо неку функцију из кључа за шардирање и ширимо све њене вредности на круг. Оне. у тачки 0, његове минималне и максималне вредности конвергирају. Затим постављамо све наше сервере у исти круг на приближно овај начин:
Сваки сервер је дефинисан једном тачком, а сектор који иде у смеру казаљке на сату до њега, сходно томе, опслужује овај хост. Када нам стигну захтеви, одмах видимо да, на пример, захтев А – он тамо има хеш – а опслужује га сервер 2. Захтев Б – сервер 3. И тако даље.
Шта се дешава у овој ситуацији током поновног шардирања?
Не поништавамо цео кеш као раније и не померамо све кључеве, већ померамо сваки сектор на мало растојање тако да, релативно говорећи, наш шести сервер, који желимо да додамо, стане у слободан простор и додајемо га тамо.
Наравно, у таквој ситуацији се и кључеви померају. Али исељавају се много слабије него раније. И видимо да су наша прва два кључа остала на својим серверима, а сервер за кеширање се променио само за последњи кључ. Ово функционише прилично ефикасно, а ако постепено додајете нове хостове, онда овде нема великог проблема. Додајеш и додајеш мало по мало, чекаш да се кеш поново напуни и све ради како треба.
Остаје само питање одбијања. Претпоставимо да је нека врста аутомобила у квару.
И не бисмо заиста желели да поново генеришемо ову мапу у овом тренутку, поништимо део кеша и тако даље, ако је, на пример, машина поново покренута, а ми морамо некако да сервисирамо захтеве. Једноставно држимо једну резервну кеш меморију фотографија на свакој локацији, која служи као замена за било коју машину која тренутно не ради. А ако изненада један од наших сервера постане недоступан, саобраћај одлази тамо. Наравно, тамо немамо никакав кеш, тј. хладно је, али се бар захтеви корисника обрађују. Ако је ово кратак интервал, онда га доживљавамо потпуно мирно. Само је више оптерећења на складишту. Ако је овај интервал дуг, онда већ можемо да донесемо одлуку - да уклонимо овај сервер са мапе или не, или да га заменимо другим.
Овде се ради о систему кеширања. Хајде да погледамо резултате.
Чини се да овде нема ништа компликовано. Али овај метод управљања кеш меморијом дао нам је стопу трикова од око 98%. Оне. од ових 80 хиљада захтева у секунди само 1600 стигне до складишта и ово је сасвим нормално оптерећење, они то мирно подносе, увек имамо резерву.
Поставили смо ове сервере у три наша ДЦ-а и добили три тачке присуства - Праг, Мајами и Хонг Конг.
То. они су мање-више локално лоцирани на сваком од наших циљних тржишта.
И као леп бонус, добили смо овај прокси за кеширање, на коме је ЦПУ у ствари неактиван, јер није толико потребан за сервирање садржаја. И тамо, користећи НГИНКС+ Луа, имплементирали смо много утилитарне логике.
На пример, можемо експериментисати са вебп-ом или прогресивним јпег-ом (ово су ефикасни модерни формати), видети како то утиче на саобраћај, донети неке одлуке, омогућити то за одређене земље итд.; правите динамичку промену величине или исеците фотографије у ходу.
Ово је добар случај када, на пример, имате мобилну апликацију која приказује фотографије, а мобилна апликација не жели да троши клијентов ЦПУ на захтев за велику фотографију, а затим да је промени величину на одређену величину како би је гурнула у поглед. Можемо једноставно динамички одредити неке параметре у УПорт условном УРЛ-у, а кеш фотографија ће променити величину саме фотографије. По правилу ће изабрати величину коју физички имамо на диску, што је могуће ближу траженој, и продати је у одређеним координатама.
Иначе, јавно смо објавили видео снимке последњих пет година конференције програмера система високог оптерећења . Гледајте, учите, делите и претплатите се на .
Ту такође можемо додати много логике производа. На пример, можемо да додамо различите водене жигове помоћу параметара УРЛ-а, можемо да замутимо, замутимо или пикселирамо фотографије. Ово је када желимо да покажемо фотографију особе, али не желимо да покажемо њено лице, ово добро функционише, овде је све имплементирано.
Шта смо добили? Добили смо три тачке присуства, добру стопу трикова, а у исто време немамо неактиван ЦПУ на овим машинама. Сада је, наравно, постао важнији него раније. Морамо себи да дамо јаче аутомобиле, али вреди.
Ово се тиче враћања фотографија. Овде је све сасвим јасно и очигледно. Мислим да нисам открио Америку, скоро сваки ЦДН ради на овај начин.
И, највероватније, софистицирани слушалац може имати питање: зашто једноставно не промените све у ЦДН? Било би отприлике исто; сви модерни ЦДН-ови то могу. И постоји низ разлога.
Први су фотографије.
Ово је једна од кључних тачака наше инфраструктуре и потребна нам је што већа контрола над њом. Ако је ово нека врста решења од треће стране, а ви немате никакву моћ над њим, биће вам прилично тешко да живите са њим када имате велики скуп података и када имате веома велики проток корисничких захтева.
Дозволите ми да вам дам пример. Сада, са нашом инфраструктуром, можемо, на пример, у случају неких проблема или подземних удара, да одемо до машине и да се петљамо тамо, релативно говорећи. Можемо додати колекцију неких метрика које су нам само потребне, можемо некако експериментисати, видети како то утиче на графиконе, итд. Сада се прикупља много статистичких података о овом кеш кластеру. И ми га периодично гледамо и проводимо дуго истражујући неке аномалије. Да је на страни ЦДН-а, било би много теже контролисати. Или, на пример, ако се деси нека несрећа, знамо шта се десило, знамо како да живимо са тим и како да то превазиђемо. Ово је први закључак.
Други закључак је такође прилично историјски, јер се систем развијао дуго времена и било је много различитих пословних захтева у различитим фазама, а они се не уклапају увек у концепт ЦДН.
А тачка која следи из претходног је
То је зато што на фото кешовима имамо много специфичне логике, која се не може увек додати на захтев. Мало је вероватно да ће вам било који ЦДН додати неке прилагођене ствари на ваш захтев. На пример, шифровање УРЛ-ова ако не желите да клијент може нешто да промени. Да ли желите да промените УРЛ на серверу и шифрујете га, а затим да пошаљете неке динамичке параметре овде.
Какав закључак ово сугерише? У нашем случају, ЦДН није баш добра алтернатива.
А у вашем случају, ако имате неке специфичне пословне захтеве, онда можете прилично лако да примените оно што сам вам сам показао. И ово ће савршено функционисати са сличним профилом оптерећења.
Али ако имате неку врсту општег решења, а задатак није баш специфичан, можете апсолутно безбедно узети ЦДН. Или ако су вам време и ресурси важнији од контроле.
А модерни ЦДН-ови имају скоро све о чему сам вам сада рекао. Са изузетком плус или минус неких карактеристика.
Овде се ради о поклањању фотографија.
Хајдемо сада мало напред у нашој ретроспективи и причати о складиштењу.
2013. је пролазила.
Додати су сервери за кеширање, проблеми са перформансама су нестали. Све је у реду. Скуп података расте. Од 2013. имали смо око 80 сервера повезаних са складиштем и око 40 сервера за кеширање у сваком ДЦ-у. Ово је 560 терабајта података на сваком ДЦ-у, тј. око петабајта укупно.
А са растом скупа података, оперативни трошкови су почели значајно да расту. Шта је ово значило?
На овом дијаграму који је нацртан - са САН-ом, са машинама и кешом повезаним са њим - има много тачака квара. Ако смо се већ раније бавили неуспехом сервера за кеширање, све је било мање-више предвидљиво и разумљиво, али на страни складиштења све је било много горе.
Прво, сама Стораге Ареа Нетворк (САН), која може покварити.
Друго, преко оптике је повезан са крајњим машинама. Може доћи до проблема са оптичким картицама и свећицама.
Наравно, нема их толико као код самог САН-а, али, ипак, и то су тачке неуспеха.
Следећа је сама машина, која је повезана са складиштем. Такође може пропасти.
Укупно имамо три бода неуспеха.
Даље, поред тачака квара, постоји и тешко одржавање самог складишта.
Ово је сложен вишекомпонентни систем и системски инжењери могу имати потешкоћа да раде са њим.
И последња, најважнија тачка. Ако дође до квара у било којој од ове три тачке, имамо ненулте шансе да изгубимо корисничке податке јер се систем датотека може срушити.
Рецимо да је наш систем датотека покварен. Прво, његов опоравак траје дуго - може потрајати недељу дана са великом количином података. И друго, на крају ћемо највероватније добити гомилу неразумљивих фајлова које ће морати некако да се комбинују у корисничке фотографије. И ризикујемо да изгубимо податке. Ризик је прилично висок. И што се такве ситуације чешће дешавају, и што се више проблема јавља у целом овом ланцу, то је ризик већи.
Морало је нешто да се уради у вези са овим. И одлучили смо да само треба да направимо резервну копију података. Ово је заправо очигледно решење и добро. Шта смо урадили?
Овако је изгледао наш сервер када је раније био повезан на складиште. Ово је један главни део, то је само блок уређај који заправо представља носач за удаљено складиштење преко оптике.
Управо смо додали други одељак.
Поставили смо друго складиште поред њега (на срећу, није толико скупо у смислу новца) и назвали га резервном партицијом. Такође је повезан преко оптике и налази се на истој машини. Али морамо некако да синхронизујемо податке између њих.
Овде једноставно правимо асинхрони ред у близини.
Није много заузета. Знамо да немамо довољно записа. Ред је само табела у МиСКЛ-у у којој су написани редови попут „треба да направите резервну копију ове фотографије“. Уз било какву промену или отпремање, копирамо са главне партиције у резервну копију користећи асинхрони или само неку врсту позадинског радника.
И тако увек имамо два конзистентна одељка. Чак и ако један део овог система поквари, увек можемо да променимо главну партицију резервном копијом и све ће наставити да ради.
Али због тога се оптерећење читања увелико повећава, јер... поред клијената који читају из главног одељка, јер тамо прво погледају фотографију (тамо је новија), а онда је траже на резервној копији, ако је нису нашли (али НГИНКС само ово ради), наш систем је такође плус резервна копија која сада чита са главне партиције. Није да је ово било уско грло, али нисам желео да повећавам оптерећење, у суштини, само тако.
И додали смо трећи диск, који је мали ССД, и назвали га бафер.
Како то сада ради.
Корисник поставља фотографију у бафер, а затим се догађај баца у ред који указује да је потребно копирати у два одељка. Копира се, а фотографија неко време (рецимо, дан) живи у баферу и тек онда се одатле чисти. Ово умногоме побољшава корисничко искуство, јер корисник постави фотографију, по правилу одмах почињу да следе захтеви или је сам ажурирао страницу и освежио је. Али све зависи од апликације која врши отпремање.
Или, на пример, други људи којима је почео да се показује одмах шаљу захтеве након ове фотографије. Још није у кешу; први захтев се јавља веома брзо. У суштини исто као из кеша фотографија. Споро складиштење уопште није укључено у ово. А када се дан касније очисти, већ је или кеширан на нашем слоју за кеширање, или, највероватније, никоме више није потребан. Оне. Корисничко искуство овде је веома добро порасло због тако једноставних манипулација.
Па, и најважније: престали смо да губимо податке.
Рецимо да смо стали потенцијално изгубимо податке, јер их нисмо заиста изгубили. Али постојала је опасност. Видимо да је ово решење, наравно, добро, али помало личи на ублажавање симптома проблема, уместо да га потпуно реши. И неки проблеми остају овде.
Прво, ово је тачка неуспеха у виду самог физичког домаћина на коме ради сва ова машинерија; она није нестала.
Друго, и даље постоје проблеми са САН-овима, остаје њихово тешко одржавање итд. Није то био критичан фактор, али сам желео да покушам да некако живим без тога.
И направили смо трећу верзију (у ствари, другу у ствари) - верзију резервације. Како је то изгледало?
Ево шта је било -
Наши главни проблеми су у чињеници да је ово физички домаћин.
Прво, уклањамо САН-ове јер желимо да експериментишемо, желимо да испробамо само локалне чврсте дискове.
Ово је већ 2014-2015, и тада је ситуација са дисковима и њиховим капацитетом у једном хосту постала много боља. Одлучили смо зашто не бисмо пробали.
А онда једноставно узимамо нашу резервну партицију и физички је преносимо на засебну машину.
Тако добијамо овај дијаграм. Имамо два аутомобила која чувају исте скупове података. Они у потпуности праве једни друге резервне копије и синхронизују податке преко мреже кроз асинхрони ред у истом МиСКЛ-у.
Зашто ово добро функционише је зато што имамо мало записа. Оне. да је писање упоредиво са читањем, можда бисмо имали неку врсту мрежног оптерећења и проблема. Мало је писања, много читања – овај метод добро функционише, тј. Ретко копирамо фотографије између ова два сервера.
Како ово функционише, ако погледате мало детаљније.
Отпремити. Балансер једноставно бира насумичне хостове са паром и отпрема их на њега. У исто време, он природно обавља здравствене провере и брине се да ауто не испадне. Оне. он поставља фотографије само на сервер уживо, а затим се кроз асинхрони ред све то копира његовом суседу. Са уплоад-ом све је крајње једноставно.
Задатак је мало тежи.
Луа нам је овде помогао, јер може бити тешко направити такву логику на ванилла НГИНКС-у. Прво постављамо захтев првом серверу, да видимо да ли је фотографија тамо, јер би потенцијално могла да буде постављена, на пример, код комшије, али још није стигла овде. Ако је фотографија тамо, то је добро. Одмах га дајемо клијенту и, евентуално, кеширамо.
Ако га нема, једноставно упутимо захтев комшији и гарантовано ћемо га добити одатле.
То. опет можемо рећи: може бити проблема са перформансама, јер има сталних кружних путовања - фотографија је постављена, није овде, постављамо два захтева уместо једног, ово би требало да ради полако.
У нашој ситуацији то не иде споро.
Сакупљамо гомилу метрика на овом систему, а условна паметна стопа таквог механизма је око 95%. Оне. Кашњење ове резервне копије је мало, и због тога смо скоро загарантовани, након што је фотографија постављена, направићемо је први пут и нећемо морати нигде да идемо два пута.
Па шта још имамо што је стварно кул?
Раније смо имали главну резервну партицију и читали смо са њих узастопно. Оне. Увек смо прво тражили главни, а затим резервни. Био је то један потез.
Сада користимо читање са две машине одједном. Ми дистрибуирамо захтеве користећи Роунд Робин. У малом проценту случајева постављамо два захтева. Али свеукупно, сада имамо дупло већи фонд за читање него што смо имали раније. А оптерећење је у великој мери смањено и на машинама за слање и директно на машинама за складиштење, које смо такође имали у то време.
Што се тиче толеранције грешака. Заправо, за то смо се углавном борили. Са толеранцијом грешака, овде је све испало одлично.
Један ауто се покварио.
Нема проблема! Систем инжењер се можда неће ни пробудити ноћу, сачекаће јутро, ништа лоше се неће догодити.
Ако чак и ако ова машина поквари, ред је у квару, нема ни проблема, дневник ће се једноставно нагомилати прво на живој машини, па ће се додати у ред, а затим у аутомобил који ће пустити у рад након неког времена.
Иста ствар са одржавањем. Једноставно искључимо једну од машина, ручно је извучемо из свих базена, она престане да прима саобраћај, урадимо неку врсту одржавања, нешто уредимо, па вратимо у функцију и ова резервна копија се доста брзо сустиже. Оне. дневно, застоји једног аутомобила сустижу за неколико минута. Ово је заиста мало. Са толеранцијом грешака, опет кажем, овде је све кул.
Који се закључци могу извући из ове шеме редундансе?
Имамо толеранцију на грешке.
Једноставан за коришћење. Пошто машине имају локалне чврсте дискове, ово је много погодније са оперативне тачке гледишта за инжењере који раде са њима.
Добили смо дупли додатак за читање.
Ово је веома добар бонус поред толеранције грешака.
Али постоје и проблеми. Сада имамо много сложенији развој неких карактеристика у вези са овим, јер је систем на крају постао 100% конзистентан.
Морамо, рецимо, у неком позадинском послу, стално размишљати: „На ком серверу сада радимо?“, „Да ли овде заиста постоји тренутна фотографија?“ итд. Ово је, наравно, све замотано, а за програмера који пише пословну логику, то је транспарентно. Али, ипак, појавио се овај велики сложени слој. Али спремни смо да трпимо ово у замену за доброте које смо од тога добили.
И ту опет настаје неки сукоб.
Рекао сам на почетку да је чување свега на локалним чврстим дисковима лоше. И сад кажем да нам се допало.
Да, заиста, временом се ситуација много променила, а сада овај приступ има много предности. Прво, добијамо много једноставнију операцију.
Друго, то је продуктивније, јер немамо ове аутоматске контролере или везе са дисковним полицама.
Тамо је огромна количина машинерије, а ово је само неколико дискова који се овде на машини склапају у рацију.
Али постоје и недостаци.
Ово је отприлике 1,5 пута скупље од коришћења САН-а чак и по данашњим ценама. Због тога смо одлучили да храбро не претварамо цео наш велики кластер у аутомобиле са локалним чврстим дисковима и одлучили смо да оставимо хибридно решење.
Половина наших машина ради са чврстим дисковима (па, не половина - вероватно 30 процената). А остало су стари аутомобили који су имали прву шему резервације. Једноставно смо их поново монтирали, пошто нам нису били потребни нови подаци или било шта друго, једноставно смо преместили монтирање са једног физичког хоста на два.
И сада имамо велику залиху лектире, и проширили смо је. Ако смо раније монтирали једно складиште на једну машину, сада монтирамо четири, на пример, на један пар. И ради добро.
Хајде да укратко изнесемо шта смо постигли, за шта смо се борили и да ли смо успели.
Резултати
Имамо корисника – чак 33 милиона.
Имамо три тачке присуства - Праг, Мајами, Хонг Конг.
Они садрже слој за кеширање, који се састоји од аутомобила са брзим локалним дисковима (ССД), на којима покрећу једноставне машинерије из НГИНКС-а, његови аццесс.лог и Питхон демони, који све ово обрађују и управљају кешом.
Ако желите, ви сте у свом пројекту, ако фотографије нису толико критичне за вас као што су за нас, или ако је компромис контроле брзине развоја и трошкова ресурса у другом правцу за вас, онда можете безбедно да их замените са ЦДН-ом, модерни ЦДН-ови добро раде.
Следећи слој за складиштење, на коме имамо групе парова машина које праве резервне копије једна другој, датотеке се асинхроно копирају из једне у другу кад год се промене.
Штавише, неке од ових машина раде са локалним чврстим дисковима.
Неке од ових машина су повезане на САН мреже.
И, с једне стране, погоднији је за коришћење и мало продуктивнији, с друге стране, погодан је у погледу густине пласмана и цене по гигабајту.
Ово је тако кратак преглед архитектуре онога што смо добили и како се све то развијало.
Још неколико савета од капитена, врло једноставних.
Прво, ако изненада одлучите да морате хитно да побољшате све у својој фото инфраструктури, прво измерите, јер можда ништа не треба побољшати.
Дозволите ми да вам дам пример. Имамо кластер машина које шаљу фотографије из прилога у четове, а шема тамо ради од 2009. године и нико од тога не пати. Сви су добро, свима се све свиђа.
Да бисте измерили, прво окачите гомилу метрика, погледајте их, а затим одлучите чиме нисте задовољни и шта треба побољшати. Да бисмо ово измерили, имамо кул алат под називом Пинба.
Омогућава вам да прикупите веома детаљну статистику од НГИНКС-а за сваки захтев и кодове одговора, као и расподелу времена - шта год желите. Има везе са свим врстама различитих аналитичких система, и онда све то можете лепо погледати.
Прво смо га измерили, а онда смо га побољшали.
Даље. Оптимизујемо читање са кеш меморијом, писање са шардирањем, али ово је очигледна ствар.
Даље. Ако тек сада почињете да градите свој систем, онда је много боље направити фотографије као непроменљиве датотеке. Зато што одмах губите читаву класу проблема са поништавањем кеша, са начином на који логика треба да пронађе исправну верзију фотографије, итд.
Рецимо да сте отпремили сто, а затим га ротирали, учинили да то буде физички другачија датотека. Оне. нема потребе да размишљам: сада ћу уштедети мало простора, уписати га у исту датотеку, променити верзију. Ово увек не функционише добро и касније изазива много главобоља.
Следећа тачка. О промени величине у ходу.
Раније, када су корисници поставили фотографију, одмах смо исекли читаву гомилу величина за све прилике, за различите клијенте, и све су биле на диску. Сада смо напустили ово.
Оставили смо само три главне величине: мале, средње и велике. Једноставно смањимо све остало са величине која стоји иза оне која нам је затражена у Упорту, једноставно смањимо и дамо кориснику.
Испоставило се да је ЦПУ слоја за кеширање много јефтинији него да стално регенеришемо ове величине на сваком складишту. Рецимо да желимо да додамо нови, ово ће трајати месец дана - покрените скрипту свуда која би све ово урадила уредно, без уништавања кластера. Оне. Ако имате прилику да бирате сада, боље је да направите што мање физичких величина, али тако да бар нека дистрибуција буде, рецимо, три. А све остало се може једноставно променити у ходу користећи готове модуле. Сада је све врло лако и доступно.
А инкрементална асинхрона резервна копија је добра.
Као што је наша пракса показала, ова шема одлично функционише са одложеним копирањем измењених датотека.
Последња тачка је такође очигледна. Ако ваша инфраструктура сада нема таквих проблема, али постоји нешто што може да се поквари, сигурно ће се покварити када буде мало више. Због тога је боље размислити о томе унапред и не имати проблема са тим. То је све што сам хтео да кажем.
kontakti
»
»
Овај извештај је транскрипт једног од најбољих говора на конференцији програмера система високог оптерећења . Остало је мање од месец дана до конференције ХигхЛоад++ 2017.
Већ имамо спремно , распоред се сада активно формира.
Ове године настављамо да истражујемо тему архитектуре и скалирања:
- / Игор Васиљев
- / Дмитри Егоров
- / Анатолиј Пласковски
- / Роман Шеховцов, Алексеј Громачиков
- / Филип Делгадо
Такође користимо неке од ових материјала у нашем онлајн курсу за развој система са високим оптерећењем је ланац посебно одабраних писама, чланака, материјала, видео записа. Наш уџбеник већ садржи више од 30 јединствених материјала. Повежите се!
Извор: ввв.хабр.цом