Festat përfunduan, dhe ne kthehemi me postimin tonë të dytë nga seria mbi Istio Service Mesh.
Tema e sotme është Circuit Breaker, që në shqip do të thotë "ndërprerës elektrik"; në folken e zakonshme – "automati i mbrojtjes". Por në Istio, ky automat ndalon jo një qark të shkurtuar apo të ngarkuar, por konteinerë të prishur.
Si duhet të funksionojë në mënyrë ideale
Kur mikroshërbimet menaxhohen nga Kubernetes, për shembull, në kuadër të platformës OpenShift, ato automatizohen në varësi të ngarkesës. Duke qenë se mikroshërbimet punojnë në pod, në një pikë fundore mund të ketë disa ekzemplarë të një mikroshërbimi të kontenierizuar, dhe Kubernetes do të rregullojë kërkesat dhe do të balancojë ngarkesën mes tyre. Dhe – në mënyrë ideale – të gjitha këto duhet të funksionojnë perfekt.
Ne e dimë se mikroshërbimet janë të vogla dhe efemere. Efemërsia, që këtu do të thotë thjeshtësinë e lindjes dhe zhdukjes, shpesh nënvlerësohet. Lindja dhe vdekja e një ekzemplari të mikroshërbimit në pod është diçka e pritshme, OpenShift dhe Kubernetes e bëjnë këtë mjaft mirë, dhe gjithçka funksionon në mënyrë të shkëlqyer – por përsëri, kjo është në teori.
Si funksionon në të vërtetë
Tani imagjinoni se një ekzemplar i caktuar i mikroshërbimit, pra një kontenier, ka shkuar në gjendje të papërshtatshme: ose nuk përgjigjet (gabimi 503), ose – që është më keq – reagon, por shumë ngadalë. Në fjalë të tjera, ai ka probleme ose nuk përgjigjet në kërkesa, por nuk përjashtohet automatikisht nga grupi. Çfarë duhet të bëjmë në këtë rast? Të përsërisim përpjekjen? Ta heqim nga skema e rrugëzim? Dhe çfarë do të thotë "shumë ngadalë" – sa është kjo në numra, dhe kush i përcakton? Ndoshta thjesht t'i japim një pushim dhe të provoni përsëri më vonë? Po, sa vonë?
Çfarë është Pool Ejection në Istio
Dhe këtu ndihmon Istio me automatet e tij të mbrojtjes Circuit Breaker, të cilat përkohësisht largojnë konteinerët e prishur nga grupi i burimeve të rrugëzimit dhe balancimit të ngarkesës, duke realizuar procedurën e Pool Ejection.
Duke përdorur strategjinë e zbulimit të devijimeve (outlier detection), Istio detekton pod-et anormale që janë jashtë normës dhe i heq ato nga grupi i burimeve për një kohë të caktuar, që quhet "dritarja e gjumit" (sleep window).
Për të treguar si funksionon kjo në Kubernetes në platformën OpenShift, fillojmë me një kapje ekran të mikroshërbimeve që punojnë normalisht nga shembulli në depo . Këtu kemi dy pod-e, v1 dhe v2, në secilin prej të cilëve punon një kontenier. Kur rregullat e rrugëzimit Istio nuk përdoren, Kubernetes si parazgjedhje aplikon rrugëzim ciklik me balancim të barabartë:
Përgatitemi për dështim
Para se të bëjmë Pool Ejection, duhet të krijojmë një rregull rrugëzimi Istio. Le të themi se duam të shpërndajmë kërkesat mes pod-eve në një raport 50/50. Për më tepër, do të rrisim numrin e konteinerëve v2 nga një në dy, kështu:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
Tani caktojmë një rregull rrugëzimi, që trafiku të shpërndahet mes pod-eve në një raport 50/50.
Ja si duket rezultati i punës së këtij rregulli:
Mund të flitet se në këtë skrin nuk është 50/50, por 14:9, por me kalimin e kohës situata do të rregullohet.
Shkaktojmë dështim
Tani do ta çojmë jashtë funksioni një nga dy konteinerët v2, që të kemi një konteiner të shëndoshë v1, një konteiner të shëndoshë v2 dhe një konteiner të prishur v2:
Rregullojmë dështimin
Pra, kemi një konteiner të prishur, dhe ka ardhur koha për Pool Ejection. Me një konfigurim shumë të thjeshtë, do ta përjashtojmë këtë konteiner të prishur nga çdo skemë rrugëzimi për 15 sekonda me shpresën se ai do të kthehet në një gjendje të shëndoshë (ose do të rinisin, ose do të rikthejë performancën). Kështu duket ky konfigurim dhe rezultatet e tij:
Siç duket, konteineri i prishur v2 nuk përdoret më për rrugëzimin e kërkesave, pasi u hoq nga grupi. Por pas 15 sekondash, ai do të kthehet automatikisht në grup. Në fakt, sapo treguam se si funksionon Pool Ejection.
Fillojmë të ndërtojmë arkitekturën
Pool Ejection në kombinim me mundësitë e monitorimit të Istio lejon të fillojmë ndërtimin e një kornize për zëvendësimin automatik të konteinerëve të prishur, për të minimizuar, madje edhe për të eliminuar, ndalesat dhe dështimet.
NASA ka një slogan të njohur – Dështimi Nuk Është Një Opcioni, autori i të cilit është kreu i fluturimeve . Në rusisht mund të përkthehet si "Dështimi nuk është një mundësi", dhe thelbi këtu është se gjithçka mund të bëhet funksionale duke pasur mjaft vullnet. Megjithatë, në jetën reale, dështimet nuk ndodhin vetëm, ato janë të pashmangshme, kudo dhe në çdo gjë. Si mund t'i përballojmë ato në rastin e mikrosherbimeve? Sipas mendimit tonë, është më mirë të mbështetemi në mundësitë e kontejnerëve, , , dhe .
Istio, siç e kemi përmendur më sipër, implementon një koncept të njohur në botën fizike të çaktivizuesve automatikë. Ashtu siç një çaktivizues elektrik fik një pjesë problematike të qarkut, ashtu edhe CuCircuit Breaker në Istio ndërpret lidhjen mes rrjedhës së kërkesave dhe kontejnerit problematik, kur diçka nuk është në rregull me pikën finale, për shembull, kur serveri ka rënë ose ka filluar të ngadalësohet.
Në rastin e dytë, problemet vetëm sa shtohen, sepse ngadalësimi i një kontejneri jo vetëm që shkakton një kaskadë të vonesave në shërbimet që i drejtohen, duke rezultuar kështu në uljen e produktivitetit të sistemit në përgjithësi, por gjithashtu krijon kërkesa të përsëritura për një shërbim që tashmë po punon ngadalë, çka vetëm e përkeqëson situatën.
Circuit Breaker në teori
Circuit Breaker është një proxy që kontrollon rrjedhën e kërkesave në pikën finale. Kur kjo pikë ndalon së funksionuari ose – sipas disa parametrave të caktuar – fillon të ngadalësohet, proxy ndërpret lidhjen me kontejnerin. Trafiku pas kësaj drejtohet në kontejnerë të tjerë, thjesht për shkak të balancimit të ngarkesës. Lidhja mbetet e hapur (open) për një periudhë të caktuar kohe, thoni, dy minuta, dhe pastaj konsiderohet gjysmë e hapur (half-open). Përpjekja për të dërguar kërkesën e ardhshme përcakton gjendjen e mëtejshme të lidhjes. Nëse gjithçka është në rregull me shërbimin, lidhja rikthehet në gjendjen funksionale dhe bëhet sërish e mbyllur (closed). Por nëse me shërbimin vazhdon të ketë probleme, lidhja ndërpritet dhe rikthehet në periudhën e pritjes. Këtu është një diagram i thjeshtuar i ndryshimeve të gjendjeve të Circuit Breaker:
Është e rëndësishme të theksohet se e gjithë kjo ndodh në nivelin, për thënë, të arkitekturës së sistemit. Prandaj, në një moment, do t'ju duhet t'i mësoni aplikacionet tuaja të punojnë me Circuit Breaker, për shembull, të ofrojnë një vlerë të paracaktuar si përgjigje ose, nëse është e mundur, të injorojnë ekzistencën e shërbimit. Për këtë përdoret modeli bulkhead, por ai kalon përtej kësaj arti.
Circuit Breaker në praktikë
Si shembull, ne do të nisim në OpenShift dy versione të mikrosherbimit tonë të rekomandimeve. Versioni 1 do të funksionojë normalisht, ndërsa në v2 do të integrojmë një vonesë për të simuluar ngadalësime në server. Për të parë rezultatet përdoret mjeti :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
E gjithë kjo duket se funksionon, por me ç'mënyrë? Në pamje të parë kemi një disponueshmëri 100%, por shikoni më afër – koha maksimale e transaksionit arrin deri në 12 sekonda. Kjo është një ngushticë e dukshme dhe duhet të zgjerohet.
Për këtë, ne do të përjashtojmë thirrjet në kontejnerët e ngadalshëm përmes Istio. Ja si duket konfigurimi përkatës me përdorimin e Circuit Breaker:
Rreshti i fundit me parametrin httpMaxRequestsPerConnection sinjalizon se lidhja duhet të ndërpritet në përpjekjen për të krijuar një lidhje – një të dytë – përveç asaj që tashmë është duke u bërë. Duke qenë se kontejneri ynë simuluar shërbimin e ngadaltë, situata të tilla do të ndodhin herë pas here, dhe atëherë Istio do të kthejë një gabim 503, ndërsa ja çfarë do të tregojë siege:
Në rregull, ne kemi Circuit Breaker, çfarë më pas?
Pra, ne kemi implementuar çaktivizimin automatik, pa ndikuar në kodin burimor të vetë shërbimeve. Duke përdorur Circuit Breaker dhe procedurën e përmendur më sipër të Pool Ejection, ne mund të heqim nga pool-i i burimeve kontejnerët ngadalësues derisa ata të rikthehen në norma dhe të kontrollojmë gjendjen e tyre me një frekuencë të caktuar – në shembullin tonë, kjo është dy minuta (parametri sleepWindow).
Vini re se aftësia e aplikacionit për t'u përgjigjur ndaj gabimit 503 përsëri vendoset në nivelin e kodit të tij burimor. Ekzistojnë shumë strategji për të punuar me Circuit Breaker, të cilat përdoren varësisht nga situata.
Në postimin e ardhshëm: do të flasim për gjurmimin dhe monitorimin, të cilat tashmë janë të integruara ose lehtë mund të shtohen në Istio, si dhe sesi të futni gabime në sistem me qëllim.
Burimi: habr.com
