Multi-tenant architektúra: jeden systém pre viac firiem

01Tenant je hranica firmy, nie iba používateľský účet

Tenant predstavuje oddelený priestor zákazníka v spoločnom produkte. Pri firemnom SaaS to býva organizácia so svojimi používateľmi, údajmi, nastaveniami a predplatným. Jedna osoba môže pracovať pre viac organizácií a v každej mať iné oprávnenia. Preto nestačí stotožniť tenant s e-mailovou adresou alebo jedným prihlásením.

Najprv nakreslite skutočné vzťahy. Má slovenská firma viac prevádzok? Majú zdieľať objednávky? Je účtovník pozvaný do priestorov viacerých klientov? Je dcérska spoločnosť samostatným zákazníkom? Tieto odpovede určujú, čo systém smie zdieľať a kde musí vytvoriť hranicu. Chybná definícia sa neskôr prejaví v reportoch aj fakturácii.

Microsoft opisuje modely multitenancy ako spektrum zdieľaných a vyhradených zdrojov. Jeden produkt môže mať spoločnú aplikačnú vrstvu a oddelené databázy. Rozhodnutie preto nie je iba voľbou medzi jedným serverom a serverom pre každú firmu.

Do zadania zapíšte aj životný cyklus: kto organizáciu založí, kto potvrdí správcu, ako sa prijíma pozvanie a ako sa ukončí členstvo. Zmena vlastníka firmy alebo odchod administrátora má mať podporovaný postup. Ručný zásah do databázy nemá byť bežnou cestou správy zákazníka.

02Vyberte mieru zdieľania podľa záväzkov

O modeli rozhodujú požiadavky zákazníkov, spôsob práce a schopnosť tímu prevádzkovať riešenie. Spoločné zdroje môžu znížiť opakovanú správu, ale vyžadujú dôslednú izoláciu a kontrolu spotreby. Samostatné prostredia poskytujú ďalšiu hranicu, no prinášajú viac aktualizácií, konfigurácií a obnovovacích postupov.

Pre bežný tarif môžete mať zdieľanú prevádzku, pre zákazníka s odlišnými podmienkami samostatné dáta. Obchodná ponuka však musí zodpovedať skutočnej izolácii. Označenie „privátny priestor“ môže znamenať iba logické oddelenie záznamov, nie vyhradený server.

Pred rozhodnutím zostavte zoznam záväzkov: požadovaný čas obnovy, prípustná strata dát, lokalita, auditné záznamy a možnosti exportu. Nepredpokladajte, že rovnaká záloha automaticky splní požiadavky všetkých zákazníkov. Každý sľub má mať prevádzkový postup a vlastníka.

03Kontext firmy overujte na serveri pri každom úkone

Prihlásenie potvrdí identitu človeka. Až autorizácia rozhodne, či môže vidieť alebo meniť konkrétny záznam v konkrétnej organizácii. Dokumentácia identity pre multitenant riešenia tieto dve úlohy odlišuje a upozorňuje na používateľov patriacich do viacerých tenantov.

Identifikátor firmy odoslaný z prehliadača používajte len spolu s kontrolou členstva a oprávnenia. Skrytý výber firmy v rozhraní nie je ochrana. Rovnaké pravidlo musí platiť pri otvorení detailu, vyhľadávaní, sťahovaní prílohy, exporte aj práci integrácie. Prístup nesmie vzniknúť len preto, že niekto pozná adresu záznamu.

Osobitne navrhnite podporu. Operátor nemá automaticky dostať trvalý prístup ku všetkým zákazníkom. Dohodnite dôvod, rozsah, čas a záznam prístupu. Pri zásahu má byť jasne viditeľné, v ktorej firme pracuje. Zmena aktívnej organizácie sa nemá ticho preniesť medzi otvorenými kartami.

Súvisiace príklady chybného prístupu rozoberá článok o chybách v kóde, cez ktoré unikajú dáta. Pri multi-tenant produkte majú tieto kontroly chrániť hranicu medzi celými zákazníckymi organizáciami.

04Databáza je jedna z viacerých vrstiev izolácie

Pri spoločných tabuľkách je identifikátor tenantu súčasťou návrhu dát a dotazov. Skontrolujte unikátne obmedzenia, vzťahy medzi tabuľkami aj importy. Číslo zákazníckej objednávky môže byť jedinečné vo firme, no nemusí byť jedinečné v celom produkte. Model má túto vlastnosť vyjadriť.

PostgreSQL podporuje pravidlá zabezpečenia riadkov. Ich účinok závisí od nastavenia a roly, ktorou aplikácia pristupuje; vlastníci tabuliek a privilegované roly majú osobitný režim. Prítomnosť pravidla preto nenahrádza test skutočného aplikačného spojenia ani správny prenos tenant kontextu.

Rovnaké oddelenie potrebuje cache, úložisko súborov, vyhľadávací index a front správ. Cache kľúč obsahujúci iba číslo záznamu môže zameniť odpoveď medzi firmami. Úloha na pozadí musí dostať overený kontext a nesmie si ho domyslieť z predchádzajúcej úlohy.

Pri analytike oddeľte zákaznícky report od oprávneného súhrnu prevádzkovateľa. Súhrnné údaje neznamenajú automaticky povolenie zdieľať obchodné alebo osobné informácie jednotlivých firiem. Zadajte konkrétny účel, prístupy a pravidlá zobrazenia.

05Výkon merajte aj podľa jednotlivých zákazníkov

Veľký import jednej firmy môže zamestnať spoločnú frontu a zhoršiť prácu ostatným. Tento problém sa označuje noisy neighbor. Vlastný návrh limitov začnite reálnymi operáciami: importom, exportom, vyhľadávaním, hromadným odosielaním a spracovaním príloh. Nestačí merať iba rýchlosť úvodnej obrazovky.

Dohodnite pravidlá férového využitia, obmedzenie paralelných úloh a priebežné spracovanie veľkých dávok. Používateľ má vedieť, že import čaká alebo sa spracúva. Nekonečné opakovanie požiadavky po nejasnej chybe môže zvýšiť záťaž a vytvoriť duplicitnú prácu.

Sledujte čas odpovede, chyby, čakajúce úlohy a spotrebu pre firmu aj celý systém. Bez tohto rozlíšenia môže priemer vyzerať dobre, hoci konkrétny zákazník pravidelne čaká. Zároveň neukladajte do prevádzkových logov celé citlivé dokumenty len preto, aby sa problém ľahšie hľadal.

Plánovanie rastu nadväzuje na škálovateľnosť webovej aplikácie. Tu doplňte najmä rozdelenie kapacity medzi tenantov a schopnosť presunúť náročného zákazníka bez narušenia ostatných. Rozhodnutie o presune má vychádzať z merania, nie z počtu registrovaných účtov.

06Obnova a zánik firmy patria do architektúry

Microsoft pri dátovej vrstve upozorňuje aj na obnovu konkrétneho tenantu. Pri spoločnej databáze môže byť potrebné obnoviť zálohu bokom a selektívne získať správne údaje. Návrat celej databázy kvôli jednej firme by mohol prepísať novšiu prácu ostatných.

Vlastný obnovovací scenár má zahŕňať záznamy, prílohy, vzťahy a nadväzujúce udalosti. Určte, ktoré úlohy sa po obnove nemajú zopakovať, napríklad odoslanie potvrdenia alebo založenie dokladu v externom systéme. Testujte výsledok z pohľadu používateľa, nie iba úspech kopírovania databázy.

Ukončenie predplatného môže vyžadovať export, blokovanie nových úloh a následné vymazanie podľa dohodnutých pravidiel. Vyjasnite výnimky uchovávania a prácu so zálohami. Nezmažte identitu bez vyriešenia jej členstiev v iných firmách. Životný cyklus človeka a organizácie sa nemusia skončiť naraz.

Pred prvým nasadením pripravte skúšobné firmy s rozdielnymi rolami a údajmi. Overte, že požiadavka jednej firmy nedostane odpoveď druhej ani pri chybe, opakovaní alebo vypršaní členstva. Testy izolácie udržiavajte pri každej zmene dôležitého procesu.

07Spustite menší počet firiem s úplnou kontrolou

Pri testovaní pripravte aj situáciu, keď osoba práve prišla o členstvo, ale stále má otvorenú kartu. Ďalšia požiadavka už nemá používať staré oprávnenia bez kontroly. Preverte tiež odvolanie integračného kľúča a zablokovanie úloh, ktoré čakajú vo fronte. Zmena prístupu sa musí prejaviť v celom systéme.

Nastavenia zákazníka udržujte v podporovanej konfigurácii. Ak každá firma dostane vlastnú vetvu kódu, opravy a aktualizácie sa začnú rozchádzať. Pri požiadavke na výnimku preto vyhodnoťte, či ide o nastavenie, všeobecnú produktovú funkciu alebo samostatnú zákazkovú dodávku. Rozhodnutie zaznamenajte aj pre obchodný tím.

Zahrňte do skúšky zmenu tarifu. Obmedzenie funkcie nesmie ticho zneprístupniť potrebné historické údaje bez dohodnutého postupu. Skontrolujte, ktoré údaje sa iba prestanú vytvárať a ktoré sa majú exportovať. Používateľ potrebuje jasné vysvetlenie následkov skôr, než zmenu potvrdí.

Ak zákazník požaduje presun do samostatného prostredia, určte kontrolu úplnosti a okamih prepnutia. Overte súbory, nastavenia, oprávnenia a integrácie popri samotných tabuľkách. Dočasné zablokovanie zápisov alebo iné riadenie súbehu je návrhová otázka konkrétneho systému; nesľubujte presun bez výpadku pred jej vyriešením.

Priebežne sledujte aj náklady na podporu jednotlivých modelov. Ručné zakladanie účtov, opravovanie konfigurácie a hľadanie chybného importu môžu znížiť výhodu spoločnej prevádzky. Pri rozhodovaní o automatizácii vyberte opakujúci sa krok s jasným pravidlom a kontrolou výsledku. Počet tenantov sám neukazuje cenu jeho obsluhy.

1. Definujte tenant, členstvo a povolené zdieľanie.
2. Zvoľte izoláciu podľa záväzkov a prevádzkových možností.
3. Preverte všetky cesty k dátam vrátane úloh a príloh.
4. Otestujte záťaž jednej firmy a dopad na ostatné.
5. Skúste obnovu, export a ukončenie organizácie.
6. Zaznamenajte limity a podmienky pre ďalší rast.

Modelový produkt pre servisné firmy môže začať spoločnou aplikáciou s jednotnými pravidlami a obmedzenými importmi. Následne tím meria konkrétne procesy a overuje nové požiadavky. Nie je nutné hneď zavádzať každý dostupný cloudový mechanizmus; nevyhnutné je vedieť, ktoré bezpečnostné a prevádzkové hranice už skutočne fungujú.

Rozšírenie tarifu alebo vstup väčšieho zákazníka posudzujte ako zmenu podmienok. Výkonový limit, samostatná obnova či vlastné prihlasovanie môžu meniť architektúru. Obchod a vývoj majú pracovať s rovnakým zoznamom podporovaných možností, aby zákazník nedostal sľub, ktorý prevádzka nevie splniť.

08Časté otázky k multi-tenant architektúre