Spis treści
Platforma sklepu internetowego nigdy nie jest obciążona równomiernie. Na przykład kampania reklamowa, premiera produktu czy Black Friday mogą w krótkim czasie wielokrotnie zwiększyć liczbę zapytań do bazy danych. Problemem nie jest tutaj sam pik takich zdarzeń, lecz to, czy infrastruktura potrafi zwiększyć wydajność dokładnie wtedy, gdy jest ona potrzebna. Jednym z rozwiązań jest architektura hybrydowa. W jej przypadku stabilna warstwa danych działa na własnych serwerach umieszczonych w data center, a warstwa aplikacyjna korzysta z elastycznych zasobów chmurowych. Takie połączenie pozwala zachować kontrolę nad bazą danych i jednocześnie automatycznie zwiększać moc obliczeniową aplikacji podczas wzrostu ruchu. W artykule wyjaśniamy, jak połączyć kolokację zasobów serwera z autowygładzaniem pików sprzedażowych.
Dlaczego hybryda w e-commerce to dobre rozwiązanie?
Hybrydowa infrastruktura łączy własne zasoby IT z usługami chmurowymi. W e-commerce można wykorzystać ten model do rozdzielenia elementów o różnych charakterystykach obciążenia. Baza danych często wymaga stałej wydajności CPU, RAM i storage, natomiast warstwa aplikacyjna może potrzebować dodatkowych instancji tylko podczas krótkich pików sprzedażowych. Umieszczenie bazy danych w kolokacji daje kontrolę nad sprzętem i jego konfiguracją, a chmura pozwala elastycznie skalować aplikację.
Aby być uczciwym, trzeba podkreślić, że są też ograniczenia takiego rozwiązania. Jeżeli aplikacja generuje zbyt dużo zapytań do bazy, samo dodanie kolejnych instancji niczego nie rozwiąże. Może nawet zwiększyć liczbę połączeń i pogłębić problem. Dlatego przed wdrożeniem hybrydy trzeba określić przepływ danych, wymagane opóźnienia i rzeczywiste wąskie gardła.
Piki sprzedażowe i autowygładzanie ruchu
Autowygładzanie piku to nie jeden mechanizm, lecz połączenie kilku warstw ochrony. Automatyczne skalowanie uruchamia dodatkowe instancje aplikacji, gdy rośnie np. liczba żądań, czas odpowiedzi czy wykorzystanie zasobów. Jednak nie każde zapytanie powinno trafiać bezpośrednio do bazy. Cache obsługuje często powtarzające się odczyty, a kolejki pozwalają odroczyć operacje, które nie muszą zostać wykonane synchronicznie.
Przed przewidywanym wydarzeniem, np. dużą promocją w sklepie, warto również zastosować tzw. pre-scaling. Dzięki niemu zasoby serwera są zwiększane jeszcze przed rozpoczęciem piku sprzedażowego, zamiast czekać na przekroczenie progów monitoringu.
Podział warstw, czyli baza danych w kolokacji oraz aplikacja w chmurze
W praktyce model hybrydowy powinien zostać podzielony na 4 odrębne sekcje. Występuje w nim warstwa:
- danych – baza SQL/NoSQL i trwałe dane biznesowe w kolokacji;
- aplikacji – backend, API i usługi aplikacyjne w chmurze;
- ruchu – urządzenie rozdzielające ruch sieciowy, CDN i WAF;
- asynchroniczna – kolejki i programy obsługujące zadania w tle.
Aplikacja powinna być możliwie najbardziej bezstanowa (stateless), aby uruchomienie kolejnej instancji nie wymagało przenoszenia sesji czy lokalnych danych. Warto przy tym pamiętać, że dla wymagającej bazy danych warto postawić na serwery dedykowane – takie rozwiązanie pozwala precyzyjnie dobrać CPU, RAM i dyski twarde do konkretnego profilu obciążenia. Z kolei warstwa aplikacyjna może być skalowana niezależnie od fizycznego sprzętu.
Łączność na linii data center–chmura
Realizując połączenie między kolokacją serwerów a chmurą, trzeba uwzględnić przepustowość, opóźnienia, stabilność, routing i redundancję. Pamiętaj, że tysiące małych zapytań do bazy danych mogą powodować problemy z szybkością działania systemu, nawet jeśli łącze internetowe ma duży zapas przepustowości. Dlatego podczas testów warto mierzyć nie tylko szybkość przesyłania informacji, ale także czas odpowiedzi na zapytania – zwłaszcza w 5% i 1% najwolniejszych przypadków.
Istotne jest także zabezpieczenie połączenia i przygotowanie alternatywnej ścieżki na wypadek awarii. W przypadku kolokacji warto wykorzystać redundantne zasilanie i łączność dostępne w profesjonalnym obiekcie. Takie warunki oferuje Sprint Data Center – posiadamy serwerownie mające m.in. zasilanie awaryjne, klimatyzację oraz łącza od różnych operatorów w ramach swojej infrastruktury.
Autoskalowanie warstwy aplikacji na piki sprzedażowe w sklepie
Autoskalowanie nie powinno opierać się wyłącznie na wykorzystaniu procesora CPU. O tym, czy potrzebne są dodatkowe zasoby, mogą informować również inne parametry, takie jak np.:
- liczba zapytań obsługiwanych w ciągu sekundy,
- czas oczekiwania na odpowiedź, szczególnie w przypadku najwolniejszych zapytań,
- liczba aktywnych połączeń, zadań oczekujących w kolejce oraz błędów serwera.
System powinien mieć zarówno określony próg, po którego przekroczeniu zaczyna zwiększać liczbę zasobów, jak i maksymalny limit uruchamianych instancji. Bez takiego ograniczenia wadliwy kod lub nagły wzrost ruchu na stronie może doprowadzić do niekontrolowanego zwiększenia liczby instancji, a w konsekwencji także kosztów. Najważniejsza zasada jest tutaj prosta – skalować trzeba komponent będący wąskim gardłem, a nie ten, który najłatwiej zwiększyć.
Cache i kolejki jako zabezpieczenie dla piku sprzedażowego
Cache zmniejsza liczbę odczytów wykonywanych bezpośrednio na bazie danych. Może przechowywać np. katalog produktów, konfigurację sklepu czy inne informacje, które nie muszą być pobierane przy każdym żądaniu. Trzeba jednak prawidłowo ustawić TTL i mechanizm unieważniania danych.
Kolejki sprawdzają się przy operacjach, które mogą zostać wykonane asynchronicznie. Zalicza się do nich np. wysyłkę powiadomień, generowanie dokumentów czy synchronizacje z systemem magazynowym. W czasie piku sprzedażowego aplikacja przekazuje zadania do kolejki, a procesy odpowiedzialne za ich wykonywanie pobierają je i realizują w kontrolowanym tempie. Warto monitorować nie tylko samą kolejkę, ale również liczbę oczekujących zadań oraz czas, jaki czeka najdłużej oczekujące zadanie. Jeżeli ich liczba w kolejce stale rośnie, oznacza to, że system nadal nie nadąża z ich przetwarzaniem.
Wysoka dostępność i odtwarzanie systemu po awarii w architekturze hybrydowej
Pamiętaj, że autoskalowanie nie zastępuje wysokiej dostępności ani strategii Disaster Recovery. Awaria bazy danych, zasilania czy samego serwera może zatrzymać system niezależnie od liczby instancji aplikacji.
Wysoka dostępność serwera (HA) powinna ograniczać skutki awarii pojedynczego elementu systemu, np. dzięki zastosowaniu dodatkowych maszyn i kopiowaniu danych między nimi. Odtwarzanie wszystkiego po poważnej awarii wymaga natomiast tworzenia kopii zapasowych, przygotowania procedur przywracania systemu oraz określenia, jak dużo danych można utracić i jak szybko system powinien zostać ponownie uruchomiony.
Dwa serwery znajdujące się w tej samej szafie nie zapewniają ochrony przed awarią całego obiektu. Jeśli budynek lub centrum danych przestanie działać, oba mogą zostać jednocześnie odłączone. Przy wysokich wymaganiach dotyczących poziomu dostępności warto więc rozważyć kopiowanie danych do niezależnej lokalizacji.
Czy baza blokuje pik sprzedażowy – jak przeprowadzić diagnozę?
Przed zwiększeniem liczby instancji aplikacji trzeba sprawdzić bazę danych podczas piku sprzedażowego. W tym celu należy monitorować m.in.:
- wykorzystanie procesora i pamięci RAM,
- szybkość odczytu i zapisu danych oraz czas dostępu do dysku,
- liczbę aktywnych połączeń z bazą,
- blokowanie dostępu do danych przez inne operacje,
- zapytania, których wykonanie zajmuje dużo czasu,
- skuteczność wykorzystywania pamięci podręcznej,
- wykorzystanie dostępnych połączeń z bazą danych.
Jeżeli aplikacja ma wolne zasoby, ale czas odpowiedzi rośnie wraz z liczbą operacji I/O, blokadami lub ilością oczekujących zapytań w bazie, problemem jest warstwa danych. Wtedy właściwym działaniem będzie optymalizacja zapytań, indeksów, puli połączeń lub pamięci – dokładanie kolejnych serwerów aplikacyjnych mija się tutaj z celem.
Testy obciążeniowe symulujące realny pik sprzedażowy
Test taki powinien odwzorowywać rzeczywisty scenariusz sprzedażowy, czyli kolejno:
- normalny ruch w sklepie online,
- stopniowy wzrost liczby zapytań do bazy,
- gwałtowny pik sprzedażowy,
- utrzymanie wysokiego obciążenia serwera przez dłuższy czas i powrót do poziomu bazowego.
Trzeba również zachować proporcje operacji. Inny profil ma ruch oparty głównie na przeglądaniu produktów, a inny sytuacja, w której duża część użytkowników jednocześnie dodaje produkty do koszyka i składa zamówienia. Podczas testu należy mierzyć nie tylko liczbę obsłużonych zapytań, ale również czas odpowiedzi systemu, liczbę błędów, obciążenie bazy danych, długość kolejek oraz sposób, w jaki system reaguje na zwiększone obłożenie i uruchamia dodatkowe zasoby. Test warto powtarzać przed dużymi kampaniami reklamowymi oraz po istotnych zmianach w sposobie działania infrastruktury.
Monitoring pików sprzedażowych i alerty
Monitoring powinien obejmować cały proces działania systemu – od ruchu użytkowników, przez urządzenie rozdzielające ruch między serwery i aplikację, aż po bazę danych, kolejki zadań oraz połączenie między centrum danych a chmurą.
Z kolei alarm informujący o wykorzystaniu procesora np. powyżej 80% często nie wystarczy. Bardziej przydatne może być powiadomienie o zbyt długim czasie odpowiedzi utrzymującym się przez kilka minut albo o stale rosnącej liczbie zadań oczekujących w kolejce. Dzięki temu można zareagować na rzeczywisty problem — pogarszającą się szybkość obsługi użytkowników — zanim doprowadzi on do niedostępności sklepu internetowego.
Dla e-commerce, w którym baza danych wymaga stabilnych zasobów, a warstwa aplikacyjna musi reagować na zmienny ruch, kolokacja serwerów może więc stanowić solidną podstawę architektury hybrydowej. Nasze polskie centrum danych Sprint Data Center oferuje to rozwiązanie, gwarantując m.in. redundantne zasilanie, sprawdzone łącza od różnych operatorów, ochronę fizyczną oraz całodobowe wsparcie techniczne. Współpracując z nami, możesz umieścić własne serwery w profesjonalnej infrastrukturze i stworzyć stabilną podstawę dla skalowalnego środowiska e-commerce. Zapraszamy do kontaktu i zapoznania się ze szczegółami oferty.
FAQ – odpowiedzi na często zadawane pytania
1. Czy baza może działać w kolokacji, a aplikacja w chmurze?
Tak. Jest to typowy scenariusz infrastruktury hybrydowej. Rozwiązanie to świetnie sprawdza się pod warunkiem zapewnienia odpowiedniej łączności i niskich opóźnień.
2. Czy autoskalowanie aplikacji rozwiąże problem przeciążonej bazy danych?
Nie. Jeśli wąskim gardłem jest baza danych, dodatkowe instancje aplikacji mogą zwiększyć liczbę zapytań i pogorszyć sytuację.
3. Czy cache zastępuje bazę danych?
Zdecydowanie nie. Cache ogranicza liczbę odczytów z bazy danych, ale nie zastępuje trwałego ich źródła, czyli serwera.
4. Jak sprawdzić, czy moja infrastruktura IT wytrzyma pik sprzedażowy?
Należy wykonać test obciążeniowy odwzorowujący rzeczywisty przypadek dużego ruchu w sklepie i obserwować wszystkie warstwy, a nie tylko serwery aplikacyjne.