Idag har Bitrix24-tjänsten inte hundratals gigabits trafik, och den har inte heller en enorm flotta av servrar (även om det naturligtvis finns en hel del befintliga). Men för många kunder är det det viktigaste verktyget för att arbeta i företaget, det är en verkligt affärskritisk applikation. Därför finns det inget sätt att falla. Tänk om kraschen inträffade, men tjänsten "återhämtade sig" så snabbt att ingen märkte något? Och hur är det möjligt att implementera failover utan att förlora kvaliteten på arbetet och antalet klienter? Alexander Demidov, chef för molntjänster på Bitrix24, talade för vår blogg om hur bokningssystemet har utvecklats under de sju år som produkten funnits.
"Vi lanserade Bitrix24 som en SaaS för 7 år sedan. Den största svårigheten var förmodligen följande: innan den lanserades offentligt som SaaS, fanns den här produkten helt enkelt i formatet av en boxad lösning. Kunder köpte det av oss, höll det på sina servrar, skapade en företagsportal - en generell lösning för medarbetarkommunikation, fillagring, uppgiftshantering, CRM, det är allt. Och 2012 bestämde vi oss för att lansera det som SaaS, administrera det själva och säkerställa feltolerans och tillförlitlighet. Vi fick erfarenhet på vägen, för fram till dess hade vi det helt enkelt inte – vi var bara mjukvarutillverkare, inte tjänsteleverantörer.
När vi lanserade tjänsten förstod vi att det viktigaste är att säkerställa feltolerans, tillförlitlighet och konstant tillgänglighet för tjänsten, för om du har en enkel vanlig hemsida, till exempel en butik, och den faller på dig och sitter där för en timme, bara du lider, du förlorar order, du förlorar kunder, men för din klient själv är detta inte särskilt kritiskt för honom. Han var förstås upprörd, men han gick och köpte den på en annan sida. Och om det här är en applikation där allt arbete inom företaget, kommunikation, beslut är knutet, så är det viktigaste att vinna användarnas förtroende, det vill säga att inte svika dem och inte falla. För allt arbete kan sluta om något inuti inte fungerar.
Bitrix.24 som SaaS
Vi monterade den första prototypen ett år innan den offentliga lanseringen, 2011. Vi monterade den på ungefär en vecka, tittade på den, snurrade den - den fungerade till och med. Det vill säga, du kan gå in i formuläret, ange namnet på portalen där, en ny portal skulle öppnas och en användarbas skapas. Vi tittade på den, bedömde produkten i princip, skrotade den och fortsatte att förädla den under ett helt år. Eftersom vi hade en stor uppgift: vi ville inte göra två olika kodbaser, vi ville inte stödja en separat paketerad produkt, separata molnlösningar - vi ville göra allt inom en kod.
En typisk webbapplikation på den tiden var en server där lite PHP-kod körs, en mysql-databas, filer laddas upp, dokument, bilder läggs i uppladdningsmappen - ja, allt fungerar. Tyvärr är det omöjligt att lansera en kritiskt stabil webbtjänst med detta. Där stöds inte distribuerad cache, databasreplikering stöds inte.
Vi formulerade kraven: det här är förmågan att vara placerad på olika platser, stödja replikering och helst vara placerad i olika geografiskt distribuerade datacenter. Separera produktlogiken och, faktiskt, datalagring. Kunna skala dynamiskt efter belastningen och tolerera statik helt och hållet. Ur dessa överväganden framkom faktiskt kraven på produkten, som vi förfinade under året. Under denna tid, i plattformen, som visade sig vara enhetlig - för boxade lösningar, för vår egen tjänst - gjorde vi stöd för de saker som vi behövde. Stöd för mysql-replikering på själva produktens nivå: det vill säga utvecklaren som skriver koden tänker inte på hur hans förfrågningar kommer att distribueras, han använder vår api och vi vet hur man korrekt distribuerar skriv- och läsbegäranden mellan masters och slavar.
Vi har gjort support på produktnivå för olika molnobjektlagringar: google storage, amazon s3, plus stöd för open stack swift. Därför var detta bekvämt både för oss som tjänst och för utvecklare som arbetar med en paketerad lösning: om de bara använder vårt API för arbetet tänker de inte på var filen i slutändan kommer att sparas, lokalt på filsystemet eller i objektfillagringen.
Som ett resultat beslutade vi omedelbart att vi skulle reservera på nivån för hela datacentret. Under 2012 lanserade vi helt och hållet på Amazon AWS eftersom vi redan hade erfarenhet av den här plattformen - vår egen webbplats var värd där. Vi lockades av det faktum att Amazon i varje region har flera tillgänglighetszoner - faktiskt (i deras terminologi) flera datacenter som är mer eller mindre oberoende av varandra och tillåter oss att reservera på nivån för ett helt datacenter: om det plötsligt misslyckas replikeras databaserna master-master, webbapplikationsservrarna säkerhetskopieras och statisk data flyttas till s3-objektlagringen. Lasten är balanserad - på den tiden av Amazon elb, men lite senare kom vi till våra egna lastbalanserare, eftersom vi behövde mer komplex logik.
Vad de ville ha är vad de fick...
Alla grundläggande saker som vi ville säkerställa - feltolerans för själva servrarna, webbapplikationer, databaser - allt fungerade bra. Det enklaste scenariot: om en av våra webbapplikationer misslyckas, då är allt enkelt - de är avstängda från balansering.
Balanseraren (på den tiden var det Amazons elb) markerade maskiner som var ur funktion som ohälsosamma och stängde av lastfördelning på dem. Amazons autoskalning fungerade: när belastningen växte lades nya maskiner till i autoskalningsgruppen, belastningen fördelades på nya maskiner - allt var bra. Med våra balanserare är logiken ungefär densamma: om något händer med applikationsservern tar vi bort förfrågningar från den, kastar ut dessa maskiner, startar nya och fortsätter att arbeta. Systemet har förändrats lite under åren, men fortsätter att fungera: det är enkelt, förståeligt och det finns inga svårigheter med det.
Vi arbetar över hela världen, kundbelastningstoppar är helt olika, och på ett vänskapligt sätt bör vi när som helst kunna utföra visst servicearbete på alla komponenter i vårt system – obemärkt av kunderna. Därför har vi möjlighet att stänga av databasen från drift och omfördela belastningen till ett andra datacenter.
Hur fungerar det hela? — Vi byter trafik till ett fungerande datacenter - om det händer en olycka i datacentret, då helt, om detta är vårt planerade arbete med en databas, så byter vi en del av trafiken som betjänar dessa klienter till ett andra datacenter, vilket avbryter det replikering. Om det behövs nya maskiner för webbapplikationer eftersom belastningen på det andra datacentret har ökat startar de automatiskt. Vi avslutar arbetet, replikeringen återställs och vi returnerar hela lasten. Om vi behöver spegla något arbete i den andra DC, till exempel installera systemuppdateringar eller ändra inställningar i den andra databasen, så upprepar vi i allmänhet samma sak, bara åt andra hållet. Och om detta är en olycka, då gör vi allt trivialt: vi använder mekanismen för händelsehanterare i övervakningssystemet. Om flera kontroller utlöses och statusen blir kritisk kör vi denna hanterare, en hanterare som kan exekvera den eller den logiken. För varje databas anger vi vilken server som är failover för den, och var trafik måste bytas om den inte är tillgänglig. Historiskt sett använder vi nagios eller några av dess gafflar i en eller annan form. I princip finns liknande mekanismer i nästan alla övervakningssystem, vi använder inte något mer komplext än, men kanske kommer vi att göra det någon gång. Nu utlöses övervakning av otillgänglighet och har möjlighet att byta något.
Har vi reserverat allt?
Vi har många kunder från USA, många kunder från Europa, många kunder som är närmare öst - Japan, Singapore och så vidare. Naturligtvis finns en stor del av kunderna i Ryssland. Det vill säga arbete finns inte i en region. Användare vill ha ett snabbt svar, det finns krav på att följa olika lokala lagar, och inom varje region reserverar vi två datacenter, plus det finns några ytterligare tjänster, som återigen är bekväma att placera inom en region - för kunder som är i denna region fungerar. REST-hanterare, auktoriseringsservrar, de är mindre kritiska för driften av klienten som helhet, du kan växla mellan dem med en liten acceptabel fördröjning, men du vill inte återuppfinna hjulet för hur man övervakar dem och vad man ska göra med dem. Därför försöker vi utnyttja befintliga lösningar maximalt, snarare än att utveckla någon form av kompetens inom ytterligare produkter. Och någonstans använder vi trivialt byte på DNS-nivå, och vi bestämmer tjänstens livlighet med samma DNS. Amazon har en Route 53-tjänst, men det är inte bara en DNS som du kan lägga in i och det är det – det är mycket mer flexibelt och bekvämt. Genom den kan du bygga geodistribuerade tjänster med geolokaliseringar, när du använder den för att avgöra var klienten kom ifrån och ge honom vissa poster – med dess hjälp kan du bygga failover-arkitekturer. Samma hälsokontroller konfigureras i själva Route 53, du ställer in ändpunkterna som övervakas, ställer in mätvärden, ställer in vilka protokoll som ska bestämma tjänstens "liveness" - tcp, http, https; ställ in frekvensen för kontroller som avgör om tjänsten är levande eller inte. Och i själva DNS anger du vad som ska vara primärt, vad som ska vara sekundärt, var du ska byta om hälsokontrollen utlöses på väg 53. Allt detta kan göras med några andra verktyg, men varför är det bekvämt - vi ställer in det upp en gång och sedan inte tänka på det alls hur vi gör kontroller, hur vi byter: allt fungerar av sig självt.
Det första "men": hur och med vad ska man reservera väg 53 själv? Vem vet, tänk om något händer honom? Lyckligtvis trampade vi aldrig på den här raken, men återigen, jag kommer att ha en historia framför oss om varför vi trodde att vi fortfarande behövde göra en reservation. Här lade vi ut sugrör åt oss själva i förväg. Flera gånger om dagen gör vi en fullständig avlastning av alla zoner som vi har på väg 53. Amazons API låter dig enkelt skicka dem i JSON och vi har flera backupservrar där vi konverterar det, laddar upp det i form av konfigurationer och har, grovt sett, en backup-konfiguration. Om något händer kan vi snabbt distribuera det manuellt utan att förlora DNS-inställningarna.
Andra "men": Vad på den här bilden är ännu inte reserverat? Själva balanseringen! Vår fördelning av kunder per region är mycket enkel. Vi har domänerna bitrix24.ru, bitrix24.com, .de - nu finns det 13 olika, som verkar i en mängd olika zoner. Vi kom fram till följande: varje region har sina egna balanserare. Detta gör det bekvämare att fördela över regioner, beroende på var toppbelastningen på nätet är. Om detta är ett misslyckande på nivån för en enda balanserare, tas den helt enkelt ur drift och tas bort från dns. Om det finns något problem med en grupp av balansörer, så säkerhetskopieras de på andra webbplatser, och bytet mellan dem görs med samma rutt53, eftersom på grund av den korta TTL sker bytet inom maximalt 2, 3, 5 minuter .
Tredje "men": Vad är ännu inte reserverat? S3, korrekt. När vi placerade filerna som vi lagrar för användare i s3 trodde vi uppriktigt att det var pansarbrytande och att det inte behövdes reserveras något där. Men historien visar att saker händer annorlunda. Generellt sett beskriver Amazon S3 som en grundläggande tjänst, eftersom Amazon själv använder S3 för att lagra maskinbilder, konfigurationer, AMI-bilder, ögonblicksbilder... Och om s3 kraschar, som hänt en gång under dessa 7 år, så länge som vi har använt bitrix24, den följer den som ett fan. Det finns en hel massa saker som dyker upp – oförmåga att starta virtuella maskiner, api-fel, och så vidare.
Och S3 kan falla - det hände en gång. Därför kom vi fram till följande plan: för några år sedan fanns det inga seriösa offentliga föremålslagringsanläggningar i Ryssland, och vi övervägde alternativet att göra något eget... Lyckligtvis började vi inte göra detta, eftersom vi skulle har grävt i den expertis som vi inte har vi har, och skulle antagligen trassla till. Nu har Mail.ru s3-kompatibel lagring, Yandex har det, och ett antal andra leverantörer har det. Så småningom kom vi på idén att vi ville ha dels backup och dels förmågan att arbeta med lokala kopior. Specifikt för den ryska regionen använder vi tjänsten Mail.ru Hotbox, som är API-kompatibel med s3. Vi behövde inga större modifieringar av koden inuti applikationen, och vi gjorde följande mekanism: i s3 finns det triggers som utlöser skapande/radering av objekt, Amazon har en tjänst som heter Lambda - detta är en serverlös lansering av kod som kommer att exekveras precis när vissa triggers utlöses.
Vi gjorde det väldigt enkelt: om vår trigger utlöses, kör vi kod som kopierar objektet till Mail.ru-lagringen. För att fullt ut kunna starta arbetet med lokala kopior av data behöver vi också omvänd synkronisering så att kunder som finns i det ryska segmentet kan arbeta med lagring som ligger närmare dem. Mail är på väg att slutföra triggers i sin lagring - det kommer att vara möjligt att utföra omvänd synkronisering på infrastrukturnivå, men för närvarande gör vi detta på nivån för vår egen kod. Om vi ser att en klient har postat en fil, placerar vi på kodnivå händelsen i en kö, bearbetar den och gör omvänd replikering. Varför det är dåligt: om vi gör något slags arbete med våra objekt utanför vår produkt, det vill säga på något externt sätt, kommer vi inte att ta hänsyn till det. Därför väntar vi till slutet, när triggers dyker upp på lagringsnivån, så att oavsett var vi exekverar koden från, så kopieras objektet som kom till oss åt andra hållet.
På kodnivå registrerar vi båda lagringarna för varje klient: den ena anses vara den huvudsakliga, den andra betraktas som en backup. Om allt är bra arbetar vi med lagringen som är närmare oss: det vill säga våra kunder som är i Amazon, de arbetar med S3, och de som arbetar i Ryssland, de arbetar med Hotbox. Om flaggan utlöses, bör failover vara ansluten och vi byter klienter till en annan lagring. Vi kan markera denna ruta oberoende av region och kan byta dem fram och tillbaka. Vi har inte använt detta i praktiken än, men vi har tillhandahållit den här mekanismen och vi tror att vi en dag kommer att behöva just denna omkopplare och komma väl till pass. Detta har redan hänt en gång.
Åh, och Amazon sprang...
I april är det årsdagen av början av blockeringen av Telegram i Ryssland. Den mest drabbade leverantören som faller under detta är Amazon. Och tyvärr drabbades ryska företag som arbetade för hela världen mer.
Om företaget är globalt och Ryssland är ett mycket litet segment för det, 3-5% - ja, på ett eller annat sätt kan du offra dem.
Om detta är ett rent ryskt företag - jag är säker på att det måste vara lokaliserat - ja, det kommer helt enkelt att vara bekvämt för användarna själva, bekvämt och det kommer att finnas färre risker.
Tänk om detta är ett företag som verkar globalt och har ungefär lika många kunder från Ryssland och någonstans runt om i världen? Segmentens kopplingsförmåga är viktig, och de måste fungera med varandra på ett eller annat sätt.
I slutet av mars 2018 skickade Roskomnadzor ett brev till de största operatörerna om att de planerade att blockera flera miljoner Amazon-IP:er för att blockera... Zello-budbäraren. Tack vare samma leverantörer - de lyckades läcka brevet till alla, och det fanns en förståelse för att kopplingen till Amazon kunde falla isär. Det var fredag, vi sprang i panik till våra kollegor från servers.ru och sa: "Vänner, vi behöver flera servrar som inte kommer att finnas i Ryssland, inte i Amazon, utan till exempel någonstans i Amsterdam," för att att för att åtminstone på något sätt kunna installera vår egen VPN och proxy där för vissa endpoints som vi inte kan påverka på något sätt, till exempel endponts av samma s3 - vi kan inte försöka få upp en ny tjänst och få en annan ip, vi måste du fortfarande komma dit. På bara några dagar satte vi upp dessa servrar, satte igång dem och förberedde oss i allmänhet för det ögonblick då blockeringen började. Det är märkligt att RKN, som tittade på väsen och paniken, sa: "Nej, vi kommer inte att blockera någonting nu." (Men detta är precis tills det ögonblick då Telegram började blockeras.) Efter att ha ställt in bypass-funktionerna och insett att blockeringen inte hade införts, började vi dock inte reda ut hela saken. Ja, för säkerhets skull.
Och 2019 lever vi fortfarande under förhållanden av blockering. Jag tittade i går kväll: ungefär en miljon IP-adresser fortsätter att vara blockerade. Visserligen var Amazon nästan helt avblockerad, på sin topp nådde den 20 miljoner adresser... I allmänhet är verkligheten att det kanske inte finns någon koherens, bra koherens. Plötsligt. Det kanske inte finns av tekniska skäl - bränder, grävmaskiner, allt det där. Eller, som vi har sett, inte helt tekniskt. Därför kan nog någon stor som stor, med egna AS:er, klara av detta på andra sätt - direktanslutning och annat är redan på l2-nivå. Men i en enkel version, som vår eller till och med mindre, kan du, för säkerhets skull, ha redundans på nivån för servrar som höjs någon annanstans, konfigurerade i förväg vpn, proxy, med möjligheten att snabbt byta konfigurationen till dem i dessa segment som är avgörande för din anslutning. Detta kom till nytta för oss mer än en gång när Amazons blockering började; i värsta fall tillät vi bara S3-trafik genom dem, men gradvis löstes allt detta.
Hur reserverar man... en hel leverantör?
Just nu har vi inget scenario om hela Amazonas går under. Vi har ett liknande scenario för Ryssland. I Ryssland var vi värd för en leverantör, från vilken vi valde att ha flera sajter. Och för ett år sedan stod vi inför ett problem: även om det är två datacenter kan det finnas problem redan på nivån för leverantörens nätverkskonfiguration som fortfarande kommer att påverka båda datacenterna. Och vi kan hamna otillgängliga på båda sidorna. Det var såklart vad som hände. Det slutade med att vi ompröva arkitekturen inuti. Det har inte förändrats särskilt mycket, men för Ryssland har vi nu två sajter, som inte kommer från samma leverantör, utan från två olika. Om det ena misslyckas kan vi byta till det andra.
Hypotetiskt, för Amazon överväger vi möjligheten att boka på nivån hos en annan leverantör; kanske Google, kanske någon annan... Men hittills har vi observerat i praktiken att medan Amazon har olyckor i nivå med en tillgänglighetszon, är olyckor på nivå med en hel region ganska sällsynta. Därför har vi teoretiskt sett tanken att vi kan göra en "Amazon är inte Amazon"-reservation, men i praktiken är det ännu inte fallet.
Några ord om automatisering
Är automatisering alltid nödvändigt? Här är det lämpligt att påminna om Dunning-Kruger-effekten. På "x"-axeln finns vår kunskap och erfarenhet som vi får, och på "y"-axeln finns förtroende för våra handlingar. Först vet vi ingenting och är inte alls säkra. Då vet vi lite och blir megasäkra - detta är den så kallade "toppen av dumhet", väl illustrerad av bilden "demens och mod". Då har vi lärt oss lite och är redo att ge oss ut i strid. Sedan kliver vi på några megaallvarliga misstag och befinner oss i en förtvivlans dal, när vi verkar veta något, men i själva verket vet vi inte mycket. Sedan, när vi får erfarenhet, blir vi mer självsäkra.
Vår logik kring olika automatiska växlar till vissa olyckor beskrivs mycket väl av denna graf. Vi började - vi visste inte hur vi skulle göra någonting, nästan allt arbete gjordes för hand. Sedan insåg vi att vi kunde koppla automatisering till allt och liksom sova lugnt. Och plötsligt trampar vi på en mega-rake: en falsk positiv utlöses, och vi byter trafik fram och tillbaka när vi på ett bra sätt inte borde ha gjort det här. Följaktligen går replikationen sönder eller något annat - detta är själva förtvivlans dal. Och då kommer vi till insikten att vi måste närma oss allt klokt. Det vill säga, det är vettigt att lita på automatisering, vilket ger möjligheten till falska larm. Men! om konsekvenserna kan bli förödande, då är det bättre att överlåta det till tjänstgöringsskiftet, till tjänstgörande ingenjörer, som ser till och övervakar att det verkligen är en olycka och kommer att utföra nödvändiga åtgärder manuellt...
Slutsats
Under loppet av 7 år gick vi från att när något föll blev det panik-panik, till insikten att problem inte finns, det finns bara uppgifter, de måste – och kan – lösas. När du bygger en tjänst, titta på den uppifrån, bedöm alla risker som kan hända. Om du ser dem direkt, sörj för redundans i förväg och möjligheten att bygga en feltolerant infrastruktur, eftersom varje punkt som kan misslyckas och leda till tjänstens inoperabilitet kommer definitivt att göra det. Och även om det verkar för dig att vissa delar av infrastrukturen definitivt inte kommer att misslyckas - som samma s3, tänk ändå på att de kan. Och åtminstone i teorin, ha en uppfattning om vad du kommer att göra med dem om något händer. Ha en riskhanteringsplan. När du funderar på att göra allt automatiskt eller manuellt, bedöm riskerna: vad händer om automatiseringen börjar byta allt - kommer det inte att leda till en ännu värre situation jämfört med en olycka? Kanske någonstans är det nödvändigt att använda en rimlig kompromiss mellan användningen av automation och reaktionen från tjänstgörande ingenjör, som kommer att utvärdera den verkliga bilden och förstå om något måste bytas på plats eller "ja, men inte nu."
En rimlig kompromiss mellan perfektionism och verklig ansträngning, tid, pengar som du kan spendera på det system som du så småningom kommer att ha.
Denna text är en uppdaterad och utökad version av Alexander Demidovs rapport vid konferensen .
Källa: will.com