2. Amazon DynamoDB 개요
• NoSQL 데이터베이스
• 완전 관리형 서비스
• 대용량, 뛰어난 확장성
• 10ms 미만의 빠르고 일관된 성능
• 유연한 데이터 모델 - 문서 및 키-값 스토어
• 세분화된 접근 제어
Amazon
DynamoDB
3. 목차
• AWS 관리형 데이터베이스 서비스
• 데이터 저장소 선택 시 고려사항
• 1단계 : 검토
• 2단계 : 테이블 설계
• 3단계 : 데이터 마이그레이션
• 4단계 : 마이그레이션 이후
• 주요 고려사항
4. AWS 관리형 데이터베이스 서비스
Amazon DynamoDB
• NoSQL
데이터베이스
• 완전 관리형
• 10ms 미만
응답속도
• 대용량, 뛰어난
확장성
• 낮은 비용
Amazon RDS
• 관계형 데이터베이
스
• 완전 관리형
• 예측 가능한 성능
• 빠르고 손쉬운 확장
• 낮은 비용, 사용량에
따른 과금
Amazon Elasticache
• 인-메모리 키-값 저장
소
• 고성능
• Memcached 및 Redis
• 완전 관리형
Amazon Redshift
• 관계형 데이터 웨어하
우스
• 대용량 병렬처리
• 페타-바이트 단위
• 완전 관리형
• HDD 및 SSD 플랫폼
7. 데이터 저장소 선택 시 고려사항
• 데이터 구조 : 고정된 스키마 / JSON / 키-값
• 억세스 방식 : 데이터를 억세스하고자 하는 방식으로 저장
• 데이터 억세스 특징 : Hot / Warm / Cold
• 비용: 적합한 비용
8. 데이터 구조 및 억세스 방식
억세스 방식 저장소
Put/Get (키, 값) 캐시, NoSQL
단순한 관계 → 1:N, M:N NoSQL
테이블 조인, 트랜잭션, SQL SQL
Faceting, 검색 검색
데이터 구조 저장소
고정된 스키마 SQL, NoSQL
스키마 없음(JSON) NoSQL, 검색
키-값 저장소 캐시, NoSQL
9. Hot Warm Cold
규모 MB–GB GB–TB PB
아이템 크기 B–KB KB–MB KB–TB
응답속도 ms ms, sec min, hrs
내구성 Low–High High Very High
요청 비율 Very High High Low
비용/GB $$-$ $-¢¢ ¢
Hot Data Warm Data Cold Data
데이터 억세스 특성 : Hot / Warm / Cold
10. Cache
SQL
요청 비율
높음 낮음
비용/GB
높음 낮음
응답속도
낮음 높음
데이터 규모
낮음 높음
Glacier
구조화
NoSQL
Hot Data Warm Data Cold Data
낮음
높음
Search
적합한 데이터 저장소 선택
11. Amazon
ElastiCache
Amazon
DynamoDB
Amazon
Aurora
Amazon
Elasticsearch
Amazon
EMR (HDFS)
Amazon
S3
Amazon
Glacier
평균 응답속도 ms ms ms, sec ms,sec sec,min,hrs ms,sec,min
(~ size)
hrs
데이터 규모 GB GB–TBs
(no limit)
GB–TB
(64 TB Max)
GB–TB GB–PB
(~nodes)
MB–PB
(no limit)
GB–PB
(no limit)
아이템 크기 B-KB KB
(400 KB max)
KB
(64 KB)
KB
(1 MB max)
MB-GB KB-GB
(5 TB max)
GB
(40 TB max)
요청 비율 높음 -
매우 높음
매우 높음
(no limit)
높음 높음 낮음– 매우 높음 낮음 –
매우 높음
(no limit)
매우 낮음
스토리지 비용
GB/월
$$ ¢¢ ¢¢ ¢¢ ¢ ¢ ¢/10
내구성 낮음 - 보통 매우 높음 매우 높음 높음 높음 매우 높음 매우 높음
Hot Data Warm Data Cold Data
적합한 데이터 저장소 선택
13. DynamoDB - 기본 키 (파티션 키)
파티션 키 (Partition Key)
데이터의 분산 / 데이터 모델 단순 /
비정렬 / 동일값 조회
14. 기본 키 (파티션 키 및 정렬 키)
파티션 키
정렬 키 (Sort Key)
데이터 모델 복합/
정렬 / 범위 값 조회
15. 1단계: 검토 – 성능 / 확장성 / 가용성 / 보안
• 모든 규모에서 낮은 응답 속도(Single digit milli-second) 제공
• 데이터 규모 및 요청 수에 따른 성능 영향 없음
쓰기
디스크 영구 저장 (커스텀 SSD)
읽기
강한 또는 최종 일관성
응답속도 저하 없음
16. 1단계: 검토 – 성능 / 확장성 / 가용성 / 보안
• 각 테이블의 읽기 쓰기 대역폭 용량을 지정
- RCU (Read Capacity Units) : 4 KB per second
- WCU (Write Capacity Units) : 1 KB per second
• 필요에 따라 대역폭 용량을 제한 없이 확장 및 축소
• 스토리지 용량 제한 없이 데이터 저장에 따라 확장
• DynamoDB가 모든 내부 작업을 관리
17. 1단계: 검토 – DynamoDB 파티션
00 55 A954 AA FF00 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
• DynamoDB 테이블은 확장성을 위하여 내부적으로 다수의 파티션 관리
• 스토리지 용량 및 쓰루풋 증가에 따라 파티션 증가
• 파티션 키는 해시 값에 따라 파티션 간 아이템 분산에 사용
18. 1단계: 검토 – DynamoDB 파티션 계산
• 초기 파티션 수 계산 공식 :
• 예 : 10,000 읽기 용량 단위와 5,000 쓰기 용량 단위
• 이후, 스토리지 용량 및 쓰루풋 증가에 따라 파티션 자동 증가
( readCapacityUnits / 3,000 ) + ( writeCapacityUnits / 1,000 ) = initialPartitions (rounded up)
( 10,000 / 3,000 ) + ( 5,000 / 1,000 ) = 9 (8.33.. rounded up)
19. 1단계: 검토 – 성능 / 확장성 / 가용성 / 보안
• 높은 가용성과 안정성을 실현하기 위해 Amazon DynamoDB는 AWS
리전의 세 개 시설에 걸쳐 데이터를 동기적으로 복제
20. 1단계: 검토 – 성능 / 확장성 / 가용성 / 보안
• DynamoDB 자원에 대한 개별 사용자 접근 제어
• 항목 및 속성 수준까지
• AWS IAM(Identity and Access Management)과 통합
• 중앙화된 관리
• 3rd 파티 인증과 통합을 위한 Web Identity Federation
22. 1단계: 검토 – 비용 (Lessons Learned)
• 인스턴스 기반의 NoSQL
• 3 복제 및 운영(Compaction, Backup, Temp 등)에 따른 스토리지 용량 소요
• 데이터 증가에 따라 인스턴스 추가
• 인스턴스 최적화 여지
• DynamoDB
• Provisioned Throughput의 %사용률 고려 (100% 사용율 어려움)
• Item 크기에 따른 WCU / RCU 소모 고려
• Eventual Consistency Read 시 Throughput 50% 소모
• Reserved Capacity 통한 비용절감 고려
23. 2단계: 테이블 설계
• 모범 사례 :
http://docs.aws.amazon.com/amazondynamodb/latest/developergui
de/GuidelinesForTables.html
• 테이블의 프로비저닝된 처리량을 최적으로 사용하려면 다음
요소가 중요 :
• 기본 키 선택
• 개별 아이템의 워크로드 패턴
• 테이블에 대해 프로비저닝한 전체 요청 처리량을 달성하려면
워크로드가 파티션 키 값에 고르게 분산되도록 유지
24. 2단계: 테이블 설계 – 기본 키 선택
• 파티션 키의 고유한 값의 갯수가 많은 속성을 파티션 키로 선택
• 좋은 예 : 사용자 ID, 애플리케이션의 사용자가 많은 경우
• 나쁜 예 : 상태 코드, 가능한 상태 코드가 몇 개 없는 경우
00:0 FF:∞
Hash (2) = 48
ID = 2
Order# = 10
Item = Pen
ID = 2
Order# = 11
Item = Shoes
ID = 1
Order# = 10
Item = Toy
ID = 1
Order# = 11
Item = Boots
Hash (1) = 7B
ID = 3
Order# = 10
Item = Book
ID = 3
Order# = 11
Item = Paper
Hash (3) = CD
55 A9:∞54:∞ AA
Partition 1 Partition 2 Partition 3
Id = 1
Order# = 10
Item = Toy
Hash (1) = 7B
Id = 2
Order# = 10
Item = Pen
Hash (2) = 48
Id = 3
Order# = 10
Item = Book
Hash (3) = CD
Key Space
25. 2단계: 테이블 설계 – 기본 키 선택
• 파티션 키의 고유한 값의 갯수가 많지 않은 경우
• 팁1 : 복합 키(Composite Key) 만들기
Composite key : 사용자 아이디 + 어플리케이션 아이디 + 레코드 아이디
Partition key Sort key Attributes
…
…
…
…
Num (user accounts) = ~20M
Random number guid /w 10 digits
Email / contacts / message
Unique values per service
Unique values
/w >10 digits
26. 2단계: 테이블 설계 – 기본 키 선택
• 팁2 : 임의(Random) 또는 계산된 값(Calculated Value) 더하여 쓰기
분산
• Write Sharding 또는 Scatter & Gather 아키텍처
Partition key : 2014-07-09.N(여기서 N은 1 -200)
Partition key Sort key Attributes
…
…
…
…
날짜는 값의 갯수는
많으나
특정 파티션에 워크로드
집중
임의 또는 계산된 값을 추가
복수 파티션에 워크로드 분산
27. 3단계: 데이터 마이그레이션
• DynamoDB 내보내기(Export) 및 가져오기(Import) 기능 활용
• 가져오기 성능 향상 : EMR 클러스터 인스턴스 타입 및 크기,
DynamoDB Provisioned WCU 및 write throughput ratio
DynamoDB
Table
Amazon S3
bucket
Amazon EMR
Cluster
AWS Data
Pipeline
RDS
instance
Generic
Database
NoSQL
Database
JSON
3. Load Files 4. Write Items
2. Launch Cluster
1. Export to JSON
DynamoDB 가져오기(Import)
28. 3단계: 데이터 마이그레이션
• 온라인 마이그레이션을 위한 아키텍처 예:
user storage path
User A <path_to_cassandra>
User B <path_to_dynamodb>
Cassandra
Cluster
DynamoDB
App servers
Mobile
Clients
Storage
path db
User
A
User
B
Normal data flow
for migrated
users
Normal data flow
for not migrated
users
Migration servers
Migration data
flow
29. 3단계: 데이터 마이그레이션
• 파티션 키의 설계 또는 파티션 간 쓰기 부하 분산이 잘못된 경우
• Provisioned Throuput 대비 Consumed Throughput이 낮으며,
Throttling이 발생
Provisioned Write Capacity
Average Consumed Write Capacity
Throttled Write Requests
30. 3단계: 데이터 마이그레이션
UerID MessageID
U1 1
U1 2
U1 …
U1 … 최대 100
U2 1
U2 2
U2 …
U2 … 최대 100
• 데이터 업로드 중 파티션 간 쓰기 부하 분산
파티션 키 정렬 키
쓰기시퀀스
- 워크로드가 분산되지 않은 시퀀스 -
UerID MessageID
U1 1
U2 1
U3 1
… …
U1 2
U2 2
U3 2
… …
파티션 키 정렬 키
쓰기시퀀스 - 워크로드가 분산된 시퀀스 -
31. 4단계: 마이그레이션 이후
Partition #1
Partition #2
Partition #3
…
Partition
#1,000
Partition #1
Partition #2
Partition #3
…
Partition
#1,000
Partition #1
Create table
Migration After
Increase WCU
to 1,000K
Decrease WCU
to 100K
1,000 WCU
per partition
X
1,000 partitions
100 WCU
per partition
X
1,000 partitions
1/10 per partition
WCU
• 대용량 쓰루풋 Provisioned 후, 마이그레이션 이후 Normal 쓰루풋
감소
• 파티션은 증가하나 감소하지 않음에 따라 파티션 당 쓰루풋 감소
- Diluted Partition 피할 것
32. 주요 고려사항
데이터 저장소 선택 시 고려사항
1. 데이터 구조, 억세스 방식, 데이터 억세스 특징을 고려하여 DynamoDB가
적합한 데이터 저장소인지 검토
1단계 : 검토
1. 성능 : DynamoDB는 모든 규모에서 한자리수 ms의 성능 제공
2. 확장성 : 파티션 확장을 통하여 무제한의 스토리지 공간 및 대역폭 성능
제공
3. 가용성 : 리전 내 3개 설비에 데이터 동기화 저장
4. 보안 : Fine Grained Access Control
33. 주요 고려사항
1단계 : 검토 (계속)
5. 비용
• 기존 NoSQL은 복제 및 인스턴스 운영, 데이터 증가에 따라 인스턴스 최적화 여지
있음
• Provisioned Throughput의 %사용률 고려
• Item 크기에 따른 WCU / RCU 소모 고려
• Eventual Consistency Read 시 Throughput 50% 소모
• Reserved Capacity 통한 비용절감 고려 - 1년 계약의 경우 최대 53%, 3년 계약의 경우
최대 76%까지 절감
6. 벤치마크
• 벤치마크 툴이 부하를 잘 분산하여 요청하는지 확인 필요
(예: YCSB의 request distribution을 zipfian -> uniform)
34. 주요 고려사항
2단계 : 테이블 설계
1. 파티션 키의 고유한 값의 갯수가 많은 속성을 파티션 키로 선택
2. 복합 키(Composite Key) 만들기
3. 임의(Random) 또는 계산된 값(Calculated Value) 더하여 쓰기 분산하
는 Write Sharding 또는 Scatter & Gather 아키텍처 고려
4. 테이블에 대해 프로비저닝한 전체 요청 처리량을 달성하려면
워크로드가 파티션 키 값에 고르게 분산되도록 유지
3단계 : 데이터 마이그레이션
1. DynamoDB 가져오기(Import) 기능 활용
35. 주요 고려사항
3단계 : 데이터 마이그레이션 (계속)
2. 가져오기 성능 향상을 위하여 EMR 클러스터 인스턴스 타입 및 크기,
DynamoDB write throughput ratio 및 Provisioned WCU 조정
3. 온라인 마이그레이션을 위하여는 Storage path DB를 관리하는 전체
어플리케이션 아키텍처 고려
4. 데이터 업로드 중 파티션 간 쓰기 부하 분산하는 쓰기 시퀀스 고려
4단계 : 마이그레이션 이후
1. Diluted Partition 피할 것
36. Online Labs & Training
Gain confidence and hands-on
experience with AWS.
Watch free Instructional Videos
and explore Self-Paced Labs
Instructor Led Classes
Learn how to design, deploy and
operate highly available, cost-
effective and secure applications
on AWS in courses led by qualified
AWS instructors
Validate your technical
expertise with AWS and use
practice exams to help you
prepare for AWS Certification
AWS Certification
More info at http://aws.amazon.com/training
37. Thank You for Attending AWS Innovate
We hope you found it interesting!
Do provide us with your feedback for the session and complete the feedback form.
Let us know your thoughts of today’s event and how we can improve the event
experience for you in the future.