Om sommeren falder både indkøbsaktiviteten og intensiteten af ændringer i webprojekters infrastruktur traditionelt, fortæller Captain Obvious. Simpelthen fordi selv it-specialister nogle gange tager på ferie. Og også CTO. Det er så meget desto sværere for dem, der forbliver i embedet, men det er ikke meningen nu: måske er sommeren derfor den bedste periode til langsomt at tænke over den eksisterende reservationsordning og udarbejde en plan for at forbedre den. Og oplevelsen af Yegor Andreev fra , som han talte om på konferencen .
Der er flere faldgruber, du kan falde i, når du bygger backup-websteder. Og det er absolut umuligt at blive fanget i dem. Og det, der ødelægger os i alt dette, som i mange andre ting, er perfektionisme og... dovenskab. Vi forsøger at gøre alt, alt, alt perfekt, men vi behøver ikke at gøre det perfekt! Du behøver kun at gøre visse ting, men gør dem korrekt, udfør dem, så de fungerer korrekt.
Failover er ikke en slags sjov, sjov ting; dette er en ting, der skal gøre præcis én ting - reducere nedetiden, så tjenesten, virksomheden, taber færre penge. Og i alle reservationsmetoder foreslår jeg at tænke i følgende sammenhæng: hvor er pengene?
Første fælde: Når vi bygger store, pålidelige systemer og engagerer os i redundans, reducerer vi antallet af ulykker. Dette er en frygtelig misforståelse. Når vi engagerer os i redundans, vil vi sandsynligvis øge antallet af ulykker. Og hvis vi gør alt rigtigt, så vil vi i fællesskab reducere nedetiden. Der vil være flere ulykker, men de vil ske til lavere omkostninger. Hvad er en reservation? - dette er en komplikation af systemet. Enhver komplikation er dårlig: vi har flere tandhjul, flere gear, kort sagt flere elementer - og derfor en større chance for sammenbrud. Og de vil virkelig gå i stykker. Og de vil gå i stykker oftere. Et simpelt eksempel: lad os sige, at vi har en hjemmeside med PHP og MySQL. Og den skal hurtigst muligt reserveres.
Shtosh (c) Vi tager den anden side, bygger et identisk system... Kompleksiteten bliver dobbelt så stor - vi har to entiteter. Vi udruller også en vis logik til at overføre data fra et sted til et andet - det vil sige datareplikering, kopiering af statiske data og så videre. Så replikeringslogikken er normalt meget kompleks, og derfor kan systemets samlede kompleksitet ikke være 2, men 3, 5, 10 gange større.
Anden fælde: Når vi bygger virkelig store komplekse systemer, fantaserer vi om, hvad vi vil have til sidst. Voila: vi ønsker at få et super-pålideligt system, der fungerer uden nedetid, skifter på et halvt sekund (eller endnu bedre, øjeblikkeligt), og vi begynder at gøre drømme til virkelighed. Men der er også en nuance her: Jo kortere den ønskede koblingstid er, jo mere kompleks bliver systemlogikken. Jo mere kompleks vi skal lave denne logik, jo oftere vil systemet bryde sammen. Og du kan ende i en meget ubehagelig situation: Vi forsøger med al vores magt at reducere nedetiden, men faktisk gør vi alting mere kompliceret, og når noget går galt, vil nedetiden ende med at blive længere. Her fanger du ofte dig selv i at tænke: jamen... det ville være bedre ikke at reservere. Det ville være bedre, hvis det fungerede alene og med forståelig nedetid.
Hvordan kan du bekæmpe dette? Vi skal holde op med at lyve for os selv, lade være med at smigre os selv over, at vi skal bygge et rumskib her nu, men tilstrækkeligt forstå, hvor længe projektet kan ligge. Og i denne maksimale tid vil vi vælge, hvilke metoder vi rent faktisk vil bruge for at øge pålideligheden af vores system.
Det er tid til “historier fra w”... fra livet, selvfølgelig.
Eksempel nummer et
Forestil dig et visitkort-websted for Pipe Rolling Plant No. 1 i byen N. Der står med store bogstaver - Pipe Rolling Plant No. 1. Lige under er sloganet: "Vores rør er de rundeste rør i N." Og nedenfor er den administrerende direktørs telefonnummer og hans navn. Vi forstår, at du skal foretage en reservation - det er en meget vigtig ting! Lad os begynde at finde ud af, hvad det består af. Html-statik - altså et par billeder, hvor den daglige leder i virkeligheden diskuterer en slags næste aftale ved bordet i badehuset med sin partner. Vi begynder at tænke på nedetid. Det kommer til at tænke på: du skal ligge der i fem minutter, ikke mere. Og så opstår spørgsmålet: hvor mange salg var der generelt fra denne side af vores side? Hvor meget - hvor meget? Hvad betyder "nul"? Og det betyder: fordi generalen sidste år lavede alle fire transaktioner ved samme bord, med de samme mennesker, som de går i badehuset og sætter sig ved bordet med. Og vi forstår, at selvom siden bliver stående i en dag, vil der ikke ske noget forfærdeligt.
Baseret på den indledende information er der en dag til at rejse denne historie. Lad os begynde at tænke på en afskedigelsesordning. Og vi vælger den mest ideelle redundansordning til dette eksempel: vi bruger ikke redundans. Det hele kan rejses af enhver administrator på en halv time med røgpauser. Installer en webserver, tilføj filer - det er det. Det vil virke. Du behøver ikke holde øje med noget, du behøver ikke være særlig opmærksom på noget. Det vil sige, at konklusionen fra eksempel nummer et er ret indlysende: Tjenester, der ikke skal reserveres, skal ikke reserveres.
Eksempel nummer to
Firmablog: specialuddannede folk skriver nyheder der, vi deltog i sådan en udstilling, men vi udgav endnu et nyt produkt og så videre. Lad os sige, at dette er standard PHP med WordPress, en lille database og en lille smule statisk. Selvfølgelig kommer det til at tænke på igen, at du under ingen omstændigheder skal ligge ned - "ikke mere end fem minutter!" Det er alt. Men lad os tænke videre. Hvad gør denne blog? Folk kommer dertil fra Yandex, fra Google baseret på nogle forespørgsler, organisk. Store. Har salget noget med det at gøre? Helligtrekonger: ikke rigtig. Annoncetrafik går til hovedsiden, som er på en anden maskine. Lad os begynde at tænke på en bookingordning. På en god måde skal den hæves i løbet af et par timer, og det ville være rart at forberede sig på dette. Det ville være rimeligt at tage en maskine fra et andet datacenter, rulle miljøet ind på det, det vil sige en webserver, PHP, WordPress, MySQL, og lade det være der. I det øjeblik, hvor vi forstår, at alt er i stykker, skal vi gøre to ting - rulle mysql-dumpet ud 50 meter, det vil flyve dertil om et minut, og rulle et vist antal billeder ud fra sikkerhedskopien der. Dette er der heller ikke for gud ved hvor længe. På en halv time rejser det hele sig således. Ingen replikering, eller Gud tilgive mig, automatisk failover. Konklusion: det, vi hurtigt kan rulle ud fra en backup, skal ikke sikkerhedskopieres.
Eksempel nummer tre, mere kompliceret
Online butik. PhP med åbent hjerte er lidt tweaked, mysql med en solid base. Rigtig meget statisk (netbutikken har trods alt smukke HD-billeder og alt det der), Redis til sessionen og Elasticsearch til søgning. Vi begynder at tænke på nedetid. Og her er det selvfølgelig åbenlyst, at en netbutik ikke kan ligge smertefrit en dag. Jo længere den ligger, jo flere penge taber vi. Det er værd at sætte farten op. Hvor meget? Jeg tror, at hvis vi ligger ned i en time, er der ingen, der bliver skøre. Ja, vi vil miste noget, men hvis vi begynder at arbejde hårdt, bliver det kun værre. Vi definerer en ordning for tilladt nedetid pr. time.
Hvordan kan alt dette reserveres? Du har under alle omstændigheder brug for en bil: en times tid er ret lidt. Mysql: her har vi allerede brug for replikering, live replikering, for om en time vil der højst sandsynligt ikke blive tilføjet 100 GB til dumpet. Statik, billeder: igen, om en time har 500 GB muligvis ikke tid til at blive tilføjet. Derfor er det bedre at kopiere billederne med det samme. Redis: det er her, tingene bliver interessante. I Redis er sessioner gemt - vi kan ikke bare tage det og begrave det. For det vil ikke være særlig godt: alle brugere bliver logget ud, deres kurve bliver tømt og så videre. Folk vil blive tvunget til at indtaste deres brugernavn og adgangskode igen, og mange mennesker kan bryde væk og ikke gennemføre købet. Igen vil konverteringerne falde. Til gengæld er Redis direkte up-to-date, hvor de sidst loggede brugere formentlig heller ikke er nødvendige. Og et godt kompromis er at tage Redis og gendanne den fra en sikkerhedskopi fra i går, eller, hvis du gør det hver time, for en time siden. Heldigvis betyder gendannelse fra en sikkerhedskopi kopiering af én fil. Og den mest interessante historie er Elasticsearch. Hvem har nogensinde hentet MySQL-replikering? Hvem har nogensinde opfanget Elasticsearch-replikation? Og for hvem fungerede det normalt efter? Hvad jeg mener er, at vi ser en bestemt enhed i vores system. Det ser ud til at være nyttigt – men det er komplekst.
Kompleks i den forstand, at vores medingeniører ikke har nogen erfaring med at arbejde med det. Eller der er en negativ oplevelse. Eller vi forstår, at dette stadig er en ret ny teknologi med nuancer eller råhed. Vi tænker... Damn, elastik er også sundt, det tager også lang tid at gendanne det fra en backup, hvad skal jeg gøre? Vi forstår, at elastik i vores tilfælde bruges til søgning. Hvordan sælger vores netbutik? Vi går til marketingfolk og spørger, hvor folk kommer fra. De svarer: "90 % fra Yandex Market kommer direkte til produktkortet." Og enten køber de det, eller også gør de det ikke. Derfor er søgning nødvendig af 10 % af brugerne. Og at holde elastisk replikering, især mellem forskellige datacentre i forskellige zoner, har virkelig mange nuancer. Hvilken udgang? Vi tager elastik fra et reserveret sted og gør intet med det. Hvis sagen trækker ud, vil vi nok tage den op en dag, men det er ikke sikkert. Faktisk er konklusionen den samme, plus eller minus: vi, igen, reserverer ikke tjenester, der ikke påvirker penge. For at gøre diagrammet enklere.
Eksempel nummer fire, endnu sværere
Integrator: sælge blomster, ringe til en taxa, sælge varer, generelt, hvad som helst. En seriøs ting, der fungerer 24/7 for et stort antal brugere. Med en fuldgyldig interessant stack, hvor der er interessante baser, løsninger, høj belastning, og vigtigst af alt, det gør ondt at ligge ned i mere end 5 minutter. Ikke kun og ikke så meget fordi folk ikke vil købe, men fordi folk vil se, at denne ting ikke virker, vil de blive sure og måske slet ikke komme tilbage.
OKAY. Fem minutter. Hvad skal vi gøre ved dette? I dette tilfælde bruger vi, ligesom voksne, alle pengene til at bygge en rigtig backup-side med replikering af alt, og måske endda automatisere skift til denne side så meget som muligt. Og udover dette skal du huske at gøre en vigtig ting: faktisk skrive skiftebestemmelserne. Reglerne, selvom du har alt automatiseret, kan være meget enkle. Fra serien "kør sådan og sådan et ansible script", "klik på sådan og sådan et afkrydsningsfelt i rute 53" og så videre - men det må være en form for præcis liste over handlinger.
Og alt virker klart. Skifte replikering er en triviel opgave, eller det vil skifte sig selv. Omskrivning af et domænenavn i DNS er fra samme serie. Problemet er, at når sådan et projekt mislykkes, begynder panikken, og selv de stærkeste, skæggede administratorer kan være modtagelige for det. Uden klare instruktioner "åbn terminalen, kom her, vores servers adresse er stadig sådan," er det svært at overholde den 5-minutters tidsfrist, der er tildelt for genoplivning. Nå, plus, når vi bruger disse regler, er det nemt at registrere nogle ændringer i infrastrukturen, for eksempel, og ændre reglerne derefter.
Nå, hvis reservationssystemet er meget komplekst, og vi på et tidspunkt lavede en fejl, så kan vi ødelægge vores backup-side, og derudover gøre dataene til et græskar på begge sider - det vil være fuldstændig trist.
Eksempel nummer fem, komplet hardcore
En international tjeneste med hundredvis af millioner af brugere over hele verden. Alle de tidszoner der er, høj belastning ved maksimal hastighed, du kan slet ikke ligge ned. Et minut - og det bliver trist. Hvad skal man gøre? Reserver igen ifølge det fulde program. Vi gjorde alt, hvad jeg talte om i det forrige eksempel, og lidt mere. En ideel verden, og vores infrastruktur er i overensstemmelse med alle koncepter i IaaC devops. Det vil sige, at alt er i git, og du trykker bare på knappen.
Hvad mangler der? En - øvelser. Det er umuligt uden dem. Det ser ud til, at alt er perfekt hos os, vi har generelt styr på det hele. Vi trykker på knappen, alt sker. Selvom det er tilfældet - og vi forstår, at det ikke sker på denne måde - interagerer vores system med nogle andre systemer. Dette er for eksempel dns fra rute 53, s3 storage, integration med nogle api. Vi vil ikke være i stand til at forudse alt i dette spekulative eksperiment. Og indtil vi rent faktisk trækker på kontakten, ved vi ikke, om det vil virke eller ej.
Det er nok alt. Vær ikke doven eller overdriv det. Og må oppetiden være med dig!
Kilde: www.habr.com