Mapowanie zależności w aplikacji

12 October, 2018 12:00 30 min Administrator

Mapowanie zależności w aplikacji

Jak nawigować w złożonych środowiskach i nie wpaść na skały problemów

Jest rok 2013. Wielka firma handlowa, Sears Holding Corp., pozywa dwie firmy IT, które zajmowały się dostawami sprzętu i jego utrzymaniem w centrum danych Searsa. Pozew dotyczył przerw w zasilaniu i przeciągających się napraw, co spowodowało straty zysków w wysokości 2,2 mln USD i dodatkowych 2,8 mln USD kosztów napraw sprzętu. Minęło pięć lat i niedawno największy na świecie dostawca aplikacji w modelu SaaS, Salesforce.com, miał wielogodzinną przerwę w działaniu swojego flagowego serwisu CRM z powodu błędu firmware-u macierzy dyskowej. Awaria spowodowała niedostępność jednej z ważnych baz danych, co w rezultacie naraziło firmę na stratę w wysokości ok. 20 mln USD, a ich klientów na trudne do oszacowania straty po stronie potencjalnych przychodów i zysków. Co prawda, na tle finansów SFDC, kwota 20 mln USD to drobiazg, ale w historii były już bardziej spektakularne katastrofy (usterki). Jedną z nich, prowadzącą niemal do bankructwa, niech będzie wpadka Knight Capital, której straty szacowano na ok. 440 mln USD. Te przykłady, choć dość skrajne, ilustrują skalę strat w wyniku przerw czy nieprawidłowym działaniu usług czy aplikacji biznesowych.

Podobne scenariusze mogą być zmorą każdego inżyniera. Pewnie i ciebie kiedyś proszono o naprawienie jakiejś awarii, wymianę sprzętu, czy rutynowy przegląd, który zakończył się serią zdarzeń, o których nie można powiedzieć, że były sukcesami. Takie frustrujące przypadki zwykle trwają w nieskończoność i kosztują: nie tylko nerwy, ale często konkretne pieniądze. Jeśli chodzi o hardware, to rzadko zdarza się, żeby taka seria niefortunnych zdarzeń wyszła poza urządzenie, ale w przypadku aplikacji to prawie zawsze oznacza, że awaria rozleje się na wiele warstw, usług i komponentów. Jaskrawym przykładem  takiej sytuacji jest wpadka Salesforce.com. Dlatego bardzo ważne jest, aby znać zależności między komponentami, rozumieć, czym jest mapowanie zależności i zdawać sobie sprawę, jaką ma to wartość dla twojej firmy.

Mapowanie zależności w aplikacji – co to jest i dlaczego to bywa trudne

Najkrócej, mapowanie zależności aplikacji to proces odwzorowania komponentów (łącznie ze wzajemnymi relacjami), z których zbudowano usługę IT. Wchodzi w to warstwa przechowywania danych (storage), sieć, oraz infrastruktura serwerowa niezbędna do uruchomienia usługi aplikacyjnej. Proces taki musi zawierać etap wykrywania i podążania za wszelkimi współzależnościami między usługami i komponentami, odpowiedniego wykreślania topologii i uwzględniania wzajemnego wpływu komponentów na siebie.

Choć nie wydaje się to zbyt skomplikowane dla niewielkich systemów, to zbudowanie mapy zależności dla hybrydowych systemów złożonych i zmiennych w czasie zadaniem prostym już nie jest. Różne komponenty zarządzane przez administratorów i inżynierów są przez nich zupełnie nieźle rozumiane, ale w miarę jak systemy się komplikują, komplikuje się również mapowanie. Aplikacje korzystają z coraz większej liczby zewnętrznych usług, zespoły administracyjne podlegają ciągłym fluktuacjom (kadrowym i kompetencyjnym), a to sprawia, że ręczne stworzenie takiej mapy może być zadaniem bardzo trudnym, czasochłonnym, a w praktyce – prawie niemożliwym.

Wg raportu 2017 State of the Network Engineer autorstwa firmy NetBrain, głównym powodem, dla którego inżynierowie sieci nie dokumentują zależności aplikacyjnych jest brak czasu. Ok. 35% respondentów wskazuje, że na mapowanie zależności aplikacyjnych ich zespoły spędziły nie mniej niż miesiąc.

I właśnie w tym miejscu do gry wchodzą narzędzia do mapowania zależności aplikacyjnych. Narzędzia takie uwalniają nas od ręcznego tworzenia map, a sam proces może być zautomatyzowany i tworzenie map znacznie uproszczone.

Dlaczego tworzenie map ma znaczenie

Jak pokazują przykłady na wstępie, w dzisiejszym społeczeństwie, nadmiernie roszczeniowym i zbyt pochopnie korzystającym z pozwów sądowych, prawne reperkusje to niemal pewnik w przypadku, gdy krytyczne usługi i sieć są niedostępne. Dodatkowo, wiele umów na świadczenie usług (SLA) zawiera klauzule definiujące kary umowne lub istotne zniżki za niedopełnienie warunków umowy, tj. za okresy nieplanowanej niedostępności usług.

Ale nawet jeśli nie ma konsekwencji prawnych z powodu przerw lub zupełnej niedostępności usług, koszty mogą być katastrofalne z punktu widzenia bazy klientów. Badania przeprowadzone przez Akamai pokazują, że 75% klientów, którzy doświadczyli problemów podczas realizacji zakupów online (powolność działania, błędy, czy zawieszenia się sklepu internetowego), nigdy więcej do takiego sklepu nie wraca.

Powyższe pozwala na postawienie następującej tezy: znalezienie przyczyn niedostępności usług czy wąskich gardeł wydajności jest łatwiejsze i szybsze, jeśli znane są zależności między komponentami, usługami i serwerami. Ta wiedza radykalnie zwiększa szybkość reakcji działów IT na awarie, ułatwia ich znajdowanie i naprawianie oraz pozwala na minimalizację skutków takich zdarzeń. W środowiskach złożonych, hybrydowych i działających w wielkiej skali, taka wiedza jest absolutnie niezbędna. Zależności muszą być dobrze udokumentowane, bo żaden poważny biznes nie może pozwolić sobie, aby wiedza ta istniała tylko i wyłącznie w głowach inżynierów i architektów.

Mapowanie zależności – wartość dla twojej firmy

Poza unikaniem kosztownych awarii, mapowanie zależności może być znaczącym źródłem oszczędności i czynnikiem podnoszącym wydajność. W świecie współczesnych aplikacji, zbudowanych na bazie wielu rozproszonych i współzależnych usług, zrozumienie zależności i optymalizacja usług jest kluczem do niezakłóconego działania i obsługi rosnącej aktywności klientów.

Przykładowo, załóżmy, że firma ma problemy związane z kiepskim działaniem sieci lub opóźnieniami usług sieciowych. W tradycyjnym modelu pracy, zespół inżynierów sieci szukałby przyczyn tych problemów diagnozując sieć i mogłoby zająć wiele roboczogodzin. W przypadku, gdyby zespół monitoringu dysponował automatycznie wygenerowaną mapą zależności usług, identyfikacja problemu, jego źródła i przyczyny, mogłaby tak naprawdę być dokonana w sposób automatyczny. Mapa zależności pokaże, jakie komponenty i usługi są w danej aplikacji wykorzystywane, gdzie są wąskie gardła lub awarie, a sam proces naprawy usterki byłby niewielkim ułamkiem czasu, który zespół spędziłby pracując w modelu tradycyjnym.

W bardziej skrajnym przypadku, mapa zależności może pomóc uniknąć problemów z wydajnością czy dostępnością usług i aplikacji albo chociaż znacznie zminimalizować wystąpienie tego rodzaju problemów. Aktualne mapy zależności usług w sieci oraz chmurze nie tylko są automatycznie stworzoną dokumentacją, która dodatkowo może być dynamiczna i odzwierciedlać zmiany w czasie, ale również narzędziem analitycznym, które pozwala na zrozumienie złożoności aplikacji i wykorzystywanej przez nie infrastruktury. Na bazie takiej mapy analiza wydajności aplikacji jest również łatwiejsza i pozwala na zrozumienie natury i zasięgu problemów. Taka wiedza, z kolei, pozwala firmie na takie planowanie rozwoju aplikacji i infrastruktury, aby podołać wymogom rynku i klientów.

Różne mapy, różne zastosowania

Nie ma jedynego słusznego podejścia do nawigacji. Czego innego potrzebują żeglarze, a czego innego kierowcy wielkich ciężarówek. Podobnie jest z mapami zależności aplikacji. Zespół inżynierów sieci będzie potrzebować innych informacji niż zespół developerów czy architektów aplikacji.

Kiedy trzeba zdiagnozować problemy z dostępnością czy wydajnością aplikacji, liczy się czas i zaangażowanie. Bez mapy zależności jest to proces prowadzony nieco po omacku i z niewielką skutecznością. Ale nie wszystkie techniki tworzenia takich map są równie proste, skuteczne i dostarczają wyników o takiej samej wartości dla odbiorcy.

Z punktu widzenia inżyniera odpowiedzialnego za zdiagnozowanie i naprawienie problemów, istotne są następujące pytania:

1. Ile czasu wymaga konfiguracja narzędzia do stworzenia i użycia mapy?

2. Jak mapa pomaga inżynierom w identyfikacji problemów w czasie rzeczywistym?

3. Czy i jak można zintegrować stosowanie map z procesem troubleshootingu?

4. Czy można przeprowadzić analizę zmienności mapy w czasie w celu identyfikacji potencjalnych zmian w zależnościach?

Statyczne mapy architektów

Bardzo często proces projektowania i dokumentowania rozwoju aplikacji czy infrastruktury uwzględnia mapowanie architektury za pomocą popularnych narzędzi do tworzenia diagramów, takich jak Visio, draw.io, czy OmniGraffle. Statyczne mapy są niezłym narzędziem pomagającym w zrozumieniu koncepcji. Kiedy jednak trzeba zdokumentować szczegóły, a jednocześnie uwzględnić dynamikę projektu, czas poświęcony na manualną aktualizację statycznych map zwiększa się w zastraszającym tempie i zwykle po jakimś czasie mapy stają się nieaktualne. Ich wartość spada do zera, jeśli dynamika aplikacji czy środowiska jest duża. Dlatego z punktu widzenia powyższych pytań, mapy statyczne nie są wiarygodnym źródłem informacji i przydatnym narzędziem w procesie rozwiązywania problemów.

Istnieją jednak inne, lepsze metody tworzenia map zależności. Metody zautomatyzowane, uwzględniające dynamikę środowisk, umożliwiające integrację map.

Mapy Viavi dla zespołów sieci i utrzymania usług

Apex, moduł analityczny wchodzący w skład rozwiązania Viavi Observer, pozwala na generowanie map na żądanie (On-demand Application Dependency Map). Mapy takie są wykreślane na podstawie danych pakietowych (wire data, packet data), czyli de facto analizy ruchu sieciowego w centrum danych i chmurze. Observer taką analizę prowadzi na bieżąco, a dla metryk ważnych z punktu widzenia dostępności lub wydajności wyliczany jest baseline. Dzięki temu, na mapie, poza zależnościami, widać również wydajność usług.

Mapa zależności aplikacji z modułu Apex

Powyższa mapa uwzględnia wszystkie usługi, które we wskazanym oknie czasowym były w użyciu przez konkretną maszynę (10.107.135.42). Mapa jako obraz jest stosunkowo łatwa do zrozumienia i oferuje szereg udogodnień, pozwalających na szybką diagnostykę:

  • Dla każdego węzła grafu mamy listę połączeń ze statusami.
  • Możemy wygenerować mapę zależności (On-Demand ADM) dla wskazanego węzła:
  • lub przeprowadzić analizę dynamiki połączeń (Connection Dynamics) oraz ekstrakcję pakietów (Trace Extraction) z ruchu wybranego węzła:

Korzyści dla inżynierów sieci, jakie płyną z takiego podejścia, są nie do przecenienia. Dostają oni nie tylko łatwą do zrozumienia informację o zależnościach usług, ale również zawężoną do konkretnego kontekstu pomoc w identyfikacji i diagnozie problemów z aplikacją, bez konieczności angażowania całego zespołu i wielu różnorodnych narzędzi. Dodatkowo, korzystając z dostępnego w Observerze REST API, można informację o zależnościach wyprowadzić do zewnętrznego narzędzia do wizualizacji danych.

Mapy Viavi to idealne narzędzie, jeśli analizujemy i diagnozujemy awarię w szerszym kontekście, nie do końca znając jej źródło. Dzięki takim mapom, inżynierowie są w stanie błyskawicznie wyizolować problematyczny obszar i ustalić dokładniejszy kontekst. A kiedy kontekst jest lepiej znany i wiadomo, że problem nie leży w sieci lub działaniu podstawowych usług sieciowych, trzeba skorzystać z narzędzi bardziej skoncentrowanych na aplikacjach.

Mapy Dynatrace dla zespołów aplikacyjnych

Dynatrace to platforma Digital Performance Monitoring trzeciej generacji, zapewniająca wgląd w full stack aplikacji, począwszy od centrum danych, przez serwery, system operacyjny, procesy i serwisy, aż do poziomu aplikacji i aktywności użytkowników. Platforma monitoringu Dynatrace, wykorzystując algorytmy sztucznej inteligencji i uczenia maszynowego, w sposób automatyczny zbiera, modeluje i generuje mapy zależności aplikacyjnych w wielowarstwowym modelu zwanym Smartscape. Na bazie danych z tego modelu, Dynatrace jest w stanie w sposób całkowicie automatyczny zidentyfikować problem z wydajnością aplikacji, zanim się rozleje w systemie i dotknie wszystkich użytkowników.

Smartscape zapewnia dynamiczne mapowanie wszystkich warstw i komponentów aplikacji oraz relacji między nimi. Użytkownicy dostają mapę zależności pomiędzy monitorowanymi hostami, procesami (w tym połączeniami sieciowymi – to element podobny do map Viavi) oraz usługami aplikacyjnymi.

Takie podejście pozwala na jednoczesne modelowanie i mapowanie zależności w architekturze aplikacji oraz zależności w infrastrukturze.

Mapy Dynatrace są dynamiczne, uwzględniają zmienność środowiska aplikacyjnego w czasie i pozwalają na błyskawiczne przejście do szczegółowej analizy każdego z komponentów. Jest to szczególnie przydatne podczas troubleshootingu problemów wydajnościowych aktualnie trwających problemów. Przypadek Knight Capital miał naturę inną niż wydajnościowa, ale pewnie nigdy by się nie zdarzył, gdyby wówczas dostępny był Dynatrace, bo wykrycie wyjątkowo dużego wolumenu zakupów (anomalii w transakcjach biznesowych) nastąpiłoby automatycznie i prawdopodobnie wyszłoby jeszcze w fazie testów wydajnościowych. Nawet gdyby zdarzyłoby się to na środowisku produkcyjnym, znalezienie tego problemu byłoby formalnością.

Zresztą, w Dynatrace również problemy są mapowane, co pozwala developerom i architektom na zrozumienie natury i dynamiki problemów. Dynamika problemu w czasie jest ilustrowana za pomocą mapy zwanej Visual resolution path.

Ten typ odwzorowania pełni funkcje inne niż poprzednie mapy, ponieważ jego kontekst dotyczy jedynie konkretnego problemu i komponentów będących na jego ścieżce. Ale korzyści z jego zastosowania są nie do przecenienia, ponieważ to jedyna mapa, która pozwala na zrozumienie dynamiki i natury problemu. A przez to może pomóc w uniknięciu podobnych zdarzeń w przyszłości.

Brakujące ogniwo – infrastruktura sieciowa

Wcześniej omówione typy map są bardzo potrzebne w zastosowaniach praktycznych i niosą wiele wymiernych korzyści, lecz nie dają pełnego obrazu monitorowanych środowisk. Brakuje tu perspektywy infrastruktury sieciowej, bez której nie działałyby żadne aplikacje czy usługi. Co prawda, Smartscape oferuje widok w warstwie hostów i ich przynależności do centrów danych, ale uwzględnia on tylko monitorowane serwery. Istnieje jednak typ mapy, która zapewnia pełne odwzorowanie infrastruktury sieciowej (routery, switche, firewalle itp.) zapewniającej łączność w środowisku aplikacyjnym. Szczególną i niezbędną właściwością rozwiązania do mapowania zależności w infrastrukturze jest automatyczne wykrywanie urządzeń. Jednym z takich rozwiązań jest SightOps, wchodzący w skład pakietu Viavi Observer. SightOps jest uniwersalnym narzędziem, przystosowanym do pracy zarówno w sieciach korporacyjnych, jak i środowiskach w chmurze publicznej i prywatnej.

Mapa infrastruktury, podobnie jak wcześniej omówione mapy, może być wykorzystana w celach dokumentacyjnych oraz diagnostycznych. Mapa ta również jest generowana dynamicznie i aktualizowana na bieżąco, aby odwzorować zmiany w czasie. Dlatego tak ważne jest, aby mechanizm wykrywania komponentów infrastruktury był w pełni zautomatyzowany i wykorzystywał różnorodne mechanizmy. Jedyne, czego potrzebuje SightOps, to wstępna konfiguracja metod wykrywania komponentów infrastruktury sieciowej.

Mamy mapy i co dalej?

Jak nawigator na statku, tak i współczesny inżynier sieciowy, developer czy architekt potrzebuje kompletu map, aby pokonać drogę z punktu A do punktu X przez wiele punktów pośrednich. Mapy powinny spełniać szereg wymogów.

Zerowa lub minimalna konfiguracja
Ich tworzenie musi działać bez konfiguracji (lub z minimalną wstępną konfiguracją) i być zautomatyzowane, jeśli chodzi o wykrywanie komponentów i relacji.
Dynamiczność
Mapy muszą być dynamiczne, zarówno jeśli chodzi o pozyskiwanie danych wejściowych, jak i generowanie końcowego odwzorowania. To szczególnie ważne tam, gdzie DevOps zyskuje na znaczeniu w środowiskach produkcyjnych.
Kontekst
Muszą być kontekstowe lub łatwe do wprowadzenia kontekstu, w przeciwnym razie nadmiar szczegółów sprawi, że informacja topologiczna będzie bezużyteczna.
Wyszukiwanie
Informacja na mapach musi być łatwa do wyszukiwania, co jest szczególnie ważne w wielkich lub szybkozmiennych, samoskalujacych się środowiskach.
Integracja/API
Dane o węzłach i ich relacjach muszą być łatwe do wyeksportowania poprzez API w celu integracji na innych platformach.

Każde środowisko ma swoją specyfikę, a użytkownicy często niepowtarzalne i odmienne potrzeby. Stąd też bardzo ważna jest możliwość integrowania informacji topologicznej pochodzącej z rożnych źródeł. Dynatrace, podobnie jak Observer, posiadają REST API do map. Stąd już stosunkowo krótka droga do automatycznej dokumentacji, zasilania baz CMDB czy analityki np. pod kątem optymalizacji procesów, usług czy infrastruktury w hybrydowych środowiskach IT.

Mapa Omniflow dla biznesu

Jednym z zastosowań bazujących na integracji danych z narzędzi do monitoringu jest mapa Omniflow. Omnilogy stworzyło narzędzie do mapowania i optymalizacji procesów – Omniflow. Jest to mapa zasilana danymi pochodzącymi z Dynatrace, choć źródłem może być dowolne narzędzie monitorujące zachowania użytkowników aplikacji. Omniflow wykorzystuje te dane do odwzorowania przepływów w aplikacji oraz heurystyki i algorytmy uczenia maszynowego do automatycznej identyfikacji anomalii czy wąskich gardeł w procesie.

Mapa przepływów jest idealnym narzędziem dla architektów i projektantów aplikacji oraz działów biznesowych, które zajmują się optymalizacją procesów (np. procesu sprzedaży). Dzięki rozbudowanym filtrom wpływającym na odwzorowanie informacji topologicznej, jest to zaawansowane i bardzo wygodne narzędzie do analityki.

Czego potrzebuje kapitan

Im wyżej w hierarchii jest odbiorca, tym bardziej syntetycznego obrazu potrzebuje. Kapitan (CIO) twojego okrętu (firmy) nie ma czasu, choć może i miałby ochotę, na analizę szczegółowej informacji technicznej. Na bazie informacji z monitoringu, w tym map, możesz przygotować syntetyczny przekaz, którego zadaniem jest informowanie np. o postępach migracji usług (z DC do chmury), postępie w realizacji nowych inicjatyw albo skuteczności w naprawie awarii. Dzięki API i wbudowanym mechanizmom do budowania dashboardów, taka informacja będzie zawsze aktualna i dostępna, pod warunkiem, że twoje środowisko jest monitorowane 24/7/365.

Monitoring to fundament

Należy pamiętać, że pierwszoplanową funkcją przytoczonych tu narzędzi (Observer, Dynatrace) nie jest mapowanie zależności, a monitoring środowisk IT. Mapy są przydatnym i wartościowym dodatkiem, ale ich wygenerowanie możliwe jest dopiero wówczas, gdy środowiska są stale monitorowane. Jeśli chcesz spróbować, jak Dynatrace działa w twoim środowisku, zarejestruj się na darmowy trial pod dynatrace.com/trial. Jeśli chcesz spróbować innych omówionych tu rozwiązań albo potrzebujesz porady, jak zbudować nowoczesny i wydajny monitoring, skontaktuj się z nami.

Materiały źródłowe: Viavi SolutionsDynatraceOmnilogy

Sprawdź także

Zadzwoń +48 22 657 0438

lub wypełnij formularz, a skontaktujemy się z Tobą!

Nazywam się
i jestem zainteresowany
Proszę o kontakt pod adresem
lub numerem tel.