Kubernetes cost optimization with Sylius: jak obciąć koszty chmury
Kubernetes cost optimization with Sylius sprowadza się do trzech rzeczy. Po pierwsze, dopasuj zasoby podów PHP-FPM do realnego zużycia. Po drugie, skaluj automatycznie tylko to, co faktycznie obsługuje ruch. Po trzecie, odciąż PHP cache'em i CDN-em, żeby płacić za mniej węzłów. W typowym sklepie na Sylius te kroki pozwalają obniżyć rachunek za klaster o 20–50%, bez pogorszenia czasu odpowiedzi.
Poniżej znajdziesz konkretny plan, przykładową konfigurację oraz kompromisy, o których rzadko mówi się w poradnikach. Opieramy się na tym, jak w Midapt budujemy i utrzymujemy sklepy oparte na Sylius.
Gdzie uciekają pieniądze w sklepie Sylius na Kubernetes
Zanim zaczniesz cokolwiek ciąć, rozbij rachunek na składniki. W sklepach na Sylius koszty prawie zawsze rozkładają się podobnie, choć proporcje zależą od skali.
- Compute aplikacji, czyli pody PHP-FPM, Nginx i workery Symfony Messenger. Zwykle to 40–60% rachunku.
- Baza danych: zarządzany MySQL lub PostgreSQL, często przewymiarowany „na zapas”.
- Usługi pomocnicze: Redis na sesje i cache, Elasticsearch lub OpenSearch, jeśli korzystasz z rozbudowanego wyszukiwania, oraz broker kolejek.
- Ruch wychodzący i load balancery. Szczególnie kosztowne są obrazy produktów serwowane bezpośrednio z klastra.
- Observability: logi i metryki trzymane latami bez polityki retencji.
- Środowiska nieprodukcyjne: staging i review apps, które działają 24/7, choć używa się ich kilka godzin dziennie.
Pierwszym krokiem jest więc widoczność. Etykietuj zasoby według środowiska i komponentu, a potem przez 2–4 tygodnie zbieraj dane o faktycznym zużyciu CPU i pamięci. Bez tego każda optymalizacja to zgadywanie.
Krok 1: right-sizing podów PHP-FPM
Najczęstszy błąd, który widzimy, to requests ustawione „na oko”, np. 1 CPU i 2 GiB na pod, który w szczycie zużywa ćwierć rdzenia. Scheduler rezerwuje te zasoby, więc płacisz za węzły wypełnione pustą rezerwacją.
Jak policzyć zasoby dla Sylius
- Zmierz pamięć jednego workera PHP-FPM pod realnym ruchem. W Sylius zwykle wychodzi kilkadziesiąt do ponad stu MB, zależnie od wtyczek.
- Ustaw pm.max_children tak, by iloczyn liczby workerów i pamięci workera mieścił się w limicie poda z zapasem 15–20%.
- Requests CPU ustal na poziomie typowego obciążenia, a nie szczytu. Szczyty obsłuży autoskalowanie.
- Limit pamięci ustaw zawsze. Limit CPU często lepiej pominąć, bo throttling PHP potrafi wydłużyć czas odpowiedzi bardziej, niż wynika to z samego zużycia.
Tańszy start kontenera
Wykonuj cache warmup Symfony i kompilację assetów na etapie budowania obrazu, a nie przy starcie poda. Włącz OPcache z preloadingiem. Pod, który startuje w kilka sekund zamiast minuty, pozwala trzymać mniejszy zapas replik, bo autoskalowanie reaguje szybciej.
Zasada praktyczna: jeśli średnie wykorzystanie zarezerwowanego CPU w klastrze spada poniżej 30–40%, płacisz za powietrze. Zacznij od korekty requests, zanim zaczniesz negocjować ceny instancji.
Krok 2: autoskalowanie HPA dla ruchu i KEDA dla kolejek
Gdy requests odpowiadają realnemu zużyciu, możesz bezpiecznie skalować poziomo. Horizontal Pod Autoscaler liczy procent wykorzystania względem requests. Przy zawyżonych wartościach po prostu nigdy nie zadziała, dlatego right-sizing musi być pierwszy.
Pody PHP-FPM
- Na produkcji trzymaj minimum 2 repliki dla dostępności. Maksimum wyznacza wydajność bazy, a nie budżet.
- Cel wykorzystania CPU na poziomie 60–70% daje bufor na nagły skok ruchu.
- Dłuższe okno stabilizacji przy skalowaniu w dół, np. 5 minut, zapobiega „piłowaniu” replik podczas kampanii.
- Przed znanymi szczytami, jak Black Friday czy wysyłka newslettera, podnieś minReplicas z wyprzedzeniem. Reaktywne skalowanie zawsze trochę się spóźnia.
Workery Symfony Messenger
Workery obsługujące maile, eksporty czy synchronizację z ERP nie powinny skalować się według CPU, tylko według długości kolejki. Tu sprawdza się KEDA, która potrafi zejść do zera replik, gdy kolejka jest pusta. W sklepach z nocnymi importami katalogu to jedna z najszybszych oszczędności.
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: sylius-php
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: sylius-php
minReplicas: 2
maxReplicas: 12
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 65
behavior:
scaleDown:
stabilizationWindowSeconds: 300
policies:
- type: Percent
value: 50
periodSeconds: 60
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: sylius-messenger
spec:
scaleTargetRef:
name: sylius-messenger-worker
minReplicaCount: 0
maxReplicaCount: 8
cooldownPeriod: 300
triggers:
- type: rabbitmq
metadata:
queueName: messages
mode: QueueLength
value: "50"
authenticationRef:
name: rabbitmq-authKrok 3: cache i CDN, czyli mniej PHP na każde żądanie
Najtańszy request to taki, który w ogóle nie dociera do PHP-FPM. W Sylius dużą część ruchu generują anonimowi użytkownicy oglądający kategorie i karty produktów, a te strony bardzo dobrze nadają się do cache'owania.
- HTTP cache: Varnish lub reverse proxy przed aplikacją dla stron katalogu. Koszyk i elementy zależne od sesji wydziel przez ESI albo doładowuj asynchronicznie.
- Redis dla cache aplikacyjnego Symfony i Doctrine oraz dla sesji. Sesje poza podem to także warunek bezpiecznego korzystania z węzłów spot.
- Obrazy produktów: miniatury LiipImagine generuj do object storage i serwuj przez CDN. Generowanie miniatur w locie na podach to klasyczny, ukryty pożeracz CPU i transferu.
- Assety statyczne serwuj z długim czasem cache i wersjonowaniem w nazwie pliku.
Dobrze ustawiony cache potrafi zmniejszyć liczbę żądań trafiających do PHP o kilkadziesiąt procent. To przekłada się bezpośrednio na mniej replik i mniej węzłów.
W sklepie na Sylius każda złotówka zainwestowana w cache wraca wielokrotnie w postaci węzłów, których nie musisz uruchamiać.
Krok 4: tańsze węzły, czyli spot, ARM i lepsze upakowanie
Samymi maszynami warto zająć się dopiero wtedy, gdy obciążenie jest dobrze zmierzone i skaluje się automatycznie. Wcześniej tańsze instancje tylko maskują problem.
Węzły spot dla bezstanowych podów
PHP-FPM, Nginx i workery Messenger są bezstanowe, więc dobrze znoszą przerwania. Instancje spot bywają tańsze od on-demand o 60–80%. Trzymaj jednak bazową pulę na zwykłych węzłach, ustaw PodDisruptionBudget i rozpraszaj repliki między różne typy instancji i strefy.
Procesory ARM
Instancje ARM zwykle dają o 15–30% lepszy stosunek ceny do wydajności dla PHP. Warunek to obrazy multi-arch i sprawdzone rozszerzenia PHP oraz zależności natywne.
Upakowanie i zobowiązania
Narzędzia takie jak Karpenter czy Cluster Autoscaler dobierają rozmiar węzłów do podów i usuwają puste maszyny. Stałe obciążenie bazowe pokryj instancjami rezerwowanymi lub savings plans na 1–3 lata, a zmienne zostaw autoskalowaniu.
Krok 5: baza danych, środowiska testowe i observability
Warstwa danych rzadko działa w samym klastrze, ale często jest drugą największą pozycją na rachunku. Tutaj oszczędności dają głównie porządki, a nie zakupy.
- Baza danych: zanim kupisz większą instancję, usuń zapytania N+1, dodaj brakujące indeksy i przejrzyj slow query log. W Sylius problemy sprawiają zwłaszcza rozbudowane filtry katalogu i raporty w panelu.
- Wyszukiwarka: Elasticsearch lub OpenSearch dobierz do wielkości katalogu. Dla kilku tysięcy produktów klaster trzywęzłowy bywa przesadą.
- Staging i review apps: wyłączaj je poza godzinami pracy i ustaw automatyczne usuwanie środowisk po zamknięciu pull requesta. To potrafi obciąć koszty nieprodukcyjne o ponad połowę.
- Logi i metryki: dla większości danych wystarczy retencja 7–30 dni. Wyłącz poziom debug na produkcji i próbkuj logi dostępowe.
Wprowadzaj zmiany pojedynczo i porównuj koszty oraz czas odpowiedzi przed i po każdej z nich. Oszczędność, która wydłuża ładowanie strony produktu, zwykle kosztuje więcej w utraconej konwersji, niż daje na fakturze.
Kiedy Kubernetes dla Sylius się nie opłaca
Nie każdy sklep potrzebuje klastra. Opłata za control plane, load balancery, monitoring, a przede wszystkim czas zespołu DevOps to koszt stały. Przy małej skali przewyższa on korzyści. Klaster zwykle się nie opłaca, gdy:
- ruch jest stabilny i mieści się na 1–3 serwerach,
- nie masz osoby, która rozumie Kubernetes i odpowiada za klaster,
- wdrażasz zmiany rzadziej niż raz na kilka tygodni.
W takich przypadkach zarządzana platforma lub kilka dobrze skonfigurowanych maszyn wirtualnych będzie tańsze i prostsze. Kubernetes zaczyna się zwracać przy wyraźnych szczytach ruchu i wielu środowiskach. Opłaca się też przy kilku sklepach lub kanałach sprzedaży oraz zespole, który regularnie wdraża zmiany. Pomagamy podjąć tę decyzję w ramach usług Cloud & DevOps.
Kubernetes cost optimization with Sylius: od czego zacząć
Kubernetes cost optimization with Sylius to proces, a nie jednorazowa akcja. Kolejność ma znaczenie. Najpierw zadbaj o widoczność kosztów i right-sizing, potem o autoskalowanie, cache i CDN, a na końcu o tańsze węzły i zobowiązania. Odwrócenie tej kolejności zwykle kończy się tanimi maszynami wypełnionymi pustymi rezerwacjami.
Jeśli Twój rachunek za chmurę rośnie szybciej niż sprzedaż, umów bezpłatną konsultację. Przejrzymy konfigurację klastra i sklepu, wskażemy największe źródła strat i oszacujemy realną oszczędność. Zobacz też, jak wspieramy firmy z branży e-commerce.
Najczęstsze pytania o koszty Kubernetes w sklepach Sylius
Tak. Sylius opiera się na Symfony, a jego warstwa aplikacyjna jest bezstanowa, jeśli sesje i cache przeniesiesz do Redisa, a pliki do object storage. Wtedy pody PHP-FPM można swobodnie skalować i przenosić między węzłami. Warunkiem jest dobrze przygotowany obraz z rozgrzanym cache Symfony i OPcache oraz osobne deploymenty dla workerów Messenger.
W typowym sklepie, który nie był wcześniej optymalizowany, realne oszczędności wynoszą zwykle 20–50% rachunku za klaster. Największe efekty daje korekta zawyżonych requests, autoskalowanie, cache i CDN oraz wyłączanie środowisk testowych poza godzinami pracy. Węzły spot i instancje rezerwowane dokładają kolejne procenty, ale dopiero po uporządkowaniu podstaw.
Można, pod warunkiem że uruchamiasz na nich tylko bezstanowe komponenty: PHP-FPM, Nginx i workery kolejek. Sesje muszą być w Redisie, a nie w podzie. Zostaw bazową pulę węzłów on-demand, ustaw PodDisruptionBudget i korzystaj z kilku typów instancji. Bazy danych, brokera kolejek ani wyszukiwarki nie uruchamiaj na spot bez replikacji.
Najlepiej oba, każde do innego zadania. HPA dobrze sprawdza się dla podów PHP-FPM obsługujących ruch HTTP, skalując je według wykorzystania CPU. KEDA lepiej pasuje do workerów Symfony Messenger, bo skaluje je według długości kolejki i potrafi zejść do zera replik, gdy nie ma zadań do przetworzenia.
To zależy od ruchu, liczby środowisk i usług pomocniczych. Mały klaster produkcyjny z bazą zarządzaną, Redisem i stagingiem to zwykle od kilkuset do kilku tysięcy złotych miesięcznie za samą infrastrukturę. Do tego dochodzi czas zespołu DevOps, który przy małej skali bywa większym kosztem niż sama chmura.