Chmura obliczeniowa nie taka straszna. Wprowadzenie do Amazon Web Services

Chmura obliczeniowa. Pojęcie, które zna pewnie każdy Project Manager. Wszyscy bowiem korzystamy z dobrodziejstw chmury – Google Docs, Google Drive, Dropbox. Co innego natomiast hosting w chmurze –  pojęcie zdecydowanie bardziej enigmatyczne, wielu Project Managerów nie wie dokładnie, jak to działa, jak jest zabezpieczone i z czym to się w ogóle „je”.

Spróbujmy zatem rozwiać wątpliwości z tym związane na przykładzie największego dostawcy chmury IaaS, Amazon Web Services.

Bezpieczeństwo

Jeżeli chcemy, żeby nikt nieupoważniony nie miał dostępu do naszych danych, to zapewniamy, że nie istnieje serwerownia pilniej strzeżona, z tak dużymi rygorami bezpieczeństwa i chroniąca przed fizycznym dostępem do danych niż Amazon Web Services. Małe lokalne serwerownie na pewno nie są w stanie spełnić na takim samym poziomie standardów bezpieczeństwa. Co do dostępu zdalnego, AWS oferuje wiele narzędzi, pozwalających ograniczyć dostęp do serwera / aplikacji, używając takich funkcji jak:

1. AWS Identity and Acces Managment – najważniejsza funkcja, pozwalająca na zarządzanie użytkownikami i prawami dostępu do AWS.
2. AWS Key Managment Service – do przechowywania kluczy do szyfrowania
3. AWS CloudTrail – logowanie wszystkiego, co dzieję się z kontem w Amazonie
4. AWS Web Application Firewall – pozwala tworzyć reguły do blokowania ataków na stronę / aplikację

High Availability

W przypadku awarii naszego serwera dedykowanego, jeżeli nie mieliśmy usługi replikacji na drugiej identycznej maszynie, tak długo jak nie dostawimy fizycznie nowego komputera i nie odzyskamy danych z dysku, jesteśmy bez serwera – nie będzie działać. Jeżeli na jednym serwerze mamy kilka stron i aplikacji, to mamy duży problem – każda pojedyncza awaria spowoduje, że nie będą działać wszystkie strony i aplikacje tam umieszczone. Wiąże się to oczywiście z niedogodnościami i koniecznością odpowiadania przed klientami za niedostępność ich usług, za które płacą.

Zakup drugiej fizycznej maszyny, albo jej wynajmowanie, jest kosztem stałym, który jest bardzo wysoki i nie ma pewności, czy się zwróci. W Amazonie nie ma tego problemu – ustawiamy replikację i inne usługi możemy łatwo zdublować. Nie kupujemy fizycznych maszyn, koszty takiej infrastruktury są niższe niż dwóch działających równocześnie serwerów i mamy pewność, że niezależnie od okoliczności, nasze aplikacje będą zawsze dostępne.

Amazon posiada również możliwość przechowywania kopii danych w zupełnie innym fizycznym regionie – jeżeli jakieś dane są dla nas bardzo cenne, warto przemyśleć opcję używania innego regionu lub strefy dostępności wewnątrz regionu – nawet w przypadku katastrofy naturalnej nasze dane będą bezpieczne w innej części kontynentu / świata.

Koszty

Rozwiązania chmurowe wydają się drogie, ale popatrzmy na koszty fizycznego zakupu i utrzymania serwera. Zwykle to kilkadziesiąt tysięcy złotych, a jeśli chcemy mieć kopie w czasie rzeczywistym na drugim serwerze, mnożymy koszt razy dwa. Do tego musimy płacić za serwer niezależnie od tego, ile jego zasobów faktycznie wykorzystujemy. Jeżeli wszystkie nasze strony i aplikacje mają stały i przewidywalny ruch, nie będzie problemu z zasobami – ale tylko tak długo, dopóki nie będziemy chcieli dodać jakiejś nowej strony (wtedy trzeba zwiększyć zasoby serwera). Jeżeli natomiast będziemy chcieli wyłączyć jakąś stronę, wtedy przepłacimy za niewykorzystane zasoby.

W przypadku aplikacji i stron z trudnym do przewidzenia ruchem, musimy mieć maszynę dostosowaną do maksymalnego ruchu na naszej stronie, a przez większość czasu będziemy płacić za niewykorzystane zasoby. To najmniejsze z naszych zmartwień – największym jest ruch, którego nasz serwer nie jest w stanie obsłużyć, co powoduje wyczerpanie zasobów i brak dostępności wszystkich stron i aplikacji, które są dostępne na tej maszynie.

Skalowalność infrastruktury

W Amazonie nie mamy tego problemu. Ustawiamy jeden serwer z wybranymi zasobami. Jeżeli mamy większy ruch, możemy albo dostawić kolejne serwery (lub zaprogramować to automatycznie – wymaga to aplikacji mogącej korzystać z wielu maszyn), bądź też zwiększyć typ instancji, dodając jej zasobów.

Jeżeli aplikacja nie cieszy się takim ruchem, jaki przewidywaliśmy, możemy zmniejszyć zasoby serwera lub wygasić niepotrzebne instancje, ograniczając tym samym koszty. A nawiązując do kosztów samej maszyny – płacimy tylko za zasoby, z których korzystamy – nie ponosimy kosztów zakupu i modernizacji sprzętu.

Możliwość wydzielania usług poza serwer

Amazon Web Services to także ponad 70 różnych usług cloud computingowych i kilka tysięcy funkcjonalności. Wyobraźmy sobie sytuację, że uruchamiamy kilkanaście serwerów pod aplikację / stronę i chcemy, żeby te serwery nie zajmowały się niczym innym. Amazon udostępniam nam narzędzia, pozwalające wydzielić składowe systemu na zewnątrz serwera jako usługi, co zmniejsza zużycie zasobów serwera i pozwala zmniejszyć ryzyko awarii oraz ułatwia ustalenie, który element infrastruktury powoduje błędy.

RDS – (Relational Database Service) możemy „wyjąć” serwer bazy danych i uruchomić ją jako usługę. W zależności od potrzeb można zwiększać lub zmniejszać zasoby RDS, aby uzyskać odpowiednią wydajność. Dodatkowo, automatycznie mamy możliwość wykorzystania point in time recovery oraz replikacji między dwoma instancjami – co zmniejsza ryzyko awarii.

ELB – Elastic Load Balancer – usługa pozwalająca na rozdzielanie ruchu użytkowników / zapytań między serwery w zależności od ich obciążenia. Dzięki ELB możemy zaprogramować sobie dostawianie kolejnych serwerów, jeżeli obciążenie już działających maszyn przekroczy określony przez nas procent. ELB można zastosować do wielu różnych rzeczy – www, serwerów pocztowych, obsługi płatności i innych usług

Redis,  służy do przechowywania danych, przy których ważny jest szybki dostęp (zapis/odczyt), kosztem ewentualnej utraty danych – są przechowywane w pamięci RAM.

Chmura obliczeniowa  w praktyce

Teraz pokażemy na dwóch przykładach, jak AWS może usprawnić pracę, zapewnić HA i obniżyć koszty hostingu dla agencji interaktywnej.

Przykład 1:

Jeden z większych portali o tematyce medycznej – duża baza danych, dużo użytkowników, quiz na stronie, pojawiające się cyklicznie wpisy ekspertów i CMS, umożliwiający ekspertom odpowiedzi na pytania użytkowników.

Strona odwiedzana głównie w miesiącach wrzesień – marzec, na październik – grudzień przypada najwyższa ilość odsłon. W okresie wiosenno -letnim ruch jest znikomy. Strona „stała” na normalnej maszynie dedykowanej o bardzo wysokich parametrach, aby była w stanie utrzymać szczytowy ruch.

Przy przenosinach portalu do AWS i wyodrębnieniu bazy do RDS, przeniesieniu sesji do Redisa i wykorzystaniu 2-3 mniejszych maszyn pod serwer www i dorzuceniu ELB, nie dość, że znacznie redukujemy koszt w skali rocznej, to zapewniamy sobie możliwość przywracania bazy danych w dowolnym momencie (point in time recovery) i zyskujemy możliwość skalowania infrastruktury w sposób płynny. Przy mniejszym ruchu wygaszamy instancje i zostajemy na 1 małej instancji WWW (miesiące letnie i wakacyjne). W trakcie maksymalnego obciążenia automatycznie w godzinach szczytu dostawiają się serwery. W przypadku, gdy ruch spada, również automatycznie są one wygaszane – płacimy tylko za to, z czego realnie korzystamy.

Przykład 2:

Portal z branży zabawkowej – realizowany pod konkurs, który trwa od końcówki października do połowy stycznia. Przez pozostałe miesiące na stronie widnieje tylko „zaślepka”. W aplikacji użytkownicy generują treści, a wybrane z nich są nagradzane przez organizatorów. W pierwszym miesiącu ruch jest znikomy, ale przy wsparciu kampanii reklamowej, w grudniu przypada szczyt ruchu z bardzo dużą liczbą odwiedzin i odsłon, generowane są znaczne ilości danych przez odwiedzających.

Najprostsze rozwiązanie? Przez miesiące z zaślepką wystarczy najmniejsza możliwa instancja www, bez bazy danych obok (ponieważ nie jest ona potrzebna – zaślepka to zwykły html). W miesiącach początkowych 1 maszyna www + baza w RDS i zrzucanie materiałów tworzonych przez odwiedzających portal do S3. W grudniu na przodzie wystawiamy ELB + dostawiamy kilka instancji pod portal, zwiększamy instancje RDS, dodajemy Redisa w celu przechowywania sesji użytkowników w trakcie generowania przez nich contentu (zyskujemy na szybkości działania aplikacji), a pliki przez nich wygenerowane przerzucamy do S3.

Po raz kolejny zyskujemy pewność, ze dane użytkowników nie zginą ( cechą S3 jest bezpieczeństwo danych na poziome 99,999999%). Aplikacja chodzi szybko i stabilnie, dostosowując liczbę serwerów do aktualnego ruchu, a po zakończeniu całego eventu wracamy do 1 małego serwera www i w skali roku redukujemy koszt o około 30%.

Podsumowanie

Chmura nie zawsze będzie najlepszym rozwiązaniem, ale ze względu na swą elastyczność, może okazać się złotym środkiem w wielu projektach IT. Jako oficjalny partner Amazon Web Services, Hostersi pomagają we wdrażaniu i zarządzaniu chmurą obliczeniową. Chętnie podpowiemy i Tobie, jak stawiać pierwsze kroki w świecie cloud computingu.

Pytania? Skontaktuj się z nami

Zobacz również:

Chmura AWS na czas sprzedaży biletów na koncert Justina Biebera
Migracja do Amazon Web Services aplikacji Landingi.com
Hosting WordPress w chmurze AWS z pełną redundancją
Skąd się bierze wysoka dostępność (HA) w chmurze?
Amazon Web Services ma już 10 lat