Benchmark Elasticsearch narzędziem Rally: jak zacząć

Rally (polecenie esrally) to oficjalne narzędzie Elastic do testów wydajności Elasticsearch. Uruchamia powtarzalny scenariusz, czyli zasila klaster danymi, wysyła zapytania i mierzy przepustowość oraz czasy odpowiedzi. Dzięki temu zmianę konfiguracji, aktualizację wersji albo nowy sprzęt możesz ocenić liczbami, a nie wrażeniem, że „chyba działa szybciej”. Poniżej opisujemy, po co robić benchmark, jak go przygotować i jak czytać raport.

Po co testować klaster, który działa?

Klaster, który dziś odpowiada szybko, jutro może się dławić, bo urośnie ilość danych, zmieni się wzór zapytań albo zespół doda nowe źródło logów. Benchmark odpowiada na pytania, których nie rozstrzygnie sam monitoring produkcji:

• ile dokumentów na sekundę klaster przyjmie, zanim zacznie opóźniać indeksowanie;
• jak zmieni się czas zapytań po zmianie liczby shardów, mapowania albo typu dysków;
• czy aktualizacja wersji Elasticsearch nie pogorszy wyników dla naszego obciążenia;
• ile węzłów i jakiego sprzętu potrzeba na planowany przyrost danych.

Test robimy zwykle przed wdrożeniem produkcyjnym platformy Elastic i przed każdą większą zmianą w klastrze, który zbiera logi lub dane do wizualizacji.

Podstawowe pojęcia w Rally

• Track to opis scenariusza: jakie dane i do jakich indeksów trafiają, jakie zapytania są wysyłane i w jakiej kolejności. Rally ma gotowe tracki, m.in. geonames, http_logs, nyc_taxis i pmc. Możesz też napisać własny track na podstawie próbki prawdziwych danych.
• Challenge to wariant wykonania w obrębie tracku, na przykład samo indeksowanie albo indeksowanie i zapytania naraz.
• Car to konfiguracja Elasticsearch, którą Rally uruchamia, gdy sam stawia węzły. Przy teście istniejącego klastra jej nie używasz.
• Pipeline określa, skąd Rally bierze Elasticsearch. Do testowania własnego klastra służy pipeline benchmark-only: Rally niczego nie instaluje, tylko generuje obciążenie.
• Race to pojedyncze uruchomienie testu. Każdy race dostaje identyfikator, po którym można go później porównać z innym.

Jak przygotować test

1. Wydziel środowisko. Test zrobi duży ruch, więc nie uruchamiaj go na klastrze produkcyjnym, który obsługuje użytkowników. Dokumentacja Rally zaleca środowisko dedykowane, w którym nie ma innego ruchu, bo inaczej wynik jest zaburzony.
2. Uruchom Rally na osobnej maszynie. Generator obciążenia nie powinien konkurować o procesor z węzłami Elasticsearch. Rally działa na Linuksie i macOS, a testować może klastry także na innych systemach.
3. Dobierz track do swojego obciążenia. Dla logów sprawdza się http_logs, dla wyszukiwania pełnotekstowego pmc, a dla agregacji liczbowych nyc_taxis. Jeśli Twoje dane są inne, zbuduj własny track, bo wynik z gotowego scenariusza mówi tylko tyle, jak klaster radzi sobie z tym scenariuszem.
4. Zapisz stan wyjściowy. Wersja Elasticsearch, liczba węzłów, rozmiar sterty, typ dysków, liczba shardów i replik. Bez tego za miesiąc nie będziesz wiedzieć, co właściwie porównujesz.
5. Zmieniaj jedną rzecz naraz. Jeśli zmienisz jednocześnie liczbę shardów i rozmiar sterty, nie dowiesz się, co poprawiło wynik.

Uruchomienie testu na istniejącym klastrze

Instalacja to jedno polecenie (wymaga Pythona, gita i JDK zgodnego z Elasticsearch, a zmienna JAVA_HOME musi wskazywać JDK):

pip3 install esrally

Listę dostępnych tracków pokaże esrally list tracks. Pierwszy przebieg dobrze zrobić z opcją --test-mode, która używa niewielkiej części danych i pozwala sprawdzić, czy połączenie i konfiguracja działają:

esrally race --track=http_logs --pipeline=benchmark-only \
  --target-hosts=10.5.5.10:9200,10.5.5.11:9200,10.5.5.12:9200 \
  --test-mode

Dopiero po powodzeniu testu próbnego uruchamiasz właściwy benchmark bez tej opcji. Gdy klaster ma włączone zabezpieczenia, używasz HTTPS i danych logowania:

esrally race --track=http_logs --pipeline=benchmark-only \
  --target-hosts=10.5.5.10:9200,10.5.5.11:9200,10.5.5.12:9200 \
  --client-options="use_ssl:true,verify_certs:true,basic_auth_user:'elastic',basic_auth_password:'<hasło>'"

Hasła nie zostawiaj w historii powłoki ani w skryptach w repozytorium. Do testów lepiej założyć osobnego użytkownika z ograniczonymi uprawnieniami. Pełna lista opcji jest w dokumentacji Rally (Command Line Reference).

Jak czytać wyniki

Na końcu Rally wypisuje raport z kilkunastoma sekcjami. Najczęściej ważne są cztery grupy wskaźników.

Wskaźnik	Co mówi
Throughput (przepustowość)	Ile operacji na sekundę klaster wykonał. Rally podaje minimum, medianę i maksimum. Dla indeksowania to dokumenty na sekundę.
Service time	Czas od wysłania żądania do otrzymania odpowiedzi. Pokazuje, jak szybko klaster obsługuje pojedyncze zapytanie.
Latency (opóźnienie)	Service time plus czas oczekiwania żądania w kolejce. Różni się od service time, gdy ustawisz docelową przepustowość i klaster nie nadąża.
Error rate	Odsetek operacji zakończonych błędem. Wynik z błędami jest bezwartościowy, dopóki nie zrozumiesz ich przyczyny.

Patrz na percentyle, nie tylko na medianę. Mediana (50. percentyl) pokazuje typowe zapytanie, a 99. percentyl ten niewielki odsetek, który użytkownik odczuwa jako „system się zawiesił”. W raporcie są też czasy łączenia segmentów (merge), odświeżania (refresh) i czasy pracy garbage collectora oraz rozmiar sterty i dysku. Rosnący czas GC przy stałej przepustowości zwykle oznacza za małą stertę lub zbyt wiele shardów.

Pojedynczy przebieg niewiele znaczy. Powtórz test co najmniej trzy razy i porównaj rozrzut. Jeśli wyniki różnią się o kilkanaście procent bez żadnej zmiany w klastrze, środowisko jest zbyt hałaśliwe, żeby wykrywać drobne różnice.

Porównywanie przebiegów

Rally zapisuje wyniki i pozwala zestawić dwa przebiegi. Listę przebiegów pokaże esrally list races, a porównanie zrobisz poleceniem:

esrally compare --baseline=<id-przebiegu-przed> --contender=<id-przebiegu-po>

Raport pokazuje różnicę dla każdego wskaźnika, więc od razu widać, czy zmiana pomogła indeksowaniu kosztem zapytań albo odwrotnie. Przy dłuższej pracy wyniki warto odkładać do osobnego klastra Elasticsearch (metrics store), skonfigurowanego w pliku ~/.rally/rally.ini. Wtedy historię pomiarów można oglądać na dashboardzie w Kibanie, a pomiary nie giną razem z maszyną testową.

Czego benchmark nie powie

Wynik Rally dotyczy scenariusza, który uruchomiłeś. Nie zastąpi testu z prawdziwymi danymi i prawdziwymi zapytaniami, a gotowy track nie uwzględnia ruchu z Twoich dashboardów ani reguł alertów. Dlatego przy większych klastrach przygotowujemy własny track na bazie próbki danych klienta i dopiero on decyduje o rozmiarowaniu. Przy planowaniu nowego klastra albo migracji pomagamy w ramach wdrożeń Elastic.