SaaS Uygulamaları İçin Çok Kiracılı Mimari Türleri ve Doğru Hosting Altyapısı Seçimi

Neden Çok Kiracılı Mimari SaaS İçin Kritik?

SaaS ürünü geliştiren neredeyse herkes aynı soruyla karşılaşıyor: “Müşteri sayısı arttıkça bu mimari beni ne kadar taşıyacak?” İlk pilot müşterilerle tek kiracılı bir kurulum (her müşteri için ayrı sunucu veya veritabanı) kısa süreliğine iş görebiliyor. Ancak onlarca, yüzlerce hatta binlerce müşteriye ölçeklenmek istiyorsanız, çok kiracılı (multi‑tenant) mimari kaçınılmaz hale geliyor.

Çok kiracılı mimariyi sadece veritabanında tabloya “tenant_id” eklemek gibi düşünmek büyük hata. Uygulama katmanından veritabanına, ağ topolojisinden yedeklemeye kadar her katmanda bu kararın yansımaları var. Doğru modeli seçmediğinizde, ileride migration projelerine, karmaşık şema değişikliklerine ve maliyet patlamalarına davetiye çıkmış oluyorsunuz.

Bu yazıda DCHost ekibi olarak; SaaS uygulamaları için farklı çok kiracılı mimari türlerini, veritabanı modellerini, izolasyon ve güvenlik boyutunu, ölçeklendirme stratejilerini ve tüm bunları taşıyacak doğru hosting altyapısını adım adım ele alacağız. Amacımız, kendi SaaS’iniz için hem bugün hem de 2–3 yıl sonrasını düşünerek mantıklı bir yol haritası oluşturmanıza yardımcı olmak.

SaaS’te Çok Kiracılı Mimari Temelleri

Önce kavramları netleştirelim. Kiracı (tenant), SaaS uygulamanızı kullanan her bir müşteri, şirket, kurum veya organizasyon anlamına gelir. Çok kiracılı mimaride aynı uygulama ve altyapı üzerinde birden fazla kiracı birlikte yaşar, ancak:

• Verileri mantıksal ya da fiziksel olarak birbirinden ayrılır.
• Kaynak kullanımı (CPU, RAM, disk, bant genişliği) yönetilebilir ve sınırlandırılabilir.
• Güvenlik ve yetkilendirme katmanları her kiracıyı koruyacak şekilde kurgulanır.

Buna karşılık tek kiracılı (single‑tenant) yaklaşımda her müşteri için ayrı bir uygulama ve/veya veritabanı kurarsınız. İzolasyon güçlüdür, ancak operasyonel maliyet ve yönetim yükü hızla artar.

Karar verirken aslında üç ana eksende düşünmelisiniz:

• İzolasyon seviyesi: Güvenlik, KVKK/GDPR, sektör regülasyonları (finans, sağlık vb.).
• Maliyet ve operasyon: Yönetilecek veritabanı/sunucu sayısı, otomasyon ihtiyacı.
• Esneklik ve ölçeklenebilirlik: Hızla yeni müşteri ekleme, bölgeler arası dağıtım, yedekleme/geri yükleme senaryoları.

Çok Kiracılı Veritabanı Mimari Türleri

1) Paylaşımlı Veritabanı, Paylaşımlı Şema (Shared DB, Shared Schema)

En çok bilinen model budur. Tüm kiracılar aynı veritabanında, aynı tabloları kullanır; her tabloya genellikle tenant_id gibi bir alan eklenir. Uygulama katmanı, sorgu atarken ilgili kiracının kimliğini bilerek filtre uygular.

Avantajları:

• Yönetmesi görece kolay; tek bir veritabanı kümesi üzerinde çalışırsınız.
• Yeni kiracı eklemek hızlı; veri tabanı düzeyinde ekstra nesne oluşturmanıza gerek yoktur.
• Altyapı maliyeti düşüktür; donanım kaynakları verimli paylaştırılır.

Dezavantajları:

• Uygulama kodu ve sorgular tenant bilincine sahip olmak zorunda; hata yapmaya çok açıktır.
• Güvenlik için satır seviyesinde yetkilendirme (row‑level security) veya view/tabanlı izolasyon kullanmanız gerekir.
• Tek bir büyük veritabanı, ölçek büyüdükçe yönetim, indeksleme ve bakım açısından zorlaşır.

Özellikle erken aşama SaaS projelerinde, MVP döneminde ve sık şema değişikliği yaptığınız ürünlerde tercih edilebilir. Ancak ileride hangi ölçeğe çıkmayı hedeflediğinizi mutlaka hesaba katmalısınız.

2) Paylaşımlı Veritabanı, Ayrı Şema (Shared DB, Isolated Schema)

Bu modelde tüm kiracılar aynı veritabanını paylaşır ama her kiracının kendi şeması (schema) vardır. Örneğin: tenant1.users, tenant2.users gibi.

Avantajları:

• Şema seviyesinde izolasyon; yanlış tenant_id filtrelemesi nedeniyle veri sızması riski azalır.
• Şema bazlı yedekleme ve geri yükleme daha esnektir; tek bir kiracıya ait şemayı hedef alabilirsiniz.
• Şema başına farklı indeks ve optimizasyon ayarları yapmak mümkündür.

Dezavantajları:

• Kiracı sayısı arttıkça yönetilecek şema sayısı hızla büyür.
• Migration ve versiyon yönetimi zorlaşır; her şemayı aynı yapıda tutmak için güçlü otomasyon gerekir.
• Veritabanı üzerinde nesne sayısı arttığı için bazı motorlarda performans ve bakım yükü artar.

Düzenli ama çok yüksek olmayan sayıda kiracıya hizmet veren, uyumluluk baskısı orta seviyede olan SaaS projeleri için dengeli bir çözümdür.

3) Her Kiracıya Ayrı Veritabanı (Database‑per‑Tenant)

İzolasyonun en güçlü olduğu klasik çok kiracılı model budur. Her müşteri için ayrı bir veritabanı oluşturursunuz; bağlantı bilgileri uygulama katmanında dinamik olarak yönetilir.

Avantajları:

• Veri izolasyonu çok yüksektir; uyumluluk ve regülasyon gerektiren sektörler için idealdir.
• Her kiracıyı ayrı ayrı ölçekleyebilirsiniz; büyük müşteriye özel daha güçlü bir veritabanı kümesi atamak mümkündür.
• Kiracı bazlı yedekleme, restore ve test ortamı kopyalama işleri çok daha esnektir.

Dezavantajları:

• Veritabanı sayısı arttıkça operasyonel yük ciddi şekilde artar.
• Migration, indeks yönetimi, performans izlemesi gibi işler otomasyon olmadan neredeyse imkansız hale gelir.
• Küçük kiracılar için kaynak kullanımı verimsiz olabilir.

Kurumsal müşterilere, yüksek biletli lisanslarla hizmet veren SaaS ürünlerinde sıkça tercih edilir. Burada veritabanı sunucusunu uygulama sunucusundan ayırmanın mantıklı olduğu durumlar özellikle önem kazanır; çünkü veritabanı katmanı başlı başına ayrı bir dünya haline gelir.

4) Hibrit Yaklaşımlar

Gerçek dünyada çoğu SaaS, tek bir modele sıkı sıkıya bağlı kalmak yerine hibrit bir yaklaşım kullanır. Örneğin:

• Küçük ve orta ölçekli kiracılar için paylaşımlı veritabanı + paylaşımlı şema,
• Kurumsal ve yüksek hacimli kiracılar için ayrı veritabanı,
• Raporlama veya arşiv verileri için bambaşka bir depolama katmanı.

Böyle bir model size fiyatlandırma esnekliği de sağlar. “Standart” paket için shared DB, “Enterprise” paket için database‑per‑tenant sunabilirsiniz. Önemli olan, bu farklı modelleri altyapı tarafında taşıyacak, otomasyonla desteklenmiş bir hosting tasarımına sahip olmanızdır.

Uygulama Katmanında Çok Kiracılık: Routing, Domain ve Kimlik

Veritabanı mimarisini seçtiniz; peki uygulama kiracıyı nasıl tanıyacak? Üç temel yaklaşım yaygın:

• Alt alan adı bazlı: musteri1.saas.com, musteri2.saas.com
• Özel alan adı (custom domain): app.musteri1.com
• URL yolu bazlı: saas.com/m/musteri1/…

Alt alan adı ve özel alan adı senaryolarında, DNS ve SSL otomasyonu kritik hale gelir. Kiracı panelden kendi alan adını eklediğinde, arka planda DNS doğrulaması, SSL sertifikası üretimi ve reverse proxy yapılandırması otomatik akmalıdır. Bunun için SaaS’te özel alan adları ve otomatik SSL mimarisini detaylı anlattığımız rehbere mutlaka göz atmanızı öneririz.

Uygulama tarafında ise tipik desenler şunlardır:

• Her istek başında domain veya path’ten kiracıyı tespit etmek.
• Kiraci_id’yi request context içerisinde taşımak (middleware, dependency injection vb.).
• Veritabanı bağlantısını ve sorguları kiracının bağlamına göre oluşturmak.
• Özellik bazlı ayrımlar için feature flag veya plan bazlı yetkilendirme kullanmak.

Burada yapılan hatalar genellikle güvenlik açığına dönüşür: Yanlış tenant bağlamında sorgu çalıştırmak, cache key oluştururken tenant bilgisini hesaba katmamak gibi. Bu yüzden kod seviyesinde tenant bilincini baştan net bir şekilde tasarlamak kritik.

Hosting ve Altyapı Seçimi: Hangi Mimariye Hangi Yapı Yakışır?

Şimdi asıl can alıcı yere gelelim: Seçtiğiniz çok kiracılı model, hosting tarafında ne anlama geliyor? DCHost tarafında gördüğümüz projelerde genel yaklaşım şöyle:

Paylaşımlı Veritabanı Kullanan SaaS’ler İçin Hosting Önerileri

Paylaşımlı veritabanı (özellikle shared schema) kullanan SaaS’lerde en büyük risklerden biri, tek bir veritabanı düğümünün tıkanmasıdır. Bu nedenle:

• Uygulama ve veritabanı sunucusunu aynı makinede başlatmak yerine, en azından orta vadede ayırmayı planlayın.
• Başlangıçta güçlü bir VPS üzerinde hem uygulama hem veritabanı ile başlayıp, ölçek arttıkça veritabanını ayrı bir VPS veya dedicated sunucuya taşıyın.
• Kapasite büyüdükçe, dedicated sunucu mu VPS mi karşılaştırması yaparak veritabanı katmanını fiziksel sunucuya çekmeyi düşünün.

Bu modelde dikey ölçekleme (daha güçlü CPU/RAM) bir süre idare eder; ama belirli bir noktadan sonra okuma/yazma ayrımı, replikasyon ve sharding gibi tekniklere ihtiyaç duyacaksınız.

Database‑per‑Tenant Kullanan SaaS’ler İçin Hosting Önerileri

Her kiracıya ayrı veritabanı verdiğiniz senaryoda işin rengi değişir. Burada:

• Veritabanı sunucularını cluster yapısında veya ayrı VPS kümelerinde dağıtmak mantıklı olur.
• Büyük kiracılar için daha güçlü, küçük kiracılar için daha mütevazı kaynak ayırabilirsiniz.
• Yüksek erişilebilirlik ihtiyacı olan kurumsal müşteriler için primary/replica yapılandırmaları ve hatta çok bölgeli replikasyon gerekebilir.

Böyle senaryolarda çok bölgeli mimariler ve DNS geo‑routing yaklaşımı büyük resimde işinize yarar. DCHost üzerinde birden fazla lokasyonda VPS veya dedicated sunucu konumlandırıp, kritik kiracılar için bölgesel replikasyon kurabilirsiniz.

Teknoloji Stack’ine Göre Seçim

Monolitik bir PHP/Laravel veya Node.js uygulamasıyla başlıyorsanız, genellikle:

• 1–2 adet uygulama VPS’i,
• 1 adet veritabanı VPS’i (veya büyüyünce dedicated),
• Güvenlik duvarı, WAF ve yedekleme altyapısı

ile başlayabilirsiniz. Mikroservis mimarisi, Kubernetes gibi daha karmaşık yapılara geçişi ise gerçekten ihtiyaç doğana kadar ertelemek çoğu SaaS için mantıklı.

DCHost tarafında hem klasik VPS/dedicated sunucu hem de colocation ile kendi fiziksel sunucularınızı barındırma seçenekleri var. Özellikle regülasyon gereği kendi donanımınızı kullanmak zorunda olduğunuz durumlarda colocation ciddi bir alternatif sunuyor.

Veritabanı ve Depolama Tasarımı: Çok Kiracılı Gerçekler

Çok kiracılı mimaride veritabanı kararları çoğu zaman uygulama kodundan daha belirleyici hale gelir. Özellikle paylaşımlı veritabanı senaryosunda dikkat edilmesi gerekenler:

• Dizinleme (indexing): Hemen her ana tabloda tenant_id + sık kullanılan filtre alanlarını kapsayan indeksler oluşturun.
• Bağlantı havuzu (connection pooling): Yük altındayken her istek için yeni bağlantı açmak yerine bağlantı havuzu kullanın.
• Noisy neighbor problemi: Tek bir kiracının ağır sorguları, diğer tüm kiracıları etkileyebilir; bu yüzden sorgu sınırları ve plan bazlı kısıtlar önemli.
• Yedekleme stratejisi: Sadece tam veritabanı yedeği değil, kiracı bazlı ihracat veya mantıksal yedek alma senaryolarını da düşünün.

Yük arttıkça veritabanı sunucusunu uygulama sunucusundan ayırmak, ayrı disk altyapısı ve IOPS planlaması yapmak zorunlu hale gelir. Bunun için daha önce hazırladığımız veritabanı sunucusunu uygulama sunucusundan ayırmanın mantıklı olduğu durumlar rehberi çok işinize yarayacaktır.

Güvenlik, İzolasyon ve KVKK/GDPR Boyutu

Bir SaaS büyüdükçe teknik borç kadar hukuki ve regülasyon yükü de artar. Çok kiracılı mimari seçimi bu noktada kritik bir kaldıraçtır.

• Veri izolasyonu: Shared schema modelinde satır seviyesinde, schema bazlı modelde şema seviyesinde, database‑per‑tenant modelde ise veritabanı seviyesinde izolasyon sunarsınız.
• Şifreleme: At‑rest (diskte) ve in‑transit (ağda) şifreleme, özellikle kişisel veri işleyen SaaS’ler için artık fiili standart.
• Loglama ve erişim kayıtları: Hangi kullanıcı hangi kiracının verisine erişti, ne yaptı? Bunların izlenebilir olması KVKK ve GDPR için önemli.

DCHost tarafında veri yerelleştirme, loglama ve silme süreçlerini düşünürken, KVKK ve GDPR uyumlu hosting rehberinde anlattığımız adımları çok kiracılı mimarinize uyarlamanızda fayda var.

Ek olarak:

• Yönetim panellerini IP kısıtlama, VPN veya mTLS ile koruyun.
• Her kiracı için veri saklama sürelerini (retention) politikalarla belirleyin.
• Düzenli zafiyet taraması ve yama yönetimi yapın; özellikle paylaşımlı ortamlarda bir zafiyet tüm kiracıları etkileyebilir.

İzleme, Ölçeklendirme ve Operasyon

Çok kiracılı yapıyı ayakta tutan görünmez katman, izleme (monitoring) ve alarm sistemidir. Burada sadece CPU/RAM değil, kiracı bazlı metrikleri de izlemeniz gerekir:

• Kiracı başına istek sayısı, sorgu sayısı, hata oranı.
• Plan bazlı limitlere yaklaşan kiracılar (örneğin depolama kotası).
• Aşırı kaynak tüketen veya anormal davranan kiracılar.

Bu metriklere göre ölçeklendirme stratejinizi belirleyebilirsiniz. Örneğin:

• Uygulama katmanında yatay ölçekleme (ek VPS veya ek container) ile istek yükünü dağıtmak.
• Veritabanında okuma replikaları ekleyerek raporlama trafiğini ana düğümden ayırmak.
• Noisy neighbor kiracılar için özel altyapı veya fiyatlandırma modeli sunmak.

DCHost üzerinde VPS veya dedicated sunucularınızı kurarken, merkezi loglama ve izleme çözümleri ile çalışmanızı öneririz. Böylece tek bir kiracının oluşturduğu sorun tüm sistemi etkilemeden önce müdahale edebilirsiniz.

DCHost Üzerinde Örnek Çok Kiracılı SaaS Mimarileri

Senaryo 1: Erken Aşama, 50–100 Kiracı Hedefleyen SaaS

Yeni bir SaaS ürünü geliştiriyorsunuz, 1 yıl içinde 50–100 müşteri hedefliyorsunuz. Regülasyon baskısı düşük, daha çok KOBİ’lere hitap ediyorsunuz.

• Veritabanı modeli: Paylaşımlı veritabanı, paylaşımlı şema.
• Altyapı: 1 adet orta seviye VPS (uygulama), 1 adet orta seviye VPS (veritabanı).
• DNS/SSL: DCHost DNS yönetimi + ACME otomasyonu ile alt alan adı bazlı çok kiracılık.
• Yedekleme: Günlük tam yedek + saatlik transaction log yedeği.

Bu seviyede maliyetleri düşük tutup ürünü doğrularken, mimariyi ileride database‑per‑tenant modele geçebilecek şekilde tasarlamanız akıllıca olur.

Senaryo 2: Kurumsal Ağırlıklı, Yüksek Biletli SaaS

Hedef kitleniz orta ve büyük ölçekli kurumlar; bilgi güvenliği ekipleri sıkı sorular soruyor, SLA beklentileri yüksek.

• Veritabanı modeli: Küçük kiracılar için shared DB, büyük kiracılar için database‑per‑tenant.
• Altyapı: Uygulama katmanı için ölçeklenebilir VPS kümesi; büyük kiracılar için ayrı veritabanı VPS’leri veya dedicated sunucular.
• Ağ: VPN veya özel ağ üzerinden yönetim erişimi, WAF ve DDoS koruma katmanı.
• DR/HA: Kritik kiracılar için farklı bölgede yedek veritabanı ve DNS bazlı failover.

Böyle bir mimaride hem gelirinizle orantılı maliyet yönetimi yapabilir, hem de kurumsal müşterilerin beklediği izolasyon ve sürekliliği sağlayabilirsiniz.

Senaryo 3: Yüksek Trafikli, Çok Bölgeli SaaS

Bir noktadan sonra tek veri merkezi veya tek bölge yeterli gelmez. Hem performans hem de felaket senaryoları için çok bölgeli yapıya geçmeniz gerekir.

• Altyapı: Birden fazla lokasyonda DCHost VPS veya dedicated sunucular.
• DNS: Anycast ve geo‑routing ile kullanıcıyı en yakın bölgeye yönlendirmek.
• Veritabanı: Bölgeler arası replikasyon; gecikme ve tutarlılık dengesini iyi planlamak.

Bu tür senaryolar için daha önce bahsettiğimiz çok bölgeli mimari rehberi ile birlikte, altyapınızı adım adım büyütmek mümkün.

Sonuç: Bugünün Kararı Yarınki Refaktoring’i Belirliyor

Çok kiracılı mimari, SaaS’inizin kaderini belirleyen en kritik teknik kararlardan biri. Bugün 5–10 müşteriyle çalışan bir ürün için “ne olacak ki, tek veritabanında gider” demek kolay. Asıl mesele, 200. müşteri geldiğinde bu kararı ne kadar rahat savunabileceğiniz. Veritabanı modeli, uygulama katmanındaki tenant bilinci, DNS/SSL otomasyonu, yedekleme ve felaket senaryoları; hepsi bir bütün olarak düşünülmeli.

DCHost tarafında biz, yeni bir SaaS projesiyle konuşurken önce iş modelini, hedef müşteri sayısını, regülasyon baskısını ve büyüme temposunu anlamaya çalışıyoruz. Çünkü paylaşımlı veritabanı mı, ayrı veritabanı mı, VPS mi yoksa dedicated mi sorularının doğru cevabı ancak bu bağlamla ortaya çıkıyor.

Eğer kendi SaaS’iniz için doğru çok kiracılı mimari ve hosting altyapısını netleştirmek istiyorsanız, mevcut tasarımınızı birlikte gözden geçirip iki‑üç yıllık gerçekçi bir yol haritası çıkarabiliriz. DCHost’un domain, hosting, VPS, dedicated ve colocation çözümlerini; seçtiğiniz mimariyle uyumlu, ölçeklenebilir bir yapı halinde kurgulamak mümkün. Bir sonraki refaktoring projeniz panik değil, plan sonucu olsun istiyorsanız, ilk adımı birlikte atalım.