Bulut Veritabanı Servisleri: Cloud SQL, Azure SQL, Amazon RDS

Yönetilen Veritabanı Nedir?

Yönetilen (managed) veritabanı, altyapı ve işletim yükünün büyük bölümünü sağlayıcıya devreden bir dağıtım biçimidir. Veritabanını kendiniz çalıştırmak (self-managed) size tam kontrol verir, ama işletim yükünü de tümüyle sırtınıza yükler. Yönetilen bir serviste ise sağlayıcı; donanım sağlamayı, işletim sistemi ve motor yamalarını, otomatik yedeklemeyi, izlemeyi ve çoğunlukla otomatik yük devretmeyi (failover) üstlenir.

Bu modelin özünde paylaşılan sorumluluk yatar: sağlayıcı altyapının dayanıklılığından sorumludur; siz ise şema tasarımı, indeksler, sorgu performansı, erişim yetkileri ve verinizin doğruluğundan sorumlu kalırsınız.

Üç Servise Genel Bakış

Google Cloud SQL

Cloud SQL, Google Cloud'un yönetilen ilişkisel veritabanı servisidir. MySQL, PostgreSQL ve SQL Server motorlarını destekler. Otomatik yedekleme, noktaya dönüş kurtarma (point-in-time recovery), okuma replikaları ve yüksek erişilebilirlik yapılandırmaları sunar. Google'ın yatayda dağıtık Cloud Spanner servisinden farklı olarak Cloud SQL, klasik tek-yazıcılı ilişkisel motorları yönetir.

Azure SQL

Azure SQL, Microsoft'un SQL Server motoru etrafında kurduğu bulut ailesidir. Başlıca iki biçimi vardır: Azure SQL Database (tam yönetilen, mantıksal veritabanı düzeyinde) ve Azure SQL Managed Instance (bir SQL Server örneğiyle yüksek uyumluluk isteyen taşıma senaryoları için). SQL Server'ı sanal makinede çalıştırmak (IaaS) da bir seçenektir; ancak bu tam yönetilen sayılmaz.

Amazon RDS

Amazon RDS (Relational Database Service), AWS'nin yönetilen ilişkisel veritabanı servisidir. MySQL, PostgreSQL, MariaDB, Oracle ve SQL Server motorlarını destekler. Bunlara ek olarak AWS, MySQL ve PostgreSQL ile uyumlu, bulut-yerlisi bir motor olan Amazon Aurora'yı da sunar; Aurora, RDS'in yönetim düzlemi üzerinden işletilir ama farklı bir depolama mimarisi kullanır.

Dağıtım Modelleri: Örnek mi, Sunucusuz mu?

Üç servis de temelde ayrılmış kaynak (provisioned) modelinde çalışır: belirli bir CPU, bellek ve depolama seçersiniz. Bunun yanında talebe göre ölçeklenen esnek seçenekler de vardır. Örneğin Azure SQL Database, kullanıma göre otomatik ölçeklenen ve boştayken duraklayabilen sunucusuz (serverless) bir hesaplama katmanı sunar. Amazon Aurora'nın da kapasiteyi otomatik ayarlayan bir yapılandırması vardır.

• Ayrılmış (provisioned): Öngörülebilir, istikrarlı yük için en uygunudur; kapasiteyi siz belirlersiniz.
• Esnek / sunucusuz: Değişken ya da kesintili yükte maliyeti gerçek kullanıma yaklaştırır; sık duraklamalarda soğuk başlama gecikmesi görülebilir.
• Yüksek erişilebilirlik: Bölge içi yedekli (multi-AZ / zone-redundant) yapılandırmalar yük devretme süresini kısaltır.

Ölçeklenme: Dikey ve Yatay

İlişkisel bir veritabanını ölçeklemenin iki temel yolu vardır. Dikey ölçeklenme (scale up), örneğe daha fazla CPU, bellek veya daha hızlı disk vermek demektir; uygulaması basittir ama tek bir makinenin tavanına takılır. Yatay ölçeklenme (scale out) ise yükü birden fazla düğüme dağıtır. Klasik tek-yazıcılı motorlarda yatay ölçeklenme çoğunlukla okuma tarafında, yani okuma replikalarıyla sağlanır.

Üç serviste de okuma replikaları, okuma ağırlıklı iş yüklerini birincil (primary) düğümden ayırmanızı sağlar. Yazma işlemleri yine tek bir birincil düğüme gider; bu yüzden yazma tarafını ölçeklemek, replika eklemekten çok daha zordur. Çok yüksek yazma hacmi ve yatay dağıtım gerektiğinde, Amazon Aurora gibi bulut-yerlisi motorlar ya da Cloud Spanner gibi dağıtık sistemler devreye girer.

Bağlantı Havuzu (Connection Pooling)

Yönetilen veritabanlarında eş zamanlı bağlantı sayısı sınırlıdır ve her bağlantı bellek tüketir. Özellikle PostgreSQL'de çok sayıda kısa ömürlü bağlantı performansı düşürebilir. Bu nedenle uygulama ile veritabanı arasına bir bağlantı havuzu koymak yaygın bir uygulamadır. Sağlayıcılar bunun için yönetilen seçenekler sunabilir; alternatif olarak PgBouncer gibi ara katmanlar kullanılır.

İzleme ve Gözlemlenebilirlik

Yönetilen servisler, temel metrikleri (CPU, bellek, disk, bağlantı sayısı, IOPS) sağlayıcının izleme paneline aktarır. Bunun üzerine yavaş sorgu günlükleri ve sorgu performansı analiz araçları eklenir. Üretimde en değerli sinyaller genellikle şunlardır:

• CPU ve bellek kullanımı: Sürekli yüksekse dikey büyüme veya sorgu iyileştirmesi gerekir.
• Bağlantı sayısı: Sınıra yaklaştığında bir bağlantı havuzu devreye girmelidir.
• Replikasyon gecikmesi: Okuma replikalarının ne kadar geride kaldığını gösterir.
• Yavaş sorgular: En çok kaynak tüketen sorgular, indeks veya şema iyileştirmesinin başlıca adaylarıdır.

Göç: Mevcut Veritabanını Taşıma

Var olan bir veritabanını yönetilen bir servise taşırken iki temel yaklaşım vardır. Küçük sistemlerde veya kısa kesintiye tolerans gösterebilen sistemlerde mantıksal bir yedek alıp (ör. pg_dump / mysqldump) hedefte geri yüklemek yeterlidir. Kesinti penceresinin dar olması gereken sistemlerde ise sağlayıcıların sunduğu göç araçları, kaynaktan hedefe sürekli replikasyon kurarak son kesintiyi kısaltır.

Yüksek Erişilebilirlik ve Yedekleme

Temel dayanıklılık özellikleri üç serviste de benzer bir mantıkla çalışır: otomatik yedekler, işlem günlüğü (transaction log) tabanlı noktaya dönüş kurtarma ve okuma replikaları. Yüksek erişilebilirlik için genellikle ikinci bir bölge ya da kullanılabilirlik alanında bekleyen (standby) bir kopya tutulur ve arıza anında trafik ona devredilir.

Bağlantı ve Örnek Kod

Yönetilen bir servise bağlanmak, motor açısından kendi sunucunuza bağlanmaktan farksızdır; değişen tek şey ağ/kimlik katmanıdır. Aşağıda, standart bir istemciyle PostgreSQL uyumlu bir örneğe bağlanma örneği var (aynı motor Cloud SQL, Azure ve RDS üzerinde de geçerlidir).

-- Ornek: yeni tablo ve basit sorgu (motor: PostgreSQL)
CREATE TABLE musteri (
  id        BIGSERIAL PRIMARY KEY,
  ad        TEXT NOT NULL,
  eposta    TEXT UNIQUE NOT NULL,
  olusturma TIMESTAMPTZ NOT NULL DEFAULT now()
);

SELECT ad, eposta
FROM musteri
WHERE olusturma >= now() - INTERVAL '30 days'
ORDER BY olusturma DESC;

# psql ile yonetilen bir PostgreSQL ornegine baglanma
# host degeri saglayiciya gore degisir (Cloud SQL / Azure / RDS uc noktasi)
psql "host=DB_HOST port=5432 dbname=uygulama user=app_user sslmode=require"

Güvenlik ve Erişim Yönetimi

Üç sağlayıcı da veritabanını kendi kimlik ve ağ katmanlarıyla bütünleştirir. Ortak iyi uygulamalar şunlardır:

• Ağ yalıtımı: Veritabanını özel bir ağa koyun; genel erişimi kapatın veya bir IP izin listesiyle daraltın.
• Şifreleme: Beklemede (at rest) ve aktarımda (in transit) şifrelemeyi açık tutun.
• En az yetki: Uygulama kullanıcılarına yalnızca gerçekten ihtiyaç duydukları yetkileri verin.
• Kimlik entegrasyonu: Merkezi erişim yönetimi için sağlayıcının kimlik hizmetini (IAM / Entra ID) kullanın.
• Denetim: Bağlantı ve sorgu denetim günlüklerini etkinleştirin.

Maliyet Nasıl Oluşur?

Yönetilen bir veritabanının maliyeti tek bir kalem değildir; birkaç bileşenin toplamıdır. Kesin fiyatlar sağlayıcıya, bölgeye, motora ve zamana göre değiştiği için burada rakam vermiyoruz; bunun yerine hesaba katmanız gereken kalemleri sıralıyoruz.

Servis Kilitlenmesi (Vendor Lock-in)

Yönetilen bir servisin sağladığı kolaylık, bir ölçüde sağlayıcıya bağımlılık riski de getirir. Bu riski, taşınabilirliği yüksek motorlar seçerek azaltabilirsiniz. Örneğin standart PostgreSQL ya da MySQL üzerinde kalırsanız, üç sağlayıcı arasında göç etmek görece kolaydır. Aurora gibi bulut-yerlisi motorlar performans avantajı sunabilir ama taşınabilirliği bir miktar azaltabilir.

Servis Nasıl Seçilir?

• Zaten bir bulutta çalışıyorsanız, ağınızı ve kimlik yönetiminizi basitleştirmek için genellikle aynı sağlayıcının veritabanı servisi mantıklıdır.
• Motor sabitse: SQL Server ağırlıklı bir kurumsal yapıda Azure SQL doğal seçimdir; Oracle gerekiyorsa Amazon RDS bunu destekler.
• Açık kaynak motorlar (PostgreSQL/MySQL/MariaDB) üç sağlayıcıda da mevcuttur; seçim çoğu zaman ekosistem ve maliyete iner.
• Değişken yük için sunucusuz/esnek seçenekleri, öngörülebilir yük için ayrılmış örnekleri değerlendirin.

Haber Siteleri İçin Pratik Notlar

Haber sitelerinde okuma trafiği yazma trafiğinden çok daha yüksektir; ziyaretçiler içeriği okur, editörler ise görece seyrek yazar. Bu profil, okuma replikaları ve önbellek (cache) katmanıyla çok iyi örtüşür: birincil düğüm yayın ve editoryal işlemleri görürken, replikalar okuma yükünü taşır. Ani trafik sıçramalarında (örneğin büyük bir haberin yayılması) esnek/sunucusuz seçenekler kapasiteyi hızla yükseltmeye yardımcı olabilir.

• Okumayı ölçekleyin: Önbellek ve okuma replikalarıyla birincil düğümü koruyun.
• Yedeği test edin: Yayın kesintisi pahalıya mal olur; kurtarma tatbikatlarını ihmal etmeyin.
• Bölge seçimi: Okuyucularınızın çoğunluğunun bulunduğu bölgeye yakın dağıtım, gecikmeyi azaltır.

Sıkça Sorulanlar

Yönetilen bir servis kendi sunucumdan daha mı güvenli?

Sağlayıcı; altyapı güvenliği ve yamalar gibi kalemleri üstlenir, bu da yükünüzü azaltır. Ancak şema, yetkiler ve erişim politikası hâlâ sizin sorumluluğunuzdadır. Yanlış yapılandırılmış bir erişim listesi, yönetilen bir serviste de risk yaratır.

Verimi başka bir sağlayıcıya taşıyabilir miyim?

Standart motorlarda (PostgreSQL, MySQL, MariaDB) mantıksal bir yedek alıp hedef serviste geri yüklemek yaygın bir yöntemdir. Tescilli, bulut-yerlisi motorlarda ise göç daha fazla planlama gerektirir.