RASP: od dwóch własnych centrów danych do public cloud

Z Wojciechem Struskim, Chief IT Architect w Ringier Axel Springer Polska rozmawiamy o 4-letnim procesie migracji do chmury; powodach i argumentach stojących za tą decyzją; podejściu do migracji i roli, jaką miał w niej zarząd; testach przed migracją i optymalizacji zasobów IT przed jej rozpoczęciem; osiągniętych korzyściach; najważniejszych, wyciągniętych lekcjach, m.in. przez programistów; elastycznym zarządzaniu infrastrukturą w chmurze; a także zarządzanie jej kosztami.

DECYZJA

Jak doszło do tego, że Ringer Axel Springer Polska w całości zmigrował do chmury?

W 2017 roku zaczęliśmy rozmowy z zarządem pokazując różnego rodzaju wyliczenia, modele dotyczące wykorzystania infrastruktury IT, w tym ocenę skutków każdego z nich, a także analizę tego, co się stanie jak zmigrujemy się do chmury publicznej.

W marcu 2018 roku dostaliśmy zaś zgodę Rady Nadzorczej, aby przeprowadzić projekt i rozpocząć rozmowy z Amazon Web Services o umowie. Po wielu analizach i audytach zdecydowaliśmy, że podpiszemy umowę na 5 lat. Z tego pierwsze 3 lata zajmie sam proces migracji. Przez kolejne dwa będziemy „spalać” tyle pieniędzy, ile obiecaliśmy w umowie.

Z punktu widzenia umowy mniej istotne było to, kiedy się zmigrujemy, a bardziej to, kiedy rzeczywiście zaczniemy używać zasobów chmury w pełnej skali. Sam proces migracji może być dosyć płynny. Przykładowo, gdy powstanie nowy produkt możemy go dorzucić do migrowanego portfolio.

Od roku 2018, przez kolejne 4 lata trwała migracja. Kolejne parę miesięcy spędziliśmy na „sprzątaniu” po migracji. Polegało to na wyłączaniu ostatnich maszyn i systemów w dotychczasowym centrum danych.

Co ostatecznie przekonało zarząd, że warto zrezygnować z własnej infrastruktury na rzecz chmury obliczeniowej?

Mogę powiedzieć jaką ja miałem motywację „sterując” w tym kierunku. Odpowiadałem wówczas w firmie za budowę prywatnej chmury obliczeniowej. Kierując jej rozwojem stwierdziłem, że dochodzimy do rozlicznych barier w dalszej jej rozbudowie.

Przede wszystkim dokładanie kolejnych, technologicznych usług zarządzanych, powodowało, że coraz trudniejsza była rozbudowa naszej infrastruktury. Coraz bardziej skomplikowana stawała się też integracja kolejnych jej elementów. Trudności wzrastały wręcz eksponencjalnie wraz z każdym, kolejnym, dokładanym do takiego systemu elementem. Dokładanie kolejnych usług w naszej chmurze prywatnej zajmuje nawet kilka kwartałów.

Co ważniejsze, mieliśmy coraz większe problemy z pozyskiwaniem osób, które potrafią zrobić to dobrze. Nasza firma nie ma też w core biznesie rozbudowy i oferowania usług technologicznych. W związku z tym podnoszenie inwestycji w ten obszar jest, jeśli się tak wyrażę, trudne.

Druga rzecz to taka, że ceny jednostkowe za usługi cloud computing stawały się coraz niższe. A obserwujemy ten rynek od roku 2010. Ceny infrastruktury – naszej i dostawców public cloud – zaczynają być porównywalne jeśli weźmie się parametr Total Cost of Ownership, a więc wszystkiego wokół, co pozwala na nieprzerwaną pracę, w tym koszt specjalistów.

Stwierdziłem wówczas, że jeśli będziemy dalej szli w tę stronę, to utracimy zdolność dostarczania biznesowi funkcjonalności w tempie w jakim tego oczekuje. Jako IT przestaniemy „dowozić”.

PLANOWANIE, PRZYGOTOWANIE, OPTYMALIZACJA

Jak postanowiliście podejść do tego problemu?

Było to o tyle trudne, że ścieżka – finansowo – była dość wąska. Musiało się też udać kilka rzeczy naraz. Po pierwsze musieliśmy zredukować nasze zużycie zasobów o kilkadziesiąt procent. Po drugie musieliśmy mieć możliwość uwolnienia części osób, które zajmowały się infrastrukturą IT i programowaniem do innych zadań. Warto podkreślić, że z powodu naszej migracji do chmury absolutnie nikt nie został zwolniony.

Myślę, że te dwa punkty – zwiększenie efektywności i zaangażowania ludzi oraz zmniejszenie zużycia własnych zasobów IT – spowodowało, że dało się narysować wykres całkowitych kosztów w chmurze, które – w długim terminie – były niższe niż koszty wynikające z posiadania własnej infrastruktury. Model robiłem kilka miesięcy zbierając i porównując dane.

A w jaki sposób ograniczyliście zasobożerność własnych zasobów IT?

Nasze podejście można by podzielić na dwa aspekty. Jeden to skalowanie zasobów zgodnie z cyklem użycia produktu, czyli np. skalowanie w dół w nocy czy w weekend. Drugi to mądrzejsze użycie rozwiązań IT. O tym można by zapewne napisać całą książkę.

Przykładowo kiedy inwestowaliśmy w nasz – największy wówczas w Polsce – klaster Hadoopa, o pojemności ok. 10 PB, to zakładaliśmy – z dzisiejszej perspektywy bardzo niemądrze – że będziemy w nim trzymać wszystkie dane, jakie zbierzemy. Kiedyś mogą się przydać. Czas zweryfikował nasze założenia. Jak nie do końca wiesz po co zbierasz dane, to te dane się do niczego nie nadają. Działa zasada „garbage in, garbage out”. To też pokazuje pewien sposób myślenia o własnej infrastrukturze.

Jeśli mamy własne zasoby, kupione z dużym nadmiarem, to zaczynamy używać wolnych mocy obliczeniowych w sposób, którego nigdy w życiu nie uzasadnilibyśmy tak wysokimi wydatkami. Nie możemy wrzucać do naszego Hadoopa dowolnych danych tylko dlatego, że „mamy miejsce”. Zarząd nie dałby na ten projekt kilku milionów złotych bazując na takim założeniu. Niestety zazwyczaj z przewymiarowaną infrastrukturą tak się w końcu dzieje.

Racjonalizacja użycia zasobów IT polegała na tym, że przykładowo przy migracji platformy Big Data „wyrzuciliśmy” nawet 50 proc. raportów, które były generowane na poprzedniej infrastrukturze. Nikt i tak ich nie oglądał. Czy można to zrobić na infrastrukturze on-premise? Zapewne tak, ale nigdy nie będzie do tego okazji. Cóż więc, że jest taka możliwość, kiedy nikt, nigdy tego nie zrobi.

Kiedy już wiemy, że mamy te „zapasowe słonie w szafie”, choć one bardzo niechętnie się ujawniają, staramy się ich pozbyć przy migracji. Robimy to, bo po jej zakończeniu płacimy w zasadzie za każdy request, „zakręcenie się” dysków czy użycie interfejsu. Wówczas nawet te osoby, które chomikowały te „słonie”, nagle uznają, że są niepotrzebne. Widzą rachunek i to, ile przechowywanie tych danych kosztuje.

Rozumiem, że każdy dział dostaje rachunek za zużycie zasobów w chmurze?

My tak robimy. Choć nie jest to proste, bo zbiór kont w infrastrukturze AWS mamy jeden dla całej organizacji. Natomiast mamy własne mechanizmy alokacji zużycia zasobów IT. Dzięki temu każdemu produktowi, każdemu systemowi potrafimy przypisać zużycie do danego obszaru, a także – niezależnie od innych – optymalizować je.

O ile udało się Wam zmniejszyć „zużycie” zasobów IT?

Jeśli licząc liczbę rdzeni procesorów to jest to dobre kilkadziesiąt procent. Dokładnie zmniejszyła się ona z ok. 6000 do 4000 rdzeni. Co ciekawe, jedną z głównych optymalizacji, którą sprzedawcy chmury pokazują, jest zwiększenie utylizacji zasobów m.in. dzięki wirtualizacji. Czyli jak porównamy klasyczną infrastrukturę on-premise – gdzie średnio zużycie procesora jest na poziomie 10-20% – to w chmurze może ona wynieść nawet 70%.

Choć w naszym przypadku, dzięki zbudowaniu chmury prywatnej, utylizacja już i tak była na poziomie ponad 50%. Tak więc w naszym przypadku ten element nie miał aż tak dużego znaczenia. Byliśmy już zoptymalizowani przez tzw. overbooking zasobów czy wykorzystywanie tych samych zasobów przez wiele procesów.

Musieliśmy więc optymalizacji szukać w innych miejscach. W naszym przypadku dotyczyło to zwłaszcza optymalizacji produktowej oraz – jak już wspominałem – dostosowywaniu zasobów do obciążenia w cyklach dobowych. W chmurze to ma znaczenie. Natomiast w przypadku własnej infrastruktury kupiony serwer amortyzuje się niezależnie od tego, czy jest w nocy włączony czy nie. Ten aspekt więc nie wpływa właściwie na koszty środowiska on-premise.

Na czym polegała optymalizacja produktowa? Przepisywaliście wasze rozwiązania na nowsze technologie zanim je zmigrowaliście?

Założyliśmy migrację platformową. Co to znaczy? U nas wszystkie produkty są uruchomione na wspólnej platformie technologicznej. Tak też było w naszej chmurze prywatnej. Założyliśmy, że jeśli uda nam się przenieść środowisko technologiczne, to po zmianie tzw. credentials deweloperzy w zasadzie nie powinni widzieć wielkiej zmiany. Uruchomią potrzebne im środowisko, choć nie będzie już ono znajdować się w chmurze prywatnej lecz publicznej.

W pewnym stopniu tak się właśnie stało. Bardzo mało było produktów, w których trzeba było coś modyfikować. Pojedyncze wyjątki dotyczyły np. niektórych usług persystencji, np. bazy danych. Niektóre z nich nie miały bowiem odpowiednika w AWS. Musiały zostać przepisane.

MIGRACJA

Rozumiem, że wasze rozwiązania były już dostosowane do działania w chmurze publicznej?

Tak. Od strony architektury opartej o mikroserwisy byliśmy gotowi do migracji. Stosowaliśmy też już warstwę abstrakcji, czyli system, który jest pod bazami danych oraz warstwę dostępową. Nasza infrastruktura wykorzystywała też automatykę do ponownego uruchomienia aplikacji w razie jej awarii. Mieliśmy też katalog usług ze standardowym interfejsem dostępowym po HTTP dla – uruchamianych w naszym środowisku – aplikacji. Takie środowisko udało nam się niemal 1 do 1 przenieść z chmury prywatnej do publicznej. Pod tym względem migracja była dla nas prostsza.

To, co okazało się dla nas wyzwaniem to złożoność środowiska, liczba marek RASP i powiązanych z nimi aplikacji. Nie mamy jednej aplikacji i nawet jeśli współdzielą wiele funkcjonalności, to samych produktów jest dużo. Każdy z nich musiał być osobno uruchomiony w chmurze AWS. Następnie zaś zweryfikowany pod kątem działania wszystkich jego funkcjonalności w nowym środowisku IT.

Jednym z wyzwań była też synchronizacja kolejności migracji kolejnych elementów. Zastanawialiśmy się jak zrobić, aby zmigrowany produkt działał mimo, że część naszych funkcjonalności – np. baza danych – znajduje się wciąż w naszej chmurze prywatnej w Krakowie, a on sam tysiąc kilometrów dalej, we Frankfurcie. Proces przenoszenia serwisów i rozpinania ich pomiędzy różnymi ośrodkami był dość złożony i skomplikowany, ale zadziałał.

Ile trwał sam proces przenoszenia Waszej infrastruktury do regionu chmury publicznej we Frankfurcie?

Wystartowaliśmy w roku 2018, a w roku 2022 przenieśliśmy ostatnie elementy do chmury AWS. Śmieję się, że trwało to mniej więcej tyle, ile amortyzacja sprzętu. Wydaje mi się, że najtrudniej było pogodzić projekt absolutnie strategiczny, jakim jest migracja do chmury, z innymi projektami w firmie, m.in. rozwojem produktów i wchodzeniem na nowe rynki, z ofertą dla nowych użytkowników. To zawsze jest wielkie wyzwanie.

Jeśli miałbym poradzić innemu CTO jak przeprowadzić taką migrację, to najważniejszą rzeczą jest sprawienie, aby projekt ten był projektem zarządu. Nie można go, w takiej skali, zrobić siłami wyłącznie IT. W takim przypadku on się po prostu nie uda. On wówczas zawsze będzie szedł w przeciwnym kierunku niż projekty, które chce realizować biznes. Będzie też angażował ludzi i wyłączał całe agendy produktowe często na 2-3 kwartały, albo je przesuwał. Będzie też minimalizował możliwości dowożenia pewnych rozwiązań. To jest duży wysiłek organizacyjny.

Wydaje mi się, że migracja u nas trwała tak długo – choć mogłoby być szybciej – aby właśnie zminimalizować negatywny efekt związany ze zmianą alokacji ludzi.

Wspominasz o agendach produktowych. Masz na myśli np. rozwój jakiegoś serwisu?

Tak, m.in. rozwój samego Onetu, wdrożenie Onet Premium, czy personalizację naszej strony głównej. De facto dzisiaj mamy kilkaset jej wersji dostosowanych do konkretnych grup użytkowników. Dodatkowo treści zmieniają się jeśli dany użytkownik już je widział. A wszystko działa w czasie rzeczywistym. To był bardzo duży projekt połączony ze zmianą nie tylko produktową, ale też technologiczną i architektoniczną.

Rozwój takiej – rozumianej szeroko – funkcjonalności stoi jednak w sprzeczności z migracją technologiczną, wymianą elementów infrastruktury, na których działa. Także jest to potężne wyzwanie. Myślę, że organizacje mogą sobie z nim nie poradzić. Szczególnie jeśli zarząd tego nie wspiera.

Was wspierał cały zarząd, czy była dedykowana osoba?

Jakbym miał wskazać na to, kto miał największy wpływ, to był to nasz ówczesny prezes. Do niego raportowaliśmy jako IT. Rozumiał, że skoro podjęliśmy się już takiego wyzwania, to musimy je skończyć. Był też świadomy wpływu tego projektu na naszą przyszłość.

Przypominał nam zawsze o celu, który chcemy osiągnąć. Starał się też zagwarantować, że migracja do chmury ma miejsce wśród pozostałych celów organizacji, że cały czas znajduje się na agendzie. Bez tego byłoby bardzo trudno zrealizować migrację.

PIERWSZE EFEKTY

O ile łatwiej jest Wam zarządzać infrastrukturą w chmurze publicznej niż to było w przypadku własnego centrum danych? Mówiłeś, że część osób, którzy zajmowali się infrastrukturą fizyczną, została przeniesiona do innych zadań.

Nie wiem jak odpowiedzieć, aby nie zabrzmieć trywialnie. Ale te dwa światy są po prostu mało porównywalne. Wiążą się z tym też zupełnie inne zadania. Przykładowo jeśli jesteś w chmurze, to w ogóle nie potrzebujesz dbać o sprzęt. Z drugiej strony korzystanie z niej daje nowe, niedostępne dotąd możliwości. Wrzucasz wyższy bieg, ale aby móc na nim jechać, musisz mieć nowe kompetencje w organizacji. Trzeba o nie zadbać.

Z perspektywy biznesowej zdecydowanie przyspieszyliśmy, jeśli chodzi o dostarczanie nowych funkcjonalności. Przykładowo serwis Sympatia chciał uruchomić wideoczat pomiędzy użytkownikami. Dzięki rozwiązaniom dostępnym w chmurze wdrożyliśmy go w zaledwie kilka tygodni, a jego utrzymanie kosztuje kilkanaście dolarów miesięcznie.

To ogromne skrócenie współczynnika Time-to-Market. Dzięki temu iterujesz dużo szybciej z pomysłami, które masz. W dzisiejszym świecie dużo ważniejsza jest możliwość szybkiego sprawdzenia hipotezy biznesowej i wrócenia z wynikiem pozwalającym na podjęcie decyzji, niż posiadanie dużego stacku technologicznego. Zwinność jest ważniejsza.

W przypadku infrastruktury on-premise musielibyśmy kupić kilka serwerów, oprogramować je, zintegrować różnego rodzaju rozwiązania, które potrafią nie tylko zbierać materiał wideo, ale go enkodować i streamować do drugiej osoby, synchronizować transmisję, a być może także nagrywać ją. W tym przypadku stałaby przed nami masa wyzwań.

A w chmurze?

Wszystko to można wyklikać z gotowych elementów, niejako „z pudełka”. Bardzo szybko możemy więc wystawić gotową funkcjonalność i udostępnić ją użytkownikom. Innym przykładem może być budowa nowego mechanizmu identyfikacji użytkownika. Temat ten – wraz z planami blokowania plików tzw. third party cookies przez właścicieli przeglądarek – staje się coraz bardziej palący. My zaś opieramy się na tym właśnie sposobie identyfikacji użytkowników naszych serwisów.

Prędkość iteracji tego projektu była tak duża, że potrafimy dzisiaj zrobić dość duży „uplift” na cenach reklam tam, gdzie ważne są dane użytkownika. Potrafiliśmy bowiem – w skończonej liczbie, szybkich iteracji – dojść do odpowiedzi na pytanie, którymi technologiami i w jaki sposób najbardziej nam się opłaca te dane przetwarzać. Takich przykładów jest dużo więcej.

Które z kompetencji, które musieliście pozyskać były najważniejsze?

Najważniejsze zdecydowanie są kompetencje techniczne związane z obsługą chmury, zarządzaniem nią, ale także aspektami Governance. Jest on krytyczny w tak dużej organizacji, jak nasza. W sytuacji, kiedy mamy kilkuset deweloperów, kilkadziesiąt projektów i różnych systemów, dużym wyzwaniem okazuje się ustanowienie zasad Governance, rozliczalności, świadomości tego, w jaki sposób alokować koszty, a także jak je optymalizować.

Nie chodzi więc już tylko o proste, choć ciężko je takimi nazwać (śmiech), kompetencje technologiczne, ale także zaawansowaną wiedzę związaną z zarządzaniem chmurą. Wykorzystanie chmury to zmiana sposobu pracy w organizacji. To jest np. ścisła współpraca z kontrolingiem. Do tej pory duża część naszych kosztów to był CAPEX za infrastrukturę i związaną z tym amortyzację. Dzisiaj większość to jest OPEX. Tego typu zmiana też może być trudna, w zależności od poziomu tych kosztów przed i po zakończeniu migracji.

Na pewno, w trakcie realizacji projektu, obserwowaliśmy zmianę koniecznych kompetencji – pomiędzy optymalizacją parametrów systemu operacyjnego, a umiejętnym wykorzystaniem skalowania infrastruktury IT. Zmienia się to, co optymalizujemy przed i po chmurze. W czasie migracji zrobiliśmy ponad 200 akredytowanych szkoleń dla pracowników, którzy uzyskali kilkadziesiąt certyfikatów.

Po migracji ciężar został przesunięty w kierunku efektywności wykorzystywania usług chmurowych. To daje bowiem dużo większy zysk i oszczędności niż optymalizowanie pojedynczych parametrów. W chmurze te działania nie są tak istotne, jak w przypadku rozwiązań on-premise.

FINOPS, CZYLI ZARZĄDZANIE KOSZTAMI

Jak w Waszym przypadku wygląda zarządzanie kosztami chmury?

Korzystamy z rozwiązań AWS. Wspieramy się też rekomendacjami, jak coś powinno zostać zrobione, aby zoptymalizować nasze koszty. Do tego stworzyliśmy własny, wewnętrzny system rozliczania, który jest pochodną naszego systemu jeszcze z czasów posiadania chmury prywatnej.

Mamy wewnętrzne systemy, które mapują koszty usług cloud computing. Przypisaliśmy użycie wszystkich usług chmurowych wewnętrznej strukturze produktów. Dzięki temu można pokazać potem w raportach P&L poszczególnych biznesów to, jak efektywność ich produktów przekłada się na koszty hostingu.

Nie ma więc możliwości, że jakiś Product Owner kupi trochę wirtualnych serwerów na poczet realizowanego projektu, a potem zapomni je wyłączyć?

Jest to możliwe, ale myślę, że dłużej niż miesiąc zbędne usługi nie będą włączone. Potem przyjdzie faktura, która wywoła alarm (śmiech). A na serio, warto zabezpieczyć się przed tego typu przypadkami. My zresztą wyłapujemy tego typu przypadki szybciej.

Dołożyliśmy nasz tzw. Shadow Monitoring do tego, co pokazuje Amazon Web Services. Ten zaś prezentuje nasze bieżąco koszty w perspektywie konkretnych produktów. Można do tych danych zapiąć alarmy. Jeśli więc gdzieś koszty zaczną rosnąć z dnia na dzień o „X” procent albo kwotę „Y”, to od razu zapali się alarm. Spowoduje to, że sprawdzimy co się dzieje i ewentualnie wyłączymy niewykorzystywaną infrastrukturę.

To jednak jest akurat łatwe do monitorowania. To, co jest trudne, to użycie różnego rodzaju zapytań w przetwarzaniu wielkich zbiorów danych. Nie zawsze jesteśmy w stanie, oszacować to, jaki będzie jego koszt. Musi ono bowiem „przelecieć” przez wszystkie dane. Co gorsza zapytanie może zostać tak napisane, że będzie musiało przeanalizować wszystkie dane wiele razy. Wówczas faktycznie można na tych kosztach popłynąć.

Z perspektywy użycia usług chmurowych także można wprowadzić monitoring i obserwować, z dnia na dzień, czy nie ma jakichś anomalii w sposobie użycia. Można próbować wyłapywać zapytania, które generują błędy. W krótkim czasie, po dniu lub dwóch, jesteśmy w stanie zorientować się, że coś jest nie tak i wyłączyć usługę generującą zbędne koszty.

Dużo gorzej byłoby w infrastrukturze on-premise, gdzie takie – puszczone, bez monitoringu zapytanie – działałoby sobie na naszych serwerach, zajmując ich zasoby. Nikt nie określiłby kosztu takiego zapytania. Dopiero wówczas, gdyby zaczęło brakować miejsca na danym klastrze zrobiono by przegląd wszystkich zapytań, analizując które są „najcięższe”. Wtedy – być może nawet po kilku miesiącach – wyszłoby, że zostało „puszczone” zapytanie, które zajmuje 20% dostępnej mocy obliczeniowej, ale nie zostało ono ani usunięte, ani zoptymalizowane.

Wydaje się jednak, że w takim przypadku ponosimy tylko koszt zużytego prądu?

Tak, ale jest też inny, negatywny aspekt. Widząc, jak mało zasobów jest dostępnych na tym klastrze serwerów, zaczynamy używać go coraz ostrożniej, nie wiedząc, jaka jest tego faktyczna przyczyna. Zaczynamy zajmować się tym problemem. Ktoś sugeruje, aby dokupić nowe maszyny. No i ostatecznie je dokupujemy.

Tymczasem z perspektywy migracji do chmury, absolutną rewolucją jest pokazanie programistom rzeczywistych kosztów i skutków ich pracy. To powoduje zmianę mindsetu. Zastanawianie się, czy to, co piszę będzie odpowiednio efektywne? Czy nie przesadzam? Czy napisałem dobrze kod? Miara wyrażona w dolarach jest najbardziej obrazowa.

JAK PROGNOZOWAĆ PRZYSZŁE KOSZTY CHMURY

Kilka razy spotykałem się z tzw. ukrytymi kosztami chmury, czasami nieprzewidywalnymi. Głównie odnoszono się do kosztów transferu danych do i z chmury. Jak to u Was wygląda? Onet z centrum danych AWS we Frankfurcie serwuje nie tylko treści, ale także i wideo.

Powiedziałeś o braku możliwości przewidywania kosztów. Nasze doświadczenie jest takie, że kalkulator, który dostarcza producent chmury służy tylko do zgrubnych szacunków. Możesz sprawdzić jakie są kategorie kosztów, na które trzeba zwrócić uwagę. Ale i tak potem trzeba zrobić własny test. Jak tego nie zrobisz, to nie będziesz wiedział ile usługi cloud computing naprawdę będą kosztować.

Trzeba to zrobić m.in. właśnie z tego powodu, o którym wspomniałeś, czyli kosztów transferu. Często wymykają się szacunkom. Nie jest to proste do policzenia, bo jest kilka zmiennych, które kształtują ten koszt. Są to: wielkość odpowiedzi czy liczba requestów, które generujesz. Jak już mamy te zmienne, policzenie kosztów transferu – nawet jak masz te dane u siebie – może być karkołomne. Jak się wgłębisz we własną strukturę ruchu, to może okazać się, że jest ona drastycznie różna w różnych momentach dnia czy miesiąca. Wszystko zależ od typu biznesu, który masz.

Uśrednianie wielkości transferu nie do końca działa. Po migracji bierzesz nie wartość średnią lecz skrajną. W zależności bowiem od tego, który parametr był skrajny w danym momencie liczona jest cena usługi w chmurze. Tak więc koszt transferu faktycznie może zaskoczyć.

A jak to wygląda w Waszym przypadku?

Większość naszych kosztów to usługa AWS EC2, czyli wykorzystywana przez nas moc obliczeniowa. W drugiej zaś kolejności zasoby pamięci masowej i dopiero transfer danych. Oczywiście wszystkie nasze usługi są udostępniane z centrum danych we Frankfurcie, ale dzięki wykorzystaniu usługi CDN AWS CloudFront obniżamy koszty przesyłu danych.

Usługa CDN polega na tym, że w różnych serwerowniach na świecie – w punktach najbliżej użytkowników naszych serwisów – znajdują się tzw. endpointy. Tam są cache’owane odpowiedzi na ich zapytania. To z tego miejsca dostanie odpowiedź, a nie z naszego głównego centrum danych we Frankfurcie. Dla treści, które są udostępniane poprzez usługę CDN, procent ponownego odpytania serwera, trafienia w tę samą treść sięga 98%-99%.

Nie wszystkie rzeczy można i jest sens cache’ować. Część ruchu nie może być udostępniana przez CDN. Dotyczy to np. spersonalizowanych wersji strony głównej Onet.pl. Każdy użytkownik może mieć inną jej wersję. Tego typu usługi wystawiane są bezpośrednio z serwerów we Frankfurcie. Wówczas koszty transferu rzeczywiście potrafią być znaczne.

Jak sobie z tym radzicie?

Przy odpowiednim wolumenie można prosić o dedykowany cennik, tzw. Private Pricing. Kiedy poziom naszych transferów i liczba requestów jest odpowiednio duża, można uzyskać znaczące upusty. Ale jest to dość trudne zagadnienie i rzeczywiście dla nas transfer to trzeci koszt pod względem wielkości. Obiektywnie jest on tak niski, bo używamy usługi CDN i mamy zagwarantowany, dedykowany poziom cen.

Jak wyglądał Wasz test analizy kosztów przed migracją?

W pierwszych założeniach, nie chcieliśmy w ogóle przenosić ruchu z Krakowa do Frankfurtu. Mieliśmy zbudowany własny CDN, w naszej, dawnej serwerowni. Ale zauważyliśmy, że to generuje różne problemy i to nie wynikające z rozstrzału geograficznego naszych data center. Istotnym problemem okazało się to, że – ponieważ większość infrastruktury IT naszej firmy przeniosła się do chmury – to ten CDN musiał mieć dedykowaną opiekę administratorów. Nasz zespół miał więc nagle dodatkową pracę do wykonania.

Po przeprowadzonych testach okazało się, że koszty jednostkowe będą wyższe po przesunięciu tej warstwy do AWS. Natomiast były one uzasadnione tym, że nasz zespół będzie miał dużo mniej pracy i będzie mógł zająć się innymi projektami. Nie porównywaliśmy więc samego kosztu usługi CDN u nas i w AWS, ale całkowite koszty, w tym czasu pracy wewnętrznego zespołu i jego kompetencji. Porównanie tych trzech składowych pokazało nam, że warto być może zapłacić nieco więcej za transfer, ale dzięki temu zyskać inne korzyści – np. odciążyć zespół czy zwiększyć poziom elastyczności skalowania infrastruktury IT.

Podejrzewam – choć nie mamy na to dowodów w postaci testów A/B, a jedynie nasze estymacje – że gdy w 2022 roku wybuchła wojna w Ukrainie, a Onet.pl miał historycznie jedne z najwyższych wyników, to bardzo trudno byłoby nam sprostać temu ruchowi, jeśli nie bylibyśmy w chmurze. Dynamicznie dokładaliśmy wówczas kolejne instancje serwerów frontowych, dla których mieliśmy ograniczone capacity we własnej serwerowni. Dodatkowo nie było ich w ofercie vendorów. Na nowy czekało się 9 miesięcy. Wciąż nie wyszliśmy wtedy z problemów logistycznych po pandemii.

Gdyby nie chmura moglibyśmy tylko degradować funkcjonalności serwisu. Z tej perspektywy migracja do chmury nam się opłaciła.

ELASTYCZNOŚĆ ZASOBÓW W CHMURZE

Wspominałeś, że możecie elastycznie włączać i wyłączać zasoby. Czy to się dzieje samoistnie, np. po północy główna strona Onetu potrzebuje jedynie 20% zasobów, które zużywa w ciągu dnia, więc do tego poziomu je ograniczacie?

To zależy bardzo od przypadku użycia. Większość stosowanych przez nas rozwiązań ma charakterystykę autoskalowania. Sygnałem do tego mogą być różne zdarzenia, np. ilość zapytań na minutę, obciążenie procesora czy czas odpowiedzi. Jeśli rosną czasy odpowiedzi, to znaczy, że serwery są przeciążone i trzeba dołożyć kolejne. Można określić, że zwiększamy zasoby np. w określonym percentylu. Widzisz, że coś się zaczyna dziać, gdzieś na skraju charakterystyki. Także sygnały techniczne mogą być bardzo różne. W większości przypadków mogą jednak wywoływać reakcje automatyczne.

Natomiast nic nie stoi na przeszkodzie, aby w określonych godzinach – np. od 23 do 6 rano – cały stack technologiczny „ograniczyć” do zaledwie kilku serwerów, które bez problemów poradzą sobie z nocnym ruchem. Tak zresztą robiliśmy na początku. Natomiast takie podejście ma parę wad, m.in. nie dostosowuje się precyzyjnie do ruchu. Po drugie wymaga utrzymania jakiejś minimalnej obsady. Cały czas trzeba weryfikować, czy nagle zachowania użytkowników nie zmieniają się na tyle, że trzeba zwiększyć założony „bufor”.

Dzisiaj używamy rozwiązań, które pozwalają na autoskalowanie względem wskazanych wcześniej parametrów technicznych.

I na takie działania pozwala Wasza infrastruktura w chmurze?

Tak, i to w różnych formach, w zależności od tego, w jaki sposób uruchomisz aplikację czy konkretne usługi. To jest bardzo złożony temat. Ale możesz to zrobić w wielu różnych ustawieniach i za pomocą różnych narzędzi.

Czy dotyczy to uruchomienia ponownie serwisu, który dotknie ewentualna awaria?

Infrastruktura AWS na pewno bardzo pomaga również i w tym. Są automaty, które mogą monitorować „zdrowie” Twoich rozwiązań i wymuszać powstanie nowego serwera. Możesz też używać takich rozwiązań jak Kubernetes, który w dużej mierze rozwiązuje te problemy. Jest to dziś zresztą podstawowa technologią do uruchamiania aplikacji mikroserwisowych, które łatwo się skalują i komunikują ze sobą. Jeśli któraś „padnie”, to system dba o to, aby odpowiednia ich liczba się pojawiła na ich miejsce.

Administratorzy „starej daty” mieli za punkt honoru to, aby nigdy nie restartować serwera. Jego uptime liczony w latach był przyczynkiem do dumy. Oznaczało to, że administrator potrafi tak modyfikować system, aby go nie wywalić. To była naprawdę wielka umiejętność.

Wraz z kilkoma zmianami podejścia do architektury IT – w szczególności takimi, które mówią, że nie ma elementu, który jest niezastępowalny, nie ma Single Point of Failure – infrastruktura IT stała się tak dobra, jak jej najsłabszy element. Jak to najlepiej sprawdzić? Powodując, aby losowo przestawały działać poszczególne jej elementy zgodnie z koncepcją Chaos Monkey. Wówczas można zobaczyć jak inne fragmenty się zachowają w takiej sytuacji.

Wówczas czas życia dłuższy niż miesiąc jakiegoś elementu oznacza, że nie wiesz czy on wstanie, jak się „wywróci”. To jest podstawowy czynnik, który chcesz sprawdzić. I oczywiście to, czy – po degradacji jakiegoś komponentu, czy grupy komponentów – system nadal świadczy usługę. Chaos Monkey to idea, w której budujemy nasze rozwiązania i nieustannie próbujemy wystawiać na próbę poszczególne aplikacje, sprawdzając czy ich awaria nie wpłynie na funkcjonowanie całego systemu.

LESSONS LEARNED

Jaką, najważniejszą lekcję wyciągnęliście z tych czterech lat procesu migracji?

O jednej już mówiłem. Jeśli robimy tak dużą zmianę technologiczną w organizacji, upewnijmy się, aby to był cel strategiczny zarządu. Bez tego ten projekt się nie uda.

Druga dotyczy tego, że – mimo posiadania wybitnych kompetencji w zespołach IT – nie wszyscy chcą działać w świecie chmurowym i nie da się ich na siłę przekonać.

Trzecia lekcja – spodziewałem się tego, ale nie sądziłem, że efekt będzie tak silny – to, że pokazanie deweloperom jak dużo zasobów „zużywa” ich rozwiązania spowoduje to, iż staną się lepszymi specjalistami. Dziś potrafią lepiej ocenić jakość tego, co dostarczają.

Daliście im narzędzia do tego, aby mogli stać się lepszymi? Inaczej tworzą kod?

Przede wszystkim w środowisku chmurowym widzą na bieżąco koszty utrzymania stworzonych rozwiązań. W świecie on-premise tego raczej nie ma. Wdrożyłeś aplikację i nie wiesz jaki to ma skutek finansowy albo efektywnościowy. Za tym idą: szkolenia, narzędzia monitoringu, Best Practices, współdzielenie się wiedzą. Mamy bardzo otwarte zespoły, które nawzajem wymieniają się informacjami, pokazując także np. dane o efektywności.

W świecie, w którym jako KPI stawia się budżet na utrzymanie jakiegoś rozwiązania w skali roku zmienia się sposób myślenia. Budżet staje się odpowiedzialnością nie tylko biznesu, ale też zespołów IT, które uczestniczą w tworzeniu i optymalizacji rozwiązań.

Za 2022 rok mieliśmy budżet, który zrealizowaliśmy w 96-97 proc., lekko „nie dowożąc” w dolarach. To pokazuje, jak ścisłą kontrolę jesteśmy w stanie realizować jednocześnie dokładając nowe projekty, nowe rozwiązania, które też „konsumują” budżet. Jeśli masz na to budżet to OK, ale jak nie, to musisz szukać pieniędzy, działać efektywniej. To jest rewolucja.

VENDOR LOCK W CHMURZE?

Ostatnie pytanie, nie boicie się tzw. vendor lock, ponieważ jesteście w jednej chmurze w 100 proc.?

To ciekawe pytanie. W sumie można by było o nim zrobić osobny wywiad. Choć dla jest ono nie techniczne, a raczej filozoficzne. Czy jeśli programuję w .NET i 90% mojego kodu powstało w oparciu o ten język, to mam czy nie mam vendor lock?

Czy alternatywą do ryzyka vendor-lock nie byłaby możliwość wykorzystania koncepcji multi-cloud? Większość, dużych organizacji korzysta z niej, aby nie doprowadzić do sytuacji, w której za dużo zasobów zostało przeniesionych do jednego dostawcy chmury.

Gdybyśmy obawiali się tego, że dany dostawca zniknie z rynku, bo nie jest wiarygodny, albo że wykorzysta monopolistyczną pozycję i podniesie ceny o 100% – co może położyć niejeden biznes – to wówczas faktycznie powinniśmy mieć pomysł na to, w jaki sposób przeciwdziałać takiej sytuacji. Jednak zazwyczaj – bez względu na vendora – mówimy zaledwie o kilku, kilkunastu procentach upustów. O tyle też może ewentualnie wzrosnąć nasz rachunek.

Natomiast wydaje mi się, że gdy korzystamy z dwóch chmur, aby mieć dwa, różne workloady u dwóch, różnych dostawców, to mam podwójny vendor lock. Nieważne bowiem, który z nich wykorzysta swoją pozycję przeciwko nam, 50% mojego biznesu nie będzie działać.

Jeśli zaś zdubluję architekturę w ten sposób, że mogę uruchamiać ją w jednej lub drugiej chmurze, to znaczy, że działam ekstremalnie nieefektywnie. Nie wykorzystuję natywnych rozwiązań dostępnych na danej platformie, tylko cały czas pilnuję, abym był przenaszalny pomiędzy dwoma chmurami. Ponoszę w związku z tym ogromne koszty, tylko dlatego, że jestem w dwóch miejscach. Do tego dochodzi transfer danych pomiędzy dwoma dostawcami.

Z kolei ciekawym może być scenariusz, kiedy dzielimy workloady w taki sposób, że np. przetwarzanie Big Data jest w jednym, aplikacje biznesowe w drugim, a storage w trzecim. Pozwala to być może na arbitraż cenowy pomiędzy dostawcami.

Podejrzewam, że dzisiaj, gdybyśmy się uparli, że musimy wyjść z obecnej chmury – z jakichkolwiek powodów, politycznych, monopolistycznych, innych – to jesteśmy w ciągu roku, maksymalnie dwóch, całkowicie zmigrować się do innego vendora. Ale to by oznaczało kolejny projekt o statusie strategicznym dla naszej firmy.

Dodatkowo wydaje mi się, że możliwość łatwego przenoszenia się pomiędzy dwoma dostawcami usług cloud computing powoduje kolejny vendor lock dotyczący dostawcy wirtualizatora.