사건 개요
goad 트래픽 테스트 도중에
Lambda Concurrency 5,000개 증가로 해결될 줄 알았겠지만
4,000개 데이터를 동시에 쿼리로 입력했을 때 Throttling 현상이 일어났다.
⚠️ WCU (쓰기 단위) 최소 값을 100으로 설정했음에도 100 미만의 구간에서 쓰로틀링 현상이 일어났다.
원인 분석
'핫 파티션' 때문이다.
DynamoDB 테이블의 각 파티션은 쓰기 용량 유닛 1,000개와 읽기 용량 유닛 3,000개로 하드 제한이 적용됩니다.
워크로드가 파티션에 고르게 분산되어 있지 않거나 워크로드가 짧은 시간에 높은 사용량을 기록할 경우(읽기 또는 쓰기 작업 급증) 테이블이 스로틀될 수 있습니다.-AWS-
4,000개 요청이 모두 한 테이블의 같은 파티션으로 put 요청을 하는 것이 원인이었다.
갑자기 많은 요청이 집중되는 파티션을 '핫 파티션' 이라 한다.
핫 파티션이 발생하지 않도록 파티션 키를 고르게 분배해야 좋은 DB 설계라고 할 수 있다.
나같은 경우 2021-03-10T16:40:02 같은 식의 datetime 으로 파티션키를 설정했는데
같은 시각 (1초) 단위에 많은 사람이 채팅을 치거나 쓰기 요청을하면 해당 파티션키가 '핫 파티션'키가 되어 쓰로틀링 현상의 원인이 되었다.
해결 방안
Sharding
2021-03-10T16:40:02 연-월-일T시:분:초 뒤에 1~100 사이의 난수를 추가로 붙여서 처리하는 것이다.
그럼 같은 시점의 요청이 들어와도 파티션을 100개로 더 나눌 수 있다.
물론, 추후 해당 시각의 데이터를 조회하기 위해선 1
00번의 쿼리 요청이 필요하게된다. (DynamoDB는 쿼리시 파티션키를 equal (==) 연산으로 명시해줘야한다.)
=> 1, 2, 3....100 개 쿼리 후 결과 병합 리턴
주의!
파티션키는 해시값으로 자동 인덱싱 되기 때문에
(1) 너무 많이 나눌 경우 -> 조회 쿼리 (query) 를 날리기 까다로워지고, 쿼리 횟수도 증가한다. + 과도하게 많은 파티션 키가 존재하면 쿼리 소요시간이 증가할 위험이 있다.
(2) 너무 적게할 경우 -> 핫 파티션 키 발생 + 쓰로틀링 발생 + "쿼리 결과를 다 받아오지 못할" 위험이 생긴다.
Query작업에서 반환된 결과의 최대 크기는 1 MB입니다. 여기에는 반환된 모든 항목의 속성 이름 및 값의 크기가 포함됩니다.-AWS-
이말인 즉슨 한번의 파티션키 쿼리로 받아올 데이터의 양은 1MB 로 제한되어있다.
∴ 한 파티션당 기록할 데이터의 크기를 고려해서 설계해야한다.
Reference
