I dag har ikke Bitrix24-tjenesten hundrevis av gigabits trafikk, og den har heller ikke en enorm serverflåte (selv om det selvfølgelig er ganske mange eksisterende). Men for mange kunder er det hovedverktøyet for å jobbe i selskapet; det er en virkelig forretningskritisk applikasjon. Derfor er det ingen måte å falle på. Hva om krasjet skjedde, men tjenesten "kom seg" så raskt at ingen la merke til noe? Og hvordan er det mulig å implementere failover uten å miste kvaliteten på arbeidet og antall klienter? Alexander Demidov, direktør for skytjenester hos Bitrix24, snakket for bloggen vår om hvordan reservasjonssystemet har utviklet seg i løpet av de 7 årene produktet har eksistert.
"Vi lanserte Bitrix24 som en SaaS for 7 år siden. Hovedproblemet var sannsynligvis følgende: før det ble lansert offentlig som SaaS, eksisterte dette produktet ganske enkelt i formatet av en boksløsning. Kunder kjøpte det fra oss, hostet det på serverne sine, satte opp en bedriftsportal - en generell løsning for kommunikasjon med ansatte, fillagring, oppgavebehandling, CRM, det er alt. Og innen 2012 bestemte vi oss for at vi ønsket å lansere det som SaaS, administrere det selv, og sikre feiltoleranse og pålitelighet. Vi fikk erfaring underveis, for til da hadde vi det rett og slett ikke – vi var bare programvareprodusenter, ikke tjenesteleverandører.
Ved lansering av tjenesten forsto vi at det viktigste er å sikre feiltoleranse, pålitelighet og konstant tilgjengelighet av tjenesten, for hvis du har en enkel ordinær nettside, for eksempel en butikk, og den faller på deg og sitter der for en time, bare du lider, du mister ordre, du mister klienter, men for klienten din selv er dette ikke veldig kritisk for ham. Han var selvfølgelig opprørt, men han gikk og kjøpte den på en annen side. Og hvis dette er en applikasjon som alt arbeidet i selskapet, kommunikasjon, beslutninger er knyttet til, så er det viktigste å få tilliten til brukerne, det vil si å ikke svikte dem og ikke falle. Fordi alt arbeid kan stoppe hvis noe innvendig ikke fungerer.
Bitrix.24 som SaaS
Vi satt sammen den første prototypen et år før den offentlige lanseringen, i 2011. Vi satte den sammen på omtrent en uke, så på den, snurret den – den fungerte til og med. Det vil si at du kan gå inn i skjemaet, skrive inn navnet på portalen der, en ny portal vil åpne, og en brukerbase vil bli opprettet. Vi så på det, vurderte produktet i prinsippet, skrotet det og fortsatte å foredle det i et helt år. Fordi vi hadde en stor oppgave: vi ønsket ikke å lage to forskjellige kodebaser, vi ønsket ikke å støtte et separat pakket produkt, separate skyløsninger - vi ønsket å gjøre alt innen én kode.
En typisk nettapplikasjon på den tiden var en server som kjører PHP-kode på, en mysql-database, filer lastes opp, dokumenter, bilder legges i opplastingsmappen - vel, alt fungerer. Akk, det er umulig å lansere en kritisk stabil webtjeneste ved å bruke denne. Der støttes ikke distribuert cache, databasereplikering støttes ikke.
Vi formulerte kravene: dette er muligheten til å være lokalisert på forskjellige steder, støtte replikering, og ideelt sett være lokalisert i forskjellige geografisk distribuerte datasentre. Skill produktlogikken og faktisk datalagring. Kunne dynamisk skalere i henhold til belastningen, og tolerere statikk totalt. Ut fra disse betraktningene dukket det faktisk opp kravene til produktet, som vi finpusset i løpet av året. I løpet av denne tiden, i plattformen, som viste seg å være enhetlig - for boksløsninger, for vår egen tjeneste - laget vi støtte for de tingene vi trengte. Støtte for mysql-replikering på selve produktets nivå: det vil si at utvikleren som skriver koden tenker ikke på hvordan forespørslene hans vil bli distribuert, han bruker api-en vår, og vi vet hvordan vi skal distribuere skrive- og leseforespørsler riktig mellom mastere og slaver.
Vi har laget støtte på produktnivå for ulike skyobjektlagringer: google storage, amazon s3, pluss støtte for open stack swift. Derfor var dette praktisk både for oss som tjeneste og for utviklere som jobber med en pakket løsning: hvis de bare bruker API-en vår til jobb, tenker de ikke på hvor filen til slutt skal lagres, lokalt på filsystemet eller i objektfillagringen.
Som et resultat bestemte vi oss umiddelbart for at vi ville reservere på nivå med hele datasenteret. I 2012 lanserte vi helt på Amazon AWS fordi vi allerede hadde erfaring med denne plattformen - vår egen nettside ble hostet der. Vi ble tiltrukket av det faktum at Amazon i hver region har flere tilgjengelighetssoner - faktisk (i deres terminologi) flere datasentre som er mer eller mindre uavhengige av hverandre og lar oss reservere på nivået til et helt datasenter: hvis det plutselig mislykkes, blir databasene replikert master-master, webapplikasjonsserverne blir sikkerhetskopiert, og de statiske dataene flyttes til s3-objektlageret. Lasten er balansert - på den tiden av Amazon elb, men litt senere kom vi til våre egne lastbalansere, fordi vi trengte mer kompleks logikk.
Det de ville ha er det de fikk...
Alle de grunnleggende tingene vi ønsket å sikre - feiltoleranse for selve serverne, webapplikasjoner, databaser - alt fungerte bra. Det enkleste scenariet: Hvis en av nettapplikasjonene våre mislykkes, er alt enkelt - de er slått av fra balansering.
Balanseren (den gang var det Amazons elb) markerte maskiner som var ute av drift som usunne og slo av lastfordelingen på dem. Amazon autoskalering fungerte: når belastningen vokste, ble nye maskiner lagt til autoskaleringsgruppen, belastningen ble fordelt på nye maskiner - alt var i orden. Med våre balansere er logikken omtrent den samme: Hvis noe skjer med applikasjonsserveren, fjerner vi forespørsler fra den, kaster ut disse maskinene, starter nye og fortsetter å jobbe. Ordningen har endret seg litt gjennom årene, men fortsetter å fungere: den er enkel, forståelig, og det er ingen vanskeligheter med den.
Vi jobber over hele verden, kundebelastningstopper er helt forskjellige, og på en vennskapelig måte bør vi kunne utføre visse servicearbeid på alle komponenter i systemet vårt når som helst – ubemerket av kundene. Derfor har vi muligheten til å slå av databasen fra drift, omfordele lasten til et andre datasenter.
Hvordan fungerer det hele? — Vi bytter trafikk til et fungerende datasenter - hvis det skjer en ulykke ved datasenteret, så fullstendig, hvis dette er vårt planlagte arbeid med én database, så bytter vi deler av trafikken som betjener disse klientene til et andre datasenter, og suspenderer det replikering. Hvis det trengs nye maskiner for webapplikasjoner fordi belastningen på det andre datasenteret har økt, vil de starte automatisk. Vi fullfører arbeidet, replikering gjenopprettes, og vi returnerer hele lasten. Hvis vi trenger å speile noe arbeid i den andre DC, for eksempel installere systemoppdateringer eller endre innstillinger i den andre databasen, så gjentar vi generelt det samme, bare i den andre retningen. Og hvis dette er en ulykke, så gjør vi alt trivielt: vi bruker hendelseshåndteringsmekanismen i overvåkingssystemet. Hvis flere kontroller utløses og statusen blir kritisk, kjører vi denne behandleren, en behandler som kan utføre denne eller den logikken. For hver database spesifiserer vi hvilken server som er failover for den, og hvor trafikken må byttes hvis den ikke er tilgjengelig. Historisk sett bruker vi nagios eller noen av dens gafler i en eller annen form. I prinsippet finnes lignende mekanismer i nesten alle overvåkingssystem, vi bruker ikke noe mer komplekst ennå, men kanskje en dag vil vi gjøre det. Nå utløses overvåking av utilgjengelighet og har muligheten til å bytte noe.
Har vi reservert alt?
Vi har mange kunder fra USA, mange kunder fra Europa, mange kunder som er nærmere Østen - Japan, Singapore og så videre. Selvfølgelig er en stor andel av kundene i Russland. Det vil si at arbeidet ikke er i én region. Brukere vil ha et raskt svar, det er krav til å overholde ulike lokale lover, og innenfor hver region reserverer vi to datasentre, pluss at det er noen tilleggstjenester, som igjen er praktiske å plassere innenfor én region - for kunder som er i denne regionen fungerer. REST-behandlere, autorisasjonsservere, de er mindre kritiske for driften av klienten som helhet, du kan bytte gjennom dem med en liten akseptabel forsinkelse, men du vil ikke finne opp hjulet på nytt for hvordan du overvåker dem og hva du skal gjøre med dem. Derfor prøver vi å utnytte eksisterende løsninger maksimalt, fremfor å utvikle en slags kompetanse på tilleggsprodukter. Og et sted bruker vi trivielt bytte på DNS-nivå, og vi bestemmer tjenestens livlighet ved den samme DNS. Amazon har en Route 53-tjeneste, men det er ikke bare en DNS du kan legge inn i, og det er det – det er mye mer fleksibelt og praktisk. Gjennom den kan du bygge geo-distribuerte tjenester med geolokasjoner, når du bruker den til å finne ut hvor klienten kom fra og gi ham visse poster - med dens hjelp kan du bygge failover-arkitekturer. De samme helsesjekkene er konfigurert i selve rute 53, du setter endepunktene som overvåkes, setter beregninger, setter hvilke protokoller som skal bestemme tjenestens "liveness" - tcp, http, https; angi hyppigheten av sjekker som avgjør om tjenesten er i live eller ikke. Og i selve DNS-en spesifiserer du hva som skal være primært, hva som skal være sekundært, hvor du skal bytte hvis helsesjekken utløses innenfor rute 53. Alt dette kan gjøres med noen andre verktøy, men hvorfor er det praktisk - vi setter det opp en gang og så ikke tenk på det i det hele tatt hvordan vi gjør kontroller, hvordan vi bytter: alt fungerer av seg selv.
Det første "men": hvordan og med hva reservere rute 53 selv? Hvem vet, hva om noe skjer med ham? Heldigvis tråkket vi aldri på denne raken, men igjen, jeg vil ha en historie i forkant om hvorfor vi trodde at vi fortsatt måtte gjøre en reservasjon. Her la vi ut sugerør til oss selv på forhånd. Flere ganger om dagen foretar vi en fullstendig lossing av alle sonene vi har i rute 53. Amazons API lar deg enkelt sende dem i JSON, og vi har flere backupservere hvor vi konverterer det, laster det opp i form av konfigurasjoner og har grovt sett en backupkonfigurasjon. Hvis noe skjer, kan vi raskt distribuere det manuelt uten å miste DNS-innstillingsdataene.
Andre "men": Hva på dette bildet er ennå ikke reservert? Selve balansereren! Vår fordeling av kunder etter region er gjort veldig enkel. Vi har domenene bitrix24.ru, bitrix24.com, .de - nå er det 13 forskjellige, som opererer i en rekke soner. Vi kom frem til følgende: hver region har sine egne balansere. Dette gjør det mer praktisk å fordele på tvers av regioner, avhengig av hvor toppbelastningen på nettet er. Hvis dette er en feil på nivået til en enkelt balanserer, blir den ganske enkelt tatt ut av drift og fjernet fra dns. Hvis det er noe problem med en gruppe balansere, blir de sikkerhetskopiert på andre nettsteder, og veksling mellom dem gjøres ved å bruke samme rute53, fordi på grunn av den korte TTL, skjer veksling innen maksimalt 2, 3, 5 minutter .
Tredje "men": Hva er ennå ikke reservert? S3, riktig. Da vi plasserte filene som vi lagrer for brukere i s3, trodde vi oppriktig at det var pansergjennomtrengende og det var ikke nødvendig å reservere noe der. Men historien viser at ting skjer annerledes. Generelt beskriver Amazon S3 som en grunnleggende tjeneste, fordi Amazon selv bruker S3 til å lagre maskinbilder, konfigurasjoner, AMI-bilder, øyeblikksbilder... Og hvis s3 krasjer, som skjedde en gang i løpet av disse 7 årene, så lenge vi har brukt bitrix24, den følger den som en fan Det er en hel haug med ting som dukker opp – manglende evne til å starte virtuelle maskiner, api-feil og så videre.
Og S3 kan falle - det skjedde en gang. Derfor kom vi til følgende ordning: for noen år siden fantes det ingen seriøse offentlige objektlagringsanlegg i Russland, og vi vurderte muligheten til å gjøre noe eget... Heldigvis begynte vi ikke med dette, fordi vi ville har gravd i kompetansen som vi ikke har vi har, og ville nok rotet til. Nå har Mail.ru s3-kompatibel lagring, Yandex har det, og en rekke andre leverandører har det. Vi kom etter hvert til ideen om at vi for det første ønsket å ha backup, og for det andre muligheten til å jobbe med lokale kopier. Spesifikt for den russiske regionen bruker vi Mail.ru Hotbox-tjenesten, som er API-kompatibel med s3. Vi trengte ingen store modifikasjoner av koden inne i applikasjonen, og vi laget følgende mekanisme: i s3 er det triggere som trigger opprettelse/sletting av objekter, Amazon har en tjeneste som heter Lambda - dette er en serverløs lansering av kode som vil bli utført akkurat når visse triggere utløses.
Vi gjorde det veldig enkelt: hvis utløseren vår utløses, kjører vi kode som kopierer objektet til Mail.ru-lagringen. For å fullt ut starte arbeidet med lokale kopier av data, trenger vi også omvendt synkronisering slik at klienter som er i det russiske segmentet kan jobbe med lagring som er nærmere dem. Mail er i ferd med å fullføre triggere i lagringen - det vil være mulig å utføre omvendt synkronisering på infrastrukturnivå, men foreløpig gjør vi dette på nivå med vår egen kode. Hvis vi ser at en klient har lagt ut en fil, plasserer vi hendelsen på kodenivå i en kø, behandler den og utfører omvendt replikering. Hvorfor det er dårlig: hvis vi gjør en eller annen form for arbeid med objektene våre utenfor produktet vårt, det vil si på noen eksterne måter, vil vi ikke ta det i betraktning. Derfor venter vi til slutten, når triggere dukker opp på lagringsnivået, slik at uansett hvor vi kjører koden fra, blir objektet som kom til oss kopiert i den andre retningen.
På kodenivå registrerer vi begge lagringene for hver klient: den ene regnes som den viktigste, den andre regnes som en sikkerhetskopi. Hvis alt er bra, jobber vi med lagringen som er nærmere oss: det vil si at våre kunder som er i Amazon, de jobber med S3, og de som jobber i Russland, de jobber med Hotbox. Hvis flagget utløses, bør failover kobles til, og vi bytter klienter til en annen lagring. Vi kan krysse av for denne boksen uavhengig etter region og kan bytte dem frem og tilbake. Vi har ikke brukt dette i praksis ennå, men vi har sørget for denne mekanismen, og vi tror at vi en dag vil trenge denne bryteren og komme til nytte. Dette har allerede skjedd en gang.
Oh, og Amazon stakk av...
Denne april markerer årsdagen for begynnelsen av Telegram-blokkering i Russland. Den mest berørte leverandøren som falt under dette er Amazon. Og dessverre led russiske selskaper som jobbet for hele verden mer.
Hvis selskapet er globalt og Russland er et veldig lite segment for det, 3-5% - vel, på en eller annen måte, kan du ofre dem.
Hvis dette er et rent russisk selskap - jeg er sikker på at det må være lokalisert - vel, det vil ganske enkelt være praktisk for brukerne selv, komfortabelt, og det vil være færre risikoer.
Hva om dette er et selskap som opererer globalt og har omtrent like mange kunder fra Russland og andre steder i verden? Tilknytningen til segmentene er viktig, og de må samarbeide med hverandre på en eller annen måte.
I slutten av mars 2018 sendte Roskomnadzor et brev til de største operatørene om at de planla å blokkere flere millioner Amazon IP-er for å blokkere... Zello messenger. Takket være de samme leverandørene - de lekket brevet til alle, og det var en forståelse for at forbindelsen med Amazon kunne falle fra hverandre. Det var fredag, vi løp i panikk til kollegene våre fra servers.ru, med ordene: "Venner, vi trenger flere servere som ikke vil være plassert i Russland, ikke i Amazon, men for eksempel et sted i Amsterdam." for å i det minste på en eller annen måte kunne installere vår egen VPN og proxy der for noen endepunkter som vi ikke kan påvirke på noen måte, for eksempel endepunkter på samme s3 - kan vi ikke prøve å opprette en ny tjeneste og få en annen ip, vi må du fortsatt komme dit. I løpet av bare noen få dager satte vi opp disse serverne, fikk dem i gang og generelt forberedt på øyeblikket blokkeringen begynte. Det er merkelig at RKN, som så på oppstyret og panikken, sa: "Nei, vi vil ikke blokkere noe nå." (Men dette er akkurat til øyeblikket da Telegram begynte å bli blokkert.) Etter å ha satt opp bypass-funksjonene og innsett at blokkeringen ikke var introdusert, begynte vi imidlertid ikke å ordne opp i hele saken. Ja, for sikkerhets skyld.
Og i 2019 lever vi fortsatt under forhold med blokkering. Jeg så i går kveld: omtrent en million IP-er er fortsatt blokkert. Riktignok ble Amazon nesten helt opphevet, på sitt topp nådde den 20 millioner adresser... Generelt er realiteten at det kanskje ikke er sammenheng, god sammenheng. Plutselig. Det finnes kanskje ikke av tekniske årsaker - branner, gravemaskiner, alt det der. Eller, som vi har sett, ikke helt teknisk. Derfor kan nok noen store og store, med egne AS'er, klare dette på andre måter - direktekobling og andre ting er allerede på l2-nivå. Men i en enkel versjon, som vår eller enda mindre, kan du, bare i tilfelle, ha redundans på nivået til servere som er hevet et annet sted, konfigurert på forhånd vpn, proxy, med muligheten til å raskt bytte konfigurasjonen til dem i disse segmentene som er avgjørende for tilkoblingen din. Dette kom til nytte for oss mer enn én gang da Amazons blokkering begynte; i verste fall tillot vi bare S3-trafikk gjennom dem, men etter hvert ble alt dette løst.
Hvordan reservere... en hel leverandør?
Akkurat nå har vi ikke et scenario i tilfelle hele Amazonas faller. Vi har et lignende scenario for Russland. I Russland ble vi hostet av én leverandør, som vi valgte å ha flere nettsteder fra. Og for et år siden sto vi overfor et problem: selv om dette er to datasentre, kan det være problemer allerede på nivået av leverandørens nettverkskonfigurasjon som fortsatt vil påvirke begge datasentrene. Og vi kan ende opp med å være utilgjengelige på begge nettstedene. Det var selvfølgelig det som skjedde. Vi endte opp med å revurdere arkitekturen inni. Det har ikke endret seg veldig mye, men for Russland har vi nå to nettsteder, som ikke er fra samme leverandør, men fra to forskjellige. Hvis det ene mislykkes, kan vi bytte til det andre.
Hypotetisk, for Amazon vurderer vi muligheten for reservasjon på nivå med en annen leverandør; kanskje Google, kanskje noen andre... Men så langt har vi observert i praksis at mens Amazon har ulykker på nivå med én tilgjengelighetssone, er ulykker på nivå med en hel region ganske sjeldne. Derfor har vi teoretisk sett ideen om at vi kan foreta en "Amazon is not Amazon"-reservasjon, men i praksis er dette ennå ikke tilfelle.
Noen få ord om automatisering
Er automatisering alltid nødvendig? Her er det på sin plass å minne om Dunning-Kruger-effekten. På "x"-aksen er vår kunnskap og erfaring som vi får, og på "y"-aksen er tillit til våre handlinger. Først vet vi ingenting og er slett ikke sikre. Da vet vi litt og blir megasikre - dette er den såkalte "toppen av dumhet", godt illustrert av bildet "demens og mot". Da har vi lært litt og er klare til å gå i kamp. Så tråkker vi på noen mega-alvorlige feil og befinner oss i en dal av fortvilelse, når vi ser ut til å vite noe, men faktisk vet vi ikke så mye. Så, etter hvert som vi får erfaring, blir vi mer selvsikre.
Vår logikk om ulike automatiske bytter til visse ulykker er meget godt beskrevet av denne grafen. Vi startet - vi visste ikke hvordan vi skulle gjøre noe, nesten alt arbeidet ble gjort for hånd. Så skjønte vi at vi kunne knytte automatisering til alt og liksom sove rolig. Og plutselig tråkker vi på en mega-rake: en falsk positiv utløses, og vi bytter trafikk frem og tilbake når vi på en god måte ikke skulle ha gjort dette. Følgelig bryter replikasjonen sammen eller noe annet - dette er selve fortvilelsens dal. Og så kommer vi til forståelsen av at vi må tilnærme oss alt med omhu. Det vil si at det er fornuftig å stole på automatisering, og sørger for muligheten for falske alarmer. Men! hvis konsekvensene kan være ødeleggende, så er det bedre å overlate det til vaktskiftet, til ingeniørene på vakt, som vil sørge for og overvåke at det virkelig er en ulykke, og vil utføre de nødvendige handlingene manuelt...
Konklusjon
I løpet av 7 år gikk vi fra at når noe falt, ble det panikk-panikk, til forståelsen av at problemer ikke finnes, det er bare oppgaver, de må – og kan – løses. Når du bygger en tjeneste, se på den ovenfra, vurder alle risikoene som kan skje. Hvis du ser dem med en gang, sørg for redundans på forhånd og muligheten for å bygge en feiltolerant infrastruktur, fordi ethvert punkt som kan mislykkes og føre til at tjenesten ikke fungerer, vil definitivt gjøre det. Og selv om det ser ut til at noen elementer i infrastrukturen definitivt ikke vil svikte - som den samme s3, må du likevel huske på at de kan. Og i det minste i teorien, ha en ide om hva du vil gjøre med dem hvis noe skjer. Ha en risikostyringsplan. Når du tenker på å gjøre alt automatisk eller manuelt, vurder risikoene: hva vil skje hvis automatiseringen begynner å bytte alt - vil ikke dette føre til en enda verre situasjon sammenlignet med en ulykke? Kanskje et sted er det nødvendig å bruke et rimelig kompromiss mellom bruken av automatisering og reaksjonen til den vakthavende ingeniøren, som vil vurdere det virkelige bildet og forstå om noe må byttes på stedet eller "ja, men ikke nå."
Et rimelig kompromiss mellom perfeksjonisme og reell innsats, tid, penger som du kan bruke på opplegget du til slutt vil ha.
Denne teksten er en oppdatert og utvidet versjon av Alexander Demidovs rapport på konferansen .
Kilde: www.habr.com