Amazon Aurora: AWS'nin Cloud-Native Veritabanını Anlamak

Amazon Aurora ile standart RDS arasında seçim yapmak basit değil. Aurora, 5x MySQL ve 3x PostgreSQL performansı, 128TB’ye kadar otomatik storage scaling ve %99.99 availability vaat ediyor. Ama I/O pricing modeline aşina olmayan ekipleri şaşırtabilecek ek karmaşıklık ve maliyetle geliyor.

Karar “daha iyi” olmakla ilgili değil - veritabanı mimarisini workload özelliklerine, operasyonel gereksinimlere ve maliyet kısıtlamalarına uydurmakla ilgili. Bilinçli bir seçim yapmak için bilmen gerekenler burada.

Amazon Aurora Nedir?

Amazon Aurora, MySQL ve PostgreSQL ile uyumlu cloud-native bir relational database engine. Standart RDS’in cloud altyapısında vanilla database’leri çalıştırmasının aksine, Aurora distributed cloud mimarisinden yararlanmak için sıfırdan inşa edildi.

Temel Mimari Farklar:

• Storage Ayrımı: Compute (database instance’ları) storage’dan (distributed layer) ayrılmış
• Otomatik Scaling: Storage 10GB’den 128TB’ye 10GB’lik artışlarla büyüyor, downtime yok
• Yerleşik Replication: Varsayılan olarak 3 Availability Zone’da verinin 6 kopyası
• Sınırlı Engine Desteği: Sadece MySQL ve PostgreSQL (Aurora diğer engine’leri desteklemiyor)

AWS Veritabanı Ekosistemi: Aurora Nerede Konumlanıyor

Aurora’ya daha derinlemesine girmeden önce, AWS’nin geniş veritabanı ekosistemini anlamak önemli. Aurora, her biri belirli kullanım senaryoları için tasarlanmış birçok database servisinden sadece biri.

Relational Veritabanları (SQL)

Servis	Engine’ler	En İyi Kullanım
Amazon RDS	MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Db2	Standart relational workload’lar, geniş engine uyumluluğu
Amazon Aurora	Sadece MySQL, PostgreSQL	High availability, read-heavy workload’lar, cloud-native özellikler
Amazon Redshift	PostgreSQL-tabanlı	Data warehousing, analytics, OLAP workload’ları

NoSQL Veritabanları

Servis	Tip	En İyi Kullanım
Amazon DynamoDB	Key-value, Document	Serverless uygulamalar, gaming, IoT, tek haneli milisaniye latency
Amazon DocumentDB	Document (MongoDB-uyumlu)	MongoDB workload’ları, JSON document storage
Amazon Keyspaces	Wide-column (Cassandra-uyumlu)	Cassandra migration’ları, time-series data
Amazon Neptune	Graph	Sosyal ağlar, fraud detection, knowledge graph’lar
Amazon Timestream	Time-series	IoT metrikleri, DevOps monitoring, uygulama telemetrisi

In-Memory ve Caching

Servis	Tip	En İyi Kullanım
Amazon ElastiCache	Redis, Memcached	Caching, session storage, real-time analytics
Amazon MemoryDB	Redis-uyumlu	Dayanıklı in-memory database, mikrosaniye okuma

Özelleşmiş Servisler

Servis	Amaç
Amazon QLDB	Değiştirilemez ledger, audit trail’leri, kriptografik doğrulama
Amazon OpenSearch	Full-text arama, log analytics, uygulama monitoring

Aurora’yı Ne Zaman SEÇMEMELİSİN

Alternatifleri anlamak, Aurora’nın doğru seçim olduğu durumları netleştiriyor:

• SQL Server, Oracle veya Db2 mi gerekiyor? → RDS kullan (Aurora bunları desteklemiyor)
• MongoDB uyumlu document storage mı gerekiyor? → DocumentDB kullan
• Scale’de tek haneli ms latency ile key-value mi gerekiyor? → DynamoDB kullan
• Data warehousing/analytics mi gerekiyor? → Redshift kullan
• Graph ilişkileri mi gerekiyor? → Neptune kullan
• Time-series data mı gerekiyor? → Timestream kullan

Aurora özellikle high availability, read scalability ve cloud-native özellikler gerektiren MySQL ve PostgreSQL workload’larında öne çıkıyor. Diğer kullanım senaryoları için AWS amaca yönelik alternatifler sunuyor.

Aurora’nın Distributed Storage Mimarisi

Aurora’nın storage layer’ı Protection Group’ları kullanıyor - 10GB’lık segment’ler üç availability zone’da altı kopya olarak replicate ediliyor. Bu tasarım, traditional replication overhead’i olmadan hızlı recovery ve high availability sağlıyor.

Quorum-Based Write’lar: Aurora write’ların commit edilmesi için 6’dan 4 acknowledgment gerektiriyor. Bu, tüm bir availability zone’u artı bir ek kopyayı kaybetse bile write availability’yi etkilemeyeceği anlamına geliyor.

Redo Log Mimarisi: Aurora storage’a sadece redo log’ları gönderiyor, full data page’leri değil. Bu, traditional database’lerin full page’leri artı transaction log’ları yazmasına kıyasla write amplification’ı önemli ölçüde azaltıyor.

Self-Healing Storage: Storage layer otomatik olarak disk arızalarını tespit edip onarıyor, genellikle 10GB’lık bir segment’i manuel müdahale olmadan bir dakikanın altında recover ediyor.

Aurora vs RDS: Teknik Karşılaştırma

Özellik	RDS (MySQL/PostgreSQL)	Aurora
Storage	Instance’lara bağlı EBS volume’lar	Distributed storage layer (6 kopya, 3 AZ)
Storage Scaling	Manuel, downtime gerektirir	Otomatik, 128TB’ye kadar, downtime yok
Replication	Binary/streaming (max 5 replica)	Log-based, shared storage (max 15 replica)
Replica Lag	Saniyeler ile dakikalar arası olabilir	Genellikle millisaniye
Write Metodu	Full page write + double-write buffer	Sadece redo log
Failover Süresi	1-2 dakika (DNS-based)	30-120 saniye, AWS driver’larla daha hızlı
HA SLA	%99.95 (Multi-AZ)	%99.99
Backup Etkisi	Snapshot sırasında I/O pause	Sürekli, performans etkisi yok

Write Performance Özellikleri

Aurora’nın redo-log-only yaklaşımı write’lar için I/O operation sayısını azaltıyor. Traditional database’ler şunları yazıyor:

1. Storage’a data page
2. Storage’a transaction log
3. Double-write buffer’a data page (MySQL)

Aurora sadece redo log entry’sini yazıyor. Storage layer bu değişiklikleri asenkron olarak uygulayarak birçok workload için write amplification’ı 5-7x’ten yaklaşık 1x’e düşürüyor.

Ne Zaman Aurora, Ne Zaman RDS Seçilmeli

Aurora’yı Şu Durumlarda Seç:

1. High Availability Kritik

• Multi-AZ RDS için %99.95’e karşı %99.99 uptime SLA gerekiyor
• Sub-minute failover gereksinimleri
• İş 1-2 dakikalık database kesintilerini tolere edemiyor

2. Read-Heavy Workload’lar

• 5’ten fazla read replica gerekiyor
• Millisaniye replication lag gerekiyor
• Read traffic write’lardan önemli ölçüde fazla

3. Öngörülemeyen Storage Büyümesi

• Storage provisioning yönetmek istemiyorsun
• Storage ihtiyaçları beklenmedik şekilde artabilir
• Over-provisioning storage maliyetlerinden kaçınmak istiyorsun

4. Multi-Region Gereksinimleri

• Sub-second lag ile cross-region replication gerekiyor
• Hızlı failover ile disaster recovery
• Global read distribution

5. Değişken Workload’lar

• Traffic pattern’leri önemli ölçüde değişiyor (günlük 10x dalgalanmalar)
• Serverless v2 auto-scaling’den faydalanabilirsin
• Non-production environment’lar için sıfıra scale etmek istiyorsun

RDS’i Şu Durumlarda Seç:

1. Maliyet Hassasiyeti Olan Projeler

• Öngörülebilir, düşük-orta seviye workload
• Aurora premium’unun haklı çıkmadığı bütçe kısıtlamaları
• I/O pattern’leri yüksek Aurora maliyetlerini tetiklemeyecek

2. Daha Geniş Engine Desteği Gerekiyor

• SQL Server, Oracle, MariaDB veya Db2 gerekiyor
• Aurora’da bulunmayan spesifik engine özellikleri
• Aurora-compatible olmayan engine’lere mevcut uygulama bağımlılıkları

3. Basit Gereksinimler

• Single-AZ development veya test environment’ları
• Basit backup ve restore yeterli
• Advanced özelliklere ihtiyaç yok

4. Düşük I/O Workload

• Ayda 1 milyar request’in altında öngörülebilir I/O pattern’leri
• Aurora’nın I/O cost trap’ine düşmeyecek
• Standart storage ve IOPS provisioning iyi çalışıyor

Karar Cercevesi

Hizli Referans:

• Turuncu (RDS): MySQL/PostgreSQL disindaki engine’ler veya butce kisitlamali dusuk I/O workload’lari icin en iyisi
• Mavi (Aurora Standard): Cogu production MySQL/PostgreSQL workload’u icin varsayilan secim
• Mor (Aurora I/O-Optimized): I/O maliyetleri Aurora faturanizin %25’ini astiginda

Maliyet Analizi ve I/O Tuzağı

Aurora’nın pricing’i üç bileşenden oluşuyor: compute, storage ve I/O. I/O bileşeni genellikle ilk migration’larını yapan ekipleri şaşırtıyor.

Pricing Dağılımı

Aurora Standard:

• Instance: Eşdeğer RDS instance type ile aynı fiyat
• Storage: $0.10/GB-ay (kullandığın kadar öde)
• I/O: Milyon request başına $0.20
• Backup’lar: İlk backup ücretsiz (cluster storage boyutu), ek backup $0.021/GB-ay

Aurora I/O-Optimized (2023’te tanıtıldı):

• Instance: Standard’dan %30 daha pahalı
• Storage: $0.225/GB-ay (Standard’ın 2.25 katı)
• I/O: $0 (dahil)
• Backup’lar: Standard ile aynı

I/O Cost Trap Açıklaması

Birçok ekip Aurora maliyetlerini instance ve storage pricing kullanarak tahmin ediyor, sonra I/O charge’larından şaşırıyor. Bir production workload kolayca ayda 50-100 milyar I/O request üretebilir.

Örnek Hesaplama:

interface AuroraConfig {
  instanceType: string;
  storageGB: number;
  monthlyIORequests: number;
}

interface CostBreakdown {
  compute: number;
  storage: number;
  io: number;
  total: number;
}

function calculateAuroraCost(
  config: AuroraConfig,
  optimized: boolean = false
): CostBreakdown {
  // us-east-1 için örnek pricing
  const instancePricing: Record<string, number> = {
    'db.r6g.2xlarge': optimized ? 0.806 : 0.62, // saat başına
  };

  const storagePricing = optimized ? 0.225 : 0.10; // GB-ay başına
  const ioPricing = optimized ? 0 : 0.20; // milyon request başına

  const hoursPerMonth = 730;

  const computeCost = instancePricing[config.instanceType] * hoursPerMonth;
  const storageCost = config.storageGB * storagePricing;
  const ioCost = optimized ? 0 : (config.monthlyIORequests / 1_000_000) * ioPricing;

  return {
    compute: computeCost,
    storage: storageCost,
    io: ioCost,
    total: computeCost + storageCost + ioCost
  };
}

// Örnek: Yüksek I/O workload
const highIOWorkload: AuroraConfig = {
  instanceType: 'db.r6g.2xlarge',
  storageGB: 2000,
  monthlyIORequests: 50_000_000_000, // 50 milyar I/O request
};

const standardCost = calculateAuroraCost(highIOWorkload, false);
const optimizedCost = calculateAuroraCost(highIOWorkload, true);

console.log('Aurora Standard:', standardCost);
// { compute: 452.6, storage: 200, io: 10000, total: 10652.6 }

console.log('Aurora I/O-Optimized:', optimizedCost);
// { compute: 588.38, storage: 450, io: 0, total: 1038.38 }

// Temel kural: I/O total maliyetin %25'ini aştığında I/O-Optimized'a geç
const ioPercentage = (standardCost.io / standardCost.total) * 100;
console.log(`I/O toplam maliyetin %${ioPercentage.toFixed(1)}'i`);
// I/O toplam maliyetin %93.9'u - kesinlikle I/O-Optimized kullan!

Maliyet Optimizasyon Stratejileri

1. İlk Günden I/O Metric’lerini İzle Migration’dan hemen sonra CloudWatch’ta VolumeReadIOPs ve VolumeWriteIOPs’u takip et. Bu metric’ler tahminleri değil, gerçek I/O tüketimini gösteriyor.

2. Buffer Cache’i Artır Daha fazla memory’ye sahip daha büyük instance’lar cache hit ratio’larını iyileştirerek I/O’yu azaltıyor. Bazen daha büyük bir instance için ödeme yapmak I/O maliyetlerinde tasarruf sağlıyor.

3. Query Optimizasyonu Daha iyi indexing, query optimization ve full table scan’lerden kaçınarak gereksiz I/O’yu azalt. Önlenen her I/O operation milyon başına $0.20 tasarruf sağlıyor.

4. Stratejik Olarak I/O-Optimized’a Geç I/O maliyetleri toplam Aurora faturasının %25’ini aştığında, I/O-Optimized neredeyse her zaman daha ucuza mal oluyor. Spesifik öneriler için AWS Compute Optimizer kullan.

5. Değişken Workload’lar için Serverless v2 Development ve staging için, 0 ACU minimum ile (Kasım 2024 özelliği) Serverless v2, provisioned instance’lara kıyasla %90’a kadar tasarruf sağlayabiliyor.

Aurora Serverless v2

Aurora Serverless v2, geleneksel provisioned instance’ların scaling sınırlamalarını gerçek yüke dayalı otomatik kapasite ayarlamasıyla çözüyor.

Temel Özellikler (2024/2025 Güncellemeleri)

• 256 ACU’ya Instant Scaling (Ekim 2024): Önceden 128 ACU ile sınırlıydı
• 0 ACU’ya Scale (Kasım 2024): Önceden minimum 0.5 ACU’ydu
• Fine-Grained Scaling: 0.5 ACU artışlarla ayarlama
• Full Feature Desteği: Global Database, Performance Insights ve tüm Aurora özellikleriyle çalışıyor

1 ACU = yaklaşık 2GB memory + orantılı CPU ve network bandwidth

Serverless v2 Konfigürasyonu

import * as rds from 'aws-cdk-lib/aws-rds';
import * as ec2 from 'aws-cdk-lib/aws-ec2';

const serverlessCluster = new rds.DatabaseCluster(this, 'ServerlessCluster', {
  engine: rds.DatabaseClusterEngine.auroraPostgres({
    version: rds.AuroraPostgresEngineVersion.VER_16_1,
  }),
  vpc,
  writer: rds.ClusterInstance.serverlessV2('writer', {
    autoMinorVersionUpgrade: true,
  }),
  readers: [
    rds.ClusterInstance.serverlessV2('reader1', {
      scaleWithWriter: true, // Reader writer ile birlikte scale oluyor
    }),
  ],
  serverlessV2MinCapacity: 0, // Sıfıra scale (Kas 2024 özelliği)
  serverlessV2MaxCapacity: 256, // 256 ACU'ya kadar (Ekim 2024 özelliği)
});

// Not: 0 ACU minimum PostgreSQL 13.15+, 14.12+, 15.7+, 16.3+
// veya MySQL 3.08+ gerektiriyor

Serverless v2 Kullanım Durumları

1. Değişken/Öngörülemeyen Workload’lar Flash sale’ler sırasında e-ticaret, mevsimsel uygulamalar veya pazarlama kampanyası traffic artışları.

2. Development ve Staging Environment’ları Kullanılmadığında sıfıra scale. Günde 8 saat, haftada 5 gün kullanılan bir development database’i compute maliyetlerinde %76 tasarruf sağlıyor.

3. Multi-Tenant SaaS Bağımsız scaling ile tenant başına database’ler. Her tenant’ın database’i kendi gerçek kullanımına göre scale oluyor.

4. Seyrek Batch Job’lar Günlük veya haftalık çalışan data processing. Çalışmalar arasında minimum’a scale.

Pricing Örneği

// Serverless v2 pricing (us-east-1)
const acuPricePerHour = 0.12; // PostgreSQL

// Örnek: Dev environment
// Günde 8 saat, haftada 5 gün ortalama 2 ACU'da kullanılıyor
// Kullanılmadığında 0 ACU'ya scale oluyor

const monthlyHoursActive = 8 * 5 * 4.33; // ~ayda 173 saat
const avgACUs = 2;

const serverlessV2Cost = monthlyHoursActive * avgACUs * acuPricePerHour;
// = 173 * 2 * 0.12 = $41.52/ay

// Eşdeğer provisioned instance (db.r6g.large = 2 ACU eşdeğeri)
const provisionedCost = 730 * 0.246; // $179.58/ay

const savings = ((provisionedCost - serverlessV2Cost) / provisionedCost) * 100;
// = %76.9 tasarruf

RDS’den Aurora’ya Migration

Migration Metodları

1. Aurora Read Replica (Önerilen - Minimal Downtime)

Bu metod mevcut RDS instance’ından bir Aurora read replica oluşturuyor, sonra onu standalone cluster’a promote ediyor.

# Adım 1: RDS MySQL instance'ından Aurora Read Replica oluştur
aws rds create-db-instance-read-replica \
    --db-instance-identifier myapp-aurora-replica \
    --source-db-instance-identifier myapp-rds-mysql \
    --db-instance-class db.r6g.2xlarge \
    --engine aurora-mysql

# Adım 2: Replication lag'i izle
aws cloudwatch get-metric-statistics \
    --namespace AWS/RDS \
    --metric-name AuroraReplicaLag \
    --dimensions Name=DBInstanceIdentifier,Value=myapp-aurora-replica \
    --start-time 2025-11-29T00:00:00Z \
    --end-time 2025-11-29T01:00:00Z \
    --period 60 \
    --statistics Average

# Adım 3: Lag sıfıra yaklaştığında Aurora replica'yı promote et
aws rds promote-read-replica-db-cluster \
    --db-cluster-identifier myapp-aurora-cluster

Downtime: Promotion ve application cutover sırasında 15-30 dakika

2. Snapshot Migration

RDS snapshot’ını Aurora cluster olarak restore et. Büyük database’ler için daha hızlı ama cutover sırasında downtime gerektiriyor.

aws rds restore-db-cluster-from-snapshot \
    --db-cluster-identifier myapp-aurora \
    --snapshot-identifier myapp-rds-snapshot \
    --engine aurora-postgresql \
    --engine-version 16.1

Downtime: Snapshot restore’un tam süresi artı test süresi

3. AWS DMS (Database Migration Service)

En esnek ama en karmaşık. Cross-account, cross-VPC senaryolar veya encrypted/unencrypted database dönüşümleri için iyi.

4. pg_dump/mysqldump

Basit ama yavaş. Sadece 500GB altındaki database’ler için pratik.

Pre-Migration Checklist

• Aurora’nın RDS engine versiyonunu desteklediğini doğrula
• CloudWatch metric’lerini kullanarak I/O maliyetlerini tahmin et
• Staging environment’ta uygulamayı Aurora ile test et
• Connection pooling stratejisini planla (RDS Proxy düşün)
• Rollback prosedürünü dokümante et
• RDS’de auto minor version upgrade’leri devre dışı bırak
• Migration’ı düşük traffic döneminde planla
• Yeni Aurora cluster için monitoring ve alerting hazırla

Multi-Region için Global Database

Aurora Global Database, sub-second lag ile cross-region replication sağlayarak global read distribution ve hızlı disaster recovery’yi mümkün kılıyor.

Mimari

• 1 Primary Region: Read ve write traffic kabul ediyor
• 10’a Kadar Secondary Region: Read-only (Mayıs 2025’te 5’ten artırıldı)
• Tipik Replication Lag: 1 saniyeden az
• Dedicated Infrastructure: Replication public internet kullanmıyor

Global Database Setup

import * as rds from 'aws-cdk-lib/aws-rds';
import * as ec2 from 'aws-cdk-lib/aws-ec2';

// Primary region (us-east-1)
const primaryCluster = new rds.DatabaseCluster(this, 'PrimaryCluster', {
  engine: rds.DatabaseClusterEngine.auroraPostgres({
    version: rds.AuroraPostgresEngineVersion.VER_16_1,
  }),
  vpc: primaryVpc,
  writer: rds.ClusterInstance.provisioned('writer', {
    instanceType: ec2.InstanceType.of(ec2.InstanceClass.R6G, ec2.InstanceSize.XLARGE2),
  }),
});

// Global database oluştur
const globalCluster = new rds.CfnGlobalCluster(this, 'GlobalCluster', {
  globalClusterIdentifier: 'myapp-global',
  sourceDbClusterIdentifier: primaryCluster.clusterArn,
  engine: 'aurora-postgresql',
  engineVersion: '16.1',
});

// Secondary region (eu-west-1) - ayrı stack'te deploy ediliyor
const secondaryCluster = new rds.DatabaseCluster(secondaryStack, 'SecondaryCluster', {
  engine: rds.DatabaseClusterEngine.auroraPostgres({
    version: rds.AuroraPostgresEngineVersion.VER_16_1,
  }),
  vpc: secondaryVpc,
  writer: rds.ClusterInstance.provisioned('writer', {
    instanceType: ec2.InstanceType.of(ec2.InstanceClass.R6G, ec2.InstanceSize.XLARGE2),
  }),
});

// Secondary'yi global database'e attach et
new rds.CfnDBCluster(secondaryStack, 'SecondaryAttach', {
  globalClusterIdentifier: 'myapp-global',
  dbClusterIdentifier: secondaryCluster.clusterIdentifier,
});

Failover Yetenekleri

Planlı Switchover (Managed):

• Sıfır veri kaybı
• Cluster topology’sini koruyor
• Kullanım durumu: Regional rotation, compliance gereksinimleri

Plansız Failover:

• Secondary’yi yaklaşık 1 dakikada primary’ye promote ediyor
• Potansiyel veri kaybı failure anındaki replication lag’e bağlı
• RPO tipik olarak saniyeler, RTO yaklaşık 1 dakika

Maliyet Değerlendirmeleri

Global Database birkaç alanda maliyet ekliyor:

• Cross-region data transfer charge’ları
• Tüm region’lara replicate edilen storage
• Her region’da instance maliyetleri
• Her region’da I/O charge’ları (Standard) veya artırılmış instance maliyetleri (I/O-Optimized)

Bu pahalı olabilir. Global Database’i sadece iş gereksinimleri gerçekten multi-region active-active read’ler veya sub-minute regional failover gerektirdiğinde implement et.

RDS Proxy ile Connection Management

Aurora’nın hızlı failover yetenekleri akıllı connection management ile birleştirildiğinde en iyi şekilde çalışıyor. RDS Proxy connection pooling sağlıyor ve failover’ı transparent şekilde handle ediyor.

import * as rds from 'aws-cdk-lib/aws-rds';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as cdk from 'aws-cdk-lib';

const proxy = new rds.DatabaseProxy(this, 'AuroraProxy', {
  proxyTarget: rds.ProxyTarget.fromCluster(auroraCluster),
  secrets: [auroraCluster.secret!],
  vpc,
  dbProxyName: 'myapp-aurora-proxy',
  // Connection pooling konfigürasyonu
  maxConnectionsPercent: 90,
  maxIdleConnectionsPercent: 50,
  connectionBorrowTimeout: cdk.Duration.seconds(120),
  // Session pinning filter'ları - gereksiz pinning'den kaçın
  sessionPinningFilters: [
    rds.SessionPinningFilter.EXCLUDE_VARIABLE_SETS,
  ],
  requireTLS: true,
});

// Uygulama cluster endpoint yerine proxy endpoint'e bağlanıyor
const proxyEndpoint = proxy.endpoint;

Faydaları:

• Lambda invocation’lar arasında connection pool’u koruyor
• Application-level retry logic olmadan failover’ı handle ediyor
• Serverless workload’lar için database connection’ları %90+ azaltıyor
• Ek güvenlik için IAM authentication zorunlu kılıyor

RDS Proxy’nin Gerekli Olduğu Durumlar:

• Serverless uygulamalar (Lambda function’lar)
• Connection storm’lu uygulamalar
• Birçok bağımsız service’li microservice’ler
• Tenant başına connection pattern’li multi-tenant uygulamalar

Yaygın Tuzaklar ve Çözümleri

1. DNS Caching Sorunları

Sorun: Uygulama database endpoint DNS’ini çok uzun süre cache’liyor, failover sonrası yeniden bağlanmada başarısız oluyor.

Çözüm: Uygulama DNS resolver’ını 30 saniyeden az TTL ile konfigüre et. Gerçek recovery süresini ölçmek için staging’de failover senaryolarını test et.

// Node.js DNS cache konfigürasyonu
import dns from 'dns';
dns.setDefaultResultOrder('ipv4first');

// DNS TTL'ye saygı gösteren connection library kullan
import { Pool } from 'pg';
const pool = new Pool({
  host: process.env.DB_HOST,
  // Connection'ları süresiz cache'leme
  idleTimeoutMillis: 30000,
  connectionTimeoutMillis: 3000,
});

2. Yanlış Instance Class Seçimi

Sorun: 40TB üzerindeki production workload’lar için t2/t3/t4g burstable instance’lar kullanılması.

Çözüm: Production için r6g veya r6i instance family’leri kullan. Burstable instance’lar development için çalışıyor, ama production database’leri tutarlı performansa ihtiyaç duyuyor.

3. CPU Credit Tükenmesinden Replica Lag

Sorun: T-instance read replica’ları CPU credit’lerini tüketiyor, replication lag dramatik artıyor, instance’lar restart oluyor.

Çözüm: CPUCreditBalance metric’ini izle. Production read replica’ları için non-burstable instance type’ları kullan.

4. Connection Tükenmesi

Sorun: Serverless uygulamalar binlerce kısa ömürlü connection oluşturuyor, database connection’larını tüketiyor.

Çözüm: RDS Proxy veya application-side connection pooling implement et. Lambda için bu neredeyse zorunlu.

5. Parallel Query Cost Artışı

Sorun: Parallel query’yi etkinleştirmek buffer cache’i bypass ettiği için beklenmedik şekilde I/O maliyetlerini artırıyor.

Çözüm: Parallel query’yi etkinleştirdikten sonra VolumeReadIOPs’u izle. Parallel query workload’ın için kritikse I/O-Optimized’ı değerlendir.

6. CloudFormation Veri Kaybı Riski

Sorun: CloudFormation stack güncellemeleri instance’ları yeniden oluşturabilir, potansiyel olarak veri kaybedebilir.

Çözüm: Database resource’larında her zaman DeletionPolicy: Retain kullan. Uygulamadan önce CloudFormation change set’leri dikkatlice incele.

7. Binary Logging Performansı

Sorun: Büyük transaction’lar (1M+ insert) binary logging etkinken çok yavaş oluyor.

Çözüm: Daha küçük transaction’lara böl (10K-50K insert) veya point-in-time recovery gerekli değilse binary logging’i devre dışı bırak.

Monitoring ve Operasyonlar

İzlenecek Temel Metric’ler

Performans Metric’leri:

• CPUUtilization: Ortalama %80’den az hedefle
• DatabaseConnections: max_connections ayarına göre izle
• BufferCacheHitRatio: %95’ten büyük hedefle
• AuroraReplicaLag: 100ms’den az hedefle

I/O ve Storage Metric’leri:

• VolumeReadIOPs, VolumeWriteIOPs: Maliyet artışlarını izle
• VolumeBytesUsed: Otomatik storage büyümesini takip et
• DiskQueueDepth: I/O darboğazlarını gösterir

Availability Metric’leri:

• FailoverLatency: Gerçek failover süresini ölç
• DeadlockCount: Uygulama tasarım sorunları
• CommitLatency: Write performansı

Operasyonel Best Practice’ler

1. Enhanced Monitoring’i Etkinleştir 1 saniyelik granülaritede OS-level metric’ler (memory, CPU, disk I/O) sağlıyor. Production troubleshooting için kritik.

2. Performance Insights Kullan Query-level analiz hangi query’lerin resource tükettiğini gösteriyor. Free tier 7 günlük retention içeriyor.

3. CloudWatch Alarm’ları Ayarla Sorun olmadan önce temel metric’lerde alarm ver:

• 5 dakika boyunca CPU > %80
• Replica lag > 1 saniye
• Connection’lar max_connections’ın %80’ini aşıyor
• BufferCacheHitRatio < %90

4. Çeyrek Yılda Failover Test Et Düzenli failover test’leri gerçek RTO’nu doğrulıyor. Birçok ekip DNS caching veya connection pool sorunlarını sadece production incident’ları sırasında keşfediyor.

5. AWS Compute Optimizer Kullan Gerçek kullanım pattern’lerine dayalı rightsizing önerileri sağlıyor. I/O-Optimized’a geçme veya instance downsize fırsatlarını belirleyebiliyor.

Temel Çıkarımlar

Aurora “daha iyi RDS” değil - farklı maliyet modelleri ve operasyonel özelliklere sahip temelde farklı bir mimari. Pazarlama iddialarına değil, gerçek gereksinimlere göre seç.

I/O cost trap gerçek - birçok ekip I/O charge’larını 5-10x küçük tahmin ediyor. İlk günden VolumeReadIOPs ve VolumeWriteIOPs’u her zaman izle. I/O toplam maliyetin %25’ini aştığında I/O-Optimized kullan.

Aurora’nın güçlü yanları read scalability ve high availability - millisaniye lag ile 15’e kadar read replica ve %99.99 SLA ile sub-minute failover. Bunlara ihtiyacın yoksa RDS daha maliyet-etkin olabilir.

Migration path önemli - Aurora Read Replica metodu near-zero downtime ve kolay rollback sağlıyor. Production benzeri data ve traffic pattern’leriyle her zaman önce staging’de test et.

Connection management kritik - RDS Proxy serverless uygulamalar için neredeyse zorunlu ve failover’ı gracefully handle etmek için production sistemler için yüksek oranda öneriliyor.

Serverless v2 ekonomileri değiştiriyor - 0 ACU minimum (Kasım 2024) ve 256 ACU maksimum (Ekim 2024) ile dev/test için %90’a kadar tasarruf sağlayabiliyor ve production spike’larını etkili şekilde handle edebiliyor.

Global Database gerçek multi-region HA sağlıyor - 10 region’a sub-second replication, ama önemli maliyetle geliyor. Sadece iş gereksinimleri gerçekten gerektirdiğinde kullan.

Workload’unu benchmark et - Aurora’nın 5x MySQL / 3x PostgreSQL performans iddiaları workload’a bağımlı. Commit etmeden önce gerçek query’lerin ve data pattern’lerinin ile test et.

Basit başla, gerektiğinde scale et - RDS ile başla, scalability gerektirdiğinde Aurora’ya migrate et, multi-region gerektiğinde Global Database ekle. Her uygulamanın Aurora’ya ihtiyacı yok.

Sürekli izle - Temel metric’ler için CloudWatch alarm’ları kur. Maliyet önerileri için AWS Compute Optimizer kullan. RTO varsayımlarını doğrulamak için çeyrek yılda failover test et.