Tänapäeval ei ole Bitrix24 teenusel sadade gigabitiste liiklust ega ka tohutut serveriparki (kuigi olemasolevaid on muidugi üsna vähe). Kuid paljudele klientidele on see peamine tööriist ettevõttes töötamiseks, see on tõeline ärikriitiline rakendus. Seetõttu pole võimalust kukkuda. Mis siis, kui krahh juhtus, kuid teenus "taas" nii kiiresti, et keegi ei märganud midagi? Ja kuidas on võimalik tõrkevahetust rakendada ilma töö kvaliteeti ja klientide arvu kaotamata? Bitrix24 pilveteenuste direktor Aleksander Demidov rääkis meie ajaveebi jaoks, kuidas broneerimissüsteem on toote 7-aastase eksisteerimise jooksul arenenud.
„Käivitasime Bitrix24 SaaS-ina 7 aastat tagasi. Peamine raskus seisnes ilmselt järgmises: enne selle SaaS-i nime all avalikku turule toomist oli see toode lihtsalt karbis oleva lahenduse kujul olemas. Kliendid ostsid selle meilt, majutasid seda oma serverites, seadsid üles ettevõtte portaali – üldine lahendus töötajate suhtluseks, failide salvestamiseks, ülesannete haldamiseks, CRM-i jaoks, see on kõik. Ja 2012. aastaks otsustasime, et tahame selle käivitada SaaS-ina, administreerides seda ise, tagades tõrketaluvuse ja töökindluse. Kogemusi saime sellel teel, sest seni meil seda lihtsalt polnud – olime ainult tarkvaratootjad, mitte teenusepakkujad.
Teenuse käivitamisel saime aru, et kõige olulisem on tagada teenuse tõrketaluvus, töökindlus ja pidev kättesaadavus, sest kui sul on lihtne tavaline veebileht, näiteks pood ja see sulle peale kukub ja istub. tund, ainult teie kannatate, kaotate tellimusi, kaotate kliente, kuid teie kliendi enda jaoks pole see tema jaoks eriti oluline. Ta oli muidugi ärritunud, kuid läks ja ostis selle teiselt saidilt. Ja kui see on rakendus, millele on seotud kogu ettevõttesisene töö, suhtlus, otsused, siis on kõige olulisem võita kasutajate usaldus ehk neid mitte alt vedada ja mitte kukkuda. Sest kogu töö võib peatuda, kui midagi sees ei tööta.
Bitrix.24 kui SaaS
Esimese prototüübi panime kokku aasta enne avalikku turuletoomist, 2011. aastal. Panime selle kokku umbes nädalaga, vaatasime, keerutasime – isegi töötas. Ehk siis võiks minna vormi sisse, sisestada sinna portaali nimi, siis avaneb uus portaal ja tekib kasutajabaas. Vaatasime seda, hindasime toodet põhimõtteliselt, lammutasime selle ära ja jätkasime selle täiustamist terve aasta. Sest meil oli suur ülesanne: me ei tahtnud teha kahte erinevat koodibaasi, me ei tahtnud toetada eraldi pakendatud toodet, eraldi pilvelahendusi – tahtsime seda kõike teha ühe koodi sees.
Tüüpiline veebirakendus tol ajal oli üks server, millel jookseb mingi PHP kood, mysql andmebaas, failid laetakse üles, dokumendid, pildid pannakse üleslaadimise kausta - no kõik töötab. Paraku on selle abil võimatu käivitada kriitiliselt stabiilset veebiteenust. Seal ei toetata hajutatud vahemälu, andmebaasi replikatsiooni ei toetata.
Sõnastasime nõuded: see on võimalus asuda erinevates kohtades, toetada replikatsiooni ja ideaalis asuda erinevates geograafiliselt hajutatud andmekeskustes. Eraldage toote loogika ja tegelikult andmete salvestamine. Suuda dünaamiliselt skaleerida vastavalt koormusele ja üldse taluda staatikat. Nendest kaalutlustest kujunesidki välja nõuded tootele, mida aasta jooksul täpsustasime. Selle aja jooksul tegime platvormil, mis osutus ühtseks - kastilahenduste jaoks, oma teenuse jaoks, tuge neile asjadele, mida vajasime. Mysql-i replikatsiooni tugi toote enda tasemel: see tähendab, et koodi kirjutav arendaja ei mõtle sellele, kuidas tema päringuid levitatakse, ta kasutab meie api-d ja me teame, kuidas kirjutamis- ja lugemistaotlusi meistrite vahel õigesti jagada. ja orjad.
Oleme teinud tootetasemel tuge erinevatele pilveobjektide salvestustele: google storage, amazon s3, pluss avatud stack swifti tugi. Seetõttu oli see mugav nii meile teenusena kui ka pakendatud lahendusega töötavatele arendajatele: kui nad kasutavad lihtsalt tööks meie API-t, ei mõtle nad sellele, kuhu fail lõpuks salvestatakse, kas lokaalselt failisüsteemi või objektifailide salvestusruumis.
Selle tulemusena otsustasime kohe, et reserveerime kogu andmekeskuse tasemel. 2012. aastal käivitasime täielikult Amazon AWS-i, kuna meil oli selle platvormiga juba kogemusi – seal majutati meie enda veebisaiti. Meid köitis asjaolu, et igas piirkonnas on Amazonil mitu saadavuse tsooni - tegelikult (nende terminoloogias) mitu andmekeskust, mis on üksteisest enam-vähem sõltumatud ja võimaldavad meil broneerida terve andmekeskuse tasemel: kui see ootamatult ebaõnnestub, kopeeritakse andmebaasid ülem-ülem, veebirakenduste serverid varundatakse ja staatilised andmed teisaldatakse s3 objektide salvestusruumi. Koormus on tasakaalustatud - tol ajal Amazoni elbi järgi, aga veidi hiljem jõudsime oma koormuse tasakaalustajateni, sest vajasime keerulisemat loogikat.
Mida nad tahtsid, seda nad ka said...
Kõik põhilised asjad, mida tahtsime tagada – serverite endi veataluvus, veebirakendused, andmebaasid – kõik toimis hästi. Lihtsaim stsenaarium: kui mõni meie veebirakendustest ebaõnnestub, on kõik lihtne – need lülitatakse tasakaalustamisest välja.
Tasakaalustaja (tol ajal oli see Amazoni elb) märkis rivist väljas olnud masinad ebatervislikeks ja lülitas neil koormuse jaotuse välja. Amazoni automaatskaling toimis: koormuse kasvades lisati autoskaleerimise gruppi uusi masinaid, koormus jaotati uutele masinatele – kõik oli korras. Meie tasakaalustajatega on loogika ligikaudu sama: kui rakendusserveriga midagi juhtub, eemaldame sealt päringud, viskame need masinad välja, käivitame uued ja jätkame tööd. Skeem on aastate jooksul veidi muutunud, kuid töötab jätkuvalt: see on lihtne, arusaadav ja sellega pole raskusi.
Töötame kõikjal maailmas, klientide koormuse tipud on täiesti erinevad ja sõbralikul viisil peaksime saama oma süsteemi mis tahes komponendiga teatud hooldustöid teha igal ajal - klientidele märkamatult. Seetõttu on meil võimalus andmebaasi tööst välja lülitada, jaotades koormuse ümber teisele andmekeskusele.
Kuidas see kõik toimib? — Vahetame liikluse töötavale andmekeskusele – kui andmekeskuses juhtub õnnetus, siis täielikult, kui see on meie plaanitud töö ühe andmebaasiga, siis lülitame osa neid kliente teenindavast liiklusest teisele andmekeskusele, peatades selle replikatsioon. Kui veebirakenduste jaoks on vaja uusi masinaid, kuna teise andmekeskuse koormus on suurenenud, käivituvad need automaatselt. Lõpetame töö, replikatsioon taastatakse ja tagastame kogu koormuse. Kui meil on vaja mõnda tööd teises DC-s peegeldada, näiteks installida süsteemivärskendusi või muuta sätteid teises andmebaasis, siis üldiselt kordame sama asja, lihtsalt teises suunas. Ja kui see on õnnetus, siis teeme kõike triviaalselt: kasutame seiresüsteemis sündmuste käsitlejate mehhanismi. Kui käivitatakse mitu kontrolli ja olek läheb kriitiliseks, siis käivitame selle töötleja, töötleja, mis suudab seda või teist loogikat täita. Iga andmebaasi jaoks määrame, milline server on selle jaoks tõrkesiirde ja kuhu tuleb liiklus ümber lülitada, kui see pole saadaval. Ajalooliselt kasutame ühel või teisel kujul nagiost või mõnda selle kahvlit. Põhimõtteliselt on sarnased mehhanismid peaaegu igas seiresüsteemis olemas, midagi keerukamat me veel ei kasuta, aga ehk kunagi hakkame. Nüüd käivitab jälgimise kättesaamatus ja sellel on võimalus midagi ümber lülitada.
Kas oleme kõik broneerinud?
Meil on palju kliente USA-st, palju kliente Euroopast, palju kliente, kes on idale lähemal – Jaapan, Singapur jne. Muidugi on tohutu osa klientidest Venemaal. See tähendab, et töö ei ole ühes piirkonnas. Kasutajad tahavad kiiret reageerimist, kehtivad nõuded järgida erinevaid kohalikke seadusi ja igas piirkonnas broneerime kaks andmekeskust, lisaks on mõned lisateenused, mida on jällegi mugav paigutada ühte piirkonda – klientidele, kes on see piirkond töötab. REST-käitlejad, autoriseerimisserverid, need on kliendi kui terviku toimimise jaoks vähem kriitilised, saate neid väikese vastuvõetava viivitusega läbi lülituda, kuid te ei taha jalgratast uuesti leiutada, kuidas neid jälgida ja mida teha nendega. Seetõttu püüame olemasolevaid lahendusi maksimaalselt ära kasutada, mitte arendada mingisugust kompetentsi lisatoodete osas. Ja kuskil kasutame triviaalselt DNS-i tasemel ümberlülitamist ja määrame teenuse elavuse sama DNS-i järgi. Amazonil on teenus Route 53, kuid see pole lihtsalt DNS, millesse saate sisestada ja ongi kõik – see on palju paindlikum ja mugavam. Selle kaudu saate luua geograafiliselt hajutatud teenuseid koos geograafiliste asukohtadega, kui kasutate seda kliendi päritolu kindlakstegemiseks ja talle teatud kirjete andmiseks – selle abil saate luua tõrkesiirdearhitektuure. Samad tervisekontrollid on konfigureeritud ka marsruudil 53, määrate jälgitavad lõpp-punktid, määrate mõõdikud, määrate, millised protokollid määravad teenuse "elavuse" - tcp, http, https; määrake kontrollide sagedus, mis määrab, kas teenus on elus või mitte. Ja DNS-is endas määrate, mis on esmane, mis sekundaarne, kuhu lülitada, kui tervisekontroll käivitatakse marsruudil 53. Seda kõike saab teha mõne muu tööriistaga, kuid miks see on mugav - meie määrame selle korra üles ja siis ära mõtle sellele, kuidas me kontrollime, kuidas me ümber vahetame: kõik toimib iseenesest.
Esimene "aga": kuidas ja millega marsruuti 53 ise reserveerida? Kes teab, mis siis, kui temaga midagi juhtub? Õnneks me selle reha otsa ei astunud, aga mul on jällegi lugu ees, miks me arvasime, et peame siiski broneerima. Siin laotasime endale eelnevalt õled. Mitu korda päevas teeme täieliku mahalaadimise kõigist tsoonidest, mis meil marsruudil 53 on. Amazoni API võimaldab teil neid lihtsalt JSON-is saata ja meil on mitu varuserverit, kus me selle teisendame, konfiguratsioonidena üles laadime ja jämedalt öeldes on meil ka varukonfiguratsioon. Kui midagi juhtub, saame selle kiiresti käsitsi juurutada, ilma DNS-i seadete andmeid kaotamata.
Teine "aga": Mis sellel pildil on veel broneerimata? Tasakaalustaja ise! Meie klientide jaotus piirkonniti on tehtud väga lihtsaks. Meil on domeenid bitrix24.ru, bitrix24.com, .de – praegu on neid 13 erinevat, mis tegutsevad erinevates tsoonides. Jõudsime järgmiseni: igal regioonil on oma tasakaalustajad. See muudab piirkondade vahel jaotamise mugavamaks, olenevalt sellest, kus on võrgu tippkoormus. Kui see on rike ühe tasakaalustaja tasemel, võetakse see lihtsalt kasutusest välja ja eemaldatakse dns-ist. Kui tasakaalustajate rühmaga on mingi probleem, siis varundatakse need teistele saitidele ja nende vahel vahetatakse sama marsruuti kasutades53, kuna lühikese TTL tõttu toimub ümberlülitamine maksimaalselt 2, 3, 5 minuti jooksul. .
Kolmas "aga": Mis pole veel broneeritud? S3, õige. Kui paigutasime failid, mida me kasutajate jaoks s3-sse salvestame, uskusime siiralt, et see on soomust läbistav ja sinna pole vaja midagi reserveerida. Kuid ajalugu näitab, et asjad juhtuvad teisiti. Üldiselt kirjeldab Amazon S3-d kui fundamentaalset teenust, sest Amazon ise kasutab S3-d masinapiltide, konfiguratsioonide, AMI-piltide, hetktõmmiste salvestamiseks... Ja kui s3 jookseb kokku, nagu juhtus korra selle 7 aasta jooksul, nii kaua, kui oleme kasutanud. bitrix24 järgib seda nagu fänn. Esile tuleb terve hulk asju – suutmatus käivitada virtuaalseid masinaid, api rike ja nii edasi.
Ja S3 võib kukkuda – see juhtus kord. Seetõttu jõudsime järgmisele skeemile: mõned aastad tagasi ei olnud Venemaal tõsiseltvõetavaid avalike objektide hoidlaid ja kaalusime varianti, et teeme midagi omaette... Õnneks me seda tegema ei hakanud, sest tahaksime. oleme süvenenud teadmistesse, mida meil ei ole, ja läheks ilmselt sassi. Nüüd on Mail.ru-l s3-ga ühilduv salvestusruum, Yandexil ja paljudel teistel pakkujatel. Lõpuks jõudsime mõttele, et tahame esiteks varundust ja teiseks võimalust töötada kohalike koopiatega. Konkreetselt Venemaa piirkonna jaoks kasutame teenust Mail.ru Hotbox, mis ühildub API-ga s3-ga. Me ei vajanud rakendusesiseses koodis suuri muudatusi ja tegime järgmise mehhanismi: s3-s on käivitajad, mis käivitavad objektide loomise/kustutamise, Amazonil on teenus nimega Lambda – see on serverita koodi käivitamine. mis käivitatakse just siis, kui teatud päästikud käivituvad.
Tegime seda väga lihtsalt: kui meie päästik käivitub, käivitame koodi, mis kopeerib objekti Mail.ru salvestusruumi. Kohalike andmete koopiatega töö täielikuks käivitamiseks vajame ka pöördsünkroonimist, et Venemaa segmendis olevad kliendid saaksid töötada neile lähemal asuva salvestusruumiga. Mail on oma salvestusruumis käivitamas lõpule viima – pöördsünkroonimist on võimalik teostada infrastruktuuri tasemel, kuid praegu teeme seda oma koodi tasemel. Kui näeme, et klient on faili postitanud, siis koodi tasemel asetame sündmuse järjekorda, töötleme seda ja teeme pöördreplikatsiooni. Miks see on halb: kui teeme oma objektidega tööd väljaspool oma toodet, st mingite väliste vahenditega, siis me ei võta seda arvesse. Seetõttu ootame lõpuni, kui salvestustasandil ilmuvad trigerid, nii et olenemata sellest, kust koodi käivitame, kopeeritakse meieni jõudnud objekt teises suunas.
Koodi tasemel registreerime iga kliendi jaoks mõlemad salvestusruumid: ühte peetakse peamiseks, teist varuvaraks. Kui kõik on korras, töötame meile lähemal asuva salvestusruumiga: meie kliendid, kes on Amazonis, töötavad S3-ga ja need, kes töötavad Venemaal, töötavad Hotboxiga. Kui lipp käivitatakse, tuleks tõrkesiirde ühendada ja vahetame kliendid teisele salvestusruumile. Saame selle kasti piirkondade kaupa eraldi märkida ja neid edasi-tagasi vahetada. Me pole seda praktikas veel kasutanud, kuid oleme selle mehhanismi ette näinud ja arvame, et kunagi läheb meil just seda lülitit vaja ja see tuleb kasuks. Seda on juba korra juhtunud.
Ja Amazon jooksis minema...
Tänavu aprillis möödub Telegrami blokeerimise algusest Venemaal. Kõige rohkem mõjutatud teenusepakkuja, kes selle alla kuulus, on Amazon. Ja kahjuks said rohkem kannatada Venemaa ettevõtted, kes töötasid kogu maailma heaks.
Kui ettevõte on globaalne ja Venemaa on selle jaoks väga väike segment, 3-5% - noh, nii või teisiti, võite need ohverdada.
Kui see on puhtalt Venemaa ettevõte - olen kindel, et see peab asuma kohapeal -, siis on see lihtsalt kasutajatele endile mugav, mugav ja sellega on vähem riske.
Mis siis, kui see on globaalselt tegutsev ettevõte, millel on ligikaudu võrdne arv kliente Venemaalt ja mujalt maailmast? Segmentide ühenduvus on oluline ja need peavad ühel või teisel viisil üksteisega töötama.
2018. aasta märtsi lõpus saatis Roskomnadzor suurimatele operaatoritele kirja, milles teatas, et nad kavatsevad blokeerida mitu miljonit Amazoni IP-d, et blokeerida... Zello messenger. Tänu nendele samadele pakkujatele - nad lekitasid kirja edukalt kõigile ja tekkis arusaam, et ühendus Amazoniga võib laguneda. Oli reede, jooksime paanikas serveris.ru kolleegide juurde, öeldes: "Sõbrad, meil on vaja mitut serverit, mis ei asuks mitte Venemaal, mitte Amazonis, vaid näiteks kuskil Amsterdamis," et saaksime vähemalt kuidagi installida oma VPN-i ja puhverserveri sinna mõne lõpp-punkti jaoks, mida me kuidagi mõjutada ei saa, näiteks sama s3 lõpp-punktid - me ei saa proovida uut teenust tõsta ja teistsugust ip-d hankida, me peame ikkagi sinna jõudma. Vaid mõne päevaga seadsime need serverid üles, panime tööle ja üldiselt valmistusime blokeerimise alguse hetkeks. On uudishimulik, et RKN ütles kära ja paanikat vaadates: "Ei, me ei blokeeri nüüd midagi." (Kuid seda täpselt hetkeni, mil Telegrami blokeerima hakati.) Olles seadistanud möödasõiduvõimalused ja mõistnud, et blokeeringut pole sisse viidud, ei hakanud me aga kogu asja ajama. Jah, igaks juhuks.
Ja 2019. aastal elame endiselt blokeerimise tingimustes. Vaatasin eile õhtul: umbes miljon IP-d on jätkuvalt blokeeritud. Tõsi, Amazon oli peaaegu täielikult lahti blokeeritud, tipphetkel jõudis see 20 miljoni aadressini... Üldiselt on reaalsus see, et sidusust, head sidusust ei pruugi olla. Järsku. Seda ei pruugi olla tehnilistel põhjustel – tulekahjud, ekskavaatorid, kõik see. Või nagu nägime, mitte täiesti tehniline. Seega keegi suur ja suur, oma AS-idega, saab sellega ilmselt teisiti hakkama - otseühendus ja muu on juba l2 tasemel. Kuid lihtsas versioonis, nagu meie või isegi väiksemas versioonis, saate igaks juhuks koondada kuskil mujal üles ehitatud serverite tasemel, mis on eelnevalt konfigureeritud vpn, puhverserver, võimalusega nendes segmentides konfiguratsiooni kiiresti nendele lülitada. mis on teie ühenduvuse jaoks üliolulised. See tuli meile kasuks rohkem kui korra, kui Amazoni blokeerimine algas, halvimal juhul lubasime neist läbi vaid S3 liikluse, kuid tasapisi see kõik lahenes.
Kuidas broneerida... terve pakkuja?
Praegu pole meil stsenaariumi juhuks, kui kogu Amazon kukub alla. Meil on sarnane stsenaarium Venemaa jaoks. Venemaal võõrustas meid üks pakkuja, kelle hulgast valisime mitu saiti. Ja aasta tagasi seisime silmitsi probleemiga: kuigi tegemist on kahe andmekeskusega, võib juba teenusepakkuja võrgukonfiguratsiooni tasandil esineda probleeme, mis mõjutavad endiselt mõlemat andmekeskust. Ja me ei pruugi olla mõlemal saidil saadaval. Muidugi juhtus nii. Lõpuks vaatasime üle sisemise arhitektuuri. See pole palju muutunud, kuid Venemaa jaoks on meil nüüd kaks saiti, mis ei ole ühelt pakkujalt, vaid kahelt erinevalt. Kui üks ebaõnnestub, saame teisele üle minna.
Hüpoteetiliselt kaalume Amazoni jaoks võimalust broneerida mõne teise pakkuja tasemel; võib-olla Google, võib-olla keegi teine... Kuid seni oleme praktikas täheldanud, et kui Amazonil on õnnetusi ühe saadavustsooni tasemel, siis terve regiooni tasemel õnnetusi on üsna harva. Seetõttu on meil teoreetiliselt mõte, et võiksime teha broneeringu "Amazon ei ole Amazon", kuid praktikas see veel nii ei ole.
Paar sõna automatiseerimisest
Kas automatiseerimine on alati vajalik? Siinkohal on asjakohane meenutada Dunning-Krugeri efekti. X-teljel on meie teadmised ja kogemused, mille me saame, ning y-teljel on usaldus oma tegude vastu. Alguses me ei tea midagi ega ole sugugi kindlad. Siis teame natuke ja muutume megakindlaks - see on nn rumaluse tipp, mida illustreerib hästi pilt "dementsus ja julgus". Siis oleme natuke õppinud ja valmis lahingusse minema. Siis astume megatõsiste vigade peale ja leiame end meeleheite orust, kui justkui teame midagi, aga tegelikult ei tea palju. Siis, kui me kogemusi omandame, muutume enesekindlamaks.
See graafik kirjeldab väga hästi meie loogikat erinevate automaatsete lülitumiste kohta teatud õnnetustele. Alustasime - me ei teadnud, kuidas midagi teha, peaaegu kogu töö tehti käsitsi. Siis saime aru, et saame kõigele automaatika külge panna ja nagu rahulikult magada. Ja järsku astume megarehale: käivitub valepositiivsus ja me vahetame liiklust edasi-tagasi, kuigi heas mõttes poleks me pidanud seda tegema. Järelikult replikatsioon katkeb või midagi muud - see on meeleheite org. Ja siis jõuame arusaamisele, et kõigele tuleb läheneda targalt. See tähendab, et on mõttekas tugineda automatiseerimisele, mis näeb ette valehäirete võimaluse. Aga! kui tagajärjed võivad olla laastavad, siis parem jätta see töövahetuse hooleks, valves olevate inseneride hooleks, kes veenduvad ja jälgivad, et avarii tõesti juhtus ning vajalikud toimingud teevad käsitsi...
Järeldus
7 aasta jooksul jõudsime sellest, et kui miski kukkus, tekkis paanika-paanika, arusaamani, et probleeme pole olemas, on vaid ülesanded, need tuleb – ja saab – lahendada. Teenust ehitades vaadake seda ülalt, hinnake kõiki võimalikke riske. Kui näete neid kohe, siis nähke ette koondamine ja tõrketaluva taristu väljaehitamise võimalus, sest iga punkt, mis võib ebaõnnestuda ja viia teenuse töövõimetuseni, teeb seda kindlasti. Ja isegi kui teile tundub, et mõned infrastruktuuri elemendid kindlasti ebaõnnestuvad – nagu seesama s3, siis pidage siiski meeles, et nad saavad hakkama. Ja vähemalt teoreetiliselt on teil ettekujutus sellest, mida te nendega teete, kui midagi juhtub. Omage riskijuhtimisplaani. Kui mõtlete teha kõike automaatselt või käsitsi, hinnake riske: mis saab siis, kui automaatika hakkab kõike ümber lülitama – kas see ei too kaasa õnnetusega võrreldes veelgi hullemat olukorda? Võib-olla on kuskil vaja kasutada mõistlikku kompromissi automaatika kasutamise ja valves oleva inseneri reaktsiooni vahel, kes hindab tegelikku pilti ja saab aru, kas midagi tuleb kohapeal ümber lülitada või "jah, aga mitte kohe."
Mõistlik kompromiss perfektsionismi ja tõelise jõupingutuse, aja ja raha vahel, mida saate kulutada lõpuks saadava skeemi jaoks.
See tekst on Aleksandr Demidovi konverentsil peetud ettekande uuendatud ja laiendatud versioon .
Allikas: www.habr.com