Aurora Serverless v2 İncelemesi: Mimari Derinlemesine Bakış

Aurora Serverless v2, çoğu zaman provisioned Aurora’dan bağımsız, ayrı bir veritabanı ürünüymüş gibi tanıtılır. Bu çerçeve mühendisleri yanlış varsayımlara götürür: replika sayısının otomatik arttığı, ölçekleme anında bağlantıların düştüğü, her ölçeklemede cache’in soğuduğu sanılır. Üçü de doğru değil; ama Kasım 2024’ten beri bir dördüncü kısmen doğru: sıfıra ölçekleme bir soğuk başlangıç yolu ima ediyor.

Adlandırma üzerine kısa bir not

Nisan 2026’da AWS, “Aurora Serverless v2” adını “Aurora serverless” olarak değiştirdi. AWS Database Blog’un sıfıra ölçekleme duyuru yazısının başında şu banner duruyor: “April, 2026: Aurora Serverless v2 has been renamed Aurora serverless. No action required.” Eski v1 ürünü hâlâ ayrı bir teklif olarak duruyor ve aşamalı olarak kullanımdan kaldırılıyor. Okurların büyük kısmı hâlâ “Aurora Serverless v2” adıyla arıyor; dokümantasyon URL slug’ları da içeride v2 ifadesini korumaya devam ediyor, dolayısıyla aşağıda aynı terim kullanılıyor. “Serverless v2” geçtiği her yerde, AWS’in artık yalnızca “Aurora serverless” dediği ürün kastediliyor.

Mimari açıdan bu yeniden adlandırma, baştan beri doğru olan bir şeyi netleştiriyor: tek bir Aurora var, ve “serverless”, onun üzerine eklenmiş bir faturalama ve çalıştırma modu. Aurora Serverless v2, 2014’ten bu yana provisioned cluster’ları besleyen aynı Aurora işlem ve depolama altyapısının üstünde duran ince bir scaling daemon ve faturalama sarmalayıcısıdır; “sıfıra ölçekleme” ise bu çerçeveyi anlamlı şekilde zorlayan tek mekanizmadır.

Depolama katmanı

Aurora performansı, dayanıklılığı veya ölçeklenmesi üzerine yapılan, depolama katmanından başlamayan her sohbet sonunda kafa karışıklığıyla biter. Aurora’yı Aurora yapan depolama katmanıdır; işlem katmanı, çoğu açıdan görece sadedir. Aurora Serverless v2 bu katmanı dokunmadan devralır. Serverless v2 dokümantasyonu bu denkliği açıkça ifade ediyor: “Aurora serverless storage has the same reliability and durability characteristics as described in Amazon Aurora storage. That’s because the storage for Aurora DB clusters works the same whether the compute capacity uses Aurora serverless or provisioned.”

Üç availability zone’a yayılmış altı kopya

Bir Aurora cluster volume, tüm verinin altı kopyasını üç availability zone’a yayarak saklar; cluster’da kaç DB instance olduğundan bağımsız olarak. Replikasyon faktörü işlem sayısından bağımsızdır. Tek instance’lı bir cluster, on beş instance’lı bir cluster’la aynı altı yönlü replikasyonu alır. Volume mantıksal olarak cluster’daki tüm işlem instance’larından erişilebilen paylaşılan bir cihazdır; talep üzerine 10 GiB’tan 128 TiB’a kadar, güncel Aurora PostgreSQL (17.5+, 16.9+, 15.13+) ve Aurora MySQL 3.10+ sürümlerinde ise Temmuz 2025’teki tavan artışıyla 256 TiB’a kadar otomatik olarak büyür.

Bu 6/3 yerleşimi, Verbitski ve arkadaşlarının SIGMOD 2018 makalesinde formalize ettiği quorum semantiğini mümkün kılar: yazma işlemleri altı kopyadan dördünün onayını gerektirir, okumalar altıdan üçünü. Asimetri kasıtlıdır. Üç AZ ile sistem, bir AZ’nin tamamının ve başka bir AZ’deki bir kopyanın kaybına rağmen yazmaya devam edebilir. Bir AZ’nin tamamı kaybedildiğinde de okumalar sürer. Depolama 10 GiB’lık “protection group”lara parçalanmıştır, her biri altı yönlü replike edilir ve birbirinden bağımsız onarılır; bu da kurtarma işlemlerinin volume bazında değil, protection group bazında çalışması anlamına gelir.

Log, veritabanının kendisidir

Aurora’nın en sonuç doğuran tasarım kararı, işlemden depolamaya ağ üzerinden yalnızca redo log kayıtlarının iletilmesidir; tam veri sayfaları değil. Bir işlem (transaction) bir compute instance üzerinde commit edildiğinde, instance etkilenen protection group’lar için tüm altı depolama düğümüne log kayıtlarını gönderir. Depolama düğümleri sayfaları talep üzerine materyalize etmek için log kayıtlarını uygular; compute instance sayfa yazma yolunda değildir. SIGMOD 2017 bu prensibi “log is the database” sloganıyla tanıtır ve sayfa gönderen geleneksel replikasyona kıyasla ağ trafiğindeki azalmayı sayılarla gösterir.

Buradan doğrudan üç sonuç çıkar. Birincisi, durum aşağıda yaşadığı için işlem (compute) esnek olabilir; bir ölçekleme olayı sayfaları taşımak zorunda değildir, yalnızca işlem katmanının yakın log konumlarını yenilemesi yeterlidir. İkincisi, dayanıklılık tamamen instance yaşam süresinden bağımsız hâle gelir; bir compute instance işlem ortasında çökse bile, kurtarma depolamadaki log’tan ilerler. Üçüncüsü, read replika’lar bir replikasyon kanalı üzerinden writer’dan değil, aynı paylaşılan volume’dan okurlar; replika gecikmesi (replica lag) işlem yeniden oynatma değil, buffer pool invalidasyonlarının cluster içinde yayılmasıdır.

Bunun Serverless v2 için önemi

Bu üç özelliğin üçü de Serverless v2 davranışının ön koşuludur. Yerinde ölçekleme mümkündür çünkü depolama altta paylaşılır ve dayanıklıdır. Sıfıra ölçekleme mümkündür çünkü dayanıklılık, çalışan herhangi bir compute instance’ın yokluğunda da yaşar. Karışık modlu cluster’lar işler çünkü her reader ve writer, instance ister provisioned ister serverless olsun, aynı cluster volume’a bağlanır. Serverless v2 dokümanları “depolama katmanı değişmedi” derken gerçek bir iş yapıyorlar: bu tek olgu, scaling daemon’un yeni bir veritabanı motoru değil, küçük bir ek olmasını sağlayan şeydir.

İşlem katmanı

Aurora Serverless v2’nin işlem katmanı, provisioned Aurora ile aynı işlem altyapısının üzerinde, yalnızca esnek kapasiteyle çalışır. Kapasite birimi Aurora Capacity Unit, kısaca ACU’dur. AWS, 1 ACU’yu yaklaşık 2 GiB RAM ile orantılı CPU ve ağ kapasitesi olarak tanımlar; karşılaştırılabilir bir provisioned Aurora instance ile uyumlu olacak şekilde kalibre edilmiştir. Kapasite, minimum ve maksimum ile 0.5 ACU adımlarında belirtilen bir aralık olarak yapılandırılır. Güncel aralık 0 ACU ile 256 ACU arasıdır; 256 ACU tavanı 3 Ekim 2024’te duyuruldu, 0 ACU tabanı ise Kasım 2024’teki sıfıra ölçekleme duyurusuyla geldi.

Buffer pool (MySQL’de innodb_buffer_pool_size, PostgreSQL’de shared_buffers), o anki ACU değeriyle birlikte ölçeklenir. Instance büyürken buffer pool büyür; küçülürken küçülür. Bu alışılmadık bir durumdur: çoğu veritabanı buffer pool’u açılışta sabit bir tahsis olarak ele alır ve yeniden boyutlandırmak çevrim dışı bir işlemdir. Aurora’nın işlem katmanı, buffer pool belleğinin yerinde yeniden boyutlandırılması için mühendisliği yapılmıştır. Scaling daemon’un genelde etkili olmasını sağlayan teknik gerçek budur. Buna karşılık max_connections açılışta sabittir ve cluster için yapılandırılan maksimum ACU değerinden türetilir. Aşağı ölçekleme max_connections değerini düşürmez, yani instance küçüldüğünde kurulmuş bağlantılar düşmez. Bir veritabanı işlem katmanı için doğru varsayılan budur. Anlamı şu: maksimumu 4 ACU olan bir cluster, gerçekte hangi noktada çalıştığından bağımsız olarak max_connections’ı 4 ACU’ya uygun değerde yapılandırır.

Caspian altyapısı

Aurora işlem birimlerini fiziksel host’lar üzerinde planlayan ısı yönetimi (heat management) altyapısının iç adı Caspian’dır. AWS dokümanları bu adı kullanmaz; herkese açık kanonik referans, Marc Brooker’ın aşırı abone (oversubscribed) host’lardaki ısı yönetimini ayrıntılı tartıştığı Resource Management in Aurora Serverless yazısıdır. Caspian’ın işi, çok sayıda Aurora compute instance’ını paylaşılan host’lara sığdırmak ve bir instance’ın talebi komşularının verebileceğinden daha hızlı büyüdüğünde onu host’lar arasında taşımaktır. Cluster perspektifinden bu görünmezdir: bir ölçekleme olayı ACU tahsisini büyütür, ve ya o anki host kapasiteye sahiptir ya da Caspian instance’ı yeterli alana sahip bir host’a taşır.

Kaçınılması gereken ifade şudur: “bu, önceden hazırlanmış instance’lardan oluşan sıcak bir havuzdur.” O, Serverless v1 modeliydi ve v2 öyle çalışmıyor. Atanmayı bekleyen sıcak yedek instance havuzu yoktur. Her biri pek çok kiracı instance çalıştıran Aurora compute host filolarından oluşan bir alt yapı vardır; yük değiştikçe kaynaklar bu host’ların içinde ve aralarında yeniden tahsis edilir. Yukarı ölçeklemenin hızlı görünmesinin sebebi, bir instance’ın bir kuyruktan çekilmesi değildir; mevcut instance’a o anki host üzerinde daha fazla bellek ve CPU tahsis edilir, veya boşluğu olan bir host’a taşınır.

Scaling daemon

Scaling daemon, yükü gözlemleyen ve ACU tahsisini ayarlayan bileşendir. Girdileri CPU, bellek ve ağ kullanımıdır; AWS dokümanları bunları topluca “the load” olarak adlandırır. Çıktısı, yapılandırılan minimum ve maksimum ile sınırlanmış bir hedef ACU değeridir. Tetikleyiciler sayısal olarak yayımlanmamıştır; dokümanlar, kapasitenin bu üç boyuttan herhangi birinde sıkıştığında, veya Aurora’nın ölçeklemeyle çözebileceği performans sorunlarını algıladığında ölçeklemenin gerçekleştiğini söyler. Her writer ve her reader instance birbirinden bağımsız ölçeklenir.

Ölçekleme yerinde gerçekleşir. Dokümanlar her durumda sıfır bağlantı kaybı sözü vermez, ama tipik bir ölçekleme olayı failover içermez, motoru yeniden başlatmaz ve kurulmuş oturumları düşürmez. ACU değeri değiştikçe buffer pool boyutu da ayarlanır. Motor sayfaları boşaltıp yeniden yüklemez; alttaki bellek tahsisi büyür veya küçülür ve motorun kullanılabilir önbellek alanı görüşü onu izler.

AWS sayısal bir ölçekleme gecikmesi SLA’i yayımlamaz. Dokümanlar “rapidly” sözcüğünü kullanır ve ölçeklemeyi tek bir sıçrama olarak değil, saniye düzeyinde adım adım gerçekleşen bir süreç olarak tanımlar. Beklentiyi kalibre etmek için doğru yer burasıdır: 1 ACU’dan 32 ACU’ya geçiş anlık değildir çünkü daemon adımlarla tırmanır, ancak her bir adım hızla tamamlanır.

Aurora Auto Scaling: kasıtlı bir eksik

CPU kullanımına göre yeni reader replika ekleyen eski Aurora Auto Scaling özelliği, Serverless v2 üzerinde açıkça desteklenmemektedir. Requirements dokümantasyonu şöyle der: “Aurora Auto Scaling isn’t supported. This type of scaling adds new readers to handle additional read-intensive workload, based on CPU usage. However, scaling based on CPU usage isn’t meaningful for Aurora serverless.”

Bu, doküman ekibinin mimari modeli yazılı olarak onaylamasıdır. Serverless v2’de ölçekleme birimi instance’tır, replika sayısı değil. Her reader, daha fazla kapasiteye ihtiyaç duyduğunda kendi kendini büyütür. Yeni reader eklemek hâlâ kasıtlı bir operatör eylemidir; tek bir instance’ın boyutundan bağımsız olarak hizmet veremeyeceği bir okuma eşzamanlılığı oluştuğunda gerçekleşir, ama bir otomatik ölçekleme ilkel’i değildir. Yük altında bir Serverless v2 cluster’ının kendiliğinden reader ekleyeceğini bekleyen mühendisler, provisioned modelden analoji yaparak akıl yürütüyorlar; dokümanlar bu kapıyı açıkça kapatıyor.

CPU temelli replika ekleme Serverless v2 için “anlamlı” değil çünkü her Serverless v2 reader zaten CPU baskısına ACU tahsisini büyüterek yanıt veriyor. Yeni bir reader eklemek, ölçekleme tepkisinin üzerine daha yavaş, daha kaba taneli bir sinyali bindirirdi. Bu sınırlamayı doğru okumak şudur: eksik bir özellik değil, v2 mimarisinin v1 ve provisioned Aurora’nın harici bir denetleyiciyle yaptığını içselleştirdiğinin bir ifadesi.

Sıfıra ölçekleme: tek mimari ek yeri

Sıfıra ölçekleme Kasım 2024’te kullanıma sunuldu. Minimum ACU’yu 0 olarak ayarlamak, --serverless-v2-scaling-configuration flag’i üzerindeki SecondsUntilAutoPause parametresi ile kontrol edilen bir otomatik duraklatma davranışı etkinleştirir; parametre 300 saniye ile 86.400 saniye arasında yapılandırılabilir. Yapılandırılan boş bekleme aralığı, niteliğe uygun bir etkinlik olmadan tamamlanırsa instance duraklatılır; sonraki bağlantı denemesinde geri açılır.

“İnce scaling daemon” çerçevesinin gerçekten zorlandığı tek nokta burasıdır. Orijinal Aurora tasarımı uzun ömürlü compute instance’ları varsayar; duraklatma ve devam etme bu resmin içinde değildir. AWS, daha derin bir uyku durumu ve ölçülü bir devam etme yolu ile bu eki etrafında mühendislik yaptı, ama dikiş yeri uygulama tarafından duraklatma sonrası ilk istek gecikmesi olarak görünür.

Motor sürüm tabanı

Sıfıra ölçekleme yeni motor sürümleri gerektirir: Aurora PostgreSQL en az 16.3, 15.7, 14.12 veya 13.15; Aurora MySQL en az 3.08.0. Aynı parameter family üzerindeki eski motor sürümleri sıfıra ölçekleme alamaz. Bu, mevcut bir filo üzerinde Serverless v2’yi değerlendirirken kolayca gözden kaçan türden bir gerekliliktir: örneğin Aurora PostgreSQL 15.4 çalıştıran bir cluster, Serverless v2’de çalışır, ama otomatik duraklatma devreye girmez.

Otomatik duraklatmayı engelleyen koşullar

Otomatik duraklatma dokümantasyonu, bir duraklatmayı bloklayan koşulları listeler. Mimari olarak ilginç olanlar arasında şunlar var:

• Kullanıcı tarafından başlatılmış herhangi bir açık bağlantı. Yönetimsel health-check bağlantıları sayılmaz.
• Devam eden patching veya yükseltme işlemleri.
• PostgreSQL logical replication veya MySQL binlog replication açıksa: writer ve failover-tier-0 veya tier-1 reader’lar duraklamaz; bu yapılandırmada yalnızca failover önceliği 2 veya daha yüksek olan reader’lar duraklayabilir.
• Bazı yapılandırmalarda ilişkili bir RDS Proxy.

Replikasyon maddesi vurgulanmaya değer. Analitik, change data capture veya bölgeler arası yayılım için başka bir sisteme logical replication yapan bir cluster’ın writer’ı duraklayamaz. Bu doğrudur: writer duraklarsa, replikasyon akışı durur. Bu aynı zamanda yaygın bir üretim yapılandırmasının, yani aşağı akış bir veri platformunu besleyen logical replication’ın, writer tarafı otomatik duraklatma ile yapısal olarak uyumsuz olduğu anlamına gelir.

Devam etme mekanikleri

Yakın geçmişteki bir duraklamadan tipik devam etme gecikmesi yaklaşık 15 saniyedir. 24 saatten uzun süren bir duraklamanın ardından Aurora instance’ı daha derin bir uyku durumuna alır ve devam etme gecikmesi yaklaşık 30 saniyeye veya daha fazlasına çıkar. Dokümantasyon, istemci connectTimeout değerinin en az 15 saniyeye, uzun duraklama olasılığı olan cluster’lar için en az 30 saniyeye ayarlanmasını önerir. Bu, sıfıra ölçeklemenin uygulama tarafındaki en görünür etkisidir ve özelliğin bir iş yüküne uyup uymadığını en doğrudan belirleyen olgudur: 15 saniyelik bir soğuk başlangıca tahammülü olmayan senkron bir istek yolu, birincil veritabanında sıfıra ölçeklemeyi kullanamaz.

Devam etme soğuk başlar

Otomatik duraklatma dokümantasyonunda yük taşıyan bir cümle var: “a relatively small capacity and scales up from there. This starting capacity applies even if the DB instance had some higher capacity immediately before it was automatically paused.” Başka bir deyişle, devam etme duraklama öncesi kapasiteyi geri yüklemez. Düşük bir ACU değerinde başlar ve scaling daemon’un yeniden tırmanmasına izin verir.

Bu cümle, buffer pool sıcaklığı hikâyesini baştan yazar. Olağan yerinde yukarı ve aşağı ölçeklemede buffer pool, ACU tahsisi ile boyut değiştirir, ama daha küçük boyutta zaten önbelleğe alınmış girdiler mümkün olduğunca korunur: yukarı ölçekleme bellek ekler, önbelleği silmez. Otomatik duraklatma sonrası instance soğuk başlar: buffer pool boştur, plan cache soğuktur ve ilk sorgular tam sayfa-getirme ve ayrıştırma maliyetlerini öder. Büyük sıcak çalışan kümeleri olan iş yükleri için sıfıra ölçeklemenin pratik bedeli bu yüzden 15 saniyelik devam etme değil, önbellek yeniden ısınırken yaşanan dakikalar süren bozulmuş gecikmedir.

Mimari dikiş yeri budur. Sıfıra ölçekleme, önbellek maliyetinin küçük olduğu düşük trafikli cluster’lar için, gecikmenin önemsiz olduğu geliştirme cluster’ları için ve yavaş bir ilk sorguyu absorbe edebilen read replika’lar için uygundur. Gecikmeye duyarlı trafiği işleyen bir üretim birincilinde ücretsiz bir anahtar değildir.

Karışık modlu cluster’lar

Tek bir Aurora cluster, Serverless v2 ve provisioned instance’ları herhangi bir kombinasyonda karıştırabilir. Depolama katmanı paylaşılır ve işlem katmanı modu ne olursa olsun aynı cluster volume’a bağlandığı için, instance’ları modlar arasında değiştirmek cluster düzeyinde değil instance düzeyinde bir işlemdir.

Üretimde iki yapı tekrarlanır:

Birincisi, provisioned writer ve Serverless v2 reader’lar. Bu, istikrarlı ve öngörülebilir yazma hızlarına ve değişken okuma yüklerine sahip iş yüklerine, veya Serverless v2 tavanının şu anda absorbe edebileceğinin ötesinde ölçekteki yazma iş yüklerine uyar. Provisioned writer, kararlı ve öngörülebilir yazma throughput’u verir; Serverless v2 reader’lar, okuma fan-out değişkenliğini operatör müdahalesi olmadan absorbe eder.

İkincisi, Serverless v2 writer ve provisioned reader’lar. Bu, dalgalı yazma ve kararlı, iyi anlaşılmış okuma profili olan iş yüklerine uyar. Serverless v2 writer, yazma dalgasıyla birlikte ölçeklenir; provisioned reader’lar, okuma tarafı için kararlı, öngörülebilir maliyet ve kapasite sağlar. Bu iki yapı, otomatik duraklatma sayfasında açıkça önerilen yapılandırmalardır; sırasıyla geliştirme/test sistemleri ve yüksek erişilebilirlikli üretim sistemleri için kanonik düzenler olarak sunulur.

Yükseltme yolu üzerine pratik bir not: bazı Aurora motor sürüm yükseltmeleri, eski minor sürümlerden başlarken provisioned writer ile başlamayı ve sonrasında Serverless v2’ye dönüştürmeyi gerektirir. Bu, sürüm-sürüm yükseltme ön koşullarının bir parçası olarak belgelenmiştir, ve doğru kontrol noktası Serverless v2 girişi değil, requirements sayfasıdır. Serverless v2 dönüşümüyle birlikte bir major sürüm yükseltmesi planlayan ekipler, iki işlemin tek adımda olabileceğini varsaymamalıdır.

Katman yığınına bir bakış

Aşağıdaki Mermaid diyagramı, Aurora Serverless v2’yi oluşturan dört katmanı ve aralarındaki bağımlılık yönünü gösterir.

Diyagram bağımlılık açısından bilinçli olarak aşağıdan yukarı okunur. Depolama katmanı, geri kalanın üzerine kurulduğu temeldir. İşlem katmanı, Caspian-yönetimli bir host üzerinde belirli bir ACU tahsisinde çalışan Aurora motorudur. Scaling daemon, yükü gözlemleyen ve ACU tahsisini ayarlayan bir denetleyicidir. Faturalama yüzeyi, müşterinin faturada gördüğüdür. Her katman, altındaki depolama katmanına kıyasla incedir.

Adı konulması gereken mimari sınırlar

Birçok Serverless v2 sınırlaması, keyfi boşluklar olarak değil, alttaki mimarinin ifadeleri olarak en iyi şekilde anlaşılır. Requirements dokümantasyonu bunları sıralar.

Database Activity Streams (DAS) Serverless v2’de desteklenmiyor. DAS, provisioned Aurora’da uyumluluk ve denetim kullanım örnekleri için veritabanı etkinliğini Kinesis’e akıtır. Serverless işlem katmanında mevcut değil. DAS’ı zorunlu kılan uyumluluk gereksinimleri olan ekipler bu iş yüklerini bugün Serverless v2’de çalıştıramaz.

Aurora PostgreSQL için cluster cache management devre dışıdır. Writer üzerinde bir replika’nın önbelleğini önceden ısıtarak hızlı crash recovery sağlayan apg_ccm_enabled parametresinin Serverless v2 instance’larında etkisi yoktur. Özellik, önbellek içeriklerinin kararlı olduğu sabit boyutlu provisioned reader’lar için vardır; Serverless v2’de önbellek içeriği ACU değeriyle değişir ve önceden ısıtma anlamlı değildir.

Aurora Auto Scaling, yukarıda tartışıldığı gibi desteklenmez ve anlamlı değildir. Reader sayısı operatör tarafından yönetilir; reader başına kapasite otomatiktir.

Bölgesel kullanılabilirlik tek tip değildir. Supported regions and engines sayfası yetkili referanstır; son eklemeler (özellikle AWS GovCloud ve bazı yeni ticari bölgeler) özelliklerin duyuru tarihinden aylar sonra gelir. Daha az yaygın bölgelerde işlem yapan ekipler, sıfıra ölçeklemenin veya 256 ACU tavanının yerel olarak mevcut olduğunu varsaymadan önce bölgeler matrisine doğrudan bakmalıdır.

Motor sürüm gereksinimleri evrilmeye devam ediyor. Aurora MySQL 8.0, aurora-mysql8.0 parameter family ile destekleniyor. Aurora PostgreSQL 13’ten 17’ye, aurora-postgresql13 ile aurora-postgresql17 arasındaki family’lerle destekleniyor. Serverless v2 üzerinde PostgreSQL 17 desteği güncel durum ve birçok eski yazının ima ettiğinden daha yeni; bu hızlı hareket eden bir olgu ve ikincil kaynaklar yerine doğrudan bölgeler sayfasıyla doğrulamaya değer.

Kapanış

Aurora Serverless v2’yi en iyi şekilde, provisioned cluster’ları çalıştıran aynı Aurora işlem ve depolama altyapısının üzerinde duran bir scaling daemon ve bir faturalama sarmalayıcısı olarak anlamak gerekir. Depolama katmanı değişmemiştir. İşlem katmanı, Caspian-yönetimli host’lar üzerinde esnek bir ACU tahsisinde çalışan Aurora motorudur. Scaling daemon her writer ve her reader üzerinde CPU, bellek ve ağı bağımsız olarak izler ve failover olmadan yerinde yeniden boyutlandırır. Karışık modlu cluster’lar çalışır çünkü her instance, serverless veya provisioned, aynı paylaşılan volume’a bağlanır. Mimari dikiş yeri sıfıra ölçeklemedir: tanıtıldığı gibi çalışır, ama devam etme hem ACU düzeyinde hem önbellek düzeyinde soğuk başlar. Bu kombinasyon, herhangi bir cluster üzerinde etkinleştirme kararını yönlendirmesi gereken etmendir.

Bu modelden çıkan tavsiye şudur: iş yükü, otomatik doğru-boyutlandırmanın operasyonel tasarrufunun paylaşılan ve aşırı abone edilmiş işlem üzerinde çalışmanın maliyetini aştığı kadar değişkenken Serverless v2’yi seçin. İş yükü kararlıyken, önbellek düzeyinde gecikmeye duyarlıyken veya serverless katmanın henüz desteklemediği DAS gibi özellikler gerektirirken provisioned Aurora’ya yönelin. Sıfıra ölçekleme, senkron kullanıcı trafiği işleyen üretim birincillerinde değil, düşük trafikli ve geliştirme cluster’larında ulaşılacak bir koldur.

Kaynaklar

• Using Aurora serverless - Aurora serverless dokümantasyonunun kanonik giriş noktası; tüm alt sayfalar buradan dallanır, URL slug’ı v2’yi korur.
• How Aurora serverless works - Ölçekleme tetikleyicileri, yerinde ölçekleme semantiği, provisioned ile depolama eşdeğerliği, karışık modlu cluster yapılandırmaları.
• Performance and scaling for Aurora serverless - ACU tanımı, buffer pool ölçekleme davranışı, max_connections semantiği, kapasite için CloudWatch metrikleri.
• Requirements and limitations for Aurora serverless - 0.5 ACU adımlarındaki kapasite aralığı, DAS ve Aurora Auto Scaling dahil desteklenmeyen özellikler, motor ve platform bağımlılıkları.
• Scaling to Zero ACUs with automatic pause and resume - Motor sürüm tabanı, otomatik duraklatmayı engelleyen koşullar, devam etme gecikme rakamları, replikasyon-engelleme kuralları.
• Aurora storage and reliability - Üç AZ’a yayılmış altı kopya, cluster volume mekanikleri, otomatik yeniden boyutlandırma davranışı.
• Supported Regions and engines for Aurora serverless - Bölge ve motor sürüm kullanılabilirlik matrisi; özellik desteğini iddia ederken yetkili kaynak.
• Introducing scaling to 0 capacity with Amazon Aurora Serverless v2 - Otomatik duraklatmanın Kasım 2024 AWS Database Blog duyuru yazısı; Nisan 2026 yeniden adlandırma banner’ını taşır.
• Aurora Serverless v2 now supports up to 256 ACUs - 3 Ekim 2024 duyurusu, tavanı 128 ACU’dan 256 ACU’ya çıkardı.
• Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases (SIGMOD 2017) - Verbitski ve arkadaşları; depolama katmanı, redo offload ve “log is the database” prensibini kapsayan kurucu Aurora mimari makalesi.
• Amazon Aurora: On Avoiding Distributed Consensus for I/O, Commit, and Membership Changes (SIGMOD 2018) - Verbitski ve arkadaşları; Aurora’nın 4/6 yazma ve 3/6 okuma quorum semantiğini formalize eder ve Paxos’un neden sıcak yolda olmadığını açıklar.
• Marc Brooker: Resource Management in Aurora Serverless - AWS Databases Principal Engineer; Caspian, aşırı abonelik ve Aurora Serverless’taki ısı yönetimi üzerine en erişilebilir açık yazı.
• Amazon Aurora design: cloud-native relational database (All Things Distributed) - Werner Vogels’in Aurora tasarım anlatısını çerçeveleyişi; bağlam için yararlı, Serverless v2’den öncedir.