SaaS'ta Çok Kiracılı Mimari: Üç Yaklaşım ve Seçim Ölçütleri

SaaS ürünlerinde tek bir uygulama çok sayıda müşteriye hizmet verir. Her müşteri bir “kiracı” (tenant) olarak adlandırılır ve kendi verisini yalnızca kendisi görmelidir. Kiracıların verisinin nasıl ayrılacağı, ürünün maliyetini, güvenliğini ve işletim yükünü yıllarca etkileyen bir mimari karardır.

Üç temel yaklaşım

1. Ortak veritabanı, ortak şema

Tüm kiracıların verisi aynı tablolarda durur; her satır hangi kiracıya ait olduğunu gösteren bir alan taşır. Her sorgu bu alana göre süzülür. Kurulumu ve işletimi en basit, kaynak kullanımı en verimli yaklaşımdır.

Riski, süzmenin unutulduğu tek bir sorgunun başka bir kiracının verisini gösterebilmesidir. Bu risk, süzmeyi uygulama koduna bırakmak yerine veritabanı düzeyinde zorunlu kılarak azaltılır; örneğin PostgreSQL'in satır düzeyinde güvenlik özelliği bu amaçla kullanılır.

2. Ortak veritabanı, kiracı başına ayrı şema

Kiracılar aynı veritabanı sunucusunu paylaşır, ancak her birinin tabloları ayrı bir şemada durur. Yalıtım daha güçlüdür ve tek bir kiracının verisini yedekten döndürmek kolaylaşır. Buna karşılık kiracı sayısı arttıkça şema değişikliklerini tüm şemalara uygulamak zorlaşır.

3. Kiracı başına ayrı veritabanı

Her kiracının kendi veritabanı vardır. Yalıtım en üst düzeydedir; bir kiracının yoğun kullanımı diğerlerini etkilemez ve verinin belirli bir bölgede tutulması gibi talepler karşılanabilir. Bedeli, daha yüksek altyapı maliyeti ve çok sayıda veritabanını yönetmenin getirdiği işletim yüküdür.

Karşılaştırma

Ölçüt	Ortak şema	Ayrı şema	Ayrı veritabanı
Veri yalıtımı	Mantıksal	Daha güçlü	En güçlü
Kiracı başına maliyet	En düşük	Orta	En yüksek
Şema değişikliği	Tek seferde	Her şema için	Her veritabanı için
Kiracıya özel yedek ve geri yükleme	Zor	Kolay	En kolay
Çok sayıda küçük kiracı	Çok uygun	Sınırlı	Uygun değil
Az sayıda büyük kurumsal kiracı	Yeterli olabilir	Uygun	Çok uygun

Seçimi neler belirler?

• Müşteri profili: Binlerce küçük işletmeye mi, az sayıda büyük kuruma mı hizmet vereceksiniz?
• Sözleşme ve mevzuat gereklilikleri: Müşteriler verilerinin fiziksel olarak ayrı tutulmasını şart koşuyor mu?
• Özelleştirme düzeyi: Kiracılar yalnızca ayar mı değiştirecek, yoksa kendilerine özel alanlar ve iş akışları mı isteyecek?
• Ekip kapasitesi: Çok sayıda veritabanını izleyecek ve güncelleyecek işletim gücünüz var mı?

Karma model

Yaklaşımlar birlikte de kullanılabilir. Yaygın bir düzen; standart paketlerdeki müşterileri ortak şemada tutmak, kurumsal müşterilere ise ayrı veritabanı sunmaktır. Bunun mümkün olabilmesi için kiracı bilgisinin uygulamanın her katmanında baştan taşınması gerekir.

Veritabanı dışında düşünülmesi gerekenler

• Kimlik ve yetki: Her oturumun hangi kiracıya ait olduğu kesin olarak bilinmeli; kullanıcılar birden fazla kiracıya üye olabiliyorsa geçiş güvenli kurgulanmalıdır.
• Kaynak paylaşımı: Tek bir kiracının yoğun kullanımı diğerlerini yavaşlatmamalıdır. İstek sınırları ve arka plan işleri için kiracı bazlı kotalar bu amaçla kullanılır.
• Dosyalar ve önbellek: Yalıtım yalnızca veritabanında değil; dosya depolama, önbellek ve arama dizininde de sağlanmalıdır.
• İzleme: Hata ve performans kayıtları kiracı bilgisini içermelidir; aksi halde “hangi müşteri etkilendi?” sorusu yanıtsız kalır.

Çoğu SaaS ürünü için ortak şema doğru başlangıçtır; önemli olan, ileride ayrı veritabanına geçişi engellemeyecek şekilde kurgulanmasıdır.

Ürününüzün mimarisini birlikte planlamak için SaaS ürün geliştirme hizmetimizi inceleyebilirsiniz.