SaaS Uygulamalarda Tenant Nedir ve Nasıl Yönetilir?

SaaS (Software as a Service) uygulamaları gün geçtikçe daha fazla tercih ediliyor. Özellikle aynı uygulamanın onlarca hatta binlerce farklı müşteriye hizmet verdiği sistemlerde en kritik kavramlardan biri tenant yapısıdır. Aslında SaaS mimarisinin temelini tenant yönetimi oluşturur. Çünkü kullanıcı doğrulama, veri izolasyonu, lisanslama, abonelik yönetimi ve yetkilendirme gibi birçok konu doğrudan tenant mantığı üzerine kuruludur. Bu nedenle multi-tenant bir sistem geliştirmeden önce tenant kavramını doğru anlamak oldukça önemlidir.

Tenant Nedir?

En basit tanımıyla tenant, sistemi kullanan bağımsız müşteri veya firma anlamına gelir. Örneğin bir CRM uygulaması geliştirdiğinizi düşünelim.

• afirmasi.blabla.com → Tenant A
• bfirmasi.blabla.com → Tenant B

Her iki firma aynı uygulamayı kullanmasına rağmen;

• kullanıcıları farklıdır,
• verileri birbirinden tamamen izoledir,
• ayarları farklı olabilir,
• hatta kullandıkları özellikler bile değişebilir.

Yani uygulama fiziksel olarak tek olsa bile her müşteri kendisini ayrı bir sisteme bağlanıyormuş gibi hisseder. Kısacası;

Tenant = Firma = Company = Müşteri

Birçok projede TenantId, CompanyId veya OrganizationId gibi isimlerle de karşımıza çıkabilir. Önemli olan isim değil, temsil ettiği mantıktır.

Multi-Tenant Neden Tercih Edilir?

Tek bir müşteri için geliştirilen uygulamalarda tenant kavramına ihtiyaç duyulmayabilir. Ancak SaaS dünyasında her müşteri için ayrı bir uygulama yayınlamak ciddi operasyonel maliyet oluşturur. Multi-tenant mimaride ise;

• tek uygulama çalışır,
• tek deployment yapılır,
• tek bakım süreci yönetilir,
• birçok müşteri aynı altyapıyı paylaşır.

Bu yaklaşım hem geliştirme hem de operasyon maliyetlerini önemli ölçüde azaltır. Örneğin yeni bir özellik geliştirdiğinizde her müşteriye ayrı ayrı kurulum yapmak yerine uygulamayı bir kez güncellemeniz yeterlidir.

Tenant Nasıl Tespit Edilir?

Bir isteğin hangi tenant'a ait olduğunu anlayabilmek için önce tenant'ın belirlenmesi gerekir. En yaygın iki yöntem vardır.

1. Subdomain Kullanımı

En sık kullanılan yöntemlerden biridir. Örnek olarak;

afirmasi.blabla.com
bfirmasi.blabla.com

İstek uygulamaya ulaştığında host bilgisi okunur.

afirmasi.blabla.com

Buradan afirmasi bilgisi alınır ve Tenant tablosunda sorgulanır. Elde edilen TenantId, uygulamanın geri kalanında kullanılmaya başlanır. Bu yöntem özellikle çok sayıda müşterisi olan SaaS uygulamalarında oldukça pratiktir.

2. Custom Domain Kullanımı

Bazı müşteriler kendi alan adlarını kullanmak ister. Örneğin;

www.afirmasi.com

Bu durumda müşteri DNS tarafında bir CNAME kaydı oluşturur ve alan adını SaaS uygulamasına yönlendirir. .NET tarafında ise host bilgisi okunarak ilgili tenant bulunur.

www.afirmasi.com

Kullanıcı açısından deneyim tamamen kendi markası altında devam eder. Özellikle kurumsal müşteriler için bu yöntem oldukça yaygındır.

Tenant Bilgisi Nerede Saklanır?

Genellikle merkezi bir Tenant tablosu oluşturulur.

CREATE TABLE Tenants (
    TenantId INT IDENTITY(1,1) PRIMARY KEY,
    Name NVARCHAR(100) NOT NULL,
    Subdomain NVARCHAR(100) NULL,
    CustomDomain NVARCHAR(255) NULL,
    IsActive BIT DEFAULT 1,
    CreatedAt DATETIME DEFAULT GETDATE()
);

Alanların amacı şöyledir;

TenantId : Benzersiz tenant kimliği Name : Firma adı Subdomain: Subdomain kullanan müşteriler CustomDomain: Kendi domainini kullanan müşteriler IsActive: Abonelik veya kullanım durumu CreatedAt: Oluşturulma tarihi

Gerçek projelerde bunlara ek olarak;

• PackageId
• TimeZone
• Language
• Theme
• Logo
• ConnectionString
• StorageProvider
• SubscriptionEndDate

gibi alanlar da eklenebilir.

IIS Tarafında Tenant Yönetimi

IIS'in görevi tenant'ı çözmek değildir. IIS yalnızca gelen isteği doğru uygulamaya yönlendirir.

Wildcard Subdomain

DNS tarafında;

*.blabla.com

tek IP adresine yönlendirilir. IIS üzerinde ise tek site çalışır.

Host Name : blabla.com

Böylece bütün subdomain'ler aynı uygulamaya gelir.

Custom Domain

Müşteri kendi domainini CNAME ile SaaS uygulamasına yönlendirir.

www.afirmasi.com

İstek yine aynı uygulamaya ulaşır. Sonrasında tenant çözümleme işlemi tamamen uygulama içerisinde yapılır. Yani IIS yalnızca isteği karşılar, hangi tenant'ın kullanılacağına uygulama karar verir.

ASP.NET Core'da Tenant Çözümleme

ASP.NET Core projelerinde bu işlem genellikle middleware ile yapılır.

public class TenantMiddleware
{
    private readonly RequestDelegate _next;

    public TenantMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context, ITenantService tenantService)
    {
        var host = context.Request.Host.Host;

        var tenant = tenantService.GetBySubdomainOrCustomDomain(host);

        if (tenant == null)
        {
            context.Response.StatusCode = 404;
            await context.Response.WriteAsync("Tenant bulunamadı.");
            return;
        }

        context.Items["Tenant"] = tenant;

        await _next(context);
    }
}

Bu middleware her istekte çalışır. Önce host bilgisini alır. Ardından ilgili tenant'ı bulur ve HttpContext içerisine ekler. Böylece uygulamanın diğer katmanları tekrar tekrar tenant sorgulamak zorunda kalmaz. Daha büyük projelerde bu bilgi genellikle ITenantContext benzeri bir servis üzerinden tüm uygulamaya taşınır. Böylece servisler, repository katmanı ve yetkilendirme mekanizmaları aynı tenant bilgisini güvenli şekilde kullanabilir.

Veri İzolasyonu Nasıl Sağlanır?

Tenant bilgisini bulmak tek başına yeterli değildir. Asıl önemli konu, her tenant'ın yalnızca kendi verilerini görebilmesidir. EF Core kullanıyorsanız bunu Global Query Filter ile oldukça temiz şekilde çözebilirsiniz.

modelBuilder.Entity<Call>()
    .HasQueryFilter(c => c.TenantId == _tenantContext.TenantId);

Bu sayede yazılan sorguların büyük kısmında ayrıca TenantId filtresi eklemek gerekmez. Ancak burada dikkat edilmesi gereken önemli bir nokta vardır. Global Query Filter kullanılıyor olsa bile, yönetici ekranları, raporlama servisleri veya arka plan görevlerinde filtrelerin bilinçli şekilde devre dışı bırakılması gerekiyorsa bunun kontrollü yapılması gerekir. Yanlış yapılandırılmış sorgular farklı tenant verilerine erişilmesine neden olabilir.

Her Tenant İçin Ayrı Veritabanı mı Kullanılmalı?

Bu soru multi-tenant projelerde en sık karşılaşılan konulardan biridir. Aslında tek bir doğru cevap yoktur.

Aynı veritabanı, TenantId ile ayrım

Avantajları:

• Yönetimi kolaydır.
• Daha düşük maliyetlidir.
• Küçük ve orta ölçekli SaaS projeleri için idealdir.

Dezavantajları:

• Veri büyüdükçe performans optimizasyonu daha önemli hale gelir.
• Tenant izolasyonu tamamen uygulama katmanına bağlıdır.

Her tenant için ayrı veritabanı

Avantajları:

• Çok güçlü veri izolasyonu sağlar.
• Yedekleme ve taşıma işlemleri daha kolay yönetilebilir.
• Büyük kurumsal müşteriler için tercih edilebilir.

Dezavantajları:

• Yönetilecek veritabanı sayısı hızla artar.
• Migration, bakım ve operasyon süreçleri daha karmaşık hale gelir.

Gerçek hayatta birçok SaaS ürünü başlangıçta ortak veritabanı modeliyle ilerler. Müşteri sayısı ve kurumsal ihtiyaçlar arttığında ise büyük müşteriler için ayrı veritabanına geçiş yapılabilir. Bu hibrit yaklaşım hem maliyet hem de ölçeklenebilirlik açısından sık tercih edilen bir yöntemdir.

Tenant Yapısının Sağladığı Avantajlar

Doğru tasarlanmış bir tenant mimarisi birçok avantaj sağlar.

• Veri izolasyonu güvenli şekilde sağlanır.
• Tek uygulama ile yüzlerce müşteri yönetilebilir.
• Abonelik bazlı paketler kolayca uygulanabilir.
• Tenant bazlı özellik açma veya kapatma yapılabilir.
• Ölçeklenebilirlik artar.
• Bakım ve deployment süreçleri kolaylaşır.

Örneğin Premium pakette çalışan bir müşteriye ek raporlama modülü açarken, diğer müşteriler aynı uygulamayı kullanmaya devam edebilir. Bunun için çoğu zaman yalnızca tenant bazlı bir özellik tanımı yeterlidir.

Örnek Tenant Akışı

Tipik bir istek aşağıdaki adımlarla ilerler:

1. Kullanıcı uygulamaya istek gönderir.
2. Host bilgisi (subdomain veya custom domain) okunur.
3. Tenant tablosundan ilgili kayıt bulunur.
4. Tenant bilgisi uygulama içerisine alınır.
5. Kullanıcı doğrulama işlemleri gerçekleştirilir.
6. Veritabanı sorgularında yalnızca ilgili tenant'ın verileri kullanılır.
7. İstek güvenli şekilde tamamlanır.

Bu akış sayesinde tüm müşteriler aynı uygulamayı kullanırken birbirlerinin verilerine erişemez.

Sonuç

Tenant kavramı, modern SaaS uygulamalarının temel yapı taşlarından biridir. Doğru kurgulanmış bir tenant yönetimi; veri izolasyonu, güvenlik, ölçeklenebilirlik ve bakım kolaylığı gibi birçok avantaj sağlar. İster subdomain ister custom domain kullanın, önemli olan tenant bilgisini uygulamanın erken aşamasında doğru şekilde çözümlemek ve tüm katmanlarda tutarlı olarak kullanmaktır. Proje büyüdükçe tenant yönetimi yalnızca bir kimlik bilgisi olmaktan çıkar; yetkilendirme, lisanslama, özellik yönetimi ve veri mimarisinin merkezine yerleşir. Bu nedenle mimariyi en baştan doğru planlamak, ileride karşılaşılabilecek birçok operasyonel ve güvenlik probleminin önüne geçecektir.