Wzorce architektury aplikacji na AWS

Wdrażanie aplikacji na AWS

Dunieski Otano

Amazon Web Services Solutions Architect

Poznaj swojego instruktora

Instruktor kursu Dunieski Otano, architekt rozwiązań AWS z około dziesięcioletnim doświadczeniem w chmurze

Dlaczego właściwa architektura ma znaczenie

Diagram decyzyjny na jasnym tle: jeden węzeł wyboru architektury rozgałęzia się na trzy czynniki — sprzężenie, stan i komunikacja — oraz ikonę wagi symbolizującą kompromisy

Architektura to zestaw kompromisów, nie jedna właściwa odpowiedź
- Każdy wybór kształtują trzy pytania:
  - Jak ściśle są powiązane komponenty?
  - Gdzie przechowywany jest stan?
  - Czy komunikacja jest synchroniczna, czy asynchroniczna?
- Dopasuj wzorzec do obciążenia, a nie do trendów

Piątkowa kaskada awarii

Wolne API płatności blokowało cały proces zakupu
Każda usługa synchronicznie czekała na odpowiedź
Rozwiązaniem jest zmiana architektury, nie szybsze API

Porównanie: ściśle powiązane usługi blokujące się nawzajem versus usługi rozdzielone kolejką komunikatów

Jak architektura wpływa na wdrożenie

Diagram porównujący kruchą architekturę ściśle powiązaną, w której awaria jednej usługi rozprzestrzenia się na wszystkie, z odpornym projektem, gdzie bufor kolejki izoluje awarię i inne usługi działają bez zakłóceń

Wybrany wzorzec decyduje o tym, jak aplikacja skaluje się i reaguje na awarie
- Ściśle powiązany projekt załamuje się pod obciążeniem
Właściwy wzorzec sprawia, że wdrożenie staje się przewidywalne
- Ten sam kod, zupełnie inne zachowanie na produkcji

Podstawowe wzorce architektury

Monolityczna: jedna jednostka wdrożeniowa, prosta na start
Mikroserwisy: niezależne usługi, wdrażane osobno
Sterowana zdarzeniami: komponenty reagują na zdarzenia, nie na bezpośrednie wywołania
- Fanout to podwzorzec: jedno zdarzenie trafia do wielu odbiorców

Trzy wzorce architektury aplikacji obok siebie: monolityczna jako jeden blok, mikroserwisy jako niezależne usługi oraz sterowana zdarzeniami z magistralą zdarzeń; wzorzec fanout zaznaczony jako podwzorzec publikujący jedno zdarzenie do wielu odbiorców

Stanowa vs bezstanowa

Bezstanowa: brak danych klienta między żądaniami
- Każda instancja może obsłużyć dowolne żądanie
Stanowa: instancja pamięta wcześniejsze interakcje
Bezstanowość umożliwia skalowanie poziome
- Wspólny stan przenieś do DynamoDB lub ElastiCache

Bezstanowa instancja funkcji dostępna dla dowolnego żądania po lewej versus stanowa instancja powiązana z jedną sesją klienta po prawej

Ścisłe vs luźne powiązanie

Ścisłe powiązanie: wywołujący zablokowany w oczekiwaniu na wolny serwis versus luźne powiązanie: kolejka SQS buforuje wiadomości, dzięki czemu producent może działać dalej

Ścisłe powiązanie: wywołujący czeka na odpowiedź wywoływanego
Jedna wolna usługa blokuje cały łańcuch
Luźne powiązanie: między usługami stoi kolejka Amazon SQS
Producent działa dalej, nawet gdy konsument jest niedostępny

Synchroniczna vs asynchroniczna

Synchroniczna: wywołujący blokuje się i czeka na wynik
Stosuj, gdy odpowiedź jest potrzebna natychmiast
Asynchroniczna: wywołujący przekazuje zadanie i wraca do pracy
Stosuj przy zadaniach wolnych, nieregularnych lub niepiln ych

Wywołanie synchroniczne: wywołujący zablokowany do nadejścia odpowiedzi po lewej versus asynchroniczne przekazanie zadania z natychmiastowym powrotem i przetwarzaniem w tle po prawej

Wzorce odporności przy wywołaniach zewnętrznych

Ponowna próba z wykładniczym wycofaniem: coraz dłuższe przerwy między próbami
Wyłącznik: tymczasowe wstrzymanie wywołań do niesprawnej usługi
Kolejka niedostarczonych wiadomości: przechowuje wiadomości, których nie udało się przetworzyć
Łącz te wzorce; masowe ponowne próby nasilają awarie

Trzy wzorce odporności: krzywa wykładniczego wycofania, wyłącznik wstrzymujący wywołania do niesprawnej usługi oraz kolejka niedostarczonych wiadomości przechwytująca wiadomości po wyczerpaniu prób

Czas na praktykę!

Wdrażanie aplikacji na AWS