AWSKRUG 2016년 10월 정기 밋업 정민영

1. DynamoDB의 안과 밖
정민영
AWSKRUG

2. DynamoDB의 바깥

3. Amazon DynamoDB는 완벽하게 관리되는
NoSQL 데이터베이스 서비스로, 원활한 확장성과
함께 빠르고 예측 가능한 성능을 제공합니다.
DynamoDB는 분산 데이터베이스를 운영하고 조정
하는 데 따른 관리 부담을 줄이며, 따라서 하드웨어
프로비저닝, 설정 및 구성, 복제, 소프트웨어 패치 또
는 클러스터 조정에 대해 걱정할 필요가 없습니다

4. DynamoDB는 테이블의 데이터와 트래픽을 충분한 수
의 서버로 자동 분산하여 처리량 및 스토리지 요구 사
항을 처리하면서도 일관되고 빠른 성능을 유지합니다.
모든 데이터가 SSD(Solid State Disk)에 저장되고
AWS 리전의 여러 가용 영역에 걸쳐 자동 복제되기 때
문에 확실한 고가용성과 데이터 내구성을 보입니다.

5. 안 쓸 수 없는 DDB

6. • 관리형이면서
• 성능을 예측하여 설계할 수 있고
• 일관된 성능을 보장하는데
• 고가용성과 내구성까지?

7. 인생이 그렇게 쉬울리가

8. DynamoDB에 관한
가장 흔한 질문

9. 왜 돈낸만큼
성능이 나오지 않나요?

10. 왜 처리량에 여유가 있는데
쓰로팅이 발생하나요?

11. DDB의 특징에 대한
바른 이해?

12. • DDB는 고유의 특징과 제약을 동시에 지님
• 특히 일관된 성능(=Latency)를 제공하는데 주력
• ex) 성능 지연 대신 요청 거부(Throttling)

13. DDB의 가장 큰 장점
DDB 특징/제약의 원흉

14. 일관된 성능 제공

16. ??

17. 일관된 성능을 제공하기 위한
DDB의 안쪽

18. Throughput

19. • 테이블의 읽기(RCU)와 쓰기(WCU)에 원하는 만큼
의 처리량을 설정
• RCU와 WCU는 각기 독립적으로 설정
• 1 WCU = 1KB/sec
• 1 RCU = 4KB/sec **

20. • DDB는 항목의 일관성에 대하여 2가지 옵션을 제공.
• Strongly vs Eventually
• 1 RCU는 최대 4KB의 항목에 대하여, Strongly 조건으
로 1/sec, Eventually 조건으로 2/sec
• ex) 6KB 항목에 대해서 100회 읽기를 Strongly/
Eventually 각 수행할 경우 필요 RCU
• Ceiling(6KB/4KB) * 100 = 2 * 1 * 100 = 200
• Ceiling(6KB/4KB) / 2 * 100 = 2 / 2 * 100 = 100

21. 파티셔닝

22. • DDB는 일관된 성능을 제공하기 위해 한 테이블을 여러개의 파
티션으로 분산
• 파티션의 갯수는 Throughput과 테이블의 크기로 결정
• 어떤 항목이 어떤 파티션에 저장될지는 분산키(Hash Key)에
의해 결정
• 파티션의 갯수를 결정하는 공식
• MAX((RCU/3000+WCU/1000), Table Size(GB)/10GB)
• MAX((5000/3000+500/1000), 8/10) = MAX(3, 1) = 3

23. 00 55 A954 AA FF
Hash table
• Hash key uniquely identifies an item
• Hash key is used for building an unordered hash index
• Table can be partitioned for scale
00 FF
Id = 1
Name = Jim
Hash (1) = 7B
Id = 2
Name = Andy
Dept = Engg
Hash (2) = 48
Id = 3
Name = Kim
Dept = Ops
Hash (3) = CD
Key Space

24. 그렇다면….
• 매우 고르게 분포하는 분산키를 사용하고 (Uniform
distribution Hash key)
• 적절한 처리량을 설정하면 아무 문제 없겠구나!

26. DDB의 함정

27. 1. 설정한 Throughput은
모든 파티션에 균등 분배된다

28. 읽기와 쓰기에서 분산키의
인기도가 다를 수 있음
(Hot Key)

29. Example: hot keysPartition
Time
Heat

30. 2. 한번 증가한 파티션
은 줄어들지 않는다

31. Throughput
확장의 고민요소

32. = 파티션당 RCU/WCU
는 갈수록 줄어들 수 있음

33. RCU/WCU가 여유 있는
데 쓰로팅 발생의 주 원인

34. Throughput을 무조건
늘리는 대응의 위험성

35. 3. LSI는 테이블의
WCU를 소모한다

36. 평균 항목 크기 계산에
서 흔히 놓치는 지점

37. 사용되지 않는
Throughput은 저장된다
고 들었는데요?

38. Burst capacity is built-in
0
400
800
1200
1600
CapacityUnits
Time
Provisioned Consumed
“Save up” unused capacity
Consume saved up capacity
Burst capacity: 300 seconds
(1200 × 300 = 3600 CU)

39. Burst capacity may not be sufficient
0
400
800
1200
1600
CapacityUnits
Time
Provisioned Consumed Attempted
Burst capacity: 300 seconds
(1200 × 300 = 3600 CU)
Throttled requests
Don’t completely depend on burst capacity… provision sufficient throughput

40. 하지만 이것도
전부 파티션 단위

41. 제발 패치좀….
• DDB의 Throughput은 테이블 단위로 설정하지만*
파티션에 균등 분배됨. 즉 사실상 Throughput은 파
티션 단위의 설정.
• 별도의 요청 없이는 파티션 상황을 추적하기 어려워
Throughput 설계에 어려움이 많음
• Throughput 감소가 4회/24시간 제약
• * GSI제외

42. 그럼에도 불구하고….

43. 장점도 뚜렷한 DDB

44. • Latency를 일정하게 낮게 관리할 수 있는건 매우 큰
장점
• 저장 용량에 신경쓰지 않고 이용 가능
• Rich한 자료형 지원으로 복잡한 고급 기능 처리 가능

45. 나름의 BP들

46. 테이블 관리
• 명백하게 인기 있는 항목(Hot)과 덜 인기 있는 항목
(Cold)을 분리할 수 있다면, 테이블을 분리
• ex) 시계열 데이터의 경우 연-월 혹은 연-월-일 단
위의 테이블 분리
• 과거 테이블의 경우 쓰기 혹은 읽기가 발생하지 않
을 수 있어 비용 절감
• Index에 모든 Attribute를 포함시키지 않고 LSI 보다
GSI로 대체

47. 50% 이상 버퍼

48. https://github.com/sebdah/dynamic-dynamodb

49. DynamoDB Stream
• DDB에서 Scan은 매우 비싸고 Query도 Get에 비하
면 상대적으로 고 비용
• 키 혹은 내용 검색을 위해서 DDB Stream과
ElasticSearch를 연계해서 이용하는 방법 고려
• 테이블을 분산시키는 경우등에도 유용

50. Q&A

51. Reference
• http://www.slideshare.net/
AmazonWebServices/deep-dive-amazon-
dynamodb
• http://www.slideshare.net/
AmazonWebServices/deep-dive-on-amazon-
dynamodb
• https://docs.aws.amazon.com/ko_kr/
amazondynamodb/latest/developerguide/
Introduction.html