DynamoDB Otomatik Ölçekleme Nasıl Kurulur

DynamoDB otomatik ölçekleme, provisioned bir tablonun okuma ve yazma kapasitesini sizin seçtiğiniz bir hedef kullanım oranına doğru ayarlar; böylece RCU/WCU'yu elle ayarlamayı ve gece gündüz en kötü durum rezervasyonu için ödeme yapmayı bırakırsınız. Bu rehber, kapasite hikâyesinin uygulamalı yarısıdır: konsol yolu, CLI komutları, rakamları gerçekte nasıl seçeceğiniz ve keskin bir ani artışı yine de kısıtlayan zamanlama sınırları. Henüz bir kapasite modu seçmediyseniz On-Demand ve Provisioned ile başlayın — otomatik ölçekleme yalnızca Provisioned için geçerlidir.

Bir DynamoDB tablosunda otomatik ölçeklemeyi nasıl etkinleştirirsiniz?

Konsolda: tablonuzu açın, Additional settings → Read/write capacity → Edit yolunu izleyin, Provisioned'ı seçin ve okuma kapasitesi, yazma kapasitesi ya da her ikisi için Auto scaling'i On yapın; her birine bir minimum, bir maksimum ve bir hedef kullanım (%20 ile %90 arasında ayarlanabilir) verin. CLI'dan, aws application-autoscaling ile ölçeklenebilir bir hedef kaydedin ve hedef izlemeli bir ölçekleme politikası ekleyin. Konsol üzerinden oluşturulan tablolarda otomatik ölçekleme varsayılan olarak etkindir.

Otomatik ölçekleme gerçekte ne yapar

Bir ölçekleme politikası, Application Auto Scaling'e bir tablonun tüketilen/provisioned oranını, belirlediğiniz minimum ve maksimum kapasite sınırları içinde hedef kullanım değerinize yakın tutmasını söyler. Kaputun altında üst ve alt sınırlar için bir çift CloudWatch alarmı oluşturur; tüketim birini geçtiğinde Application Auto Scaling, provisioned kapasiteyi taşımak için bir UpdateTable çağrısı yayınlar.

Kurulumdan önce iki yapısal gerçek önemlidir:

• Politikalar tablo başına ve GSI başınadır. Her global secondary index'in kendi provisioned throughput'u vardır, bu yüzden her birinin kendi politikasına (ya da konsolun "tüm GSI'ler için aynı ayarlar" onay kutusuna) ihtiyacı vardır. Az ölçeklenmiş bir GSI, temel tablo yazmalarını kısıtlayabilir — bkz. bir GSI temel tabloyu neden kısıtlar.
• Konsolda oluşturulan tablolar varsayılan olarak dahil olur; sonradan eklenen GSI'ler kurulurken ölçeklenmez. Mevcut bir tablodaki yeni bir GSI, geri dolumu boyunca manuel kapasiteyle başlar — politika bağlanana kadar onu izleyin.

Kabul ettiğiniz zamanlama

Otomatik ölçekleme tepkiseldir ve tepki süreleri sabittir — AWS, alarm veri noktası sayılarının ayarlanabilir olmadığını belgeler:

• Ölçek büyütme, tüketilen kapasite hedefi arka arkaya iki dakika boyunca aştıktan sonra tetiklenir (artı birkaç dakikaya kadar CloudWatch alarm gecikmesi).
• Ölçek küçültme, hedefin altında arka arkaya 15 adet bir dakikalık veri noktası bekler.
• Her iki tetikten sonra da UpdateTable çağrısının uygulanması birkaç dakika sürer — ve bu sırada eski tavanın üzerindeki istekler kısıtlanır.

İhlalden yeni kapasiteye kadarki o ~5 dakikalık taban, özelliğin dürüst sınırıdır: otomatik ölçekleme büyüyen trafiği emer, basamak atlayan trafiği değil. Yükü bir dakikada üçe katlayan bir flaş indirim, politikanız ne olursa olsun provisioned kapasitede kısıtlanacaktır; o şekil On-Demand ister — ki o da önceki zirvenizin iki katına kadar olanı anında karşılar (ve 30 dakika içinde iki katının ötesini kısıtlar — aynı fiziğin kendi versiyonu).

Konsol kurulumu

Mevcut bir tablo için (AWS adımları):

1. DynamoDB konsolu → Tables → tabloyu seçin.
2. Additional settings sekmesi → Read/write capacity → Edit.
3. Capacity mode: Provisioned.
4. Table capacity altında, okuma, yazma ya da her ikisi için Auto scaling'i On konumuna getirin, sonra her biri için Minimum capacity units, Maximum capacity units ve Target utilization değerlerini ayarlayın.
5. İsteğe bağlı olarak aynı ayarları her GSI'ye uygulayın ve Save deyin.

Bilinmeye değer bir konsol sınırlaması: cooldown'lar orada sunulmaz. AWS'nin kendi belgeleri sizi "scale-in ve scale-out cooldown sürelerini ayarlamak gibi daha gelişmiş özellikler için" CLI'a yönlendirir.

CLI kurulumu

Boyut başına iki çağrı: ölçeklenebilir hedefi (min/max sınırları) kaydedin, sonra hedef izlemeli politikayı ekleyin. Bir tabloda yazma kapasitesi için, AWS'nin CLI adım adım anlatımından birebir:

aws application-autoscaling register-scalable-target \
    --service-namespace dynamodb \
    --resource-id "table/TestTable" \
    --scalable-dimension "dynamodb:table:WriteCapacityUnits" \
    --min-capacity 5 \
    --max-capacity 10

Politika yapılandırması bir JSON dosyasında yaşar:

{
  "PredefinedMetricSpecification": {
    "PredefinedMetricType": "DynamoDBWriteCapacityUtilization"
  },
  "ScaleOutCooldown": 60,
  "ScaleInCooldown": 60,
  "TargetValue": 50.0
}

aws application-autoscaling put-scaling-policy \
    --service-namespace dynamodb \
    --resource-id "table/TestTable" \
    --scalable-dimension "dynamodb:table:WriteCapacityUnits" \
    --policy-name "MyScalingPolicy" \
    --policy-type "TargetTrackingScaling" \
    --target-tracking-scaling-policy-configuration file://scaling-policy.json

Okumalar için boyutu dynamodb:table:ReadCapacityUnits ile, metriği ise DynamoDBReadCapacityUtilization ile değiştirin. Bir GSI için kaynak kimliği table/TestTable/index/test-index olur ve dynamodb:index:* boyutları kullanılır. Dolayısıyla her iki boyutu da ölçekleyen üç GSI'li bir tablonun sekiz hedef/politika çiftine ihtiyacı vardır — betikleyin.

İki cooldown, DynamoDB için varsayılan olarak 0'dır ve yalnızca CLI'dan erişilen düğmelerdir: ScaleOutCooldown kapasite artışları arasındaki minimum saniyedir (daha büyük bir scale-out yine de anında geçer), ScaleInCooldown ise bir sonraki azalmayı engeller — gerçi bir scale-out, bir scale-in cooldown'ını beklemek yerine keser.

Rakamları seçmek

Hedef kullanım, baş oda ile maliyet arasındaki bir kadrandır. %T'lik bir hedefte, tükettiğiniz kapasitenin kabaca 100/T katı için ödeme yaparsınız: %70'lik bir hedef, istikrarlı trafiğin üzerinde ~1,4× baş oda satın alır; %50'lik bir hedef 2× satın alır. Daha düşük hedefler daha keskin büyümeyi kısıtlanmadan atlatır; daha yüksek hedefler daha az rezervasyon israf eder. Aralık %20–90'dır.

Kadran doğrudan faturaya bağlanır. Güncel us-east-1 fiyatlarından (DynamoDB otomatik ölçeklenebilir mi? ile aynı türetme): %100 kullanımda provisioned kapasite, istek başına on-demand'den ~3,46× daha ucuzdur ve başa baş noktası ~%29 kullanımdadır. Otomatik ölçeklemenin işi, gerçek kullanımı hedefinize yakın tutmaktır, dolayısıyla hedef aslında indiriminizi seçiyor demektir: %70'te tutulduğunda provisioned, on-demand'den ~2,4× daha ucuza çalışır; %50'de ~1,7×; ~%29'un altında ise onun yerine on-demand'de olmalısınız. Kendi iş yükünüzün rakamlarını fiyatlandırma hesaplayıcısında kontrol edin.

Minimum kapasite ani artış tabanınızdır: otomatik ölçeklemenin tepki vermek için ihtiyaç duyduğu ~5 dakika boyunca zaten orada olan kapasitedir. Onu ortalama trafiğe göre değil, kısıtlanmadan emmeniz gereken en keskin patlamaya göre belirleyin.

Maksimum kapasite başıboş kalmaya karşı korumadır — bir hatanın, sıcak bir Lambda döngüsünün ya da bir yük testinin size faturalayabileceğinin tavanı. Onu gerçekçi zirvenizin üzerine ayarlayın ve ona çarpmayı normal işleyiş değil, bir alarm olarak ele alın.

Ölçek küçültme kota sınırlıdır. Provisioned azaltmalar bir token kovasından gelir: her UTC gününe 4 kullanılabilir azaltmayla başlarsınız, saatte bir tane daha birikir (en fazla 4 tutulur) ve tablo başına günde en çok 27 azaltma olur — GSI limitleri ayrıdır, ama hem tabloyu hem index'i azaltan tek bir istek, taraflardan birinin kotası yetmiyorsa bütünüyle reddedilir. Otomatik ölçeklemenin muhafazakâr 15 dakikalık ölçek küçültmesi pratikte buna zaten saygı gösterir, ama kapasitenin bir ani artıştan sonra neden yavaş yavaş aşağı indiğini — ve salınan trafiğin günü neden ortalamasından yüksek sabitlenmiş bitirdiğini — bu açıklar.

DynoTable'da yapın

Minimumu boyutlandırmak ve hedefi doğrulamak, tahminlerden değil gerçek rakamlardan başlar: item'lar ne kadar büyük, kaç tane var ve temsili bir okuma ya da yazma gerçekte ne tüketiyor. DynoTable'ın tablo görünümü canlı item sayısını ve tablo boyutunu öne çıkarır ve sorgu maliyeti önizlemesi, bir ifadenin RCU tahminini o çalıştırılmadan önce gösterir — bir kapasite planının yapıldığı rakamların ta kendisi. Tek bir item'ı boyutlandırmak için ücretsiz item boyutu hesaplayıcısı onun RCU/WCU ayak izini hesaplar.

Tuzaklar ve sonraki adımlar

• Otomatik ölçekleme bölüm başına fiziği yenmez. Sıcak bir anahtar, kapasite artakalırken bile kısıtlar — bkz. sıcak bölümler ve uyarlanabilir kapasite.
• GSI'leri unutmayın. Her index kendi başına ölçeklenir (ya da kısıtlar).
• Rezerve kapasite yalnızca provisioned üzerine biner. Bir iş yükü, otomatik ölçekleme neredeyse hiç kımıldamayacak kadar istikrarlıysa, sıradaki indirim rezerve kapasitedir (Standard tablo sınıfı, yalnızca provisioned mod) — on-demand tablolar bunu kullanamaz.
• İlk günü izleyin. CloudWatch'ta provisioned çizgisine karşı ConsumedReadCapacityUnits / ConsumedWriteCapacityUnits, hedefin tuttuğunu mu yoksa salındığını mı size hızla söyler.

Kapasite, maliyet modelinin bir eksenidir; sorgularınızın ne tükettiği ise diğeri — Scan ile Query ve SQL-scan maliyet modeli o yarıyı kapsar.

Kapasite rakamlarını tablonuza işlemeden önce onun gerçek boyutunu, item sayısını ve sorgu başına maliyetini okumak için DynoTable'ı indirin.