Jak podjąć decyzję o multi-tenancy, której łatwo nie cofniesz

Multi-tenancy to jedna z niewielu decyzji architektonicznych SaaS, która naprawdę zasługuje na słowo „nieodwracalna." Nie ściśle nieodwracalna — każdą architekturę można zmienić, mając wystarczająco dużo pieniędzy i okno awarii — ale wystarczająco droga do zmiany, że większość zespołów, które wybrały źle, żyje ze złym wyborem przez lata.

Trzy opcje są dobrze znane: wspólna baza danych z izolacją tenanta na poziomie wiersza, schemat na tenanta wewnątrz wspólnej bazy danych lub baza danych na tenanta. Większość artykułów na ten temat kończy na wylistowaniu ich. Interesującym pytaniem jest, który model pasuje do jakiego biznesu — a odpowiedź zależy od właściwości Twoich klientów, nie właściwości Twojego kodu.

Jak wyglądają trzy modele

Krótko, dla wspólnego słownika:

Wspólna baza danych, izolacja na poziomie wiersza. Jedna baza danych. Jeden schemat. Każda tabela ma kolumnę tenant_id. Każde zapytanie ma klauzulę WHERE tenant_id = ?. Izolacja tenanta jest egzekwowana na warstwie aplikacji. To domyślne rozwiązanie dla większości produktów SaaS i najłatwiejsze do budowy.

Schemat na tenanta. Jedna baza danych. Oddzielny schemat na klienta. Aplikacja łączy się ze ścieżką wyszukiwania specyficzną dla tenanta lub zapytaniami kwalifikowanymi schematem. Izolacja jest egzekwowana przez granicę bazy danych między schematami. Kopie zapasowe, przywracanie i migracje odbywają się per schemat.

Baza danych na tenanta. Oddzielna baza danych na klienta. Aplikacja utrzymuje pulę połączeń, wybiera właściwą bazę danych dla żądania i odpowiednio routuje. Izolacja jest egzekwowana przez najmocniejszą granicę, jaką oferuje silnik bazy danych.

Istnieją również warianty — wspólna baza danych z politykami bezpieczeństwa na poziomie wiersza (Postgres RLS), modele hybrydowe, gdzie niektóre tabele są współdzielone, a inne per-tenant, oraz zarządzane rozwiązania jak Aurora Serverless lub tabele DynamoDB per-tenant. Framework decyzyjny stosuje się i do nich.

Cztery czynniki, które decydują

Cztery właściwości Twojego biznesu decydują, który model pasuje. Większość zespołów przecenia trzeci i niedocenia pozostałych.

Rozkład wielkości tenantów. Jeśli Twoi tenanci są w przybliżeniu równi pod względem wielkości — małe firmy każda używająca może 100MB danych — wspólna baza danych działa dobrze, a prostota operacyjna jest ogromna. Jeśli tenanci różnią się o trzy rzędy wielkości — jedni mają 1MB, inni terabajt — wspólna baza zaczyna produkować patologiczne plany zapytań dla małych tenantów, bo statystyki indeksów są zdominowane przez dużych. Schemat na tenanta lub baza danych na tenanta staje się strukturalnie lepszym rozwiązaniem.

Ryzyko hałaśliwego sąsiada. Niektóre obciążenia klientów są nagłe w sposób, który wpływa na innych klientów. Zapytanie raportowe skanujące całą historię tenanta może zablokować wspólną bazę danych, jeśli jest źle zbudowane. W modelu współdzielonym błąd jednego klienta degraduje wszystkich. Koszt izolacji jest realny, ale realny jest też koszt jej braku dla klientów, których praca jest nierówna obciążeniowo.

Ograniczenia regulacyjne i umowne. Niektórzy klienci podpiszą kontrakt enterprise tylko wtedy, gdy ich dane będą żyły w bazie danych wyłącznie ich. Niektóre branże — ochrona zdrowia, usługi finansowe — czynią to domyślnym oczekiwaniem, a nie wyjątkiem. Jeśli Twój zespół sprzedaży będzie na to natrafiał w ciągu następnych dwóch lat, budowanie wspólnej bazy teraz oznacza migrację później. Migracja jest drogą częścią całej decyzji architektonicznej.

Dojrzałość operacyjna. Wspólna baza danych to jedna rzecz do backup'owania, jedna do łatania, jedna do migracji. Tysiąc baz danych to tysiąc rzeczy. Baza danych na tenanta działa tylko wtedy, gdy Twoje narzędzia operacyjne mogą traktować tysiąc jako flotę — zautomatyzowany provisioning, automatyczne łatanie, automatyczna weryfikacja backupów, automatyczne monitorowanie kosztów. Zespoły, które wybierają bazę danych na tenanta bez tych narzędzi, toną w operacjach w ciągu roku.

Framework decyzyjny

Zmapuj cztery czynniki uczciwie:

• Tenanci są jednorodni pod względem wielkości, brak obaw o hałaśliwego sąsiada, brak presji regulacyjnej, mały zespół ops → wspólna baza danych. To właściwa odpowiedź dla większości SaaS na wczesnym etapie.

• Tenanci różnią się o rząd wielkości lub dwa, niektórzy są wystarczająco duzi, by powodować problemy z hałaśliwym sąsiadem, brak presji regulacyjnej → schemat na tenanta. Daje izolację bez eksplozji operacyjnej oddzielnych baz danych.

• Tenanci obejmują klientów enterprise wymagających izolacji na poziomie danych, ograniczenia regulacyjne w grze, zespół ops ma narzędzia flotowe → baza danych na tenanta. Często właściwa odpowiedź dla sales-led enterprise SaaS, niemal zawsze zła odpowiedź dla self-serve SaaS.

Model hybrydowy — część wspólna, część per-tenant — jest często faktycznym celem po kilku latach wzrostu. Nie jest modelem, od którego się zaczyna. Jest wynikiem zaczynania w jednym miejscu i odkrycia, że drugi model jest właściwy dla określonego podzbioru klientów.

Co budować teraz, nawet jeśli później zmienisz

Kilka nawyków sprawia, że ewentualna migracja jest tańsza, niezależnie od modelu, od którego zaczynasz.

Uczyń tenant ID pierwszorzędną koncepcją w modelu domeny od pierwszego dnia. Nawet w jednotenantowym prototypie model danych powinien go mieć. Uzupełnianie tego wstecznie jest bolesne; projektowanie tego od początku jest bezpłatne.

Traktuj zakresowanie tenanta jako jeden kawałek kodu, nie klauzulę WHERE rozsypaną wszędzie. Warstwa repozytorium lub query builder automatycznie wstrzykujący zakres oznacza, że błędy izolacji tenanta są bardzo rzadkie. Ręcznie pisane zapytania, które „pamiętają" o dołączeniu filtra, oznaczają, że błędy izolacji tenanta są nieuniknione. Widzieliśmy realne pieniądze utracone przez to.

Buduj abstrakcję puli połączeń z obsługą routingu per-tenant, nawet jeśli jej nie używasz. Gdy nadejdzie dzień migracji, okablowanie jest już na miejscu. To jeden z najtańszych elementów inwestycji z wyprzedzeniem, jakie możesz poczynić.

Przeprowadzaj ćwiczenie „ile kosztowałaby migracja?" co sześć miesięcy. Nie dlatego, że zamierzasz to zrobić, ale dlatego, że odpowiedź zmienia się wraz z rozrostem systemu. Migracja, która kosztowałaby tydzień dziś, może kosztować kwartał za osiemnaście miesięcy. Znajomość liczby pozwala Ci zdecydować się na działanie świadomie.

Uczciwe podsumowanie

Wybór multi-tenancy jest naprawdę trudny i naprawdę warto poświęcić mu czas. To nie jest decyzja, którą zespół inżynierski może podjąć sam — odpowiedź zależy od tego, komu sprzedajesz i jak to się zmieni w ciągu najbliższych trzech lat. Zaproś do rozmowy przed decyzją zarówno kierownictwo sprzedaży, jak i inżynierskie. Zespoły, które tracą pieniądze na tej decyzji, zazwyczaj straciły je w pokoju, gdzie decyzja była domyślna, a nie dyskusją.