Planowanie zdolności przesyłowych

1) Jakie jest planowanie zdolności przepustowej i dlaczego jest ona potrzebna

Planowanie zdolności jest systematycznym procesem oceny i zabezpieczenia zasobów potrzebnych do osiągnięcia docelowych SLO po minimalnych kosztach. Mówimy nie tylko o procesorze/pamięci, ale także o przepustowości sieci, pamięci masowej, bazach danych/buforach, kolejkach/autobusie eventowym, dostawcach zewnętrznych (płatności/CCM/zwalczaniu nadużyć finansowych), a także o zasobach ludzkich (dyżury, wsparcie).

• Wykonać SLO/SLA nawet w szczytach i rozkładach.
• Zminimalizować TCO i nadprzyrodzanie kapitału.
• Zmniejsz ryzyko wystąpienia incydentów z powodu wyczerpania zasobów (nasycenie → p99/błąd).
• Zapewnienie przewidywalności wydań i kampanii (marketingu, turniejów, najlepszych meczów).

2) Dane wejściowe i źródła prawdy

Obserwowalność: RPS/concatenation, p50/p95/p99, błąd, nasycenie (CPU, mem, disk IOPS, network pps/mbps), długość kolejki, limity szybkości.
Wydarzenia biznesowe: kalendarze kampanii, sezonowość (wieczory/weekendy/mega-wydarzenia), regiony/jurysdykcje.
Zadłużenie techniczne/funkcje: mapa drogowa wydań, zmiany architektoniczne (na przykład szyfrowanie, nowe rejestrowanie).
Dostawcy: kwoty i przepustowość płatności/CUS/mail/usługi zwalczania nadużyć finansowych.
Incydenty z przeszłości: gdzie jest wąskie gardło (baza danych, pamięć podręczna, L7 balancer, autobus, CDN, dysk).

3) Podstawowe pojęcia i wzory

Zagłówek - margines pojemności: 'zagłówek = (max _ stable _ RPS − actual _ RPS )/max _ stable _ RPS'.
Cel przy szczycie 20-40% (dla strumieni krytycznych).
Nasycenie - stosunek zajętego zasobu do dostępnego (CPU%, pamięć/GC, połączenia, deskryptory plików, IOPS, głębokość kolejki).
Stabilna przepustowość - prędkość, przy której p99 i prędkość błędu wykonują SLO przez długi czas (nie jednorazowy wybuch).
Pojemność jednostki (CU) - znormalizowana jednostka zasilania usługi (na przykład X RPS na podstronę vCPU = 1, RAM = 2 GiB).
Granica układu jest maksymalna bez degradacji: 'N _ pods × CU'. Ważne jest, aby uwzględnić współdzielone zależności (DB/cache/bus).

4) Model popytu: Prognozowanie

Serie statystyczne: tygodniowa/dzienna sezonowość, wakacje, finały sportowe, regionalne szczyty.
Kohorty: według krajów, dostawców płatności, urządzeń, segmentów VIP.
Delta wydarzeń: wpływ kampanii/pooches/releases/SEO.
„Co jeśli” (scenariusz planowania): + 50% do ruchu o 19: 00-22: 00; spadek dostawcy A → redystrybucja do B (+ 30% do opóźnienia).
Korekty w czasie rzeczywistym: nowcasting przez ołowiane mierniki (rewitalizacja sesji, kolejka do meczu, koszyki).

5) Model dostaw: gdzie łańcuch „pęka”

Przenośnik zapytania: Krawędź/CDN → L7 balancer → zastosowanie → cache → DB → zewnętrzny API → turn/tire → handlers/ETL.

• Pojemność (CU/instance), skalowalność (horyzont/wierzchołek), ograniczenia (połączenia, pps, IOPS), opóźnienia.
• Zasady awarii (ograniczenie prędkości, wyłącznik, degradacja).
• SLO są lokalne i ich wkład w e2e-SLO.

6) Margines błędu i budżet

Łączymy głowę z budżetem na błędy: mniej budżetu → więcej zapasów.
Dla przepływów krytycznych (płatność/weryfikacja) - sala główna powyżej, dla przepływów wtórnych - poniżej.
Rezerwy zimne/ciepłe: aktywowane w szczycie/wypadku.

7) Skalowanie: taktyka

HPA (według mierników obciążenia): RPS, opóźnienie, długość kolejki, SLIs użytkownika (lepsze niż CPU%).
VPA: korekta zasobów podam (ostrożnie ze stanowczym i p99 GC).
KEDA/adaptery: skalowanie przez zewnętrzne źródła (Kafka lag, długość listy Redis, głębokość CloudQueue).
Ciepłe baseny/ocieplenie: wstępnie podniesione instancje, aby uniknąć zimnego początku.
Podejście „load-as-Code”: zasady Autoskale/limit/timeout/retray są zmieniane i przeglądane.

8) Kolejki, ciśnienie wsteczne i kontrola ogona

Celem jest zapobieganie lawinopodobnemu wzrostowi p99.
Ograniczamy rozmiar równoległości i kolejki, wprowadzamy okna czasowe i idempotencję.
Hedging/Retry-budget: ograniczyć całkowity budżet użytkownika i systemu.
Wdzięczna degradacja: wyłączanie wtórnych funkcji podczas przeciążania.

9) DB, bufory i przechowywanie

DB: limit połączenia, rejestrowanie/FSync, indeksy, plan zapytania, lag repliki, hot-keys/tables, max TPS dla transakcji.
Keshi: współczynnik trafienia według segmentu, „burza zaginionych” podczas zwolnienia/niepełnosprawność, dystrybucja klucza.
Przechowywanie: IOPS/przepustowość, opóźnienia, kompresja, TTL, czyszczenie starych partii/migawki.
System migracji: rozszerzyć → migrate → kontrakt bez blokad stop.

10) Przepływy zdarzeń i ETL

Kafka/bus: przepustowość partii, lag, ISR, zagęszczenie, limit producenta/konsumenta.

ETL/partie: okna startowe, budżety runtime, przepustnica I/O

Idempotencja i dokładnie tak jak w przypadku przepływów krytycznych (płatności/salda).

11) Sieć i obwód

L4/L7 balancery: limity połączeń, zaległości syna, TLS offload, powtórne wykorzystanie sesji.
CDN/Edge: szerokość pasma, polityka pamięci podręcznej w celu zmniejszenia obciążenia pochodzenia.
Limity wewnątrz sieci: pps/mbps w sieci VPC/podsieci, egress-cost (FinOp).

12) Wielobranżowe, DR i jurysdykcje

Strategie: aktywny (GSLB/Anycast), aktywny-pasywny (gorący/ciepły/zimny DR).
N + 1 według regionów: Utrzymać utratę AZ/regionu przy zachowaniu strumieni rdzenia SLO.
Lokalizacja prawna: podział ruchu/danych według krajów, różne limity i SLO na dostawców.
Badania DR: regularne dni gry z rzeczywistym transferem obciążenia.

13) Dostawcy zewnętrzni: kwoty i trasy

Płatności/KYC/przeciwdziałanie oszustwom/poczta/SMS: TPS, kwoty pęknięcia, dzienne limity.
Multi-provider: routing według opóźnienia/sukcesu, SLO na dostawcę, auto-feiler.
Umowy SLA: zgodność e2e-SLO, kanały eskalacji, haki internetowe.

14) FinOps: Koszt i wydajność

TCO: compute + storage + network egress + licencje/dostawcy + duty.
Unit Economics: koszt 1k żądań/1 transakcja depozytowa/1 KYC.
Optymalizacja: prawy rozmiar, rabaty spot/prefix, hitrate pamięci podręcznej, dedup log/trace, poziom chłodzenia.
Przenoszenie obciążenia w czasie: nieistotne partie w „nocnych” oknach i tanich regionach.

15) Deski rozdzielcze i sprawozdawczość (minimalny zestaw)

• Obciążenie prądu vs stałe przepustowość na linki.
• Główna sala według usług i regionu; 24/72 godzinna prognoza.
• FinOps KPI: $/1k żądania, $/depozyt.

• Górne wąskie gardła (p99, nasycenie, opóźnienie), margines DR.

• sukces dostawcy/opóźnienia i ograniczenia; udział ruchu na trasach.

• Plan modernizacji/indeksu/optymalizacji, przewidywane oszczędności/wzrost zdolności produkcyjnych.

16) Procesy i role

RACI: Platform (infra/clusters/balancers), Database/Data (indeksy, replikacje), Service commands (profiling/cache), SRE (SLO, alerty), Sec/Compliance (crypto/logs), Finance (budget).
Rytm: tygodniowy przegląd przepustowości (plan działania, prognoza, ryzyko), miesięczne raporty FinOps, kwartalne badania DR-testy.
Zarządzanie zmianą: Główne kampanie/wydania idą capacity-gate (lista kontrolna poniżej).

17) Brama przepustowa

• Prognoza obciążenia szczytowego i „+ x% ogon awaryjny”.
• Dostępna sala główna dla głównych strumieni (płatności/ACC/login).
• Kwoty zostały potwierdzone dostawcom; alternatywne trasy są aktywne.
• Progi HPA/KEDA i ciepłej puli są skonfigurowane.
• Sprawdzone kolejki/limity i degradacja (playbooks ready).
• Akcje kanaryjskie i automatyczny zwrot są włączone.
• Sprawdzone deski rozdzielcze/alerty (spalanie, nasycenie, p99).
• Istotne są plany DR i kontakty eskalacyjne.

18) Anty-wzory

„Procesor <70% - wszystko jest w porządku”: ignorowanie limitów zależności (połączenia DB, IOPS, kolejki).
Scentralizowane „czarne pudełko” bez metryk per-link - nie można zrozumieć, gdzie jest limit.
Brak strategii pamięci podręcznej - uwolnienie brakuje zabić pochodzenie.
Hardcode limit retray bez budżetów jest burzą wniosków.
„Jeden dostawca płatności” jest punktem awarii na szczycie.
Ignorowanie ciepłych rezerw to zimny początek jako przyczyna incydentów.
Brak okresowych badań DR - plan nie działa w razie potrzeby.

19) Mini kosztorysy (przykład)

Usługa X: stabilny 350 RPS na pojemnik (vCPU = 1, RAM = 2 GiB). Celem jest 5000 RPS, zagłówek 25%.
Potrzebna moc = '5000/0. 75 = 6667 RPS ".
Podov = 'pułap (6667/350) = 20'. Plus ciepły basen 15% → 3 więcej strąków.
DB: limit 12k TPS, kredyt bieżący 9k TPS, 10 prognoz szczytowych. 5k TPS → zapasy 1. 5k (14%). Wymaga indeksów/shading/replik lub buforowania, aby zmniejszyć do 8. 5k.
Dostawca A (KYC): quota 120 rps, peak 95 rps, kampania + 40% → 133 rps> kontyngenty → routing 70% A/30% B.

20) Szablon wdrażania planowania zdolności

1. Opisz ścieżkę e2e i wąskie gardła.
2. Wprowadź CU i zmierz trwałą przepustowość każdej warstwy.
3. Konfiguracja nasycenia i metryki p99 na wszystkich linkach.
4. Generowanie kalendarza wydarzeń/kampanii/wydawania.
5. Zbuduj prognozę kohorty i scenariusze co-jeśli.
6. Pin headroom per-thread i per-region (wiążący dla budżetu błędu).
7. Skonfiguruj HPA/VPA/KEDA + ciepłe baseny, limity/przekładki/kolejki.
8. Sprawdź kwoty dostawcy, włącz wiele tras.
9. Zbierz deski rozdzielcze i cotygodniowy przegląd pojemności rytmu.
10. Kwartalnik - ćwiczenia DR i przegląd modelu.

21) Najważniejsze

Planowanie przepustowości to możliwy do opanowania pakiet prognoz, ograniczeń architektonicznych i kosztów, a nie ". "Kiedy każda warstwa ścieżki e2e ma mierzoną pojemność, a strategie zagłady i degradacji są związane z budżetem SLO i błędów, to szczytowe obciążenia, kampanie i wypadki przestają być niespodzianką. Podejście to zmniejsza ryzyko incydentów, stabilizuje wskaźniki biznesowe i optymalizuje koszty.