Usługi / Testy obciążeniowe
TestyProjektujemy i prowadzimy testy obciążeniowe k6 pod Waszą aplikację
Projektujemy i prowadzimy testy obciążeniowe k6 pod Waszą aplikację. Zaczynamy od ścieżek, które naprawdę obciążają system: logowanie, checkout, webhook, raport nocny. Potem składamy harness, dashboard i obserwację klastra. Wynik to decyzja o architekturze, limicie albo koszcie, z raportem dla zespołu.
Jak to składa się w całość
Od aplikacji do obciążenia, obserwacji i decyzji
Najpierw rozumiemy aplikację i model ruchu. Na tej podstawie składamy k6, Grafanę, klaster i widok sieci w jeden wniosek dla architektury. Harness zostaje w repozytorium, do powtórki przed pikem.
- Pierwszy test wydajności i ćwiczenie failover to dwa osobne terminy.
- Software house może dostać ten sam harness na kolejnym kliencie, ze zmianą modelu ruchu.
Projektujemy scenariusz z analityki i odtwarzamy ruch
k6, i JMeter tam gdzie już jest, dostaje model z produkcji: logowanie, checkout, webhook, raport nocny. Spike, soak i stress są osobnymi sesjami. Harness zostaje w repozytorium. Da się go odpalić przed pikem.
Model
Udział ścieżek z produkcji. Think time, cache, warmup. Bez tego test rozjeżdża się z ruchem klientów.
Rodzaje
Load, spike, soak, stress. Soak łapie wyciek po godzinach, nie po dwóch minutach.
Bramka
SLO w teście: p95, błąd, saturacja. Pipeline kończy się błędem, gdy budżet pęka.
Powtórka
Ten sam skrypt na stagingu klienta software house i przed kampanią.
Sprawdzamy p95, błędy i saturację razem z aplikacją
k6 bez obserwacji to RPS bez kontekstu. Patrzymy na p95 API, locki bazy, CPU, GC i długość kolejki. Decyzja wychodzi z pomiaru: indeks, cache, więcej poda, inny limit.
Korelacja
VU, latencja, błąd i saturacja na jednej osi czasu.
Warstwy
Aplikacja, baza, cache, kolejka, storage. Wąskie gardło ma nazwę.
Porównanie
Przed zmianą i po. Ten sam scenariusz, inny build.
Raport
Dla engineeringu i dla produktu: co pęka przy jakim ruchu.
Sprawdzamy limity i autoscaling pod ruchem
HPA, PDB i requesty widać dopiero pod obciążeniem. Test pokazuje, czy dobijacie do limitu CPU, do puli połączeń, czy do IP w węźle. Capacity planning wychodzi z pomiaru.
Limity
Throttle CPU wygląda jak wolne API. W teście to widać.
Skala
HPA, node pool, PDB. Czy nowy pod wstaje, zanim p95 ucieknie.
Sąsiedztwo
Noisy neighbor i limit namespace. Test na wspólnym klastrze ma osobne wnioski.
Koszt
Większy node group bez potrzeby jest wnioskiem FinOps, obok wniosku o wydajność.
Sprawdzamy ścieżkę, gdy wąskie gardło jest poza kodem
ntopng i metryki krawędzi pokazują, czy test uderza w aplikację, czy w firewall, NAT albo łącze. Chaos i failover są osobną sesją. Pierwszy pomiar wydajności robimy bez mieszania awarii.
Ścieżka
Generator, krawędź, load balancer, pod. Każdy skok latencji ma warstwę.
Aplikacje
TLS, baza, kolejka. Klasyfikacja ruchu podpowiada, co skalować.
Failover
Osobna sesja: utrata AZ, restart bazy, przełączenie DNS.
Granica
Test DDoS ma inny cel i inny playbook niż load test produktu.
Jak pracujemy
Od aplikacji klienta do decyzji o pojemności
Zaczynamy od analityki i SLO. Potem składamy harness i obserwację. Prowadzimy load, spike i soak. Zostawiamy wniosek i, gdy jest w zakresie, osobną sesję chaos.
- Model Sprawdzamy ścieżki, udział, SLO, środowisko i dane testowe. Z tego wychodzi scenariusz k6.
- Harness Składamy k6 w CI albo sesję sterowaną, dashboardy i baseline. Skrypt zostaje w repozytorium.
- Pomiar Prowadzimy load, spike i soak. Wąskie gardło dostaje nazwę warstwy: aplikacja, baza, klaster albo sieć.
- Decyzja Zmieniamy architekturę, limit albo koszt. Ponowny test potwierdza skutek.
Rozmowa
Omówimy aplikację, scenariusz ruchu i SLO
Na tej podstawie przygotujemy zakres: harness, sesje i raport.
Skontaktuj się