dynamodb 요청량 증가에 따른 처리

scan에 대한 성능

• 데이터 조회시 전체 테이블이나 보조 인덱스를 스캔하는 방식
• 전체 테이블 데이터를 조회하여 필터 조건을 걸어 결과 추출
• 요청한 값을 찾기 위해 항상 전체 테이블을 조회하기 때문에 매우 비효율적
• 때문에 웬만한 경우에는 scan이 아닌 query를 통해 원하는 값을 조회하도록 해야 한다.

급격한 read 요청 증가

• strongly consistent read은 2개의 RCU를 소비한다.
• scan은 기본적으로 eventually consistent read방식으로 데이터를 조회하며, 최대 1MB 용량(페이지)의 데이터 조회 가능
• 따라서 최대 (1MB / 4KB) / 2 = 128개의 RCU를 소비하게 되며 strongly consistent read의 경우 256개의 RCU 소비
• 이렇게 큰 용량으로 조회 작업이 요청되면 사용량이 급증하며 ProvisionedThroughputExceeded 에러가 발생할 가능성이 올라간다.
• 또한, scan은 하나의 파티션에 대해 요청을 하므로 해당 파티션의 RCU를 모두 소비하게 될 수 있으며, 이 경우 해당 파티션에 들어온 다른 조회 요청은 병목 현상을 겪게 된다.
  • 읽기 요청을 여러 파티션으로 분산하여 방지 가능

조회 작업시 RCU 급증이 미치는 영향

ref. 데이터 쿼리 및 스캔 모범 사례

• 위 그림과 같이 사용량이 급증하면 처리량에 영향을 줄 수 있다.

사용량 급증 방지

페이지 크기 축소

• scan은 페이지 단위(1MB)로 데이터를 읽어오므로, 페이지 크기를 축소하여 사용량을 감소시킨다.

scan 요청 격리

• 여러 테이블을 생성하여 데이터를 복제하여 관리
• read용 테이블과 write용 혹은 트래픽이 몰아치는 테이블을 관리하여 scan요청을 격리한다.

 

ref. https://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/bp-query-scan.html