Autoskalowanie

Automatyczne dostosowywanie liczby zasobów obliczeniowych do bieżącego obciążenia. Dodaje instancje przy wzroście ruchu i usuwa je, gdy ruch spada.

Autoskalowanie (ang. autoscaling) to mechanizm, który automatycznie dopasowuje liczbę zasobów obliczeniowych do bieżącego obciążenia aplikacji. Gdy ruch rośnie, system sam dokłada instancje, kontenery albo pody; gdy ruch spada, nadmiarowe zasoby są usuwane. Dzięki temu nie musisz o trzeciej w nocy ręcznie klikać „dodaj serwer”, a faktura za chmurę nie eksploduje, bo nie płacisz za moc, której nikt nie używa.

Jak to działa

Autoskalowanie opiera się na pętli: metryka → próg → akcja. System monitoruje jakąś wartość (najczęściej zużycie CPU, pamięci, liczbę żądań na sekundę albo długość kolejki), porównuje ją z zdefiniowanym progiem i podejmuje decyzję o zmianie liczby zasobów. Zwykle ustawiasz minimum i maksimum instancji, żeby skalowanie nie uciekło ci ani w dół do zera (chyba że tego chcesz), ani w górę do bankructwa.

Warto rozróżnić dwa kierunki. Skalowanie poziome (horizontal, scale out/in) dokłada lub usuwa całe instancje — to klasyczne autoskalowanie. Skalowanie pionowe (vertical, scale up/down) zmienia rozmiar pojedynczej instancji, dokładając jej CPU czy RAM. W praktyce częściej spotkasz to pierwsze, bo dorzucenie kolejnej kopii aplikacji jest prostsze niż restart z większą maszyną.

Przykład z praktyki

W Kubernetes robi to Horizontal Pod Autoscaler (HPA). Powiesz mu: „trzymaj średnie CPU podów na poziomie 50%, w zakresie od 2 do 10 replik”, a on resztę załatwi sam:

kubectl autoscale deployment sklep --cpu-percent=50 --min=2 --max=10

Gdy w Black Friday ruch wystrzeli, HPA zauważy, że CPU przekroczyło 50%, i podbije liczbę podów. Po świętach, gdy obciążenie wróci do normy, zredukuje je z powrotem do dwóch. W chmurze odpowiednikami są AWS Auto Scaling Groups, GCP Managed Instance Groups czy Azure Virtual Machine Scale Sets.

Na co uważać

  • Czas startu. Jeśli nowa instancja wstaje 3 minuty, autoskalowanie nie uratuje cię przed nagłym spike’em — zareaguje za późno. Stąd pomysły jak warm pools czy skalowanie z wyprzedzeniem.
  • Flapping. Zbyt czułe progi powodują, że system na zmianę dodaje i usuwa instancje. Ratunkiem są okresy stabilizacji (cooldown) i histereza.
  • Mit „autoskalowanie = oszczędność zawsze”. Źle dobrane metryki potrafią skalować w górę bez sensu. Skalowanie ma sens tylko wtedy, gdy aplikacja jest bezstanowa albo poprawnie obsługuje współdzielony stan.

Pojęcia powiązane

Load balancing, elastyczność (elasticity), Kubernetes HPA i Cluster Autoscaler, skalowanie poziome i pionowe, serverless, infrastructure as code, SLA i SLO.