Według definicji aplikacja multi-tenant pozwala użytkownikom należącym do wielu tenantów korzystać ze współdzielonej instancji oprogramowania. Dzięki temu możemy oszczędzić sporo kosztów, gdyż stosując osobne aplikacje dla każdego tenanta, koszty pomnożą się o liczbę tenantów.
Infrastructure as code (IaC)
Aby uniknąć manualnych prac w zakresie devops, najlepszym podejściem jest IaC, realizowany w Azure za pomocą ARM templates. Do niedawna standardem ARM templates był format JSON, ale pojawił się nowy język mocno promowany przez Mocrosoft, mianowicie Bicep.
Bicep ma jedną przewagę nad poprzednikiem, która jest nieoceniona przy rozwiązaniach multi-tenant. Jest to możliwość definiowania pętli w kodzie. Dzięki temu możemy stworzyć generyczny kod, który bazując na kolekcji nazw lub konfiguracji tenantów, tworzy instancje serwisu w kontekście każdego tenanta.
Z punktu widzenia współczesnego podejścia do architektury oprogramowania, tendencje są takie, aby raczej tworzyć wiele niezależnych instancji, gdyż wówczas minimalizujemy skutki awarii oprogramowania. Jeśli zawiedzie jedna instancja, to dalej przy dobrej architekturze pozostałe powinny działać.
Postaram się na przykładzie rozwiązań opartych o serwisy Azure, pokazać różne sposoby połączenia podejścia multi-tenant z modularyzacją. Powyższy diagram przedstawia, jak mogłoby wyglądać takie rozwiązanie.
DNS
Jeżeli mamy aplikację internetową z zarejestrowaną domeną (domena.com), to możemy stworzyć w usłudze DNS subdomeny dla każdego tenanta: tenant1.domena.com, tenant2.domena.com … Subdomeny rejestrujemy jako wpisy CNAME wskazujące na serwis Azure front door. W ten sposób każdy tenant wysyła żądanie do tego serwisu z informacją kim jest – identyfikuje go subdomena.
Front door
Serwis Azure front door nie jest jedynym możliwym rozwiązaniem, ale z kilku powodów najlepszym. Jest serwisem globalnym, czyli definiując go w Azure, nie podajemy konkretnego regionu. Wysyłając żądanie, zostajemy przekierowani do najbliższej brzegowej instancji front door, która używając firewalla, silnika reguł oraz routera, zweryfikuje nas oraz ewentualnie przekieruje do odpowiedniej usługi app service.
Front door potrafi dodać do żądania HTTP(S) dodatkowe informacje, bazując na zdefiniowanych regułach. Nie musimy tego robić, jeśli dla każdego tenanta używamy innej subdomeny, gdyż wówczas w app service możemy przeczytać adres z nagłówka HTTP – Referer i bazując na tej informacji, możemy wybrać elementy konfiguracji w kontekście tenanta.
Front door posiada także wbudowany globalny load balancer, który w połączeniu z możliwościami skalowania app service, umożliwia bardzo szybkie przesyłanie żadań i opowiedzi. Używając Azure front door, dobrą praktyką jest zablokowanie na firewallach we wszystkich usługach app service pakietów sieciowych z innym źródłem/punktem przeznaczenia niż front door. W ten sposób mocno podniesiemy poziom bezpieczeństwa.
Azure Active Directory Business to Customer (AAD B2C)
Mimo że front door przekierowuje nas bezpośrednio do app service, to bardzo często app service wymaga, abyśmy się uwierzytelnili. W związku z tym zanim zdążymy zobaczyć jakąkolwiek stronę aplikacji, zostajemy przekierowani do identity service – w przypadku Azure jest to przeważnie Active Directory lub Active Directory Business to Customer.
Druga opcja daje większe możliwości. W zależności od potrzeb poszczególnych tenantów możemy mieć jeden identity service dla wszystkich tenantów, osobny dla każdego lub coś pomiędzy. Aby umożliwić uwierzytelnianie w AAD (B2C) dedykowanym dla konkretnego tenanta, możemy uwarunkować wartości konfiguracji AAD (B2C) w app service od informacji wysłanych w oryginalnym żądaniu lub dodanych przez front door.
App service
Jak wspomniałem, możemy posiadać wiele instancji app service w jednym lub wielu regionach. Niezależnie od lokalizacji, mamy możliwość optymalizacji kosztów za pomocą serwisu app service plan. Jeden plan w zależności od wybranego pricing tier, może zawierać od 10 do nieograniczonej liczby aplikacji oraz skalować się nawet do 100 instancji w najwyższym planie.
Kiedy do app service dotrze request, przeważnie mamy w nim dodatkowe informacje identyfikujące tenanta. Aplikacja osadzona w app service używa tych danych do wybrania odpowiedniej konfiguracji. Sama konfiguracja przeważnie zapisana jest w usłudze key vault. App service odczytuję ją jednorazowo przy uruchomieniu serwera WWW.
Key vault
Przechowujemy tu najbardziej wrażliwe dane takie jak hasła, klucze i connection stringi do baz danych oraz storage. Ponieważ dobrą polityką jest posiadanie oddzielnych baz danych oraz storage dla poszczególnych tenantów, również konfiguracja zapisana w key vault powinna być oddzielna dla każdego tenanta. Wydawałoby się, że możliwości key vault, który przechowuje proste pary klucz-wartość, nie dają takich opcji. Istnieje jednak sposób na struktury drzewaste:
Bazy danych i storage
App service prawie zawsze potrzebuje persystencji danych. Najczęściej używane są tutaj serwisy Azure storage oraz SQL Server, chociaż ostatnio coraz większą popularność zyskują rozwiązania typu NoSQL, na przykład Cosmos DB. Storage daje pewne możliwości multi-tenancy, nawet w ramach pojedynczego serwisu, za sprawą kontenerów. Jednak bardziej naturalne wydaje się posiadanie wielu storage accounts. Aby zaoszczędzić, można mieć jeden storage account z wieloma kontenerami zawierającymi pliki, czyli blobs.
SQL Server w Azure można zamodelować na kilka sposobów. Jeżeli chcemy mieć wiele instancji baz danych, musimy mieć na względzie koszty, gdyż akurat SQL Server w Azure do tanich nie należy. Aby zaoszczędzić, warto zastanowić się nad serwisem SQL Server elastic pool. Wówczas definiujemy maksymalne rozmiary dla samego poola, a zdefiniowane w nim bazy danych muszą mieścić się w tych ramach.
Możemy także zdefiniować reguły skalujące. Koszty naliczane są na podstawie parametrów elastic pool, a nie poszczególnych instancji baz danych.
Podsumowanie
Opisane przeze mnie rozwiązanie jest tylko jednym z wielu możliwych. Multi-tenancy, w zależności od skali i możliwości systemu, może używać innych, nieopisanych przeze mnie serwisów Azure, takich jak:
- kolejki,
- serwery mail,
- szyny danych,
- app functions,
- logic apps
- i wiele innych.
Podobnie jak w opisanych przykładach będziemy mogli wybrać pomiędzy współdzieleniem serwisu przez tenanty, osobnymi instancjami per tenant lub kombinacjami obu.
Finalnie, będzie to zawsze jakaś analogia do serwisów które opisałem. Najważniejsze, aby podjęte decyzje były przemyślane i oparte o rzeczywiste potrzeby i wymagania.
***
Jeśli interesuje Cię tematyka Azure, polecamy również inne artykuły naszych specjalistów np.: Azure Arc – rozwiązanie dla infrastruktury hybrydowej i multicloud, Skalowalny monitoring dla środowisk Azure oraz Usługi Azure Policy i Azure Blueprint.
Zostaw komentarz