Scott Tiger Tech Blog

Blog technologiczny firmy Scott Tiger S.A.

Archiwum: 'Cloud computing' Kategorie

Przegląd usług AWS c.d.

Autor: Piotr Karpiuk o 14. maja 2017

Z chmury Amazonu korzysta już ponad milion aktywnych klientów. Poniżej krótki opis co ciekawszych z przeszło 100 dostępnych obecnie usług AWS. Jest to uzupełnienie wcześniejszego artykułu na ten temat.

Moc obliczeniowa

AWS Lambda
Problem z instancjami EC2 jest taki, że kosztują nawet gdy nic nie robią i dodatkowo wymagają konfiguracji i pielęgnacji (choćby np. aktualizacji systemu operacyjnego). W AWS Lambda wrzucasz kod obsługujący zdarzenia — usługa sama podejmuje wszystkie czynności niezbędne do uruchomienia i skalowania kodu, nie wykonujesz działań administracyjnych. Płacisz jedynie za czas obliczeń – w szczególności nic gdy nie ma zdarzeń do obsłużenia. Zdarzenia mogą być wyzwalane z innych usług AWS lub z Internetu/aplikacji mobilnych/urządzeń IoT itp. Większość aplikacji i usług da się zaimplementować w architekturze Lambda.
Amazon EC2 Container Registry
Rejestr obrazów Dockera.
Amazon EC2 Container Service
Usługa zarządzająca kontenerami Dockera na klastrze instancji EC2.

Pamięć masowa

Elastic File System (EFS)
Sieciowy system plików, który w przeciwieństwie do EBS może być jednocześnie współdzielony przez wiele instancji EC2 i nie wymaga rezerwacji miejsca na dysku — płacisz za dokładnie tyle miejsca ile zapisałeś, a system plików rozrasta się praktycznie w nieskończoność w miarę jak zapisujesz kolejne pliki. Przy użyciu VPNa możesz podmontować wolumen EFS do swojej lokalnej sieci i traktować jak „wirtualny dysk w chmurze” o nieograniczonej pojemności, np. na użytek backupu.
AWS Storage Gateway
Pozwala w lokalnej serwerowni podmontować zasoby S3, Glacier i EBS Amazonu za pomocą protokołów NFS i iSCSI.

Czytaj więcej »

Tags:
Napisany w AWS, Cloud computing | Brak komentarzy »

Dokumentacja Chmury Amazona: wizualizacja

Autor: Piotr Karpiuk o 10. maja 2017

Jak duża jest dokumentacja chmury Amazona (AWS) i jak się mają do siebie – pod względem wysiłku potrzebnego do pełnego ogarnięcia – wielkości poszczególnych usług? Napisałem skrypt, który ściąga pliki PDF dokumentacji każdej usługi, zlicza strony każdego dokumentu (łącznie ponad 50 tys. stron!) i generuje wizualizację w postaci tzw. treemapy – pole powierzchni każdego prostokąta jest proporcjonalne do liczby stron dokumentacji na temat odpowiadającej mu usługi. Po najechaniu kursorem myszki nad prostokąt w dymku pokazuje się pełna nazwa usługi, jej krótki opis i liczba stron dokumentacji. Przy okazji można więc pobieżnie zaznajomić się z ofertą dostawcy chmury.

Patrz także pełny ekran.

Napisany w AWS, Cloud computing, Wizualizacja | Brak komentarzy »

AWS CloudTrail

Autor: Piotr Karpiuk o 21. kwietnia 2017


CloudTrail to usługa logowania wywłań API chmury Amazonu, a więc akcji podejmowanych przez użytkowników, role i usługi AWS. Nie ma znaczenia czy użytkownik zainicjował akcję z wiersza poleceń, przez API z jakiegoś języka programowania czy z konsoli przeglądarki. Krótko mówiąc, możesz użyć CloudTrail aby obserwować aktywność na swoim koncie AWS, taką jak zalogowanie się użytkownika w konsoli, utworzenie maszyny wirtualnej EC2, zmiana uprawnień użytkownika itp. Usługa jest domyślnie włączona.

Historia zdarzeń

Ze swojej konsoli w przeglądarce masz dostęp do najważniejszych logów z ostatnich 7 dni (patrz rysunek) i nie wiąże się to z żadnymi kosztami.


Logi możesz tu przeglądać, przeszukiwać lub ściągnąć (JSON/CSV).

Czytaj więcej »

Napisany w AWS, Cloud computing | Brak komentarzy »

Apache HBase

Autor: Piotr Karpiuk o 9. marca 2015

HBase to otwartoźródłowa, zaimplementowana w Javie, rozproszona baza danych inspirowana Googlowym BigTable. Jest częścią projektu Apache Hadoop i przechowuje dane w HDFS (Hadoop Distributed FileSystem). Jest to przykład tzw. kolumnowej NoSQLowej bazy danych, pozwalającej na przechowywanie w sposób odporny na awarie dużej ilości danych rzadkich (ang. sparse data) – które w relacyjnej bazie wymagałyby tabel z dużą ilością przeważnie pustych kolumn.

Pierwotnie HBase był tworzony z myślą o przetwarzaniu języka naturalnego, a od czasu przejęcia projektu przez Apache z bazy korzysta obecnie szereg firm (w tym Twitter, Stumbleupon, eBay, Yahoo!), a bodaj najbardziej spektakularne jest użycie tej bazy przez Facebooka do implementacji komunikatora internetowego Facebook Messenger.

Powszechna wiedza głosi, że sens użycia HBase pojawia się dopiero przy przetwarzaniu co najmniej 100 GB danych przy użyciu min. 5 maszyn w klastrze.

Autorzy dokumentacji używają pojęć nawiązujących do modelu relacyjnego: tabela, wiersz, kolumna – ale jest to bardzo kontrowersyjny pomysł. Osobie przyzwyczajonej do świata relacyjnych baz danych w miarę wgryzania się w HBase oczy będą się coraz bardziej otwierać ze zdumienia. W rzeczy samej, HBase wobec Oracla jest jak zły brat bliźniak, Bizarro, mr. Hyde czy Frankenstein.

Spójrzmy na poniższy rysunek, objaśniający model danych omawianej dzisiaj bazy:

W tabeli mamy dowolnie wiele wierszy, każdy identyfikowany unikalnym kluczem. Kolumny są pogrupowane w rodziny kolumn (zwane też superkolumnami). O ile rodzin kolumn zwykle jest kilka, o tyle samych kolumn mogą być miliony. HBase nie jest transakcyjna i zapewnia atomowość na poziomie rekordu (wiersza), przy czym mamy wersjonowanie: pamiętane są domyślnie 3 ostatnie wersje każdego rekordu opatrzone stemplami czasowymi. Sens istnienia superkolumn jest taki, że dla każdej z nich można zdefiniować inne parametry bazy danych, np. rodzaj kompresji danych (GZ, LZO), poziom redundancji, czas po jakim dane mają być usuwane, czy wersjonowanie. Modyfikacja parametrów superkolumny jest kosztowna – pociąga za sobą utworzenie nowej superkolumny z nową specyfikacją i skopiowanie wszystkich danych – dlatego warto ustawić parametry na docelowe zanim zacznie się wstawiać dane. Wartości kolumn nie mają typów i są traktowane jako ciągi bajtów.

W zasadzie, być może zamiast kurczowo trzymać się nomenklatury nazewniczej z relacyjnych baz danych lepiej byłoby spojrzeć na model danych HBase jak na 4-poziomową mapę asocjacyjną (kolejne poziomy to tabela, klucz, superkolumna i kolumna).

Nazwę kolumny określa się mianem kwalifikatora kolumny (ang. column qualifier). Połączenie klucza wiersza i pełnej nazwy kolumny (wraz z nazwą rodziny) zapisuje się w postaci table/family:qualifier.

Rekordy w bazie są posortowane wedle klucza i podzielone na rozłączne regiony, przy czym za każdy region odpowiedzialna jest inna maszyna klastra.

HBase nie posiada języka zapytań, nie ma indeksów. Zapewnione jest tylko skanowanie całej tabeli i bardzo szybki dostęp do rekordu po kluczu i do wartości kolumny w rekordzie, jak również Hadoopowy mechanizm MapReduce.

Facebook używa HBase jako głównego komponentu swojej infrastruktury komunikatów, zarówno do przechowywania komunikatów jak i odwróconego indeksu (ang. inverted index) na potrzeby wyszukiwania.
W tabeli implementującej indeks:

  • Kluczem wiersza jest ID użytkownika.
  • Kwalifikatorami kolumn są słowa występujące w komunikatach tego użytkownika.
  • Stemple czasowe są identyfikatorami komunikatów zawierających to słowo.

W ten sposób wykorzystywane jest wersjonowanie.

W przykładach poniżej będziemy używać powłoki napisanej w języku JRuby, ale są też inne sposoby komunikacji z bazą (najpopularniejszy jest Thrift):

Nazwa Metoda połączenia Dojrzałość
Shell Bezpośrednia Tak
Java API Bezpośrednia Tak
Thrift Protokół binarny Tak
REST HTTP Tak
Avro Protokół binarny Nie

Czytaj więcej »

Tags: , ,
Napisany w Bazy danych, Cloud computing | Brak komentarzy »

Amazon Web Services Storage

Autor: Piotr Karpiuk o 3. lutego 2015

Wybierając usługę chmury Amazona zwykle określamy region w którym ona ma fizycznie działać (USA, Brazylia, Azja, Europa), różnice cen między regionami zwykle wahają się w okolicach 10%. Każdy region jest podzielony na osobno zasilane i rozrzucone geograficznie strefy dostępności (ang. availability zones, AZ). Niektóre usługi (np. EBS – dysk sieciowy, patrz niżej, czy instancja EC2 – maszyna wirtualna) wymagają podania również strefy dostępności. Amazon ma dedykowane, szybkie połączenia sieciowe między strefami dostępności w obrębie tego samego regionu.

Propozycje Amazonu w zakresie przechowywania danych:

  • Instance storage: w wynajętej maszynie wirtualnej może być podłączony dysk SSD lub HDD o żądanej pojemności, np. instancja typu c3.8xlarge ma 2 dyski SSD po 320 GB każdy
  • Elastic Block Storage (EBS) [Cennik]: odpowiednik NASa, czyli dysk sieciowy widoczny tak samo jak dysk lokalny; jego standardowa wydajność jest słaba i wynosi ok. 100 IOPS (I/O operations per second), ale można zażyczyć sobie opcję Provisioned IOPS pozwalającą zwiększyć wydajność nawet 40-krotnie poprzez zarezerwowanie przepustowości sieci w obrębie strefy dostępności, co oczywiście dodatkowo kosztuje.
    Inne cechy EBS:
    • rozmiar jednego wolumenu waha się między 1GB a 1TB; na jednym koncie AWS można mieć max. 20 wolumenów EBS
    • cykl życia wolumenu EBS jest niezależny od instancji EC2 — można go przepinać między różnymi maszynami wirtualnymi,
    • funkcjonalność migawek (ang. snapshots) pozwala wykonać (spakowaną) migawkę zawartości wolumenu w postaci obiektu S3 (patrz dalej) a kolejne migawki mogą być przyrostowe (uwzględniają tylko zmiany od poprzedniej migawki); nowy wolumen EBS można wypełnić migawką,
    • Amazon twierdzi że każdy wolumin EBS jest duplikowany dla uchronienia się przed awarią dysku (macierz?)
  • Simple Storage Service (S3) [Cennik]: bodaj najpopularniejsza usługa Amazonu, mówi się o niej że jest magazynem Internetu (ang. the filing cabinet of the Internet), bazują na niej firmy takie jak Dropbox, Netflix czy Medcommons (ta ostatnia przechowuje w chmurze dane medyczne pacjentów). Szacuje się że 25% dużych aplikacji enterprise korzysta z S3. W ciągu ostatnich 2 lat ceny przechowywania 1 GB spadły 3-krotnie.
    • każdy obiekt ma swój klucz (łańcuch) i wartość (ciąg bajtów o wielkości od 1B do 5TB),
    • obiekty są przechowywane w wiadrach (ang. bucket, odpowiednik tabeli), jedno konto AWS może mieć max. 100 wiader; wiadro jest umiejscowione w konkretnym regionie
    • każdy obiekt S3 ma swojego URLa postaci http://s3.amazonaws.com/bucket/key, np. http://s3-us-west-1.amazonaws.com/aws4dummies/Cat+Photo.JPG i jest dostępny poprzez interfejs REST (czyli np. z przeglądarki internetowej, curl-em, itp.) o ile nadamy mu odpowiednie uprawnienia,
    • nie obsługuje modyfikacji, np. poprzez dołączenie czegoś na końcu; można tylko nadpisać obiekt nowym obiektem (można włączyć wersjonowanie, czyli dostęp do poprzednich wersji obiektu) – jest to bardzo duża różnica w porównaniu z plikiem w typowym systemie plików,
    • uprawnienia mają postać listy ACL określającej kto może wykonywać jakie operacje, klasy użytkowników to: właściciel, wskazani użytkownicy lub grupy, autoryzowani użytkownicy AWS, każdy.
    • obiekt może mieć datę ważności, po upływie której jest usuwany (stosowane np. przy wypożyczaniu filmów na określony czas), lub przenoszony do archiwum (usługa Glacier, patrz niżej),
    • obiekty mogą być szyfrowane,
    • można logować dostęp do obiektów,
    • w celu zapobiegania awariom i zwiększenia dostępności każdy obiekt jest duplikowany na kilku maszynach; można zrezygnować z tej możliwości aby zmniejszyć koszty usługi
  • DynamoDB [Cennik]: NoSQLowa baza typu key-value, odpowiednik opisanej wcześniej na blogu bazy danych Riak; korzysta z dysków SSD, dane są duplikowane w różnych strefach dostępności regionu; dostęp jest poprzez REST, lub z poziomu języków Java, .NET, Python i PHP.
  • Glacier [Cennik]: usługa backupu oparta na S3; pojedynczy plik archiwum może mieć do 40TB, dane są szyfrowane i przesyłane po SSL; zamiast wysyłać zawartość dysku po sieci, można pocztą zwykłą wysłać do Amazona fizyczny dysk – jego zawartość zostanie wrzucona do Glaciera przez pracownika Amazonu.
  • RDS [Cennik]: relacyjna baza danych (Oracle, MySQL, PostgreSQL, SQL Server, Aurora)

Zwraca się uwagę, że usługi przechowywania danych oferowane przez Amazona: DynamoDB a zwłaszcza sztandarowa S3, są świetnie przystosowane do ery BigData: nie trzeba deklarować ani rezerwować wymaganej przestrzeni dyskowej ponieważ ten sposób przechowywania danych jest wybitnie skalowalny i nie ogranicza się do pojedynczej maszyny. Redundancja w celu zapewnienia odporności na awarie pozwala nie martwić się o backupy.

Powstaje pytanie czym różni się w praktyce usługa S3 od DynamoDB. Odpowiedź na to pytanie znajdziemy w DynamoDB FAQ:

Q: When should I use Amazon DynamoDB vs Amazon S3?

A: Amazon DynamoDB stores structured data, indexed by primary key, and allows low latency read and write access to items ranging from 1 byte up to 400KB. Amazon S3 stores unstructured blobs and suited for storing large objects up to 5 TB. In order to optimize your costs across AWS services, large objects or infrequently accessed data sets should be stored in Amazon S3, while smaller data elements or file pointers (possibly to Amazon S3 objects) are best saved in Amazon DynamoDB.

Tags:
Napisany w Cloud computing | Brak komentarzy »