Архитектура за съхранение и споделяне на снимки в Badoo

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

Badoo е най-големият сайт за запознанства в света. В момента имаме около 330 милиона регистрирани потребители по целия свят. Но това, което е много по-важно в контекста на днешния ни разговор е, че съхраняваме около 3 петабайта потребителски снимки. Всеки ден нашите потребители качват около 3,5 милиона нови снимки, а натоварването при четене е около 80 хиляди заявки в секунда. Това е доста за нашия бекенд и понякога има трудности с това.

Ще говоря за дизайна на тази система, която съхранява и изпраща снимки като цяло, и ще я разгледам от гледна точка на разработчика. Ще има кратка ретроспекция за развитието му, където ще очертая основните етапи, но ще говоря по-подробно само за решенията, които използваме в момента.

Сега да започваме.

Както казах, това ще бъде ретроспекция и за да започнем отнякъде, нека вземем най-обикновения пример.

Имаме обща задача, трябва да приемаме, съхраняваме и изпращаме потребителски снимки. В тази форма задачата е обща, можем да използваме всичко:

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

В исторически план Badoo - както сега, така и тогава (по времето, когато беше само в начален стадий) - живее на свои собствени сървъри, в нашите собствени DC. Следователно този вариант беше оптимален за нас.

Просто взехме няколко машини, нарекохме ги „снимки“ и получихме клъстер, който съхранява снимки. Но изглежда, че нещо липсва. За да работи всичко това, трябва по някакъв начин да определим на коя машина какви снимки ще съхраняваме. И тук също няма нужда да отваряме Америка.

Добавяме поле към нашето хранилище с информация за потребителите. Това ще бъде ключът за шардинг. В нашия случай го нарекохме place_id и този идентификатор на място сочи към мястото, където се съхраняват потребителски снимки. Правим карти.

На първия етап това може да стане дори ръчно - казваме, че снимка на този потребител с такова място ще кацне на такъв сървър. Благодарение на тази карта ние винаги знаем, когато потребител качи снимка, къде да я запазим и знаем откъде да я дадем.

Това е абсолютно тривиална схема, но има доста значителни предимства. Първото е, че е просто, както казах, а второто е, че с този подход можем лесно да мащабираме хоризонтално, като просто доставяме нови коли и ги добавяме към картата. Не е нужно да правите нищо друго.

Така беше и при нас известно време.

Това беше около 2009 г. Доставиха коли, доставиха...

И в един момент започнахме да забелязваме, че тази схема има някои недостатъци. Какви са недостатъците?

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

И второ. Това е нетипична конфигурация на машини, тъй като такива машини трудно се използват повторно в някои други клъстери; те са доста специфични, т.е. те трябва да са слаби като производителност, но в същото време с голям твърд диск.

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

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

По това време цената беше много висока и трябваше да потърсим алтернативи. Тези. трябваше по някакъв начин да оползотворим по-добре както пространството в центровете за данни, така и физическите сървъри, на които се намира всичко това. И нашите системни инженери започнаха голямо проучване, в което прегледаха куп различни опции. Те също така разгледаха клъстерни файлови системи като PolyCeph и Luster. Имаше проблеми с производителността и доста трудна работа. Те отказаха. Опитахме се да монтираме целия набор от данни чрез NFS на всяка кола, за да го увеличим по някакъв начин. Четенето също вървеше зле, опитахме различни решения от различни доставчици.

И в крайна сметка се спряхме на така наречената Storage Area Network.

Това са големи SHD, които са специално проектирани за съхранение на големи количества данни. Те представляват рафтове с дискове, които се монтират на крайните машини за оптичен изход. Че. имаме някакъв набор от машини, доста малък, и тези SHD, които са прозрачни за нашата изпращаща логика, т.е. за нашия nginx или някой друг да обслужва заявки за тези снимки.

Това решение имаше очевидни предимства. Това е SHD. Предназначен е за съхранение на снимки. Това излиза по-евтино от простото оборудване на машини с твърди дискове.

Втори плюс.

Това е, че капацитетът е станал много по-голям, т.е. можем да поберем много повече място за съхранение в много по-малък обем.

Но имаше и недостатъци, които се появиха доста бързо. С нарастването на броя на потребителите и натоварването на тази система започнаха да възникват проблеми с производителността. И проблемът тук е съвсем очевиден - всеки SHD, предназначен да съхранява много снимки в малък обем, като правило страда от интензивно четене. Това всъщност е вярно за всяко облачно хранилище или нещо друго. Сега нямаме идеално хранилище, което би било безкрайно мащабируемо, можете да поставите всичко в него и то би понасяло много добре четене. Особено случайни четения.

Какъвто е случаят с нашите снимки, тъй като снимките се изискват непоследователно и това значително ще повлияе на тяхното представяне.

Дори според днешните данни, ако получим някъде повече от 500 RPS за снимки на машина, към която е свързано хранилище, проблемите вече започват. И това беше достатъчно лошо за нас, тъй като броят на потребителите расте, нещата само ще се влошат. Това трябва да се оптимизира по някакъв начин.

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

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

Вече казах в първия слайд: имаме 80 хиляди заявки за четене в секунда със само 3,5 милиона качвания на ден. Тоест това е разлика от три порядъка. Очевидно е, че четенето трябва да се оптимизира и на практика е ясно как.

Има още един малък момент. Спецификата на услугата е такава, че човек се регистрира, качва снимка, след което започва активно да гледа други хора, да ги харесва и активно да се показва на други хора. След това той намира половинка или не намира половинка, зависи как ще се развие, и спира да използва услугата за известно време. В този момент, когато го използва, снимките му са много горещи - търсят се, много хора ги гледат. Веднага след като спре да прави това, доста бързо той се отказва от толкова много излагане на други хора, колкото е имал преди, и снимките му почти никога не се искат.

Тези. Имаме много малък набор от горещи данни. Но в същото време има много заявки за него. И напълно очевидно решение тук е да добавите кеш.

Кеш с LRU ще реши всичките ни проблеми. Какво правим?

Добавяме още един сравнително малък пред нашия голям клъстер със съхранение, който се нарича фотокешове. Това по същество е просто кеширащ прокси.

Как работи отвътре? Тук е нашият потребител, тук е хранилището. Всичко си е както преди. Какво добавяме между тях?

Това е просто машина с физически локален диск, който е бърз. Това е с SSD например. И някакъв вид локален кеш се съхранява на този диск.

Как изглежда? Потребителят изпраща заявка за снимка. NGINX го търси първо в локалния кеш. Ако не, тогава просто proxy_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 или progressive jpeg (това са ефективни съвременни формати), да видим как се отразява на трафика, да вземем някои решения, да го активираме за определени държави и т.н.; направете динамично преоразмеряване или изрязване на снимки в движение.

Това е добър случай на използване, когато например имате мобилно приложение, което показва снимки, и мобилното приложение не иска да губи процесора на клиента, за да поиска голяма снимка и след това да я преоразмери до определен размер, за да я постави в гледката. Можем просто динамично да посочим някои параметри в условния URL адрес на UPort и фотокешът ще преоразмери самата снимка. Като правило, той ще избере размера, който физически имаме на диска, възможно най-близък до искания, и ще го намали в определени координати.

Между другото, направихме публично достъпни видеозаписи от последните пет години на конференцията на разработчиците на системи с високо натоварване HighLoad ++. Гледайте, научете, споделяйте и се абонирайте YouTube канал.

Можем също да добавим много продуктова логика там. Например, можем да добавяме различни водни знаци, използвайки URL параметри, можем да размазваме, замъгляваме или пикселизираме снимки. Това е, когато искаме да покажем снимка на човек, но не искаме да показваме лицето му, това работи добре, всичко е реализирано тук.

Какво получихме? Имаме три точки на присъствие, добра честота на трикове и в същото време нямаме неактивен процесор на тези машини. Сега той, разбира се, стана по-важен от преди. Трябва да си дадем по-здрави коли, но си заслужава.

Това се отнася за връщането на снимки. Тук всичко е съвсем ясно и очевидно. Мисля, че не съм открил Америка, почти всеки CDN работи по този начин.

И най-вероятно един сложен слушател може да има въпрос: защо просто не промените всичко на CDN? Би било почти същото; всички съвременни CDN могат да направят това. И има редица причини.

Първият е снимките.

Това е една от ключовите точки на нашата инфраструктура и се нуждаем от възможно най-голям контрол върху нея. Ако това е някакъв вид решение от доставчик на трета страна и нямате никаква власт над него, ще ви бъде доста трудно да живеете с него, когато имате голям набор от данни и когато имате много голям поток от потребителски заявки.

Нека ви дам един пример. Сега, с нашата инфраструктура, можем, например, в случай на някакви проблеми или подземни удари, да отидем до машината и да бъркаме там, относително казано. Можем да добавим колекцията от някои показатели, от които се нуждаем само, можем да експериментираме по някакъв начин, да видим как това се отразява на графиките и т.н. Сега в този кеширащ клъстер се събират много статистически данни. И ние периодично го разглеждаме и прекарваме дълго време в изследване на някои аномалии. Ако беше от страната на CDN, щеше да е много по-трудно да се контролира. Или например, ако се случи някакъв инцидент, знаем какво се е случило, знаем как да живеем с него и как да го преодолеем. Това е първият извод.

Второто заключение също е по-скоро историческо, тъй като системата се развива дълго време и имаше много различни бизнес изисквания на различни етапи и те не винаги се вписват в концепцията на CDN.

И точката, която следва от предишната е

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

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

И във вашия случай, ако имате някакви специфични бизнес изисквания, можете съвсем лесно да реализирате това, което ви показах сами. И това ще работи перфектно с подобен профил на натоварване.

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

И съвременните CDN имат почти всичко, за което ви казах сега. С изключение на плюс или минус някои функции.

Тук става въпрос за раздаване на снимки.

Нека сега да преминем малко напред в нашата ретроспекция и да поговорим за съхранението.

2013 г. си отиваше.

Добавени бяха кеширащи сървъри, проблемите с производителността изчезнаха. Всичко е наред. Наборът от данни нараства. Към 2013 г. имахме около 80 сървъра, свързани към хранилище, и около 40 кеширащи във всеки DC. Това са 560 терабайта данни на всеки DC, т.е. около един петабайт общо.

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

В тази диаграма, която е начертана - със SAN, с машини и кешове, свързани към него - има много точки на отказ. Ако вече се бяхме сблъсквали с повредата на кеширащите сървъри преди, всичко беше повече или по-малко предвидимо и разбираемо, но от страна на хранилището всичко беше много по-лошо.

Първо, самата мрежа за съхранение (SAN), която може да се провали.

Второ, той е свързан чрез оптика към крайните машини. Възможно е да има проблеми с оптични карти и свещи.

Разбира се, няма толкова много от тях, колкото при самата SAN, но въпреки това това също са точки на провал.

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

Общо имаме три точки на провал.

Освен това, в допълнение към точките на повреда, има тежка поддръжка на самото хранилище.

Това е сложна многокомпонентна система и на системните инженери може да им е трудно да работят с нея.

И последната, най-важна точка. Ако възникне повреда в някоя от тези три точки, имаме различен от нула шанс да загубим потребителски данни, тъй като файловата система може да се срине.

Да приемем, че нашата файлова система е повредена. Първо, възстановяването му отнема много време - може да отнеме седмица с голямо количество данни. И второ, в крайна сметка най-вероятно ще се окажем с куп неразбираеми файлове, които ще трябва по някакъв начин да бъдат комбинирани в потребителски снимки. И рискуваме да загубим данни. Рискът е доста голям. И колкото по-често се случват такива ситуации и колкото повече проблеми възникват в цялата тази верига, толкова по-висок е този риск.

Трябваше да се направи нещо по въпроса. И решихме, че просто трябва да архивираме данните. Това всъщност е очевидно решение и добро. какво направихме

Ето как изглеждаше нашият сървър, когато беше свързан към хранилището преди. Това е една основна секция, това е просто блоково устройство, което всъщност представлява стойка за отдалечено съхранение чрез оптика.

Току-що добавихме втори раздел.

Поставихме второ хранилище до него (за щастие, не е толкова скъпо от гледна точка на пари) и го нарекохме резервен дял. Той също е свързан по оптика и се намира на същата машина. Но трябва по някакъв начин да синхронизираме данните между тях.

Тук просто правим асинхронна опашка наблизо.

Тя не е много заета. Знаем, че нямаме достатъчно записи. Опашката е просто таблица в MySQL, в която са написани редове като „трябва да направите резервно копие на тази снимка“. При всяка промяна или качване, ние копираме от основния дял в резервно копие, като използваме асинхронен или просто някакъв фонов работник.

И по този начин винаги имаме две последователни секции. Дори ако една част от тази система се повреди, винаги можем да променим основния дял с резервно копие и всичко ще продължи да работи.

Но поради това натоварването при четене се увеличава значително, защото... в допълнение към клиентите, които четат от основния раздел, защото първо гледат снимката там (там е по-скорошна) и след това я търсят в архива, ако не са я намерили (но NGINX прави само това), нашата система също е плюс резервно копие сега чете от основния дял. Не че това беше пречка, но не исках да увеличавам натоварването, по същество, просто така.

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

Как работи сега.

Потребителят качва снимка в буфера, след което в опашката се хвърля събитие, което показва, че трябва да се копира в две секции. Копира се и снимката живее в буфера известно време (да речем един ден) и едва след това се изчиства от там. Това значително подобрява потребителското изживяване, тъй като потребителят качва снимка, като правило заявките започват да следват незабавно или той сам актуализира страницата и я опреснява. Но всичко зависи от приложението, което прави качването.

Или, например, други хора, на които той започна да се показва, веднага изпращат заявки след тази снимка. Все още не е в кеша; първата заявка се появява много бързо. По същество същото като от кеша за снимки. Бавното съхранение изобщо не е включено в това. И когато един ден по-късно той бъде изчистен, той вече е или кеширан на нашия слой за кеширане, или най-вероятно вече никой не се нуждае от него. Тези. Потребителското изживяване тук е нараснало много добре поради такива прости манипулации.

Е, и най-важното: спряхме да губим данни.

Да кажем, че спряхме потенциално загуба на данни, защото всъщност не сме ги загубили. Но имаше опасност. Виждаме, че това решение, разбира се, е добро, но е малко като изглаждане на симптомите на проблема, вместо да го реши напълно. И някои проблеми остават тук.

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

Второ, все още има проблеми със SAN, тежката им поддръжка и т.н. Не че беше критичен фактор, но исках да се опитам някак да живея без него.

И направихме третата версия (всъщност втората всъщност) - резервационната версия. Как изглеждаше?

Ето какво беше -

Основните ни проблеми са с факта, че това е физически хост.

Първо, ние премахваме SAN, защото искаме да експериментираме, искаме да опитаме само локални твърди дискове.

Това е вече 2014-2015 г. и по това време ситуацията с дисковете и капацитета им в един хост стана много по-добра. Решихме защо да не опитаме.

И тогава ние просто вземаме нашия резервен дял и го прехвърляме физически на отделна машина.

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

Защо това работи добре е, защото имаме малко записи. Тези. ако писането беше сравнимо с четенето, може би щяхме да имаме някакъв вид мрежови разходи и проблеми. Има малко писане, много четене - този метод работи добре, т.е. Рядко копираме снимки между тези два сървъра.

Как става това, ако погледнете малко по-подробно.

Качване. Балансьорът просто избира произволни хостове с чифт и качва в него. В същото време той естествено прави проверки на здравето и се грижи колата да не падне. Тези. той качва снимки само на жив сървър и след това чрез асинхронна опашка всичко се копира на неговия съсед. С качването всичко е изключително просто.

Задачата е малко по-трудна.

Lua ни помогна тук, защото може да бъде трудно да се направи такава логика на vanilla NGINX. Първо правим заявка до първия сървър, вижте дали снимката е там, защото потенциално може да бъде качена, например, на съсед, но все още не е пристигнала тук. Ако снимката е там, това е добре. Веднага го даваме на клиента и евентуално го кешираме.

Ако го няма, просто правим заявка до съседа и гарантирано ще го получим оттам.

Че. отново можем да кажем: може да има проблеми с производителността, защото има постоянни двупосочни пътувания - снимката беше качена, не е тук, правим две заявки вместо една, това трябва да работи бавно.

В нашата ситуация това не работи бавно.

Ние събираме куп показатели в тази система и условната интелигентна скорост на такъв механизъм е около 95%. Тези. Закъснението на това архивиране е малко и поради това сме почти сигурни, че след като снимката бъде качена, ще я направим от първия път и няма да се налага да ходим никъде два пъти.

И така, какво още имаме, което е наистина страхотно?

Преди това имахме основния резервен дял и четехме от тях последователно. Тези. Винаги първо търсихме в основния, а след това в резервния. Беше едно движение.

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

Що се отнася до толерантността към грешки. Всъщност за това основно се борихме. С толерантността към грешки тук всичко се оказа страхотно.

Една кола се разваля.

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

Ако дори и тази машина да се повреди, опашката не работи, също няма проблеми, логът просто ще се натрупа първо на живата машина, след което ще бъде добавен към опашката и след това към колата, която ще влезте в действие след известно време.

Същото нещо и с поддръжката. Просто изключваме една от машините, ръчно я изваждаме от всички пулове, тя спира да получава трафик, извършваме някаква поддръжка, редактираме нещо, след това я връщаме в услуга и този архив наваксва доста бързо. Тези. на ден, престоят на една кола се наваксва за няколко минути. Това наистина е много малко. С толерантността към грешки, пак казвам, тук всичко е готино.

Какви изводи могат да се направят от тази схема за съкращения?

Имаме толерантност към грешки.

Лесен за използване. Тъй като машините имат локални твърди дискове, това е много по-удобно от оперативна гледна точка за инженерите, които работят с нея.

Получихме двойна надбавка за четене.

Това е много добър бонус в допълнение към толерантността към грешки.

Но има и проблеми. Сега имаме много по-сложно развитие на някои функции, свързани с това, защото системата е станала 100% в крайна сметка последователна.

Трябва, да речем, в някаква фонова работа постоянно да мислим: „На какъв сървър работим сега?“, „Наистина ли има актуална снимка тук?“ и т.н. Всичко това, разбира се, е приключило и за програмиста, който пише бизнес логика, е прозрачно. Но въпреки това се появи този голям сложен слой. Но ние сме готови да се примирим с това в замяна на екстрите, които получихме от него.

И тук отново възниква някакъв конфликт.

Казах в началото, че съхраняването на всичко на локални твърди дискове е лошо. И сега казвам, че ни хареса.

Да, наистина с течение на времето ситуацията се промени много и сега този подход има много предимства. Първо, получаваме много по-проста работа.

Второ, това е по-продуктивно, защото нямаме тези автоматични контролери или връзки към рафтове с дискове.

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

Но има и недостатъци.

Това е приблизително 1,5 пъти по-скъпо от използването на SAN дори при днешните цени. Затова решихме да не преобразуваме смело целия си голям клъстер в автомобили с локални твърди дискове и решихме да оставим хибридно решение.

Половината от нашите машини работят с твърди дискове (е, не половината - вероятно 30 процента). А останалите са стари коли, които са били с първа резервационна схема. Ние просто ги премонтирахме, тъй като нямахме нужда от нови данни или нещо друго, просто преместихме монтажите от един физически хост на два.

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

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

Резултати от

Имаме потребители - цели 33 милиона.

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

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

Ако желаете, вие сте във вашия проект, ако снимките не са толкова критични за вас, колкото са за нас, или ако компромисът между контрола и скоростта на разработка и разходите за ресурси е в другата посока за вас, тогава можете спокойно да го замените с CDN съвременните CDN се справят добре.

След това идва слоят за съхранение, на който имаме клъстери от двойки машини, които се архивират взаимно, файловете се копират асинхронно от един на друг, когато се променят.

Освен това някои от тези машини работят с локални твърди дискове.

Някои от тези машини са свързани към SAN.

И, от една страна, той е по-удобен за използване и малко по-продуктивен, от друга страна, той е удобен по отношение на плътността на разположение и цената на гигабайт.

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

Още няколко съвета от капитана, много прости.

Първо, ако изведнъж решите, че спешно трябва да подобрите всичко във вашата фото инфраструктура, първо измерете, защото може би нищо не трябва да се подобрява.

Нека ви дам един пример. Имаме клъстър от машини, които изпращат снимки от прикачени файлове в чатове и там схемата работи от 2009 г. и никой не страда от това. Всички са добре, всички харесват всичко.

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

Позволява ви да събирате много подробни статистики от NGINX за всяка заявка и кодове за отговор, както и разпределение на времето - каквото искате. Той има обвързвания към всякакви различни аналитични системи и след това можете да го разгледате красиво.

Първо го измерихме, после го подобрихме.

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

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

Да приемем, че сте качили сто, след това сте го завъртели, направете го така, че да е физически различен файл. Тези. няма нужда да мисля: сега ще спестя малко място, ще го запиша в същия файл, ще променя версията. Това винаги не работи добре и причинява много главоболия по-късно.

Следваща точка. Относно преоразмеряването в движение.

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

Оставихме само три основни размера: малък, среден и голям. Ние просто намаляваме мащаба на всичко останало от размера, който е зад този, който ни беше поискан от Uport, ние просто намаляваме мащаба и го даваме на потребителя.

Процесорът на кеширащия слой тук се оказва много по-евтин, отколкото ако постоянно регенерираме тези размери на всяко хранилище. Да кажем, че искаме да добавим нов, това ще отнеме един месец - стартирайте скрипт навсякъде, който ще направи всичко това спретнато, без да унищожава клъстера. Тези. Ако имате възможност да избирате сега, по-добре е да направите възможно най-малко физически размери, но така че поне някакво разпределение да е три. И всичко останало може просто да бъде преоразмерено в движение с помощта на готови модули. Сега всичко е много лесно и достъпно.

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

Както показа нашата практика, тази схема работи чудесно със забавено копиране на променени файлове.

Последната точка също е очевидна. Ако инфраструктурата ви няма такива проблеми сега, но има нещо, което може да се счупи, определено ще се счупи, когато стане малко повече. Ето защо е по-добре да помислите за това предварително и да не изпитвате проблеми с него. Това е всичко, което исках да кажа.

Контакти

» bo0rsh201
» Блог на Badoo

Този доклад е препис на една от най-добрите речи на конференцията на разработчиците на системи с високо натоварване HighLoad ++. Остава по-малко от месец до конференцията HighLoad++ 2017.

Вече го имаме готово Програма на конференцията, сега графикът се формира активно.

Тази година продължаваме да изследваме темата за архитектурите и мащабирането:

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

Ние също използваме някои от тези материали в нашия онлайн курс за обучение за разработване на системи с високо натоварване HighLoad.Guide е верига от специално подбрани писма, статии, материали, видеоклипове. Нашият учебник вече съдържа повече от 30 уникални материала. Свържете се!

Източник: www.habr.com