DynoTable
중급8분 분량

DynamoDB 오토 스케일링을 설정하는 법

DynamoDB 오토 스케일링은 프로비저닝된 테이블의 읽기 및 쓰기 용량을 여러분이 고른 목표 사용률 쪽으로 조정합니다. 그래서 RCU/WCU를 손으로 튜닝하는 일도, 최악의 경우에 맞춘 예약에 하루 종일 지불하는 일도 그만둘 수 있습니다. 이 가이드는 용량 이야기의 실전 절반입니다. 콘솔 경로, CLI 명령, 숫자를 실제로 고르는 법, 그리고 급격한 급증을 여전히 스로틀링하는 타이밍 한계죠. 아직 용량 모드를 고르지 않았다면 온디맨드 대 프로비저닝에서 시작하세요 — 오토 스케일링은 프로비저닝에만 적용됩니다.

DynamoDB 테이블에서 오토 스케일링을 어떻게 활성화하나요?

콘솔에서는 테이블을 열고 Additional settings → Read/write capacity → Edit로 가서 Provisioned를 고르고, 읽기 용량, 쓰기 용량, 또는 둘 다에 대해 Auto scaling을 On으로 설정한 뒤 각각에 최소, 최대, 목표 사용률(20~90퍼센트 사이에서 설정 가능)을 주세요. CLI에서는 조정 가능한 대상을 등록하고 aws application-autoscaling으로 대상 추적 조정 정책을 연결합니다. 콘솔을 통해 생성한 테이블은 오토 스케일링이 기본으로 활성화됩니다.

오토 스케일링이 실제로 하는 일

조정 정책은 Application Auto Scaling에게 테이블의 소비 대 프로비저닝 비율을 여러분의 목표 사용률 근처로, 여러분이 설정한 최소와 최대 용량 경계 안에서 유지하라고 지시합니다. 내부적으로는 상한과 하한에 대한 CloudWatch 경보 한 쌍을 만듭니다. 소비가 그중 하나를 넘으면 Application Auto Scaling이 프로비저닝된 용량을 옮기기 위해 UpdateTable 호출을 발행합니다.

설정하기 전에 두 가지 구조적 사실이 중요합니다.

  • 정책은 테이블별 그리고 GSI별입니다. 모든 글로벌 보조 인덱스는 자체 프로비저닝된 처리량을 가지므로, 각각에 자체 정책이 필요합니다(또는 콘솔의 "same settings for all GSIs" 체크박스). 과소 조정된 GSI는 베이스 테이블 쓰기를 스로틀링할 수 있습니다 — GSI가 베이스 테이블을 스로틀링하는 이유를 보세요.
  • 콘솔에서 생성한 테이블은 기본으로 참여하고, 나중에 추가한 GSI는 빌드하는 동안 조정되지 않습니다. 기존 테이블의 새 GSI는 백필하는 동안 수동 용량으로 시작합니다 — 정책이 붙을 때까지 지켜보세요.

여러분이 감수하는 타이밍

오토 스케일링은 반응형이고, 그 반응 시간은 고정되어 있습니다 — AWS는 경보 데이터 포인트 개수가 조정 불가능하다고 문서화합니다.

  • 스케일 업은 소비된 용량이 연속 2분 동안 목표를 넘어선 뒤에 트리거됩니다(여기에 최대 몇 분의 CloudWatch 경보 지연이 더해집니다).
  • 스케일 다운은 목표 아래인 연속된 1분짜리 데이터 포인트 15개를 기다립니다.
  • 어느 쪽이 트리거되든, UpdateTable 호출은 적용되는 데 몇 분이 걸리며 — 그동안 이전 상한을 넘는 요청은 스로틀링됩니다.
DynamoDBApplication AutoScalingCloudWatchTrafficDynamoDBApplication AutoScalingCloudWatchTrafficrequests above the old ceiling throttle until the update landsconsumed > target, minute 1consumed > target, minute 2alarm firesUpdateTable (several minutes)

위반에서 새 용량까지의 그 약 5분이라는 하한이 이 기능의 정직한 한계입니다. 오토 스케일링은 자라는 트래픽을 흡수하지, 계단처럼 뛰는 트래픽을 흡수하지 않습니다. 1분 만에 부하를 세 배로 만드는 플래시 세일은 정책과 관계없이 프로비저닝 용량에서 스로틀링됩니다. 그 형태는 온디맨드를 부릅니다. 온디맨드는 이전 피크의 두 배까지 즉시 수용합니다(그리고 30분 이내에 두 배를 넘어서면 스로틀링합니다 — 같은 물리 법칙의 자체 버전이죠).

콘솔 설정

기존 테이블의 경우 (AWS 단계):

  1. DynamoDB 콘솔 → Tables → 테이블을 고릅니다.
  2. Additional settings 탭 → Read/write capacity → Edit.
  3. Capacity mode: Provisioned.
  4. Table capacity 아래에서 읽기, 쓰기, 또는 둘 다에 대해 Auto scaling을 On으로 바꾼 다음, 각각에 Minimum capacity units, Maximum capacity units, Target utilization을 설정합니다.
  5. 선택적으로 같은 설정을 모든 GSI에 적용하고 Save합니다.

알아둘 만한 콘솔 한계가 하나 있습니다. 쿨다운은 거기에 노출되지 않습니다. AWS 자체 문서가 "스케일 인 및 스케일 아웃 쿨다운 시간 설정과 같은 더 고급 기능"을 위해 CLI를 가리킵니다.

CLI 설정

차원당 두 번의 호출입니다. 조정 가능한 대상(최소/최대 경계)을 등록한 다음, 대상 추적 정책을 연결합니다. 테이블의 쓰기 용량에 대해 AWS의 CLI 안내에서 그대로 가져왔습니다.

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

정책 구성은 JSON 파일에 있습니다.

{
  "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

읽기의 경우 차원을 dynamodb:table:ReadCapacityUnits로, 지표를 DynamoDBReadCapacityUtilization으로 바꾸세요. GSI의 경우 리소스 id가 dynamodb:index:* 차원과 함께 table/TestTable/index/test-index가 됩니다. 따라서 두 차원을 모두 조정하는 GSI 세 개짜리 테이블에는 여덟 쌍의 대상/정책이 필요합니다 — 스크립트로 만드세요.

두 쿨다운은 DynamoDB에서 기본값이 0이며 CLI 전용 손잡이입니다. ScaleOutCooldown은 용량 증가 사이의 최소 초이고(더 큰 스케일 아웃은 여전히 즉시 통과합니다), ScaleInCooldown은 다음 감소를 막습니다 — 다만 스케일 아웃은 스케일 인 쿨다운을 기다리지 않고 중단시킵니다.

숫자 고르기

목표 사용률은 여유 대 비용의 다이얼입니다. 목표가 T 퍼센트일 때, 소비한 용량의 대략 100/T 배를 지불합니다. 70% 목표는 꾸준한 트래픽 위로 약 1.4배의 여유를 사고, 50% 목표는 2배를 삽니다. 낮은 목표는 더 급격한 증가를 스로틀링 없이 넘기고, 높은 목표는 예약을 덜 낭비합니다. 범위는 20~90%입니다.

이 다이얼은 청구서에 곧장 연결됩니다. 현재 us-east-1 요율에서 (DynamoDB는 오토 스케일링할 수 있나요?와 같은 도출): 100% 사용률의 프로비저닝 용량은 요청당 온디맨드보다 약 3.46배 저렴하며, 손익분기점은 약 29% 사용률에 있습니다. 오토 스케일링의 일은 실제 사용률을 여러분의 목표 근처로 유지하는 것이므로, 목표는 사실상 여러분의 할인율을 고르는 셈입니다. 70%로 유지하면 프로비저닝이 온디맨드보다 약 2.4배 저렴하고, 50%에서는 약 1.7배이며, 약 29% 아래라면 대신 온디맨드에 있어야 합니다. 여러분 워크로드의 숫자는 요금 계산기에서 확인하세요.

최소 용량은 여러분의 급증 바닥입니다. 오토 스케일링이 반응하는 데 필요한 약 5분 동안 이미 거기에 있는 용량이죠. 평균 트래픽이 아니라, 스로틀링 없이 흡수해야 하는 가장 급격한 버스트를 기준으로 설정하세요.

최대 용량은 폭주 방지 장치입니다 — 버그, 뜨거운 Lambda 루프, 또는 부하 테스트가 여러분에게 청구할 수 있는 것의 상한이죠. 현실적인 피크 위로 설정하고, 거기에 도달하는 것을 정상 운영이 아니라 경보로 취급하세요.

스케일 다운은 할당량 제한이 있습니다. 프로비저닝 감소는 토큰 버킷에서 나옵니다. 매 UTC 하루를 사용 가능한 4개로 시작하고, 시간당 하나씩 적립되며(최대 4개 보유), 테이블당 하루 최대 27번의 감소입니다 — GSI 한도는 별개지만, 테이블과 인덱스를 모두 감소시키는 단일 요청은 어느 한쪽이라도 할당량이 부족하면 통째로 거부됩니다. 오토 스케일링의 보수적인 15분 스케일 다운이 실전에서는 이미 이를 존중하지만, 그것이 급증 후에 용량이 천천히 내려가는 이유이자 — 진동하는 트래픽이 평균보다 높게 고정된 채 하루를 마치는 이유입니다.

DynoTable에서 하기

최소를 크기 재는 일과 목표를 검증하는 일 모두 추측이 아니라 실제 숫자에서 시작합니다. 항목이 얼마나 큰지, 몇 개인지, 대표적인 읽기나 쓰기가 실제로 무엇을 소비하는지 말이죠. DynoTable의 테이블 뷰는 라이브 항목 수와 테이블 크기를 드러내고, 쿼리 비용 미리보기는 문장이 실행되기 전에 그 RCU 추정치를 보여줍니다 — 용량 계획이 만들어지는 바로 그 숫자들입니다. 단일 항목의 크기를 재려면 무료 항목 크기 계산기가 그 RCU/WCU 발자국을 계산해 줍니다.

함정과 다음 단계

  • 오토 스케일링은 파티션당 물리 법칙을 이기지 못합니다. 뜨거운 키는 용량이 남아돌아도 스로틀링됩니다 — 핫 파티션과 적응형 용량을 보세요.
  • GSI를 잊지 마세요. 각 인덱스는 자체적으로 조정됩니다(또는 스로틀링됩니다).
  • 예약 용량은 프로비저닝에만 쌓입니다. 오토 스케일링이 거의 움직이지 않을 만큼 워크로드가 꾸준하다면, 예약 용량(Standard 테이블 클래스, 프로비저닝 모드 전용)이 다음 할인입니다 — 온디맨드 테이블은 쓸 수 없습니다.
  • 첫날을 지켜보세요. CloudWatch에서 프로비저닝된 선에 대비한 ConsumedReadCapacityUnits / ConsumedWriteCapacityUnits가 목표가 유지되고 있는지 진동하고 있는지 빠르게 알려줍니다.

용량은 비용 모델의 한 축이고, 여러분의 쿼리가 소비하는 것이 다른 축입니다 — Scan 대 Query와 SQL 스캔 비용 모델이 그 절반을 다룹니다.

테이블에 용량 숫자를 커밋하기 전에 DynoTable을 다운로드해서 테이블의 실제 크기, 항목 수, 쿼리당 비용을 읽으세요.

업데이트됨