Služba Bitrix24 dnes nemá stovky gigabitov prenosu ani nemá obrovskú flotilu serverov (hoci, samozrejme, existuje niekoľko serverov). Pre mnohých klientov je to však hlavný nástroj pre prácu v spoločnosti, je to skutočne kritická aplikácia. Preto neexistuje spôsob, ako spadnúť. Čo ak k havárii skutočne došlo, ale služba sa „zotavila“ tak rýchlo, že si nikto nič nevšimol? A ako je možné zaviesť failover bez straty kvality práce a počtu klientov? Alexander Demidov, riaditeľ cloudových služieb Bitrix24, pre náš blog hovoril o tom, ako sa rezervačný systém vyvíjal za 7 rokov existencie produktu.
„Bitrix24 sme spustili ako SaaS pred 7 rokmi. Hlavný problém bol pravdepodobne nasledujúci: predtým, než bol verejne spustený ako SaaS, tento produkt jednoducho existoval vo formáte krabicového riešenia. Klienti si to od nás kúpili, hostili na svojich serveroch, zriadili firemný portál – všeobecné riešenie pre komunikáciu zamestnancov, ukladanie súborov, správu úloh, CRM, to je všetko. A do roku 2012 sme sa rozhodli, že ho chceme spustiť ako SaaS, spravovať si ho sami, zabezpečiť odolnosť voči chybám a spoľahlivosť. Skúsenosti sme získavali za pochodu, pretože dovtedy sme ich jednoducho nemali – boli sme len výrobcovia softvéru, nie poskytovatelia služieb.
Pri spustení služby sme pochopili, že najdôležitejšie je zabezpečiť odolnosť voči poruchám, spoľahlivosť a stálu dostupnosť služby, pretože ak máte jednoduchú bežnú webovú stránku, napríklad obchod, padne na vás a sedí tam hodinu trpíte len vy, prichádzate o zákazky, prichádzate o klientov, ale pre samotného klienta to nie je veľmi kritické. Samozrejme, bol naštvaný, ale išiel a kúpil si to na inej stránke. A ak ide o aplikáciu, na ktorej je viazaná všetka práca vo firme, komunikácia, rozhodnutia, tak najdôležitejšie je získať si dôveru používateľov, teda nesklamať a nespadnúť. Pretože všetka práca sa môže zastaviť, ak niečo vo vnútri nefunguje.
Bitrix.24 ako SaaS
Prvý prototyp sme zostavili rok pred verejným uvedením na trh, v roku 2011. Zložili sme to asi za týždeň, pozreli, zakrútili - dokonca to fungovalo. To znamená, že by ste mohli ísť do formulára, zadať tam názov portálu, otvoril by sa nový portál a vytvorila by sa užívateľská základňa. Pozreli sme sa na to, produkt v zásade posúdili, zošrotovali a celý rok pokračovali v jeho zušľachťovaní. Pretože sme mali veľkú úlohu: nechceli sme vytvoriť dve rôzne kódové základne, nechceli sme podporovať samostatný zabalený produkt, samostatné cloudové riešenia – chceli sme to všetko urobiť v rámci jedného kódu.
Typickou webovou aplikáciou v tej dobe bol jeden server, na ktorom beží nejaký PHP kód, mysql databáza, nahrávajú sa súbory, dokumenty, obrázky sa ukladajú do nahrávacieho priečinka – no, všetko funguje. Bohužiaľ, nie je možné spustiť kriticky stabilnú webovú službu pomocou tohto. Tam distribuovaná vyrovnávacia pamäť nie je podporovaná, replikácia databázy nie je podporovaná.
Sformulovali sme požiadavky: ide o schopnosť byť umiestnený na rôznych miestach, podporovať replikáciu a ideálne byť umiestnený v rôznych geograficky distribuovaných dátových centrách. Oddeľte logiku produktu a vlastne aj ukladanie dát. Byť schopný dynamicky meniť mierku podľa zaťaženia a úplne tolerovať statiku. Z týchto úvah vlastne vyplynuli požiadavky na produkt, ktoré sme v priebehu roka dolaďovali. Počas tejto doby sme v platforme, ktorá sa ukázala ako jednotná – pre krabicové riešenia, pre našu vlastnú službu – vytvorili podporu pre tie veci, ktoré sme potrebovali. Podpora replikácie mysql na úrovni samotného produktu: to znamená, že vývojár, ktorý píše kód, nemyslí na to, ako budú distribuované jeho požiadavky, používa naše API a vieme, ako správne distribuovať požiadavky na zápis a čítanie medzi mastermi. a otrokmi.
Na úrovni produktu sme vytvorili podporu pre rôzne úložiská cloudových objektov: úložisko Google, amazon s3 plus podporu pre open stack swift. Preto to vyhovovalo ako pre nás ako službu, tak aj pre vývojárov, ktorí pracujú s baleným riešením: ak na prácu používajú len naše API, nemyslia na to, kde sa súbor nakoniec uloží, či lokálne v súborovom systéme resp. v úložisku súborov objektu.
V dôsledku toho sme sa okamžite rozhodli, že rezervujeme na úrovni celého dátového centra. V roku 2012 sme spustili úplne Amazon AWS, pretože sme už s touto platformou mali skúsenosti – bola tam hosťovaná naša vlastná webová stránka. Upútalo nás, že v každom regióne má Amazon niekoľko zón dostupnosti – vlastne (v ich terminológii) niekoľko dátových centier, ktoré sú viac-menej na sebe nezávislé a umožňujú nám rezervovať na úrovni celého dátového centra: ak náhle zlyhá, databázy sa replikujú master-master, servery webových aplikácií sa zálohujú a statické údaje sa presunú do úložiska objektov s3. Záťaž je vyvážená – v tom čase Amazon elb, ale o niečo neskôr sme prišli na vlastné load balancery, pretože sme potrebovali zložitejšiu logiku.
Čo chceli, to aj dostali...
Všetky základné veci, ktoré sme chceli zabezpečiť – odolnosť samotných serverov, webových aplikácií, databáz – všetko fungovalo dobre. Najjednoduchší scenár: ak jedna z našich webových aplikácií zlyhá, potom je všetko jednoduché – sú vypnuté z vyrovnávania.
Balancér (vtedy to bol elb od Amazonu) označil stroje, ktoré boli nefunkčné, za nezdravé a vypol na nich rozloženie záťaže. Automatické škálovanie Amazonu fungovalo: keď zaťaženie rástlo, do skupiny automatického škálovania boli pridané nové stroje, zaťaženie bolo rozdelené na nové stroje - všetko bolo v poriadku. S našimi balancermi je logika približne rovnaká: ak sa niečo stane s aplikačným serverom, odstránime z neho požiadavky, vyhodíme tieto stroje, spustíme nové a pokračujeme v práci. Schéma sa v priebehu rokov trochu zmenila, ale naďalej funguje: je jednoduchá, zrozumiteľná a nie sú s ňou žiadne ťažkosti.
Pracujeme po celom svete, špičky zaťaženia zákazníkov sú úplne odlišné a priateľským spôsobom by sme mali byť schopní kedykoľvek a bez povšimnutia zákazníkov vykonať určité servisné práce na akýchkoľvek komponentoch nášho systému. Preto máme možnosť vypnúť databázu z prevádzky a prerozdeliť záťaž do druhého dátového centra.
Ako to celé funguje? — Prepneme prevádzku do fungujúceho dátového centra – ak dôjde k nehode v dátovom centre, tak úplne, ak ide o našu plánovanú prácu s jednou databázou, tak časť prevádzky slúžiacej týmto klientom presunieme do druhého dátového centra a pozastavíme to replikácia. Ak sú potrebné nové stroje pre webové aplikácie, pretože sa zvýšilo zaťaženie druhého dátového centra, automaticky sa spustia. Dokončíme prácu, replikácia sa obnoví a celú záťaž vrátime späť. Ak potrebujeme zrkadliť nejakú prácu v druhom DC, napríklad nainštalovať aktualizácie systému alebo zmeniť nastavenia v druhej databáze, potom vo všeobecnosti opakujeme to isté, len v opačnom smere. A ak ide o nehodu, potom robíme všetko triviálne: používame mechanizmus obsluhy udalostí v monitorovacom systéme. Ak sa spustí niekoľko kontrol a stav sa stane kritickým, spustíme tento handler, handler, ktorý môže vykonávať tú alebo onú logiku. Pre každú databázu špecifikujeme, ktorý server je pre ňu núdzový a kam je potrebné prepnúť prevádzku, ak je nedostupná. Historicky používame nagios alebo niektoré jeho vidlice v tej či onej forme. V zásade podobné mechanizmy existujú takmer v každom monitorovacom systéme, nič zložitejšie zatiaľ nepoužívame, ale možno niekedy áno. Teraz je monitorovanie spúšťané nedostupnosťou a má možnosť niečo prepnúť.
Máme všetko rezervované?
Máme veľa klientov z USA, veľa klientov z Európy, veľa klientov, ktorí sú bližšie k východu – Japonsko, Singapur a podobne. Samozrejme, obrovský podiel klientov je v Rusku. To znamená, že práca nie je v jednom regióne. Používatelia chcú rýchlu reakciu, sú tam požiadavky na dodržiavanie rôznych miestnych zákonov a v rámci každého regiónu máme rezervované dve dátové centrá, plus sú tu nejaké doplnkové služby, ktoré je opäť vhodné umiestniť v rámci jedného regiónu – pre klientov, ktorí sú v tento región funguje. REST handlery, autorizačné servery, sú menej kritické pre fungovanie klienta ako celku, môžete sa cez ne prepínať s malým prijateľným oneskorením, ale nechcete znovu vynájsť koleso, ako ich monitorovať a čo robiť s nimi. Snažíme sa preto maximálne využiť existujúce riešenia, než rozvíjať nejakú kompetenciu v ďalších produktoch. A niekde triviálne používame prepínanie na úrovni DNS a živosť služby určujeme rovnakým DNS. Amazon má službu Route 53, ale nie je to len DNS, do ktorého môžete zadávať záznamy, a to je všetko – je to oveľa flexibilnejšie a pohodlnejšie. Prostredníctvom neho môžete budovať geograficky distribuované služby s geolokáciami, keď pomocou neho určíte, odkiaľ klient prišiel a poskytnete mu určité záznamy - s jeho pomocou môžete vybudovať architektúry zlyhania. Rovnaké kontroly stavu sú nakonfigurované v samotnej Route 53, nastavujete koncové body, ktoré sa monitorujú, nastavujete metriky, nastavujete, ktoré protokoly určujú „živosť“ služby – tcp, http, https; nastaviť frekvenciu kontrol, ktoré určujú, či je služba nažive alebo nie. A v samotnom DNS určíte, čo bude primárne, čo sekundárne, kam sa prepnúť, ak sa kontrola stavu spustí vo vnútri cesty 53. To všetko sa dá urobiť pomocou niektorých iných nástrojov, ale prečo je to pohodlné - nastavíme to raz hore a potom na to vôbec nemysli, ako robíme kontroly, ako sa prepíname: všetko funguje samo.
prvé "ale": ako a čím rezervovať samotnú trasu 53? Ktovie, čo ak sa mu niečo stane? Našťastie sme na tieto hrable nikdy nestúpili, ale opäť budem mať pred sebou príbeh, prečo sme si mysleli, že ešte musíme urobiť rezerváciu. Tu sme si vopred rozložili slamky. Niekoľkokrát denne robíme kompletnú vykládku všetkých zón, ktoré máme na trase 53. Rozhranie API Amazonu vám umožňuje jednoducho ich odosielať v JSON a máme niekoľko záložných serverov, kde to konvertujeme, nahrávame vo forme konfigurácií a máme, zhruba povedané, konfiguráciu zálohy. Ak sa niečo stane, môžeme to rýchlo nasadiť manuálne bez straty údajov o nastaveniach DNS.
druhé "ale": Čo na tomto obrázku ešte nebolo rezervované? Samotný vyvažovač! Naša distribúcia klientov podľa regiónov je veľmi jednoduchá. Máme domény bitrix24.ru, bitrix24.com, .de - teraz je ich 13 rôznych, ktoré fungujú v rôznych zónach. Dospeli sme k nasledovnému: každý región má svoje vlastné vyrovnávače. To uľahčuje distribúciu medzi regiónmi v závislosti od toho, kde je špičkové zaťaženie siete. Ak ide o poruchu na úrovni jedného vyvažovača, potom sa jednoducho vyradí z prevádzky a odstráni z DNS. Ak je nejaký problém so skupinou balancerov, tak sú zálohované na iných stránkach a prepínanie medzi nimi prebieha rovnakou cestou53, pretože kvôli krátkemu TTL dochádza k prepínaniu maximálne do 2, 3, 5 minút .
Tretie "ale": Čo ešte nie je rezervované? S3, správne. Keď sme súbory, ktoré ukladáme pre používateľov, umiestnili do s3, úprimne sme verili, že je to priebojné brnenie a nie je potrebné tam nič rezervovať. História však ukazuje, že veci sa dejú inak. Vo všeobecnosti Amazon opisuje S3 ako základnú službu, pretože samotný Amazon používa S3 na ukladanie obrazov strojov, konfigurácií, obrazov AMI, snímok... A ak s3 spadne, ako sa to stalo raz počas týchto 7 rokov, pokiaľ používame bitrix24, nasleduje to ako fanúšik Je tu veľa vecí, ktoré sa objavia – nemožnosť spustiť virtuálne stroje, zlyhanie API atď.
A S3 môže spadnúť - stalo sa to raz. Preto sme dospeli k nasledujúcej schéme: pred niekoľkými rokmi v Rusku neboli žiadne seriózne sklady verejných objektov a zvažovali sme možnosť urobiť niečo vlastné... Našťastie sme to nezačali robiť, pretože by sme zahrabali sa do odborných znalostí, ktoré nemáme, a pravdepodobne by to pokazili. Teraz má Mail.ru úložisko kompatibilné s s3, má ho Yandex a má ho množstvo ďalších poskytovateľov. Nakoniec sme dospeli k myšlienke, že chceme mať po prvé zálohovanie a po druhé možnosť pracovať s lokálnymi kópiami. Konkrétne pre ruský región používame službu Mail.ru Hotbox, ktorá je API kompatibilná s s3. Nepotrebovali sme žiadne veľké úpravy kódu vo vnútri aplikácie a urobili sme nasledujúci mechanizmus: v s3 sú spúšťače, ktoré spúšťajú vytváranie/mazanie objektov, Amazon má službu s názvom Lambda – ide o spúšťanie kódu bez servera ktorý sa vykoná práve vtedy, keď sa spustia určité spúšťače.
Urobili sme to veľmi jednoducho: ak sa spustí náš spúšťač, spustíme kód, ktorý skopíruje objekt do úložiska Mail.ru. Na úplné spustenie práce s lokálnymi kópiami údajov potrebujeme aj spätnú synchronizáciu, aby klienti, ktorí sú v ruskom segmente, mohli pracovať s úložiskom, ktoré je im bližšie. Mail sa chystá dokončiť spúšťače vo svojom úložisku – spätnú synchronizáciu bude možné vykonávať na úrovni infraštruktúry, no zatiaľ to robíme na úrovni vlastného kódu. Ak vidíme, že klient odoslal súbor, potom na úrovni kódu umiestnime udalosť do frontu, spracujeme ju a vykonáme spätnú replikáciu. Prečo je to zlé: ak robíme nejakú prácu s našimi predmetmi mimo nášho produktu, teda nejakými vonkajšími prostriedkami, nebudeme to brať do úvahy. Čakáme teda až na koniec, keď sa na úrovni úložiska objavia spúšťače, aby sa bez ohľadu na to, odkiaľ kód spustíme, objekt, ktorý k nám prišiel, skopíroval opačným smerom.
Na úrovni kódu registrujeme pre každého klienta obe úložiská: jedno sa považuje za hlavné, druhé za záložné. Ak je všetko v poriadku, pracujeme s úložiskom, ktoré je nám bližšie: teda naši klienti, ktorí sú v Amazone, pracujú s S3 a tí, ktorí pracujú v Rusku, pracujú s Hotboxom. Ak sa spustí príznak, potom by sa malo pripojiť zlyhanie a prepneme klientov na iné úložisko. Toto políčko môžeme zaškrtnúť nezávisle podľa regiónu a môžeme ich prepínať tam a späť. Zatiaľ sme to v praxi nepoužili, ale zabezpečili sme tento mechanizmus a myslíme si, že jedného dňa budeme potrebovať práve tento prepínač a príde vhod. Toto sa už raz stalo.
A Amazon utiekol...
Tento apríl si pripomíname výročie začiatku blokovania telegramu v Rusku. Najviac postihnutým poskytovateľom, ktorý pod toto spadal, je Amazon. A, žiaľ, viac utrpeli ruské spoločnosti, ktoré pracovali pre celý svet.
Ak je spoločnosť globálna a Rusko je pre ňu veľmi malý segment, 3-5% - no, tak či onak, môžete ich obetovať.
Ak ide o čisto ruskú spoločnosť - som si istý, že sa musí nachádzať lokálne - bude to jednoducho pohodlné pre samotných používateľov, pohodlné a bude to menej rizík.
Čo ak ide o spoločnosť, ktorá pôsobí globálne a má približne rovnaký počet klientov z Ruska a niekde z celého sveta? Dôležitá je konektivita segmentov, ktoré musia navzájom fungovať tak či onak.
Roskomnadzor koncom marca 2018 poslal list najväčším operátorom, v ktorom uviedol, že plánujú zablokovať niekoľko miliónov IP adries Amazonu, aby zablokovali... messenger Zello. Vďaka tým istým poskytovateľom - úspešne unikli list všetkým a došlo k pochopeniu, že spojenie s Amazonom sa môže rozpadnúť. Bol piatok, v panike sme bežali ku kolegom zo servers.ru a povedali sme: „Priatelia, potrebujeme niekoľko serverov, ktoré sa nebudú nachádzať v Rusku, nie v Amazone, ale napríklad niekde v Amsterdame,“ aby aby sme si tam mohli aspoň nejako nainštalovať vlastnú VPN a proxy pre niektoré koncové body, ktoré nemôžeme nijako ovplyvniť, napríklad koncové body toho istého s3 - nemôžeme skúšať navýšiť novú službu a získať inú IP, my sa tam ešte musíte dostať. Za pár dní sme tieto servery nastavili, spustili a vo všeobecnosti sme sa pripravili na začiatok blokovania. Je zvláštne, že RKN pri pohľade na ten rozruch a paniku povedal: „Nie, teraz nebudeme nič blokovať. (To je však presne do momentu, kedy sa začal blokovať Telegram.) Po nastavení možností obchvatu a zistení, že blokovanie nebolo zavedené, sme však celú záležitosť nezačali riešiť. Áno, pre každý prípad.
A v roku 2019 stále žijeme v podmienkach blokovania. Včera večer som sa pozrel: stále je blokovaných asi milión IP. Pravda, Amazon bol takmer úplne odblokovaný, na vrchole dosiahol 20 miliónov adries... Vo všeobecnosti je realita taká, že tam nemusí byť súdržnosť, dobrá súdržnosť. Zrazu. Nemusí existovať z technických príčin – požiare, bagre, všetko ostatné. Alebo, ako sme videli, nie úplne technické. Preto niekto veľký a veľký, s vlastnými AS, to asi zvládne aj inak - direct connect a ostatné veci sú už na úrovni l2. Ale v jednoduchej verzii, ako je naša alebo ešte menšia, môžete pre každý prípad mať redundanciu na úrovni serverov postavených niekde inde, vopred nakonfigurovaných vpn, proxy, s možnosťou rýchleho prepínania konfigurácie na ne v týchto segmentoch ktoré sú rozhodujúce pre vaše pripojenie. To sa nám viackrát hodilo, keď sa začalo s blokovaním Amazonu, v najhoršom prípade sme cez ne povolili iba prevádzku S3, no postupne sa to všetko vyriešilo.
Ako rezervovať... celého poskytovateľa?
Momentálne nemáme scenár pre prípad, že by celý Amazon spadol. Podobný scenár máme aj pre Rusko. V Rusku nás hostil jeden poskytovateľ, od ktorého sme si vybrali niekoľko stránok. A pred rokom sme čelili problému: aj keď ide o dve dátové centrá, môžu sa vyskytnúť problémy už na úrovni konfigurácie siete poskytovateľa, ktoré budú stále ovplyvňovať obe dátové centrá. A môžeme skončiť nedostupní na oboch stránkach. Samozrejme, že sa tak aj stalo. Nakoniec sme prehodnotili architektúru vo vnútri. Veľmi sa to nezmenilo, ale pre Rusko máme teraz dve stránky, ktoré nie sú od rovnakého poskytovateľa, ale od dvoch rôznych. Ak jeden zlyhá, môžeme prejsť na druhý.
Hypoteticky pre Amazon zvažujeme možnosť rezervácie na úrovni iného poskytovateľa; možno Google, možno niekto iný... Ale zatiaľ sme v praxi pozorovali, že kým Amazon má nehody na úrovni jednej zóny dostupnosti, nehody na úrovni celého regiónu sú dosť zriedkavé. Preto teoreticky máme predstavu, že by sme mohli urobiť rezerváciu „Amazon nie je Amazon“, ale v praxi to tak ešte nie je.
Pár slov o automatizácii
Je automatizácia vždy potrebná? Tu je vhodné pripomenúť Dunning-Krugerov efekt. Na osi „x“ sú naše vedomosti a skúsenosti, ktoré získame, a na osi „y“ dôvera v naše činy. Spočiatku nič nevieme a nie sme si vôbec istí. Potom sa trochu dozvieme a staneme sa mega sebavedomými - toto je takzvaný „vrchol hlúposti“, ktorý dobre ilustruje obrázok „demencia a odvaha“. Potom sme sa trochu naučili a sme pripravení ísť do boja. Potom šliapeme po megazávažných chybách a ocitneme sa v údolí zúfalstva, keď sa nám zdá, že niečo vieme, no v skutočnosti toho veľa nevieme. Potom, keď naberáme skúsenosti, stávame sa sebavedomejšími.
Našu logiku o rôznych automatických prepínačoch pri určitých nehodách veľmi dobre vystihuje tento graf. Začali sme - nevedeli sme nič robiť, takmer všetka práca sa robila ručne. Potom sme si uvedomili, že ku všetkému môžeme pripojiť automatizáciu a napríklad pokojne spať. A zrazu stúpime na mega-rake: spustí sa falošný poplach a prepíname premávku tam a späť, keď sme to v dobrom slova zmysle nemali robiť. V dôsledku toho sa replikácia pokazí alebo niečo iné – toto je samotné údolie zúfalstva. A potom prídeme na to, že ku všetkému musíme pristupovať s rozumom. To znamená, že má zmysel spoliehať sa na automatizáciu, ktorá poskytuje možnosť falošných poplachov. Ale! ak môžu byť následky zničujúce, tak je lepšie to nechať na služobnú zmenu, na službukonajúcich inžinierov, ktorí sa postarajú a dohliadajú, či naozaj došlo k nehode a potrebné úkony vykonajú ručne...
Záver
V priebehu 7 rokov sme prešli od toho, že keď niečo padlo, nastala panika, k pochopeniu, že problémy neexistujú, sú len úlohy, tie sa musia – a dajú sa – riešiť. Keď budujete službu, pozerajte sa na ňu zhora, posúďte všetky riziká, ktoré môžu nastať. Ak ich hneď uvidíte, tak vopred zabezpečte redundanciu a možnosť vybudovania infraštruktúry odolnej voči chybám, pretože každý bod, ktorý môže zlyhať a viesť k nefunkčnosti služby, to určite urobí. A aj keď sa vám zdá, že niektoré prvky infraštruktúry určite nezlyhajú – ako ten istý s3, stále majte na pamäti, že môžu. A aspoň teoreticky majte predstavu o tom, čo s nimi urobíte, ak sa niečo stane. Majte plán riadenia rizík. Keď uvažujete o tom, že všetko urobíte automaticky alebo manuálne, zvážte riziká: čo sa stane, ak automatizácia začne všetko prepínať – nepovedie to k ešte horšej situácii v porovnaní s nehodou? Možno niekde treba použiť rozumný kompromis medzi využitím automatizácie a reakciou technika v službe, ktorý vyhodnotí skutočný obraz a pochopí, či treba niečo prepínať na mieste alebo „áno, ale nie teraz“.
Rozumný kompromis medzi perfekcionizmom a skutočným úsilím, časom, peniazmi, ktoré môžete minúť na schému, ktorú nakoniec budete mať.
Tento text je aktualizovanou a rozšírenou verziou správy Alexandra Demidova na konferencii .
Zdroj: hab.com