Co to jest AWS (Amazon Web Services) i jakie usługi oferuje?

AWS (Amazon Web Services) to publiczna chmura obliczeniowa, która dostarcza wirtualne serwery, przestrzeń dyskową, bazy danych i narzędzia sieciowe przez internet w modelu płatności za faktyczne zużycie. Platforma ta pozwala firmom uruchamiać dowolne aplikacje i systemy bez konieczności kupowania, utrzymywania i serwisowania fizycznego sprzętu we własnych serwerowniach. Prawda jest zresztą absolutnie taka, że dzisiaj większość globalnego internetu stoi na ich infrastrukturze. I to widać na każdym kroku u każdego dużego dostawcy usług cyfrowych.

Kiedyś kupowało się maszyny za grube dziesiątki tysięcy. Czekało się tygodniami na dostawę sprzętu od dystrybutora. Teraz klikasz w panelu i po kilkunastu sekundach masz gotowy serwer z Linuxem albo Windowsem. To po prostu brutalna wygoda. Chmura AWS daje dostęp do setek różnych specjalistycznych narzędzi. Od prostego hostingu dla małych stron po potężne klastry obliczeniowe dla modeli sztucznej inteligencji. My w zespole wdrożeniowym najczęściej używamy twardych podstaw, bo to one robią największą robotę w typowym, codziennym biznesie B2B.

Dlaczego firmy rezygnują z własnych serwerowni na rzecz chmury AWS?

Utrzymanie własnego sprzętu to finansowa studnia bez dna. Dyski padają. Kable się psują. Zasilacze palą się w weekendy. Prąd drożeje z miesiąca na miesiąc. Przejście na usługi chmurowe Amazon Web Services ucina te problemy u samego twardego źródła. Firma płaci tylko za to, co aktualnie działa na koncie. Wyłączasz serwer testowy na noc? Rachunek natychmiast spada. To model IaaS (Infrastructure as a Service) w najczystszej i najprostszej postaci rynkowej.

Zrobieliśmy na wdrożeniu w zeszłym miesiącu prosty test dla klienta z branży e-commerce z małego osiedla na obrzeżach Poznania. Mieli własny serwer w szafie w biurze. Kiedy przyszła sezonowa wyprzedaż, ruch zabił im stronę w trzy minuty od wysłania mailingu. Przenieśliśmy ich sklep na wirtualne instancje z automatycznym skalowaniem. Problem zniknął. System sam dodał cztery kolejne maszyny, gdy obciążenie nagle wzrosło. Potem o północy je usunął. Rachunek za ten skok wyniósł ledwie kilkanaście dolarów za transfer. Kupno nowego fizycznego serwera pod ten jeden dzień kosztowałoby ich ułamek budżetu rocznego na całe IT.

Zawsze powtarzam, że AWS to nie jest tania zabawka do nauki programowania. Jeśli zostawisz włączone potężne maszyny obliczeniowe i o nich zapomnisz, faktura na koniec miesiąca mocno zaboli budżet projektowy. Ale ten system daje pełną kontrolę i mierzalność. Zawsze wiesz, za co płacisz. Przesuwasz koszty z wydatków kapitałowych (CAPEX) na koszty operacyjne (OPEX). Księgowi to uwielbiają.

Jakie są najpopularniejsze usługi infrastrukturalne w Amazon Web Services?

Amazon ma w ofercie grubo ponad dwieście usług. Nikt nie zna ich wszystkich. Nawet inżynierowie w samym Amazonie gubią się w nowościach. W codziennej pracy używa się zazwyczaj kilku podstawowych bloków budulcowych. Z nich składa się większość aplikacji webowych i systemów firmowych.

Jak działa wirtualny serwer Amazon EC2 w praktyce?

Amazon Elastic Compute Cloud (EC2) to twarde serce całej platformy AWS. To po prostu twój wirtualny serwer w chmurze. Wybierasz system operacyjny, ilość pamięci RAM i moc procesora. Uruchamiasz. Gotowe. Masz pełen dostęp przez protokół SSH z prawami administratora systemu.

Instancje EC2 dzielą się na różne specjalistyczne rodziny. Jedne mają więcej procesora do ciężkich obliczeń matematycznych. Inne mają więcej pamięci RAM do obsługi baz danych. Dobrym pomysłem jest dobranie precyzyjnego typu maszyny do konkretnego zadania, żeby nie przepalać budżetu na zasoby, z których aplikacja i tak nie skorzysta w trakcie działania.

• T3 lub T4g – małe, tanie maszyny do testów i prostych aplikacji. Dają radę przy skokowym ruchu dzięki mechanizmowi zbierania kredytów procesora.
• Rodzina C – instancje zoptymalizowane pod surową moc obliczeniową. Używamy ich do kodowania wideo i analizy potężnych logów, gdzie procesor poci się na potęgę przez kilka godzin. Zazwyczaj odpalasz je na krótko. Robią swoje i idą do kosza.
• Typ R – potwory z ogromną ilością RAMu na pokładzie. Idealne pod bazy danych trzymane w pamięci dla minimalizacji opóźnień.
• Instancje Spot – kupujesz niewykorzystaną moc obliczeniową Amazonu za ułamek standardowej ceny. Haczyk polega na tym, że chmura AWS może ci ten serwer zabić i zabrać z dwuminutowym wyprzedzeniem. Świetna sprawa do zadań w tle i asynchronicznego przetwarzania danych.

Nie ma tu żadnej magii. To po prostu cudzy komputer zamknięty w ogromnej, klimatyzowanej hali gdzieś we Frankfurcie lub w Irlandii. Działa świetnie pod dużym obciążeniem.

Gdzie przechowywać pliki i backupy używając Amazon S3?

Amazon Simple Storage Service (S3) to magazyn na obiekty. Nie zainstalujesz tam żadnego systemu operacyjnego. Ta usługa służy wyłącznie do trzymania plików. Zdjęć, filmów, backupów, logów systemowych, dokumentów PDF. S3 jest ekstremalnie tanie i praktycznie bezawaryjne. Amazon chwali się trwałością danych na poziomie jedenastu dziewiątek po przecinku. To oznacza wprost, że ryzyko utraty pojedynczego pliku z winy infrastruktury jest bliskie zera.

Wrzucasz plik do tak zwanego wiadra (bucket). Dostajesz natychmiast link. Możesz go udostępnić publicznie dla wszystkich w internecie albo twardo zablokować dostęp tylko dla swoich aplikacji. Sam często konfiguruję S3 tak, żeby starsze pliki automatycznie przenosiły się na tańsze warstwy przechowywania, takie jak S3 Glacier. Glacier jest śmiesznie tani w utrzymaniu. Odzyskanie z niego danych zajmuje jednak kilka godzin. Idealne miejsce na archiwa księgowe firmy, do których nikt nie zagląda latami, a prawo wymaga ich trzymania na dysku.

W jaki sposób chmura AWS obsługuje bazy danych bez administracji?

Stawianie własnej bazy danych na gołym serwerze to proszenie się o gigantyczne kłopoty pozycjonujące w nocy. Trzeba dbać o aktualizacje silnika, robić codzienne kopie zapasowe, konfigurować trudną replikację master-slave. Amazon Web Services przejmuje te obowiązki w ramach usług zarządzanych (PaaS – Platform as a Service). Ty tylko podpinasz aplikację i korzystasz z bazy. Resztą martwią się skrypty automatyzujące chmury.

Kiedy wybrać Amazon RDS a kiedy nierelacyjne DynamoDB?

Amazon RDS (Relational Database Service) obsługuje w pełni klasyczne silniki. MySQL, PostgreSQL, MS SQL Server czy Oracle. Klikasz formularz i masz gotową bazę z automatycznymi backupami do 35 dni wstecz. Jeśli główna maszyna z bazą fizycznie padnie, system sam przepnie cały ruch na maszynę zapasową w innej strefie dostępności. To dosłownie ratuje życie na produkcji podczas awarii sprzętowych w centrum danych.

Z drugiej strony mamy usługę DynamoDB. To flagowa baza NoSQL od Amazonu. Nie ma tu tabel, kolumn i sztywnych relacji w klasycznym rozumieniu języka SQL. Są elastyczne dokumenty i klucze wartości. DynamoDB skaluje się automatycznie w nieskończoność. Używamy tego w projektach, gdzie dziesiątki tysięcy użytkowników zapisują drobne dane w ułamku sekundy. Wyniki w grach mobilnych lub logi z urządzeń IoT. Zwykły RDS by się przy tym zadławił od blokad na tabelach. DynamoDB nawet nie zauważy takiego obciążenia na wykresach.

Relacyjna baza RDS jest o wiele łatwiejsza na start dla nowego projektu. Większość programistów zna SQL od czasów studiów. W zdecydowanej większości standardowych aplikacji webowych i systemów ERP to właśnie baza relacyjna stanowi domyślny, bezpieczny wybór architektoniczny.

Co to jest architektura serverless i jak działa AWS Lambda?

Serverless to podejście programistyczne, w którym jako deweloper w ogóle nie myślisz o utrzymaniu serwerów. Piszesz tylko sam kod biznesowy. Usługa AWS Lambda pozwala uruchomić ten kod w odpowiedzi na konkretne zdarzenie w systemie. Ktoś wgrywa zdjęcie profilowe do koszyka S3? Lambda odpala się automatycznie, zmniejsza to zdjęcie do formatu miniatury i wyłącza się po 200 milisekundach. Płacisz tylko i wyłącznie za te 200 milisekund działania procesora.

Zmienia to całkowicie podejście do pisania i wyceny aplikacji. Zamiast ogromnego, monolitycznego systemu, masz kilkadziesiąt małych, niezależnych funkcji. Kodujesz w Pythonie, Node.js albo Go. Brak widocznego serwera oznacza całkowity brak łatania systemu operacyjnego po godzinach pracy. Skalowanie jest natychmiastowe. Jeśli tysiąc osób wgra zdjęcie w tej samej sekundzie, AWS uruchomi równolegle tysiąc instancji Lambdy. To podejście tnie na pół koszty w aplikacjach o bardzo nieregularnym, skokowym ruchu sieciowym.

Zastanawiacie się zresztą, dlaczego to na produkcji tak wyje na testach po drodze? Sam się nad tym borykałem dzisiaj u siebie we wtorek. Wdrażaliśmy głupią poprawkę do VPC (Virtual Private Cloud). Architektura sieciowa w AWS potrafi zjeść nerwy na surowo. Konfigurujesz podsieci publiczne, prywatne, tabele routingu, bramy internetowe NAT. Zrobiłem małą literówkę w regułach Security Group i odcięło nam całkowicie dostęp do bazy danych. Trzy godziny szukania w logach CloudTrail. Chociaż prawdę mówiąc brakuje nam twardych danych za wczoraj, więc wydaje się to tylko jedną z możliwych hipotez na ten pad systemu przed weekendem. Systemy w chmurze są super, dopóki nie zaczną rzucać dziwnymi błędami IAM o braku uprawnień na poziomie polityk ról. Czasem mam ochotę rzucić to wszystko i wrócić do stawiania prostego FTP na współdzielonym hostingu za pięć złotych. Ale potem patrzę na metryki wydajności i mi przechodzi złość na to środowisko.

Ile faktycznie kosztuje korzystanie z usług chmury Amazonu?

Cennik AWS to lektura dla bardzo wytrwałych inżynierów. Jest skomplikowany. Podstawowa zasada rozliczeń w chmurze publicznej brzmi: płacisz za zużytą moc obliczeniową, zajęte miejsce na dyskach blokowych i transfer danych wychodzących z chmury do zewnętrznego internetu. Transfer wchodzący do AWS jest całkowicie darmowy. Amazon chce, żebyś wgrał tam swoje dane bez oporów. Schody zaczynają się, gdy chcesz te gigabajty wyciągnąć na zewnątrz.

Jakie ukryte koszty transferu danych zaskakują początkujących?

Wielu ludzi łapie się na wewnątrzsieciowych kosztach architektury. Stawiają główny serwer aplikacji i bazę danych w dwóch różnych strefach dostępności (Availability Zones) dla zachowania wysokiej odporności na awarie. Bardzo mądry pomysł inżynieryjny. Ale AWS kasuje drobne kwoty za przesyłanie danych pomiędzy tymi strefami. Jeśli aplikacja intensywnie gada z bazą i przesyła gigabajty zapytań, rachunek za sam transfer wewnętrzny potrafi zabić opłacalność projektu.

Kolejna bolączka to przypisane publiczne adresy IPv4. Od niedawna Amazon zaczął pobierać opłatę za każdy przypisany publiczny adres IP na koncie, nawet jeśli przypięta do niego instancja jest wyłączona z prądu. Małe pozycje na fakturze zbierają się w duże kwoty. Dlatego zawsze konfigurujemy alarmy budżetowe w usłudze AWS Budgets na każdym nowym koncie. Jak koszty dobiją do 50 dolarów, dostaję maila. Proste, twarde i skuteczne rozwiązanie na ochronę portfela.

Czy dane w chmurze publicznej AWS są bezpieczne przed atakami?

Bezpieczeństwo w Amazon Web Services opiera się w całości na modelu współdzielonej odpowiedzialności. AWS dba o fizyczne bezpieczeństwo „samej chmury”. Chronią serwerownie zbrojonymi strażnikami, zabezpieczają sprzęt sieciowy, kable, zasilanie i chłodzenie. Ty dbasz o oprogramowanie i bezpieczeństwo „w chmurze”. Konfigurujesz zapory sieciowe, zarządzasz uprawnieniami użytkowników w systemie i szyfrujesz dane na dyskach.

Jeśli z lenistwa zostawisz otwarty port 22 (SSH) na cały świat i ktoś włamie się na twój wirtualny serwer podrzucając koparkę kryptowalut, to jest wyłącznie twoja wina. AWS dostarcza masę narzędzi ochronnych do zbudowania szczelnego środowiska. AWS WAF (Web Application Firewall) blokuje na brzegu sieci ataki typu SQL Injection. Amazon GuardDuty analizuje logi sieciowe pod kątem podejrzanej aktywności przy pomocy uczenia maszynowego. AWS Shield chroni zasoby przed masowymi atakami DDoS.

Używamy centralnej usługi IAM (Identity and Access Management) do rygorystycznego cięcia uprawnień między serwisami. Zasada najmniejszego możliwego przywileju. Jeśli aplikacja do fakturowania musi tylko czytać pliki z konkretnego wiadra S3, dajemy jej uprawnienie wyłącznie do czytania. Żadnego modyfikowania. Żadnego kasowania plików. To twardy wymóg architektoniczny na każdej produkcji B2B w naszej firmie bez wyjątku.

Jak zarządzać ruchem za pomocą Amazon Route 53 i CloudFront?

Aplikacja stojąca na serwerze to jedno, ale użytkownicy muszą do niej jakoś trafić z przeglądarki. W tym miejscu wchodzi infrastruktura sieciowa na brzegu. Amazon Route 53 to ich autorski system DNS. Zarządza domenami internetowymi i kieruje ruch do odpowiednich serwerów. Route 53 potrafi sprawdzać zdrowie serwerów. Jeśli maszyna w Warszawie przestanie odpowiadać na pingi, DNS automatycznie przekieruje klientów na zapasowy serwer w innej lokalizacji.

Z kolei Amazon CloudFront to usługa typu CDN (Content Delivery Network). Przyspiesza ładowanie stron internetowych. CloudFront buforuje statyczne pliki (obrazki, skrypty JS, arkusze CSS) na setkach serwerów brzegowych rozsianych po całym świecie. Jeśli użytkownik z Japonii wejdzie na twój polski sklep, nie pobiera zdjęć z serwera w Europie. Dostaje je z najbliższego węzła w Tokio. Zmniejsza to obciążenie głównych instancji EC2 i drastycznie obcina koszty drogiego transferu wychodzącego, o którym wspominałem wyżej.

Czytanie suchej dokumentacji to jedno. Inżynieryjna praktyka to zupełnie co innego. Złóż sobie testowe konto w AWS. Mają bardzo obszerny darmowy pakiet na pierwszy rok, tak zwany Free Tier. Postaw najprostszą stronę HTML na małej instancji EC2. Wgraj do niej plik graficzny na S3. Skonfiguruj bazę RDS i zepnij to w działającą całość kodem. Zobaczysz na własne oczy, jak szybko można budować skalowalne systemy, omijając biurokrację i zakupy sprzętu. A jeśli obawiasz się, że klikniesz coś nie tak w panelu i dostaniesz rachunek na tysiąc dolarów w poniedziałek? Ustaw ten alarm budżetowy na samym początku pracy. Zatem zrób to po prostu dzisiaj wieczorem i sprawdź, czy faktycznie potrzebujesz tego drogiego, powolnego hostingu VPS, za który płacisz faktury od pięciu lat.

Bibliografia

1. Amazon Web Services – https://aws.amazon.com
2. Główny Urząd Statystyczny – https://stat.gov.pl
3. Wydawnictwo Naukowe PWN – https://pwn.pl
4. Ministerstwo Cyfryzacji – https://www.gov.pl/web/cyfryzacja
5. Naukowa i Akademicka Sieć Komputerowa – https://www.nask.pl