დატვირთვის დაბალანსება და failover

1) მიზნები და ტერმინები

დაბალანსება ანაწილებს ტრაფიკს ნიმუშებს/ზონებს/რეგიონებს შორის პროდუქტიულობისა და სტაბილურობისთვის.
Failover - კონტროლირებადი გადართვა უარის თქმის დროს.
RTO/RPO: სამიზნე დრო და დასაშვები მონაცემების დაკარგვა.
SLO: ხელმისაწვდომობის/ლატენტობის მიზნობრივი დონე; ემსახურება როგორც „კარიბჭეს“ ავტომატური ფეილოვერისთვის და უკან დახევისთვის.

2) დაბალანსების ფენები

2. 1 L4 (TCP/UDP)

უპირატესობები: შესრულება, სიმარტივე, TLS passthrough. უარყოფითი: მარშრუტის/კუკის გაგება არ არსებობს.
მაგალითები: NLB/GLB, HAProxy/Envoy L4, IPVS.

2. 2 L7 (HTTP/gRPC)

უპირატესობები: მარშრუტიზაცია ტრასაზე/კედლებზე, კანარის წონა, სტიკი. უარყოფითი მხარეები: უფრო ძვირია, ვიდრე CPU/ლატენტობა.
მაგალითები: NGINX/HAProxy/Envoy/Cloud ALB/API Gateway.

2. 3 გლობალური დონე

DNS/GSLB: ჯანმრთელობის შემოწმებები + გეო/დაბალანსებული პასუხი.
Anycast/BGP: ერთი IP მთელს მსოფლიოში, განცხადების უახლოესი წერტილი.
CDN/Edge: ქეში/ფეილოვერი პერიმეტრზე.

3) განაწილების ალგორითმები

Round-robin/wighted - საბაზო.
Last Connections/latence - „მძიმე“ მოთხოვნისთვის.
Consistent hashing - სტიგმა გასაღები (მომხმარებელი/ტენანტი) ცენტრის სესიის გარეშე.
Hash-based მოწყობა - ქეში და სახელმწიფო სერვისებისთვის.

4) სესიები და წებოვანი

Cookie-sticky: L7 LB ადგენს ქუქი-ფაილს ასლის დასაბრუნებლად.
Src-IP სტილი: L4- ზე, უარესი NAT/CGNAT.
Consistent hashing: უკეთესი ჰორიზონტალური ქეში/ჩატი.
Aim: თუ ეს შესაძლებელია, გააკეთეთ სახელმწიფო მომსახურება, წინააღმდეგ შემთხვევაში, მიიღეთ სახელმწიფო (სესიები Redis/DB), რათა გამარტივდეს failover.

5) საიმედოობა: ჯანმრთელობის შემოწმებები და როტაციიდან ამოღება

აქტიური შემოწმებები: HTTP 200/ღრმა ბიზნეს ტესტები (მაგალითად, „/healthz/withdraw “დამოკიდებულებებით).
Passive (outlier detection): ზურგჩანთა Exection 5xx/Timauts.
Warm-up: ახალი ინსტანციების გლუვი ჩართვა (slow-start).
Graceful drain: ამოიღეთ აუზიდან და დაელოდეთ მოთხოვნის დასრულებას.

NGINX (მაგალითი):

nginx upstream api {
zone api 64k;
least_conn;
server app-1:8080 max_fails=2 fail_timeout=10s;
server app-2:8080 max_fails=2 fail_timeout=10s;
keepalive 512;
}
proxy_next_upstream error timeout http_502 http_503 http_504;
proxy_next_upstream_tries 2;

Envoy outlier detection (ფრაგმენტი):

yaml outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s max_ejection_percent: 50

6) წარუმატებლობის მართვა: Timeout/retry/circuit-breaking

Timeouts: უფრო მოკლეა ვიდრე კლიენტის ტაიმუტი; მიუთითეთ per-route.
Retries: 1-2 ერთად ჯიტერი და იდემპოტენტობა; POST- ზე ჭაობის აკრძალვა idempotence გასაღებების გარეშე.
Circuit breaker: ერთდროული შეკითხვის/შეცდომების შეზღუდვა; „ნახევრად ღია“ აღდგენა.
Budgets: Retrai- ის ლიმიტები/ბორტების შერწყმა ისე, რომ არ მოაწყოთ self-DDOS.

7) Kubernetes ნიმუშები

ClusterIP/NodePort/LoadBalancer/Ingress არის ძირითადი პრიმიტივები.
Readiness/Liveness: ტრაფიკი მხოლოდ მზა საყრდენებზე.
PodDisrupite Budget: დაუშვებელია რეპლიკების ერთდროული ვარდნა.
HPA/VPA: სკალირება CPU/RED მეტრებზე, LB- სთან ერთად.
სერთიფიკატი ტოპოლოგია/ტოპოლოგიის აკვარიუმის ჰინტები: ზონაში ადგილსამყოფელი.
სერვისის ტიპი = LoadBalancer (zonal): მინიმუმ 2 შენიშვნა თითოეულ AZ- ში.

კრიტიკული მარშრუტისთვის დასვენების მაგალითი:

yaml readinessProbe:
httpGet: { path: /healthz/dependencies, port: 8080 }
periodSeconds: 5 failureThreshold: 2

8) ჯვარედინი ზონა და ჯვარედინი რეგიონალური ტრაფიკი

Multi-AZ (რეგიონის შიგნით): განაწილება თანაბრად (zonal LB), შენახვა - სინქრონული შენიშვნები.

Multi-region:

აქტიური აქტივობა: ორივე რეგიონი ემსახურება ტრაფიკს; უფრო რთულია - საჭიროა გეოგრაფიაში მონაცემების რეპლიკაცია, კოორდინაცია და მარშრუტიზაცია.
Active-Passive: ძირითადი რეგიონი ემსახურება, რეზერვი - „ცხელი/თბილი/ცივი“. უფრო ადვილია, უფრო სწრაფად გადართვა, მაგრამ უფრო მაღალია ვიდრე RPO.

GSLB სტრატეგია:

Geo-DNS (უახლოესი რეგიონი).
შაბათ DNS (კანარი/გადანაწილება).
Latency-based (RTT გაზომვები).
Failover = ჯანმრთელობის/ხელმისაწვდომობის სიგნალების მიხედვით (probes რამდენიმე vantage წერტილიდან).

9) მონაცემები და failover

Kash/state: თუ ეს შესაძლებელია - რეგიონალური ადგილობრივი; აქტიური აქტიურობისთვის - CRDT/კომპოზიციური ჰეშები.

BD:

სინქრონული რეპლიკაცია = დაბალი RPO, ლატენტობის ზემოთ.
ასინქრონული = ლატენტობის ქვემოთ, მაგრამ RPO> 0.
რიგები: მარცვლეული/მულტიკლასტიკური ტოპები; მოვლენების დედობა.
შეიმუშავეთ ოპერაციების idempotence და replay მექანიკა.

10) პერიმეტრი: DNS/Anycast/BGP/CDN

DNS: მოკლე TTL (30-60s) + ჯანმრთელობის შემოწმებები თქვენი ქსელის გარეთ.
Anycast: რამდენიმე ROP ერთად ერთი IP - უახლოესი იღებს ტრაფიკს, ფეილოვერი მარშრუტიზაციის დონეზე.
CDN/Edge: ქეში და „კარიბჭე“ დასაცავად, სტატიკა/მედია ემსახურება origin- ის დაცემის დროს; origin-shield + пер-POP health.

11) კონფიგურაციის ნიმუშები

HAProxy L7:

haproxy defaults timeout connect 2s timeout client 15s timeout server 15s retries 2 option redispatch

backend api balance leastconn option httpchk GET /healthz/dependencies http-check expect status 200 server app1 app-1:8080 check inter 5s fall 2 rise 2 slowstart 3000 server app2 app-2:8080 check inter 5s fall 2 rise 2 slowstart 3000

NGINX sticky по cookie:

nginx upstream api {
hash $cookie_session_id consistent;
server app-1:8080;
server app-2:8080;
}

Envoy retry/timeout (route):

yaml route:
timeout: 2s retry_policy:
retry_on: 5xx,connect-failure,reset num_retries: 1 per_try_timeout: 500ms

12) ავტომატური failover: სიგნალები და კარიბჭეები

ეს-SLI: 5xx-rate, p95/p99, saturation, handsheiks TLS, TCP resets.
ბიზნეს SLI: დეპოზიტების/გადახდების წარმატება, PSP- ს არ აქვს გადახდის შეცდომები.
კარიბჭეები: როდესაც ბარიერები აღემატება - გამორთეთ ზონა/ინსტანცია, გაზარდეთ სტაბილური აუზის წონა, გადართეთ GSLB.
Runbook: გადართვისა და დაბრუნების ეტაპობრივი ინსტრუქცია (rollback).

13) ტესტები და შემოწმებები (chaos & game-days)

Chaos ტესტები: AZ/რეგიონების გამორთვა, BD/ქეშის დეგრადაცია, პაკეტის ლოსის სიმულაცია.
Game-day: ტრენინგი faylover გუნდების მონაწილეობით.
დიაგნოზი: პერიმეტრიდან ზურგჩანთებამდე კვალი, გამოშვება და მეტრიკის შედარება.

14) უსაფრთხოება და შესაბამისობა

mTLS LB სერვისებს შორის, WAF/Rate limits პერიმეტრზე.
უკმარისობის/სეგმენტის ზონები: blast-radius იზოლაცია.
პოლიტიკოსები: უარის თქმის ერთჯერადი წერტილების აკრძალვა (SPOF), მოთხოვნები „მინიმალური N რეპლიკების/AZ“.

15) ანტი შაბლონები

ერთი LB/ერთი ზონა ყველა სასაქონლო ტრაფიკისთვის (SPOF).
ღრმა შემოწმების არარსებობა '/healthz '(მწვანე - მაგრამ BD/ხაზი არ არის ხელმისაწვდომი).
Retray idempotent- ის გარეშე - ოპერაციების/გადახდების ორმაგი.
Sticky per IP მასიური NAT- ით არის დისბალანსი.
DNS Faylover მაღალი TTL (გადართვის საათები).
არ არსებობს გრეიფულის დასხივება - მოთხოვნის გაფუჭება.

16) განხორციელების სიის სია (0-45 დღე)

0-10 დღე

განშორება 2 AZ; ჩართვა/შემცირება, ჯანმრთელობის შემოწმება.
კონფიგურაცია L7-timeouts/retries (1 მცდელობა), outlier detection.
ჩართეთ graceful drain და slow-start.

11-25 დღე

შეიყვანეთ GSLB (geo/wighted) ან Anycast პერიმეტრისთვის.
კანარის წონა/მარშრუტების პოლიტიკა; sticky მეშვეობით cookie/consistent hash.
SLO კარიბჭე მანქანის ფეილოვერისთვის (p95/5xx + ბიზნეს SLI).

26-45 დღე

რეგიონალური DR: Active-Active ან Active-Passive თარგმანის ტესტით.
Chaos დღეები AZ/რეგიონების გათიშვით, RTO/RPO ანგარიშები.
ავტომატური runbook 'და (სკრიპტები pause/shift/rollback).

17) სიმწიფის მეტრიკა

Multi-AZ- ის დაფარვა კრიტიკული ბილიკების 99% -ს შეადგენს.
DNS/GSLB/Anycast დაინერგა საზოგადოებრივი ენდოინტებისთვის.
MTTR ერთი AZ- ის დაცემისას <5 წუთი (p95).
RPO კრიტიკული მონაცემებისთვის არის სამიზნე (მაგალითად, 30 წამი).
კვარტალური თამაშები და წარმატებული დაგეგმილი ფეილოვერი.

18) დასკვნა

საიმედო დაბალანსება და failover არის ფენიანი არქიტექტურა: ადგილობრივი L7 პოლიტიკა (Timeouts/retries/CB, Health Checks), სწორი წებოვანი და ჰეშინგი, ჯვარედინი ზონის სტაბილურობა და GSLB/DNS/ANycANycasasTasTast პერიმეტრატი. დაამატეთ SLO კარიბჭეები, idempotence, graceful drain და რეგულარული chaos ტესტები - და კვანძის, ზონის ან თუნდაც რეგიონის ნებისმიერი დაკარგვა გახდება კონტროლირებადი მოვლენა პროგნოზირებადი RTO/RPO.

დატვირთვის დაბალანსება და failover