DynamoDB 테이블 용량 조절 구조

DynamoDB 생성 시 결정해야 하는 설정 중 고민하게 되는 부분이 있습니다.

 

• 용량 계산기

-> 평균 항목 크기(KB), 초당 읽기/쓰기 항목 수치, 읽기 일관성과 쓰기 일관성

 

각 용어의 정의부터 정리하고 넘어가겠습니다. 봐도봐도 헷갈립니다.

- 평균 항목 크기 : KB 단위

- 항목 읽기/초 : 항목 읽기/초 * 평균 항목 크기 = 읽기 용량 단위

- 항목 쓰기/초 : 항목 쓰기/초 * 평균 항목 크기 = 쓰기 용량 단위

- 읽기 일관성

   - 최종적 읽기 일관성 : 최근 완료된 쓰기 결과가 반영되지 않을 수 있음. 요청 반복 시 최신 결과 반환

                                (읽기 2번에 단위 1)

   - 강력한 읽기 일관성 : 최근 완료된 쓰기 결과를 반영한 응답 반환.
                                그러나 지연 시간이 더 길 수 있고, 네트워크 상태에 문제가 생기면 사용이 어렵다.

                                (읽기 1번에 단위 1)

   - 트랜잭션 : ACID 보장. 대신 트랜잭션 준비 + 커밋 작업이기에 작업 수가 2개로 늘어난다.
                  이 옵션을 사용할 경우엔 읽기나 쓰기나 1번의 작업을 2번 실행해야 한다고 생각해야 한다.

                  (읽기 1번에 단위 2)

- 쓰기 일관성

   - 표준

   - 트랜잭션 : 위와 동일

 

• 읽기/쓰기 용량 설정 : 용량 모드를 설정(On-demand or Provisioned)

생성한 이후에도 이 설정은 변경 가능합니다. 단, 모드 변경은 24시간에 1번 가능합니다.

On-demand를 사용하면 추가로 설정할 것은 없습니다. 다만, 이 옵션이 진짜로 필요한 만큼 무한정 제공해주는지 뒤져볼 필요가 있습니다.

 

먼저, 처음부터 On-demand로 생성한 테이블은 4,000회의 쓰기와 12,000회의 읽기를 감당할 수 있습니다. 왜냐면 초기 생성 시 테이블이 수용할 수 있는 피크가 쓰기 2,000회와 읽기 6,000회인데, On-demand 테이블은 이전 피크의 2배까지 즉시 수용할 수 있기 때문입니다.

그런데 종종 On-demand 테이블에서 문제가 발생한다는 사례가 있습니다. 여기에서 On-demand가 정말 무한정 제공해주는지에 대한 의문이 생깁니다.

 

결론부터 요약하자면, '즉시 무제한 제공'은 아닙니다. 해당 문제에 대한 링크를 보면, AWS에서 답변한 내용에서 정보를 캐낼 수 있습니다. 해당 답변에서 뽑아낸 정보는 다음과 같습니다.

1. 테이블 트래픽이 이전 피크를 넘어가면 용량이 2배 확장되는데, 이 확장은 30분에 1번 가능합니다. 테이블이 확장을 거친 후 30분 이내로 또 확장을 하려 한다면 문제가 발생한다는 의미입니다.

2. 그런데 트래픽이 이전 피크의 2배를 넘어간다면 확장을 해도 문제가 발생합니다. 확장을 했음에도 필요한 용량에는 모자라는데, 다음 확장은 30분 후에나 발생하니까요. 아무튼 이런 경우 쓰로틀링이 발생할 수 있습니다.

3. 위 링크에서 AWS의 답변은 간단합니다. 해당 트래픽 증가를 분산해서 받으라고 하네요. 말은 쉬운데 기존 피크의 2배가 넘는 트래픽을 예상하고 30분 이상의 간격을 두고 확장하는게 쉬운지는 잘 모르겠습니다.

   -> CloudWatch의 ComsumedReadCapacityUnits 지표를 모니터링하는 것을 권하고 있습니다.

   -> 워크로드의 트래픽을 예상할 수 있다면 Pre-warming 과정을 거치는 것도 좋은 방법입니다.

       (피크를 미리 늘려놓는 방식입니다.)

 

피크치가 2배 늘어난 후 다시 줄어드는지에 대해서는 아직 찾지 못했습니다. 일단 다른 블로그 뒤져보니 확장된 피크치가 유지된다고는 하네요. 

 

위 링크에서 언급된 '트래픽이 파티션당 최대값을 초과하는 경우'에 대해서는 아직 잘 이해가 안가네요.

나중에 다시 봐야겠습니다.

 

 

다음은 '프로비저닝됨'(Provisioned) 모드입니다. 읽기/쓰기 용량을 미리 할당하는 방식으로 관리합니다.

작업 변화량이 급격하지 않거나 워크로드에 필요한 용량을 예상 가능하다면 사용하기 좋겠네요.

이 모드를 사용한다면 읽기/쓰기에 대해 auto scaling 활성화가 가능합니다. 또한 최소/최대 용량 단위를 설정할 수 있습니다.

목표 사용률 : 프로비저닝된 용량 단위에 대한 소비된 용량 단위의 비율

 

목표 사용률을 CloudWatch를 통해 모니터링하고, 초과 시 경보 트리거를 발생시킵니다. 이 경보는 AWS SNS를 통해 알림을 받을 수 있습니다.

어쨌건 CloudWatch로 경보를 받으면 Application Auto Scaling을 호출해 목표 사용률에 근접하게 테이블을 조정하거나 처리 용량을 늘립니다.

 

 

 

• 이 글의 교훈

AWS 문서 뒤지는 것도 좋지만, 못찾겠다 싶으면 AWS 지식 센터에서 뒤져봐야겠습니다. 

고객이 질문한 내용이라 더 자세하고 와닿는 내용들이 많네요.