Ta treść została automatycznie przetłumaczona z ukraińskiego.
Kiedy system przestaje radzić sobie z rosnącym obciążeniem, istnieją dwa podstawowe sposoby na zwiększenie jego wydajności: w pionie i w poziomie.
Na pierwszy rzut oka to terminy IT, ale w rzeczywistości zasada jest bardzo prosta i występuje nawet w zwykłym budownictwie.
Krótko:
W pionie — uczynić jeden element mocniejszym.W poziomie — dodać więcej takich samych elementów.
W pionie
W pionie (vertical scaling, lub scale up) oznacza zwiększenie mocy już istniejącego komponentu.
Na przykład mamy serwer z:
- 4 CPU;
- 16 GB pamięci RAM;
- SSD o pojemności 500 GB.
System zaczyna działać wolno. Zamiast dodawać kolejny serwer, możemy zainstalować:
- 16 CPU;
- 64 GB RAM;
- szybszy SSD.
Serwer pozostał jeden, ale stał się znacznie mocniejszy.
To jest w pionie.
Przykład z budownictwa
Wyobraźmy sobie budynek, który musi wytrzymać większe obciążenie.
Podejście w pionie — wzmocnić istniejącą konstrukcję:
- użyć grubszych belek;
- zwiększyć przekrój słupów;
- dodać zbrojenie;
- uczynić fundament mocniejszym.
Nie budujemy drugiego budynku. Uczynić istniejący budynek silniejszym.
Przykład z energii słonecznej
Jest system słoneczny z jednym inwerterem o mocy 5 kW.
Jeśli potrzebujemy więcej mocy, podejście w pionie może wyglądać jak wymiana go na inwerter o mocy 10 kW.
Było:
5 kW → 1 inwerter
Stało się:
10 kW → 1 mocniejszy inwerter
To samo można zrobić z baterią: zamiast akumulatora o pojemności 5 kWh zainstalować większy, na przykład 10 kWh.
W poziomie
W poziomie (scale out) działa inaczej.
Zamiast uczynić jeden komponent mocniejszym, dodajemy nowe komponenty.
Na przykład jeden serwer już działa na granicy możliwości.
Zamiast przechodzić z 4 CPU na 16 CPU, można postawić jeszcze trzy takie same serwery.
Było:
[ Serwer ]
Staje się:
[ Serwer ] [ Serwer ] [ Serwer ] [ Serwer ]
Każdy serwer z osobna może być niezbyt mocny, ale razem mogą obsługiwać znacznie więcej zapytań.
Budownictwo: drugi budynek
Tutaj w poziomie również łatwo sobie wyobrazić.
Załóżmy, że jeden budynek nie wystarcza do pomieszczenia ludzi.
Wariant w pionie:
zbudować wyższy budynek lub uczynić go większym.
W poziomie:
zbudować jeszcze jeden budynek.
Na przykład, zamiast jednego dużego magazynu o powierzchni 10 000 m² można mieć dwa magazyny po 5 000 m².
Zaletą takiego podejścia jest to, że jeśli jeden obiekt przestanie działać, drugi może kontynuować pracę.
Ta właściwość jest bardzo ważna w IT.
Energia słoneczna: więcej paneli czy mocniejszy inwerter?
Tutaj różnicę widać szczególnie dobrze.
Wyobraźmy sobie system:
10 paneli słonecznych × 500 W = 5 kW
Jeśli potrzebujemy więcej generacji, są dwa warianty.
Podejście w pionie
Zainstalować mocniejsze panele.
Na przykład:
10 × 700 W = 7 kW
Liczba paneli nie zmieniła się, ale każdy stał się mocniejszy.
To analogia do scale up.
Podejście w poziomie
Zostawić panele po 500 W, ale dodać jeszcze 4:
14 × 500 W = 7 kW
Uzyskaliśmy mniej więcej tę samą zainstalowaną moc, ale zwiększyliśmy liczbę elementów.
To scale out.
Oczywiście w rzeczywistym systemie słonecznym wszystko jest bardziej skomplikowane: trzeba uwzględnić napięcie stringów, MPPT, maksymalny prąd inwertera, powierzchnię dachu, orientację paneli i inne ograniczenia.
Jednak zasada pozostaje ta sama.
IT: najbardziej oczywisty przykład
Wyobraźmy sobie stronę, która obsługuje 100 zapytań na sekundę.
Jeden serwer działa na 90% CPU.
Scale up
Bierzemy ten serwer i zwiększamy jego moc:
4 CPU → 16 CPU
Teraz jeden serwer może obsługiwać, na przykład, 400 zapytań na sekundę.
Zaletą jest to, że architektura pozostaje stosunkowo prosta.
Ale jest problem: konkretny serwer ma fizyczną granicę.
Nie można w nieskończoność zwiększać liczby CPU i RAM.
Scale out
Inna opcja — dodać serwery.
Na przykład:
1 serwer × 100 zapytań/s
przekształca się w:
4 serwery × 100 zapytań/s = 400 zapytań/s
Przed serwerami instaluje się load balancer, który rozdziela zapytania między nimi.
Na przykład:
┌── Serwer 1
│
Użytkownicy → Load Balancer ── Serwer 2
│
├── Serwer 3
│
└── Serwer 4
Jeśli obciążenie wzrośnie jeszcze bardziej, można dodać nowe serwery.
100 → 200 → 300 → 400 → 500 serwerów...
W tym tkwi główna siła poziomego skalowania.
A co się stanie, jeśli jeden serwer się zepsuje?
To jedna z najważniejszych różnic.
Przy pionowym skalowaniu często mamy jedną dużą punkt awarii.
Użytkownicy ↓ [ DUŻY SERWER ]
Jeśli ten serwer ulegnie awarii, cały system może przestać działać.
Przy poziomym skalowaniu:
┌── Serwer 1
├── Serwer 2
Użytkownicy → LB ──┼── Serwer 3
└── Serwer 4
Jeśli Serwer 2 się zepsuje, balansujący może przestać kierować na niego ruch.
Inne serwery będą kontynuować pracę.
Dlatego poziome skalowanie często stosuje się nie tylko dla wydajności, ale także dla odporności na awarie.
Ale poziome skalowanie jest trudniejsze
Na pierwszy rzut oka może się wydawać, że scale out zawsze jest lepszy.
W rzeczywistości nie.
Jeśli mamy jeden serwer, aplikacja może przechowywać dane lokalnie:
Aplikacja
↓
Dysk lokalny
Kiedy serwerów staje się dziesięć, pojawia się pytanie:
gdzie przechowywać dane?
Jeśli użytkownik załadował plik na Serwer 1, a następne zapytanie trafiło na Serwer 7 — Serwer 7 musi jakoś uzyskać ten plik.
Dlatego przy poziomym skalowaniu często trzeba dodawać:
- load balancer;
- wspólne przechowywanie;
- oddzielną bazę danych;
- cache;
- kolejki wiadomości;
- mechanizmy synchronizacji;
- monitorowanie;
- automatyczne skalowanie.
To znaczy, że zyskujemy więcej możliwości, ale także więcej złożoności architektonicznej.
Dlaczego nie używać tylko poziomego skalowania?
Bo nie wszystko można po prostu podzielić między kilka maszyn.
Na przykład baza danych może być trudniejsza do skalowania w poziomie niż serwer www.
Jeśli strona ma 20 serwerów, to jeszcze nie oznacza, że można tak samo łatwo postawić 20 kopii bazy danych i uzyskać 20-krotną wydajność.
Dlatego rzeczywiste systemy często stosują oba podejścia jednocześnie.
Na przykład:
Load Balancer
↓
┌────────────┼────────────┐
↓ ↓ ↓
Serwer Serwer Serwer
└────────────┼────────────┘
↓
Baza danych
↓
Przechowywanie
Początkowo można zwiększyć moc poszczególnych serwerów (scale up), a gdy to już nie wystarcza — dodawać nowe serwery (scale out).
Najprostsza analogia
Wyobraź sobie kasy w supermarkecie.
Jeśli jedna kasa nie radzi sobie z klientami, są dwa warianty.
W pionie:
uczynić jedną kasę szybszą — zainstalować szybszy skaner, zautomatyzować płatność itp.
W poziomie:
otworzyć jeszcze 5 kas.
W pierwszym przypadku poprawiamy jeden zasób.
W drugim — zwiększamy liczbę zasobów.
To właśnie ta różnica leży u podstaw pojęć scale up i scale out.
I chociaż terminy te najczęściej występują w IT, ta sama zasada może być dostrzegana dosłownie wszędzie: od serwerów i baz danych po budynki, linie produkcyjne i elektrownie słoneczne.
Podoba ci się?Zareaguj
🧵
Ten post nie ma jeszcze żadnych dodatków od autora.
