Definujte tenant jako obchodní i technickou hranici
SaaS popisuje způsob poskytování produktu; multitenance je jedna z možností, jak sdílet jeho technické části. Microsoft v architektonickém průvodci tyto pojmy výslovně rozlišuje. Tenant může být firma, tým nebo jiná skupina, jejíž uživatelé sdílejí data a nastavení. Před volbou databázového schématu je nutné říct, kdo tenant zakládá, kdo jej spravuje, jak se do něj uživatel dostane a zda smí pracovat ve více tenantech. Bez této definice se oprávnění později opravují obtížně.
Sepište životní cyklus: založení, pozvání, změna plánu, pozastavení, export a zrušení. U každého kroku určete vlastníka dat, očekávaný čas a dopad na přístup. Zrušený tenant nemusí znamenat okamžité smazání všech záznamů; konkrétní retenční podmínky se odvíjejí od smlouvy a práva. Technický model musí umožnit tato rozhodnutí provést a doložit. První verze může být jednoduchá, ale pravidlo oddělení zákazníků musí být explicitní.
Izolaci ověřujte na každé cestě k datům
Sdílená aplikace a databáze mohou být vhodným začátkem, pokud se kontext tenantu vynucuje jednotně. Oddělené databáze nebo prostředí zvyšují hranici izolace, ale přidávají správu, migrace a monitoring. Microsoft popisuje různé přístupy i vztah mezi náklady, výkonem a izolací. Neexistuje jediný správný model pro všechny zákazníky. Volba se řídí citlivostí dat, smluvními podmínkami, velikostí tenantů a schopností provozního týmu řešení skutečně udržovat.
Testujte nejen běžný dotaz na obrazovce. Kontext tenantu se může ztratit v asynchronním jobu, exportu, cache, vyhledávacím indexu nebo administrátorském nástroji. Každá cesta má předávat identitu, tenant a oprávnění až k datům. Zkuste negativní scénáře: uživatel změní identifikátor v URL, pracovník fronty načte špatnou dávku, cache vrátí odpověď jiné firmě. Logy mají pomoci incident vysvětlit, ale nesmí samy zbytečně obsahovat citlivá data.
Plán a fakturace jsou oddělené domény
Katalog funkcí, oprávnění produktu a finanční předplatné se často mění v jiných okamžicích. Externí billing poskytovatel může řešit faktury a platby; vaše aplikace stále musí rozhodnout, jaké schopnosti má konkrétní tenant právě využívat. Modelujte proto interní entitlement, jeho zdroj, čas účinnosti a případnou toleranci při opožděné události. Nezakládejte přístup jen na tom, že se v prohlížeči právě otevřela stránka úspěšné platby.
Stripe dokumentuje samostatné události pro změny předplatného, fakturaci a selhání platby. Pokud podobného poskytovatele zvolíte, integrační vrstva musí události ověřit, opakované doručení zpracovat bezpečně a při nejasnosti umožnit rekonciliaci. Aplikace nemá bez výslovného důvodu přebírat roli platebního procesoru. Obchodní pravidla pro zkušební období, změnu tarifu a ukončení přístupu je třeba určit s vlastníkem produktu, protože z technické dokumentace sama neplynou.
Růst dat sledujte podle tenantů, ne jen celkově
Celkový počet uživatelů zakrývá rozdíly. Jeden velký tenant může vytvářet většinu dat, dlouhé reporty nebo extrémní špičky. Sledujte velikost, počet požadavků, latenci a náklady po tenantech tam, kde to soukromí dovolí. Mějte limity pro náročné operace a jasně vysvětlené chování při jejich dosažení. Škálování databáze nenahradí opravu dotazu, který pro každého klienta načítá zbytečně všechny historické záznamy.
Nejdříve měřte konkrétní úzké místo. Index, dávkové zpracování nebo oddělený reportovací tok mohou být přiměřenější než rozdělení celého systému na služby. Při použití cache určete, které hodnoty jsou sdílené a které patří jedinému tenantovi. V analytice sledujte i datum vzniku a mazání dat; bez životního cyklu roste objem trvale. Výkonnostní test má obsahovat malé i velké tenanty a souběh jejich práce, nikoli jen rovnoměrně rozdělené syntetické požadavky.
Release proces nesmí vyžadovat společný výpadek
Jedna verze aplikace pro všechny zákazníky zjednodušuje údržbu, ale změna může zasáhnout celý produkt. Potřebujete možnost postupného zapnutí, sledování dopadu a návratu. Nové databázové pole nejprve přidejte kompatibilně, poté převeďte data a až nakonec odstraňte staré použití. To umožní nasazení i v době, kdy běží starší job nebo klientské rozhraní. Feature flagy používejte střídmě a každému určete datum odstranění.
U změn, které upravují data, nestačí vrátit starý kontejner. Připravte postup pro chybu v migraci, neúplný export a rozdílné verze klientů. Před vydáním ověřte přístup mezi tenanty, oprávnění rolí, billing události a důležité integrační kontrakty. Nástroje jsou méně důležité než schopnost říct, jaká verze běží, koho se změna týká a jak poznat regresi. Odpovědný release zahrnuje i komunikaci zákazníkům, pokud se mění jejich workflow.
Observabilita musí ukazovat zkušenost zákazníka
Dostupný proces nemusí znamenat fungující produkt. U každé důležité cesty sledujte míru chyb, dobu dokončení a počet operací čekajících na ruční zásah. Oddělte problémy jednoho tenantu od společné infrastruktury. U podpory musí existovat bezpečný způsob, jak dohledat stav konkrétní operace, aniž by pracovník získal plošný přístup ke všem datům. Každý přístup podpory k citlivému záznamu má mít důvod a odpovídající oprávnění.
U incidentu stanovte, kdo rozhoduje o vypnutí nové funkce, kdo komunikuje a kdo kontroluje následné srovnání dat. Záloha databáze není hotový plán obnovy. Ověřte, že lze obnovit aplikaci včetně správné verze schématu, objektového úložiště a konfigurace, a zvažte vliv obnovy jednoho tenantu na ostatní. Pro každý typ služby určete realistickou hranici ztráty dat a dobu návratu podle obchodního dopadu, nikoli podle reklamního slibu infrastruktury.
Kdy architekturu měnit a jak začít
Přestavba dává smysl, když opakovaně narážíte na prokazatelné limity: nemožnost izolovat citlivého zákazníka, příliš pomalé migrace, neúměrné náklady konkrétního workloadu nebo release riziko, které nelze zvládnout menší změnou. Zapište metriky a incidenty, které důvod dokládají. Pak navrhněte nejmenší hranici změny: například samostatný reportovací proces nebo oddělené úložiště pro velké tenanty. Celoplošný přepis bez ověřených hranic může problém pouze přesunout.
Pilot má zahrnovat založení nového tenantu, změnu tarifu, selhání billing události, výkon velkého tenantu, export a odstranění dat. EXCOIN zde netvrdí konkrétní počet provozovaných SaaS zákazníků ani partnerství s billing poskytovatelem. Vhodným výstupem úvodní spolupráce je mapa tenantů a dat, model přístupů, seznam kritických toků a měření, které ukáže, kde platforma skutečně potřebuje změnu. Teprve na těchto důkazech stojí rozhodnutí o dalším škálování.
Ještě před rozhodnutím o oddělení infrastruktury porovnejte náklady na izolaci s náklady na provozní chyby. Zeptejte se, zda má konkrétní zákazník odlišné požadavky na obnovu, umístění dat nebo interval vydávání. Pokud ano, neznamená to automaticky novou platformu pro všechny. Může stačit vyčlenit jeden datový nebo výpočetní tok a ponechat společné části tam, kde fungují. Rozhodnutí zapište tak, aby bylo možné po půl roce znovu posoudit podle skutečných nákladů a incidentů.