Wyślij zapytanie Dołącz do Sii

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.

fragment kodu
Architektura jako kod
Ryc. 1 Architektura jako kod

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ć.

Przykładowe połączenia podejścia multi-tenant z modularyzacją
Ryc. 2 Przykładowe połączenia podejścia multi-tenant z modularyzacją

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.

Tworzenie subdomen w usłudze DNS
Ryc. 3 Tworzenie subdomen w usłudze DNS

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.

Serwis Azure Front door - działanie
Ryc. 4 Serwis Azure Front door – działanie

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.

Uwierzytelnienie Azure AD B2C
Ryc. 5 Uwierzytelnienie Azure AD B2C
Uwierzytelnianie w AAD (B2C) dedykowane dla konkretnego tenanta
Ryc. 6 Uwierzytelnianie w AAD (B2C) dedykowane dla konkretnego tenanta

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.

App service - regiony
Ryc. 7 App service – regiony

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:

fragment kodu
fragment kodu

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.

Schemat działania Storage accounts, kontenerów i plików
Ryc. 8 Schemat działania Storage accounts, kontenerów i plików

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.

Różnica pomiędzy SQL Server Azure a SQL Server elastic pool
Ryc. 9 Różnica pomiędzy SQL Server Azure a SQL Server elastic pool

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.

Ocena:
Autor
Avatar
Filip Kostrzewa

Architekt oprogramowania w Sii specjalizujący się w technologiach .NET oraz Azure. W wolnym czasie spekuluje na giełdzie, gra w szachy superbłyskawiczne i pokera

Zostaw komentarz

Twój adres e-mail nie zostanie opublikowany.

Może Cię również zainteresować

Pokaż więcej postów

Bądź na bieżąco

Zapisz się do naszego newslettera i otrzymuj najświeższe informacje ze świata Sii.

Otrzymaj ofertę

Jeśli chcesz dowiedzieć się więcej na temat oferty Sii, skontaktuj się z nami.

Wyślij zapytanie Wyślij zapytanie

Get an offer

Natalia Competency Center Director

Dołącz do Sii

Znajdź idealną pracę – zapoznaj się z naszą ofertą rekrutacyjną i aplikuj.

APLIKUJ APLIKUJ

Join Sii

Paweł Process Owner

ZATWIERDŹ

This content is available only in one language version.
You will be redirected to home page.

Are you sure you want to leave this page?