Scott Tiger Tech Blog

Blog technologiczny firmy Scott Tiger S.A.

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)

Chmury obliczeniowe

Prezentowany tu materiał pochodzi z prezentacji firmowej z dnia 11.I.2012.
Ostatnia zmiana 15 stycznia 2012.

Co to jest?

U podstaw chmury obliczeniowej nie leży technologia, lecz ekonomia i modele biznesowe. W obecnych firmowych centrach danych działają takie same serwery, systemy operacyjne i aplikacje jak te, które pracują w chmurze.

Na najwyższym poziomie chmurę obliczeniową można zdefiniować jako usługi oferowane przez zewnętrzne podmioty i dostępne na życzenie w dowolnym momencie, skalujące się dynamicznie w odpowiedzi na zmieniające się zapotrzebowanie. Chmura stwarza iluzję nieskończonych zasobów dostępnych na żądanie. Sednem rewolucji jest możliwość skalowania bez ponoszenia nadmiarowych kosztów. W ten sposób moc obliczeniowa docelowo staje się zasobem, usługą komunalną taką jak prąd czy woda.

Oto pięć podstawowych zasad przetwarzania w chmurze (publicznej):

  • Pula zasobów dostępna dla każdego kto ma kartę kredytową. Nie trzeba tracić czasu na negocjowanie umów z zewnętrznymi firmami.
  • Wirtualizacja w celu maksymalizacji wykorzystania sprzętu. Wirtualizacja ma kluczowe znaczenie dla chmury, ponieważ skala infrastruktury jest przeogromna, oparta na tysiącach serwerów.
  • Elastyczność: dynamiczne skalowanie. Jest to pojęcie o tak kluczowym znaczeniu, że Amazon postanowił nazwać swoją chmurę Amazon Elastic Computer Cloud.
  • Automatyzacja: budowanie, wdrażanie, konfiguracja, zabezpieczanie i przenoszenie bez konieczności ręcznej interwencji.
  • Naliczanie opłat: model biznesowy zależny od realnego użycia — nie płacisz za niewykorzystane zasoby. Z reguły zasoby są przydzielane i rozliczane godzinowo. Jeśli aplikacja nie zyska znienacka oszałamiającej popularności, koszty jej utrzymania pozostaną niskie. W przypadku przechowywania danych w chmurze z reguły płacisz za ilość przesyłanych danych oraz, co jakiś czas, za zajmowane przez nie miejsce.

Skalowalność w chmurze to zdolność platformy do obsłużenia zwiększonej liczby użytkowników korzystających z aplikacji. Elastyczność to zdolność skalowania w górę lub w dół bez przerywania normalnego działania aplikacji. Bez elastyczności przeniesienie aplikacji i działalności firmy w chmurę byłoby nieopłacalne. W chmurze EC2 możesz skonfigurować aplikację np. mówiąc, że ma otrzymać dodatkową jedną instancję, gdy średnie wykorzystanie procesora przekroczy 80%, a jedna instancja może zostać odjęta, gdy wynik ten spadnie poniżej 40% na dłużej niż 10 minut. Typowe dla chmury jest stawianie na żądanie gotowej do pracy instancji w ok. 20 sekund, co pozwala reagować na zmiany zapotrzebowania właściwie w czasie rzeczywistym.

Pierwszy raz pojęcia „chmura” w dzisiejszym znaczeniu użyli Gillet i Kapor w 1996 r. w artykule wydanym przez MIT Press (wywodzi się ono z faktu, że przez ponad dekadę osoby projektujące architektury aplikacji związanych z internetem z reguły przedstawiały go jako chmurę), a pierwszą instancję chmury utworzył Amazon w połowie 2007 r. Tym niemniej, podwaliny technologiczne pod model przetwarzania w chmurze kładziono przez ostatnie 40 lat. Pojęcie wirtualizacji było znane już na mainfraimach IBMa w latach 60-tych, a w latach 90-tych przeniesiono tą ideę na ogólnodostępny sprzęt, wykorzystując możliwości wielordzeniowych procesorów. W 1976 r. superkomputer Cray-1 wart 5 mln dolarów potrafił wykonać 150 milionów operacji zmiennoprzecinkowych na sekundę, co oznacza że 1 MFLOP kosztował 33 tys. dolarów. Typowy współczesny czterordzeniowy procesor w komputerze PC wart mniej niż tysiąc dolarów wykonuje 50 GigaFLOPS, co daje koszt 0,02 dolara za 1 MFLOP. Na początku lat osiemdziesiątych jeden megabajt przestrzeni dyskowej kosztował ponad 200 dolarów, teraz to mniej niż 0,01 dolara.

Ze wszystkich technologii wykorzystywanych w chmurze to wirtualizacja i jej udane wdrożenie zadecydowały o przyjęciu się nowego trendu. Bez wirtualizacji i umożliwianego przez nią zużycia procesora wynoszącego ponad 60% chmura nie byłaby opłacalna. Szacuje się, że przeciętny serwer w firmowym centrum danych jest wykorzystywany w ok. 6% i nawet w chwilach maksymalnego obciążenia wykorzystanie nie przekracza 20%, a w najlepiej zarządzanych centrach danych serwery wykorzystują średnio ok. 15% swoich możliwości. Jednak gdy takie centra zdecydują się na pełną wirtualizację, wykorzystanie mocy procesora wzrasta do 65% i więcej.

Strona programistyczna chmury to SOA (ang. Service-Oriented Architecture) oraz SaaS (ang. Software as a Service). SOA ułatwia tworzenie rozproszonych komponentów i ich składanie do postaci aplikacji, natomiast model SaaS zakłada że aplikacji nie kupujemy, lecz wynajmujemy — przychód uzyskany dzięki oprogramowaniu jest proporcjonalny do wydanych na nie pieniędzy.

Klasyfikacja

Chmury obliczeniowe można klasyfikować na różne sposoby. Tutaj potraktujmy usługi przetwarzania w chmurze jako „X jako usługa” (XaaS), przy czym za X można podstawić: sprzęt, infrastrukturę, platformę, framework lub aplikację.

Klasyfikacja warstw chmury: różne typy do różnych zastosowań
Wsparcie chmury
Infrastruktura i usługi pozwalające „skleić” system w działającą całość
Oprogramowanie jako usługa (SaaS)
Zapakowana aplikacja (najstarsze wcielenie chmury)
Przykłady: GMail, Google Docs
Framework (szkielet) jako usługa (FaaS)
Środowisko do tworzenia modułów dla systemu ERP
Platforma jako usługa (PaaS)
Środowisko do tworzenia za pomocą IDE i uruchamiania w kontenerze zarządzanej aplikacji z bogatymi bibliotekami klas.
Tylko konkretne języki programoania (np. Java/Python).
Przykłady: Google AppEngine, Microsoft Azure
Infrastruktura jako usługa (IaaS)
Środowisko do tworzenia natywnych aplikacji
Synonim: HaaS (Software as a Service)
Przykład: EC2
Obrazy różnych OSów, przestrzeń dyskowa, łącza sieciowe

Porównywanie dwóch chmur należących do różnych typów nie ma większego sensu. Częstym powodem wejścia jakiegoś dostawcy chmury publicznej na rynek jest chęć spożytkowania nadmiaru sprzętu niewykorzystywanego aktualnie do operacji handlowych (w przypadku Google chodzi o wyszukiwarkę, a Amazona — sklep internetowy).

Amazon EC2: IaaS

Wśród największych istniejących chmur EC2 jest chmurą najogólniejszego typu. Ma ona najmniejsze wsparcie automatyczne dla skalowania i korekty błędów — te wymagania musi obsłużyć sama aplikacja. Ale za to programista może wybrać dowolny język programowania i ma pełną kontrolę nad aplikacją (dostaje odpowiednik fizycznej maszyny, na której można zainstalować system i wszystkie inne wymagane elementy). Ceny EC2 zaczynają się od paru centów za godzinę używania procesora niewielkiej instancji linuksowej, najdroższe instancje to koszt ok. pół dolara za godzinę. Ceny S3 (magazynowanie danych) zaczynają się od 15 centów za 1GB na miesiąc. Im więcej przestrzeni wykorzysta użytkownik, tym mniejsza cena za 1GB.

Wybierz EC2 jeśli:

  • chcesz używać istniejącego oprogramowania open source,
  • masz już część kodu,
  • chcesz na późniejszym etapie przenieść aplikację internetową na własną maszynę lub własne serwery,
  • przenosisz kod do innego języka,
  • chcesz pełnej kontroli,
  • chcesz przeprowadzić testy obciążeniowe i sprawdzić skalowalność (np. na tysiącu instancji).

Olbrzymią zaletą EC2 jest fakt, że narzędzia opensource’owe takie jak Eucaliptus czy OpenNebula, pozwalające utworzyć własną chmurę, są zgodne pod względem interfejsu z EC2, co pozwala łączyć chmury ze sobą (tworzyć chmury hybrydowe), o czym będzie jeszcze mowa. EC2 jest niekwestionowanym liderem, który mocno wpływa na standardy, posiada już ponad 500 tysięcy klientów.

Microsoft Azure: IaaS

Ta chmura oferuje również sporo usług na poziomie PaaS. Daje się zauważyć trend Microsoftu do przenoszenia w chmurę aplikacji dostępnych na desktopach. Windows Azure to system Windows Server 2008 zmodyfikowany pod kątem pracy w chmurze. Mamy tutaj składowanie plików i środowisko programistyczne (platforma .NET) pozwalające emulować Azure na własnych maszynach — wystarczy wdrożyć aplikację na własnym laptopie i zduplikować instancje w chmurze.

Wybierz Azure jeśli:

  • i tak wykorzystujesz już .NET i SQL Server,
  • Twój zespół jest przyzwyczajony do programowania w C# w Visual Studio,
  • nie przeszkadza Ci bycie uzależnionym od produktów firmy MS.

Google AppEngine: PaaS

Nie jest to chmura ogólnego przeznaczenia — służy do wdrażania tradycyjnych aplikacji internetowych, które są zmuszane do wyraźnego oddzielenia bezstanowej warstwy obliczeniowej od stanowej warstwy danych. Nie zainstalujesz tu własnego oprogramowania opensource. Języki programowania dozwolone w App Engine to Python i Java 6 (serwlety). Najlepiej sprawdza się w przypadku aplikacji internetowych o strukturze żądanie-odpowiedź, w których pomiędzy wywołaniami występują długie okresy bez używania procesora (przykładowo użytkownik zastanawia się nad wyborem opcji). Google surowo racjonuje czas korzystania z procesora przeznaczony do obsługi każdego z żądań. Aplikacje działają w piaskownicy niezależnej od sprzętu, systemu operacyjnego i fizycznej lokalizacji, zapewniającej jedynie ograniczony dostęp do usług systemu operacyjnego. To pozwala App Engine na rozpraszanie żądań wysyłanych do aplikacji na wiele serwerów, uruchamianych i zatrzymywanych stosownie do zmieniającego się zapotrzebowania.

Pierwszych 6,5h czasu procesora i 1 GB przesyłanych w obie strony danych są darmowe. Po przekroczeniu tych progów za transfer płaci się 0,1 dolara za 1GB, czas procesora kosztuje 0,10 dolara za godzinę, a składowanie danych 0,15 za 1 GB na miesiąc.

Wybierz AppEngine jeśli:

  • nie masz jeszcze kodu,
  • tworzysz aplikację internetową żądanie-odpowiedź lub hybrydową aplikację typu mashup,
  • priorytetem jest dla Ciebie jak najszybsze dotarcie z aplikacją na rynek,
  • nie robisz nic wymyślnego (tzn. nie instalujesz oprogramowania),
  • nie przeszkadza Ci bycie uzależnionym od produktów Google.

Centra danych

Niezależnie od typu, chmura potrzebuje:

  • serwerów sieciowych zgromadzonych w fizycznej lokalizacji — centrum danych,
  • API do zamawiania nowych serwerów, wysyłania i pobierania danych, uruchamiania i zatrzymywania aplikacji, zwalniania niepotrzebnych zasobów — zwykle jest ono oparte o HTTP (SOAP, REST).
  • miejsca do składowania danych,
  • bazę danych — większość aplikacji potrzebuje ustrukturyzowanych danych

Centrum danych Google w Dalles

Dostawcy chmur inwestują w olbrzymie centra danych, kosztujące po 500 mln dolarów i więcej (w 2008 roku Google wydał na budowę centrów danych 2,3 mld dolarów). Korzysta się tam z kontenerów po tysiąc lub więcej serwerów każdy. Jeśli potrzebna jest naprawa lub aktualizacja, wymienia się cały kontener, a nie poszczególne serwery. Maszynownie napędzające chmurę są dziś odpowiedzialne za więcej niż 1,2% całkowitego zużycia energii w USA.

Kluczowe dla zrozumienia biznesowego modelu chmury jest wykorzystywanie przez centra danych efektu skali. Dzięki olbrzymim zamówieniom na sprzęt i energię, jak również strategicznemu sytuowaniu centrów w pobliżu elektrowni, operatorzy centrów danych mogą liczyć na duże upusty — nie 10% czy 15%, lecz np. 60% i więcej. Na przykład w 2008 roku Amazon zapłacił ok. 90 mln dolarów za 50 tys. serwerów firmy Rackable/SGI — w normalnym handlu kosztowałyby one 215 mln dolarów. Często wykorzystywana jest infrastruktura pozostała po firmach, które zbankrutowały gdy w 2001 r. pękła bańka internetowa.

Bechtel to duża firma budowlana zatrudniająca ponad 40 tysięcy pracowników, działająca w ponad 50 krajach. Jej prezes dokonał porównania:

  • YouTube płaci 50 razy mniej za Mb/s miesięcznie niż Bechtel,
  • Amazon pobiera od klientów 15 centów za gigabajt składowanych danych — Bechtel za tę samą ilość płaci 3 dolary i 75 centów,
  • w Google jeden administrator utrzymuje 20 tysięcy serwerów, w Bechtel — tylko 100.

Google polega na tanich komputerach ze zwykłymi procesorami wielordzeniowymi, wypatroszonymi ze wszystkich zbędnych elementów takich jak karty graficzne. Wprowadza się mechanizmy optymalizujące pobór prądu, wentylatory o zmiennej prędkości czy obniżanie napięcia i częstotliwości zegara procesora w pewnych okresach.

Średnie opóźnienie w przesyłaniu pakietów ok. 15 razy większe w przypadku komunikacji z chmurą w porównaniu z siecią lokalną, jest poważnym ograniczeniem. Aby je zredukować, w praktyce dostawcy chmury pozwalają wybrać lokalizację fizyczną zasobów obliczeniowych (np. Europa, Bliski Wschód lub USA).

Chmury prywatne

Chmury prywatne (wewnętrzne, korporacyjne, firmowe) to półśrodek który pozwala wykorzystać zalety chmury bez obawy o bezpieczeństwo wrażliwych danych. Poza tym duże firmy często dysponują znacznymi zasobami obliczeniowymi, które chcą wykorzystać.

Niestety, nie jest to najszczęśliwsze rozwiązanie. Weź pod uwagę takie argumenty:

  • nawet duże korporacje będą miały problem z osiągnięciem takiego efektu skali (a więc i zniżek u dostawców sprzętu i energii), które cechują chmury publiczne,
  • istniejące aplikacje trudno przekształcić do postaci chmurowej — prawdziwe zyski przynosi tylko zmiana architektury aplikacji,
  • to że serwer stoi na terenie firmy nie oznacza jeszcze że dane są bezpieczne: Google czy Amazon mogą mieć większe doświadczenie w radzeniu sobie z atakami hakerskimi, zaszyfrowane dane w chmurze publicznej mogą być bezpieczniejsze niż niezaszyfrowane w chmurze prywatnej, budynki firmowe nie mają zwykle dobrych generatorów prądu na wypadek awarii,
  • chmury prywatne zawsze będą o krok do tyłu pod względem innowacyjności: Google czy Amazon po prostu żyją z tego co robią.

Paradoksalnie jednym z powodów tworzenia chmur prywatnych może być gwarancja dostępności. Pula publiczna nie gwarantuje przydziału zasobów gdy potrzebujesz ich naprawdę dużo. Np. pod koniec 2009 roku Amazon ostrzegł użytkowników, że nie jest w stanie zagwarantować dostępu do 500 instancji XL (wysokowydajne zasoby obliczeniowe z ośmioma wirtualnymi procesorami) w dowolnym momencie z określonej strefy dostępności. Przypadki wymagające zastosowania więcej niż tysiąca instancji XL należy zgłaszać z tygodniowym wyprzedzeniem w celu zwiększenia szansy na dostępność zasobów. Dla porównania zauważmy, że przemysł energetyczny, rozwijany od ponad wieku, nadal ma problemy z dostawami w okresie letnim, gdy zapotrzebowanie zwiększa się m.in. z powodu działających systemów klimatyzacji.

Dość ciekawym praktykowanym rozwiązaniem jest tzw. wirtualna chmura prywatna (VPC, ang. Virtual Private Cloud), czyli rozwiązanie hybrydowe oferowane m.in. przez Amazon: pozwala na spięcie chmury prywatnej i publicznej za pomocą VPN, aby w razie brakujących zasobów prywatnych uzupełnić je zasobami publicznymi — takie zjawisko nazywamy oberwaniem chmury, ang. cloudbursting. Pomyśl o cloudburstingu jak o niespodziewanych gościach — nie kupujesz większego domu, tylko umieszczasz nadkompletowe jednostki w pobliskim hotelu. Odpowiednikiem tego rozwiązania w przypadku Google jest Secure Data Connector. Jednym z nietypowych zastosowań VPC jest odzyskiwanie prywatnego centrum danych po awarii — bywa że potrzebne jest do tego drugie centrum danych, np. w chmurze publicznej, które przechowuje kopię bezpieczeństwa.

Przykładem chmury prywatnej na dużą skalę jest chmura rządowa USA. Celem tej inicjatywy jest zmniejszenie kosztów utrzymania rządowych centrów danych przy jednoczesnym utrzymaniu wysokiego poziomu bezpieczeństwa. Dyrektor działu informatyki w amerykańskim sektorze rządowym Vivek Kunda wygłosił deklarację: „Potrzebny jest nam nowy model, zmniejszający koszty, a zwiększający innowacyjność. Rząd powinien rozwiązywać problemy, a nie prowadzić centra danych.” W tej chwili zaleca się wdrażanie w chmurze publicznej aplikacji, które nie są utajnione, w celu zmniejszenia kosztów.

W XVII wieku, aby zapewnić sobie energię, gospodarstwa budowały prywatne koła wodne zasilające np. młyn. Wraz z postępami elektryfikacji takie inwestycje przestały być na ogół opłacalne, choć w dalszym ciągu generatory prądu bywają używane w wojsku, szpitalach czy na statkach. Analogicznie, można się spodziewać, że za mniej więcej 10 lat nadal będą istniały chmury prywatne, ale będzie ich coraz mniej.

Bazy danych

eBay

  • Ponad 89 mln aktywnych użytkowników na całym świecie
  • 190 mln przedmiotów wystawionych na sprzedaż w 50 tys. kategorii
  • Ponad 8 mld żądań URL dziennie
  • Setki nowych funkcjonalności co kwartał
  • Około 10% przedmiotów jest dodawanych lub sprzedawanych każdego dnia
  • 39 krajów, 10 języków
  • Wymagane działanie 24 godziny na dobę przez 365 dni w roku
  • 70 mld operacji odczytu i zapisu dziennie
  • 50 TB nowych danych każdego dnia
  • 50 PB danych analizowanych każdego dnia

Relacyjne bazy danych i skalowalność to pojęcia które niestety kłócą się ze sobą. Dwa podstawowe problemy to zbyt duże zbiory robocze (cache nie mieści się w pamięci żadnego pojedynczego komputera) i zbyt wiele operacji zapisu, na które nie pomaga już używanie macierzy RAID. Ograniczenia RDBMSów powodują, że nie najlepiej sprawdzają się podczas przetwarzania dużych objętości danych w bezprecedensowej współczesnej skali (np. skrzynka odbiorcza Facebooka ma 50 TB, a dane o wszystkich aukcjach portalu eBay to ok. 2 TB). Bazy danych, w przeciwieństwie do nowych serwerów, nie mogą być dostarczane na żądanie, a sprawa migracji danych i równoważenia obciążenia wygląda dość kiepsko. Odpowiedzią na to są nierelacyjne bazy danych, które na ogół mają prostą strukturę (często ograniczają się do przechowywania par klucz-wartość), skalują się horyzontalnie, często nie wymagają sztywnych schematów danych (czy może inaczej: dają słabe gwarancje spójności, którą trzeba implementować w wyższych warstwach oprogramowania, podobnie jak np. transakcje). Wszystkie dane rekordu przechowywane są w nim, a nie w tabelkach słownikowych, co pozwala uniknąć operacji łączenia tabel (ang. join), i jest oczywistym złamaniem reguł obowiązujących w relacyjnych bazach danych (w szczególności postaci normalnej danych).

Proces dzielenia bazy danych pomiędzy wiele maszyn przyjęło się nazywać shardowaniem.

Zarówno Amazon jak i Google zaproponowały nierelacyjne systemy bazodanowe oparte na parach klucz-wartość (odpowiednio SimpleDB i BigTable), własne systemy na swój użytek opracowały też Facebook, Flickr!, Friendster, Yahoo! i Wikipedia, istnieje kilka noSQLowych baz danych opensource (np. Redis, Riak czy Apache Cassandra), ale niestety trudno mówić o jakimś standardzie i tak naprawdę jesteśmy w początkowych fazach rozwoju. Najlepszą strategię shardowania można wyznaczyć dopiero po uważnym przeanalizowaniu wzorców zachowań i zapytań użytkowników. Taka baza jest zoptymalizowana pod kątem pewnego zbioru spodziewanych zapytań.

Przekształcenie istniejącej aplikacji tak, by wykorzystywała jedną z chmurowych baz danych, jest albo trudne, albo całkowicie niewarte wysiłku. Lepiej jest w przypadku aplikacji, które już teraz korzystają z frameworków ORM (ang. Object-Relational Mapping, mapowanie obiektowo-relacyjne), takich jak np. Hibernate w Javie.

Niestety olbrzymią wadą noSQLowych baz danych jest utrudniona lub niemożliwa analityka. W przypadku relacyjnych baz danych możemy konstruować dość dowolne zapytania z uzasadnioną nadzieją że wykonają się w sensownym czasie. W bazach noSQLowych wydajność wykonania nieprzewidzianego przez konstruktora bazy zapytania może być beznadziejna.

Kolejnym problemem nowego podejścia do baz danych jest równoważenie obciążenia, wymagające przenoszenia danych pomiędzy shardami — gdy odbywa się to podczas działania bazy, przypomina wymianę koła w pędzącym samochodzie. Odwołania do danych muszą przechodzić przez pewnego rodzaju usługę nazw — ceną jest dodatkowe komplikowanie systemu (takie rozwiązanie zastosował m.in. Google w BigTable).

Ze shardowaniem często związane jest zagadnienie duplikowania danych, zarówno aby uodpornić system na awarię, jak też np. wyłączyć wybrane serwery aby zaktualizować ich oprogramowanie. Przykładowo w serwisie Flickr komentarz pod zdjęciem jest duplikowany i trzymany zarówno na koncie osoby komentującej, jak i komentowanej.

Flickr

  • Ponad 4 mld zapytań dziennie
  • Ok. 35 mln zdjęć w pamięci podręcznej Squid (serwer pośredniczący, na wolnej licencji),
  • Ok. 2 mln zdjęć w pamięci RAM obsługiwanej przez Squid
  • Ok. 470 mln zdjęć, każde w 4 lub 5 rozmiarach
  • 38 tys. żądań do Memcached (system buforowania pamięci podręcznej, na wolnej licencji) na sekundę
  • 2 petabajty danych,
  • Ok. 400 tys. nowych zdjęć dziennie.

Analiza biznesowa

Wdrożenie w chmurze ma sens gdy:

  • aplikacja ma działać tylko przez krótki, z góry określony czas,
  • prawdopodobne są znaczące zmiany w obciążeniu (np. dla typowej aplikacji obracającej finansami i akcjami obciążenie w porze otwarcia i zamknięcia rynku wzrasta ok. 4-krotnie w porównaniu z momentami przestoju, a dla sklepów internetowych w okresie przedświątecznym ten współczynnik może wynieść nawet 20); nawet strona firmowa ma w chmurze sens biorąc pod uwagę rozwój firmy,
  • chodzi o zapasowe kopie danych,
  • chcemy uruchomić wirtualne laboratorium testowe.

Zauważ, że chmura jest świetna dla startupów, które mają pomysł, nie chcą ponosić ryzyka związanego z zakupem sprzetu i całej infrastruktury, a płacić tylko za wykorzystane zasoby obliczeniowe — niewielka strata gdy pomysł nie wypali. Kolejnym zdecydowanie wartym zwrócenia uwagi zastosowaniem chmury jest użycie jej jako platformy testowej. Możemy tutaj zrównoleglać nie tylko testy jednostkowe czy obciążeniowe, ale również uruchamiać całe farmy przeglądarek testujących interfejs użytkownika. Narzędzia do ciągłej integracji takie jak Hudson potrafią już wyekspediować część testów do chmury publicznej gdy zorientują się że zaczyna brakować zasobów obliczeniowych w sieci lokalnej.

Z kolei nie warto myśleć o chmurze gdy:

  • chodzi o aplikację działającą starego typu, zwłaszcza chodzącą na systemach takich jak VMS czy HP-UX (trzeba taką aplikację zaprojektować i przepisać na nowo),
  • mamy do czynienia z krytycznymi scenariuszami czasu rzeczywistego — chodzi nie tylko o opóźnienia w transferze danych, ale nawet o prozaiczny dostęp do Internetu, którego może zabraknąć np. z winy TP SA,
  • aplikacja obsługuje wrażliwe lub poufne dane — często wręcz prawo zabrania wyekspediowania takich danych do publicznej chmury, np. w USA są to SOX — ustawa Sarbanesa-Oxleya, czy HIPAA — ustawa o przenośności i odpowiedzialności w ubezpieczeniach zdrowotnych. W wielu krajach istnieją przepisy zmuszające dostawców oprogramowania do zachowania w granicach kraju danych klientów oraz materiałów objętych prawami autorskimi.

Najbardziej oporne w atakowaniu chmury są wielkie korporacje, gdzie opór psychologiczny jest największy. Tym niemniej i tu zdarzają się przypadki takie jak firmy farmaceutyczne wykorzystujące zasoby chmury do prac badawczo-rozwojowych.

Amerykańskie Archiwum Narodowe na żądanie gazety The Washington Post opublikowało dokument na temat codziennej działalności Hillary Clinton w latach 1993-2001, kiedy urzędował prezydent Bill Clinton. Dokument był w formie niskiej jakości pliku PDF o objętości 18 tys. stron i nie można było przeszukiwać. Starszy inżynier pracujący dla gazety użył oprogramowania OCR i zaproponował procedurę pozwalającą przetworzyć jedną stronę w 30 minut. Przeniósł ją do chmury, uruchomił 200 instancji EC2 i przetworzył cały dokument w 9 godzin. Gazeta opublikowała możliwy do przeszukania dokument 26 godzin po jego ogłoszeniu przez Archiwum Narodowe. Wykorzystano 1401 godzin pracy maszyn wirtualnych, co kosztowało 144 dolary (416zł). Dla porównania wykonanie kserokopii dokumentu kosztowałoby sześciokrotnie więcej.

Bezpieczeństwo i niezawodność

Dużo mówi się o fizycznym bezpieczeństwie centrów danych: autoryzowanym personelu wykonującym ściśle rejestrowane czynności, systemach wykrywających wtargnięcia, całodobowych patrolach, skanerach biometrycznych badających geometrię dłoni, a nawet klatkach do których wpadają nieproszeni goście. Padają i takie sformułowania, że centrum danych bywa lepiej zabezpieczone niż Fort Knox. Opisane praktyki są podstawą przyznania certyfikatu SAS 70 przez Amerykański Instytut Biegłych Rewidentów, co oznacza że dostawca wprowadził wystarczającą kontrolę wewnętrzną i dba o jej utrzymanie. Wiele nowych przepisów w USA wymaga korzystania z centrów danych certyfikowanych SAS 70 w aplikacjach obsługujących dane objęte tymi przepisami.

W elektronicznym dostępie do chmury publicznej stosuje się wszystkie znane i sprawdzone rozwiązania takie jak potwierdzanie tożsamości właściciela karty kredytowej za pomocą innego kanału (np. wpisanie dodatkowego hasła z telefonu komórkowego), opcjonalny ale zalecany mechanizm autentykacji wieloczynnikowej (RSA SecurID), szyfrowanie z użyciem pary kluczy publicznego i prywatnego (w tym certyfikaty X.509), wyliczanie skrótu MD5 dla wszystkich obiektów przechowywanych na dyskach w chmurze, domyślne ustawianie praw dostępu do danych wyłącznie dla właściciela, firewalle, SSH, izolowanie hostów tak by nie mogły podsłuchiwać komunikacji sieciowej przeznaczonej dla innych itp.

Ponieważ chmura składa się na ogół z taniego sprzętu, tworząc popularną aplikację w chmurze musisz przygotować się na awarie. Jest bardzo ważne, aby aplikacje wdrażane w chmurze składały się z luźno sprzężonych komponentów — można je wtedy szybko wdrażać, testować i wymieniać. Z pomocą przychodzi tu SOA i jej usługi sieciowe realizowane za pomocą HTTP. Wykorzystywanie SOA w nowotworzonych aplikacjach ułatwi ich późniejszą ewentualną migrację w chmurę.

Często do komunikacji między procesami różnych instancji używa się skalowalnych, niezawodnych, asynchronicznych kolejek, takich jak Amazon Simple Queue Service (SQS). Wiele różnych procesów może pobierać i wstawiać komunikaty z i do kolejki Amazon SQS w tym samym czasie bez wchodzenia sobie w drogę.

Aby uprościć tworzenie niezawodnych aplikacji, powstały frameworki takie jak Google’owy MapReduce. Wystarczy w konfiguracji zdefiniować dwie funkcje: dzielącą duże zadanie na mniejsze (operacja „map”) przed rozesłaniem ich do procesów podrzędnych, oraz zbierającą wyniki i przetwarzającą je (operacja „reduce”) przed wysłaniem do procesu nadrzędnego. Takie podejście pozwala łatwo wdrożyć typowe, dające się dobrze zrównoleglać zadania, jak np. wyszukiwanie w dokumentach określonego wzorca. Istnieje opensource’owa implmentacja tego wzorca, Hadoop.

Kwestie praktyczne

Dokumenty SLA (ang. Service Level Agreement, umowy o poziomie usług) publikowane przez dostawców chmury wyznaczają jakość ich usług w sposób kontraktowy. Dość typowe jest zarezerwowanie przez dostawców ok. 4 godzin w roku na prace konserwacyjne i związane z tym utrudnienia dla odbiorców. W razie niewywiązywania się ze zobowiązań, to na kliencie ciąży obowiązek wykrycia problemów i zgłoszenia żądania będącego podstawą do zadośćuczynienia. Na ogół jedyną formą zadośćuczynienia jakiej można się spodziewać, są zniżki na usługi w przyszłości (np. 5-15%, ew. „następny miesiąc za darmo”).

Warto poświęcić kilka centów za godzinę, aby wykupić usługę konsoli monitorującej zamówione zasoby, np. CloudWatch w Amazonie (patrz rys.).



Amazon CloudWatch

Przyszłość chmury

W miarę jak system operacyjny i przeglądarka stają się tym samym, znaczenie chmury wzrasta, ponieważ to ona musi zapewnić dom aplikacjom, które potrzebują niedostępnych w urządzeniu zasobów. Tymczasem rynek smartfonów powiększa się o ok. 30% rocznie, a tylko w ostatnim tygodniu grudnia 2011 r. pobrano ponad 1 mld aplikacji na smartfony i tablety.

Jak już zasugerowano wcześniej, w przyszłości zdecydowana większość zasobów obliczeniowych ulokowana będzie w chmurach publicznych. Szacuje się jednak, że potrzeba całej wymiany pokoleniowej (ok. 20 lat), aby stało się to faktem. Głównym powodem są opory psychologiczne — trudno sobie wyobrazić dyrektora/managera we współczesnej korporacji, który wyekspediuje wrażliwe dane do publicznej chmury i weźmie za to odpowiedzialność. Prawdopodobnie chmury prywatne stanowić będą krok przejściowy w tej ewolucji.

Jako że wykładanie dużych ilości na sprzęt nie będzie już potrzebne i geograficzna lokalizacja programistów przestanie mieć znaczenie, bardzo prawdopodobnym wydaje się scenariusz, w którym programiści spoza USA i Europy przeskoczą Zachód wygrywając chociażby ze względu na koszta.

10 prognoz na temat ewolucji

  • Chmura będzie tańsza, bardziej niezawodna, bezpieczniejsza i prostsza w użyciu (głosowanie portfelami).
  • Chmura stanie się motorem napędzającym wzrost firm, które wcześnie na nie przejdą.
  • Koszty dostawców chmury będą równe 25% kosztów ponoszonych przez firmowe centra danych.
  • Megacentra danych w chmurze w 2020 roku będą się składały z 500 tys. serwerów wartych miliard dolarów.
  • Do 2020 roku stosunek liczby administratorów do liczby serwerów u najlepszego dostawcy spadnie z 1:1000 do 1:10000.
  • Przyszłość chmury jest związana z oprogramowaniem open source.
  • Liderzy rynku wypracują pragmatyczne standardy. Rola lidera będzie należała do firmy Amazon.
  • Ostatecznie pojawi się standard ISO dla chmury. Póki co, ze względu na brak standardów dostawcy chmury silnie uzależniają od siebie klientów, a ci ryzykują mając świadomość że będą mieli problemy gdy dostawca zniknie z rynku.
  • Rząd amerykański będzie jedną z głównych firm w chmurze.
  • Model SaaS będzie się rozrastał. Usługi będą aktualizowane zgodnie z najlepszymi standardami (HTML5).

Literatura

The cloud at your service, J.Rosenberg, A.Matheos, Manning 2010.

Chmury obliczeniowe, 5.0 out of 5 based on 1 rating
Share and Enjoy:
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Śledzik
  • Blip
  • Blogger.com
  • Gadu-Gadu Live
  • LinkedIn
  • MySpace
  • Wykop

1 Komentarz do “Chmury obliczeniowe”

  1. Kuzniewski napisał(a):

    Wow, wielkie dzięki za to podsumowanie. W tak wyczerpujący i konkretny sposób działanie chmury obliczeniowej nie jest opisanie ani w Wikipedii, ani nawet na stronach dostawców tej usług!

Zostaw komentarz

XHTML: Możesz użyć następujących tagów: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>