Как Badoo постигна способността да изобразява 200k снимки в секунда

Съвременната мрежа е почти немислима без медийно съдържание: почти всяка баба има смартфон, всеки е в социалните мрежи, а прекъсването на услугите струва скъпо на компаниите. На вашето внимание препис от историята на компанията Badoo за това как е организирала доставката на снимки с помощта на хардуерно решение, какви проблеми с производителността е срещнала в процеса, какво ги е причинило и как тези проблеми са били решени с помощта на софтуерно решение, базирано на Nginx, като същевременно се гарантира толерантност към грешки на всички нива (видео). Благодарим на авторите на историята Олег Санис Ефимова и Александра Димова, които споделиха своя опит на конференцията Работен ден 4.

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

Естествено, веднага възникна въпросът: ако някой от нашите сървъри падне и стане недостъпен, каква част от трафика губим? Разгледахме какво има на пазара и решихме да купим едно желязо, за да реши всичките ни проблеми. Изборът падна върху решението на мрежовата компания F5 (която, между другото, купи NGINX, Inc не толкова отдавна): BIG-IP Local Traffic Manager.

Какво прави това парче желязо (LTM): това е железен рутер, който прави железен излишък на своите външни портове и ви позволява да маршрутизирате трафик въз основа на топологията на мрежата, на някои настройки и прави проверки на здравето. За нас беше важно това парче желязо да може да се програмира. Съответно бихме могли да опишем логиката на това как снимките на определен потребител са върнати от конкретен кеш. Как изглежда? Има част от хардуера, който търси в интернет един домейн, един ip, прави ssl разтоварване, анализира http заявки, избира номер на кеша от IRule, къде да отиде, и пуска трафика там. В същото време прави проверки на здравето и в случай на недостъпност на дадена машина направихме така, че трафикът да отива към един резервен сървър по това време. От гледна точка на конфигурацията, разбира се, има някои нюанси, но като цяло всичко е доста просто: предписваме карта, определен номер съответства на нашия IP в мрежата, казваме, че ще слушаме на портове 80 и 443, ние казваме, че ако сървърът е недостъпен, тогава трябва да позволите на трафика да отиде към архива, в този случай, 35-ия, и ние описваме куп логика как тази архитектура трябва да бъде разглобена. Единственият проблем беше, че езикът, на който се програмира желязото, е Tcl. Ако някой изобщо си спомня това ... този език е по-скоро само за писане, отколкото език, удобен за програмиране:

Какво получихме? Имаме хардуер, който осигурява висока наличност на нашата инфраструктура, маршрутизира целия ни трафик, осигурява проверки на здравето и просто работи. Освен това работи доста дълго време: през последните 10 години няма оплаквания за него. В началото на 2018 г. вече изобразявахме около 80 хиляди снимки в секунда. Това е някъде около 80 гигабита трафик от двата ни центъра за данни.

Въпреки това…

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

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

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

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

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

Тъй като задачата звучеше като „направете нещо възможно най-бързо и с помощта на хардуера, който имаме“, първото нещо, което си помислихме, беше просто да премахнем някои не най-мощните машини отпред, да поставим там Nginx, с който знаем как да работи и се опитайте да приложите същата логика, която правеше парчето желязо. Тоест всъщност оставихме нашата част от хардуера, инсталирахме още 4 сървъра, които трябваше да конфигурираме, направихме външни домейни за тях по аналогия с това как беше преди 10 години ... Загубихме малко в наличността, ако тези машини паднаха , но все пак по-малко реши проблема на нашите потребители на местно ниво.

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

Сядаме да пишем конфигурации. Първоначално изглеждаше, че всичко е много просто, но, за съжаление, е много трудно да се намерят ръководства за всяка задача. Затова не ви съветваме просто да търсите в Google „как да конфигурирате Nginx за снимки“: по-добре е да се обърнете към официалната документация, която ще покаже кои настройки трябва да бъдат докоснати. Но е по-добре сами да изберете конкретен параметър. Е, тогава всичко е просто: описваме сървърите, които имаме, описваме сертификатите ... Но най-интересното е всъщност самата логика на маршрутизиране.

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

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

За да избегнем това, направихме две неща:

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

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

За съжаление, това също не е всичко, защото буквално първите две седмици от работата на тази схема показаха, че проверката на състоянието на TCP също е ненадеждно нещо: не Nginx или Nginx в D-състояние може да бъде стартиран на сървъра нагоре по веригата, а в в този случай ядрото ще приеме връзката, проверката на здравето ще премине, но няма да работи. Затова веднага го заменихме с http's health-check, направихме специфичен, който ако вече дава 200, значи всичко работи в този скрипт. Можете да направите допълнителна логика - например, в случай на кеширащи сървъри, проверете дали файловата система е правилно монтирана:

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

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

И буквално добавяйки четири сървъра, получихме това: заменихме част от товара - премахнахме от LTM към тези сървъри, внедрихме същата логика там, използвайки стандартен хардуер и софтуер, веднага получихме бонус, че тези сървъри могат да бъдат мащабирани, защото те могат да бъдат просто сложете толкова, колкото ви е необходимо. Е, единственият минус е, че загубихме висока наличност за външни потребители. Но по това време трябваше да пожертвам това, защото беше необходимо незабавно да реша проблема. И така, премахнахме част от натоварването, по това време беше около 40%, LTM се подобри и буквално две седмици след началото на проблема започнахме да даваме не 45k заявки в секунда, а 55k. Всъщност ние нараснахме с 20% - това очевидно е трафикът, който не дадохме на потребителя. И след това започнаха да мислят как да решат останалия проблем - да осигурят висока външна наличност.

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

Като начало от какво се състои Keepalived. Първият е протоколът VRRP, широко известен на мрежовите специалисти, разположен на мрежово оборудване, което осигурява устойчивост на грешки за външния IP адрес, към който се свързват клиентите. Втората част е IPVS, IP виртуален сървър, за балансиране между фото рутери и осигуряване на толерантност към грешки на това ниво. И третото е здравни проверки.

Да започнем с първата част: VRRP – как изглежда? Има определено виртуално IP, което има запис в dns badoocdn.com, където клиентите се свързват. В даден момент имаме IP адрес на един сървър. Пакетите Keepalived се изпълняват между сървъри, използващи протокола VRRP, и ако главният изчезне от радара - сървърът се е рестартирал или нещо друго, тогава резервният сървър автоматично повишава този IP адрес - не са необходими ръчни действия. Главният и резервният се различават, главно приоритет: колкото по-висок е, толкова по-вероятно е машината да стане главна. Много голямо предимство е, че не е необходимо да конфигурирате IP адреси на самия сървър, достатъчно е да ги опишете в конфигурацията и ако IP адресите се нуждаят от персонализирани правила за маршрутизиране, това е описано директно в конфигурацията, с същият синтаксис, както е описано в пакета VRRP. Няма да срещнете непознати неща.

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

По този начин сме осигурили устойчивост на грешки на външния IP адрес. Следващата част е по някакъв начин да балансирате трафика от външен IP адрес към фото рутери, които вече го прекъсват. С протоколите за балансиране всичко е достатъчно ясно. Това е или обикновен кръгов режим, или малко по-сложни неща, wrr, свързване на списък и т.н. Това основно е описано в документацията, няма нищо специално за това. Но начинът на доставка... Тук ще се спрем по-подробно - защо избрахме един от тях. Това са NAT, Direct Routing и TUN. Факт е, че веднага заложихме връщането на 100 гигабита трафик от сайтовете. Това е, ако разберете, имате нужда от 10 гигабитови карти, нали? 10 гигабитови карти в един сървър - това вече надхвърля поне нашата концепция за "стандартно оборудване". И тогава се сетихме, че ние не просто раздаваме малко трафик, ние раздаваме снимки.

Каква е функцията? - Огромна разлика между входящия и изходящия трафик. Входящият трафик е много малък, изходящият трафик е много голям:

Ако погледнете тези графики, можете да видите, че в момента към директора се изпращат около 200 Mb в секунда, това е най-типичният ден. Ние връщаме 4,500 MB в секунда, съотношението е около 1/22. Вече е ясно, че за да осигурим напълно изходящ трафик към 22 работещи сървъра, е достатъчен един, който приема тази връзка. Тук на помощ идва алгоритъмът за директно маршрутизиране, алгоритъмът за маршрутизиране.

Как изглежда? Нашият фотографски директор, според неговата таблица, прехвърля връзки към фоторутери. Но фото рутерите изпращат обратен трафик директно към интернет, изпращат го на клиента, той не се връща през фотодиректора, така че с минимален брой машини ние осигуряваме пълна толерантност към грешки и изпомпване на целия трафик. В конфигурациите изглежда така: посочваме алгоритъма, в нашия случай това е прост rr, предоставяме метода за директно маршрутизиране и след това започваме да изброяваме всички реални сървъри, колко от тях имаме. Което ще определи този трафик. В случай, че имаме още един или два, няколко сървъра, които се появяват там, възниква такава необходимост - ние просто добавяме този раздел към конфигурацията и не се притесняваме много. От страна на реални сървъри, от страна на фото-рутер, този метод изисква най-минималната конфигурация, той е перфектно описан в документацията и там няма клопки.

Особено приятно е, че такова решение не предполага радикална промяна на локалната мрежа, това беше важно за нас, трябваше да го решим с минимални разходи. Ако погледнете Изход на IPVS администраторска командатогава ще видим как ще изглежда. Тук имаме определен виртуален сървър, на порт 443, слуша, приема връзка, всички работещи сървъри са изброени и се вижда, че връзката е плюс или минус същата. Ако погледнем статистиката на същия виртуален сървър, имаме входящи пакети, входящи връзки, но абсолютно никакви изходящи. Изходящите връзки отиват директно към клиента. Е, успяхме да разбалансираме. Сега, какво се случва, ако един от нашите фото рутери се повреди? В крайна сметка желязото си е желязо. Може да изпадне в паника на ядрото, може да се счупи, захранването може да изгори. Всичко. За това са здравните прегледи. Те могат да бъдат толкова прости, колкото да проверите как портът е отворен при нас, или някои по-сложни, до някои самостоятелно написани скриптове, които дори ще проверят бизнес логиката.

Спряхме някъде по средата: имаме https заявка за конкретно местоположение, извиква се скрипт, ако отговори с 200-ен отговор, смятаме, че всичко е наред с този сървър, че е жив и може да се включи доста лесно .

Как изглежда това отново на практика. Изключен сървър, допустим за профилактика - флашване на BIOS например. В регистрационните файлове веднага имаме изчакване, виждаме първия ред, след което след три опита той се маркира като „неуспешен“ и просто се премахва от списъка.

Възможно е и второ поведение, когато просто VS е настроен на нула, но в случай на връщане на снимка това не работи добре. Сървърът се издига, Nginx стартира там, веднага проверките на здравето разбират, че връзката преминава, че всичко е наред и сървърът се появява в нашия списък и натоварването веднага започва да се прилага автоматично към него. Не се изискват ръчни действия от дежурния администратор. През нощта сървърът се рестартира - отделът за мониторинг не ни се обажда за това през нощта. Казват ви какво се е случило, всичко е наред.

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

Остава да се каже, че всичко това, разбира се, трябва да се следи. Отделно трябва да се отбележи, че Keepalivede, като софтуер, написан преди много време, има куп начини за наблюдение, като и двата използват проверки чрез DBus, SMTP, SNMP и стандартен Zabbix. Освен това самият той знае как да пише букви на почти всяко кихане и честно казано, в един момент дори си помислихме да го изключим, защото той пише много букви за всяко превключване на трафика, включване, за всеки IP-shnik и така нататък Разбира се, ако има много сървъри, тогава можете да се наводните с тези писма. Използвайки стандартни методи, ние наблюдаваме nginx на фото рутери и хардуерният мониторинг не е изчезнал. Разбира се, бихме посъветвали още две неща: първо, външни проверки на здравето и достъпност, защото дори и всичко да работи, всъщност потребителите може да не получат снимки поради проблеми с външни доставчици или нещо по-сложно. Винаги си струва да държите някъде в друга мрежа, в Amazon или някъде другаде, отделна машина, която може да пингва вашите сървъри отвън, и също така си струва да използвате или откриване на аномалии, за тези, които са добри в сложното машинно обучение, или просто мониторинг, най-малкото за да се проследи дали заявките са намалели рязко, или обратното, са нараснали. Освен това е полезно.

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

Какво завършихме? Имахме проблем на януарските празници на 2018г. През първите шест месеца, докато пускахме тази схема в експлоатация, разширявайки я до целия трафик, за да премахнем целия трафик от LTM, ние нараснахме само в трафика в един център за данни от 40 гигабита на 60 гигабита, и в същото време за цялата 2018 година успяха да дадат почти три пъти повече снимки в секунда.

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