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

1) რატომ და სად არის იგი არქიტექტურაში

• წვდომა (ერთი უკმარისობის წერტილის გარეშე), ლატენტობა (p95 ქვევით), მასშტაბი (ჰორიზონტალი), უსაფრთხოება (TLS/WAF), გამოშვებების მართვა (კანარი/ცისფერი-მწვანე).

• Edge/Global: Anycast, GSLB/GeoDNS, CDN/Edge-LB, DDoS.
• L4 (TCP/UDP): NLB, magles, მარიონეტული ტერმინალის გარეშე.
• L7 (HTTP/2, GRPC, WebSocket, QUIC): მარშრუტიზაცია ტრასაზე/სათაურებზე/სტიგმებზე, ქეში/შეკუმშვა/რეტრაში.
• Data-tier: DB-прокси (PgBouncer/ProxySQL), Redis Cluster/Consistent Hash, Kafka partitioning.

2) მოდელები და დაბალანსების ალგორითმები

Round-Robin (RR): მარტივი ერთგვაროვანი.
Least Connections (LC): კარგია გრძელი კონექტორებისთვის (WS, gRPC).
Least Request/Power of-Two (P2C): ორი შემთხვევითი შედარება კარგი ბალანსია/ხარისხი.
Weighted RR/LC: წონა ჟანრის/„ ცხელი “ნოდებისთვის.
Consistent Hashing (CH): სხდომის წებოვანი მაგიდის გარეშე (ბარათი, Redis).
Maglev/Flow-hash: სწრაფი L3/L4 განაწილება flapping- ის წინააღმდეგობით.
Latency-aware: არჩევანი მოცურების p50/p95.
EWMA: ითვალისწინებს შეფერხებების ისტორიას.

რეკომენდაცია: ნაგულისხმევი P2C L7- ზე; stateful/kesh- ისთვის - consistent hash; для WS/gRPC — least-connections.

3) აფსტრიმების ჯანმრთელობა: შემოწმება და „გამოსახლება“

Health-checks: TCP, HTTP 200/匹配 тела, gRPC status; ინტერვალები/ტაიმაუტები/შეცდომების ბარიერი.
Outlier Ejection: „ხმაურიანი“ ინსტანციების (consecutive-5xx, success-rate-ejection) დასკვნა.
Slow-start & warmup: ახალი ინსტანციების რბილი შეყვანა (წონის თანდათანობითი ზრდა).
კავშირი დალაგება: ამოღებისას/დეპრესიისას - აქტიური კონექტორების „დაჭერა“ კლდის გარეშე.

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

Cookie-stickiness (L7): `Set-Cookie: lb=<id>; SameSite; Secure`.
CH გასაღები: 'hash (userID' sessionID 'cartID)'.
IP-hash - მხოლოდ დახურულ ქსელებში (NAT არღვევს).
TTL clypsions + fallback noda- ს ევიკუაციის დროს.
მნიშვნელოვანია: მინიმუმამდე დაიყვანეთ წებოვანი საჭიროება და შეინახეთ მდგომარეობა ინსტანციის გარეთ (Redis/DB/JWT).

5) გლობალური დაბალანსება (GTM/GSLB)

Anycast + health-probe: ერთი IP, ტრეფიკი უახლოეს PoP- ში; ავტომატური ფეილოვერი.
GeoDNS/Latency-DNS: პასუხი გეო/შეფერხებაზე.
რეგიონალური მტევანი: „რეზიდენტების მონაცემები“ რჩება რეგიონში (GDPR); ინტერრეგიონალური failover რეპლიკაციით.
პოლიტიკოსები: გეო-ბლოკები, „სტიკერეგიონი“ ანგარიშზე/ნიშანი.

6) ოქმები და მახასიათებლები

HTTP/2: მულტიპლექსი, პრიორიტეტები; საჭიროა კომპეტენტური კავშირი-აუზი აფსიდზე.
GRPC: გრძელი ნაკადები - გრძელი კავშირები, აგრესიული ჯანმრთელობის შემოწმებები.
WebSocket/SSE: connection წებოვანი, დიდი idle Timauts, TCP keep-alive.
QUIC/HTTP/3: სწრაფი დასაწყისი, დანაკარგისადმი წინააღმდეგობა; მიჰყევით MTU/path-MTU.
TLS-termination/mTLS: edge/L7-LB არგუმენტი; შიგნით - mTLS/იდენტურობა (SPIFFE).

7) გადატვირთვისგან დაცვა

Rate-limit: per-IP, per-key, per-route; burst+sustain.
Adaptive Concurrence (Envoy): ერთდროული მოთხოვნების დინამიური ზღვარი.
Queue/Surge-buffer: ხაზის შეზღუდული ზომა გულწრფელი უარი 503.
Hedging/Parallel racing: ნელი მოთხოვნების დუბლირება (მხოლოდ imempotent).
Timeout budget: ცალკეული კავშირი/read/write.
Backpressure: '503 + Retry-After', კლიენტის ექსპონენციალური რეაგირება ჯიტერთან.
Slow-loris დაცვა: კითხვის/ჩაწერის დრო, მინიმალური სიჩქარე.

8) გამოშვებები და ტრაფიკის მენეჯმენტი

Canary (weighted): 1–5–10–25–50–100% с guardrails (p95, 5xx, timeouts).
Blue-Green: მყისიერი სვიტრი, გამოტოვება - DNS/LB.
Shadow/Mirror: მოთხოვნის ასლი პასუხზე გავლენის გარეშე; შენიღბვა PII.
Header/Claim-routing: `X-Canary: 1` или `JWT. claims. region/role`.

9) ავტო სკეილინგი და დრენაჟი

HPA/ASG по CPU+RPS+p95+queue-depth.
PreStop hook: დაელოდეთ კონექტორების დასრულებას.
Warm pool/instance reuse: ცივი დაწყების შემცირება.
Capacity planning: მიზნები 'utilization 60-70%' ნორმალურად p95.

10) დაკვირვება და SLO

მეტრიკა LB: RPS, p50/p95/p99, 4xx/5xx, ღია კავშირები, დედოფალი-ლენი, ejections, retries, hit-ratio კეში.
ტრეისი: 'traceparent/x-request-id' LB- ის საშუალებით - BD სერვისები.
ლოგოები: სტრუქტურული, PII/PAN ნიღბები, კორელაცია ფორთოხლით.
SLO მარშრუტზე: მაგალითად, 'latency p95-300 ms', 'availability-99. 9%`, `5xx ≤ 0. 5%`.
ალერტები: გადახრები (burn-rate SLO, ejection ზრდა, ზრდა 5xx/timeout).

11) მონაცემთა დაბალანსება და ქეში

• Read/Write split (ProxySQL/pgpool) + read-replicas; sticky-txn.
• Failover: სინქრონული რეპლიკა RPO = 0 (უფრო ძვირი).

• Redis Cluster + hash-slot; სესიებისთვის - CH; Taimauts/Retryable errors.

• ბალანსი partitioning და consumer groups; არ იყოს დაბნეული HTTP-LB- სთან.
• Object Storage (S3/MinIO): multi-region failover через GSLB/replication.

12) K8s და ღრუბლოვანი LB

სერვისი (ClusterIP/NodePort/LoadBalancer) - ბაზა L4.
Ingress/Gateway API - L7 მარშრუტიზაცია, კანარის წონა, TLS.
AWS: NLB (L4, მაღალი გამშვები), ALB (L7, WAF, sticky, header-routing).
GCP: Global LB (L7/HTTP(S) с Anycast), TCP/UDP proxy LB.
Azure: Front Door (global), Application Gateway (L7), Load Balancer (L4).

13) კონფიგურაციის მაგალითები

13. 1 NGINX (L7, least_conn, sticky, canary)

nginx upstream api_pool {
least_conn;
server api-1:8080 max_fails=3 fail_timeout=10s;
server api-2:8080 max_fails=3 fail_timeout=10s;
sticky cookie lb_id expires=30m path=/ secure httponly;
}

map $http_x_canary $dst {
default api_pool;
1    canary_pool;
}

upstream canary_pool {
least_conn;
server api-canary:8080 weight=1;
}

server {
listen 443 ssl http2;
location /api/ {
proxy_read_timeout 5s;
proxy_connect_timeout 1s;
proxy_set_header X-Request-Id $request_id;
proxy_pass http://$dst;
}
}

13. 2 HAProxy (P2C, health, slowstart, stick-table)

haproxy backend api balance leastconn option httpchk GET /health default-server inter 3s fall 3 rise 2 slowstart 10s server s1 10. 0. 0. 11:8080 check server s2 10. 0. 0. 12:8080 check stick-table type ip size 100k expire 30m http-request track-sc0 src rate limit per IP http-request deny deny_status 429 if { sc_http_req_rate(0) gt 50 }

13. 3 Envoy (P2C, outlier, retries, adaptive concurrency)

yaml load_assignment: {... }
lb_policy: LEAST_REQUEST least_request_lb_config: { choice_count: 2 }
outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s typed_extension_protocol_options:
envoy. extensions. filters. http. adaptive_concurrency. v3. AdaptiveConcurrency:
gradient_controller_config:
sample_aggregate_percentile: PERCENTILE_50 retry_policy:
retry_on: "5xx,reset,connect-failure"
num_retries: 2 per_try_timeout: 1s

13. 4 Kubernetes (Gateway API, weighted canary)

yaml apiVersion: gateway. networking. k8s. io/v1 kind: HTTPRoute spec:
rules:
- matches: [{ path: { type: PathPrefix, value: /api }}]
backendRefs:
- name: api-v1 weight: 90 port: 8080
- name: api-v2-canary weight: 10 port: 8080

14) ჩეკის ფურცლები

LB/მარშრუტის გამოშვებამდე

• ალგორითმი შერჩეულია (P2C/LC/CH) ტრაფიკის ტიპისთვის.
• ჯანმრთელობის შემოწმებები და ejection ბარიერები მორგებულია.
• Slow-start, warmup, connection-drain შედის.
• TLS/mTLS, HSTS, უსაფრთხო შიფრები; საჭიროების შემთხვევაში HTTP/2/3.
• Sticky/CH მხოლოდ საჭიროების შემთხვევაში; TTL и fallback.
• Rate-limit/burst, timeouts, retry-budget, adaptive concurrency.
• logs/traces: 'trace-id' იჭრება; შენიღბვა PII.
• SLO/ალერტები p95/5xx/ელექციებში/queue-len.
• კანარის წონა + გამოტოვების გეგმა; shadow დიდი ცვლილებებით.

გადახდის/შესაბამისობის მარშრუტებისთვის

• Idempotence POST (Idempotency-Key).
• Failover PSP- ს შორის; same-method შემოწმება.

შეცდომის კოდი ნორმალიზებულია; ETA/კლიენტის მიზეზები.

BD/ქეში

• RW-split/რეპლიკები; ტაიმაუტები, ქსელის რეტრი.
• CH/slot-hash for Redis; „ცხელი გასაღებებისგან“ დაცვა.
• შეფერხებების და შეფერხებების მონიტორინგი.

15) ხარისხის მეტრიკა (მინიმალური)

Latency p50/p95/p99 მარშრუტებზე/მეთოდებზე.
Error rate 4xx/5xx, timeout/overflow.
Open/active connections, queue depth, retry count.
Outlier Ejections და მიზეზები.
Sticky hit-ratio / cache hit-ratio.
GSLB: რეგიონალური განაწილება, ფეილოვერები, PoP- ის ხელმისაწვდომობა.

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

ერთი მონოლითური LB სარეზერვო გარეშე.
Sticky სესიები „ყველაფრისთვის“, ნაცვლად სახელმწიფო მოხსნისა.
გლობალური გაუთავებელი ხაზები (მალავს პრობლემას, იზრდება p99).
Retrai გარეშე jitter/ბიუჯეტი - მოთხოვნების „ქარიშხალი“.
ნდობა "X-Forwarded-For 'სანდო მარიონეტული ჩამონათვალის გარეშე.
ხარვეზების არარსებობა არის WS/GRPC კლდეები.
არ არის აღრიცხული გრძელი სკეიტის კონექტორები.

17) iGaming სპეციფიკა

მწვერვალები და ტურნირები: მიკრო-საკეტი საცნობარო წიგნებზე/ჩამონათვალში (1-5 ს), მანქანების სკეიტი თავის მხრივ.
მსუბუქი თამაშები/ნაკადები: LC გრძელი კონექტორებისთვის, უახლოესი PoP- ის პრიორიტეტი.
გადახდები: გეო/ვალუტის მარშრუტიზაცია/თანხა/პროვაიდერი; მკაცრი ტაიმაუტები და იდემპოტენტობა.
პასუხისმგებელი თამაში და შესაბამისობა: პრიორიტეტი, რომ გამოტოვოთ ლიმიტები/საკეტები, თუნდაც დეგრადაციის დროს (fail-open/close პოლიტიკა).

18) განხორციელების პროცესი (4 სპრინტი)

1. ტრაფიკის რუკა: ოქმები, p95/p99 დატვირთვა, კრიტიკული მარშრუტები.
2. LB კონფიგურაცია: ალგორითმები, health/outlier, TLS, limites/Timauts, observability.
3. GSLB/Edge: Anycast/GeoDNS, PoP helscheks, რეგიონალური მონაცემთა პოლიტიკოსები.
4. გამოშვება სტრატეგია: canary/shadow, SLO ალერტები, skale + drain, პოსტ-ინციდენტის ანალიზი.

საბოლოო ყალბი ფურცელი

შეარჩიეთ ალგორითმი ტრაფიკის ტიპისთვის (P2C/LC/CH) და კონექტის ხანგრძლივობა.
შეინარჩუნეთ აფსიდი „ჯანმრთელი“: ჯანმრთელობის შემოწმებები + outlier + slow-start + drain.
აკონტროლეთ მწვერვალის დატვირთვა: rate-limit, adaptive concurrence, რიგები მარცხით.
გამოიყენეთ GSLB/Anycast რეგიონში გლობალური ხელმისაწვდომობისა და შესაბამისობისთვის.
დაკვირვება და SLO სავალდებულოა; გამოშვებები - canary/shadow- ით დაბრუნების გეგმით.
სადაც ეს შესაძლებელია, ამოიღეთ სესია ინსტანციებიდან და წებოვანი LB- დან.