Naglalaman ang artikulong ito ng ilang karaniwang pattern upang matulungan ang mga inhinyero na magtrabaho sa malalaking serbisyo na ina-access ng milyun-milyong user.
Sa karanasan ng may-akda, ito ay hindi isang kumpletong listahan, ngunit sa katunayan epektibo payo. Kaya, magsimula tayo.
Isinalin nang may suporta .
Antas ng pagpasok
Ang mga hakbang na nakalista sa ibaba ay medyo simple na ipatupad ngunit may mataas na epekto. Kung hindi mo pa nasubukan ang mga ito dati, magugulat ka sa mga makabuluhang pagpapabuti.
Imprastraktura bilang code
Ang unang bahagi ng payo ay ang pagpapatupad ng imprastraktura bilang code. Nangangahulugan ito na dapat ay mayroon kang isang programmatic na paraan upang i-deploy ang buong imprastraktura. Mukhang kumplikado, ngunit talagang pinag-uusapan natin ang sumusunod na code:
Pag-deploy ng 100 virtual machine
- sa Ubuntu
- 2 GB RAM bawat isa
- magkakaroon sila ng sumusunod na code
- gamit ang mga parameter na ito
Maaari mong subaybayan ang mga pagbabago sa iyong imprastraktura at mabilis na bumalik sa mga ito gamit ang kontrol ng bersyon.
Sinasabi ng modernista sa akin na maaari mong gamitin ang Kubernetes/Docker upang gawin ang lahat ng nasa itaas, at tama siya.
Bilang karagdagan, maaari kang magbigay ng automation gamit ang Chef, Puppet o Terraform.
Patuloy na Pagsasama at Paghahatid
Upang lumikha ng isang scalable na serbisyo, mahalagang magkaroon ng build at test pipeline para sa bawat pull request. Kahit na ang pagsubok ay napaka-simple, ito ay hindi bababa sa matiyak na ang code na iyong i-deploy ay pinagsama-sama.
Sa bawat oras sa yugtong ito sasagutin mo ang tanong: ang aking pagpupulong ay mag-compile at makapasa sa mga pagsusulit, wasto ba ito? Ito ay maaaring mukhang isang mababang bar, ngunit nalulutas nito ang maraming problema.
Wala nang mas maganda kaysa makita ang mga garapata na ito
Para sa teknolohiyang ito maaari mong suriin ang Github, CircleCI o Jenkins.
Mga Balanse ng Load
Kaya, gusto naming magpatakbo ng load balancer upang i-redirect ang trapiko at matiyak ang pantay na pagkarga sa lahat ng node o magpapatuloy ang serbisyo kung sakaling mabigo:
Ang isang load balancer ay karaniwang gumagawa ng magandang trabaho sa pamamahagi ng trapiko. Ang pinakamahusay na kasanayan ay ang labis na balanse upang wala kang isang punto ng pagkabigo.
Karaniwan, ang mga load balancer ay naka-configure sa cloud na iyong ginagamit.
RayID, correlation ID o UUID para sa mga kahilingan
Nakaranas ka na ba ng error sa application na may mensaheng tulad nito: "May nangyaring mali. I-save ang id na ito at ipadala ito sa aming team ng suporta"?
Ang isang natatanging identifier, correlation ID, RayID, o alinman sa mga variation, ay isang natatanging identifier na nagbibigay-daan sa iyong subaybayan ang isang kahilingan sa buong lifecycle nito. Binibigyang-daan ka nitong subaybayan ang buong path ng kahilingan sa mga log.
Gumagawa ng kahilingan ang user sa system A, pagkatapos ay nakikipag-ugnayan ang A kay B, na nakikipag-ugnayan kay C, nag-iimbak nito sa X, at pagkatapos ay ibabalik ang kahilingan sa A
Kung malayo kang kumonekta sa mga virtual machine at susubukan mong subaybayan ang landas ng kahilingan (at manu-manong iugnay kung aling mga tawag ang ginagawa), mababaliw ka. Ang pagkakaroon ng natatanging identifier ay nagpapadali sa buhay. Ito ay isa sa mga pinakasimpleng bagay na maaari mong gawin upang makatipid ng oras habang lumalaki ang iyong serbisyo.
Average na antas
Ang payo dito ay mas kumplikado kaysa sa mga nauna, ngunit ang mga tamang tool ay nagpapadali sa gawain, na nagbibigay ng return on investment kahit para sa mga maliliit at katamtamang laki ng mga kumpanya.
Sentralisadong pag-log
Binabati kita! Nag-deploy ka ng 100 virtual machine. Kinabukasan, dumating ang CEO at nagreklamo tungkol sa isang error na natanggap niya habang sinusubukan ang serbisyo. Iniuulat nito ang kaukulang ID na napag-usapan namin sa itaas, ngunit kakailanganin mong tingnan ang mga log ng 100 machine upang mahanap ang naging sanhi ng pag-crash. At kailangan itong mahanap bago ang pagtatanghal bukas.
Bagama't ito ay parang isang masayang pakikipagsapalaran, pinakamahusay na tiyaking mayroon kang kakayahang hanapin ang lahat ng mga magazine sa isang lugar. Nalutas ko ang problema sa pagsentralisa ng mga log gamit ang built-in na functionality ng ELK stack: sinusuportahan nito ang mahahanap na koleksyon ng log. Ito ay talagang makakatulong sa paglutas ng problema sa paghahanap ng isang tiyak na journal. Bilang bonus, maaari kang lumikha ng mga chart at iba pang nakakatuwang bagay tulad niyan.
ELK stack functionality
Mga ahente sa pagsubaybay
Ngayon na ang iyong serbisyo ay gumagana at tumatakbo, kailangan mong tiyakin na ito ay tumatakbo nang maayos. Ang pinakamahusay na paraan upang gawin ito ay ang magpatakbo ng ilan mga ahente, na gumagana nang magkatulad at suriin kung gumagana ito at ginagawa ang mga pangunahing operasyon.
Sa puntong ito suriin mo iyon maganda ang pakiramdam at gumagana nang maayos ang tumatakbong build.
Para sa maliliit hanggang katamtamang laki ng mga proyekto, inirerekomenda ko ang Postman para sa pagsubaybay at pagdodokumento ng mga API. Ngunit sa pangkalahatan, gusto mo lang tiyakin na mayroon kang paraan upang malaman kung kailan nagkaroon ng outage at maabisuhan sa isang napapanahong paraan.
Autoscaling depende sa load
Ito ay napaka-simple. Kung mayroon kang mga kahilingan sa VM servicing at ito ay papalapit na sa 80% na paggamit ng memory, maaari mong dagdagan ang mga mapagkukunan nito o magdagdag ng higit pang mga VM sa cluster. Ang awtomatikong pagpapatupad ng mga operasyong ito ay mahusay para sa nababanat na mga pagbabago sa kapangyarihan sa ilalim ng pagkarga. Ngunit dapat kang palaging mag-ingat tungkol sa kung gaano karaming pera ang iyong ginagastos at magtakda ng mga makatwirang limitasyon.
Sa karamihan ng mga serbisyo sa cloud, maaari mo itong i-configure sa awtomatikong pag-scale gamit ang higit pang mga server o mas malakas na mga server.
Sistema ng eksperimento
Ang isang mahusay na paraan upang ligtas na ilunsad ang mga update ay ang makapagsubok ng isang bagay para sa 1% ng mga user sa loob ng isang oras. Siyempre, nakita mo ang gayong mga mekanismo sa pagkilos. Halimbawa, ipinapakita ng Facebook ang mga bahagi ng audience ng ibang kulay o binabago ang laki ng font upang makita kung paano nakikita ng mga user ang mga pagbabago. Ito ay tinatawag na A/B testing.
Kahit na ang pagpapalabas ng bagong feature ay maaaring simulan bilang isang eksperimento at pagkatapos ay matukoy kung paano ito ilalabas. Makukuha mo rin ang kakayahang "tandaan" o baguhin ang configuration sa mabilisang batay sa function na nagdudulot ng pagkasira sa iyong serbisyo.
Advanced na antas
Narito ang mga tip na medyo mahirap ipatupad. Malamang na kakailanganin mo ng kaunti pang mga mapagkukunan, kaya ang isang maliit o katamtamang laki ng kumpanya ay mahihirapang pamahalaan ito.
Mga asul-berde na deployment
Ito ang tinatawag kong "Erlang" na paraan ng paglalahad. Ang Erlang ay naging malawakang ginamit nang lumitaw ang mga kumpanya ng telepono. Nagsimulang gumamit ng mga softswitch para iruta ang mga tawag sa telepono. Ang pangunahing layunin ng software sa mga switch na ito ay hindi mag-drop ng mga tawag sa panahon ng pag-upgrade ng system. Ang Erlang ay may magandang paraan ng paglo-load ng bagong module nang hindi na-crash ang nauna.
Ang hakbang na ito ay depende sa pagkakaroon ng isang load balancer. Isipin natin na mayroon kang bersyon N ng iyong software, at pagkatapos ay gusto mong i-deploy ang bersyong N+1.
Mo kaya namin itigil lang ang serbisyo at ilunsad ang susunod na bersyon sa oras na gumagana para sa iyong mga user at makakuha ng ilang downtime. Ngunit ipagpalagay na mayroon ka talaga mahigpit na kondisyon ng SLA. Kaya, ang SLA 99,99% ay nangangahulugan na maaari kang mag-offline lamang ng 52 minuto bawat taon.
Kung gusto mo talagang makamit ang mga naturang indicator, kailangan mo ng dalawang deployment nang sabay-sabay:
- ang isa na ngayon (N);
- susunod na bersyon (N+1).
Sasabihin mo sa load balancer na mag-redirect ng porsyento ng trapiko sa bagong bersyon (N+1) habang aktibong sinusubaybayan mo ang mga regression.
Narito mayroon kaming berdeng N deployment na gumagana nang maayos. Sinusubukan naming lumipat sa susunod na bersyon ng deployment na ito
Una, nagpapadala kami ng napakaliit na pagsubok upang makita kung gumagana ang aming N+1 deployment sa kaunting trapiko:
Sa wakas, mayroon kaming isang hanay ng mga automated na pagsusuri na sa kalaunan ay pinapatakbo namin hanggang sa makumpleto ang aming deployment. kung ikaw very very mag-ingat, maaari mo ring i-save ang iyong N deployment magpakailanman para sa isang mabilis na rollback kung sakaling magkaroon ng masamang regression:
Kung gusto mong pumunta sa mas advanced na antas, hayaang awtomatikong tumakbo ang lahat sa blue-green na deployment.
Pagtukoy ng anomalya at awtomatikong pagpapagaan
Dahil mayroon kang sentralisadong pag-log at mahusay na koleksyon ng log, maaari ka nang magtakda ng mas matataas na layunin. Halimbawa, maagap na mahulaan ang mga pagkabigo. Ang mga function ay sinusubaybayan sa mga monitor at sa mga log at iba't ibang mga diagram ay binuo - at maaari mong mahulaan nang maaga kung ano ang magiging mali:
Kapag natukoy ang mga anomalya, sisimulan mong suriin ang ilan sa mga pahiwatig na ibinibigay ng serbisyo. Halimbawa, ang pagtaas ng pag-load ng CPU ay maaaring magpahiwatig na ang isang hard drive ay nabigo, habang ang pagtaas ng mga kahilingan ay maaaring magpahiwatig na kailangan mong palakihin. Ang ganitong uri ng istatistikal na data ay nagbibigay-daan sa iyong gawing aktibo ang serbisyo.
Gamit ang mga insight na ito, maaari mong sukatin sa anumang dimensyon at proactive at reaktibong baguhin ang mga katangian ng mga machine, database, koneksyon at iba pang mapagkukunan.
Yun lang!
Ang listahan ng mga priyoridad na ito ay magliligtas sa iyo ng maraming problema kung magtataas ka ng serbisyo sa cloud.
Inaanyayahan ng may-akda ng orihinal na artikulo ang mga mambabasa na iwanan ang kanilang mga komento at gumawa ng mga pagbabago. Ang artikulo ay ipinamahagi bilang open source, pull request ng may-akda .
Ano pa ang mababasa sa paksa:
Pinagmulan: www.habr.com