Multi-Tenant ERP: Paylaşımlı Schema'nın Riskleri ve Alternatifler

Multi-Tenant ERP’de Paylaşımlı Schema Yaklaşımı Neden Riskli?

Bir üretim ERP’sinde, farklı müşteriler için aynı veritabanı üzerinde izole edilmiş veri yapıları kurmak yerine, tüm müşterilerin verilerini tek bir veritabanı içerisinde, ancak farklı tablolar veya sütunlar aracılığıyla yönetmeye çalıştığımız bir senaryo hayal edin. İşte bu, “paylaşımlı schema” (shared schema) yaklaşımının temelini oluşturuyor. Bu yaklaşım ilk bakışta kaynakları verimli kullanma ve yönetim kolaylığı gibi cazip avantajlar sunsa da, özellikle kurumsal düzeyde ve hassas verilerle uğraşan ERP sistemlerinde ciddi riskler barındırıyor. Yıllardır sistem mimarisi ve veritabanı yönetimi alanında edindiğim tecrübeler gösteriyor ki, bu tür bir “ucuz” çözüm uzun vadede çok daha pahalıya mal olabiliyor.

Bu yazıda, paylaşımlı schema yaklaşımının neden bir tuzak olduğunu, hangi teknik ve güvenlik sorunlarına yol açtığını, gerçek dünya senaryolarından örneklerle ve somut verilerle derinlemesine inceleyeceğiz. Ayrıca, bu risklerden kaçınmak için hangi alternatif mimari yaklaşımların daha güvenli ve ölçeklenebilir olduğunu da tartışacağız. Amacım, karşılaştığınızda “işte bu yüzden bu yolu seçmemeliymişim” dedirtecek kadar net bir analiz sunmak.

Paylaşımlı Schema’nın Cazibesi ve İlk Görünen Avantajları

Paylaşımlı schema mimarisi, en basit haliyle, birden fazla “tenant”ın (müşteri, kullanıcı grubu veya departman) verilerinin, aynı veritabanı sunucusu üzerinde, genellikle aynı veritabanı içinde ancak farklı tablolarda veya aynı tablolarda ek bir tenant ID sütunu kullanılarak saklanması anlamına gelir. Bu modelin ilk akla gelen avantajları şunlardır:

• Kaynak Optimizasyonu: Tek bir veritabanı sunucusu ve tek bir veritabanı örneği, birden fazla veritabanı örneğine kıyasla daha az donanım kaynağı (CPU, RAM, disk) gerektirebilir. Bu, özellikle başlangıç maliyetlerini düşürmek isteyen projeler için çekici olabilir.
• Yönetim Kolaylığı: Tek bir veritabanı örneğini yedeklemek, bakımını yapmak ve güncellemeleri uygulamak, yüzlerce veya binlerce ayrı veritabanı örneğini yönetmekten daha basittir. Otomatikleştirme script’leri daha az karmaşık hale gelir.
• Veritabanı Maliyeti: Lisans maliyetleri (özellikle ticari veritabanlarında) veritabanı örnek sayısına göre hesaplanıyorsa, paylaşımlı schema maliyetleri önemli ölçüde düşürebilir.
• Geliştirme Hızı (İlk Aşama): Uygulama geliştirme ekibi için, tek bir veritabanı şeması üzerinde çalışmak, her tenant için ayrı bir veritabanı altyapısı kurma ve yönetme karmaşıklığıyla uğraşmak zorunda kalmadıkları için daha hızlı başlayabilir.

Bir zamanlar, küçük ölçekli projelerde veya iç araçlarda bu tür bir yaklaşımı düşündüğüm olmuştu. Örneğin, kendi kişisel blogumun veya basit bir görev yönetim aracımın kullanıcı verilerini tek bir veritabanında yönetmek, ayrı bir PostgreSQL instance’ı kurmaktan daha pratik görünüyordu. Ancak, bu kararı verirken göz ardı ettiğim veya yeterince önemsemediğim bazı kritik faktörler vardı ki, bunlar kurumsal düzeydeki ERP uygulamaları için tamamen felaket senaryoları doğurabiliyor.

Veri İzolasyonu Sorunları: Güvenlik ve Uyumluluk Açmazı

Paylaşımlı schema’nın en büyük zayıflığı, tenant’lar arasındaki veri izolasyonunu sağlamanın zorluğudur. “Shared schema” denince akla gelen iki ana yaklaşım vardır:

1. Shared Database, Shared Schema: Tüm tenant’ların verileri aynı veritabanı içinde aynı tablolarda tutulur. Her tablonun bir tenant_id sütunu bulunur ve sorgular bu tenant_id’ye göre filtrelenir.
2. Shared Database, Separate Schemas: Tüm tenant’lar aynı veritabanı sunucusu üzerinde yaşar, ancak her tenant için ayrı bir veritabanı schema’sı (PostgreSQL’de olduğu gibi) oluşturulur.

İlk yaklaşım (shared schema) en riskli olanıdır. tenant_id sütununu her sorguda doğru şekilde belirtmek, uygulamanın sorumluluğundadır. Eğer bir geliştirici bu filtrelemeyi atlar veya yanlışlıkla başka bir tenant’ın verisine erişebilecek bir sorgu yazarsa, veri gizliliği ihlali kaçınılmaz olur.

Örneğin, bir e-ticaret ERP’sinde, müşteri A’nın siparişlerini listelemek istediğinizde, uygulamanın arka planda şu sorguyu çalıştırması gerekir:

SELECT * FROM orders WHERE tenant_id = 'müşteri_a_id';

Eğer geliştirici WHERE tenant_id = 'müşteri_a_id' kısmını unutursa veya yanlışlıkla WHERE tenant_id = 'müşteri_b_id' yazarsa, bu, diğer müşterinin hassas sipariş bilgilerinin sızdırılmasına yol açar. Bu tür hatalar, özellikle büyük ekiplerde ve hızlı geliştirme döngülerinde sıkça yaşanabilir. Bir üretim firmasının ERP’sinde, bir operatör ekranında kullanıcının yalnızca kendi bölümünün üretim emirlerini görmesi gerekiyordu; ancak filtreleme eksikliğinden kaynaklanan bir bug nedeniyle tüm fabrikanın üretim emirlerini görebiliyordu. Bu basit bir tenant_id eksikliğiydi ve sonuçları ciddi bir veri gizliliği riskiydi.

Ayrıca, GDPR, KVKK gibi veri koruma regülasyonları, kişisel verilerin izole edilmesini ve yetkisiz erişime karşı korunmasını zorunlu kılar. Paylaşımlı schema modelinde bu uyumluluğu sağlamak, her sorgunun doğru şekilde filtrelendiğinden emin olmak anlamına gelir ki bu da insan hatasına oldukça açıktır.

Performans ve Ölçeklenebilirlik Kısıtlamaları

Paylaşımlı schema’nın bir diğer önemli sorunu, performans ve ölçeklenebilirlik konusundaki kısıtlamalarıdır. Tenant sayısı arttıkça veya tekil tenant’ların veri hacmi büyüdükçe, aynı veritabanı ve tablolar üzerinde yoğunlaşan okuma/yazma işlemleri ciddi performans darboğazlarına yol açar.

Örneğin, bir tablonun milyonlarca satır içerdiğini ve bu satırların her birinde farklı tenant’lara ait veriler olduğunu düşünelim. Bu tabloda tenant_id’ye göre indeksleme yapılsa bile, sorgular genellikle bu devasa indeksi taramak zorunda kalacaktır. Bir tenant’ın sorgusu, diğer tenant’ların verilerini de etkileyebilecek I/O operasyonlarına neden olabilir.

Aynı veritabanı içinde farklı satıcılar için veri tutan bir sipariş yönetimi yapısında, yeni bir satıcı sisteme katıldığında veya mevcut satıcıların işlem hacmi arttığında tüm sistem yavaşlayabilir. orders tablosunda seller_id’ye göre indeks olsa bile sorguların genel performansı düşer; çünkü sorun yalnızca sorgunun ilgili satıcının verisini getirmesi değil, aynı zamanda veritabanı sunucusunun genel yükünün artmasıdır. Bir satıcının yaptığı yoğun işlem, diğer satıcıların işlemlerini de etkiler. Bu durum, paylaşımlı schema’nın ölçeklenebilirlik sınırlarını açıkça gösterir.

Ayrıca, bir tenant’ın veri tabanında yaptığı yoğun bir işlem (örneğin, büyük bir rapor çalıştırma veya toplu veri güncelleme), diğer tüm tenant’ların işlemlerini engelleyebilir veya yavaşlatabilir. Bu “noisy neighbor” problemi olarak bilinir ve paylaşımlı kaynakların doğasında vardır.

Yönetim ve Bakım Zorlukları

İlk bakışta yönetim kolaylığı sunan paylaşımlı schema, aslında uzun vadede ciddi bakım ve operasyonel zorluklar yaratır.

Yedekleme ve Geri Yükleme

Tüm tenant’ların verisinin tek bir veritabanında olması, yedekleme ve geri yükleme süreçlerini karmaşıklaştırır. Diyelim ki bir tenant’ın verisi bozuldu veya yanlışlıkla silindi. Geriye dönük yedekten sadece o tenant’ın verisini izole etmek, özellikle shared schema yaklaşımında çok zordur. Genellikle tüm veritabanını geri yükleyip, ardından diğer tenant’ların verilerini yeniden ayıklamanız gerekir ki bu da hem zaman alıcı hem de risklidir.

Örneğin, PostgreSQL’de pg_dump ile tüm veritabanını yedeklerseniz, geri yüklerken tüm veritabanını geri yüklersiniz. Eğer sadece bir tenant’ın verisini geri yüklemek isterseniz, bu durumda özel script’ler yazmanız veya veritabanının iç yapısını anlamanız gerekir. Bir keresinde, bir müşteri projesinde, belirli bir tenant_id’ye ait verilerin yanlışlıkla silindiğini fark ettik. Geriye dönük yedekten sadece o verileri çekmek ciddi zaman aldı. Bu, tenant_id sütununu filtreleyerek ve INSERT komutları üreterek yapıldı. Bu operasyon sırasında hata yapma ihtimali de yüksekti.

Schema Güncellemeleri

Uygulama güncellendiğinde veritabanı şemasında değişiklikler yapılması gerekebilir. Paylaşımlı schema’da yapılan her şema değişikliği, potansiyel olarak tüm tenant’ları etkiler. Eğer bir şema güncellemesi bir tenant için uyumsuzluk yaratırsa veya bir bug içeriyorsa, bu tüm sistemi etkileyebilir. A/B testing veya canary deployments gibi kontrollü dağıtım stratejilerini uygulamak zorlaşır.

Örneğin yeni bir raporlama özelliği için sipariş tablolarına yalnızca bazı müşterilere gereken bir sütun eklemek istediğinizde, paylaşımlı schema’da bunu yönetmek zordur. Pratikte tüm müşterilerin tablolarına bu sütunu eklemek ve yalnızca ilgili müşterilerin arayüzünde göstermek gibi bir yola gidilir; bu da hem gereksiz veri depolamaya yol açar hem de gelecekteki sorgu performansını olumsuz etkiler.

Veritabanı Yönetimi ve Bakım

Veritabanı optimizasyonu, indeks yönetimi, VACUUM işlemleri gibi rutin bakım görevleri, paylaşımlı schema’da daha karmaşık hale gelir. Bir tenant’ın yoğun aktivitesi, genel veritabanı sağlığını bozabilir. Örneğin, VACUUM işlemleri, tüm veritabanını etkileyebilir ve bu sırada performans düşüşlerine neden olabilir.

Güvenlik Açıkları ve Sızma Noktaları

Paylaşımlı schema mimarisi, uygulamanın kendisinde veya veritabanı katmanında çeşitli güvenlik açıklarına kapı aralar.

SQL Injection Riski

Daha önce de bahsettiğimiz gibi, tenant_id filtrelemesinin atlanması en yaygın SQL injection türlerinden biridir. Ancak, bu sadece tenant_id ile sınırlı değildir. Uygulamanın başka yerlerinde de benzer mantık hataları, yetkisiz veri erişimine yol açabilir.

Yetkilendirme Karmaşası

Her tenant’ın kendi içindeki kullanıcıları için farklı yetkilendirme seviyeleri olabilir. Paylaşımlı schema’da bu yetkilendirmeyi yönetmek, tenant_id’nin yanı sıra user_id ve role gibi ek filtrelemeler gerektirir. Bu da sorguları daha karmaşık hale getirir ve hata yapma olasılığını artırır.

Veritabanı Güvenlik Yamaları

Paylaşımlı veritabanı örneği, tüm tenant’lar için tek bir güvenlik yaması veya güncelleme gerektirir. Eğer veritabanında bilinen bir güvenlik açığı varsa ve bu yama hemen uygulanmazsa, tüm tenant’lar risk altında demektir. Bu durum, özellikle kurumsal müşterilerin hassasiyetleri göz önüne alındığında kabul edilemez.

Alternatif Mimari Yaklaşımlar

Paylaşımlı schema’nın risklerini göz önüne aldığımızda, daha güvenli ve ölçeklenebilir alternatiflere yönelmek kaçınılmazdır.

1. Veritabanı Başına Tenant (Database per Tenant)

Bu yaklaşımda, her tenant için tamamen ayrı bir veritabanı örneği oluşturulur. Bu, en yüksek izolasyonu sağlar.

• Avantajları:
  • Maksimum Veri İzolasyonu: Bir tenant’ın verisi diğerini kesinlikle etkilemez.
  • Gelişmiş Güvenlik: Bir veritabanındaki güvenlik ihlali diğerlerini etkilemez.
  • Basit Yönetim: Her veritabanı bağımsız olduğu için yedekleme, geri yükleme, schema güncelleme işlemleri daha kolaydır.
  • Performans: Tenant’lar birbirlerinin performansını etkilemez.
  • Özelleştirme: Her tenant için özel veritabanı ayarları veya indeksler tanımlanabilir.
• Dezavantajları:
  • Yüksek Maliyet: Daha fazla sunucu, lisans ve yönetim kaynağı gerektirir.
  • Yönetim Karmaşıklığı: Binlerce veritabanını yönetmek otomasyon gerektirir.
  • Kaynak İsrafı: Boşta duran veritabanı örnekleri kaynak israfına neden olabilir.

Veri güvenliği ve performans gereksinimleri kritik olduğunda bu model öne çıkar. Özellikle büyük ölçekli üretim yapan ve hassas mali verileri tutan firmalar için bu, tartışmasız en iyi seçenektir. Ancak, başlangıç maliyetleri ve operasyonel yükü artırır.

2. Schema Başına Tenant (Schema per Tenant)

Bu model, PostgreSQL gibi bazı veritabanlarında mümkündür. Tek bir veritabanı sunucusu üzerinde, her tenant için ayrı bir veritabanı schema’sı oluşturulur.

• Avantajları:
  • İyi Veri İzolasyonu: Paylaşımlı schema’dan daha iyi izolasyon sağlar. Veritabanı seviyesinde erişim kontrolü daha kolaydır.
  • Daha Az Maliyet: Tek bir veritabanı örneği olduğu için maliyetler, database-per-tenant modeline göre daha düşüktür.
  • Yönetim Kolaylığı: Yönetim, tek bir veritabanı örneği üzerinden yapılır.
• Dezavantajları:
  • Performans Sınırları: Veritabanı sunucusu üzerindeki toplam yük arttıkça performans sorunları yaşanabilir.
  • Schema Güncelleme Zorluğu: Her schema’yı ayrı ayrı güncellemek gerekebilir (otomasyonla çözülür).
  • Tenant Sayısı Sınırı: Çok yüksek sayıda schema yönetimi, veritabanı performansını etkileyebilir.

Bu yaklaşım, orta ölçekli projeler ve belirli bir sayıda tenant’ı olan uygulamalar için iyi bir denge sunar. Kullanıcı başına ayrı schema kullanmak, veri izolasyonu ile yönetim kolaylığı arasında makul bir orta yol oluşturur.

3. Hybrid Yaklaşımlar

Bazen en iyi çözüm, farklı modelleri birleştirmektir. Örneğin:

• Küçük tenant’lar için paylaşımlı schema, büyük tenant’lar için ayrı veritabanı: Maliyet ve performans dengesi kurulabilir.
• Shardlama (Sharding): Veritabanı verilerini yatay olarak bölerek farklı sunuculara dağıtma tekniğidir. Bu, hem ölçeklenebilirliği artırır hem de veri izolasyonunu sağlayabilir. Tenant’lar, belirli bir shard’a atanabilir.

Çok büyük veri hacmine sahip senaryolarda, verileri hem tenant_id hem de bölgesel bazda shard’lara ayırmak hem performansı artırır hem de veri erişimini hızlandırır.

Sonuç: Riskleri Bilerek Hareket Etmek

Multi-tenant ERP sistemlerinde paylaşımlı schema yaklaşımı, ilk etapta cazip görünse de, uzun vadede ciddi güvenlik, performans ve yönetim sorunlarına yol açar. Özellikle hassas kurumsal verilerle uğraşırken, veri izolasyonu en üst düzeyde tutulmalıdır. Bir geliştiricinin yapacağı basit bir hata, tüm sistemin güvenliğini tehlikeye atabilir.

“Ucuz” görünen çözümler genellikle daha pahalıya patlar. Bir üretim ERP’sinin temelini oluşturan veritabanı mimarisini seçerken, başlangıç maliyetlerinden ziyade, ölçeklenebilirlik, güvenlik ve bakım kolaylığı gibi faktörlere odaklanmak gerekir. Eğer bir ERP sistemi tasarlıyorsanız veya mevcut bir sistemi yönetiyorsanız, paylaşımlı schema’nın getireceği riskleri çok iyi anlamalı ve mümkünse “schema per tenant” veya “database per tenant” gibi daha güvenli mimarilere yönelmelisiniz. Unutmayın, veritabanı, bir ERP sisteminin kalbidir ve bu kalbin sağlığı, sistemin tüm bileşenlerinin sağlığını belirler.