Yönetilen veritabanını işletmek: RDS ve Aurora'da günlük iş akışı

RDS ve Aurora ne devralır, ne sizde kalır?

Amazon RDS, ilişkisel veritabanı sunucusunu sizin adınıza kuran ve işleten bir hizmettir. Donanım, işletim sistemi yamaları, yedekleme düzeni ve yük devretme mekanizması AWS'nin sorumluluğundadır. Şema tasarımı, sorgu performansı, kullanıcı yetkileri, bağlantı sayısı ve uygulama tarafındaki hata yönetimi ise hâlâ sizde kalır. Yönetilen veritabanı, "veritabanı yöneticisine gerek yok" demek değildir; işin türü değişir, ağırlık sunucu bakımından kapasite, sorgu ve güvenlik kararlarına kayar.

Aurora, RDS ailesi içinde AWS'nin kendi geliştirdiği, MySQL ve PostgreSQL ile uyumlu motordur. Belgelere göre bir Aurora kümesi (DB cluster) bir ya da birden çok veritabanı instance'ından ve birden çok erişilebilirlik bölgesine yayılan bir küme diskinden (cluster volume) oluşur. Hesaplama ile depolamanın ayrılması Aurora'nın temel mimari özelliğidir: tek instance'lı bir Aurora yapılandırması bile, altında birden çok depolama düğümü olduğu için küme sayılır.

İşe başlarken ilk karar motordur. Mevcut uygulama hangi veritabanını kullanıyorsa onun uyumlu seçeneği, göçü kolaylaştırır. Standart RDS motorları ile Aurora arasında mimari ve işletim farkları vardır; hangisinin yük, ekip ve bütçe için uygun olduğuna kıyaslamalı bir deneme ve güncel AWS belgeleri ışığında karar verin.

Adım adım: ilk veritabanını oluşturmak

Konsolda RDS sayfasından Create database ile sihirbazı açarsınız. Karar sırası genellikle şöyledir:

• Motor ve sürüm: uygulamanın desteklediği motoru seçin. Sürüm seçerken desteğin ne kadar süreceğine bakın; eski sürümlere verilen destek bir tarihte sona erer.
• Şablon ve dağıtım: üretim için Multi-AZ'yi içeren bir şablon, geliştirme için daha sade bir yapı seçilir.
• Instance sınıfı: işlemci ve bellek miktarını belirler. Veritabanı belleğe duyarlı olduğundan sınıfı iş yüküne göre seçin ve sonradan değiştirebileceğinizi unutmayın.
• Depolama: türü ve boyutu belirleyin; otomatik depolama büyütmesini açmak disk dolmasını önler.
• Bağlantı: VPC, alt ağ grubu ve güvenlik grubu. Veritabanına genel erişim açmak yerine, yalnızca uygulama sunucularının güvenlik grubundan gelen trafiğe izin verin.
• Kimlik bilgileri: ana parolayı kodun içine gömmek yerine AWS Secrets Manager ile saklayıp döndürmek tercih edilmelidir.
• Yedekleme, şifreleme ve izleme ayarları: otomatik yedekleme saklama süresi ve şifreleme oluşturma sırasında seçilir; bazı ayarları sonradan açmak güçtür, bu yüzden baştan düşünün.

Oluşturma bittiğinde RDS size bir uç nokta (endpoint) adresi verir. Uygulama bu ada bağlanır; arkada yük devri olsa bile adres değişmez.

Yüksek erişilebilirlik: Multi-AZ ve okuma kopyaları

İkisi sık karıştırılır, çünkü her ikisi de "ikinci bir kopya" üretir. Amaçları farklıdır.

Multi-AZ, erişilebilirlik içindir. AWS belgeleri iki dağıtım türünü ayırır. Multi-AZ DB instance dağıtımında bir yedek instance yük devri desteği sağlar ama okuma trafiğine hizmet vermez. Multi-AZ DB cluster dağıtımında ise birden çok yedek instance hem yük devrini sağlar hem okuma trafiğini karşılayabilir. Birincil instance'ta sorun olursa RDS yedeğe geçer ve uç nokta adresi aynı kalır.

Okuma kopyası (read replica) ise ölçek içindir. Raporlama sorguları ya da okuma ağırlıklı uygulama yükü kopyaya yönlendirilerek birincil instance rahatlatılır. Bölgeler arası okuma kopyası, felaket kurtarma senaryolarında da kullanılır; AWS DR belgesi, Aurora dışındaki RDS motorlarında okuma kopyasını birincil instance'a terfi ettirmenin birkaç dakika sürdüğünü ve yeniden başlatma içerdiğini belirtir.

Aurora'da yapı biraz farklıdır: bir yazıcı (primary) instance tüm değişiklikleri yapar, okuyucu instance'lar (Aurora Replica) aynı küme diskine bağlanır ve yalnızca okuma yapar. Birincil instance erişilemez olursa Aurora okuyucuya otomatik yük devri yapar; okuyucular arasında devir önceliği belirleyebilirsiniz. Okuyucuları farklı erişilebilirlik bölgelerine koymak yüksek erişilebilirliği güçlendirir.

Bağlantı yönetimi ve uygulama entegrasyonu

Aurora'da farklı amaçlı uç nokta türleri bulunur ve uygulama doğru olanı kullanmalıdır: küme uç noktası her zaman güncel yazıcıya gider, okuyucu uç noktası okuyuculara dağıtım yapar, özel uç noktalar seçtiğiniz instance grubuna yönlendirir, instance uç noktası ise tek bir instance'ı hedefler. Yazan kod küme uç noktasına, raporlama kodu okuyucu uç noktasına bağlanırsa okuma yükü doğal olarak ayrışır.

Uygulama tarafında en sık görülen sorunlar şunlardır:

• Bağlantı havuzu olmadan her istekte yeni bağlantı açmak. Ölçeklenen uygulamada veritabanının bağlantı sınırı hızla dolar. Havuzlama ya da RDS Proxy gibi bir bağlantı aracısı kullanın.
• Yük devri sonrası eski bağlantıyı tutmak. Uygulama, bağlantı koptuğunda uç noktayı yeniden çözümleyip tekrar denemeli; DNS önbelleği uzun tutulmamalıdır.
• Uzun süren işlemler. Bakım ve yük devri sırasında yarım kalan işlem yeniden denenebilir olmalıdır.
• Okuma kopyasından okurken gecikmeyi unutmak. Kopya birincilin biraz gerisinde olabilir; yazdığı kaydı hemen okuması gereken akışlar yazıcıya yönlendirilmelidir.

Örneğin bir sipariş uygulamasında sipariş oluşturma işlemi yazıcıya gider, "siparişlerim" listesi okuyucudan gelir; ama sipariş verildiği anda açılan onay sayfası yazıcıdan okunmalıdır.

Performans izleme ve yedekleme/kurtarma

İzleme için ilk bakılacak yerler CloudWatch ölçümleri, Enhanced Monitoring ve Performance Insights'tır. Performance Insights, veritabanı yükünü bekleme olaylarına ve sorgulara göre ayırarak darboğazın nerede olduğunu gösterir. Pratik bir izleme listesi: işlemci kullanımı, boş bellek, disk gecikmesi, bağlantı sayısı, kopya gecikmesi ve boş depolama alanı. Bunlar için alarm tanımlayın.

Sorgu ayarında yöntem basittir: yavaş sorguyu bulun, çalışma planını inceleyin, eksik indeksi ekleyin ya da sorguyu yeniden yazın. Çoğu zaman donanımı büyütmek yerine bir indeks sorunu çözer.

Yedekleme tarafında RDS, otomatik yedekleri ve işlem günlüklerini saklayarak belirli bir ana geri dönüşü (point-in-time recovery) destekler. Elle alınan anlık görüntüler, siz silene kadar durur ve büyük değişiklikten önce güvenli geri dönüş noktası olarak kullanılır. Önemli olan şu: geri yükleme her zaman yeni bir veritabanı oluşturur, var olanı yerinde geri sarmaz. Bu yüzden kurtarma planında uygulamanın yeni uç noktaya nasıl geçeceği de yazılı olmalıdır.

Yedeğin varlığı yeterli değildir; geri yükleme periyodik olarak denenmelidir. Denenmemiş yedek, kurtarma gününde ilk kez keşfedilen bir risktir.

Bakım, güvenlik ve göç

RDS belirli aralıklarla bakım işlemleri uygular. Bakım penceresini trafiğin düşük olduğu saate ayarlamak, yamaların iş saatlerine denk gelmesini engeller. Motor sürüm yükseltmeleri ise test ortamında denenip planlı yapılmalıdır.

Güvenlik için temel liste: kaydı ve depolamayı şifreleme, aktarımda şifreli bağlantı, güvenlik grubunda yalnızca gerekli kaynaklara izin, IAM tabanlı yetki ve kimlik bilgilerinin Secrets Manager'da tutulması. Kişisel veri işleyen sistemlerde erişim kayıtlarını ve denetim ayarlarını uyum ekibiyle birlikte belirleyin.

Göç projelerinde AWS Database Migration Service ve motora özgü araçlar öne çıkar. Genel yaklaşım şudur: kaynak veritabanını ve bağımlılıkları envantere alın, şema uyumunu ve veri türlerini denetleyin, test göçü yapın, geçiş anında kesinti penceresini ya da sürekli çoğaltmayı planlayın, geri dönüş yolunu hazır tutun. Aurora'ya geçiş uyumluluk avantajı sağlar ama uygulama testi gerektirir.

Maliyet izlemede de disiplin gerekir: kullanılmayan instance, eski anlık görüntüler ve gereğinden büyük sınıflar birikir. Güncel fiyatlar için AWS fiyatlandırma sayfasına bakın.

Mindset programlarında bu beceri nerede çalışılır?

Amazon RDS ve Aurora ile Yönetilen Veritabanı İşletimi programı, bu sayfadaki işleyişi modüller üzerinden uygulamalı çalışmaya çevirir: yüksek erişilebilirlik ve okuma ölçekleme, bağlantı yönetimi, performans izleme ve sorgu ayarı, yedekleme ve kurtarma, güvenlik, göç ve olay yönetimi başlıklarını içerir. Veritabanı yöneticileri, bulut altyapı mühendisleri ve veritabanını üretimde işleten backend geliştiricileri için uygundur.

AWS Solutions Architect Associate Hazırlık programında Veritabanı ve Önbellekleme Mimarisi modülü ise aynı konuyu mimari seçim açısından ele alır: hangi iş yükü için hangi veritabanı hizmeti ve nasıl bir dayanıklılık düzeni. Kurumsal ekiplerde veritabanı ve uygulama ekiplerinin ortak çalışması için iyi bir zemindir.