Çok Kiracılı Veritabanlarının Güvenlik ve Performansa Etkisi

Çok Kiracılı Veritabanı Ne Anlama Gelir

Bir çok kiracılı veritabanı, birden fazla müşterinin (kiracıların) aynı veritabanı sistemini paylaştığı bir düzenlemedir—aynı veritabanı sunucusu, aynı temel depolama ve genellikle aynı şema—uygulama ise her kiracının yalnızca kendi verisine erişmesini sağlar.

Bunu bir apartmana benzetin: herkes binanın yapısını ve altyapısını paylaşıyor, ama her kiracının kendi kilitli ünitesi var.

Çok kiracılı vs tek kiracılı (yüksek seviyede)

Tek kiracılı yaklaşımda, her müşteriye ada özgü veritabanı kaynakları verilir—örneğin kendi veritabanı örneği veya sunucusu. İzolasyonu değerlendirmek daha kolaydır, ama müşteri sayısı arttıkça maliyetli ve işletme yükü ağır olabilir.

Çok kiracılılık ile kiracılar altyapıyı paylaşır; bu verimli olabilir—ancak sınırları kasıtlı olarak uygulamanız gerekir.

Neden SaaS ekipleri çok kiracılığı seçer

SaaS şirketleri pratik nedenlerle genellikle çok kiracılığı tercih eder:

• Müşteri başına daha düşük maliyet (paylaşılan işlem, depolama, lisans ve operasyon zamanı)
• Ölçekte daha basit operasyonlar, örneğin yamalamak, yükseltmek ve izlemek için daha az veritabanı
• Yeni müşteriler için daha hızlı onboarding (tam bir veritabanı yığını sağlama ihtiyacı yok)

Ana beklenti: tasarım sonuçları belirler

Çok kiracılılık kendi başına otomatik olarak “güvenli” veya “hızlı” olmaz. Sonuçlar, kiracıların nasıl ayrıldığına (şema, satır veya ayrı veritabanı), erişim kontrolünün nasıl uygulandığına, şifreleme anahtarlarının nasıl yönetildiğine ve bir kiracının iş yükünün diğerlerini yavaşlatmasını nasıl önlediğinize bağlıdır.

Bu rehberin geri kalanı bu tasarım seçimlerine odaklanıyor—çünkü çok kiracılı sistemlerde güvenlik ve performans inşa edilen özelliklerdir, devraldığınız varsayımlar değil.

Yaygın Çok Kiracılı Veritabanı Modelleri

Çok kiracılılık tek bir tasarım seçimi değildir—altyapıyı ne kadar sıkı paylaştığınıza dair bir yelpazededir. Seçtiğiniz model izolasyon sınırınızı belirler (ne asla paylaşılmamalı) ve bu doğrudan veritabanı güvenliğini, performans izolasyonunu ve günlük operasyonları etkiler.

Tenant başına veritabanı

Her kiracı kendi veritabanını alır (genellikle aynı sunucu veya kümede).

İzolasyon sınırı: veritabanı. Bu genelde en temiz kiracı izolasyon hikayesidir çünkü kiracılar arası erişim tipik olarak bir veritabanı sınırını geçmeyi gerektirir.

Operasyonel takaslar: ölçeklendiğinde işletilmesi daha ağırdır. Yükseltmeler ve şema migration'ları binlerce kez çalıştırılmak zorunda kalabilir, bağlantı havuzlama karmaşıklaşabilir. Yedek/geri yükleme kiracı düzeyinde basittir, ama depolama ve yönetim yükü hızla büyüyebilir.

Güvenlik ve tuning: genelde müşteri bazında güvenli ve ayarlanması en kolay yaklaşımdır; farklı uyumluluk gereksinimleri olan kiracılar için uygundur.

Tenant başına şema

Kiracılar bir veritabanını paylaşır, ama her kiracının kendi şeması vardır.

İzolasyon sınırı: şema. Anlamlı bir ayrım sunar, ancak doğru izinlere ve araçlara dayanır.

Operasyonel takaslar: upgrade ve migration'lar hala tekrarlıdır, ancak database-per-tenant kadar ağır değildir. Yedeklemeler daha karmaşıktır: birçok araç veritabanını yedek birimi olarak ele alır, bu yüzden kiracı düzeyinde işlemler şema düzeyinde dışa aktarma gerektirebilir.

Güvenlik ve tuning: paylaşılan tablolara kıyasla izolasyonu uygulamak kolaydır, ancak ayrı şemaya yanlışlıkla başvurmayı engelleyecek disiplin gerektirir.

Tenant başına tablo

Tüm kiracılar aynı veritabanı ve şemayı paylaşır, ancak her kiracı için ayrı tablolar vardır (ör. orders_tenant123).

İzolasyon sınırı: tablo kümesi. Az sayıda kiracı için çalışabilir, ancak ölçeklenmesi zordur: metadata şişmesi, migration script'leri zorlayıcı olur ve sorgu planlaması bozulabilir.

Güvenlik ve tuning: izinler hassas olabilir, ancak operasyonel karmaşıklık yüksektir ve yeni tablo/özellik eklerken hatalar yapmak kolaydır.

Paylaşılan tablo (paylaşılan şema)

Tüm kiracılar aynı tabloları paylaşır; ayırt edici sütun genellikle tenant_id'dir.

İzolasyon sınırı: sorgu ve erişim kontrol katmanınız (genellikle satır düzeyinde güvenlik). Bu model operasyonel olarak verimli—tek şema migrate edilir, tek indeks stratejisi yönetilir—ancak veritabanı güvenliği ve performans izolasyonu açısından en zorlu olanıdır.

Güvenlik ve tuning: doğru yapmak en zor olanıdır çünkü her sorgunun kiracı farkındalığı olmalıdır; aksi halde gürültülü komşu problemi daha olasıdır ve kaynak sınırlama ile dikkatli indeksleme gerekir.

Yararlı bir kural: ne kadar çok paylaşırsanız, yükseltmeler o kadar basitleşir—ama kiracı izolasyonu ve performans izolasyonu kontrollerinde o kadar titiz olmanız gerekir.

Çok Kiracılılık Güvenlik Modelini Nasıl Değiştirir

Çok kiracılılık yalnızca "birden çok müşteri tek veritabanında" demek değildir. Tehdit modelinizi değiştirir: en büyük risk dışarıdan atlamalar yerine yetkili kullanıcıların kazara (veya kasıtlı) başka bir kiracının verisini görmesidir.

Kimlik doğrulama vs yetkilendirme: kiracı bağlamı bir yetkilendirme kararıdır

Kimlik doğrulama "sen kimsin?" cevabını verir. Yetkilendirme "neyi erişebilirsin?" sorusunu cevaplar. Çok kiracılı bir veritabanında kiracı bağlamı (tenant_id, account_id, org_id) yetkilendirme sırasında zorunlu olarak uygulanmalıdır—opsiyonel bir filtre gibi görülmemelidir.

Yaygın hata, bir kullanıcı kimlik doğrulandıktan sonra uygulamanın doğal olarak sorguları ayıracağını varsaymaktır. Pratikte ayrım açık ve tutarlı bir kontrol noktasında uygulanmalıdır (ör. veritabanı politikaları veya zorunlu sorgu katmanı).

Temel kural: her okuma ve yazma kiracıya göre sınırlandırılmalıdır

En basit ve en önemli kural: her SELECT, UPDATE ve DELETE tam olarak bir kiracıya göre sınırlandırılmalıdır.

Bu şunları kapsar:

• Sayfa listelemeleri ve dışa aktarmalar dahil SELECT'ler
• UPDATE/DELETE işlemleri
• Arka plan işleri ve ETL script'leri
• Yönetici araçları ve destek iş akışları

Kiracı kapsamı opsiyonelse, eninde sonunda atlanacaktır.

Çapraz-kiracı erişimine neden olan yaygın hata modları

Çapraz-kiracı sızıntıları genellikle küçük, rutin hatalardan kaynaklanır:

• Bir uç noktada veya kod yolunda eksik kiracı filtreleri
• Bir tablonun scope'lu olduğu ama JOIN yapılan tablonun olmadığı "kırık" JOIN'ler
• Sadece kullanıcı veya URL ile anahtarlanmış ancak kiracı ile anahtarlanmamış önbelleklenen cevaplar
• Yanlış tenant_id bağlayan yeniden kullanılan prepared statement'lar

Neden "testlerde çalışıyor" üretimde hâlâ sızıntıya neden olabilir

Testler genellikle küçük veri setleri ve temiz varsayımlarla çalışır. Üretim, eşzamanlılık, retry'ler, önbellekler, karışık kiracı verisi ve gerçek kenar durumları ekler.

Bir özellik testleri geçebilir çünkü test veritabanında yalnızca bir kiracı vardır veya fixture'lar kiracılar arasında çakışan ID'leri içermez. En güvenli tasarımlar, yanlışlıkla kapsam dışı bir sorgu yazmayı zorlaştıran yapılardır; her seferinde gözden geçirilmesine güvenmek yerine bunun yazılmasını güçleştirin.

Çapraz-Kiracı Veri Erişimini Engelleyen İzolasyon Kontrolleri

Çok kiracılı bir veritabanındaki temel güvenlik riski basittir: sorguda kiracı filtresini unutmak başka birinin verisini açığa çıkarabilir. Güçlü izolasyon kontrolleri hataların olacağını varsayar ve bu hataları zararsız hâle getirir.

Kiracı tanımlayıcıları ve sıkı kapsam desenleri

Her kiracıya ait kayıt bir kiracı tanımlayıcı (tenant_id gibi) taşımalıdır ve erişim katmanınız okuma/yazma işlemlerini her zaman bununla sınırlandırmalıdır.

Pratik bir desen "önce kiracı bağlamı": uygulama kiracıyı (alt alan, org ID veya token beyanlarından) çözer, istek bağlamında saklar ve veri erişim kodunuz bu bağlam olmadan çalışmayı reddeder.

Yardımcı korumalar:

• Uygun yerlerde birincil/benzersiz anahtarlar içinde tenant_id zorunlu kılın (kiracılar arası çakışmayı önlemek için).
• Yabancı anahtarları tenant_id içerecek şekilde ekleyin, böylece çapraz-kiracı ilişkileri kazara oluşturulamaz.

Satır düzeyinde güvenlik (RLS) ve politika tabanlı erişim

Desteklendiği yerlerde (özellikle PostgreSQL), satır düzeyinde güvenlik kiracı kontrollerini veritabanına taşıyabilir. Politikalar her SELECT/UPDATE/DELETE'i yalnızca o anki kiracıyla eşleşen satırlara kısıtlayabilir.

Bu, "her geliştirici WHERE koşulunu hatırladı" bağımlılığını azaltır ve bazı enjeksiyon veya ORM yanlış kullanımı senaryolarına karşı koruma sağlayabilir. RLS'i tek kilit olarak değil, ek bir kilit olarak değerlendirin.

Şema/veritabanı ayrımı bir izolasyon aracı olarak

Kiracılar daha hassas veya sıkı uyumluluk ihtiyaçlarına sahipse, şema veya veritabanı bazında ayırma patlama alanını azaltabilir. Takas, artan operasyonel yük ve karmaşıklıktır.

Güvenli varsayılanlar: varsayılan olarak reddet ve en az ayrıcalık

İzinleri "erişim yok" olacak şekilde tasarlayın:

• Uygulama rolleri yalnızca ihtiyaç duydukları tablo erişimine sahip olsun.
• Yönetici iş akışları ayrı hesaplar ve denetlenmiş yükseltme kullanmalı.
• Uygulama kodunda paylaşılan "superuser" bağlantılarından kaçının.

Bu kontroller birlikte en iyi şekilde çalışır: güçlü kiracı kapsamı, mümkünse veritabanı tarafından zorlanan politikalar ve bir şey kaydığında zararı sınırlayan muhafazakar ayrıcalıklar.

Paylaşılan Depolarda Şifreleme ve Anahtar Yönetimi

Şifreleme, diğer izolasyon katmanları başarısız olsa bile yardımcı olan birkaç kontrolden biridir. Paylaşılan bir depoda amaç, veriyi taşınırken, beklerken ve uygulamanın hangi kiracı adına hareket ettiğini kanıtlaması sırasında korumaktır.

Taşınma ve dinlenme sırasında şifreleme

Taşınan veri için her adımda TLS zorunlu kılın: istemci → API, API → veritabanı ve iç servis çağrıları. Mümkünse veritabanı seviyesinde bunu zorlayın (örneğin TLS olmayan bağlantıları reddetmek) ki "geçici istisnalar" sessizce kalıcı olmasın.

Dinlenme verisi için veritabanı veya depolama seviyesinde şifreleme kullanın (yönetilen disk şifreleme, TDE, şifreli yedekler). Bu, kaybolan ortam, snapshot açıklığı ve bazı altyapı ihlali sınıflarına karşı korur—ama hatalı bir sorgunun başka bir kiracının satırlarını döndürmesini engellemez.

Paylaşılan anahtarlar vs kiracı başına anahtarlar

Tek bir paylaşılan şifreleme anahtarı işletilmesi daha basit olan yaklaşımdır (daha az anahtar döndürme, daha az hata modu). Dezavantajı patlama alanıdır: anahtar açığa çıkarsa tüm kiracılar etkilenir.

Kiracı başına anahtarlar patlama alanını azaltır ve bazı kurumsal müşterilerin gereksinimlerini karşılamaya yardımcı olur. Ancak karmaşıklık artar: anahtar yaşam döngüsü yönetimi, döndürme takvimleri ve destek iş akışları (ör. kiracı anahtarı devre dışı bırakırsa ne olur) gerekir.

Pratik bir orta yol, per-kiracı veri anahtarlarını şifrelemek için bir master anahtarın kullanıldığı zarflama (envelope encryption) yöntemidir; bu döndürmeyi yönetilebilir kılar.

Veritabanı kimlik bilgileri için sır yönetimi

Veritabanı kimlik bilgilerini uzun ömürlü yapılandırmalardaki ortam değişkenlerinde saklamak yerine bir sır yöneticisinde saklayın. Kısa ömürlü kimlik bilgileri veya otomatik döndürme tercih edin ve erişimi servis rolüne göre sınırlandırın ki bir bileşenin ele geçirilmesi otomatik olarak her veritabanına erişim sağlamasın.

Token ve oturum yönetimi: sahtesi yapılmış kiracı bağlamını önleme

Kiracı kimliğini güvenlik açısından kritik kabul edin. İstemciden gelen ham tenant_id değerini “doğru” olarak kabul etmeyin. Kiracı bağlamını imzalı token'lara ve sunucu tarafı yetkilendirme kontrollerine bağlayın ve her istekte veritabanı çağrısından önce doğrulayın.

Denetim, İzleme ve Olay Hazırlığı

Çok kiracılılık "normal"in ne olduğunu değiştirir. Sadece bir veritabanını izlemiyorsunuz—aynı sistemi paylaşan birçok kiracıyı izliyorsunuz; bir hata çapraz-kiracı açıklamaya dönüşebilir. İyi denetim ve izleme hem olay olasılığını hem de patlama alanını azaltır.

Denetim günlükleri: tam hikâyeyi kaydedin

En azından, kiracı verisini okuyabilecek, değiştirebilecek veya erişim verebilecek her eylemi kaydedin. En faydalı denetim olayları şunları yanıtlar:

• Kim: kullanıcı/servis kimliği, kimlik doğrulama yöntemi, rol, kaynak IP/cihaz
• Ne: işlem (SELECT/UPDATE/DELETE), etkilenen nesneler, sorgu sınıfı (tam SQL gerekli değil), yetkili değişiklikler için öncesi/sonrası
• Ne zaman: zaman dilimiyle birlikte zaman damgası, korelasyon için istek/iz ID'si
• Kiracı: kiracı ID'si birinci sınıf alan olarak (sonradan türetilmemeli)

Ayrıca yönetici eylemlerini kaydedin: kiracı oluşturma, izolasyon politikalarını değiştirme, RLS kuralı düzenleme, anahtar döndürme ve bağlantı dizesi değişiklikleri.

Çapraz-kiracı ve ayrıcalık anormallikleri için uyarılar

İzleme, sağlıklı SaaS kullanımında beklenmeyen desenleri tespit etmelidir:

• Birden fazla tenant ID için satır döndüren sorgular veya "tenant uyuşmazlığı" reddi sayısında ani artışlar
• Bir servis hesabının normalde erişmediği bir kiracıya erişim
• Hızlı rol/izin değişiklikleri, yeni yöneticiler, devre dışı bırakılmış güvenlik politikaları veya RLS atlama denemeleri

Uyarıları eyleme geçirilebilir çalışma kitapçıklarıyla bağlayın: ne kontrol edilmeli, nasıl izole edilmeli ve kimi çağırmalı.

Yönetici kontrolleri ve acil durum (break-glass) prosedürleri

Ayrıcalıklı erişimi bir üretim değişikliği gibi ele alın. En az ayrıcalık rolleri, kısa ömürlü kimlik bilgileri ve hassas operasyonlar (şema değişiklikleri, veri dışa aktarma, politika düzenleme) için onay süreçleri kullanın. Acil durum için bir break-glass hesabı tutun: ayrı kimlik bilgileri, zorunlu bilet/onay, zaman sınırlı erişim ve ekstra günlükleme.

Saklama ve kiracıya göre sınırlandırılmış günlük erişimi

Saklama süresini uyumluluk ve soruşturma ihtiyaçlarına göre ayarlayın, ama erişimi öyle sınırlandırın ki destek personeli sadece kendi kiracısının günlüklerini görebilsin. Müşteri denetim dışa aktarma talep ettiğinde, ham paylaşılan günlükler yerine kiracı filtreli raporlar sağlayın.

Performans Temelleri ve Gürültülü Komşu Problemi

Çok kiracılılık, birçok müşterinin aynı veritabanı altyapısını paylaşmasına izin vererek verimliliği artırır. Takası, performansın da paylaşılan bir deneyim hâline gelmesidir: bir kiracı ne yaparsa yapsın diğerlerini etkileyebilir, veriler tamamen izole olsa bile.

"Gürültülü komşu" problemi (düz Türkçeyle)

"Gürültülü komşu", bir kiracının aktivitesinin o kadar yoğun (veya dalgalı) olmasıdır ki paylaşılan kaynakların adil payını tüketir. Veritabanı "bozulmuş" değildir—sadece o kiracının işini yürütmekle meşguldür, bu yüzden diğerleri daha uzun bekler.

Bir apartmanda ortak su basıncı gibi düşünün: bir birim birden fazla duşu ve çamaşır makinesini aynı anda çalıştırırsa diğerleri zayıf su akışı hisseder.

Gerçekte neler paylaşılıyor?

Her kiracı ayrı satırlar veya şemalar kullansa bile birçok performans-kritik bileşen paylaşılır:

• CPU: sorgu yürütme, sıralama, join'ler, şifreleme/çözme, arka plan bakım
• Bellek: buffer/cache sayfaları, sorgu çalışma belleği, iç kuyruklar
• Disk / I/O: veri dosyalarını okuma, log yazma, checkpoint flush'ları, compaction/vacuum
• Bağlantılar: veritabanı bağlantı limitleri ve thread pool'lar
• Önbellekler: plan cache, buffer cache ve bazen uygulama tarafı önbellekleri

Bu ortak havuzlar dolduğunda gecikme herkes için artar.

Patlama yapan iş yükleri neden diğer kiracıları etkiler

Birçok SaaS iş yükü ani patlamalarla gelir: bir içe aktarma, ay sonu raporları, pazarlama kampanyası, saat başında çalışan cron işi.

Patlamalar veritabanı içinde "trafik sıkışıklığı" yaratabilir:

• Bir kiracı aynı anda birçok pahalı sorgu başlatır, CPU %100'e çıkar.
• Büyük yazmalar ekstra I/O tetikler (log yazma, indeks bakımı), diğerlerinin okumasını yavaşlatır.
• Bağlantı dalgalanmaları havuzu doldurur, diğer kiracılar slot bulamaz.

Patlama sadece birkaç dakika sürse bile, kuyrukların boşalması gecikmelere neden olabilir.

Kullanıcılar tipik olarak ne fark eder

Müşteri açısından gürültülü komşu sorunları rastgele ve haksızmış gibi hissedilir. Yaygın belirtiler:

• Giriş, arama, ödeme veya raporlama sırasında zaman aşımı
• Özellikle liste görünütleri ve panellerde yavaş sayfalar
• Tutarsız hız (10:05'te hızlı, 10:10'da yavaş, 10:20'de tekrar hızlı)
• Arka plan işlerindeki gecikmeler (dışa aktarmalar, webhook'lar gecikiyor)

Bu semptomlar, yalnızca daha fazla donanım eklemek yerine performans izolasyonu tekniklerine ihtiyaç duyduğunuzun erken uyarıcılarıdır.

Kaynak İzolasyonu ve Sınırlama Teknikleri

Çok kiracılılık, bir müşterinin veritabanı kapasitesinin adil payından fazlasını alamayacağı gardrails olduğunda en iyi şekilde çalışır. Kaynak izolasyonu, ağır bir kiracının herkesi yavaşlatmasını engelleyen koruyuculardır.

Bağlantı havuzu limitleri ve kiracı başına kotalar

Sık görülen hata, sınırsız bağlantılardır: bir kiracı trafiği aniden yüzlerce oturum açar ve veritabanını tüketir.

İki yerde sert sınırlar koyun:

• Uygulama havuzunda: servis örneği başına maksimum bağlantıları sınırlayın ve arka plan işler için minimum rezervasyon ayırın.
• Kiracı bazında: planlardan türeyen "N eşzamanlı istek" veya "M eşzamanlı DB oturumu" gibi kotalar uygulayın.

Veritabanınız doğrudan "kiracı başına bağlantı" uygulayamıyorsa, her kiracıyı ayrılmış bir havuz veya havuz bölümü üzerinden yönlendirerek yaklaşık bir çözüm sunabilirsiniz.

Hız sınırlama ve iş yükü şekillendirme (uygulama + DB)

Hız sınırlama, zaman içinde adalettir. Bunu kenara (API gateway/uygulama) yakın uygulayın ve destekleniyorsa veritabanı içinde de (resource groups/workload management) uygulayın.

Örnekler:

• Pahalı uç noktalar için kiracı başına token-bucket limitleri (dışa aktarmalar, arama)
• İnteraktif isteklerin batch işlere göre öncelik kazanması için öncelik katmanları
• Patlamaları dümdüz veritabanına göndermek yerine yumuşatmak için kuyruk tabanlı şekillendirme

Sorgu zaman aşımı, ifade limitleri ve devre kesiciler

Veritabanını "kaçan" sorgulardan koruyun:

• Uzun taramaları durdurmak için sorgu/zaman aşımı
• Patlayabilecek uç noktalar için maksimum satır/byte döndürme
• Hata oranı veya gecikme eşiklerini aşınca bir kiracının pahalı özelliğini geçici engelleyen devre kesiciler

Bu kontroller nazikçe başarısız olmalı: net bir hata döndürüp yeniden deneme/geri çekilme önermelidir.

İçerik yoğun okumaları azaltmak için replikalar ve önbellekleme

Okuma ağırlıklı trafiği primery'den uzaklaştırın:

• Dashboard, raporlama ve analitik tarzı sorgular için okuma replikaları
• Tekrarlanan lookuplar ve yapılandırma verileri için önbellekleme (kiracı bazlı anahtarlar, kısa TTL)

Amaç yalnızca hız değil—kilit baskısını ve CPU rekabetini azaltarak gürültülü kiracıların başkalarını etkileme yollarını daraltmaktır.

Hız Etkileyen Veri Modelleme Seçimleri

Çok kiracılı performans sorunları genelde "veritabanı yavaş" gibi görünür, ama kök neden genellikle veri modeli: kiracı verisinin nasıl anahtarladığı, filtrelendiği, indekslendiği ve fiziksel olarak düzenlendiğidir. İyi modelleme kiracıya göre sorguları doğal olarak hızlı yapar; kötü modelleme veritabanını gereksiz yere zorlar.

Kiracıya göre sorgular için indeksleme

Çoğu SaaS sorgusu bir kiracı tanımlayıcısı içermelidir. Bunu açık modelleyin (örneğin tenant_id) ve indeksleri bununla başlayacak şekilde tasarlayın. Pratikte (tenant_id, created_at) veya (tenant_id, status) gibi bileşik indeksler, sadece created_at veya status üzerinde indekslemeden çok daha faydalıdır.

Ayrıca benzersizlik için: eğer e-postalar sadece kiracı bazında benzersizse, bunu global email yerine (tenant_id, email) ile zorlayın.

Tam tablo taramalarından kaçınma (eksik kiracı filtreleri)

Yavaş sorgu örüntülerinden biri kazara çapraz-kiracı taramasıdır: kiracı filtresi unutulur ve büyük bir kısmı taranır.

Güvenli yolu kolay yol yapın:

• Sorgu katmanınızda kiracı filtrelerini zorunlu kılın (ORM scope'ları, repository metotları)
• Mümkünse veritabanı korumaları kullanın (varsayılan kiracı görünümleri veya politikalar) ki kapsam dışı erişim hızlıca başarısız olsun

Partitioning ve sharding: kiracıya veya zamana göre

Partitioning, her sorgunun bakması gereken veri miktarını azaltabilir. Kiracılar büyük ve dengesizse tenant bazlı partition düşünün. Erişim çoğunlukla güncelse zamana göre partitioning tercih edin; her partition içinde tenant_id lider kolon olarak indekslenebilir.

Tek bir veritabanı peak throughput'u karşılayamıyorsa veya bir kiracının iş yükü herkesi tehdit ediyorsa sharding düşünün.

Sıcak (hot) kiracıları yönetme

"Hot kiracılar" orantısız okuma/yazma hacmi, kilit çatışması veya aşırı büyük indekslerle ortaya çıkar.

Bunları kiracı başına sorgu süresi, okunan satır sayısı ve yazma oranını izleyerek tespit edin. Bir kiracı baskınsa onları izole edin: ayrı bir shard/veritabanına taşıyın, büyük tabloları kiracı bazında bölün veya diğer kiracıların hızını korumak için özel önbellekler ve oran sınırlamaları ekleyin.

Hem Güvenliği Hem Performansı Koruyan Operasyonel Uygulamalar

Çok kiracılılık genelde veritabanının bunu yapamamasından değil, günlük operasyonların küçük tutarsızlıklara izin vermesinden başarısız olur. Amaç, her değişiklikte, işte ve deploy'da güvenli yolu varsayılan hâle getirmektir.

Kiracı anahtarını standartlaştırın (ve her yerde zorlayın)

Tek bir canonical kiracı tanımlayıcı seçin (ör. tenant_id) ve bunu tablolar, indeksler, günlükler ve API'lerde tutarlı şekilde kullanın. Tutarlılık hem güvenlik hatalarını (yanlış kiracı sorgulama) hem de performans sürprizlerini (doğru bileşik indekslerin eksikliği) azaltır.

Pratik korumalar:

• Tüm temel erişim yollarında (tenant_id zorunlu) gerektir
• Yaygın lookuplar için tenant_id ile başlayan bileşik indeksler ekleyin
• Mümkünse veritabanı kısıtları kullanın (yabancı anahtarlar tenant_id içerecek şekilde veya check constraint'ler) ki hatalı yazmalar erken yakalansın

Arka plan işlerinde kiracı karışmalarına karşı korunma

Async worker'lar genelde kiracı bağlamını isteği başlatan bağlamdan bağımsız yürüttükleri için çapraz-kiracı olaylarının kaynağıdır.

Yardımcı operasyonel desenler:

• Her iş yükü yükünde tenant_id'yi açıkça geçin; dolaylı bağlama güvenmeyin
• Idempotency anahtarlarında ve önbellek anahtarlarında kiracı anahtarını dahil edin
• İş başlangıç/bitirişinde ve her retry'de tenant_id kaydedin ki soruşturma kolay olsun

Migration'ları kiracı-dostu yapın

Şema ve veri migration'ları kusursuz, senkronize bir dağıtım olmadan deploy edilebilmelidir.

Rolling değişiklikleri kullanın:

• Genişlet/ daralt stratejisi (yeni kolon/indeks ekle, çift-yazma/okuma yap, sonra eski yolu kaldır)
• Uzun, engelleyici işlemlerden kaçının; backfill'leri kiracı bazında partiler halinde çalıştırarak yükü kontrol edin
• Her backfill sorgusunun kiracıya göre scoped ve oran sınırlı olduğundan emin olun ki kendi yarattığınız gürültülü komşu etkilerini önleyin

İzolasyon hataları için testler yazın—sadece mutlu yol testleri değil

Bilerek başka bir kiracının verisine erişmeyi deneyen otomatik negatif testler ekleyin. Bunları sürüm engelleyiciler olarak ele alın.

Örnekler:

• Tenant A'da bilinen bir kaydı Tenant B olarak kimlik doğruluyken almaya çalışın ve başarısız olduğunu doğrulayın
• Yanlış tenant_id ile arka plan işlerini çalıştırıp sert hata aldığını doğrulayın
• Her sorgu yardımcı fonksiyonu için regresyon testleri ekleyin ki kiracı kapsamı hep uygulansın

Yedekler, Geri Yükleme ve Kiracı Düzeyinde Veri Operasyonları

Yedekler "veritabanını kopyala" demek kolaydır ama çok kiracılı bir veritabanında güvenli şekilde uygulamak zor olabilir. Birçok müşteri tabloyu paylaştığında, tek bir kiracıyı nasıl kurtaracağınız konusunda bir planınız olmalıdır.

Yedek/geri yük stratejileri: tek kiracı vs herkes

Tam veritabanı yedeği hâlâ felaket kurtarma için temel teşkil eder, ama günlük destek vakaları için yeterli değildir. Yaygın yaklaşımlar:

• Tam yedekler + zaman noktasına geri döndürme (herkesi etkileyen olaylar için)
• Kiracıya özel dışa aktarmalar (tenant_id ile filtrelenmiş mantıksal dump'lar) tek bir kiracıyı kurtarmak için
• Kiracı başına ayrı depolama (mümkünse) geri yüklemeyi doğal olarak kiracıya sınırlar

Mantıksal dışa aktarmalara güveniyorsanız, dışa aktarma işini üretim kodu gibi ele alın: izolasyonu satır düzeyinde güvenlik veya benzeri mekanizmalarla zorlayın, tek bir WHERE koşuluna güvenmeyin.

Kiracı düzeyinde dışa aktarma/silme (gizlilik talepleri)

Gizlilik talepleri (dışa aktarma, silme) hem güvenlik hem performansı etkileyen işlerdir. Tekrarlanabilir, denetlenebilir iş akışları inşa edin:

• Tutarlı snapshot içinde kiracı verisini dışa aktarma
• Kiracı verisini orphan satır bırakmadan silme
• Tamamlama kanıtı için günlükler ve checksum'lar sağlama

Kazara çapraz-kiracı geri yüklemelerini önleme

En büyük risk bir hacker değil—aceleci bir operatördür. İnsan hatasını azaltmak için korumalar:

• Kiracı tanımlayıcısı artı ikincil doğrulama (kiracı adı, fatura ID'si) gerektirin
• İçe aktarma öncesi satır sayıları ve tenant_id dağılımını doğrulayın
• Önce karantina ortamına geri yükleyin, sonra üretime terfi ettirin

Felaket kurtarma tatbikatları ve sonrasında sınırların doğrulanması

Bir DR tatbikatından sonra sadece "uygulama açık" demeyin. Otomatik kontroller çalıştırın: kiracılar arası örnek sorgular, denetim günlüklerinin gözden geçirilmesi ve şifreleme anahtarlarının ve erişim rollerinin doğru scoped olduğunun doğrulanması.

Çok Kiracılılık Doğru Uygun Olmadığında

Çok kiracılılık genelde SaaS için iyi bir varsayımdır, ama kalıcı bir karar olmak zorunda değildir. Ürün ve müşteri karışımı değiştikçe, "tek paylaşılan depo" yaklaşımı iş riski veya teslimat hızını yavaşlatmaya başlayabilir.

İzolasyonu artırma sinyalleri

Daha izole yaklaşıma geçmeyi düşünün:

• Büyüme ve ölçek etkileri: birkaç kiracı trafik, depolama veya arka plan işleri açısından orantısız bir yük yaratıyor ve herkesi ayarlamak zorlaşıyorsa
• Uyumluluk ve sözleşmesel gereksinimler: müşteriler adanmış ortam, belirli bölgesel yerleşim kontrolleri, ayrı anahtar sahipliği veya paylaşılan modelinizin temizce sağlayamadığı daha sıkı denetim sınırları istiyorsa
• Özel desenlere sahip ağır kiracılar: büyük içe aktarmalar, raporlama patlamaları veya özel entegrasyonlar tekrarlayan çatışma yaratıyorsa

Maliyet ve karmaşıklığı paydaşlara açıklamak

Daha fazla izolasyon genelde daha yüksek altyapı gideri, daha fazla operasyonel yük (migration, izleme, on-call) ve daha fazla sürüm koordinasyonu anlamına gelir. Takas, daha net performans garantileri ve uyumluluk konuşmalarını kolaylaştırmaktır.

Sonraki adımlar

İzolasyon seçeneklerini değerlendiriyorsanız, ilgili rehberleri /blog'da inceleyin veya planlar ve dağıtım seçeneklerini /pricing üzerinde karşılaştırın.

Hızlıca bir SaaS prototipi oluşturup çok kiracılı varsayımlarınızı (kiracı kapsamı, RLS uyumlu şemalar, throttling ve operasyonel iş akışları) erken test etmek istiyorsanız, Koder.ai gibi bir platform sohbetten React + Go + PostgreSQL uygulaması oluşturmanıza, planlama modunda yinelemenize ve snapshot/rollback ile dağıtmanıza yardımcı olabilir—hazır olduğunuzda kaynak kodunu dışa aktarabilirsiniz.