TRANSKRYPCJA WEBINARU

Oszczędzaj mądrze. Optymalizacja kosztów w chmurze

 

Data: 19.11.2024

Prelegent: Arkadiusz Ryfa

 

Arkadiusz Ryfa: Witam państwa jeszcze raz na webinarze ,,Oszczędzaj mądrze: optymalizacja kosztów w chmurze” Jeszcze poczekamy minutkę na spóźnialskich i będziemy zaczynać. 

Może czekając na resztę, opowiem kim jest FOTC. Jesteśmy uznanym liderem technologii chmurowych, sztucznej inteligencji oraz narzędzi wspierających nowoczesne środowisko pracy. Nasz zespół certyfikowanych specjalistów oferuje kompleksowe wsparcie od migracji po modernizację, aż po optymalizację procesu, pomagając w pełni wykorzystać potencjał technologii.

Mamy agendę, o czym dzisiaj będziemy rozmawiać:

• Czy chmura jest droga i czy możemy na niej zaoszczędzić, 
• kluczowe sposoby na optymalizację kosztów, 
• przygotowanie na Black Friday i inne wydarzenia e-commerce, 
• system overload – jak go uniknąć. 
• Usługi Google Cloud do hostowania web aplikacji, 
• na końcu pokażemy krótkie demo 
• Q&A. 

Jeszcze zachęcam państwa do wzięcia udziału w ankiecie, która właśnie wyświetliła wam się na ekranie. Jedno proste pytanie: czy planują państwo optymalizować koszty chmury w najbliższym czasie?

Jak na razie super, nie ma żadnej osoby, która nie chciałaby optymalizować. Dobry znak. Okej, tutaj już ankieta została zakończona. Ja ponownie udostępniam państwu prezentację i możemy przechodzić do meritum.

 

Dlaczego chmura wydaje się droga

Zacznijmy od tego dlaczego chmura jest tak droga, bądź niekoniecznie, ponieważ często stresują nas wszyscy, że chmura to przecież takie drogie koszty, trzeba za wszystko płacić. Ale tak naprawdę, to tak nie jest. Porównajmy sobie chmurę do tradycyjnego serwera. Jeżeli zaczynamy swój biznes, potrzebujemy na start dość małych osiągów naszego serwera, więc po prostu kupujemy go słabego, co wiąże się z pierwszym wydatkiem kosztów, że musimy kupić dany serwer. Musimy złożyć, kupić, potem utrzymywać, płacić za prąd. Jest to dość duży koszt po prostu żeby postawić sobie chociaż jakiś najprostszy serwerek.

 

 

Nagle, gdy nasz serwis okazuje się sukcesem, mamy większy ruch i potrzebujemy wzmocnić ten serwer. Mamy drogi – albo ulepszać to co mamy, przez co mamy przerwy w dostawie naszej usługi, bądź po prostu dokupować. Zawsze musimy wycelować tak, że trafimy idealnie, że będzie taki jaki potrzebujemy zawsze, albo będzie troszkę za słaby, przez co będzie nam gorzej działała usługa. Bądź po prostu przepłacimy, bo stwierdzimy że już nam tak super idzie i kupimy za kupę pieniędzy porządny serwer i nagle może się okazać, że jednak nasza usługa aż tylu nie ma użytkowników.

Korzystając z chmury z usługi serverless pay as you go, płacimy dokładnie tyle ile zużywamy. Jeśli mamy startujący startup, nasze pierwsze dni aplikacji, mamy mało odwiedzających, będziemy płacić dosłownie grosze. Potem w miarę rozwoju będzie nam to po prostu się zwiększać, nie będziemy mieli żadnych opóźnień ani przerw. tylko po prostu będziemy płacić dosłownie za zużycie, nie będziemy ani nadpłacać ani niedopłacać.

 

Jak śledzić wydatki w chmurze

Wróćmy do tych kosztów, bo wspomniałem, że będziemy więcej płacić. Ale skąd mamy wiedzieć ile będziemy płacić? Mamy w zakładce Google Cloud takie menu jak billing i mamy tam piękne takie wykresy, gdzie mamy rozpisane dokładnie każdą z naszych usług. Ile zostało zużyte, ile za to zapłacimy i dzięki temu możemy sobie bazować oraz śledzić nasze wydatki, że jeśli jakaś usługa generuje zbyt duże koszty, możemy to spróbować zoptymalizować.

Możemy spróbować zrobić to inaczej poprzez inną usługę, która jest na przykład tańsza. Możemy to sobie segregować by service, tak jak mamy aktualnie na ekranie, bądź zaznaczyć tam opcję SKU. Wtedy mamy to dosłownie wylistowane po najmniejszym szczególe, takim jak na przykład ruch internetowy, ruch skąd dokąd, dosłownie każdy najmniejszy szczegół. Każdy najmniejszy cent, który wydajemy w Google Cloud jest wtedy tam rozpisany, za co konkretnie to jest.

 

Budżety i alerty kosztowe

Żeby nie siedzieć cały czas na raportach, ponieważ zajmowałoby to nam godzinami, moglibyśmy sobie to śledzić. Mamy taką usługę jak budżety i alerty. Jest to usługa dzięki której możemy ustawić sobie budżet na naszą chmurę. Możemy to ustawić na nasz cały billing account, bądź na konkretne projekty, bądź ustawić budżet na dosłownie każdą usługę Google Cloud, na przykład Compute Engine czy Cloud Storage. Ustawiamy sobie wtedy budżet na przykład 1000 zł na całe konto i przychodzą nam powiadomienia.

Możemy sobie ustawić stopnie, progi na przykład 20%, 50%, 90% i dostajemy wtedy powiadomienie na przykład na maila z informacją, że zużyłeś 20% swojego budżetu. Jest to bardzo fajna usługa, którą polecam w Google Cloud. Jeżeli mamy jakiś błąd w naszej aplikacji, coś zapętlone co będzie nam ciągle generowało koszty, jakąś najmniejszą pomyłkę, która szybko będzie generować koszty, to zanim wejdziemy na te raporty i sprawdzimy, że ojejku jednak zużyłem aż tyle pieniędzy przez jakiś błąd, to przyjdzie nam powiadomienie na maila: uwaga zużyłeś 20%. Jeśli za 15 minut przyjdzie nam mail uwaga zużyłeś 50%, po prostu reagujemy od razu, wyłączamy tą usługę bądź optymalizujemy, patrzymy co się dzieje, że nagle nasze koszty aż tak szybko wzrosły.

A jeżeli wszystko jest w porządku, zazwyczaj mamy budżet który wiemy, który chcemy wydać i wszystko się zgadza, że na przykład na początku miesiąca jest 20%, pod koniec 90% i jesteśmy spokojni, że trzymamy się swojego budżetu, nie mamy żadnych zaskoczeń.

 

Zniżka za deklarowane zużycie

Przejdziemy teraz do kluczowych sposobów na optymalizację kosztów Google Cloud. Committed Use Discount, jest to zniżka za deklarowane zużycie. Czyli na przykład jeżeli wiemy, że potrzebujemy na 100% danej maszynki przez następny rok, bądź 3 lata, ponieważ mamy możliwość podpisania tego Committed Use Discount na rok bądź 3 lata. Wtedy możemy podpisać jakby taką ugodę z Googlem i mamy za to tańsze te zasoby. 3 lata z tego co pamiętam to jest nawet do 46% zniżki, jeżeli zadeklarujemy, że będziemy na 100% przez 3 lata używać danych zasobów.

Jeżeli nie zużyjemy, nagle będziemy zużywać ich mniej, wtedy niestety płacimy tą samą kwotę którą się zadeklarowaliśmy. Za to jeśli będziemy używać więcej, to te zasoby które podpisaliśmy że będą używane będą tańsze, a już te nadprogramowe będą po prostu w standardowej cenie. Jest to porównywalne do telefonii komórkowych, gdzie podpisujemy umowę na 5 giga internetu i 1000 smsów. Jeśli zużyjemy mniej to płacimy daną kwotę, jeśli to przekroczymy to wtedy niestety jest nam naliczane dodatkowo. Tak więc jest to dobra usługa.

Jeśli ktoś ma jakąś swoją usługę, ona nie zmienia się, na przykład nie jest wystawiona publicznie na świat, tylko do naszych celów firmowych prywatnych, wiemy że to nam wystarcza, nie będziemy tego zmieniać, działa to super, to wtedy po prostu podpisujemy za właśnie Committed Use Discount i mamy zniżkę. W jakich usługach możemy wykupić Committed Use Discount? 

Możemy w Compute wykupić, możemy w Kubernetes, można w Cloud SQL, VMware. Jest to na liście jeszcze kilka usług, ale to są takie główne z których zazwyczaj korzystamy: Compute Engine, Kubernetes Engine.

 

Klasy przechowywania Cloud Storage

Mamy taką usługę jak Cloud Storage. Dość popularna, więc myślę że słyszeli państwo o niej. Jest to usługa do przechowywania danych, jest to taki magazyn chmurowy danych podobny do Google Drive, ale potężniejszy i domyślnie stworzony raczej jako backend innych usług i aplikacji. Posiada on kilka klas przechowywania, tak jak widać na obrazku.

 

 

Standard jest to klasa dedykowana dla danych w ciągłym użyciu, czyli koszt pobierania, wysyłania jest najniższy, za to koszt przechowywania najdroższy. Za to Archive koszt pobierania jest najdroższy, a przechowywania najniższy. I Nearline oraz Coldline to pomiędzy. O co chodzi z tym kosztem przechowywania, kosztem pobierania? Chodzi w tym o to, jeżeli na przykład mamy sklep internetowy, gdzie wrzucamy zdjęcia swoich ubrań, to wtedy te zdjęcia są pobierane cały czas. Wtedy przechowujemy to w klasie standard, ponieważ wychodzi to najkorzystniej dla nas.

Ale jeśli na przykład potrzebujemy zrobić backup czegoś z którego nie będziemy korzystać więcej niż raz do roku, ponieważ klasa Archive raz do roku ma darmowe pobieranie, wtedy wrzucamy to w Archive i sobie trzymamy backup zamiast na jakichś starych dyskach w piwnicy. Tworzymy sobie Cloud Storage Archive, wrzucamy tam i po prostu to sobie tam siedzi, w razie jeśli tego potrzebujemy mamy to dostępne w chmurze pod ręką. Ale raczej jest to dla plików, z których wiemy, że nie będziemy korzystać przez najbliższy rok.

 

Usługi jako Pizza as a Service

Tutaj mamy takie dość ciekawe, wesołe nawiązanie – Pizza as a Service. Jest to opowiedzenie w takim przyziemnym sposobie czym są po prostu usługi w Google Cloud, takie jak on-premise, czyli to co robimy jakby nasz serwer lokalny nie w chmurze, Infrastructure as a Service, Platform as a Service i Software as a Service. Jest to nawiązanie do pizzy.

Czyli jeśli mamy nasz serwer on-premise, jest to nawiązanie do pizzy zrobionej w domu, gdzie musimy zapewnić stół, napój, elektryczność, piekarnik, ogień, spód do pizzy, sos pomidorowy, dodatki i ser. Infrastructure as a Service jest to gotowa infrastruktura, czyli coś tak jak w chmurze, że musimy po prostu dostarczyć nasz kod, nasz pomysł, nasz plan, ale usługi już są, tak jak Compute Engine i możemy sobie z tych klocków, że tak powiem, budować. Wtedy już dostarczony mamy spód pizzy, sos pomidorowy, ser, dodatki, tak jak w pizzy mrożonej, ale musimy jeszcze mieć stół, napój, elektryczność, piekarnik i ogień.

Platform as a Service jest to coś takiego jak na przykład Cloud Run i wtedy dostarczamy tylko kontener, wszystko pod spodem się buduje samo. To tak naprawdę potrzebujemy tylko stół i napój, czyli jak pizzę z dostawą. Jeśli mamy Software as a Service, czyli Cloud Functions na przykład, piszemy tylko kod, to tak naprawdę wszystko mamy zapewnione tak jak w pizzerii.

 

Usługi Serverless i kontenery

Teraz kilka usług Serverless Computing w GCP. Mamy takie usługi jak Cloud Functions, App Engine i Cloud Run. I są to usługi w których, tak jak wcześniej wspomniałem serverless, tylko wrzucamy nasz kod. Chyba że w Cloud Runie, to wtedy wrzucamy nasz kontener, a wszystko pod spodem buduje nam się samo. Cloud Functions to jest usługa do pisania prostych funkcji, która reaguje na jakieś zdarzenia. Możemy napisać nasz kod w Pythonie, Javie, PHP, Go.

App Engine jest podobne do Cloud Functions, ale nie piszemy tam już takich prostych funkcji. Jest to jednak usługa do bardziej złożonych aplikacji i w podobnych językach możemy pisać kod, aby korzystać z tej usługi. I Cloud Run, jest to container service, czyli używamy kontenerów, wrzucamy do repozytorium i robimy deploy za pomocą Cloud Run.

 

Zasada najniższych uprawnień

Troszkę o security, ponieważ jest to dość istotny temat, tym bardziej w obecnych czasach. Security oczywiście w Google Cloud, czyli Principle of Least Privilege (POLP), jest to kluczowa wręcz zasada w Google Cloud, aby ustawiać jak najniższe uprawnienia osobom, które mają dostęp do naszej infrastruktury. To znaczy, jeśli mamy pana Iksińskiego, który zajmuje się nam jedną VM-ką w Compute Engine i ustawia aplikacje, nie dajemy żadnych uprawnień do IAM, do Cloud Runów, do innych zasobów, dajemy mu jak najniższe uprawnienia do danego zasobu.

Jeśli mamy na przykład panią z księgowości, która chce wchodzić w nasze billing raporty, aby tam sobie je generować, sprawdzać, kontrolować, dajemy wtedy pani tylko i wyłącznie viewera na billing. Nie dajemy możliwości klikania, włączania nowych usług, żeby ktoś coś przypadkiem nie połączył, nie poklikał. Dajemy jej uprawnienia tylko viewer, aby tylko móc sobie popatrzeć, ewentualnie coś zanotować. W Google Cloud mamy bardzo rozbudowaną infrastrukturę uprawnień, gdzie tak naprawdę na każdy zasób można dać różne uprawnienia. Jest to bardzo bezpieczne, bardzo rozbudowane.

Service accounts są to konta identyfikujące usługę, czyli nie nadajemy też uprawnień jeśli jakaś usługa musi korzystać z jakiegoś konta. Nie musimy tego nadawać na jakiegoś użytkownika prawdziwego, tylko tworzymy tak zwany service account i ten service account po prostu z tego korzysta, wtedy uprawnienia musimy dać na dany service account. Jest to również bezpieczne, żeby po prostu nie nadawać zbyt wielu uprawnień różnym osobom, które coś mogą ewentualnie nawet z niewiedzy włączyć, co wygeneruje nam niepotrzebne koszty.

 

Przykładowa infrastruktura na slajdzie

 

 

Na danym slajdzie będę pokazywał przykładową architekturę. Mamy użytkowników, którzy łączą się przez Cloud Load Balancing. Balancer rozprzestrzenia nam ruch na różne kontenery, bądź po prostu VM-ki, aby cały ruch nie szedł w jedną, tylko jest on rozprzestrzeniony do kilku, na przykład w kilku regionach. Następnie mamy naszą frontendową aplikację na App Engine, która jest autoskalowalna, dzięki czemu unikamy przeciążeń jak i również unikamy nadpłaty. Ponieważ jeśli nasze aplikacje, tak jak na początku pokazywałem, skalują się w górę, równie dobrze jeśli jest mniejszy ruch aplikacja będzie skalować się w dół, dzięki czemu będziemy mieli mniejsze koszty.

Nasz backend również na autoskalowalnym App Engine. Cloud Storage Jeśli na przykład mamy sklep z obrazkami, potrzebujemy jakiś grafik, możemy to połączyć z Cloud Storage, dzięki czemu będą zasysane. Równie dobrze możemy, jeśli tworzymy w drugą stronę na przykład jakąś usługę gdzie użytkownicy wrzucają zdjęcia jak jakieś memy czy coś takiego, wtedy również możemy podłączyć do Cloud Storage i jest po prostu przesyłane na serwer, a nie z serwera do Cloud Storage. I oczywiście jeśli potrzebujemy jeszcze jakiegoś Cloud SQL bądź Datastore, również podłączamy to do naszej aplikacji App Engine.

I mamy tak naprawdę przykładową infrastrukturę gotową, zrobioną z autoskalowaniem, dzięki czemu unikniemy przepłacania jak i przeciążeń.

 

Przygotowanie infrastruktury na Black Friday

A propos przeciążeń, to za 10 dni z tego co kojarzę, mamy Black Friday, czyli wielkie święto zakupów. Wydaje mi się, że większość z państwa wie czym jest Black Friday, a jeśli nie to jest to początek sezonu wyprzedaży przed Bożym Narodzeniem, zapoczątkowany w Stanach Zjednoczonych. W Europie i w Polsce Black Friday zyskuje coraz większą popularność wraz z segmentem sprzedaży internetowej. Jak często wiemy, dużo serwisów miało problem na Black Friday. Z tego co ja kojarzę, to sklep X-kom często na Black Friday, nieraz się próbowałem dostać i niestety nie udawało mi się, ponieważ serwery były przeciążone.

Jak przygotować e-commerce na Black Friday? Jeżeli przygotowujemy nasz sklep, potrzebujemy mieć cel, pojemność, architekturę, potem musimy przetestować te systemy. Musimy wiedzieć plus minus jaki będziemy mieli ruch. Wykonanie, czyli wykonanie danej infrastruktury i następnie monitorowanie naszego systemu, czy nie zostaje przeciążony.

A propos przeciążenia, tak jak normalnie musimy tyle planować, to w usługach które się autoskalują, od razu mamy skalowalność w górę. Możemy z tego korzystać bez tego dużego planowania i martwienia się, czy musimy dokupować te serwery na ten dzień, czy nie dokupować serwerów na ten dzień. Ponieważ mamy usługi Google Cloud Platform, które się autoskalują i wytrzymają nam takie obciążenie, a zarazem nie musimy wydawać na nowy serwer na jeden dzień, ponieważ po Black Friday jak będzie mniejszy ruch, automatycznie zacznie nam się to skalować w dół.

 

Usługi skalowalne Google Cloud

Mamy takich kilka usług w Google. Compute Engine sam z siebie niestety nie jest skalowalny, ale mamy już coś takiego jak Managed Instance Group – jest to zbiór maszyn wirtualnych, które już potrafią się skalować zarówno w górę jak i w dół. Mamy wcześniej wspomniany App Engine, mamy Cloud Run oraz Kubernetes Engine. W Cloud Run i Kubernetes używamy obrazów, a w App Engine używamy kodu.

Teraz pokrótce opowiem a propos wszystkich tych wcześniej wspomnianych usług. Zacznijmy od Managed Instance Group i tak jak wspomniałem, jest to zbiór maszyn wirtualnych, którymi możemy zarządzać centralnie. W dużym uproszczeniu jest to po prostu jakby wszystkie maszyny wirtualne w jednym dużym urządzeniu. Instance Group zapewnia automatyczne skalowanie w górę jak i w dół. Należy ustawić minimalną oraz maksymalną liczbę instancji, do których może odbywać się skalowanie. To jest o tyle ważne, ponieważ jeśli ustawimy skalowanie do zera, wtedy jeśli mamy pierwszy ruch, zazwyczaj klient będzie musiał chwilę poczekać żeby te maszynki jakby włączyły się.

Więc jeśli wiemy, że mamy jakikolwiek ruch to jednak zawsze polecamy ustawiać na minimalną wartość na jeden, żeby zawsze w tle chodziła ta aplikacja, że jak ktoś nagle wejdzie żeby nie musiał czekać aż one się włączą. Maksimum instancji również ustawiamy na taką jaką chcemy. Ponieważ jeśli dostaniemy jakieś niepożądane ataki typu DDoS na nasz serwer, to wtedy te maszynki, staną one po prostu skalowalne i będą wstawać. A propos tego, to mamy również usługę Cloud Armor, która broni nas przed takimi nikczemnymi zachowaniami.

Jak wdrożyć Managed Instance Group? Na bazie danego szablonu konfigurujemy sobie nasz serwis, możemy uzależnić skalowanie od trzech metryk takich jak użycie procesora, wykorzystanie load balancera w procentach, bądź jakąś inną metrykę z monitoringu. 

 

Co to App Engine i jak go wdrożyć?

Jest to usługa, która włącza się i automatycznie dostosowuje się do zwiększenia oraz zmniejszenia ruchu. W App Engine możemy używać wielu języków programowania takich jak Java, Ruby, C#, Go, Python lub PHP. Jest to w pełni zarządzalne środowisko, które pozwala się skupić wyłącznie na naszym kodzie, a App Engine stworzy resztę. 

Jak wdrożyć App Engine? Piszemy naszą aplikację w wymienionych językach programowania, następnie musimy mieć plik konfiguracyjny w YAMLu. I wdrażamy naszą aplikację poprzez Cloud SDK czyli konsolę.

 

Cloud Run i wdrażanie kontenerów

Cloud Run jest to usługa, w której uruchamiamy kontenery, obrazy dockerowe. Wystarczy go po prostu stworzyć, skonteneryzować naszą aplikację, następnie wrzucamy do Cloud Repository albo Artifact Registry i odnieść się do niego przy konfiguracji.

Cloud Run jest najprostszym sposobem do uruchamiania usług aplikacji kontenerowych w Google Cloud. Jak wdrożyć to już w sumie też pokrótce opowiedziałem. Musimy przygotować kontener dockerowy, wypushować ten obraz do Artifact Registry i podczas konfigurowania wpisujemy ścieżkę do danego kontenera i uruchamiamy naszą aplikację.

 

Google Kubernetes Engine

Na końcu mamy Google Kubernetes. Jest to narzędzie do zarządzania aplikacjami kontenerowymi. Jest to usługa hybrydowa, która korzysta z maszyn wirtualnych, które są zarządzane przez managera klastra. GKE implementuje pełny interfejs Kubernetes API i czterokierunkowe autoskalowanie i obsługę wielu klastrów. Tak, jest to ewidentnie usługa do jak najwyższych, złożonych rozbudowanych aplikacji z kontenerami.

Jak wdrożyć Kubernetes Engine? Na pewno musimy napisać naszą aplikację, stworzenie obrazu dockerowego i wysłanie go do Artifact Registry, stworzenie klastra Kubernetes, stworzenie deploymentu na bazie utworzonego obrazu, upublicznienie, i wdrożenie. GKE jest trochę podobne do Cloud Runu, ale tworząc deployment trzeba skonfigurować bardzo dużo parametrów, między innymi skalowanie. Ostatnim etapem jest upublicznienie naszego wdrożenia. Kubernetes to bardzo złożone narzędzie i jego dokładny opis znacząco wykracza poza zakres tej prezentacji, więc zachęcam państwa do kontaktu z nami, bądź po prostu zapoznania się. Ponieważ o Kubernetes tak naprawdę to godzinkę mógłbym opowiadać tylko i wyłącznie o nim i o niczym więcej.

 

Prezentacja demo: Skalowanie w Cloud Run

Prezentację demo obejrzysz na nagraniu z webinaru (czas: 33:25)

Mam dla państwa przygotowane krótkie demo a propos wdrożenia aplikacji na Cloud Runie. Jest to aplikacja taka testowa, która dostarcza Google, ale pięknie zobrazuje oraz pokaże nam jak wygląda skalowanie na tej oto usłudze. Tutaj na naszym komputerku włączę, chyba widzimy, zerknę… widzimy. Super. Tak więc jesteśmy w naszym panelu Google Cloud i następnie przechodzimy do zakładki Cloud Run. Ja tutaj aby państwa nie zanudzać przygotowałem sobie wcześniej, już wdrożyłem aplikację testową skonteneryzowaną z ustawionym skalowaniem. Jest to bardzo łatwe do wyklikania, tak jak przed chwilą pokazywałem. Jest to domyślna taka podstawowa aplikacja od Google z obywatelem z jednorożcem.

Dzięki usłudze Locust do wymuszania ruchu spróbuję teraz wdrożyć dość spory ruch na moją podstawową aplikację, która stoi dość tam na słabej wirtualce z oczywiście autoskalowaniem, gdzie ona sobie tam wegetuje na jednej wirtualce. Wpisałem aby było 100 000 użytkowników w piku przez 10 sekund, aby po prostu zobaczyć jak sobie poradzi z tym Cloud Run, że z takiej prostej usługi na którą nikt nie wchodził, nagle wskakuje nam 100 000 użytkowników w odstępie 10 sekund. Tutaj Locust nam pokazuje jak to wzrasta.

I teraz przejdziemy jeszcze tutaj, pokazuje że nic się nie wykrzacza, strona działa podczas ruchu tych 100 000 osób. Możemy sobie wszystko to oczywiście sprawdzić w naszym kontenerku w Cloud Runie. Tutaj robiłem wcześniej właśnie te testy i możemy zobaczyć na wykresie jak wzrosły requesty, oczywiście te metryki mamy domyślnie utworzone, dzięki czemu mam super kontrolę nad tym co widzimy tak naprawdę. I tutaj najważniejsze: instance count, czyli skalowanie. Cały czas mieliśmy jedną, ustawiłem na minimalną jedną żeby nie trzeba było czekać i nagle w piku automatycznie bez żadnego mojego ruchu czy dotyku wyskalowało się to do czterech, potem spadło do trzech i już po dosłownie chwili z powrotem do jednej.

Ponieważ taką mu narzuciłem minimalną wartość, żeby zawsze przynajmniej jedna instancja była włączona. Dlatego jest to, jeśli chodzi o Black Friday, super usługa. Automatycznie nam się wyskaluje, nie musimy nad tym wyczekiwać oraz oczywiście nie przynosi nam to później kosztów gdy skończy się dany ruch, bo jest to jednak bardzo istotne również, o tym zapominamy. Bo każdy myśli tylko jak utrzymać serwery na Black Friday, ale jednak trzeba pamiętać również, że ten ruch się dość szybko kończy. Wtedy jeśli nakupujemy serwerów bądź innych usług, co z nimi potem zrobić, z powrotem odsprzedać czy zwrócić, czy co? Bo tak naprawdę przez resztę roku aż takiego ruchu jak w Black Friday to na pewno nie będzie.

 

Sesja pytań i odpowiedzi (Q&A)

To już pokrótce wszystko. Jeśli się pojawiły jakieś pytania to postaram się chętnie odpowiedzieć. Jeżeli są to jeszcze jakieś bardziej rozbudowane czy zaawansowane pytania, zachęcam do kontaktu poprzez naszych sales, bądź pisanie bezpośrednio na mój adres, może jeszcze dopiszę w razie co, albo na taki.

P: Czy jest mechanizm wykrywania anomalii kosztowych, który wysyła maile?

Jeśli o anomalie kosztowe chodzi to, tak jak mówiłem na początku a propos billingu, mamy tam taką usługę jak budżety i alerty, i te alerty tak naprawdę przychodzą do billing account userów i billing account administratorów. Jeżeli właśnie wzrośnie, nie jest to jako anomalie stricte, bo to niestety nie wykryje czy my włączyliśmy, że nagle wzrosły koszty, czy jednak nie. Ale ustawiając sobie te progi, to nad tym mamy pełną kontrolę.

P: Czy można skalować Cloud SQL, MySQL, czy jednak baza musi być uruchomiona zawsze?

Jeśli chodzi o Cloud SQL, jest ona uruchomiona, że tak powiem, zawsze. Nie można tego wyskalować do zera.

 

Zakończenie

Jeszcze tutaj, ja również tutaj koleżanka widzę, że już podziękowała za uwagę, ja również dziękuję państwu bardzo serdecznie za uwagę. Mam nadzieję, że nauczyli się państwo, albo dowiedzieli się po prostu czegoś nowego, bądź czegoś co państwa zainteresowało. Jeśli tak, to chętnie zapraszam do kontaktu z FOTC, może możemy pomóc jakoś w rozwiązaniu problemów w waszej firmie, bądź skorzystania z naszej usługi takiej jak optymalizacja kosztów.

Jeśli cokolwiek jakieś pytania, bądź chęć przeniesienia po prostu swojej infrastruktury do Google Cloud, zachęcamy do kontaktu, tak z naszym supportem bądź z naszym działem sprzedaży. Podejrzewam że to będzie sales, którzy odpowiedzą na pytania, a support to jednak bardziej techniczne do nas, tak jest. Dziękujemy serdecznie i do usłyszenia, do zobaczenia.