Ocena niezawodności środowiska SaaS za pomocą AWS Well-Architected SaaS Lens

30 kwietnia 2021

Filar niezawodności rozwiązania AWS Well-Architected SaaS Lens koncentruje się na stanie niezawodności rozwiązania typu software-as-a-service (SaaS).

SaaS Lens pomaga klientom Amazon Web Services (AWS) ocenić ogólną niezawodność ich architektury SaaS, zapewniając wytyczne, które umożliwiają lepsze dostosowanie ich architektury do dobrych praktyk w zakresie niezawodności SaaS.

W środowiskach multi-tenant, każda przerwa w działaniu (outage) lub pogorszenie jakości obsługi może mieć wpływ na wszystkich klientów. W tym poście omówimy, jak uzyskać wgląd w stan środowiska SaaS i określonych tenantów, złagodzić możliwe przerwy i przetestować niezawodność komponentów systemu.

Zastosowanie dobrych praktyk opisanych w tym filarze umożliwi Twojej aplikacji SaaS obsługę nieprzewidywalnych wzorców użytkowania tenantów, odzyskanie sprawności po zakłóceniach infrastruktury lub usług oraz skalowanie w celu zaspokojenia zapotrzebowania na zasoby. Celem jest tutaj upewnienie się, że żaden z tenantów ani inne elementy systemu nie zostaną naruszone pod względem jakości usług.

Zagadnienia dotyczące niezawodności aplikacji SaaS

Podczas tworzenia lub optymalizacji rozwiązania SaaS pod kątem niezawodności, należy pamiętać o kilku kluczowych kwestiach. Podczas gdy niektóre dotyczą wszystkich nowoczesnych rozwiązań, inne są specyficzne dla modelu dostarczania SaaS i na tym skupiamy się w tym poście.

Filar niezawodności SaaS stanowi rozszerzenie istniejących zasad niezawodności Well-Architected. Aby dostosować się do pełnego zakresu sprawdzonych metod, upewnij się, że uwzględnisz te podstawowe praktyki w swoim przeglądzie. Aby uzyskać więcej informacji, zapoznaj się z opisem filaru niezawodności Well-Architected Framework.

Pytania dotyczące filaru niezawodności SaaS Lens są zgodne z ogólnymi zasadami projektowania Well-Architected powyżej, ale dotyczą wyjątkowych wyzwań w rozwiązaniach SaaS.

Istnieją trzy główne obszary, na których koncentrujemy się w filarze niezawodności SaaS Lens:

Hałaśliwy sąsiad

Obciążenia tenantów w środowisku multi-tenant mogą się nieustannie zmieniać. Najemcy mogą nałożyć na system różne rodzaje obciążeń. Nowi tenantowie z nowymi profilami obciążenia mogą być również stale dodawani do systemu. Czynniki te mogą utrudniać firmom SaaS tworzenie architektury, która jest wystarczająco odporna, aby reagować i odpowiadać na te zmieniające się potrzeby.

Termin noisy neighbor określa użytkownika systemu (tenanta), który obciąża system w taki sposób, aby obniżyć jakość usług, z których korzystają inni użytkownicy. Rozwiązanie multi-tenant powinno posiadać mechanizmy, które mogą wykrywać takie sytuacje i łagodzić je. Wprowadzając proaktywne konstrukcje do zarządzania warunkami dla noisy neighbor, rozwiązanie SaaS może zapewnić, że poziom jakości usług dla innych tenantów nie zostanie naruszony.

Widoczność stanu tenantu

Chociaż istnieje ogólna kondycja Twojego systemu, narzędzia operacyjne muszą również umożliwiać przeglądanie i ocenę kondycji poszczególnych tenantów i tierów. Uzyskanie wglądu w stan tenanta pozwala odkrywać i wykrywać problemy z niezawodnością, aktywnie im zapobiegać i utrzymywać odpowiednią jakość usług.

Tworzenie proaktywnego widoku kondycji w środowisku multi-tenant wymaga wyszukania dodatkowych danych dotyczących niezawodności, które zapewniają bardziej szczegółowe,  spostrzeżenia tenant-aware w trendy kondycji obciążeń tenantów. Te szczegółowe informacje służą do identyfikowania trendów tenant-specific, działań lub punktów, które mogą skutecznie uchwycić stan, który może mieć wpływ na niezawodność danego tenanta lub całego

Posiadanie tych danych umożliwia tworzenie alarmów, polityk i automatyzacji, które mogą próbować naprawić system bez powodowania przestoju.

Zautomatyzowane testy niezawodności

Istnieje wiele różnych wymiarów, które warto uwzględnić w strategii testowania dla multi-tenant. W wielu przypadkach testy te są ukierunkowane na weryfikację konstrukcji, które masz, aby uwzględnić skalę, operacje i wpływ na niezawodność produktu SaaS.

Należy zauważyć, że testowanie SaaS często polega na symulowaniu skrajności, z którymi może się spotkać Twoja aplikacja. Powinieneś skupić się na tworzeniu zestawu testów, które mogą skutecznie modelować i oceniać, jak Twój system zareaguje na oczekiwane i nieoczekiwane.

Wprowadzając nowe konstrukcje do zarządzania niezawodnością systemu SaaS, należy również przyjrzeć się, w jaki sposób można tworzyć testy automatyczne, które nieustannie oceniają, czy te konstrukcje działają zgodnie z oczekiwaniami. Można to zrobić, tworząc testy, które wykonują podstawowe procesy, takie jak dołączanie tenantów, aktualizacje systemu i zmiany konfiguracji.

Testowanie obciążenia multi-tenant i różnych wzorców aktywności generowanych przez wielu tenantów to kolejny rodzaj testowania, który pozwala upewnić się, że rozwiązanie SaaS może wykryć, przeciwstawić się i ograniczyć intensywne obciążenie lub nieprzewidziane działania generowane przez wielu tenantów.

Pytania dotyczące Well-Architected SaaS Lens

Teraz, gdy przyjrzałeś się niektórym kluczowym obszarom niezawodności SaaS, spójrzmy na pytania, których używa Well-Architected SaaS Lens do oceny zgodności z tymi praktykami.

Każdemu pytaniu towarzyszy krótkie podsumowanie zalecanych praktyk dla każdego tematu. Zawiera ono zestaw praktyk: Required, Good i Best, oraz odniesienia do odpowiednich treści związanych z omawianymi tematami.

Poniżej przedstawiono ogólny pogląd na zakres i cele każdego pytania. Aby uzyskać więcej informacji, zapoznaj się z sekcją dotyczącą filarów niezawodności w dokumencie SaaS Lens Whitepaper oraz w samym narzędziu AWS Well-Architected Tool. Wskazówki dotyczące poprawy obecnej postawy można znaleźć w planie doskonalenia SaaS Lens w narzędziu Well-Architected Tool.

Rysunek 1. Pytanie REL1 w narzędziu AWS Well-Architected Tool.

 

SaaS REL 1: Jak ograniczyć możliwość indywidualnego tenanta do narzucania obciążenia, które może mieć wpływ na dostępność dla innych tenantów Twojego systemu?

Określony tenant nie powinien mieć wpływu na jakość usług systemu lub innego tenatów. Aby to osiągnąć, będziesz musiał kontrolować ich aktywność w systemie.

  • Użyj zasad ograniczania przepustowości, aby ograniczyć wpływ, jaki noisy-tenants mają na system. Zidentyfikuj dzierżawców, którzy powodują nadmierne obciążenie, i użyj tych danych, aby zastosować zasady ograniczania przepustowości, aby upewnić się, że obciążenia jednego dzierżawcy nie mają wpływu na ogólną niezawodność systemu.
  • Zdefiniuj umowy SLA dla każdej warstwy tenantów. Wprowadź umowy SLA skonfigurowane dla każdego tiera tenanta obsługiwanego przez Twój system. Używaj umów SLA jako części strategii ograniczania przepustowości, aby ściśle kontrolować poziom aktywności i obciążenia, które tenanci/tiery mogą umieścić w systemie. Ta metoda zapewnia na przykład, że warstwa podstawowa w rozwiązaniu SaaS nie wpływa na niezawodność tenanta w tierze
  • Partycjonuj obciążenie tenanta w celu ograniczenia obszaru działania. Rozprowadzaj i/lub izoluj obciążenia, umożliwiając zasobom (na przykład zasoby obliczeniowe lub magazynowe) efektywne radzenie sobie z potencjalnie gwałtownymi obciążeniami. Metodę tę można zastosować do określonych komponentów systemu, które są bardziej wrażliwe lub z większym prawdopodobieństwem są narażone na wysokie lub nieprzewidywalne obciążenia. Można go również zastosować do określonych tierów tenanta, o których wiadomo, że mają nadmierne zużycie lub nietypowe wzorce użycia.

SaaS REL 2: Jak proaktywnie wykrywać i utrzymywać kondycję tenantów?

Niezawodne rozwiązanie SaaS obsługuje operacje tenant-aware, które umożliwiają proaktywne wykrywanie i rozwiązywanie problemów dotyczących tenanta i kondycji systemu.

  • Dodaj kontekst tenanta do logów aplikacji, aby aktywnie zarządzać jego kondycją. Upewnij się, że pliki logów zawierają kontekst tenanta. Ten kontekst służy do analizowania i proaktywnego identyfikowania problemów z jakością usług związanych z niezawodnością. Dzięki możliwości przeglądania tych logów, będziesz w stanie łatwo zidentyfikować określone działania tenanta, które mogą przyczyniać się do problemów z jakością usług specyficznych dla systemu lub tenanta.
  • Wprowadź szczegółowe informacje na temat tenanta, aby ulepszyć ekspertyzę kondycji. Publikuj szczegółowe dane dotyczące aktywności, zużycia, wydajności i błędów tenanta w scentralizowanym repozytorium, którego można użyć do analizowania wszelkich problemów z kondycją systemu lub trendów użycia, które mogą mieć wpływ na niezawodność.  Dane te mogą być również używane z innymi danymi dotyczącymi kondycji do diagnozowania i oceny trudniejszych zdarzeń związanych z niezawodnością multi-tenant.
  • Aktywnie identyfikuj problemy tenanta za pomocą polityk i alarmów. Połącz szczegółowe informacje na temat tenantów z politykami, aby proaktywnie wykrywać problemy, zanim wpłyną one na stabilność lub dostępność środowiska SaaS. Zasady te mogą wywoływać strategie samonaprawy dla poszczególnych tenantów i ujawniać krytyczne alerty/alarmy.

SaaS REL 3: Jak przetestować możliwości aplikacji SaaS dla multi-tenant?

SaaS wprowadza mechanizmy multi-tenant, które dodają nowe wymiary do śladu testowego aplikacji. Dołączanie, konfiguracja, noisy neighbor — to wszystko obszary, które mogą mieć wpływ na niezawodność Twojego systemu. Każdy z tych obszarów może i powinien zostać uwzględniony jako część ogólnej strategii testowania niezawodności środowiska SaaS.

  • Sprawdź rozmiar i dostępność noisy neighbor. Przetestuj różne warunki noisy neighbor, oceniając zdolność systemu do identyfikowania i reagowania na scenariusze, w których podzbiór tenantów nakłada nieproporcjonalne obciążenie na Twój system. Opracuj zestaw testów oceniających zdolność systemu do stosowania zasad skalowania, ograniczania i tierowania dla szeregu tierów i profili tenantów. Celem jest upewnienie się, że zasady dotyczące noisy neighbor działają zgodnie z oczekiwaniami.
  • Przećwicz kluczowe workflow’y pod obciążeniem multi-tenant. Zidentyfikuj workflow’y, które mogą być kluczowe dla doświadczenia klienta, i zaimplementuj testy, które sprawdzą zdolność Twojego systemu do obsługi umów SLA tych obciążeń dla szeregu obciążeń obejmujących multi-tenant. Oceń ogólną stabilność systemu, gdy tenanci lokują różne obciążenia na różnych poziomach aktywności.
  • Sprawdź skalę i powtarzalność wdrażania tenantów. Upewnij się, że środowisko wdrażania może niezawodnie i wielokrotnie dołączać tenantów o różnych wzorcach i konfiguracjach.
  • Upewnij się, że zmiany konfiguracji tenancy są pomyślnie rozpowszechnione. Sprawdź, czy system prawidłowo stosuje i rozprzestrzenia zmiany w konfiguracji tenantu. Na przykład zmiany stanu konta, takie jak status (aktywne/nieaktywne) i tier (na przykład tenant, który zaktualizował warstwę bezpłatną do warstwy premium) muszą być współdzielone między systemem rozliczeniowym a środowiskiem SaaS.
  • Sprawdź poprawność izolacji tenantu. Symuluj interakcje z systemem, aby sprawdzić, czy zasady i praktyki izolowania tenantu Twojego systemu zostały pomyślnie zastosowane. Uwzględnij testy, które badają scenariusze, w których kod dewelopera multi-tenant może przypadkowo przekroczyć granicę tenantu.

Aby uzyskać więcej informacji, zapoznaj się z sekcją dotyczącą filarów niezawodności w SaaS Lens Whitepaper.

Zacznij korzystać z Well-Architected SaaS Lens

AWS Well-Architected SaaS Lens koncentruje się na workloadach SaaS i ma na celu stymulowanie krytycznego myślenia w zakresie tworzenia i obsługi workloadów SaaS. Każde pytanie zawiera listę dobrych praktyk, a każda z nich zawiera listę planów ulepszeń, które pomogą Ci je wdrożyć.

Lens można zastosować do istniejących workloadów lub użyć do nowych, zdefiniowanych w narzędziu. Możesz użyć tej funkcji, aby ulepszyć aplikację, nad którą pracujesz, lub uzyskać wgląd w wiele workloadów używanych przez dział lub obszar, z którym pracujesz.

Funkcja Saas Lens dostępna jest we wszystkich regionach, w których oferowane jest narzędzie AWS Well-Architected Tool, godnie z opisem AWS Regional Services List. Korzystanie z narzędzia AWS Well-Architected Tool nie wiąże się z żadnymi kosztami.

Jeśli jesteś klientem AWS, znajdź obecnych Partnerów AWS, którzy mogą przeprowadzić przegląd, poznając AWS Well-Architected Partners i AWS SaaS Competency Partners.

O AWS Saas Factory

AWS SaaS Factory pomaga organizacjom na każdym etapie pracy z SaaS. Niezależnie od tego, czy chcesz tworzyć nowe produkty, migrować istniejące aplikacje lub optymalizować rozwiązania SaaS w AWS, AWS może Ci pomóc. Odwiedź centrum AWS SaaS Factory Insights Hub, aby odkryć więcej treści technicznych i biznesowych oraz dobrych praktyk.

Zachęcamy twórców SaaS do skontaktowania się ze swoim przedstawicielem handlowym w celu uzyskania informacji o modelach zaangażowania i współpracy z zespołem AWS SaaS Factory.

Zarejestruj się, aby być na bieżąco z najnowszymi wiadomościami SaaS, zasobami i wydarzeniami dotyczącymi AWS.

 

 

Case Studies
Referencje

Z przyjemnością polecamy firmę Hostersi, z którą mieliśmy przyjemność współpracować przy okazji wdrożenia skalowalnej infrastruktury w Amazon Web Services, opartej o technologię Kubernetes i metodykę DevOps.  Hostersi okazali się niezwykle proaktywnym partnerem, który nie tylko wdrażał wskazane rozwiązania, ale proponował optymalne narzędzia i technologie, które sprawiły, że efekt wdrożenia jest dla nas w pełni satysfakcjonujący. Polecamy!

Grzegorz Lentzy
IT Director LINK Mobility
W skrócie o nas
Specjalizujemy się w dostarczaniu rozwiązań IT w obszarach projektowania infrastruktury serwerowej, wdrażania chmury obliczeniowej, opieki administracyjnej i bezpieczeństwa danych.