Сучасны вэб практычна неймаверны без мэдыякантэнту: смартфоны ёсць практычна ў кожнай нашай бабулі, усё сядзяць у сацсетках, і прастоі ў абслугоўванні дорага абыходзяцца кампаніям. Вашай увазе расшыфроўка апавядання кампаніі пра тое, як яна арганізавала аддачу фатаграфій з дапамогай апаратнага рашэння, з якімі праблемамі прадукцыйнасці сутыкнулася ў працэсе, чым яны былі выкліканыя, ну і як гэтыя праблемы былі вырашаны з дапамогай софтавага рашэння на аснове Nginx, забяспечыўшы пры гэтым адмоваўстойлівасць на ўсіх узроўнях.). Дзякуем аўтарам апавядання Алега Яфімава і Аляксандра Дымава, якія падзяліліся сваім вопытам на канферэнцыі .
- Пачнем з невялікага ўвядзення аб тым, як мы захоўваем і кэшуем фатаграфіі. У нас ёсць пласт, на якім мы іх захоўваем, і пласт, дзе мы фатаграфіі кэшуем. Пры гэтым, калі мы жадаем дамагацца вялікага хітрэйта і змяншаць нагрузку на вартаўні, нам важна, каб кожная фатаграфія асобнага карыстача ляжала на адным які кэшуецца серверы. Інакш нам прыйшлося б ставіць у столькі разоў больш дыскаў, у колькі ў нас больш сервераў. Хітрэйт у нас у раёне 99%, гэта значыць мы ў 100 разоў змяншаем нагрузку на нашы storage, і для таго, каб гэта зрабіць, яшчэ 10 гадоў назад, калі ўсё гэта будавалася, у нас было 50 сервераў. Адпаведна, для таго, каб гэтыя фатаграфіі аддаваць, нам трэба было ў сутнасці 50 вонкавых даменаў, якія гэтыя серверы абслугоўваюць.
Натуральна, адразу паўстала пытанне: а калі ў нас адзін сервер упадзе, будзе недаступны, якую частку трафіку мы губляем? Мы паглядзелі, што ёсць на рынку, і вырашылі купіць жалязяку, каб яна вырашыла ўсе нашы праблемы. Выбар упаў на рашэнне кампаніі F5-network (якая, дарэчы, не так даўно купіла NGINX, Inc): BIG-IP Local Traffic Manager.
Што гэтая жалязяка (LTM) робіць: гэта жалезны роўтар, які робіць жалезнае redundancy сваіх вонкавых партоў і дазваляе роўціць трафік, засноўваючыся на тапалогіі сеткі, на нейкіх наладах, робіць health-check'і. Нам было важна тое, што гэтую жалязяку можна праграмаваць. Адпаведна, мы маглі апісаць логіку таго, як фатаграфіі пэўнага карыстальніка аддаваліся з нейкага канкрэтнага кэша. Як гэта выглядае? Ёсць жалязякі, якая глядзіць у інтэрнэт па адным дамене, аднаму ip, робіць ssl offload, разбірае http-запыты, з IRule выбірае нумар кэша, куды пайсці, і пускае туды трафік. Пры гэтым яна робіць health-cheсk'і, і ў выпадку недаступнасці нейкай машыны мы зрабілі на той момант так, каб трафік ішоў на адзін рэзервовы сервер. З пункту гледжання канфігуравання ёсць, вядома, некаторыя нюансы, але ў цэлым усё даволі проста: мы прапісваем карту, адпаведнасць нейкай колькасці нашаму IP у сетцы, які гаворыцца, што слухаць мы будзем на 80-м і 443-м партах, які гаворыцца, што, калі сервер недаступны, тое трэба пускаць трафік на рэзервовы, у дадзеным выпадку 35-й, і апісваем кучу логікі, як гэтую архітэктуру трэба разбіраць. Адзіная праблема была ў тым, што мова, якой праграмуецца жалязяка, гэта мова Tcl. Калі хто наогул такі памятае… мова гэта больш write-only, чым мова, зручная для праграмавання:
Што мы атрымалі? Мы атрымалі жалязяку, якая забяспечвае высокую даступнасць нашай інфраструктуры, роуціць увесь наш трафік, забяспечвае health-cheсk'і і проста працуе. Прычым працуе даволі доўга: за апошнія 10 год да яе не было ніякіх нараканняў. Да пачатку 2018 года мы ўжо аддавалі каля 80k фатаграфій у секунду. Гэта недзе прыкладна 80 гігабіт трафіку з абодвух нашых дата-цэнтраў.
Аднак...
У пачатку 2018 года мы на графіках убачылі непрыгожую карціну: час аддачы фатаграфій відавочна вырас. І яно перастала нас уладкоўваць. Праблема ў тым, што такія паводзіны былі відаць толькі ў самы пік трафіку - для нашай кампаніі гэта ноч з нядзелі на панядзелак. Але ўвесь астатні час сістэма паводзіла сябе як звычайна, ніякіх прыкмет паломкі.
Тым не менш праблему трэба было вырашаць. Мы вызначылі магчымыя вузкія месцы і пачалі іх зліквідаваць. У першую чаргу, вядома, мы пашырылі uplinks вонкавыя, правялі поўную рэвізію ўнутраных uplinks, знайшлі ўсе магчымыя вузкія месцы. Але відавочнага выніку ўсё гэта не дало, праблема не знікла.
Яшчэ адным магчымым вузкім месцам была прадукцыйнасць саміх фота-кэшаў. І мы вырашылі, што, магчыма, праблема ўпіраецца ў іх. Што ж, пашырылі прадукцыйнасць - у асноўным, сеткавыя парты на фотакэшах. Але зноў ніякага яўнага паляпшэння не бачылі. У рэшце рэшт, звярнулі пільную ўвагу на прадукцыйнасць самага LTM-а, і вось тут убачылі на графіках сумную карціну: загрузка ўсіх CPU пачынае ісці плыўна, але потым рэзка ўпіраецца ў паліцу. Пры гэтым LTM перастае адэкватна рэагаваць на health-check' і uplink'аў і пачынае іх выпадковым чынам выключаць, што вядзе да сур'ёзнай дэградацыі прадукцыйнасці.
Гэта значыць, мы вызначылі крыніцу праблемы, вызначылі вузкае месца. Засталося вырашыць, што ж мы будзем рабіць.
Першае, само напрошваецца, што мы маглі зрабіць, – гэта неяк мадэрнізаваць сам LTM. Але тут ёсць свае нюансы, таму што гэта жалеза дастаткова ўнікальнае, ты не пойдзеш у бліжэйшы супермаркет і не купіш. Гэта асобны кантракт, асобны кантракт на ліцэнзію, і гэта зойме шмат часу. Другі варыянт - пачаць думаць самому, прыдумаць сваё рашэнне на сваіх кампанентах, пажадана з выкарыстаннем праграмы з адкрытым доступам. Засталося толькі вырашыць, што менавіта мы абярэм для гэтага і колькі часу выдаткуем на рашэнне гэтай праблемы, бо карыстачы недаатрымлівалі фатаграфій. Такім чынам, трэба рабіць усё гэта вельмі-вельмі хутка, можна сказаць - учора.
Бо задача гучала як "зрабіць нешта максімальна хутка і выкарыстоўваючы тое жалеза, якое ў нас ёсць", першае, што мы падумалі, - гэта проста зняць з фронту якія-небудзь не самыя магутныя машыны, паставіць туды Nginx, з якім мы умеем працаваць, і паспрабаваць рэалізаваць усю тую самую логіку, якую раней рабіла жалязяка. Гэта значыць фактычна мы пакідалі нашу жалязяку, ставілі яшчэ 4 серверы, якія павінны былі сканфігураваць, рабілі для іх знешнія дамены па аналогіі з тым, як гэта было 10 гадоў таму… Мы крыху гублялі ў даступнасці ў выпадку падзення гэтых машын, але, тым не менш, вырашалі лакальна праблему нашых карыстачоў.
Адпаведна, логіка застаецца той жа самай: мы ставім Nginx, ён умее рабіць SSL-offload, мы можам на канфігах неяк праграмаваць логіку роўтынгу, health-check'і і проста прадубляваць тую логіку, якая ў нас была да гэтага.
Сядаем пісаць канфігі. Спачатку здавалася, што ўсё было вельмі проста, але, нажаль, пад кожную задачу знайсці мануалы вельмі складана. Таму не раім проста гугліць "як сканфігураваць Nginx для фатаграфій": лепш звярнуцца да афіцыйнай дакументацыі, якая пакажа, якія налады варта чапаць. Але пэўны параметр лепш падбіраць самім. Ну, а далей усё проста: апісваем серверы, якія ў нас ёсць, апісваем сертыфікаты… Але самае цікавае - гэта, уласна, сама логіка роўтынгу.
Спачатку нам здавалася, што мы проста апісваем наш лакейшн, матчым у ім нумар нашага фотакэша, рукамі ці генератарам апісваем, колькі нам трэба апстрымаў, у кожным апстрыме паказваем сервер, на які павінен ісці трафік, і бэкапны сервер – у выпадку, калі асноўны сервер недаступны:
Але, напэўна, калі б усё было б так проста, мы проста разышліся б па дамах і нічога не расказвалі. Нажаль, з дэфолтнымі наладамі Nginx, якія, увогуле-то, зробленыя за доўгія гады распрацоўкі і не зусім пад гэты кейс… канфіг выглядае так: у выпадку, калі ў нейкага апстрым-сервера адбываецца памылка запыту або таймаўт, Nginx заўсёды перамыкае трафік на наступны. Пры гэтым пасля першага фэйла на працягу 10 секунд сервер таксама будзе выключаны, прычым і па памылцы, і па таймаўце - гэта нават нельга ніяк канфігураваць. Гэта значыць калі мы прыбярэм ці скінем у апстрым-дырэктыве опцыю таймаўт, то, хоць Nginx і не будзе апрацоўваць гэты запыт і адкажа які-небудзь не вельмі добрай памылкай, сервер будзе выключацца.
Каб гэтага пазбегнуць, мы зрабілі дзве рэчы:
а) забаранілі рабіць гэта Nginx'у рукамі - і нажаль, адзіны спосаб зрабіць гэта - проста задаць налады max fails.
б) успомнілі, што мы ў іншых праектах выкарыстоўваем модуль, які дазваляе рабіць фонавыя health-check'і - адпаведна, мы зрабілі даволі частыя health-check'і, каб просты ў выпадку аварыі ў нас быў мінімальным.
Нажаль, гэта таксама не ўсё, таму што літаральна першыя два тыдні працы гэтай схемы паказалі, што TCP health-check – таксама штука ненадзейная: на апстрым-серверы можа быць падняты не Nginx, ці Nginx у D-state, і ў гэтым выпадку ядро будзе прымаць злучэнне, health-check будзе праходзіць, а працаваць не будзе. Таму мы адразу ж замянілі гэта на health-check http'шны, зрабілі пэўны, які калі ўжо аддае 200, то ўсё працуе ў гэтым скрыпце. Можна рабіць дадатковую логіку - напрыклад, у выпадку якія кэшуюць сервераў правяраць, што правільна змантаваная файлавая сістэма:
І нас бы гэта задаволіла, за выключэннем таго, што зараз схема цалкам паўтарала тое, што рабіла жалязяка. Але мы хацелі зрабіць лепш. Раней у нас быў адзін рэзервовы сервер, і, мусіць, гэта не вельмі добра, таму што калі сервераў у вас сто, то калі падае адразу некалькі, адзін рэзервовы сервер ці наўрад зладзіцца з нагрузкай. Таму мы вырашылі рэзерваванне размеркаваць па ўсіх серверах: зрабілі проста яшчэ адзін асобны апстрым, запісалі туды ўсе серверы з пэўнымі параметрамі ў адпаведнасці з тым, якую нагрузку яны могуць абслугоўваць, дадалі тыя ж самыя health-check'і, якія ў нас былі да гэтага. :
Бо ўсярэдзіне аднаго апстрыму нельга хадзіць у іншы апстрым, трэба было зрабіць так, каб у выпадку недаступнасці асноўнага апстрыму, у якім проста запісвалі правільны, патрэбны фотакэш, мы проста праз error_page ішлі на fallback, адкуль ішлі на рэзервовы апстрым:
І літаральна дадаўшы чатыры серверы, мы вось што атрымалі: замянілі частку нагрузкі – знялі з LTM на гэтыя серверы, рэалізавалі там тую ж логіку, выкарыстоўваючы стандартнае жалеза і софт, адразу ж атрымалі бонусам, што гэтыя серверы можна маштабаваць, таму што іх можна проста паставіць столькі, колькі трэба. Ну і адзіны мінус - мы страцілі высокую даступнасць для знешніх карыстальнікаў. Але на той момант прыйшлося гэтым ахвяраваць, бо трэба было неадкладна вырашыць праблему. Такім чынам, частку нагрузкі мы знялі, гэта каля 40% на той момант, LTM у стала добра, а літаральна праз два тыдні пасля пачатку праблемы мы сталі аддаваць не 45k запытаў у секунду, а 55k. Па сутнасці, мы выраслі на 20% - гэта відавочна той трафік, які мы недааддае карыстачу. І пасля гэтага пачалі думаць, як вырашыць астатнюю праблему - забяспечыць высокую знешнюю даступнасць.
У нас была некаторая паўза, падчас якой мы абмяркоўвалі, якое рашэнне мы будзем для гэтага выкарыстоўваць. Былі прапановы забяспечваць надзейнасць з дапамогай DNS, з дапамогай нейкіх самапісных скрыптоў, пратаколаў дынамічнай маршрутызацыі… варыянтаў было шмат, але ўжо стала зразумела, што для па-сапраўднаму надзейнай аддачы фатаграфій трэба ўвесці яшчэ адзін пласт, які будзе за гэтым сачыць. Мы назвалі гэтыя машыны photo directors. У якасці праграмнага забеспячэння, на якое мы абапіраліся, быў абраў Keepalived:
Для пачатку з чаго Keepalived складаецца. Першае - гэта пратакол VRRP, шырока вядомы сеткавікам, размешчаны на сеткавым абсталяванні, якое забяспечвае адмоваўстойлівасць знешняга IP-адрасы, на які злучаюцца кліенты. Другая частка гэта – IPVS, IP virtual server, для балансавання паміж фота-роўтэрамі і забеспячэнні адмоваўстойлівасці на гэтым узроўні. І трэцяе – health-check'і.
Пачнем з першай часткі: VRRP – як гэта выглядае? Ёсць нейкі virtual IP, на які ёсць запіс у dns badoocdn.com, куды падключаюцца кліенты. У нейкі момант часу ў нас IP-адрас прысутнічае на нейкім адным сэрвэры. Паміж серверамі бегаюць па пратаколе VRRP keepalived-пакеты, і ў выпадку калі майстар знікае з радараў – сервер перазагрузіўся ці яшчэ што-небудзь, то бэкапны сервер аўтаматычна паднімае гэты IP адрас у сябе – не трэба рабіць ніякіх ручных дзеянняў. Адрозніваюцца майстар і бэкап, у асноўным priority: чым яно вышэйшае, тым больш шанцаў, што машына стане майстар. Вельмі вялікая добрая якасць, тое што не трэба канфігураваць IP-адрасы на самім серверы, досыць апісаць іх у канфігу, і калі пры гэтым IP-адрасам неабходныя нейкія кастамныя правілы маршрутызацыі, гэта апісваецца прама ў канфігу, тым жа сінтаксісам, як гэта апісваецца у пакеце VRRP. Ніякіх незнаёмых рэчаў вам не сустрэнецца.
Як гэта выглядае на практыку? Што адбываецца, калі адзін з сэрвэраў сыходзіць у адмову? Як толькі майстар знікае, у нас бэкап спыняе атрымліваць адвертысменты і аўтаматычна становіцца майстрам. Праз нейкі час мы адрамантавалі майстар, перазагрузілі, паднялі Keepalived — прыходзяць адвертысменты з большым прыярытэтам, чым у бэкапу, і бэкап аўтаматычна ператвараецца назад, здымае з сябе IP-адрасы, ніякіх ручных дзеянняў пры гэтым рабіць не трэба.
Такім чынам, адмоваўстойлівасць знешняга IP-адрасы мы забяспечылі. Наступная частка - гэта з вонкавага IP-адрасы неяк балансаваць трафік на фота-роўтары, якія ўжо тэрмінуюць яго. З пратаколамі балансавання ўсё дастаткова ясна. Гэта альбо просты round-robin, альбо крыху больш складаныя рэчы, wrr, list connection і гэтак далей. Гэта ў прынцыпе апісана ў дакументацыі, нічога такога асаблівага няма. А вось метад дастаўкі ... Тут спынімся падрабязней - чаму выбралі адзін з іх. Гэта NAT, Direct Routing і TUN. Справа ў тым, што мы адразу закладаліся на аддачу 100 гігабіт трафіку з пляцовак. Гэта калі прыкінуць, трэба 10 гігабітных картак, правільна? 10 гігабітных картак у адным серверы - гэта ўжо выходзіць за рамкі, прынамсі, нашага паняцця "стандартнае абсталяванне". І тут мы ўзгадалі, што мы не проста аддаём нейкі трафік, мы аддаём фотаздымкі.
У чым асаблівасць? - Каласальная розніца паміж уваходным і выходным трафікам. Уваходны трафік вельмі маленькі, выходны вельмі вялікі:
Калі паглядзець на гэтыя графікі, то відаць, што ў дадзены момант на дырэктара паступае каля 200 Мб у секунду, гэта самы звычайны дзень. Аддаём жа мы зваротна 4,500 Мб у секунду, суадносіны ў нас прыкладна 1/22. Ужо зразумела, што нам для поўнага забеспячэння выходнага трафіку на 22 сервера працоўных досыць аднаго, які прымае гэтае злучэнне. Тут нам на дапамогу прыходзіць якраз алгарытм direct routing, алгарытм маршрутызацыі.
Як гэта выглядае? Фота-дырэктар у нас згодна са сваёй табліцай перадае злучэнні на фота-роўтары. Але зваротны трафік фота-роўтары адпраўляюць ужо наўпрост у інтэрнэт, адпраўляюць кліенту, ён не праходзіць зваротна праз фота-дырэктар, такім чынам, мінімальнай колькасцю машын мы забяспечваем поўную адмоваўстойлівасць і прапампоўванне ўсяго трафіку. У канфігах гэта выглядае наступным чынам: мы паказваем алгарытм, у нашым выпадку гэта просты rr, забяспечваем метад дырэкт-роўтынг і далей пачынаем пералічваць усе рэальныя серверы, колькі іх у нас ёсць. Якія будуць гэты трафік дэтэрмінаваць. У выпадку, калі ў нас там з'яўляюцца яшчэ адзін-два, некалькі сервераў, узнікае такая неабходнасць - проста дапісваем гэтую секцыю ў канфігу і асабліва не парымся. З боку рэальных сервераў, з боку фота-роўтара такі метад патрабуе самага мінімальнага канфігуравання, ён выдатна апісаны ў дакументацыі, і падводных камянёў тамака няма.
Што асабліва прыемна - такое рашэнне не мае на ўвазе кардынальнай пераробкі лакальнай сеткі, для нас гэта было важна, нам трэба было вырашыць гэта мінімальнымі выдаткамі. Калі паглядзець на , то мы ўбачым, як гэта выглядае. Вось у нас ёсць нейкі віртуальны сервер, на 443 порце, слухае, прымае злучэнне, ідзе пералік усіх працоўных сервераў, і відаць, што connection – ён, плюс-мінус, аднолькавы. Калі мы паглядзім статыстыку, на тым жа віртуальным серверы, - у нас ёсць уваходныя пакеты, уваходныя злучэнні, але абсалютна адсутнічаюць выходныя. Выходныя злучэнні ідуць напрамую кліенту. Добра, разбалансаваць мы змаглі. Цяпер, што будзе, калі ў нас адзін з фота-роўтэраў сыходзіць у адмову? Бо жалеза ёсць жалеза. Можа сысці ў kernel panic, можа зламацца, можа згарэць блок харчавання. Што заўгодна. Для гэтага і патрэбныя health-check'і. Яны могуць быць як самымі простымі - праверка на тое, як порт у нас адкрыты, - так і нейкая больш складанымі, аж да нейкіх самапісных скрыптоў, якія будуць нават бізнес-логіку будуць правяраць.
Мы спыніліся недзе пасярэдзіне: у нас ідзе https-запыт на пэўны location, выклікаецца скрыпт, калі ён адказвае 200-м адказам, мы лічым, што з гэтым серверам усё нармальна, што ён жывы і яго зусім спакойна можна ўключаць.
Як гэта, ізноў жа, выглядае на практыцы. Выключылі сервер дапусцім на абслугоўванне – перапрашыўка BIOS, напрыклад. У логах у нас тут жа адбываецца таймаўт, бачым першы радок, потым пасля трох спроб пазначаецца як "зафейлен", і ён выдаляецца проста са спісу.
Магчымы яшчэ другі варыянт паводзін, калі проста VS выстаўляецца ў нуль, але ў выпадку аддачы фатаграфіі гэта працуе дрэнна. Сервер паднімаецца, запускаецца там Nginx, тут жа health-check'і разумеюць, што канэкт праходзіць, што ўсё выдатна, і сервер з'яўляецца ў нас у спісе, і на яго тут жа аўтаматычна пачынае падавацца нагрузка. Ніякіх пры гэтым ручных дзеянняў ад дзяжурнага адміна не патрабуецца. Уначы сервер перазагрузіўся - аддзел маніторынгу нам з гэтай нагоды ноччу не тэлефануе. У вядомасць ставяць, што такое было, усё нармальна.
Такім чынам, досыць простым спосабам, з дапамогай невялікай колькасці серверам мы праблему знешняй адмоваўстойлівасці вырашылі.
Засталося сказаць, што ўсё гэта, вядома ж, трэба маніторыць. Асобна трэба адзначыць, што Keepalivede, як вельмі даўно напісаны софт, мае кучу спосабаў яго заманіторыць, як з дапамогай праверак праз DBus, SMTP, SNMP, так і стандартным Zabbix'ам. Плюс, ён сам па сабе ўмее пісаць лісты практычна на кожны чых, і сапраўды кажучы, мы ў нейкі момант думалі нават выключыць, таму што піша ён вельмі шмат лістоў на любое пераключэнне трафіку, уключэнні, на кожны IP-шнік і гэтак далей . Вядома, калі сервераў шмат, то можна гэтымі лістамі сябе заваліць. Стандартнымі спосабамі маніторым nginx на фота-роўтэрах, і нікуды не падзеўся маніторынг жалеза. Мы б, вядома, раілі яшчэ дзве рэчы: гэта па-першае, вонкавыя health-check'і даступнасці, таму што нават калі ўсё працуе, насамрэч, магчыма, карыстачы фатаграфіі не атрымліваюць з-за праблем з вонкавымі правайдэрамі ці чаго- то больш складанага. Заўсёды варта трымаць дзе-небудзь у іншай сетцы, у amazon ці яшчэ дзесьці, асобную машыну, якая зможа звонку пінгаваць вашы сервера, і таксама варта выкарыстоўваць альбо anomaly detection, для тых, хто ўмее ў хітры machine learning, альбо просты маніторынг, хаця б для таго, каб адсочваць, калі рэквесты рэзка ўпалі, альбо наадварот, выраслі. Таксама бывае карысна.
Падвядзем вынікі: мы, па сутнасці, замянілі жалезнае рашэнне, якое ў нейкі момант перастала нас уладкоўваць, даволі простай сістэмай, якая робіць усё тое ж самае, гэта значыць забяспечвае тэрмінаванне HTTPS трафіку і далейшы разумны роўтынг з патрэбнымі health-check'амі. Мы павялічылі стабільнасць гэтай сістэмы, гэта значыць на кожны пласт у нас усё таксама высокая даступнасць, плюс мы бонусам атрымалі тое, што на кожным пласце даволі проста ўсё гэта маштабаваць, таму што гэта стандартнае жалеза са стандартным софтам, гэта значыць тым самым мы спрасцілі сабе дыягностыку магчымых праблем.
Што мы атрымалі ў выніку? Праблема ў нас была ў студзеньскія святы 2018-га. За першыя паўгода пакуль мы ўводзілі гэтую схему ў строй, пашыралі ўжо на ўвесь трафік, каб увесь трафік зняць з LTM, мы выраслі толькі па трафіку ў адным дата-цэнтры з 40 гігабіт да 60 гігабіт, і пры гэтым за ўвесь 2018-ы год. змаглі аддаваць практычна ў тры разы больш фатаграфій у секунду.
Крыніца: habr.com