Tworząc oprogramowanie, które wykorzystywane będzie przez różnych dzierżawców, kluczowe jest wybranie odpowiedniej architektury rozwiązania oraz struktury danych. Jest to istotne zarówno z punktu widzenia rozwoju i utrzymania kodu, jak i bezpieczeństwa danych.

Wyobraźmy sobie, że rozwijamy aplikację w modelu SaaS (software-as-a-service), z której korzysta wiele firm. Wdrożenie nowych funkcji musi dotyczyć wszystkich klientów, być bezpieczne i efektywne. W większości przypadków, gdy liczba dzierżawców jest znaczna, tworzenie osobnych instancji aplikacji nie jest dobrym rozwiązaniem. Może prowadzić do wielu problemów, w szczególności związanych z procesem instalacji i utrzymania.

W takiej sytuacji znakomicie sprawdza się architektura typu „multi-tenant”.

Czym jest architektura „multi-tenant”?

Tym terminem określamy aplikację, w której jedna instancja obsługuje wielu różnych dzierżawców. Przy czym istotna jest separacja danych poszczególnych organizacji. Program musi działać w taki sposób, jakby był niezależną instancją.

Przez dzierżawcę mamy zazwyczaj na myśli firmę, która korzysta z danego oprogramowania i udostępnia zasoby swoim pracownikom lub klientom. Mogą to być np. aplikacje do zarządzania procesami lub projektami, platformy marketplace, narzędzia CRM, systemy biletowe, itp.

W przypadku architektury „single-tenant” dana organizacja ma swoją niezależną infrastrukturę i własną instancję programu. Gdy takich instancji jest niewiele, stosunkowo łatwo nimi zarządzać. Jednak w momencie, gdy liczba dzierżawców się zwiększa, administracja poszczególnymi instancjami i wdrażanie nowych wersji staje się bardziej problematyczne i zajmuje znacznie więcej czasu. Wzrasta również koszt utrzymania infrastruktury. Takie podejście sprawdza się w przypadku dystrybucji „on-premise”, jednak w rozwiązaniach SaaS podejście „multi-tenant” daje zdecydowanie więcej korzyści.

Strategie bazodanowe

Niezwykle ważny jest wybór odpowiedniej architektury bazy danych. Ta decyzja ma zasadnicze znaczenie z punktu widzenia bezpieczeństwa danych, skalowalności aplikacji oraz podatności na błędy podczas prac programistycznych i procesu publikacji.

Poniżej przedstawione zostały możliwe rozwiązania wraz ze wskazaniem plusów i minusów każdego z nich.

Pojedyncza baza danych

W tym scenariuszu dane wszystkich klientów znajdują się w jednej bazie, a każda tabela zawiera kolumnę definiującą danego dzierżawcę (np. tenant_id).

Jest to bardzo powszechne rozwiązanie ze względu na stosunkowo prostą architekturę.

Jednak poza prostotą implementacji, takie rozwiązanie ma wiele wad istotnych z punktu widzenia bezpieczeństwa i skalowalności.

Każde zapytanie do bazy danych musi zawierać w sobie warunek (WHERE) określający danego dzierżawcę (tenant_id). Stanowi to duże zagrożenie z punktu widzenia bezpieczeństwa. Łatwo wyobrazić sobie skalę problemów, gdy w wyniku błędu w kodzie zabraknie w jakimś miejscu takiego warunku i poszczególni dzierżawcy będą widzieli dane innych klientów.

Ponadto, taki scenariusz daje mniejsze możliwości skalowania bazy danych na większą liczbę serwerów. I problematyczne jest wyeksportowanie wszystkich danych konkretnego dzierżawcy (np. w celu przejścia na usługę on-premise).

Wiele baz danych

Alternatywną strategią jest utworzenie osobnej bazy danych dla każdego dzierżawcy.

Takie rozwiązanie ma wiele zalet i rozwiązuje większość problemów występujących w scenariuszu z pojedynczą bazą danych.

Przede wszystkim ma miejsce całkowita separacja danych poszczególnych klientów. W zapytaniach bazodanowych nie ma konieczności dodawania warunków wskazujących danego dzierżawcę. W ten sposób eliminowane jest ryzyko, że z powodu brakującej klauzuli nastąpi wyciek danych pomiędzy kontami.

Omawiana architektura daje także znacznie większe możliwości skalowalności. Rozdzielenie danych klientów na osobne bazy ułatwia wykorzystanie większej liczby serwerów i w dłuższej perspektywie ma istotny wpływ na wydajność. Łatwiej także wyeksportować wszystkie dane pojedynczego klienta oraz tworzyć kopie bezpieczeństwa.

Takie podejście wymaga bardziej bardziej złożonego procesu aktualizacji struktury bazy danych oraz publikacji nowych wersji aplikacji. Jednak biorąc pod uwagę znacznie większy poziom bezpieczeństwa oraz możliwości związanych z infrastrukturą, w większości przypadków taka architektura będzie zdecydowanie lepszą decyzją projektową.

Pliki użytkowników

Nie możemy zapominać o tym, że dane użytkowników mogą znajdować się nie tylko w bazie, ale również może być konieczność przechowywania plików. W większości przypadków najlepszym podejściem jest wydzielenie osobnych katalogów dla poszczególnych dzierżawców. Daje to największą elastyczność w kontekście zarządzania (backup, przenoszenie, usuwanie).

Oczywiście, niezależnie od wybranej strategii przechowywania plików należy pamiętać o tym, żeby pliki użytkowników nie były dostępne bezpośrednio z poziomu przeglądarki. Takie dane powinny być przechowywane poza katalogiem `document root` i za dostęp powinna być odpowiedzialna logika aplikacji.

Strategie związane z domenami

W przypadku architektury typu 'multi-tenant’ istotną kwestią jest także wybór strategii dotyczącej domen. Każde z rozwiązań daje inne możliwości z punktu widzenia dzierżawcy, jak i wpływa na sposób implementacji.

Subdomeny

Wygodnym i elastycznym scenariuszem jest udostępnianie każdemu dzierżawcy osobnej subdomeny. W ten sposób dla każdego klienta aplikacja jest dostępna pod innym, unikalnym adresem URL. Daje to duże możliwości dostosowywania np. wyglądu. Takie podejście sprawia, że użytkownicy mogą zalogować się na różne konta w różnych subdomenach.

Omawiana konfiguracja może być zastosowana zarówno przy pojedynczej bazie danych, jak i w przypadku zakładającym osobne bazy danych dla poszczególnych dzierżawców.

Osobne domeny

Alternatywnym sposobem jest wykorzystanie osobnych domen dla każdego klienta. Jest to szczególnie ważne w przypadku, gdy dany dzierżawca chce korzystać z aplikacji pod swoją marką (white label), wówczas podpinana jest jego własna domena.  

Taka konfiguracja najlepiej sprawdza się w przypadku rozwiązania z osobnymi bazami danych.

Częstym scenariuszem jest stosowanie obu powyższych strategii równocześnie – tzn. w przypadku wyższego rodzaju konta jest dostępna opcja z własną domeną, a dla niższych abonamentów jest dostępna subdomena aplikacji.

Pojedyncza domena

Możliwą opcją jest także wykorzystanie pojedynczej domeny dla wszystkich klientów. W takim przypadku poszczególni dzierżawcy nie mają unikalnych adresów url. Użytkownicy nie muszą zastanawiać się, jaki jest adres do zalogowania (nie muszą znać dedykowanej subdomeny/domeny), jednak ogranicza to możliwości personalizacji wyglądu oraz działania pod własną marką.

W takim scenariuszu do rozwiązania także jest problem, w jaki sposób obsługiwać przypadki gdy jeden użytkownik ma być przypisany do kilku różnych dzierżawców (z wykorzystaniem tego samego adresu email jako loginu).

W przypadku tego typu konfiguracji najczęściej wykorzystywane jest rozwiązanie z pojedynczą bazą danych.

Podsumowanie

W przypadku realizacji oprogramowania przeznaczonego dla wielu dzierżawców, niezwykle istotne jest podjęcie odpowiednich decyzji projektowych odnośnie architektury całego rozwiązania. Jest to kluczowe z punktu widzenia funkcjonalności, wygody użytkowników i bezpieczeństwa danych. Właściwe przygotowanie projektu usprawnia także dalszy rozwój i utrzymanie.

---