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

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

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

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

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

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

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

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

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

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

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

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

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

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

Беше около 2009 година. Доставяха се машини, доставяха се...

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

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

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

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

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

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

И в края на краищата решихме да използваме така наречената Storage Area Network.

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

Това решение имаше очевидни предимства. Това е SHD. То е насочено към съхраняването на снимки. Оказва се по-евтино, отколкото просто да настроим машини с твърди дискове.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Трябва по някакъв начин да определим, кои заявки за кои снимки и къде да насочим.

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

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

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

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

Т.е. при 100% запросах, например, на какой-то «example_url», они всегда будут поступать на сървър с индекс «2», и кэш ще се използва максимално ефективно.

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

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

Добавяме.

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

Тази опция също не е подходяща за нас.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И пунктът, произтичащ от предходния -

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

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

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

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

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

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

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

Годината е 2013.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В нашия случай това не работи бавно.

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

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

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

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

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

Една машина спира да работи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

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

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

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

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

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

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

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

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

Следват няколко съвета от шефа, напълно прости.

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

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

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

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

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

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

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

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

Следващата точка. За resize на момента.

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

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

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

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

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

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

Контакти

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

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

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

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

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

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

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