Deploynix’te Çoklu Kiracı SaaS: Kiracı Başına Veritabanı mı Yoksa Paylaşılan Veritabanı mı?

Çok kiracılı bir SaaS uygulaması oluşturmak, geliştiricilerin Laravel’e yönelmesinin en yaygın nedenlerinden biridir. Framework’ün zarif ORM’i, middleware sistemi ve olay odaklı mimarisi, tek bir kod tabanından birçok müşteriye hizmet eden uygulamalar için doğal bir uyum sağlar. Ancak, uygulamanızı şekillendiren mimari karar, kiracılık modelinizdir: Her kiracıya kendi veritabanını mı verirsiniz yoksa tüm kiracılar bir veritabanını mı paylaşır?

Bu, kolayca geri alınabilecek bir karar değildir. Seçiminiz, veri modelinizi, dağıtım hattınızı, yedekleme stratejinizi, ölçeklenme yaklaşımınızı ve operasyonel karmaşıklığınızı yıllar boyunca etkiler. Bu kılavuzda, her iki yaklaşımı derinlemesine inceleyeceğiz, pratikte önemli olan ticaretleri gözden geçireceğiz ve Deploynix’in altyapısının her iki modeli nasıl desteklediğini göstereceğiz.

İki Yaklaşımı Anlamak

Kiracı Sütunu ile Paylaşılan Veritabanı

Paylaşılan veritabanı modelinde, tüm kiracılar verilerini aynı veritabanında saklar. Kiracıya özgü verileri içeren her tablo, bir tenant_id sütunu içerir ve her sorgu mevcut kiracıya göre düzenlenir. Laravel’in küresel kapsamları, bunu şeffaf hale getirir: Bir TenantScope‘u modellerinize uyguladıktan sonra, tüm sorgular otomatik olarak WHERE tenant_id = ? koşulunu içerir.

Bu, daha basit bir yaklaşımdır ve çoğu Laravel SaaS uygulaması bu modelle başlar. Veritabanı şemanız tek bir tablo setine sahiptir, göçler bir kez çalıştırılır ve yedekleme tek bir veritabanı dökümüyle yapılır. Stancl/Tenancy gibi araçlar ve Laravel için Tenancy paketi, bu modeli kutudan çıkar çıkmaz destekler.

Kiracı Başına Veritabanı

Kiracı başına veritabanı modelinde, her kiracı kendi veritabanına sahip olur. Bir istek geldiğinde, uygulama kiracıyı belirler (genellikle alt alan adı, alan adı veya başlık aracılığıyla) ve veritabanı bağlantısını o kiracının veritabanına yönlendirir. Her veritabanının benzer bir şeması vardır ve göçler her kiracı veritabanı üzerinde çalıştırılır.

Bu yaklaşım, daha güçlü veri izolasyonu, kiracı bazında işlemlerin (yedekleme, geri yükleme, geçiş) daha basit olması ve yüksek değerli kiracıları özel veritabanı sunucularında barındırma olanağı sunar. Ancak, kiracı sayısı ile doğrusal olarak büyüyen önemli bir operasyonel karmaşıklık ekler.

Paylaşılan Veritabanı İçin Gerekçeler

Çok sayıda küçük ve orta ölçekli kiracıya sahip olan çoğu Laravel SaaS uygulaması için paylaşılan veritabanı, doğru başlangıç noktasıdır. İşte nedenleri:

Operasyonel Basitlik

Deploynix veritabanı sunucusunda tek bir veritabanı ile operasyonel hikayeniz temizdir. Yedeklemek için tek bir veritabanı, izlemek için tek bir veritabanı, ayarlamak için tek bir veritabanı vardır. Deploynix’in otomatik yedekleme sistemi, veritabanı dökümlerinizi AWS S3, DigitalOcean Spaces, Wasabi veya yapılandırdığınız diğer S3 uyumlu depolama alanlarına gönderir. Bir yedekleme işi tüm kiracıları kapsar.

Göçleriniz bir kez tek bir veritabanına karşı çalıştırılır. İndeks optimizasyonunuz tüm kiracıları aynı anda kapsar. Yavaş sorgu günlüğünüz, hangi sorguların dikkat gerektirdiğini tam olarak gösterir, onlarca veritabanı arasında toplama yapmanız gerekmez.

Sorgu Esnekliği

Paylaşılan veritabanında, kiracılar arası sorgular basittir. Platform genelinde bir analiz raporu oluşturmanız mı gerekiyor? Tek bir sorguyu çalıştırın. Aboneliği sona eren tüm kiracıları bulmanız mı gerekiyor? Bir sorgu. Destek amaçlı tüm kiracılar arasında bir kullanıcıyı aramanız mı gerekiyor? Bir sorgu.

Kiracı başına veritabanı modelinde, her bir işlem, her kiracı veritabanında yineleme yapmayı, sorguyu çalıştırmayı ve sonuçları toplamanızı gerektirir. Bin kiracı için, bu bin veritabanı bağlantısı ve bin sorguya denk gelir.

Kaynak Verimliliği

Veritabanı bağlantıları ücretsiz değildir. Her bağlantı, hem uygulama sunucusunda hem de veritabanı sunucusunda bellek tüketir. Paylaşılan bir veritabanı, bağlantı havuzunuzu tüm kiracılar arasında paylaşır. Kiracı başına veritabanı modeli ise, her kiracının potansiyel olarak kendi bağlantısına ihtiyacı olduğu anlamına gelir; bu durumda uygulama sunucunuzun bunların hepsini korumak için yeterli belleğe sahip olması gerekir.

Deploynix’te veritabanı sunucunuz MySQL, MariaDB veya PostgreSQL ile sağlanır. Paylaşılan bir veritabanıyla, tek bir iyi ayarlanmış veritabanı sunucusu verimlice yüzlerce kiracıyı yönetebilir. Bağlantı havuzu yönetilebilir, sorgu önbelleği etkili ve bellek havuzu tüm kiracıları sunar.

Laravel ile Uygulama

Paylaşılan veritabanı yaklaşımı, Laravel’in mimarisiyle doğal olarak bütünleşir. Taban modelinizdeki küresel bir kapsam, kiracı kapsamını ele alır:

protected static function booted(): void
{
    static::addGlobalScope('tenant', function (Builder $builder) {
        if (auth()->check()) {
            $builder->where('tenant_id', auth()->user()->tenant_id);
        }
    });
}

Stancl/Tenancy gibi paketler, alan adlarından veya alt alan adlarından kiracı kimliğini otomatik olarak belirleme, sorgu kapsamlarını uygulama ve kiracıya özgü yapılandırmaları yönetme işlemlerini otomatikleştirir. Bu paket, Laravel’in hizmet konteyneri ile bütünleşir, böylece kiracı bağlamı uygulamanızın her yerinde kullanılabilir durumda olur.

Giderilmesi Gereken Riskler

Paylaşılan veritabanı modeli, proaktif bir şekilde ele almanız gereken gerçek riskler taşır.

Veri sızıntısı en ciddi olanıdır. Tek bir sorguda kaybolan bir tenant_id kapsamı, bir kiracının verilerinin diğerine açığa çıkmasına neden olabilir. Otomatik testler şarttır: Kiracı verilerini döndüren her sorgu, kiracı sınırlarını doğru bir şekilde göz önünde bulundurması için test edilmelidir. Laravel’in model fabrikalarını kullanarak birden fazla kiracı için veri oluşturun ve sorguların yalnızca doğru kiracının verilerini döndürdüğünü doğrulayın.

Gürültülü komşular ikinci risk. Bir kiracının pahalı bir rapor çalıştırması, tüm kiracılar için veritabanını yavaşlatabilir. Pahalı işlemleri Deploynix Çalışan sunucularına aktarım yapmak için Laravel’in kuyruk sistemini kullanın ve ağır sorguları tetikleyen API uç noktalarında oran sınırlaması uygulayın.

Şema bağlılığı, tüm kiracıların aynı şemayı paylaşması anlamına gelir. Eğer bir kurumsal kiracı özel bir alana ihtiyaç duyarsa, bunu sadece onların veritabanına ekleyemezsiniz. Nullable sütunlar, JSON sütunları veya ayrı bir meta veri tablosu oluşturmanız gerekir.

Kiracı Başına Veritabanı İçin Gerekçeler

Operasyonel yüküne rağmen, kiracı başına veritabanı belirli senaryolar için doğru seçimdir.

Düzenleyici ve Uyum Gereksinimleri

Bazı sektörler, sıkı veri izolasyonu gerektirebilir. PHI’yi işleyen sağlık uygulamaları, denetime tabi mali uygulamalar ve hükümet müşterilerine hizmet veren uygulamalar, kiracı verilerinin fiziksel olarak ayrı olduğunu kanıtlamayı isteyebilir. Mantıksal izolasyon için WHERE ifadeleri kullanan paylaşılan bir veritabanı, verilerin Tenant A’nın veritabanı bağlantısından erişilemeyecek şekilde görülebilir olması gerektiğini gösteren bir denetimciyi tatmin etmeyebilir.

Kurumsal Müşteri Talepleri

Büyük kurumsal müşteriler genellikle veri izolasyonu gerektirir. Verilerini bir bütün veritabanı dökümü olarak talep etme, verilerinin belirli bir coğrafi bölgede saklandığını doğrulama ve diğer kiracıların bir veritabanı ihlalinin kendi bilgilerini açığa çıkarmasını engelleme olanağı isterler.

Kiracı Bazında Performans Garantileri

Eğer premium kiracılara performans SLA’ları sunuyorsanız, kiracı başına veritabanı, özel bir Deploynix veritabanı sunucusunda verilerini yerleştirme olanağı sunar. Kendi veritabanı sunucusundaki premium bir kiracı, diğer kiracıların sorgu desenlerinden tamamen yalıtılmıştır.

Kiracı Bazında İşlemleri Kolaylaştırma

Bir kiracının verilerini bir yedekten geri yüklemek, kiracı başına veritabanı ile son derece kolaydır: onların veritabanını geri yükleyin. Paylaşılan bir veritabanıyla, birden çok tabloda satırları seçerek geri yükleme yapmanız gerekir ki bu da hataya açık ve yavaştır.

Benzer şekilde, bir kiracıyı farklı bir bölgeye taşımak, aktif olmayan bir kiracıyı arşivlemek veya bir kiracıya uyum amaçları için verilerinin bir kopyasını sağlamak, verilerinin kendi veritabanında bulunması durumunda çok daha basittir.

Deploynix Üzerinde Kiracı Başına Veritabanı Uygulaması

Eğer kiracı başına veritabanı modelini seçerseniz, işte Deploynix’te nasıl mimarilendirileceğine dair bilgiler.

Veritabanı Sunucusu Stratejisi

Küçük-orta ölçekli (birkaç yüz kiracıya kadar) için, tek bir güçlü Deploynix veritabanı sunucusu, tüm kiracı veritabanlarını barındırabilir. MySQL ve PostgreSQL, veri boyutunun belleğe sığması ve bağlantı sayısının yönetilebilir kalması koşulunda, tek bir örnekte yüzlerce veritabanını sorunsuz bir şekilde yönetebilir.

Bundan daha fazlasını büyüdüğünüzde, Deploynix’te ek veritabanı sunucuları tahsis edin ve kiracıları bunlar arasında dağıtın. Her kiracının hangi veritabanı sunucusunda saklandığını gösteren merkezi bir veri tablosu tutun. Uygulamanız, kiracı kimliği sırasında bu tabloyu okur ve doğru sunucuya bağlanır.

Premium kiracılar için, özel bir veritabanı sunucusu tedarik edin. Deploynix, sunucuları DigitalOcean, Vultr, Hetzner, Linode, AWS veya özel sağlayıcılara yayma olanağı sunduğundan, kiracı veritabanı sunucusunu tercih ettiği bölgeye yerleştirebilirsiniz.

Göç Yönetimi

Yüzlerce kiracı veritabanına karşı göçler çalıştırmak, otomasyonu gerektirir. Stancl/Tenancy, tüm kiracıları yineleyip her veritabanına karşı göçleri çalıştıran bir artisan komutuyla bunu ele alır. Bunu, her dağıtımda göçlerin çalışmasını sağlamak için Deploynix özel dağıtım scriptinize ekleyin.

Unutmayın ki göç hataları, bu modelde daha karmaşık hale gelir. Eğer 500 kiracıdan 238’de göç 47 hata verirken oluşursa, kısmi göçleri düzgün bir şekilde ele almanız gerekir. İdempotent göçler uygulayın ve her kiracı için göç durumu kaydını tutun.

Yedekleme Stratejisi

Kiracı başına veritabanı ile tek bir yedekleme işine güvenemezsiniz. Her kiracı veritabanının kendi yedeği olmalıdır. Deploynix’in yedekleme sistemi her veritabanı için yapılandırılabilir, ancak ölçeklendiğinizde, bu işlemi planlı bir iş ile betimlemek isteyebilirsiniz ve her kiracı veritabanını seçtiğiniz depolama sağlayıcısına (AWS S3, DigitalOcean Spaces, Wasabi veya S3 uyumlu özel depolama) yedeklemek için yineleyebilirsiniz.

Bu yedeklemeleri, Deploynix’in zamanlayıcı yönetimi ile yoğun saatler dışında programlayın. Yedeklemeleri dağıtarak veritabanı sunucunuzun yüzlerce eş zamanlı döküm işlemiyle boğulmasını önleyin.

Bağlantı Havuzu Yönetimi

Laravel uygulamanızı veritabanı bağlantılarını dikkatlice yönetmek üzere yapılandırın. Bir sorgu gerçekten çalıştırılmayan bir kiracının veritabanına bağlı kalmaması için tembel bağlantılar kullanın. İstek tamamlandıktan sonra bağlantıları zamanında kapatın. Veritabanı sunucunuzun bağlantı sınırına yaklaşmadığınızdan emin olmak için Deploynix’in sunucu izleme sistemini kullanarak bağlantı sayınızı izleyin.

Hibrit Yaklaşım

Pek çok başarılı SaaS uygulaması, hibrit bir model kullanır. Paylaşılan veriler (kullanıcı hesapları, faturalama, platform yapılandırması) merkezi bir veritabanında bulunur. Kiracıya özgü uygulama verileri, kiracı başına veritabanlarında yer alır. Bu, her iki dünyanın da en iyisini sunar: platform ile ilgili endişeler için basit kiracı arası işlemler ve uygulama verileri için güçlü izolasyon.

Deploynix’te, uygulama sunucunuz en az iki veritabanına bağlanır: platform işlemleri için merkezi veritabanı ve uygulama sorguları için kiracıya özel veritabanı. Birden fazla veritabanı bağlantısını Laravel database.php yapılandırmanızda ayarlayın ve her model için uygun bağlantıyı kullanın.

Ölçeklenme Dikkatleri

Paylaşılan Veritabanı Ölçeklenmesi

Önce paylaşılan veritabanını dikey olarak (daha büyük bir Deploynix veritabanı sunucusu) ölçeklendirin, sonra yatay olarak okuma kopyalarıyla genişletin. Deploynix’te ek veritabanı sunucuları tahsis edebilir ve Laravel’in yerleşik oku/yaz veritabanı bağlantılarını yapılandırarak okuma ağırlıklı sorguları kopyalara yönlendirebilirken yazma işlemlerinin birincil veritabanına yönlendirilmesini sağlayabilirsiniz.

Deploynix’in Valkey önbellek sunucuları, veritabanı yükünü önemli ölçüde azaltır. Pahalı sorguları, oturum verilerini ve hesaplanan sonuçları önbelleğe alın. Laravel’in önbellek etiketlerini kullanarak kiracı verileri değiştiğinde önbellek girişlerini geçersiz kılın.

Kiracı Başına Veritabanı Ölçeklenmesi

Kiracı başına veritabanını ölçeklendirmek, kiracıları daha fazla veritabanı sunucusuna dağıtmayı gerektirir. Bu durum, her sunucunun bir kiracı alt kümesini işlemesi sayesinde doğal olarak ölçeklenir. Zorluk, daha fazla sunucunun, daha fazla yedekleme ve daha fazla izleme ile yönetilmesi olan operasyonel aşamadır.

Deploynix’in sağlık uyarılarını kullanarak her veritabanı sunucusunu izleyin. Disk kullanımına (kiracı veritabanları farklı hızlarda büyür), bağlantı sayılarına ve sorgu gecikmesine yönelik uyarı eşik değerleri ayarlayın.

Karar Verme

İşte basit bir karar matrisine göz atın:

Paylaşılan veritabanını seçin eğer birçok küçük ve orta ölçekli kiracınız varsa, düzenleyici ayrıştırma gereksinimleriniz yoksa, kiracılar arası analiz ihtiyaçlarınız varsa ve operasyonel karmaşıklığı en aza indirmek istiyorsanız.

Kiracı başına veritabanını seçin eğer veri izolasyonu için düzenleyici gereksinimleriniz varsa, kurumsal müşterileriniz bunun için sözleşmeli olarak gerektiriyorsa, kiracı bazında performans garantileri istiyorsanız veya kiracı bazında basit veri işlemleri (yedekleme, geri yükleme, dışa aktarma) gerekiyorsa.

Hibrit bir model seçin eğer platform çapında işlemlerin (faturalama, analiz) basit olmasını istiyorsanız fakat kiracı verileri için uygulama verilerine ayrışma ihtiyacınız varsa.

Sonuç

Her iki kiracılık modeli de Deploynix üzerinde iyi çalışır. Paylaşılan veritabanı modeli, Deploynix’in veritabanı sunucu tedarikinden, otomatik yedeklemelerden ve izleme özelliklerinden faydalanarak basit ve verimli bir mimari sağlar. Kiracı başına veritabanı modeli, Deploynix’in birçok veritabanı sunucusunu bulut sağlayıcıları arasında dağıtma yeteneğinden faydalanır ve her biri için bağımsız monitorizasyon ve yedekleme sağlar.

Bu kararın, teorik kaygılara değil gerçek gereksinimlere dayalı olarak dikkatlice alınması önemlidir. Özel bir, belgelendirilmiş nedeniniz yoksa paylaşılan veritabanı modeli ile başlayın. Daha sonra kiracı başına veritabanlarına geçiş yapmanız her zaman mümkün olsa da (acı verici olmakla birlikte), tersine geçiş neredeyse imkansızdır.