Planowanie przepustowości i wzrost obciążenia

Krótkie podsumowanie

1. Prognoza popytu (tendencja bazowa + sezonowość + zdarzenia).

2. Model obciążenia (model otwarty dla Internetu).

3. Główna sala i błędny budżet.

4. Skalowanie (horyzont/pionowy/auto) + ograniczenia (prędkość graniczna/ciśnienie wsteczne).

5. Finanse: $/1000 RPS, $/ms p95, TCO według scenariusza.

Warunki i mierniki

Przepustowość: RPS/QPS/CPS - rzeczywista przepustowość.
Latency p95/p99: docelowe SLO dla ścieżek użytkownika.
Nasycenie: procesor/pamięć/IO/FD/połączenia/kolejki ładowania.
Wskaźnik błędów: 5xx/timeout/429, błędny budżet na dany okres.
Zagłówek: udział wolnej mocy w ruchu szczytowym (zalecany ≥ 30%).
Wybuch: krótkotrwały skok (sekundy/minuty), Spike: gwałtowny wzrost × N.

Podstawowe modele i wzory

Prawo małe (dla systemów kolejkowych)

L = λ W

L jest średnią liczbą zapytań w systemie, jest średnią szybkością wejścia (RPS), W jest średnim czasem w systemie. Przydatne do oszacowania głębokości kolejki.

Współczynnik obciążeń ()

ρ = λ / μ

• - prędkość robocza (RPS przy 100% procesora). W sytuacji, w której nie ma opóźnień → 1, opóźnienie wzrasta nieliniowo - należy zachować punkt roboczy, a ≤ 0. 6–0. 75.

Współczynnik bezpieczeństwa/margines

Capacity_required = Peak_load (1 + Headroom) Degradation_factor

Gdzie Degradation_factor odpowiada za awarię N, degradację pamięci podręcznej, utratę jednego PoP/region (np., 1. 2).

Prognoza popytu

1. Historia: dzienne/tygodniowe profile, sezonowość, korelacja z wydarzeniami (mecze/strumienie/wypłaty).
2. Wydarzenia: współczynniki scenariusza (dzień regularny × 1, turniej × 2. 3, końcowy × 3. 5).
3. Źródła wahań: kampanie marketingowe, wydania, anomalie botów.
4. Jednostki prognostyczne: RPS na trasach (login, lobby, katalog, płatności), CPS TLS, QPS DB, dysk IOPS, egress Gbps.
5. Zaufanie: Zachowaj dwa scenariusze - konserwatywny i agresywny.

Symulacja obciążenia

Open-model (Poisson-like arrival): prawdopodobne dla publicznych API/web - zastosowanie do rozmiaru.
Model zamknięty (VU + think-time): odpowiedni do sekwencji wewnętrznych; połączyć.
Mieszaniny trasy: frakcje wagowe na punkty końcowe; obejmują nie tylko „gorące”, ale także „drogie” (rejestracja, depozyt).
Nie zapomnij: retras, kolejki, limity partnerskie (PSP, API osób trzecich).

Projekt marginesu bezpieczeństwa

Cel zagłówka: ≥ 30% do szczytu (dla Internetu); dla rdzenia płatności i ścieżek krytycznych - 40-50%.
N + 1/N + 2: wytrzymać awarię 1-2 instancji/stref bez naruszania SLO.
Wielobranżowy: każdy region pociąga za sobą ≥ 60% całkowitego szczytu (aby przetrwać utratę sąsiada).
Tryb degradacji: wyłączyć funkcje wtórne, zmniejszyć ładunek użytkowy, włączyć reakcje pamięci podręcznej/dźgnięcia.

Rozmiar według warstwy

Sieć/krawędź

CPS/RPS z przodu, TLS-shake p95, wznowienie ≥ 70%, egress Gbps.
Anycast/Geo-routing, limity CDN/WAF (uzgodnić z wyprzedzeniem).
Margines: link/aplink ≥ szczyt × 1. 3, zaległości SYN z marginesem UDP/443 dla H3.

Balancery/Pełnomocnicy

RPS do instancji, otwarte połączenia, kolejki, procesor/IRQ.
Utrzymywanie i łączenie połączeń - zmniejszyć połączenia do backendów.
Stado: α ≤ 0. 7, ogranicznik CPS/RPS na trasę.

Aplikacje

Docelowa wydajność na rdzeń (RPS/rdzeń) na płaskowyżu.
Puli (thread/DB/HTTP) - nie należy uruchamiać limitów.
Magazyn: autoskale do 60-70% CPU i opóźnienie (p95).

Bufory

Współczynnik trafienia, głośność hotset, eksmisja, replika.
Rezerwa: pamięć ≥ 1. 2 × hotset, zagłówek sieci ≥ 30%.

Bazy danych

QPS/TPM, żądania p95, zamki, bufor cache, WAL/replication lag.
Napędy IOPS i opóźnienia są kluczem do p95.
Margines: punkt operacyjny CPU 50-65%, replika lag <target; plan chardingowy i odczyt-repliki.

Dyski/pamięć masowa

IOPS (4k/64k), przepustowość, koszt fsync.
Stado: IOPS ≥ szczyt × 1. 5, opóźnienie p95 w oknie docelowym; oddzielne puli dla dziennika/danych.

GPU/ML (jeśli istnieje wniosek online)

Próbki/s, opóźnienia, zagłówek VRAM, łączenie.
Margines: parametry partii pod obciążeniem „piły”, GPU ciepłej puli.

Automatyczne skalowanie

HPA/KEDA: metryki procesora + niestandardowe (opóźnienie p95, RPS, kolejka).
Ciepłe baseny: wstępnie podgrzane instancje przed wydarzeniami.
Skalowanie kroków: kroki z chłodzeniem, aby nie „piła”.
Czas reakcji: celować w T_scale ≤ 1-2 minut dla warstwy przedniej; dla DB - z góry.

Ograniczenia i ciśnienie wsteczne

Ograniczenie stawek - IP/ASN/device/route; kwoty partnerskie.
Kolejki z TTL, odmowa „grzeczny” (429/via gray-vol) przed czasem.
Idempotencja: klucze do płatności; przekłady z budżetem + jitter.
Żądanie zawalenia/SWR: Nie budzić pochodzenia podczas rozprysku.

Przykład szybkiego obliczania

Biorąc pod uwagę: 35k RPS API prognoza szczytowa, p95 ≤ 250 ms, średni czas obsługi 8 ms na instancję przy 60% CPU → α 125 RPS/rdzeń, 8 rdzeni na instancję → ~ 1000 RPS/instancja.
Etap 1 (brak zapasów): 35 instancji.
Etap 2 (zagłówek 30%): 35 × 1. 3 = 46.
Etap 3 (awaria jednego AZ, + 20%): 46 × 1. 2 ≈ 55.
Krok 4 (zaokrąglanie + gorąca rezerwa 10%): 61 instancji.
Sprawdź: Na blankie35k/( 61k) wg 0. 57 - w strefie zielonej.

Model finansowy (FinOps)

$/1000 RPS według warstwy (krawędź, serwer proxy, aplikacja, DB).
$/ms p95 (koszt redukcji ogona).
Scenariusze TCO: na żądanie vs zarezerwowane vs spot (z ryzykiem przerw).
Plan przepustowości: kwartalne limity konta/klastra, kwoty w chmurze, limity PSP/CDN.

Gotowy do awarii i DR

Multi-AZ/region: każde ramię - 60% obciążenia.
Plan awaryjny: wycofać Anycast, przełączanie GSLB, TTL ≤ 60-120 s.
Zależności krytyczne: limity PSP/bankowe, dostawca wtórny.
Okresowe ćwiczenia: dzień gry z PoP/BG/cache off.

Obserwowalność i wczesne sygnały nasycenia

Wzrost p95/p99 i kolejki ze stabilnym wejściem.
Kropla pamięci podręcznej, wzrost pochodzenia.
Retransmitty/wzrost ECN CE, spadek wznowienia TLS.
Wzrost 429/timeout i powtórny tempo.
Dla baz danych - wzrost konfliktu, czas punktu kontrolnego, WAL fsync.

Praktyki operacyjne

Miesięczny przegląd zdolności: fakt vs plan.
Zmień okna na zdarzenia: zamrażaj jądra i limity.
Prewarm (CDN/DNS/TLS/baseny) 10-30 min przed szczytem.
Wersioning limitu: fix rate-limit/pools configs in Git.

iGaming/specyficzne dla fintechu

Turnieje/mecze: spike + profile plateau, szare trasy dla botów, oddzielne limity rejestracji/depozytu.
Płatności/PSP: dostawca/metody kwot, trasy awaryjne, puli egress-IP, SLA Time-to-Wallet.
Dostawcy treści: dystrybucja przez studio, hot caches, shard baseny.
Antifraud/AML: ograniczenie zasad/punktacji, degradacja do reguł światła na szczycie.

Lista kontrolna implementacji

• Prognoza szczytu (baza/sezon/wydarzenia), dwa scenariusze.
• SLO/niewłaściwy budżet i docelowa sala robocza ≥ 30%.
• Rozmiar według warstwy (krawędź/proxy/app/cache/DB/IO/network).
• Limit stawek, kolejka, idempotencja, ponowny proces budżetowy.
• HPA/KEDA + ciepłe baseny; plan promocji przed wydarzeniem.
• Multi-AZ/region, playbooks awaryjne, TTL i GSLB.
• Kwoty w chmurze/PSP/CDN są spójne i udokumentowane.
• Obserwowalność: deski rozdzielcze pojemności, wczesne sygnały nasycenia.
• Ćwiczenia DR i regularny przegląd zdolności.

Częste błędy

Plan dla przeciętnego RPS bez ogonków/kolców.
ρ≈0. 9 „na papierze” - opóźnienie wybucha przy najmniejszym hałasie.
Ignorowanie limitów usług zewnętrznych (klaster PSP/CDN/DB).
Nie ma trybów degradacji i backpressure są awarie kaskadowe.
Automatyczna skala bez wstępnego ogrzewania - zarządza „po” szczycie.
Pojedynczy zagłówek dla wszystkich warstw - wąskie gardło migruje.

Mini playbooks

Przed wydarzeniem szczytowym (T-30 min)

1. Zwiększ minRepliki/cel HPA, włącz ciepłą pulę.
2. Ogrzewanie CDN/DNS/TLS/połączenia, podgrzewanie buforów.
3. Zwiększenie limitów i kwot puli PSP zgodnie z ustaleniami.
4. Włącz szare trasy/filtry bot, wąskie ciężkie punkty końcowe.

Częściowa utrata regionu

1. GSLB → sąsiedni region, TTL 60-120 s.
2. Włącz tryb degradacji (pamięć podręczna/uproszczona realizacja transakcji).
3. Redystrybucja limitów PSP/egress-IP.
4. Komunikacja stanu, p95/kontrola błędów.

Przepięcie w rekolekcjach

1. Zmniejszyć retry-budget, włączyć backoff + jitter.
2. Włącz zawalenie żądania/SWR na GET.
3. Tymczasowo zaostrzyć limit stawki dla „hałaśliwych” zasilaczy ASN.

Wynik

Planowanie przepustowości to prognoza popytu + model inżynieryjny + margines bezpieczeństwa + dźwignie operacyjne. Sformalizować SLO i zagłówek, rozważyć zewnętrzne ograniczenia, automatycznego skalowania i degradacji, zmierzyć „koszt na milisekundę” i przeprowadzić regularne przeglądy pojemności. Następnie wzrost obciążenia zmieni się nie w ryzyko, ale w możliwą do opanowania metrykę biznesową.