Aynı uygulamayı birden fazla müşteriye sunuyorsunuz. Her müşteri için ayrı kurulum yapmak yönetimi imkânsız hâle getiriyor. Tek kurulumla hizmet vermek mümkün — ama veri izolasyonu kritik bir tasarım kararı.
Bu yazı, çok kiracılı mimarinin sunucu tarafındaki sonuçlarını ele alıyor.
Üç İzolasyon Modeli
Müşteri verilerini ayırmanın farklı seviyeleri vardır:
| Model | Özelliği |
|---|---|
| Ortak tablo, kiracı sütunu | En verimli, en riskli |
| Ayrı şema | Orta izolasyon |
| Ayrı veritabanı | En güvenli, en maliyetli |
Birinci satırın riski nettir: tek bir sorguda kiracı filtresini unutmak, bir müşteriye başkasının verisini göstermek demektir.
Bu, en ağır güvenlik ihlallerinden biridir ve genellikle küçük bir kod hatasından doğar.
Üçüncü satır bu riski tamamen ortadan kaldırır ama ölçek sınırı getirir — yüzlerce müşteri için yüzlerce veritabanı yönetmek zorlaşır.
Filtre Unutma Riskini Azaltmak
Ortak tablo modeli kullanılıyorsa, filtre uygulamayı zorunlu kılmak gerekir:
- Sorguları doğrudan yazmayın. Bir katmandan geçirin.
- Kiracı filtresini otomatik ekleyin.
- Veritabanı seviyesinde satır güvenliği kullanın.
- Filtresiz sorguyu hata olarak işaretleyin.
Üçüncü madde en güçlü korumadır: veritabanı seviyesinde tanımlanan satır erişim kuralı, uygulama kodu filtreyi unutsa bile başka kiracının verisini döndürmez.
Bu, korumayı geliştiricinin dikkatinden alıp altyapıya taşır — ve insan hatasına dayanıklı hâle getirir.
Dördüncü madde ise geliştirme aşamasında yakalar. Kiracı filtresi olmayan bir sorgu, test ortamında hata üretecek şekilde ayarlanabilir.
Kaynak Adaleti
Ortak bir sunucuda bir kiracı diğerlerini etkileyebilir:
- Ağır sorgu çalıştıran müşteri veritabanını yavaşlatır.
- Çok veri yükleyen müşteri diski doldurur.
- Yoğun trafik alan müşteri işçileri tüketir.
- Toplu işlem yapan müşteri kuyruğu tıkar.
Dördüncü madde çok kiracılı sistemlerde en sık yaşanan sorundur: bir müşterinin başlattığı yüz bin kayıtlık toplu işlem, kuyruğu doldurup diğer müşterilerin işlerini saatlerce bekletir.
Çözüm, kiracı bazlı kuyruk sınırı veya adil paylaşımlı bir işleme düzeni kurmaktır. Her kiracıya sırayla hizmet veren bir işçi, tek bir müşterinin sistemi ele geçirmesini engeller.
Kiracı Bazlı Sınırlar
Adaleti sağlamak için tanımlanacak kotalar:
| Sınır | Neyi korur |
|---|---|
| Depolama kotası | Disk |
| İstek hızı sınırı | İşçi havuzu |
| Eşzamanlı iş sayısı | Kuyruk |
| Kayıt sayısı sınırı | Veritabanı boyutu |
| Sorgu süre sınırı | Veritabanı performansı |
Beşinci satır kritik bir korumadır: belirli bir süreyi aşan sorguyu otomatik iptal etmek, tek bir kötü sorgunun tüm sistemi kilitlemesini önler.
Bu sınır olmadan, bir müşterinin oluşturduğu karmaşık bir rapor sorgusu dakikalarca çalışıp veritabanını meşgul edebilir.
Kiracıya Özel Yapılandırma
Müşterilerin farklı ihtiyaçları olur:
- Kendi alan adları.
- Kendi görsel kimlikleri.
- Farklı özellik paketleri.
- Ayrı e-posta gönderen bilgileri.
Birinci madde sunucu tarafında ek iş gerektirir: her müşterinin kendi alan adını kullanması, o alan adı için ayrı SSL sertifikası ve DNS doğrulaması demektir.
Bu, otomatikleştirilmesi gereken bir süreçtir. Müşteri alan adını bağladığında sertifikanın otomatik alınması ve yenilenmesi gerekir.
Dördüncü madde ise teslimat açısından önemlidir. Tüm müşteriler adına aynı adresten e-posta göndermek, bir müşterinin sorunlu davranışının hepsini etkilemesine yol açar.
Yedekleme ve Geri Yükleme
Çok kiracılı yapıda yedekleme karmaşıklaşır:
- Tüm sistem birlikte yedeklenir.
- Tek bir müşteriyi geri yüklemek zordur.
- Geri yükleme diğerlerini etkiler.
- Müşteri bazlı dışa aktarma gerekir.
İkinci madde gerçek bir operasyonel sorundur: bir müşteri "dünkü verilerimi geri getirin" dediğinde, tüm veritabanını geri yüklemek diğer müşterilerin bir günlük verisini silmek demektir.
Bu yüzden kiracı bazlı yedek alma ve geri yükleme yeteneği baştan tasarlanmalıdır. Ayrı veritabanı modelinde bu kendiliğinden çözülür; ortak tablo modelinde ayrıca geliştirilmesi gerekir.
Kiracı Taşıma
Bir müşteriyi başka bir sunucuya taşımak gerekebilir:
| Gerekçe | Durum |
|---|---|
| Müşteri çok büyüdü | Kendi kaynağı gerekiyor |
| Uyum gerekliliği | İzole altyapı isteniyor |
| Coğrafi gereklilik | Veri konumu şartı |
| Yük dengeleme | Sunucular arası dağıtım |
Birinci satır büyüyen bir işte kaçınılmazdır: diğer tüm müşterilerin toplamından fazla kaynak tüketen bir müşteri, ortak yapıdan çıkarılmalıdır.
Bu taşımanın mümkün olması için, verinin kiracı bazında ayrılabilir olması gerekir. Bu yetenek baştan düşünülmezse, sonradan eklemek büyük bir yeniden yapılandırma gerektirir.
Kiracı Bazlı İzleme
Sorunları teşhis etmek için ölçümler kiracı bazında kırılmalıdır:
- Kiracı başına istek sayısı
- Kiracı başına yanıt süresi
- Kiracı başına depolama
- Kiracı başına hata oranı
- En yavaş sorgular ve sahibi
Beşinci madde teşhis süresini dramatik biçimde kısaltır: sistem yavaşladığında hangi müşterinin hangi sorgusunun sebep olduğunu görmek, sorunu dakikalar içinde çözer.
Bu kırılım olmadan yalnızca "veritabanı yavaş" bilgisine sahip olursunuz ve kaynağı aramakla saatler geçer.
Bu tür ayrıntılı izlemeyi ve kaynak sınırlarını kendi yapılandırmanızda tanımlayabildiğiniz sanal sunucu barındırma ortamında, kiracı bazlı kotalar sistem seviyesinde de desteklenebilir.
Sonuç
Çok kiracılı mimaride en ağır risk veri sızıntısıdır: tek bir sorguda kiracı filtresini unutmak, bir müşteriye başkasının verisini göstermek demektir. Korumayı geliştiricinin dikkatine bırakmayın — veritabanı seviyesinde satır erişim kuralı, kod filtreyi unutsa bile veriyi korur. Kaynak tarafında en sık yaşanan sorun ise kuyruk tıkanmasıdır: bir müşterinin toplu işlemi diğerlerinin işlerini saatlerce bekletebilir. Ve kiracı bazlı yedekleme yeteneğini baştan tasarlayın.
Sıkça Sorulan Sorular (SSS)
Hangi izolasyon modelini seçmeliyim?
Az sayıda büyük müşteri varsa ayrı veritabanı en güvenlisidir. Çok sayıda küçük müşteride ortak tablo verimlidir ama filtre unutma riski taşır — bu modelde veritabanı seviyesinde satır erişim kuralı kullanmak neredeyse zorunludur.
Veri sızıntısını nasıl önlerim?
Korumayı uygulama kodundan altyapıya taşıyarak. Veritabanı seviyesinde tanımlanan satır erişim kuralı, kod kiracı filtresini unutsa bile başka müşterinin verisini döndürmez. Ayrıca sorguları doğrudan yazmayıp filtreyi otomatik ekleyen bir katmandan geçirin.
Bir müşteri sistemi yavaşlatıyor?
Kiracı bazlı sınırlar tanımlayın: istek hızı, eşzamanlı iş sayısı ve özellikle sorgu süre sınırı. Belirli süreyi aşan sorguyu otomatik iptal etmek, tek bir kötü sorgunun tüm sistemi kilitlemesini önler.
Tek bir müşterinin verisini nasıl geri yüklerim?
Bu yetenek baştan tasarlanmalıdır. Tüm veritabanını geri yüklemek diğer müşterilerin verisini de geri alır — yani onların bir günlük çalışmasını siler. Ayrı veritabanı modelinde sorun kendiliğinden çözülür; ortak tablo modelinde kiracı bazlı dışa aktarma ve içe aktarma geliştirmeniz gerekir.
