Dnes služba Bitrix24 nemá stovky gigabitů provozu ani nemá obrovskou flotilu serverů (ačkoli jich samozřejmě existuje několik). Pro mnoho klientů je to ale hlavní nástroj pro práci ve firmě, je to skutečně kritická aplikace. Proto neexistuje způsob, jak spadnout. Co když k havárii skutečně došlo, ale služba se „zotavila“ tak rychle, že si nikdo ničeho nevšiml? A jak je možné zavést failover bez ztráty kvality práce a počtu klientů? Alexander Demidov, ředitel cloudových služeb Bitrix24, pro náš blog hovořil o tom, jak se rezervační systém vyvíjel za 7 let existence produktu.
„Bitrix24 jsme spustili jako SaaS před 7 lety. Hlavní problém byl pravděpodobně následující: než byl veřejně spuštěn jako SaaS, tento produkt jednoduše existoval ve formátu krabicového řešení. Klienti si to od nás koupili, hostovali na svých serverech, založili si firemní portál – obecné řešení pro komunikaci zaměstnanců, ukládání souborů, správu úkolů, CRM, toť vše. A do roku 2012 jsme se rozhodli, že jej chceme spustit jako SaaS, spravovat jej sami, zajistit odolnost proti chybám a spolehlivost. Zkušenosti jsme získávali za pochodu, protože do té doby jsme je prostě neměli – byli jsme pouze výrobci softwaru, nikoli poskytovatelé služeb.
Při spouštění služby jsme pochopili, že nejdůležitější je zajistit odolnost proti poruchám, spolehlivost a stálou dostupnost služby, protože pokud máte jednoduchý obyčejný web, například obchod, spadne na vás a sedí tam hodinu trpíte jen vy, přicházíte o zakázky, přicházíte o klienty, ale pro vašeho klienta samotného to není příliš kritické. Byl samozřejmě naštvaný, ale šel a koupil to na jiném webu. A pokud se jedná o aplikaci, na které je vázána veškerá práce uvnitř firmy, komunikace, rozhodování, tak nejdůležitější je získat si důvěru uživatelů, tedy nezklamat je a nespadnout. Protože veškerá práce se může zastavit, pokud něco uvnitř nefunguje.
Bitrix.24 jako SaaS
První prototyp jsme smontovali rok před veřejným uvedením, v roce 2011. Asi za týden jsme to smontovali, prohlédli, zatočili - dokonce to fungovalo. To znamená, že byste mohli jít do formuláře, zadat tam název portálu, otevřel by se nový portál a vytvořila by se uživatelská základna. Podívali jsme se na to, výrobek v zásadě posoudili, sešrotovali a celý rok pokračovali v jeho zušlechťování. Protože jsme měli velký úkol: nechtěli jsme vytvářet dvě různé kódové báze, nechtěli jsme podporovat samostatný zabalený produkt, samostatná cloudová řešení – chtěli jsme to všechno dělat v rámci jednoho kódu.
Typickou webovou aplikací v té době byl jeden server, na kterém běží nějaký PHP kód, databáze mysql, soubory se nahrávají, dokumenty, obrázky se vkládají do složky pro nahrávání - no, všechno funguje. Bohužel pomocí toho není možné spustit kriticky stabilní webovou službu. Tam distribuovaná mezipaměť není podporována, replikace databáze není podporována.
Formulovali jsme požadavky: jedná se o schopnost být umístěn na různých místech, podporovat replikaci a ideálně být umístěn v různých geograficky distribuovaných datových centrech. Oddělte logiku produktu a vlastně i úložiště dat. Být schopen dynamicky škálovat podle zatížení a tolerovat zcela statiku. Z těchto úvah vlastně vyplynuly požadavky na produkt, které jsme v průběhu roku zpřesňovali. Během této doby jsme v platformě, která se ukázala jako unifikovaná – pro krabicová řešení, pro naši vlastní službu – vytvořili podporu pro věci, které jsme potřebovali. Podpora replikace mysql na úrovni samotného produktu: to znamená, že vývojář, který píše kód, nepřemýšlí o tom, jak budou jeho požadavky distribuovány, používá naše api a my víme, jak správně distribuovat požadavky na zápis a čtení mezi mastery a otroky.
Na úrovni produktu jsme vytvořili podporu pro různá úložiště cloudových objektů: úložiště google, amazon s3 a podporu pro open stack swift. To tedy vyhovovalo jak nám jako službě, tak i vývojářům, kteří pracují s baleným řešením: pokud k práci používají jen naše API, nepřemýšlejí o tom, kam se soubor nakonec uloží, lokálně v souborovém systému popř. v úložišti objektového souboru.
Ve výsledku jsme se okamžitě rozhodli, že budeme rezervovat na úrovni celého datového centra. V roce 2012 jsme spustili celý Amazon AWS, protože jsme s touto platformou již měli zkušenosti – hostovali jsme zde vlastní web. Zaujalo nás, že v každém regionu má Amazon několik zón dostupnosti – vlastně (v jejich terminologii) několik datových center, která jsou na sobě víceméně nezávislá a umožňují nám rezervaci na úrovni celého datového centra: pokud náhle selže, databáze jsou replikovány master-master, webové aplikační servery jsou zálohovány a statická data jsou přesunuta do úložiště objektů s3. Zátěž je vyvážená – v té době Amazon elb, ale o něco později jsme přišli na vlastní load balancery, protože jsme potřebovali složitější logiku.
Co chtěli, to dostali...
Všechny základní věci, které jsme chtěli zajistit – odolnost samotných serverů, webových aplikací, databází – vše fungovalo dobře. Nejjednodušší scénář: pokud jedna z našich webových aplikací selže, pak je vše jednoduché – jsou vypnuty z balancování.
Balancér (tehdy to byl elb Amazonu) označil stroje, které byly nefunkční, za nezdravé a vypnul na nich rozložení zátěže. Automatické škálování Amazonu fungovalo: když zatížení rostlo, do skupiny automatického škálování byly přidány nové stroje, zatížení bylo rozděleno na nové stroje - vše bylo v pořádku. S našimi balancery je logika přibližně stejná: pokud se něco stane s aplikačním serverem, odstraníme z něj požadavky, vyhodíme tyto stroje, spustíme nové a pokračujeme v práci. Schéma se v průběhu let trochu změnilo, ale stále funguje: je jednoduché, srozumitelné a nejsou s ním žádné potíže.
Pracujeme po celém světě, špičky vytížení zákazníků jsou zcela odlišné a přátelským způsobem bychom měli být schopni kdykoli a bez povšimnutí zákazníků provést určité servisní práce na jakékoli součásti našeho systému. Máme tedy možnost databázi vypnout z provozu a přerozdělit zátěž do druhého datového centra.
Jak to celé funguje? — Přepneme provoz do fungujícího datového centra – pokud dojde k nehodě v datovém centru, tak úplně, pokud se jedná o naši plánovanou práci s jednou databází, pak část provozu obsluhující tyto klienty převedeme do druhého datového centra a pozastavíme to replikace. Pokud jsou pro webové aplikace potřeba nové stroje, protože se zvýšilo zatížení druhého datového centra, spustí se automaticky. Dokončíme práci, replikace se obnoví a vrátíme celou zátěž zpět. Pokud potřebujeme zrcadlit nějakou práci ve druhém DC, například nainstalovat aktualizace systému nebo změnit nastavení ve druhé databázi, pak obecně opakujeme to samé, jen v opačném směru. A pokud se jedná o nehodu, pak vše děláme triviálně: používáme mechanismus obsluhy událostí v monitorovacím systému. Pokud je spuštěno několik kontrol a stav přejde na kritický, spustíme tento handler, handler, který může provádět tu či onu logiku. Pro každou databázi specifikujeme, který server je pro ni záložním a kam je potřeba přepnout provoz, pokud je nedostupný. Historicky používáme nagios nebo některé jeho vidlice v té či oné podobě. V zásadě podobné mechanismy existují téměř v každém monitorovacím systému, nic složitějšího zatím nepoužíváme, ale snad někdy ano. Nyní je monitorování spouštěno nedostupností a má možnost něco přepnout.
Máme vše rezervováno?
Máme mnoho klientů z USA, mnoho klientů z Evropy, mnoho klientů, kteří jsou blíže východu – Japonsko, Singapur a tak dále. Obrovský podíl klientů je samozřejmě v Rusku. To znamená, že práce není v jednom regionu. Uživatelé chtějí rychlou reakci, jsou zde požadavky na dodržování různých místních zákonů a v rámci každého regionu máme vyhrazena dvě datová centra, plus jsou zde některé doplňkové služby, které je opět vhodné umístit v rámci jednoho regionu – pro klienty, kteří jsou v tento region funguje. REST handlery, autorizační servery, jsou méně kritické pro chod klienta jako celku, můžete je přepínat s malým přijatelným zpožděním, ale nechcete znovu vynalézat kolo, jak je monitorovat a co dělat s nimi. Snažíme se proto maximálně využít stávající řešení, spíše než rozvíjet nějakou kompetenci v dalších produktech. A někde triviálně používáme přepínání na úrovni DNS a živost služby určujeme stejným DNS. Amazon má službu Route 53, ale není to jen DNS, do kterého můžete zadávat záznamy, a to je vše – je mnohem flexibilnější a pohodlnější. Skrze něj můžete budovat geodistribuované služby s geolokacemi, kdy pomocí něj určíte, odkud klient pochází a poskytnete mu určité záznamy – s jeho pomocí můžete budovat architektury failover. Stejné kontroly stavu jsou nakonfigurovány v samotné Route 53, nastavujete koncové body, které jsou monitorovány, nastavujete metriky, nastavujete, které protokoly určují „živost“ služby – tcp, http, https; nastavit frekvenci kontrol, které určují, zda je služba aktivní nebo ne. A v samotném DNS určíte, co bude primární, co sekundární, kam se přepnout, pokud se zdravotní kontrola spustí uvnitř cesty 53. To vše lze udělat pomocí některých dalších nástrojů, ale proč je to pohodlné - nastavíme jednou nahoru a pak už o tom vůbec nepřemýšlej, jak děláme kontroly, jak přepínáme: všechno funguje samo.
První "ale": jak a čím rezervovat samotnou trasu 53? Kdo ví, co když se mu něco stane? Naštěstí jsme na tento hrábě nikdy nešlápli, ale zase budu mít před sebou historku, proč jsme si mysleli, že je stále potřeba provést rezervaci. Zde jsme si předem rozložili brčka. Několikrát denně provádíme kompletní vyložení všech zón, které máme na trase 53. Amazonské API vám umožňuje snadno je posílat v JSON a máme několik záložních serverů, kde to převedeme, nahrajeme ve formě konfigurací a máme, zhruba řečeno, konfiguraci zálohování. Pokud se něco stane, můžeme to rychle nasadit ručně, aniž bychom ztratili data nastavení DNS.
Druhé "ale": Co na tomto obrázku ještě nebylo rezervováno? Samotný balancer! Naše rozdělení klientů podle regionů je velmi jednoduché. Máme domény bitrix24.ru, bitrix24.com, .de - nyní je jich 13 různých, které fungují v různých zónách. Došli jsme k následujícímu: každý region má své vlastní balancery. To usnadňuje distribuci napříč regiony v závislosti na tom, kde je špičkové zatížení sítě. Pokud se jedná o poruchu na úrovni jednoho balanceru, pak je jednoduše vyřazen z provozu a odstraněn z DNS. Pokud je nějaký problém se skupinou balancerů, pak jsou zálohovány na jiných stránkách a přepínání mezi nimi probíhá stejnou cestou53, protože kvůli krátkému TTL dochází k přepínání maximálně do 2, 3, 5 minut .
třetí "ale": Co ještě není rezervováno? S3, správně. Když jsme soubory, které ukládáme pro uživatele, umístili do s3, upřímně jsme věřili, že je to průrazné brnění a není potřeba tam nic rezervovat. Historie ale ukazuje, že věci se dějí jinak. Amazon obecně popisuje S3 jako základní službu, protože Amazon sám používá S3 k ukládání obrazů strojů, konfigurací, obrazů AMI, snímků... A pokud s3 spadne, jako se to stalo jednou během těchto 7 let, pokud používáme bitrix24, sleduje to jako fanoušek Je tu spousta věcí, které se objeví – nemožnost spustit virtuální stroje, selhání API a tak dále.
A S3 může spadnout - stalo se to jednou. Proto jsme došli k následujícímu schématu: před pár lety v Rusku neexistovala žádná seriózní veřejná úložiště objektů a zvažovali jsme možnost udělat něco vlastního... Naštěstí jsme to nezačali dělat, protože bychom zahrabali jsme se do odborných znalostí, které nemáme, a pravděpodobně by to pokazili. Nyní má Mail.ru úložiště kompatibilní s S3, má ho Yandex a má ho řada dalších poskytovatelů. Nakonec jsme došli k myšlence, že chceme mít za prvé zálohování a za druhé možnost pracovat s lokálními kopiemi. Konkrétně pro ruský region používáme službu Mail.ru Hotbox, která je API kompatibilní s s3. Nepotřebovali jsme žádné velké úpravy kódu uvnitř aplikace a udělali jsme následující mechanismus: v s3 jsou spouštěče, které spouštějí vytváření/mazání objektů, Amazon má službu zvanou Lambda – jedná se o spouštění kódu bez serveru který bude proveden právě při spuštění určitých spouštěčů.
Udělali jsme to velmi jednoduše: pokud se spustí náš trigger, spustíme kód, který zkopíruje objekt do úložiště Mail.ru. Pro plné spuštění práce s lokálními kopiemi dat potřebujeme také zpětnou synchronizaci, aby klienti, kteří jsou v ruském segmentu, mohli pracovat s úložištěm, které je jim blíže. Mail se chystá dokončit triggery ve svém úložišti – bude možné provádět zpětnou synchronizaci na úrovni infrastruktury, ale zatím to děláme na úrovni vlastního kódu. Pokud vidíme, že klient odeslal soubor, pak na úrovni kódu událost zařadíme do fronty, zpracujeme ji a provedeme zpětnou replikaci. Proč je to špatné: pokud s našimi objekty děláme nějakou práci mimo náš produkt, tedy nějakými vnějšími prostředky, nebudeme to brát v úvahu. Čekáme tedy až na konec, kdy se na úrovni úložiště objeví triggery, aby bez ohledu na to, odkud kód spustíme, se objekt, který k nám přišel, zkopíroval opačným směrem.
Na úrovni kódu registrujeme pro každého klienta obě úložiště: jedno je považováno za hlavní, druhé za záložní. Pokud je vše v pořádku, pracujeme s úložištěm, které je nám bližší: tedy naši klienti, kteří jsou v Amazonu, pracují s S3, a ti, kteří pracují v Rusku, pracují s Hotboxem. Pokud se příznak spustí, mělo by být připojeno převzetí služeb při selhání a přepneme klienty na jiné úložiště. Toto políčko můžeme zaškrtnout nezávisle podle regionu a můžeme je přepínat tam a zpět. Zatím jsme to v praxi nepoužili, ale zajistili jsme tento mechanismus a myslíme si, že jednoho dne budeme potřebovat právě tento přepínač a bude se hodit. To už se jednou stalo.
A Amazon utekl...
Letos v dubnu si připomínáme výročí začátku blokování telegramů v Rusku. Nejvíce postiženým poskytovatelem, který pod toto spadal, je Amazon. A bohužel více utrpěly ruské společnosti, které pracovaly pro celý svět.
Pokud je společnost globální a Rusko je pro ni velmi malý segment, 3–5 % – no, tak či onak je můžete obětovat.
Pokud se jedná o čistě ruskou společnost - jsem si jistý, že musí být umístěna lokálně - no, bude to prostě pohodlné pro samotné uživatele, pohodlné a bude to méně rizik.
Co když se jedná o společnost, která působí globálně a má přibližně stejný počet klientů z Ruska a někde ve světě? Důležitá je konektivita segmentů, které spolu musí tak či onak spolupracovat.
Na konci března 2018 Roskomnadzor rozeslal dopis největším operátorům, v němž uvedl, že plánují zablokovat několik milionů IP adres Amazonu, aby zablokovali... messenger Zello. Díky stejným poskytovatelům - úspěšně unikli dopisu všem a došlo k pochopení, že spojení s Amazonem se může rozpadnout. Byl pátek, v panice jsme běželi ke kolegům ze servers.ru se slovy: „Přátelé, potřebujeme několik serverů, které nebudou umístěny v Rusku, ne v Amazonu, ale například někde v Amsterdamu,“ abychom si tam mohli alespoň nějak nainstalovat vlastní VPN a proxy pro některé koncové body, které nemůžeme nijak ovlivnit, např. koncové body stejného s3 - nemůžeme zkoušet zvednout novou službu a získat jinou ip, my se tam ještě musíte dostat. Během několika dní jsme tyto servery nastavili, uvedli do provozu a obecně jsme se připravili na okamžik, kdy začne blokování. Je zvláštní, že RKN při pohledu na ten povyk a paniku řekl: "Ne, teď nebudeme nic blokovat." (To je ale přesně do okamžiku, kdy začal být blokován Telegram.) Po nastavení možností bypassu a zjištění, že blokování zavedeno nebylo, jsme však celou záležitost nezačali řešit. Ano, jen pro případ.
A v roce 2019 stále žijeme v podmínkách blokování. Díval jsem se včera večer: stále je blokováno asi milion IP adres. Pravda, Amazon byl téměř celý odblokován, na vrcholu dosáhl 20 milionů adres... Obecně je realita taková, že tam nemusí být koherence, dobrá koherence. Najednou. Nemusí existovat z technických důvodů – požáry, bagry, všechno to. Nebo, jak jsme viděli, ne zcela technické. Tudíž někdo velký a velký, s vlastními AS to asi zvládne jinak - direct connect a další věci už jsou na úrovni l2. Ale v jednoduché verzi, jako je ta naše nebo ještě menší, můžete pro každý případ mít redundanci na úrovni serverů vyvýšenou někde jinde, předem nakonfigurovanou vpn, proxy, s možností rychle přepnout konfiguraci na ně v těchto segmentech které jsou rozhodující pro vaši konektivitu. To se nám nejednou hodilo, když začalo blokování Amazonu, v nejhorším případě jsme přes ně povolili pouze provoz S3, ale postupně se to vše vyřešilo.
Jak rezervovat... celého poskytovatele?
Právě teď nemáme scénář pro případ, že by se celá Amazonka zhroutila. Podobný scénář máme pro Rusko. V Rusku nás hostil jeden poskytovatel, od kterého jsme si vybrali několik stránek. A před rokem jsme čelili problému: i když se jedná o dvě datová centra, mohou se vyskytnout problémy již na úrovni konfigurace sítě poskytovatele, které budou stále ovlivňovat obě datová centra. A můžeme skončit nedostupní na obou stránkách. Samozřejmě, že se tak stalo. Nakonec jsme přehodnotili architekturu uvnitř. Moc se to nezměnilo, ale pro Rusko teď máme dva weby, které nejsou od stejného poskytovatele, ale od dvou různých. Pokud jeden selže, můžeme přejít na druhý.
Hypoteticky pro Amazon zvažujeme možnost rezervace na úrovni jiného poskytovatele; možná Google, možná někdo jiný... Ale zatím jsme v praxi pozorovali, že zatímco Amazon má nehody na úrovni jedné zóny dostupnosti, nehody na úrovni celého regionu jsou celkem vzácné. Proto teoreticky máme představu, že bychom mohli provést rezervaci „Amazon není Amazon“, ale v praxi tomu tak zatím není.
Pár slov o automatizaci
Je automatizace vždy nutná? Zde je vhodné připomenout Dunning-Krugerův efekt. Na ose „x“ jsou naše znalosti a zkušenosti, které získáváme, a na ose „y“ důvěra v naše činy. Zpočátku nic nevíme a nejsme si vůbec jisti. Pak trochu víme a staneme se mega sebevědomými - to je takzvaný „vrchol hlouposti“, dobře ilustrovaný obrázkem „demence a odvaha“. Pak jsme se trochu naučili a jsme připraveni jít do bitvy. Pak šlápneme na megazávažné chyby a ocitáme se v údolí zoufalství, kdy se zdá, že něco víme, ale ve skutečnosti toho moc nevíme. Když pak získáme zkušenosti, staneme se sebevědomějšími.
Naši logiku ohledně různých automatických přepnutí na určité nehody velmi dobře popisuje tento graf. Začali jsme - neuměli jsme nic dělat, téměř veškerá práce se dělala ručně. Pak jsme si uvědomili, že můžeme ke všemu připojit automatizaci a klidně spát. A najednou šlápneme na megarake: spustí se falešně pozitivní a přepneme provoz tam a zpět, když jsme to v dobrém slova smyslu neměli dělat. V důsledku toho se replikace porouchá nebo něco jiného – to je samotné údolí zoufalství. A pak dojdeme k pochopení, že ke všemu musíme přistupovat moudře. To znamená, že má smysl spoléhat se na automatizaci, která poskytuje možnost falešných poplachů. Ale! pokud mohou být následky devastující, pak je lepší to nechat na služební směně, na službukonajících inženýrech, kteří se postarají a budou hlídat, že skutečně k nehodě došlo, a potřebné úkony provedou ručně...
Závěr
Během 7 let jsme přešli od toho, že když něco spadlo, byla panika-panika, k pochopení, že problémy neexistují, jsou jen úkoly, ty se musí - a mohou - řešit. Když budujete službu, podívejte se na ni shora, posuďte všechna rizika, která mohou nastat. Pokud je hned uvidíte, tak si předem počítejte s redundancí a možností vybudování infrastruktury odolné proti chybám, protože jakýkoli bod, který může selhat a vést k nefunkčnosti služby, to určitě udělá. A i když se vám zdá, že některé prvky infrastruktury rozhodně neselžou – jako stejný s3, stále mějte na paměti, že mohou. A alespoň teoreticky mějte představu o tom, co s nimi uděláte, pokud se něco stane. Mějte plán řízení rizik. Když přemýšlíte o tom, že vše uděláte automaticky nebo ručně, zhodnoťte rizika: co se stane, když automatika začne vše přepínat – nepovede to k ještě horší situaci ve srovnání s nehodou? Možná je někde potřeba použít rozumný kompromis mezi použitím automatizace a reakcí technika ve službě, který vyhodnotí reálný obraz a pochopí, zda je potřeba něco přepínat na místě nebo „ano, ale ne teď“.
Rozumný kompromis mezi perfekcionismem a skutečným úsilím, časem, penězi, které můžete utratit za schéma, které nakonec budete mít.
Tento text je aktualizovanou a rozšířenou verzí zprávy Alexandra Demidova na konferenci .
Zdroj: www.habr.com