Czyli w jaki sposób postawić stronę WWW bez serwera?
W Internecie istnieją setki milionów blogów. Z czego większość działa na WordPress – aplikacji serwerowej napisanej w PHP. Według statystyk, które podaje organizacja rozwijając tą platformę, jest to aż 75 milionów stron, czyli 27% całego Internetu (źródło).
Jakby nie patrzeć jest to imponujące osiągnięcie tego oprogramowania open source. W praktyce prawie każdy na hasło blog myśli Wordpress. Istnieją jednak inne rozwiązania pozwalające na zaistnienie w Internecie bez konieczności posiadania własnych serwerów.
Uwaga: Severless Polska korzysta z rozwiązania opisanego poniżej!
Hosting serverless
Hosting serverless w AWS opiera się na połączeniu trzech popularnych usług. Źródłem jest wiaderko AWS S3, z którego usługa AWS S3 serwuje pliki do AWS CloudFront. Zawartość strony WWW jest dostępna pod url domeny zdefiniowanym w Route53, jeśli nie chcemy to domena nie musi być skonfigurowana w AWS.
Na diagramie widzimy ogólny proces działania rozwiązania.
- Następuje żądanie połączenia z przeglądarki do strony WWW przez Internet
- Strona WWW znajduje się pod adresem URL skonfigurowanym w Hosted Zone w Route53
- URL wskazuje na dystrybucję AWS CloudFront
- Dystrybucja CloudFront jako źródło ma ustawione wiaderko S3.
Wiaderko S3 jest niepubliczne i tylko dystrybucja CloudFront ma do niego dostęp, co zwiększa bezpieczeństwo rozwiązania (szczególnie w przypadku SPA o czym poniżej wspominam).
CloudFront to oferowana przez AWS usługa typu content delivery network (CDN), czyli *”rozproszony system dostarczania treści do wielu centrów danych i punktów wymiany ruchu w Internecie”. CloudFront to taki globalny cache dla stron WWW, wideo, API i aplikacji webowych. Posiada 166 punktów dostępowych (*edge location) na całym świecie, to znaczy, że gdy ktoś wchodzi na stronę WWW dostarczaną przez CloudFront to zostanie on skierowany do najbliższego geograficznie punktu, w którym znajduje się kopia strony. Jeśli w najbliższym punkcie nie ma jeszcze kopii (lub się zdezaktualizowała) to CDN pobierze aktualną wersję ze źródła i przekaże klientowi.
Aktualnie najbliższy punkt dostępowy dla nas znajduje się w Warszawie.
Używanie CDN to dosyć stara praktyka optymalizacji ruchu w Internecie, osobiście słyszałem o niej jeszcze w latach 90-tych ubiegłego wieku. Na pewno wiele się zmieniło od tamtych czasów, natomiast nie byłoby w CloudFront nic interesującego gdyby nie Lambda@Edge.
Co to jest Lambda@Edge ?
Jest to specjalny rodzaj funkcji Lambda, która jest uruchamiana bliżej klienta, stąd też angielska nazwa Edge (krawędź, brzeg, skraj). Taka architektura pozwala zaoszczędzić na czasie (dla nas kod wykona się w Warszawie, a nie w Stanach) oraz wykonać funkcję w kontekście geograficznym na przykład przekierować użytkownika spoza Polski na angielskojęzyczną wersję strony. Innym zastosowaniem może być zablokowanie określonych części naszej strony (np. sklepu internetowego) dla osób z kraju gdzie nie możemy prowadzić działalności - wszystko to bez ingerencji w kod źródłowy aplikacji - na marginesie mówiąc jest to potężna funkcjonalność tego rozwiązania.
Zdarzenia na skraju funkcji 😉
Jak wspomniałem, Lambda@Edge jest osadzona w dystrybucji CloudFront i jest w stanie reagować tylko i wyłącznie na zdarzenie wygenerowane przez tę usługę. Zostały one przedstawione na rysunku poniżej. Istnieją tylko cztery, a do tego są symetrycznie, więc łatwo je zrozumieć. Mamy zatem żądanie i odpowiedź pomiędzy klientem a CloudFrontem i analogiczną parę pomiędzy CloudFrontem a źródłem (w naszym wypadku wiaderkiem S3, gdzie umieszczone są pliki HTML, JS, obrazki itp.).
W moim rozwiązaniu działa jedna funkcja Lambda, która jest odpowiedzialna za obsługę ładnych URLi i reaguje na zdarzenie typu Viewer request. To znaczy, że gdy ktoś próbuje odwiedzić https://serverlesspolska.pl/2018/12/01/Wiarygodnosc/ to Lambda zmodyfikuje jego żądanie tak aby CloudFront wysłał mu w odpowiedzi plik https://serverlesspolska.pl/2018/12/01/Wiarygodnosc/index.html. Niestety, ale na chwilę obecną CloudFront nie jest w stanie samemu się domyśleć, że klientowi chodzi o plik index.html i zwróci błąd 404 jeśli nie będzie miał skonfigurowanej takiej funkcji lambda. Takie życie.
Schemat działania Serverless Polska
Strona https://serverlesspolska.pl działa w modelu serverless jak na diagramie poniżej.
Gdzie się podział mój WordPress?
Ponieważ AWS S3 nie pozwala na uruchamianie kodu *”po stronie serwera”* (taki żarcik 🤣) nie możemy mieć strony napisanej w PHP, Ruby czy innej serwerowej technologi. Nie ma mowy o WordPress! Ale to dobrze, aby zapewnić sobie maksymalną wydajność i skalowalność przy niskich kosztach generujemy statyczne pliki HTML wraz z JavaScirpt, który zapewnia dynamikę strony WWW. Sam parę dni temu się dowiedziałem, że takie podejście ma już swoją nazwę JAMstack od JavaScript, API i Markup.
Na rynku istnieje kilka open sourcowych rozwiązań służących generowaniu cały serwisów WWW, głównie typu blog. Między innymi mamy do wyboru Jekyll, który napędza GitHub Pages, co jest już rekomendacją samą w sobie. Alternatywą jest hexo.io, z którego osobiście sam korzystam na Serverless Polska. Artykuły są pisane w markupie (jak wikipedia) dzięki czemu pisząc nie trzeba się pałować z wyglądem. Następnie za pomocą polecenia hexo generate generowany jest statyczny kod HTML+JavaScript. Ostatnim etapem jest wysłanie nowowygenerowanych plików do wiaderka S3 i poproszenie CloudFront o inwalidację cache’u, aby w swoich kopiach zastąpił starą wersje strony nową.
Warto podkreślić, że tego typu rozwiązania (Jekyll, hexo) działają bez bazy danych! Czyli o jedną absorbującą i kosztowną rzecz mniej! Oczywiśćie brak bazy danych znakomicie ułatwia skalowanie i zasadniczno sprawia, że znów chce się żyć 😋 To jest ogromna zaleta!
Źródła serwisu Serverless Polska są normalnie trzymane w gicie (AWS CodeCommit), dlatego nie ma najmniejszego problemu aby proces aktualizacji strony zautomatyzować przy pomocy AWS CodeBuild lub innego, dowolnego narzędzia CI. Cały proces publikacji nowej wersji to wywołanie trzech komend po commicie do repozytorium.
1 | hexo generate |
I to wszystko, działa jak marzenie 😎
SPA (Singe Page Application) hosting
Jeśli masz lub chcesz uruchomić aplikację typu SPA to hosting serverless będzie dla Ciebie idealny. Sam posiadam serverlessowy startup, gdzie frontend napisany w React.js jest hostowany w takim samym modelu (z pominięciem funkcji Lambda@Edge bo dla SPA nie jest potrzebna).
Szyfrowane połączenia
Aby mieć certyfikat TLS musimy skorzystać z usługi AWS Certificate Manager, która pozwala na wygenerowanie darmowego certyfikatu w regionie N.Virginia (us-east-1). Taki certyfikat bezproblemowo integruje się z dystrybucją AWS CloudFront.
Tradycyjny hosting a serverless
Rozważmy dwa tradycyjne modele stawiania stron WWW pod Wordpress. Mówię tutaj o komercyjnych zastosowaniach, gdzie chcemy mieć własną domenę, połączenie szyfrowane TLS (https) oraz jako taką pewność, że strona będzie działać. Hosting u szwagra w szafie odpada 😋
| Dedykowany serwer | Wykupiony hosting | |
|---|---|---|
| Trwałość (czy nie stracisz danych) | Tylko jeśli robisz backupy. Ale gdzie skoro masz jeden serwer? | Średnia do wysoka. Zazwyczaj robione są codzienne backupy i są wbudowane mechanizmy przywracania backupów. |
| Skalowalność (czy obsłuży nieprzewidziany duży ruch) | Brak. Musisz mieć maszynę tak mocną jak największy peak twojego ruchu. Innymi słowy jak nagle Twój post zyska popularność i 100 000 osób będzie chciało go przeczytać to Twój serwer może paść. | Niska. Rozszerzalna za opłatą. Płacimy więcej nawet gdy jest mały ruch. |
| Dostępność (czy jest odporny na awarie) | Niska, “pojedynczy punkt awarii”. | Duża. (tak dobra jak dostawcy, którego wybierzemy) |
| Globalny CDN | Brak. | Tak lub w opcji. |
| Koszt | Wysoki. | Średni lub wysoki. |
| Zaangażowanie w obsługę | Bardzo wysokie. W pełni manualna konfiguracja. Trzeba ustawić maszynę samemu i się nią opiekować (pacze, updejty, bezpieczeństwo). | Bardzo niskie. Kupujemy usługę i działa. |
| Języki wykonywalne po stronie serwera | Tak. | Tak. |
Jak widać powyższe opcje mają dwa podstawowe problemy:
- nie są skalowalne,
- generują koszty nawet gdy stoją bezczynnie - opłaty nie odzwierciedlają realnego użycia.
Hosting serverless oferuje
| Serverless hosting | |
|---|---|
| Trwałość (czy nie stracisz danych) | Bardzo wysoka. |
| Skalowalność (czy obsłuży nieprzewidziany duży ruch) | Praktycznie nieograniczona, dynamiczna. |
| Dostępność (czy jest odporny na awarie) | Bardzo duża. |
| Globalny CDN | Tak [wbudowany CloudFront]. |
| Koszt | Bardzo niski, bezpośrednio zależny od ruchu. |
| Zaangażowanie w obsługę | Średnie. Trzeba na początku skonfigurować ale potem się już nic nie robi. |
| Języki wykonywalne po stronie serwera | Nie. Tylko JavaScript po stronie klienta. |
Jak widać hosting serverless ma zdecydowaną przewagę nad tradycyjnymi rozwiązaniami. Technicznie jest to świetna opcja, którą gorąco polecam każdemu, przynajmniej pod rozwagę.
Równocześnie, mam świadomość, że dla większości firm i ludzi odejście od WordPress może wydawać się niemożliwe biorąc pod uwagę jego ogromny ekosystem - tysiące pluginów, skórek, kursów itd.
Koszty
Są uzależnione od ruchu na stronie. Zatem jeśli ten artykuł zostanie odsłonięty 200 miliardów razy to pójdę z torbami… 😆
Serverless Polska łapie się w Free Tier. Na chwilę obecną głównym kosztem jest 50 centów, co miesiąc ryczałtowej opłaty za konfigurację domeny w Route53. Dodatkowo 18 centów za S3, 10 centów za CloudFront i 3 centy za Lambdę (to obejmuje też koszy użycia spoza Serverless Polska, moje inne projekty, dane itp.). Razem hosting Serverless Polska wyniósł 81 centów w lutym 2019. Wszystkie usługi poza Route53 są rozliczne w modelu pay-as-you-go, czyli zależą od realnego użycia i nie generują kosztów w przypadku bezczynności.
Jeszcze raz podkreślam, że z racji użycia hexo.io nie potrzebuje bazy danych, co zmniejsza koszty, oszczędza mój czas na obsłudze i nie tworzy problemów przy skalowaniu.
AWS Free Tier
AWS Free Tier posiada następujące limity
- CloudFront: 50GB data transfer out, 2,000,000 HTTP and HTTPS Requests.
- S3: 5GB na dane, 20,000 requestów, 2,000 put’ow (prez rok)
Lambda@Edge nie ma darmowej opcji. Kosztuje:
- $0.0000006 per request, czyli 60 centów za milion requestów, plus
- $0.00000625125 za każdą sekundę działania z pamięcią 128MB (przy większych zasobach odpowiednio drożej)
Miłego dnia i powodzenia przy tworzeniu rozwiązań serverless!
Paweł
