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

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

1) Не үшін және не үшін «масштабтау» деп есептеу керек

Масштабтау - бұл платформаның өткізу қабілетін (RPS/TPS, коннектілер, IOPS, throughput) және SLO-ны жоғалтпастан және бақыланатын өзіндік құнмен деректер көлемін арттырудың жүйелік қабілеті. iGaming/fintech үшін бұл тікелей ақша туралы: депозиттер/мөлшерлемелер конверсиясы, live-ойындар және есеп айырысулар.

• Жүктеменің X-еселенген өсуі мен маусымдық шыңдарда SLO ұстау.
• Болжамды масштабтау уақытын қамтамасыз ету (minutes, not hours).
• Экономиканы сақтау: cost/RPS, cost/транзакция, cost/1k оқиғалар.

2) Масштабталатын платформа қағидаттары

1. Көлденең-алдымен: ұсақ, stateless-сервистерге бөлу; жай-күйі - деректер кластерлерінде.
2. Back-pressure және кезектер: жарылыстарды тегістеу, «дауылдан» қорғау.
3. Барлық қабаттарда кэштеу: client/edge/service/DB.
4. Теңсіздік және қайталану: қауіпсіз ретрациялар, outbox, дедуп.
5. Шектеулермен тәуелділік: таймауттар, брейкерлер, bulkhead-оқшаулау, rate-limits.
6. Сыйымдылық сигналдары бойынша бақылау: headroom, p95/p99, lag, коннектілер, квоталар.
7. Гард-рельстері бар автоматты масштабтау: HPA/VPA/Cluster Autoscaler + тоқтау шарттары.
8. Multi-region by design: тәуелсіз blast-аймақтар, жергілікті деректер, тұрақты фейловерлер.

3) Capacity planning: қалай «қанша қажет екенін санау»

Модель кірістері: мақсатты ең жоғары TPS, трафик профилі (сағаттық), «сындарлы жолдар», кэш-хит коэффициенттері, орташа payload's, SLO және провайдерлер лимиттері.

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

Headroom: мақсат 20-40% шыңында (қабаттар бойынша). Төмен 15% → триггер «capacity uplift».

4) Масштабтау қабаттары мен паттерндері

4. 1 Edge / CDN / WAF

Шетіндегі кэштеу (TTL + SWR), гео-теңгерім, сығу, HTTP/2/3.
Rate-limits IP/JWT/кілті бойынша периметрде, жарылыстан қорғау.
Оқиғалар фанауты (джекпоттар, live-хабарландырулар) брокерлер/pub/sub арналары арқылы.

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

Статлес-поды бойынша көлденең масштабтау, даунстримдерге арналған пулдар dedicated.
Бизнес-метриктер бойынша HPA: RPS, p99, ворк-пулдағы кезек - тек CPU емес.

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

Партиялар мен консюмерлер бойынша масштаб; skew (кілттер мен үлестіруді) болдырмау.
Lag-алерты + консюмерлерді авто-масштабтау; DLQ және retry-топиктер.
Retention SLA реконсиляция және реплея астында.

4. 4 Кэштер (Redis/Memcached)

Кластерлік режимдер, репликалар, eviction-саясаттар (LFU), multiget, pipeline.
Hot-key және фондық тапсырмаларды бөлу, клиенттер мен max-memory policy лимиттері.

4. 5 Дерекқорлар

Оқу репликалары және оқу роутингі, connection pooling.
Өңір/тенант/кілттер ауқымы бойынша шардалау.
CQRS: жазбалар - шеберге/жетекшіге, оқу - репликаға.
Индекстеу және бэтч-жазу воркфлоу (outbox → stream → sink).
Мұрағаттау және ыстық/суық деректер (tiering).

4. 6 Файлдық/нысандық сақтау орындары

Көп ағындылық, multipart-жүктеу, CDN-front, асинхронды трансформациялар.
Провайдердің квоталары, «қалдықтарды» тазалау және egress бюджеті.

4. 7 Провайдерлер (PSP/KYC/студиялар)

Квоталар/SLO/құны бойынша мульти-вендор және маршруттау.
Әрбір провайдерге circuit breaker + rate-limit, ретрайлардың кезегі, «grace-режимдер».

5) Авто-масштабтау және гард-рейлер

• HPA: метрики `rps_per_pod`, `queue_depth`, `p99_latency`; `targetAverageValue`.
• VPA: ресурстар бойынша ұсынымдар; шыңнан тыс жаңарту.
• Cluster Autoscaler: артықшылықтары бар нод-топ профильдері (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.
• 'open _ circuit = 1' тар жерлер кезінде 'Stop retries'.

6) Multi-region: актив/актив және актив/пассив

Blast-оқшауланған өңірлер: тәуелсіз кластерлер, жергілікті құпиялар/квоталар.
Жаһандық роутинг: latency-/geo-based, health-probes, қолмен override.

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

7) Желілік және сервистік паттерндер

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

8) Өнімділік: тесттер мен дәлелдер

& Стресс прайм-тайм профиліне + worst-case.
Soak (ұзақ) - жадының/дескрипторларының кемуі, latency өсуі.
Chaos/game-days: брокердің/провайдердің/аймақтың құлауы, «баяу провайдер».
CI перф-регрессиялар: эталондық сценарийлер мен автоматты гейттер жиынтығы.

9) Деректер мен қоймалар: өсу стратегиялары

«Төбеге» дейін тік өсу → көлденең/шардинг.
Оқу → реплика/кэш; жазбалар → батчи/асинхрон/журнал.
Схемаларды көшіру: expand → migrate → contract, жаһандық бұғаттаусыз.
Мұрағаттау: суық партиялар арзан қоймаға + on-demand қайта гидрациялау.
Іздеу: жеке индекстер (OpenSearch/Solr).

10) Провайдерлерді және квоталарды басқару

Квота картасы (TPS, терезелер, құны); алерты 'usage _ ratio> 0. 9`.
Құны/сапасы бойынша роутинг (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 & Quotas (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-офлоад.
Логтарды құндылық деңгейі бойынша жинау және мұрағаттау (hot vs cold).
Ескерту квоталары (soft-cap) және кеңейтуге арналған авто-тикеттер.

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

Change Management: канареялар, фичефлагтар, регрессия кезіндегі тоқтаулар.
Дайындық оқиғасы: runbook 'және «сыйымдылықты қайда қосу керек», «аймақты қалай ауыстыру керек».
Шыңдарды жоспарлау: матчтар/турнирлер/науқандар күнтізбесі және провайдерлердің терезелері.
Тұрақты game-days және DR-жаттығулар.
Иелену матрицасы: кім фейловерге/квоталарды ұлғайтуға «түймешікті басады».

14) Енгізу чек-парақтары

• Күрделі жолдар мен лимиттердің картасы (қабаттар бойынша), headroom мақсаты ≥ 30%.
• Бизнес-метриктер бойынша HPA + Cluster Autoscaler; PDB/SpreadConstraints.
• Ыстық жолдардағы кезектер, idempotency-keys, outbox.
• Кэштер: 90% ≥ мақсаттар, evictions саясаты, негізгі индекстер.
• DB: read-replications, коннектілер пулы, шардинг жоспары.
• Провайдерлер: мульти-вендор, квоталар, брейкерлер/ретраилер.
• «Capacity/Stream/DB/Providers» дашбордтары, § 11-ден алерттар.
• Канарейка және автогейттер «шығарылғанға дейін/кейін».
• DR-плейбук және бір ішінара фейловер-тренинг.

• Кэштерді жылыту, HPA/ASG алдын ала скейл, warm-standby репликасы.
• Провайдерлердің квоталарын арттыру, smart-routing қосу.
• Критикалық емес қателіктер үшін night-mode басуды қосу.
• «safe mode» фичефлагы бірден қосылуға дайын.

15) Қарсы үлгілер

Көлденең орнына «тірекке дейін» тік апгрейді.
Барлық даунстримдердегі ағындардың/қосылыстардың жалпы пулы (head-of-line).
Жіңішке жерлердегі таймауттағы ретрайлер, джиттердің болмауы → дауыл.
Алерттер мен scale-саясаттарда гистерезис жоқ → «кесу».
Деректерді шардингісіз және оқшаулаусыз бірыңғай жаһандық БД.
Таймауттарды/ретрайларды/байқалушылықты бақылаусыз 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-офлоадтан үнемдеу.
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: бірінші масштабтау қандай?
А: Дашборд деректері бойынша тар орындар: кезектер/кэштер/ДБ оқу. Ыстық жолдар (депозит/мөлшерлеме/ойынды іске қосу) - басымдық.

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

Q: Әрдайым екінші провайдер қажет пе?
А: Сындарлы жолдар үшін - иә. Әйтпесе, ең болмағанда жеңілдетілген скрипт және кэш бар «safe mode».

Q: Active-active или active-passive?
A: Егер RTO талаптары төмен және өңірлік ойыншылар көп болса - active-active. Әйтпесе, пайдаланылған фейловермен active-passive бағдарламасынан бастаңыз.