Mitme üürniku vs ühe üürniku | Õige SaaS arhitektuuri valimine

Iga SaaS toode peab vastama põhimõttelisele küsimusele: kuidas teenindate mitut klienti samast tarkvarast? Vastus on teie üürniku mudel. See mõjutab kulusid, turvalisust, jõudlust ja seda, kui kiiresti saate tarnida. Selle varajane õigeks saamine säästab teid valusatest migratsioonidest hiljem.

Definitsioonid

Mitme üürnikuga

Üks rakenduse eksemplar teenindab kõiki kliente. Kõik jagavad samu servereid, sama koodibaasi ja sageli sama andmebaasi. Iga kliendi andmed on loogiliselt isoleeritud, kuid infrastruktuur on jagatud.

Mõelge sellest nagu korterelamu. Iga üürnik elab samas hoones, jagab lifti ja koridore, kuid tal on oma lukustatud korter oma mööbliga.

Ühe üürnikuga

Iga klient saab oma pühendunud rakenduse eksemplari. Eraldi serverid, eraldi andmebaasid, mõnikord eraldi koodibaasid. Klientide vahel ei jagata midagi.

Mõelge sellest nagu eraldiseisvad majad. Igal üürnikul on oma hoone, oma torustik, oma aed. Täielik isolatsioon, kuid kallim hooldada.

Kuidas mitme üürniku arhitektuur töötab

Mitme üürniku arhitektuuri jaoks on kolm levinud lähenemist, igaühel erinevad kompromissid.

Mudel 1: jagatud rakendus, jagatud andmebaas

Kõik üürnikud jagavad ühte rakenduse eksemplari ja ühte andmebaasi. Üürniku andmed eraldatakse üürniku identifikaatori (tavaliselt tenant_id veerg) abil igas tabelis.

Arhitektuur:

• Üks rakendusserver (või klaster) käsitleb kõiki päringuid.
• Üks andmebaas salvestab kõigi üürnike andmed.
• Iga päring sisaldab WHERE tenant_id = ? klauslit andmete piiramiseks õigele üürnikule.

Plussid:

• Madalaim infrastruktuuri kulu. Üks andmebaas, üks rakenduse juurutus.
• Lihtsaim juurutada ja uuendada. Suruge korra, kõik saavad muudatuse.
• Lihtne andmeid üürnike lõikes analüütika ja aruandluse jaoks koondada.

Miinused:

• Kõrgeim andmelekke risk, kui päring unustab üürniku filtri.
• Üks mürakas üürnik võib kõigi jõudlust halvendada.
• Andmebaasi migratsioonid mõjutavad kõiki üürnikke samaaegselt.
• Kõige raskem andmete asukohanõuetele vastata.

See on kõige levinum lähenemine B2B SaaS toodetele suure hulga väikeste kuni keskmiste klientidega.

Mudel 2: jagatud rakendus, eraldi andmebaasid

Kõik üürnikud jagavad sama rakenduse eksemplari, kuid iga üürnik saab oma andmebaasi. Rakendus suunab päringud õigesse andmebaasi vastavalt autenditud üürnikule.

Arhitektuur:

• Üks rakendusserver (või klaster) käsitleb kõiki päringuid.
• Eraldi andmebaas iga üürniku jaoks.
• Suunamiskiht kaardistab üürniku identiteedi õigele andmebaasiühendusele.

Plussid:

• Tugevam andmeisolatsioon. Üürnike vaheliste päringute riski pole.
• Lihtsam andmete asukohanõuetele vastata. Saate paigutada iga andmebaasi üürniku nõutud piirkonda.
• Üürniku kaupa varundamine ja taastamine on lihtne.
• Ühe üürniku raske kasutus ei lukusta teiste üürnike tabeleid.

Miinused:

• Rohkem infrastruktuuri haldada. Sajad üürnikud tähendab sadu andmebaase.
• Skeemi migratsioonid tuleb rakendada igale andmebaasile eraldi.
• Üürnike ülene aruandlus nõuab mitmest andmebaasist pärimist.
• Kõrgem kulu kui täielikult jagatud mudel.

See on tugev kesktee toodetele, mis vajavad paremat isolatsiooni ilma täieliku ühe üürniku kuluta.

Mudel 3: eraldi rakendus, eraldi andmebaas

Iga üürnik saab oma rakenduse eksemplari ja oma andmebaasi. Täielikult isoleeritud. See on sisuliselt ühe üürniku arhitektuur, kuid mida haldab SaaS pakkuja kliendi asemel.

Arhitektuur:

• Pühendunud rakenduse juurutus üürniku kohta.
• Pühendunud andmebaas üürniku kohta.
• Suunamiskiht (sageli koormuse tasakaalustaja või API värav) suunab liikluse õigesse eksemplari.

Plussid:

• Täielik isolatsioon. Jagatud ressursse üürnike vahel ei ole.
• Maksimaalne paindlikkus kohandamiseks üürniku kohta.
• Ühe üürniku jõudlus ei mõjuta kunagi teist.
• Lihtsaim vastavuslugu.

Miinused:

• Kõrgeim infrastruktuurikulu kaugelt.
• Juurutamise keerukus kasvab lineaarselt üürnike arvuga.
• Uuendused tuleb iga eksemplari jaoks eraldi (või väga hoolikalt automatiseeritult) välja rullida.
• Ei skaleeru majanduslikult suure hulga väikeste üürnike jaoks.

See mudel on mõistlik suurettevõtete SaaS-ile, kus kliendid nõuavad pühendunud infrastruktuuri ja on nõus selle eest lisatasu maksma.

Plussid ja miinused ülevaates

Tegur	Mitme üürnikuga (jagatud AB)	Mitme üürnikuga (eraldi AB)	Ühe üürnikuga
Infrastruktuuri kulu	Madalaim	Keskmine	Kõrgeim
Andmeisolatsioon	Loogiline (reataseme)	Füüsiline (andmebaasitaseme)	Täielik
Juurutamise keerukus	Madal	Keskmine	Kõrge
Uuendamise kiirus	Kohene kõigile	Kohene rakendus, AB-kaupa migratsioonid	Eksemplari kaupa väljamine
Kohandamine	Piiratud	Piiratud	Täielik
Vastavus	Raskem	Mõõdukas	Lihtsaim
Skaleeritavus (üürnike arv)	Suurepärane	Hea	Halb
Mürakad naaber risk	Kõrge	Keskmine	Puudub

Andmeisolatsioon ja turvalisus

Andmeisolatsioon on mis tahes üürniku mudeli kõige olulisem kaalutlus. Turvalisuse rikkumine, kus üks üürnik pääseb teise üürniku andmetele ligi, on SaaS ettevõtte jaoks katastroofiline. See võib hävitada usalduse, rikkuda regulatsioone ja lõpetada ettevõtte.

Reataseme turvalisus

Jagatud andmebaasi mudelis on PostgreSQL-i reataseme turvalisus (RLS) üks tugevaimaid kaitseid andmelekke vastu. RLS jõustab üürnike isolatsiooni andmebaasi tasemel, mitte rakenduse tasemel. Isegi kui teie rakendusekoodi on viga, mis unustab üürniku järgi filtreerimise, takistab andmebaas ise üürnike vahelist juurdepääsu.

Siin on, kuidas seda seadistada:

-- Enable RLS on a table
ALTER TABLE projects ENABLE ROW LEVEL SECURITY;

-- Create a policy that restricts access to the current tenant
CREATE POLICY tenant_isolation ON projects
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);

-- Force RLS even for table owners
ALTER TABLE projects FORCE ROW LEVEL SECURITY;

Enne mis tahes päringu täitmist seadke üürniku kontekst:

-- Set at the beginning of each request/transaction
SET LOCAL app.current_tenant_id = 'a1b2c3d4-e5f6-7890-abcd-ef1234567890';

-- Now this query automatically returns only the current tenant's data
SELECT * FROM projects;
-- No WHERE clause needed. RLS handles it.

Rakendusetaseme isolatsioon

Lisaks andmebaasitaseme turvalisusele peaks teie rakendus jõustama üürniku piire:

// Middleware that sets tenant context on every request
async function tenantMiddleware(req: Request, res: Response, next: NextFunction) {
  const tenantId = extractTenantId(req); // From JWT, subdomain, or header

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

  // Set tenant context for the database connection
  await db.raw(`SET LOCAL app.current_tenant_id = '${tenantId}'`);

  req.tenantId = tenantId;
  next();
}

Kaitse sügavuti on siin põhimõte. Ärge kunagi lootke ühele isolatsioonikihile. Kombineerige rakendusetaseme filtreerimist, andmebaasitaseme turvalisust ja regulaarseid turvaauditeid.

Jõudluse kaalutlused

Jagatud andmebaasi väljakutsed

Jagatud andmebaasis võistlevad kõik üürnikud samade ressursside pärast. Üürnik, kes käitab rasket aruannet, võib aeglustada kõigi teiste päringuid. Leevendamismeetmed sisaldavad:

• Ühenduse koondamine. Kasutage PgBouncer’it või sarnast tööriista, et takistada ühe üürniku poolt andmebaasi ühenduste ammendamist.
• Päringu aegumised. Seadke maksimaalsed täitmisajad, et kontrollist väljunud päring ei saaks ressursse lõputult lukustada.
• Piirangud. Jõustage üürniku kohta piirangud API päringutele ja andmebaasi operatsioonidele.
• Lugemiskoopiad. Suunake rasked lugemisoperatsioonid (aruanded, ekspordid) koopiasse, et need ei mõjutaks peamist andmebaasi.

Eraldi andmebaasi eelised

Üürniku kohta andmebaasidega on jõudluse isolatsioon sisseehitatud. Ühe üürniku raske töökoormus mõjutab ainult nende enda andmebaasi. Saate ka suuremaid või väiksemaid andmebaase eraldada vastavalt iga üürniku plaanile ja kasutusele.

Kompromiss on halduskoormis. 500 andmebaasi jälgimine on raskem kui ühe jälgimine. Automatiseeritud tööriistamine muutub hädavajalikuks.

Kulutagajärjed mahus

Vaadame mõnda umbkaudset numbrit. Oletame, et teil on 100 üürnikku.

Jagatud andmebaas (mitme üürnikuga):

• 1 rakendusklaster: ~200 eurot/kuu
• 1 hallatav PostgreSQL eksemplar: ~100 eurot/kuu
• Kokku: ~300 eurot/kuu (3 eurot üürniku kohta)

Eraldi andmebaasid (mitme üürnikuga):

• 1 rakendusklaster: ~200 eurot/kuu
• 100 väikest andmebaasi eksemplari: ~2000 eurot/kuu
• Kokku: ~2200 eurot/kuu (22 eurot üürniku kohta)

Ühe üürnikuga:

• 100 rakenduse eksemplari: ~5000 eurot/kuu
• 100 andmebaasi eksemplari: ~2000 eurot/kuu
• Kokku: ~7000 eurot/kuu (70 eurot üürniku kohta)

Need numbrid on lihtsustatud, kuid muster kehtib. Jagatud infrastruktuur on dramaatiliselt odavam. 1000 üürniku juures muutub vahe veelgi suuremaks.

Seepärast peab hinnakujundus ühtima arhitektuuriga. Kui küsite 20 eurot kuus ja käitate ühe üürniku infrastruktuuri 70 euro eest üürniku kohta, kaotate igalt kliendilt raha.

Millal valida mitme üürnikuga

Mitme üürniku arhitektuur on õige valik, kui:

• Ehitate B2B SaaS-i SMB-dele. Suur maht, madalamad hinnapunktid ja standardsed funktsioonide komplektid.
• Kuluefektiivsus on oluline. Peate hoidma infrastruktuuri kulud tuluga võrreldes madalad.
• Soovite kiireid, ühtlaseid uuendusi. Juurutage korra, kõik üürnikud saavad paranduse.
• Teie kliendid ei nõua pühendunud infrastruktuuri. Enamik väikeseid ja keskmisi ettevõtteid ei hooli, kus nende andmed asuvad, kui need on turvalised.
• Olete varases staadiumis. Alustage mitme üürnikuga. See on odavam ja lihtsam. Saate alati hiljem suurettevõtete klientidele ühe üürniku pakkuda.

Millal valida ühe üürnikuga

Ühe üürniku arhitektuur on mõistlik, kui:

• Müüte suurettevõtetele. Suured organisatsioonid nõuavad sageli pühendunud infrastruktuuri osana oma hankeprotsessist.
• Vastavus nõuab seda. Tööstusharud nagu tervishoid (HIPAA), rahandus (SOX, PCI-DSS) ja valitsus omavad rangeid andmeisolatsiooni nõudeid.
• Kliendid vajavad kohandamist. Kui iga klient vajab erinevaid konfiguratsioone, integratsioone või isegi funktsioone, annab ühe üürniku arhitektuur teile paindlikkuse.
• Teie hinnapunkt toetab seda. Kui küsite 5000 eurot või rohkem kuus kliendi kohta, on infrastruktuuri kulu kergesti õigustatud.
• Andmete asukohanõue on range nõue. Kui andmed peavad asuma konkreetses riigis, on eraldi infrastruktuur üürniku kohta kõige otsekohesem lähenemine.

Hübriidlähenemised

Te ei pea valima ainult ühte. Paljud edukad SaaS ettevõtted kasutavad hübriidmudelit:

• Mitme üürnikuga standardtasemete jaoks. Tasuta, alustaja ja pro kliendid jagavad infrastruktuuri. See hoiab kulud madalad ja laseb teil skaleeruda.
• Ühe üürnikuga suurettevõtete jaoks. Premium kliendid saavad pühendunud eksemplarid kohandatud SLA-dega, vastavussertifikaatidega ja pühendunud toega.

Rakenduse kood on sama. Juurutamise mudel erineb. See nõuab head infrastruktuuri automatiseerimist, kuid see on tõestatud muster.

Kuidas hübriidmudelit rakendada

1. Ehitage rakendus esmalt mitme üürnikuna. Kogu üürniku isolatsiooni loogika jääb samaks sõltumata juurutamise mudelist.
2. Kasutage infrastruktuuri-koodina (Terraform, Pulumi või CDK) keskkonna loomise automatiseerimiseks.
3. Looge provisjoneerimise torustik, mis suudab uue pühendunud keskkonna minutitega üles panna, mitte päevadega.
4. Hoidke üht koodibaasi. Sama Docker’i kujutis töötab nii jagatud kui pühendunud keskkondades. Konfiguratsioon (mitte kood) määrab käitumise.

Andmebaasi strateegiad üksikasjalikult

Andmebaas on koht, kus üürniku otsustel on suurim mõju. Siin on kolm tõestatud strateegiat.

Strateegia 1: jagatud tabelid tenant_id-ga

Igal tabelil on tenant_id veerg. Kõik päringud filtreerivad selle järgi.

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);

-- Always query with tenant context
SELECT * FROM projects WHERE tenant_id = $1;

Sobib paremini: enamikule SaaS toodetele. Lihtne, kuluefektiivne, hästi mõistetud.

Strateegia 2: skeem üürniku kohta

Iga üürnik saab oma PostgreSQL skeemi jagatud andmebaasi sees. Tabelitel on sama struktuur, kuid andmed on füüsiliselt eraldatud.

-- Create a schema for a new tenant
CREATE SCHEMA tenant_abc123;

-- Create tables in the tenant's schema
CREATE TABLE tenant_abc123.projects (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Set the search path per request
SET search_path TO tenant_abc123, public;

-- Now queries are automatically scoped
SELECT * FROM projects;

Sobib paremini: toodetele, mis vajavad tugevamat isolatsiooni kui reataseme, kuid ei soovi eraldi andmebaaside kulu. Töötab hästi kuni mõnesaja üürnikuni.

Strateegia 3: eraldi andmebaasid

Iga üürnik saab pühendunud PostgreSQL eksemplari (või pühendunud andmebaasi jagatud serveris).

// Database connection routing
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> {
    // Look up tenant's database connection details
    // from a central configuration store
    return await configStore.get(`tenants/${tenantId}/database`);
  }
}

Sobib paremini: suurettevõtete SaaS-ile kõrge väärtusega klientidega, rangete vastavusnõuetega või andmete asukohanõuetega.

Otsuse tegemine

Siin on lihtne otsustusraamistik:

1. Milline on teie sihtgrupi kliendi suurus? SMB osutab mitme üürnikule. Suurettevõte osutab ühe üürniku või hübriidi suunas.
2. Milline on teie hinnapunkt? Alla 100 euro/kuu vajate mitme üürnikut, et olla kasumlik. Üle 1000 euro/kuu muutub ühe üürniku teostatavaks.
3. Millised on vastavusnõuded? Reguleeritud tööstusharud nõuavad sageli tugevamat isolatsiooni.
4. Mitu üürnikku ootate? Sajad või tuhanded üürnikud vajavad jagatud infrastruktuuri. Kümme kuni viiskümmend suurt üürnikku suudavad töötada pühendunud eksemplaridega.
5. Milline on teie meeskonna operatiivne võimekus? Ühe üürniku nõuab rohkem DevOps investeeringut. Mitme üürnikuga on operatiivselt lihtsam.

Kui te pole kindel, alustage mitme üürnikuga, kasutades jagatud andmebaasi ja reataseme turvalisust. See on madalaima kuluga valik, see on turvaliselt rakendatuna turvaline ja see hoiab teie arhitektuuri lihtsa. Saate alati hiljem lisada pühendunud taseme suurettevõtete klientide jaoks.

Kokkuvõte

Universaalselt korrektset üürniku mudelit ei ole olemas. Õige valik sõltub teie klientidest, teie hinnakujundusest, teie vastavusnõuetest ja teie operatiivsetest võimekustest.

Enamik SaaS tooteid peaks alustama mitme üürnikuga. See on odavam, lihtsam ja skaleerub hästi. Kui liigute turuga ülespoole ja hakkate müüma suurematele organisatsioonidele, lisage ühe üürniku valikud klientidele, kes seda vajavad ja vastavalt maksavad.

Arhitektuur peaks teenima ettevõtet, mitte vastupidi. Ehitage klientidele, kes teil täna on, ja kujundage piisava paindlikkusega, et teenindada kliente, keda soovite homme.

---

Vajate abi oma SaaS toote jaoks õige arhitektuuri valimisel? Oleme ehitanud mitme üürniku ja ühe üürniku süsteeme erinevates tööstusharudes. Selgitame välja parima lähenemise teie projektile.