Scott Tiger Tech Blog

Blog technologiczny firmy Scott Tiger S.A.

Archiwum: 'Cloud computing' Kategorie

Mikrousługi w chmurze Amazonu

Autor: Piotr Karpiuk o 17. maja 2017

Architektura mikrousług

Idea mikrousług nie powstała znikąd, obejmuje szereg sprawdzonych koncepcji takich jak programowanie zwinne (ang. agile development), architektura zorientowana na usługi (SOA), podejście API-first czy ciągłe dostarczanie (ang. continuous delivery, CD).

Główne cechy mikrousług:

  • Decentralizacja, zarówno jeśli chodzi o sposób działania (i np. spojrzenie na modele danych), ale również sposób tworzenia.
  • Niezależność – każdy komponent można zmienić niezależnie od pozostałych. Każdy komponent jest też tworzony przez osobny zespół.
  • Mikrousługa robi jedną rzecz, ale dobrze, skupiając się na jednej dziedzinie.
  • Można użyć wiele technologii – każda mikrousługa może być tworzona przy użyciu technologii najlepiej pasującej do dziedziny problemu i umiejętności zespołu.
  • Każda usługa jest czarną skrzynką z dobrze zdefiniowanym API.
  • Zespół który tworzy usługę jest odpowiedzialny za jej wdrożenie i utrzymanie – jest to jedna z najważniejszych zasad DevOps, o tyle istotna że zgodnie z prawem Conwaya architektura systemów tworzonych przez firmę odzwierciedla jej strukturę organizacyjną.

Najważniejsze zalety mikrousług:

  • Zwinność. Mikrousługi sprzyjają organizacji małych niezależnych zespołów przejmujących swoje usługi we władanie. Zespoły działają w obrębie swoich małych i dobrze zrozumiałych światów, co pozwala im skracać cykle produkcji.
  • Innowacja. Wiąże się ze swobodą wyboru technologii, języków programowania i narzędzi do tworzenia każdej usługi. Metodyki zwinne, DevOps i ciągła integracja zachęcają do eksperymentów, które można szybko przetestować i łatwo wycofać w razie niepowodzeń. Niski koszt porażki tworzy kulturę podatną na zmiany i innowacje.
  • Skalowalność i dostępność. Ponieważ mikrousługi są niezależne, można je na produkcji łatwo podmieniać i rozmnażać.

Rzecz jasna nie ma darmowych obiadów i architektura mikrousług ma również swoje wady:

  • Jest to architektura rozproszona, ze wszystkimi wadami. W szczególności nie można założyć że sieć jest niezawodna, opóźnienia komunikacji pomijalne a przepustowość interfejsów sieciowych nieskończona. Architektura mikrousług to problemy z asynchroniczną komunikacją, spójnością danych (transakcje!), odnajdywaniem się mikrousług, czy uwierzytelnianiem komunikacji.
  • Migracja. Przy przejściu z architektury monolitycznej na architekturę mikrousług trzeba podjąć właściwe decyzje dotyczące podziału – wszelkie błędy będą się później srodze mścić.
  • Wersjonowanie. W praktyce często jedna usługa będzie działać w wielu kopiach, ale w różnych wersjach. Trzeba umieć nad tym zapanować.
  • Organizacja. Skuteczne wdrożenie systemów opartych na mikrousługach wymaga często zmian organizacyjnych w firmie, która może być przystosowana do tworzenia oprogramowania w stary sposób.
  • Inne problemy. Każda mikrousługa może być tworzona przy użyciu innych technologii, ale powinien istnieć jakiś spójny mechanizm logowania czy monitorowania takiego systemu – pojawia się pytanie jak uniknąć duplikowania narzędzi i procesów, a także jak to zorganizować żeby nie poświęcać temu zbyt dużo czasu i skupić się na funkcjach biznesowych aplikacji.

Czytaj więcej »

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

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 »