Skip to main content

> saas_çok_kiracılı_i̇zolasyon_mimarisi_(silo_vs._havuz)

SaaS Çok Kiracılı İzolasyon Mimarisi (Silo vs. Havuz)

Çok kiracılı (multi-tenant) SaaS sistemlerinde altyapı maliyetlerini patlatmadan mutlak veri izolasyonu, yasal regülasyon uyumu ve gürültülü komşu (noisy neighbor) engellemesi nasıl sağlanır?

Stack: SOFTWARE ARCHITECTURE STACK →Staff (L6-L7)pattern

ÖZET VE TEKNİK CEVAP

Kiracı seviyelerine uygun bir model seçerek: Standart kullanıcılar için PostgreSQL Satır Düzeyinde Güvenlik (RLS) kullanan Havuzlu Ortak Veritabanı, regülasyon gereksinimleri olan kurumsal müşteriler için ise Silo İzole Veritabanı/Sunucu mimarisi kurarak.

Mühendislik El Kitabı & Mekanizma

1. Temel Çalışma Mekanizması

Çok kiracılı mimariler üç ana model arasında seçim yapar: 1) Silo Modeli (Kiracı Başına Veritabanı): Maksimum güvenlik ve özel yedekleme sağlayan, ancak en yüksek maliyet ve operasyonel yüke sahip tam fiziksel izolasyon; 2) Köprü Modeli (Kiracı Başına Şema): Aynı veritabanı kümesinde her kiracıya ayrı SQL şeması; 3) Havuz Modeli (Ortak Veritabanı ve Tablolar): Tüm kiracıların aynı tabloları `tenant_id` kolonuyla paylaştığı model. PostgreSQL Satır Düzeyinde Güvenlik (RLS), veritabanı motoru seviyesinde `WHERE tenant_id = current_setting('app.current_tenant_id')` filtresini otomatik ekleyerek geliştirici WHERE yazmayı unutsa dahi veri sızıntısını kesin olarak engeller.

2. Doğru Kullanım Senaryosu

Hem maliyet optimizasyonu isteyen binlerce standart kullanıcıya hem de katı KVKK/HIPAA/SOC2 veri izolasyonu talep eden kurumsal müşterilere hizmet veren B2B SaaS platformları.

3. Prodüksiyon Arıza Modları

1) Çapraz Kiracı Veri Sızıntısı: Geliştiricinin SQL sorgusuna `tenant_id` filtresi koymayı unutması sonucu bir müşterinin faturalarının diğerine görünmesi; 2) Gürültülü Komşu Kaynak Tüketimi: Bir müşterinin dev bir CSV raporu çalıştırıp bağlantı havuzunu tüketerek diğer tüm müşterileri yavaşlatması; 3) Şema Göçü Kilitlenmesi: 5.000 ayrı şemanın yönetildiği yapıda migrasyonun 842. şemada kilitlenip yarım kalması.

4. Teşhis ve Telemetri Sinyalleri

Kiracı bazlı CPU/bellek tüketim metrikleri, veritabanı RLS güvenlik ihlali alarmları, çok şemalı geçişlerdeki hata oranları ve kiracı bazlı API hız sınırı aşımları.

5. Önleme ve Mimari Bariyerler

Tüm tablolarda PostgreSQL Row-Level Security (RLS) kullanımını zorunlu kılın; API ara katmanında (middleware) otomatik kiracı bağlamı enjekte edin; kiracı bazlı hız sınırlama ve kaynak yalıtımı (bulkhead) uygulayın ve kurumsal müşterilere özel Silo veritabanları sunun.

6. Mimari Ödünleşimler (Trade-offs)

Havuz (Pool) modeli maliyet verimliliğini zirveye taşır ve dağıtımları basitleştirir; buna karşılık gürültülü komşu ve sızıntı riski taşır. Silo modeli ise kusursuz güvenlik sağlar; fakat yüksek altyapı maliyeti ve operasyonel yönetim yükü getirir.

Vaka İncelemesi (TinyCTO Örneği)

TinyCTO Vaka 072: Bir geliştirici bildirim sorgusunda `WHERE tenant_id = ?` filtresini unuttu ve bir şirketin gizli maaş bildirimleri 12 rakip şirkete gönderildi. PostgreSQL Row-Level Security (RLS) mimarisine geçilerek kiracı izolasyonu veritabanı çekirdeğinde zorunlu kılındı; uygulama kodunda hata olsa bile başka kiracının verisine erişim matematiksel olarak imkansız hale getirildi.

İnteraktif Konsept Alıştırmaları

3 Alıştırma
Q1

PostgreSQL Row-Level Security (RLS), çok kiracılı veri sızıntılarını matematiksel olarak nasıl engeller?

RLS, uygulama sorgusunda ne yazarsa yazsın, veritabanı motorunun her SQL sorgusuna otomatik olarak güvenlik politikasını (`tenant_id = current_setting('app.tenant_id')`) eklemesini zorunlu kılar.
Q2

Çok kiracılı mimarilerde 'Gürültülü Komşu' (Noisy Neighbor) problemi nedir?

Aşırı aktif tek bir kiracının paylaşılan CPU, bellek, veritabanı bağlantısı veya disk IOPS kaynaklarını orantısız tüketerek aynı kümedeki diğer tüm müşterileri yavaşlatmasıdır.
Q3

Kiracı Başına Şema (Bridge) modeli 1.000'den fazla kiracıya ulaşıldığında neden yönetilmesi son derece zor hale gelir?

Binlerce şemada veritabanı migrasyonu çalıştırmak saatler sürer, bağlantı havuzları parçalanır ve veritabanı sistem katalog belleği gigabaytlarca RAM tüketir.

SaaS Çok Kiracılı İzolasyon Mimarisi (Silo vs. Havuz) — Sıkça Sorulan Sorular

PostgreSQL'de kiracı bağlamı API'den veritabanı oturumuna güvenli şekilde nasıl aktarılır?

Doğrulanmış JWT belirtecinden kiracı kimliğini alın ve işlem (transaction) içinde veritabanı bağlantısını alır almaz `SET LOCAL app.current_tenant_id = 'tenant_123'` komutunu çalıştırın.

Havuzlu çok kiracılı mimariler HIPAA veya SOC2 gibi kurumsal regülasyon standartlarını karşılayabilir mi?

Evet; kiracı bazlı anahtarlarla şifreleme (envelope encryption), veritabanı düzeyinde RLS izolasyonu, eksiksiz denetim loglaması ve katı mantıksal erişim kontrolleri kanıtlandığı sürece.

Havuzlu modelde tek bir müşteriye özel veri yedekleme ve geri yükleme nasıl yapılır?

Tüm veritabanı yedeğini geri yüklemek diğer kiracıların verisini ezeceğinden, `tenant_id` filtresiyle çalışan özel veri dışa aktarma ve geri yükleme (export/import) scriptleri yazılmalıdır.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

  • ▸Çok kiracılık (Multi-tenancy), bir yazılım uygulamasının tek bir örneğinin birden fazla bağımsız müşteri organizasyonuna (kiracı) hizmet vermesini sağlayan mimari tasarımdır.
  • ▸PostgreSQL Row-Level Security (RLS), sıfır ağ gecikmesiyle doğrudan veritabanı çekirdeğinde çalıştırılır.

Yaygın Yanılgılar

  • ✗Uygulama düzeyindeki ORM filtrelerinin (Prisma/Hibernate middleware) veritabanı RLS kadar güvenli olduğunu sanmak; yazılan tek bir ham SQL sorgusu uygulama ara katmanını tamamen baypas eder.

Karar Kılavuzu & Önceliklendirme

Maksimum geliştirme hızı ve maliyet verimliliği için RLS kullanan Havuzlu Veritabanı ile başlayın. Silo Veritabanı seçeneğini kurumsal müşterilere ek ücretli bir kurumsal paket olarak sunun.

Doğrulanmış Kaynaklar & Referanslar