DynamoDB Rate Limiting: Single Table Design'da Ölçekte Stratejiler
Single Table Design uygulamalarında DynamoDB throttling'i önleme ve yönetme stratejileri. Partition key tasarımı, write sharding, kapasite modları, DAX caching, retry pattern'leri ve yüksek throughput sistemler için CloudWatch monitoring konularını kapsar.
DynamoDB'yi ölçekte kullanırken throttling kaçınılmaz bir sorun haline geliyor. ProvisionedThroughputExceededException hatası, tablo seviyesinde yeterli kapasite olmasına rağmen sıkça karşılaşılan bir durum. Bunun nedenini anlamak için DynamoDB'nin iç mekanizmalarına inmek gerekiyor.
Bu rehberde, Single Table Design uygulamalarında throttling'i önleme ve yönetme konusunda kanıtlanmış pattern'leri ele alacağız. Partition key stratejilerinden, sorunları kullanıcıları etkilemeden yakalayan monitoring yapılandırmalarına kadar her şeyi kapsıyoruz.
DynamoDB'nin Throttling Mekanizmasını Anlamak
DynamoDB, rate limiting için token bucket algoritması kullanıyor. Her partition, provisioned kapasiteyle eşleşen bir hızda doldurulan kendi read ve write token bucket'ına sahip. Token'lar tükendiğinde, istekler throttle ediliyor.
Akılda tutulması gereken kritik limitler:
İşte işleri zorlaştıran nokta: provisioned kapasite partition'lara dağıtılıyor. 100 RCU ve 3 partition'a sahip bir tablo, her partition'a yaklaşık 33 RCU veriyor demek. Eğer bir partition trafiğin %80'ini alıyorsa, tabloda headroom olmasına rağmen throttle olacak.
Partition Key Tasarımı: Temel
Hot partition'lar çoğu throttling sorununun nedeni. Partition key tasarımını doğru yapmak, hiçbir kapasite artışının çözemeyeceği sorunları önlüyor.
Kaçınılması Gereken Anti-Pattern'ler
İşe Yarayan Yüksek Kardinalite Pattern'leri
Write Sharding: Hot Key'leri Dağıtmak
İş gereksinimleri düşük kardinaliteli erişim pattern'lerini zorunlu kıldığında, write sharding yükü birden fazla partition'a dağıtıyor.
Rastgele Suffix Sharding
Okuma agregasyonunun kabul edilebilir olduğu yazma-yoğun pattern'ler için en uygun:
Deterministik Sharding
Scatter-gather olmadan belirli item'ları okuman gerektiğinde:
GSI Write Sharding
GSI throttling'inin ana tablo yazmalarını engellemesini önlemek için Global Secondary Index'lere aynı pattern'i uygula:
Warning: GSI throttling, ana tablo yazmalarına backpressure yaratır. GSI'ın ana tablo yazma hızına ayak uyduramıyorsa, tüm yazmalar başarısız olur. GSI kapasitesini her zaman ana tablo ihtiyaçlarıyla eşleştir.
Kapasite Modu Seçimi
On-Demand Modu: Limitleri Anlamak
On-demand kapasitenin ekipleri hazırlıksız yakalayan ölçekleme kısıtlamaları var:
Trafik ani artışlarında bu 2x limiti önemli. Normal trafiğin 10 katı olan bir flash satış, on-demand tarafından hemen karşılanamaz. Tablonun kademeli olarak "ısınması" veya önceden provision edilmiş kapasite kullanması gerekiyor.
Auto-Scaling ile Provisioned
Maliyet hassasiyeti olan tahmin edilebilir iş yükleri için:
Karar Çerçevesi
Burst ve Adaptive Kapasite
DynamoDB, dengesiz trafik pattern'lerinde yardımcı olan iki otomatik mekanizma sağlıyor.
Burst Kapasite
Kullanılmayan kapasite 5 dakikaya kadar birikir ve trafik artışlarında tüketilebilir:
Adaptive Kapasite ve Split-for-Heat
DynamoDB kapasiteyi otomatik olarak hot partition'lara doğru yeniden dengeler ve gerektiğinde onları bölebilir:
Note: Adaptive kapasite yeniden dengeleme anında gerçekleşir (Mayıs 2019'dan beri), ancak split-for-heat (partition bölme) birkaç dakika alır. Flash satış senaryoları veya viral içerik için tek bir hot partition key'e her iki mekanizma da yardımcı olamaz. Adaptive kapasiteye güvenmek yerine partition key'leri düzgün tasarla.
Okuma-Yoğun İş Yükleri için DAX
DynamoDB Accelerator (DAX), okuma trafiğini DynamoDB'den yükler, hem gecikmeyi hem de kapasite tüketimini azaltır.
Note: JavaScript için DAX SDK v3 (
@amazon-dax-sdk/lib-dax) Mart 2025'te yayınlandı. Standart DynamoDB SDK v3'teki.send()pattern'i yerine aggregated method'lar (.get(),.query()) kullanıyor.
DAX Ne Zaman Mantıklı
Veri Tipine Göre TTL Stratejisi
Retry Stratejileri ve Circuit Breaker'lar
Throttling'i düzgün yönetmek uygun retry mantığı gerektirir. AWS SDK yerleşik retry sağlar, ancak batch işlemler ek handling gerektiriyor.
SDK Yapılandırması
Batch İşlemler: Unprocessed Item'ları Yönetmek
SDK batch işlemlerden dönen unprocessed item'ları otomatik olarak yeniden DENEMIYOR:
Sürekli Throttling için Circuit Breaker
Throttling devam ettiğinde, circuit breaker retry fırtınalarını önler:
İstemci Taraflı Rate Limiting
İstek oranlarını proaktif olarak sınırlamak, throttling'in oluşmasını önler:
CloudWatch Monitoring ve Alerting
Düzgün monitoring, throttling'i kullanıcıları etkilemeden önce yakalar.
Temel Metrikler
CDK Alarm Yapılandırması
Hot Key Tespiti için Contributor Insights
Hangi partition key'lerin throttling'e neden olduğunu belirlemek için Contributor Insights'ı etkinleştir:
Yaygın Tuzaklar ve Çözümler
Tuzak 1: Adaptive Kapasiteye Güvenmek
Tuzak 2: GSI Kapasitesini Göz Ardı Etmek
Tuzak 3: On-Demand Ölçekleme Varsayımları
Tuzak 4: Batch Retry Mantığını Kaçırmak
Tuzak 5: Partition Başına Metrikleri İzlememek
Temel Çıkarımlar
- Önce Partition Key'leri Tasarla: Hot partition'lar throttling sorunlarının %90'ına neden oluyor
- Partition Başına Limitleri Anla: 3.000 RCU / 1.000 WCU per partition gerçek kısıt
- Write Sharding Çalışıyor: 10 shard = aynı erişim pattern'i için 10x yazma throughput'u
- Adaptive Kapasitenin Limitleri Var: Yeniden dengeleme anında, ama split-for-heat dakikalar alır; hiçbiri tek hot key'lere yardımcı olmaz
- On-Demand'ın Limitleri Var: 30 dakika içinde 2x ölçekleme, sınırsız değil
- GSI Throttling Yazmaları Engelliyor: Kapasite eşleştirme şart
- DAX Yüksek Hit Rate Gerektirir: %80 cache hit rate'in altında, ROI negatif
- Contributor Insights'ı İzle: Single Table Design'da hot key'leri belirlemenin tek yolu
- Unprocessed Item'ları Yeniden Dene: SDK batch işlem başarısızlıklarını otomatik yeniden denemiyor
- Etkinlikler için Ön Isıtma Yap: Hem provisioned hem de on-demand, trafik artışları için hazırlık gerektiriyor
Throttling'e dayanıklı DynamoDB uygulamaları oluşturmak, bu mekanizmaları anlamayı ve her katmanda uygun pattern'leri uygulamayı gerektiriyor. Partition key tasarımıyla başla, gerektiğinde sharding ekle, düzgün retry'lar uygula ve agresif bir şekilde izle. Sonuç, beklenmedik throttling incident'ları olmadan öngörülebilir şekilde ölçeklenen bir sistem.