Skalowanie pionowe

Zwiększanie wydajności przez dodanie zasobów (CPU, RAM) do istniejącej maszyny. Prostsze, ale ograniczone możliwościami pojedynczego serwera.

Skalowanie pionowe (ang. vertical scaling, potocznie scaling up) to zwiększanie wydajności systemu przez dokładanie zasobów do jednej, istniejącej maszyny — więcej rdzeni CPU, więcej RAM-u, szybszy dysk NVMe zamiast HDD, mocniejsza karta sieciowa. Mówiąc obrazowo: nie kupujesz drugiego serwera, tylko dopychasz ten, który już masz, żeby udźwignął więcej. To przeciwieństwo skalowania poziomego (horizontal scaling), gdzie dorzucasz kolejne maszyny i rozkładasz ruch między nie.

Działa to prosto, i to jest jego największa zaleta. Aplikacja nie musi wiedzieć, że nagle ma dwa razy więcej RAM-u — po prostu działa szybciej i obsłuży więcej żądań. Nie potrzebujesz load balancera, nie kombinujesz z synchronizacją sesji między węzłami, nie martwisz się o spójność danych w rozproszonym klastrze. Dlatego skalowanie pionowe to często pierwszy ruch przy bazach danych typu PostgreSQL czy MySQL, które źle znoszą rozbijanie na wiele węzłów (sharding to ból).

Problem w tym, że trafisz w sufit. Pojedyncza maszyna ma fizyczny limit — nie wsadzisz nieskończenie dużo RAM-u do jednej płyty głównej, a najmocniejszy procesor i tak kiedyś się kończy. No i jest pojedynczy punkt awarii: pada serwer, pada cała usługa.

Przykład z praktyki

Masz instancję w AWS EC2 typu t3.medium (2 vCPU, 4 GB RAM) i baza danych zaczyna się dławić. Skalowanie pionowe to po prostu zmiana typu instancji na większą, np. m5.xlarge (4 vCPU, 16 GB RAM):

  1. zatrzymujesz instancję (aws ec2 stop-instances --instance-ids i-0abc123),
  2. zmieniasz typ (aws ec2 modify-instance-attribute --instance-id i-0abc123 --instance-type m5.xlarge),
  3. startujesz z powrotem.

Trzy komendy, kilka minut przestoju. Dla porównania skalowanie poziome wymagałoby auto-scaling group, load balancera i przemyślenia, jak aplikacja trzyma stan.

Na co uważać

  • Downtime. W większości chmur zmiana rozmiaru wymaga restartu maszyny. Jeśli zależy Ci na zero-downtime, sama pionowa droga nie wystarczy.
  • Koszt rośnie nieliniowo. Instancja dwa razy mocniejsza potrafi kosztować więcej niż dwa razy tyle. Na pewnym poziomie taniej wyjdzie kilka mniejszych maszyn.
  • Mit „dorzucę RAM i będzie dobrze”. Jeśli wąskim gardłem jest źle napisane zapytanie SQL albo brak indeksu, mocniejszy sprzęt tylko zamaskuje problem na chwilę. Najpierw profiluj, potem dokupuj.

Pojęcia powiązane: skalowanie poziome (horizontal scaling), load balancing, auto-scaling, sharding, pojedynczy punkt awarii (SPOF), elastyczność chmury (cloud elasticity).