Dobrym przykładem przedsiębiorstwa, któremu udało się przeprowadzić skuteczną migrację do chmury, jest firma naszego klienta – jednego z wiodących na polskim rynku nadawców telewizyjnych i internetowych. W toku kilkuletniej współpracy z klientem przeprowadziliśmy testy wydajnościowe w różnej skali – od kilkuset do nawet 250 tysięcy wirtualnych użytkowników – i różnym poziomie skomplikowania: od prostych interfejsów API, przez testy serwisów www, do weryfikacji wydajności platformy streamingowej.
Na kanwie tego doświadczenia omówimy wyzwania, z jakimi mierzyliśmy się realizując testy wydajnościowe systemu oraz zalety narzędzia, które wybraliśmy i które znakomicie sprawdziło się w trakcie wykonywania postawionych nam zadań.
Dlaczego Tricentis NeoLoad?
Jakkolwiek w pewnych sytuacjach narzędzia open-source (my używaliśmy Apache Jmeter) okazały się zupełnie wystarczające, to jednak w przypadku bardziej zaawansowanych aplikacji i systemów konieczne było wykorzystanie równie zaawansowanego narzędzia testowego. Nasz wybór padł na NeoLoad firmy Tricentis.
Szybkość przygotowania i modyfikacji skryptów
Poziom skomplikowania skryptów uwzględniający losowy wybór materiału, kontekst użytkownika oraz dostępny dla niego materiał powodował konieczność zbudowania dość skomplikowanego frameworku testowego. Pojedynczy skrypt liczył minimum kilkanaście kroków, a każdy krok od kilku do kilkunastu requestów do różnych endpointów. Ponadto testowana przez nas platforma odwoływała się do kilkudziesięciu serwerów backendowych. Dodatkowo zmienność aplikacji i zakresu testów stawiała pod znakiem zapytania zasadność oraz opłacalność inwestowania w długotrwałe przygotowanie i utrzymanie frameworku testowego w Apache JMeter. To właśnie zadecydowało o wyborze NeoLoad. Narzędzie to ma wbudowane liczne mechanizmy usprawniające konfigurację testów, począwszy od parametryzacji adresów serwerów, przez wyszukiwanie wartości w zarejestrowanych requestach, kończąc na mechanizmach budowy polityki ruchu. Przygotowanie skryptów, a następnie ich modyfikacja zajmuje więc zdecydowanie mniej czasu niż w przypadku Apache JMeter.
Stabilne środowisko obciążeniowe złożone z wielu chmur obliczeniowych
Ogromną zaletą NeoLoad jest łatwość budowy środowiska obciążeniowego oraz zarządzanie nim bezpośrednio z GUI narzędzia. W przypadku Apache JMeter konieczne jest wykonanie szeregu konfiguracji, a maszyny generujące ruch muszą znajdować się w tej samej sieci. Dodatkowo narzędzie to nie jest w stanie zarządzać więcej niż kilkoma generatorami, zarówno pod kątem działania, jak i dystrybucji skryptów czy danych testowych. NeoLoad nie ma tych ograniczeń; pozwala na zbudowanie środowiska obciążeniowego składającego się z różnych chmur – niekiedy konieczne było tworzenie i uruchamianie testów wydajnościowych na środowiskach obciążeniowych zbudowanych z nawet 400 maszyn rozlokowanych w różnych chmurach. Co więcej, NeoLoad umożliwia wynajęcie puli generatorów w modelu usługi. NeoLoad zdejmuje więc z zespołów testowych ciężar przygotowania środowiska obciążeniowego – jedyne, co pozostaje, to zarejestrować sesję i zalogować się w narzędziu. Cała reszta dzieje się automatycznie.
Obserwacja wyników na żywo
Bardzo istotna jest możliwość śledzenia wyników w czasie rzeczywistym. W trakcie testu możemy obserwować nie tylko zagregowane czasy odpowiedzi, ale również definiować własne wykresy, aż do poziomu pojedynczego requesta. Niezwykle ważna jest również podawana na bieżąco informacja o występujących błędach. Poza kodem błędu wskazany jest konkretny request i response. Informacja ta jest niezwykle pomocna w poszukiwaniu “wąskich gardeł”.
Narzędzie Tricentis ma jeszcze wiele innych ciekawych funkcjonalności, jak chociażby wbudowany pasywny monitoring, możliwość integracji z narzędziami typu APM czy też usługę NeoLoad Web, pozwalającą na zarządzanie testami z poziomu przeglądarki. Może być również wykorzystywane do obsługi zarówno starszych protokołów i frameworków w rodzaju websocket czy java serialization, jak i rozwiązań typu SalesForce czy SAP – NeoLoad jest zresztą narzędziem rekomendowanym i certyfikowanym przez producenta SAP. Jednak to trzy opisane powyżej cechy NeoLoad były dla nas kluczowe z punktu widzenia zapewniania wydajności systemu, w tym zwłaszcza testów wydajności platformy streamingowej, która z uwagi na stale rosnące zainteresowanie użytkowników jest sukcesywnie przenoszona do chmury AWS.
Testy wydajności platformy streamingowej – wyzwania
Jedno z największych wyzwań w trakcie przygotowywania i realizacji testów wydajnościowych platformy streamingowej wynikało z różnorodności form dostępu do platformy. Należało przechwycić komunikację z różnych typów urządzeń – przeglądarki – klasycznego interfejsu www, aplikacji na smartfony i tablety oraz smartTV. O ile rejestracja skryptów przy użyciu smartfonów znaliśmy z wcześniejszych testów, o tyle obsłużenie smartTV stanowiło nowe wyzwanie. Nie obeszło się bez rootowania fizycznych urządzeń, a także kilku porażek, zanim ostatecznie udało się przechwycić komunikację.
W tamtym czasie cała infrastruktura serwisu zlokalizowana była jeszcze w serwerowniach klienta. Zanim uruchomiliśmy testy dla 250 tysięcy użytkowników, wspólnie z zespołem klienta zrealizowaliśmy dziesiątki iteracji testowych na niższych wolumenach ruchu. Testy te wykazały, że to właśnie infrastruktura on-premise będzie blokować możliwość obsługi przewidywanej większej liczby użytkowników platformy. Klient podjął więc decyzję o stopniowej migracji do chmury.
Tak, jak wspomniano, proces migracji do chmury wiąże się z przynajmniej częściową przebudową backendu; pociągnęło to za sobą konieczność zmiany zestawu skryptów wydajnościowych. Zalety NeoLoad okazały się w tej sytuacji nie do przecenienia – bieżąca obserwacja i analiza błędów umożliwiały szybką identyfikację “wąskich gardeł”, natomiast łatwa modyfikacja skryptów testowych pozwalała na bieżąco reagować na poprawki programistyczne i konfiguracyjne.
Po migracji do chmury mogliśmy przejść do realizacji testów wydajnościowych w docelowej skali – 250 tysięcy użytkowników. Przed realizacją konieczne było wykonanie kilku iteracji skalujących oraz przebudowa środowiska obciążeniowego – powołanie 400 wirtualnych maszyn w czterech różnych chmurach. Z uwagi na potencjalne problemy w zarządzaniu tak dużym parkiem generatorów ruchu, skorzystaliśmy z usługi NeoLoad Cloud, mając jednocześnie przygotowany backup w postaci lustrzanego środowiska. Test polegał na tym, że każdy użytkownik z puli był traktowany jako nowy, tzn. każdorazowo pobierał wszelkie treści statyczne, takie jak pliki css, wszelkiego rodzaju grafiki czy materiały wideo dostępne za pośrednictwem serwisu. W szczytowym momencie testów obciążenie przekroczyło 200 tys. req/s przy transferze danych rzędu 90 Gb/s. Generatory poradziły sobie bardzo dobrze, nie trzeba było skorzystać z backupu. Testy wykazały, że po migracji do chmury i po odpowiedniej konfiguracji serwisu czasy odpowiedzi na zadane requesty nie przekraczały 30 ms.
Jak więc widzimy na tym przykładzie, planując migrację do chmury warto przewidzieć przestrzeń na testy wydajnościowe, ponieważ dopiero pod kontrolowanym obciążeniem możliwe jest zweryfikowanie działania mechanizmów chmurowych, takich jak reguły skalowania, szybkość podnoszenia się kolejnych podów dockerowych czy konfiguracja loadbalancingu.
Tak dobre rezultaty nie zostały osiągnięte przy pierwszej iteracji testowej, lecz dopiero przy jednej z ostatnich. W czasie kolejnych testów modyfikowano konfiguracje oraz weryfikowano różne opcje i parametry, a następnie wybrano te, które zapewniały najlepszą wydajność.
Warto na koniec powrócić jeszcze do kwestii narzędzi open-source. Oczywiście większość testów wydajnościowych można wykonać narzędziami tego typu, należy się jednak liczyć z tym, że wymagają one poświęcenia znacznie większej ilości czasu na konfigurację, przygotowanie i utrzymanie zestawu skryptów oraz środowiska obciążeniowego. Osoby odpowiedzialne za realizację testów wydajnościowych muszą podjąć decyzję, czy są w stanie ponieść takie koszty.