EN
Email office@midapt.com
Telefon +48 731 679 458

Zapisano do newslettera!

Adres został dodany do naszej listy mailingowej. Będziesz otrzymywać najnowsze artykuły i aktualizacje prosto na swoją skrzynkę.

Wiadomość wysłana!

Dziękujemy. Otrzymaliśmy Twoją wiadomość i odpowiemy w ciągu 24 godzin.

Wróć na stronę główną

Aplikacja wysłana!

Dziękujemy. Twoja aplikacja na stanowisko została przyjęta. Nasz zespół ją przejrzy i wkrótce się odezwie.

Zobacz wszystkie stanowiska
EN
Porozmawiajmy
Strona główna/Blog/Artykuł
E-commerce

Kubernetes cost optimization with Sylius: jak obciąć koszty chmury

Szafy serwerowe w centrum danych z podświetlonymi kontrolkami, symbolizujące infrastrukturę chmurową sklepu

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.

autoscaling.yaml 
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-auth

Krok 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.