Večnajemniško ali enonajemniško | Izbira prave SaaS arhitekture

Vsak SaaS izdelek mora odgovoriti na temeljno vprašanje: kako služiti več strankam iz iste programske opreme? Odgovor je vaš model najemništva. Vpliva na stroške, varnost, zmogljivost in hitrost dostave. Pravilna zgodnja izbira vam prihrani boleče migracije pozneje.

Opredelitve

Večnajemniško

Ena instanca aplikacije služi vsem strankam. Vsi si delijo iste strežnike, isto zbirko kode in pogosto isto bazo podatkov. Podatki vsake stranke so logično izolirani, infrastruktura pa je deljena.

Predstavljajte si ga kot stanovanjski blok. Vsak najemnik živi v isti zgradbi, si deli dvigalo in hodnike, ima pa lastno zaklenjeno enoto z lastnim pohištvom.

Enonajemniško

Vsaka stranka dobi svojo namensko instanco aplikacije. Ločeni strežniki, ločene baze podatkov, včasih ločene zbirke kode. Med strankami ni ničesar deljenega.

Predstavljajte si ga kot samostojne hiše. Vsak najemnik ima svojo zgradbo, lastno vodovodno instalacijo, lasten vrt. Popolna izolacija, toda dražje za vzdrževanje.

Kako večnajemništvo deluje

Obstajajo trije pogosti pristopi k večnajemniški arhitekturi, vsak z različnimi kompromisi.

Model 1: Deljena aplikacija, deljena baza podatkov

Vsi najemniki si delijo eno instanco aplikacije in eno bazo podatkov. Podatki najemnikov so ločeni z identifikatorjem najemnika (običajno stolpec tenant_id) v vsaki tabeli.

Arhitektura:

• En aplikacijski strežnik (ali grozd) obravnava vse zahteve.
• Ena baza podatkov shranjuje vse podatke najemnikov.
• Vsaka poizvedba vključuje klavzulo WHERE tenant_id = ? za omejitev podatkov na pravilnega najemnika.

Prednosti:

• Najnižji stroški infrastrukture. Ena baza podatkov, ena uvedba aplikacije.
• Najpreprostejša uvedba in posodabljanje. Uvedite enkrat, vsi dobijo spremembo.
• Enostavno združevanje podatkov med najemniki za analitiko in poročanje.

Slabosti:

• Najvišje tveganje uhajanja podatkov, če poizvedba pozabi filter najemnika.
• En hrupen najemnik lahko poslabša zmogljivost za vse.
• Migracije baze podatkov vplivajo na vse najemnike hkrati.
• Najtežje izpolniti zahteve glede rezidence podatkov.

To je najpogostejši pristop za B2B SaaS izdelke z velikim številom malih do srednje velikih strank.

Model 2: Deljena aplikacija, ločene baze podatkov

Vsi najemniki si delijo isto instanco aplikacije, toda vsak najemnik dobi svojo bazo podatkov. Aplikacija usmerja poizvedbe v pravilno bazo podatkov na podlagi avtenticiranega najemnika.

Arhitektura:

• En aplikacijski strežnik (ali grozd) obravnava vse zahteve.
• Ločena baza podatkov za vsakega najemnika.
• Usmerjevalna plast preslika identiteto najemnika v pravilno povezavo baze podatkov.

Prednosti:

• Močnejša izolacija podatkov. Brez tveganja mednajemerniških poizvedb.
• Lažje izpolnjevanje zahtev glede rezidence podatkov. Vsako bazo podatkov lahko umestite v zahtevano regijo najemnika.
• Varnostno kopiranje in obnavljanje po najemniku sta preprosta.
• Težka uporaba enega najemnika ne zaklepa tabel za druge najemnike.

Slabosti:

• Več infrastrukture za upravljanje. Sto najemnikov pomeni sto baz podatkov.
• Migracije sheme je treba uporabiti za vsako bazo podatkov posamično.
• Mednajemerniško poročanje zahteva poizvedovanje več baz podatkov.
• Višji stroški kot popolnoma deljeni model.

To je močna srednja pot za izdelke, ki potrebujejo boljšo izolacijo brez stroškov polnega enonajemništva.

Model 3: Ločena aplikacija, ločena baza podatkov

Vsak najemnik dobi svojo namensko instanco aplikacije in svojo bazo podatkov. Popolnoma izolirano. To je v bistvu enonajemništvo, toda upravljano s strani SaaS ponudnika namesto stranke.

Arhitektura:

• Namenska uvedba aplikacije za vsakega najemnika.
• Namenska baza podatkov za vsakega najemnika.
• Usmerjevalna plast (pogosto izravnalnik obremenitve ali API prehod) usmerja promet v pravilno instanco.

Prednosti:

• Popolna izolacija. Brez deljenih virov med najemniki.
• Maksimalna prilagodljivost za prilagoditev po najemniku.
• Zmogljivost enega najemnika nikoli ne vpliva na drugega.
• Najpreprotejša zgodba o skladnosti.

Slabosti:

• Daleč najvišji stroški infrastrukture.
• Zapletenost uvedbe raste linearno s številom najemnikov.
• Posodobitve je treba uvesti za vsako instanco posamično (ali zelo skrbno avtomatizirano).
• Ekonomsko ne skalira za veliko število majhnih najemnikov.

Ta model je smiselen za poslovni SaaS, kjer stranke zahtevajo namensko infrastrukturo in so pripravljene plačati premijo zanjo.

Prednosti in slabosti na prvi pogled

Dejavnik	Večnajemniško (deljena BP)	Večnajemniško (ločena BP)	Enonajemniško
Stroški infrastrukture	Najnižji	Srednji	Najvišji
Izolacija podatkov	Logična (na ravni vrstic)	Fizična (na ravni baze podatkov)	Popolna
Zapletenost uvedbe	Nizka	Srednja	Visoka
Hitrost posodobitev	Takojšnja za vse	Takojšnja aplikacija, migracije po BP	Uvedba po instancah
Prilagoditev	Omejena	Omejena	Popolna
Skladnost	Težja	Zmerna	Najlažja
Skalabilnost (število najemnikov)	Odlična	Dobra	Slaba
Tveganje hrupa soseda	Visoko	Srednje	Brez

Izolacija in varnost podatkov

Izolacija podatkov je najpomembnejši vidik vsakega modela najemništva. Varnostna kršitev, pri kateri en najemnik lahko dostopa do podatkov drugega najemnika, je katastrofalna za SaaS podjetje. Lahko uniči zaupanje, krši regulacije in konča podjetje.

Varnost na ravni vrstic

V modelu z deljeno bazo podatkov je Row-Level Security (RLS) v PostgreSQL ena najmočnejših obramb pred uhajanjem podatkov. RLS uveljavlja izolacijo najemnikov na ravni baze podatkov, ne na ravni aplikacije. Tudi če ima vaša aplikacijska koda hrošč, ki pozabi filtrirati po najemniku, baza podatkov sama preprečuje mednajemerniški dostop.

Tukaj je, kako jo nastaviti:

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

Pred izvajanjem katerekoli poizvedbe nastavite kontekst najemnika:

-- 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.

Izolacija na ravni aplikacije

Poleg varnosti na ravni baze podatkov mora vaša aplikacija uveljavljati meje najemnikov:

// 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();
}

Obramba v globino je načelo tukaj. Nikoli se ne zanašajte na eno samo plast izolacije. Kombinirajte filtriranje na ravni aplikacije, varnost na ravni baze podatkov in redne varnostne revizije.

Zmogljivostni vidiki

Izzivi deljene baze podatkov

V deljeni bazi podatkov vsi najemniki tekmujejo za iste vire. Najemnik, ki poganja težko poročilo, lahko upočasni poizvedbe za vse ostale. Ukrepi za ublažitev vključujejo:

• Združevanje povezav. Uporabite PgBouncer ali podobno orodje za preprečevanje, da en najemnik izčrpa povezave baze podatkov.
• Časovne omejitve poizvedb. Nastavite največje čase izvajanja, da pobegla poizvedba ne more zakleniti virov za nedoločen čas.
• Omejevanje hitrosti. Uveljavljajte omejitve na najemnika za API zahteve in operacije baze podatkov.
• Bralne replike. Usmerite težke bralne operacije (poročila, izvoze) na repliko, da ne vplivajo na primarno bazo podatkov.

Prednosti ločenih baz podatkov

Z bazami podatkov po najemniku je izolacija zmogljivosti vgrajena. Težka obremenitev enega najemnika vpliva le na njegovo lastno bazo podatkov. Prav tako lahko dodelite večje ali manjše baze podatkov glede na paket in uporabo vsakega najemnika.

Kompromis je upravljavski dodatni stroški. Spremljanje 500 baz podatkov je težje od spremljanja ene. Avtomatizirano orodje postane bistveno.

Stroškovne posledice na obsegu

Poglejmo nekaj grobih številk. Predpostavimo, da imate 100 najemnikov.

Deljena baza podatkov (večnajemniško):

• 1 aplikacijski grozd: ~200 EUR/mesec
• 1 upravljana instanca PostgreSQL: ~100 EUR/mesec
• Skupaj: ~300 EUR/mesec (3 EUR na najemnika)

Ločene baze podatkov (večnajemniško):

• 1 aplikacijski grozd: ~200 EUR/mesec
• 100 majhnih instanc baz podatkov: ~2.000 EUR/mesec
• Skupaj: ~2.200 EUR/mesec (22 EUR na najemnika)

Enonajemniško:

• 100 aplikacijskih instanc: ~5.000 EUR/mesec
• 100 instanc baz podatkov: ~2.000 EUR/mesec
• Skupaj: ~7.000 EUR/mesec (70 EUR na najemnika)

Te številke so poenostavljene, toda vzorec drži. Deljena infrastruktura je dramatično cenejša. Pri 1.000 najemnikih je razlika še večja.

Zato morajo cene ustrezati arhitekturi. Če zaračunavate 20 EUR na mesec in poganjate enonajemniško infrastrukturo po 70 EUR na najemnika, izgubljate denar pri vsaki stranki.

Kdaj izbrati večnajemniško

Večnajemniška arhitektura je prava izbira, ko:

• Gradite B2B SaaS za SMB-je. Velik obseg, nižje cenovne točke in standardni nabori funkcionalnosti.
• Je stroškovna učinkovitost pomembna. Stroške infrastrukture morate ohranjati nizke glede na prihodke.
• Želite hitre, enote posodobitve. Uvedite enkrat, vsi najemniki dobijo izboljšavo.
• Vaše stranke ne zahtevajo namenske infrastrukture. Večina malih in srednje velikih podjetij ne skrbi, kje so njihovi podatki, dokler so varni.
• Ste v zgodnjih fazah. Začnite večnajemniško. Je cenejše in preprostejše. Enonajemniško lahko vedno ponudite pozneje za poslovne stranke.

Kdaj izbrati enonajemniško

Enonajemniška arhitektura je smiselna, ko:

• Prodajate podjetjem. Velike organizacije pogosto zahtevajo namensko infrastrukturo kot del svojega naročniškega procesa.
• Skladnost to zahteva. Panoge kot so zdravstvo (HIPAA), finance (SOX, PCI-DSS) in vlada imajo stroge zahteve glede izolacije podatkov.
• Stranke potrebujejo prilagoditev. Če vsaka stranka zahteva različne konfiguracije, integracije ali celo funkcionalnosti, vam enonajemniško daje prilagodljivost.
• Vaša cenovna točka to podpira. Če zaračunavate 5.000 EUR ali več na mesec na stranko, so stroški infrastrukture enostavno upravičeni.
• Rezidenca podatkov je trda zahteva. Ko morajo podatki bivati v določeni državi, je ločena infrastruktura po najemniku najpreprotejši pristop.

Hibridni pristopi

Ni vam treba izbrati le enega. Mnoga uspešna SaaS podjetja uporabljajo hibridni model:

• Večnajemniško za standardne razrede. Brezplačne, začetne in profesionalne stranke si delijo infrastrukturo. To ohranja nizke stroške in omogoča skaliranje.
• Enonajemniško za poslovne stranke. Premium stranke dobijo namenske instance s prilagojenimi SLA, certifikacijami skladnosti in namensko podporo.

Aplikacijska koda je ista. Model uvedbe se razlikuje. To zahteva dobro avtomatizacijo infrastrukture, toda je preizkušen vzorec.

Kako implementirati hibridni model

1. Najprej zgradite aplikacijo kot večnajemniško. Celotna logika izolacije najemnikov ostane enaka ne glede na model uvedbe.
2. Uporabite infrastrukturo-kot-kodo (Terraform, Pulumi ali CDK) za avtomatizacijo ustvarjanja okolij.
3. Ustvarite cevovod za dodeljevanje, ki lahko postavi novo namensko okolje v minutah, ne dneh.
4. Vzdržujte eno samo zbirko kode. Ista Docker slika teče v deljenih in namenskih okoljih. Konfiguracija (ne koda) določa vedenje.

Strategije baz podatkov podrobno

Baza podatkov je tista, kjer imajo odločitve o najemništvu največji vpliv. Tukaj so tri dokazane strategije.

Strategija 1: Deljene tabele s tenant_id

Vsaka tabela ima stolpec tenant_id. Vse poizvedbe filtrirajo po njem.

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;

Najboljše za: večino SaaS izdelkov. Preprosto, stroškovno učinkovito, dobro razumljeno.

Strategija 2: Shema po najemniku

Vsak najemnik dobi svojo PostgreSQL shemo znotraj deljene baze podatkov. Tabele imajo enako strukturo, toda podatki so fizično ločeni.

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

Najboljše za: izdelke, ki potrebujejo močnejšo izolacijo od ravni vrstic, toda ne želijo stroškov ločenih baz podatkov. Deluje dobro do nekaj sto najemnikov.

Strategija 3: Ločene baze podatkov

Vsak najemnik dobi namensko instanco PostgreSQL (ali namensko bazo podatkov na deljenem strežniku).

// 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`);
  }
}

Najboljše za: poslovni SaaS z visoko-vrednostnimi strankami, strogimi zahtevami skladnosti ali obveznostmi glede rezidence podatkov.

Sprejemanje odločitve

Tukaj je preprost okvir za odločanje:

1. Kakšna je velikost vaše ciljne stranke? SMB kaže na večnajemniško. Podjetja kažejo na enonajemniško ali hibridno.
2. Kakšna je vaša cenovna točka? Pod 100 EUR/mesec potrebujete večnajemniško za dobičkonosnost. Nad 1.000 EUR/mesec postane enonajemniško izvedljivo.
3. Kakšne so zahteve skladnosti? Regulirane panoge pogosto zahtevajo močnejšo izolacijo.
4. Koliko najemnikov pričakujete? Stotine ali tisoče najemnikov potrebujejo deljeno infrastrukturo. Deset do petdeset velikih najemnikov lahko deluje z namenskimi instancami.
5. Kakšna je operativna zmogljivost vaše ekipe? Enonajemniško zahteva več investicij v DevOps. Večnajemniško je operativno preprostejše.

Če niste prepričani, začnite z večnajemniškim z deljeno bazo podatkov in varnostjo na ravni vrstic. Je najcenejša možnost, varna ob pravilni implementaciji in ohranja vašo arhitekturo preprosto. Namenski razred za poslovne stranke lahko vedno dodate pozneje.

Bistvo

Ne obstaja univerzalno pravilni model najemništva. Prava izbira je odvisna od vaših strank, vaše cenovne politike, vaših zahtev skladnosti in vaših operativnih zmogljivosti.

Večina SaaS izdelkov bi morala začeti večnajemniško. Je cenejše, preprostejše in dobro skalira. Ko se premaknete navzgor po trgu in začnete prodajati večjim organizacijam, dodajte enonajemniške možnosti za stranke, ki jih potrebujejo in bodo temu primerno plačale.

Arhitektura mora služiti poslu, ne obratno. Gradite za stranke, ki jih imate danes, in oblikujte z dovolj prilagodljivosti za služenje strankam, ki jih želite jutri.

---

Potrebujete pomoč pri izbiri prave arhitekture za vaš SaaS izdelek? Zgradili smo večnajemniške in enonajemniške sisteme v različnih panogah. Ugotovimo najboljši pristop za vaš projekt.