Архитектура за складирање и споделување фотографии во Badoo

Артем Денисов ( bo0rsh201, Badoo)

Badoo е најголемата страница за запознавање во светот. Во моментов имаме околу 330 милиони регистрирани корисници ширум светот. Но, она што е многу поважно во контекст на нашиот разговор денес е тоа што складираме околу 3 петабајти кориснички фотографии. Секој ден нашите корисници прикачуваат околу 3,5 милиони нови фотографии, а оптоварувањето за читање е околу 80 илјади барања во секунда. Ова е доста за нашиот заден дел, а понекогаш има потешкотии со ова.

Ќе зборувам за дизајнот на овој систем, кој ги складира и испраќа фотографиите воопшто, и ќе го разгледам од гледна точка на развивачот. Ќе има кратка ретроспектива за тоа како се развиваше, каде што ќе ги наведам главните пресвртници, но само подетално ќе зборувам за решенијата што моментално ги користиме.

Сега да почнеме.

Како што кажав, ова ќе биде ретроспектива, а за да почнеме од некаде, да го земеме најчестиот пример.

Имаме заедничка задача, треба да прифаќаме, складираме и испраќаме кориснички фотографии. Во оваа форма, задачата е општа, можеме да користиме што било:

• модерно складирање на облак,
• кутии решение, од кои исто така има многу сега;
• Можеме да поставиме неколку машини во нашиот центар за податоци и да ставиме големи хард дискови на нив и да складираме фотографии таму.

Badoo историски - и сега и тогаш (во времето кога беше само во повој) - живее на свои сервери, внатре во нашите DC-и. Затоа, оваа опција беше оптимална за нас.

Само што направивме неколку машини, ги нарековме „фотографии“ и добивме кластер што складира фотографии. Но, се чини дека нешто недостасува. За да функционира сето ова, треба некако да одредиме на која машина кои фотографии ќе ги складираме. И тука нема потреба да се отвора Америка.

Додаваме поле во нашето складирање со информации за корисниците. Ова ќе биде клучот за споделување. Во нашиот случај, го нарековме place_id, и овој ID на место укажува на местото каде што се зачувани фотографиите на корисниците. Ние правиме мапи.

Во првата фаза, ова може да се направи дури и рачно - велиме дека фотографијата на овој корисник со такво место ќе слета на таков сервер. Благодарение на оваа мапа, секогаш знаеме кога корисникот ќе постави фотографија, каде да ја зачува и знаеме од каде да ја дадеме.

Ова е апсолутно тривијална шема, но има доста значајни предности. Првата е дека е едноставна, како што реков, а втората е дека со овој пристап можеме лесно да се скалираме хоризонтално со едноставно доставување нови автомобили и нивно додавање на картата. Не треба да правите ништо друго.

Така ни беше некое време.

Ова беше околу 2009 година. Испорачаа автомобили, доставија ...

И во одреден момент почнавме да забележуваме дека оваа шема има одредени недостатоци. Кои се недостатоците?

Како прво, има ограничен капацитет. Не можеме да натрупаме онолку хард дискови на еден физички сервер колку што би сакале. И ова стана одреден проблем со текот на времето и со растот на базата на податоци.

И второ. Ова е нетипична конфигурација на машини, бидејќи таквите машини се тешки за повторна употреба во некои други кластери; тие се доста специфични, т.е. тие треба да бидат слаби во перформансите, но во исто време со голем хард диск.

Сето ова беше за 2009 година, но, во принцип, овие барања се актуелни и денес. Имаме ретроспектива, па во 2009 година се беше сосема лошо со ова.

И последната точка е цената.

Цената беше многу висока во тоа време, и требаше да бараме некои алтернативи. Оние. требаше некако подобро да го искористиме и просторот во центрите за податоци и физичките сервери на кои се наоѓа сето ова. И нашите системски инженери започнаа голема студија во која разгледаа еден куп различни опции. Тие, исто така, ги разгледаа групираните датотечни системи како што се PolyCeph и Luster. Имаше проблеми со перформансите и доста тешко работење. Тие одбија. Се обидовме да ја монтираме целата база на податоци преку NFS на секој автомобил со цел некако да ја зголемиме. Читањето исто така помина лошо, пробавме различни решенија од различни продавачи.

И на крајот, се решивме да ја користиме таканаречената мрежа на простор за складирање.

Ова се големи SHD кои се специјално дизајнирани за складирање на големи количини на податоци. Тие се полици со дискови кои се монтираат на финалните оптички излезни машини. Тоа. имаме некој вид на базен на машини, прилично мали, и овие SHD, кои се проѕирни за нашата логика на испраќање, т.е. за нашиот nginx или кој било друг да услужи барања за овие фотографии.

Оваа одлука имаше очигледни предности. Ова е SHD. Таа е насочена кон складирање фотографии. Ова функционира поевтино отколку едноставно опремување на машини со хард дискови.

Втор плус.

Ова е дека капацитетот стана многу поголем, т.е. можеме да сместиме многу повеќе складирање во многу помал волумен.

Но, имаше и недостатоци кои се појавија доста брзо. Како што растеше бројот на корисници и оптоварувањето на овој систем, почнаа да се појавуваат проблеми со перформансите. И проблемот овде е сосема очигледен - секој SHD дизајниран да складира многу фотографии во мал волумен, по правило, страда од интензивно читање. Ова всушност важи за секое складирање во облак или за било што друго. Сега немаме идеално складирање кое би било бескрајно скалабилно, можете да внесете што било во него и многу добро би толерирало читање. Особено случајни читања.

Како што е случајот со нашите фотографии, бидејќи фотографиите се бараат неконзистентно, а тоа многу ќе влијае на нивната изведба.

Дури и според денешните бројки, ако добиеме некаде повеќе од 500 RPS за фотографии на машина на која е поврзан складирањето, проблемите веќе почнуваат. И тоа беше доволно лошо за нас, бидејќи бројот на корисници расте, работите само ќе се влошат. Ова треба некако да се оптимизира.

Со цел да се оптимизира, решивме во тоа време, очигледно, да го погледнеме профилот на оптоварување - што, генерално, се случува, што треба да се оптимизира.

И тука сè игра во нашите раце.

Веќе реков во првиот слајд: имаме 80 илјади барања за читање во секунда со само 3,5 милиони прикачувања дневно. Тоа е, ова е разлика од три реда на големина. Очигледно е дека читањето треба да се оптимизира и практично е јасно како.

Има уште една мала точка. Спецификите на услугата се такви што едно лице се регистрира, поставува фотографија, потоа почнува активно да гледа во други луѓе, како нив, и активно се прикажува на други луѓе. Потоа тој наоѓа партнер или не наоѓа партнер, зависи како ќе излезе и престанува да ја користи услугата некое време. Во овој момент, кога го користи, неговите фотографии се многу жешки - барани се, многу луѓе ги гледаат. Штом ќе престане да го прави тоа, многу брзо се откажува од изложеноста на други луѓе како порано, а неговите фотографии речиси никогаш не се бараат.

Оние. Имаме многу мала топла база на податоци. Но, во исто време има многу барања за него. И сосема очигледно решение тука е да додадете кеш.

Кеш со LRU ќе ги реши сите наши проблеми. Што правиме?

Додаваме уште еден релативно мал пред нашиот голем кластер со складиште, кој се нарекува фотокеш. Ова во суштина е само прокси за кеширање.

Како функционира одвнатре? Еве го нашиот корисник, тука е складирањето. Сè е исто како порано. Што додаваме помеѓу?

Тоа е само машина со физички локален диск, што е брзо. Ова е со SSD, на пример. И некој вид локален кеш е зачуван на овој диск.

Како изгледа? Корисникот испраќа барање за фотографија. NGINX прво го бара во локалниот кеш. Ако не, тогаш едноставно прокси_pass до нашето складирање, преземете ја фотографијата од таму и дајте му ја на корисникот.

Но овој е многу банален и нејасно е што се случува внатре. Работи вака нешто.

Кешот е логично поделен на три слоја. Кога велам „три слоја“, тоа не значи дека постои некој вид сложен систем. Не, ова се условно само три директориуми во датотечниот систем:

1. Ова е бафер каде што одат фотографиите штотуку преземени од прокси.
2. Ова е врел кеш што ги складира моментално активно бараните фотографии.
3. И ладна кеш, каде што фотографиите постепено се истиснуваат од врелиот кеш кога ќе им дојдат помалку барања.

За да функционира ова, треба некако да управуваме со овој кеш, треба да ги преуредиме фотографиите во него итн. Ова е исто така многу примитивен процес.

Nginx едноставно пишува во RAMDisk access.log за секое барање, во кое ја означува патеката до фотографијата што моментално ја опслужува (се разбира, релативна патека) и која партиција и била сервирана. Оние. може да каже „слика 1“, а потоа или бафер, или топла кеш, или ладна кеш, или прокси.

Во зависност од ова, треба некако да одлучиме што да правиме со фотографијата.

Имаме мал демон кој работи на секоја машина што постојано го чита овој дневник и складира статистика за употребата на одредени фотографии во нејзината меморија.

Едноставно собира таму, ги чува шалтерите и периодично го прави следново. Активно бараните фотографии, за кои има многу барања, ги преместува во жешкиот кеш, каде и да се.

Фотографиите кои ретко се бараат и поретко се бараат, постепено се туркаат од врелиот кеш во студениот.

И кога ќе ни снема простор во кешот, едноставно почнуваме да бришеме сè од ладниот кеш неселективно. И патем, ова функционира добро.

За да може фотографијата веднаш да се зачува при нејзино прокси во баферот, ја користиме директивата proxy_store и баферот е исто така RAMDisk, т.е. за корисникот работи многу брзо. Ова се однесува на внатрешните работи на самиот сервер за кеширање.

Останатото прашање е како да се дистрибуираат барањата низ овие сервери.

Да речеме дека има кластер од дваесет машини за складирање и три сервери за кеширање (вака се случи).

Треба некако да одредиме кои барања се за кои фотографии и каде да ги спуштиме.

Најчеста опција е Round Robin. Или направете го тоа случајно?

Ова очигледно има голем број на недостатоци бидејќи во таква ситуација би го користеле кешот многу неефикасно. Барањата ќе се спуштат на некои случајни машини: тука е кеширана, но на следната веќе ја нема. И ако сето ова функционира, ќе биде многу лошо. Дури и со мал број машини во кластерот.

Треба недвосмислено недвосмислено да одредиме кој сервер кое барање да го пристигне.

Постои банален начин. Го земаме хашот од URL-то или хашот од нашиот клуч за споделување, кој е во URL-то, и го делиме со бројот на сервери. Ќе работи? Волја.

Оние. Имаме 2% барање, на пример, за некое „example_url“ секогаш ќе слета на серверот со индекс „XNUMX“, а кешот постојано ќе се отстранува што е можно подобро.

Но, во таквата шема има проблем со осладувањето. Ресхардинг - мислам на промена на бројот на сервери.

Да претпоставиме дека нашиот кластер за кеширање повеќе не може да се справи и решивме да додадеме друга машина.

Да додадеме.

Сега сè се дели не со три, туку со четири. Така, скоро сите клучеви што ги имавме, скоро сите URL адреси сега живеат на други сервери. Целиот кеш беше поништен едноставно за момент. Сите барања паднаа на нашиот кластер за складирање, стана лошо, услугата не успеа и незадоволни корисници. Не сакам да го правам тоа.

И оваа опција не ни одговара.

Тоа. Што треба да правиме? Мора некако ефикасно да го користиме кешот, да го прикачуваме истото барање на истиот сервер одново и одново, но да бидеме отпорни на преобликување. И постои такво решение, не е толку комплицирано. Тоа се нарекува доследно хаширање.

Како изгледа?

Земаме некоја функција од клучот за споделување и ги шириме сите негови вредности на кругот. Оние. во точката 0, неговите минимални и максимални вредности се спојуваат. Следно, ги поставуваме сите наши сервери на истиот круг на приближно вака:

Секој сервер е дефиниран со една точка, а секторот што оди во насока на стрелките на часовникот до него, соодветно, го опслужува овој домаќин. Кога ни доаѓаат барања, веднаш гледаме дека, на пример, барањето А - има хаш таму - и го опслужува серверот 2. Барањето Б - од серверот 3. И така натаму.

Што се случува во оваа ситуација за време на решердирањето?

Не го поништуваме целиот кеш, како порано, и не ги поместуваме сите клучеви, туку го поместуваме секој сектор на кратко растојание, така што, релативно кажано, нашиот шести сервер, кој сакаме да го додадеме, да се вклопи во слободниот простор и го додаваме таму.

Се разбира, во таква ситуација и клучевите се поместуваат. Но, тие се иселуваат многу послаби од порано. И гледаме дека нашите први два клуча останаа на нивните сервери, а серверот за кеширање се смени само за последниот клуч. Ова функционира доста ефикасно, и ако додавате нови хостови постепено, тогаш тука нема голем проблем. Додавате и додавате по малку, почекајте повторно да се наполни кешот и сè работи добро.

Единственото прашање останува со одбивањата. Да претпоставиме дека некој вид на автомобил не е во функција.

И ние навистина не би сакале да ја регенерираме оваа мапа во овој момент, да поништиме дел од кешот и така натаму, ако, на пример, машината се рестартира и треба некако да ги сервисираме барањата. Едноставно чуваме по еден резервен кеш за фотографии на секоја локација, кој делува како замена за која било машина што моментално не работи. И ако одеднаш еден од нашите сервери стане недостапен, сообраќајот оди таму. Нормално, немаме кеш таму, т.е. ладно е, но барем барањата на корисниците се обработуваат. Ако ова е краток интервал, тогаш го доживуваме сосема мирно. Има само повеќе оптоварување на складирањето. Ако овој интервал е долг, тогаш веќе можеме да донесеме одлука - да го отстраниме овој сервер од мапата или не, или можеби да го замениме со друг.

Станува збор за системот за кеширање. Да ги погледнеме резултатите.

Се чини дека тука нема ништо комплицирано. Но, овој метод на управување со кешот ни даде стапка на трикови од околу 98%. Оние. Од овие 80 илјади барања во секунда, само 1600 стигнуваат до складиште и тоа е сосема нормално оптоварување, мирно го поднесуваат, секогаш имаме резерва.

Ги поставивме овие сервери во три наши DC и добивме три точки на присуство - Прага, Мајами и Хонг Конг.

Тоа. тие се повеќе или помалку локално лоцирани на секој од нашите целни пазари.

И како убав бонус, го добивме овој прокси за кеширање, на кој процесорот е всушност неактивен, бидејќи не е толку потребен за да се сервира содржина. И таму, користејќи NGINX+ Lua, имплементиравме многу утилитарна логика.

На пример, можеме да експериментираме со webp или прогресивен jpeg (ова се ефективни модерни формати), да видиме како тоа влијае на сообраќајот, да донесеме некои одлуки, да го овозможиме за одредени земји итн.; направете динамична промена на големината или исечете фотографии во лет.

Ова е добра употреба кога, на пример, имате мобилна апликација која прикажува фотографии, а мобилната апликација не сака да го троши процесорот на клиентот за барање голема фотографија и потоа менување на нејзината големина до одредена големина за да ја турне во погледот. Можеме едноставно динамички да одредиме некои параметри во условната URL-адреса на UPort, а кешот за фотографии ќе ја промени големината на самата фотографија. Како по правило, ќе ја избере големината што физички ја имаме на дискот, што е можно поблиску до бараната, и ќе ја намали во специфични координати.

Патем, направивме јавно достапни видео снимки од последните пет години од конференцијата на развивачи на системи со големо оптоварување HighLoad ++. Гледајте, учете, споделувајте и претплатете се на YouTube канал.

Таму можеме да додадеме и многу логика на производи. На пример, можеме да додадеме различни водени жигови користејќи ги параметрите на URL-то, можеме да ги замаглиме, замаглиме или пикселиме фотографиите. Ова е кога сакаме да покажеме фотографија од некоја личност, но не сакаме да го покажеме неговото лице, ова функционира добро, сето тоа е имплементирано овде.

Што добивме? Добивме три точки на присуство, добра стапка на трикови, а во исто време немаме неактивен процесор на овие машини. Тој сега стана, се разбира, поважен од порано. Треба да си дадеме посилни болиди, но вреди.

Ова се однесува на враќањето на фотографиите. Сè овде е сосема јасно и очигледно. Мислам дека не ја открив Америка, скоро секој CDN функционира на овој начин.

И, најверојатно, софистициран слушател може да има прашање: зошто да не смени сè во CDN? Тоа би било приближно исто; сите модерни CDN можат да го направат тоа. И има голем број причини.

Првиот е фотографии.

Ова е една од клучните точки на нашата инфраструктура и ни треба што е можно поголема контрола над неа. Ако ова е некакво решение од трет продавач, а вие немате никаква моќ над него, ќе ви биде доста тешко да живеете со него кога имате голема база на податоци и кога имате многу голем проток на барањата на корисниците.

Дозволете ми да ви дадам пример. Сега, со нашата инфраструктура, можеме, на пример, во случај на некои проблеми или подземни тропања, да одиме до машината и да се плеткаме таму, релативно кажано. Можеме да додадеме збирка од некои метрики што само ни требаат, да експериментираме некако, да видиме како тоа влијае на графиконите итн. Сега се собираат многу статистички податоци за овој кластер за кеширање. И ние периодично го разгледуваме и поминуваме долго време истражувајќи некои аномалии. Да беше на страната на ЦДН, ќе беше многу потешко да се контролира. Или, на пример, ако се случи некаква несреќа, знаеме што се случило, знаеме како да живееме со тоа и како да го надминеме. Ова е првиот заклучок.

Вториот заклучок е исто така прилично историски, бидејќи системот се развива долго време, и имаше многу различни деловни барања во различни фази, и тие не секогаш се вклопуваат во концептот ЦДН.

И поентата што следи од претходната е

Тоа е затоа што на кешот на фотографии имаме многу специфична логика, која не може секогаш да се додаде по барање. Малку е веројатно дека некој CDN ќе ви додаде некои сопствени работи на ваше барање. На пример, шифрирање на URL-адреси ако не сакате клиентот да може да промени нешто. Дали сакате да го промените URL-то на серверот и да го шифрирате, а потоа да испратите некои динамички параметри овде.

Каков заклучок сугерира ова? Во нашиот случај, CDN не е многу добра алтернатива.

И во вашиот случај, ако имате некои специфични деловни барања, тогаш можете многу лесно да го имплементирате она што сам ви го покажав. И ова ќе работи совршено со сличен профил на оптоварување.

Но, ако имате некакво општо решение, а задачата не е многу специфична, можете апсолутно безбедно да земете CDN. Или ако времето и ресурсите ви се поважни од контролата.

И модерните ЦДН имаат речиси сè што ви кажав сега. Со исклучок на плус или минус некои карактеристики.

Станува збор за подарување фотографии.

Ајде сега да продолжиме малку напред во нашата ретроспектива и да разговараме за складирањето.

2013 минуваше.

Се додадоа сервери за кеширање, проблемите со изведбата исчезнаа. Се е во ред. Збирката на податоци расте. Почнувајќи од 2013 година, имавме околу 80 сервери поврзани со складирање и околу 40 сервери за кеширање во секој DC. Ова е 560 терабајти податоци на секој DC, т.е. вкупно околу еден петабајт.

И со растот на базата на податоци, оперативните трошоци почнаа значително да растат. Што значеше ова?

На овој дијаграм што е нацртан - со САН, со машини и кешови поврзани на него - има многу точки на неуспех. Ако претходно веќе се занимававме со неуспехот на кеширањето на серверите, сè беше повеќе или помалку предвидливо и разбирливо, но на страната за складирање сè беше многу полошо.

Прво, самата мрежа за складирање (САН), која може да пропадне.

Второ, тој е поврзан преку оптика со крајните машини. Може да има проблеми со оптички картички и свеќички.

Се разбира, нема толку многу од нив како со самиот SAN, но, сепак, ова се исто така точки на неуспех.

Следна е самата машина, која е поврзана со складиштето. Може и да пропадне.

Вкупно имаме три бода на неуспех.

Понатаму, покрај точките на дефект, има и напорно одржување на самото складирање.

Ова е сложен повеќекомпонентен систем и системските инженери може да имаат тешко време да работат со него.

И последната, најважна точка. Ако се случи дефект во која било од овие три точки, имаме ненула шанса да ги изгубиме корисничките податоци бидејќи датотечниот систем може да се сруши.

Да речеме дека нашиот датотечен систем е скршен. Прво, неговото обновување трае долго - може да потрае една недела со голема количина на податоци. И второ, на крајот најверојатно ќе завршиме со еден куп неразбирливи датотеки кои ќе треба некако да се комбинираат во кориснички фотографии. И ризикуваме да изгубиме податоци. Ризикот е доста висок. И колку почесто се случуваат такви ситуации и колку повеќе проблеми се појавуваат во целиот овој синџир, толку е поголем овој ризик.

Мораше да се направи нешто околу ова. И решивме дека само треба да направиме резервна копија на податоците. Ова е всушност очигледно и добро решение. Што направивме?

Вака изгледаше нашиот сервер кога претходно беше поврзан со складиштето. Ова е еден главен дел, тоа е само блок уред кој всушност претставува монтирање за далечинско складирање преку оптика.

Само додадовме втор дел.

Поставивме втор склад до него (за среќа, не е толку скап во однос на пари) и го нарековме резервна партиција. Се поврзува и преку оптика и се наоѓа на истата машина. Но, треба некако да ги синхронизираме податоците меѓу нив.

Овде едноставно правиме асинхрона редица во близина.

Таа не е многу зафатена. Знаеме дека немаме доволно рекорди. Редот е само табела во MySQL во која се напишани линии како „треба да направите резервна копија на оваа фотографија“. Со каква било промена или прикачување, ние копираме од главната партиција во резервна копија користејќи асинхрон или само некој вид на работник во заднина.

И така секогаш имаме два конзистентни делови. Дури и ако еден дел од овој систем не успее, секогаш можеме да ја смениме главната партиција со резервна копија и сè ќе продолжи да работи.

Но, поради ова, оптоварувањето со читање значително се зголемува, бидејќи ... покрај клиентите кои читаат од главниот дел, бидејќи прво ја гледаат фотографијата таму (таму е понова), а потоа ја бараат на резервната копија, ако не ја нашле (но NGINX само го прави ова), нашиот систем е исто така плус резервна копија што сега се чита од главната партиција. Не дека ова беше тесно грло, но не сакав да го зголемам товарот, во суштина, токму така.

И додадовме трет диск, кој е мал SSD, и го нарековме бафер.

Како функционира сега.

Корисникот поставува фотографија во баферот, а потоа настан се фрла во редот што покажува дека треба да се копира во два дела. Се копира, а фотографијата живее на баферот некое време (да речеме, еден ден) и дури потоа се чисти од таму. Ова во голема мера го подобрува корисничкото искуство, бидејќи корисникот поставува фотографија, по правило, веднаш почнуваат да се следат барањата, или тој самиот ја ажурирал страницата и ја освежил. Но, се зависи од апликацијата што го прави прикачувањето.

Или, на пример, други луѓе на кои тој почна да се покажува веднаш испраќаат барања по оваа фотографија. Сè уште не е во кешот; првото барање се јавува многу брзо. Во суштина исто како од кешот на фотографии. Бавното складирање воопшто не е вклучено во ова. И кога еден ден подоцна ќе се исчисти, тој веќе е или кеширан на нашиот слој за кеширање, или, најверојатно, веќе никому не му треба. Оние. Корисничкото искуство овде порасна многу добро поради такви едноставни манипулации.

Па, и што е најважно: престанавме да губиме податоци.

Само да речеме дека застанавме потенцијално изгуби податоци, затоа што навистина не ги изгубивме. Но, имаше опасност. Гледаме дека ова решение е, се разбира, добро, но тоа е малку како да се измазнуваат симптомите на проблемот, наместо целосно да се реши. И тука остануваат некои проблеми.

Прво, ова е точка на неуспех во форма на самиот физички домаќин на кој работи целата оваа машинерија; таа не исчезнала.

Второ, сè уште има проблеми со САН-ите, нивното тешко одржување итн. Не беше дека тоа беше критичен фактор, но сакав да се обидам некако да живеам без него.

И ја направивме третата верзија (всушност, втората всушност) - верзијата за резервација. Како изгледаше тоа?

Еве што беше -

Нашите главни проблеми се со тоа што ова е физички домаќин.

Прво, ги отстрануваме САН затоа што сакаме да експериментираме, сакаме да пробаме само локални хард дискови.

Ова е веќе 2014-2015 година, а во тоа време ситуацијата со дисковите и нивниот капацитет во еден домаќин стана многу подобра. Решивме зошто да не го пробаме.

И тогаш едноставно ја земаме нашата резервна партиција и физички ја пренесуваме на посебна машина.

Така, го добиваме овој дијаграм. Имаме два автомобили кои ги чуваат истите збирки на податоци. Тие целосно прават резервни копии еден на друг и ги синхронизираат податоците преку мрежата преку асинхрона редица во истиот MySQL.

Зошто ова функционира добро е затоа што имаме малку записи. Оние. ако пишувањето би било споредливо со читањето, можеби ќе имавме некаков вид на мрежна покривка и проблеми. Има малку пишување, многу читање - овој метод добро функционира, т.е. Ретко копираме фотографии помеѓу овие два сервери.

Како функционира ова, ако погледнете малку подетално.

Поставете. Балансерот едноставно избира случајни домаќини со пар и поставува на него. Во исто време, тој природно прави здравствени проверки и се грижи автомобилот да не испадне. Оние. тој поставува фотографии само на сервер во живо, а потоа преку асинхрона редица сето тоа се копира на неговиот сосед. Со поставувањето сè е исклучително едноставно.

Задачата е малку потешка.

Луа ни помогна овде, бидејќи може да биде тешко да се направи таква логика на ванила NGINX. Прво правиме барање до првиот сервер, видете дали е фотографијата таму, бидејќи потенцијално може да биде поставена, на пример, кај сосед, но сè уште не е пристигната овде. Ако фотографијата е таму, тоа е добро. Веднаш го даваме на клиентот и, евентуално, го кешираме.

Ако не е таму, ние едноставно поднесуваме барање до нашиот сосед и гарантирано ќе го добиеме од таму.

Тоа. повторно можеме да кажеме: може да има проблеми со перформансите, бидејќи има постојани кружни патувања - фотографијата е поставена, не е тука, поставуваме две барања наместо едно, ова треба полека да работи.

Во нашата ситуација, ова не функционира бавно.

Ние собираме еден куп метрика на овој систем, а условната паметна стапка на таков механизам е околу 95%. Оние. Заостанувањето на оваа резервна копија е мало, и поради тоа ние сме речиси загарантирани, откако фотографијата ќе биде поставена, ќе ја земеме првиот пат и нема да мора да одиме никаде двапати.

Значи, што друго имаме што е навистина кул?

Претходно, ја имавме главната резервна партиција и читавме од нив последователно. Оние. Секогаш прво баравме на главната, а потоа на резервната. Тоа беше еден потег.

Сега користиме читање од две машини одеднаш. Ние дистрибуираме барања користејќи Round Robin. Во мал процент од случаите правиме две барања. Но, генерално, сега имаме двојно повеќе залихи за читање од претходно. И товарот беше многу намален и на машините за испраќање и директно на машините за складирање, кои исто така ги имавме во тоа време.

Што се однесува до толеранцијата на грешки. Всушност, тоа е она за што главно се боревме. Со толеранција на грешки, овде сè излезе одлично.

Еден автомобил се расипува.

Нема проблем! Системски инженер можеби нема ни да се разбуди ноќе, ќе почека до утрото, ништо лошо нема да се случи.

Ако дури и ако оваа машина не успее, редот не е во функција, нема никакви проблеми, едноставно дневникот ќе се акумулира прво на живата машина, а потоа ќе се додаде во редот, а потоа на автомобилот што ќе стапи во функција по некое време.

Истото со одржувањето. Едноставно исклучуваме една од машините, рачно ја извлекуваме од сите базени, престанува да прима сообраќај, правиме некакво одржување, уредуваме нешто, потоа го враќаме во сервис и оваа резервна копија доста брзо се фаќа. Оние. дневно, застојот на еден автомобил достигнува за неколку минути. Ова е навистина многу малку. Со толеранција на грешки, пак велам, овде се е кул.

Кои заклучоци може да се извлечат од оваа шема за технолошки вишок?

Добивме толеранција на грешки.

Лесен за користење. Бидејќи машините имаат локални хард дискови, ова е многу попогодно од оперативна гледна точка за инженерите кои работат со него.

Добивме двоен додаток за читање.

Ова е многу добар бонус покрај толеранцијата на грешки.

Но, има и проблеми. Сега имаме многу покомплексен развој на некои карактеристики поврзани со ова, бидејќи системот на крајот стана 100% конзистентен.

Мораме, да речеме, во некоја заднина работа, постојано да размислуваме: „На кој сервер работиме сега?“, „Дали навистина има актуелна фотографија овде?“ итн. Се разбира, сето ова е завршено, а за програмерот кој пишува деловна логика е проѕирно. Но, сепак, се појави овој голем комплексен слој. Но, ние сме подготвени да го трпиме ова во замена за добрите што ги добивме од него.

И тука повторно настанува некаков конфликт.

Реков на почетокот дека складирањето на сè на локални хард дискови е лошо. И сега велам дека ни се допадна.

Да, навистина, со текот на времето ситуацијата многу се промени, а сега овој пристап има многу предности. Прво, добиваме многу поедноставно работење.

Второ, тоа е попродуктивно, бидејќи ги немаме овие автоматски контролери или врски со полиците на дискот.

Таму има огромно количество машини, а тоа се само неколку дискови што се собрани овде на машината во рација.

Но, постојат и недостатоци.

Ова е приближно 1,5 пати поскапо од користењето САН дури и по денешните цени. Затоа, решивме смело да не го претвораме целиот наш голем кластер во автомобили со локални хард дискови и решивме да оставиме хибридно решение.

Половина од нашите машини работат со хард дискови (добро, не половина - веројатно 30 проценти). А останатите се стари автомобили кои порано ја имаа првата шема за резервации. Едноставно ги ремонтиравме, бидејќи не ни требаа нови податоци или нешто друго, едноставно ги преместивме монтирањата од еден физички хост на два.

И сега имаме голема залиха на читање, и ја проширивме. Ако порано монтиравме едно складиште на една машина, сега монтираме четири, на пример, на еден пар. И работи добро.

Ајде да направиме кратко резиме за тоа што постигнавме, за што се боревме и дали успеавме.

Резултатите од

Имаме корисници - дури 33 милиони.

Имаме три точки на присуство - Прага, Мајами, Хонг Конг.

Тие содржат слој за кеширање, кој се состои од автомобили со брзи локални дискови (SSD), на кои работат едноставни машини од NGINX, неговиот access.log и Python демони, кои го обработуваат сето ова и управуваат со кешот.

Ако сакате, вие сте во вашиот проект, ако фотографиите не се толку критични за вас како што се за нас, или ако контролата на компромисот наспроти брзината на развојот и трошоците за ресурси е во друга насока за вас, тогаш можете безбедно да ја замените со CDN, модерните CDN се добро.

Следува слојот за складирање, на кој имаме кластери од парови машини кои прават резервна копија една на друга, датотеките асинхроно се копираат од една на друга секогаш кога ќе се променат.

Покрај тоа, некои од овие машини работат со локални хард дискови.

Некои од овие машини се поврзани со САН.

И, од една страна, поудобно е за користење и малку попродуктивно, од друга страна, погодно е во однос на густината на поставување и цена по гигабајт.

Ова е толку краток преглед на архитектурата на она што го добивме и како сето тоа се развива.

Уште неколку совети од капетанот, многу едноставни.

Прво, ако одеднаш одлучите дека итно треба да подобрите сè во вашата фотографска инфраструктура, прво измерете, бидејќи можеби ништо не треба да се подобри.

Дозволете ми да ви дадам пример. Имаме кластер на машини кои испраќаат фотографии од прилози во разговори, а шемата функционира таму од 2009 година и никој не страда од тоа. Сите се добро, на сите им се допаѓа сè.

За да измерите, прво обесете еден куп метрика, погледнете ги и потоа одлучете од што сте незадоволни и што треба да се подобри. За да го измериме ова, имаме кул алатка наречена Pinba.

Тоа ви овозможува да собирате многу детални статистики од NGINX за секое барање и кодови за одговор, како и распределба на времињата - што и да посакате. Има врски за секакви различни аналитички системи, а потоа можете убаво да го погледнете сето тоа.

Прво го измеривме, па го подобривме.

Понатаму. Ние го оптимизираме читањето со кеш, пишувањето со сердинг, но ова е очигледна точка.

Понатаму. Ако само сега почнувате да го градите вашиот систем, тогаш е многу подобро да правите фотографии како непроменливи датотеки. Затоа што веднаш губите цела класа проблеми со неважење на кешот, со тоа како логиката треба да ја најде точната верзија на фотографијата итн.

Да речеме дека сте поставиле стотина, потоа сте ја ротирале, направете го така што тоа е физички различна датотека. Оние. нема потреба да размислувате: сега ќе заштедам малку простор, ќе го напишам во истата датотека, ќе ја сменам верзијата. Ова секогаш не функционира добро и предизвикува многу главоболки подоцна.

Следна точка. За промена на големината на летот.

Претходно, кога корисниците поставуваа фотографија, веднаш сечевме цел куп големини за сите прилики, за различни клиенти и сите беа на дискот. Сега го напуштивме ова.

Оставивме само три главни големини: мала, средна и голема. Едноставно смалуваме сè друго од големината што е зад онаа што ни беше побарана во Uport, едноставно правиме намалување на скалата и му ја даваме на корисникот.

Процесорот на слојот за кеширање овде излегува дека е многу поевтин отколку ако постојано ги регенериравме овие големини на секое складирање. Да речеме дека сакаме да додадеме нова, ова ќе потрае еден месец - секаде изврши скрипта што ќе го направи сето ова уредно, без да го уништи кластерот. Оние. Ако имате можност да изберете сега, подобро е да направите што е можно помалку физички големини, но барем некоја дистрибуција да биде, да речеме, три. И сè друго може едноставно да се промени големината на летот користејќи готови модули. Сето тоа е многу лесно и достапно сега.

И зголемената асинхрона резервна копија е добра.

Како што покажа нашата практика, оваа шема работи одлично со одложено копирање на променетите датотеки.

Последната точка е исто така очигледна. Ако вашата инфраструктура сега нема такви проблеми, но има нешто што може да се скрши, дефинитивно ќе се скрши кога ќе стане малку повеќе. Затоа, подобро е да размислите за ова однапред и да не доживувате проблеми со тоа. Тоа е се што сакав да кажам.

Контакт

» bo0rsh201
» Блог на Badoo

Овој извештај е препис на еден од најдобрите говори на конференцијата на развивачи на системи со големо оптоварување HighLoad ++. Останува помалку од еден месец до конференцијата HighLoad++ 2017 година.

Веќе го имаме подготвено Конференциска програма, распоредот сега активно се формира.

Оваа година продолжуваме да ја истражуваме темата архитектура и скалирање:

• Како да опслужите милијарда корисници и да обезбедите терабит сообраќај / Игор Василиев
• Како да ја преработите базата на лични пораки VKontakte од нула и да мигрирате во неа без прекини / Дмитриј Егоров
• Смрт од продажба: како Yandex.Money се обиде да забрза до црниот петок и да преживее / Анатолиј Пласковски
• Архитектура толерантна за грешки на предниот систем на банката / Роман Шеховцов, Алексеј Громатчиков
• Архитектура на платен систем: речиси претпријатие / Филип Делгадо

Ние, исто така, користиме некои од овие материјали во нашиот онлајн курс за обука за развој на системи со големо оптоварување HighLoad.Водич е синџир од специјално избрани писма, статии, материјали, видеа. Нашиот учебник веќе содржи повеќе од 30 уникатни материјали. Поврзете се!

Извор: www.habr.com