Çok Kiracılı SaaS Mimari Diyagramı: Silo, Havuz ve Köprü Modelleri

Çok kiracılı (multi-tenant) bir SaaS ürününü, çoğu ekibin herhangi bir sistemi çizdiği gibi çizerseniz tek kiracılı bir sistemden hiçbir farkı kalmaz: bir ağ geçidi, birkaç servis, bir veritabanı. Sistemin en önemli özelliği, yani hangi müşterinin verisinin nereye düşebileceği, sayfanın hiçbir yerinde görünmez. Oysa en zor kararları bu özellik belirler: kiracıların nasıl izole edileceği, büyük müşterilere nasıl hizmet verileceği, onboarding'in nasıl işleyeceği ve gürültülü bir komşunun (noisy neighbor) neleri bozabileceği.

Bu rehber, çok kiracılılığı bir mimari diyagramda nasıl görünür kılacağınızı gösteriyor: temel kavramlar, diyagramın neyi göstermesi gerektiği, silo, havuz (pool) ve köprü (bridge) modelleri ve hem paylaşılan hem de adanmış kaynaklar içeren bir örnek.

Temel kavramlar

Aşağıdaki terimler, AWS'in SaaS rehberleri de dahil olmak üzere SaaS mimarisi üzerine yazılanlarda yaygın olarak kullanılır:

• Kiracı (tenant). Kendi kullanıcıları ve verisi olan bir müşteri kuruluşu.
• Kontrol düzlemi (control plane). Ürünü sunmak yerine kiracıları yöneten servisler: onboarding, kiracı kayıt defteri (tenant registry), kimlik, ölçümleme ve faturalandırma.
• Uygulama düzlemi (application plane). Ürünün kendisi: kiracıların her gün kullandığı servisler ve veri depoları.
• Kiracı bağlamı (tenant context). Her istekle birlikte taşınan kiracı ID'si; genellikle erişim token'ında bir claim olarak yer alır.
• Silo. Tek bir kiracıya ayrılmış kaynaklar; örneğin ayrı bir veritabanı ya da eksiksiz bir stack.
• Havuz (pool). Birçok kiracının paylaştığı, politikalarla ve kiracı ID'siyle birbirinden ayrılan kaynaklar.
• Köprü (bridge). İkisinin karışımı: örneğin paylaşılan işlem kaynakları (compute) ve bazı kiracılar için adanmış veritabanları.

Diyagramın göstermesi gerekenler

1. Kiracı bağlamının nereden geldiği. Kimlik sağlayıcı ve kiracı ID'sini taşıyan token claim'i.
2. İzolasyonun nerede sağlandığı. "Kodda" değil, belirli bir yerde: bir satır düzeyinde güvenlik (row-level security) politikası, kiracı başına bir şema, ayrı bir veritabanı, bir IAM politikası.
3. Hangi kaynakların paylaşıldığı, hangilerinin adanmış olduğu. Her veri deposunu ve servisi havuz ya da silo olarak etiketleyin.
4. Bir isteğin kaynaklarını nasıl bulduğu. Kiracıyı doğru veritabanına ya da stack'e gönderen yönlendirme veya arama (lookup) mekanizması.
5. Kiracıların nasıl oluşturulduğu. Kayıt defterine yazan ve varsa adanmış kaynakları hazırlayan onboarding akışı.

Silo, havuz ve köprü

Model	Ne paylaşılır	Güçlü yanları	Bedeli
Silo	Uygulama düzleminde hiçbir şey	Güçlü izolasyon, kiracı başına ince ayar, uyumluluk sorularına daha basit yanıtlar	Kiracı başına daha yüksek maliyet, işletilecek daha fazla dağıtım
Havuz	İşlem kaynakları ve veri, kiracı ID'siyle ayrılır	Kiracı başına düşük maliyet, tek dağıtım	İzolasyon her sorguya ve her politikaya bağlıdır; gürültülü komşular
Köprü	Bazı katmanlar paylaşılır, bazıları adanmıştır	İzolasyona yalnızca önemli olduğu yerde yatırım yapılır	Geliştirilecek, test edilecek ve çizilecek iki yol

Birçok ürün havuzla başlar, en büyük ya da en sıkı düzenlemeye tabi müşterilerini sonradan silolara taşır ve sistem böylece bir köprüye dönüşür. Diyagram bu ayrımı açıkça göstermelidir.

Örnek: havuzdaki kiracılar ve tek bir kurumsal silo

Bir B2B analitik ürününün yüzlerce standart kiracısı ve kendi veritabanını şart koşan tek bir kurumsal müşterisi, Globex, olsun:

• Kullanıcılar, kiracıları tanıyan (tenant-aware) bir kimlik sağlayıcı üzerinden giriş yapar. Erişim token'ları tenant_id taşır.
• API ağ geçidi token'ı doğrular ve kiracı bağlamını analitik API'sine iletir.
• Analitik API'si kiracının seviyesini (tier) ve veritabanını kiracı kayıt defterinde arar.
• Standart kiracılar, satır düzeyinde güvenliğin her sorguyu tenant_id ile filtrelediği bir havuz PostgreSQL veritabanını paylaşır.
• Globex'e ise kiracı oluşturulurken onboarding servisinin hazırladığı adanmış bir veritabanı verilir.

İki çerçeve kontrol düzlemini uygulama düzleminden ayırır; veri depolarındaki etiketler de hangi izolasyon modelinin geçerli olduğunu söyler. Artık diyagramı inceleyen biri doğru soruları sorabilir: Kayıt defteri çökerse ne olur, bir kiracının seviyesini kim değiştirebilir?

Çok kiracılı diyagramlar için kurallar

Kiracıları değil, seviyeleri çizin

Asla müşteri başına bir kutu çizmeyin. Her seviye ya da dağıtım modeli için bir yol çizin; işe yarıyorsa, yukarıdaki Globex örneğinde olduğu gibi örnek bir kiracının adını yazın.

Kiracı bağlamını kenarlara yazın

Her adımda kiracının nasıl tanımlandığını yazın: JWT tenant_id, header X-Tenant-Id set by the gateway, tenant_id in the message. Arka plan işleri ve olay tüketicileri de kiracı bağlamına ihtiyaç duyar ve bağlam en sık onlarda kaybolur.

İzolasyonu sağlayan noktayı diyagrama koyun

"Kiracı ID'siyle izole edilir" bir sözdür; satır düzeyinde güvenlik politikası, kiracı başına şema ya da ayrı bir hesap ise bir mekanizmadır. Mekanizmayı veri deposunun etiketine yazın ya da yanına bir Politika düğümü ekleyin.

Kiracı başına sınırları gösterin

Kiracı başına hız sınırları (rate limit), kotalar ve eşzamanlılık sınırları, havuz modelindeki bir sistemin kiracıları birbirinden korumasını sağlar. Bunları ağ geçidinde ve bu sınırları uygulayan servislerde not edin.

Ölçümleme ve faturalandırmayı kontrol düzleminde tutun

Kiracı başına kullanım olayları ölçümleme ve faturalandırmayı besler. Bunları kontrol düzleminde çizin; böylece uygulama düzlemi isteklere yanıt vermeye odaklı kalır.

Sık yapılan hatalar

• Kontrol düzlemi yok. Onboarding, kiracı kayıt defteri ve kimlik, yönetim araçları değil, mimarinin çekirdeğidir.
• Konvansiyona dayalı izolasyon. "Her sorgu kiracıya göre filtrelenir" diyen bir not, bir kontrol değildir. Bunu zorunlu kılan politikayı gösterin.
• Görünmez yönlendirme. Bazı kiracılar farklı kaynaklar kullanıyorsa, buna karar veren aramayı çizin.
• Unutulan asenkron yollar. Kiracı ID'sini kaybeden kuyruklar, zamanlanmış işler ve analitik dışa aktarımları klasik bir sızıntı kaynağıdır.
• Tek dev diyagram. Veri yerleşimini (bölgeler), dağıtımı ve mantıksal görünümü ayrı diyagramlarda tutun.

Archboard'da oluşturun

1. Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
2. Temel paketinden iki Çerçeve düğümü ekleyin: Control plane ve Application plane.
3. Standart kullanıcılar ve Globex kullanıcıları için Temel paketinden iki Kutu düğümü, Güvenlik paketinden bir Kimlik sağlayıcı, Bulut paketinden bir API ağ geçidi, onboarding servisi ve analitik API'si için de C4 Modeli paketinden Konteyner düğümleri ekleyin.
4. Kiracı kayıt defteri, havuz veritabanı ve adanmış veritabanı için Veri paketinden Postgres düğümleri ekleyin; izolasyon modelini etikete yazın.
5. Kenarları kiracı bağlamıyla etiketleyin ve kaynak hazırlama (provisioning) kenarını kesik çizgili yapın.

Örnek 11 diyagram düğümü kullanır ve Free planın sınırları içinde kalır. Alttaki bulut ve ağ katmanı için AWS VPC diyagramı yazısına ve bulut kullanım alanı sayfasına göz atın.

SSS

Hangi izolasyon modelini seçmeliyim? Müşterilerinizin gereksinimlerinden ve kiracı başına maliyetinizden yola çıkın. Havuzu işletmek en ucuzudur, siloyu bir güvenlik denetçisine anlatmak en kolayıdır, köprü ise ikisini birden sunmanızı sağlar. Gerekçeyi diyagrama yazın.

Yüzlerce kiracıyı nasıl gösteririm? Göstermezsiniz. Her seviyeyi ya da dağıtım modelini bir kez gösterin; kiracı listesini de ait olduğu yerde, kayıt defterinde tutun.

Her kiracının kendi diyagramı olmalı mı? Hayır. Her mimari için, seviyelerin üzerinde yer aldığı tek bir diyagram yeterlidir. Silo modelindeki kurumsal bir kiracı ayrı bir hesapta ya da bölgede çalışıyorsa kendi dağıtım diyagramına sahip olabilir.

Veri yerleşimini (data residency) nasıl gösteririm? Ayrı bir dağıtım diyagramında bölge çerçeveleriyle; her çerçeve, o bölgede kalması gereken kiracıların stack'lerini ya da veritabanlarını içerir.

Kiracı başına şifreleme anahtarları nereye konur? Korudukları veri depolarının yanına, Güvenlik paketinden bir düğüm ya da bir not olarak; anahtarları tutan anahtar yönetim servisiyle birlikte.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.