Jargonsuz Multi-Tenant Mimari: Kurucular İçin Rehber

Bir yazılım ürünü geliştirirken bir noktada bir geliştirici size "multi-tenant" kelimesini söyleyecek, yüzünüze bakacak ve anladığınızı varsayacaktır. Muhtemelen başınızı salladınız. Çoğu kurucu öyle yapar. Ama bu, ne kadar hızlı büyüyebileceğinizin, ne kadar ucuza çalışabileceğinizin ve bir müşteri kendisine ait olmayan veriyi görürse işlerin ne kadar kötü gidebileceğinin tavanını sessizce belirleyen o erken kararlardan biridir. Şimdi on dakikanızı ayırmaya değer, çünkü sonradan gözden geçirmek çok pahalıdır.

Pek çok teknik olmayan kurucunun karşısında oturdum — bir SaaS ürünü için keskin bir fikri olan ama veritabanlarına özel bir ilgisi olmayan insanlar. İyi haber şu: bu kararı iyi vermek için kod yazmayı öğrenmenize gerek yok. Net bir zihinsel modele ve kısa bir soru listesine ihtiyacınız var. Bu rehber tam olarak bu. Süslü kelimeler yok, bir daha bakmayacağınız mimari şemalar yok; sadece geliştiricinizin ilk satır koddan önce anlamanızı dilediği şey.

Tek bir fikir aklınızda kalacaksa, bu olsun: multi-tenancy sonradan eklediğiniz bir özellik değildir. Bir temeldir. Bir evi yeniden boyayabilirsiniz, ama duvarlar dikildikten sonra üzerinde durduğu şeyi kolayca değiştiremezsiniz.

"Multi-tenant" gerçekte ne demek

Bir apartman düşünün. Her kiracının kendi dairesi var — kendi anahtarı, kendi mobilyası, kendi kapısı. Ama hepsi aynı yapıyı paylaşır: temel, tesisat, çatı, asansör. Ev sahibi elli ayrı ev değil, tek bir bina bakar ve kirayı uygun kılan da budur. Multi-tenant yazılım tam olarak böyle çalışır. Tek bir uygulama birçok müşteriye — "tenant"lara — hizmet verir ve her biri, hepsi alttaki aynı paylaşılan sistem üzerinde çalışsa bile, onu kendi özel alanı gibi deneyimler.

Bunun zıttı yaklaşım single-tenant'tır: her müşteri yazılımın kendi ayrı kopyasını alır, her biri için yepyeni müstakil bir ev inşa etmek gibi. Daha özel, daha özelleştirilebilir — ve inşa etmesi, çalıştırması ve güncellemesi çok daha pahalı, çünkü artık tek bir bina yerine elli ev bakıyorsunuz.

Günlük kullandığınız neredeyse her ürün multi-tenant'tır. E-postanız, muhasebe aracınız, rezervasyon sisteminiz, satış ekibinizin içinde yaşadığı CRM. Siz ve binlerce başka şirket aynı temel yazılımı paylaşıyorsunuz ve hiçbiriniz birbirinizi görmüyorsunuz. Bu görünmezlik — bu temiz ayrım — multi-tenancy'nin tüm sanatıdır.

Bu karar neden tüm işinize dokunur

Bunu "geliştiricimin hallettiği teknik bir ayrıntı" diye sınıflandırmak cazip gelir. Ama seçtiğiniz model, doğrudan gerçekten önemsediğiniz iş kısımlarına dalga dalga yayılır: aylık barındırma faturanıza, yeni bir özelliği herkese ne kadar hızlı çıkarabileceğinize, tedirgin bir kurumsal alıcıya ne söz verebileceğinize ve tek bir hatanın ne kadar zarar verebileceğine.

İyi inşa edilmiş bir multi-tenant üründe bir hatayı düzelttiğinizde ya da bir özellik yayınladığınızda, her müşteri bunu aynı anda alır, tek bir güncellemeden. Single-tenant dünyada bu değişikliği, her biri artık birbirinden biraz farklı olabilecek elli ayrı kuruluma yayıyor olurdunuz. Biri salı öğleden sonrası işidir. Diğeri bir projedir. Bunu yılların güncellemeleriyle çarpın, SaaS sektörünün neden multi-tenancy üzerinde döndüğünü görürsünüz.

Madalyonun diğer yüzü, altyapıyı paylaşmanın ayrımın bahsini yükseltmesidir. Bir apartmanda bir tesisat arızası birden fazla daireyi etkileyebilir. Multi-tenant yazılımda, kiracıları nasıl ayırdığınızdaki bir hata yalnızca bir müşteriyi rahatsız etmekle kalmaz — aynı anda herkesin verisini ifşa edebilir. Bu, multi-tenancy'den kaçınmak için bir sebep değildir. Bunu daha önce yapmış biriyle, düzgün bir şekilde inşa etmek için bir sebeptir.

Kiracıları ayırmanın üç yolu

Geliştiriciler multi-tenancy hakkında tartıştığında, genellikle her kiracının verisinin ne kadar ayrı olması gerektiğini tartışırlar. Üç yaygın yaklaşım vardır ve bunlar "maksimum paylaşım, en düşük maliyet"ten "maksimum ayrım, en yüksek maliyet"e doğru kayan bir ölçekte yer alır. Birini kendiniz seçmenize gerek yok — ama geliştiricinizin sizin adınıza yaptığı ödünleşimi anlamalısınız.

1. Paylaşılan veritabanı, paylaşılan tablolar

Herkesin verisi aynı veritabanında, aynı tablolarda, hangi satırların kime ait olduğunu işaretleyen gizli bir etiketle — bir "tenant ID" ile — yaşar. Yazılım her zaman bu etikete göre filtrelemekten sorumludur, böylece A müşterisi yalnızca A'nın satırlarını görür. Bu en ucuz ve en ölçeklenebilir modeldir, çoğu erken aşama SaaS ürününün kullandığıdır. Kötü tarafı: ayrım kodda yaşar, dolayısıyla atlanan tek bir filtre verinin sızma biçimidir. Dikkatli, disiplinli mühendislik gerektirir.

2. Paylaşılan veritabanı, ayrı bölmeler

Tek bir veritabanı, ama her kiracı içinde kendi duvarla çevrili bölümünü alır (geliştiriciler bunlara "şema" der). İlk modelden daha güçlü bir ayrım, hâlâ makul ölçüde verimli ve örneğin bir müşterinin verisini temiz bir şekilde dışa aktarmayı ya da silmeyi kolaylaştırır. Ödünleşim: yüzlerce ve binlerce kiracıya doğru büyüdükçe yönetilecek daha fazla hareketli parça.

3. Her kiracı için ayrı bir veritabanı

Her müşteri kendi özel veritabanını alır — uygulamayı hâlâ paylaşırken onlara özel bir ev vermeye en yakın şey. Bu en güçlü yalıtımdır ve güvenliğe duyarlı kurumsal bir alıcıya anlatılacak en kolay hikâyedir. Aynı zamanda çalıştırması ve işletmesi en pahalı olandır, bu yüzden genellikle yüksek değerli müşterilere, düzenlemeye tabi sektörlere ya da bir veri karışıklığının felaket olacağı ürünlere ayrılır.

Yanlış yapamayacağınız kısım: yalıtım

Endişenizi harcayacağınız tek bir yer varsa, o da burasıdır. Tenant yalıtımı, A müşterisinin hiçbir koşulda B müşterisinin verisini göremeyeceği, düzenleyemeyeceği, hatta varlığını sezemeyeceği güvencesidir. Bariz geliyor. Aynı zamanda multi-tenant ürünlerdeki ciddi hataların tek başına en yaygın kaynağıdır, çünkü arıza sessizdir — biri bir gün bir rapor açıp içinde bir yabancının müşterilerini görene kadar her şey yolunda görünür.

Bunun olma sebebi yapısaldır. En ucuz modelde her tek veritabanı isteğinin kiracıya göre filtrelemeyi hatırlaması gerekir. On bin kez doğru, bir kez yanlış yapın, bir sızıntınız olur. İşte bu yüzden deneyimli ekipler geliştiricilerin hatırlamasına güvenmez — yalıtımı temele inşa ederler, böylece unutmak yalnızca olası değil, imkânsız hale gelir. Bunu nasıl yaptıklarını anlamanıza gerek yok. Yapıp yapmadıklarını sormanız gerekiyor.

Bu sorunun daha sessiz bir kuzeni de var: "gürültülü komşu". Kiracılar altyapıyı paylaştığı için, ağır bir şey yapan bir müşteri — devasa bir içe aktarma, kontrolden çıkmış bir rapor — sistemi herkes için yavaşlatabilir, tıpkı her musluğu açık bir dairenin tüm binada su basıncını düşürmesi gibi. İyi multi-tenant tasarımı bunu sınırlar ve adil paylaşımla planlar. Özellikle birkaç çok büyük müşteri bekliyorsanız, sormaya değer.

Single-tenant'ın aslında doğru karar olduğu zamanlar

Multi-tenancy SaaS için varsayılandır, ama bir din değildir. Bir müşteriye kendi ayrı kopyasını vermenin dürüst sebepleri vardır ve iyi bir danışman, her şeyi paylaşılan modele zorlamak yerine bunlardan birine çarptığınızda size söyler.

• Uyum kuralları, verisinin kanıtlanabilir şekilde ayrı bir yerde durmasını fiilen şart koşan, düzenlemeye tabi bir sektördeki — sağlık, finans, kamu — bir müşteri.
• Özel bir kurulumu hak edecek kadar ödeyen ve herkesin deneyimine sızmasını istemediğiniz derin bir özelleştirme isteyen tek bir büyük müşteri.
• Kiracılar arası bir sızıntının maliyeti işi bitirecek kadar hassas veriler; bu da maksimum yalıtımı ek masrafa değer kılar.
• Yazılımın sizin bulutunuz yerine müşterinin kendi duvarları içinde çalışması gereken bir on-premise gereksinimi.

Kalıba dikkat edin: single-tenant, tüm işi üzerine inşa ettiğiniz varsayılan değil, genellikle belirli bir yüksek değerli müşteri için bilerek başvurduğunuz istisnadır. Bir geliştirici standart ürününüz için daha ilk günden single-tenant öneriyorsa, nedenini size anlatmasını isteyin — bu genellikle çok daha yüksek bir çalıştırma maliyeti ve daha yavaş güncellemeler demektir ve bunun bir tercih olmasını istersiniz, kaza değil.

Kimse kod yazmadan önce sorulacak sorular

Mimariyi tasarlamanıza gerek yok. Tasarlayan kişinin doğru şeyleri düşünmüş olduğundan emin olmanız gerekiyor. İşte teknik olmayan bir kurucunun o ilk görüşmeye getirmesini isteyeceğim kısa liste — yazdırın, sorun, ne kadar güvenle yanıtlandığını izleyin.

1. 1
   Kiracıların verisini nasıl ayrı tutacaksınız?

   Yapısal bir yanıt arıyorsunuz — sistem bunu sağlıyor — "dikkatli olacağız" değil. Bu, üzerinde pazarlık olmayan tek soru.
2. 2
   Hangi modeli kullanıyoruz ve neden?

   Paylaşılan tablolar, ayrı bölmeler ya da kiracı başına veritabanı. Yanlış yanıt yok, ama müşterilerinize ve bütçenize uyan bir sebep olmalı.
3. 3
   Sonradan büyük bir müşteriye özel yalıtım sunabilir miyiz?

   Tamamen paylaşılan başlasanız bile, tasarım büyük ya da düzenlemeye tabi bir müşteriye yeniden inşa olmadan daha güçlü ayrım vermeye yer bırakmalı.
4. 4
   Bir müşteri devasa olunca ne olur?

   Sistem ağır bir kiracının herkesi yavaşlatmasını nasıl engelliyor? Gürültülü komşu senaryolarının düşünüldüğünü duymak istersiniz.
5. 5
   Bir müşterinin verisini nasıl temizce dışa aktarır ya da sileriz?

   Müşteriler ayrılır ve gizlilik yasası, talep üzerine verilerini kaldırmanızı gerektirir. Bu, bir panik değil, basit ve iyi anlaşılmış bir işlem olmalı.

Yanıtların teknik ayrıntısına not vermiyorsunuz. Bu soruların hiçbirinin sürpriz olarak düşmediğini kontrol ediyorsunuz. Daha önce multi-tenant yazılım inşa etmiş bir ekibin beşine de net, neredeyse sıkkın yanıtları olacaktır. Birinci ya da üçüncüdeki tereddüt, yavaşlayıp derine inme sinyalidir.

Kısa, gerçeğe yakın bir örnek

Bir kurucu bize küçük klinikleri hedefleyen bir randevu aracı için çalışan bir prototiple geldi. Zaten üç ödeme yapan müşterisi vardı — ve sessiz bir sorunu. Pazara hızla çıkmak için ilk geliştirici her kliniğe uygulamanın kendi ayrı kopyasını vermişti. Üç müşteri, üç kurulum, biraz farklı üç sürüm, çünkü her biri yol boyunca küçük bir düzenleme istemişti.

Üçte harika çalışıyordu. Kurucunun kâbusu otuz düşüncesiydi. Her hata düzeltmesi üç yere giriş yapmak demekti. Her yeni özellik üç dağıtım ve test edilecek üç şey demekti. Yeni bir klinik elle kurulması için neredeyse bir hafta alıyordu. Onları lansmana taşıyan model, artık büyümelerini sınırlayan şeydi — tam olarak bu yazının baştan sona anlattığı temel sorunu.

Her şeyi dramatik bir yeniden yazımla söküp atmadık. Çekirdeği, yalıtımı sistem düzeyinde sağlanan paylaşılan bir multi-tenant temele yeniden inşa ettik, klinik başına özelleştirmeleri ayrı kod tabanları yerine yapılandırılabilir ayarlar olarak tuttuk ve mevcut üç kliniği teker teker, paralel olarak taşıdık, böylece kimsenin korkutucu bir geçiş günü olmadı. Yeni bir klinik eklemek bir haftalık elle işten self-servis kayda dönüştü. Yeni özellikler artık her müşteriye tek bir sürümden ulaşıyor.

Buradaki sayılar bir söz değil, örnekleyici — her ürün farklıdır — ama biçim tipiktir: yeniden inşa gerçek para ve birkaç aya mal oldu ve artık parmak kıpırdatmadan ekleyebildikleri ilk avuç dolusu yeni müşteride kendini amorti etti. Kurucunun çıkardığı ders daha ucuz olanıydı: baştan beş soruyu sormuş olsalardı, yeniden inşa edilecek hiçbir şey olmazdı.

Sık sorulan sorular