Monen vuokralaisen vs. yhden vuokralaisen arkkitehtuuri | Oikean SaaS-arkkitehtuurin valinta

Jokaisen SaaS-tuotteen pitää vastata perustavanlaatuiseen kysymykseen: miten palvelet useita asiakkaita samalla ohjelmistolla? Vastaus on vuokralaismallisi. Se vaikuttaa kustannuksiin, turvallisuuteen, suorituskykyyn ja siihen, kuinka nopeasti voit julkaista. Sen tekeminen oikein aikaisin säästää sinulta tuskallisilta migraatioilta myöhemmin.

Määritelmät

Monen vuokralaisen arkkitehtuuri

Yksi sovellusinstanssi palvelee kaikkia asiakkaita. Kaikki jakavat samat palvelimet, saman koodikannan ja usein saman tietokannan. Jokaisen asiakkaan data on loogisesti eristettynä, mutta infrastruktuuri on jaettua.

Ajattele sitä kerrostalona. Jokainen vuokralainen asuu samassa rakennuksessa, jakaa hissin ja käytävät, mutta heillä on oma lukittu asuntonsa omilla huonekaluillaan.

Yhden vuokralaisen arkkitehtuuri

Jokainen asiakas saa oman dedikoidun sovellusinstanssinsa. Erilliset palvelimet, erilliset tietokannat, joskus erilliset koodikannat. Mitään ei jaeta asiakkaiden välillä.

Ajattele sitä omakotitaloina. Jokaisella vuokralaisella on oma rakennuksensa, oma putkistonsa, oma pihansa. Täydellinen eristys, mutta kalliimpi ylläpitää.

Miten monen vuokralaisen arkkitehtuuri toimii

On kolme yleistä lähestymistapaa monen vuokralaisen arkkitehtuuriin, joilla on erilaiset kompromissit.

Malli 1: Jaettu sovellus, jaettu tietokanta

Kaikki vuokralaiset jakavat yhden sovellusinstanssin ja yhden tietokannan. Vuokralaisten data erotetaan vuokralaistunnisteella (yleensä tenant_id-sarake) jokaisessa taulussa.

Arkkitehtuuri:

• Yksi sovelluspalvelin (tai klusteri) käsittelee kaikki pyynnöt.
• Yksi tietokanta tallentaa kaiken vuokralaisdatan.
• Jokainen kysely sisältää WHERE tenant_id = ? -ehdon datan rajaamiseksi oikealle vuokralaiselle.

Edut:

• Matalimmat infrastruktuurikustannukset. Yksi tietokanta, yksi sovelluksen käyttöönotto.
• Yksinkertaisin ottaa käyttöön ja päivittää. Julkaise kerran, kaikki saavat muutoksen.
• Helppo koostaa dataa vuokralaisten yli analytiikkaa ja raportointia varten.

Haitat:

• Suurin datavuotoriski, jos kysely unohtaa vuokralaissuodattimen.
• Yksi meluisa vuokralainen voi heikentää suorituskykyä kaikille.
• Tietokantamigraatiot vaikuttavat kaikkiin vuokralaisiin samanaikaisesti.
• Vaikeinta noudattaa datan sijaintivaatimuksia.

Tämä on yleisin lähestymistapa B2B SaaS -tuotteille, joilla on suuri määrä pieniä ja keskisuuria asiakkaita.

Malli 2: Jaettu sovellus, erilliset tietokannat

Kaikki vuokralaiset jakavat saman sovellusinstanssin, mutta jokainen vuokralainen saa oman tietokantansa. Sovellus reitittää kyselyt oikeaan tietokantaan todennetun vuokralaisen perusteella.

Arkkitehtuuri:

• Yksi sovelluspalvelin (tai klusteri) käsittelee kaikki pyynnöt.
• Erillinen tietokanta jokaiselle vuokralaiselle.
• Reitityskerros kartoittaa vuokralaisen identiteetin oikeaan tietokantayhteyteen.

Edut:

• Vahvempi datan eristys. Ei riskiä vuokralaisten välisille kyselyille.
• Helpompi täyttää datan sijaintivaatimukset. Voit sijoittaa jokaisen tietokannan vuokralaisen vaatimaan alueeseen.
• Vuokralaiskohtainen varmuuskopiointi ja palautus on suoraviivaista.
• Yhden vuokralaisen raskas käyttö ei lukitse tauluja muilta vuokralaisilta.

Haitat:

• Enemmän infrastruktuuria hallittavana. Satoja vuokralaisia tarkoittaa satoja tietokantoja.
• Skeemamigraatiot pitää ajaa jokaiseen tietokantaan erikseen.
• Vuokralaisten välinen raportointi vaatii useiden tietokantojen kyselyä.
• Korkeampi kustannus kuin täysin jaettu malli.

Tämä on vahva välimaasto tuotteille, jotka tarvitsevat parempaa eristystä ilman täyden yhden vuokralaisen arkkitehtuurin kustannuksia.

Malli 3: Erillinen sovellus, erillinen tietokanta

Jokainen vuokralainen saa oman sovellusinstanssinsa ja oman tietokantansa. Täysin eristettynä. Tämä on käytännössä yhden vuokralaisen arkkitehtuuri, mutta SaaS-palveluntarjoajan hallitsemana.

Arkkitehtuuri:

• Dedikoitu sovelluksen käyttöönotto per vuokralainen.
• Dedikoitu tietokanta per vuokralainen.
• Reitityskerros (usein kuormantasaaja tai API-portti) ohjaa liikenteen oikeaan instanssiin.

Edut:

• Täydellinen eristys. Ei jaettuja resursseja vuokralaisten välillä.
• Maksimaalinen joustavuus vuokralaiskohtaiseen räätälöintiin.
• Yhden vuokralaisen suorituskyky ei koskaan vaikuta toiseen.
• Yksinkertaisin vaatimustenmukaisuustarina.

Haitat:

• Selvästi korkeimmat infrastruktuurikustannukset.
• Käyttöönottomonimutkaisuus kasvaa lineaarisesti vuokralaismäärän mukana.
• Päivitykset pitää levittää jokaiseen instanssiin erikseen (tai automatisoida erittäin huolellisesti).
• Ei skaalaudu taloudellisesti suurelle määrälle pieniä vuokralaisia.

Tämä malli on järkevä yrityspuolen SaaS:lle, jossa asiakkaat vaativat dedikoitua infrastruktuuria ja ovat valmiita maksamaan siitä lisähintaa.

Edut ja haitat yhdellä silmäyksellä

Tekijä	Monen vuokralaisen (jaettu TK)	Monen vuokralaisen (erillinen TK)	Yhden vuokralaisen
Infrastruktuurikustannus	Matalin	Keskitaso	Korkein
Datan eristys	Looginen (rivitaso)	Fyysinen (tietokantataso)	Täydellinen
Käyttöönottomonimutkaisuus	Matala	Keskitaso	Korkea
Päivitysnopeus	Välitön kaikille	Välitön sovellus, TK-kohtaiset migraatiot	Instanssikohtainen levitys
Räätälöinti	Rajallinen	Rajallinen	Täysi
Vaatimustenmukaisuus	Vaikeampi	Kohtalainen	Helpoin
Skaalautuvuus (vuokralaismäärä)	Erinomainen	Hyvä	Heikko
Meluisan naapurin riski	Korkea	Keskitaso	Ei mitään

Datan eristys ja turvallisuus

Datan eristys on tärkein huomio missä tahansa vuokralaismallissa. Tietoturvaloukkaus, jossa yksi vuokralainen pääsee käsiksi toisen vuokralaisen dataan, on katastrofaalinen SaaS-liiketoiminnalle. Se voi tuhota luottamuksen, rikkoa säännöksiä ja lopettaa yrityksen.

Rivitason tietoturva

Jaetussa tietokantamallissa PostgreSQL:n Row-Level Security (RLS) on yksi vahvimmista suojauksista datavuotoa vastaan. RLS pakottaa vuokralaiseristyksen tietokantatasolla, ei sovellustasolla. Vaikka sovelluskoodissasi olisi bugi, joka unohtaa suodattaa vuokralaisen mukaan, tietokanta itse estää vuokralaisten välisen pääsyn.

Näin se pystytetään:

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

Ennen minkään kyselyn suorittamista, aseta vuokralaiskonteksti:

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

Sovellustason eristys

Tietokantatason turvallisuuden lisäksi sovelluksesi pitäisi pakottaa vuokralaisrajat:

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

Syvyyssuuntainen puolustus on periaate tässä. Älä koskaan luota yhteen eristyskerrokseen. Yhdistä sovellustason suodatus, tietokantatason turvallisuus ja säännölliset tietoturva-auditoinnit.

Suorituskykyhuomiot

Jaetun tietokannan haasteet

Jaetussa tietokannassa kaikki vuokralaiset kilpailevat samoista resursseista. Vuokralainen, joka ajaa raskasta raporttia, voi hidastaa kyselyjä kaikille muille. Lieventäviä toimia:

• Yhteyksien yhteiskäyttö. Käytä PgBounceria tai vastaavaa työkalua estämään yhtä vuokralaista kuluttamasta kaikki tietokantayhteydet.
• Kyselyjen aikakatkaisut. Aseta maksimisuoritusajat, jotta karannut kysely ei voi lukita resursseja loputtomiin.
• Pyyntörajoitukset. Pakota vuokralaiskohtaiset rajat API-pyynnöille ja tietokantaoperaatioille.
• Luku-replikat. Reititä raskaat lukuoperaatiot (raportit, viennit) replikaan, jotta ne eivät vaikuta ensisijaiseen tietokantaan.

Erillisten tietokantojen edut

Vuokralaiskohtaisilla tietokannoilla suorituskyvyn eristys on sisäänrakennettu. Yhden vuokralaisen raskas työkuorma vaikuttaa vain heidän omaan tietokantaansa. Voit myös provisioida suurempia tai pienempiä tietokantoja kunkin vuokralaisen suunnitelman ja käytön perusteella.

Kompromissi on hallinnollinen ylikuorma. 500 tietokannan seuranta on vaikeampaa kuin yhden. Automatisoitu työkaluisto muuttuu välttämättömäksi.

Kustannusvaikutukset mittakaavassa

Katsotaan joitain karkeita lukuja. Oletetaan, että sinulla on 100 vuokralaista.

Jaettu tietokanta (monen vuokralaisen):

• 1 sovellusklusteria: ~200 euroa/kuukausi
• 1 hallittu PostgreSQL-instanssi: ~100 euroa/kuukausi
• Yhteensä: ~300 euroa/kuukausi (3 euroa per vuokralainen)

Erilliset tietokannat (monen vuokralaisen):

• 1 sovellusklusteria: ~200 euroa/kuukausi
• 100 pientä tietokantainstanssia: ~2 000 euroa/kuukausi
• Yhteensä: ~2 200 euroa/kuukausi (22 euroa per vuokralainen)

Yhden vuokralaisen:

• 100 sovellusinstanssia: ~5 000 euroa/kuukausi
• 100 tietokantainstanssia: ~2 000 euroa/kuukausi
• Yhteensä: ~7 000 euroa/kuukausi (70 euroa per vuokralainen)

Nämä luvut ovat yksinkertaistettuja, mutta kaava pätee. Jaettu infrastruktuuri on dramaattisesti halvempaa. 1 000 vuokralaisella ero kasvaa entisestään.

Tämän vuoksi hinnoittelun pitää olla linjassa arkkitehtuurin kanssa. Jos veloitat 20 euroa kuukaudessa ja käytät yhden vuokralaisen infrastruktuuria 70 eurolla per vuokralainen, häviät rahaa jokaisesta asiakkaasta.

Milloin valita monen vuokralaisen arkkitehtuuri

Monen vuokralaisen arkkitehtuuri on oikea valinta, kun:

• Rakennat B2B SaaS:ia PK-yrityksille. Suuri volyymi, matalammat hintapisteet ja vakio-ominaisuudet.
• Kustannustehokkuudella on merkitystä. Infrastruktuurikustannusten pitää pysyä matalana suhteessa liikevaihtoon.
• Haluat nopeita, yhdenmukaisia päivityksiä. Julkaise kerran, kaikki vuokralaiset saavat parannuksen.
• Asiakkaasi eivät vaadi dedikoitua infrastruktuuria. Useimmat pienet ja keskisuuret yritykset eivät välitä, missä datansa sijaitsee, kunhan se on turvassa.
• Olet alkuvaiheessa. Aloita monen vuokralaisen arkkitehtuurilla. Se on halvempaa ja yksinkertaisempaa. Voit aina tarjota yhden vuokralaisen ratkaisun myöhemmin yritysasiakkaille.

Milloin valita yhden vuokralaisen arkkitehtuuri

Yhden vuokralaisen arkkitehtuuri on järkevä, kun:

• Myyt suuryrityksille. Suuret organisaatiot vaativat usein dedikoitua infrastruktuuria osana hankintaprosessiaan.
• Vaatimustenmukaisuus vaatii sitä. Alat kuten terveydenhuolto (HIPAA), rahoitus (SOX, PCI-DSS) ja julkishallinto omaavat tiukat datan eristysvaatimukset.
• Asiakkaat tarvitsevat räätälöintiä. Jos jokainen asiakas vaatii erilaisia konfiguraatioita, integraatioita tai jopa ominaisuuksia, yhden vuokralaisen arkkitehtuuri antaa joustavuuden.
• Hintapisteesi tukee sitä. Jos veloitat 5 000 euroa tai enemmän kuukaudessa per asiakas, infrastruktuurikustannus on helposti perusteltavissa.
• Datan sijainti on ehdoton vaatimus. Kun datan pitää sijaita tietyssä maassa, erillinen infrastruktuuri per vuokralainen on suoraviivaisin lähestymistapa.

Hybridilähestymistavat

Sinun ei tarvitse valita vain yhtä. Monet menestyvät SaaS-yritykset käyttävät hybridimallia:

• Monen vuokralaisen arkkitehtuuri vakiotasoille. Ilmaiset, starter- ja pro-asiakkaat jakavat infrastruktuurin. Tämä pitää kustannukset matalina ja mahdollistaa skaalauksen.
• Yhden vuokralaisen arkkitehtuuri yritysasiakkaille. Premium-asiakkaat saavat dedikoidut instanssit räätälöidyillä SLA:lla, vaatimustenmukaisuussertifikaateilla ja oma tukea.

Sovelluskoodi on sama. Käyttöönottomalli eroaa. Tämä vaatii hyvää infrastruktuuri-automaatiota, mutta se on todistettu malli.

Hybridimallin toteuttaminen

1. Rakenna sovellus monen vuokralaisen arkkitehtuurilla ensin. Kaikki vuokralaiseristyslogiikka pysyy samana riippumatta käyttöönottomallista.
2. Käytä infrastruktuuria koodina (Terraform, Pulumi tai CDK) ympäristöjen luonnin automatisointiin.
3. Luo provisiointiputki, joka voi pystyttää uuden dedikoidun ympäristön minuuteissa, ei päivissä.
4. Ylläpidä yhtä koodikantaa. Sama Docker-image pyörii sekä jaetuissa että dedikoiduissa ympäristöissä. Konfiguraatio (ei koodi) määrittää käyttäytymisen.

Tietokantastrategiat yksityiskohtaisesti

Tietokanta on paikka, jossa vuokralaispäätöksillä on eniten vaikutusta. Tässä kolme todistettua strategiaa.

Strategia 1: Jaetut taulut tenant_id:llä

Jokaisessa taulussa on tenant_id-sarake. Kaikki kyselyt suodattavat sillä.

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;

Parasta: useimmille SaaS-tuotteille. Yksinkertainen, kustannustehokas, hyvin ymmärretty.

Strategia 2: Skeema per vuokralainen

Jokainen vuokralainen saa oman PostgreSQL-skeemansa jaetussa tietokannassa. Tauluilla on sama rakenne, mutta data on fyysisesti erotettua.

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

Parasta: tuotteille, jotka tarvitsevat vahvempaa eristystä kuin rivitaso mutta eivät halua erillisten tietokantojen kustannuksia. Toimii hyvin muutamaan sataan vuokralaiseen asti.

Strategia 3: Erilliset tietokannat

Jokainen vuokralainen saa dedikoidun PostgreSQL-instanssin (tai dedikoidun tietokannan jaetulla palvelimella).

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

Parasta: yrityspuolen SaaS:lle korkean arvon asiakkailla, tiukoilla vaatimustenmukaisuusvaatimuksilla tai datan sijaintivelvotteilla.

Päätöksen tekeminen

Tässä yksinkertainen päätösviitekehys:

1. Mikä on kohdeasiakkaasi koko? PK-yritykset viittaavat monen vuokralaisen arkkitehtuuriin. Suuryritykset viittaavat yhden vuokralaisen arkkitehtuuriin tai hybridiin.
2. Mikä on hintapisteesi? Alle 100 euroa/kuukausi, tarvitset monen vuokralaisen arkkitehtuuria ollaksesi kannattava. Yli 1 000 euroa/kuukausi, yhden vuokralaisen arkkitehtuuri tulee mahdolliseksi.
3. Mitkä ovat vaatimustenmukaisuusvaatimukset? Säännellyt alat vaativat usein vahvempaa eristystä.
4. Kuinka monta vuokralaista odotat? Satoja tai tuhansia vuokralaisia tarvitsevat jaettua infrastruktuuria. 10-50 suurta vuokralaista voi toimia dedikoiduilla instansseilla.
5. Mikä on tiimisi operatiivinen kapasiteetti? Yhden vuokralaisen arkkitehtuuri vaatii enemmän DevOps-investointia. Monen vuokralaisen arkkitehtuuri on operatiivisesti yksinkertaisempi.

Jos olet epävarma, aloita monen vuokralaisen arkkitehtuurilla jaetulla tietokannalla ja rivitason tietoturvalla. Se on matalakustannuksinen vaihtoehto, se on turvallinen oikein toteutettuna ja se pitää arkkitehtuurisi yksinkertaisena. Voit aina lisätä dedikoidun tason yritysasiakkaille myöhemmin.

Lopputulos

Universaalisti oikeaa vuokralaismallia ei ole olemassa. Oikea valinta riippuu asiakkaistasi, hinnoittelustasi, vaatimustenmukaisuusvaatimuksistasi ja operatiivisista kyvykkyyksistäsi.

Useimpien SaaS-tuotteiden pitäisi aloittaa monen vuokralaisen arkkitehtuurilla. Se on halvempaa, yksinkertaisempaa ja skaalautuu hyvin. Kun siirryt ylemmäs markkinoilla ja alat myydä suuremmille organisaatioille, lisää yhden vuokralaisen vaihtoehtoja asiakkaille, jotka tarvitsevat niitä ja maksavat vastaavasti.

Arkkitehtuurin pitäisi palvella liiketoimintaa, ei toisinpäin. Rakenna nykyisille asiakkaillesi ja suunnittele tarpeeksi joustavasti palvellaksesi asiakkaita, joita haluat huomenna.

---

Tarvitsetko apua oikean arkkitehtuurin valitsemisessa SaaS-tuotteellesi? Olemme rakentaneet monen vuokralaisen ja yhden vuokralaisen järjestelmiä eri aloille. Selvitetään paras lähestymistapa projektillesi.