Битрикс24: „Оно што се брзо подигне не сматра се палим“

Данас сервис Битрикс24 нема стотине гигабита саобраћаја, нити има огромну флоту сервера (иако их, наравно, има доста). Али за многе клијенте то је главни алат за рад у компанији; Према томе, нема начина да падне. Шта ако се пад ипак десио, али се услуга „опоравила“ тако брзо да нико ништа није приметио? А како је могуће имплементирати фаиловер без губитка квалитета рада и броја клијената? Александар Демидов, директор цлоуд сервиса у Битрикс24, говорио је за наш блог о томе како се систем резервација развијао током 7 година постојања производа.

„Покренули смо Битрикс24 као СааС пре 7 година. Главна потешкоћа је вероватно била следећа: пре него што је јавно представљен као СааС, овај производ је једноставно постојао у формату решења у кутији. Клијенти су га купили од нас, хостовали на својим серверима, поставили корпоративни портал - опште решење за комуникацију запослених, складиштење датотека, управљање задацима, ЦРМ, то је све. И до 2012. одлучили смо да желимо да га покренемо као СааС, да га сами администрирамо, обезбеђујући толеранцију грешака и поузданост. Искуство смо стицали успут, јер га до тада једноставно нисмо имали – били смо само произвођачи софтвера, а не пружаоци услуга.

Приликом покретања услуге схватили смо да је најважније обезбедити толеранцију грешака, поузданост и сталну доступност услуге, јер ако имате обичну веб локацију, продавницу, на пример, она пада на вас и седи тамо за сат времена, само ви патите, губите наруџбине, губите клијенте, али за самог вашег клијента то није од велике важности за њега. Био је узнемирен, наравно, али је отишао и купио га на другом сајту. А ако је ово апликација на којој је везан сав рад унутар компаније, комуникације, одлуке, онда је најважније придобити поверење корисника, односно не изневерити их и не пасти. Јер сав посао може стати ако нешто унутра не ради.

Битрик.24 као СааС

Саставили смо први прототип годину дана пре јавног представљања, 2011. Саставили смо га за отприлике недељу дана, погледали, завртили - чак је и радио. Односно, могли бисте да уђете у форму, унесете назив портала, отвориће се нови портал и креираће се база корисника. Погледали смо га, начелно проценили производ, избацили га и наставили да га усавршавамо читаву годину дана. Зато што смо имали велики задатак: нисмо желели да направимо две различите базе кода, нисмо желели да подржимо посебан упаковани производ, одвојена решења у облаку – желели смо да све то урадимо у оквиру једног кода.

Типична веб апликација у то време је била један сервер на коме се покреће неки ПХП код, мискл база података, уплоадују се фајлови, документи, слике стављају у фолдер за отпремање - па, све ради. Нажалост, немогуће је покренути критично стабилну веб услугу користећи ово. Тамо, дистрибуирани кеш није подржан, репликација базе података није подржана.

Формулисали смо захтеве: ово је могућност да се налазите на различитим локацијама, подржавате репликацију и идеално је да будете лоцирани у различитим географски распоређеним центрима података. Одвојите логику производа и, у ствари, складиштење података. Бити у стању да динамички скалира у складу са оптерећењем и да у потпуности толерише статику. Из ових разматрања, заправо, произашли су захтеви за производ, које смо усавршавали током године. За то време, у платформи, за коју се показало да је обједињена – за решења у кутијама, за сопствену услугу – направили смо подршку за оне ствари које су нам биле потребне. Подршка за мискл репликацију на нивоу самог производа: то јест, програмер који пише код не размишља о томе како ће његови захтеви бити дистрибуирани, он користи наш АПИ, а ми знамо како да правилно дистрибуирамо захтеве за писање и читање између мајстора и робови.

Направили смо подршку на нивоу производа за различите складишта објеката у облаку: гоогле складиште, амазон с3, плус подршку за опен стацк свифт. Стога је ово било згодно и за нас као услугу и за програмере који раде са упакованим решењем: ако само користе наш АПИ за рад, не размишљају о томе где ће датотека на крају бити сачувана, локално на систему датотека или у складишту објектне датотеке.

Као резултат тога, одмах смо одлучили да резервишемо на нивоу целог дата центра. У 2012. смо покренули у потпуности на Амазон АВС-у јер смо већ имали искуства са овом платформом – тамо је била хостована наша веб локација. Привукла нас је чињеница да у сваком региону Амазон има неколико зона доступности – заправо (у њиховој терминологији) неколико центара података који су мање-више независни један од другог и омогућавају нам да резервишемо на нивоу читавог дата центра: ако изненада не успе, базе података се реплицирају мастер-мастер, сервери веб апликација се праве резервна копија, а статички подаци се премештају у складиште с3 објеката. Оптерећење је избалансирано - у то време Амазон елб-ом, али мало касније смо дошли до сопствених балансера оптерећења, јер нам је била потребна сложенија логика.

Оно што су хтели то су и добили...

Све основне ствари које смо хтели да обезбедимо – толеранција на грешке самих сервера, веб апликација, база података – све је функционисало добро. Најједноставнији сценарио: ако једна од наших веб апликација не успе, онда је све једноставно - оне се искључују из балансирања.

Балансер (у то време је то био Амазонов елб) означио је машине које нису у функцији као нездраве и искључио расподелу оптерећења на њима. Амазон аутоматско скалирање је функционисало: када је оптерећење порасло, нове машине су додате групи за аутоматско скалирање, оптерећење је распоређено на нове машине - све је било у реду. Код наших балансера логика је приближно иста: ако се нешто деси са сервером апликација, уклањамо захтеве са њега, избацимо ове машине, покрећемо нове и настављамо са радом. Шема се мало променила током година, али наставља да функционише: једноставна је, разумљива и нема потешкоћа са њом.

Радимо широм света, вршна оптерећења купаца су потпуно различита, и, на пријатељски начин, требало би да будемо у могућности да извршимо одређене сервисне радове на било којој компоненти нашег система у било ком тренутку - незапажено од стране купаца. Због тога имамо прилику да искључимо базу података из рада, прерасподеливши оптерећење на други центар података.

Како то све функционише? — Пребацујемо саобраћај на радни дата центар – ако дође до хаварије у дата центру, онда у потпуности, ако је ово наш планирани рад са једном базом података, онда пребацујемо део саобраћаја који опслужује ове клијенте на други дата центар, обустављајући то репликација. Ако су нове машине потребне за веб апликације због повећања оптерећења другог центра података, оне ће се аутоматски покренути. Завршавамо посао, репликација се обнавља и враћамо цело оптерећење назад. Ако треба да пресликамо неки посао у другом ДЦ-у, на пример, да инсталирамо ажурирања система или променимо подешавања у другој бази података, онда, генерално, понављамо исту ствар, само у другом правцу. А ако је ово несрећа, онда све радимо тривијално: користимо механизам за руковање догађајима у систему за праћење. Ако се покрене неколико провера и статус постане критичан, онда покрећемо овај руковалац, руковалац који може да изврши ову или ону логику. За сваку базу података наводимо који сервер је за њу прелазак на грешку и где саобраћај треба да се пребаци ако је недоступан. Историјски гледано, ми користимо нагиос или неке од његових виљушки у овом или оном облику. У принципу, слични механизми постоје у скоро сваком систему праћења, ми још не користимо ништа сложеније, али можда ћемо једног дана. Сада надгледање покреће недоступност и има могућност да промени нешто.

Јесмо ли све резервисали?

Имамо много клијената из САД, много клијената из Европе, много клијената који су ближи Истоку - Јапану, Сингапуру и тако даље. Наравно, огроман удео клијената је у Русији. То јест, посао није у једном региону. Корисници желе брз одговор, постоје захтеви да се поштују различити локални закони, а у оквиру сваког региона резервишемо два дата центра, плус постоје неке додатне услуге, које је, опет, згодно поставити у оквиру једног региона - за клијенте који су у овај регион раде. РЕСТ руковаоци, ауторизациони сервери, они су мање критични за рад клијента у целини, можете да прелазите кроз њих са малим прихватљивим кашњењем, али не желите да поново измишљате точак како да их надгледате и шта да радите са њима. Стога се трудимо да максимално искористимо постојећа решења, а не да развијамо неку врсту компетенције у додатним производима. А негде тривијално користимо пребацивање на ДНС нивоу, а живост услуге одређујемо истим ДНС-ом. Амазон има услугу Роуте 53, али то није само ДНС у који можете да уносите и то је то – много је флексибилнији и практичнији. Преко њега можете да градите гео-дистрибуисане сервисе са геолокацијама, када помоћу њега одредите одакле је клијент дошао и дате му одређене записе - уз његову помоћ можете да градите архитектуру за превазилажење грешке. Исте здравствене провере су конфигурисане у самом Роуте-у 53, ви постављате крајње тачке које се надгледају, постављате метрику, подешавате које протоколе ће одредити „живост“ услуге – тцп, хттп, хттпс; подесите учесталост провера којима се утврђује да ли је сервис жив или не. А у самом ДНС-у наведете шта ће бити примарно, а шта секундарно, где да се пребаците ако се провера здравља покрене унутар руте 53. Све ово може да се уради са неким другим алатима, али зашто је згодно - ми то постављамо једном и онда уопште не размишљај о томе како вршимо провере, како се мењамо: све ради само од себе.

Прво "али": како и чиме резервисати саму руту 53? Ко зна, шта ако му се нешто деси? На срећу, никада нисмо нагазили на ове грабље, али опет ћу имати причу унапред зашто смо мислили да још увек треба да резервишемо. Овде смо унапред изложили сламке за себе. Неколико пута дневно вршимо потпуни истовар свих зона које имамо на рути 53. Амазонов АПИ вам омогућава да их лако пошаљете у ЈСОН-у, а ми имамо неколико резервних сервера на којима га конвертујемо, отпремамо у облику конфигурација и имамо, грубо речено, резервну конфигурацију. Ако се нешто деси, можемо брзо да га применимо ручно без губитка података о ДНС подешавањима.

Друго "али": Шта на овој слици још није резервисано? Сам балансер! Наша дистрибуција клијената по регионима је веома једноставна. Имамо домене битрик24.ру, битрик24.цом, .де - сада постоји 13 различитих, који раде у различитим зонама. Дошли смо до следећег: сваки регион има своје балансере. Ово га чини погоднијим за дистрибуцију по регионима, у зависности од тога где је вршно оптерећење на мрежи. Ако је ово квар на нивоу једног балансера, онда се једноставно повлачи из употребе и уклања из днс-а. Ако постоји неки проблем са групом балансера, онда се они праве резервне копије на другим сајтовима, а пребацивање између њих се врши истом рутом53, јер због кратког ТТЛ-а, пребацивање се дешава у року од највише 2, 3, 5 минута .

Треће "али": Шта још није резервисано? С3, тачно. Када смо фајлове које чувамо за кориснике сместили у с3, искрено смо веровали да је то оклопно и да ту нема потребе да било шта резервишемо. Али историја показује да се ствари дешавају другачије. Генерално, Амазон описује С3 као фундаменталну услугу, јер сам Амазон користи С3 за складиштење слика машина, конфигурација, АМИ слика, снимака... А ако се с3 сруши, као што се десило једном током ових 7 година, колико користимо битрик24, прати га као обожаватељ. Постоји читава гомила ствари које се појављују – немогућност покретања виртуелних машина, неуспех АПИ-ја и тако даље.

И С3 може пасти - десило се једном. Дакле, дошли смо до следеће шеме: пре неколико година у Русији није било озбиљних складишта јавних објеката и разматрали смо опцију да урадимо нешто своје... На срећу, нисмо почели да радимо ово јер бисмо ископали смо у стручност коју немамо имамо, и вероватно би забрљали. Сада Маил.ру има складиште компатибилно са с3, Иандек га има, а имају га и бројни други провајдери. На крају смо дошли до идеје да желимо да имамо, прво, резервну копију, а друго, могућност рада са локалним копијама. Конкретно за руски регион, користимо услугу Маил.ру Хотбок, која је АПИ компатибилна са с3. Нису нам биле потребне никакве веће модификације кода унутар апликације и направили смо следећи механизам: у с3 постоје окидачи који покрећу креирање/брисање објеката, Амазон има услугу под називом Ламбда - ово је покретање кода без сервера који ће се извршити управо када се активирају одређени окидачи.

Урадили смо то врло једноставно: ако се наш окидач активира, извршавамо код који ће копирати објекат у складиште Маил.ру. Да бисмо у потпуности покренули рад са локалним копијама података, потребна нам је и обрнута синхронизација како би клијенти који су у руском сегменту могли да раде са складиштем који им је ближи. Пошта се спрема да заврши окидаче у свом складишту - биће могуће извршити обрнуту синхронизацију на нивоу инфраструктуре, али за сада то радимо на нивоу сопственог кода. Ако видимо да је клијент поставио датотеку, онда на нивоу кода стављамо догађај у ред, обрађујемо га и вршимо обрнуту репликацију. Зашто је то лоше: ако радимо неку врсту посла са нашим објектима ван нашег производа, односно неким спољним средствима, нећемо то узети у обзир. Стога чекамо до краја, када се на нивоу складиштења појаве окидачи, тако да без обзира одакле извршавамо код, објекат који нам је дошао буде копиран у другом правцу.

На нивоу кода региструјемо оба складишта за сваког клијента: једно се сматра главним, а друго резервним. Ако је све у реду, радимо са складиштем које нам је ближе: то јест, наши клијенти који су у Амазону, раде са С3, а они који раде у Русији, раде са Хотбок-ом. Ако се заставица активира, онда би требало да се повеже прелазак на грешку и ми пребацимо клијенте на друго складиште. Можемо да означимо ово поље независно по регионима и можемо да их мењамо напред и назад. Ово још нисмо користили у пракси, али смо обезбедили овај механизам и мислимо да ће нам једног дана затребати управо овај прекидач и да ће нам добро доћи. Ово се већ једном десило.

Ох, и Амазон је побегао...

Овог априла обележава се годишњица почетка блокирања Телеграма у Русији. Најпогођенији провајдер који је потпао под ово је Амазон. И, нажалост, више су страдале руске компаније које су радиле за цео свет.

Ако је компанија глобална и Русија је веома мали сегмент за њу, 3-5% - па, на овај или онај начин, можете их жртвовати.

Ако је ово чисто руска компанија - сигуран сам да треба да се налази локално - па, једноставно ће бити згодно за саме кориснике, удобно, и биће мање ризика.

Шта ако је ово компанија која послује глобално и има приближно једнак број клијената из Русије и негде широм света? Повезаност сегмената је важна и они морају радити једни са другима на овај или онај начин.

Крајем марта 2018. Роскомнадзор је послао писмо највећим оператерима у којем је навео да планирају да блокирају неколико милиона Амазон ИП-ова како би блокирали... месинџер Зелло. Захваљујући тим истим провајдерима – успешно су процурили писмо свима, и дошло је до разумевања да би веза са Амазоном могла да се распадне. Био је петак, панично смо побегли колегама са серверс.ру, са речима: „Пријатељи, потребно нам је неколико сервера који ће се налазити не у Русији, не у Амазону, већ, на пример, негде у Амстердаму,“ да бисмо могли бар некако да инсталирамо свој ВПН и прокси тамо за неке крајње тачке на које не можемо ни на који начин утицати, на пример ендпонте истог с3 - не можемо покушати да подигнемо нови сервис и добијемо другачији ип, још увек морате да стигнете тамо. За само неколико дана поставили смо ове сервере, покренули их и, уопште, припремили се за тренутак када је блокирање почело. Занимљиво је да је РКН, гледајући галаму и панику, рекао: „Не, нећемо сада ништа блокирати“. (Али то је тачно до тренутка када је Телеграм почео да се блокира.) Пошто смо поставили могућности заобилажења и схватили да блокирање није уведено, нисмо, међутим, почели да решавамо целу ствар. Да, за сваки случај.

И 2019. године и даље живимо у условима блокаде. Погледао сам синоћ: око милион ИП адреса је и даље блокирано. Истина, Амазон је био скоро потпуно деблокиран, на свом врхунцу достигао је 20 милиона адреса... Генерално, реалност је да можда нема кохерентности, добре кохерентности. Одједном. Можда не постоји из техничких разлога – пожари, багери, све то. Или, као што смо видели, не сасвим технички. Дакле, неко велики и велики, са сопственим АС-овима, вероватно може ово да управља на друге начине - директно повезивање и друге ствари су већ на л2 нивоу. Али у једноставној верзији, као што је наша или још мања, можете, за сваки случај, имати редундантност на нивоу сервера подигнутих негде другде, унапред конфигурисан впн, проки, са могућношћу брзог пребацивања конфигурације на њих у тим сегментима који су критични за вашу повезаност. Ово нам је више пута користило, када је Амазоново блокирање почело, у најгорем случају, дозволили смо само С3 саобраћај кроз њих, али постепено је све то решено.

Како резервисати... целог провајдера?

Тренутно немамо сценарио у случају да цео Амазон пропадне. Сличан сценарио имамо и за Русију. У Русији нас је угостио један провајдер, од кога смо изабрали да имамо неколико сајтова. А пре годину дана смо се суочили са проблемом: иако су ово два дата центра, можда већ постоје проблеми на нивоу мрежне конфигурације провајдера који ће и даље утицати на оба дата центра. И можда ћемо бити недоступни на оба сајта. Наравно да се то десило. На крају смо поново размотрили архитектуру унутра. Није се много променило, али за Русију сада имамо два сајта, који нису од истог провајдера, већ од два различита. Ако једно не успе, можемо да пређемо на друго.

Хипотетички, за Амазон разматрамо могућност резервације на нивоу другог провајдера; можда Гугл, можда неко други... Али до сада смо у пракси приметили да док Амазон има незгоде на нивоу једне зоне доступности, незгоде на нивоу читавог региона су прилично ретке. Стога, теоретски имамо идеју да бисмо могли направити резервацију „Амазон није Амазон“, али у пракси то још није случај.

Неколико речи о аутоматизацији

Да ли је аутоматизација увек неопходна? Овде је прикладно подсетити се Дуннинг-Кругеровог ефекта. На оси „к“ је наше знање и искуство које стичемо, а на „и“ оси је поверење у наше поступке. У почетку не знамо ништа и нисмо уопште сигурни. Тада знамо мало и постајемо мегапоуздани - ово је такозвани „врх глупости“, добро илустрован сликом „деменција и храброст“. Онда смо мало научили и спремни смо за борбу. Онда нагазимо на неке мега-озбиљне грешке и нађемо се у долини очаја, када нам се чини да нешто знамо, а у ствари не знамо много. Затим, како стичемо искуство, постајемо сигурнији.

Наша логика о разним аутоматским пребацивањима на одређене незгоде је веома добро описана овим графиконом. Почели смо - нисмо знали ништа да урадимо, скоро сав посао је рађен ручно. Онда смо схватили да на све можемо да прикључимо аутоматизацију и да, као, мирно спавамо. И одједном нагазимо на мега-грабуље: активира се лажни позитиван резултат, и ми пребацујемо саобраћај напред-назад када, на добар начин, то није требало да радимо. Сходно томе, репликација се квари или нешто друго — ово је сама долина очаја. И тада долазимо до схватања да свему морамо приступити мудро. Односно, има смисла ослонити се на аутоматизацију, предвиђајући могућност лажних аларма. Али! ако последице могу да буду поражавајуће, онда је боље препустити дежурству, дежурним инжењерима, који ће се уверити и пратити да заиста дође до хаварије, а потребне радње спровести ручно...

Закључак

Током 7 година ишли смо од тога да када је нешто пало, настала је паника-паника, до схватања да проблеми не постоје, постоје само задаци, они се морају – и могу – решавати. Када градите услугу, погледајте је одозго, процените све ризике који се могу десити. Ако их одмах видите, онда унапред обезбедите редундантност и могућност изградње инфраструктуре отпорне на грешке, јер свака тачка која може да поквари и доведе до неоперабилности сервиса ће то свакако учинити. Чак и ако вам се чини да неки инфраструктурни елементи сигурно неће пропасти – као што је с3, ипак имајте на уму да могу. И барем у теорији, имајте идеју шта ћете учинити са њима ако се нешто деси. Имајте план управљања ризиком. Када размишљате о томе да све радите аутоматски или ручно, процените ризике: шта ће се десити ако аутоматизација почне да мења све – зар то неће довести до још горе ситуације у поређењу са несрећом? Можда је негде потребно користити разуман компромис између употребе аутоматике и реакције дежурног инжењера, који ће проценити стварну слику и схватити да ли треба нешто променити на лицу места или „да, али не сада“.

Разуман компромис између перфекционизма и стварног труда, времена, новца који можете потрошити на шему коју ћете на крају имати.

Овај текст је ажурирана и проширена верзија извештаја Александра Демидова на конференцији Радни дан 4.

Извор: ввв.хабр.цом