Multi-tenant vs. single-tenant | A megfelelő SaaS architektúra kiválasztása

Minden SaaS terméknek meg kell válaszolnia egy alapvető kérdést: hogyan szolgáljon ki több ügyfelet ugyanabból a szoftverből? A válasz a bérleti (tenancy) modellje. Ez befolyásolja a költségeket, biztonságot, teljesítményt és azt, milyen gyorsan tud szállítani. A korai helyes döntés megkíméli a fájdalmas migrációtól később.

Definíciók

Multi-tenant

Az alkalmazás egyetlen példánya szolgálja ki az összes ügyfelet. Mindenki osztozik ugyanazon a szervereken, ugyanazon a kódbázison, és gyakran ugyanazon az adatbázison. Minden ügyfél adatai logikailag elkülönítettek, de az infrastruktúra megosztott.

Gondoljon rá úgy, mint egy társasház. Minden bérlő ugyanabban az épületben él, osztozik a liften és folyosókon, de van saját zárt lakása a saját bútoraival.

Single-tenant

Minden ügyfél saját dedikált alkalmazáspéldányt kap. Különálló szerverek, különálló adatbázisok, néha különálló kódbázisok. Semmi sincs megosztva az ügyfelek között.

Gondoljon rá úgy, mint önálló házak. Minden bérlőnek saját épülete, saját vízvezetéke, saját udvara van. Teljes elkülönítés, de drágább a karbantartása.

Hogyan működik a multi-tenancy

A multi-tenant architektúrának három gyakori megközelítése van, mindegyik más kompromisszumokkal.

1. modell: Megosztott alkalmazás, megosztott adatbázis

Minden bérlő osztozik egyetlen alkalmazáspéldányon és egyetlen adatbázison. A bérlői adatokat bérlő-azonosító (tenant_id oszlop) segítségével választják szét minden táblában.

Architektúra:

• Egy alkalmazásszerver (vagy klaszter) kezeli az összes kérést.
• Egy adatbázis tárolja az összes bérlő adatait.
• Minden lekérdezés tartalmaz egy WHERE tenant_id = ? feltételt, amely az adatokat a megfelelő bérlőre szűkíti.

Előnyök:

• Legalacsonyabb infrastruktúra költség. Egy adatbázis, egy alkalmazástelepítés.
• Legegyszerűbb telepíteni és frissíteni. Egyszer telepít, mindenki megkapja a változást.
• Könnyű aggregálni az adatokat a bérlők között analitikához és jelentésekhez.

Hátrányok:

• Legmagasabb adatszivárgási kockázat, ha egy lekérdezés elfelejti a bérlőszűrőt.
• Egy zajos bérlő mindenki számára ronthatja a teljesítményt.
• Az adatbázis migrációk egyszerre érintik az összes bérlőt.
• A legnehezebb az adatrezidencia szabályozásoknak megfelelni.

Ez a leggyakoribb megközelítés a B2B SaaS termékekhez, amelyeknek nagyszámú kis és közepes ügfelük van.

2. modell: Megosztott alkalmazás, külön adatbázisok

Minden bérlő osztozik ugyanazon az alkalmazáspéldányon, de minden bérlő saját adatbázist kap. Az alkalmazás a hitelesített bérlő alapján irányítja a lekérdezéseket a megfelelő adatbázisba.

Architektúra:

• Egy alkalmazásszerver (vagy klaszter) kezeli az összes kérést.
• Külön adatbázis minden bérlőhöz.
• Egy irányító réteg térképezi a bérlő identitását a megfelelő adatbázis-kapcsolatra.

Előnyök:

• Erősebb adatelkülönítés. Nincs kockázata a bérlők közötti lekérdezéseknek.
• Könnyebb az adatrezidencia követelményeknek megfelelni. Minden adatbázist a bérlő szükséges régiójába helyezheti.
• A bérlőnkénti biztonsági mentés és visszaállítás egyszerű.
• Egy bérlő intenzív használata nem zárolja a táblákat a többi bérlőnél.

Hátrányok:

• Több kezelendő infrastruktúra. Száz bérlő száz adatbázist jelent.
• A séma migrációkat minden adatbázisra egyenként kell alkalmazni.
• A bérlők közötti jelentéskészítés több adatbázis lekérdezését igényli.
• Magasabb költség, mint a teljesen megosztott modell.

Ez erős középút azoknak a termékeknek, amelyeknek jobb elkülönítésre van szükségük a teljes single-tenancy költsége nélkül.

3. modell: Külön alkalmazás, külön adatbázis

Minden bérlő saját alkalmazáspéldányt és saját adatbázist kap. Teljesen elkülönítve. Ez lényegében single-tenancy, de a SaaS szolgáltató által kezelve az ügyfél helyett.

Architektúra:

• Dedikált alkalmazástelepítés bérlőnként.
• Dedikált adatbázis bérlőnként.
• Egy irányító réteg (gyakran terheléselosztó vagy API átjáró) irányítja a forgalmat a megfelelő példányra.

Előnyök:

• Teljes elkülönítés. Nincs megosztott erőforrás a bérlők között.
• Maximális rugalmasság a bérlőnkénti testreszabáshoz.
• Egy bérlő teljesítménye soha nem érinti a másikat.
• Legegyszerűbb megfelelőségi történet.

Hátrányok:

• Messze a legmagasabb infrastruktúra költség.
• A telepítési komplexitás lineárisan nő a bérlők számával.
• A frissítéseket minden példányra egyenként kell kibocsátani (vagy nagyon gondosan automatizálni).
• Gazdaságilag nem skálázódik nagyszámú kis bérlőre.

Ez a modell vállalati SaaS-nál van értelme, ahol az ügyfelek dedikált infrastruktúrát igényelnek és hajlandóak felárat fizetni érte.

Előnyök és hátrányok áttekintése

Tényező	Multi-tenant (megosztott DB)	Multi-tenant (külön DB)	Single-tenant
Infrastruktúra költség	Legalacsonyabb	Közepes	Legmagasabb
Adatelkülönítés	Logikai (sorszintű)	Fizikai (adatbázisszintű)	Teljes
Telepítési komplexitás	Alacsony	Közepes	Magas
Frissítés sebessége	Azonnali mindenkinek	Azonnali app, DB-nkénti migráció	Példányonkénti kibocsátás
Testreszabás	Korlátozott	Korlátozott	Teljes
Megfelelőség	Nehezebb	Közepes	Legkönnyebb
Skálázhatóság (bérlőszám)	Kiváló	Jó	Gyenge
Zajos szomszéd kockázat	Magas	Közepes	Nincs

Adatelkülönítés és biztonság

Az adatelkülönítés a legfontosabb szempont minden bérleti modellben. Egy biztonsági incidens, ahol az egyik bérlő hozzáférhet a másik bérlő adataihoz, katasztrofális egy SaaS vállalkozás számára. Megsemmisítheti a bizalmat, megsértheti a szabályozásokat és véget vethet a vállalatnak.

Sorszintű biztonság

Megosztott adatbázis modellben a PostgreSQL Row-Level Security (RLS) az egyik legerősebb védelem az adatszivárgás ellen. Az RLS adatbázis szinten érvényesíti a bérlő elkülönítést, nem alkalmazás szinten. Még ha az alkalmazás kódjában van egy hiba, amely elfelejt bérlő szerint szűrni, maga az adatbázis megakadályozza a bérlők közötti hozzáférést.

Így állítsa be:

-- RLS engedélyezése egy táblán
ALTER TABLE projects ENABLE ROW LEVEL SECURITY;

-- Irányelv létrehozása, amely korlátozza a hozzáférést az aktuális bérlőre
CREATE POLICY tenant_isolation ON projects
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);

-- RLS kényszerítése még a tábla tulajdonosaira is
ALTER TABLE projects FORCE ROW LEVEL SECURITY;

Minden lekérdezés végrehajtása előtt állítsa be a bérlő kontextust:

-- Beállítás minden kérés/tranzakció elején
SET LOCAL app.current_tenant_id = 'a1b2c3d4-e5f6-7890-abcd-ef1234567890';

-- Most ez a lekérdezés automatikusan csak az aktuális bérlő adatait adja vissza
SELECT * FROM projects;
-- Nincs szükség WHERE feltételre. Az RLS kezeli.

Alkalmazásszintű elkülönítés

Az adatbázisszintű biztonság mellett az alkalmazásnak is érvényesítenie kell a bérlő határokat:

// Middleware, amely beállítja a bérlő kontextust minden kérésre
async function tenantMiddleware(req: Request, res: Response, next: NextFunction) {
  const tenantId = extractTenantId(req); // JWT-ből, aldomainből vagy fejlécből

  if (!tenantId) {
    return res.status(401).json({ error: "Tenant not identified" });
  }

  // Bérlő kontextus beállítása az adatbázis-kapcsolathoz
  await db.raw(`SET LOCAL app.current_tenant_id = '${tenantId}'`);

  req.tenantId = tenantId;
  next();
}

A mélyreható védelem az elv itt. Soha ne támaszkodjon egyetlen elkülönítési rétegre. Kombinálja az alkalmazásszintű szűrést, adatbázisszintű biztonságot és rendszeres biztonsági auditokat.

Teljesítmény szempontok

Megosztott adatbázis kihívásai

Megosztott adatbázisban minden bérlő ugyanazokért az erőforrásokért verseng. Egy nehéz jelentést futtató bérlő mindenki más lekérdezéseit lelassíthatja. Enyhítő megoldások:

• Kapcsolat-pooling. Használjon PgBouncer-t vagy hasonló eszközt, hogy egy bérlő ne meríthesse ki az adatbázis-kapcsolatokat.
• Lekérdezés időtúllépések. Állítson be maximális végrehajtási időket, hogy egy elszabadult lekérdezés ne zárolja határozatlan időre az erőforrásokat.
• Sebességkorlátozás. Bérlőnkénti korlátok érvényesítése API kérésekre és adatbázis műveletekre.
• Olvasási replikák. Irányítsa a nehéz olvasási műveleteket (jelentések, exportok) replikára, hogy ne érintsék az elsődleges adatbázist.

Külön adatbázis előnyei

Bérlőnkénti adatbázisoknál a teljesítmény-elkülönítés beépített. Egy bérlő nehéz munkaterhelése csak a saját adatbázisát érinti. Emellett nagyobb vagy kisebb adatbázisokat is biztosíthat minden bérlő csomagja és használata alapján.

A kompromisszum a kezelési többlet. 500 adatbázis monitorozása nehezebb, mint egyé. Az automatizált eszközök elengedhetetlenné válnak.

Költség vonzatok nagy méretben

Nézzünk néhány hozzávetőleges számot. Tegyük fel, hogy 100 bérlője van.

Megosztott adatbázis (multi-tenant):

• 1 alkalmazás klaszter: ~200 EUR/hó
• 1 felügyelt PostgreSQL példány: ~100 EUR/hó
• Összesen: ~300 EUR/hó (3 EUR bérlőnként)

Külön adatbázisok (multi-tenant):

• 1 alkalmazás klaszter: ~200 EUR/hó
• 100 kis adatbázis példány: ~2 000 EUR/hó
• Összesen: ~2 200 EUR/hó (22 EUR bérlőnként)

Single-tenant:

• 100 alkalmazáspéldány: ~5 000 EUR/hó
• 100 adatbázis példány: ~2 000 EUR/hó
• Összesen: ~7 000 EUR/hó (70 EUR bérlőnként)

Ezek egyszerűsített számok, de a minta helytálló. A megosztott infrastruktúra drámaian olcsóbb. 1 000 bérlőnél a különbség még nagyobb.

Ezért kell az árazásnak összhangban lennie az architektúrával. Ha havi 20 EUR-t számol fel és single-tenant infrastruktúrát futtat bérlőnként 70 EUR-ért, minden ügyfélen veszít.

Mikor válassza a multi-tenant-et

A multi-tenant architektúra a helyes választás, ha:

• B2B SaaS-t épít KKV-knak. Nagy volumen, alacsonyabb árkategória és standard funkciókészlet.
• A költséghatékonyság számít. Alacsonyan kell tartania az infrastruktúra költségeket a bevételhez képest.
• Gyors, egységes frissítéseket akar. Egyszer telepít, minden bérlő megkapja a fejlesztést.
• Az ügyfelei nem igényelnek dedikált infrastruktúrát. A legtöbb kis és közepes vállalkozást nem érdekli, hol vannak az adatai, amíg biztonságban vannak.
• Korai szakaszban van. Kezdjen multi-tenant-tel. Olcsóbb és egyszerűbb. Később bármikor kínálhat single-tenant-et vállalati ügyfeleknek.

Mikor válassza a single-tenant-et

A single-tenant architektúra akkor van értelme, ha:

• Nagyvállalatoknak értékesít. A nagy szervezetek gyakran megkövetelik a dedikált infrastruktúrát a beszerzési folyamat részeként.
• A megfelelőség megköveteli. Az olyan iparágak, mint az egészségügy (HIPAA), pénzügy (SOX, PCI-DSS) és kormányzat, szigorú adatelkülönítési követelményeket támasztanak.
• Az ügyfeleknek testreszabásra van szükségük. Ha minden ügyfél különböző konfigurációkat, integrációkat vagy akár funkciókat igényel, a single-tenant adja meg a rugalmasságot.
• Az árazása támogatja. Ha havi 5 000 EUR-t vagy többet számít fel ügyfelenként, az infrastruktúra költség könnyen indokolható.
• Az adatrezidencia kemény követelmény. Amikor az adatoknak egy adott országban kell maradniuk, a bérlőnkénti külön infrastruktúra a legegyszerűbb megközelítés.

Hibrid megközelítések

Nem kell csak egyet választania. Sok sikeres SaaS vállalat hibrid modellt használ:

• Multi-tenant a standard szintekhez. Az ingyenes, starter és pro ügyfelek megosztott infrastruktúrán vannak. Ez alacsony költségeket és skálázást biztosít.
• Single-tenant enterprise-nak. A prémium ügyfelek dedikált példányokat kapnak egyedi SLA-kkal, megfelelőségi tanúsítványokkal és dedikált támogatással.

Az alkalmazás kódja ugyanaz. A telepítési modell különbözik. Ez jó infrastruktúra automatizálást igényel, de bevált minta.

Hogyan implementáljon hibrid modellt

1. Először multi-tenant-ként építse az alkalmazást. Az összes bérlő-elkülönítési logika ugyanaz marad a telepítési modelltől függetlenül.
2. Használjon infrastructure-as-code-ot (Terraform, Pulumi vagy CDK) a környezet létrehozásának automatizálásához.
3. Hozzon létre egy provisioning csővezetéket, amely percek alatt, nem napok alatt tudja felállítani az új dedikált környezetet.
4. Tartson fenn egyetlen kódbázist. Ugyanaz a Docker image fut mind a megosztott, mind a dedikált környezetekben. A konfiguráció (nem a kód) határozza meg a viselkedést.

Adatbázis stratégiák részletesen

Az adatbázis az, ahol a bérleti döntéseknek a legnagyobb hatása van. Íme három bevált stratégia.

1. stratégia: Megosztott táblák tenant_id-vel

Minden táblának van tenant_id oszlopa. Minden lekérdezés szűr rá.

CREATE TABLE projects (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id),
  name TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

CREATE INDEX idx_projects_tenant ON projects(tenant_id);

-- Mindig bérlő kontextussal lekérdezni
SELECT * FROM projects WHERE tenant_id = $1;

Legjobb: a legtöbb SaaS termékhez. Egyszerű, költséghatékony, jól ismert.

2. stratégia: Bérlőnkénti séma

Minden bérlő saját PostgreSQL sémát kap egy megosztott adatbázison belül. A táblák szerkezete azonos, de az adatok fizikailag elkülönítettek.

-- Séma létrehozása új bérlőhöz
CREATE SCHEMA tenant_abc123;

-- Táblák létrehozása a bérlő sémájában
CREATE TABLE tenant_abc123.projects (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Keresési útvonal beállítása kérésenként
SET search_path TO tenant_abc123, public;

-- Most a lekérdezések automatikusan szűkítettek
SELECT * FROM projects;

Legjobb: erősebb elkülönítést igénylő, de a külön adatbázisok költségét el nem viselő termékekhez. Jól működik néhány száz bérlőig.

3. stratégia: Külön adatbázisok

Minden bérlő dedikált PostgreSQL példányt kap (vagy dedikált adatbázist egy megosztott szerveren).

// Adatbázis-kapcsolat irányítás
class TenantDatabaseRouter {
  private connections: Map<string, DatabasePool> = new Map();

  async getConnection(tenantId: string): Promise<DatabasePool> {
    if (this.connections.has(tenantId)) {
      return this.connections.get(tenantId)!;
    }

    const config = await this.loadTenantDbConfig(tenantId);
    const pool = new DatabasePool({
      host: config.host,
      port: config.port,
      database: config.database,
      user: config.user,
      password: config.password,
    });

    this.connections.set(tenantId, pool);
    return pool;
  }

  private async loadTenantDbConfig(tenantId: string): Promise<DbConfig> {
    // Bérlő adatbázis-kapcsolati adatainak keresése
    // központi konfigurációs tárból
    return await configStore.get(`tenants/${tenantId}/database`);
  }
}

Legjobb: nagy értékű ügyfelekkel rendelkező vállalati SaaS-hoz, szigorú megfelelőségi követelményekkel vagy adatrezidencia kötelezettségekkel.

A döntés meghozatala

Íme egy egyszerű döntési keretrendszer:

1. Mi a célügyfél mérete? KKV a multi-tenant felé mutat. Nagyvállalat a single-tenant vagy hibrid felé.
2. Mi az árazása? Havi 100 EUR alatt multi-tenant kell a nyereségességhez. Havi 1 000 EUR felett a single-tenant megvalósíthatóvá válik.
3. Mik a megfelelőségi követelmények? A szabályozott iparágak gyakran erősebb elkülönítést igényelnek.
4. Hány bérlőre számít? Százak vagy ezrek bérlőnek megosztott infrastruktúra kell. Tíz-ötven nagy bérlő működhet dedikált példányokkal.
5. Mi a csapata operatív kapacitása? A single-tenant több DevOps befektetést igényel. A multi-tenant operatívAN egyszerűbb.

Ha bizonytalan, kezdjen multi-tenant-tel megosztott adatbázissal és sorszintű biztonsággal. Ez a legolcsóbb opció, helyesen implementálva biztonságos, és egyszerűen tartja az architektúráját. Később bármikor hozzáadhat dedikált szintet vállalati ügyfeleknek.

Összegzés

Nincs univerzálisan helyes bérleti modell. A helyes választás az ügyfeleitől, árazásától, megfelelőségi követelményeitől és operatív képességeitől függ.

A legtöbb SaaS terméknek multi-tenant-tel kell kezdenie. Olcsóbb, egyszerűbb és jól skálázódik. Ahogy feljebb lép a piacon és nagyobb szervezeteknek kezd értékesíteni, adjon hozzá single-tenant opciókat azoknak az ügyfeleknek, akiknek szükségük van rájuk és ennek megfelelően fizetnek.

Az architektúrának az üzletet kell szolgálnia, nem fordítva. Építsen azoknak az ügyfeleknek, akik ma vannak, és tervezzen elég rugalmassággal, hogy kiszolgálja azokat az ügyfeleket, akiket holnap szeretne.

---

Segítségre van szüksége a SaaS terméke megfelelő architektúrájának kiválasztásához? Multi-tenant és single-tenant rendszereket egyaránt építettünk különböző iparágakban. Találjuk ki a legjobb megközelítést a projektjéhez.