AWS RDS Kullanımda Dikkat Edilmesi Gerekenler

RDS, Amazon Web Services (AWS) sunduğu, ve AWS’nin kendisinin yönettiği servislerden olup; Amazon Aurora , PostgreSQL , MySQL , MariaDB , Oracle Database , and Microsoft SQL Server gibi veritabanlarını destekleyen bir veritabanı servisidir.

Bu yazıda sizinler RDS kullanımı esnasında dikkat edilmesi gereken bir kaç ipuçunu paylaşmaya çalışacağım.

1- RDS için makine tipi/boyutu seçilirken dikkat edilmesi gerekenler:

RDS için uygulamamızın desteklediği ve kullanmaya karar verdiğimiz veritabanını tipini belirledikten sonra (Amazon Aurora , PostgreSQL , MySQL , MariaDB , Oracle Database , and Microsoft SQL Server); uygulamamızın hacmi, atacağı sorgu miktarı, tutacağı veri yapısı, üretebileceği io yükünü vs hesaba katarak bir makine tipini seçmemiz gerekiyor. AWS’de her ne kadar managed (yönetilen) servisler olsa da ; bu servislerin üzerinde koşacağı makine tiplerini tamamen sizin seçmeniz gerekiyor. Bu seçim aynı zamanda direkt faturanıza da etki edecektir.

Bazı makine tipleri; daha çok cpu kullanımı için elverişli iken; bazı makine tipleri ise memory veya io-optimized olabiliyor. Bu aşamada uygulamanızın davranışını biliyor olmanız ve ona göre bir makine tipi seçmenizde fayda var. Fakat şunu da eklemek gerekir ki; uygulamayı açtıktan sonra da; uygulamayı ve RDS servisinin metriklerini izleyerek; seçtiğiniz makine tipinden farklı bir makine tipine geçmeniz de mümkündür. Bunu gerçekleşitrmenin de bir kaç yöntemi vardır. (Scale, yeni instance ekleme , failover vs ) . Bunların bir kısmına bu yazının devamında kısaca değinmeye çalışacağım.

Şunu da eklemem gerekiyor ki; buradaki makine tipi seçim konusu; veritabanınızın kullanabileceği network limitlerini, alabileceği maksimum açık bağlantı sayısını vs direkt olarak etki ettiği için; yoğun trafik alan uygulamaların veri tabanlarında, bu durum göz önünde bulundurularak seçim yapılmalıdır. https://aws.amazon.com/tr/rds/instance-types/ bu link içerisinde makine tiplerinin hafıza tipleri, RAM miktarları, network bant değerleri vs yer almaktadır.

Burada değinmek istediğim bir diğer konu da; AWS’nin sunduğu veritabanlarının bazılarının kökeni aynı olmakta ve genellikle birbirinin yerine kullanılabilmektedir. Mysql, MariaDB aynı kökenden gelen veritabanları olmasına rağmen AWS’nin kendi optimize ettiği AWS Aurora Mysql de bu ailenin bir üyesi olıp aynı şekilde kullanılabilmektedir.

2- RDS servisini konfigüre etme süreci

RDS managed bir servis olduğu için AWS tarafından optimize edilmiş olup minör güncelleme yüklemeleri AWS tarafından yürütülmektedir. Bu nedenle AWS veritabanının belirli birkaç parametresini configure etmenize izin verirken; bazılarını değiştirmenize izin vermez. Değiştirebileceğiniz parametreleri https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.html burada anlatıldığı şekilde Parameter Groups üzerinden konfigüre edebilirsiniz.

3- RDS erişim güvenliği

Veritabanları genelde en çok korunması gereken unsurların başında gelmektedir. Bu nedenle genellikle RDS servislerinin AccessGroup ve Security Policy’leri buna göre konfiure edilir ve genellikle burada RDS’in içinde bulunduğu VPC’nin iç network’ünden başka yerden erişime kapatılırlar. Harici bir yerden erişim gerekiyorsa; VPN, proxy, tunnel gibi kısıtlı şekilde sadece belirlenen whiteList uygulama ve IP’lerden erişime açık tutulması gerekiyor. Ne kadar az yerden erişime izin verilirse o kadar güvende olma ihtimaliniz artar.

4- Multi-Instance kullanım

Eğer büyük bir uygulamamız varsa; yoğun trafik alıyorsak; işin raporlama vs tarafları da söz konusu ise; burada genellikle kullanılan RDS servisi multi-instance olarak konumlandırılır. Burada destekleyen veri tabanlarında (RDBMS yani ilişkisel veri tabanları genellikle destekler) genellikle 1 Master (writer/yazma) ve 1'den fazla Slave (reader/okuma) instance’ları konumladırılır. Farklı master-master veya farklı regionalarda aktif birden fazla master yapıları da mevcut olsa da; en genel kullanım olan 1 master ve 1+ slave üzerinden devam edeceğim.

Eğer birden fazla instance kullanıyorsanız; AWS size bu instance’ların her biri için bir instance-endpoint; ve cluster yapısı için de bir writer bir de reader olmak üzere 2 tane de cluster endpointi verir. Şimdi nedir bu instance endpoint ve cluster endpoint? Nedir bunların birbirinden farkı?

RDS’te her bir instance’ın yani her bir makinenin 1 adet IP’si bir tane de aws tarafından sağlanan bir dns kaydı olur. Bu ip ve dns sadece bu makineye ait olup; yeni bir makine açtığınızda yada varolan makineyi değiştirdiğinizde veya yerine yeni bir makine eklediğinizde; makineye has bir değer olduğu için bunu kullanmak biraz riskli bir durumdur. Söz gelimi bu IP’yi veya veya dns kaydını uygulama içerisine yazdığınızda herhangi bir upScale/DownScale veya bir failover esnasında uygulamanız veritabanına erişemez olur.

Peki Cluster endpointleri nedir? Cluster endpointleri; AWS’nin aynı RDS içerisindeki instance’ları belirli özelliklerine göre gruplayıp her bir grubua verdiği sabit dns kayıtlarıdır. Ve bu RDS kapatılmadığı veya silinmediği sürece değişmezler. Örnek verecek olursak; RDS’imizde 1 master ve 2 tane slave instance olduğu durumda; AWS bize bir cluster endpointi verir ve bu master’a referans verir. Genellikle yazma/güncelleme/silme işlemlerini ve DDL sorgularını burada çalıştırırız. Burada herhangi bir failover esnasında yada makine tipi değişikliğinde cluster hangi makineyi master olarak kabul ediyorsa; bu endpoint direkt olarak ona gitmeye başlar. Böylece uygulama içerisinden sürekli host bilgisi değiştirmek zorunda kalmazsınız. Bunun yanı sıra; AWS bize bir tane de Reader cluster endpointi verir. Bu endpoint ise master dışında kalan slave yani sadece okuma özellikli makinelerin tamamını kapsar. Siz uygulamaya slave endpoint olarak bu endpoint’i verdiğinizde; RDS yük durumunda göre sorguları içerdeki 2 slave makineye otomatik olarak dağıtmaktadır.

Buradan çıkaracağımız en önemli nokta; instance endpointlerini kullanmaktan kaçının ve mümkünse cluster endpointlerini kullanın.

Bu konuyla ilgili bir önemli ipucu daha vermeye çalışacağım:
RDS bize default olarak verdiği cluster enpointlerinin dışında bizim de belirli şartlarda custom-endpointler oluşturmamıza izin veriyor. Bu konu da aslında çok önemli ve yeri geldi mi hayat kurtaran bir konudur. Örnek verecek olursam: cluster içerisinde 1 Master, 3 Reader instance’ınız olsun. Bu reader instance’lara sürekli ağır rapor sorguları çekme süreçleri geldiği durumda; bu intance’ların yük durumu rapor harici uygulamanın çalışmasını etkileyebilir ve sıkıntıya sokabilir. Bu durumda şöyle bir yol izlenebilir: Master için genel cluster’ın ana endpointini kullanmaya devam edebiliriz. Fakat reader’lar için cluster’ın bize verdiği ikinci endpointi kullanmak yerine; 2 yeni custom endpoint tanımlayıp; bu endpointlerden birini slave’lerde 1 tanesini dışarda bırakacak şekilde konfigüre edebiliriz. Bu durumda burada uygulama bu dışarda bırakılan instance’a sorgu atmayacaktır ve daha sonra 3. bir slave eklenmesi durumunda bunu da ilgili gruba otomatik dahil edecektir. İkinci custom endpoint için de sadece bir tane instance’ı dahil edecek şekilde ayarlayıp; geri kalan slave’leri izole edip; bu endpoint’i de raporlama uygulaması için kullanabiliriz. Böylece uygulamanın gittiği slave’ler ile raporlamanın gittiği slave’leri birbirinden izole edip; uygulama ve raporlamanın birbirini engellemesinin önüne geçmiş oluruz. Custom Endpointleri oluşturma ve kullanma ile ilgili olarak https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.Endpoints.html#aurora-custom-endpoint-creating buradaki belgeleri inceleyebilirsiniz.

5- Yedekleme ve Geri Yükleme

RDS ‘ler managed servisler olduğu için birden fazla yedekleme opsiyonu mevcut. https://aws.amazon.com/tr/rds/features/backup/ burada yedekleme çeşitlerinden bahsedilmektedir. Bunların başında AWS’nin belirli aralıklarla kendi aldığı snapshot yedekler yani otomatik yedeklemeler gelir. Bu yedeklemeler belir bir süre ve belirli sayıda tutulduktan sonra en eskileri otomatik olarak silinir. Bir diğer yedekleme çeşidi anlık yedeklemeler olup; sizin belirlediğiniz bir anda oluşturacağınız yedektir ve siz silene kadar silinmez. Her iki çeşit yedeklemede de; mevcut database’i belirli bir yedeğe geri döndürebileceğiniz gibi; bu yedeklerden tamamen yeni bir rds cluster kopyası oluşturmanız da mümkündür. (Yeni cluster’ın endpointleri farklı olmaktadır). Yedeklerin sıklığı ve geri dönülebilir olması sorun anlarında can kurtarsa da; çok fazla yedek tutmanın da kendi içerisinde bir maliyeti olduğunu göz önünde bulundurarak; ideal bir yedekleme polikitası/stratejisi planlanmalıdır. Özellikle veri tabanı boyutunuz büyüdükçe bu yedeklerin maliyeti ve geri yükleme sürelerinin de uzadığını hatırlatmak isterim.

Bu yazıda RDS ile ilgili bir kaç önemli ipucuna değinmek istedim. Faydalı olması dileğiyle. Kalın sağlıcakla…