Shaping და ტრეფიკის მარშრუტი

1) რატომ არის ეს ყველაფერი

• სტაბილურობა: ჩვენ არ ვაძლევთ „ხმაურიან მეზობლებს“ არხების გატეხვას.
• სამართლიანობა: პრიორიტეტები და კვოტები ტენანტებს/კლასებს შორის.
• ეფექტურობა: ჩვენ გამოგიგზავნით თხოვნას იქ, სადაც ის უფრო სწრაფად/იაფია დამუშავება.
• ცვლილების კონტროლი: კანარის/ყოველკვირეული გამოშვებები რისკის გარეშე.
• დანაზოგი: egress/egress ღირებულებების ოპტიმიზაცია და CDN ქეში ჰიტრაიტი.

2) ძირითადი ცნებები

2. 1 Traffic shaping vs policing

Shaping - ასწორებს ტრაფიკს, ბუფერავს და პაკეტებს უგზავნის სამიზნე სიჩქარით („აფეთქებების“ გაბრტყელება).
Policing - ჭარბი ჭარბი (წვეთი/ეტიკეტირება) ბუფერიზაციის გარეშე. უფრო მკაცრი, მაგრამ იაფი.

2. 2 კლასები, რიგები და დისციპლინები

პრიორიტეტული ხაზები (PRIO), WFQ/DRR (სამართლიანი განაწილება), HTB (იერარქიული კვოტები), CoDel/RED (ბუფლოატთან ბრძოლა), ECN (სიგნალი გადატვირთვის გარეშე).
L7- ზე - „რიგები“ RPS/კონექტორების/ბაიტის და პრიორიტეტული აუზების ლიმიტების სახით.

2. 3 შეზღუდული ალგორითმები

ტოკენ ბუკეტი (n ნიშნებს ემატება rate r; მოთხოვნა „ხარჯავს“ კ ნიშნებს).
Leaky Bucket (ფიქსირებული გადინება; კარგია შერყევისთვის).
გლობალური/ადგილობრივი ლიმიტები: ადგილობრივი - სწრაფი, გლობალური - სამართლიანი (Redis/etcd/per-tenant).

3) QoS L3/L4

3. 1 DSCP/ToS და მომსახურების კლასები

მიუთითეთ პაკეტები ტრაფიკის ტიპის მიხედვით (ინტერაქტიული, უკანა RPC, ფონის დავალებები).
მონაცემთა ცენტრებში - კოორდინაცია გაუწიეთ DSCP პოლიტიკას ქსელის ქარხანასთან/ღრუბელთან.

3. 2 Linux tc: HTB + fq _ codel (ესკიზი)

bash
Clearing tc qdisc del dev eth0 root 2 >/dev/null         true

Корневая HTB с 1Gbit tc qdisc add dev eth0 root handle 1: htb default 30 tc class add dev eth0 parent 1: classid 1:1 htb rate 1gbit

Класс latency-critical 200Mbit tc class add dev eth0 parent 1:1 classid 1:10 htb rate 200mbit ceil 1gbit prio 0 tc qdisc add dev eth0 parent 1:10 handle 10: fq_codel

Класс background 100Mbit tc class add dev eth0 parent 1:1 classid 1:30 htb rate 100mbit ceil 1gbit prio 2 tc qdisc add dev eth0 parent 1:30 handle 30: fq_codel

3. 3 ECN/RED/BBR

ECN ამცირებს წვერებს მწვერვალებზე; RED/CoDel ზღუდავს ბუფლოატს.
BBR (კუბის ნაცვლად) ხშირად ამცირებს p99 ლატენტობას, განსაკუთრებით WAN/მძიმე რიგების თავზე.

4) L7 მარშრუტი (HTTP/gRPC/WS)

4. 1 როუტინგის კრიტერიუმები

გზები/მეთოდები ('/ap/v1/', 'POST'), სათაურები (კლიენტის ვერსია, დროშები, კანარის კედელი), ქუქი-ფაილები (A/B, სტილი), JWT ბრენდები (tenant/role), geo/ASN, დროებითი ფანჯრები, დატვირთვა (outlier detetetetetetetetetetetetetetetececitititike).
პროტოკოლი: HTTP/2 (მულტიპლექსირება), HTTP/3/QUIC (პაკეტების დაკარგვის წინააღმდეგობა), gRPC (bi-di streams), WebSocket (გრძელი კონექტორები).

4. 2 შეწონილი სპლიტი/კანარის გამოშვებები

Rout 'v1: 95%', 'v2: 5%', ავტომატური ზრდა მწვანე მეტრებში.
მოწყვეტა: შეცდომები/ლატენტობა/ბიზნეს ინვარიანტები.

Envoy (ესკიზი)

yaml route:
weighted_clusters:
clusters:
- name: svc-v1 weight: 95
- name: svc-v2 weight: 5

Istio

yaml apiVersion: networking. istio. io/v1beta1 kind: VirtualService spec:
hosts: ["svc"]
http:
- route:
- destination: { host: svc, subset: v1, weight: 95 }
- destination: { host: svc, subset: v2, weight: 5 }

4. 3 Sticky სესიები და consistent hashing

Cookie/IP/JWT იდენტიფიკატორის სესია.
Consistent hashing ქეშების მტევნებისთვის, შარდმდენი სერვისებისთვის, გეითვეის ლიმიტისთვის.

Nginx

nginx upstream api {
hash $cookie_user_id consistent;
server 10. 0. 0. 1;
server 10. 0. 0. 2;
}

4. 4 გეო და ლატენტური როუტინგი

GeoIP/ASN ზღვარზე (CDN/edge) არის უახლოესი ROP/რეგიონი.
Latency-aware: პერიოდული health + RTT გაზომვები - ტრეფიკი „ყველაზე სწრაფ“ კლასტერში.

4. 5 Outlier detection / circuit breaking

„ცუდი“ ინსტანციების დაარტყა: მაქს-ejection-percent, ძირითადი შეცდომები/ლატენტობა.
Circuit breaker: კონექტორების შეზღუდვები/RPS/რიგებში.

5) სამგზავრო დაშლა კარიბჭის/საშუალო დასტის დონეზე

5. 1 Rate limiting

ადგილობრივი (per-pod): იაფი, მაგრამ არა სამართლიანი ურთიერთგამომრიცხავი.
გლობალური (Redis/etcd): სამართლიანობა per-tenant/API გასაღები.
პოლიტიკოსები: per-route, per-method, per-tenant, burst.

Envoy RLS (ესკიზი)

yaml typed_per_filter_config:
envoy. filters. http. ratelimit:
"@type": type. googleapis. com/envoy. extensions. filters. http. ratelimit. v3. RateLimit domain: "api"
rate_limit_service:
grpc_service: { envoy_grpc: { cluster_name: rate_limit_cluster } }

5. 2 Fairness და პრიორიტეტები

პრიორიტეტული აუზები: „ინტერაქტიული“> „სისტემური“> „ფონი“.
DRR/WFQ ეკვივალენტები L7- ზე: კვოტები/წონა per კლიენტი/ტენანტი.

5. 3 გადატვირთვა და დაცვა

Load shed: უარი/დეგრადაცია ბიუჯეტების გადაჭარბებით.
Adaptive concurrence: p50/p95/queue-len- ის ლიმიტების დინამიკა.
Server-side backpressure: 429/503 + Retry-After.

6) eBPF და CNI დონე

6. 1 Cilium/eBPF

ბირთვში ფილტრაცია/მარშრუტი: ნაკლები კონტექსტური სვიტჩები, თხელი L3-L7 პოლიტიკოსები.
Maglev hashing სტაბილური განაწილებისთვის.
eBPF პროგრამები per-pod QoS (TC/XDP hooks).

6. 2 Calico/NetworkPolicies

L3/L4 დაშვების პოლიტიკოსები, ძირითადი პრიორიტეტული კლასები, Kubernetes QoS- ის ინტეგრაცია (Guaranteed/Burstable/BestEffort).

7) Edge/CDN და API კარიბჭეები

CDN: ქეშის გასაღებები (query/headers- ის ნორმალიზაცია), stale-while-revalidate, origin დაცვა (rate limit/bot ფილტრები).
API კარიბჭეები: ავთენტიფიკაცია, კვოტები/სატარიფო გეგმები (per-consumer), SLA შეზღუდვები, გეო-როუტინგი, API ვერსია.
WAF: ფილტრაცია ზღვარზე, ისე რომ არ დახარჯოთ ბირთვის CPU.

8) ასინქრონული საბურავები/ნაკადი

Kafka/NATS/Pulsar: კვოტები მწარმოებლებისთვის/კონსიუმერებისთვის, batch ზომის ლიმიტი, backpressure მეშვეობით lag.
მოვლენების მარშრუტიზაცია: განაწილების გასაღებები (tenant/idempotency-key), „ციმციმული“ წვეულებები ერთგვაროვნებისთვის.
Exactly-once - „ეფექტურად ერთხელ“: გარიგების მწარმოებლები + იდემპოტენტური სისხლჩაქცევები.

9) Taimauty, retrai, backoff

ტაიმაუტები: კლიენტი <მარიონეტული <მომსახურება (არა პირიქით).
Retrai: შეზღუდული რიცხვი ჯიტტერიზებული ექსპონენციალური ბაჩოფით, მაგრამ ქარიშხლის გარეშე.
Idempotention სავალდებულოა ჭიდაობის დროს; წინააღმდეგ შემთხვევაში - SAGA/ანაზღაურება.
Hedged/parallel requests (ფრთხილად): აუმჯობესებს p99, ზრდის საერთო ტრაფიკს.

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

10. 1 მეტრიკა

rate_limit_hits, requests_queued, shed_requests_total, latency_ms{p50,p95,p99}, error_ratio, retry_attempts, outlier_ejections, queue_time_ms.

10. 2 ვაჭრობა

გადაყარეთ Correlation-ID; განათავსეთ სპილოები მიზეზის ტიპით: 'retry' shed 'throttle' queue '.
Retrais/hedges ლინკები ქვესისტემებზე გავლენის გასაგებად.

10. 3 ლოგიკა/მოხსენებები

ფრაგმენტები/შედევრი/ლიმიტები, თერმული ბარათები მარშრუტების გასწვრივ.
იუსტიციის ცალკეული პანელები.

10. 4 SLO მაგალითები

"p99-300 ms 95-percentile დატვირთვისთვის; shed ≤ 0. 1%; error_ratio ≤ 0. 5%».
„კვოტის მინიმუმ 95% გარანტირებულია ინტერაქტიული კლასის გადატვირთვისას“.

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

11. 1 Nginx: rate limit + burst + კანარის სპლიტი

nginx map $http_x_canary $canary { default 0; 1 1; }

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;

upstream api_v1 { server 10. 0. 0. 1; }
upstream api_v2 { server 10. 0. 0. 2; }

server {
location /api/ {
limit_req zone=perip burst=20 nodelay;
if ($canary) { proxy_pass http://api_v2; break; }
proxy_next_upstream error timeout http_502 http_503 http_504;
proxy_pass http://api_v1;
}
}

11. 2 Envoy: circuit breaker + outlier detection

yaml circuit_breakers:
thresholds:
- priority: DEFAULT max_connections: 1000 max_pending_requests: 500 max_requests: 2000 outlier_detection:
consecutive_5xx: 5 interval: 10s max_ejection_percent: 50 base_ejection_time: 30s

11. 3 Istio: კვოტის წინა ტენანტი (რეზერვი ლაბელის საშუალებით)

yaml apiVersion: security. istio. io/v1 kind: AuthorizationPolicy spec:
selector: { matchLabels: { app: api } }
rules:
- when:
- key: request. headers[x-tenant]
values: ["gold"]
Next - RateLimitPolicy in the limit provider with a large quota pool for "gold."

11. 4 Kubernetes QoS ჰინტები

Guaranteed კრიტიკული პოდებისთვის (requests = limits).
PodPriority & Preemption: კრიტიკული ფონი დეფიციტით გამოისახება.
Topology Spread Constraints: განაწილება სტაბილურობის ზონებში.

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

გლობალური ლიმიტი „თვალისთვის“ არის მნიშვნელოვანი მომხმარებლებისგან ყალბი 429/ტაიმაუტები.
Retrai გარეშე jitter/idempotence - ქარიშხალი.
ტაიმაუტების (კლიენტი> სერვერი) დაბნეულობა და „ორმაგი სამუშაო“.
ზოგადი ქეში/ხაზები და ექსპერიმენტები - მონაცემთა დაბინძურება.
„ყოველთვის სტიკი“ საღი აზრის გარეშე არის არათანაბარი დატვირთვა/ცხელი კვანძები.
გამორთული outlier detection და „დამპალი“ ინსტანცია აფუჭებს კვირის მეტრებს.

13) განხორციელების შემოწმების სია

• შეაკეთეთ ტრაფიკი: კლასები/ტენანტები/მარშრუტები.
• დაუსვით მიზნობრივი ბიუჯეტები: RPS/კონექტორები/ბაიტი და p95/p99.
• ჩართეთ rate limit (ადგილობრივი + გლობალური), circuit breaker, outlier detection.
• კონფიგურაცია იმ კანარის ერთობლიობისთვის + მეტრიკებზე ავტომატური გადაზიდვა.
• დაწერეთ ტაიმაუტები/რეტრაები ექსპონენციალური backoff + gitter.
• ჩართეთ ECN/BBR (სადაც შესაძლებელია) და fq _ codel/HTB egress.
• ცალკეული აუზები/ქეში/ხაზები „ჩრდილებისა“ და ექსპერიმენტებისთვის.
• დაშბორდი: ლიმიტების მეტრიკა, რიგები, ლატენტობა, fairness.
• SLO და runbook: შედარების/გამოტოვების/ჩართვის კრიტერიუმები.

14) FAQ

Q: რა უნდა აირჩიოთ: shaping ან policing?
A: მომხმარებლის ბილიკებისთვის - shaping (გაბრტყელებული ფრჩხილების გარეშე). მომსახურების კლასებისთვის, „ფონ „/“ ბულკი “არის კრიტიკული ნაკადების დასაცავად.

Q: როგორ ავიცილოთ ქარიშხალი?
A: Gitterized backoff, მცდელობების ლიმიტი, idempotention, სერვერის რჩევები 'Retry-After', გლობალური კვოტები.

Q: Sticky ან hashing?
A: Sticky - როდესაც საჭიროა სესია/ქეში ლოკალიზებულია მომხმარებლისთვის; hashing - როდესაც საჭიროა sharding ერთგვაროვნება და სტაბილურობა.

Q: რას იძლევა HTTP/3/QUIC?
A: HOL TCP საკეტების გარეშე, დანაკარგების საუკეთესო წინააღმდეგობა, სწრაფი აღდგენა - შესამჩნევად ამცირებს p99/p999 კუდებს.

15) შედეგები

ეფექტური shaping და L7 მარშრუტიზაცია არის პოლიტიკოსის შეთანხმებული ნაკრები: პრიორიტეტები და კვოტები, სამართლიანი განაწილება, უსაფრთხო ლიმიტები და ჭკვიანი როუტინგი, რომელსაც მხარს უჭერს დაკვირვება და SLO. აღწერილი პრაქტიკის შემდეგ (HTB/fq _ codel/ECN ქვედა დონეზე და Envoy/Istio/Nginx/eBPF ზედა), თქვენ მიიღებთ პროგნოზირებადი ლატენტობის კუდებს, გადატვირთვის წინააღმდეგობას და კონტროლირებად, უსაფრთხო გამოშვებებს.