Operacje i → Zarządzanie Skalowanie infrastruktury operacyjnej

Skalowanie infrastruktury operacyjnej

1) Dlaczego i co jest uważane za „skalowanie”

Skalowanie to zdolność systemu platformy do zwiększenia przepustowości (RPS/TPS, połączenia, IOPS, przepustowość) i wolumenu danych bez utraty SLO i po kontrolowanych kosztach. W przypadku iGaming/fintech chodzi bezpośrednio o pieniądze: konwersję depozytów/zakładów, gry na żywo i rozliczenia.

• Utrzymywanie SLO przy X-krotnym wzroście obciążenia i sezonowych szczytach.
• Zapewnij przewidywalny czas skalowania (minuty, a nie godziny).
• Oszczędność gospodarki: koszt/RPS, koszt/transakcja, koszt/1k zdarzenia.

2) Skalowalne zasady platformy

1. Pierwszy poziom: podział na małe, bezpaństwowe usługi; status - w klastrach danych.
2. Ciśnienie wsteczne i kolejki: wygładzanie wybuchów, ochrona przed „burzami”.
3. Buforowanie na wszystkich warstwach: klient/edge/service/database.
4. Idempotencja i powtarzalność: bezpieczne rekolekcje, outbox, dedup.
5. Zależność ograniczona: czasy, wyłączniki, izolacja grodzi, limity prędkości.
6. Obserwowalność przez sygnały pojemności: zagłówek, p95/p99, lag, połączenia, kontyngenty.
7. Automatyczne skalowanie za pomocą szyn ochronnych: HPA/VPA/Cluster Autoscaler + warunki zatrzymania.
8. Multi-region według projektu: niezależne strefy wybuchu, dane lokalne, stabilne fylovery.

3) Planowanie przepustowości: jak „obliczyć, ile potrzebujesz”

Wejścia modelu: docelowy maksymalny TPS, profil ruchu (co godzinę), „ścieżki krytyczne”, współczynniki trafienia pamięci podręcznej, średnie ładunki użytkowe, SLO i limity dostawców.

• RPS → CPU/pods: 'pods = RPS p99_time/effective _ CPU _ in _ pod' (z marginesem 30-50%).
• Kolejki: "minimum _ speed _ of _ consumers ≥ peak _ speed _ of _ producers 1. 2`.
• Połączenia DB: 'max _ conns = active _ service _ pools medium _ pool _ size 1. 3`.
• Pamięć podręczna: rozmiar = „gorący zestaw roboczy w N minut” + 20-30% marży.
• Egress/CDN: peak egress = pik żądania średni rozmiar odpowiedzi (rozważyć kompresję).

Zagłówek: 20-40% cel na szczyt (według warstwy). Poniżej 15% → „zwiększenie pojemności” wyzwalacz.

4) Warstwy i wzory skalowania

4. 1 krawędź/CDN/WAF

Buforowanie krawędzi (TTL + SWR), geo-balans, kompresja, HTTP/2/3.
Limity prędkości na obwodzie przez IP/JWT/key, ochrona przed przepięciami.
Event fan-out (jackpoty, alerty na żywo) przez brokerów/pub/sub kanały.

4. 2 Backend-for-Frontend API Gateway

Poziomy skalowanie przez statle, dedykowane baseny przez niższych strumieni.
HPA według mierników biznesowych: RPS, p99, kolejka puli pracy - nie tylko procesora.

4. 3 kolejki asynchroniczne/strumieniowe (Kafka/Królik/Pulsar)

skala ze strony stron i konsumentów; unikać skew (klawiszy i dystrybucji).
Alerty lag + automatyczne skalowanie konsumentów; DLQ i powtórne tematy.
Zatrzymanie w ramach uzgodnień SLA i powtórzenie.

4. 4 bufory (Redis/Memcached)

Tryby klastra, repliki, zasady eksmisji (LFU), multiget, rurociąg.
Rozdzielenie zadań hot-key i tła, ograniczenia klienta i maks-polityka pamięci.

4. 5 Bazy danych

Czytaj repliki i czytanie routingu, łączenie połączeń.
Shading według regionu/najemcy/klucza.
CQRS: pisze do mistrza/lidera, czyta do replik.
Indeksowanie i zapisywanie partii przepływów pracy (outbox → stream → sink).
Archiwizacja i dane na gorąco/na zimno (wielopoziomowe).

4. 6 sklepów plików/obiektów

Multitreading, multipart downloads, CDN-front, asynchroniczne transformacje.
Kwoty dostawcy, czyszczenie ogona i budżet wyjścia.

4. 7 dostawców (PSP/KYC/Studios)

Multi-sprzedawca i quote/SLO/cost routing.
Wyłącznik + limit prędkości dla każdego dostawcy, kolejka retray, „tryby grace”.

5) Automatyczne skalowanie i osłony szyn

• HPA: метрика 'rps _ per _ pod', 'queue _ depth', 'p99 _ latency'; ' Value'.
• VPA: wytyczne dotyczące zasobów; aktualizacja poza szczytem.
• Cluster Autoscaler: spot + profile na żądanie z priorytetami.
• Budżet PodDis /Top Ograniczenia: jednolite w różnych strefach.
• Limit Range/ Quota: ochrona przed zanieczyszczeniami „pijanymi”.

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

• „Pauza & Rollback”, jeśli z kanaryjskim p99> 1. 3 × wartość wyjściowa 10 minut.
• „Zamrożenie skali” w doskonałym czasie, tylko w skali.
• „Stop retries” w 'open _ circuit = 1' do wąskich gardeł.

6) Wielregion: aktywa/aktywa i aktywa/zobowiązania

Regiony izolowane od wybuchu: niezależne klastry, lokalne tajemnice/kwoty.
Global routing: latency-/geo-based, health-probes, manual override.

• Hot - lokalnie + ewentualna replikacja (strumienie).
• Transakcje krytyczne - spójne według domeny (księga/salda).
• Odtwarzacze awaryjne: krok po kroku zmiana źródła, TTL, podręczniki rozgrzewające.
• Rozporządzenie w sprawie ćwiczeń (DR): Ćwiczenia kwartalne z celami RTO/RPO.

7) Wzorce sieci i usług

Siatka serwisowa: mTLS, retry/breaker, detekcja zewnętrzna, limity na niższy szczebel.
eBPF/Obserwowalność na L4/L7, granice połączeń, ochrona głowy linii.
Wewnętrzne bramy API dla S2S, ogólnego limitu stawek i audytu.
VPC/podsieci według stref wybuchu, kontrola NAT/Egress, peering z dostawcami.

8) Wydajność: Badania i dowody

Obciążenie i stres w czasie początkowym + najgorszy profil przypadku.
Moczenie (długie) - wycieki pamięci/deskryptora, wzrost opóźnień.
Chaos/gra-days: broker/provider/zone drop, „slow provider”.
Regresje perf w CI: zestaw scenariuszy referencyjnych i automatycznych bram.

9) Dane i przechowywanie: strategie wzrostu

Wzrost pionowy do sufitu → poziomy/shading.
Czytaj → replika/pamięć podręczna; rekordy → partia/asynchron/log.
Schemat migracji: rozszerzyć → migrate → kontrakt, bez globalnych zamków.
Archiwizacja: zimne partie do taniego magazynowania + nawodnienie na żądanie.
Wyszukiwanie: poszczególne indeksy (OpenSearch/Solr) z rurociągiem aktualizacji przyrostowych.

10) Zarządzanie dostawcami i kontyngentami

Karta kwotowa (TPS, okna, koszt); współczynnik _ wykorzystania alertów> 0. 9`.
Routing według kosztów/jakości (inteligentny routing).
Umowy OLA, SLO i proces zwiększania kwot.
Pula alternatyw i „gorące” przełączanie.

11) Obserwowalność i sygnały skalowania

• Pojemność zagłówka, слоси; 'queue _ lag/backlog growth'; 'kafka ISR'; 'db connections '/' repl lag'; 'redis evictions'; 'open _ circuit '/' retry _ rate'; 'quota _ usage'.
• Wskaźniki biznesowe: wskaźnik sukcesu/konwersja depozytu, czas rozpoczęcia gry.
• Koszt: koszt/RPS, koszt/1k połączenia.

• Przegląd pojemności (zagłówek, najwyższe ryzyko, szybkość spalania SLO).
• Stream & Queue Panel (lag/backlog, nasycenie konsumenta).
• DB & Cache (p99, połączenia, hit/eksmisje).
• Dostawcy i cytaty (TPS, timeouts, cost, switching).
• Zmiana bezpieczeństwa (przed/po zwolnieniu, kanarka, autoginiany).

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: Skalowanie jest opłacalne

Wskaźniki efektywności: koszt/RPS, koszt/depozyt, koszt/1k zdarzeń.
Rozmiar prawy: wiceprezes/rekomendacje, zawyżone raporty.
Spot/Preemptible for non-critical; Zarezerwowany/przeznaczony na ładunek podstawowy.
Egress budżet i buforowanie, CDN/edge offload.
Zbieranie i archiwizacja dzienników według poziomu wartości (hot vs cold).
Kwoty ostrzegawcze (miękka czapka) i auto-bilety na przedłużenie.

13) Procesy i ludzie

Zarządzanie zmianami: kanarki, ficheflagi, przystanki w regresjach.
Gotowość do incydentów: runbook'i „gdzie dodać pojemność”, „jak zmienić region”.
Planowanie szczytów: kalendarz meczów/turniejów/kampanii i okna dostawców.
Regularne dni gry i ćwiczenia DR.
Macierz własności: kto może „nacisnąć przycisk” na feilover/zwiększyć kwoty.

14) Listy kontrolne wdrażania

• Mapa ścieżek krytycznych i limitów (według warstwy), cel zagłówka ≥ 30%.
• HPA by Business Metrics + Cluster Autoscaler; Ograniczenia PDB/ .
• Kolejki na gorących ścieżkach, idempotency-keys, outbox.
• Caches: cele trafienia ≥ 90%, polityka eksmisji, kluczowe indeksy.
• DB: czytać repliki, basen połączeń, plan shading.
• Dostawcy: wielokrotny sprzedawca, kwoty, wyłączniki/rekolekcje.
• Tablice rozdzielcze „Capacity/Stream/DB/Providers”, wpisy z § 11.
• Autogaty kanaryjskie i przed/po uwolnieniu.
• DR playbook i jedno szkolenie częściowe feilover.

• Podgrzewanie buforów, przedskalowe repliki HPA/ASG, ciepłe repliki.
• Zwiększenie kwot dostawców, umożliwienie inteligentnych tras.
• Umożliwia tłumienie trybu nocnego dla niepodważalnych wpisów.
• Funkcja „bezpiecznego trybu” jest gotowa do natychmiastowej aktywacji.

15) Anty-wzory

Uaktualnienie pionowe „full stop” zamiast poziomego.
Wspólna pula gwintów/połączeń na wszystkich niższych poziomach.
Retrai na wąskich gardeł czasu, brak jitter → burza.
Nie ma histerezy w wpisach i zasadach skali → „piła”.
Pojedyncza globalna baza danych bez strzępienia danych i lokalizacji.
Ślepa wiara w sprzedawcę SDK bez kontroli timeout/retray/observability.
Brak ćwiczeń DR: feilover „tylko na papierze”.

16) Skalowalność KPI

Zgodność SLO na szczycie (p95/p99, wskaźnik sukcesu).
Zagłówek według warstwy w Prime Time.
MTTS (Mean Time To Scale) - do czasu uzyskania dodatkowych zasobów.
Czas rozdzielczości zaległości/opóźnienia - czas, w którym kolejki zapadają się po szczycie.
Zmiana współczynnika awarii na okres aktywnego wzrostu.
Koszt/RPS i oszczędności z pamięci podręcznej/CDN/krawędzi offload.
DR Gotowość: RTO/RPO w ćwiczeniach.

17) Przykłady „szybkich” szablonów

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

P: Co najpierw skalować?
Odp.: Wąskie gardła według desek rozdzielczych: czytniki kolejek/buforów/bazy danych. Gorące ścieżki (uruchomienie depozytu/zakładu/gry) są priorytetem.

P: Jak zrozumieć, że automatyczne skalowanie „pogarsza sytuację”?
Odp.: Zobacz korelację: skale- up, a p99/błędy nie poprawiają się - być może „skala problemu” (wąski strumień/kwota). Zawierają wyłączniki/degradację.

P: Czy zawsze potrzebujesz drugiego dostawcy?
Odp.: Dla ścieżek krytycznych, tak. W przeciwnym razie przynajmniej „tryb bezpieczny” z uproszczonym skryptem i pamięcią podręczną.

P: Aktywny-aktywny ила aktywny-pasywny?
Odp.: Jeśli wymagania RTO są niskie i wielu regionalnych graczy są aktywne. W przeciwnym razie należy zacząć od aktywnego pasywnego użycia feilover.