• Ogólne
  • Dla Architektów
  • Bezpieczeństwo

Jak przyśpieszyć ładowanie zawartości stron WWW?

28 czerwca 2018Tomasz StachlewskiDla Architektów

Jeśli posiadasz własną stronę WWW czy też aplikację webową z dużym prawdopodobieństwem posiadasz jakieś zasoby statyczne, które serwujesz swoim użytkownikom. To mogą być takie pliki jak zdjęcia, filmy, muzyka albo po prostu skrypty (.css, .js). Standardowe podejście budowy aplikacji, które było wykorzystywane przez wiele lat, zakładało, że takie zasoby statyczne umieścilibyśmy na zwykłym serwerze, skąd następnie byłyby serwowane dla użytkowników z całego świata. Okazuje się jednak, że w erze ‘chmurowej’, istnieje lepsze podejście. W tym poście przyjrzymy się jak można wykorzystać usługę Amazon Simple Storage Service (S3) oraz Amazon CloudFront, aby przechowywać i dostarczać zasoby w sposób lepszy, szybszy i bezpieczniejszy niż w tradycyjnym podejściu. Aby dodatkowo uprościć cały proces, przygotowaliśmy szablon CloudFormation, który pozwoli wam przetestować samodzielnie to podejście budowy aplikacji w zaledwie kilka minut!

Po pierwsze, musimy gdzieś przechowywać nasze dane statyczne (pliki, filmy, skrypty itp.) – musi to być bezpieczna lokalizacja i wysoce skalowalna. Tutaj sprawa ma się prosto, zasada jest jedna, dane statyczne w chmurze, które będziemy chcieli oferować użytkownikom przez Internet należy umieścić w S3 – czyli Simple Storage Service. S3 to usługa, która dostarcza przestrzeń, gdzie możemy przechowywać dane a następnie udostępniać je za pomocą protokołu HTTPS. S3 ma wiele interesujących charakterystyk, jedną z nich jest to, że automatycznie replikuje dane do wielu serwerowni, dzięki czemu charakteryzuje się bardzo dużą dostępnością i niezawodnością.

Samo użycie S3 jest bajecznie proste, tworzymy bowiem najpierw tzw. bucket – czyli wiaderko, do którego następnie będziemy wrzucać nasze dane. Co istotne, nie musimy również deklarować jak duże będzie to wiadro (ile MB, GB itp.) – bowiem kolejną charakterystyką tej usługi jest to, że automatycznie skaluje się do wymaganej przez nas pojemności. S3 to również przykład usługi typu serverless – czyli takiej, gdzie użytkownik nie musi myśleć o serwerach, które są wykorzystywane w ramach usługi – przykładowo, to dostawca chmurowy zajmuje się bowiem ich aktualizacją – a my skupiamy się na naszych danych, które bezpiecznie przechowujemy w S3.

Warto również dodać, że oczywiście może się okazać, że i tak gdzieś obok będziemy potrzebowali zwykłego serwera – skąd będziemy udostępniali zawartość dynamiczną strony – ale nawet wówczas, poprawna architektura zakłada, że S3 wykorzystamy, ponieważ S3 „odciąży” nasze serwery (ponieważ zawartość statyczna nie będzie z nich udostępniana) – a mniej obciążony serwer to możliwie mniejszy serwer, a mniejszy serwer to tańszy serwer.

Co prawda moglibyśmy na tym zakończyć usprawnianie naszej aplikacji (strony), ale tak naprawdę historia tutaj się nie kończy. Kolejnym krokiem, aby zwiększyć szybkość ładowania strony oraz jej bezpieczeństwo jest uruchomienie usługi Amazon CloudFront przez naszym bucketem S3.

CloudFront jest przykładem technologii CDN (ang. Content Delivery Network), która służy do przyśpieszenia dostarczania zawartości stron (statycznych i dynamicznych) dla użytkowników końcowych. W celu zapewnienia swojej funkcjonalności CloudFront wykorzystuje sieć tzw. punktów brzegowych – czyli serwerowni, które będą uczestniczyły w dostarczaniu zawartości strony dla użytkowników końcowych. W chwili pisania tego postu, na świecie jest ponad 110 takich lokalizacji (dalej określanych również jako POPy – ang. Point of Presence), zlokalizowany w 56 miastach, w 24 krajach na świecie (w tym w Polsce!).

Poniższa mapa prezentuje aktualną infrastrukturę CloudFront na świecie.

Idea działania CloudFronta polega na tym, że żądania o zawartość strony (np. obrazków) są kierowane nie do serwerów, gdzie użytkownik domyślnie zapisał dane (np. S3) ale do najbliższej lokalizacji brzegowej. Odbywa się to w sposób przezroczysty dla użytkownika z wykorzystaniem DNSa. Jeśli punkt brzegowy posiada obiekt (obrazek, film itp.) którego dotyczy żądanie to jest on zwracany, jeśli nie, to żądanie następnie zostanie przesłane do serwerowni źródłowej – skąd będzie on pobrany (ewentualnie pomiędzy zostanie jeszcze wykorzystany regionalny cache). Następnie CloudFront cache-uje dany obiekt w punkcie brzegowym, aby zwrócić go następnemu użytkownikowi, który o niego zapyta (czas przechowywania obiektu w punkcie brzegowym jest konfigurowalny). Tego typu podejście pozwala zmniejszyć diametralnie czas zwracania obiektów dla użytkownika końcowego (o czym przekonamy się za kilka minut).

Warto również wspomnieć, że nawet w przypadku dostarczania zawartości dynamicznej – wykorzystanie CloudFronta ciągle może się okazać bardzo dobrym pomysłem, ponieważ CloudFront wykorzysta prywatną sieć AWS w celu szybszego dostarczania zawartości do użytkownika z serwerowni źródłowych.

Zdjęcie jest czasem warte tysiąca słów, zatem poniżej zamieściłem przykładowy przebieg żądań pomiędzy użytkownikiem końcowym a serwerami źródłowymi (w tym przypadku S3). Widzimy na nim, że skonfigurowaliśmy jeden bucket S3 w Europie – gdzie nasze pliki są przechowywane. Następnie, wielu użytkowników na świecie wysyła żądania o te pliki i oczywiście wszystkie kierowane są do ‘źródła’ czyli do naszego wiadra S3. Z uwagi na duże odległości użytkowników od miejsca, gdzie dane są przechowywane, czas dostarczania plików może być odczuwalny.

A teraz spójrzmy, jak wygląda ta sama sytuacja, ale z wykorzystaniem CloudFronta. Na zdjęciu poniżej, możemy zobaczyć, że żądania użytkowników nie są już kierowane do źródła (czyli w naszym przypadku bucketu S3), ale do najbliższej lokalizacji brzegowej (pierwsze z żądań spowoduje wysłanie żądania w ramach sieci wewnętrznej AWS do źródła i pobranie go do punktu brzegowego). Możemy zatem spodziewać się zdecydowanie szybszego dostarczania plików dla użytkowników.

Bezpieczeństwo

Często okazuje się również, że chcemy zapewnić, że tylko określone osoby będą miały dostęp do danych, które udostępniamy w Internecie. CloudFront zapewnia wiele dodatkowych mechanizmów bezpieczeństwa, które możemy wykorzystać, aby je zaimplementować. Po pierwsze wykorzystuje się wówczas tzw. OAI (ang. Origin Access Identity), który będzie gwarantował, że dostęp do naszych danych w S3, jeśli możliwy jedynie z wykorzystaniem CloudFronta. Kolejnym etapem będzie już wykorzystanie funkcjonalności CloudFronta, tzw. jak Geo-Restrictions (czyli wskazanie krajów, z których użytkownicy (nie)mogą pobierać plików), linków tymczasowych i reguł WAF (ang. Web Application Firewall).

Zaczynamy!

Aby przetestować wykorzystanie CloudFronta oraz S3 przygotowaliśmy szablon CloudFormation, dzięki któremu szybko będziecie mogli przetestować tezę tego postu. Szablon ten utworzy nowy bucket S3 oraz skonfiguruje odpowiednio usługę CloudFormation. Postępują według kroków poniżej opisanych.

  1. Kliknij na przycisk Launch Stack poniżej. Przeniesie Cię on wówczas do usługi CloudFormation (potencjalnie będziesz musiał najpierw zalogować się do swojego konta AWS). Zasoby, których będziemy używać zostaną uruchomione w regionie N. Virginia (us-east-1).
  1. Przejdź do procesu uruchamiania szablonu i wybierz opcję Create. Proces powoływania zasobów powinien zająć około 15 minut. W tym czasie spokojnie możesz zrobić sobie przerwę na kawę 🙂
  2. Po tym jak status ulegnie zmianie na CREATE_COMPLETE, wybierz swój stack a następnie zakładkę Output. Jeden z parametrów widocznych na ekranie będzie nazwą twojego bucketu S3 (S3BucketName) – zapamiętaj je, ponieważ będzie Ci ono potrzebne później. Zapisz również wartość parametru CfDistributionDomainName.
  1. Następnie przejdź do usługi S3, gdzie powinieneś zobaczyć wiaderko S3, które zostało utworzone przez usługę CloudFormation (nazwa z poprzedniego punktu). Wejdź do tego bucketu, a następnie załaduj do niego jakiś przykładowy obrazek. W moim przypadku załaduję plik o nazwie image.jpg.
  1. Po załadowaniu pliku, mogę spróbować skopiować adres HTTPS tego pliku i wejść na niego w przeglądarce (ty również to sprawdź). Jeśli wszystko przebiegło pomyślnie, powinniśmy zobaczyć błąd jak poniżej. Błąd w tym przypadku był oczekiwany i prawidłowy! Oznacza to, że mechanizm OAI zadziałał i dostęp do plików z pominięciem CloudFront nie jest możliwy.
  1. Następnie spróbuje ponownie otworzyć plik, ale tym razem wykorzystując CloudFronta. Zastąp początek adresu, adresem dystrybucji CloudFront, skopiowanym w kroku 3. Jeśli wszystko przebiegnie pomyślnie powinieneś zobaczyć swoje zdjęcie. W moim przypadku ujrzałem taki widok (mój pies, który wabi się Java).

Jak widzisz, w ciągu zaledwie kilku minut udało nam się utworzyć bucket S3 I „przykryć” go dystrybucją CloudFront. Ale czy było warto? Sprawdźmy czy rzeczywiście czas ładowania naszego obrazka został skrócony – w tym celu przeprowadzimy testy z różnych lokalizacji na świecie (możecie wykorzystać wiele darmowych narzędzi w Internecie aby powtórzyć ten test).

W moim przypadku, przeprowadziłem testy z 3 lokalizacji: Szwecja (Sztokholm), USA (Nowy Jork) oraz Australia (Melbourne). Pamiętajcie, że moim źródłem był bucket S3 zlokalizowany w USA (N.Virginia). W celu zweryfikowania i porównania szybkości ładowania obrazka utworzyłem drugi bucket S3 w tej samej lokalizacji, gdzie umieściłem ten sam obrazek, ale tym razem nie „przykryłem” go CloudFrontem.

Diagramy poniżej prezentują czasy ładowania obrazka z różnych lokalizacji. Na niebiesko testy drugiego bucketu, bez wykorzystania CloudFronta, natomiast na zielono – testy z wykorzystaniem CloudFronta.

Jak widzicie, w każdej lokalizacji przeprowadziłem 4 testy. Pierwszy test, to pierwsze żądanie, jak można się spodziewać, nie jest ono na ogół dużo szybsze, z uwagi, że mamy do czynienia wówczas z brakiem pliku w punkcie brzegowym. Kolejne testy wykorzystują już jednak fakt, że nasz plik został zapisany w punkcie brzegowym, dzięki czemu czas dostarczania obrazka skrócił się wielokrotnie przy niektórych lokalizacjach.

Mam nadzieje, że sami przyznacie, że cały proces konfiguracji takiej architektury był prosty a jednocześnie zalety wykorzystania S3 oraz CloudFronta są bardzo zauważalne. Zatem pamiętajcie, jeśli udostępniacie dane statyczne na świat to wykorzystujcie S3, a jeśli wykorzystujecie S3 to wykorzystujcie CloudFront!

: CloudFormation, CloudFront, Content Delivery Network, OAI, Origin Access Identity, Point of Presence, s3, serverless, WAF, Web Application Firewall
Tomasz Stachlewski
Architekt systemów IT na Polskę dla Amazon Web Services. Na co dzień doradza klientom w tworzeniu architektur systemów, które mają zostać zmigrowane lub utworzone w chmurze AWS i w pełni wykorzystywać możliwości jakie niesie ze sobą chmura. Doradza wielu wiodącym firmom (począwszy od startupów po korporacje) z różnych branż m.in. IT, telekomunikacja, finanse. Prowadzi szkolenia dla polskich i zagranicznych partnerów podczas których przekazuje w jaki sposób firmy powinny korzystać z chmury, jak powinna wyglądać ich droga z tradycyjnej infrastruktury do infrastruktury chmurowej, aby zmaksymalizować korzyści z tego płynące. Absolwent informatyki na Politechnice Łódzkiej oraz studiów podyplomowych z zarządzania projektami na SGH.

Related Articles

CloudFormation i StackSets, łatwe zarządzanie na dużą skalę

13 września 2017Łukasz Dorosz

Ochrona przez atakami DDoS w chmurze AWS

21 lutego 2017Tomasz Stachlewski

Wiosenne porządki z AWS Glue cz.2

22 czerwca 2018Piotr Pietrzkiewicz

Najnowsze wpisy

  • Wiosenne porządki z AWS Glue cz.3 4 września 2018
  • Jak przyśpieszyć ładowanie zawartości stron WWW? 28 czerwca 2018
  • Wiosenne porządki z AWS Glue cz.2 22 czerwca 2018

Szkolenia AWS

  • Kursy wprowadzające
  • Dla Architektów
  • Dla Developerów
  • SysOps
  • DevOps
  • Big Data
  • Bezpieczeństwo

ACTION Centrum Edukacyjne

Znajdź nas na:

Facebook
LinkedIn
YouTube
RSS

Copyright by ACTION Centrum Edukacyjne Sp. z o.o.