Infrastruktura

Wielodostępność

AktywnyOpublikowano: 1 października 2026Aktualizacja: 1 października 2026Opublikowany

Architektura, w której pojedyncza instancja oprogramowania i współdzielona infrastruktura obsługują wielu najemców (tenantów), zapewniając izolację ich danych i konfiguracji.

Kluczowa innowacja

Umożliwienie jednej instancji oprogramowania i współdzielonej infrastruktury bezpiecznej obsługi wielu niezależnych najemców (tenantów) z logiczną izolacją danych i konfiguracji, zamiast uruchamiania osobnej instancji dla każdego klienta.

Kategoria

Infrastruktura

Poziom abstrakcji

Wzorzec

Poziom operacji

SystemWdrożenieUdostępnianie

Zastosowania

Platformy SaaS B2B i B2CWspółdzielone platformy AI/ML dla wielu klientów i zespołówWieloklientowe platformy agentowe z izolacją danych i politykWspółdzielone klastry (np. Kubernetes) obsługujące wiele jednostek organizacjiHostowane API inferencyjne z izolacją kluczy i limitów per klient

Jak działa

Każde żądanie jest powiązane z tenantem poprzez identyfikator (tenant ID / kontekst najemcy), zwykle wyznaczany na podstawie uwierzytelnienia, subdomeny lub nagłówka. Warstwa izolacji wymusza, by operacje i zapytania działały wyłącznie w obrębie danych tego tenanta. Dane partycjonuje się według jednego z trzech modeli: osobne bazy danych na tenanta (najsilniejsza izolacja, najwyższy koszt), współdzielona baza z osobnymi schematami, albo współdzielona baza i współdzielony schemat z kolumną dyskryminującą tenanta (najwyższa gęstość, najniższy koszt, najmocniejsza zależność od zabezpieczeń w warstwie aplikacji). Na poziomie wdrożenia stosuje się modele silo (zasoby dedykowane tenantowi), pool (zasoby współdzielone i skalowalne) oraz bridge (hybryda łącząca oba). Nadrzędna warstwa sterowania (control plane) zarządza onboardingiem, tożsamością, konfiguracją i cyklem życia tenantów, a mechanizmy zarządzania zasobami — limity, kwoty i throttling — chronią przed sytuacją, w której jeden najemca degraduje wydajność pozostałych.

Rozwiązany problem

Uruchamianie osobnej, dedykowanej instancji aplikacji dla każdego klienta jest kosztowne i trudne w utrzymaniu: rośnie liczba środowisk do aktualizacji, monitorowania i skalowania, a zasoby pozostają słabo wykorzystane. Multi-tenancy rozwiązuje ten problem, pozwalając jednej instancji obsłużyć wielu najemców na współdzielonej infrastrukturze — przy zachowaniu izolacji danych i konfiguracji każdego z nich.

Komponenty

Kontekst najemcy (tenant ID)Identyfikacja i propagacja przynależności do tenanta

Identyfikator powiązujący każde żądanie, rekord i operację z konkretnym tenantem. Propagowany przez cały stos — od uwierzytelnienia po warstwę danych.

Warstwa izolacji tenantówEgzekwowanie granic bezpieczeństwa między tenantami

Mechanizmy gwarantujące, że dane i działania jednego najemcy nie są dostępne dla innych — od filtrowania zapytań i polityk dostępu po separację sieciową i środowisk wykonawczych.

Partycjonowanie danychLogiczne lub fizyczne rozdzielenie danych najemców

Strategia rozdzielenia danych tenantów: osobne bazy, współdzielona baza z osobnymi schematami, albo wspólny schemat z kolumną dyskryminującą tenanta.

Osobne bazy danych na tenantaNajsilniejsza izolacja, najwyższy koszt na tenanta.

Współdzielona baza, osobne schematyUmiarkowana izolacja i gęstość.

Współdzielony schemat z kolumną tenantaNajwyższa gęstość i najniższy koszt; wymaga silnych zabezpieczeń w warstwie aplikacji.

Oficjalna

Warstwa sterowania i zarządzania tenantamiCentralne zarządzanie najemcami

Wspólny komponent odpowiedzialny za onboarding, tożsamość, konfigurację, rozliczenia i cykl życia tenantów — nawet gdy ich zasoby są dedykowane (silo).

Zarządzanie zasobami (kwoty i throttling)Ochrona współdzielonych zasobów przed nierównowagą

Limity, kwoty i ograniczanie przepustowości zapobiegające sytuacji, w której jeden tenant zużywa nieproporcjonalną część współdzielonych zasobów.

Oficjalna

Implementacja

Pułapki implementacyjne

Problem hałaśliwego sąsiada (noisy neighbor)Wysoka

Pojedynczy tenant generujący nieproporcjonalne obciążenie może degradować wydajność pozostałych najemców współdzielących zasoby.

Rozwiązanie:Wprowadzenie limitów przepustowości, kwot zasobów oraz izolacja najemców o wysokim zużyciu (np. przeniesienie do modelu silo).

Wyciek danych między tenantamiKrytyczna

Przy współdzielonym schemacie brak filtrowania po identyfikatorze tenanta w choćby jednym zapytaniu może ujawnić dane innego najemcy.

Rozwiązanie:Egzekwowanie filtrowania po tenancie w warstwie danych (np. row-level security), audyty i testy izolacji.

Utrata kontekstu tenantaWysoka

Jeśli kontekst tenanta nie jest konsekwentnie propagowany przez cały stos (kolejki, zadania w tle, wywołania usług), operacje mogą trafić do danych niewłaściwego najemcy.

Rozwiązanie:Jawne przenoszenie identyfikatora tenanta w każdej warstwie i operacji asynchronicznej.

Ewolucja

1999

Salesforce popularyzuje wieloklientowy model SaaS

Punkt przełomowy

Komercyjny sukces oprogramowania dostarczanego jako usługa na współdzielonej, wieloklientowej infrastrukturze ustanowił multi-tenancy jako dominujący wzorzec SaaS.

2006

Publiczna chmura upowszechnia ekonomię modelu pool

Pojawienie się publicznej chmury (m.in. Amazon EC2) sprawiło, że współdzielona, skalowalna infrastruktura stała się standardem, wzmacniając korzyści skali z wielodostępności.