Amazon SAA-C03: Veritabanları ve Önbellekleme — Çalışma kılavuzu

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Şunun bir parçası: AWS SAA-C03 — Eksiksiz çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Amazon sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Amazon RDS: Yönetilen İlişkisel Motorlar

Amazon RDS, altı yönetilen motor sunar — MySQL, PostgreSQL, MariaDB, Oracle, SQL Server ve Amazon Aurora (MySQL ve PostgreSQL uyumlu) — bu sayede yama yönetimi, yedeklemeler, replikasyon topolojisi ve yük devretme gibi işlemleri soyutlar. Motor seçimi; lisanslamayı, yedekleme semantiğini ve özelliklerin kullanılabilirliğini belirler: Oracle ve SQL Server, BYOL (Kendi Lisansını Getir) ve Lisans Dahil seçenekleri sunar, SQL Server yerel replikasyon aracılığıyla beş adede kadar okuma replikasını destekler ve Oracle okuma replikaları için Enterprise Edition ile Active Data Guard gerektirir.

Kullanılabilirlik ve ölçeklendirme için en çok yararlanılan ve en sık karıştırılan iki RDS özelliği Çoklu AZ (Multi-AZ) dağıtımları ve okuma replikalarıdır. Bu ikisi birbirinden bağımsız, birbirini tamamlayıcı ve birbirinin yerine geçemez niteliktedir.

Çoklu AZ, ikinci bir Erişilebilirlik Alanı’nda (Availability Zone) senkron bir yedek replika oluşturur. Her yazma işlemi, onaylanmadan önce hem birincil hem de yedek veritabanına işlenir. Bu, RPO’yu (Kurtarma Noktası Hedefi) etkin bir şekilde sıfıra indirir ve otomatik yük devretme sırasında 60-120 saniyelik bir RTO (Kurtarma Süresi Hedefi) sağlar. Yedek replika trafik kabul etmez — yalnızca yük devretme amacıyla mevcuttur. Birincil veritabanı arızalandığında, bir AZ’de sorun olduğunda veya bakım yeniden başlatma gerektirdiğinde, RDS DNS CNAME’i yedeğe yönlendirir ve uygulamalar aynı uç nokta üzerinden şeffaf bir şekilde yeniden bağlanır. Çoklu AZ, tek bir AZ’deki tek hata noktasını (single point of failure) düzeltmek için en az çaba gerektiren çözümdür: bu bir yapılandırma seçeneğidir, şema veya uygulama değişikliği gerektirmez ve uç noktayı korur. Daha yeni olan Çoklu AZ küme dağıtımı, yarı senkron replikasyon kullanan üç düğümlü bir topolojidir (bir yazıcı, iki okunabilir yedek). Yaklaşık bir saniyelik işleme gecikmesiyle hem yüksek kullanılabilirlik (HA) hem de sınırlı okuma yükü dağıtımı sağlar.

Okuma replikaları, motorun yerel asenkron replikasyonunu kullanır (MySQL binlog, PostgreSQL WAL streaming). Aksi takdirde birincil veritabanındaki OLTP işlemlerini yavaşlatacak olan analitik sorgular, raporlama panoları, anlık SELECT sorguları gibi okuma ölçeklendirmesi için doğru araçtır. Klasik senaryo: çalışanların ay sonu uzun raporlar çalıştırması nedeniyle sipariş işleme veritabanının zaman aşımına uğraması. Bir okuma replikası ekleyip raporlama aracını bu replikanın uç noktasına yönlendirmek, birincil veritabanının boyutunu artırmadan analitik yükü izole eder. Okuma replikaları bölgeler arası (cross-region) olabilir ve manuel olarak bağımsız veritabanlarına yükseltilebilir, ancak bu yükseltme asla otomatik değildir ve arıza anında henüz replike edilmemiş işlemler kaybolur.

Bu alanda iki tuzak sıkça tekrarlanır. Birincisi, okuma replikalarını bir HA çözümü olarak görmek birçok açıdan yanlıştır: replikalar asenkrondur (potansiyel veri kaybı), otomatik yükseltme mekanizması yoktur, yükseltme sonrası uç nokta değişir ve işlem anındaki (in-flight) sorgular kaybolur. Eğer bir tasarım “sıfır veri kaybı” vaat ediyor ve yük devretme hedefi olarak bir okuma replikasını gösteriyorsa, bu vaat yanlıştır. İkincisi, okuma trafiğine hizmet etmek için Çoklu AZ sağlamak para israfıdır, çünkü standart topolojide yedek veritabanı okunabilir değildir. Çoklu AZ kullanılabilirlik sorununu çözer; okuma replikaları okuma ölçeği sorununu çözer; genellikle her ikisine de ihtiyaç duyarsınız.

Okuma replikaları yazma ölçeklendirmesi için de bir şey yapmaz — her yazma işlemi yine birincil veritabanına gider ve replikaların bunu tekrar etmesi gerekir. Yazma ölçeği için, veri parçalama (sharding) yapar, Aurora’ya (ayrıştırılmış depolama) geçer veya DynamoDB’ye yönelik bir yeniden tasarım yaparsınız.

Okuma Replikalarını Doğru Boyutlandırma

Bir replikanın, birincil veritabanının örnek sınıfıyla eşleşmesi gerekmez. Birincil veritabanı tam yazma yükünü ve okuma işlemlerini karşılarken; bir replika yalnızca kendisine yönlendirilen okuma işlemlerini karşılar. Gece çalıştırılan bir raporlama işi için db.r6i.4xlarge birincil veritabanının db.r6i.large bir replika ile eşleştirilmesi, replikanın replikasyon I/O’suna yetişebilmesi koşuluyla tamamen makuldür. Yöntem şudur: replikanın gerçek CPU, bellek ve replika gecikmesini (replica lag) ölçün, ardından bu iş yüküne göre boyutlandırın. Tek istisna: Bir felaket kurtarma (DR) senaryosunda replikayı birincil veritabanı yapmak niyetindeyseniz, yazma yükünü kaldırabilecek şekilde boyutlandırılmalıdır. Yetersiz boyutlandırılmış replikalar yükseltme hedefi olamaz.

Mavi/Yeşil Dağıtımlar ve Depolama

RDS Mavi/Yeşil Dağıtımlar, üretim ortamının (yeşil) tam bir hazırlık kopyasını oluşturur ve bu kopya mantıksal replikasyon yoluyla senkronize kalır. Yeşil ortamda motor sürümünü yükseltir, parametre gruplarını değiştirir veya şemaları düzenlersiniz, test edersiniz ve otomatik uç nokta yeniden adlandırma ile bir dakikadan kısa sürede geçiş yaparsınız. Bu, başarısız bir ana sürüm yükseltmesinin bir snapshot’tan geri dönmeyi zorunlu kıldığı klasik yerinde yükseltme riskini ortadan kaldırır.

Yazma ağırlıklı OLTP için depolama seçimi, örnek sınıfı kadar önemlidir. gp3/io2 sınıflandırması:

gp3’ün gp2’ye göre iyileştirmesi, IOPS’u boyuttan ayırmasıdır — artık performans için kapasiteyi gereğinden fazla sağlamanıza gerek kalmaz. Sürekli IOPS ihtiyacı gp3’ün tavanını aştığında veya %99.999 dayanıklılık gerektiğinde io2’yi seçin. Multi-Attach, tek bir io2 biriminin 16 adede kadar Nitro örneğine bağlanmasına izin verir, ancak dosya sistemi veya uygulamanın küme farkındalığına sahip olması gerekir; bu, replikasyonun bir alternatifi değildir. Gizli bir kesinti tuzağı: depolama alanını otomatik ölçeklendirme etkinleştirilmeden veya FreeStorageSpace için bir CloudWatch alarmı olmadan sabit depolama alanı sağlamak. Boş alan sıfıra ulaştığında, RDS storage-full durumuna girer ve yazma işlemlerini reddeder.

Amazon Aurora: Mimarisi ve Uç Noktaları

Aurora, MySQL ve PostgreSQL’in altındaki depolama katmanını, üç AZ’ye yayılan, dağıtık, log yapılı, altı yönlü replike edilmiş bir birim olarak yeniden uygular. Hesaplama düğümleri depolamaya göre durumsuzdur (stateless), bu nedenle bir Aurora Replicası, bir logu yeniden oynatmak yerine yazıcı ile aynı temel birimden okuma yapar. Replikasyon gecikmesi (lag) genellikle 10-20 ms’dir, standart RDS replikaları için ise bu süre saniyeler mertebesindedir ve bir küme, yaklaşık 30 saniye içinde yazıcıya (writer) yükseltilebilen 15 adede kadar replikayı destekler.

Aurora dört tür uç nokta (endpoint) sunar:

Özel uç noktalar, replikalar heterojen olduğunda önem kazanır. Altı replikadan üçü analitik raporlama için db.r6g.8xlarge iken geri kalanı OLTP okumalarına hizmet ediyorsa, genel okuyucu uç noktası zaman zaman raporlamayı daha küçük düğümlere yönlendirerek öngörülebilirliği zayıflatır. Yalnızca büyük replikaları kapsayacak şekilde yapılandırılmış özel bir uç nokta, deterministik iş yükü izolasyonu sağlar:

aws rds create-db-cluster-endpoint \
  --db-cluster-identifier prod-aurora \
  --db-cluster-endpoint-identifier reporting \
  --endpoint-type READER \
  --static-members reporting-node-1 reporting-node-2 reporting-node-3

Aurora uç noktası DNS TTL’lerinin 5 saniye olduğunu unutmayın; bağlantı dizelerini (connection strings) daha uzun süre önbelleğe almak, yük devretme (failover) davranışını bozar.

Aurora Auto Scaling, hedef CPU veya bağlantı metriklerine göre okuyucular (reader) ekleyip kaldırır. Bu, yüksek oranda erişilebilir kalması gereken, öngörülemeyen, okuma ağırlıklı iş yükleri için standart çözümdür:

TargetTrackingScalingPolicyConfiguration:
  PredefinedMetricSpecification:
    PredefinedMetricType: RDSReaderAverageCPUUtilization
  TargetValue: 60.0
  ScaleInCooldown: 300
  ScaleOutCooldown: 60

RDS MySQL okuma replikaları, yoğun zamanlarda replikasyon gecikmesini bir saniyenin altında tutamadığında, az kodlama gerektiren çözüm Aurora MySQL’e geçiş yapmaktır — bağlantı dizeleri neredeyse hiç değişmez ve depolama seviyesindeki replikasyon gecikmeyi ortadan kaldırır.

Aurora Serverless v2 ve Klonlama

Aurora Serverless v2, hesaplama gücünü, oturumları kesmeden yaklaşık yarım saniyede, hassas taneli Aurora Kapasite Birimleri (ACU, her biri 2 GiB bellek) cinsinden dikey olarak ölçeklendirir. Bu, bilinen bir temel bellek ayak izine sahip değişken iş yükleri için uygundur — örneğin, her zaman en az 2 GiB tüketen şirket içi (on-prem) bir MySQL geçişi. Minimum 1 ACU, maksimum 32 ACU olarak ayarlayın; küme yönetim gerektirmeden esneklik gösterir. Yük sabit ve öngörülebilir olduğunda Provisioned Aurora tercih edilir, çünkü Serverless v2 ACU başına bir ek maliyet getirir.

Aurora klonlama, kaynak kümenin depolama sayfalarını copy-on-write (yazma anında kopyalama) yoluyla paylaşan yeni bir küme oluşturur. Klonlar saniyeler içinde oluşur ve veriler farklılaşana kadar hiçbir maliyeti yoktur. Bu da onları hazırlık (staging) ortamları, riskli geçişler veya analistlerin bir üretim kopyası üzerinde yoğun işlem yapmasına izin vermek için ideal kılar. Bir anlık görüntüden (snapshot) geri yükleme, veriyi fiziksel olarak yeniden oluşturur ve saatler sürebilir; hız önemli olduğunda klonlama kazanır.

Aurora Global Database

Aurora Global Database, özel depolama katmanı replikasyon altyapısı kullanarak — binlog gönderimi değil — bir kümeyi beşe kadar ikincil Bölgeye (Region) genişletir. Tipik replikasyon gecikmesi bir saniyenin altındadır, RPO bir saniyenin altındadır ve yönetilen yük devretme (managed failover) bir ikincil bölgeyi bir dakikadan kısa sürede yükseltir.

İki kritik semantik: ikincil bölgeler normal çalışma sırasında salt okunurdur ve Global Database, aktif-aktif çoklu ana (multi-master) için değil, düşük RPO’lu DR (Felaket Kurtarma) ve düşük gecikmeli uzaktan okumalar için tasarlanmıştır. Bir global veritabanının “ikincil bölgedeki yazmaları otomatik olarak yönettiğini” varsaymak yanlıştır — oraya yazma işlemi, açıkça yönetilen bir yük devretme veya ayırma ve yükseltme (detach-and-promote) gerektirir. Bölgeler arasında minimum operasyonel yük ile 5 dakikalık RPO / 20 dakikalık RTO gereksinimi belirtildiğinde, Global Database standart çözümdür.

RDS Proxy ve Bağlantı Yönetimi

Sunucusuz (serverless) ve yüksek eşzamanlılığa sahip iş yükleri, klasik bir sorunu daha da kötüleştirir: bağlantı fırtınaları (connection storms). 3.000 eşzamanlı yürütmeye ölçeklenen bir Lambda işlevi, 3.000 soket açarak max_connections sınırını aşar ve tam da sistem yük altındayken zincirleme arızalara neden olur. Her eşzamanlı yürütme ortamı yalıtılmış olduğu için işlev içi havuzlar (in-function pools) yardımcı olmaz.

RDS Proxy, istemciler ile veritabanı arasında yer alarak sıcak bir bağlantı havuzu tutar ve istemci oturumlarını bu havuzdaki bağlantılar üzerine çoklar (multiplexing). İki sorunu çözer:

1. Bağlantı fırtınaları. Binlerce istemci oturumu, küçük bir arka uç (backend) havuzuna çoklanır.
2. Yük devretme süresi. Proxy, arka uç bağlantısını yeniden kurarken istemci bağlantılarını açık tutar, bu da algılanan yük devretme süresini %66’ya kadar azaltır ve istemci tarafında TCP/TLS yeniden kurulumunu ve DNS yeniden çözümlemesini ortadan kaldırır.

Kimlik bilgisi yönetimi için IAM ve Secrets Manager ile entegre olur, böylece uygulama kodundan sabit kodlanmış sırları (hard-coded secrets) kaldırır.

DBProxy:
  Type: AWS::RDS::DBProxy
  Properties:
    EngineFamily: POSTGRESQL
    RequireTLS: true
    IdleClientTimeout: 1800
    Auth:
      - AuthScheme: SECRETS
        SecretArn: !Ref DBSecret
        IAMAuth: REQUIRED

Uygulamalar, küme uç noktasına değil, proxy uç noktasına bağlanır. Özel bir neden olmadıkça, herhangi bir Lambda-RDS veya yüksek fan-out mimarisi RDS Proxy kullanmalıdır. EC2 üzerinde kendi bağlantı havuzlayıcınızı (PgBouncer, ProxySQL) çalıştırmak mümkündür, ancak bu, proxy’nin ortadan kaldırmak için var olduğu operasyonel yükü ekler.

DynamoDB: Kapasite Modları

DynamoDB, hash anahtarına göre yatay olarak bölümlenmiş, her ölçekte tek haneli milisaniye gecikme süresi sunan, yönetilen bir anahtar-değer/belge deposudur. İki kapasite modu sunar:

İsteğe bağlı mod önemli ölçüde daha basittir ancak iyi kullanılan sağlanmış kapasiteye göre istek başına yaklaşık 6-7 kat daha maliyetlidir. Geceleri 4 saat süren 500 WCU’luk bir toplu işlem için isteğe bağlı modda önemli ölçüde fazla ödeme yapılır — zamanlanmış ölçeklendirme veya rezerve kapasite ile sağlanan mod çok daha ucuzdur. Tersine, öngörülemeyen bir halka açık lansman iş yükü için sağlanan modu kullanmak kısıtlamaya (throttling) yol açar. Orta düzeyde değişkenliğe sahip düzenli iş yükleri için, %70 kullanım oranı civarında hedef izlemeli otomatik ölçeklendirme ile sağlanan mod, isteğe bağlı moddan anlamlı derecede daha ucuzdur — genellikle %50-70 oranında:

TargetTrackingScalingPolicyConfiguration:
  TargetValue: 70.0
  PredefinedMetricSpecification:
    PredefinedMetricType: DynamoDBReadCapacityUtilization
  ScaleInCooldown: 60
  ScaleOutCooldown: 60

Modlar arasında her 24 saatte bir geçiş yapabilirsiniz. İsteğe bağlı modun evrensel olarak daha ucuz olduğunu varsaymak maliyetli bir hatadır; aynı şekilde, ani artış gösteren trafik için sağlanan modun her zaman doğru olduğunu varsaymak da bir hatadır.

DynamoDB: Tutarlılık, Akışlar (Streams), Global Tablolar

Okumalar varsayılan olarak nihai tutarlıdır (yaklaşık 1 saniye içinde eski veriyi döndürebilir, 0.5 RCU maliyetindedir). ConsistentRead=true ayarı, maliyeti iki katına çıkararak en son kaydedilmiş değeri döndürür. Güçlü tutarlı okumalar, global ikincil indeksler veya DAX aracılığıyla desteklenmez — bu yollar her zaman nihai tutarlı veri döndürür.

DynamoDB Streams, öğe düzeyindeki değişiklikleri 24 saat boyunca saklanan sıralı bir günlük olarak yakalar ve sorgulama (polling) yapmadan akış aşağı işleme (arama indeksleme, bildirimler, tablolar arası denormalizasyon) için Lambda’yı tetikler.

Global Tablolar, son yazan kazanır (last-writer-wins) çakışma çözümü ile çoklu-aktif, çoklu-Bölge replikasyonu sağlamak için Streams üzerine kurulmuştur. Okuma ve yazmaların birden fazla Bölgede yerel olması gerektiğinde doğru yanıttır. Ancak depolama ve yazma maliyetlerini kabaca ikiye katlarlar — her yazma işlemi her replika Bölgesinde bir WCU’dur — ve Bölgeler arası tutarlılığı zayıflatırlar. Tuzak, tek bir Bölgenin erişilebilirlik gereksinimlerini karşıladığı durumlarda Global Tabloları etkinleştirmektir: Tek bir Bölgedeki DynamoDB, zaten %99.99 erişilebilirlikle üç AZ (Kullanılabilirlik Alanı) arasında replike edilir. Uygun maliyetli tek Bölgeli yüksek erişilebilirlik (HA), PITR etkinleştirilmiş ve istenirse otomatik ölçeklendirmeli sağlanan kapasiteye sahip tek Bölgeli bir tablodur.

Zaman İçinde Belirli Bir Noktaya Kurtarma (PITR), son 35 gün için saniye bazında geri yükleme hassasiyetiyle sürekli yedeklemeler sağlar ve ek yükü ihmal edilebilir düzeydedir. Herhangi bir üretim tablosunda etkinleştirin — saatler yerine dakikalar olan tipik RPO (Kurtarma Noktası Hedefi) gereksinimlerini karşılar. Daha uzun saklama süreleri (yasal saklama süreleri) için, zamanlanmış, yaşam döngüsü yönetilen, bölgeler arası kopyalanabilir yedekler için AWS Backup‘ı entegre edin.

TTL, Unix epoch formatında bir son kullanma zamanı içeren bir nitelik belirtmenize olanak tanır; DynamoDB, süresi dolan öğeleri hiçbir maliyet olmadan asenkron olarak siler. Bu, oturum depoları, geçici token’lar veya olay önbellekleri için idealdir. TTL silmeleri, akış aşağı arşivleme için Streams üzerinden akar:

TTLSpecification:
  AttributeName: expireAt
  Enabled: true

Analitik için, S3’e dışa aktarma işlemi, tablo kapasitesini tüketmeden Athena, Redshift Spectrum veya EMR tarafından okunabilen belirli bir anın anlık görüntüsünü (snapshot) oluşturur — bu, tabloyu taramaktan çok daha iyi bir yöntemdir.

DAX: DynamoDB Hızlandırıcısı

DAX, DynamoDB’nin tek haneli milisaniye temel seviyesine karşılık mikrosaniye düzeyinde okuma gecikmesi sunan, özellikle DynamoDB için tasarlanmış, tamamen yönetilen, bellek içi, yazma anında güncellenen (write-through) bir önbellektir. Ayırt edici özelliği API uyumluluğudur: DAX istemcisi, DynamoDB SDK istemcisinin doğrudan yerine geçebilen bir alternatiftir, bu nedenle uygulamalar sorgu mantığını yeniden yazmak yerine uç nokta (endpoint) yapılandırmasını değiştirerek onu benimser:

import amazondax
dax = amazondax.AmazonDaxClient(
    endpoint_url='dax://cluster.abc.dax-clusters.us-east-1.amazonaws.com')
table = dax.Table('Products')
resp = table.get_item(Key={'sku': '1234'})  # microsecond hit path

DAX iki önbellek tutar: GetItem/BatchGetItem sonuçları için bir öğe önbelleği ve Query/Scan sonuçları için bir sorgu önbelleği. Yazmalar yazma anında güncellenir (write-through) — DAX, DynamoDB’ye proxy’lik yapar ve başarı durumunda öğe önbelleğini günceller — ancak sorgu önbelleği TTL’e dayanır, bu nedenle sorgu sonuçları yeni yazılmış öğeler için bile eskiyebilir.

İki kısıtlama önemlidir. Birincisi, DAX yalnızca nihai tutarlı okumaları hızlandırır; güçlü tutarlı okumalar önbelleği atlar. İkincisi, DAX’ı atlayan diğer yazıcılar verinin eskimesine neden olur. Günde milyonlarca kez ziyaret edilen bir ürün detay sayfası için DAX, en az operasyonel yüke sahip hızlandırıcıdır — önbellek geçersizleştirme kodu yok, ayrı bir küme yönetimi yok. DynamoDB’nin önünde ElastiCache de işe yarardı ancak DAX’in gereksiz kıldığı cache-aside (önbellek kenarı) mantığını gerektirir.

ElastiCache: Redis ve Memcached

ElastiCache, Redis veya Memcached çalıştıran yönetilen bir hizmet olarak milisaniyenin altında, bellek içi veri erişimi sunar. Motor seçimi özellik odaklıdır:

• Memcached — yatay sharding özelliğine sahip, saf, çok iş parçacıklı bir anahtar/değer önbelleğidir; kalıcılık, replikasyon veya pub/sub desteği yoktur. Yalnızca tüm önbelleği kaybetmenin kabul edilebilir olduğu geçici önbellekleme için kullanılır.
• Redis — replikasyon, otomatik yük devretme ile Multi-AZ, sharding için küme modu, kalıcılık, pub/sub, sıralı kümeler, işlemler ve aktarım sırasında ve beklemedeyken şifrelemeyi destekler. Dayanıklı veya karmaşık veri türleri gerektiren her şey için gereklidir.

İki temel model öne çıkar.

Merkezi oturum deposu. Bir ALB, trafiği durum bilgisi olmayan (stateless) EC2 veya ECS örneklerine dağıttığında, yerel oturum depolaması yapışkan oturumları (sticky sessions) zorunlu kılar. Bu durum, yükü dengesizleştirir ve küçülme (scale-in), dağıtımlar ve AZ arızaları sırasında sistemi bozar. Oturumları Redis’e harici hale getirmek, herhangi bir örneğin herhangi bir isteğe hizmet vermesini sağlar ve oturumlar ana makine arızalarından etkilenmez:

import redis, json
r = redis.Redis(host='sessions.abc123.ng.0001.use1.cache.amazonaws.com',
                port=6379, ssl=True)

def save_session(sid, data, ttl=1800):
    r.setex(f"sess:{sid}", ttl, json.dumps(data))

Maliyetli sorgular için okuma yükünü hafifletme — liderlik tabloları (Redis sıralı kümeleri ile ZADD/ZREVRANGE aracılığıyla), katalog aramaları, birleştirmeler. Önbellekleme stratejileri tutarlılık ihtiyaçlarıyla eşleşmelidir:

• Lazy loading (cache-aside): uygulama önbelleği okur; isabet etmezse (miss), veritabanını okur ve önbelleği bir TTL ile doldurur. Basittir, ancak başlangıçtaki isabetsizlikler (cold misses) performansı düşürür ve veri güncelliğini yitirebilir.
• Write-through: uygulama aynı işlemde hem önbelleğe hem de veritabanına yazar. Önbellek taze kalır, ancak yazma işlemleri daha yavaştır ve kullanılmayan veriler bellekte yer kaplamaya devam eder.
• Write-back (write-behind): yazma işlemleri önce önbelleğe yapılır, ardından asenkron olarak veritabanına aktarılır. En hızlı yazma yöntemidir, ancak bir önbellek arızasında veri kaybı yaşanır.

data = r.get(f"product:{sku}")
if data is None:
    data = db.query("SELECT * FROM products WHERE sku=%s", sku)
    r.setex(f"product:{sku}", 300, serialize(data))

Bir geçersiz kılma stratejisi — TTL, güncellemede açıkça DEL kullanma veya write-through — olmadan herhangi bir önbellekleme katmanına güvenmek, güncel olmayan verilerin okunmasına (stale reads) neden olur. Bu hata modu sessizdir: kullanıcılar bir tutarsızlık fark edene kadar uygulama doğru çalışıyor gibi görünür. Önbellekleme aynı zamanda, okuma replikalarının rahatça destekleyebileceğinin ötesinde okuma işlemlerini ölçeklendirmenin en ucuz yoludur ve trafik artışları sırasında birincil veritabanını korur.

DAX’ın aksine, ElastiCache motor-bağımsızdır — geçersiz kılma mantığı size aittir — bu nedenle arka plandaki depolama DynamoDB olduğunda DAX, operasyonel basitlik açısından kazanır.

Migrasyon: DMS ve SCT

AWS Database Migration Service (DMS), homojen motorlar (Oracle→Oracle, MySQL→Aurora MySQL) veya heterojen motorlar (Oracle→Aurora PostgreSQL, SQL Server→RDS MySQL, on-prem→DynamoDB) arasında veri replikasyonu yapar. Bir DMS görevinin üç aşaması vardır:

1. Full load — mevcut satırların toplu kopyalanması.
2. CDC (change data capture) — kaynak veritabanının işlem günlüğünü (transaction log) takip etme ve devam eden değişiklikleri uygulama.
3. Full load + CDC — yaygın minimum kesinti süresi modeli: kaynak çevrimiçi kalır, DMS hedefi senkronize tutar, geçiş (cutover) kısa bir DNS değişikliği ile yapılır.

aws dms create-replication-task \
  --replication-task-identifier ora-to-aurora \
  --source-endpoint-arn $SRC --target-endpoint-arn $TGT \
  --migration-type full-load-and-cdc \
  --table-mappings file://mappings.json \
  --replication-instance-arn $RI

DMS Serverless, replikasyon örneklerini boyutlandırma ve yönetme ihtiyacını ortadan kaldırır — kapasite, iş yüküne göre otomatik olarak sağlanır ve bu da onu değişken veya uzun süreli CDC için uygun hale getirir. Kaynak motorlarda ek günlüklemenin (supplemental logging - Oracle) veya ROW formatında ikili günlüklemenin (binary logging - MySQL) etkinleştirilmiş olması gerekir. Çok büyük başlangıç verileri için DMS, çevrimdışı yüklemeler için Snowball Edge ile entegre olur.

DMS, şemayı değil veriyi taşır. Heterojen migrasyonlar için bunu, saklı yordamları (stored procedures), görünümleri (views), tetikleyicileri (triggers), sıraları (sequences) ve lehçeye özgü türleri — örneğin, Oracle PL/SQL’den PostgreSQL PL/pgSQL’e veya T-SQL’den Aurora MySQL’e — dönüştüren AWS Schema Conversion Tool (SCT) ile birlikte kullanırsınız. SCT, manuel düzenleme gerektiren nesneleri işaretleyen bir değerlendirme raporu oluşturur (karmaşık kod tabanları için genellikle %5-20). Motorlar arası bir migrasyon için yalnızca DMS çalıştırmak yaygın bir hatadır: DMS temel hedef tabloları oluşturabilse de, yordamları veya özel türleri doğru bir şekilde çevirmez. Homojen migrasyonlar için SCT gereksizdir — yerel araçlar (mysqldump, pg_dump, RMAN) ve DMS CDC yeterlidir.

Tam motorlar arası migrasyon modeli:

1. SCT: convert schema, apply to target RDS/Aurora
2. DMS full-load task: bulk copy existing data
3. DMS CDC task: capture ongoing changes from source
4. Cutover: stop writes at source, wait for CDC lag = 0, redirect app

Yedeklemeler ve Belirli Bir Zamana Geri Dönme (Point-in-Time Recovery)

RDS otomatik yedeklemeleri, günlük anlık görüntüleri (snapshots) 5 dakikalık işlem günlüğü yedekleriyle birleştirerek, saklama penceresi (1-35 gün, varsayılan 7) içindeki herhangi bir saniyeye PITR (belirli bir zamana geri dönme) olanağı tanır. Geri yükleme yeni bir örnek oluşturur — yerinde geri yükleme yapamazsınız — bu nedenle uygulama uç noktalarının veya CNAME’lerin güncellenmesi gerekir. Manuel anlık görüntüler, saklama süresinin ötesinde kalır ve örnek silinmesinden etkilenmez (son anlık görüntü ayarına bağlı olarak), DR için Bölgeler arası kopyalanabilir ve hesaplar arasında paylaşılabilir.

Fast Snapshot Restore (FSR), EBS destekli anlık görüntüler için lazy-load cezasını ortadan kaldırarak, geri yüklenen volümlerin anında tam performans vermesini sağlar — bu, zaman baskısı altında tek bir anlık görüntüden birden çok ortam oluştururken kullanışlıdır. Aurora klonlama, aynı bölgedeki kopyalar için anlık görüntüleri tamamen atlar. DynamoDB PITR, tablo başına etkinleştirilmesi gereken paralel bir özelliktir ve geri yükleme sırasında yeni bir tablo oluşturur.

Amaca Yönelik Veritabanları

Erişim desenleri gerektirdiğinde amaca yönelik bir motor seçmek, maliyetli yeniden mimarilerden kaçınmayı sağlar. Amazon Neptune, Gremlin, openCypher ve SPARQL’ı destekleyen yönetilen bir graf veritabanıdır — ilişkisel bir motorda tekrarlayan birleştirmelerin (recursive joins) aşırı maliyetli olacağı, sorguların ilişkiler arasında gezindiği (dolandırıcılık ağları, sosyal grafikler, bilgi grafikleri) durumlar için uygundur. Amazon QLDB, yalnızca ekleme yapılabilen bir günlüğe sahip, değişmez, kriptografik olarak doğrulanabilir bir defterdir (ledger); tedarik zinciri kökeni, finansal işlemler, trafik tescil kayıtları gibi kurcalamaya karşı korumalı denetim gerektiren kayıt sistemleri (systems of record) için uygundur. DynamoDB, tek tablolu tasarım, hiyerarşik erişim için bileşik sıralama anahtarları ve alternatif erişim yolları için GSI’lar gibi desenler kullanarak, her ölçekte tek haneli milisaniyelik anahtar-değer veya belge erişimi için varsayılan seçenektir. Bu iş yüklerini RDS’e zorlamak, kilit çekişmesi (defter yazmaları), sorgu karmaşıklığı (graf dolaşımı) veya ölçeklendirme tavanları (yüksek verimli anahtar-değer) yaratır — her birinin sonradan düzeltilmesi, tasarım zamanında doğru seçimi yapmaktan çok daha maliyetlidir.

Tuzak Özeti

• Okuma replikalarını HA olarak kullanmak. Asenkron, otomatik yükseltme yok, yükseltme sırasında uç nokta (endpoint) değişir, devam eden işlemler kaybolur. HA için doğru çözüm Multi-AZ’dir.
• Okuma ölçeklendirmesi için Multi-AZ kullanmak. Standart RDS Multi-AZ’de beklemedeki (standby) veritabanı okunamaz. Okuma replikalarını (read replicas) veya Aurora replikalarını kullanın.
• Üretim ortamında Single-AZ kullanmak. Yedek sisteme geçiş (failover) hedefi yoktur; herhangi bir AZ olayında veya sunucu (instance) yeniden başlatıldığında erişilebilirlik kaybedilir. Multi-AZ, niteliksel bir erişilebilirlik artışı için yaklaşık 2 kat maliyetlidir.
• Replikanın varsayılan olarak birincil (primary) ile aynı boyutta olması. Replikalar genellikle çok daha az kaynağa ihtiyaç duyar; replika bir yükseltme hedefi değilse, ölçülen iş yüküne göre boyutlandırın.
• On-demand DynamoDB’nin her zaman daha ucuz olduğunu düşünmek. İstek başına maliyeti yaklaşık 6-7 kat daha fazladır; istikrarlı iş yükleri için tedarik edilmiş (provisioned) + otomatik ölçeklendirme (auto-scaling) daha avantajlıdır.
• Tek bölgeli (single-region) ihtiyaçlar için Global Tables kullanmak. Çok bölgeli kullanıcı yakınlığı veya felaket kurtarma (DR) gerekmedikçe, bir fayda sağlamadan maliyeti ikiye katlar ve tutarlılığı zayıflatır.
• Aurora Global Database ikincillerinin (secondaries) yazma işlemlerine hizmet ettiğini düşünmek. Yönetilen bir yedek sisteme geçiş (failover) ile yükseltilene kadar salt okunurdurlar.
• RDS Proxy olmadan Lambda → RDS bağlantısı kurmak. Bağlantı fırtınası (connection storm) max_connections limitini tüketir; fonksiyon içi havuzlar (in-function pools) eş zamanlı yürütme ortamları arasında yardımcı olmaz.
• Heterojen geçişler için yalnızca DMS kullanmak. Şemayı değil, veriyi taşır. SCT ile birlikte kullanın.
• Otomatik ölçeklendirme veya FreeStorageSpace alarmları olmadan sabit RDS depolaması kullanmak. Gizli kesinti — storage-full durumu yazma işlemlerini reddeder.
• Geçersiz kılma (invalidation) stratejisi olmadan önbelleğe alma (caching) yapmak. Sessiz veri eskimesi. TTL’ler, write-through veya açık geçersiz kılma (explicit invalidation) pazarlık konusu dahi olamaz.
• DAX veya GSI’lar aracılığıyla güçlü tutarlı (strongly consistent) okumalar yapmaya çalışmak. Her iki yol da yalnızca nihai tutarlı (eventually consistent) veri sunar.

← İçerik Dağıtımı · Tüm alanlar · Analitik →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →

Amazon'a göz atın →