본문으로 건너뛰기

CapacityModes

1 용량 모드​

![[Pasted image 20240701104719.png]]

  • DynamoDB는 테이블의 용량(읽기/쓰기 처리량)을 관리하는 두 가지 모드를 제공합니다.
  • 이 모드들은 테이블의 성능과 비용에 직접적인 영향을 미칩니다.
  • 프로비저닝된 모드 (Provisioned Mode)
    • 기본 모드로, 초당 읽기/쓰기 횟수를 미리 지정합니다.
    • 용량을 사전에 계획해야 하며, 프로비저닝된 용량 단위에 대해 비용을 지불합니다.
    • 예측 가능한 워크로드나 일정한 트래픽 패턴을 가진 애플리케이션에 적합합니다.
  • 온디맨드 모드 (On-Demand Mode)
    • 워크로드에 따라 읽기/쓰기가 자동으로 확장/축소됩니다.
    • 용량 계획이 필요 없으며, 사용한 만큼만 비용을 지불합니다.
    • 예측하기 어려운 워크로드나 급격한 트래픽 변동이 있는 애플리케이션에 적합합니다.
    • 프로비저닝된 모드보다 비용이 더 높을 수 있습니다.

2 프로비저닝된 모드 (Provisioned Mode)​

  • 기본 모드로, 테이블의 초당 읽기/쓰기 횟수를 미리 지정합니다.
  • 용량을 사전에 계획해야 하며, 프로비저닝된 읽기 및 쓰기 용량 단위에 대해 비용을 지불합니다.
  • 예측 가능한 워크로드나 일정한 트래픽 패턴을 가진 애플리케이션에 적합합니다.

2.1 프로비저닝된 모드의 특징​

  • 읽기 용량 단위(RCU)와 쓰기 용량 단위(WCU)로 처리량을 측정합니다.
  • 자동 스케일링 옵션을 통해 수요에 맞춰 처리량을 조정할 수 있습니다.
  • "버스트 용량"을 통해 일시적으로 처리량을 초과할 수 있습니다.
  • 버스트 용량이 소진되면 "ProvisionedThroughputExceededException"이 발생합니다.

2.2 스로틀링(Throttling)과 해결 방법​

  • 프로비저닝된 RCU나 WCU를 초과하면 ProvisionedThroughputExceededException이 발생합니다.

스로틀링의 주요 원인

  • 핫 키(Hot Keys): 특정 파티션 키에 대한 읽기가 과도하게 많은 경우 (예: 인기 있는 아이템)
  • 핫 파티션(Hot Partitions): 특정 파티션에 트래픽이 집중되는 경우
  • 대용량 아이템: RCU와 WCU는 아이템 크기에 따라 달라지므로, 매우 큰 아이템의 경우 더 많은 용량 단위를 소비합니다.

해결 방법

  • 예외 발생 시 지수 백오프(Exponential backoff) 사용
    • 클라이언트 요청이 스로틀링될 때 지수 백오프를 통해 재시도 간격을 점차 늘려줍니다.
    • 초기 재시도 간격을 짧게 시작해 점차 길게 함으로써 서버 부하를 줄이고 성공 확률을 높입니다.
    • AWS SDK에서는 이미 지수 백오프 전략이 기본적으로 구현되어 있어 추가적인 작업이 필요하지 않습니다.
  • 파티션 키를 최대한 분산하여 사용
    • 트래픽이 특정 파티션에 집중되지 않도록 파티션 키를 더 고르게 분산해야 합니다.
    • 파티션 키에 주기적인 값(예: 날짜, 지역) 등을 추가하여 더 많은 파티션으로 데이터를 분산시킵니다.
    • 이로 인해 트래픽이 여러 파티션으로 나누어져 전체적인 스로틀링을 완화할 수 있습니다.
  • RCU 관련 문제의 경우, DynamoDB Accelerator(DAX)를 사용하여 캐싱 계층 추가 고려
    • DAX는 DynamoDB에 캐싱 계층을 추가하여 자주 조회되는 데이터를 메모리에서 빠르게 가져올 수 있게 합니다.
    • 읽기 요청이 캐시에서 처리되므로 RCU를 줄일 수 있고, 스로틀링 문제도 완화됩니다.
    • DAX는 일관성 요구사항이 덜 엄격한 애플리케이션에 적합하며, 응답 시간을 크게 단축할 수 있습니다.

3 온디맨드 모드 (On-Demand Mode)​

  • 읽기 및 쓰기 작업이 워크로드에 맞춰 자동으로 확장되고 축소됩니다.
  • WCU와 RCU를 미리 설정할 필요 없이, 필요 시 용량이 자동으로 조정됩니다.
  • 사용한 만큼만 비용을 지불하며, 예측 불가능한 트래픽이나 급격한 변동이 있는 애플리케이션에 이상적입니다.
  • 스로틀링이 발생하지 않지만, 무제한으로 확장되기 때문에 비용이 더 높을 수 있습니다.
  • 온디맨드 모드는 프로비저닝된 용량 모드보다 약 2.5배 더 비싸므로, 신중하게 사용해야 합니다.

4 용량 단위 이해하기​

4.1 쓰기 용량 단위 (WCU)​

  • 1 WCU = 최대 1KB 크기의 항목에 대해 초당 1회 쓰기
  • 항목 크기가 1KB를 초과하면 더 많은 WCU가 소비됩니다.

예시

  • 2KB 항목을 초당 10개 쓰는 경우: 10 * (2KB / 1KB) = 20 WCU 필요
  • 4.5KB 항목을 초당 6개 쓰는 경우: 6 * (5KB / 1KB) = 30 WCU 필요 (4.5KB는 5KB로 반올림)
  • 2KB 항목을 분당 120개 쓰는 경우: (120 / 60) * (2KB / 1KB) = 4 WCU 필요

4.2 읽기 용량 단위 (RCU)​

  • 1 RCU = 최대 4KB 크기의 항목에 대해 초당 1회 강력한 일관된 읽기 또는 2회의 최종적 일관된 읽기
  • 항목 크기가 4KB를 초과하면 더 많은 RCU가 소비됩니다.

예시

  • 4KB 항목에 대해 초당 10회의 강력한 일관된 읽기: 10 * (4KB / 4KB) = 10 RCU 필요
  • 12KB 항목에 대해 초당 16회의 최종적 일관된 읽기: (16 / 2) * (12KB / 4KB) = 24 RCU 필요
  • 6KB 항목에 대해 초당 10회의 강력한 일관된 읽기: 10 * (8KB / 4KB) = 20 RCU 필요 (6KB는 8KB로 반올림)

5 일관성 모델​

5.1 최종적 일관된 읽기 (Eventually Consistent Read)​

  • 기본 설정으로, 복제 지연으로 인해 최신 데이터를 읽지 못할 수 있습니다.
  • 더 적은 RCU를 소비합니다.

5.2 강력한 일관된 읽기 (Strongly Consistent Read)​

  • 쓰기 직후 읽기 시 항상 최신 데이터를 반환합니다.
  • API 호출 시 'ConsistentRead' 파라미터를 True로 설정하여 사용합니다.
  • 최종적 일관된 읽기의 두 배의 RCU를 소비합니다.

6 모드 전환 및 주의사항​

  • 용량 모드는 24시간마다 한 번씩 전환할 수 있습니다.
  • 모드 전환 시 테이블의 성능과 비용에 영향을 미칠 수 있으므로 신중히 결정해야 합니다.
  • 프로비저닝된 모드에서는 자동 스케일링 설정을 통해 유연성을 확보할 수 있습니다.

7 결론​

  • DynamoDB의 용량 모드는 애플리케이션의 요구사항과 트래픽 패턴에 따라 선택해야 합니다.
  • 프로비저닝된 모드는 예측 가능한 워크로드에, 온디맨드 모드는 변동이 심한 워크로드에 적합합니다.
  • 용량 단위(WCU, RCU)를 정확히 이해하고 계산하는 것이 효율적인 리소스 관리와 비용 최적화에 중요합니다.
  • 일관성 모델을 적절히 선택하여 애플리케이션의 요구사항을 충족시키면서도 비용을 최적화할 수 있습니다.