Архитектура на съхранение и предаване на фотографии в Badoo

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

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

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

А сега, нека да започнем.

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

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

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

Badoo исторически — и сега, и тогава (времето, когато всичко започваше) — работи на собствени сървъри, в нашите собствени дата центрове. Затова този вариант беше оптимален за нас.

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

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

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

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

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

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

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

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

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

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

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

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

И в крайна сметка стигнахме до решението да използваме т.нар. Storage Area Network.

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

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

Второто предимство.

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

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

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

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

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

И тук всичко работи в наша полза.

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

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

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

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

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

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

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

Как изглежда това? Потребителят изпраща запитване за снимка. NGINX първо я търси в локалния кеш. Ако я няма, прави просто proxy_pass на нашия storage, сваля снимката оттам и я дава на потребителя.

Но това е много банално и неясно какво се случва от вътре. Работи по следния начин.

Кешът е логически разделен на три слоя. Когато казвам «три слоя», не значи, че там има сложна система. Не, условно това са просто три директории в файловата система:

1. Това е буфер, където попадат току-що изтеглените от proxy снимки.
2. Това е горещ кеш, в който се съхраняват активно търсените в момента снимки.
3. И студен кеш, в който постепенно снимките се изтласкват от горещия, когато получават по-малко запитвания.

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

Nginx записва на RAMDisk access.log на все заявки, в който указва относителния път до снимката, която в момента обработва, и коя секция я е обслужила. Т.е. там може да пише "снимка 1" и след това или буфер, или горещ кеш, или студен кеш, или прокси.

В зависимост от това, трябва да вземем решение какво да правим със снимката.

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

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

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

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

За да се съхранява снимката веднага при проксирането в буфера, използваме директивата proxy_store, а буферът също е RAMDisk, т.е. за потребителя това работи много бързо. Това е свързано с вътрешността на кеширащия сървър.

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

Да предположим, че има клъстер от двадесет storage машини и три кеширащи сървъра (така се е получило).

Нужно е по някакъв начин да определим кои заявки за кои снимки и къде да насочим.

Най-простият вариант е Round Robin. Или да го правим на случаен принцип?

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

Нужно е по някакъв начин еднозначно да определим на кой сървър да насочим коя заявка.

Има прост начин. Взимаме хаш от URL адреса или хаша от нашия шардов ключ, който е в URL адреса, и го делим на брой сървъри. Ще работи? Да.

Т.е. имаме сто процента request, например, за някакъв «example_url» винаги ще се приземява на сървър с индекс «2», и кешът ще се използва максимално ефективно.

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

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

Добавяме.

Сега всичко вече се разделя на четири, а не на три. Така че почти всички ключове, които преди бяха, почти всички URL адреси сега живеят на други сървъри. Целият кеш се инвалидизира просто за миг. Всички заявки се насочиха към нашия кластер-storage, той се обърка, отказа ни обслужване и недоволните потребители. Не искаме да се случи така.

Този вариант също не ни подхожда.

Т. е. какво трябва да направим? Трябва по някакъв начин ефективно да използваме кеша, постоянно да насочваме един request към един и същ сървър, но същевременно да сме устойчиви на решардинг. И такова решение има, то не е толкова сложно. Нанася се consistent hashing.

Как изглежда това?

Вземаме някаква функция от шардинг ключа и я разстиламе на окръжността. Т.е. в точка 0 се съединяват минималните и максималните й стойности. След това на тази същата окръжност поставяме всички наши сървъри по следния начин:

Всеки сървър се определя с една точка, а секторът, който следва до него по часовниковата стрелка, съответно, се обслужва от този хост. Когато получаваме заявки, веднага виждаме, че например заявка А — има такъв хеш — и се обслужва от сървър 2. Заявка Б — от сървър 3. И така нататък.

Какво се случва в тази ситуация при решардинг?

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

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

Единственият въпрос остава при откази. Да предположим, че имаме някаква машина, която е излязла от строя.

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

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

На пръв поглед, тук няма нищо сложно. Но този метод за управление на кеша ни даде хитрейти от порядъка на 98%. Т.е. от тези 80 хиляди заявки в секунда, само 1600 достигат до хранилищата, и това е напълно нормално натоварване, те спокойно го понесат, винаги имаме резерв.

Разположихме тези сървъри в трите ни DC и получихме три точки на присъствие — Прага, Маями и Хонконг.

Т.е. те са повече-мене локално разположени към всеки от нашите целеви пазари.

И като приятно допълнение получихме този кеширащ прокси, на който CPU всъщност е неактивен, тъй като за отдаване на съдържание не е толкова нужен. И там с помощта на NGINX+ Lua реализирахме много утилитарна логика.

Например, можем експериментираме с webp или progressive jpeg (това са ефективни съвременни формати), да видим как това влияе на трафика, да вземем решения за определени държави и т.н.; да правим динамичен resize или crop на снимки в реално време.

Това е добър use case, когато имате, например, мобилно приложение, което показва снимки, а мобилното приложение не иска да харчи CPU на клиента за да изиска голяма снимка и след това да я ресайзва до определен размер, за да я постави във вьюшката. Можем просто динамично да посочим в URL-а определени параметри в UPort, и фотокешът сам ще ресайзне снимката. Обикновено той ще избере размера, който имаме физически на диска, най-близкия до искания, и ще го задаунскеллира в конкретни координати.

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

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

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

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

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

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

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

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

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

И точка, която произтича от предишната –

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

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

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

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

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

Това е по отношение на предоставянето на снимки.

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

2013 година минаваше.

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

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

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

На първо място, самата Storage Area Network (SAN), която може да откаже.

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

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

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

Така че имаме три точки на отказ.

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

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

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

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

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

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

Просто добавихме втори дял.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Това, което беше -

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

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

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

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

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

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

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

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

С задачата е малко по-сложно.

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

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

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

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

Събираме множество метрики по тази система, а условният хитрейт на такъв механизъм е около 95%. Т.е. закъснението на този backup е малко, и затова практически гарантирано, след като снимката е била качена, я получаваме от първия път и не правим два пъти запитвания.

По този начин какво още получихме и какво е много готино?

По-рано имахме основни backup-дялове и четяхме от тях последователно. Т.е. винаги първо търсехме на основния, а после на backup-а. Това беше едно ходене.

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

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

Една машина излиза от строя.

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

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

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

Какви изводи можем да направим от тази схема за резервиране?

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

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

Получихме двойна резервна мощност за четене.

Това е много добра добавка към отказоустойчивостта.

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

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

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

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

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

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

Има огромна машина, а тук просто става въпрос за няколко диска, събрани в RAID на самия сървър.

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

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

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

И сега имаме голямо предимство в четенето, и ние увеличихме капацитета. Ако преди на една машина монтирахме един storage, сега на един комплект монтираме четири, например. И това работи нормално.

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

Итог

Имаме потребители — общо 33 млн.

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

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

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

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

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

Част от тези машини са свързани със SAN.

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

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

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

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

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

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

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

Първо измервали — после подобрили.

Следваща точка. Оптимизираме четенето с кеш, а записването — с шардване, но това е очевиден пункт.

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

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

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

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

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

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

А инкременталният асинхронен бекъп — това е добре.

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

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

Контакти

» bo0rsh201
» Блог на компанията Badoo

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

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

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

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

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

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