Kalkulator Zasobów VPS

Najpierw nie nazwa pakietu, a charakter obciążenia

Wybierając VPS, nazwa pakietu łatwo zwodzi. „Basic”, „standard”, „premium”, „general purpose”… Ładnie wyglądają. Ale żadna z tych nazw sama w sobie nie mówi, ile RAM-u zje strona, kiedy zapcha CPU, czy którego dnia dysk się zapełni.

Strona statyczna i sklep WooCommerce mogą mieć tego samego odwiedzającego, ale nie potrzebują tego samego serwera. W jednym przypadku serwowane są gotowe pliki; w drugim działają koszyk, płatności, stany magazynowe, sesje użytkowników, zapytania do bazy, panel administracyjny, a czasem także zadania w tle (kolejki). Różnica tkwi właśnie tutaj.

Ten model obliczeniowy analizuje VPS pod kątem czterech głównych zasobów: vCPU, RAM, dysku i miesięcznego transferu. Nie traktuje ich jednak jak gołych liczb; uwzględnia typ aplikacji, poziom środowiska, użycie cache/CDN, usługi działające na tym samym VPS, logi, lokalne kopie zapasowe oraz zapas na rozwój.

Nie istnieje jeden „oficjalny wzór na VPS”. Zresztą w dokumentacji dużych dostawców chmury sprawa jest ujęta właśnie w ten sposób: CPU, pamięć, sieć i przechowywanie rozpatruje się łącznie; rodziny maszyn różnią się w zależności od obciążenia. Maszyny ogólnego przeznaczenia działają inaczej niż maszyny zoptymalizowane pod obliczenia czy pod pamięć. Na VPS obowiązuje ta sama logika, tylko w mniejszej skali.

flowchart LR
  A["Typ aplikacji"] --> E["Szacowanie zasobów"]
  B["Ruch i pamięć podręczna"] --> E
  C["Baza danych, worker, panel administracyjny, Docker"] --> E
  D["Dysk, logi, kopie zapasowe, bufor wzrostu"] --> E
  E --> F["vCPU"]
  E --> G["RAM"]
  E --> H["Dysk"]
  E --> I["Miesięczny ruch"]

W tego typu obliczeniach najbardziej nie lubię zdania: „2 vCPU wystarczy”. Do czego wystarczy? Do statycznej strony, WooCommerce, Odoo, API w Node.js, czy do mieszanej instalacji, gdzie na tym samym serwerze działają MySQL, Redis, poczta i Docker?

Ponadto umyka różnica między współdzielonym CPU a dedykowanym (wydzielonym) CPU. W małych planach VPS CPU jest często współdzielone. Dla lekkich stron internetowych to może nie być problem. Ale w systemach, które regularnie uruchamiają workery, przyjmują ruch w szczytach, generują raporty lub często obciążają bazę danych, ta sama liczba vCPU może być odczuwalnie słabsza niż oczekiwano.

Dlatego wynik tutaj to nie „dokładny plan”, ale bezpieczny szacunek na start. Daje dobry pierwszy obraz przy wyborze zasobów. W produkcji ostateczne zdanie należy do metryk: użycie CPU, zużycie RAM, zapełnienie dysku, ruch sieciowy, wolne zapytania, logi błędów, kolejka workerów.

Papier to jedno, serwer to drugie.

Od czego zaczynamy?

Pierwszy podział w obliczeniach wynika z typu aplikacji. Ponieważ bazowe obciążenie każdej klasy aplikacji nie jest takie samo.

Strona statyczna jest po najlżejszej stronie. Przyjmuje się bazowe CPU 1 vCPU, bazowy RAM 1 GB; współczynnik CPU utrzymywany jest na niskim poziomie, np. 0.2. To logiczne. Ponieważ dobrze zcacheowana strona statyczna serwuje głównie gotowe pliki, warstwa aplikacji pracuje bardzo mało.

Dla WordPress / bloga start jest wyższy: bazowe CPU 1.5 vCPU, bazowy RAM 2 GB, współczynnik CPU 1. WordPress ma fundament PHP i bazę danych. Motywy, wtyczki, przetwarzanie obrazów, operacje w panelu, wyszukiwanie, komentarze — to nie działa jak strona statyczna. Przy odpowiednim cache można to jednak znacznie odciążyć.

WooCommerce / e-commerce to inna klasa. W tym modelu przyjmuje się bazowe CPU 2.5 vCPU, bazowy RAM 4 GB, współczynnik CPU 2. Moim zdaniem dla e-commerce to rozróżnienie jest konieczne. Ponieważ WooCommerce na zwykłym WordPressie dodaje warstwę koszyka, płatności, zamówień, stanów magazynowych i kont użytkowników. Dodatkowo niektóre strony nie nadają się w pełni do cache. Strona produktu może pochodzić z cache, ale przy koszyku i płatnościach sytuacja się zmienia.

Dla aplikacji Laravel / PHP oraz Node.js / API bazowe CPU 2 vCPU, bazowy RAM 3 GB, współczynnik CPU 1.2. Tutaj rzeczywiste zapotrzebowanie bardzo zależy od kodu. Proste API może działać bardzo lekko; aplikacja komunikująca się z zewnętrznymi usługami, stale przetwarzająca dane, korzystająca z kolejek, może być w tej samej klasie znacznie cięższa.

Dla małego SaaS bazowe CPU 3 vCPU, bazowy RAM 4 GB, współczynnik CPU 1.8. Sesje użytkowników, zadania w tle, powiadomienia, raporty i ruch w bazie danych zwykle idą w parze. Liczba odwiedzających może wydawać się mała, ale operacji wewnątrz aplikacji jest dużo. Patrząc jak na stronę internetową, wybiera się zły pakiet.

Systemy podobne do Odoo / ERP są po cięższej stronie: bazowe CPU 4 vCPU, bazowy RAM 8 GB, współczynnik CPU 3. W instalacjach Odoo planowanie workerów i pamięci już osobno się rozważa. Raportowanie, sesje użytkowników, moduły, operacje na bazie danych i długotrwałe zadania odróżniają tę klasę od zwykłego bloga.

Dla serwera gier bazowe CPU 3 vCPU, bazowy RAM 4 GB, współczynnik CPU 2.5; dla botów / workerów przyjmuje się bazowe CPU 2 vCPU, bazowy RAM 2 GB, współczynnik CPU 1.5. Szczególnie w zadaniach typu worker liczba odwiedzających może być myląca. Nawet jeśli nikt nie wchodzi na stronę, w tle mogą być przetwarzane dane.

Wybór środowiska nakłada się na wartość bazową niczym współczynnik. Środowisko testowe / hobbystyczne 0.75, mała produkcja 1, produkcja 1.25, przygotowanie pod wysoką dostępność 1.6. „Przygotowanie pod wysoką dostępność” nie oznacza, że pojedynczy VPS nagle stał się HA; oznacza po prostu pozostawienie większego zapasu zasobów. Prawdziwe HA wymaga osobnej architektury.

Zapas na rozwój wchodzi w grę na końcu. Domyślnie 30%. Uważam, że to rozsądne. Dobry zakres, aby pokryć oczekiwany wzrost w ciągu 3-6 miesięcy. Można wpisać 300%, ale jeśli naprawdę nie spodziewasz się takiego wzrostu, obliczenia zmieniają się w rachunek strachu.

Obliczanie ruchu: średnia miesięczna trochę myli

Miesięczna liczba odwiedzin to pierwsza dana, na którą patrzymy, ale przy podejmowaniu ostatecznej decyzji jest niewystarczająca. Dwie strony z 100 tysiącami odwiedzin mogą generować różne obciążenie. Jedna pokazuje 1.5 strony na odwiedzającego, rozmiar strony 1 MB, CDN działa dobrze. Druga pokazuje 4 strony na odwiedzającego, rozmiar strony 3 MB, ma dużo elementów dynamicznych. Ten sam ruch, zupełnie inne obciążenie serwera.

Obliczanie ruchu uwzględnia liczbę odwiedzających, wartość strony / sesji oraz średni rozmiar strony. Następnie odejmuje się wpływ cache, dodaje zapas na rozwój, a wynik przelicza na GB. Końcowa wartość jest zaokrąglana do progów co 50 GB; nawet w bardzo małych scenariuszach pokazywane jest minimum 50 GB ruchu.

Założenia dotyczące cache są następujące: brak cache – oszczędność 0, podstawowy cache – 35%, cache stron + obiektowy – 60%, CDN + silny cache – 75%. To nie są oficjalne gwarantowane wartości. Przy użyciu cache NGINX lub CDN oczekuje się zmniejszenia obciążenia serwera źródłowego; ale realne oszczędności zależą od współczynnika trafień cache, struktury strony i elementów dynamicznych.

Szczególnie w WooCommerce należy na to uważać. Sam fakt posiadania CDN nie sprawia, że strona koszyka i płatności nagle staje się darmowa. W miejscach takich jak treści spersonalizowane, sesje, operacje administracyjne, proces płatności, kontrola stanów magazynowych cache jest bardziej ograniczony. Cache to dobry hamulec; nie zastępuje silnika.

Jest też współczynnik szczytu godzinowego. Ruch miesięczny nie rozkłada się równomiernie. Dzień kampanii, wysyłka newslettera, udostępnienia w mediach społecznościowych, nagłe wzrosty na stronach informacyjnych... Średnia może wyglądać spokojnie, a serwer może się pocić przez godzinę. W tym obliczeniu Peak RPS znajduje się w przybliżeniu jako (miesięczni odwiedzający × strony / sesję × współczynnik szczytu godzinowego) podzielone przez liczbę sekund w 30 dniach. 30 dni to 2 592 000 sekund.

Wpływ ruchu na CPU jest jeszcze ciekawszy. Liczba odwiedzających jest odnoszona do 50 000, obciążenie mnożone jest przez współczynnik CPU, dodawany jest współczynnik szczytu godzinowego, a połowa efektu cache jest odejmowana po stronie CPU. Oznacza to, że cache znacząco zmniejsza ruch, ale wpływ na CPU jest redukowany ostrożniej. Uważam, że to właściwe podejście, ponieważ nie każde żądanie jest obsługiwane z cache.

W teście statycznej, zcacheowanej strony: 100 tysięcy miesięcznych odwiedzin, 1.5 strony / sesję, rozmiar strony 1 MB, współczynnik szczytu godzinowego 2, CDN + silny cache oraz 20% zapasu na rozwój. Wynik pozostaje na poziomie 1 vCPU, 2 GB RAM, 40 GB dysku, 50 GB miesięcznego ruchu. Ruch jest, ale obciążenie lekkie.

W przykładzie e-commerce nie ma takiego komfortu. Przy 200 tysiącach miesięcznych odwiedzin, 4 stronach / sesję, średnim rozmiarze strony 3 MB, współczynniku szczytu godzinowego 5, cache stron + obiektowym i 50% zapasu na rozwój, miesięczny ruch wzrasta do 1450 GB. Sugerowane CPU to 32 vCPU. Na pierwszy rzut oka może wydawać się wysokie; ale gdy zestawimy liczby, obraz robi się ostrzejszy: więcej odwiedzających, więcej stron, większe strony, cięższe obciążenie, wyższe szczyty.

Rozmiar strony to osobny problem. Nie wystarczy powiedzieć „strona jest lekka”, trzeba to zmierzyć. Duże obrazy, czcionki, skrypty stron trzecich, kody reklamowe, znaczniki analityczne, niepotrzebne pliki JS zwiększają ruch. To, że strona szybko się otwiera w przeglądarce, nie oznacza, że transfer danych jest mały.

Kto pracuje na tym samym serwerze?

Na małych VPS-ach prawdziwa walka często rozgrywa się właśnie tutaj. Serwer WWW nie stoi sam. W tym samym miejscu jest MySQL, Redis, panel, być może też serwer pocztowy. Gdy dołożymy kontenery Docker i procesy workerów, 2 GB RAM może zabraknąć tchu.

Jeśli baza danych znajduje się na tym samym VPS, do modelu wchodzi dodatkowe obciążenie RAM. Rozmiar bazy danych dzielony jest przez 20; wynik jest ograniczany do minimum 1 GB i maksimum 8 GB. Na przykład nawet dla bazy 5 GB rezerwowane jest 1 GB RAM. Dla bazy 30 GB powstaje dodatkowe obciążenie około 1.5 GB. Po stronie CPU dla bazy danych dodaje się 0.5 vCPU.

To nie jest kalkulacja tuningu bazy danych. Jeśli indeksy są złe, zapytania długie, a blokady tabel występują, 0.5 vCPU nie wystarczy. Ale na potrzeby wstępnego planowania to lepsze niż traktowanie bazy danych jak „zerowego kosztu”.

Jeśli Redis / object cache znajduje się na tym samym VPS, do RAM dodaje się 0.5 GB. Redis działa w pamięci; gdy o tym zapomnisz, na małym serwerze pojawiają się dziwne spowolnienia. Cache został stworzony, aby zwiększyć wydajność, owszem, ale sam też potrzebuje RAM.

W panelu zarządzania są trzy poziomy: brak, lekki panel, pełny panel jak cPanel / Plesk. Lekki panel dodaje 0.3 GB RAM i 0.15 vCPU do CPU. Pełny panel dodaje 1 GB RAM i 0.3 vCPU. Instalowanie systemów takich jak cPanel czy Plesk na VPS z 1 GB RAM i późniejsze oczekiwanie wydajności od aplikacji to niezbyt dobry pomysł. Panel daje wygodę; płacisz za nią zasobami.

Liczba workerów / kolejek ma bezpośredni wpływ. Dla każdego workera dodaje się 0.5 GB RAM i 0.5 vCPU. Może się to wydawać nieco wysokie, ale jeśli zadania w tle są poważne, ma to sens. Przetwarzanie obrazów, generowanie raportów, pobieranie danych z zewnętrznych API, opróżnianie kolejki maili, zadania po płatności... Jeśli worker nie stoi bezczynnie, zajmuje zasoby.

Jeśli serwer pocztowy działa na tym samym VPS, dodaje się 0.5 GB RAM i 0.3 vCPU. Pomijając zasoby, serwer pocztowy jest także uciążliwy operacyjnie. DNS, SPF, DKIM, DMARC, spam, kolejki, dostarczalność. To obliczenie obejmuje tylko udział zasobów; nie liczy bólu głowy.

Za użycie Docker / kontenerów dodaje się 0.5 GB RAM i 0.2 vCPU. Docker wprowadza porządek, ale nie jest za darmo. Jeśli limit pamięci, zachowanie swap i przydział CPU w Dockerze nie są poprawnie skonfigurowane, jeden kontener może zdusić całą maszynę. „Zrobiliśmy kontenery, odetchnęliśmy” to nie zawsze prawdziwe stwierdzenie.

Istota obliczania CPU jest następująca: bierzemy większą z wartości bazowego CPU i zapotrzebowania CPU z ruchu, dodajemy obciążenia CPU usług, stosujemy współczynnik środowiska i zapas na rozwój. W przypadku RAM sumujemy bazowy RAM z RAM usług, ponownie dodajemy środowisko i zapas na rozwój. Następnie wynik jest zaokrąglany do praktycznych progów pakietów: dla CPU 1, 2, 4, 6, 8, 12, 16, 24, 32, 64; dla RAM 1, 2, 4, 8, 16, 32, 64, 128 GB.

Nie ma świata z ułamkami. Jeśli wyjdzie zapotrzebowanie 5.3 GB RAM, patrzy się na 8 GB. Jeśli wyjdzie 3.1 vCPU, sensowny jest 4 vCPU. W środowisku produkcyjnym drobiazgowe obliczenia przybliżają do ściany przy najmniejszych wahaniach.

Na dysku największy ciężar to czasem niewidoczne rzeczy

Myśli się, że skoro folder z kodem jest mały, to i potrzeba dyskowa jest mała. To częsty błąd w obliczeniach. Aplikacja 3 GB, media 10 GB; mówi się „wystarczy 20 GB dysku”. Potem przychodzą logi, baza danych, lokalna kopia zapasowa, pliki systemowe, obrazy kontenerów, pliki tymczasowe.

Obliczanie dysku uwzględnia pliki aplikacji, media / uploady, rozmiar bazy danych, dzienny log, liczbę dni przechowywania logów oraz lokalną kopię zapasową. Jeśli baza danych nie znajduje się na tym samym VPS, nie wchodzi do obliczeń dysku. Jeśli jest na tym samym VPS, wchodzi.

Najpierw tworzona jest suma częściowa dysku: pliki aplikacji + pliki mediów + baza danych (jeśli na tym samym VPS) + dzienny log × liczba dni przechowywania. Następnie uwzględniana jest liczba lokalnych kopii zapasowych. Jedna lokalna kopia mniej więcej podwaja zbiór danych. Do tego dodaje się 15 GB zapasu systemowego, stosuje 20% bufor bezpieczeństwa, a także dodaje zapas na rozwój. Wynik jest zaokrąglany do progów co 10 GB, z zaleceniem minimum 20 GB.

Niech 15 GB zapasu systemowego nie wydaje się małe. System operacyjny, pakiety, pozostałości po aktualizacjach, pliki tymczasowe, logi usług, obrazy Docker, pliki tymczasowe bazy danych zajmują stamtąd miejsce. W produkcji dysk to nie tylko Twój folder na uploady.

Logi są podstępne. 0.5 GB logów dziennie i 14 dni przechowywania daje 7 GB. 2 GB logów dziennie i 30 dni przechowywania to 60 GB. Rosną po cichu. Dysk przekracza 80%, potem 90, a potem podczas wdrożenia pojawia się ten słynny błąd: „no space left on device”.

Lokalna kopia zapasowa również wymaga uwagi. Przechowywanie kopii na tym samym dysku nie daje pełnego bezpieczeństwa w scenariuszu katastrofy; jeśli dysk zniknie, znika też kopia. Ale jedna lokalna kopia może wystarczyć do szybkiego przywrócenia. Model uwzględnia to w obliczeniach zasobów. Decyzje takie jak zdalna kopia, przechowywanie obiektowe, osobny serwer backupów należy planować osobno.

W teście produkcyjnym WordPress: 5 GB plików aplikacji, 10 GB mediów, 5 GB bazy danych, 0.5 GB logów dziennie, 14 dni przechowywania, 1 lokalna kopia zapasowa i 30% zapasu na rozwój – zalecany dysk to 90 GB. Na pierwszy rzut oka dużo. Ale po dodaniu logów, kopii, zapasu systemowego i bufora bezpieczeństwa to nie jest dużo, raczej ostrożnie.

W przypadku e-commerce sprawa się rozrasta: 10 GB plików aplikacji, 80 GB mediów, 30 GB bazy danych, 2 GB logów dziennie, 30 dni przechowywania, 1 lokalna kopia zapasowa i 50% zapasu na rozwój. Wynikowy dysk to 480 GB. Jeśli zdjęcia produktów, dane zamówień, logi i kopia znajdują się na tym samym serwerze, ten wynik nie jest zaskakujący.

Zbytnie oszczędzanie na dysku to zły nawyk. Jeśli brakuje CPU, zobaczysz spowolnienie. Jeśli brakuje RAM, zaczyna się swap. Jeśli dysk się zapełni, usługi potrafią psuć się znacznie dotkliwiej: baza danych nie może zapisywać, logi nie są tworzone, pliki sesji nie otwierają się, wdrożenie zostaje w połowie. Co gorsza, błąd nie zawsze mówi o sobie wprost.

Zamieniając wynik na pakiet

Na wyjściu są cztery główne wartości: CPU, RAM, dysk i miesięczny ruch. Nie wrzucaj ich do jednego worka. Każda wskazuje inny limit.

CPU to chwilowa moc obliczeniowa. Żądanie PHP, odpowiedź API w Node.js, zapytanie do bazy, zadanie workera, operacja po płatności... To dotyka CPU. Gdy rośnie ruch, CPU może wzrosnąć; cache może to zmniejszyć, ale nie usuwa całkowicie.

RAM to przestrzeń dla działających usług. MySQL, Redis, PHP-FPM, procesy Node.js, panel, kontenery Docker, serwer pocztowy, workery. Gdy RAM się zmniejsza, system może zacząć używać swapu. Udaje, że działa, ale robi się cięższy. Szczególnie w aplikacjach dynamicznych tę różnicę szybko czuć.

Dysk to pamięć trwała. Patrzą na niego pliki aplikacji, media, baza danych, logi, kopie zapasowe i pliki systemowe. W obliczeniach dysku należy myśleć nie o dzisiejszym rozmiarze, ale o narastaniu w ciągu kilku miesięcy.

Miesięczny ruch to transfer danych. CDN, cache i optymalizacja strony go zmniejszają. Politykę ruchu dostawcy należy sprawdzić osobno: czy jest limit, czy opłaty za przekroczenie, czy ograniczenie prędkości? Kalkulacja podaje zapotrzebowanie w GB; nie podaje warunków komercyjnych dostawcy.

W tym modelu surowe wartości są zaokrąglane do praktycznych progów pakietów. Jeśli jest surowe zapotrzebowanie 3.4 vCPU, zalecany jest 4 vCPU. Jeśli potrzeba 9 GB RAM, można przejść na poziom 16 GB. Dysk również jest zaokrąglany do progów co 10 GB. To zaokrąglanie czasem zawyża wynik, ale pakiety VPS i tak nie są sprzedawane z ułamkami.

I jeszcze jedno: 4 vCPU u każdego dostawcy może nie zachowywać się jak to samo 4 vCPU. Generacja CPU, struktura współdzielona/dedykowana, warstwa wirtualizacji, typ dysku, jakość sieci, maszyny sąsiednie — wszystko ma znaczenie. Dostawcy tacy jak DigitalOcean nie bez powodu podkreślają w dokumentach wyboru planu różnicę między współdzielonym a dedykowanym CPU.

Dlatego to obliczenie należy traktować jak techniczną kontrolę przed naciśnięciem przycisku zakupu. Jeśli masz istniejący system, porównaj z rzeczywistymi metrykami: wykres CPU, użycie RAM, zapełnienie dysku, ruch wychodzący, wolne zapytania, błędy 5xx, czas oczekiwania w kolejkach. Jeśli budujesz nowy system, przetestuj kilka scenariuszy.

Co się dzieje bez cache? Jak bardzo spada ruch po wybraniu CDN? Czy odłączenie bazy danych od VPS odciąża RAM? Gdzie idzie CPU, gdy liczba workerów wzrośnie z 0 do 4? O ile zwiększa dysk lokalna kopia zapasowa?

Wybór pakietu czasem wynika z odpowiedzi na te pytania, a nie z pojedynczej linii wyniku.

Gdybym to ja, szczególnie przyjrzałbym się trzem wartościom: współczynnikowi szczytu godzinowego, temu czy baza danych jest na tym samym VPS oraz lokalnej kopii zapasowej. Ponieważ w prawdziwym życiu to one najbardziej zaburzają obliczenia. Ruch zbiera się w jednej godzinie, MySQL na tym samym serwerze zajmuje więcej RAM niż oczekiwano, kopie zapasowe wypełniają dysk. Potem wszyscy obwiniają pakiet CPU.

Czasem wina nie leży po stronie CPU.