Tworzenie rozwiązania Saas dla architektury multi-tenant przy użyciu Amazon EKS

Wraz z tym, jak coraz więcej organizacji wybiera model dostarczania oprogramowania jako usługi (SaaS), wiele z nich jako cel swoich rozwiązań wybiera Amazon Elastic Kubernetes Service (Amazon EKS).

Sposób programowania, efektywność kosztowa, bezpieczeństwo, wdrażanie i atrybuty operacyjne EKS stanowią kolejny przykuwający uwagę model dla dostawców SaaS.

Model EKS także przedstawia architektom i programistom SaaS zbiór nowych zagadnień związanych z wielodostępnością oprogramowania. Od teraz będziesz musiał rozważyć, jak podstawowe zasady SaaS (izolacja, wdrażanie, tożsamość) są realizowane w środowisku EKS.

Aby zapewnić bardziej przejrzysty obraz tego, w jaki sposób zbudowane są owe reguły, utworzone zostało próbne rozwiązanie EKS SaaS, które zapewnia zarówno programistom, jak i architektom działający przykład. To przedstawia sposób, w jaki najlepsze praktyki wielodostępności oprogramowania architektury i projektowania są wdrażane w środowisku EKS.

Z tego artykułu dowiesz się o najważniejszych elementach architektury przykładowej dotyczących architektury EKS. Zapoznasz się z tym, w jaki sposób wyizolować tenants (dzierżawców) w klastrze EKS, zautomatyzować wdrażanie tenants, zarządzać ich tożsamościami oraz obsługiwać routing obciążeń dzierżawców.

To rozwiązanie obejmuje pełne, aktywne doświadczenie z próbną aplikacją SaaS i konsolą administracyjną, która zarządza Twoim środowiskiem SaaS.

Wybór modelu izolacji

Istnieje niezliczona ilość sposobów projektowania i budowania wielodostępności programowania rozwiązania SaaS dla Amazon EKS, z których każdy posiada własny zestaw kompromisów. Wraz z EKS posiadasz wiele możliwości wyboru, które mogą wpłynąć na nakład pracy, złożoność operacyjną oraz efektywność kosztową.

Jako przykład, niektórzy mogą zdecydować się na zastosowanie modelu cluster-per-tenant, aby wyizolować swoich dzierżawców. To zapewniałoby prostą historię izolacji, ale może także wiązać się z dość wysokimi kosztami.

Inni mogą używać współdzielonego modelu obliczeniowego, gdzie wszyscy tenants są umieszczani w klastrze i przestrzeni nazw, a izolacja obsługiwana jest na poziomie aplikacji. Jak można się spodziewać, zapewnia to dużą efektywność operacyjną i kosztową. Dodatkowo reprezentuje to także mniej istotny model izolacji.

W samym środku tych dwóch skrajności znajduje się izolacja przestrzeni nazw na dzierżawcę, gdzie każdy z dzierżawców jest wdrażany w tym samym klastrze, ale oddzielony od siebie za pomocą przestrzeni nazw oraz szeregu natywnych i dodatkowych konstrukcji Kubernetes. Jest to powszechnie określane jako model „silosu”, w którym zasoby tenants nie są przez nich dzielone.

Ten model namespace-per-tenant reprezentuje dobre połączenie izolacji i efektywności kosztowej. Z tego powodu zdecydowano się na zaimplementowanie tego modelu w przykładowym rozwiązaniu EKS SaaS. Wybór ten ostatecznie posiada znaczący wpływ na nasze rozwiązanie, w tym dołączanie tenants, izolację oraz routing ruchu dzierżawców.

Architektura wysokiego poziomu

Zanim zagłębisz się w szczegóły rozwiązania SaaS EKS, warto przyjrzeć się wysokopoziomowym elementom architektury używanym przez to przykładowe rozwiązanie. Poniżej zobaczysz każdą z warstw, które są częścią rozwiązania EKS SaaS.

Rysunek 1: Architektura koncepcyjna

Na początku mamy 3 różne rodzaje aplikacji, które są częścią EKS SaaS. Są one powiązane z popularnymi typami aplikacji, które znajdziesz w wielu środowiskach SaaS. Pierwsza z aplikacji, strona docelowa, reprezentuje stronę publiczną, na której klient może znaleźć i zapisać się na rozwiązanie. Nowi klienci mogą trafić na tę stronę, zapoczątkować proces rejestracji i utworzyć nowy tenant w systemie.

Kolejna aplikacja jest przykładem aplikacji handlowej. Została tutaj utworzona prosta aplikacja e-commerce, która zapewnia podstawową funkcjonalność dotyczącą zamówień oraz produktów podczas komunikacji z mikrousługami specyficznymi dla tenant podczas obsługi klastra EKS. To właśnie dlatego w tym miejscu zamieszczasz aplikację SaaS dla modelu multi-tenant.

Ostatnią aplikacją jest konsola administracyjna dostawcy SaaS, która także wykorzystuje Amazon Cognito do kontroli dostępu. Jako dostawca SaaS będziesz korzystał z tej aplikacji w celu skonfigurowania i zarządzania swoimi zasadami i ustawieniami tenant. Każda z tych aplikacji współdziała z usługami, które działają w klastrze EKS.

Istnieją dwie różne kategorie usług, które działają w tym klastrze. Po pierwsze warstwa współdzielonych usług reprezentuje wszystkie typowe usługi niezbędne do obsługi wszystkich funkcji operacyjnych, zarządzania, tożsamości, wdrażania i konfiguracji środowiska SaaS.

Pozostała kategoria usług stanowi część zarządzanych środowisk tenants. Usługi działające w tym miejscu reprezentują różne wdrożone środowiska dzierżawców, które obsługują mikrousługi naszej aplikacji. Istnieją tam oddzielne wdrożenia systemu dla każdego z tenants. Poniżej zostanie przedstawione racjonalne uzasadnienie decyzji dotyczącej architektury.

Co jest zaopatrywane?

Teraz, kiedy rozumiesz już architekturę wysokiego poziomu, pora przejść na bardziej zaawansowany poziom w celu zapoznania się z tym, co jest zaopatrywane podczas instalacji rozwiązań EKS SaaS.

Infrastruktura podstawowa

Zanim zajmiesz się tenants i aplikacjami, należy wdrożyć podstawową wersję środowiska.

Poniższa infrastruktura obejmuje rzeczywisty klaster EKS, który obsługuje usługę. Oprócz tego zawiera wymaganą infrastrukturę pomocniczą, taką jak role AWS Identity and Access Management (IAM), dystrybucje Amazon CloudFront oraz zapasowe zasobniki Amazon Simple Storage Service (Amazon S3).

Rysunek 2: Infrastruktura podstawowa

Klaster EKS, wraz z odpowiadającą mu wirtualną chmurą prywatną (VPC), podsieciami i bramami sieciowymi NAT, zostaje wdrożony poprzez narzędzie eksctl CLI tool. Ten interfejs wiersza poleceń (CLI) usprawnia tworzenie różnych skryptów AWS CloudFormation wymaganych do wdrożenia gotowego do użycia klastra EKS. Klaster ten obsługuje współużytkowane środowiska tenants dla Twojego rozwiązania EKS SaaS.

Pomimo że zostały wykorzystane wspólne wzorce konfigurowania i wdrażania klastra, być może będziesz chciał zastanowić się nad tym, jak dodatkowo zabezpieczyć sieć i klaster w oparciu o specyficzne potrzeby Twojego środowiska. Dowiedz się więcej o najlepszych praktykach tworzenia w pełni zabezpieczonego klastra EKS.

Kiedy klaster jest już zainstalowany, należy wdrożyć w nim szereg obiektów Kubernetes API, w tym kontroler danych wejściowych NGINX typu open-source i zewnętrzny DNS (External DNS).

Kontroler wejściowy odgrywa bardzo ważną rolę, pomagając kierować żądania multi-tenant z aplikacji klienta. Działa w tandemie zewnętrznym DNS, który automatycznie tworzy wpisy DNS Amazon Route 53 dla dowolnych subdomen, do których odwołują się zasoby wejściowe.

W Twoim przypadku to jedynie api.DOMAIN.com. Przywołana tutaj domena reprezentuje domenę niestandardową, którą skonfigurujesz w trakcie wdrażania.

Ta podstawa struktura obejmuje Amazon S3 i jest miejscem, w którym każda z aplikacji internetowych w tym rozwiązaniu jest hostowana przez statyczne witryny internetowe. Do dystrybucji wykorzystuje się CloudFront z niestandardowymi nazwami domen w celu dystrybucji treści. Każda strona internetowa jest tworzona i kopiowana do właściwego zasobnika S3 po wdrożeniu.

Oprócz zasobników S3 i obsługujących usługi CloudFront baseline stack dostarcza certyfikat typu wildcard odpowiadający niestandardowej nazwie domeny podanej podczas wdrażania. Ten certyfikat używany jest w celu zapewnienia połączeń HTTPS do wszystkich publicznych jednostek sieciowych w tym rozwiązaniu, włączając w to trzy aplikacje sieciowe opisane powyżej, a także publicznie udostępniane i sprecyzowane usługi internetowe.

Konfiguracja tego podstawowego środowiska obejmuje także wdrażanie części usług współdzielonych w środowisku SaaS (rejestracja, zarządzanie tenant i zarządzanie użytkownikami). Wspierają one zdolność do wdrażania i zarządzania tenants oraz zarządzania administratorami i użytkownikami dzierżawców.

Współdzielone usługi posiadają zależności oparte na różnych zasobach AWS. Zarządzanie tenants magazynuje i zarządza informacjami o dzierżawcach w tabeli Amazon DynamoDB. User managements zarządza użytkownikami przechowywanymi w Cognito.

Wszystkie mikrousługi działające w EKS są implementowane w Java Spring Boot. Podczas wdrażania stosu bazowego dla każdej mikrousługi systemu tworzone jest repozytorium Amazon Elastic Container Registry (Amazon ECR). W czasie wdrażania każda usługa jest tworzona i umieszczana w odpowiednim repo.

Ostatnim krokiem w konfiguracji podstawowej jest dodanie rekordów Amazon Route 53 DNS do dwóch z trzech aplikacji internetowych w tym rozwiązaniu. Konsola administratora jest konfigurowana jako admin.DOMAIN.com, a strona docelowa zostaje skonfigurowana jako www.DOMAIN.com. Przykładowa strona aplikacji e-commerce nie otrzymuje alias Route 53, dopóki nie zostanie wdrożony tenant.

Infrastruktura dzierżawcy

Po utworzeniu infrastruktury bazowej możesz rozpocząć planowanie infrastruktury, która będzie niezbędna do obsługi dzierżawców, gdy są dołączani do aplikacji SaaS.

Wybrana uprzednio architektura używa modelu namespace-per-tenant do zaimplementowania izolacji, która wymaga wdrożenia oddzielnych zasobów do każdego tenant. Poniżej znajduje się bardziej szczegółowe objaśnienie.

Rysunek nr 3: Wdrażanie mikrousług tenants

Powyższa architektura przedstawia sposób, w jaki mikrousługi aplikacji zostają wdrożone do infrastruktury podstawowej. Umieszczono je w tym samym klastrze, który był użyty w celu wdrożenia współdzielonych usług środowiska. Kluczową różnicę stanowi fakt, że żadna z tych mikrousług i przestrzeni nazw nie zostaje utworzona, dopóki nie zostanie wdrożony tenant.

Oczywiście konstrukcje niezbędne do „ożywienia” tych mikrousług posiadają więcej ruchomych części. Poniższy diagram obrazuje bardziej szczegółowy widok na elementy w środowisku dzierżawcy.

Rysunek nr 4: Infrastruktura tenant

Przyglądając się podstawowemu przepływowi, widzisz zasoby wykorzystywane przez aplikację SaaS w celu uzyskania dostępu do każdej z przestrzeni nazw tenants. Oddzielne pule i domeny użytkowników są wykorzystywane do uwierzytelnienia i przekierowywania tenants do Twojego środowiska.

Gdy przemieścisz się na dół, rozwiązanie wykorzystuje kontroler NGINX do przekierowywania ruchu na Twoje przestrzenie nazw. Inne rozwiązanie, jakie może zostać tutaj wykorzystane, to niedawno wydany AWS Load Balancer Controller.

Usługi w zakresie zamówień i produktów stanowią zaplecze dla przykładowej aplikacji e-commerce. Podczas gdy serwisy te są wdrażane z repozytorium ECR, które jest współdzielone przez wszystkich tenants, każdy z nich otrzymuje własną kopię tych mikrousług, które są konfigurowane przy użyciu informacji specyficznych dla dzierżawcy w czasie wdrażania.

Wszystkie z artefaktów specyficznych dla dzierżawców, w tym mikrousługi i zasoby przechodzące NGINX, są wdrażane do własnej przestrzeni nazw. Do konta usługi tenant przypisuje się zarówno zasady uprawnień, jak i zasady zabezpieczeń sieci w celu dodatkowego bezpieczeństwa.

Usługi AWS Code*, przedstawione na dole rysunku nr 4, są używane jako „maszyna”, która organizuje konfigurację i wdrażanie tych obiektów w klastrze EKS. Projekty Code* są zdefiniowane jako zasoby CloudFormation z parametrami, które służą jako symbole zastępcze dla danych specyficznych dla tenants.

Po prawej stronie znajdują się tabele DynamoDB. Twórcy chcieli przedstawić wiele przykładów partycjonowania danych w rozwiązaniu EKS SaaS. Przykładowo mikrousługa zamówień wykorzystuje model partycjonowania magazynu silosu, w którym tenant posiada oddzielną tabelę DynamoDB. Dla każdego nowego dzierżawcy dodanego do systemu tworzona jest nowa tabela zamówień.

Mikrousługa produktu korzysta z modelu partycjonowania w puli, w którym dane dzierżawców są pomieszane w tej samej tabeli i dostępne za pośrednictwem klucza partycji wypełnionego identyfikatorem tenant.

Mikrousługa produktu korzysta z modelu partycjonowania w puli, w którym dane dzierżawców są pomieszane w tej samej tabeli i dostępne za pośrednictwem klucza partycji wypełnionego identyfikatorem tenant.

Wdrażanie dzierżawców

Nowi dzierżawcy zostają zapoznani z systemem poprzez bezproblemowy onboarding, który organizuje wszystkie usługi wymagane do skonfigurowania i uruchomienia tego dzierżawcy. Posiadanie zautomatyzowanego środowiska onboardingowego o niskim współczynniku tarcia stanowi klucz do umożliwienia dostawcom SaaS posiadania powtarzalnego, skalowalnego mechanizmu wprowadzania nowych tenants.

W przypadku tego rozwiązania twórcy posiadają wiele ruchomych części, które są uwzględnione w procesie onboardingu. Na początek należy utworzyć nowy tenant i użytkownika administracyjnego dla tego dzierżawcy. Następnie należy skonfigurować przestrzeń nazw Kubernetes i zasad dla dzierżawcy oraz wdrożyć mikrousługi aplikacji dla tej przestrzeni nazw.

Rysunek nr 5 przedstawia proces wdrażania. Rozpoczyna się on od wypełnienia formularza rejestracyjnego, symulującego typową stronę, którą zaproponowałbyś jako publiczną ofertę dla nowych dzierżawców. Wdrożenie może zostać wywołane przez aplikację administracyjną.

Uwzględniliśmy ten przepływ, aby zilustrować, jak by to wyglądało, gdyby to samo doświadczenie wdrożeniowe było zarządzane przez wewnętrzny proces. Kluczowym wnioskiem jest to, że obydwa procesy opierają się na tym samym mechanizmie wdrażania dzierżawcy do systemu.

Rysunek nr 5: Wdrażanie dzierżawców

Poniższe kroki zarysowują sekwencję wydarzeń, które są zaangażowane w trakcie procesu wdrażania dzierżawcy.

1. Usługa rejestracji dzierżawcy otrzymuje żądanie ze strony docelowej lub aplikacji administratora, która zawiera dane dołączenia dzierżawcy.
2. Usługa rejestracji wywołuje usługę zarządzania tenants w celu zarejestrowania szczegółów dzierżawcy w Amazon Dynamo DB.
3. Usługa rejestracji tworzy nową pulę użytkowników dla dzierżawcy.
4. Usługa rejestracji wywołuje usługę zarządzania użytkownikami w celu utworzenia użytkownika administracyjnego tenant w nowo utworzonej puli użytkowników.
5. Usługa rejestracji rozpoczyna świadczenie usług aplikacji dzierżawcy, korzystając z AWS CodePipeline i AWS CodeBuild w celu zorganizowania wdrażania zasobów dzierżawcy. Obejmuje to zarówno tworzenie przestrzeni nazw dla dzierżawcy oraz wdrażanie mikrousług produktu i zamówienia w przestrzeni nazw dzierżawcy.
6. Zasady zabezpieczeń izolacji dzierżawcy zostają stosowane na poziomie sieci i danych.

Poza izolacją przestrzeni nazw

Tak jak opisano wcześniej, twórcy wykorzystują model namespace-per-tenant w celu utworzenia warstwy izolacji dla dzierżawców oraz ich zasobów w klastrze Amazon EKS.

Przestrzeń nazw Kubernetes domyślnie nie zapewnia granicy mocnej izolacji dla zasobów, które znajdują się w tej przestrzeni nazw. Muszą zostać wprowadzone dodatkowe konstrukcje, aby zapobiec dostępowi między dzierżawcami.

Rysunek nr 6: Izolacja dzierżawców

W tym przykładzie użyliśmy zabezpieczeń pod i zasad sieciowych, aby zapobiec dostępowi między dzierżawcami na poziomie przestrzeni nazw pod. Wykorzystano role IAM dla Service Account w celu wymuszenia izolacji.

To podejście wprowadza izolację poświadczeń, zapewniając, że kontener może pobierać tylko poświadczenia dla roli IAM, które zostały skojarzone z kontem usługi, do której przynależy. Oznacza to, że kontener nigdy nie może uzyskać dostępu do poświadczeń dla kontenera, który przynależy do innego podu działającego w innej przestrzeni nazw.

Przemieszczając się w dół do rysunku nr 6, możesz zobaczyć, w jaki sposób stosuje się izolację, gdy każda przestrzeń nazw próbuje uzyskać dostęp do innego zasobu dzierżawcy (w tym przypadku tabeli DynamoDB). Istnieją dwa różne warianty izolacji dla produktu i zamówień.

W przypadku mikrousługi zamówień każdy z dzierżawców posiada oddzielną tabelę zamówień (wykorzystywaną jako model magazynu silosowego). Twórcy posiadają zasady uprawnień, które ograniczają dostęp na poziomie tabeli.

Mikrousługa produktu posiada jedną tabelę dla wszystkich dzierżawców. W tym scenariuszu zasady IAM ograniczają dostęp do rzeczywistych pozycji w tabeli.

Podczas gdy te konstrukcje pomagają wymusić dany model izolacji, będziesz również musiał przemyśleć to, w jaki sposób izolować je na poziomie sieci. Domyślnie cały ruch pod-to-pod w Kubernetes jest dozwolony i bez kontroli wszystkie pody mogą swobodnie komunikować się z innymi podami w obrębie przestrzeni nazw w klastrze EKS oraz między nimi.

Aby zapobiec sytuacji otrzymania dostępu w przestrzeni nazw, twórcy wdrożyli zasady sieciowe przy użyciu Tigera Calico, które umożliwiają izolację sieci poprzez zastosowanie szczegółowych zasad sieciowych na poziomie przestrzeni nazw.

Wnioski

W tym poście zostały omówione niektóre kluczowe kwestie, które mogą wpłynąć na sposób podejścia do projektowania i budowania rozwiązań SaaS wraz z Amazon EKS. Powinno być zrozumiałe, że energia i elastyczność także wymagają znalezienia kreatywnych sposobów realizacji niektórych podstawowych zasad architektonicznych SaaS.

Im bardziej zagłębiasz się w prezentowaną tutaj przykładową aplikację SaaS, otrzymujesz lepszy obraz całościowego doświadczenia związanego z budowaniem kompletnego, działającego rozwiązania EKS SaaS w AWS. To powinno zapewnić Ci dobry start, a jednocześnie umożliwić kształtowanie go w oparciu o zasady, które są zgodne z potrzebami środowiska SaaS.

Aby dokładniej przyjrzeć się temu rozwiązaniu, zapoznaj się z repozytorium rozwiązań. Znajdziesz tam instrukcje wdrażania krok po kroku, a także przewodnik skoncentrowany na programowaniu, który pomoże Ci zrozumieć wszystkie ruchome elementy środowiska.

Dowiedz się więcej o SaaS Factory

Twórcy zachęcają niezależnych producentów oprogramowania do skontaktowania się z przedstawicielem AWS Partner Network (APN) w celu uzyskania informacji na temat współpracy z zespołem AWS SaaS Factory. Dodatkowe, najlepsze praktyki można uzyskać za pośrednictwem AWS SaaS Factory.

źródło: AWS