ოპერაციები და მენეჯმენტი - ოპერაციული ინფრასტრუქტურის მასშტაბები

ოპერაციული ინფრასტრუქტურის მასშტაბები

1) რატომ და რა ითვლება „მასშტაბად“

სკალირება არის პლატფორმის სისტემური უნარი გაზარდოს გამტარუნარიანობა (RPS/TPS, კონექტორები, IOPS, throughput) და მონაცემების მოცულობა SLO დაკარგვის გარეშე და კონტროლირებადი ღირებულებით. IGaming/fintech- ისთვის ეს პირდაპირ ფულია: დეპოზიტების/განაკვეთების კონვერტაცია, ცოცხალი თამაშები და გამოთვლები.

• შეინახეთ SLO დატვირთვის X-ჯერ გაზრდით და სეზონური მწვერვალებით.
• უზრუნველყოს პროგნოზირებადი მასშტაბის დრო (minutes, not hours).
• ეკონომიკის შენარჩუნება: cost/RPS, cost/გარიგება, cost/1k მოვლენები.

2) ფართომასშტაბიანი პლატფორმის პრინციპები

1. ჰორიზონტალური პირველი: დაყოფა მცირე, სტატუსის სერვისებად; მდგომარეობა - მონაცემთა მტევნებში.
2. Back-pressure და რიგები: აურზაური, დაცვა „ქარიშხლებისგან“.
3. ქეშირება ყველა ფენაზე: client/edge/service/BD.
4. Idempotence და განმეორება: უსაფრთხო retrais, outbox, dedup.
5. შეზღუდვებთან დამოკიდებულება: ტაიმაუტები, ბრეიკერები, ბულკჰედის იზოლაცია, საბადოები-ლიმიტები.
6. დაკვირვება ტევადობის სიგნალებზე: headroom, p95/p99, lag, კონექტორები, კვოტები.
7. მანქანის მასშტაბირება გარდერობის ფრენებით: HPA/VPA/Cluster Autoscaler + გაჩერების პირობები.
8. მრავალფუნქციური დიზაინი: დამოუკიდებელი blast ზონები, ადგილობრივი მონაცემები, სტაბილური ყალბი.

3) კაპიტალური გეგმა: როგორ „გამოვთვალოთ რამდენი საჭიროა“

მოდელის შესასვლელები: სამიზნე მწვერვალი TPS, ტრაფიკის პროფილი (საათობრივი), „კრიტიკული ბილიკები“, ქეშების ჰიტების კოეფიციენტები, საშუალო პაილოდი, SLO და პროვაიდერების ლიმიტები.

• RPS - CPU/პოდები: 'პოდები = RPS p99 _ time/ეფექტური _ CPU _ pode' (რეზერვით 30-50%).
• რიგები: 'მინიმალური _ სიჩქარე _ საკონსულოები - პიკი _ სიჩქარე _ მწარმოებლები 1. 2`.
• DB კონექტორები: 'max _ conns = აქტიური _ puls _ სერვისები საშუალო _ pool _ size 1. 3`.
• ქეში: ზომა = „ცხელი სამუშაო ნაკრები N წუთში“ + 20-30% რეზერვი.
• Egress/CDN: მწვერვალი egress = მოთხოვნის პიკი საშუალო ზომით (გაითვალისწინეთ კომპრესია).

Headroom: მიზანი 20-40% მწვერვალზე (ფენებზე). 15% -ზე ქვემოთ არის „კაპიტალის uplift“ ტრიგერი.

4) მასშტაბის ფენები და ნიმუშები

4. 1 Edge / CDN / WAF

ქეშირება ზღვარზე (TTL + SWR), გეო ბალანსი, შეკუმშვა, HTTP/2/3.
Rate-limits პერიმეტრზე IP/JWT/გასაღები, დაცვისგან დაცვა.
მოვლენების გულშემატკივარი (ჯეკპოტები, ცოცხალი სიგნალები) ბროკერების/არხების მეშვეობით/pub/sub.

4. 2 API კარიბჭე/Backend-for-Frontend

ჰორიზონტალური სკალირება სტატუსის პოდებზე, dedicated აუზზე dounstrimes.
HPA ბიზნეს მეტრებში: RPS, p99, ხაზი ქურდის აუზში - და არა მხოლოდ CPU.

4. 3 ასინქრონული ხაზები/ნაკადი (Kafka/Rabbit/Pulsar)

პარტიებისა და კონსიუმერების მასშტაბები; თავიდან აიცილოთ skew (გასაღებები და განაწილება).
Lag-alertes + კონსიუმერების მასშტაბები; DLQ და retry ტოპები.
Retention ქვეშ SLA reconsilation და replay.

4. 4 კეში (Redis/Memcached)

კლასტერული რეჟიმები, რეპლიკები, საღამოს პოლიტიკა (LFU), მულტიგეტი, მილის.
Hot-key და ფონის დავალებების გამიჯვნა, მომხმარებელთა შეზღუდვები და მაქს-მემორიალური პოლიტიკა.

4. 5 მონაცემთა ბაზა

კითხვის რეპლიკები და როუტინგი, კომუნიკაცია.
შარდვა რეგიონში/ტენანტი/გასაღების დიაპაზონი.
CQRS: ჩანაწერები - სამაგისტრო/ლიდერისთვის, კითხვა - რეპლიკებში.
ინდექსირება და batch წერის workflow (outbox stream sink).
არქივირება და ცხელი/ცივი მონაცემები.

4. 6 ფაილური/ობიექტის საცავი

მულტიპარტიული დატვირთვა, CDN-front, ასინქრონული ტრანსფორმაციები.
პროვაიდერის კვოტები, კუდის გაწმენდა და egress ბიუჯეტი.

4. 7 პროვაიდერები (PSP/KYC/სტუდიები)

მრავალ გამყიდველი და მარშრუტიზაცია კვოტებით/SLO/ღირებულებით.
Circuit breaker + rate-limit თითოეული პროვაიდერისთვის, retrain ხაზი, „grace რეჟიმები“.

5) მანქანის სკალირება და გარდერობი

• HPA: метрики `rps_per_pod`, `queue_depth`, `p99_latency`; `targetAverageValue`.
• VPA: რეკომენდაციები რესურსებზე; განაახლეთ მწვერვალის მიღმა.
• Cluster Autoscaler: spot + on-demand პროფილები პრიორიტეტებით.
• PodDisrupite Budget/TopologySpreadConstraints: ერთგვაროვნება ზონებში.
• LimitRange/ResourceÉta: დაცვა „მთვრალი“ დეპლოებისგან.

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler spec:
scaleTargetRef: {apiVersion: apps/v1, kind: Deployment, name: api-gw}
minReplicas: 8 maxReplicas: 200 metrics:
- type: Pods pods:
metric:
name: rps_per_pod target:
type: AverageValue averageValue: "120"
- type: Pods pods:
metric:
name: p99_latency_ms target:
type: AverageValue averageValue: "280"
behavior:
scaleUp:
stabilizationWindowSeconds: 90 scaleDown:
stabilizationWindowSeconds: 300

• „Pause & Rollback“, თუ კანარზე p99> 1. 3 × ბასელინი 10 წუთი.
• „Freeze scale-down“ პრემიერ დროში, მხოლოდ scale-up.
• „Stop retries“ 'Open _ circuit = 1' ვიწრო ადგილებში.

6) Multi-region: აქტივი/აქტივი და აქტივი/ვნება

Blast იზოლირებული რეგიონები: დამოუკიდებელი მტევანი, ადგილობრივი საიდუმლოებები/კვოტები.
გლობალური როუტინგი: latency-/geo-based, health-probes, სახელმძღვანელო override.

• ცხელი - ადგილობრივად + საღამოს რეპლიკაცია (ნაკადები).
• კრიტიკული გარიგებები შეთანხმებულია დომენზე (ledger/ბალანსები).
• Failover playbuks: წყაროს ეტაპობრივი ცვლილება, TTL, თბება ქეში.
• სავარჯიშო წესები (DR): კვარტალური ტრენინგი RTO/RPO მიზნებით.

7) ქსელური და მომსახურების ნიმუშები

Service Mesh: mTLS, retry/breaker, outlier detection, limita- ს პერფორმანსი.
eBPF/Observability on L4/L7, ნაერთების ლიმიტები, დაცვა head-of-line- ისგან.
შიდა API კარიბჭეები S2S- ისთვის, ზოგადი ზღვარი-ლიმიტი და აუდიტი.
VPC/ქვესახეები blast ზონებში, NAT/Egress- ის კონტროლი, გამყიდველები.

8) პროდუქტიულობა: ტესტები და მტკიცებულებები

Load & stress პრემიერ დროის პროფილში + worst-case.
Soak (გრძელი) - მეხსიერების/აღწერილობების გაჟონვა, ლატენტობის ზრდა.
Chaos/game-days: ბროკერის/პროვაიდერის/ზონის ვარდნა, „ნელი პროვაიდერი“.
Perf რეგრესია CI- ში: საცნობარო სცენარებისა და ავტომატური კარიბჭეების ნაკრები.

9) მონაცემები და შენახვა: ზრდის სტრატეგიები

ვერტიკალური სიმაღლე „ჭერზე“ არის ჰორიზონტალური/შარდინგი.
წაკითხული რეპლიკები/ქეში; ჩანაწერები - ბრძოლები/ასინქრონი/ჟურნალი.
სქემების მიგრაცია: expand - migrate - contract, გლობალური საკეტების გარეშე.
არქივი: ცივი ნაწილები იაფი საცავში + on-demand re- ჰიდრაცია.
ჩხრეკა: ინდივიდუალური ინდექსები (OpenSearch/Solr) პიპლინური დროებითი განახლებებით.

10) პროვაიდერების და კვოტების მართვა

კვოტების რუკა (TPS, ფანჯრები, ღირებულება); ალერტები 'usage _ ratio> 0. 9`.
Routing ღირებულებით/ხარისხით (smart routing).
OLA-SLO ხელშეკრულებები და კვოტების გაზრდის პროცესი.
ალტერნატივის აუზი და ცხელი გადართვა.

11) დაკვირვება და მასშტაბის სიგნალები

• Capacity headroom по слоям; `queue_lag/backlog growth`; `kafka ISR`; `db connections`/`repl lag`; `redis evictions`; `open_circuit`/`retry_rate`; `quota_usage`.
• ბიზნეს მეტრიკა: success rate/ანაბრის კონვერტაცია, თამაშის დაწყების დრო.
• ღირებულება: cost/RPS, cost/1k calls.

• Capacity Overview (headroom, ტოპ რისკები, burn-rate SLO).
• Stream & Queue Panel (lag/backlog, consumer saturation).
• DB & Cache (p99, კონექტორები, hit/evictions).
• Providers & Étas (TPS, Timeouts, ღირებულება, გადართვა).
• Change Safety (გამოსვლის შემდეგ, კანარი, ავტო კარიბჭე).

ALERT HeadroomLowAPI
IF capacity_headroom{layer="api"} < 0. 15 FOR 10m

ALERT KafkaBacklogAtRisk
IF (consumer_lag > 5e6 AND rate(consumer_lag[5m]) > 5e4) AND (hpa_desired == hpa_max) FOR 10m

ALERT DBConnectionsNearMax
IF active_conns / max_conns > 0. 85 FOR 5m

ALERT ProviderQuota90
IF usage_quota_ratio > 0. 9 FOR 5m

12) FinOps: მასშტაბები მომგებიანია

ეფექტურობის კოეფიციენტები: cost/RPS, cost/ანაბარი, cost/1k მოვლენები.
Right-sizing: VPA/რეკომენდაციები, მოხსენებები „over-provisioned“ შესახებ.
Spot/Preemptible არ არის კრიტიკული; Reserved/Committed საბაზო დატვირთვისთვის.
Egress ბიუჯეტი და ქეშირება, CDN/edge offload.
ლოგოების შეგროვება და არქივირება ღირებულების თვალსაზრისით (ცხელი vs cold).
გამაფრთხილებელი კვოტები (რბილი-cap) და გასაფართოებელი მანქანები.

13) პროცესები და ადამიანები

Change Management: canares, icheflages, გაჩერებები რეგრესიის დროს.
ინციდენტი მზადყოფნაა: runbook 'და „სად დაამატოთ კონტეინერი“, „როგორ გადავიდეს რეგიონი“.
მწვერვალების დაგეგმვა: მატჩების/ტურნირების/კამპანიების კალენდარი და პროვაიდერების ფანჯრები.
რეგულარული თამაშის დღეები და DR სწავლებები.
საკუთრების მატრიცა: ვისაც შეუძლია „ღილაკის დაწვა“ ყალბი/კვოტების გაზრდა.

14) განხორციელების ჩეკის ფურცლები

• კრიტიკული გზებისა და შეზღუდვების რუკა (ფენების მიხედვით), მიზანი headroom - 30%.
• HPA ბიზნეს მეტრებში + Cluster Autoscaler; PDB/SpreadConstraints.
• რიგები ცხელ ტრასებზე, idempotence-keys, outbox.
• კეში: hit მიზნები - 90%, evictions პოლიტიკა, ძირითადი ინდექსები.
• DB: read შენიშვნები, კონექტორების აუზი, sharding გეგმა.
• პროვაიდერები: მრავალ გამყიდველი, კვოტები, ბრეიკერები/რეინჯერები.
• დაშბორდები „Capacity/Stream/DB/Providers“, ალერტები § 11-დან.
• Canareika და autogates „გამოშვების შემდეგ“.
• DR ფლეიბუკი და ერთი ნაწილობრივი ფეილოვერის ტრენინგი.

• გაათბეთ ქეში, წინასწარი სკაილი HPA/ASG, warm-standby რეპლიკები.
• პროვაიდერების კვოტების ზრდა, ჭკვიანი როუტინგის ჩართვა.
• ღამის ჩახშობის ჩართვა არაკრიტიკული ალერტებისთვის.
• Ficheflag „safe mode“ მზად არის მყისიერი ჩართვისთვის.

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

ვერტიკალური განახლება „გაჩერებამდე“ ჰორიზონტალის ნაცვლად.
ნაკადების/ნაერთების მთლიანი აუზი ყველა downstrim- ზე (head-of-line).
ვიწრო ადგილების ტაიმაუტები, ჯიტტერის ნაკლებობა და ქარიშხალი.
ალერტებსა და სკალელ პოლიტიკოსებში არ არსებობს ჰისტერეზია - „ხერხი“.
ერთიანი გლობალური მონაცემთა ბაზა Sharding და მონაცემთა ლოკალიზაციის გარეშე.
ბრმა რწმენა SDK მოვაჭრეებისთვის ტაიმაუტების/რეპრესიების/დაკვირვებების კონტროლის გარეშე.
DR ვარჯიშების არარსებობა: ფეილოვერი „მხოლოდ ქაღალდზე“.

16) KPI მასშტაბურობა

SLO დაცვა მწვერვალზე (p95/p99, success rate).
Headroom ფენებში პრემიერ დროში.
MTTS (Mean Time To Scale) - დამატებითი რესურსების გამოჩენამდე.
Backlog/Lag Resolution Time არის მწვერვალების დაჭერის დრო.
Change Failure Rate აქტიური ზრდის პერიოდისთვის.
Cost/RPS და დანაზოგი ქეში/CDN/edge offload.
DR Readiness: RTO/RPO ვარჯიშებში.

17) სწრაფი შაბლონების მაგალითები

partitions(topic="bets") = ceil(peak_msgs_per_sec / target_msgs_per_partition)
consumers = min(partitions, max_pods); rebalance_on: skew > 1. 5x scale_up_if: lag > 5e5 && rate(lag[5m]) > 5e4

max_connections = poolers pool_size 1. 3 read_routing: primary (write), replicas (read majority)
shard_key: tenant_id or region_id

maxmemory-policy: allkeys-lfu cluster-replicas: 1 evict-alert: rate(evictions[5m]) > 0 && used_mem/limit > 0. 8

guardrails:
- metric: api_p99_ms, threshold: 1. 3 baseline_1d, window: 10m, action: pause_and_rollback
- metric: error_rate, threshold: 2 baseline_1d, window: 5m, action: pause max_step: 10%
step_interval: 15m

18) FAQ

Q: რა უნდა გავაკეთოთ პირველ რიგში?
A: ვიწრო ადგილები დაშბორდების მიხედვით: ხაზები/ქეში/BD კითხვა. ცხელი გზები (ანაბარი/განაკვეთი/თამაშის დაწყება) პრიორიტეტულია.

Q: როგორ გავიგოთ, რომ მანქანის მასშტაბი „უარესდება“?
A: იხილეთ კორელაცია: scale-up, და p99/შეცდომები არ უმჯობესდება - შესაძლოა, „პრობლემის მასშტაბები“ (ვიწრო downstrim/კვოტა). ჩართეთ ბრეიკერები/დეგრადაცია.

Q: ყოველთვის საჭიროა მეორე პროვაიდერი?
ა: კრიტიკული გზებისთვის - დიახ. წინააღმდეგ შემთხვევაში, მინიმუმ „safe mode“ გამარტივებული სცენარით და ქეში.

Q: Active-active или active-passive?
A: თუ RTO- ს მოთხოვნები დაბალია და ბევრი რეგიონალური მოთამაშეა - აქტიური. წინააღმდეგ შემთხვევაში, დაიწყეთ აქტიური ფასიანი ქაღალდით.