Multi-tenant SaaS'ta kiracı izolasyonu
Çok kiracılı (multi-tenant) bir SaaS uygulamasında birden fazla müşteri (kiracı) aynı uygulamayı ve çoğu zaman aynı veritabanını kullanır. Bu mimarinin tek bir vazgeçilmez kuralı vardır: bir kiracının verisi, başka bir kiracıya asla görünmemelidir. AKS ERP'de kiracı izolasyonu ve idempotency denetimlerini yürütürken öğrendiklerimi bu yazıda topladım.
Üç izolasyon modeli
| Model | Nasıl | Artı | Eksi |
|---|---|---|---|
| Ayrı veritabanı | Her kiracıya ayrı veritabanı | En güçlü izolasyon | Yönetim ve maliyet yükü |
| Ayrı şema | Aynı veritabanında kiracı başına şema | İyi izolasyon | Migrasyonlar karmaşıklaşır |
| Paylaşılan tablo | Her satırda tenant_id | Basit, ölçeklenir | İzolasyon uygulama disiplinine bağlı |
Çoğu SaaS paylaşılan tablo modeliyle başlar. Bu modelde izolasyonun güvencesi, her sorgunun doğru tenant_id ile filtrelenmesidir; ve tek bir unutulmuş filtre, veri sızıntısı demektir.
Filtreyi unutulamaz kılmak
İzolasyonu her geliştiricinin dikkatine bırakmak yerine, unutulamaz hâle getirmek gerekir:
- Satır seviyesinde güvenlik (RLS): PostgreSQL'de her tabloya kiracı politikası tanımlanır; veritabanı, oturumdaki kiracıya ait olmayan satırları sorgu ne derse desin döndürmez.
- Kiracı bağlamı tek yerden: kiracı kimliği istekten bir kez çözülür ve veri erişim katmanına otomatik geçirilir; sorgu yazan kişi onu elle eklemez.
- Varsayılan kapalı: kiracı bağlamı olmayan bir sorgu hata vermelidir, bütün satırları döndürmemelidir.
İzolasyonu kanıtlamak
"İzolasyon var" demek yetmez; kanıtlanmalıdır. İşe yarayan yöntemler:
- Çapraz kiracı testleri: A kiracısı olarak oturum açıp B kiracısının kayıtlarına her uç noktadan erişmeye çalışan otomatik testler. Hepsinin reddedilmesi beklenir.
- Sorgu denetimi: kiracı filtresi olmayan sorguları CI'da yakalayan statik kontroller.
- Kanıt raporu: hangi uç noktanın, hangi senaryoyla, hangi sonuçla test edildiğini gösteren yazılı bir rapor. Denetimde "test ettik" demek yerine sonucu göstermek güven verir.
İzolasyon yalnızca okuma için değil, yazma için de geçerlidir: A kiracısının bir isteği, B kiracısının kaydını güncelleyememeli ya da ona bağlı bir kayıt oluşturamamalıdır. Tekrar gelen isteklerin çift kayıt oluşturmaması da aynı disiplinin parçasıdır; bunu idempotency yazısında anlattım.
Kiracı izolasyonu gibi kararlar, bir mimari karar kaydına (ADR) değer; nasıl yazıldığını ADR yazısında anlattım.