Çok Kiracılı SaaS Mimarisi: Tek Kurulum, Çok Müşteri

Her müşteriye ayrı kurulum yapmak ilk bakışta en güvenli yoldur: veriler fiziksel olarak ayrıdır, biri diğerini göremez. Sorun ölçeklenmede başlar. Beş kurulumda bir güvenlik yaması beş kez uygulanır, elli kurulumda elli kez; üstelik her biri farklı sürümde kalmaya başlar. Bir süre sonra 'hangi müşteride hangi sürüm var' sorusunun cevabı bir tabloya dönüşür ve o tablo hep eskidir.

İkinci maliyet destek tarafındadır. Bir hata bildirimi geldiğinde önce hangi kurulumda olduğunu, o kurulumun hangi sürümde olduğunu ve o sürümde bu hatanın düzeltilip düzeltilmediğini bulmanız gerekir. Tek kurulumda bu üç sorunun hiçbiri yoktur. Çok kiracılı mimariye geçmenin asıl gerekçesi teknik zarafet değil, işletim maliyetidir.

Ayrı kurulumun hâlâ doğru olduğu durumlar var: verinin kurum dışına çıkamadığı sözleşmeler, ağ düzeyinde yalıtım gerektiren sektörler ve devasa tek müşteriler. Bu yüzden ürünlerimizi hem çok kiracılı bulut hem de kurum içi tek kurulum olarak sunuyoruz — ama ikisi aynı çekirdek, ayrı çatal değil.

Çok kiracılı bir sistemin ilk kararı, gelen isteğin hangi kiracıya ait olduğunun nasıl anlaşılacağıdır. Üç yaygın yol var: alan adından, adres yolundan ya da kullanıcının oturumundan. Üçü de çalışır ve seçim ürünün doğasına bağlıdır — müşteri kendi markasıyla görünmek istiyorsa alan adı, iç kullanıma yönelik bir panel ise oturum bilgisi daha uygundur.

İçerik platformumuzda alan adını seçtik: gelen adres kayıtlı alan adlarıyla eşleştiriliyor ve o sitenin teması, dilleri ve içeriği yükleniyor. Tema bile çalışma anında seçildiği için yeni bir müşteri açmak yeni bir dağıtım gerektirmiyor. İşletme ürünümüzde ise kiracı kullanıcının oturumundan geliyor ve üstüne bir hiyerarşi biniyor: organizasyon, marka, şube.

Hangi yolu seçerseniz seçin, kritik nokta bu bilginin zincir boyunca korunmasıdır. Araya giren bir katman adresi kendi adıyla değiştirirse sistem yanlış kiracıyı açar ve bu bir hata gibi görünmez: sayfa açılır, sadece yanlış içerik gelir. Bu yüzden 'tanımadığım kiracı' durumunun sessiz bir varsayılana düşmesi değil, kayda geçmesi gerekir.

Başlangıçta kiracı denince akla tek bir müşteri gelir; gerçek hayatta ise müşterinin kendi içinde katmanları olur. Bir restoran zincirinin markaları, her markanın şubeleri vardır; bir holdingin şirketleri, şirketlerin bölümleri. Veri modelini tek seviye kiracı üzerine kurarsanız, ikinci şube geldiğinde ya yeni bir kiracı açarsınız — ve raporları birleştiremezsiniz — ya da modeli değiştirirsiniz.

Biz işletme ürünümüzde üç seviyeli bir hiyerarşi kullanıyoruz: organizasyon, marka, şube. Kayıtlar en alt seviyeye bağlanır, yetkiler herhangi bir seviyeye verilebilir ve raporlar yukarı doğru toplanır. Tek şubeli bir işletme için bu fazladan karmaşıklık gibi görünür ama görünmez: kullanıcı yalnız kendi şubesini görür, hiyerarşi arka planda durur.

Hiyerarşi kararı sonradan değiştirmesi en pahalı kararlardan biridir, çünkü her tabloyu ve her sorguyu etkiler. Bu yüzden ilk sürümde bile 'bu müşterinin ikinci bir şubesi olursa ne olur' sorusunu sormak gerekir. Cevap 'olmaz' ise tek seviye yeterlidir; 'olabilir' ise hiyerarşi baştan kurulmalıdır.

Çok kiracılı bir sistemde en kritik güvenlik özelliği, bir kiracının verisinin başka bir kiracıya asla görünmemesidir. Bunu tek bir yerde çözmeye çalışmak — örneğin yalnız uygulama katmanında filtre koymak — en yaygın hatadır; çünkü tek bir unutulmuş sorgu bütün korumayı geçersiz kılar. İzolasyon katmanlı kurulmalıdır: veritabanı seviyesinde satır güvenliği, uygulama seviyesinde zorunlu kiracı kısıtı ve liste bileşenlerinde otomatik süzgeç.

Bu üç katmanın üçüncüsü bizde sonradan eklendi ve ekleme sebebi somut: bir denetimde, liste bileşeninin kiracı süzgecini otomatik uygulamadığı ve belirli bir uçta başka kurumun verisinin görünebildiği tespit edildi. Kod yanlış yazılmamıştı; yalnız bir yerde filtre eklenmesi unutulmuştu. Sistemik açık buydu: koruma, geliştiricinin hatırlamasına bağlıydı.

Buradan çıkan ilke şu: güvenlik, hatırlanması gereken bir şey olmamalı. Kiracı süzgeci varsayılan davranış hâline getirildiğinde, unutmak mümkün olmaz — aksini yapmak için bilinçli bir çaba gerekir. Veritabanı seviyesindeki satır güvenliği de aynı mantıkla ikinci bir ağdır: uygulama hata yapsa bile veritabanı yanlış satırı döndürmez.

İzolasyon testi, olumsuz senaryo testidir: doğru kullanıcının doğru veriyi görmesi değil, yanlış kullanıcının yanlış veriyi görememesi denenir. Pratik yöntem, iki kiracıyla test verisi kurmak ve birinin oturumuyla diğerinin kayıtlarına ulaşmayı denemektir — hem arayüzden hem doğrudan uçlardan. Arayüz genellikle temizdir; sızıntılar uç seviyesinde olur.

Bu testi bir kez yapıp geçmek yetmez; yeni her uç için tekrarlanmalıdır. Bunu insan disiplinine bırakmak yerine otomatik teste bağlamak en sağlıklısı: her uç için 'başka kiracının kimliğiyle çağır, boş dönmeli' biçiminde bir test, bir kez yazılır ve her değişiklikte çalışır. Güvenliğin en ucuz hâli, otomatik olanıdır.

Çok kiracılı bir üründe her müşteri bir şeyin farklı olmasını ister ve bu istekler makuldür. Sınırı çizmezseniz ürün, kod içinde 'eğer müşteri X ise' kontrolleriyle dolar ve bir süre sonra kimse hangi müşteride ne olduğunu bilemez. Doğru yaklaşım, farklılıkları koda değil yapılandırmaya taşımaktır: açılıp kapanabilen modüller, kiracı bazlı ayarlar, değiştirilebilir metinler ve tema.

Bizim ürünlerimizde bu üç biçimde karşılık buluyor. İşletme ürününde modüller şube bazında açılıyor — kullanmayan ödemiyor, görmüyor. İçerik platformunda her kiracı kendi temasını, dillerini ve dört yüzden fazla arayüz metnini kendi kelimeleriyle değiştirebiliyor. Her iki durumda da çekirdek tek; değişen yalnız yapılandırma.

Yapılandırmayla çözülemeyen gerçek bir fark çıktığında karar netleşir: ya bu ihtiyaç ürünün geneline mal edilir ve herkese açık bir özellik olur, ya da o müşteri için ayrı bir modül yazılır. Üçüncü seçenek — çekirdeğe müşteriye özel bir istisna gömmek — kısa vadede en kolay, uzun vadede en pahalı olandır.

Çok kiracılı bir sistemde veriyi ayırmanın üç yolu vardır: hepsi tek veritabanında ve satırlar kiracı kimliğiyle ayrışır; her kiracıya ayrı şema; her kiracıya ayrı veritabanı. Üçü de gerçek seçeneklerdir ve seçim, müşteri sayısı ile izolasyon ihtiyacının kesişiminde yapılır. Yüzlerce küçük müşteriyle çalışıyorsanız ortak tablo tek makul yoldur; on büyük kurumla çalışıyorsanız ayrı şema mantıklı olabilir.

Ortak tablonun avantajı işletimdir: tek şema, tek göç, tek yedek, tek izleme. Dezavantajı, izolasyonun tamamen yazılıma bağlı olmasıdır — bu yüzden veritabanı seviyesinde satır güvenliği bir lüks değil, ikinci ağdır. Ayrı şema yaklaşımında izolasyon daha güçlüdür ama her şema değişikliği kiracı sayısı kadar tekrarlanır ve göç günleri uzar.

Biz ortak veritabanını seçtik ve izolasyonu katmanlarla güçlendirdik. Karar noktası şuydu: müşteri sayımızın artmasını bekliyoruz ve her yeni müşterinin işletim maliyetinin sıfıra yakın olması gerekiyor. Buna karşılık, verinin kurum dışına çıkamadığı müşteriler için tamamen ayrı kurulum sunuyoruz — yani üçüncü yolu bir ürün seçeneği olarak tutuyoruz.

Ortak veritabanında yedekleme kolay, geri yükleme zordur. Bütün sistemi dünkü hâline döndürmek teknik olarak basittir ama bunu tek bir müşterinin hatası için yapamazsınız — diğer kiracıların bir günlük verisini silmiş olursunuz. Bu yüzden çok kiracılı bir üründe 'tek kiracıyı geri yükleme' ayrı bir yetenek olarak tasarlanmalıdır.

Pratik çözüm iki katmanlıdır. Birincisi, silmenin gerçekten silme olmaması: kayıtlar işaretlenerek pasifleştirilir, belirli bir süre sonra fiziksel olarak temizlenir. Bu, kullanıcı hatalarının büyük çoğunluğunu yedek gerektirmeden çözer. İkincisi, yedekten yalnız o kiracının satırlarını çıkarıp geri yazabilen bir araç — bunu ihtiyaç doğduğunda yazmaya çalışmak, en kötü zamanda yazmaktır.

Bir müşteri ayrıldığında ne olacağı, ürünün ilk gününde tasarlanması gereken bir akıştır. Üç soru cevaplanmalı: veri hangi biçimde dışarı verilecek, ne kadar süre saklanacak, sonra nasıl silinecek? Bunu sözleşmeye yazmak yetmez; ürünün içinde çalışan bir mekanizma olması gerekir, aksi hâlde her ayrılık elle müdahaleye dönüşür.

Silme tarafında en sık yapılan hata, kaydı silip izleri bırakmaktır: yedeklerde, günlüklerde, önbelleklerde ve rapor tablolarında aynı veri durmaya devam eder. Gerçek bir silme politikası bu yerlerin hepsini kapsamalı ve süresi tanımlı olmalıdır. Müşteri 'verimi silin' dediğinde verilecek cevabın net olması gerekir.

Bu akışın ticari faydası da var: çıkışın kolay olduğunu bilen müşteri, girişte daha rahat karar verir. Veri dışa aktarımını bir 'özellik' değil temel yetenek olarak tutmamızın sebebi bu — müşteriyi tutan şey kilitlenmiş olması değil, memnun olması olmalı.

Tek kurulum, bakım maliyetini düşürürken riski yoğunlaştırır: bir hata artık bir müşteriyi değil hepsini etkiler. Bu yüzden çok kiracılı bir üründe yayın süreci, tek müşterili bir üründekinden daha disiplinli olmak zorundadır — kademeli yayın, geri dönüş planı ve yayın sonrası izleme burada isteğe bağlı değildir.

Aynı yoğunlaşma performansta da geçerli. Bir kiracının ağır bir raporu, aynı kaynakları paylaşan diğer kiracıları yavaşlatabilir. Bunun önüne geçmek için ağır işleri ayrı bir sıraya almak, sorguları kiracı bazında sınırlamak ve yavaş uçları izlemek gerekir. 'Sistem bugün yavaş' şikâyetinin arkasında sıklıkla tek bir kiracının olağandışı bir işlemi vardır.

Çok kiracılı mimari, aynı ürünü çok müşteriye ulaştırmanın en ekonomik yoludur ama bedeli disiplindir: kiracı bilgisinin zincir boyunca korunması, hiyerarşinin baştan doğru kurulması, izolasyonun tek değil üç katmanla sağlanması, olumsuz senaryoların otomatik test edilmesi ve farklılıkların koda değil yapılandırmaya taşınması.

Bu ilkelerin hepsini kendi ürünlerimizde uyguluyoruz ve bir tanesini zor yoldan öğrendik: koruma, geliştiricinin hatırlamasına bağlı olduğu sürece eksiktir. Çok müşteriye açılacak bir ürün planlıyorsanız, izolasyon tasarımını ilk günden konuşmak en ucuz yoldur.