Veritabanı Sunucusunu Uygulama Sunucusundan Ayırmak Ne Zaman Mantıklı?

Veritabanı Sunucusunu Ayırma Kararını Neden Bu Kadar Düşünmek Gerek?

MySQL veya PostgreSQL kullanan çoğu web uygulaması, ilk günlerinde tek bir sunucu üzerinde başlar: Aynı makinada hem PHP/Laravel ya da Node.js uygulamanız çalışır, hem de veritabanınız barınır. Kurulum kolaydır, maliyet düşüktür ve ilk aşamada gayet iyi iş çıkarır. Ancak proje büyüdükçe, özellikle okuma-yazma trafiği arttığında, raporlama ihtiyaçları çoğaldığında ve güvenlik beklentileri sertleştikçe şu soru masaya gelir: Veritabanı sunucusunu uygulama sunucusundan ayırmanın zamanı geldi mi?

Bir kapasite planlama toplantısında CPU grafikleri, disk I/O değerleri ve yavaş sorgu logları açıldığında, bu karar teknik ve iş tarafını doğrudan etkileyen stratejik bir konuya dönüşür. Fazla erken ayırırsanız gereksiz karmaşıklık ve maliyet eklersiniz; geç kalırsanız performans sorunları, kesintiler ve veri bütünlüğü riskleriyle uğraşırsınız. Bu rehberde, MySQL/PostgreSQL tabanlı web uygulamaları için ne zaman tek sunucuda kalmanın mantıklı, ne zaman ayrı veritabanı sunucusuna geçmenin zorunlu hale geldiğini; ayrıca bu geçişte izlemeniz gereken mimari seçenekleri, pratik eşik değerlerini ve DCHost altyapısında nasıl konumlandırabileceğinizi detaylı şekilde ele alacağız.

Tek Sunucu Mimarisi: Ne Zaman Yeterli, Ne Zaman Sınırda?

Monolitik kurulumun tipik yapısı

Tek sunucu mimarisinde genellikle aşağıdakilerin tamamı aynı makinadadır:

• Web sunucusu (Nginx, Apache, LiteSpeed vb.)
• Uygulama katmanı (PHP-FPM, Node.js, Python, Ruby vb.)
• Veritabanı (MySQL/MariaDB veya PostgreSQL)
• Önbellek (Redis/Memcached, kuruluysa)

Bu yapı, özellikle erken aşama projeler, kurumsal iç uygulamalar ve düşük-orta trafik alan web siteleri için son derece pratiktir. Yönetimi kolaydır, ağ gecikmesi neredeyse yoktur (localhost bağlantısı) ve maliyet açısından verimlidir. DCHost üzerinde tek bir güçlü VPS veya bir fiziksel dedicated sunucu ile uzun süre bu mimariyle ilerleyebilirsiniz.

Tek sunucu mimarisinin avantajları

• Düşük gecikme: Uygulama ile veritabanı arasında ağ üzerinden değil, yerel soket veya localhost üzerinden iletişim kurulur. Özellikle sık ve küçük sorgular için ciddi avantaj sağlar.
• Basit yönetim: Tek sunucu, daha az hareketli parça demektir. Log toplama, izleme, backup senaryoları daha düz ve tahmin edilebilirdir.
• Düşük başlangıç maliyeti: Yeni başlayan projelerde ikinci bir sunucunun lisans, yönetim ve operasyon maliyetlerini düşünmek zorunda kalmazsınız.
• Kolay hata ayıklama: Uygulama ve veritabanı loglarını aynı yere toplayıp korelasyon kurmak daha rahattır.

Tek sunucunun sınırlarına yaklaştığınızı gösteren işaretler

Belli metrikler ve semptomlar, artık veritabanını ayrı bir sunucuya taşıma zamanının yaklaştığını gösterir:

• Sürekli yüksek CPU kullanımı: Özellikle MySQL/PostgreSQL proseslerinin CPU yüzdesi uzun süre %70-80 üzerindeyse.
• Disk I/O tıkanıklığı: Linux üzerinde iowait oranlarının yüksek olması, vmstat, iostat çıktılarında diskin kilitlendiğinin görülmesi.
• Artan bellek baskısı: Uygulama belleği ve veritabanı buffer’ları (MySQL InnoDB buffer pool veya PostgreSQL shared_buffers) birbirini yemeye başlıyorsa.
• Yavaş sorgu şikayetleri: Özellikle kampanya saatlerinde, yoğun raporlama dönemlerinde sorgu sürelerinin belirgin artması.
• Dağıtım sırasında kesinti zorunluluğu: Uygulamayı güncellemek için tüm sunucuyu resetlemek zorunda kalmanız ve bunun veritabanını da etkilemesi.

Bu noktaya gelmeden önce elbette veritabanı tuning yapmalısınız. Örneğin WooCommerce sitelerinde InnoDB ayarlarını optimize etmek için hazırladığımız MySQL/InnoDB tuning kontrol listesi rehberimiz bu aşamada çok işinize yarar. Benzer şekilde PostgreSQL tarafında shared_buffers ve work_mem gibi temel parametreleri nasıl optimize edeceğinizi anlattığımız rehberi mutlaka inceleyin. Buna rağmen kaynaklar hala sınıra dayanıyorsa, artık mimariyi konuşma vaktidir.

Veritabanını Ayırmak: Ne Kazanırsınız, Ne Kaybedersiniz?

Ayrı veritabanı sunucusunun temel fikri

Bu mimaride uygulama ve veritabanı, farklı sunuculara dağıtılır:

• Uygulama sunucuları: HTTP trafiğini karşılar, iş mantığını çalıştırır.
• Veritabanı sunucusu: Sadece MySQL/PostgreSQL proseslerini ve ona eşlik eden replikasyon, backup, izleme ajanlarını barındırır.

İlerleyen aşamalarda uygulama katmanını birden fazla VPS veya fiziksel sunucuya yayarken, veritabanı katmanını ayrı bir dedicated sunucuya veya yüksek IOPS’lu özel bir VPS’e taşıyabilirsiniz. DCHost tarafında genellikle şu modele doğru evrilme görüyoruz: Web/app katmanı için ölçeklenebilir VPS’ler + güçlü disk altyapısına sahip ayrı veritabanı sunucusu.

Avantajlar: Neden ayırmaya değer?

• Kaynak izolasyonu: Uygulama kodundaki bir hafıza sızıntısı, veritabanının RAM’ini tüketip tüm sistemi çökertemez. Disk I/O baskısını da veritabanı tarafında izole edersiniz.
• Bağımsız ölçeklenebilirlik: Trafik artışında uygulama sunucularını yatayda çoğaltabilir, veritabanını ise dikeyde (daha fazla RAM, daha hızlı NVMe disk) büyütebilirsiniz.
• Daha iyi tuning imkanı: Veritabanı sunucusunda işletim sistemi, kernel ve dosya sistemi ayarlarını tamamen veritabanına göre optimize edebilirsiniz.
• Güvenlik: Veritabanı sunucusunu doğrudan internete hiç açmadan, sadece uygulama sunucularının bağlı olduğu özel bir ağda tutabilirsiniz. Bu da saldırı yüzeyini ciddi şekilde azaltır.
• Bakım esnekliği: Uygulama dağıtımı, PHP versiyon güncellemesi ya da web sunucusu değişimi yaparken veritabanını yerinde ve çalışır halde tutabilirsiniz.

Dezavantajlar: Her zaman otomatik kazanım değildir

• Ağ gecikmesi: Artık veritabanına her sorgu, ağ üzerinden gider. DCHost gibi düşük gecikmeli veri merkezi ağlarında bile bu fark hissedilebilir; özellikle çok sayıda küçük sorgu yapan kötü optimize edilmiş uygulamalarda.
• Artan karmaşıklık: Ağ tasarımı, güvenlik duvarı kuralları, bağlantı havuzu (connection pooling), izleme gibi katmanlar devreye girer.
• Ek maliyet: İkinci bir sunucu kiralamak, yedekleme ve izleme altyapısını büyütmek anlamına gelir. Küçük projelerde bu yatırım geri dönmeyebilir.
• Yanlış yapılandırma riski: Örneğin veritabanı sunucusu ile uygulama sunucusunu farklı lokasyonlarda konumlandırırsanız (farklı ülkeler veya kıtalar gibi) gecikme dramatik şekilde artabilir.

MySQL/PostgreSQL İçin Karar Eşikleri: Ne Zaman Ayırmalı?

1) Kaynak kullanımı ve metrikler

Teknik tarafta sıkça kullandığımız bazı pratik eşikler şunlar:

• CPU: Normal iş yükü altında (pik değil) veritabanı proseslerinin CPU kullanımı sürekli %60-70’in üzerindeyse ve sorgu optimizasyonu ile rahatlatamıyorsanız.
• RAM: MySQL InnoDB buffer pool veya PostgreSQL shared_buffers değerlerini artırmak istiyor ancak aynı sunucuda uygulama için yeterli RAM bırakamıyorsanız.
• Disk: SSD/NVMe diskinizin IOPS kapasitesini sık sık zorluyor, iowait oranları yükseliyorsa.
• Bağlantı sayısı: MySQL veya PostgreSQL bağlantı sayısı, sistem limitlerine sürekli dayanıyorsa ve connection pooling ile çözemiyorsanız.

Bu metrikleri zaten takip etmiyorsanız, önce izleme kurmak gerekir. DCHost üzerindeki VPS veya dedicated sunucularınızda Prometheus + Grafana ya da benzer çözümlerle metrik toplayıp alarmlar kurmanızı öneriyoruz.

2) İş ihtiyaçları: Güvenlik, uyumluluk, rollerin ayrımı

Bazen performans değil, güvenlik ve regülasyon tarafı kararı zorlar:

• Kredi kartı verisi, sağlık verisi veya KVKK kapsamındaki hassas kişisel verileri tutuyorsanız.
• Veri tabanına erişim yetkilerini, sunucu erişim yetkilerinden tamamen ayrı yönetmek istiyorsanız.
• Denetimlerde (audit) veritabanı sunucusunun çok daha sıkı politikalarla yönetilmesi bekleniyorsa.

Bu tür senaryolarda veritabanını, uygulama sunucularından ayrı ACL’lere, ayrı yönetim politikalarına sahip özel bir sunucuya almak anlamlı olur. Örneğin DCHost üzerinde uygulama katmanınızı yönetilen VPS’lerde, veritabanınızı ise sadece sınırlı IP’lerden erişilebilen bir dedicated sunucuda konumlandırabilirsiniz.

3) Ölçeklenme planları ve yol haritası

Projede önümüzdeki 6-12 ay için net bir büyüme beklentisi varsa, mimariyi erkenden hazırlamak mantıklıdır:

• Beklenen trafik artışı ile sorgu sayısının katlanacağını biliyorsanız.
• Okuma yoğunluklu raporlama, analitik veya mobil uygulama entegrasyonları gündemdeyse.
• İleride birden fazla uygulamanın (örneğin mobil API, yönetim paneli, raporlama aracı) aynı veritabanına bağlanacağını biliyorsanız.

Bu durumlarda veritabanını merkezde konumlandırıp uygulama katmanını esnek tutmak gelecekteki değişimleri kolaylaştırır. Daha ileri aşamada çok bölgeli mimariler ve veritabanı replikasyonu ile felaket dayanıklılığı kurmak istediğinizde, veritabanı katmanının baştan ayrı tasarlanmış olması avantaj sağlar.

MySQL Özelinde Mimari Seçenekler

1) Tek primary, tek uygulama kümesi

En sık gördüğümüz ilk adım mimarisi şöyle:

• 1 veya daha fazla uygulama sunucusu (VPS veya fiziksel)
• 1 adet MySQL/MariaDB primary sunucusu

Burada tüm okuma ve yazma trafiği aynı veritabanı sunucusuna gider. Bu aşamada kazanımınız, veritabanı kaynaklarının izole edilmesi ve daha agresif tuning yapma imkanıdır. Disk tarafında NVMe depolama kullanıyorsanız, çoğu orta ölçekli proje için uzun süre yeterli performans sağlar.

2) Primary + read replica ile ölçekleme

Okuma trafiğiniz çok yüksekse, MySQL replikasyonu kullanarak bir veya birden fazla read replica ekleyebilirsiniz. Tipik model:

• 1 adet primary (yazmalar ve kritik okumalar)
• 1-2 adet read replica (raporlama, listeleme sayfaları, düşük tutarlılık gerektiren okuma istekleri)

Bu yapıyı uygulama tarafında doğru yönetmek için çoğu zaman bir bağlantı havuzu ve route eden bir katman gerekir. Örneğin MySQL için ProxySQL ile read/write ayrıştırma ve bağlantı havuzu kurulumunu adım adım anlattığımız rehber, uygulama kodunu minimum değiştirmek isteyenler için çok değerlidir.

3) Yüksek erişilebilirlik: Galera, Group Replication vb.

Eğer işiniz için veritabanı kesintisi kabul edilemez seviyedeyse, tek primary modelinden ziyade küme (cluster) çözümlerine bakmak gerekir. Örneğin MariaDB Galera Cluster veya MySQL Group Replication gibi çözümlerle aynı anda birden çok düğüm üzerinde veri tutabilirsiniz. Bu tür senaryoları, yüksek erişilebilir MySQL/MariaDB küme mimarilerinden bahsettiğimiz rehberimizde detaylıca işlemiştik.

Bu tür HA mimarilerinde veritabanı sunucusunu uygulama sunucusundan ayırmak artık bir tercih değil, zorunluluk haline gelir; çünkü cluster düğümlerini farklı fiziksel sunuculara dağıtmanız gerekir.

PostgreSQL Özelinde Mimari Seçenekler

1) Tek PostgreSQL sunucusunu maksimum verimle kullanmak

PostgreSQL, doğru ayarlandığında tek bir sunucuda oldukça yüksek yükleri kaldırabilir. Öncelikle:

• shared_buffers, work_mem, maintenance_work_mem gibi parametreleri bellek yapınıza göre ayarlamak,
• WAL (write-ahead log) ayarlarını disk hızınıza ve yedekleme stratejinize göre optimize etmek,
• Autovacuum’u doğru tune etmek

gerekir. Bunların tamamını tek sunucuda yapabilirsiniz. PostgreSQL tuning için hazırladığımız detaylı ayar rehberindeki pratik önerileri uyguladıktan sonra bile hala sınırdaysanız, ayrı veritabanı sunucusuna geçmek gündeme gelir.

2) Connection pooling ve PgBouncer

PostgreSQL her bağlantı için ayrı bir işlem (process) oluşturur. Çok sayıda kısa ömürlü bağlantı açan uygulamalar, veritabanını gereksiz yere yorar. Bu sorunu çözmek için sıklıkla PgBouncer veya benzeri connection pooler kullanılır. Uygulama sunucularınız ile PostgreSQL sunucunuz ayrıysa, PgBouncer’ı:

• Uygulama sunucularının yanında (her app sunucusunda ayrı),
• Veya ayrı bir küçük “pooler” sunucusunda

konumlandırabilirsiniz. Buradaki kritik nokta, ağ trafiğini gereksiz yere dallandırmamak ve gecikmeyi minimumda tutmaktır.

3) Streaming replication ve read replica

PostgreSQL’de streaming replication kullanarak read replica (standby) kurmak oldukça yaygındır. Özellikle raporlama, BI araçları veya ağır SELECT sorguları için production primary sunucusunu yormak istemediğinizde:

• Primary: Yazma ağırlıklı iş yükü, kritik işlemler
• Standby(ler): Raporlama, analitik, düşük tutarlılık gerektiren okuma istekleri

şeklinde bir dağılım planlayabilirsiniz. Çok bölgeli PostgreSQL replikasyonu kurmak isterseniz, yine çok bölgeli mimari rehberimizde bahsettiğimiz DNS yönlendirme ve failover stratejilerini göz önünde bulundurmak gerekir.

Ayrı Veritabanı Sunucusuna Geçiş İçin Pratik Yol Haritası

1) Önce verileri ve kalıpları anlayın

Rastgele “bir sunucu daha açalım” yerine, önce iş yükünüzü anlamaya başlayın:

• En sık çalışan sorgular hangileri? (slow query log, pg_stat_statements)
• Okuma/yazma oranı nedir?
• Tipik ve pik anlarda saniyedeki sorgu sayısı (QPS) nedir?
• Hangi tablolar en büyük ve en yoğun kullanılanlar?

Bu analiz, yeni veritabanı sunucusunun CPU/RAM/disk profilini doğru seçmenizi sağlar. DCHost üzerinde NVMe diskli VPS’ler veya daha ağır iş yükleri için dedicated sunucular bu ihtiyaca göre boyutlandırılabilir.

2) Backup ve geri dönüş planını netleştirin

Veritabanını ayırma projesi, aynı zamanda yedekleme stratejisini gözden geçirmek için ideal zamandır. MySQL/PostgreSQL için uygulama-tutarlı yedekler almayı, LVM snapshot ve fsfreeze gibi tekniklerle detaylandırdığımız rehbere mutlaka göz atın. Geçiş öncesi:

• Güncel tam yedek (full backup)
• Yedekten geri dönüş testinin gerçekten yapılmış olması
• Gerekirse Point-in-Time Recovery (PITR) stratejisinin hazır olması

şarttır. Taşıma sırasında beklenmedik bir sorun yaşarsanız, hızlıca eski duruma dönebilmelisiniz.

3) Ağ topolojisini ve güvenlik duvarını planlayın

Uygulama ve veritabanı sunucularınız:

• Aynı veri merkezinde
• Mümkünse aynı ağ segmentinde (aynı bölge / availability zone eşleniği)

olmalı. Aradaki gecikmeyi minimize etmek için çapraz bölge veya farklı ülke trafiğinden kaçının. Güvenlik duvarı tarafında ise:

• MySQL (3306) veya PostgreSQL (5432) portlarını sadece uygulama sunucularının IP’lerine açın.
• Mümkünse VPN veya özel ağ (private network) üzerinden bağlanın.
• SSH erişimini sadece yönetim IP’leriyle sınırlayın.

4) Geçiş senaryosu: minimum kesinti için adımlar

Basitleştirilmiş bir taşıma planı şöyle olabilir:

1. Yeni veritabanı sunucusunu kurun, MySQL/PostgreSQL versiyonlarını ve ayarlarını üretimle uyumlu hale getirin.
2. Eski sunucudan yeni sunucuya ilk tam veri kopyasını (mysqldump, pg_dump veya fiziksel kopya) alın.
3. Replikasyon kurarak ikisini kısa süre senkron çalıştırın (mümkünse).
4. Bakım penceresi belirleyip uygulamayı kısa süre “read-only” moda alın.
5. Son delta verisini aktarın, uygulama konfigurasyonunda veritabanı bağlantı bilgilerini yeni sunucuya yönlendirin.
6. Uygulamayı tekrar normal moda alın ve metrikleri yakından izleyin.

DCHost tarafında, bu süreçlerde genellikle test ortamı için ek bir VPS üzerinde prova yapılmasını, ardından canlı taşımanın adım adım ilerletilmesini öneriyoruz.

Sonuç: Herkes İçin Ayrı Veritabanı Sunucusu Şart mı?

Özetlemek gerekirse, her proje için baştan ayrı veritabanı sunucusu şart değildir. Küçük ve orta ölçekli pek çok web uygulaması, iyi yapılandırılmış tek bir güçlü sunucuyla yıllarca sorunsuz çalışabilir. Önemli olan, ne zaman dar boğaza girdiğinizi anlayacak metrikleri izlemek ve bu sinyalleri görmezden gelmemektir. CPU, RAM ve disk I/O sınırlarına yaklaşıyor; güvenlik ve regülasyon beklentileriniz artıyor; ölçeklenme planlarınız netleşiyorsa, veritabanını ayırmak hem performans hem de operasyonel esneklik açısından büyük fark yaratır.

DCHost olarak pratik önerimiz, önce veritabanı tuning ve izleme ile mevcut sunucunuzu maksimum verimle kullanmanız; ardından net sinyaller geldiğinde planlı bir şekilde ayrı veritabanı sunucusuna geçmeniz yönünde. İster NVMe VPS, ister dedicated sunucu, ister colocation altyapısı kullanın; uygulama ve veritabanı katmanını doğru şekilde konumlandırdığınızda, hem performans hem de kesintisizlik tarafında rahat bir nefes alırsınız. Kendi projeniz özelinde hangi mimarinin daha doğru olduğuna emin olamıyorsanız, DCHost ekibiyle birlikte mevcut iş yükünüzü analiz edip, adım adım uygulanabilir bir mimari yol haritası çıkarmakla başlayabilirsiniz.