Multi-tenancy közérthetően: útmutató alapítóknak

Egy szoftvertermék építése során egy ponton egy fejlesztő ki fogja mondani Önnek a „multi-tenant” szót, figyeli az arcát, és feltételezi, hogy értette. Valószínűleg bólintott. A legtöbb alapító így tesz. Pedig ez azon korai döntések egyike, amelyek csendben megszabják a plafont arra, milyen gyorsan tud növekedni, milyen olcsón tud üzemelni, és mennyire mehetnek félre a dolgok, ha egy ügyfél valaha is olyan adatot lát, amely nem az övé. Most megéri rászánni tíz percet, mert később nagyon költséges visszatérni rá.

Sok nem műszaki alapítóval ültem szemben — éles ötlettel rendelkező emberekkel egy SaaS termékhez, akiket az adatbázisok különösebben nem érdekelnek. A jó hír az, hogy nem kell megtanulnia programozni ahhoz, hogy jól meghozza ezt a döntést. Egy világos gondolati modellre és egy rövid kérdéslistára van szüksége. Pontosan ez ez az útmutató. Semmi divatos szakzsargon, semmi architektúradiagram, amelyre soha többé nem fog ránézni, csak az, amit a fejlesztője szeretne, hogy az első kódsor előtt megértsen.

Ha egyetlen gondolatot visz magával, legyen ez az: a multi-tenancy nem egy funkció, amelyet később hozzáad. Ez egy alap. Egy házat újra lehet festeni, de azt, amin áll, már nem könnyű megváltoztatni, ha egyszer felhúzták a falakat.

Mit jelent valójában a „multi-tenant”

Képzeljen el egy társasházat. Minden lakónak saját lakása van — saját kulcsa, saját bútora, saját bejárati ajtaja. De mind ugyanazt a szerkezetet osztják meg: az alapot, a vízvezetéket, a tetőt, a liftet. A tulajdonos egyetlen épületet tart karban, nem ötven külön házat, és épp ez teszi megfizethetővé a bérleti díjat. A multi-tenant szoftver pontosan így működik. Egyetlen alkalmazás sok ügyfelet — „tenantot” — szolgál ki, és mindegyik a saját privát tereként éli meg, jóllehet a felszín alatt mind ugyanazon a megosztott rendszeren futnak.

Az ellentétes megközelítés a single-tenant: minden ügyfél a szoftver saját külön példányát kapja, mintha mindegyiknek vadonatúj különálló házat építenénk. Privátabb, jobban testreszabható — és drámaian drágább megépíteni, üzemeltetni és frissíteni, mert most ötven házat tart karban egyetlen épület helyett.

Szinte minden termék, amelyet nap mint nap használ, multi-tenant. Az e-mailje, a könyvelőeszköze, a foglalási rendszere, a CRM, amelyben az értékesítési csapata él. Ön és ezer másik cég ugyanazt az alapszoftvert osztja meg, és egyikük sem látja a másikat soha. Ez a láthatatlanság — ez a tiszta elválasztás — a multi-tenancy egész művészete.

Miért érinti ez a döntés az egész vállalkozását

Csábító ezt a „műszaki részlet, amit a fejlesztőm intéz” kategóriába sorolni. De a választott modell egyenesen átgyűrűzik a vállalkozás azon részeibe, amelyek valóban érdeklik: a havi tárhelyszámlába, abba, milyen gyorsan tud egy új funkciót mindenkihez eljuttatni, mit ígérhet egy ideges nagyvállalati vevőnek, és mennyi kárt okozhat egyetlen hiba.

Amikor egy jól megépített multi-tenant termékben kijavít egy hibát vagy kiad egy funkciót, minden ügyfél egyszerre kapja meg, egyetlen frissítésből. Egy single-tenant világban ezt a változtatást ötven külön telepítésre vezetné ki, amelyek mindegyike mostanra már lehet kissé eltérő. Az egyik egy keddi délután. A másik egy projekt. Szorozza ezt évek frissítéseivel, és látja, miért nyugszik a SaaS-iparág a multi-tenancyn.

Az érem másik oldala, hogy az infrastruktúra megosztása megemeli a tétet az elválasztáson. Egy társasházban egy vízvezeték-hiba több lakást is érinthet. A multi-tenant szoftverben egy hiba abban, ahogyan a tenantokat különtartja, nemcsak egy ügyfelet zavar — egyszerre fedheti fel mindenki adatát. Ez nem ok arra, hogy kerülje a multi-tenancyt. Ez az ok arra, hogy rendesen építse meg, valakivel, aki már csinálta korábban.

A tenantok különtartásának három módja

Amikor a fejlesztők a multi-tenancyról vitatkoznak, általában arról vitatkoznak, hogy mennyire különálljon az egyes tenantok adata. Három elterjedt megközelítés létezik, és ezek egy csúszó skálán helyezkednek el a „maximális megosztás, legkisebb költség”-től a „maximális elválasztás, legnagyobb költség”-ig. Nem kell magának kiválasztania egyet — de értenie kell a kompromisszumot, amelyet a fejlesztője az Ön nevében köt.

1. Közös adatbázis, közös táblák

Mindenki adata ugyanabban az adatbázisban, ugyanazokban a táblákban él, egy rejtett címkével — egy „tenant ID”-val —, amely jelzi, melyik sor kié. A szoftver felel azért, hogy mindig e szerint a címke szerint szűrjön, így az A ügyfél csak az A sorait látja. Ez a legolcsóbb és legjobban skálázható modell, ezt használja a legtöbb korai SaaS-termék. A csapda: az elválasztás a kódban él, így egyetlen kihagyott szűrő az, ahogyan az adat kiszivárog. Gondos, fegyelmezett mérnöki munkát igényel.

2. Közös adatbázis, külön rekeszek

Egyetlen adatbázis, de minden tenant saját elfalazott szakaszt kap benne (a fejlesztők ezeket „sémáknak” hívják). Erősebb elválasztás, mint az első modell, még mindig ésszerűen hatékony, és könnyebbé teszi például egy ügyfél adatának tiszta exportálását vagy törlését. A kompromisszum: több mozgó alkatrész, amelyet kezelni kell, ahogy százas, ezres tenantszámra nő.

3. Tenantonként külön adatbázis

Minden ügyfél saját dedikált adatbázist kap — a legközelebbi dolog ahhoz, hogy privát házat adjon neki, miközben az alkalmazás továbbra is közös. Ez a legerősebb szeparáció és a legkönnyebben elmesélhető történet egy biztonságtudatos nagyvállalati vevőnek. Egyúttal ez a legdrágább üzemeltetni és működtetni, így általában a nagy értékű ügyfeleknek, a szabályozott iparágaknak vagy az olyan termékeknek tartják fenn, ahol egy adatkeveredés katasztrofális lenne.

Amit nem szabad elrontania: a szeparáció

Ha egyetlen hely van, ahová az aggodalmát fektetnie kell, az ez. A tenant-szeparáció az a garancia, hogy az A ügyfél semmilyen körülmények között nem láthatja, szerkesztheti, sőt nem is érzékelheti a B ügyfél adatának létezését. Magától értetődőnek hangzik. Ugyanakkor ez a multi-tenant termékek súlyos hibáinak egyetlen leggyakoribb forrása, mert a hiba néma — minden rendben tűnik egészen a napig, amikor valaki megnyit egy jelentést, és egy idegen ügyfeleit látja benne.

Az ok, amiért ez megtörténik, szerkezeti. A legolcsóbb modellben minden egyes adatbázis-lekérdezésnek emlékeznie kell arra, hogy tenant szerint szűrjön. Csinálja jól tízezerszer, és rosszul egyszer, és máris ott a szivárgás. Ezért a tapasztalt csapatok nem arra hagyatkoznak, hogy a fejlesztők emlékezzenek — a szeparációt beépítik az alapba, hogy a felejtés ne csak valószínűtlen, hanem lehetetlen legyen. Nem kell értenie, hogyan csinálják. Azt kell megkérdeznie, hogy csinálják-e.

Van ennek a problémának egy csendesebb rokona is: a „zajos szomszéd”. Mivel a tenantok megosztják az infrastruktúrát, egy ügyfél, aki valami nehezet csinál — egy óriási import, egy elszabadult jelentés — lelassíthatja a rendszert mindenki másnak, ahogy egy lakás, amelyben minden csapot megnyitnak, az egész épületben leejtheti a víznyomást. A jó multi-tenant tervezés ezzel korlátokkal és méltányos megosztással számol. Érdemes rákérdezni, főleg ha néhány nagyon nagy ügyfélre számít.

Amikor a single-tenant valójában a helyes döntés

A multi-tenancy a SaaS alapértelmezése, de nem vallás. Vannak tisztességes okok arra, hogy egy ügyfélnek saját külön példányt adjon, és egy jó tanácsadó megmondja, mikor akadt rá egyre, ahelyett hogy mindent a közös modellbe préselne.

• Egy szabályozott iparágban — egészségügy, pénzügy, közigazgatás — működő ügyfél, akinek megfelelőségi szabályai gyakorlatilag megkövetelik, hogy adata bizonyíthatóan külön helyen legyen.
• Egyetlen nagy ügyfél, aki eleget fizet ahhoz, hogy a dedikált beállítás megérje, és aki olyan mély testreszabást akar, amelyet nem akar mindenki más élményébe átszivárogtatni.
• Annyira érzékeny adat, hogy egy tenantok közti szivárgás költsége megszüntetné a vállalkozást, ami a maximális szeparációt megéri a többletköltség árán.
• Egy on-premise követelmény, ahol a szoftvernek az ügyfél saját falain belül kell futnia, nem az Ön felhőjében.

Vegye észre a mintát: a single-tenant a kivétel, amelyhez szándékosan nyúl, általában egy konkrét nagy értékű ügyfél kedvéért, nem az alapértelmezés, amelyre az egész vállalkozást építi. Ha egy fejlesztő a standard termékéhez már az első naptól single-tenantot javasol, kérje meg, hogy magyarázza el, miért — ez általában sokkal magasabb üzemeltetési költséget és lassabb frissítéseket jelent, és Ön azt akarja, hogy ez döntés legyen, ne baleset.

A kérdések, amelyeket feltesz, mielőtt bárki kódot ír

Nem Önnek kell megterveznie az architektúrát. Arról kell meggyőződnie, hogy aki tervezi, a megfelelő dolgokon gondolkodott. Íme a rövid lista, amelyet szeretném, ha egy nem műszaki alapító magával vinne arra az első beszélgetésre — nyomtassa ki, tegye fel, és figyelje, milyen magabiztosan válaszolnak rájuk.

1. 1
   Hogyan tartják külön a tenantok adatát?

   Szerkezeti választ keres — a rendszer kényszeríti ki —, nem azt, hogy „óvatosak leszünk”. Ez az, amiről nincs alku.
2. 2
   Melyik modellt használjuk, és miért?

   Közös táblák, külön rekeszek vagy tenantonkénti adatbázis. Nincs rossz válasz, de legyen olyan indok, amely illik az ügyfeleihez és a költségvetéséhez.
3. 3
   Kínálhatunk-e dedikált szeparációt egy nagy ügyfélnek később?

   Még ha teljesen közösen is indul, a tervezés hagyjon teret arra, hogy egy nagy vagy szabályozott ügyfélnek erősebb elválasztást adjon újraépítés nélkül.
4. 4
   Mi történik, amikor egy ügyfél óriásivá nő?

   Hogyan akadályozza meg a rendszer, hogy egy nehéz tenant lelassítson mindenki mást? Azt akarja hallani, hogy a zajos szomszéd forgatókönyveit figyelembe vették.
5. 5
   Hogyan exportáljuk vagy töröljük tisztán egy ügyfél adatát?

   Az ügyfelek távoznak, és az adatvédelmi törvény megköveteli, hogy kérésre eltávolítsa az adatukat. Ennek egyszerű, jól értett műveletnek kell lennie, nem pániknak.

Nem a válaszok műszaki részletét osztályozza. Azt ellenőrzi, hogy e kérdések egyike se csapjon le meglepetésként. Egy csapat, amely már épített multi-tenant szoftvert, mind az ötre velős, már-már unott választ ad. Az első vagy a harmadiknál való habozás a jel, hogy lassítson és ásson mélyebbre.

Egy rövid, valósághű példa

Egy alapító egy működő prototípussal jött hozzánk: egy időpontfoglaló eszközzel, amelyet kis klinikáknak szántak. Már három fizető ügyfele volt — és egy csendes problémája. Hogy gyorsan piacra kerüljön, az első fejlesztő minden klinikának a saját külön példányát adta az alkalmazásnak. Három ügyfél, három telepítés, három kissé eltérő verzió, mert mindegyik kért útközben egy-egy kis módosítást.

Háromnál gyönyörűen működött. Az alapító rémálma a harminc gondolata volt. Minden hibajavítás három helyre való bejelentkezést jelentett. Minden új funkció három telepítést és három tesztelnivalót jelentett. Egy új klinika közel egy hétnyi kézi beállítást igényelt. A modell, amely elindította őket, most az volt, ami plafonozta a növekedésüket — pontosan az alapprobléma, amelyről ez az egész cikk szól.

Nem téptünk ki mindent egy drámai újraírásban. A magot egy közös, multi-tenant alapra építettük újra, a szeparációt rendszerszinten kényszerítve ki, a klinikánkénti testreszabásokat különálló kódbázisok helyett konfigurálható beállításokként megtartottuk, és a három meglévő klinikát egyenként, párhuzamosan migráltuk át, hogy senkinek se legyen ijesztő átállási napja. Egy új klinika beállítása egy hét kézi munkából önkiszolgáló regisztrációvá vált. Az új funkciók most egyetlen kiadásból érnek el minden ügyfelet.

Az itteni számok szemléltetők, nem ígéret — minden termék más —, de a forma jellemző: az újraépítés valódi pénzbe és néhány hónapba került, és megtérült az első néhány új ügyfélen, akiket hirtelen ujjmozdítás nélkül tudtak bevonni. A tanulság, amelyet az alapító magával vitt, az olcsóbb volt: ha az elején feltették volna az öt kérdést, nem lett volna mit újraépíteni.

Gyakori kérdések