Efektywne środowisko IT. Jak zwiększyć wydajność systemów bez wydawania fortuny na nowe serwery? 

Błędy, opóźnienia, powolne reakcje, aż w końcu częste i długotrwałe przestoje w działaniu – tak właśnie “starzeją” się systemy IT. Szczególnie te, którym przez lata dokładaliśmy nowych funkcjonalności. Same spadki wydajności wiążą się przede wszystkim z brakiem odpowiedniej optymalizacji. Zamiast szukać usprawnień, inwestujemy w drogie rozwiązania (serwery, licencje), które wyłącznie maskują narastające problemy. Co jednak pozostaje w alternatywie do niekończącej się rozbudowy infrastruktury?

Performance engineering: Kiedy systemy zwalniają, a biznes nie chce płacić za kolejny serwer. Zobacz wideo

Doświadczenie ekspertów od performance engineeringu pokazuje, że najczęściej zastane środowisko IT jest wystarczające, żeby system działał wydajnie i bez przeszkód. Problem w tym, że za mało skupiamy się na posiadanych zasobach i nie wiemy, jak poprawnie je wykorzystywać.

Rozwijamy oprogramowanie myśląc o doświadczeniu użytkowników, ale zapominając o ich stopniowym przyroście. Integrujemy rozwiązania, bez analizy otoczenia. W efekcie wszystkie nasze działania zaczynają generować wąskie gardła, które zaburzają pracę systemu i obniżają jego wydajność. Bez świadomości, co i gdzie nie działa, zyskujemy błędne wrażenie, że problem leży po stronie utrzymania i serwerów.

Wydajność vs złożoność systemów IT

Rozwój systemu zaczyna się w momencie, kiedy dodajemy pierwsze podstawowe funkcjonalności, a liczba użytkowników jest niewielka.

Na tym etapie zazwyczaj pracuje jeszcze zespół odpowiedzialny za budowę rozwiązania, tym samym wiedząc, co i gdzie zostało zakodowane oraz jak to wszystko działa. Biznesowa presja również jest stosunkowo niewielka, ponieważ system nie działa jeszcze na wielką skalę i nie generuje znaczących przychodów. Można pozwolić sobie na eksperymenty, krótkie przestoje czy wolniejsze działanie.

Jednak, kiedy osiągamy sukces biznesowy, następują dwa zjawiska:

  • System zaczyna funkcjonować w pewnym otoczeniu i zmiany nie wiążą się już tylko z wewnętrznymi, zaplanowanymi pracami, ale również ze zmiennymi zewnętrznymi, np. wykrywane są podatności, pojawiają się nowe wersje bibliotek/frameworków, przychodzą nowe zespoły rozwojowe itp. Zmiany zaczynają narastać i to nie tylko w warstwie aplikacyjnej, a praktycznie w całym, coraz bardziej skomplikowanym środowisku IT.
  • System zaczyna być istotny biznesowo, więc każdy problem/przestój dużo kosztuje.

Pojawia się więc dylemat: ruszać i rozwijać system ryzykując błędy, czy lepiej uznać, że skoro system (jakoś) działa, to lepiej nic nie zmieniać? Szczególnie, że dużo zespołów developerskich ma tendencję do skupiania się na samych funkcjonalnościach (co te mają za zadanie robić), pomijając aspekt wydajności – ile użytkowników ma ta funkcjonalność obsługiwać.

W efekcie kończymy z mocno przebudowanym systemem, który jednocześnie jest bardzo krytyczny dla firmy i jej przychodów. A ta złożoność powoduje kolejne zagrożenia dla jego wydajności:

  • Odblokowując jedno wąskie gardło, możemy odsłonić większy problem w innym miejscu;
  • Zaczynamy mieć tendencję do wyłącznie lokalnej optymalizacji, a nie globalnej;
  • Brak nam całościowego spojrzenia na system (e2e), szczególnie przy rozwiązaniach klasy enterprise.

Działania i efekty performance engineeringu

Performance engineering skupia się na identyfikacji i eliminacji wąskich gardeł, które mogą wpływać negatywnie na działanie systemów, a także na zoptymalizowaniu korzystania z istniejących zasobów. Główne założenia obejmują analizę obciążenia, optymalizację kodu i architektury, identyfikację problemów wydajnościowych, a także stosowanie odpowiednich narzędzi do monitorowania i pomiaru parametrów systemu.

Tym samym jest niezwykle ważnym elementem zarządzania infrastrukturą IT, zwłaszcza w dynamicznym i wymagającym środowisku biznesowym.

Główne działania w ramach performance engineeringu:

  • Audyt/Tuning – okresowy bilans systemu, dzięki któremu zyskujemy listę zaleceń i możemy zaplanować “leczenie” (backlog zagadnień i jego zaplanowana obsługa). Warto przeprowadzać go regularnie, żeby wyłapywać problemy na bieżąco, zanim urosną i spowodują większe spustoszenia. Możemy działać według przykładowej checklisty:
    • Zrozumienie Aktorów i ich wzorców ruchu (użytkownicy/procesy/konsumenci API);
    • Analiza topowych transakcji i ich profili oraz trendów w różnych warstwach;
    • Analiza warstw (utylizacja zasobów: cpu, io, net, jvm/gc, pule itd.).
  • Troubleshooting – resuscytacja systemu, w celu jak najszybszego usunięcia problemu (działanie reaktywne, ale zgodnie z przygotowanym procesem). Przykładową sytuacją jest reagowanie na zgłoszenie o nagłym spowolnieniu systemu: patrzymy na wysycenie zasobów, sprawdzamy wątki użytkowników, przechodzimy do innego systemu, znowu sprawdzamy zasoby i wątki, aż dojdziemy np. do bazy danych, która intensywnie laguje. Nie stawiamy zbyt wcześnie hipotez, kierujemy się raczej zasadą: monitoring first, hypothesus later (or never 😉).

Wdrażając procesy związane z performance engineeringiem, możemy liczyć na efekty w postaci:

  • Optymalizacja kosztów infrastruktury IT. Po tuningu/audycie znajdziemy rozwiązania, które pozwolą nam obniżyć koszty utrzymania czy licencji. Jest to szczególnie ważne, jeżeli rozważamy migrację do chmury, gdzie płaci się za faktyczne zużycie zasobów mocy obliczeniowej;
  • Polepszenie doświadczeń użytkownika (szybszy i sprawniejszy system);
  • Wzrost przychodu / marży (połączenie dwóch pierwszych punktów);
  • Green IT. Mniejsza konsumpcja zasobów i zmniejszenie śladu węglowego, czyli de facto wparcie inicjatyw ESG. Optymalizacja infrastruktury: zmniejszenie liczby zaangażowanych procesorów, zmniejszona ilość poboru energii.

Poprawa wydajności systemów – jak uniknąć milionowych wydatków

Zalety performance engineeringu najlepiej pokazać na przykładzie. W naszym przypadku jest to rzeczywiste case study klienta: system zaprojektowany do wsparcia sprzedaży i obsługi produktów przez wewnętrzne Call Center. W pewnym momencie API systemu udostępnione zostało partnerowi zewnętrznemu, aby utworzyć nowy kanał partnerski. Z punktu widzenia sprzedażowego projekt okazał się bardzo dużym sukcesem i przyniósł duży wzrost sprzedaży.

Jednak z drugiej strony efekt był taki, że w porze lunchowej system był praktycznie nieużywalny przez pracowników Call Center. Nie dało się ani tworzyć nowych sprzedaży, ani obsługiwać klientów, ponieważ system się zawieszał. Problem został przekazany do zespołów zajmujących się utrzymaniem i jednym z pierwszych pomysłów na rozwiązanie patowej sytuacji była dodatkowa inwestycja w infrastrukturę.

W tym przypadku inwestycja w procesory. I oczywiście, inwestycja w jednej warstwie, to koszty w kolejnych – inwestycja w procesory pociągała za sobą inwestycję w licencje itp. Dodatkowo potrzebny był czas: okazało się, że nie ma już na maszynie wirtualnej miejsca, co oznaczało konieczność dokupienia kolejnych serwerów, a całość rozrosła się do trzech miesięcy prac.

Z początkowego sukcesu i zadowolenia ze wzrostu sprzedaży, zrobił się problem. Naszym zadaniem było znaleźć mniej oczywistą alternatywę, tańszą i szybszą we wdrożeniu.

Performance engineering – case study

W ramach performance engineeringu w pierwszej kolejności przystąpiliśmy zarówno do analizy ruchu (wewnętrznego oraz wygenerowanego przez partnerów), jak i najbardziej obciążonych komponentów. W kolejnym kroku wiedzieliśmy już, że wysyconą warstwą jest CPU na bazie danych.

Problemy w jednej warstwie przekładały się na problemy w pozostałych, dlatego po kolei usuwaliśmy znalezione wąskie gardła (przeprowadzaliśmy synchronizacje, optymalizacje pul wątków, połączeń, analizę zapytań SQL). Następnie wprowadziliśmy mechanizmy separujące ruch wewnętrzny i zewnętrzny oraz tuning, co pozwoliło zmniejszyć zużycie zasobów i sprawiło, że system wrócił do normalnej pracy pod wymaganym obciążeniem.

Iteracyjne podejście: Actors -> quotas -> tops -> pule -> synchronizacje w kodzie -> i od nowa.

W ramach prac dwóch ekspertów od performance engineeringu i w ciągu zaledwie trzech tygodni, wraz z zespołem utrzymaniowym klienta udało się przywrócić aplikację do pracy w godzinach lunchowych (zmniejszenie obciążenia CPU ze 100% do 60%). Zmiany były wykonywane wieczorem/w nocy, żeby nie zakłócać pracy biznesowej. Dzięki temu klient uniknął inwestycji w infrastrukturę, która wynosiłaby kilka milionów złotych (w stosunku rocznym).

Ponadto, po przeanalizowaniu wszystkich warstw aplikacji – systemowej, operacyjnej, wirtualizacji, bazy danych – znaleźliśmy kilka rzeczy obniżających wydajność systemu (np. defaltowe ustawienia serwerów aplikacyjnych). Wprowadziliśmy zmiany, dzięki którym wygenerowana została przestrzeń na około dwa lata liniowego wzrostu ruchu. Tym samym nasze działania przełożyły się na ogromne oszczędności i pozwoliły

Wygeneruj oszczędności w swojej firmie

Performance engineering jest kluczem do efektywnego zarządzania środowiskiem IT, pozwalając na zwiększenie wydajności systemów bez ponoszenia zbędnych kosztów. Jeżeli widzisz u siebie problemy związane z szybkością systemów, umów się na rozmowę zamiast od razu kupować kolejny serwer.

Jesteśmy autoryzowanym partnerem Dynatrace, a w portfolio mamy już kilka projektów wydajnościowych, które wygenerowały ogromne oszczędności.