multi-tenancy

Multi-tenancy to architektura, w której jedna instancja aplikacji obsługuje wielu odizolowanych od siebie klientów.

Architektura współdzielenia jednej aplikacji przez wielu klientów

Multi-tenancy, czyli architektura wielodostępna, polega na tym, że jedna uruchomiona instancja aplikacji obsługuje wielu niezależnych klientów, nazywanych często tenantami. Klientem może być firma, dział organizacji, szkoła albo inna logicznie wydzielona grupa użytkowników. Wspólna instancja oznacza współdzielenie kodu aplikacji, jej mechanizmów obsługi żądań i zwykle części zasobów infrastrukturalnych, ale dane, ustawienia oraz uprawnienia każdego tenanta muszą pozostać od siebie odseparowane.

Ważną cechą multi-tenancy jest rozróżnienie między użytkownikiem a tenantem. Użytkownik należy do konkretnego tenanta i otrzymuje uprawnienia określone zarówno przez swoją rolę, jak i przez granice organizacji, do której należy. Ta sama aplikacja może więc obsługiwać równocześnie wiele przedsiębiorstw, lecz zapytanie wykonane przez użytkownika jednego klienta nie powinno zwracać rekordów należących do innego klienta. Izolacja jest częścią logiki aplikacji, modelu danych i mechanizmu autoryzacji, a nie tylko kwestią wyglądu interfejsu.

Modele izolacji danych w systemie wielodostępnym

Najczęściej spotykany model przechowuje dane wielu tenantów we wspólnej bazie i rozróżnia rekordy za pomocą identyfikatora tenanta, na przykład pola tenant_id. Każde zapytanie dotyczące danych klienta musi wtedy zawierać prawidłowy warunek ograniczający wynik do właściwego identyfikatora. Samo dodanie kolumny nie zapewnia jednak bezpieczeństwa. Trzeba jeszcze zagwarantować, że identyfikator jest pobierany z wiarygodnego kontekstu sesji, nie może zostać dowolnie zmieniony przez użytkownika i jest stosowany we wszystkich ścieżkach odczytu, zapisu, modyfikacji oraz usuwania danych.

Inne rozwiązanie wykorzystuje osobny schemat bazy dla każdego tenanta. Taki wariant zwiększa logiczne rozdzielenie tabel, ale wymaga obsługi wielu schematów podczas migracji, tworzenia indeksów i aktualizacji struktury danych. Możliwe jest także użycie osobnej bazy dla każdego klienta. Zapewnia to silniejszą separację i ułatwia niezależne operacje na danych, lecz zwiększa liczbę połączeń, kopii zapasowych, konfiguracji oraz czynności administracyjnych. Wybór modelu zależy od wymagań dotyczących izolacji, kosztu utrzymania, skalowania i sposobu wykonywania kopii zapasowych.

Autoryzacja, konfiguracja i kontrola granic tenanta

W systemie multi-tenant uwierzytelnienie odpowiada na pytanie, kim jest użytkownik, natomiast autoryzacja określa, do jakiego tenanta należy i jakie operacje może wykonać. Kontekst tenanta powinien być ustalany przed obsługą żądania i przekazywany do warstwy dostępu do danych. Szczególnej kontroli wymagają operacje wykonywane poza zwykłym widokiem aplikacji, takie jak eksport danych, raporty zbiorcze, wyszukiwanie, import plików, zadania cykliczne oraz obsługa błędów. Pominięcie filtra w jednej z tych ścieżek może naruszyć izolację mimo poprawnego działania pozostałej części systemu.

Konfiguracja również może być współdzielona albo przypisana do konkretnego tenanta. Dotyczy to między innymi języka interfejsu, strefy czasowej, limitów, włączonych funkcji i ustawień procesu obsługi. Kod aplikacji powinien rozróżniać wartości globalne od wartości należących do klienta, aby ustawienie zmienione przez jednego tenanta nie wpływało przypadkowo na innych. Przydatne są testy sprawdzające dostęp krzyżowy: użytkownik tenanta A powinien otrzymać odmowę albo pusty wynik przy próbie odwołania do zasobu tenanta B, także wtedy, gdy zna jego identyfikator.

Skutki błędnej separacji oraz diagnostyka działania

Najpoważniejszym problemem w architekturze wielodostępnej jest wyciek danych między tenantami, ale błędy mogą mieć także mniej oczywiste skutki. Nieprawidłowe współdzielenie pamięci podręcznej może zwrócić jednemu klientowi wynik wygenerowany dla innego. Wspólny mechanizm kolejkowania może przypisać zadanie do niewłaściwego kontekstu, a źle zaprojektowane logi mogą utrudnić ustalenie, którego klienta dotyczy zdarzenie. Z kolei brak limitów zasobów dla poszczególnych tenantów może spowodować, że intensywne użycie aplikacji przez jednego klienta pogorszy działanie pozostałych.

Diagnostyka systemu multi-tenant powinna obejmować analizę identyfikatora tenanta w żądaniu, logach, zapytaniach do bazy i wynikach operacji asynchronicznych. Warto sprawdzać, czy identyfikator jest obecny w każdej ścieżce przetwarzania, czy transakcje nie zmieniają kontekstu oraz czy pamięć podręczna rozróżnia klucze należące do różnych klientów. Należy również testować migracje danych, odtwarzanie kopii zapasowych, eksporty i usuwanie kont, ponieważ właśnie w operacjach masowych często ujawniają się błędy granic. W przypadku problemów z aplikacją działającą na laptopie lub komputerze PC można zweryfikować między innymi poprawność połączenia, ustawienia klienta, komunikaty błędów i lokalne pliki konfiguracyjne, bez utożsamiania tych czynności z naprawą samej architektury wielodostępnej.