Üç yıl kadar önce AWS kariyerimin başlarında, arka uçta DynamoDB bulunan Lambda tabanlı bir API devraldım ve Aurora PostgreSQL'e geçiş yapmam istendi - veri modeli ilişkisel hale gelmişti ve ekip uygun yabancı anahtar kısıtlamaları istiyordu.
Geçiş UAT'de sorunsuz tamamlandı. Üretime Salı gecesi geçirildi. Perşembe sabahına kadar Lambda eşzamanlılığı tükendi, Aurora bağlantı havuzu hataları vermeye başladı ve CTO ile birlikte 80K RPS'de tam bir API kesintisini açıklamak için savaş odasında oturuyordum.
Üretim yükünde bağlantı davranışının nasıl olacağını hiç test etmemiştim. İyi olacağını varsaymıştım.
İyi değildi.
Ölçekte veritabanı seçimini varsayarak geçemezsiniz.
Yöntem
pinpole'un ön dağıtım kanvasını kullanarak yapılandırılmış bir simülasyon karşılaştırması yaptım. Üç ayrı kanvas - biri DynamoDB, biri RDS/Aurora, üçüncüsü Aurora Serverless v2 için karşılaştırma amaçlı.
Kanvas topolojisi (her iki konfigürasyon için):
Route 53 → CloudFront → API Gateway → Lambda → [DynamoDB | RDS + Proxy] WAF (CloudFront önünde) · SQS (yazma ayrıştırma yolu) · ElastiCache (RDS senaryosu)
RDS Proxy notu: Önemli bir ölçekte Lambda'yı RDS'ye çalıştırıyorsanız RDS Proxy bağlantı havuzunu yönetmeden, patlama yükü altında veritabanı bağlantılarını tüketirsiniz. Bu, Salı gecesi felaketime neden olan mimari hatanın ta kendisidir. Aşağıdaki RDS/Aurora konfigürasyonlarında RDS Proxy her zaman mevcuttur.
Tüm konfigürasyonlar üretim gerçekçi özelliklerde: Lambda 1.769 MB (1 vCPU eşdeğeri), 30 saniye zaman aşımı; API Gateway 10K RPS patlama sınırı; DynamoDB hem talebe göre hem de tahsisli modlarda; RDS PostgreSQL db.r6g örneklerinde; Aurora Serverless v2 her katmana uygun ACU sınırlarıyla.
Her RPS seviyesinde dört trafik deseni çalıştırdım: Sabit (istikrarlı temel), Rampa (10 dakika içinde doruğa lineer büyüme), Patlama (ani 10× artış) ve Dalga (doruğun %30 ile %100 arasında salınım). Her çalıştırma karşılaştırma için yürütme geçmişine kaydedildi.
10K RPS sonuçları
Konfigürasyon p50 p99 Aylık Tahmin DynamoDB talebe göre 2ms 7ms ~8.400 TL DynamoDB tahsisli (9K RCU / 1K WCU) 2ms 7ms ~1.150 TL RDS PostgreSQL db.r6g.2xlarge + Proxy 3ms 11ms ~870 TL Aurora MySQL db.r6g.2xlarge + Proxy 4ms 13ms ~980 TL Aurora Serverless v2 (ortalama 4 ACU) 4ms 15ms ~720 TL
10K RPS'deki en büyük sürpriz: DynamoDB talebe göre, sürekli ve öngörülebilir trafik için iyi yapılandırılmış bir RDS örneğinden neredeyse 10 kat daha pahalıdır. DynamoDB'nin "sunucusuz veritabanı" olarak ünü, mühendislerin onu orta ölçeklerde ucuz olduğunu varsaymalarına yol açar. Tutarlı günlük yük desenlerine sahip bir ürün için tahsisli kapasite nadiren yanlış cevaptır ve talebe göre mod nadiren doğru cevaptır.
10K → 100K ani artış deseni altında (Patlama), DynamoDB talebe göre herhangi bir yapılandırma değişikliği olmadan artışı karşıladı. Sabit bir örnekle çalışan RDS PostgreSQL bağlantı havuzu baskısı yaşadı - p99 yaklaşık 90 saniye boyunca 38ms'ye yükseldi.
100K RPS sonuçları
Konfigürasyon p50 p99 Aylık Tahmin DynamoDB tahsisli (otomatik ölçeklendirme) 2ms 9ms ~4.200 TL RDS PostgreSQL db.r6g.8xlarge + Proxy 3ms 14ms ~3.100 TL Aurora MySQL db.r6g.8xlarge + Proxy 4ms 16ms ~3.400 TL Aurora Serverless v2 (ortalama 18 ACU) 4ms 19ms ~2.900 TL
100K RPS'de DynamoDB talebe göre yapısal olarak pahalı hale gelir. 10K RPS'de zararsız görünen istek başına fiyatlandırma modeli doğrusal olarak ölçeklenir. Otomatik ölçeklendirmeli tahsisli DynamoDB resimde önemli değişiklik yapar. RDS maliyeti hâlâ rekabetçidir - sabit örnek genel gideri artık daha verimli bir şekilde amorti edilir.
Bu seviyedeki Patlama deseni en fazla tanısal bilgiyi üretti. DynamoDB otomatik ölçeklendirme tam olarak yanıt vermek için 3-7 dakika aldı - bu sırada pinpole p99'un yükseldiğini tespit etti ve daha agresif ölçeklendirme ayarları önerdi. Bu davranışı dağıtımdan önce bilmeniz gerekir.
Yapay zeka özeti
Compare the performance and cost of DynamoDB and RDS at 10K, 100K, and 1M RPS. Learn how to make informed database selection decisions based on access pattern complexity, traffic predictability, and scale trajectory.
