Skalowanie poziome (ang. horizontal scaling, czasem scale-out) to zwiększanie wydajności systemu przez dokładanie kolejnych maszyn lub instancji, które dzielą się obciążeniem — zamiast pompowania mocy w jeden, coraz większy serwer. Masz za mało? Dorzucasz drugi, trzeci, dziesiąty węzeł i rozkładasz na nie ruch. To podejście domyślne dla systemów rozproszonych i chmury, gdzie maszyny traktujesz jak „bydło, nie zwierzątka domowe” — bezimienne, wymienne, łatwe do dodania i usunięcia.
Jak to działa
Zamiast jednego potężnego serwera stawiasz pulę identycznych instancji, a przed nimi load balancer, który rozdziela żądania (round robin, least connections itd.). Dzięki temu możesz dokładać moc niemal liniowo i przeżyć awarię pojedynczego węzła — reszta przejmie ruch. Klucz to bezstanowość: instancja nie może trzymać sesji ani plików lokalnie, bo następne żądanie tego samego użytkownika może trafić gdzie indziej. Stan ląduje w wspólnym miejscu — Redis, baza danych, zewnętrzny storage.
Przeciwieństwem jest skalowanie pionowe (vertical scaling): więcej CPU/RAM w jednej maszynie. Prostsze, ale ma sufit (i to drogi), a sam serwer pozostaje pojedynczym punktem awarii.
Przykład z praktyki
W Kubernetesie skalowanie poziome to codzienność. Masz Deployment i jednym poleceniem zwiększasz liczbę replik poda:
kubectl scale deployment api --replicas=5
A jeśli chcesz, żeby działo się to automatycznie pod obciążeniem, dodajesz Horizontal Pod Autoscaler:
kubectl autoscale deployment api --min=3 --max=10 --cpu-percent=70
Od teraz Kubernetes sam dorzuca pody, gdy CPU przekroczy 70%, i zwija je, gdy ruch spadnie. Podobnie działają Auto Scaling Groups w AWS czy managed instance groups w GCP.
Na co uważać
Najczęstszy błąd to próba skalowania poziomego aplikacji, która trzyma stan lokalnie — sesje w pamięci procesu albo uploady na dysku instancji. Po dodaniu drugiego węzła użytkownicy losowo się wylogowują, a pliki „znikają”. Drugi mit: że skalowanie poziome jest zawsze tańsze i lepsze. Dochodzi narzut na load balancer, spójność danych i ruch sieciowy między węzłami — czasem mocniejsza pojedyncza maszyna jest po prostu rozsądniejsza. Pamiętaj też, że baza danych zwykle nie skaluje się poziomo tak łatwo jak warstwa aplikacji (potrzebujesz replikacji czy shardingu).
Pojęcia powiązane
Skalowanie pionowe, load balancing, aplikacje bezstanowe (stateless), autoscaling, systemy rozproszone, sharding, replikacja, wysoka dostępność (high availability).