Операциялар жана башкаруу → Операциялык инфраструктураны масштабдоо

Операциялык инфраструктураны масштабдоо

1) Эмне үчүн жана эмне үчүн "масштабдоо"

Масштабдоо - бул SLO жоготуусуз жана контролдонуучу наркы менен платформанын системалык кубаттуулугу (RPS/TPS, коннектилер, IOPS, throughput) жана маалымат көлөмү. iGaming/fintech үчүн бул түздөн-түз акча жөнүндө: депозиттерди/коюмдарды которуу, live-оюндар жана эсептешүүлөр.

• Жүктүн X эселенген өсүшү жана сезондук туу чокулары менен SLO сактоо.
• Алдын ала масштабдоо убактысын камсыз кылуу (minutes, not hours).
• экономика сактоо: cost/RPS, cost/бүтүм, cost/1k окуялар.

2) Масштабдуу платформанын принциптери

1. Horizontal-биринчи: майда бөлүү, stateless-кызмат; мамлекеттик - маалыматтар кластерлеринде.
2. Back-pressure жана кезек: жылмакай, "бороон" каршы коргоо.
3. Бардык катмарларда кэш: client/edge/service/DD.
4. Идемпотенттүүлүк жана кайталануучулук: коопсуз ретра, outbox, дедуп.
5. Чектөөлөр менен көз карандылык: таймауттар, брейкерлер, bulkhead-изоляция, rate-limits.
6. Сыйымдуулуктун сигналдары боюнча байкоо: headroom, p95/p99, lag, коннектилер, квоталар.
7. Гард-рельстер менен Auto-масштабдоо: HPA/VPA/Cluster Autoscaler + токтоо шарттары.
8. Көп-аймак дизайн: көз карандысыз blast зоналары, жергиликтүү маалыматтар, туруктуу Failovers.

3) Capacity planning: кантип "эсептөө керек"

Моделдин кириштери: максаттуу жогорку TPS, трафик профили (сааттык), "критикалык жолдор", кэш-хит коэффициенттери, орточо payloads, SLO жана провайдерлердин лимиттери.

• RPS → CPU/жол: 'жол = RPS p99_time/натыйжалуу _ CPU _ жол' (30-50% камдык менен).
• Кезектер: 'минималдуу _ ылдамдык _ консумерлер ≥ эң жогорку _ ылдамдык _ продюсерлер 1. 2`.
• DB-байланыштар: 'max _ conns = активдүү _ пулдар _ орто _ pool _ size 1. 3`.
• Cache: көлөмү = "N мүнөт үчүн ысык working-set" + 20-30% запасы.
• Egress/CDN: pik egress = pik суроо-жооп орточо өлчөмү (кысуу эске алуу).

Headroom: максаттуу 20-40% туу чокусунда (катмарлары боюнча). Төмөндө 15% → триггер "capacity uplift".

4) катмарлары жана масштабдуу үлгүлөрү

4. 1 Edge / CDN / WAF

четине кэш (TTL + SWR), гео-баланс, кысуу, HTTP/2/3.
Rate-limits IP/JWT/ачкыч боюнча периметри боюнча, жарылуудан коргоо.
Иш-чаралардын күйөрманы (джекпот, жандуу эскертүүлөр) брокерлер/pub/sub каналдары аркылуу.

4. 2 API-шлюз/Backend-for-Frontend

Statless-pod боюнча горизонталдуу масштабдоо, downstream боюнча dedicated пулдар.
HPA бизнес-метрика боюнча: RPS, p99, Work Pool кезек - гана CPU эмес.

4. 3 Асинхрондук кезек/агымы (Kafka/Rabbit/Pulsar)

Партиялардын жана консюмерлердин масштабы; качуу skew (ачкычтар жана бөлүштүрүү).
Lag-alert + auto-масштабдоо Консумерлер; DLQ жана retry-топиктер.
SLA реконсиляция жана реплика астында Retention.

4. 4 Кэш (Redis/Memcached)

Кластердик режимдер, репликалар, eviction-policies (LFU), multiget, pipeline.
Hot-key жана арткы милдеттерди бөлүштүрүү, кардарларга чектөөлөрдү жана max-memory policy.

4. 5 Маалымат базалары

Read-replications жана роутинг окуу, connection pooling.
Аймак/Тенант/ачкыч диапазону боюнча шардана.
CQRS: жазуулар - мастер/лидер, окуу - реплика.
Индекстөө жана бетч жазуу workflow (outbox → stream → sink).
Архив жана ысык/муздак маалыматтар (tiering).

4. 6 File/объект сактоо

Көп агымы, multipart жүктөмөлөр, CDN-front, асинхрондук өзгөрүүлөр.
Провайдердин квоталары, "куйруктарды" тазалоо жана бюджет egress.

4. 7 жөнөтүүчүлөр (PSP/KYC/студиялар)

Көп сатуучу жана маршруттук/SLO/наркы.
Ар бир провайдер үчүн Circuit breaker + rate-limit, ретрациялардын кезеги, "grace-режимдери".

5) Auto-масштабдоо жана Гард-Rail

• HPA: метрики `rps_per_pod`, `queue_depth`, `p99_latency`; `targetAverageValue`.
• VPA: ресурстар боюнча сунуштар; чокусунан тышкары жаңыртуу.
• Cluster Autoscaler: артыкчылыктары менен NOD Group профилдери (spot + on-demand).
• PodDisruptionBudget/TopologySpreadConstraints: зоналар боюнча бир калыпта.
• LimitRange/ResourceQuota: "мас" деплой коргоо.

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 × baseline 10 мүнөт.
• "Freeze scale-down" прайм-тайм, бир гана scale-up.
• "Stop retries" качан 'open _ circuit = 1' тар жерлерге.

6) Multi-аймак: актив/актив жана актив/пассив

Blast-обочолонгон аймактар: көз карандысыз кластерлер, жергиликтүү сырлар/квоталар.
Global роутинг: latency-/geo-based, health-probes, кол override.

• Hot - жергиликтүү + eventual репликация (агымдар).
• Критикалык транзакциялар - домен боюнча макулдашылган (ledger/баланстар).
• Failover Playbook: кадам булагы өзгөртүү, TTL, кэш жылытуу.
• көнүгүү регламенти (DR): RTO/RPO максаттары менен чейрек машыгуу.

7) Тармактык жана сервистик үлгүлөр

Service Mesh: mTLS, retry/breaker, outlier detection, per-downstream лимиттери.
eBPF/Observability боюнча L4/L7, байланыш чеги, башчысы-of-line коргоо.
S2S үчүн ички API-шлюздары, жалпы rate-limit жана аудит.
VPC/blast аймактар, NAT/Egress көзөмөлдөө, сатуучулар менен peering.

8) аткаруу: тесттер жана далилдер

Prime-Time + worst-case профилине жүктөө жана стресс.
Soak (узакка созулган) - эстутумдун/дескриптордун агып чыгышы, latency өсүшү.
Chaos/оюн-күндөр: брокердин/провайдердин/аймактын кулашы, "жай провайдер".
Перф-регрессия в CI: эталондук сценарийлердин жана автоматтык дарбазалардын жыйындысы.

9) Маалыматтар жана сактоо: өсүү стратегиялары

"шыпка" чейин тик өсүшү → горизонталдуу/шардинг.
Окуу → реплика/кэш; → батчи/асинхрон/журнал жазуулар.
схемалар көчүрүү: expand → migrate → contract, эч кандай глобалдык бөгөт коюу.
Archivation: муздак бөлүктөрү арзан сактоо + on-demand кайра-гидрация.
Издөө: жеке индекстер (OpenSearch/Solr) менен пайплайн инкременталдык тактоо.

10) Провайдерлерди жана квоталарды башкаруу

Квота картасы (TPS, терезелер, наркы); alerty 'usage _ ratio> 0. 9`.
наркы/сапаты боюнча роутинг (Smart Routing).
ОЛА СЛО макулдашуулары жана квоталарды жогорулатуу процесси.
Альтернативалардын бассейни жана "ысык" которуу.

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 & Quotas (TPS, убакыт, наркы, которуу).
• 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-оффлоад.
Баалуулук боюнча логдорду чогултуу жана архивдөө (hot vs cold).
Квота эскертүүлөр (soft-cap) жана авто-билеттер кеңейтүү үчүн.

13) Процесстер жана адамдар

Change Management: канарейка, phicheflages, регрессия токтотуу.
Инцидент-даярдык: runbook 'и "кайда кубаттуулукту кошуу керек", "аймакты кантип которуу керек".
Чокуларды пландаштыруу: матчтардын/турнирлердин/кампаниялардын календары жана провайдерлердин терезелери.
Үзгүлтүксүз оюн-күн жана DR-машыгуулар.
Ээлик Matrix: ким Feylover боюнча "баскычын басуу "/квоталарды көбөйтүү.

14) Киргизүүнүн чек-баракчалары

• Маанилүү жолдордун жана чектердин картасы (катмарлар боюнча), headroom максаты ≥ 30%.
• HPA бизнес-метрика + Cluster Autoscaler; PDB/SpreadConstraints.
• ысык жолдордо кезек, idempotency-keys, outbox.
• Кэш: hit максаттары ≥ 90%, evictions саясаты, негизги индекстер.
• DB: Read-replications, Pool connections, sharding планы.
• Провайдерлер: көп сатуучу, квота, брейкер/ретра.
• Dashbord "Capacity/Stream/DB/Providers", Параграф 11.
• Канарейка жана автогейттер "бошотулганга чейин/кийин".
• DR playbook жана бир жарым-жартылай Feylover окутуу.

• Жылытуу кэш, алдын ала скейлинг HPA/ASG, warm-standby реплика.
• Провайдерлердин квоталарын жогорулатуу, smart-routing киргизүү.
• Night-mode critic эмес alerts үчүн басуу киргизүү.
• Ficheflag "safe mode" заматта иштетүүгө даяр.

15) Анти-үлгүлөрү

горизонталдуу ордуна тик апгрейд "басым".
Бардык downstream (head-of-line) боюнча агымдардын/байланыштардын жалпы бассейни.
Таймауттарда узун жерлерди ретрациялоо, життердин жоктугу → бороон.
Эч кандай гистерезис алерт жана scale-саясатчылар → "кесүү".
Unified Global DD эч кандай шардинг жана маалыматтарды локалдаштыруу.
SDK сатуучуга сокур ишеним убакыт/retraut/байкоо көзөмөлсүз.
DR-машыгуу жоктугу: Feylover "кагаз бетинде гана".

16) KPI масштабдуулугу

SLO-туу чокусунда сактоо (p95/p99, success rate).
Headroom прайм-тайм катмарлары боюнча.
MTTS (Mean Time To Scale) - кошумча ресурстар пайда болгонго чейин.
Backlog/Lag Resolution Time - чокусунан кийин кезек кулап убакыт.
активдүү өсүү мезгилине Change Failure Rate.
Cost/RPS жана кэш/CDN/edge-оффлоад үнөмдөө.
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: Dashboard маалыматтары боюнча тар жерлер: кезек/кэш/DD окуу. Ысык жолдор (депозит/коюм/оюнду баштоо) - артыкчылыктуу болуп саналат.

Q: авто-масштабдоо "жаман кылат" деп кантип түшүнүүгө болот?
A: корреляцияны көрүңүз: scale-up ↑, ал эми p99/каталар жакшырбайт - балким, сиз "маселени масштабдап" жатасыз (тар даунстрим/квота). Брейкерлерди/деградацияны күйгүзүңүз.

Q: Мен ар дайым экинчи камсыздоочу керек?
A: оор жолдор үчүн - ооба. Болбосо, жок дегенде жөнөкөйлөтүлгөн скрипт жана кэш менен "коопсуз режим".

Q: Active-active или active-passive?
A: Эгерде RTO талаптары төмөн жана аймактык оюнчулар көп болсо - active-active. Болбосо, иштеген Feylover менен active-passive менен башталат.