Bir SaaS ürününde aynı yazılımı birden fazla müşteriye sunmak kolay görünür: her müşteri hesap açar, kullanıcılarını ekler ve sistemi kullanmaya başlar. Asıl mimari problem ise müşterilerin verilerini, yetkilerini, yapılandırmalarını ve kaynak tüketimini birbirinden güvenli biçimde ayırmaktır. Multi-tenant yazılım mimarisi, bu ayrımı her müşteri için ayrı bir ürün kopyası oluşturmadan yönetmeyi amaçlar.
Doğru model seçilmediğinde bir müşterinin verisinin başka bir müşteriye görünmesi, yoğun kullanımın tüm sistemi yavaşlatması veya her yeni müşteri için manuel kurulum yapılması gibi ciddi sorunlar ortaya çıkabilir. Bu rehber; SaaS geliştiren girişimciler, teknik yöneticiler ve yazılım geliştirme yatırımı planlayan işletmeler için multi-tenant mimarinin temel kararlarını somut örneklerle açıklar.
Multi-tenant yazılım mimarisi nedir?
Multi-tenant, Türkçede “çok kiracılı” olarak ifade edilen ve tek bir yazılım sisteminin birden fazla bağımsız müşteri grubuna hizmet verdiği mimari yaklaşımdır. Buradaki her müşteri grubu bir tenant olarak tanımlanır. B2B bir SaaS ürününde tenant çoğunlukla müşteri şirketi, kullanıcılar ise o şirkette sisteme erişen çalışanlardır.
Örneğin teknik servis firmalarına sunulan bir iş yönetimi SaaS’ında her servis firması ayrı tenant olabilir. Her tenant kendi müşterilerini, iş emirlerini, personelini ve raporlarını görür. Uygulamanın kod tabanı ortak olsa bile bir firmanın verisi diğer firmadan mantıksal veya fiziksel olarak ayrılır.
Multi-user ile multi-tenant aynı şey değildir: Bir uygulamada çok sayıda kullanıcı bulunması onu otomatik olarak multi-tenant yapmaz. Multi-tenant yapıda kullanıcıların hangi müşteri alanına bağlı olduğu, kaynakların nasıl paylaşıldığı ve tenant sınırlarının nasıl korunduğu açık biçimde modellenir.
AWS SaaS Lens, tenant izolasyonunu her SaaS sağlayıcısının ele alması gereken temel konulardan biri olarak tanımlar. Paylaşılan altyapı maliyet ve operasyon avantajı sağlasa da her tenant’ın diğer tenant’ların kaynaklarına erişmesini önleyecek sınırların kurulması gerekir AWS SaaS Lens.
Multi-tenant mimaride üç temel izolasyon modeli
Multi-tenant tasarım “her şey ortak” veya “her şey ayrı” şeklinde iki seçeneğe indirgenmemelidir. Uygulama, veritabanı, dosya depolama, önbellek ve mesaj kuyrukları farklı seviyelerde paylaşılabilir. Bu nedenle model seçimi, tek bir teknoloji kararından çok bir izolasyon spektrumudur.
| Model | Temel yapı | Avantajı | Başlıca riski | Uygun olduğu durum |
|---|---|---|---|---|
| Silo | Her tenant için ayrı uygulama veya altyapı ve çoğunlukla ayrı veritabanı | Yüksek izolasyon ve müşteriye özel kaynak kontrolü | Maliyet ve operasyon yükünün tenant sayısıyla artması | Az sayıda, yüksek sözleşme değerli veya güçlü izolasyon isteyen kurumsal müşteriler |
| Pool | Uygulama ve veri kaynakları tenant’lar arasında paylaşılır | Daha verimli kaynak kullanımı ve merkezi güncelleme | Tenant bağlamındaki bir hata geniş çaplı veri sızıntısına dönüşebilir | Çok sayıda müşteriye standart ürün sunan SaaS sistemleri |
| Bridge / hibrit | Bazı katmanlar ortak, bazı kaynaklar tenant’a özel tutulur | Maliyet ile izolasyon arasında esneklik | Birden fazla dağıtım modelini yönetme karmaşıklığı | Standart paket yanında özel izolasyon paketi sunan ürünler |
Microsoft’un çok kiracılı mimari rehberi de model seçiminin yalnızca teknik olmadığını; maliyet, uyumluluk gereksinimleri, müşteri deneyimi, otomasyon kapasitesi ve hedeflenen ölçekle birlikte değerlendirilmesi gerektiğini belirtir Microsoft Azure Architecture Center. Bu nedenle başlangıçta yalnızca “en ucuz” modeli seçmek, ileride büyük müşteriler için pahalı bir mimari dönüşüm gerektirebilir.
Veri katmanında tenant izolasyonu nasıl kurulmalıdır?
Multi-tenant sistemlerin en kritik kararı verinin nerede ve hangi sınırlarla tutulacağıdır. Kullanıcı arayüzünde farklı şirket adlarının gösterilmesi izolasyon sağlamaz. Veritabanı sorguları, dosya yolları, önbellek anahtarları, arama indeksleri ve arka plan görevleri tenant bağlamını taşımak zorundadır.
Ortak veritabanı ve ortak tablolar
Pool modelinde tenant’ların kayıtları aynı tablolarda tutulabilir ve her tenant’a ait satırda bir tenant kimliği bulunur. Bu yaklaşım yeni müşteri açılışını kolaylaştırır, altyapı maliyetini düşürür ve şema güncellemelerinin tek merkezden yürütülmesini sağlar. Buna karşılık tenant filtresinin unutulduğu tek bir sorgu bile yanlış müşterinin verisini döndürebilir.
Bu modelde yalnızca geliştiricilerin her sorguya filtre eklemesine güvenmek yeterli değildir. Uygulama katmanındaki kapsamlandırmaya ek olarak veritabanı politikaları, otomatik testler ve yetki sınırları kullanılmalıdır. PostgreSQL’in Row-Level Security özelliği, belirlenen politikalara göre hangi satırların okunabileceğini veya değiştirilebileceğini veritabanı seviyesinde sınırlayabilir PostgreSQL Documentation. Ancak RLS de yanlış rol kullanımı, politika eksikliği veya ayrıcalıklı bağlantılar nedeniyle tek başına kusursuz bir güvenlik katmanı sayılmamalıdır.
Tenant başına şema veya veritabanı
Her tenant için ayrı şema kullanmak, ortak tablo modeline göre daha belirgin bir mantıksal sınır oluşturur. Tenant başına ayrı veritabanı ise yedekleme, geri yükleme, veri taşıma ve kaynak sınırlandırma işlemlerini müşteri bazında kolaylaştırabilir. Buna karşılık yüzlerce veritabanının sürümünü, bağlantısını ve migrasyonunu yönetmek güçlü otomasyon gerektirir.
Karar verirken yalnızca bugünkü müşteri sayısı değil; beklenen tenant sayısı, veri hacmi, sözleşmesel izolasyon şartları, müşteri bazında geri yükleme ihtiyacı ve operasyon ekibinin kapasitesi değerlendirilmelidir. Yüksek güvenlik beklentili müşteriler için ayrı veritabanı, daha küçük müşteriler için ortak veri katmanı kullanılan hibrit model de uygulanabilir.
Tenant bağlamı isteğin başında belirlenmelidir
Tenant kimliğinin bir form alanından, sorgu parametresinden veya değiştirilebilir HTTP başlığından doğrudan alınması güvenli değildir. Kullanıcı başka bir tenant kimliği göndererek yetkili olmadığı kaynağa ulaşmaya çalışabilir. Tenant bağlamı, doğrulanmış kullanıcı oturumu ve kullanıcının tenant üyeliği üzerinden üretilmelidir.
OWASP’ın Multi-Tenant Security rehberi; tenant bağlamının istek yaşam döngüsünün erken aşamasında kurulmasını, istemciden gelen tenant kimliğine doğrulama olmadan güvenilmemesini ve bu bağlamın tüm uygulama katmanlarına güvenli biçimde taşınmasını önerir OWASP Cheat Sheet Series.
- Kullanıcıyı doğrulayın: Oturumun veya erişim belirtecinin geçerli olduğunu kontrol edin.
- Tenant üyeliğini çözümleyin: Kullanıcının hangi müşteri alanlarına ve hangi rollerle erişebildiğini sunucu tarafında belirleyin.
- Tenant bağlamını oluşturun: Doğrulanmış tenant kimliğini isteğin uygulama içi bağlamına ekleyin.
- Her veri erişimini kapsamlandırın: Okuma, ekleme, güncelleme ve silme işlemlerinde tenant sınırını zorunlu tutun.
- Bağlamı asenkron süreçlere taşıyın: Kuyruk mesajları, zamanlanmış görevler, dosya işlemleri ve bildirimlerde tenant kimliğini doğrulanabilir biçimde koruyun.
- İşlem kaydını tenant bazında tutun: Hangi kullanıcının hangi tenant adına hangi işlemi yaptığını denetlenebilir hale getirin.
Bu yaklaşım özellikle API entegrasyonlarında önemlidir. Dış sistemden gelen bir sipariş, ödeme veya müşteri kaydı yalnızca kullanıcıya değil, doğru tenant’a da bağlanmalıdır. Entegrasyon anahtarı geçerli olsa bile tenant eşlemesi ayrıca doğrulanmalıdır.
“Noisy neighbor” etkisi nasıl önlenir?
Kaynakları paylaşan bir SaaS sisteminde bir tenant’ın yoğun kullanımı diğer tenant’ların performansını etkileyebilir. Çok büyük bir rapor, kontrolsüz dışa aktarma işlemi, yüksek hacimli API çağrısı veya toplu dosya yükleme aynı işlemciyi, veritabanını ya da kuyruğu tüketebilir. Bu durum “noisy neighbor”, yani gürültülü komşu etkisi olarak adlandırılır.
Bu riski azaltmak için tenant bazında kaynak politikaları tanımlanmalıdır:
- API çağrıları için tenant ve paket bazlı hız sınırları uygulayın.
- Ağır raporları doğrudan web isteğinde çalıştırmak yerine kuyruğa alın.
- Tenant başına depolama, dosya boyutu ve eş zamanlı işlem sınırı belirleyin.
- Veritabanı sorgularını tenant bazında izleyerek aşırı tüketimi görünür hale getirin.
- Büyük kurumsal müşterileri gerektiğinde ayrı işçi, veritabanı veya dağıtıma taşıyabilecek bir yol bırakın.
- Ürün paketlerini yalnızca özellik sayısına göre değil, kaynak kullanım sınırlarına göre de tasarlayın.
Amaç her müşteriye aynı teknik kaynağı vermek değil, bir tenant’ın davranışının diğerlerinin hizmet kalitesini bozmasını önlemektir. Ölçekleme yaklaşımı ayrı bir konu olsa da tenant bazlı ölçüm yapılmadan sağlıklı kapasite planı kurulamaz.
Müşteriye özel ayarlar kod çatallanmasına dönüşmemeli
SaaS müşterileri logo, renk, alan adı, bildirim metni, iş akışı, kullanıcı rolleri veya rapor alanlarında farklı taleplerde bulunabilir. Her müşteri için ayrı kod dalı oluşturmak ilk aşamada hızlı görünür; fakat güvenlik yamalarının, yeni özelliklerin ve hata düzeltmelerinin çok sayıda sürüme uygulanmasına yol açar.
Daha sürdürülebilir yaklaşım; ortak kod tabanı üzerinde tenant yapılandırması, özellik bayrakları ve paket yetkileri kullanmaktır. Örneğin bir tenant’ta onay akışı iki aşamalı, diğerinde tek aşamalı olabilir. Bu fark kodun iki ayrı kopyasıyla değil, doğrulanmış yapılandırma verisiyle yönetilmelidir.
Tenant yöneticisinin değiştirebileceği ayarlar ile yalnızca sistem yöneticisinin yönetebileceği alanlar ayrılmalıdır. Bu ayrım, yönetim paneli geliştirme sürecinde ekran tasarımından önce yetki modeli olarak planlanmalıdır. Özellik bayrakları da yalnızca arayüzde buton gizlemek için değil, sunucu tarafındaki erişim kontrolüyle birlikte uygulanmalıdır.
Onboarding, taşıma ve silme süreçleri otomatik olmalıdır
Multi-tenant mimari yalnızca çalışan uygulama ekranlarından ibaret değildir. Yeni tenant açılması, varsayılan rollerin oluşturulması, depolama alanlarının hazırlanması, alan adı doğrulaması, paket haklarının tanımlanması ve ilk yöneticinin davet edilmesi tekrarlanabilir bir süreç olmalıdır.
Benzer şekilde tenant kapatma süreci de açık kurallara ihtiyaç duyar. Aktif oturumların sonlandırılması, entegrasyon anahtarlarının iptali, verinin dışa aktarılması, saklama süresi ve nihai silme işlemleri birlikte tasarlanmalıdır. Özellikle müşteri verisinin nerelerde çoğaltıldığı bilinmiyorsa ana veritabanından silinen kayıt; yedeklerde, arama indeksinde, dosya depolamada veya analiz sisteminde kalabilir.
Pratik karar: Yeni bir tenant açmak için geliştiricinin veritabanına manuel müdahale etmesi gerekiyorsa onboarding henüz ürünleşmemiştir. Kurulum adımları idempotent, kayıt altına alınan ve hata halinde tekrar çalıştırılabilen bir akışa dönüştürülmelidir.
Loglama ve gözlemlenebilirlik tenant seviyesinde kurulmalıdır
Toplam CPU kullanımı veya genel hata oranı, hangi müşterinin sorun yaşadığını açıklamaz. Uygulama loglarında, izlerde ve iş metriklerinde tenant kimliği bulunmalıdır. Böylece yalnızca “sistem yavaş” denmez; belirli bir tenant’ın rapor görevlerinin kuyruğu doldurduğu veya belirli bir entegrasyonun hatalı istek ürettiği görülebilir.
Tenant kimliği loglara eklenirken kişisel veri veya gizli içerik gereksiz yere kaydedilmemelidir. Destek ekibinin tenant verisine erişimi de rol, amaç ve işlem geçmişiyle sınırlandırılmalıdır. Özel geliştirilmiş bir web yazılımı için yalnızca uygulama yöneticisi ekranı değil, destek ve denetim akışı da mimarinin parçasıdır.
İzlenmesi faydalı tenant bazlı göstergeler şunlardır:
- Aktif kullanıcı ve oturum sayısı
- API istek hacmi ve hata oranı
- Arka plan görevi süresi ve kuyruk bekleme zamanı
- Depolama ve veritabanı büyümesi
- Paket limitine yaklaşan kullanım değerleri
- Yetkisiz erişim ve tenant sınırı ihlali denemeleri
Gerçekçi bir multi-tenant SaaS senaryosu
Örnek olarak saha servis firmalarına iş emri yönetimi sunan bir SaaS ürünü düşünelim. Her servis firması tenant, firma çalışanları ise tenant içindeki kullanıcılardır. Uygulama katmanı ortak, veritabanındaki müşteri, cihaz ve iş emri tabloları tenant kimliğiyle ayrılmış olabilir.
Kullanıcı giriş yaptığında sunucu, kullanıcının firma üyeliğini doğrular ve tenant bağlamını oluşturur. Bir iş emri sorgusu hem kullanıcı rolünü hem de tenant sınırını kontrol eder. Firmaya ait yüklenen belgeler tenant’a özel dosya yolu ve erişim politikasıyla saklanır. Rapor oluşturma görevi kuyruğa gönderildiğinde tenant kimliği mesaja eklenir ve işçi süreç bu bağlamı yeniden doğrular.
Daha yüksek izolasyon isteyen kurumsal bir müşteri geldiğinde aynı ürünün uygulama katmanı ortak kalırken müşteri ayrı veritabanına taşınabilir. Bu geçişin mümkün olması için tenant ile veri konumu arasındaki eşlemenin baştan soyutlanmış olması gerekir. Böylece ürün, standart müşteriler için maliyet verimli pool modelini; özel gereksinimli müşteriler için hibrit modeli destekleyebilir.
Multi-tenant mimari kontrol listesi
- Tenant’ın müşteri, şirket, şube, ekip veya birey olarak neyi temsil ettiği açık mı?
- Kullanıcının birden fazla tenant’a üyeliği desteklenmesi gerekiyorsa geçiş akışı tanımlı mı?
- Tenant bağlamı doğrulanmış oturumdan mı üretiliyor?
- Veritabanı, önbellek, dosya depolama, arama ve kuyruk katmanlarında aynı izolasyon kuralı uygulanıyor mu?
- Tenant sınırını aşan okuma ve yazma girişimleri otomatik testlerle kontrol ediliyor mu?
- Kaynak tüketimi tenant bazında ölçülüyor ve sınırlandırılıyor mu?
- Müşteri ayarları ortak kod tabanını bozmadan yönetilebiliyor mu?
- Tenant açma, taşıma, dışa aktarma ve kapatma süreçleri otomatik mi?
- Yedekleme ve geri yükleme planı tenant bazlı kurtarma ihtiyacını karşılıyor mu?
- Kurumsal müşteriler için daha yüksek izolasyona geçiş yolu bulunuyor mu?
Sonuç: Multi-tenant mimari veri tabanına tenant_id eklemekten fazlasıdır
Multi-tenant SaaS tasarımının merkezinde ortak altyapı değil, doğrulanmış tenant sınırı bulunur. Veritabanına tenant kimliği eklemek gerekli olabilir; ancak kimlik doğrulama, yetkilendirme, dosya depolama, önbellek, kuyruk, loglama ve kaynak yönetimi aynı sınırı uygulamıyorsa sistem güvenli biçimde çok kiracılı sayılmaz.
En doğru model; müşteri sayısı, izolasyon beklentisi, bütçe, operasyon kapasitesi ve büyüme planı birlikte değerlendirilerek seçilir. Pool, silo ve hibrit modellerin hiçbiri her proje için mutlak doğru değildir. Sağlam mimari, bugün verimli çalışırken yarın belirli tenant’ları daha izole bir yapıya taşıyabilecek esnekliği korur.
Sıkça Sorulan Sorular
Multi-tenant ve single-tenant mimari arasındaki temel fark nedir?
Single-tenant mimaride bir müşteriye ait uygulama veya altyapı kaynakları çoğunlukla diğer müşterilerden ayrı dağıtılır. Multi-tenant mimaride ise kod tabanı ve bazı altyapı bileşenleri birden fazla tenant tarafından paylaşılabilir. Temel fark yalnızca sunucu sayısı değildir; izolasyonun fiziksel kaynaklarla mı, uygulama ve veri politikalarıyla mı sağlandığıdır. Single-tenant daha güçlü özelleştirme ve izolasyon sağlayabilir, ancak maliyet ve operasyon yükü artar. Multi-tenant yapı daha verimli ölçeklenebilir, fakat tenant bağlamının her katmanda doğru uygulanmasını gerektirir.
Ortak veritabanı kullanan multi-tenant bir sistem güvenli olabilir mi?
Evet, ortak veritabanı modeli doğru güvenlik katmanlarıyla güvenli biçimde uygulanabilir; ancak yalnızca tablolara tenant_id alanı eklemek yeterli değildir. Tenant bağlamı doğrulanmış kullanıcı oturumundan üretilmeli, tüm sorgular bu bağlamla sınırlandırılmalı ve tenant dışı erişimler otomatik testlerle kontrol edilmelidir. Veritabanı seviyesinde Row-Level Security gibi ek politikalar kullanılabilir. Önbellek, dosya depolama, arama indeksleri ve arka plan görevleri de aynı izolasyon kuralına uymalıdır. Ayrıcalıklı yönetici bağlantılarının bu kontrolleri aşabileceği ayrıca hesaba katılmalıdır.
Her tenant için ayrı veritabanı ne zaman tercih edilmelidir?
Ayrı veritabanı; müşterinin sözleşmesel veya düzenleyici izolasyon talebi bulunduğunda, tenant bazında yedekleme ve geri yükleme gerektiğinde ya da büyük müşterilerin kaynak tüketimi diğerlerini etkileyebilecek düzeye ulaştığında anlamlıdır. Az sayıda ve yüksek değerli kurumsal müşteriye hizmet veren ürünlerde de operasyon maliyeti kabul edilebilir olabilir. Buna karşılık çok sayıda küçük müşteri için her tenant’a ayrı veritabanı açmak migrasyon, bağlantı yönetimi ve izleme yükünü büyütür. Bu nedenle bazı müşterilerin ortak, bazılarının ayrı veritabanında tutulduğu hibrit model sık kullanılan bir seçenektir.
Tenant kimliği URL veya istek başlığından alınabilir mi?
URL alt alan adı veya istek başlığı tenant’ın bulunmasına yardımcı olabilir, fakat bu değer tek başına yetkilendirme kanıtı sayılmamalıdır. İstemci tarafından gönderilebilen tenant kimliği değiştirilebilir. Sunucu, önce kullanıcının kimliğini doğrulamalı; ardından kullanıcının ilgili tenant’a üyeliğini ve rolünü kendi güvenilir kayıtlarından kontrol etmelidir. Doğrulanan tenant bağlamı daha sonra veritabanı, dosya, önbellek ve kuyruk işlemlerine taşınmalıdır. Kullanıcının birden fazla tenant’a üyeliği varsa tenant değiştirme işlemi de sunucu tarafında yeniden yetkilendirilmelidir.
Multi-tenant SaaS ürününde müşteriye özel geliştirmeler nasıl yönetilir?
Müşteriye özel ihtiyaçlar mümkün olduğunca ortak kod tabanı üzerinde yapılandırma, özellik bayrağı, paket yetkisi ve genişletilebilir iş akışı mekanizmalarıyla yönetilmelidir. Her müşteri için ayrı kod dalı oluşturmak, güncellemelerin ve güvenlik düzeltmelerinin farklı sürümlere tek tek taşınmasına neden olur. Ancak özelleştirmenin sınırı da belirlenmelidir; ürünün temel veri modeli ve güvenlik kuralları müşteri ayarlarıyla devre dışı bırakılamamalıdır. Çok özel gereksinimi olan müşteriler için aynı kod tabanını kullanan, fakat ayrı altyapıda çalışan bir dağıtım seçeneği sunulabilir.
Mevcut single-tenant yazılım multi-tenant yapıya dönüştürülebilir mi?
Dönüştürülebilir, ancak işlem çoğunlukla yalnızca veritabanına tenant alanı eklemekten daha kapsamlıdır. Önce kullanıcı, müşteri ve tenant ilişkileri yeniden modellenir. Ardından tüm veri erişimleri, dosya yolları, önbellek anahtarları, görev kuyrukları, raporlar ve entegrasyonlar tenant bağlamına göre incelenir. Mevcut müşteri verilerinin doğru tenant’lara taşınması için doğrulanabilir migrasyon planı gerekir. En güvenli yaklaşım, tenant sınırı testlerini hazırlamak ve sistemi kademeli olarak dönüştürmektir. Bazı eski yapılar için hibrit geçiş, tek seferde tam dönüşümden daha düşük riskli olabilir.
