Blue-Green և Canary ալյումինե
(Բաժին ՝ Ճարտարապետություն և Արձանագրություններ)
1) Ինչո՞ ւ պետք է «ապահով փորագրություններ»։
Ժամանակակից համակարգերում թողարկումը ոչ միայն կոդի առաքումն է, այլ նաև վաճառքի կառավարվող փորձը, մենք միաժամանակ նվազեցնում ենք ռիսկը (չենք կոտրում օգտագործողներին) և նվազեցնում ենք հետադարձ կապի ժամանակը (արագ տեսնում ենք էֆեկտը)։ Երկու դասական ռազմավարություններ 'Blue-Green և Canary, լուծում են դա տարբեր կերպ, բայց ընդհանուր նպատակով' զրոյական դաունտայմ, արագ արձագանք, SLO-ի դիտարկումը։
2) Հիմնական սահմանումները
Blue-Green
Մենք պահում ենք երկու ամբողջական պատճեններ պրոդ-միջավայրում 'ակտիվ (Blue) ծառայում է ստանդարտ, պասիվ (Green) պատրաստում է նոր տարբերակը։ Փոխակերպումը ատոմային (switch/flip) է հավասարակշռիչի/ուղղիչի մակարդակում։ Եթե ավելի վատ է դարձել, անմիջապես վերադառնում ենք դեպի Blue։
Canary
Մենք հավաքում ենք այն մասերը, որոնք առաջին հերթին փոքր տոկոսն են (օրինակ ՝ 1-5%), մենք տեսնում ենք մետրեր/SLO, ապա մաքսանենգորեն ավելացնում ենք մասնաբաժինը (10% - 25% - 50% - 100%)։ Դեգրադացիայի դեպքում 'արձագանք կամ կանգառ նախորդ կայուն վրա։
3) Ե՞ րբ է ավելի լավ մոտեցումը
Blue-Green-ը ընտրում ենք, եթե
Անհրաժեշտ է ակնթարթային արձագանք առանց բարդ մանևրերի։
Ճարտարապետությունը/բյուջեթը թույլ է տալիս կրկնակի ենթակառուցվածքային կրկնօրինակումը։
Մենք ուզում ենք անցկացնել մեծ ստանդարտներ կամ նորարարություններ պլատֆորմի (OS/JDK/rantaim) մեկուսացված։
Հավելվածը/փուլերը զգայուն են աստիճանական «խառը» վիճակի վրա։
Canary, մենք ընտրում ենք, եթե
Պետք է նվազագույնի հասցնել blast radius-ը և տեսնել վարքագիծը օգտագործողների մասնաբաժնի վրա։
Առյուծների բարձր հաճախականությունը, առաջադիմական առաքումը որպես նորմ։
Կան տեսողական դիտարկումներ և ավտոմատ խաղեր (error budget, latency, conversion)։
Ապրանքային թիմը ցանկանում է ստուգել վարկածները 'ազդել ծրարի վրա, պահել, LTV և այլն։
4) Հաջող ֆորումի ընդհանուր սկզբունքները
Idempotent-artefakts: Նույն պատկերը/փաթեթը բոլոր փուլերում։
Դետերմինացված կազմաձևը 'www.g որպես կոդ, շրջապատի համեմատությունը։
Դիտարկելով by design 'logs, metrics, հետքեր, ալերտներ։ SLI/SLO նախօրոք։
Արագ, ավտոմատացված արձագանք 'կոճակը/վերափոխման թիմը մի մասն է, ոչ թե ձեռքի մոգությունը։
Սխեմաների համատեղելի փոփոխությունները 'expand-migrate-entract ռազմավարությունը (տե՛ ս թիվ 10)։
L7 մակարդակում (ցանկալի է) 'ճկունություն վերնագրերի/կտորների/հետքերի/API տարբերակների վրա։
5) Blue-Green 'ճարտարապետություն և գործընթաց
5. 1 Տեղաբանություն
Երկու պրոդ ապակիներ ՝ Blue (ակտիվ) և Green (թեկնածուն)։
Ընդհանուր արտաքին կախվածությունը 'CDN, արտաքին API, հերթեր։ ԲԴ - հատուկ դեպք (տե՛ ս 10)։
Փոխանցման կետը 'հավասարակշռող/Ingress/Gateway։
5. 2 Գայթակղիչ ֆլոու
1. Մենք բարձրացնում ենք Green-ը նոր արտեֆակտով (vNext), մենք անցկացնում ենք Smok թեստեր։
2. Green-ի դեմ (e2e, պայմանագրային, ռեգրեսիայի)։
3. Մենք տաքացնում ենք քեշը/սեսիոնները (եթե կիրառելի է), համաժամեցնում ենք ֆոնային ջոբները/հերթերը։
4. Մենք տեղափոխում ենք Green: Ատոմային ֆլիպ (MSTL ցածր, Rober/Listener swap, Ingress weight = 100%)։
5. Մենք տեսնում ենք SLO-ն առաջին րոպեների ընթացքում (golden signals: latency, errors, saturation + բիզնես մետրիկներ)։
6. Խնդիրների դեպքում, ակնթարթային գրանցումը Blue-ում (flip back)։
5. 3 Պլյուսներ/մինուսներ
Պլյուսներ ՝ ակնթարթային արձագանք, պարզ մտավոր մոդել, մաքուր մեկուսացում։
Մինուսները 'ենթակառուցվածքի կրկնապատկումը, ստատեֆուլ բաղադրիչների բարդությունը և տվյալների բաղադրիչները։
6) Canary 'ճարտարապետություն և գործընթաց
6. 1 Տեղաբանություն
Միասնական պրոդ կլաստեր; մի քանի տարբերակներ (stable և canary) մեկ ճակատում։
Մոսկվան կիսվում է քաշով (1-5-10-25-50-100%) կամ Թարգետներում (վերնագրով/տիկնիկ/ID)։
6. 2 Գայթակղիչ ֆլոու
1. Նույն կլաստերի/ASG/NSG։
2. Կղզիների մի մասի միկրոակտիվացումը (օրինակ, 1-5 տոկոսը) canary-ում։
3. SLI/SLO ավտոմատ ստուգումները և բիզնես մետրիկը։ CI/CD (error rate, p95 latency, CPU/RES, կոնվերսիա, մերժում/2019)։
4. Գոմերի անցնելիս պարտքի մասնաբաժնի ավելացումը կատարվում է։
5. Ամբողջական rollout մինչև 100 տոկոսը և հին տարբերակի ապակայունացումը։ քայքայման ժամանակ 'auto-rollback։
6. 3 Պլյուսներ/մինուսներ
Պլյուսներ 'նվազագույն ռիսկը օգտագործողների մեծամասնության համար, 2019-driven լուծումը։
Մինուսներ 'անհրաժեշտ է տեսողական դիտարկում, գրագետ միկրոօրգանիզացիա, ինստանցիների միջև «version skew» ռիսկը։
7) Միգրանտների տեղափոխումը
L4 մակարդակը 'IP/պորտերի հավասարակշռություն; պարզ է, բայց ճկուն չէ։
L7: HTTP/S կանոնները 'ճանապարհի, հանրակացարանի, վերնագրի, տիկնիկների, User-Agent, GeoIP, PPI-ի միջոցով։
Տեխնիկան
Weighted routing (քաշը 1-100%)։
Header-based/Cookie-based (օգտագործողի ամրագրումը խմբում)։
Session stickiness (կարևոր է stateful/keshul կոդերի համար)։
Shadow/Traffic mirroring (մենք հարցումներ ենք հավաքում նոր տարբերակում «vtichu»)։
8) Գործիքներ և իրականացումներ (օրինակներ)
Kubernetes: Ingress (NGINX, Contour), Service Mesh (Istio/Linkerd), Argo Rollouts, Flagger.
Облака: AWS ALB/ELB, Route 53 weighted records, ECS/EKS; GCP Load Balancing + NEG; Azure Front Door/App Gateway.
CD պլատֆորմներ ՝ Spinnaker, Argo CD, GitHub Actions + Progressivery Divery, GitLab/CD։
9) Դիտարկումը, SLI/SLO և խաղերը
Golden signals: Latency (p95/p99), Error rate (5xx/4xx по типам), RPS, Saturation (CPU/Memory/GC), Queue lag.
Բիզնես մետրերը 'փոխակերպում, հեղինակային իրավունքի, վճարումների/հաջողությունների, միջին չեկի, ձագերի քայլերի մերժումը։
Գեյթ
Սխալի շեմն (օրինակ ՝ error rate canary nobaseline + X%)։
P95 լատինականությունը ավելի վատ չէ, քան baseline-ը։
Բիզնես շեմը (օրինակ, փոխադարձության նվազումը ERror budget-ը SLO-ում չպետք է այրվի արագացված։ Մրցույթի տևողությունը 'նվազագույն ժամանակը, բավարար վիճակագրական կարևորության համար (կախված է հաճախորդից)։ 10) Intel BD-ն և սխեմաների համատեղելիությունը Հիմնական կանոնը 'ածխաջրածինները անվտանգ են, եթե տարբերակները միասին են։ Expand-migrate-medract ռազմավարությունը 1. Expand: Մենք ավելացնում ենք նոր/ինդեքսներ/աղյուսակներ, առանց կոտրելու հին տարբերակը։ 2. Deploy ap vNext (կարդում/գրում է նոր սխեմայի մեջ, բայց կարող է աշխատել հնի հետ)։ 3. Migrate-ը (background/batch, idempotent, chekpoints)։ 4. Euract 'հեռացրեք հին դաշտերը/fichi-ից հետո։ Anti-patterns: 108, որոնք պահանջում են բացառիկ արգելափակում Blue-Green-ի ժամանակ։ Դաունգրեյդի սխեմայի անհնարինությունը։ «Կրկնակի ձայնագրություն» առանց դեդուպլիզացիայի։ 11) Rollback (rollback) և դժբախտ պատահարների պլանները Blue-Green: ակնթարթային ֆլիպ Blue-ում; դիտարկենք Green ֆոնային ջոբների «պոչերը»։ Canary: Քաշը (օրինակ, 25 տոկոսով առաջ 5 տոկոսով կամ 0%); ավտոմատ abult alertes-ում։ Տվյալները 'խոհարարների/փոխհատուցման մտածված քաղաքականությունը (idempotency keys, «inbox/wwww.box» pattern, հաղորդագրությունների deduplication)։ Ֆիչեֆլագները 'արագ kill switch-ը, որպեսզի կարողանան ձեռք բերել մասամբ պատրաստված հնարավորություններ։ 12) Սթեյթի և նստաշրջանների հետ աշխատելը Sticky sessions-ի համար, կամ արտաքին նստաշրջանների պահպանումը (Redis/Memcached), որպեսզի տարբերակները փոխազդեն։ Քեշը նախապես տաքացնել (Green warm-up) և հաշվի առնել proalidation flip-ում։ Ֆոնային գողերը 'թույլ մի տվեք «մրցավազքը» տարբերակների միջև' հերթերի բաժանումը կամ «առաջնորդությունը» ըստ վարկածի։ 13) Անվտանգություն և համապատասխանություն Green/Canary-ի հասանելիությունը Zero Trust-ով 'ծառայողական հաշիվներ, նվազագույն անհրաժեշտ դերեր։ Գաղտնիքները և բանալիները KFC/Secrets Express-ի միջոցով։ միացրեք տարհանումը։ Իսպանիան միայն TFC է։ endpoint's տարբերակները հստակ նշված են. ուղղահայաց և հիբրիդային գործողությունների աուդիտ։ 14) Արժեքը և արտադրողականությունը Blue-Green-ը կրկնապատկում է ենթակառուցվածքը (վճարման ժամանակ կամ անընդհատ) - տեղադրեք բյուջեթը։ Canary-ը ավելի տնտեսական է, բայց պահանջում է դիտարկման և ինժեներական ժամանակի գործիքներ ավտոմատիզացման համար։ Օպտիմիզացիան 'ավտոկեյլինգը, ephemeral միջավայրը, տարբերակների զուգահեռ գոյության պատուհանի կրճատումը։ 15) Չեկ թերթերը Նախքան ֆորումը 16) Հաճախակի սխալներ և հակատիպեր Հանեք առանց նշանի, տվյալներ չկան, չկա վերահսկվող լուծում։ Անհամատեղելի BD սխեմաների խառնուրդը, Դաունգրեյդի ռազմավարության բացակայությունը։ Պատահականության խառնուրդ. Ոչ stickiness, օգտագործողները «ցատկում են» տարբերակների միջև։ Թաքնված stateful կախվածությունը (տեղական սկավառակներ, in-memory cashi)։ Երկար SNA-TTL-ը խանգարում է արագ ֆլիպ (Blue-Green)։ Ավտոմեքենաների բացակայությունը 'ձեռքով «աչքերի վրա» լուծումները խոչընդոտում են և ավելացնում ռիսկերը։ 17) Համակցված մոտեցումներ Blue-Green + Canary: Նախ Green-ը, ապա Green-ի ներսում Canary-ը առանձին ծառայությունների համար։ Shadow/միգրացիոն ֆորումը 'Canary-ից առաջ մենք հայելային փաթեթ ենք տեղափոխում նոր տարբերակով։ Feature flags (progressivery): ֆունկցիոնալը միանում է կայուն տարբերակի վերևում «մութ» դրոշներով։ 18) Արձանագրությունների օրինակներ (էսքիզներ) 1. Մենք շրջում ենք Green (v2) նոր Listener/Ingress-ի համար։ 2. Մենք տաքացնում ենք քեշերը, կատարում ենք readonly ստուգումներ, smoke։ 3. Մենք փոխում ենք քաշը Green = 100 տոկոսով։ 4. Մենք դիտում ենք SLO 30-60 րոպե; եթե ամեն ինչ անջատենք Blue-ը։ Canary (միկրովայրկյան վճարման) 1. Deplay canary vNext (5%)։ 2. Մենք ներառում ենք 355 տոկոսը ներքին հաշիվների/թեստային կոդերի համար։ 3. Ավտոգեյթ ՝ error rate no baseline + 0։ 3%, p95 ≤ +20ms. 4. Մենք յուրաքանչյուր N րոպեի ընթացքում 10 տոկոսը բարձրացնում ենք 25% -ը։ 5. 100 տոկոսով մենք փոխանցում ենք ֆիչեֆլագը բոլոր հատվածներում։ հեռացնում ենք հին տարբերակը։ 19) Տարբեր ճարտարապետությունների համար տատանումներ Մոնոլիտ 'Blue-Green-ը ավելի հեշտ է, Canary-ը ավելի բարդ է ֆիչի անբարոյության պատճառով։ օգտագործեք ֆիկեֆլագները։ Միկրովեռներ ՝ Canary բնական; հետևեք համապատասխան հղման պայմանագրերին (consumer-driven no. racom)։ Stateful ծառայություններ. Նախընտրեք Blue-Green-ը մանրակրկիտ ուսումնասիրված և stickiness-ով։ 20) Համեմատություն (ռեզյումե) Արձագանքման արագությունը ՝ Blue-Green = անմիջապես; Canary = արագ, բայց քաշի հետ։ Ենթակառուցվածքի արժեքը ՝ Blue-Green 2019; Canary ↔︎/↓. Օգտագործողների ռիսկը 'Canary ցածր (վերահսկում ենք բաժինը)։ Իրականացման բարդությունը 'Blue-Green-ը ավելի հեշտ է սկսել։ Canary պահանջում է ուժեղ դիտարկում և ավտոմատացում։ Տվյալների/սխեմաների համատեղելիությունը քննադատական է երկուսի համար։ պլանավորեք expand-migrate-medract։ 21) Արդյունքը Blue-Green և Canary-ը փոխկապակցող ռազմավարություններ չեն, այլ առաջադիմական առաքման տարրեր։ Ընտրությունը կախված է արժեքի սահմանափակումներից, դիտարկման հասունությունից և փոփոխության բնույթից։ Անկախ մոտեցումից, կայուն թողարկումը պահվում է չորս հենարանների վրա 'ավտոմատիզացիա, դիտարկում, հակադարձ համատեղելիություն և արագ արձագանք։
Թողարկման ընթացքում
Թողարկումից հետո