Bitrix24: „Она што брзо се подига не се смета за паднато“

Денес, услугата Bitrix24 нема стотици гигабити сообраќај, ниту пак има огромна флота на сервери (иако, се разбира, има доста постоечки). Но, за многу клиенти тоа е главната алатка за работа во компанијата, таа е вистинска бизнис-критична апликација. Затоа, нема начин да паднете. Што ако падот навистина се случил, но услугата „се опорави“ толку брзо што никој ништо не забележал? И како е можно да се спроведе фајловер без да се изгуби квалитетот на работата и бројот на клиенти? Александар Демидов, директор за облак услуги во Bitrix24, зборуваше за нашиот блог за тоа како еволуирал системот за резервации во текот на 7-те години од постоењето на производот.

„Го лансиравме Bitrix24 како SaaS пред 7 години. Главната тешкотија веројатно беше следново: пред да биде јавно лансиран како SaaS, овој производ едноставно постоеше во формат на решение во кутии. Клиентите го купија од нас, го хостираа на нивните сервери, поставија корпоративен портал - општо решение за комуникација со вработените, складирање датотеки, управување со задачи, CRM, тоа е сè. И до 2012 година, решивме дека сакаме да го лансираме како SaaS, администрирајќи го сами, обезбедувајќи толеранција и доверливост на грешки. Попатно стекнавме искуство, бидејќи дотогаш едноставно го немавме - бевме само производители на софтвер, а не даватели на услуги.

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

Bitrix.24 како SaaS

Првиот прототип го составивме една година пред јавното лансирање, во 2011 година. Го составивме за околу една недела, го погледнавме, го вртевме - дури и работеше. Односно, можете да влезете во формуларот, да го внесете името на порталот таму, да се отвори нов портал и да се создаде корисничка база. Го разгледавме, начелно го проценивме производот, го укинавме и продолживме да го рафинираме цела година. Бидејќи имавме голема задача: не сакавме да направиме две различни основи на кодови, не сакавме да поддржуваме посебен спакуван производ, одделни решенија за облак - сакавме сето тоа да го направиме во еден код.

Типична веб-апликација во тоа време беше еден сервер на кој работи некој PHP-код, база на податоци mysql, датотеките се поставуваат, документите, сликите се ставаат во папката за испраќање - добро, сето тоа функционира. За жал, невозможно е да се стартува критично стабилна веб-услуга користејќи го ова. Таму, дистрибуираниот кеш не е поддржан, репликацијата на базата на податоци не е поддржана.

Ги формулиравме барањата: ова е способност да се наоѓате на различни локации, да поддржувате репликација и идеално да се наоѓате во различни географски распределени центри за податоци. Одделете ја логиката на производот и, всушност, складирањето податоци. Да може динамички да се скалира според оптоварувањето и целосно да толерира статика. Од овие размислувања, всушност, произлегоа барањата за производот, кои ги рафиниравме во текот на годината. За тоа време, во платформата, која се покажа како унифицирана - за решенија во кутии, за нашата сопствена услуга - направивме поддршка за оние работи што ни беа потребни. Поддршка за репликација на mysql на ниво на самиот производ: т.е. развивачот кој го пишува кодот не размислува за тоа како ќе се дистрибуираат неговите барања, тој го користи нашето api и знаеме како правилно да ги дистрибуираме барањата за пишување и читање помеѓу мајсторите и робови.

Направивме поддршка на ниво на производ за различни складишта на облак објекти: складирање на Google, amazon s3, плус поддршка за open stack swift. Затоа, ова беше погодно и за нас како услуга и за програмерите кои работат со спакувано решение: ако само го користат нашиот API за работа, тие не размислуваат за тоа каде датотеката на крајот ќе биде зачувана, локално на датотечниот систем или во објектното складирање на датотеки .

Како резултат на тоа, веднаш решивме дека ќе резервираме на ниво на целиот центар за податоци. Во 2012 година, стартувавме целосно на Amazon AWS бидејќи веќе имавме искуство со оваа платформа - нашата сопствена веб-страница беше хостирана таму. Бевме привлечени од фактот дека во секој регион Амазон има неколку зони на достапност - всушност, (во нивната терминологија) неколку центри за податоци кои се повеќе или помалку независни еден од друг и ни овозможуваат да резервираме на ниво на цел центар за податоци: ако ненадејно не успее, базите на податоци се реплицираат како господар, серверите на веб-апликациите се резервни копии и статичките податоци се преместуваат во складиштето на објекти s3. Товарот е избалансиран - во тоа време од Amazon elb, но малку подоцна дојдовме до сопствените load balancers, бидејќи ни требаше посложена логика.

Она што го сакаа е тоа што го добија...

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

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

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

Како функционира сето тоа? — Го префрламе сообраќајот во работен центар за податоци - ако дојде до несреќа во центарот за податоци, тогаш целосно, ако ова е нашата планирана работа со една база на податоци, тогаш дел од сообраќајот што им служи на овие клиенти го префрламе на втор центар за податоци, суспендирајќи тоа репликација. Доколку се потребни нови машини за веб-апликации бидејќи се зголеми оптоварувањето на вториот центар за податоци, тие ќе се стартуваат автоматски. Ја завршуваме работата, репликацијата е обновена и го враќаме целиот товар назад. Ако треба да пресликуваме некоја работа во вториот DC, на пример, да инсталираме ажурирања на системот или да ги промениме поставките во втората база на податоци, тогаш, генерално, го повторуваме истото, само во друга насока. И ако ова е несреќа, тогаш правиме сè тривијално: го користиме механизмот за справување со настани во системот за следење. Ако се активираат неколку проверки и статусот оди на критичен, тогаш го извршуваме овој управувач, управувач што може да ја изврши оваа или онаа логика. За секоја база на податоци, ние одредуваме кој сервер е фајловер за него и каде сообраќајот треба да се префрли ако е недостапен. Историски гледано, ние користиме нагиос или некои од неговите вилушки во една или друга форма. Во принцип, слични механизми постојат во речиси секој систем за следење; ние сè уште не користиме ништо покомплексно, но можеби еден ден ќе го искористиме. Сега мониторингот се активира поради недостапност и има можност да префрли нешто.

Дали резервиравме сè?

Имаме многу клиенти од САД, многу клиенти од Европа, многу клиенти кои се поблиску до Истокот - Јапонија, Сингапур и така натаму. Се разбира, огромен дел од клиентите се во Русија. Односно, работата не е во еден регион. Корисниците сакаат брз одговор, има барања за усогласување со различни локални закони, а во секој регион резервираме два центри за податоци, плус има некои дополнителни услуги, кои, повторно, се погодни за поставување во еден регион - за клиенти кои се во овој регион работи. REST ракувачи, сервери за авторизација, тие се помалку критични за работата на клиентот како целина, можете да се префрлите преку нив со мало прифатливо задоцнување, но не сакате повторно да го измислите тркалото за тоа како да ги следите и што да правите со нив. Затоа, се обидуваме максимално да ги искористиме постоечките решенија, наместо да развиваме некаква компетентност во дополнителни производи. И некаде тривијално користиме префрлување на ниво на DNS и ја одредуваме живоста на услугата со истиот DNS. Амазон има услуга Route 53, но тоа не е само DNS во кој можете да внесувате записи и тоа е тоа - тој е многу пофлексибилен и поудобен. Преку него можете да изградите гео-дистрибуирани услуги со геолокации, кога го користите за да одредите од каде доаѓа клиентот и да му дадете одредени записи - со негова помош можете да изградите фајловер архитектури. Истите здравствени проверки се конфигурирани во самата рута 53, ги поставувате крајните точки што се следат, поставувате метрики, поставувате кои протоколи да ја одредат „живоста“ на услугата - tcp, http, https; поставете ја фреквенцијата на проверки кои одредуваат дали услугата е жива или не. И во самиот DNS одредуваш што ќе биде примарно, што ќе биде секундарно, каде да се префрли ако здравствената проверка се активира во рутата 53. Сето ова може да се направи со некои други алатки, но зошто е погодно - ние го поставивме еднаш, а потоа воопшто не размислувај за тоа како правиме проверки, како се префрламе: сè работи само по себе.

Првото „но“: како и со што да се резервира самата рута 53? Кој знае, што ако нешто му се случи? За среќа, никогаш не стапнавме на ова гребло, но повторно ќе имам приказна пред тоа зошто мислевме дека сепак треба да направиме резервација. Овде однапред поставивме сламки за себе. Неколку пати дневно правиме целосно растоварување на сите зони што ги имаме на рутата 53. API на Amazon ви овозможува лесно да ги испраќате во JSON, а ние имаме неколку резервни сервери каде што го конвертираме, го поставуваме во форма на конфигурации и имаме, грубо кажано, резервна конфигурација. Ако нешто се случи, можеме брзо да го распоредиме рачно без да ги изгубиме податоците за поставките за DNS.

Второ „но“: Што на оваа слика сè уште не е резервирано? Самиот балансер! Нашата дистрибуција на клиенти по регион е многу едноставна. Ги имаме домените bitrix24.ru, bitrix24.com, .de - сега има 13 различни, кои работат во различни зони. Дојдовме до следново: секој регион има свои балансери. Ова го прави поудобно да се дистрибуира низ региони, во зависност од тоа каде е максималното оптоварување на мрежата. Ако ова е неуспех на ниво на еден балансер, тогаш едноставно се вади од употреба и се отстранува од dns. Доколку има некаков проблем со група балансери, тогаш тие се прават резервна копија на други сајтови, а префрлувањето меѓу нив се врши по истата рута53, бидејќи поради краткиот TTL, префрлувањето се случува во рок од максимум 2, 3, 5 минути. .

Трето „но“: Што се уште не е резервирано? S3, точно. Кога ги сместивме датотеките што ги чуваме за корисниците во s3, искрено верувавме дека е оклопен и нема потреба да резервираме ништо таму. Но, историјата покажува дека работите се случуваат поинаку. Генерално, Амазон го опишува S3 како фундаментална услуга, бидејќи самиот Амазон користи S3 за складирање на слики од машината, конфигурации, AMI слики, снимки... И ако s3 падне, како што се случи еднаш во текот на овие 7 години, колку што користевме bitrix24, го следи како обожавател Има цел куп работи што се појавуваат - неможност за стартување виртуелни машини, дефект на API итн.

И S3 може да падне - тоа се случи еднаш. Затоа, дојдовме до следнава шема: пред неколку години немаше сериозни капацитети за складирање на јавни предмети во Русија и ја разгледавме опцијата да направиме нешто свое... За среќа, не почнавме да го правиме ова, бидејќи ќе вкопавме во експертизата што ја немаме, ја имаме, и веројатно ќе се збркаме. Сега Mail.ru има складирање компатибилно со s3, Yandex го има и голем број други провајдери. На крајот дојдовме до идејата дека сакаме да имаме, прво, резервна копија, и второ, можност за работа со локални копии. Конкретно за рускиот регион, ја користиме услугата Mail.ru Hotbox, која е API компатибилна со s3. Не ни требаа некои поголеми модификации на кодот во апликацијата и го направивме следниот механизам: во s3 има тригери кои предизвикуваат создавање/бришење на објекти, Amazon има услуга наречена Lambda - ова е лансирање на код без сервер што ќе се изврши токму кога ќе се активираат одредени предизвикувачи.

Ние го направивме тоа многу едноставно: ако нашиот активирач се активира, извршуваме код што ќе го копира објектот во складиштето на Mail.ru. За целосно да започнеме работа со локални копии на податоци, потребна ни е и обратна синхронизација за клиентите кои се во рускиот сегмент да можат да работат со складирање што е поблиску до нив. Поштата е на пат да ги комплетира активирањата во своето складирање - ќе биде можно да се изврши обратна синхронизација на ниво на инфраструктура, но засега тоа го правиме на ниво на сопствен код. Ако видиме дека клиентот објавил датотека, тогаш на ниво на код го ставаме настанот во редица, го обработуваме и правиме обратна репликација. Зошто е лошо: ако работиме со нашите предмети надвор од нашиот производ, односно со некои надворешни средства, нема да го земеме предвид. Затоа, чекаме до крајот, кога ќе се појават тригери на ниво на складирање, така што без разлика од каде го извршуваме кодот, објектот што ни дошол да се копира во друга насока.

На ниво на код, ние ги регистрираме двете складишта за секој клиент: едното се смета за главно, другото се смета за резервно. Ако сè е во ред, ние работиме со складиштето што е поблиску до нас: тоа е, нашите клиенти кои се во Амазон, тие работат со S3, а оние што работат во Русија, работат со Hotbox. Ако знамето се активира, тогаш треба да се поврзе неуспехот и ние ги префрламе клиентите на друга меморија. Можеме да го штиклираме ова поле независно по регион и можеме да ги префрламе напред-назад. Сè уште не сме го користеле ова во пракса, но го обезбедивме овој механизам и мислиме дека еден ден ќе ни треба токму овој прекинувач и ќе ни се најде. Ова веќе се случи еднаш.

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

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

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

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

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

На крајот на март 2018 година, Роскомнадзор испрати писмо до најголемите оператори во кое се наведува дека планираат да блокираат неколку милиони IP-адреси на Amazon за да го блокираат... гласникот на Zello. Благодарение на истите тие провајдери - тие успешно го обелоденија писмото до сите, и имаше разбирање дека врската со Амазон може да се распадне. Беше петок, во паника истрчавме до нашите колеги од servers.ru, со зборовите: „Пријатели, ни требаат неколку сервери што ќе бидат лоцирани не во Русија, не во Амазон, туку, на пример, некаде во Амстердам“. за да можеме барем некако да инсталираме свој VPN и прокси таму за некои крајни точки на кои не можеме да влијаеме на кој било начин, на пример крајни точки на истиот s3 - не можеме да се обидеме да подигнеме нова услуга и да добиеме различна ИП, сè уште треба да стигнете таму. За само неколку дена, ги поставивме овие сервери, ги активиравме и, генерално, се подготвивме за моментот кога започна блокирањето. Љубопитно е што РКН, гледајќи ја вревата и паниката, рече: „Не, сега нема да блокираме ништо“. (Но, ова е точно до моментот кога Телеграма почна да се блокира.) Откако ги поставивме можностите за бајпас и сфативме дека блокирањето не е воведено, ние, сепак, не почнавме да ја средуваме целата работа. Да, за секој случај.

И во 2019 година сè уште живееме во услови на блокирање. Погледнав синоќа: околу милион IP-адреси и понатаму се блокирани. Точно, Амазон беше скоро целосно деблокиран, на својот врв достигна 20 милиони адреси... Генерално, реалноста е дека можеби нема кохерентност, добра кохерентност. Одеднаш. Можеби не постои од технички причини - пожари, багери, сето тоа. Или, како што видовме, не целосно технички. Затоа, некој голем и голем, со свои AS, веројатно може да управува со ова на други начини - директно поврзување и другите работи се веќе на ниво l2. Но, во едноставна верзија, како нашата или дури и помала, можете, за секој случај, да имате вишок на ниво на сервери подигнати на друго место, однапред конфигурирани vpn, прокси, со можност брзо да ја префрлите конфигурацијата на нив во тие сегменти кои се клучни за вашата поврзаност. Ова ни беше добро повеќе од еднаш, кога започна блокирањето на Амазон; во најлошото сценарио, дозволивме само S3 сообраќај преку нив, но постепено сето тоа беше решено.

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

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

Хипотетички, за Amazon ја разгледуваме можноста за резервација на ниво на друг провајдер; можеби Google, можеби некој друг... Но, досега во пракса забележавме дека додека Amazon има несреќи на ниво на една зона на достапност, несреќите на ниво на цел регион се доста ретки. Затоа, теоретски имаме идеја дека би можеле да направиме резервација „Амазон не е Амазон“, но во пракса тоа сè уште не е случај.

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

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

Нашата логика за различни автоматски прекинувачи на одредени несреќи е многу добро опишана со овој график. Почнавме - не знаевме како да правиме ништо, скоро целата работа беше направена рачно. Тогаш сфативме дека можеме да прикачиме автоматизација на сè и, на пример, да спиеме мирно. И одеднаш стапнуваме на мега-гребло: се активира лажна позитива и го менуваме сообраќајот напред-назад кога, на добар начин, не требаше да го направиме ова. Следствено, репликацијата се распаѓа или нешто друго - ова е самата долина на очајот. И тогаш доаѓаме до разбирање дека мора да пристапиме мудро на сè. Тоа е, има смисла да се потпреме на автоматизација, обезбедувајќи можност за лажни аларми. Но! ако последиците можат да бидат поразителни, тогаш подобро е да се остави на дежурната смена, на дежурните инженери, кои ќе се уверат и надгледуваат дека навистина има несреќа и рачно ќе ги извршат потребните дејствија...

Заклучок

Во текот на 7 години, отидовме од фактот дека кога нешто ќе падне, владееше паника-паника, до сфаќањето дека проблемите не постојат, постојат само задачи, тие мора - и можат - да се решат. Кога градите услуга, погледнете ја одозгора, проценете ги сите ризици што може да се случат. Ако ги видите веднаш, тогаш однапред обезбедете технолошки вишок и можност за изградба на инфраструктура толерантна за грешки, бидејќи секоја точка што може да пропадне и да доведе до нефункционалност на услугата дефинитивно ќе го стори тоа. И дури и да ви се чини дека некои елементи од инфраструктурата дефинитивно нема да откажат - како истиот s3, сепак имајте на ум дека можат. И барем во теорија, имајте идеја што ќе правите со нив ако нешто се случи. Имајте план за управување со ризик. Кога размислувате да правите сè автоматски или рачно, проценете ги ризиците: што ќе се случи ако автоматизацијата почне да менува сè - зарем ова нема да доведе до уште полоша ситуација во споредба со несреќа? Можеби некаде е неопходно да се користи разумен компромис помеѓу употребата на автоматизација и реакцијата на дежурниот инженер, кој ќе ја процени реалната слика и ќе разбере дали нешто треба да се префрли на лице место или „да, но не сега“.

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

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

Извор: www.habr.com