이 섹션에서는 DynamoDB 테이블에 적절한 용량 모드를 선택하는 방법을 간략히 살펴봅니다. 각 모드는 처리량(throughput) 변화에 대한 대응력 및 사용량 청구 방식 측면에서 다양한 워크로드의 요구 사항을 충족하도록 조정됩니다. 결정을 내릴 때 이러한 요소들의 균형을 맞춰야 합니다.
사용할 수 있는 테이블 용량 모드
DynamoDB 테이블을 생성할 때 온디맨드 또는 프로비저닝된 용량 모드를 선택해야 합니다. 24시간마다 한 번 용량 모드를 전환할 수 있습니다. 유일한 예외는 프로비저닝된 모드 테이블을 온디맨드 모드로 전환하는 경우 동일한 24시간 내에 프로비저닝된 모드로 다시 전환할 수 있다는 것입니다.
온디맨드 용량 모드
온디맨드 용량 모드는 DynamoDB 테이블의 용량을 계획하거나 프로비저닝할 필요가 없도록 설계되었습니다. 이 모드에서 테이블은 리소스를 확장하거나 축소할 필요 없이 테이블에 대한 요청을 즉시 수용합니다(테이블의 이전 최대 처리량(throughput)의 최대 2배).
DynamoDB 온디맨드는 읽기 및 쓰기 요청에 대해 요청당 지불 요금이 적용되므로 사용하는 만큼에 대해서만 비용을 지불하면 됩니다.
프로비저닝된 용량 모드
프로비저닝된 용량 모드는 테이블이 요청에 사용할 수 있는 용량을 직접 또는 오토 스케일링의 도움으로 정의할 수 있는 보다 전통적인 모델입니다. 지정된 시간에 테이블에 대해 특정 용량이 프로비저닝되기 때문에 비용은 사용된 요청 수가 아닌 프로비저닝된 용량을 기준으로 청구됩니다. 할당된 용량을 초과하면 테이블이 요청을 거부하고 애플리케이션 사용자의 경험을 감소시킬 수도 있습니다.
프로비저닝된 용량 모드에서는 스로틀링을 낮게 유지하고 비용을 조정하기 위해 테이블을 과다 프로비저닝 또는 과소 프로비저닝하지 않도록 지속적인 모니터링을 통해 균형을 찾아야 합니다.
온디맨드 용량 모드를 선택하는 경우
비용에 맞게 최적화할 때는 다음 그래프와 유사한 워크로드가 있는 경우 온디맨드 모드가 최선의 선택입니다.
이러한 유형의 워크로드에 영향을 미치는 요소는 다음과 같습니다.
-
시간이 지남에 따라 변화하는 트래픽 패턴
-
다양한 볼륨의 요청(배치 워크로드로 인한 요청)
-
예측할 수 없는 요청 타이밍(트래픽 급증 초래)
-
지정된 시간 동안 0 또는 피크의 30% 미만으로 떨어짐


위의 요소가 있는 워크로드의 경우 Auto Scaling을 사용하여 테이블에서 트래픽 급증에 대응할 수 있는 충분한 용량을 유지하면 테이블이 과도하게 프로비저닝되고 필요 이상으로 비용이 많이 들거나 테이블이 과소 프로비저닝되고 요청이 불필요하게 제한될 수 있습니다. 온디맨드 용량 모드는 용량을 예측하거나 조정할 필요 없이 변동하는 트래픽을 처리할 수 있으므로 더 나은 선택입니다.
온디맨드 모드의 요청당 지불 요금 모델을 사용하면 실제로 사용하는 처리량에 대해서만 지불하기 때문에 유휴 용량에 대해 걱정할 필요가 없습니다. 사용된 읽기 또는 쓰기 요청당 요금이 청구되므로 요금에 실제 사용량이 직접 반영되어 비용과 성능의 균형을 쉽게 맞출 수 있습니다. 선택적으로, 개별 온디맨드 테이블 및 글로벌 보조 인덱스의 초당 최대 읽기 또는 쓰기(또는 둘 다) 처리량을 구성하여 비용과 사용량을 제한할 수도 있습니다. 자세한 내용은 온디맨드 테이블의 최대 처리량을 참조하세요.
프로비저닝된 용량 모드를 선택하는 경우
프로비저닝된 용량 모드에 대한 이상적인 워크로드는 아래 그래프와 같이 사용 패턴이 더 안정적이고 예측 가능한 워크로드입니다.
참고
프로비저닝된 용량에 대해 조치를 취하기 전에 14일 등 세분화된 기간으로 지표를 검토하는 것이 좋습니다.
이러한 유형의 워크로드에 영향을 미치는 요소는 다음과 같습니다.
-
지정된 시간 또는 날짜에 대한 안정적이고 예측 가능한 주기적 트래픽
-
제한적인 단기 트래픽 폭주

지정된 시간 또는 일의 트래픽 볼륨이 더 안정적이기 때문에 테이블의 프로비저닝된 용량을 테이블의 실제 사용된 용량에 비교적 가깝게 설정할 수 있습니다. 프로비저닝된 용량 테이블의 비용 최적화는 궁극적으로 테이블에서 ThrottledRequests
를 늘리지 않고 할당된 용량(파란색 선)을 사용된 용량(주황색 선)에 최대한 가깝게 만드는 연습입니다. 두 선 사이의 공간은 낭비된 용량뿐만 아니라 제한으로 인해 발생할 수 있는 나쁜 사용자 경험에 대비한 용량을 나타냅니다. 애플리케이션의 처리량 요구 사항을 예측할 수 있고 읽기 및 쓰기 용량 제어의 비용 예측성을 선호하는 경우 프로비저닝된 테이블을 계속 사용할 수 있습니다.
DynamoDB는 프로비저닝된 용량 테이블에 대한 Auto Scaling을 제공하므로 사용자를 대신하여 자동으로 균형을 조정할 수 있습니다. 이를 통해 하루 종일 사용된 용량을 추적하고 몇 가지 변수를 기반으로 테이블의 용량을 설정할 수 있습니다. 오토 스케일링을 사용하면 테이블이 과다 프로비저닝되므로 워크로드 요구 사항에 맞게 스로틀 수와 과다 프로비저닝된 용량 단위 간의 비율을 미세 조정해야 합니다.

최소 용량 단위
제한을 설정하지 않도록 테이블의 최소 용량을 설정할 수 있지만 테이블 비용이 줄어들지는 않습니다. 테이블 사용량이 낮은 기간이 있다가 갑자기 사용량이 급증한 경우 최소값으로 설정하면 Auto Scaling이 테이블 용량을 너무 낮게 설정하는 것을 방지할 수 있습니다.
최대 용량 단위
테이블의 최대 용량을 설정하여 테이블 확장을 의도한 것보다 높게 제한할 수 있습니다. 대규모 로드 테스트가 필요하지 않은 Dev 또는 Test 테이블에는 최대값을 적용하는 것이 좋습니다. 모든 테이블에 대해 최대값을 설정할 수 있지만 실수로 제한되지 않도록 프로덕션에서 사용할 때 테이블 기준선에 대해 이 설정을 정기적으로 평가해야 합니다.
목표 사용률
테이블의 목표 사용률을 설정하는 것은 프로비저닝된 용량 테이블에 대한 비용 최적화의 기본 수단입니다. 여기서 백분율 값을 낮게 설정하면 테이블이 오버프로비저닝되는 양이 늘어나 비용이 증가하지만 제한의 위험은 줄어듭니다. 백분율 값을 높게 설정하면 테이블이 오버프로비저닝되는 양이 줄어들지만 제한의 위험은 높아집니다.
테이블 용량 모드를 선택할 때 고려해야 할 추가 요소
두 모드 중 하나를 결정할 때 고려해야 할 몇 가지 추가 요소가 있습니다.
프로비저닝된 용량 사용률
온디맨드 모드의 비용이 프로비저닝된 용량보다 낮은 시기를 확인하려면 할당된(또는 ‘프로비저닝된’) 리소스가 얼마나 효율적으로 사용되고 있는지를 나타내는 프로비저닝된 용량 사용률을 살펴보는 것이 좋습니다. 온디맨드 모드는 프로비저닝된 평균 용량 사용률이 35% 미만인 워크로드에 비해 비용이 저렴합니다. 대부분의 경우 프로비저닝된 용량 사용률이 35%보다 높은 워크로드의 경우에도 특히 워크로드의 활동량이 적을 때가 있고 가끔 피크가 발생하는 경우 온디맨드 모드를 사용하는 것이 비용 효과적일 수 있습니다.
예약 용량
프로비저닝된 용량 테이블의 경우 DynamoDB는 읽기 및 쓰기 용량에 대한 예약 용량을 구매할 수 있는 기능을 제공합니다(복제된 쓰기 용량 단위(rWCU) 및 Standard-IA 테이블은 현재 해당 없음). 예약 용량은 표준 프로비저닝 용량 요금보다 상당한 할인을 제공합니다.
두 테이블 모드 중 하나를 결정할 때는 이러한 추가 할인이 테이블 비용에 얼마나 영향을 미치는지 고려합니다. 대부분의 경우 비교적 예측하기 어려운 워크로드라도 예약 용량이 있는 과다 프로비저닝된 용량 테이블에서 실행하는 것이 더 저렴할 수 있습니다.
워크로드의 예측 가능성 향상
경우에 따라 워크로드에 예측 가능한 패턴과 예측할 수 없는 패턴이 모두 있는 것처럼 보일 수 있습니다. 온디맨드 테이블에서는 이러한 워크로드도 쉽게 지원할 수 있지만, 워크로드에 있는 예측할 수 없는 패턴을 개선할 수 있다면 비용을 더 줄일 수 있을 것입니다.
이러한 패턴의 가장 일반적인 원인 중 하나는 일괄 가져오기입니다. 이러한 유형의 트래픽은 테이블을 실행할 때 제한이 발생할 정도로 테이블의 기준 용량을 초과하는 경우가 많습니다. 프로비저닝된 용량 테이블에서 이와 같은 워크로드를 계속 실행하려면 다음 옵션을 사용해봅니다.
-
예약된 시간에 일괄 처리가 발생하는 경우 실행 전에 Auto Scaling 용량을 늘리도록 예약할 수 있습니다.
-
일괄 처리가 무작위로 발생하는 경우 최대한 빨리 실행하는 대신 실행 시간을 연장하는 것이 좋습니다.
-
가져오기 속도가 처음에는 느린 속도에서 시작해서 Auto Scaling이 테이블 용량 조정을 시작할 수 있을 때까지 몇 분 동안 서서히 오르도록 증가 기간을 가져오기에 추가합니다.