Ĉi tiu artikolo enhavas kelkajn komunajn ŝablonojn por helpi inĝenierojn labori kun grandskalaj servoj alireblaj de milionoj da uzantoj.
Laŭ la sperto de la aŭtoro, ĉi tio ne estas ĝisfunda listo, sed ja efika konsilo. Do, ni komencu.
Tradukita kun subteno .
Unua nivelo
La mezuroj listigitaj malsupre estas relative simplaj por efektivigi sed havas altan efikon. Se vi ne provis ilin antaŭe, vi estos surprizita pri la gravaj plibonigoj.
Infrastrukturo kiel kodo
La unua parto de la konsilo estas efektivigi infrastrukturon kiel kodon. Ĉi tio signifas, ke vi devas havi programan manieron disfaldi la tutan infrastrukturon. Ĝi sonas komplika, sed ni fakte parolas pri la sekva kodo:
Deplojo de 100 virtualaj maŝinoj
- kun Ubuntu
- 2 GB RAM ĉiu
- ili havos la jenan kodon
- kun ĉi tiuj parametroj
Vi povas spuri ŝanĝojn al via infrastrukturo kaj rapide reveni al ili per versio-kontrolo.
La modernisto en mi diras, ke vi povas uzi Kubernetes/Docker por fari ĉion supre, kaj li pravas.
Krome, vi povas provizi aŭtomatigon per Chef, Puppet aŭ Terraform.
Kontinua Integriĝo kaj Livero
Por krei skaleblan servon, gravas havi konstruan kaj testan dukton por ĉiu tira peto. Eĉ se la testo estas tre simpla, ĝi almenaŭ certigos, ke la kodo, kiun vi deplojas, kompilos.
Ĉiufoje en ĉi tiu etapo vi respondas la demandon: ĉu mia asembleo kompilos kaj trapasos provojn, ĉu ĝi validas? Ĉi tio povas ŝajni malalta trinkejo, sed ĝi solvas multajn problemojn.
Estas nenio pli bela ol vidi ĉi tiujn iksodojn
Por ĉi tiu teknologio vi povas taksi Github, CircleCI aŭ Jenkins.
Ŝarĝbalanciloj
Do, ni volas ruli ŝarĝbalancilon por redirekti trafikon kaj certigi egalan ŝarĝon sur ĉiuj nodoj aŭ la servo daŭras en kazo de fiasko:
Ŝarĝbalancilo kutime faras bonan laboron distribui trafikon. La plej bona praktiko estas trobalanci por ke vi ne havu ununuran punkton de fiasko.
Tipe, ŝarĝbalanciloj estas agorditaj en la nubo, kiun vi uzas.
RayID, korelacia ID aŭ UUID por petoj
Ĉu vi iam renkontis aplikan eraron kun mesaĝo tia: "Io misfunkciis. Konservu ĉi tiun identigilon kaj sendu ĝin al nia subtena teamo"?
Unika identigilo, korelacia ID, RayID aŭ iu ajn el la varioj, estas unika identigilo, kiu permesas vin spuri peton dum ĝia vivociklo. Ĉi tio permesas vin spuri la tutan peton en la protokoloj.
La uzanto faras peton al sistemo A, tiam A kontaktas B, kiu kontaktas C, konservas ĝin en X, kaj tiam la peto estas resendita al A.
Se vi malproksime konektus al virtualaj maŝinoj kaj provus spuri la petan vojon (kaj permane korelacii kiuj vokoj estas faritaj), vi freneziĝus. Havi unikan identigilon faciligas la vivon. Ĉi tio estas unu el la plej simplaj aferoj, kiujn vi povas fari por ŝpari tempon dum via servo kreskas.
Intermeza nivelo
La konsiloj ĉi tie estas pli kompleksaj ol la antaŭaj, sed la ĝustaj iloj faciligas la taskon, provizante profiton de investo eĉ por malgrandaj kaj mezgrandaj kompanioj.
Alcentrigita arbohakado
Gratulon! Vi deplojis 100 virtualajn maŝinojn. La sekvan tagon, la ĉefoficisto venas kaj plendas pri eraro, kiun li ricevis dum testado de la servo. Ĝi raportas la respondan identigilon pri kiu ni parolis supre, sed vi devos trarigardi la protokolojn de 100 maŝinoj por trovi tiun, kiu kaŭzis la kraŝon. Kaj ĝi devas esti trovita antaŭ la morgaŭa prezento.
Kvankam ĉi tio sonas kiel amuza aventuro, estas plej bone certigi, ke vi havas la kapablon serĉi ĉiujn revuojn en unu loko. Mi solvis la problemon de centralizo de protokoloj uzante la enkonstruitan funkcion de la ELK-stako: ĝi subtenas serĉeblan protokolon. Ĉi tio vere helpos solvi la problemon trovi specifan revuon. Kiel gratifiko, vi povas krei leterojn kaj aliajn amuzajn aferojn.
ELK-stako-funkcieco
Monitoraj agentoj
Nun kiam via servo funkcias, vi devas certigi, ke ĝi funkcias glate. La plej bona maniero fari tion estas kuri plurajn agentoj, kiuj funkcias paralele kaj kontrolas ke ĝi funkcias kaj bazaj operacioj estas faritaj.
Je ĉi tiu punkto vi kontrolas tion la kuranta konstruo sentas sin bone kaj funkcias bone.
Por malgrandaj ĝis mezgrandaj projektoj, mi rekomendas Postman por monitorado kaj dokumentado de API-oj. Sed ĝenerale, vi nur volas certigi, ke vi havas manieron scii kiam okazis malfunkcio kaj esti sciigita ĝustatempe.
Aŭtoskalo depende de ŝarĝo
Ĝi estas tre simpla. Se vi havas petojn pri servo de VM kaj ĝi alproksimiĝas al 80% da uzado de memoro, vi povas aŭ pliigi ĝiajn rimedojn aŭ aldoni pli da VM-oj al la areto. Aŭtomata plenumo de ĉi tiuj operacioj estas bonega por elastaj potencoŝanĝoj sub ŝarĝo. Sed vi ĉiam zorgu pri kiom da mono vi elspezas kaj fiksu raciajn limojn.
Kun la plej multaj nubaj servoj, vi povas agordi ĝin por aŭtomata skalo uzante pli da serviloj aŭ pli potencaj serviloj.
Eksperimenta sistemo
Bona maniero por sekure lanĉi ĝisdatigojn estas povi testi ion por 1% de uzantoj dum horo. Vi kompreneble vidis tiajn mekanismojn en agado. Ekzemple, Facebook montras al partoj de la spektantaro malsaman koloron aŭ ŝanĝas la tiparon por vidi kiel uzantoj perceptas la ŝanĝojn. Ĉi tio nomiĝas A/B-testado.
Eĉ liberigi novan funkcion povas esti komencita kiel eksperimento kaj poste determini kiel liberigi ĝin. Vi ankaŭ ricevas la kapablon "memori" aŭ ŝanĝi la agordon sur la flugo surbaze de la funkcio, kiu kaŭzas degradadon en via servo.
Altnivela nivelo
Jen konsiletoj, kiuj estas sufiĉe malfacile efektivigeblaj. Vi verŝajne bezonos iom pli da rimedoj, do malgranda aŭ mezgranda kompanio malfacile administros ĉi tion.
Bluverdaj deplojoj
Jen kion mi nomas la "Erlang" maniero disvolviĝi. Erlang iĝis vaste uzita kiam telefonkompanioj aperis. Softŝaltiloj komencis esti uzitaj por direkti telefonvokojn. La ĉefa celo de la programaro sur ĉi tiuj ŝaltiloj estis ne faligi vokojn dum sistemaj ĝisdatigoj. Erlang havas belan manieron ŝargi novan modulon sen kraŝi la antaŭan.
Ĉi tiu paŝo dependas de la ĉeesto de ŝarĝbalancilo. Ni imagu, ke vi havas version N de via programaro, kaj tiam vi volas deploji version N+1.
Vi ni povus simple ĉesigu la servon kaj lanĉu la sekvan version samtempe, kiu funkcias por viaj uzantoj kaj ricevu iom da malfunkcio. Sed supozu, ke vi havas vere striktaj SLA-kondiĉoj. Do, SLA 99,99% signifas, ke vi povas eksterrete nur je 52 minutoj jare.
Se vi vere volas atingi tiajn indikilojn, vi bezonas du deplojojn samtempe:
- tiu, kiu estas nun (N);
- sekva versio (N+1).
Vi diras al la ŝarĝbalancilo redirekti procenton de trafiko al la nova versio (N+1) dum vi aktive kontrolas por regresoj.
Ĉi tie ni havas verdan N-deplojon, kiu funkcias bone. Ni provas moviĝi al la sekva versio de ĉi tiu deplojo
Unue ni sendas vere malgrandan teston por vidi ĉu nia N+1-deplojo funkcias kun malgranda trafiko:
Fine, ni havas aron da aŭtomataj kontroloj, kiujn ni eventuale plenumas ĝis nia disfaldo finiĝos. Se vi tre tre zorgeme, vi ankaŭ povas konservi vian N-deplojon por ĉiam por rapida retrovoko en kazo de malbona regreso:
Se vi volas iri al eĉ pli altnivela nivelo, lasu ĉion en la bluverda deplojo funkcii aŭtomate.
Detekto de anomalioj kaj aŭtomata mildigo
Konsiderante, ke vi centralizis protokolon kaj bonan registrokolekton, vi jam povas agordi pli altajn celojn. Ekzemple, proaktive antaŭdiri fiaskojn. Funkcioj estas spuritaj sur ekranoj kaj en protokoloj kaj diversaj diagramoj estas konstruitaj - kaj vi povas antaŭdiri kio misfunkcios:
Post kiam anomalioj estas detektitaj, vi komencas ekzameni kelkajn el la indicoj, kiujn la servo provizas. Ekzemple, piko en CPU-ŝarĝo povas indiki ke malmola disko malsukcesas, dum piko en petoj povas indiki ke vi devas pligrandigi. Ĉi tiu speco de statistikaj datumoj permesas al vi fari la servon proaktiva.
Kun ĉi tiuj komprenoj, vi povas grimpi en ajna dimensio kaj proaktive kaj reaktive ŝanĝi la karakterizaĵojn de maŝinoj, datumbazoj, konektoj kaj aliaj rimedoj.
Tio estas ĉio!
Ĉi tiu listo de prioritatoj savos al vi multajn problemojn se vi altigas nuban servon.
La aŭtoro de la originala artikolo invitas legantojn lasi siajn komentojn kaj fari ŝanĝojn. La artikolo estas distribuita kiel malferma fonto, tirpetoj de la aŭtoro .
Kion alian legi pri la temo:
fonto: www.habr.com