Rally: od benchmarkingu do ciągłej optymalizacji

Autor: Pierre-Samuel Le Stang, Inżynier DevOps w OVH.

Utrzymanie wysokiego poziomu jakości usług jest wyzwaniem dla każdej firmy. W OVH dążymy do tego, aby nasze usługi zyskiwały ciągle na jakości. Ale w jaki sposób mierzyć jakość, na przykład usług w chmurze?

W przypadku chmury publicznej OVH, opartej na technologii OpenStack jako dwa główne wyznaczniki jakości usług przyjęliśmy:

  • Dostęp do API OpenStack w aplikacjach klienckich OpenStack, bibliotekach czy API v6 OVH;
  • Wydajność na poziomie instancji (procesor, pamięć RAM, dysk, sieć).

To one mają największy wpływ na doświadczenie klienta.

Kluczowe jest określenie i zmierzenie tego, co uznajemy za jakość usługi. Pozwoli nam to identyfikować odchylenia i prowadzić skuteczną analizę w sytuacji wystąpienia odstępstwa od przyjętej normy.

W naszym przypadku, do mierzenia wydajności interfejsu API wykorzystaliśmy mierzenie czasu odpowiedzi na poszczególnych etapach tworzenia i zarządzania infrastrukturą Public Cloud. Dzięki temu mamy pewność, że użytkowanie naszych usług odbywa się płynnie, co przekłada się na jakość usługi dla klienta.

Rally: narzędzie benchmarkingowe w ekosystemie OpenStack

Rally stanowi element projektu OpenStack i określane jest mianem rozwiązania typu „Benchmarking as a Service”. Jego zadaniem jest testowanie danej platformy OpenStack z perspektywy klienta i sporządzenie na tej podstawie pomiarów czasu wykonania operacji.

Projekt, opracowany w języku Python, został zapoczątkowany w roku 2013. W lipcu 2018 roku wyszła jego wersja 1.0.0. Decyzja o wykorzystaniu tego narzędzia w OVH do mierzenia wydajności interfejsów API zapadła dość szybko, biorąc pod uwagę fakt, iż stanowi on część dobrze nam znanego ekosystemu OpenStack oraz oferuje funkcjonalności odpowiadające naszym potrzebom.

Rally umożliwia realizację scenariuszy będących zbiorami sekwencyjnych testów o modyfikowalnych parametrach i większym lub mniejszym stopniu skomplikowania. W ten sposób możemy, na przykład, przetestować tworzenia tokena uwierzytelniającego i sprawdzić, czy działa prawidłowo. Możliwe są również inne, bardziej skomplikowane operacje, np. przetestowanie, w ramach jednego scenariusza, uwierzytelnienia oraz procesu tworzenia kilku instancji wraz z dołączeniem do nich wolumenów. Dzięki elastyczności, jaką oferuje nam to narzędzie, łatwo możemy wyobrazić sobie przeprowadzenie nieskończonej liczby bardzo specyficznych testów. Rally domyślnie dostarcza kompletny zestaw scenariuszy sklasyfikowanych według komponentów funkcjonalnych OpenStack (Nova, Neutron, Keystone, czy np. Glance).

Rally mierzy czas odpowiedzi na poszczególnych etapach oraz czas całkowity. Dane zapisywane są w bazach i mogą być eksportowane w formie raportów sporządzonych w HTML lub JSON. Narzędzie jest w stanie powtórzyć zadanie określoną ilość razy według tego samego scenariusza i obliczyć wartości średnie, jak również wygenerować inne dane statystyczne (mediana, 90-ty percentyl, 95-ty percentyl, minimum, maksimum) dla każdej iteracji, jak również w odniesieniu do całości powtórzeń.

Raport testowy Rally wygenerowany w HTML

Raport testowy Rally wygenerowany w HTML

Narzędzie spełnia również wymagania przewidziane w Service Level Agreement (SLA), tzn. stwarza możliwość określenia dopuszczalnego odsetka błędu w stosunku do danej liczby iteracji, na podstawie którego test globalny może zostać uznany za pomyślny.

Innym, ważnym aspektem, który zainteresował nas w tym projekcie, była możliwość przeprowadzenia testów z pozycji klienta końcowego, bez konieczności przechodzenia przez funkcję administratora. Dzięki temu możemy w pełni wcielić się w rolę klienta korzystającego z usługi Public Cloud.

Przykłady zastosowania

Mierzenie wydajności

Naszą podstawową potrzebą jest zebranie danych o API dla istniejącej platformy. W tym celu przeprowadzamy kilka razy na godzinę określoną liczbę powtórzeń testów Rally dla każdego komponentu funkcjonalnego OpenStack, we wszystkich regionach.

Kwalifikacja oprogramowania

Kolejnym zastosowaniem narzędzia jest sytuacja, gdy wdrażamy łatkę lub przeprowadzamy aktualizację bezpieczeństwa lub aktualizację oprogramowania. W każdym z powyższych przypadków trudno jest, bez odpowiedniego narzędzia, zmierzyć konsekwencje tych zmian. Możemy tutaj posłużyć się przykładem aktualizacji kernela w związku z lukami w zabezpieczeniach (Spectre oraz Meltdown), które spowodować miały obniżenie wydajności. Dzięki Rally możemy teraz dość łatwo ocenić ewentualne konsekwencje wprowadzenia zmian.

Kwalifikacja sprzętu

Rozwiązanie Rally może znaleźć zastosowanie również w sytuacji, gdy chcemy przetestować nową gamę fizycznych serwerów używanych na płaszczyźnie sterowania (Control Plane) technologii OpenStack. Dzięki Rally możemy sprawdzić występowanie ewentualnych wahań wydajności.

Pomiary pomiarami, ale...

Nie zapomnijmy o tym, że naszym celem jest wizualizacja zmian czasów odpowiedzi w perspektywie długoterminowej. Rally może dostarczyć raport HTML z realizacji jednego scenariusza, a zatem w odniesieniu do bardzo krótkiego okresu czasu. Natomiast nie jest on w stanie dokonać syntezy raportów z wszystkich przeprowadzonych w określonym czasie testów.

Dlatego potrzebny był nam sposób na wydobycie danych z raportów i zebranie ich w graficznej formie. Wybraliśmy do tego celu naszą wewnętrzną platformę metryk, korzystająca z technologii Warp 10 do przechowywania danych oraz z narzędzia Grafana do tworzenia dashboardów.

Do wyciągnięcia wartości zmierzonych podczas testów i przeniesienia ich na platformę metryk posłużyliśmy się eksportem w formacie JSON implementowanym w Rally. Następnie stworzyliśmy dashboard, który pozwala nam zwizualizować czasy odpowiedzi w kontekście długoterminowym dla każdego testu i każdego regionu. W ten sposób możemy w prosty sposób zobrazować ich zmiany i porównać między sobą regionalne czasy odpowiedzi. W przypadku regionów sobie bliskich (na przykład we Francji: GRA, RBX i SBG) powinniśmy otrzymać dosyć zbliżony czas odpowiedzi. Jeśli tak nie jest, szukamy źródła tej różnicy, aby móc naprawić błąd.

Wewnętrzny dashboard podsumowujący rezultaty testów Rally

Wewnętrzny dashboard podsumowujący rezultaty testów Rally

Analiza konkretnego przypadku

Po wdrożeniu wszystkich niezbędnych komponentów, porównaliśmy między sobą zmiany w czasach odpowiedzi pomiędzy poszczególnymi regionami. Okazało się, że w przypadku niektórych specyficznych testów naszego projektu, w perspektywie długoterminowej i dla niektórych regionów, poziom wydajności obniżał się. Dla przykładu, istnieje test polegający na stworzeniu spisu wszystkich instancji projektu Rally: otrzymany czas średni wynosi 600 ms, podczas gdy w niektórych regionach dochodził on do 3 sekund.

Na początek sprawdziliśmy, czy ta nieprawidłowość była związana wyłącznie z naszym projektem. Potwierdziliśmy, że takie odchylenia występowały tylko w naszym projekcie.

Po bardziej dogłębnej analizie udało nam się ustalić, że wąskie gardło znajdowało się na poziomie bazy danych dla wersji Juno OpenStack. OpenStack stosuje metodę soft delete przy usuwaniu danych. Oznacza to, że klasyfikuje daną jako usuniętą, ale nie kasuje jej fizycznie z tabeli. W naszym przypadku tabela „instancje” składa się, między innymi, z kolumn” project_id oraz „deleted”. W momencie, gdy Rally sporządza listę serwerów projektu, zapytanie sformułowane jest w sposób następujący:

SELECT * FROM instances WHERE project_id=’xxx’ AND deleted = 0 ;

Niestety w wersjach Juno technologii Openstack tabela ta nie zawiera indeksu („project_id”, „deleted”), w przeciwieństwie do wersji Newton Openstack. W ramach projektu Rally, dla każdego regionu uruchamianych jest codziennie około 3000 nowych instancji. Po 3 miesiącach mieliśmy w naszych bazach 270 000 wpisów o instancjach w trybie soft delete. Ta wysoka liczba danych znajdujących się w bazach, w połączeniu z brakiem indeksu w tabeli, tłumaczy opóźnienia, które zaobserwowaliśmy w niektórych regionach (wyłącznie dla wersji Juno).

Aby rozwiązać ten problem, wdrożyliśmy na naszych projektach wewnętrznych proces definitywnego usuwania danych oznaczonych jako soft delete. Rezultat był natychmiastowy: czterokrotne skrócenie czasu odpowiedzi dla testów polegających na sporządzaniu list serwerów projektu Rally.

Wyraźna poprawa czasów odpowiedzi dla pojedynczego regionu w ramach projektu Rally

Wyraźna poprawa czasów odpowiedzi dla pojedynczego regionu w ramach projektu Rally

W tym konkretnym przypadku, dla klientów, którzy mogliby stanąć w obliczu podobnych problemów, wprowadzimy automatyczną archiwizację danych soft deleted w specjalnie do tego stworzonych tabelach typu „shadow” dla OpenStack.

Dzięki narzędziu Rally dysponujemy teraz środkami pozwalającymi na identyfikację anomalii mogących wystąpić pomiędzy regionami i które mają istotny wpływ na doświadczenie użytkownika. Wdrażamy niezbędne rozwiązania, aby wyrównać te różnice i uzyskać najbardziej optymalne działanie usług dla zbliżonych geograficznie regionów. Narzędzie pozwala nam nie tylko na benchmarking, ale także umożliwiło nam stworzenie procesu nieustannego doskonalenia, co przekłada się na polepszenia jakości użytkowania naszych API OpenStack.