Nowe, zwinne sposoby wytwarzania i wdrażania oprogramowania sprawiły, że kontrola działania aplikacji i przydziału niezbędnych do tego zasobów nabiera krytycznego znaczenia dla poprawnego funkcjonowania organizacji.

W czasach dominacji wielkich monolitycznych środowisk aplikacyjnych – nie tak przecież odległych! – sprawa była stosunkowo prosta: dział IT nadzorował poprawność funkcjonowania infrastruktury sprzętowej (zużycie procesorów, pamięci, przestrzeni dyskowej), wzajemnych odwołań systemów, np. komunikacji aplikacji z bazą danych oraz spinającej to wszystko sieci.

W takich warunkach łatwiej było prześledzić, co dzieje się z danym systemem, a w wypadku wystąpienia problemów – przeprowadzić debugowanie. Co więcej, często wystarczały do tego procesy manualne.

Nowoczesne aplikacje i środowiska informatyczne o rozproszonej architekturze wymagają jednak zasadniczej zmiany w podejściu do monitorowania infrastruktury i zarządzania nią.

Potrzebne nowe podejście
„Zmienił się paradygmat” – tłumaczy Sebastian Pietrzak z IBM, lider segmentu AIOps, integracji i automatyzacji na Polskę i kraje bałtyckie. „Kiedyś zasoby były przydzielane do aplikacji, która musiała działać non stop. Dziś w architekturze rozproszonej, opartej na Kubernetes, w momencie, gdy aplikacja lub jej komponent przestają działać, jest on domyślnie restartowany i uruchamiany na nowo.” To sprawia, że trudniejsze jest nie tylko wychwycenie samego błędu czy problemu ale i miejsca oraz czasu jego wystąpienia.

W dodatku, o ile komponenty (procesy) w systemach monolitycznych mogły sobie funkcjonować osobno, to w dzisiejszym krajobrazie aplikacyjnym bazują na integracji i komunikacji z mnóstwem innych modułów, mikroserwisów. Zerwanie takiej łączności lub niebezpiecznie wysokie opóźnienia w przesyłaniu danych przekładają się na wydajność całego systemu.

A o tym, że czas realizacji usługi ma kluczowe znaczenie nie trzeba specjalnie przypominać – sprawnie działająca aplikacja to wyższy poziom satysfakcji klienta. Nawet sekundowe opóźnienie przekłada się na niższy współczynnik NPS oraz ogólny odbiór usługi przez użytkowników.

Co gorsza, problem w aplikacjach – w tym nowym świecie mikroserwisów, systemów rozproszonych, składających się z wielu komponentów, działających w architekturze mikrousługowej – może pojawić się w jednym miejscu ale, niczym kręgi na wodzie, rozejść się po całym środowisku.

Problemy się propagują, skolejkowanie czy duża liczba żądań w pamięci podręcznej zatyka fizyczny serwer, ograniczając jego wydajność i blokuje kolejną aplikację czy komponent. To nie jest problem globalnego braku zasobów ale wąskich gardeł tworzących się w naszym środowisku, co powoduje, że są bardzo trudne do uchwycenia – podkreśla Włodzimierz Dymaczewski, architekt rozwiązań chmurowych w IBM.

Monitoring zaczyna więc dotykać nie tylko samych modułów aplikacji, ale także relacji pomiędzy jej komponentami oraz sposobu, w jaki przekłada się generowane przez nie obciążenia na poszczególne warstwy infrastruktury IT.

Jak analizować działanie aplikacji
O współczesnych wyzwaniach monitoringu rozmawialiśmy w gronie przedstawicieli społeczności CIONET oraz zaproszonych ekspertów w trakcie kolejnego spotkania z cyklu CIONET Tech Camp, organizowanego we współpracy z IBM. Jednym z zagadnień, jakie pojawiły się w toku dyskusji, była automatyzacja – jak osiągnąć gotowość do zautomatyzowania czynności związanych z zarządzaniem infrastrukturą.

Skrócenie czasu między poszczególnymi wydaniami aplikacji powoduje, że kolejnych wersji nie zawsze można odpowiednio przetestować, co może prowadzić do niestabilnego działania po wdrożeniu. A przy aplikacjach składających się z wielu modułów, wytwarzanych i wdrażanych w trybie ciągłym – z nowymi wydaniami w odstępie dni – nie ma czasu na jakiekolwiek operacje manualne.

Dlatego, jak zwrócił uwagę Maciej Szulc, specjalista ds. technologii Kubernetes, OpenShift i CloudPaks w IBM, firmy potrzebują inteligentnych narzędzi, umiejących automatycznie przystosowywać się do zmieniającej się infrastruktury, monitorujących i utrzymujących ją we właściwy sposób na przykład poprzez automatyczne orkiestrowanie środowisk uruchomieniowych czy ustalanie progów wyzwalania alertów.

Mówimy o zupełnie nowej klasie rozwiązań do monitoringu aplikacji, które muszą działać w czasie rzeczywistym. Nie ma mowy o próbkowaniu czy zbieraniu danych – trzeba na bieżąco obserwować, co się dzieje w aplikacji i jak ona działa – przekonywał Sebastian Pietrzak.

Takie podejście zastosowano w firmie InPost, jednej z wielu organizacji, które odczuły powiew cyfrowych zmian spowodowanych pandemią. „Musimy powiększać możliwości obecnych aplikacji i rozwijać nowe. To dużo pracy związanej z automatyzacją i monitorowaniem oprogramowania na każdym etapie wytwarzania” – wyjaśnia Paweł Kowalski, dyrektor ds. aplikacji w InPost. Ponieważ nie wszystko da się wychwycić w drodze testów, aplikacje są ściśle weryfikowane: pod kątem tego, jak odwołują się do innych systemów, jaki mają wpływ na zasoby centrum danych, jak wykonywany jest kod i jak zachowuje stos technologiczny.

Zasoby zawsze pod ręką
Z zagadnieniem wydajności aplikacji nierozerwalnie wiąże się kwestia dostarczenia odpowiedniej mocy obliczeniowej.

Przedsiębiorstwa mierzą się z dramatycznym wzrostem ruchu w swoich aplikacjach i koniecznością znacznie szybszego ich rozwoju, co przekłada się na ilość środowisk developerskich. Odpowiedzią na te wyzwania jest chmura, do której przedsiębiorstwa coraz częściej migrują swoje zasoby – czy to w formie całej infrastruktury czy tylko warstwę aplikacyjną – a która umożliwia autoskalowanie mocy zgodnie z bieżącymi wymogami.

Pytanie, jak ustalać zapotrzebowanie aplikacji na zasoby, przy założeniu, że część z nich to stosunkowo proste do oszacowania zasoby mierzalne, takie jak pamięć masowa, a pozostałe – trudniejsze, niemierzalne (w tym obciążenie procesora czy zużycie pamięci)?

W trakcie spotkania CIONET Tech Camp starły się dwa poglądy – zdaniem części uczestników dyskusji, w tym Macieja Szulca, jeśli nie posiadamy narzędzi do automatycznego zarządzania zasobami (ARM), bezpiecznie jest planować zasoby niemierzalne ze sporym nadmiarem, skoro nie da się przewidzieć z góry przyszłych obciążeń.

Innego zdania był Jakub Fuszara, IT Manager w Polkomtelu. Tendencja do nadmiarowego szacowania zasobów to jedno, ale w procesie wytwarzania aplikacji bierze udział wiele osób. „Gdy każda z nich coś sobie ‘dołoży’, aplikacja się rozrasta. A workload kosztuje”. Dlatego z programistami warto – i trzeba – negocjować. „Mając inicjalny rozmiar aplikacji i faktor wzrostu możemy ocenić, jak będzie wyglądać zapotrzebowanie za rok, 3 i 5 lat, żeby nie płacić za nadmiarowe zasoby już dziś” – dodaje Fuszara.

Część problemów można wyeliminować przez dodanie do istniejącego monitoringu systemu zarządzania zasobami dla aplikacji. Bo o ile dodanie zasobów zazwyczaj nie niesie ze sobą ryzyka, zmniejszenie – już tak: aplikacja może działać wolniej lub mogą wystąpić problemy z dostępnością. „Dlatego to takie trudne” – ocenił Sebastian Pietrzak. Konieczność stosowania automatyzacji w obszarze rozwoju integracji i dostarczania aplikacji nie podlega już dziś dyskusji; z automatyzacją zarządzania środowiskiem i zasobami powinno być tak samo.

„Nie jest sztuką obserwowanie, jak zmienia się zapotrzebowanie na zasoby, sztuką jest przewidzieć konsekwencje zmiany i wręcz je wyprzedzać. Nałożenie mechanizmów predykcji i dostosowanie nie tyle architektury, co zasobów do potrzeb aplikacji z wyprzedzeniem – to jest dzisiejsze wyzwanie” – powiedział.

Każdy dobry administrator jest leniwy, co znaczy, że automatyzuję swoją pracę – zawsze to robiliśmy i będziemy to robić. Dziś poziom skomplikowania architektury jest trochę większy więc potrzebujemy nowych narzędzi do automatyzacji. Automatyzujmy wszystko, byle rozsądnie i z pewnym poziomem zaufania do tych narzędzi – podsumował Sebastian Pietrzak.