DynamoDB 트래픽 관리 | Throttling, On-Demand, Provisioned, Auto Scaling 이해하기

들어가며

이전 글에서는 DynamoDB의 WCU와 RCU, 그리고 읽기·쓰기 처리량을 계산하는 방법에 대해 알아보았습니다.

하지만 WCU와 RCU를 계산할 수 있다고 해서 항상 안정적으로 서비스를 운영할 수 있는 것은 아닙니다. 실제 운영 환경에서는 예상보다 많은 요청이 발생하거나 특정 데이터에 트래픽이 집중되면서 성능 문제가 발생할 수 있습니다.

 

이번 글에서는 DynamoDB에서 트래픽을 관리하는 핵심 개념인 Throttling, Hot Partition, On-Demand, Provisioned, Auto Scaling에 대해 알아보고, 각각 어떤 상황에서 사용하는 것이 적합한지 살펴보겠습니다.

---

1. Throttling이란?

Throttling은 DynamoDB가 처리할 수 있는 읽기 또는 쓰기 처리량을 초과하는 요청이 발생했을 때 일부 요청을 제한하는 동작입니다.

예를 들어 테이블의 처리 용량이 다음과 같이 설정되어 있다고 가정해보겠습니다.

• WCU : 100
• RCU : 200

이 상태에서 초당 300개의 Write 요청이 발생하면 DynamoDB는 모든 요청을 처리할 수 없습니다.

처리 가능한 100개의 요청은 정상적으로 수행되지만, 나머지 요청은 ThrottlingException 또는 ProvisionedThroughputExceededException과 같은 예외가 발생하며 재시도를 수행하게 됩니다.

즉, Throttling은 장애가 아니라 데이터베이스를 보호하기 위한 안전장치라고 이해하면 됩니다.

---

2. Hot Partition과의 관계

https://www.scylladb.com/glossary/dynamodb-hot-partition

Throttling이 발생하는 가장 대표적인 원인 중 하나가 Hot Partition입니다.

DynamoDB는 Partition Key를 기준으로 데이터를 여러 파티션에 분산 저장합니다.

하지만 모든 요청이 하나의 Partition Key에 집중된다면 해당 파티션만 과도한 부하를 받게 됩니다.

예를 들어 다음과 같은 Partition Key를 사용했다고 가정해보겠습니다.

• USER
• USER
• USER
• USER

모든 데이터가 동일한 Partition Key를 사용하므로 요청 역시 하나의 파티션에 집중됩니다.

반면,

• user001
• user002
• user003
• user004

처럼 다양한 Partition Key를 사용하면 여러 파티션으로 요청이 분산되어 더 안정적인 처리 성능을 유지할 수 있습니다.

따라서 DynamoDB에서는 좋은 Partition Key를 설계하는 것이 성능과 직결되는 중요한 요소입니다.

---

3. On-Demand 모드

On-Demand는 WCU와 RCU를 사용자가 직접 설정하지 않는 Capacity 모드입니다.

애플리케이션의 트래픽에 따라 DynamoDB가 자동으로 처리 용량을 확장하거나 축소하며, 사용자는 실제 수행한 Read와 Write 요청 수만큼만 비용을 지불합니다.

예를 들어 평소에는 초당 100건의 요청이 발생하지만 특정 이벤트로 인해 갑자기 초당 3,000건의 요청이 발생하더라도 DynamoDB가 자동으로 처리 용량을 확장하여 서비스를 유지합니다.

On-Demand는 다음과 같은 환경에서 적합합니다.

• 신규 서비스
• 트래픽 예측이 어려운 서비스
• 이벤트성 서비스
• 개발 및 테스트 환경

반면 지속적으로 많은 요청이 발생하는 서비스에서는 Provisioned 모드보다 비용이 높아질 수 있습니다.

---

4. Provisioned 모드와 비교

Provisioned 모드는 사용자가 미리 WCU와 RCU를 설정하는 방식입니다.

예를 들어

• WCU : 500
• RCU : 1,000

으로 설정하면 DynamoDB는 해당 처리량을 항상 확보합니다.

트래픽이 거의 없어도 설정한 Capacity에 대한 비용이 발생하지만, 일정한 트래픽에서는 On-Demand보다 비용 효율이 높습니다.

 

항목	On-Demand	Provisioned
WCU/RCU 설정	불필요	직접 설정
비용 기준	실제 요청 수	설정한 Capacity
트래픽 예측	불필요	필요
적합한 환경	신규 서비스, 이벤트	운영 중인 안정적인 서비스

---

5. Auto Scaling

Provisioned 모드를 사용한다고 해서 항상 같은 WCU와 RCU를 유지하는 것은 아닙니다.

Auto Scaling을 활성화하면 CloudWatch에서 모니터링한 사용량을 기준으로 WCU와 RCU를 자동으로 조정할 수 있습니다.

평소에는

• WCU : 200

이면 충분하지만, 점심시간에는

• WCU : 600

이 필요할 수도 있습니다.

Auto Scaling은 이러한 변화를 감지하여 필요한 만큼 Capacity를 자동으로 증가시키고, 트래픽이 감소하면 다시 줄여 비용을 절감합니다. 따라서 트래픽이 어느 정도 예측 가능하지만 시간대별 편차가 큰 서비스에서 많이 활용됩니다.

---

6. 실무에서는 어떤 모드를 사용할까?

실무에서는 서비스의 특성에 따라 Capacity 모드를 선택합니다.

6-1) On-Demand를 사용하는 경우

• 신규 서비스
• 초기 MVP
• 이벤트성 서비스
• 사용량 예측이 어려운 환경

처음에는 트래픽을 예측하기 어렵기 때문에 운영 부담이 적은 On-Demand를 선택하는 경우가 많습니다.

6-2) Provisioned + Auto Scaling을 사용하는 경우

서비스가 안정적으로 운영되고 일정 수준 이상의 트래픽이 유지된다면 Provisioned 모드와 Auto Scaling을 함께 사용하는 경우가 많습니다.

 

예를 들어 쇼핑몰이나 금융 서비스처럼 하루 평균 트래픽이 일정한 서비스에서는 필요한 Capacity를 미리 확보하면서도 Auto Scaling으로 시간대별 트래픽 변화에 대응하여 비용과 성능을 함께 관리합니다.

• 예측 불가능한 서비스 → On-Demand
• 예측 가능한 운영 서비스 → Provisioned + Auto Scaling

이라는 방식이 일반적인 운영 전략입니다.

---

7. 마치며

이번 글를 정리하며 DynamoDB에서는 단순히 WCU와 RCU를 계산하는 것만큼이나 트래픽을 어떻게 관리하는지도 중요하다는 점을 알 수 있었습니다. 특히 Throttling은 단순한 오류가 아니라 처리 용량을 초과한 요청으로부터 데이터베이스를 보호하기 위한 기능이며, Hot Partition을 방지할 수 있는 Partition Key 설계가 성능에 큰 영향을 미친다는 점을 이해할 수 있었습니다. 또한 서비스 특성에 따라 On-Demand와 Provisioned 모드를 선택하고 Auto Scaling을 활용하면 비용과 성능을 함께 고려한 운영이 가능하다는 점도 배울 수 있었습니다.