LG 이노텍 - Amazon Redshift Serverless를 활용한 데이터 분석 플랫폼 혁신 과정 - 발표자: 유재상 선임, LG이노...
[Retail & CPG Day 2019] Amazon.com의 무중단, 대용량 DB패턴과 국내사례 (Lotte e-commerce) - 황경태, AWS 솔루션즈 아키텍트, 신봉기, 롯데 이커머스 DB 엔지니어
1. Amazon.com의
무중단, 대용량 DB 패턴과 국내사
례
1
황경태
솔루션즈 아키텍트
아마존 웹 서비스
신봉기
DB Engineer
Lotte e-commerce/Tech
2. Agenda
모던 어플리케이션 요구사항
Amazon.com의 대규모 이벤트의 규모와 인프라
대규모 무제한의 비정형 데이터베이스(DynamoDB)
Items and Offers Plaform의 DyanmoDB 마이그레이션
고객의 AWS 프로젝트를 가속하는 Data Lab 프로그램
국내 사례 (롯데 e커머스)
2
3. 모던 어플리케이션의 요구사항
사용자 1백만+
데이터 양 TB, PB, EB
데이터 위치 Global
성능 Milliseconds, microseconds
요청량 Millions
접근방식 Mobile, IoT, devices
스케일링 Up and down
비용 방식 Pay as you go
개발자 접근방식 Instant API access
Relational Key-value Document
In-memory Graph
4. 인터넷 스케일의 온라인 커머스
4
세계 최대의 전자 상거래 비즈니스
중 하나인 Amazon.com은 규모,
성능 및 유지관리 이점으로 인해
비관계형 클라우드 데이터베이스
에서 실행됩니다
— Werner Vogels
CTO, Amazon
”A deep dive on how we were using our existing databases revealed that they
were frequently not used for their relational capabilities”
5. 아마존 2019년 프라임데이
5
DynamoDB
초당 4천540만(최고)
총 7조1001억
AURORA
1,900개 DB인스턴스
1,480억 트랜잭션
컴퓨팅 인프라
서버 372,000 ~ 426,000
데이터전송: 185PB
https://aws.amazon.com/ko/blogs/korea/amazon-prime-day-2019-powered-by-aws/
426,000
45,000,000
7,100,100,000,000
1,900
48hr
Alexa, Amazon.com 및 442개의 아마
존 fulfillment 센터 포함한 온/오프라
인 시스템의대용량 트래픽을 지원
6. Amazon DynamoDB
규모에 제한 없는 Fully Managed 비관계형 클라우드 데이터베이
스
빠르고 일관된 성능
사실상의 무제한 처리량
사실상의 무제한 저장공간
전송중 및 저장시 암호화
Fine-grained 접근 제어
PCI, HIPAA, FIPS140-2 준수
Service-level agreement
유지보수 불필요
서버리스(Serverless)
Auto scaling
백업 및 복원
글로벌 테이블
7. 주요 개념: 테이블, 아이템, 인덱
스
• 파티션키(Partition Key) 또는 Hash Key : 데이터 분산 결정
• 정렬키(Sort Key): 쿼리 다양화
테이블
속성1 속성2 속성3 속성4
속성1
속성1
속성1
속성2
속성2 속성3
속성3
아이템
파티션키 정렬키
Read Capacity Unit(RCU), Write Capacity Unit(WCU) 범위 GSI의 RCU, WCU 범위
• RCU: 테이블 또는 GSI의 초대 최대 읽기 Unit 개수
• WCU: 테이블 또는 GSI의 초당 최대 쓰기 Unit 개수
로컬 보조 인덱스(LSI)
속성1 속성3 속성4
속성1
속성1 속성3
속성3
파티션키 정렬키 Projected
속성
글로벌 보조 인덱스(GSI)
속성2 속성3 속성4
속성2
속성2 속성3
파티션키 정렬키 Projected
속성
8. 주요 개념: 파티션을 통한 데이터
분산
ID = 1
Name = 홍길동
Hash(1) = 78
ID = 2
Name = 이순신
Role = Dev
Hash(2) = 48
ID = 3
Name = 정도전
Dept = AI
Hash(3) = CO
아이템
파티션1 파티션2 파티션3
키 스페이스
00 FF
Replica 1
파티션1
Replica 2
파티션2
파티션3
파티션1
Replica 3
파티션2
파티션3
3 방향 복제
테이블
9. Storage NodeStorage Node Storage Node
주요 개념: 고 가용성 아키텍처
HTTP(S) End
point
Frontend Frontend Frontend
DC 1 DC 2 DC 3
Storage Node Storage Node Storage Node
10. 주요 개념: DynamoDB 스트림스
테이블의 변경사항에 대해 이벤트가 발생하며 다양한 방식의 처리 지원
파티션 A
파티션 B
파티션 C
변경된 항목의 순서 보장
정확히 한번만 전달, 키 기
준으로 엄격한 순서 유지
고 내구성, 확장성
24 시간 보관
1초 미만 전달
TTL 만기 이벤트
Kinesis 클라이언트 라이브
러리 호환
DynamoDB 스트림스
1
2
3
추가,변경,삭
제, TTL 만기
이벤트
KCL
Worker
Kinesis Client
Library
KCL
Worker
KCL
Worker
DynamoDB Table Shards
Lambda
Consumers
11. 관계형과 비관계형DB의 스케일링 방식
전통적인 SQL NoSQL
DB
DB
Scale up
DB
host1
DB
hostn
DB
host2
DB
host3
복수개의 샤드 Scale out
(DynamoDB: 파티션)
12. DynamoDB의 유통 유스케이스
Use cases DynamoDB 기능
고객 프로파일
장바구니
워크플로우 엔진
주문
리뷰
DynamoDB 테이블
로컬보조인텍스/글로벌보조인덱스
DynamoDB 스트림스
AWS Lambda를 통한 연계: Amazon Redshift, Amazon
Elasticsearch Service, Amazon S3
프로모션, 특가/쿠폰
즉시 적응형 용량(Adaptive capacity)
Auto scaling
DAX
Global tables
Payments (credit cards) 저장시 암호화, VPC 엔드포인트
14. Item Master Service (IMS)
Blob 스토어 4
인덱스 테이블 7
데이터베이스 24
파티셔닝 Hash
논리적 파티션 256
레코드 건수 ~6,000억
일 갱신 건수 ~50 억/일
24 Oracle Databases
Sellers
Updates Publish
…..
Website
Oracle DB instance Oracle DB instance Oracle DB instance Oracle DB instance
15. IOP가 직면하였던 이슈
참고 https://aws.amazon.com/ko/blogs/korea/migration-complete-amazons-consumer-business-just-turned-off-its-final-oracle-database/ 또는 https://amzn.to/35ES26A
16. Read-modify-write 동시 수행
판매자의 변경사항 적용을 위한 지속적인
카탈로그 업데이트
다양한 최대 부하량 및 I/O 요구사항을
만족하는 글로벌 서비스
가변적인 데이터베이스 워크로드
왜 Amazon DynamoDB 인가?
높은 처리량의 벌크 액세스
17. COLUMN NAME TYPE Details
CUSTOMER_ID NUMBER Primary key
SKU VARCHAR2
DOMAIN_ID NUMBER
ITEM_ID VARCHAR2
IS_TOMBSTONED CHAR Active/Inactive
CREATED_BY VARCHAR2 Audit Info
CREATION_DATE DATE
LAST_UPDATED_BY VARCHAR2
LAST_UPDATED_DATE DATE
예시: 오라클 스키마용 index 테이
블SKU to ASIN 맵핑
18. Attribute Details
hash_key Partition key
range_key Sort Key
is_tombstoned Active/Inactive
last_updated_by Audit Info
last_updated_date Audit Info
version Version of the record
예시: DynamoDB의 index 테이블
SKU to ASIN 맵핑
19. 마이그레이션 방안
Item Master Se
rvice
Oracle Datab
ase
애플리케이션의 지속성 계층에서 Oracle, DynamoDB
중 한쪽 또는 양쪽에 읽거나 쓰는 다양한 마이그레이
션 방식을 지원하도록 업데이트 하였음
Oracle Datab
ase
AWS DMS의 객체 매핑 템플릿으로 Oracle 데이터
가 대상 형식으로 변환되고, 조건부 PUT 방식으
로 DynamoDB에 기록 됨
20. Live Migration
어플리케이션을 통해 다양한 방식으로 데이터를 이동
Item Mast
er Service
Oracle Da
tabase
Write
Write
Read
Item Mast
er Service
Oracle Da
tabase
Write
Write
Read
Read
Dest is based o
n lookup store
Item Mast
er Service
Oracle Da
tabase
Write
Read
Read
21. Backfill 마이그레이션 & DMS 스케일링
Run multiple replication tasks per table
테이블 당
논리적 파티션 개수
256
DMS 인스턴스 당 마
이그레이션 성능
3K - 5K TPS
테이블당
마이그레이션 성능
30K - 100K TPS
전체 테이블
마이그레이션 성능
100K – 150K TPS
레코드 건수 ~ 6000 억
전체 데이터 사이즈 ~ 150 TB
AWS DMS
replication
instance
AWS DMS
replication
instance
AWS DMS
replication
instance
Oracle
Database
Oracle
Database
Oracle
Database
22. 마이그레이션 결과
가용성 10배 향상
운영 업무 90% 감소
어플리케이션 수평적 확장 가능
지속성 계층 단순화
다른 AWS 서비스와 손쉬운 통합
22
23. Data Lab 프로그램
23
데이터 마이그레이션
데이터 레이크 구축
예지 분석
마이크로서비스 배포
성능 최적화
3-4 일간 시애틀 온사이트
솔루션 설계
고객 환경에서 구축
AWS 전문가와 함께 작업
기능 검증
Data Lab 아키텍트
솔루션즈 아키텍트(2)
DBS 프로그램 매니져
DBS 엔지니어
DBS Specialist SA’s
4-8 고객 엔지니어
Data Lab은 고객과 AWS간의 상호노력으로 고객의 대규모 프로젝트 배포를 가속화 할 수 있는 결과물을
생성하기 위해 AWS 전문가와 고객엔지니어가 4일동안 협력합니다. 이후에도 프로젝트가 성공적으로 구
현될 때까지 의사소통을 유지합니다.
24. 참고 - Amazon 사례
Items & Offers
https://aws.amazon.com/solutions/case-studies/itemsandoffers/
Prime Video
https://aws.amazon.com/solutions/case-studies/prime_video_dynamoDB
Advertising
https://aws.amazon.com/solutions/case-studies/Amazonadvertising
Amazon Fulfillment
https://aws.amazon.com/solutions/case-studies/amazon-fulfillment-aurora/
Analytics
https://aws.amazon.com/solutions/case-studies/amazon-migration-analytics/
Amazon Database Migration
https://aws.amazon.com/solutions/case-studies/amazon-database-migration/
24
26. 목 차
26
1. Lotte ON 프로젝트
2. IT 서비스 변화
3. 데이터 저장소 검토
4. DynamoDB Modeling
5. 트랜잭션 처리
6. 서비스간 데이터 동기화
7. 모니터링
8. 질문하며 정리하기
27. Lotte ON
27
롯데 온라인 6개 서비스를 통합하여 고객에게 높은 가치의 상품과 서비스를 빠르게 제공
Lotte
ON
• 라이프 스타일 맞춤 제안
• 상품 경쟁력 강화
• 온/오프 통합 시너지 창출
• 데이터 기반 업무 혁신
• 물류 최적화
28. IT 서비스 변화
28
• 서비스의 변화
많은 상품 제공
품질 높은 상품 정보 제공
다양한 서비스 제공
• IT 운영 환경의 변화
데이터 량 증가
대량 / 스파이크성 트래픽 발생
Application 복잡도 증가
Test 복잡도 증가
MSA 개발 방법론 검토
NoSQL 도입 검토
29. 데이터도 서비스 처럼
29
• OLTP / OLAP
하나의 DBMS를 여러 목적으로 사용할 경우 세션간 간섭에 의해 Waiting, Down 발생 위험 존재
대용량 데이터 관리 부담 발생
기능의 목적에 맞게 데이터 서비스를 제공
데이터 적재 layer 적용 대상 서비스 유형
Tier 1 대고객 대용량 트래픽 수용, 빠른고 일관된 응답속도
Tier 2 내부 서비스, 배치 다양한 목적의 Query, 평균응답속도
OLAP 분석 대용량 쿼리, 낮은응답속도
Data Lake 데이터 공유
30. 데이터 저장소 검토
30
비 기능적 요구 사항을 파악하여 적합한 데이터 저장소를 선정
Requests
Latency
Security
Scalablity
Stability
Data Size
Useability(join..)
Backup/Recovery
OLAP …….
Aurora
(MySQL5.7)
Redis ElasticSearch DynamoDB
S3
(Athena)….
etc
기준은 각 서비스마다 상이
예) Requests
전시
상 100,000/s ~
중 50,000 ~ 100,000/s
하 40,000 ~ 50,000/s
상품평
상 5,000/s ~
중 3,000 ~ 5,000/s
하 1,000 ~ 3,000/s
34. DynamoDB Modeling
34
응모 이벤트(example)
• 좋아하는 상품에 태깅
• 특정 하나의 상품에 동시에 많은 사람들이 응모 가능
• 당첨자 리스트를 웹에 게시하고 선물 증정
Primary Key 일반속성
Hash_key Sort_key GSI_01_HK GSI_01_SK GSI_02_HK GSI_02_SK 당첨자(Map Type) 기타 속성 리스트
1
이벤트 번호 이벤트기본 이벤트 번호 당첨자
이벤트명, 일자, 등등
EVT_001 BASE EVT_001
{"1":"MEM_09"},{"2":"
MEM_01"}…
2
이벤트번호^상품번호^랜덤 응모일시+고객번호 고객번호 응모일시 이벤트 번호
당첨등수, 당첨일시
EVT_001^PD_01^random_1 2017-10-16_10:30:50+MEM_01 MEM_01 2017-10-16_10:30:50 EVT_001
3
이벤트번호^상품번호^랜덤 응모일시+고객번호 고객번호 응모일시 이벤트 번호
EVT_001^PD_01^random_9 2017-10-16_10:30:50+MEM_02 MEM_02 2017-10-16_10:30:50 EVT_001
4
이벤트번호^상품번호^랜덤 응모일시+고객번호 고객번호 응모일시 이벤트 번호
EVT_001^PD_01^random_2 2017-10-16_10:30:50+MEM_03 MEM_03 2017-10-16_10:30:50 EVT_001
5
이벤트번호^상품번호^랜덤 응모일시+고객번호 고객번호 응모일시 이벤트 번호
EVT_001^PD_01^random_1 2017-10-16_10:30:50+MEM_04 MEM_04 2017-10-16_10:30:50 EVT_001
Partition key 분산 : workload 분산
당첨자 조회 비용 절감
35. 트랜잭션 처리
35
• DynamoDB Transaction
• Step Function
워크플로우 로직을 쉽게 구현
병렬처리 가능
오류발생시 Rollback 등 예외처리 구현이 용이
타 MSA 모듈간의 Transaction 처리 용이(이기종 DBMS)
• 활용 예)
Step Function 구현 예시
주문접수 재고차감 결제처리
선물메시지
마케팅처리
주문생성
36. Queue
서비스간 데이터 동기화
36
• ETL(Extract, Transform, Load)
• Lambda Function
• CEP(Complex Event Processing)
Event 유형에 맞는 데이터 처리 프로세싱 모듈 (복제, 로깅)
Event를 Parsing하고 Queue를 통해 데이터를 처리
∙ DynamoDB : Stream
∙ RDBMS : Annotation
CEP
Queue
Queue
Consumer
Table
준 실시간
이벤트
37. DynamoDB 모니터링
37
CloudWatch → ElasticSearch → Grafana
사용기술
∙ 로그 검색 용이 ∙ 가독성 및 사용성 좋음
주요 Metric
• Consumed / Provisioned : RCU, WCU
• ThrottledRequests : Read, Write
대응 : RCU, WCU 값 조정, Partition Key 점검
• Scan 발생빈도
대응 : Query 튜닝, Data Lake에서 업무 처리
38. 질문하며 정리하기
38
• NoSQL을 꼭 사용해야하는 상황인가?
기존 DB서비스에 Capacity, Throughput, Query Latency 이슈가 있다면 도입을 고민하자.
• 꼭 DynamoDB이어야 하는가?
무중단, 안정성, 관리성(Full managed) 이 중요하다면 먼저 DynamoDB를 검토하자.
• OLTP/OLAP성 업무도 존재하고, 대용량 트래픽도 받아야 하고, 다양한 조건의
Ad-hoc Query도 수행해야 하는데 괜찮을까?
왜 꼭 하나의 DBMS만 사용해야하는가? DynamoDB와 RDB를 데이터 복제하여 목적에 맞게 사용하자.
(Tier1, Tier2..)