Jak ograniczyć niekontrolowany wzrost kosztów AWS w projektach DataOps

Rachunki za chmurę w projektach analitycznych zazwyczaj nie skaczą z dnia na dzień. Znacznie częściej mamy do czynienia z powolnym, trudnym do zauważenia drenażem budżetu, który po kilku miesiącach kończy się trudną rozmową z działem finansowym. Adam Zuzo, inżynier danych, w swoim wystąpieniu na MeetUpie SO/DO omówił, jak zmieniają się wyzwania operacyjne DataOps w zależności od stopnia zaawansowania i skali projektu.

Skąd bierze się dług technologiczny przy małych wolumenach danych?

Na wczesnym etapie wdrażania analityki, gdy wolumen danych nie przekracza 5 TB, kłopoty rzadko wynikają z rzeczywistej złożoności systemów. Częściej odpowiada za nie moda na rozwiązania klasy Big Data. Zespoły sięgają po rozbudowane hurtownie danych, na przykład Amazon Redshift, mimo że w praktyce operują na kilkuset gigabajtach zwykłych plików CSV. Utrzymywanie klastra działającego w trybie provisioned, czyli rozliczanego za godziny pracy węzła obliczeniowego, prowadzi wówczas do rachunków liczonych w tysiącach dolarów za instancję, która przez większą część doby stoi bezczynnie.

Zdaniem Adama Zuzo przy niewielkiej skali projektu najważniejsza jest zasada brzytwy Ockhama, czyli świadome upraszczanie architektury. Zamiast opłacać drogie, stale dostępne węzły hurtowni danych, warto oprzeć się na podejściu serverless — na przykład odpytywać dane bezpośrednio z S3 przy pomocy Amazon Athena oraz lekkich funkcji AWS Lambda. Zmiana modelu rozliczeń z opłaty za czas pracy na opłatę za liczbę zeskanowanych bajtów, jak w przypadku Athena, może obniżyć wydatki na infrastrukturę DataOps nawet o ponad 90 procent. Ta sama logika dotyczy narzędzi Business Intelligence — korzystanie równolegle z sześciu różnych platform analitycznych, na przykład Tableau, PowerBI czy Superset, prowadzi do rozproszenia wiedzy w zespole i podwójnych kosztów licencji. Przy mniejszej skali projektu ograniczenie się do jednego narzędzia BI wyraźnie zmniejsza niepotrzebne wydatki.

Jak partycjonowanie danych chroni budżet firmy przy średniej skali projektu?

Wraz z rozwojem organizacji, gdy rośnie liczba tabel i liczba analityków biznesowych korzystających z danych, kontrola nad kosztami zaczyna słabnąć z powodu nieefektywnych zapytań. Odpytanie tabeli o rozmiarze 10 TB, która nie została podzielona na partycje, wymusza na silniku bazy danych skanowanie wszystkich wierszy, zanim na końcu odfiltrowany zostanie interesujący fragment, na przykład dane z ostatniego tygodnia. Taki mechanizm podwójnie obciąża budżet przeznaczony na chmurę.

Wyjściem z tej sytuacji jest konsekwentne stosowanie partycjonowania oraz mechanizmu partition pruning. Kiedy dane w pamięci masowej zostaną fizycznie podzielone według wybranego klucza, na przykład daty albo segmentu rynku, silnik zapytań może z góry pominąć zbędne fragmenty i pobrać z AWS S3 jedynie niewielką część zbioru. Dzięki temu drastycznie spada liczba skanowanych megabajtów. Na tym etapie istotne jest również, by nie polegać ślepo na jednym narzędziu BI. Przykładowo Apache Superset przesyła zapytania do silnika analitycznego zdefiniowanego w konfiguracji. Zamiana konektora z Amazon Athena na Snowflake — albo odwrotnie — może przy tych samych dashboardach nawet dziesięciokrotnie zmienić wysokość rachunków, w zależności od modelu cenowego danego dostawcy: opłaty za skan danych czy za czas wykonania zapytania.

Dlaczego zaniedbanie kompresji i formatów plików szkodzi analityce Big Data?

Przy bardzo dużej skali, powyżej 100 terabajtów, a nierzadko sięgającej petabajtów danych, pozornie drobne kwestie techniczne zaczynają mieć ogromny wpływ na finanse. Zespoły pracujące z Big Data powinny regularnie przenosić archiwalne, rzadko wykorzystywane logi i metryki do tańszych, chłodniejszych klas pamięci masowej, na przykład z S3 Standard do S3 Infrequent Access. Podstawą kontroli kosztów w tak dużej skali w AWS jest korzystanie z dedykowanych dashboardów S3 Storage Lens.

O tym, czy system będzie działał sprawnie w skali makro, decyduje ostatecznie architektura wykorzystywanych plików. Ekspert zwraca uwagę zespołom inżynieryjnym, że format .json różni się fundamentalnie pod względem fizycznej struktury danych od formatów .parquet czy .orc. Pliki kolumnowe, takie jak Parquet skompresowane algorytmem Snappy, świetnie sprawdzają się przy odpytywaniu ogromnych tabel w hurtowniach danych, natomiast silniki oparte na AWS Athena mogą praktycznie się zablokować przy próbie odczytu tysięcy niewielkich plików w formacie CSV czy ORC. Co więcej, mocniejsze algorytmy kompresji, na przykład GZIP, owszem obniżają koszt przechowywania danych o niewielkie kwoty w porównaniu do standardowych rozwiązań, jednak dekompresja takiego pliku w czasie rzeczywistym bywa na tyle czasochłonna i obciążająca dla klastra obliczeniowego, że firma traci wszystkie wcześniej wypracowane oszczędności.

Pogłębij wiedzę o optymalizacji kosztów razem z SysOps/DevOps Polska

Prowadzenie rozbudowanej infrastruktury chmurowej bez znajomości zasad optymalizacji to najprostszy sposób na przepalenie budżetu firmy. Osoby zainteresowane pełnym zestawem wykresów kosztowych przygotowanych przez Adama Zuzo oraz dalszym zgłębianiem tematu DataOps mogą skorzystać z poniższych możliwości.

• Meetupy SO/DO: teoria to jedno, ale nic nie zastąpi rozmów w kuluarach — warto dołączyć do społeczności inżynierskiej i wziąć udział w bezpłatnych spotkaniach organizowanych w całej Polsce, a kalendarz najbliższych wydarzeń dostępny jest pod adresem https://www.sysopspolska.pl/eventy/
• Budowa infrastruktury jako kodu oraz efektywne wykorzystanie usług chmurowych wymagają solidnych podstaw — szkolenia z inżynierii DevOps, chmury publicznej AWS oraz Kubernetes Security znajdują się pod adresem https://www.sysopspolska.pl/szkolenia/, co pomaga uniknąć nieprzyjemnych niespodzianek na fakturach od dostawców chmurowych
• Dla osób zainteresowanych sztuczną inteligencją przygotowano osobną ścieżkę — cykl bezpłatnych webinarów AI Now Polska

Pełne nagranie prelekcji Adama Zuzo pod tytułem DataOps i koszty: operacyjne wyzwania danych jest dostępne do obejrzenia online.