Chmury są jak magiczne pudełko – pytasz, czego potrzebujesz, a zasoby pojawiają się znikąd. Maszyny wirtualne, bazy danych, sieć – to wszystko należy tylko do Ciebie. Istnieją inni najemcy chmur, ale w swoim Wszechświecie jesteś jedynym władcą. Masz pewność, że zawsze otrzymasz potrzebne zasoby, nie bierzesz nikogo pod uwagę i samodzielnie ustalasz, jaka będzie sieć. Jak działa ta magia, która sprawia, że chmura elastycznie alokuje zasoby i całkowicie izoluje od siebie najemców?
Chmura AWS to mega-super złożony system, który ewoluuje ewolucyjnie od 2006 roku. Część tego rozwoju miała miejsce Wasilij Pantiukhin - Architekt usług internetowych Amazon. Jako architekt ma wgląd nie tylko w efekt końcowy, ale także w wyzwania, przed którymi stoi AWS. Im większe zrozumienie działania systemu, tym większe zaufanie. Dlatego Wasilij podzieli się z nami tajnikami usług chmurowych AWS. Poniżej projekt fizycznych serwerów AWS, elastyczna skalowalność bazy danych, niestandardowa baza danych Amazon oraz sposoby na zwiększenie wydajności maszyn wirtualnych przy jednoczesnym obniżeniu ich ceny. Znajomość podejść architektonicznych Amazona pomoże Ci efektywniej korzystać z usług AWS i może dać Ci nowe pomysły na budowanie własnych rozwiązań.
O prelegencie: Wasilij Pantyukhin () zaczynał jako administrator Uniksa w firmach .ru, przez 6 lat pracował na dużym sprzęcie Sun Microsystem, a przez 11 lat głosił w firmie EMC świat skoncentrowany na danych. W naturalny sposób przekształciła się w chmury prywatne, a w 2017 roku przeszła do chmur publicznych. Obecnie udziela porad technicznych, które pomagają żyć i rozwijać się w chmurze AWS.
Zastrzeżenie: wszystko poniżej jest osobistą opinią Wasilija i może nie pokrywać się ze stanowiskiem Amazon Web Services. Raport, na podstawie którego powstał artykuł, dostępny jest na naszym kanale YouTube.
Dlaczego mówię o urządzeniu Amazon?
Mój pierwszy samochód miał manualną skrzynię biegów. Było wspaniale, bo miałem poczucie, że mogę prowadzić samochód i mieć nad nim pełną kontrolę. Podobało mi się też to, że przynajmniej w przybliżeniu zrozumiałem zasadę jego działania. Naturalnie wyobrażałem sobie konstrukcję pudła jako dość prymitywną – coś w rodzaju skrzyni biegów w rowerze.
Wszystko było super, poza jedną rzeczą – utknięciem w korkach. Wydaje się, że siedzisz i nic nie robisz, ale ciągle zmieniasz biegi, wciskasz sprzęgło, gaz, hamulec – to naprawdę cię męczy. Problem z korkami został częściowo rozwiązany, gdy rodzina kupiła samochód z automatyczną skrzynią biegów. Jadąc miałem czas o czymś pomyśleć i posłuchać audiobooka.
W moim życiu pojawiła się kolejna zagadka, bo zupełnie przestałam rozumieć, jak działa mój samochód. Nowoczesny samochód to złożone urządzenie. Samochód dostosowuje się jednocześnie do kilkudziesięciu różnych parametrów: wciśnięcia gazu, hamulca, stylu jazdy, jakości drogi. Nie rozumiem już jak to działa.
Kiedy zaczynałem pracę nad chmurą Amazon, również była to dla mnie zagadka. Tylko ta zagadka jest o rząd wielkości większa, bo w aucie jest jeden kierowca, a w AWS-ie są ich miliony. Wszyscy użytkownicy jednocześnie kierują, naciskają gaz i hamują. To niesamowite, że idą tam, gdzie chcą – dla mnie to cud! System automatycznie dostosowuje się, skaluje i elastycznie dopasowuje do każdego użytkownika tak, aby wydawało mu się, że jest sam w tym Wszechświecie.
Magia nieco opadła, kiedy później zacząłem pracować jako architekt w Amazon. Widziałem, z jakimi problemami się borykamy, jak je rozwiązujemy i jak rozwijamy usługi. Wraz ze wzrostem zrozumienia działania systemu pojawia się większe zaufanie do usługi. Chcę więc udostępnić obraz tego, co kryje się pod maską chmury AWS.
O czym powinniśmy porozmawiać
Wybrałem podejście zróżnicowane – wytypowałem 4 ciekawe usługi, o których warto porozmawiać.
Optymalizacja serwera. Chmury efemeryczne o fizycznej postaci: fizyczne centra danych, w których znajdują się fizyczne serwery, które szumią, nagrzewają się i migają światłami.
Funkcje bezserwerowe (Lambda) to prawdopodobnie najbardziej skalowalna usługa w chmurze.
Skalowanie bazy danych. Opowiem Ci jak budujemy własne skalowalne bazy danych.
Skalowanie sieci. Ostatnia część, w której otworzę urządzenie naszej sieci. To cudowna rzecz – każdy użytkownik chmury wierzy, że jest w chmurze sam i w ogóle nie widzi innych najemców.
Notatka. W tym artykule omówiona zostanie optymalizacja serwerów i skalowanie baz danych. Skalowanie sieci rozważymy w następnym artykule. Gdzie są funkcje bezserwerowe? Opublikowano o nich odrębny zapis „" Opowiada o kilku różnych metodach skalowania, a także szczegółowo omawia rozwiązanie Firecracker – symbiozę najlepszych cech maszyny wirtualnej i kontenerów.
Serwery
Chmura jest efemeryczna. Ale ta efemeryczność nadal ma fizyczne ucieleśnienie - serwery. Początkowo ich architektura była klasyczna. Standardowy chipset x86, karty sieciowe, Linux, hypervisor Xen, na którym uruchomiono maszyny wirtualne.
W 2012 roku architektura ta radziła sobie całkiem nieźle ze swoimi zadaniami. Xen to świetny hypervisor, ale ma jedną zasadniczą wadę. Ma dość duże obciążenie związane z emulacją urządzenia. W miarę pojawiania się nowych, szybszych kart sieciowych lub dysków SSD obciążenie to staje się zbyt duże. Jak sobie poradzić z tym problemem? Postanowiliśmy działać na dwóch frontach jednocześnie - zoptymalizuj zarówno sprzęt, jak i hypervisor. Zadanie jest bardzo poważne.
Optymalizacja sprzętu i hypervisora
Robienie wszystkiego na raz i robienie tego dobrze nie zadziała. Początkowo nie było jasne, co oznaczało „dobro”.
Zdecydowaliśmy się na podejście ewolucyjne - zmieniamy jeden ważny element architektury i wrzucamy go do produkcji.
Wchodzimy na każdą grabię, wysłuchujemy skarg i sugestii. Następnie zmieniamy kolejny komponent. Dlatego małymi krokami radykalnie zmieniamy całą architekturę w oparciu o opinie użytkowników i wsparcie.
Transformacja rozpoczęła się w 2013 roku od najbardziej złożonej rzeczy – sieci. W С3 przypadkach do standardowej karty sieciowej dodano specjalną kartę Network Accelerator. Podłączano go dosłownie krótkim kablem typu „loopback” na przedniej ściance. Nie jest ładnie, ale w chmurze tego nie widać. Jednak bezpośrednia interakcja ze sprzętem zasadniczo poprawiła fluktuacje i przepustowość sieci.
Następnie postanowiliśmy poprawić dostęp do blokowego przechowywania danych EBS – Elastic Block Storage. Jest to połączenie sieci i pamięci masowej. Trudność polega na tym, że chociaż na rynku istniały karty Network Accelerator, nie było możliwości prostego zakupu sprzętu Storage Accelerator. Zwróciliśmy się więc do startupu Laboratorium Annapurny, który opracował dla nas specjalne chipy ASIC. Umożliwiły one montowanie zdalnych woluminów EBS jako urządzeń NVMe.
W przypadkach C4 rozwiązaliśmy dwa problemy. Po pierwsze, wdrożyliśmy fundamenty przyszłości obiecującej, ale wówczas nowej technologii NVMe. Po drugie, znacząco odciążyliśmy centralny procesor przenosząc przetwarzanie żądań do EBS na nową kartę. Wyszło dobrze, więc teraz Annapurna Labs jest częścią Amazona.
W listopadzie 2017 roku zdaliśmy sobie sprawę, że nadszedł czas na zmianę samego hypervisora.
Nowy hypervisor powstał w oparciu o zmodyfikowane moduły jądra KVM.
Umożliwiło to zasadniczo zmniejszenie narzutu związanego z emulacją urządzenia i bezpośrednią pracę z nowymi układami ASIC. Instancje С5 były pierwszymi maszynami wirtualnymi z nowym hypervisorem działającym pod maską. Nazwaliśmy go Nitro.
Ewolucja instancji na osi czasu.
Wszystkie nowe typy maszyn wirtualnych, które pojawiły się od listopada 2017 r., działają na tym hypervisorze. Instancje Bare Metal nie mają hypervisora, ale nazywane są również Nitro, ponieważ korzystają z wyspecjalizowanych kart Nitro.
W ciągu następnych dwóch lat liczba typów instancji Nitro przekroczyła kilkadziesiąt: A1, C5, M5, T3 i inne.
Typy instancji.
Jak działają nowoczesne maszyny Nitro
Składają się z trzech głównych komponentów: hiperwizora Nitro (omówionego powyżej), chipa zabezpieczającego i kart Nitro.
Chip zabezpieczający zintegrowany bezpośrednio z płytą główną. Kontroluje wiele ważnych funkcji, takich jak kontrolowanie ładowania systemu operacyjnego hosta.
Karty nitro - Są ich cztery rodzaje. Wszystkie zostały opracowane przez Annapurna Labs i opierają się na popularnych układach ASIC. Niektóre z ich oprogramowania sprzętowego są również powszechne.
Cztery rodzaje kart Nitro.
Jedna z kart jest przeznaczona do współpracy siećVPC. To właśnie jest widoczne w maszynach wirtualnych jako karta sieciowa ENA – elastyczna karta sieciowa. Hermetyzuje również ruch podczas przesyłania go przez sieć fizyczną (porozmawiamy o tym w drugiej części artykułu), kontroluje zaporę grup zabezpieczeń oraz jest odpowiedzialny za routing i inne rzeczy sieciowe.
Wybrane karty współpracują z pamięcią blokową EBS i dyski wbudowane w serwer. Pojawiają się na gościnnej maszynie wirtualnej jako Adaptery NVMe. Odpowiadają także za szyfrowanie danych i monitorowanie dysku.
System kart Nitro, hypervisor i chip zabezpieczający jest zintegrowany z siecią SDN lub Sieć definiowana programowo. Odpowiedzialny za zarządzanie tą siecią (płaszczyzna sterowania) karta kontrolera.
Oczywiście nadal opracowujemy nowe układy ASIC. Na przykład pod koniec 2018 roku wypuścili chip Inferentia, który pozwala wydajniej pracować z zadaniami uczenia maszynowego.
Układ procesora uczenia maszynowego Inferentia.
Skalowalna baza danych
Tradycyjna baza danych ma strukturę warstwową. Aby znacznie uprościć, wyróżnia się następujące poziomy.
- SQL — pracują nad tym klienci i dyspozytorzy żądań.
- Zaprowiantowanie transakcje - tutaj wszystko jest jasne, ACID i tak dalej.
- buforowanie, który jest zapewniany przez pule buforów.
- Logowanie — zapewnia pracę z dziennikami powtórzeń. W MySQL nazywane są one dziennikami bin, w PosgreSQL - dziennikami zapisu z wyprzedzeniem (WAL).
- magazynowanie – bezpośredni zapis na dysk.
Warstwowa struktura bazy danych.
Istnieją różne sposoby skalowania baz danych: sharding, architektura Shared Nothing, dyski współdzielone.
Jednak wszystkie te metody zachowują tę samą monolityczną strukturę bazy danych. To znacznie ogranicza skalowanie. Aby rozwiązać ten problem, opracowaliśmy własną bazę danych − Amazonka Aurora. Jest kompatybilny z MySQL i PostgreSQL.
Amazonka Aurora
Główną ideą architektoniczną jest oddzielenie poziomów przechowywania i rejestrowania od głównej bazy danych.
Patrząc w przyszłość, powiem, że uniezależniliśmy także poziom buforowania. Architektura przestaje być monolitem, a zyskujemy dodatkowe stopnie swobody w skalowaniu poszczególnych bloków.
Poziomy rejestrowania i przechowywania są oddzielone od bazy danych.
Tradycyjny system DBMS zapisuje dane w systemie pamięci masowej w postaci bloków. W Amazon Aurora stworzyliśmy inteligentną pamięć masową, która mówi językiem powtórz logi. Wewnątrz pamięć zamienia logi w bloki danych, monitoruje ich integralność i automatycznie tworzy kopie zapasowe.
Takie podejście pozwala na realizację takich ciekawych rzeczy jak klonowanie. Działa zasadniczo szybciej i oszczędniej ze względu na to, że nie wymaga tworzenia pełnej kopii wszystkich danych.
Warstwa pamięci masowej jest zaimplementowana jako system rozproszony. Składa się z bardzo dużej liczby serwerów fizycznych. Każdy dziennik powtórzeń jest przetwarzany i zapisywany jednocześnie sześć węzłów. Zapewnia to ochronę danych i równoważenie obciążenia.
Skalowanie odczytu można osiągnąć stosując odpowiednie repliki. Rozproszona pamięć masowa eliminuje konieczność synchronizacji pomiędzy główną instancją bazy danych, poprzez którą zapisujemy dane, a pozostałymi replikami. Gwarantujemy dostępność aktualnych danych dla wszystkich replik.
Jedynym problemem jest buforowanie starych danych w replikach odczytu. Ale ten problem jest w trakcie rozwiązywania przeniesienie wszystkich dzienników powtórzeń do replik poprzez sieć wewnętrzną. Jeśli log znajduje się w pamięci podręcznej, zostaje oznaczony jako nieprawidłowy i nadpisany. Jeśli nie ma go w pamięci podręcznej, jest on po prostu odrzucany.
Uporządkowaliśmy przechowywanie.
Jak skalować warstwy DBMS
Tutaj skalowanie poziome jest znacznie trudniejsze. Idźmy więc utartym szlakiem klasyczne skalowanie pionowe.
Załóżmy, że mamy aplikację, która komunikuje się z systemem DBMS poprzez węzeł główny.
Skalując w pionie, przydzielamy nowy węzeł, który będzie miał więcej procesorów i pamięci.
Następnie przełączamy aplikację ze starego węzła głównego na nowy. Pojawiają się problemy.
- Będzie to wymagało znacznych przestojów aplikacji.
- Nowy węzeł główny będzie miał zimną pamięć podręczną. Wydajność bazy danych będzie maksymalna dopiero po rozgrzaniu pamięci podręcznej.
Jak poprawić sytuację? Skonfiguruj serwer proxy między aplikacją a węzłem głównym.
Co nam to da? Teraz nie trzeba już ręcznie przekierowywać wszystkich aplikacji do nowego węzła. Przełączenie można wykonać za pośrednictwem serwera proxy i jest zasadniczo szybsze.
Wygląda na to, że problem został rozwiązany. Ale nie, nadal cierpimy z powodu konieczności rozgrzania pamięci podręcznej. Dodatkowo pojawił się nowy problem - teraz proxy jest potencjalnym punktem awarii.
Ostateczne rozwiązanie z bezserwerową usługą Amazon Aurora
Jak rozwiązaliśmy te problemy?
Zostawiłem proxy. Nie jest to osobna instancja, ale cała rozproszona flota serwerów proxy, za pośrednictwem których aplikacje łączą się z bazą danych. W przypadku awarii dowolny z węzłów można niemal natychmiast wymienić.
Dodano pulę ciepłych węzłów o różnych rozmiarach. Dlatego jeśli zajdzie potrzeba przydzielenia nowego węzła o większym lub mniejszym rozmiarze, jest on natychmiast dostępny. Nie trzeba czekać, aż się załaduje.
Cały proces skalowania kontrolowany jest przez specjalny system monitoringu. Monitoring stale monitoruje stan bieżącego węzła głównego. Jeśli wykryje np., że obciążenie procesora osiągnęło wartość krytyczną, powiadamia pulę ciepłych instancji o konieczności przydzielenia nowego węzła.
Rozproszone serwery proxy, ciepłe instancje i monitorowanie.
Dostępny jest węzeł o wymaganej mocy. Kopiowane są do niego pule buforów, a system zaczyna czekać na bezpieczny moment na przełączenie.
Zwykle moment na zmianę przychodzi dość szybko. Następnie komunikacja pomiędzy proxy a starym węzłem głównym zostaje zawieszona, wszystkie sesje zostają przełączone na nowy węzeł.
Praca z bazą danych zostaje wznowiona.
Z wykresu wynika, że zawieszenie rzeczywiście jest bardzo krótkie. Niebieski wykres pokazuje obciążenie, a czerwone kroki pokazują momenty skalujące. Krótkoterminowe spadki na niebieskim wykresie są właśnie tym krótkim opóźnieniem.
Nawiasem mówiąc, Amazon Aurora pozwala całkowicie zaoszczędzić pieniądze i wyłączyć bazę danych, gdy nie jest ona używana, na przykład w weekendy. Po zatrzymaniu obciążenia DB stopniowo zmniejsza swoją moc i wyłącza się na pewien czas. Gdy ładunek powróci, ponownie podniesie się płynnie.
W dalszej części opowieści o urządzeniu Amazon porozmawiamy o skalowaniu sieci. Subskrybuj i bądź na bieżąco, aby nie przegapić artykułu.
Na Wasilij Pantyukhin złoży raport „" Jakie wzorce projektowe dla systemów rozproszonych stosują programiści Amazona, jakie są przyczyny awarii usług, czym jest architektura Cell-Based, Constant Work, Shuffle Sharding – to będzie ciekawe. Niecały miesiąc do konferencji - . 24 października ostateczna podwyżka cen.
Źródło: www.habr.com