Bir SaaS ürününe abone olduğunuzda ilginç bir şey olur: sisteme kendi adresinizden girersiniz, kendi logonuzu, kendi müşterilerinizi, kendi verilerinizi görürsünüz. Sanki yazılım yalnızca sizin için kurulmuş gibidir. Oysa perde arkasında aynı yazılım, aynı sunucularda, sizinle birlikte yüzlerce başka işletmeye daha hizmet vermektedir. Bu sihrin adı multi-tenant, Türkçesiyle çok kiracılı mimaridir ve modern SaaS mimarisinin temel taşıdır.
Bu yazıda multi-tenant mimariyi teknik olmayan okuyucunun da rahatça izleyebileceği bir dille anlatacağız: apartman benzetmesinden veri izolasyonuna, maliyet avantajından güvenlik önlemlerine. Konuyu masa başından değil, kendi geliştirdiğimiz ve canlıda işlettiğimiz çok kiracılı sistemlerin tecrübesiyle yazıyoruz; örnekler gerçek mimari kararlardan geliyor.
Apartman benzetmesi: tek bina, ayrı daireler
Multi-tenant mimariyi anlamanın en kolay yolu apartman benzetmesidir. Single-tenant, yani tek kiracılı model, her ailenin kendine ait müstakil ev yaptırmasına benzer: arsa, temel, çatı, tesisat; her şey her ev için ayrı ayrı inşa edilir ve ayrı ayrı bakılır. Multi-tenant model ise apartmandır: temel, çatı, asansör ve tesisat ortaktır; ama her dairenin kendi kapısı, kendi kilidi ve kendi özel yaşamı vardır. Komşunuzun dairesine giremezsiniz, o da sizinkine giremez.
Yazılım dünyasına çevirirsek: tek kiracılı modelde her müşteri için ayrı bir yazılım kopyası, ayrı veritabanı, ayrı sunucu kurulur. Çok kiracılı modelde ise tek bir yazılım ve altyapı, tüm müşterilere (kiracılara, yani tenant'lara) birlikte hizmet verir; her kiracının verisi mantıksal duvarlarla birbirinden yalıtılır. Kullanıcı deneyimi açısından fark yoktur: herkes yalnızca kendi dünyasını görür.
Bu tercihin sonuçları apartman ekonomisiyle aynıdır: ortak altyapının maliyeti tüm sakinlere bölünür, bakım tek elden yapılır, iyileştirmelerden herkes aynı anda yararlanır. Kurumsal sınıf bir yazılımın aylık makul bir abonelik bedeliyle sunulabilmesinin mühendislik sırrı, işte bu paylaşımdır.
Veri izolasyonu: sistemin en kutsal kuralı
Çok kiracılı bir sistemde her şey tek bir soruya doğru cevap vermek üzerine kuruludur: A işletmesinin verisini yalnızca A işletmesi görebilir mi? Buna veri izolasyonu denir ve mimarinin en kutsal kuralıdır. Pratikte en yaygın yöntem, veritabanındaki her kaydın bir kiracı kimliğiyle (TenantId) etiketlenmesidir: her müşteri kaydı, her randevu, her fatura, hangi işletmeye ait olduğunu üzerinde taşır.
İyi tasarlanmış bir sistemde bu filtreleme, geliştiricinin her seferinde hatırlamasına bırakılmaz; altyapının kendisine gömülür. Bizim kullandığımız yaklaşımda veritabanı katmanı, oturum açan işletmenin kimliğini bilir ve yazılan her sorguya 'yalnızca bu kiracının kayıtları' filtresini otomatik ekler. Geliştirici filtreyi yazmayı unutsa bile sistem unutmaz. Güvenliği insan dikkatine değil mimariye emanet etmek, çok kiracılı tasarımın altın kuralıdır.
İzolasyonun bir de istek düzeyinde katmanı vardır: kullanıcı sisteme hangi adresten geldi, oturumundaki kimlik hangi işletmeye ait, ikisi tutarlı mı? Örneğin bir işletmenin kullanıcısı, adres satırını değiştirerek başka bir işletmenin ekranına ulaşmaya çalışırsa, sistem oturum kimliğiyle hedef kiracıyı karşılaştırıp isteği reddeder. Bu tür çapraz kiracı kontrolleri, ciddi bir SaaS mimarisinin görünmeyen ama vazgeçilmez bekçileridir.
Veritabanı stratejileri: üç yol, üç denge
Teknik ekiplerin çok kiracılı mimaride verdiği en önemli karar veritabanı stratejisidir ve üç ana yol vardır. Birincisi, herkes için ayrı veritabanı: en güçlü fiziksel izolasyon budur ama yüzlerce veritabanının bakımı, yedeklemesi ve güncellenmesi operasyonel olarak ağırdır. İkincisi, ortak veritabanında ayrı şemalar: orta yol sayılır, ama şema sayısı arttıkça yönetim yine karmaşıklaşır.
Üçüncü ve SaaS dünyasında en yaygın yol, ortak veritabanı ve kiracı kimliğiyle etiketlenmiş ortak tablolardır. Bakımı en kolay, maliyeti en düşük, ölçeklenmesi en pratik model budur; bedeli ise izolasyonun tamamen yazılım katmanındaki disipline dayanmasıdır. Bu yüzden bu modeli seçen ekiplerin, az önce anlattığımız otomatik filtreleme ve çapraz kiracı kontrollerini taviz vermeden kurması gerekir.
Hangi yolun doğru olduğu ürünün doğasına bağlıdır. Küçük ve orta ölçekli işletmelere hizmet veren, kiracı sayısının yüzlerle ifade edildiği tipik bir dikey SaaS için ortak veritabanı modeli hem ekonomik hem yönetilebilir olandır. Çok büyük kurumsal müşterilere ya da özel mevzuat gerekliliklerine hizmet eden ürünlerde ise ayrı veritabanı, hatta ayrı sunucu gerekebilir. Mimari, ideolojiyle değil ihtiyaçla seçilir.
Maliyet ve operasyon: neden herkes bu modele koşuyor?
Çok kiracılı mimarinin ekonomisi, ölçeklendikçe güzelleşir. Tek kiracılı modelde her yeni müşteri, yeni bir kurulum demektir: sunucu ayarları, veritabanı, yedekleme düzeni, izleme... Yüzüncü müşteride yüz ayrı sistemin bakımını yapıyorsunuzdur ve her güncellemeyi yüz kez tekrarlarsınız. Çok kiracılı modelde ise yeni müşteri, veritabanına eklenen bir kayıt kadar hafiftir: dakikalar içinde açılır, altyapı maliyeti neredeyse sıfırdır.
Güncelleme tarafı daha da çarpıcıdır: tek dağıtımla bütün kiracılar aynı anda yeni sürüme geçer. Bir hata düzeltildiğinde herkes için düzeltilmiştir; bir özellik eklendiğinde herkese eklenmiştir. Eski sürümde unutulmuş müşteri diye bir kavram yoktur. Bu, hem geliştirme ekibinin hızını hem de ürün kalitesinin tutarlılığını doğrudan artırır.
Kaynak verimliliği de cabası: yüz işletmenin her birinin kendi sunucusunda kapasitesinin küçük bir kısmını kullanması yerine, ortak altyapı toplam yükü dengeli biçimde taşır. Daha az sunucu, daha az enerji, daha az bakım; hem üretici hem müşteri hem de doğrusu gezegen için daha verimli bir denklem.
Zorluklar ve dikkat edilmesi gerekenler
Dürüst bir teknik yazı, madalyonun öteki yüzünü de anlatmalı. Çok kiracılı mimarinin ilk zorluğu 'gürültücü komşu' sorunudur: bir kiracının anormal yükü (dev bir rapor, yoğun bir veri aktarımı) ortak kaynakları yorup diğer kiracıları yavaşlatabilir. Çözüm; kaynak sınırlama, istek hızı limitleme ve ağır işlerin kuyruklara alınmasıdır. İyi bir SaaS, apartmandaki ses yalıtımını da mimariden kurgular.
İkinci zorluk özelleştirme dengesidir: tüm kiracılar aynı yazılımı kullandığına göre, farklı ihtiyaçlar nasıl karşılanır? Cevap, plan bazlı özellik bayraklarıdır: her kiracının aboneliğine göre hangi modüllerin açık olduğu sistemde tanımlıdır; yazılım tek, deneyim kiracıya göre şekillenir. Üçüncü konu yedekleme ve geri dönüş senaryolarıdır: tek bir kiracının verisini, diğerlerine dokunmadan belirli bir ana geri döndürebilmek, baştan planlanması gereken bir yetenektir.
Bir SaaS ürünü değerlendiren işletmeye pratik önerimiz şu: sağlayıcınıza mimariyi sorun. Verim diğer müşterilerin verisinden nasıl ayrılıyor? Çapraz erişim nasıl engelleniyor? Yoğunlukta performans nasıl korunuyor? Bu sorulara net ve gönül rahatlığıyla cevap verebilen bir ekip, işini bilen bir ekiptir. Biz Rezon olarak FizyoDesk'te bu soruların her birine mimariyle cevap verdik ve aynı omurgayı yeni ürünlerimizde de yaşatıyoruz; çünkü çok kiracılı mimari doğru kurulduğunda, tek altyapıyla yüzlerce işletmeye aynı kalitede hizmet vermenin en zarif yoludur.
Sık sorulan sorular
+Multi-tenant (çok kiracılı) mimari nedir?
Tek bir yazılım ve altyapının, verileri birbirinden mantıksal olarak yalıtılmış çok sayıda işletmeye aynı anda hizmet verdiği yazılım mimarisidir. Her işletme yalnızca kendi verisini görür; ortak altyapı sayesinde maliyet ve bakım yükü tüm kiracılara bölünür.
+Multi-tenant ile single-tenant arasındaki fark nedir?
Single-tenant modelde her müşteri için ayrı yazılım kopyası ve veritabanı kurulur; multi-tenant modelde tek altyapı herkese hizmet verir. Tek kiracılı model daha güçlü fiziksel izolasyon sunar ancak kurulumu ve bakımı pahalıdır; çok kiracılı model ekonomik, hızlı ve merkezi olarak güncellenebilirdir.
+Çok kiracılı sistemde verilerim diğer firmalardan nasıl ayrılıyor?
Her kayıt bir kiracı kimliğiyle (TenantId) etiketlenir ve iyi tasarlanmış sistemlerde veritabanı katmanı her sorguya kiracı filtresini otomatik ekler. Ayrıca oturum kimliğiyle hedef kiracının karşılaştırıldığı çapraz erişim kontrolleri, bir işletmenin başka bir işletmenin verisine ulaşmasını engeller.
+Multi-tenant mimari güvenli midir?
Doğru kurulduğunda evet. Güvenlik, geliştiricinin dikkatine değil mimariye gömülü otomatik filtrelere, kimlik doğrulamaya ve erişim kontrollerine dayanmalıdır. Değerlendirdiğiniz SaaS sağlayıcısına veri izolasyonunu nasıl sağladığını sormanız, en sağlıklı testtir.
+SaaS ürünleri neden çoğunlukla multi-tenant kurulur?
Çünkü yeni müşteri eklemek neredeyse maliyetsizdir, güncellemeler tek dağıtımla tüm müşterilere ulaşır ve ortak altyapı kaynakları verimli kullanılır. Bu ekonomi, kurumsal sınıf yazılımın küçük işletmelerin karşılayabileceği abonelik bedelleriyle sunulabilmesini mümkün kılar.