Wybieraj, twórz i śledź metryki jednostek dla swoich aplikacji

Gdy działasz w modelu zmiennych wydatków w chmurze, rozwój firmy może przełożyć się na zmienny rachunek, który odzwierciedla aktywność Twoich obciążeń w Twoim środowisku. Dla niektórych klientów miesięczny wzrost rachunku za AWS jest normalną częścią wzrostu, ale dla znacznej części jest niepożądanym skutkiem. Dlatego ważne jest, aby wykorzystać odpowiednie wskaźniki do oceny ekonomiki infrastruktury.

Metryki jednostkowe, zdefiniowane jako „koszt na wartość biznesową”, pozwalają mierzyć koszty pod względem dostarczanej wartości biznesowej. Na przykład firma zajmująca się handlem elektronicznym może chcieć poznać „koszt wizyty klienta” lub „koszt konwersji” oprócz łącznego rachunku za rozwiązanie e-commerce w chmurze, ponieważ oczekuje się, że te dwie wartości biznesowe wzrosną . Pomaga to oddzielić wpływ wahań wzrostu firmy od kosztów; zapewniając jaśniejsze, bezstronne i wnikliwe informacje. W idealnej sytuacji możesz chcieć zobaczyć, jak wskaźniki jednostek spadają lub przynajmniej pozostają takie same. Za pomocą metryk jednostkowych możesz ocenić, jak efektywnie Twój zespół wykorzystuje zasoby technologiczne, prognozować przyszłe potrzeby w zakresie wydatków i inwestycji, a także uzyskać poparcie i opowiedzieć „historię wartości IT” w swojej organizacji. Metryki jednostkowe są również przydatnymi narzędziami dla zespołów IT, aby skuteczniej komunikować się z ich działami finansowymi. Chociaż specyfika metryk jednostkowych może się różnić w zależności od branży i firmy, metodologia wyboru, obliczania i używania metryk jednostkowych pozostaje taka sama.

Zanim rozpoczniesz

Nawet jeśli treść tego artykułu nie wymaga wdrożenia poniższych elementów, przed przystąpieniem do wdrażania zaleca się przejrzenie poniższej listy implementacji:

1. CUDOS Dashboard to dogłębny, szczegółowy i oparty na rekomendacjach pulpit nawigacyjny, który pomaga zagłębić się w koszty i zużycie. Ten artykuł odnosi się do CUDOS, który wdraża ostateczny pulpit nawigacyjny. Jednak przedstawione tutaj rozwiązanie ma zastosowanie do każdego wdrożenia Cloud Financial Management (CFM) lub Business Intelligence (BI), o ile obsługuje Amazon Athena.
2. AWS Organizations to usługa zarządzana przez AWS, która pomaga centralnie zarządzać kontami AWS w Twojej organizacji. Nadal możesz korzystać z tego rozwiązania dla jednego konta AWS, ale artykuł ma na celu adresowanie organizacji składających się z wielu kont AWS.
3. Resource tagging to jedna z najlepszych praktyk śledzenia i znajdowania zasobów. Metadane są przypisywane do zasobu w postaci tagów, par klucz-wartość. Będziemy używać tagów do wyszukiwania zasobów związanych z biznesem i związanych z nimi kosztów.

Autorzy artykułu wybrali przykładową aplikację, aby pokazać, jak obliczać metryki jednostkowe w tym artykule: Document Understanding Solution (DUS). Ta aplikacja korzysta z AWS AI/ML, obliczeń, baz danych, pamięci masowej, przesyłania wiadomości i usług aplikacji do analizowania dokumentów tekstowych. Zakłada się, że DUS jest interfejsem API używanym przez użytkowników, którzy uzyskują wgląd w dokumenty dzięki udanym wywołaniom, co napędza przychody. Możesz wdrożyć tę przykładową aplikację zgodnie z wyjaśnieniem (opcjonalnie) lub postępować zgodnie z instrukcjami i zastosować rozwiązanie we własnej aplikacji. Należy jednak pamiętać o kosztach związanych z tą aplikacją.

Krok pierwszy: wybór znaczących metryk jednostkowych

Metryka jednostkowa to kluczowy wskaźnik wydajności (KPI) składający się z licznika, który określa ilościowo kwotę wydatków AWS (np. „Całkowity koszt dostarczenia wartości AWS”) oraz mianownika, który określa ilościowo siłę napędową popytu (np. X'), gdzie „X” to wszelkie dane biznesowe, które stanowią wartość dla Twojej organizacji; takie, że;

Unit Metric = Cost Data / Business Data

Mianownik ma silną korelację statystyczną z licznikiem i jest metryką, którą można łatwo odnieść do reprezentowanych funkcji biznesowych, finansowych lub użytkowników końcowych. Wybór właściwej miary kosztu jednostkowego jest pierwszym i najważniejszym krokiem. W związku z tym zaangażowanie interesariuszy biznesowych i zespołów finansowych na wczesnym etapie procesu pomaga w wyborze odpowiednich wskaźników jednostkowych dla Twojej firmy.

W omawianym przykładzie aplikacji DUS punkt końcowy zapewnia wartość, konwertując dokumenty na szczegółowe informacje. Wybrano „Number of Critical Documents Analyzed by Specialists” jako miarodajną metrykę jednostkową. Możesz łatwo zmodyfikować tę metrykę, aby nadawała się „na analizowaną stronę” lub „na 100 analizowanych słów”. Dodatkowo inną metryką jednostkową, stosowaną w wielu aplikacjach, jest „Cost per Successful API response”. Parametr biznesowy oparty na interfejsie API jest bardziej elastyczny i ma zastosowanie do innych przypadków użycia.

Krok drugi: Lokalizowanie źródeł danych

Drugim krokiem jest zlokalizowanie źródeł danych dostarczających danych wejściowych do obliczeń metryk jednostkowych, mianowicie: źródła danych dotyczące kosztów i danych biznesowych.

Koszt danych (licznik)

Twoje obciążenia mogą obsługiwać więcej niż jedną aplikację lub być wdrażane w wielu środowiskach, takich jak programowanie, testowanie i produkcja. Każda aplikacja lub środowisko może mieć inne wymagania dotyczące rachunkowości. Dlatego ważne jest, aby najpierw oddzielić rzeczywiste koszty aplikacji od całkowitego rachunku za AWS. Jednym ze sposobów jest wykorzystanie środowiska produkcyjnego, które jest generalnie głównym czynnikiem generującym koszty i zapewnia wartość biznesową dla użytkowników końcowych.

Proces pozyskiwania danych o kosztach nie jest unikalny dla aplikacji CUD. Możesz wyodrębnić dane o kosztach aplikacji wdrożonych w AWS za pomocą raportu AWS Cost and Usage Report (AWS CUR), który zawiera najbardziej wszechstronny zestaw danych o kosztach i użytkowaniu. CUR może być dostarczany do określonego segmentu Amazon S3, co godzinę, codziennie lub co tydzień, w zależności od Twojego wyboru. Możesz zastosować interfejsy API AWS CUR do tworzenia, pobierania lub usuwania CUR programowo. Jeśli już wdrożyłeś pulpit nawigacyjny CUDOS zgodnie z zaleceniami w sekcji Before Getting Started, miałbyś już raport CUR w swoim zasobniku S3. W przeciwnym razie możesz samodzielnie utworzyć Raport kosztów i użytkowania.

Dane biznesowe (mianownik)

Lokalizowanie danych biznesowych może nie być tak proste jak danych o kosztach, ponieważ źródła danych biznesowych zależą od rodzaju działalności i aplikacji. Innymi słowy, istnieją dwa popularne sposoby praktykowane przez klientów AWS:

• Zapytania programowe mogą w sposób programowy dostarczać dane biznesowe. Amazon CloudWatch, bazy danych, datalake lub pamięć masowa to powszechne źródła zapytań o dane w celu uzyskania zagregowanych informacji biznesowych. Tymi zasobami mogą być zasoby AWS (np. Amazon RDS, S3, Aurora, DynamoDB, Redshift) lub zasób zewnętrzny (np. JDBC).
• Metoda manualna/ad-hoc może być zawsze częścią procesu, ponieważ ludzie mogą chcieć ręcznie wypełnić te dane w arkuszach kalkulacyjnych MS Excel, plikach CSV, plikach PDF, prezentacjach itp.

Powyższe metody nie wykluczają się wzajemnie; możesz ich używać jednocześnie.

Metoda zapytań programowych: interfejsy API to popularne sposoby wysyłania zapytań do danych za pośrednictwem zestawów SDK, interfejsów CLI AWS lub konsoli AWS. Na przykład danymi mogą być liczba „aktywnych użytkowników”, „sesji” lub „zakupów klientów”, które mają być dostępne w bazie danych w ramach normalnego procesu biznesowego.

W przykładowej aplikacji DUS wykorzystano Amazon CloudWatch Metrics do zapytania „Liczba udanych wywołań API” wykonanych do Amazon API Gateway. Włączono metryki Amazon API Gateway, aby śledzić pomyślne odpowiedzi API (np. z nagłówkiem HTTP 2XX). Jeśli metryka nie byłaby dostępna, utworzono by niestandardową metrykę CloudWatch i użyto tej samej metody. Zastosowano API GetMetricData w Amazon Cloudwatch Insights, aby efektywnie kosztowo wysyłać zapytania na żądanie. Ten interfejs API jest szczególnie przydatny w przypadku okazjonalnych żądań, tak jak w omawianym przypadku.

Przykładowa aplikacja go nie miała, ale w niektórych przypadkach niektóre dane biznesowe mogą znajdować się w bazach danych, ale nie w CloudWatch. W takim przypadku możesz użyć AWS Lambda z Amazon Event Bridge do planowania wywołań Lambda i wykonywania zapytań programowych z odpowiednim dostępem. Możesz odnieść się do AWS Constructs, aby zobaczyć szablony kodu dla AWS Lambda i źródła danych utworzone dla najlepszych wdrożeń.

Metoda manualna/ad-hoc: możesz mieć wyspecjalizowany zespół, który ręcznie wypełnia dane biznesowe oprócz lub równolegle do metody zautomatyzowanej. Niezależnie od używanej metody autorzy zalecają wyodrębnianie danych biznesowych do pliku (lub plików) w formacie CSV (Comma Separated Values), który jest oparty na wierszach i ma natywną integrację z komercyjnym oprogramowaniem do obsługi arkuszy kalkulacyjnych (np. „Zapisz jako” w MS Excel). Użyto również prostego schematu tabeli z pierwszą kolumną podającą datę reprezentującą czas metryki biznesowej, a pozostałe kolumny podające wartości biznesowe. Podczas gdy my twórcy używali plików CSV i prostej tabeli do przedstawiania metryk biznesowych w czasie, Ty masz możliwość zastosowania własnego schematu i obsługiwanych formatów plików dzięki funkcjom Glue Crawler.

Dla przykładowej aplikacji DUS „Liczba krytycznych dokumentów przeanalizowanych przez specjalistów” reprezentuje metodę ręczną. Założono, że specjaliści kompilują te dane po wyimaginowanym ręcznym kroku i zapisują dane w pliku (plikach) programu Excel.

Krok trzeci: wdrażanie komponentów

Rysunek nr 1 przedstawia architekturę wdrożenia. To rozwiązanie ma cztery bloki: CUDOS Dashboard, Data Sources for Business Metrics, Business Data Collection i Twoja aplikacja (czyli DUS w omawianym przypadku).

• Pulpit nawigacyjny CUDOS jest punktem wyjścia, jak wyjaśniono w sekcji Getting Started.
• Data Sources for Business Metrics zawiera informacje/dane o wartości biznesowej podczas jej normalnej działalności (np. liczba klientów, liczba transakcji itp.).
• Zbieranie danych biznesowych obejmuje AWS Lambda (wykonawca) i Amazon EventBridge (orkiestrator) do wyszukiwania danych biznesowych ze źródeł danych w celu uzyskania metryk biznesowych. Autorzy używają tej samej funkcji AWS Lambda do wysyłania zapytań ze źródeł i tworzenia/umieszczania plików CSV w zasobniku Amazon S3 z wdrożenia CUDOS.
• Twoja aplikacja to aplikacja, która obsługuje użytkowników końcowych w AWS. W tym scenariuszu jest to aplikacja DUS. Należy pamiętać, że Twoja architektura przedstawia wyraźną granicę między źródłami danych dla metryk biznesowych a aplikacją, co nie musi mieć miejsca, ponieważ niektóre lub wszystkie dane mogą znajdować się w aplikacji.

Przechowywanie danych biznesowych w standardowych plikach CSV) na zasobniku S3

Możesz zacząć od utworzenia zasobnika S3 do przechowywania plików CSV ze wszystkich danych biznesowych, które zawierają ręcznie wyselekcjonowany plik csv (np. zasobnik z danymi biznesowymi).

• w razie potrzeby można znaleźć tutaj do pobrania przykładowy plik danych biznesowych opracowany ręcznie (DocumentBusinessMetricsData.csv). Możesz ręcznie przesłać plik obiektu (DocumentBusinessMetricsData.csv) do utworzonego zasobnika S3 (business-metric-bucket); lub możesz użyć AWS Lambda i AWS EventBridge do programowego i/lub automatycznego przesyłania danych biznesowych. Tworzysz i przesyłasz pliki CSV przy użyciu innego schematu do eksperymentowania.

W przypadku metryk biznesowych dostępnych w CloudWatch możesz użyć funkcji AWS Lambda, aby wysłać zapytanie do metryki biznesowej w celu wywołania interfejsu API GetmetricData. Ponieważ przykładowa aplikacja (DUS) korzystała z API Gateway, użyto poniższego zapytania, aby zsumować wszystkie „Udane wywołania API” z naszego ApiName = „dusstack-dusapi-fqvfbqjcsj2fxh9pu242th”.

SELECT SUM(Count) FROM SCHEMA(AWS/ApiGateway, ApiName, Stage)

WHERE ApiName = 'dusstack-dusapi-fqvfbqjcsj2fxh9pu242th' AND Stage = 'prod'

Wyodrębnianie danych CSV do tabel Athena za pomocą AWS Glue Crawler

Następnym krokiem jest utworzenie AWS Glue Crawler. Skonfiguruj zasobnik S3 (business-metric-bucket) jako źródło, a następnie nazwij tabelę wyjściową „unitmetrics-externalsource”. Możesz sprawić, by robot był uruchamiany na żądanie, w oparciu o zdarzenia lub harmonogramy zarządzane przez EventBridge. Powszechną praktyką jest wykorzystywanie zaplanowanych zadań rozpoczynających cały proces, począwszy od wizualizacji metryk, w ramach harmonogramu przeglądu biznesowego (miesięcznego, kwartalnego, tygodniowego itp.). Jednak nadal możesz uruchamiać proces na żądanie lub w sposób sterowany zdarzeniami w oparciu o zdarzenia biznesowe, takie jak ręczne przesyłanie nowego pliku CSV do zasobnika S3 (poprzedni krok) itp.

AWS Glue Crawler uruchamia i tworzy wspomnianą tabelę wyjściową (unitmetrics-externalsource) na podstawie przesłanych plików CSV.

Tworzenie Athena view w celu umocnienia wszystkich danych

• Źródła danych ustanowione przez AWS Glue Crawler można znaleźć w Edytorze zapytań w Amazon Athena, jak pokazano na rysunkach 2(a) i 2(b) poniżej. Tutaj posiadasz dwa źródła danych, jedno z metryk Amazon CloudWatch cloudwatchmetrics-csv i jedno z zewnętrznych plików csv AwsDataCatalog. Pierwsze powinna pokazywać dwie tabele metric_samples i metrics. Drugie powinien pokazywać jedną tabelę unitmetrics_custom.
• Możesz utworzyć Amazon Athena View, aby skonsolidować te źródła danych; tabele logiczne utworzone przez zapytanie SQL.
• Po utworzeniu widoku możesz przejść do poniższej sekcji pulpitu nawigacyjnego Amazon QuickSight. Jeśli korzystasz z innego narzędzia BI, możesz obliczyć metrykę jednostki w widoku Amazon Athena do wykorzystania w innym narzędziu.

Zbuduj pulpit nawigacyjny metryk jednostkowych w Amazon QuickSight

Na tym etapie masz już wdrożone niezbędne tabele i łączniki. Teraz czas na połączenie danych, obliczenie metryk jednostkowych i zbudowanie dashboardu na Amazon QuickSight. Aby wykonać ten krok:

• Najpierw postępuj zgodnie z instrukcjami podanymi na pulpicie nawigacyjnym Cloud Intelligence, sekcja Metryki jednostek. Wybierając zestaw danych, wybierz Athena i dodaj zestaw danych za pomocą opcji „Dodaj zestaw danych” i wybierz widok unitmetrics_custom Athena.
• Następnie wykonaj czynności opisane w sekcji Dostosuj pulpit nawigacyjny w dokumentacji, aby utworzyć pulpit nawigacyjny.

Stworzyłeś dwa przykładowe pulpity nawigacyjne, jak pokazano na rysunku nr 3.

Odinstalowywanie Przykładowej Aplikacji

Jeśli wdrożono przykładową aplikację DUS, możesz postępować zgodnie z instrukcjami, aby odinstalować aplikację.

Interpretacja biznesowa wyników metryk kosztów jednostkowych

Korzystanie z metryk jednostkowych zapewnia przydatny wgląd w wydajność operacji, architekturę i biznes.

Jednym z głównych zastosowań metryk jednostkowych jest umieszczenie kosztów całkowitych w kontekście, jak pokazano na rysunku 3b. Tutaj widać, że „Koszt całkowity” (aplikacji) i „Koszt jednostkowy” (miernik jednostkowy „Koszt analizowanego dokumentu krytycznego”), zostały pokazane razem na wykresie osi czasu, gdzie koszt całkowity stale rośnie, a koszt jednostkowy spada i zaczyna się zbiegać. Jest to powszechny wzorzec, który pomaga wyjaśnić fakt, że całkowity koszt zależy od efektywnego rozwoju firmy (np. właściciele firm mogą wykazać wzrost wydajności dzięki lepszym praktykom kontroli kosztów i ekonomii skali. Jak omówiono w serii artykułów na temat metryk jednostkowych, akceptowalny jest tymczasowy wzrost kosztu jednostkowego podczas migracji obciążeń do chmury i/lub stosowania wymaganych dostosowań do aplikacji (np. błędów technicznych, wymagań prawnych itp.).

Inną dobrą praktyką jest przekształcenie pierwotnego jednostkowego kosztu metryki (np. Kosztu za udaną odpowiedź API lub jak w tym przypadku 0,0021 USD) na wersję bardziej „przyjazną dla użytkownika / czytelną dla człowieka” (np. Koszt za 1000 udanych odpowiedzi API) w celu wyświetlenia podziału kosztów, jak pokazano na rysunku 3a.

Kolejnym krokiem byłoby uzyskanie „jednostkowego przychodu” związanego z czynnikami biznesowymi (np. „Przychód na analizowany dokument”), a dzięki tym informacjom można oszacować „zyski na transakcję” i wyświetlić je na pulpicie nawigacyjnym.

Co dalej?

Za pomocą tego artykułu opisano w szczegółowy sposób, jak wybrać, obliczyć i wdrożyć pulpit nawigacyjny dla metryk jednostkowych w AWS, zapewniając jednocześnie wskazówki krok po kroku za pomocą przykładowej aplikacji korporacyjnej.

Jako najlepszą praktykę autorzy zalecają właścicielom firm ustanowienie procesu zarządzania cyklem życia poprzez ciągłe przeglądanie metryk jednostkowych dla ich aplikacji; poprzez ulepszenie istniejących wskaźników jednostkowych (np. dostrojenie licznika za pomocą dokładniejszego procesu alokacji kosztów lub zwiększenie korelacji mianownika z bardziej odpowiednim czynnikiem napędzającym popyt) i/lub włączenie dodatkowych wskaźników (np. analiza podrzędnych części aplikacji lub uwzględnienie wszystkich nowych aplikacji). Umożliwia to organizacjom przeprowadzanie bezstronnych ocen finansowych, lepsze zrozumienie rentowności biznesu i ostatecznie odblokowanie realizacji wartości dla ich aplikacji w AWS.

Źródło: AWS