Om sommeren avtar tradisjonelt både kjøpsaktiviteten og intensiteten av endringer i infrastrukturen til nettprosjekter, forteller Captain Obvious. Rett og slett fordi selv IT-spesialister noen ganger drar på ferie. Og CTO også. Det er desto vanskeligere for de som sitter igjen, men det er ikke poenget nå: kanskje er det derfor sommeren er den beste perioden for sakte å tenke på den eksisterende reservasjonsordningen og utarbeide en plan for å forbedre den. Og opplevelsen av Yegor Andreev fra , som han snakket om på konferansen .
Det er flere fallgruver du kan falle i når du bygger sikkerhetskopieringssider. Og det er helt umulig å bli fanget i dem. Og det som ødelegger oss i alt dette, som i mange andre ting, er perfeksjonisme og... latskap. Vi prøver å gjøre alt, alt, alt perfekt, men vi trenger ikke å gjøre det perfekt! Du trenger bare å gjøre visse ting, men gjør dem riktig, fullfør dem slik at de fungerer som de skal.
Failover er ikke en morsom ting "så være det"; dette er en ting som bør gjøre akkurat én ting – redusere nedetiden slik at tjenesten, selskapet, taper mindre penger. Og i alle reservasjonsmetoder foreslår jeg å tenke i følgende sammenheng: hvor er pengene?
Første felle: Når vi bygger store, pålitelige systemer og driver redundans, reduserer vi antall ulykker. Dette er en forferdelig misforståelse. Når vi engasjerer oss i overtallighet, vil vi sannsynligvis øke antallet ulykker. Og hvis vi gjør alt riktig, vil vi samlet redusere nedetiden. Det vil være flere ulykker, men de vil skje til lavere kostnader. Hva er en reservasjon? - Dette er en komplikasjon av systemet. Enhver komplikasjon er dårlig: vi har flere tannhjul, flere gir, med et ord, flere elementer - og derfor en større sjanse for sammenbrudd. Og de vil virkelig gå i stykker. Og de vil knekke oftere. Et enkelt eksempel: la oss si at vi har en nettside med PHP og MySQL. Og det må snarest reserveres.
Shtosh (c) Vi tar den andre siden, bygger et identisk system... Kompleksiteten blir dobbelt så stor - vi har to enheter. Vi ruller også ut en viss logikk for overføring av data fra en side til en annen – det vil si datareplikering, kopiering av statiske data og så videre. Så replikeringslogikken er vanligvis veldig kompleks, og derfor kan den totale kompleksiteten til systemet ikke være 2, men 3, 5, 10 ganger større.
Andre felle: Når vi bygger virkelig store komplekse systemer, fantaserer vi om hva vi ønsker å få til til slutt. Voila: vi ønsker å få et superpålitelig system som fungerer uten nedetid, bytter på et halvt sekund (eller enda bedre, umiddelbart), og vi begynner å gjøre drømmer til virkelighet. Men det er også en nyanse her: jo kortere den ønskede koblingstiden er, desto mer kompleks blir systemlogikken. Jo mer kompleks vi må gjøre denne logikken, jo oftere vil systemet bryte sammen. Og du kan havne i en svært ubehagelig situasjon: vi prøver med all kraft å redusere nedetiden, men faktisk gjør vi alt mer komplisert, og når noe går galt, vil nedetiden ende opp med å bli lengre. Her tar du ofte deg selv i å tenke: vel... det ville være bedre å ikke reservere seg. Det ville vært bedre om det fungerte alene og med forståelig nedetid.
Hvordan kan du bekjempe dette? Vi må slutte å lyve for oss selv, slutte å smigre oss selv for at vi skal bygge et romskip her nå, men tilstrekkelig forstå hvor lenge prosjektet kan ligge. Og for denne maksimale tiden vil vi velge hvilke metoder vi faktisk vil bruke for å øke påliteligheten til systemet vårt.
Det er tid for "historier fra w"... fra livet, selvfølgelig.
Eksempel nummer én
Se for deg et visittkortnettsted for Pipe Rolling Plant No. 1 i byen N. Det står med store bokstaver - RØRRULLEANLEGG nr. 1. Rett under er slagordet: "Våre rør er de rundeste rørene i N." Og nedenfor er administrerende direktørs telefonnummer og navnet hans. Vi forstår at du må foreta en reservasjon - dette er en veldig viktig ting! La oss begynne å finne ut hva den består av. Html-statikk - altså et par bilder der daglig leder faktisk diskuterer en slags neste avtale ved bordet i badehuset med sin partner. Vi begynner å tenke på nedetid. Det kommer til tankene: du må ligge der i fem minutter, ikke mer. Og da oppstår spørsmålet: hvor mange salg var det fra denne siden vår generelt? Hvor mye - hvor mye? Hva betyr "null"? Og det betyr: fordi generalen gjorde alle fire transaksjonene i fjor ved samme bord, med de samme folkene som de går på badehuset og sitter ved bordet med. Og vi forstår at selv om siden blir stående i en dag, vil ingenting forferdelig skje.
Basert på den innledende informasjonen, er det en dag for å løfte denne historien. La oss begynne å tenke på en permitteringsordning. Og vi velger den mest ideelle redundansordningen for dette eksemplet: vi bruker ikke redundans. Hele denne greia kan tas opp av enhver admin på en halvtime med røykpauser. Installer en webserver, legg til filer - det er det. Det vil fungere. Du trenger ikke holde øye med noe, du trenger ikke være spesielt oppmerksom på noe. Det vil si at konklusjonen fra eksempel nummer én er ganske åpenbar: tjenester som ikke må reserveres trenger ikke reserveres.
Eksempel nummer to
Bedriftsblogg: spesialutdannede folk skriver nyheter der, vi var med på en slik og en utstilling, men vi ga ut et nytt produkt, og så videre. La oss si at dette er standard PHP med WordPress, en liten database og litt statisk. Selvfølgelig kommer det til tankene igjen at du under ingen omstendigheter skal legge deg ned - "ikke mer enn fem minutter!" Det er alt. Men la oss tenke videre. Hva gjør denne bloggen? Folk kommer dit fra Yandex, fra Google basert på noen søk, organisk. Flott. Har salget noe med det å gjøre? Helligtrekonger: egentlig ikke. Annonsetrafikk går til hovedsiden, som er på en annen maskin. La oss begynne å tenke på en bookingordning. På en god måte må den heves i løpet av et par timer, og det hadde vært fint å forberede seg på dette. Det vil være rimelig å ta en maskin fra et annet datasenter, rulle miljøet inn på det, det vil si en webserver, PHP, WordPress, MySQL, og la det være der. I øyeblikket når vi forstår at alt er ødelagt, må vi gjøre to ting - rulle ut mysql-dumpen 50 meter, den vil fly dit om et minutt, og rulle ut et visst antall bilder fra sikkerhetskopien der. Dette er heller ikke der for gud vet hvor lenge. Dermed hever det hele seg på en halvtime. Ingen replikering, eller gud tilgi meg, automatisk failover. Konklusjon: det vi raskt kan rulle ut fra en backup trenger ikke å sikkerhetskopieres.
Eksempel nummer tre, mer komplisert
Online-butikk. PhP med åpent hjerte er litt finjustert, mysql med en solid base. Ganske mye statisk (nettbutikken har tross alt vakre HD-bilder og alt det der), Redis for økten og Elasticsearch for søk. Vi begynner å tenke på nedetid. Og her er det selvsagt åpenbart at en nettbutikk ikke kan ligge smertefritt en dag. Tross alt, jo lenger den ligger, jo mer penger taper vi. Det er verdt å øke hastigheten. Hvor mye? Jeg tror at hvis vi legger oss en time, blir ingen gale. Ja, vi vil miste noe, men hvis vi begynner å jobbe hardt, vil det bare bli verre. Vi definerer et skjema for tillatt nedetid per time.
Hvordan kan alt dette reserveres? Du trenger en bil i alle fall: en times tid er ganske lite. Mysql: her trenger vi allerede replikering, live replikering, for om en time vil 100 GB mest sannsynlig ikke bli lagt til dumpen. Statikk, bilder: igjen, om en time kan det hende at 500 GB ikke har tid til å legges til. Derfor er det bedre å kopiere bildene med en gang. Redis: det er her ting blir interessant. I Redis lagres økter - vi kan ikke bare ta det og begrave det. For dette vil ikke være særlig bra: alle brukere vil bli logget ut, kurvene deres tømmes, og så videre. Folk vil bli tvunget til å skrive inn brukernavn og passord på nytt, og mange mennesker kan bryte ut og ikke fullføre kjøpet. Igjen vil konverteringene falle. På den annen side er Redis direkte oppdatert, med de sist påloggede brukerne sannsynligvis heller ikke nødvendig. Og et godt kompromiss er å ta Redis og gjenopprette den fra en sikkerhetskopi fra i går, eller, hvis du gjør det hver time, for en time siden. Heldigvis betyr å gjenopprette den fra en sikkerhetskopi å kopiere én fil. Og den mest interessante historien er Elasticsearch. Hvem har noen gang plukket opp MySQL-replikering? Hvem har noen gang plukket opp Elasticsearch-replikering? Og for hvem fungerte det normalt etter? Det jeg mener er at vi ser en viss enhet i systemet vårt. Det ser ut til å være nyttig – men det er komplekst.
Kompleks i den forstand at våre medingeniører ikke har noen erfaring med å jobbe med det. Eller det er en negativ opplevelse. Eller vi forstår at dette fortsatt er en ganske ny teknologi med nyanser eller råhet. Vi tenker... Jammen, strikk er også sunt, det tar også lang tid å gjenopprette det fra en backup, hva skal jeg gjøre? Vi forstår at strikk i vårt tilfelle brukes til søk. Hvordan selger nettbutikken vår? Vi går til markedsførere og spør hvor folk kommer fra. De svarer: "90 % fra Yandex Market kommer direkte til produktkortet." Og enten kjøper de det eller så gjør de det ikke. Derfor er søk nødvendig av 10 % av brukerne. Og å beholde elastisk replikering, spesielt mellom forskjellige datasentre i forskjellige soner, har virkelig mange nyanser. Hvilken utgang? Vi tar strikk fra et reservert nettsted og gjør ingenting med det. Hvis saken trekker ut vil vi nok ta den opp en dag, men dette er ikke sikkert. Faktisk er konklusjonen den samme, pluss eller minus: vi, igjen, reserverer ikke tjenester som ikke påvirker penger. For å gjøre diagrammet enklere.
Eksempel nummer fire, enda vanskeligere
Integrator: selge blomster, ringe en taxi, selge varer, generelt, hva som helst. En seriøs ting som fungerer 24/7 for et stort antall brukere. Med en fullverdig interessant stabel, hvor det er interessante baser, løsninger, høy belastning, og viktigst av alt, det gjør vondt å ligge i mer enn 5 minutter. Ikke bare og ikke så mye fordi folk ikke vil kjøpe, men fordi folk vil se at denne tingen ikke fungerer, vil de bli opprørt og kanskje ikke komme tilbake i det hele tatt.
OK. Fem minutter. Hva skal vi gjøre med dette? I dette tilfellet bruker vi, som voksne, alle pengene til å bygge en ekte backupside, med replikering av alt, og kanskje til og med automatisere bytte til denne siden så mye som mulig. Og i tillegg til dette må du huske å gjøre en viktig ting: faktisk skrive bytteforskriften. Regelverket, selv om du har alt automatisert, kan være veldig enkelt. Fra serien "kjør et slikt og slikt skript", "klikk på en slik og en avkrysningsboks i rute 53" og så videre - men dette må være en slags eksakt liste over handlinger.
Og alt virker klart. Å bytte replikering er en triviell oppgave, eller det vil bytte seg selv. Å omskrive et domenenavn i DNS er fra samme serie. Problemet er at når et slikt prosjekt mislykkes, begynner panikken, og selv de sterkeste, skjeggete administratorene kan være mottakelige for det. Uten klare instruksjoner "åpne terminalen, kom hit, serverens adresse er fortsatt slik," er det vanskelig å overholde 5-minutters tidsfristen som er tildelt for gjenopplivning. Vel, pluss, når vi bruker disse forskriftene, er det enkelt å registrere noen endringer i for eksempel infrastrukturen, og endre regelverket deretter.
Vel, hvis reservasjonssystemet er veldig komplekst og på et tidspunkt har vi gjort en feil, så kan vi ødelegge backupsiden vår, og i tillegg gjøre dataene om til et gresskar på begge nettstedene - dette vil være helt trist.
Eksempel nummer fem, komplett hardcore
En internasjonal tjeneste med hundrevis av millioner brukere over hele verden. Alle tidssonene som finnes, høy belastning ved maksimal hastighet, du kan ikke legge deg i det hele tatt. Et minutt - og det blir trist. Hva å gjøre? Reserver, igjen, ifølge hele programmet. Vi gjorde alt jeg snakket om i forrige eksempel, og litt til. En ideell verden, og vår infrastruktur er i henhold til alle konseptene til IaaC devops. Det vil si at alt er i git, og du trykker bare på knappen.
Hva mangler? En - øvelser. Det er umulig uten dem. Det ser ut til at alt er perfekt hos oss, vi har stort sett alt under kontroll. Vi trykker på knappen, alt skjer. Selv om det er slik – og vi forstår at det ikke skjer på denne måten – samhandler systemet vårt med noen andre systemer. Dette er for eksempel dns fra rute 53, s3-lagring, integrasjon med noe api. Vi vil ikke kunne forutse alt i dette spekulative eksperimentet. Og før vi faktisk trekker på bryteren, vet vi ikke om det vil fungere eller ikke.
Det er nok alt. Ikke vær lat eller overdriv. Og kan oppetid være med deg!
Kilde: www.habr.com