Chmury przypominają magiczny kuferek — wystarczy, że powiesz, czego potrzebujesz, a zasoby pojawiają się znikąd. Wirtualne maszyny, bazy danych, sieć — to wszystko należy tylko do ciebie. Istnieją także inne tenanty chmury, ale w swojej własnej rzeczywistości jesteś jedynym władcą. Jesteś pewien, że zawsze otrzymasz potrzebne zasoby, nie musisz się z nikim liczyć i samodzielnie określasz, jak będzie wyglądać sieć. Jak działa ta magia, która sprawia, że chmura elastycznie przydziela zasoby i całkowicie izoluje tenanty od siebie?
Chmura AWS to mega super skomplikowany system, który ewolucyjnie rozwija się od 2006 roku. Część tego rozwoju zauważył Wasilij Pantyuchin — architekt Amazon Web Services. Jako architekt widzi on nie tylko końcowy rezultat, ale także trudności, które pokonuje AWS. Im większe zrozumienie działania systemu, tym większe zaufanie. Dlatego Wasilij podzieli się sekretami chmurowych usług AWS. Pod zdjęciem przedstawione są architektura fizycznych serwerów AWS, elastyczna skalowalność baz danych, dostosowana baza danych Amazon i metody zwiększania wydajności wirtualnych maszyn przy jednoczesnym obniżaniu ich ceny. Znajomość architektonicznych podejść Amazon pomoże efektywniej korzystać z usług AWS i być może zainspiruje do stworzenia własnych rozwiązań.
O prelegencie: Wasilij Pantiuchin () zaczynał jako administrator Unix w rosyjskich firmach, przez 6 lat zajmował się dużymi maszynami Sun Microsystem, przez 11 lat promował podejście związane z danymi w EMC. Naturalnie ewoluował w kierunku prywatnych chmur, a w 2017 roku przeszedł do chmur publicznych. Obecnie udziela technicznych wskazówek, które pomagają żyć i rozwijać się w chmurze AWS.
Zastrzeżenie: wszystko, co poniżej, to osobista opinia Wasilija i może nie zgadzać się z stanowiskiem Amazon Web Services. wystąpienia, na podstawie którego powstał artykuł, jest dostępne na naszym kanale YouTube.
Dlaczego mówię o działaniu Amazon
Moją pierwszą maszyną była „ręczna” — na mechanicznym skrzyni biegów. To było wspaniałe uczucie, że mogłem prowadzić samochód i w pełni go kontrolować. Lubiłem też to, że przynajmniej mniej więcej rozumiałem zasady jego działania. Oczywiście wyobrażałem sobie działanie skrzyni biegów dość prymitywnie — mniej więcej jak w rowerze.
Wszystko było wspaniałe, z wyjątkiem jednego — stania w korkach. Wydaje się, że siedzisz i nic nie robisz, ale cały czas zmieniasz biegi, wciskasz sprzęgło, gaz, hamulec — od tego naprawdę się męczysz. Problem korków częściowo zniknął, gdy w rodzinie pojawił się samochód z automatem. Za kierownicą miałem czas, aby o czymś myśleć, posłuchać audiobooka.
W moim życiu pojawiła się zagadka, ponieważ całkowicie przestałem rozumieć, jak działa mój samochód. Nowoczesny samochód to skomplikowane urządzenie. Samochód dostosowuje się jednocześnie do dziesiątek różnych parametrów: wciśnięcia gazu, hamulca, stylu jazdy, jakości drogi. Już nie rozumiem, jak to działa.
Kiedy zacząłem zajmować się chmurą Amazon, dla mnie to też była tajemnica. Tylko ta tajemnica jest na wyższym poziomie, ponieważ w samochodzie jest jeden kierowca, a w AWS ich miliony. Wszyscy użytkownicy jednocześnie kierują, naciskają gaz i hamulec. Dziwne, że wszyscy jadą tam, gdzie chcą — to dla mnie cud! System automatycznie dostosowuje się, skalując i elastycznie dopasowując do każdego użytkownika, tak że wydaje mu się, że jest jedynym w tym wszechświecie.
Magia nieco osłabła, gdy później zacząłem pracować jako architekt w Amazon. Zobaczyłem, z jakimi problemami się borykamy, jak je rozwiązujemy, jak rozwijamy usługi. Wraz ze wzrostem zrozumienia działania systemu pojawia się większe zaufanie do usługi. Dlatego chcę podzielić się wizją tego, co kryje się pod maską chmury AWS.
O czym porozmawiamy
Wybrałem zróżnicowane podejście — wybrałem 4 interesujące usługi, o których warto porozmawiać.
Optymalizacja serwerów. Efemeryczne chmury z fizycznym ucieleśnieniem: fizyczne centra danych, w których stoją fizyczne serwery, które warczą, nagrzewają się i migoczą lampkami.
Funkcje serverless (Lambda) — prawdopodobnie najbardziej skalowalna usługa w chmurze.
Skalowanie bazy danych. Opowiem, jak budujemy nasze własne skalowalne bazy danych.
Skalowanie sieci. Ostatnia część, w której odkryję strukturę naszej sieci. To wspaniała rzecz — każdy użytkownik chmury uważa, że jest w chmurze sam i w ogóle nie widzi innych najemców.
Uwaga. W tym artykule skupimy się na optymalizacji serwerów i skalowaniu baz danych. Skalowanie sieci zostanie omówione w następnym artykule. Gdzie są funkcje serverless? O tym pojawiła się oddzielna analiza.. Zawiera ona opis kilku różnych sposobów skalowania oraz szczegółową analizę rozwiązania Firecracker — symbioza najlepszych cech maszyn wirtualnych i kontenerów.
Serwery
Chmura jest efemeryczna. Ale ta efemeryczność ma swoje fizyczne przedstawienie — serwery. Ich architektura początkowo była klasyczna. Standardowy chipset x86, karty sieciowe, Linux, hipernadzorca Xen, na którym uruchamiano maszyny wirtualne.
W 2012 roku taka architektura w pełni spełniała swoje zadania. Xen to doskonały hipernadzorca, ale ma jedną poważną wadę. Ma stosunkowo wysokie koszty narzutu związane z emulacją urządzeń.Wraz z pojawieniem się nowych, szybszych kart sieciowych lub dysków SSD te koszty stają się zbyt wysokie. Jak poradzić sobie z tym problemem? Postanowiono działać na dwóch frontach — optymalizować zarówno sprzęt, jak i hipernadzorcę.Zadanie jest bardzo poważne.
Optymalizacja sprzętu i hipernadzorców
Nie da się zrobić wszystkiego naraz i dobrze. Co to znaczy «dobrze», również na początku nie było jasne.
Postanowiono zastosować podejście ewolucyjne — zmieniając jeden ważny element architektury, wprowadzamy go do produkcji.
Natrafiamy na wszystkie pułapki, wysłuchujemy skarg i propozycji. Potem zmieniamy inną komponentę. W ten sposób, małymi krokami, radykalnie zmieniamy całą architekturę na podstawie opinii użytkowników i wsparcia.
Przemiany rozpoczęły się w 2013 roku od najtrudniejszego — sieci. W C3 instancjach standardową kartę sieciową uzupełniliśmy o specjalną kartę Network Accelerator. Podłączano ją dosłownie krótkim kablem loopback z przodu. Nieestetyczne, ale w chmurze tego nie widać. Jednak bezpośrednia interakcja ze sprzętem zasadniczo poprawiła jitter i przepustowość sieci.
Potem postanowiono zająć się poprawą dostępu do blokowego przechowywania danych EBS — Elastic Block Storage. To kombinacja sieci i pamięci. Problem w tym, że choć na rynku istniały karty Network Accelerator, możliwość zakupienia sprzętu Storage Accelerator była nieosiągalna. Dlatego zwróciliśmy się do startupu Annapurna Labs, który opracował dla nas specjalne chipy ASIC. Umożliwiły one podłączanie zdalnych wolumenów EBS jako urządzeń NVMe.
W instancjach C4 rozwiązaliśmy dwa problemy. Pierwszy — zrealizowaliśmy przyszłościowe przygotowanie dla nowej wówczas technologii NVMe. Drugi — znacznie odciążaliśmy procesor centralny, przenosząc przetwarzanie zapytań do EBS na nową kartę. Udało się to osiągnąć, dlatego teraz Annapurna Labs jest częścią Amazon.
Do listopada 2017 roku zrozumieliśmy, że nadszedł czas na zmianę samego hypervisora.
Nowy hypervisor został opracowany na podstawie zmodyfikowanych modułów jądra KVM.
Pozwolił on zasadniczo zmniejszyć koszty emulacji urządzeń i pracować bezpośrednio z nowymi chipami ASIC. Instancje C5 były pierwszymi wirtualkami, pod maską których działa nowy hypervisor. Nazwaliśmy go Nitro.
Ewolucja instancji na osi czasu.
Wszystkie nowe typy maszyn wirtualnych, które pojawiły się od listopada 2017, działają na tym hypervisorze. Instancje Bare Metal nie mają hypervisora, ale też nazywa się je Nitro, ponieważ wykorzystują wyspecjalizowane karty Nitro.
W ciągu następnych dwóch lat liczba typów instancji Nitro przekroczyła kilka tuzinów: A1, C5, M5, T3 i inne.
Typy instancji.
Jak działają nowoczesne maszyny Nitro
Mają trzy główne komponenty: hypervisor Nitro (o którym wspomniano wcześniej), chip bezpieczeństwa i karty Nitro.
Chip bezpieczeństwa jest zintegrowany bezpośrednio z płytą główną. Kontroluje wiele ważnych funkcji, takich jak kontrola ładowania systemu operacyjnego hosta.
Karty Nitro — jest ich cztery typy. Wszystkie zostały opracowane przez Annapurna Labs i bazują na wspólnych chipach ASIC. Część ich oprogramowania również jest wspólna.
Cztery typy kart Nitro.
Jedna z kart jest przeznaczona do pracy z sieciąVPC. Właśnie ona jest widoczna w wirtualkach jako karta sieciowa ENA — Elastic Network Adaptor. Ponadto kapsułkuje ruch podczas jego przesyłania przez sieć fizyczną (o tym porozmawiamy w drugiej części artykułu), kontroluje zapory sieciowe Security Groups, odpowiada za routing oraz inne kwestie sieciowe.
Oddzielne karty pracują z blokowym przechowywaniem EBS i dyskami, które są wbudowane w serwer. Gospodarce wirtualnej są one przedstawiane jako adaptery NVMe. Ponadto odpowiadają za szyfrowanie danych i monitorowanie dysków.
System kart Nitro, hypervisora i chipa bezpieczeństwa jest zintegrowany w sieci SDN lub Software Defined Network. Zarządzanie tą siecią (Control Plane) zapewnia kontroler mapy.
Oczywiście, kontynuujemy rozwój nowych ASIC. Na przykład, pod koniec 2018 roku wprowadziliśmy chip Inferentia, który umożliwia bardziej efektywne wykonywanie zadań związanych z uczeniem maszynowym.
Chip Inferentia Processor do Uczenia Maszynowego.
Skalowalna baza danych
Tradycyjna baza danych ma warstwową strukturę. Jeśli bardzo uprościć, wyróżnia się następujące poziomy.
- SQL — działają na nim menedżery klientów i zapytań.
- Zabezpieczenia transakcje — tutaj wszystko jest jasne, ACID i tym podobne.
- Odtwarzanie, co jest zapewnione przez pule buforowe.
- Rejestrowanie — zapewnia obsługę redo-logów. W MySQL nazywają się one Bin Logs, w PosgreSQL — Write Ahead Logs (WAL).
- Przechowywanie – bezpośrednio zapis do dysku.
Warstwowa struktura bazy danych.
Istnieją różne sposoby skalowania baz danych: sharding, architektura Shared Nothing, współdzielone dyski.
Jednak wszystkie te metody zachowują tę samą monolityczną strukturę bazy danych. Ogranicza to skalowalność. Aby rozwiązać ten problem, opracowaliśmy naszą własną bazę danych — Amazon Aurora. Jest zgodna z MySQL i PostgreSQL.
Amazon Aurora
Główna idea architektoniczna — oddzielić poziomy przechowywania i logowania od głównej bazy danych.
Na przód powiem, że poziom buforowania również uczyniliśmy niezależnym. Architektura przestaje być monolitem i zyskujemy dodatkowe swobody w skalowaniu poszczególnych bloków.
Poziomy logowania i przechowywania są oddzielone od bazy danych.
Tradycyjna SGBD zapisuje dane do systemu przechowywania w postaci bloków. W Amazon Aurora stworzyliśmy „inteligentne” przechowywanie, które może rozmawiać w języku redo-logów. Wewnątrz przechowywanie zamienia logi na bloki danych, monitoruje ich integralność i automatycznie wykonuje kopie zapasowe.
To podejście pozwala na realizację takich interesujących rzeczy jak klonowanie. Działa zasadniczo szybciej i ekonomiczniej, ponieważ nie wymaga tworzenia pełnej kopii wszystkich danych.
Poziom przechowywania jest zrealizowany w postaci rozproszonego systemu. Składa się z bardzo dużej liczby fizycznych serwerów. Każdy redo-log jest przetwarzany i zapisywany jednocześnie przez sześć węzłów. Zapewnia to ochronę danych i rozkład obciążenia.
Skalowanie odczytu można zapewnić dzięki odpowiednim replikom. Rozproszone przechowywanie eliminuje potrzebę synchronizacji między główną instancją bazy danych, przez którą zapisujemy dane, a pozostałymi replikami. Aktualne dane są gwarantowane jako dostępne dla wszystkich replik.
Jedyny problem to cache'owanie starych danych na replikach odczytu. Ale ten problem można rozwiązać przekazywaniem wszystkich redo-logów do replik przez wewnętrzną sieć. Jeśli log znajduje się w cache'u, jest oznaczany jako niepoprawny i nadpisywany. Jeśli go tam nie ma, po prostu jest odrzucany.
Z przechowywaniem się rozwiązałem.
Jak skalować poziomy DBMS
Tutaj poziome skalowanie jest znacznie trudniejsze. Dlatego pójdziemy utartą ścieżką klasycznego pionowego skalowania..
Załóżmy, że mamy aplikację, która komunikuje się z DBMS przez węzeł główny.
Przy pionowym skalowaniu przydzielamy nowy węzeł, który ma więcej procesorów i pamięci.
Następnie przełączamy aplikację ze starego węzła głównego na nowy. Powstają problemy.
- Wymaga to zauważalnego czasu przestoju aplikacji.
- Nowy węzeł główny będzie miał zimny cache. Wydajność bazy danych osiągnie maksimum dopiero po rozgrzaniu cache'a.
Jak poprawić sytuację? Umieścić proxy między aplikacją a węzłem głównym.
Co nam to da? Teraz wszystkie aplikacje nie muszą być ręcznie przekierowywane na nowy węzeł. Przełączenie można zrealizować przez proxy i będzie zasadniczo szybsze.
Wydaje się, że problem został rozwiązany. Ale nie, wciąż cierpimy z powodu konieczności rozgrzewania cache'a. Poza tym pojawił się nowy problem — teraz proxy to potencjalny punkt awarii.
Końcowe rozwiązanie z Amazon Aurora serverless
Jak rozwiązaliśmy te problemy?
Zostawiliśmy proxy. To nie jest jakiś oddzielny instancja, lecz cały rozproszony floty proxy, przez które aplikacje łączą się z bazą danych. Każdy z węzłów w przypadku awarii można wymienić praktycznie natychmiast.
Dodaliśmy pulę ciepłych węzłów o różnej wielkości. Dlatego w przypadku potrzeby przydzielenia nowego węzła większego lub mniejszego rozmiaru jest on od razu dostępny. Nie trzeba czekać, aż się załaduje.
Cały proces skalowania jest kontrolowany przez specjalny system monitorowania. Monitorowanie stale śledzi stan aktualnego węzła-mistrza. Jeśli na przykład wykryje, że obciążenie procesora osiągnęło krytyczną wartość, informuje pulę ciepłych instancji o konieczności przypisania nowego węzła.
Rozproszone proxy, ciepłe instancje i monitorowanie.
Węzeł o wymaganej mocy jest dostępny. Buffory są kopiowane na niego, a system zaczyna czekać na bezpieczny moment do przełączenia.
Zwykle moment przełączenia następuje wystarczająco szybko. Wtedy komunikacja między proxy a starym węzłem-mistrzem jest wstrzymywana, a wszystkie sesje są przełączane na nowy węzeł.
Praca z bazą danych jest wznawiana.
Na wykresie widać, że wstrzymanie jest naprawdę bardzo krótkie. Na niebieskim wykresie widać obciążenie, a na czerwonych schodkach - momenty skalowania. Krótkoterminowe spadki na niebieskim wykresie to właśnie ta krótka zwłoka.
Notabene, Amazon Aurora pozwala na oszczędności i wyłączenie bazy danych, gdy nie jest używana, na przykład w weekendy. Po zatrzymaniu obciążenie bazy danych stopniowo zmniejsza swoją moc i na pewien czas się wyłącza. Gdy obciążenie wraca, znowu płynnie wzrasta.
W kolejnej części opowieści o urządzeniach Amazon porozmawiamy o skalowaniu sieci. Subskrybuj i śledź aktualizacje, aby nie przegapić artykułu.
Na Wasilij Pantiechin wygłosi referat „”. Jakie wzorce projektowania rozproszonych systemów stosują programiści Amazon, jakie są przyczyny awarii usług, co to jest architektura oparta na komórkach, stała praca, Shuffle Sharding — będzie ciekawie. Do konferencji mniej niż miesiąc — . 24 października ostateczna podwyżka cen.
Źródło: habr.com
