multi-tenant environment

Multi-tenant environment to środowisko współdzielone przez wielu klientów, w którym kluczowa jest izolacja ich danych.

Architektura środowiska współdzielonego przez wielu klientów

Multi-tenant environment, czyli środowisko wielodzierżawne, to sposób organizacji aplikacji, w którym jedna działająca instancja systemu obsługuje wielu niezależnych klientów. Każdy klient jest nazywany tenantem lub dzierżawcą. Wspólne mogą być procesy aplikacji, serwery, usługi sieciowe, pamięć masowa albo baza danych, lecz dane, konfiguracja i uprawnienia poszczególnych tenantów muszą pozostać logicznie rozdzielone. Dzięki temu nie trzeba uruchamiać całego stosu oprogramowania oddzielnie dla każdego odbiorcy.

Ważną cechą takiej architektury jest rozróżnienie między współdzieleniem zasobów a współdzieleniem danych. Wspólny proces aplikacji może wykonywać żądania wielu klientów, ale każde żądanie powinno mieć jednoznacznie ustalony identyfikator tenanta. Ten identyfikator jest następnie używany przy odczycie i zapisie rekordów, wyborze konfiguracji, naliczaniu limitów oraz kontroli dostępu. Sam fakt, że użytkownik przesłał identyfikator w parametrze żądania, nie może być uznany za wystarczające potwierdzenie jego uprawnień.

Izolacja danych i zakres uprawnień

Izolacja w środowisku multi-tenant może być realizowana na kilku poziomach. Dane mogą znajdować się we wspólnej bazie z kolumną identyfikującą tenanta, w osobnych schematach tej samej bazy albo w oddzielnych bazach danych. Wspólna tabela z polem tenant_id upraszcza zarządzanie infrastrukturą, ale wymaga konsekwentnego uwzględniania tego pola w zapytaniach. Błąd w jednym filtrze może spowodować zwrócenie rekordu należącego do innego klienta.

Kontrola dostępu powinna obejmować zarówno użytkownika, jak i kontekst tenanta. System uwierzytelnia osobę lub usługę, a następnie ustala, do którego tenanta należy sesja i jakie role są w tym zakresie dostępne. Autoryzacja sprawdza nie tylko to, czy dana osoba ma prawo wykonać określoną operację, lecz także czy operacja dotyczy właściwego zbioru danych. Szczególnej uwagi wymagają zadania wykonywane w tle, eksporty, raporty, mechanizmy wyszukiwania, pamięć podręczna oraz pliki tymczasowe, ponieważ mogą działać poza typowym cyklem obsługi żądania.

Wydajność, limity i obserwowalność tenantów

Wspólne zasoby oznaczają, że intensywne działanie jednego klienta może wpływać na pozostałych. Dlatego środowiska wielodzierżawne stosują limity liczby żądań, ograniczenia wielkości plików, limity miejsca, kolejki zadań oraz kontrolę równoległości. Mechanizmy te nie zastępują izolacji danych, ale ograniczają ryzyko, że pojedynczy tenant zużyje cały dostępny procesor, pamięć, przepustowość dysku lub czas pracy usługi.

Monitoring powinien umożliwiać przypisanie zdarzenia do konkretnego tenanta bez rejestrowania wrażliwej treści danych. Przydatne są między innymi czasy odpowiedzi, liczba błędów, liczba operacji, zużycie przestrzeni, długość kolejki i odrzucone żądania. Logi aplikacyjne muszą zachowywać spójny identyfikator korelacyjny, aby można było odtworzyć przebieg pojedynczej operacji przez warstwę wejściową, logikę biznesową i magazyn danych. Jednocześnie logowanie identyfikatorów tenantów wymaga ograniczenia dostępu do samych logów, ponieważ mogą one ujawniać strukturę klientów oraz sposób korzystania z systemu.

Diagnostyka błędów w środowisku multi-tenant

Diagnozę problemu należy rozpocząć od ustalenia, czy błąd dotyczy jednego tenanta, czy całej współdzielonej usługi. Awaria widoczna u wielu klientów może wskazywać na problem z aplikacją, połączeniem do bazy, konfiguracją wspólnego komponentu albo wyczerpaniem zasobów. Błąd ograniczony do jednego tenanta częściej wiąże się z jego konfiguracją, uprawnieniami, limitem, uszkodzonym rekordem lub nieprawidłowym mapowaniem identyfikatora. Nie jest to jednak reguła, ponieważ wadliwy filtr w zapytaniu może ujawnić się dopiero przy określonym układzie danych.

Podczas sprawdzania należy porównać identyfikator tenanta zapisany w sesji, identyfikator przekazany do warstwy aplikacji oraz warunek użyty w zapytaniu do magazynu danych. Warto również przeanalizować zadania asynchroniczne, cache i mechanizmy eksportu, ponieważ tam kontekst tenanta może zostać utracony albo zastąpiony wartością domyślną. Zmiana konfiguracji powinna być testowana na danych testowych reprezentujących więcej niż jednego klienta. W środowisku produkcyjnym nie należy usuwać danych ani wykonywać szerokich modyfikacji bez potwierdzenia zakresu, kopii zapasowej i możliwości odtworzenia stanu.