AWS Türkçe Blog

Sağlanan Aurora kümeleriniz için Amazon Aurora Serverless v2’yu değerlendirin

Orijinal makale: Link (Rajeev Sakhuja ve Raj Jayakrishnan)

Bu gönderide, Aurora Serverless v2 veritabanları ve sağlanan (provisioned) bulut sunucularını Aurora Serverless v2 örnekleri ile değiştirirken göz önünde bulundurulması gereken faktörler hakkında bilgi edineceksiniz.

Amazon Aurora Serverless, uygulama veritabanınız için işlem yönetimi konusunda endişelenmeden Amazon Aurora MySQL-Compatible Edition ve Amazon Aurora PostgreSQL-Compatible Edition kullanmanıza olanak tanır.

Günümüzde birçok kuruluş, uygulama oluşturmak için sunucusuz mimariyi benimsiyor. AWS sunucusuz teknolojilerle, bu kuruluşlar pazara daha hızlı geçebilir, altyapı maliyetlerini düşürebilir ve doğal ölçeklendirmeden faydalanabilir. AWS, çok katmanlı bir uygulamada katmanların her biri için sunucusuz hizmetler sunar. İhtiyaçlarınıza bağlı olarak, uygun bir veri katmanı sunucusuz hizmeti seçebilirsiniz.

Aurora Serverless v2 DB sunucuları

Aurora Serverless v2 örneği, Aurora’nın otomatik ölçeklendirme yapılandırmasıdır. Amazon Aurora tarafından sağlanan veritabanı bulut sunucusu statik kapasiteye sahipken Aurora Serverless v2 örneğinin kapasitesi, kullanıcı tarafından kontrol edilen minimum ve maksimum kapasite aralığı arasında değişir.

Sağlanan sunucunun statik kapasitesi, sınıfı tarafından belirlenir. Örneğin db.r6g.4xlarge, 128 GB belleğe, 16 vCPU’ya ve 10 Gbps’e kadar ağ bant genişliğine sahiptir. Sunucusuz bir örneğe tahsis edilen kapasite, Aurora Kapasite Birimleri (Aurora Capacity Units – ACU’lar) cinsinden ölçülür. 1 ACU, kabaca 2 GB belleğe ve eşdeğer CPU ve ağ bant genişliğine eşittir. İzin verilen minimum ACU, kabaca 1 GB bellek olan 0,5’tir ve maksimum ACU, kabaca 256 GB belleğe eşdeğer olan 128 ACU’ya kadar olabilir.

Sunucusuz örnek kapasite aralığı (minimum ACU–maksimum ACU), küme düzeyinde sizin tarafınızdan belirlenir—kümedeki tüm Aurora Serverless v2 örneklerine aynı kapasite aralığı atanır. Bir küme, sunucusuz örneklerin ve sağlanan sunucuların bir karışımını içerebilir; buna karma yapılandırma kümesi (mixed-configuration cluster) denir. Aşağıdaki şekilde, sağlanan bir yazar (writer) sunucusu ve tek bir sunucusuz okuma replikası içeren böyle bir yapılandırma gösterilmektedir.
Aurora cluster with 1 provisioned and 1 serverless instance

Aurora Serverless v2 örneği ölçeklendirmesi

Aurora, veritabanı sunucu kapasitesini kaynak taleplerini karşılayacak şekilde ayarlamak için belleği, CPU’yu ve ağı sürekli olarak izler. Aurora, bulut sunucusu belleği, CPU ve ağ bant genişliği baskı altındaysa sunucusuz örneği ölçeklendirir. Kaynaklar üzerindeki baskı azaldığında örneği küçültür. Herhangi bir noktada Aurora Serverless v2 veritabanı örneği kapasitesini etkileyen birkaç faktör vardır.

Veritabanı yükü

Yazar sunucusunda bellek, CPU ve ağ bant genişliği kullanımı, yazma ve okuma sorgularının hacmine bağlıdır; oysa bu kaynakların okuyucu sunucularında kullanımı, okuma sorgularının hacmine ve okuyucu sunucularının sayısına bağlıdır. Tüm sunucusuz veritabanları ile bir küme tasarlarken, küme kapasite aralığının iş yükünüzün okuma ve yazma hızı gereksinimleri için yeterli olduğundan emin olmanız gerekir.

Sorgu yüküne ek olarak, veritabanı sunucusunda çalışan arka plan işlemleri de hesaplamalı kaynakları kullanır. PostgreSQL vakumu ve analizi bu tür süreçlerin örnekleridir. Bulut sunucusunda etkinleştirilirse Amazon RDS Performance Insights, ölçümleri toplamak için basit bir aracı (agent) işlemi kullanır. Global database kullanımdaysa veya Performance Insights etkinleştirildiyse, küme için minimum ACU’nun 2 ACU olarak ayarlanması önerilir.

Yük devretme önceliği

Kümedeki okuyuculara 0 (ilk) ile 15 (son) arasında bir yük devretme önceliği (failover priority) atanır. Yük devretme durumunda Aurora, okuyucuyu yeni birincil sunucuya daha iyi öncelik vererek yükseltir. Aurora, önceliği 0 veya 1 olarak ayarlanmış sunucusuz okuyucuların her zaman yazar sunucuyla aynı kapasiteye sahip olmasını sağlar. Bunu, önceki yazıcıda çalışmakta olan iş yükünü desteklemek için yeterli kapasitenin mevcut olması için yapar. Yani okuyucu, üzerinde hiçbir yük olmadığı halde yazarla aynı seviyeye getirilecektir. Önceliği 2 veya üzeri olan okuyucular, yazarın kapasitesinden etkilenmez. Kümenizin işletme maliyetini etkileyebileceğinden, bu faktörü tam olarak anlamak önemlidir.

Dikkate alınacak faktörler

Şimdi, sağlanan bulut sunucularınızı Aurora Serverless v2 ile değiştirmek için göz önünde bulundurmanız gereken faktörleri ele alıyoruz. Bu rehberlik tamamen teknik bir bakış açısıyla sağlanmaktadır. Bu değişiklikle herhangi bir ölçeklendirme veya maliyet avantajı elde edip etmediğinizi değerlendirmek için hedef yapılandırmanızı üretim benzeri bir yükle test etmenizi öneririz. Bu gönderide ele alınan faktörlere ek olarak, Sunucusuz v2 özellik desteği ile ilgili belgeleri de incelemenizi öneririz.

Motor versiyonu

Aurora Serverless v2, MySQL 8.0 sonrası ve PostgreSQL 13 sonrası için desteklenir. Sağlanan kümeniz, desteklenen sürümden daha düşük bir sürümdeyse, Aurora Serverless v2 örneklerinden yararlanabilmeniz için önce kümenizi desteklenen bir sürüme yükseltmeniz gerekir.

Sunucu boyutu

256 GB’a kadar belleğe sahip bir Aurora kümesindeki herhangi bir veritabanı, sunucusuz ile değiştirilebilir. Sunucu için minimum kapasite, sağlanan mevcut sunucunun kaynak kullanımına bağlıdır. Global Database kullanılıyorsa veya Performance Insights etkinleştirildiyse minimum değerin 2 veya üzeri olması önerilir. Örneğin maksimum kapasitesi, iş yükü gereksinimlerinizi karşılayabiliyorsa, sağlanan bulut sunucusu kapasitesinin eşdeğerine ayarlanabilir. Örneğin, bir db.r6g.4xlarge (128 GB) bulut sunucusu için CPU kullanımı çoğu zaman %10’da kalırsa minimum ACU’lar 6,5 ACU’ya (128 GB’ın %10’u) ve maksimum 64 ACU’ya (64x2GB=128GB) ayarlanabilir.

Ölçekleme oranı

Aurora Serverless v2 DB örneğin ölçeklendirme oranı, mevcut kapasitesine bağlıdır. Mevcut kapasite ne kadar yüksek olursa, o kadar hızlı ölçeklenir. İş yükü performansa duyarlıysa, iş yükünüzü üretim benzeri bir yükle test etmeniz ve istenen performansı elde etmek için minimum kapasiteyi ayarlamanız önerilir.

Kullanım özellikleri

Veritabanı kümeleri, okuyucu ve yazar sunucuları için farklı kullanım özelliklerine sahip olabilir. Kullanım modelinin kendisine bakarak, Aurora Serverless v2 örneklerine geçiş yapmanın herhangi bir maliyet avantajı olup olmayacağını ölçebilirsiniz. Aşağıdaki grafikler, veritabanı sunucuları için ortak kaynak kullanım modellerini göstermektedir.

Database load characteristics/patterns

Peaks and valleys modelinde, kullanım düşük ve yüksek CPU kullanımı arasında gidip gelir. Böyle bir uygulamaya örnek olarak, çoğunlukla iş saatlerinde kullanılan bir İK uygulaması verilebilir. Sunucusuz ile, bulut sunucusu iş yükünün kapasite gereksinimlerini karşılamak üzere otomatik olarak ölçeklendirileceğinden en yüksek kapasite için ödeme yapmanız gerekmez.

Outliers değerler modelinde, CPU kullanımı çoğunlukla düşük kalır, ancak daha sonra normalden daha yüksek CPU kullanımına yol açan kullanım artışları olur. Böyle bir uygulamanın bir örneği, önemli bir dünya olayı olduğunda kullanımının arttığı küresel bir haber portalıdır. Bu kullanım kalıplarına sahip veritabanı bulut sunucuları, sunucusuz ile değiştirilmek için iyi bir adaydır.

Random model, adından da anlaşılacağı gibi, veritabanı sunucusunun kullanımının tahmin edilemez olduğu bir modeldir. Öngörülemeyen yük özelliklerine sahip iş yüklerinde, özellikleri anlamak için sunucusuz ile başlamanız ve ardından optimum performans ve maliyet elde etmek için kapasiteyi ayarlamanız önerilir.

Consistent model, sunucu kaynak kullanımının çoğu zaman dar bir bant içinde kaldığı durumu ifade eder. Böyle bir uygulamanın bir örneği, sahadan sürekli sensör verilerini toplayan bir IoT uygulamasıdır. Kapasite kullanımında dalgalanmalar olmadığı için bulut sunucusu ölçeklendirme perspektifinden pek fayda sağlamazsınız.

Aurora Serverless v2’ya geçmenin potansiyel faydalarını ölçmek için sağlanan yazar ve okuyucu sunucularınız için Amazon CloudWatch CPU kullanımına ve bellek ölçümlerine bakmanızı öneririz.

Yük devretme performansı

Yazma yükünün consistent modeli izlediği ve okuma yükünün outliers modelini izlediği bir küme düşünün. Önceki tartışmaya dayanarak, sağlanan bir yazar sunucusu ve sunucusuz okuyucu örnekleri içeren karma yapılandırmalı bir kümeye gitmeye karar verebilirsiniz.

Yük devretmede, sunucusuz olan birincil (yazar) olur ve sağlanan örnek okuyucu olur. Sunucusuz önceliği 0 veya 1 olarak ayarlanmışsa kapasitesi, yük devretme sırasında sağlanan sunucunun kapasitesine eşdeğer olacaktır. Ancak sunucusuz önceliği 2 veya üzerindeyse, kapasitesi yazarın kapasitesini takip etmeyecektir. Gerçekte, kümedeki tüm okuyuculara 2 veya üzeri bir öncelik atanırsa, yük devretme sonrasında kısa bir süre için performans düşüşü gözlemleyebilirsiniz. Performansa duyarlı iş yüklerinde, en az bir okuyucu için okuyucu önceliğinin 0 veya 1 olarak ayarlanmasını öneririz. Bu, tüm sunucusuz veritabanı örneklerine sahip bir küme için bile geçerlidir.

Aşağıdaki diyagram, Aurora küme mimarimizi göstermektedir.

Aurora Mixed Configuration

Aşağıdaki diyagram yük devretme sonrası mimariyi göstermektedir.

Aurora Mixed Configuration - After failover

Yük devretmeden daha hızlı kurtarma için MySQL veya PostgreSQL için Amazon RDS Proxy hizmetini veya AWS Aurora JDBC sürücüsünü kullanmayı düşünmenizi öneririz.

Sunucu ölçeklendirme ile otomatik ölçeklendirmeyi değiştirin

Aurora, kümedeki okuyucuları dinamik olarak eklemek veya kaldırmak için bir otomatik ölçeklendirme (auto scaling) mekanizması sunar. Otomatik ölçeklendirme davranışı, okuma kapasitesini ayarlamak için ortalama CPU, ortalama veritabanı bağlantısı sayısı ve hatta özel ölçümler gibi ölçümleri kullanan bir politika aracılığıyla yönlendirilir. Otomatik ölçeklendirme tetiklendiğinde, kümeye yeni bir okuyucu eklenir. Hedef metrik eşiğin altına düştüğünde, yeni eklenen sunucu kaldırılır. Bu ölçek büyütme işlemi, yeni bir okuyucu veritabanı sunucusu başlattığı için birkaç dakika sürebilir. Otomatik ölçeklendirme özelliğini kullanıyorsanız, Aurora Serverless v2 tarafından sunulan dikey ölçeklendirme ile değiştirme seçeneğiniz vardır. Sağlanan okuyucularınızı, uygun küme kapasite aralığına sahip daha fazla sayıda sunucusuz okuyucuyla değiştirebilirsiniz. Bu kurulumun avantajı, bulut sunucusu düzeyinde dikey ölçeklendirmenin, bulut sunucusu başlatmaya kıyasla son derece hızlı olması ve yalnızca kullandığınız kapasite için ödeme yapmanızdır.

Aurora Serverless v2 iş başında

Bu bölümde, Aurora Serverless v2 ile uygulamalı bir deneyim sunuyoruz. Bu bölümde ele alınan adımlar, sağlanan Aurora veritabanı kümenizi karma yapılandırmalı bir kümeye ve ardından tamamen sunucusuz bir kümeye nasıl taşıyabileceğinizi gösterir. Bu geçiş için kullandığımız işlemin, geçiş sırasında çalışan uygulamalar üzerinde minimum etkisi vardır. Yük devretme önceliğinin sunucusuz v2 örneği üzerindeki etkisini de gözlemleyeceksiniz.

Bir Aurora PostgreSQL veya MySQL kümesi oluşturun

Bir adet sağlanan yazar sunucusu ve bir adet sağlanan okuyucu sunucusu ile bir Aurora PostgreSQL kümesi oluşturarak başlıyoruz. Her iki sunucu için de sunucu sınıfı db.r6g.xlarge (32 GB bellek) kullanalım. Veritabanı kümesine bağlanmak için bir bastion host kullanabilirsiniz. Küme kullanılabilir olduğunda, PostgreSQL psql gibi uygun bir veritabanı istemcisi kullanarak veritabanı bulut sunucunuza olan bağlantıyı test edin.

Aşağıdaki diyagram bu mimariyi göstermektedir.

Aurora cluster with provisioned instances

Sunucusuz bir okuyucu ekleyin

Bu adımda, kümeye sunucusuz bir okuyucu örneği eklersiniz. Amaç, bunu okuyucu uç noktasını kullanan uygulamalarda herhangi bir kesintiyi önleyecek şekilde yapmaktır. Okuyucu eklendikten sonra, sağlanan ve sunucusuz örneklerin bir karışımını içeren bir küme elde ederiz, yani karma bir yapılandırma kümesi.

Aurora mixed cluster - add Serverless v2 instance

Okuyucu eklemek için aşağıdaki adımları tamamlayın:

  1. Amazon RDS konsolunda gezinme bölmesinde Databases seçin.
  2. Kümenizi seçin ve Actions menüsünde Add reader seçin.
  3. DB instance identifier için, bir ad girin.
  4. DB instance class için, Serverless v2 seçin.
  5. Capacity range için minimum ACU’ları 2’ye ve maksimumu 16’ya ayarlayın.
  6. Additional configuration altında, Failover Priority‘i tier-2‘ye ayarlayın.

Bir süre bekleyin ve ardından sunucusuz örnek için CloudWatch ServerlessDatabaseCapacity metriğini kontrol edin. Aşağıdaki grafikte görüldüğü gibi okuyucu ortamına ayrılan kapasitenin yazarın kapasitesinden bağımsız olduğunu ve yüksüz durumda 2 ACU’ya yerleştiğini göreceksiniz. Ölçekleme davranışını görmek için isteğe bağlı olarak SQL yükünü okuyucu uç noktasına karşı çalıştırabilirsiniz.

Drop in capacity for SV2 instance on changing to tier-2

Sunucusuz okuyucu yük devretme önceliğini tier-1 olarak değiştirin

Bu adımda, sunucusuz okuyucu örneğinin önceliğini tier-1 olarak değiştiriyoruz. Bu değişiklikle birlikte okuyucu kapasitesi, yazar örneği kapasitesini takip etmeye başlayacaktır.

  1. Amazon RDS konsolunda gezinme bölmesinde Databases seçin.
  2. Sunucusuz örneği seçin.
  3. Additional configuration altında, Failover Priority‘i tier-1‘e ayarlayın.
  4. When to apply modifications için, Apply immediately seçin.

Wait for the modifications to complete and then check the CloudWatch ServerlessDatabaseCapacity metric for the serverless instance. You will observe that the serverless instance’s capacity is fixed at 16 ACU; it’s equivalent to the writer instance’s capacity, which in this test setup is 16 ACUs.

Değişikliklerin tamamlanmasını bekleyin ve ardından sunucusuz örnek için CloudWatch ServerlessDatabaseCapacity metriğini kontrol edin. Sunucusuz örneğin kapasitesinin 16 ACU’da sabitlendiğini göreceksiniz; bu test kurulumunda 16 ACU olan yazar örneğinin kapasitesine eşdeğerdir.

Update to capaciyt for SV2 instance with priority = tier-1

Sağlanan okuyucuyu bırakın ve yük devredin

Bu adımda, sağlanan okuyucu sunucusunu silecek ve ardından yük devrederek sunucusuz örneği yazar yapacaksınız.

  1. Amazon RDS konsolunda gezinme bölmesinde Databases seçin.
  2. Sağlanan okuyucu sunucusunu seçin ve Actions menüsünde Delete seçin.

Silme işleminin tamamlanmasını bekleyin.

Şimdi yük devretme işlemini gerçekleştiriyoruz.

  1. Databases sayfasında, kümeden bir örnek seçin.
  2. Actions menüsünde, Failover seçin.

Yük devretmenin tamamlanmasını bekleyin. Yük devretme tamamlandıktan sonra sunucusuz okuyucu örneği yazar olur ve sağlanan sunucu okuyucu olur.

Aşağıdaki diyagram, güncellenmiş mimarimizi göstermektedir.

Removed provisioned instance from cluster

Sağlanan sunucuyu sunucusuz olarak değiştirin

Bu adımda, sağlanan sunucu sınıfını db.serverless olarak değiştireceksiniz.

  1. Amazon RDS konsolunda gezinme bölmesinde Databases seçin.
  2. Sağlanan sunucuyu (Okuyucu) seçin, Modify seçin.
  3. Instance configuration altında, Serverless v2 seçin
  4. When to apply modifications için, Apply immediately seçin.

Şu anda, iki sabit kapasiteli veritabanı sunucusu içeren bir test kümesini iki sunucusuz veritabanı içeren bir kümeye dönüştürdünüz. Kümedeki her örnek birimi için kullanılabilen maksimum kapasite (16 ACU), bir db.r6g.xlarge sunucusunun sabit (32 GB) kapasitesine eşdeğerdir. Herhangi bir noktada bulut sunucuları için kapasite kullanımı 2 ACU ile 16 ACU arasında olacak ve kullandığınız gerçek kapasite için ödeme yapacaksınız.

Aurora - all serverless v2 instances

Temizleme

Sunucusuz örnekleri test etmeyi bitirdikten sonra tüm veritabanı örneklerinin ve bastion host’un silindiğinden emin olun.

  1. Oluşturduğunuz Aurora kümesini silin.
  2. Bastion host için EC2 sunucusunu silin.

Sonuç

Bu gönderide, sağlanandan Aurora Serverless v2 DB bulut sunucularına nasıl geçeceğinizi öğrendiniz. Aurora, sunucusuz örnek kapasitesini örnek üzerindeki kaynak baskısına (bellek, CPU, ağ bant genişliği) göre ayarlar. Önceliği 0 veya 1 olarak ayarlanmış okuyucuların kapasitesi, yazarın kapasitesini takip eder. Kümenin yük devretme performansı ve maliyet üzerinde doğrudan etkisi olduğundan, bu “okuyucular yazarı izler” mekanizmasını anlamanız önemlidir.

Bu gönderide tartıştığımız faktörleri göz önünde bulundurarak, Aurora Serverless v2’ya geçiş için mevcut Aurora veritabanlarınızı değerlendirmenizi öneririz. İş yükünüzü sunucusuz hale getirmeye karar verirseniz, üretime geçmeden önce üretim benzeri bir yükle kapsamlı test yapmanızı öneririz. Sunucusuz geçişin düşük riskli bir değişiklik olduğunu unutmayın, çünkü uygulamalar üzerinde minimum etkiyle istediğiniz zaman sağlanan bir bulut sunucusu yapılandırmasına geri dönebilirsiniz.