«Bitrix24»: «Kiiresti üles tõstetud ei loeta kukkunuks»

Tänaseks päevaks ei ole „Bitrix24“ teenusel sadu gigabite liiklust ega tohutut serverite parki (kuigi neid on kindlasti mitmeid). Kuid paljude klientide jaoks on see nende ettevõtte peamine tööriist, tõeline ärikriitiline rakendus. Seetõttu ei saa see mingil juhul katkeda. Aga mis siis, kui katkestus ikkagi juhtus, kuid teenus „taastus“ nii kiiresti, et keegi ei märkagi? Ja kuidas suudetakse seejuures rakendada failover’it ilma töö kvaliteedi ja klientide arvu kadudeta? Aleksandr Demidov, „Bitrix24“ pilveteenuste valdkonna direktor, rääkis meie blogile, kuidas on toote 7-aastase olemasolu jooksul arenenud varundussüsteem.

„SaaS kujul käivitasime „Bitrix24“ 7 aastat tagasi. Peamine keerukus oli tõenäoliselt järgmine: enne, kui see avalikustati SaaS-ina, eksisteeris see toode lihtsalt kastilahendusena. Klient ostis selle meilt, paigaldas selle oma serveritele, lõi ettevõtte portaali – üldlahenduse töötajate suhtlemiseks, failide hoidmiseks, ülesannete haldamiseks, CRM-iks, kõigeks selleks. Ja 2012. aastaks otsustasime, et tahame seda käivitada SaaS-ina, mida haldame ise, tagades talitlushäired ja usaldusväärsuse. Kogemus tuli meile protsessi käigus, kuna varem seda meil lihtsalt ei olnud – olime vaid tarkvara tootjad, mitte teenusepakkujad.

Teenuse käivitamisel mõistsime, et kõige tähtsam on tagada talitlushäired, usaldusväärsus ja teenuse pidev kättesaadavus, sest kui teil on lihtsalt tavaline veebisait, näiteks pood, ja see kukub tunni ajaks maha – kannatate ainult teie ise, kaotate tellimusi, kliente, kuid teie kliendi jaoks ei ole see väga kriitiline. Ta on küll pettunud, kuid läheb ja ostab teiselt veebilehelt. Kui aga see on rakendus, millega on seotud kogu töö ettevõttes, suhtlemine, lahendused, siis on kõige olulisem võita kasutajate usaldus, see tähendab mitte alt vedada ja mitte kokku kukkuda. Sest kogu töö võib seiskuda, kui midagi seestpoolt ei toimi.

Bitrix24 kui SaaS

Esimese prototüübi kokku panime aasta enne avalikku käivitamist, 2011. aastal. Koondasime selle umbes nädalaga, vaatasime, keerutasime — see oli isegi töötav. See tähendab, et oli võimalik minna vormi, sisestada portaalinimi, luua uus portaal, genereerida kasutajate andmebaas. Vaatasime seda, hindasime tegelikult toodet, sulgesime selle ja terve aasta töötasime edasi. Sest meil oli suur ülesanne: me ei tahtnud teha kahte erinevat koodibaasi, me ei tahtnud toetada eraldi pakendi toodet ja eraldi pilvelahendusi — tahtsime kõike teha ühe koodi raames.

Tüüpiline veebirakendus sel ajal — see on üks server, millel töötab mingi PHP kood, MySQL andmebaas, failid laaditakse üles, dokumendid, pildid pannakse üleslaadimisnimekirja — ja kõik see töötab. Kahjuks ei ole sellisel alusel võimalik käivitada kriitiliselt stabiilset veebiteenust. Seal ei toetata jaotatud vahemälu, andmebaaside replikatsiooni ei toetata.

Me määratlesime nõuded: see peab suutma paikneda erinevates asukohtades, toetama replikatsiooni, ideaaljuhul paikneda erinevates geograafiliselt jaotatud andmekeskustes. Eraldada toote loogika ja andmete salvestamine. Dynaamiliselt suutma koormuse järgi skaleeruda, staatika täiesti eraldi välja viia. Nendest kaalutlustest tekkisidki nõudmised tootele, mida me täpselt aasta jooksul täiustasime. Selle aja jooksul, platvormis, mis kujunes üheks — pakendilahenduste jaoks, meie enda teenuse jaoks — tegime toetuse nendele asjadele, mis meile vajalikud olid. Toetuse replikatsiooni mysql tasemel tootest: see tähendab, et arendaja, kes kirjutab koodi — ei pea mõtlema, kuidas tema päringud jaotatakse, ta kasutab meie api-d ja meie oskame õigesti jaotada kirjutamise ja lugemise päringud masterite ja slave'ide vahel.

Oleme teinud toote tasemel mitmesuguste pilvepõhiste objektide salvestuslahenduste toetuse: Google Storage, Amazon S3 — pluss, OpenStack Swift toetus. Seega oli see mugav nii meie teenuse jaoks kui ka arendajatele, kes töötavad pakendilahendusega: kui nad kasutavad lihtsalt meie API-d, siis ei pea nad mõtlema, kuhu fail lõppkokkuvõttes salvestatakse, kas kohalikule failisüsteemile või satub objektide salvestuslahendusse.

Kokkuvõttes otsustasime kohe, et broneerime tervet andmekeskust. 2012. aastal alustasime täielikult Amazon AWS-is, kuna meil oli juba kogemus selle platvormiga — meie enda veebisait oli seal hostitud. Meid köitis see, et igas Amazon'i regioonis on mitu saadavuse tsooni — sisuliselt (nende terminoloogias) mitu andmekeskust, mis on enam-vähem üksteisest sõltumatud ja võimaldavad meil broneerida tervet andmekeskust: kui see peaks rikkis olema, replikeeruvad andmebaasid master-master režiimis, veebirakenduste serverid on broneeritud ning staatika on väljastatud objektide hoidjasse s3. Koormus jaotub — tol ajal Amazoni elb kaudu, kuid hiljem läksime oma koormuse tasakaalustajate juurde, kuna vajasime keerukamat loogikat.

Mida soovisime, selle ka saime...

Kõik põhiasjad, mida soovisime tagada — serverite, veebirakenduste ja andmebaaside talitlushäired — töötasid hästi. Kõige lihtsam stsenaarium: kui mõni meie veebirakendus rikneb, on kõik lihtne — need lülitatakse välja koormuse tasakaalustamisest.

Rikkis masinad märkis koormuse tasakaalustaja (tol hetkel oli see Amazoni elb) ise unhealthy, lõpetades koormuse jaotamise neile. Töötab Amazoni automaatne skaleerimine: kui koormus suureneb, lisatakse automaatsete skaleerimisrühma uusi masinaid, koormus jaotatakse uutele masinatele — kõik toimis hästi. Meie koormuse tasakaalustajate loogika on peaaegu sama: kui midagi juhtub rakenduste serveriga, eemaldame sellelt päringud, viskame need masinad välja, käivitame uued ja jätkame tööd. Selle skeem on aastate jooksul veidi muutunud, kuid see töötab jätkuvalt: see on lihtne, arusaadav ja sellel pole mingeid keerukusi.

Me töötame üle kogu maailma, klientide koormuspiigid on täiesti erinevad ja õigupoolest peaksime olema võimelised teostama teenindustöid meie süsteemi mis tahes komponentidega igal ajal – klientidele märkamatult. Seetõttu on meil võimalus andmebaas välja lülitada, jagades koormuse teise andmekeskusesse.

Kuidas see kõik töötab? — Me suuname liikluse töötavale andmekeskusele — kui seal on rike, siis täielikult, kui see on meie kavandatud töö mõnes konkreetses andmebaasis, siis suuname osa liiklusest, mis teenindab neid kliente, teise andmekeskusesse, koopiatöö peatatakse. Kui me vajame uusi masinaid veebirakenduste jaoks, kuna teises andmekeskuses on koormus suurenenud, then need käivituvad automaatselt. Lõpetame tööd, koopiatöö taastatakse ja suuname kogu koormuse tagasi. Kui meil on vaja teha midagi sarnast teises DC-s, näiteks installida süsteemiuuendusi või muuta seadeid teises andmebaasis, siis kordame sisuliselt kõike sama, lihtsalt teises suunas. Ja kui see on rike, siis teeme kõike üsna lihtsasti: jälgimissüsteemis kasutame mehhanismi event-handlers. Kui meil aktiveerub mitu kontrolli ja staatus muutub kriitiliseks, siis aktiveerub see käitleja, mis võib teostada teatud loogikat. Meil on iga andmebaasi jaoks kirjas, millisest serverist tuleb teha failover ja kuhu liiklus suunata, kui see on kättesaamatu. Me — nii see ajalooliselt on välja kujunenud — kasutame mingit vormi nagiosest või selle hargnemistest. Üldiselt on sarnased mehhanismid praktiliselt igas jälgimissüsteemis, midagi keerulisemat me hetkel ei kasuta, kuid võib-olla kunagi hakkame. Praegu aktiveerub jälgimine, kui teenus on puudulik ja tal on võimalus midagi suunata.

Kas me oleme kõik kinni pannud?

Meil on palju kliente Ameerikast, palju kliente Euroopast, palju kliente, kes on lähemal idas — Jaapan, Singapur ja nii edasi. Loomulikult on suur osa kliente Venemaalt. See tähendab, et töö ei käi ainult ühes regioonis. Kasutajad soovivad kiiret reageerimist, kohalikke seadusi tuleb järgida, ja igas regioonis reservime kaks andmekeskust, lisaks on veel mõned teenused, mida on mugav paigutada ühte regioonis — klientide jaoks, kes selles regioonis töötavad. REST-i töötlejad, autoriseerimiserverid on kliendi töö jaoks vähem kriitilised, nende pealt on võimalik lülituda väikese vastuse viivitusega, kuid ei soovi leiutada jalgratast, kuidas neid jälgida ja mida nendega teha. Seetõttu püüame maksimaalselt kasutada juba olemasolevaid lahendusi, mitte arendada mingit kompetentsi täiendavate toodete osas. Ja mõnel juhul kasutame lihtsalt DNS-i tasemel vahetust, kusjuures teenuse elujõudlust määrame sama DNS-iga. Amazonis on teenus Route 53, kuid see ei ole lihtsalt DNS, kuhu võib salvestusi lisada ja kõik — see on palju paindlikum ja mugavam. Selle kaudu saab luua geo-jaotatud teenuseid geolokatsioonidega, kui te tema abil määrate, kust klient tuli, ja annate talle vastavad salvestused — selle abil saab luua failover-arhitektuure. Samad health-check-id seadistatakse Route 53-s, te määrate endpoint’id, mida jälgitakse, määrate mõõdikud, määrate, milliste protokollide alusel määrata teenuse „elujõud“ — tcp, http, https; määrate kontrollide sageduse, mis määravad, kas teenus on elus või mitte. Ja DNS-is määrate, mis on peamine, mis on sekundaarne, kuhu vahetada, kui Route 53 sees toimib health-check. Kõike seda saab teha mõne teise tööriistaga, kuid mugavus seisneb selles, et seadistate selle ühe korra ja siis ei pea me üldse mõtlema, kuidas meie kontrollid toimuvad, kuidas vahetus toimub: kõik töötab iseenesest.

Esimene 'aga': kuidas ja millega reserveerida Route 53? Kui midagi juhtub? Õnneks pole me kunagi sellesse takerdunud, kuid mul on esitada lugu, miks peaksime ikkagi mõtlema reserveerimisele. Siin valmistame end ette. Korduvalt päevas teeme täieliku väljundi kõigist tsoonidest, mis meil Route 53-s on. Amazoni API võimaldab neid rahulikult JSON-is edastada, ning meil on üles seatud mitu varuserverit, kuhu me selle konverteerime, väljundime konfiguraatorite kujul ja meil on, ütleme nii, varukoopia konfiguratsioon. Kui midagi juhtub, saame selle kiiresti käsitsi üles seada, kaotamata DNS-seadete andmeid.

Teine „aga“: mida selles pildis pole veel reserveeritud? Balansseerija! Meie klientide jaotus regioonide vahel on tehtud väga lihtsalt. Meil on domeenid bitrix24.ru, bitrix24.com, .de — hetkel on neid umbes 13 erinevat, mis töötavad erinevates tsoonides. Oleme jõudnud järgmisele: igas regioonis on oma balansseerijad. Niimoodi on mugavam jaotada regioonide vahel, sõltuvalt kõrgeimast koormusest võrgu kaudu. Kui ühe balansseerija tasemel toimub rike, siis see lihtsalt eemaldatakse kasutusest ja DNS-ist. Kui tekib probleem balansseerijate grupiga, siis need reserveeritakse teistel platvormidel ning vahetus nende vahel toimub sama Route 53 abil, kuna lühikese TTL tõttu toimub vahetus maksimaalselt 2, 3, 5 minuti jooksul.

Kolmas „aga“: mida veel ei ole reserveeritud? S3, õige. Me, kui salvestame faile, mida hoiame kasutajatel S3-s, – uskusime siiralt, et see on muutumatult töökindel ja seal ei pea midagi reserveerima. Kuid ajalugu näitab, et asjad ei lähe alati nii. Üldiselt kirjeldab Amazon S3-d kui põhilist teenust, kuna Amazon kasutab S3-d masinapiltide, konfiguratsioonide, AMI-piltide, hetkeseisude salvestamiseks… Ja kui S3 tõrkeb, nagu see kord meie seitsme Bitrix24 aasta jooksul juhtus, tõmbab see kaasa kogu hulga asju — virtuaalmasinate käivitamise kätte saamata jäämine, API tõrked ja nii edasi.

Ja s3 võib kokku kukkuda - see juhtus kunagi. Seetõttu jõudsime järgmisele skeemile: mõned aastad tagasi ei olnud Venemaal tõsiseid objekti avalikke salvestusruume ja me kaalusime, et teha midagi enda oma… Õnneks me seda ei alustanud, sest oleksime kadunud sellesse ekspertiisi, mis meil puudus, ja kindlasti oleksime midagi valesti teinud. Praegu on s3-ühilduvaid salvestusi Mail.ru, Yandexil ja veel mitmel teenusepakkujal. Lõpuks jõudsime mõttele, et tahame, esiteks, varundust ja teiseks, võimalust töötada kohalike koopiatega. Konkreetse Venemaa regiooni jaoks kasutame Mail.ru Hotboxi teenust, mis on api poolest s3-ühilduv. Me ei pidanud rakenduse sisekoodis tegema tõsiseid muudatusi ja tegime järgmise mehhanismi: s3-s on käivitajad, mis aktiveeruvad objektide loomisel/mahimise ajal, Amazonil on selline teenus nagu Lambda - see on serverless koodi käitamise teenus, mis käivitub just nende käivitajate aktiveerimisel.

Me tegime väga lihtsalt: kui meie käivitaja aktiveerub, käitame koodi, mis kopeerib objekti Mail.ru salvestusse. Et täielikult alustada kohalike andmekoopiate kasutamist, vajame ka tagasipöördumist, et kliendid, kes asuvad Venemaa segmendis, saaksid töötada salvestusega, mis neile lähemal on. Mail lõpetab peagi käivitajat oma salvestuses - infrastruktuuri tasemel saab juba tagasipöördumist käivitada, praegu teeme seda meie enda koodi tasemel. Kui me näeme, et klient on üles laadinud mingi faili, siis meie koodi tasemel paneme sündmuse järjekorda, töötleme seda ja teeme tagasireplikatsiooni. Miks see halb on: kui meie objektidega toimub mingit tööd väljaspool meie toodet, st mingite välistööriistadega, ei pruugi me seda arvesse võtta. Seetõttu ootame, kuni käivitajad salvestuse tasemel ilmuvad, et sõltumata sellest, kust me koodi käitame, kopeeritaks objekt, mis meie juurde jõuab, teise suunda.

Kooditasandil määrame iga kliendi jaoks kaks salvestusruumi: üks peamine ja teine varus. Kui kõik on hästi, kasutame seda salvestusruumi, mis on meile lähedasem: see tähendab, et meie kliendid, kes on Amazonis, töötavad S3-ga, ja need, kes töötavad Venemaal, töötavad Hotboxiga. Kui lüliti aktiveeritakse, peab meil olema failover ja me suuname kliendid teise salvestusruumi. Saame seda lülitit sõltumatult piirkondade kaupa seada ja neid vahetada. Praktiliselt pole me seda veel kasutanud, kuid mehhanism on ette nähtud, ja me arvame, et mingil hetkel on see vahetus vajalik. Üks kord on see juba juhtunud.

Oh, Amazon on teid pettnud…

Sel aprillil on möödunud aasta, mil Venemaal blokeeriti Telegram. Kõige enam kannatanud teenusepakkuja, kes sellesse sattus, on Amazon. Kahjuks on rohkem kannatanud Vene ettevõtted, kes tegutsesid kogu maailmas.

Kui ettevõte on globaalne ja Venemaa on selle jaoks vaid väga väike segment, 3-5% — siis on mingil määral neid võimalik ohverdada.

Kui see on puhtalt Vene ettevõte — olen kindel, et see peaks paiknema kohalikes serverites — lihtsalt kasutajatele on nii mugavam ja riskid on väiksemad.

Aga kui see on ettevõte, mis tegutseb globaalselt ja tal on umbes sama palju kliente Venemaalt kui ka mujalt maailmast? Segmentide omavaheline seos on oluline, ja nad peavad üksteisega töötama.

Juba märtsi lõpus 2018 saatis Roskomnadzor suurematele operaatoritele kirja, et nad kavatsevad blokeerida mitu miljonit Amazon'i IP aadressi, et blokeerida... sõnumiteenus Zello. Tänu nendele teenusepakkujatele levis kiri kiiresti ning tekkis arusaam, et seos Amazoniga võib kaduda. See oli reede, me jooksime paanika tõttu kolleegide juurde servers.ru, öeldes: "Sõbrad, meil on vaja mitmeid servereid, mis ei oleks Venemaal, mitte Amazonis, vaid näiteks kuskil Amsterdamis," et meil oleks võimalus seal vähemalt mingil moel oma servereid paigaldada. vpn ja proxy mõnedele endpoint'idele, millele me ei saa mingil viisil mõjutada, näiteks s3 endpont'id - ei saa proovida tõsta uut teenust ja saada teist ip-d, me peame saama nendeni ikka ligi. Paari päevaga seadistasime need serverid, tõstsime need üles ja üldiselt olime valmis, kui blokeeringud algasid. Huvi pakub, et RKN, nähes elevust ja tekitatud paanikat, ütles: "Ei, me ei kavatse praegu midagi blokeerida." (Kuni hetkeni, mil hakati Telegrammi blokeerima.) Seadsime ümbersoidu võimalused ja mõistsime, et blokeeringut ei rakendatud, kuid me ei hakanud seda kõike lahendama. Nii igaks juhuks.

Ja nii elame 2019. aastal blokeeringute tingimustes. Ma vaatasin eile öösel: ligikaudu miljon ip-d jätkavad blokeerimist. Tõsi, Amazon on peaaegu täielikult avatud, haripunktis oli see kuni 20 miljoni aadressiga... Üldiselt on reaalsus selline, et sidet, head sidet - seda ei pruugi olla. Äkitselt. Seda ei pruugi olla tehniliste põhjuste tõttu - tulekahjud, ekskavaatorid, kõike seda. Või, nagu me nägime, mitte täpselt tehnilistel põhjustel. Seega võib keegi suur ja suur, kellel on oma AS-id, tõenäoliselt nende asjadega muul moel toime tulla - otseühendus jne juba l2 tasemel. Kuid lihtsas variandis, nagu meie või veel väiksemad, on mõistlik omada serverite tasemel varundust, mis on tõstetud kuskil mujal, eelnevalt seadistatud vpn, proxy, võimalusega kiiresti nendele konfigureerimist vahetada neis segmentides, mis on teile kriitilised ning seotuse osas. See on meid korduvalt aidanud, kui Amazonil blokeeringud algasid, suunatud liiklus S3 kaudu, kuid järk-järgult läks see kõik korda.

Kuidas varundada... terve teenusepakkuja?

Praegu pole meil stsenaariumi, et kogu Amazoni süsteem võib ebaõnnestuda. Meil on sarnane stsenaarium Venemaa jaoks. Oleme Venemaal paiknenud ühes teenusepakkujas, kelle puhul valisime mitmeid platvorme. Aasta tagasi kohtasime probleemi: isegi kui need on kaks andmekeskust, võivad teenusepakkuja võrgu konfigureerimise tasemel esineda tõrkeid, mis mõjutavad siiski mõlemat andmekeskust. Ja me võime kogeda juurdepääsmatus mõlemal platvormil. Loomulikult nii juhtuski. Lõpuks ülevaatasime oma arhitektuuri sisemiselt. See ei muutunud palju, kuid Venemaal on meil nüüd kaks platvormi, mis ei asu ühes teenusepakkujas, vaid kahes erinevas. Kui ühes midagi läheb katki, saame lülituda teisele.

Hüpoteetiliselt kaalume Amazoni jaoks võimalust reserveerida teise teenusepakkuja tasemel; võib-olla Google, võib-olla keegi teine... Kuid seni oleme praktikas täheldanud, et kui Amazoni käitumises esinevad õnnetused ühe saadavuse tsoonis, siis õnnetused kogu piirkonnas on piisavalt haruldased. Seetõttu on meil teoreetiline ettekujutus, et võib-olla teeme reserveeringu „Amazon - mitte Amazon“, kuid praktikas pole me seda veel teinud.

Mõned sõnad automatiseerimisest

Kas automatiseerimine on alati vajalik? Siin on paslik meenutada Dunning-Krugeri efekti. X-teljel on meie teadmised ja kogemused, mida me omandame, ja Y-teljel - meie enesekindlus. Esiteks ei tea me midagi ja oleme täielikult ebakindlad. Siis teame veidi ja muutume üliusutavaks - see on nn „rumaluse tipp“, mida illustreerib hästi pilt „lollus ja julgus“. Edasi liikudes oleme juba natuke õppinud ja oleme valmis lahingusse minema. Siis astume mingitele üliseriousetele vitsadele ja satume meeleheite orgu, kus näib, et teame midagi, aga tegelikult ei tea me palju. Siis, kogemuste tõttu, saame juba kindlamaks.

Meie loogika erinevatest automaatsetest üleminekutest erinevatele häiretele on väga hästi kirjeldatud selles graafikus. Me alustasime — me ei osanud peaaegu midagi, kõik tööd tehti käsitsi. Siis mõistsime, et kõike on võimalik automatiseerida ja siis saame rahulikult magada. Ja äkki astume megatriblerile: meil aktiveerub vale positiivne signaal, ja me suuname liiklust siia ja sinna, kui tegelikult poleks seda pidanud tegema. Selle tulemusena katkevad replikeerimised või juhtub veel midagi — see on see hädade org. Edasi liikudes saame arusaamise, et kõigega tuleb targalt toime tulla. See tähendab, et on mõistlik toetuda automaatikale, ette nähes valeaktiveerimise võimalust. Aga! Kui tagajärjed võivad olla hävitavad, on parem usaldada see vahetusvahetuse inseneridele, kes veenduvad, kontrollivad, et tõepoolest on häire ja teevad vajalikud toimingud käsitsi…

Kokkuvõte

Seitsme aasta jooksul oleme läbinud tee sellest, et kui midagi kukkus, valitses paanika, arusaamiseni, et probleeme ei eksisteeri, on ainult ülesanded, mida tuleb lahendada. Kui ehitate mõnd teenust, vaadake seda kõrvalt, hinnake kõiki riske, mis võivad tekkida. Kui näete neid kohe, siis planeerige ette varundamine ja võimalus üles ehitada tõrkekindel infrastruktuur, sest iga punkt, mis võib rikki minna ja viia teenuse töövõimetuseni — see kindlasti ka juhtub. Ja isegi kui teile tundub, et mõned infrastruktuuri elemendid ei lähe kindlasti rikki — näiteks s3, pidage siiski meeles, et nad võivad. Ja vähemalt teoreetiliselt pidage silmas, mida te nendega teete, kui midagi ikkagi juhtub. Olge valmis riskide haldamiseks. Kui mõtlete, kas teha kõik automaatika abil või käsitsi — hinnake riske: mis juhtub, kui automaatika hakkab kõike vahetama — kas see toob kaasa veel halvemad tagajärjed võrreldes häirega? Võib-olla on mõnes kohas mõistlik kompromiss automaatika ja vahetusinseneri reageerimise vahel, kes hindab olukorda ja mõistab, kas on vaja kohe midagi vahetada või "jah, aga mitte praegu".

Mõistlik kompromiss perfektsionismi ja teie rahaliselt ning ajaliselt kättesaadavate võimaluste vahel, mis võimaldab teil lõpuks saavutada soovitud tulemuse.

See tekst on Aleksandr Demidovi ettekande täiendatud ja laiendatud versioon konverentsil. Uptime päev 4.

Allikas: habr.com