[DynamoDB] DynamoDB Schema Modeling 하는 과정

목차

• DynamoDB와 같은 Wide Columns DB는 RDB에 비해서 더 확장성(scalability)을 가지는가 ?
• 그거 알아요 ? DynamoDB는 HTTP로 통신한다는거 (RDB 운영 이슈, Transaction, Conflict)
• DynamoDB에서 사용하는 용어 정리
• DynamoDB는 사용한 만큼 비용을 냅니다
• http API 실습히가 - Write 편
• http API 실습히가 - Read 편
• 제약사항과 그 철학
• 아키텍처 구조 이해하기
• Schema Modeling 하는 과정

개요

DynamoDB는 RDB와 그 구조가 다르다는 것을 이전시간들을 걸쳐서 알아보았습니다. 다시 한번 지금까지 나왔던 내용을 되짚어 보면 아래에 나열된 점이 DynamoDB의 특성입니다.

• 확장성을 위해서 Join을 지원하지 않는다
• HTTP로 통신을 한다
• OLTP 기반의 강력한 제약사항을 가진다
• Partition Key와 Sort Key 기반의 접근만 가능하다

이러한 특성으로 DynamoDB는 RDB를 모델링 하는 것과는 다르게 접근해야합니다. 오늘은 DynamoDB 에서 Modeling 하는 과정을 하나씩 알아보도록 하겠습니다.

DynamoDB 모델링 접근하는 과정

DynamoDB의 모델링은 RDB에 비해서 초기 설정이 중요합니다. 왜냐하면 데이터에 접근할 수 있는 방법이 Primary Key로 제한 되어있고 Primary Key가 아니면 Scan을 사용해서 Full Search를 하거나 별도의 GSI 만들어서 접근해야하기 때문입니다.

아래와 같은 프로세스를 통해서 Dynamo Table의 모델링을 접근할 수 있습니다.

• 어플리케이션 Domain에 대해서 이해
• ERD(Entity-Relationship diagram) 작성
• Write 및 Read Access Pattern 작성
• Primary Key 모델링
• (Optional) Secondary Index 모델링

ERD 작성

DynamoDB는 Join이 안되기 때문에 ERD가 필요 없다고 생각할 수 있습니다. 하지만 그렇지 않습니다. Dynamo Table을 설계할 때 역시 ERD 작성해야합니다. 그 이유는 ERD를 작성 함으로써 얻는 Entity 간의 명확한 관계도가 Dynamo Table을 설계할 때도 기본이 되기 때문입니다. 이는 어떠한 NoSQL data를 설계할때도 마찬가지입니다.

유저가 상품을 주문하는 것을 ERD로 간단하게 나타내면 아래와 같이 나타낼 수 있습니다. 이는 USER와 ORDER의 관계가 1 : N의 관계를 가지고 있다는것을 나타냅니다.

ERD를 통해서 어플리케이션에 속할 요소에 대해서 미리 생각해 볼 수 있도록 강제하기 때문에 ERD를 작성하는 것을 권장합니다.

Access Pattern 정의

RDB는 이를 Table로 바로 변환시킬 수 있지만 DynamoDB는 여기서 조금 더 고민해봐야하는 포인트들이 몇가지 있습니다. 첫째로 item Access Patterns을 파악하는 것입니다.

access pattern을 명확히 하기 위해서는 요구사항을 명확히 해야합니다. 이는 API의 구현 방향, UI/UX의 형태에 좌우될 수 있습니다. 따라서 이를 위해서 PM, Manager 등 관련 스테이크홀더들과 이야기를 진행하며 기반이 되는 요구사항을 먼저 명확히 한 후 Access Pattern을 작성합니다.

요구 사항이 명확해졌으면 아래 처럼 Table을 작성해보면 좋습니다. 아래의 형식은 Alex Debrie의 책에서 발췌한 것입니다.

User의 Item을 보도록 하겠습니다. Access Pattern을 아래와 같이 판단하겠습니다.

1. User는 회원가입시 생성
2. User는 Access Token을 통해서 UserNumber를 가져올 수 있음
3. 해당 UserNumber를 토대로 유저의 정보를 반환해야함

다음으로 Order를 보도록 하겠습니다.

1. Order는 User가 주문을 하면 1개의 Item을 생성
2. UserNumber를 기반으로 본인이 주문한 Order List를 가져올 수있어야함
3. Order 상세 정보를 가져올 수 있어야함

Entity	Access Patten	Index	Parameters	Notes
User	Create User
	Get By UserNumber
Order	Create Order
	Query By UserNumber
	Get By UserNumber + OrderNumber

이렇게 미리 Access Pattern을 작성해봄으로써 실제로 API에 어떻게 적용시킬 수 있을지, Primary Key로 접근할 수 있을지, Index로 접근해야할지 명확히 할 수 있습니다.

Primary Key 모델링

다음으로 진행할 것은 Primary Key를 선정하는 것입니다. Primary Key는 Partition Key와 Sort Key로 이루어진다는 것을 이해하고 접근해보도록 하겠습니다.

Entity	Access Patten	Index	Parameters	Notes
User	Create User	X	name, usernumber, createdat
	Get By UserNumber		usernumber
	Query By UserName		username
Order	Create Order	X
	Query By UserNumber		usernumber
	Get By UserNumber + OrderNumber

명심하셔야하는 점은 DynamoDBd의 경우 item에 접근하기 위해서는 API에서 item의 primary key를 알아야한다는 점입니다. 또는 Primary Key의 일부인 Parition Key를 알아야 Query가 가능합니다. 그렇지 않다면 Scan을 통해서 full table 조회가 필요합니다.

User를 다시 보도록 하겠습니다. 우리는 위에서 Access Pattern을 확인했고 Primary Key를 아래와 같이 정의할 수 있습니다.

• User는 Partition Key로 UserNumber를 지정
• User 정보에는 별도 Sort Key를 통해서 Item Collection을 만들 필요성은 없음
• 유저의 정보가 추가되면 attribute로 커버 가능

다음으로 Order를 보도록 하겠습니다. 우에서 정의한 Access Pattern을 기준으로 Primary Key를 아래와 같이 정의하게습니다.

• Order는 Partition Key로 UserNumber, 그리고 Sort Key로 OrderNumber를 지정
• 유저의 주문 정보 리스트는 UserNumber를 통해서 Query하여 가져올 수 있음
• 특정 주문에 대한 상세 정보는 Order는 User와 1 : N 관계를 가지기 때문에 UserNumber + OrderNumber를 통해서 가져올 수 있음

이러한 과정을 통해서 User와 Order의 Dynamo Table 모델링을 완수할 수 있고 같이 Entity 별 Primary Key가 설정되게 됩니다.

Entity	PK	SK
User	UserNumber	X
Order	UserNumber	OrderNumber

Secondary Index 모델링

이렇게 만들어 둔 Primary Key는 아쉽게도 모든 케이스의 Access Pattern을 커버하지 못할 수 있습니다. 그리고 요구사항은 지속적으로 변경되기 때문에 커버하지 못하는 Access Pattern을 새롭게 추가해야하는 경우도 있습니다. 이 경우 Secondary Index를 통해서 해결할 수 있습니다. Secondary Index는 DynamoDB는 GSI와 LSI가 있습니다. 이에 대한 자세한 내용은 참고해주시고 오늘은 모델링에 집중하도록 하겠습니다.

우리의 예제 케이스의 경우 User Entity에서 UserName으로 데이터를 가져올 수 있어야 한다는 요구사항이 이에 해당 할 수 있습니다.

우리는 이를 만족하기 위해서 username을 GSI로 만들어서 UserName에 맞는 list를 반환하게 할 수 있습니다.

Entity	Access Patten	Index	Parameters	Notes
User	Create User	X	name, usernumber, createdat
	Get By UserNumber	PK	usernumber
	Query By UserName	GSI	username
Order	Create Order	X	usernumber, orderNumber, address
	Query By UserNumber	PK	usernumber
	Get By UserNumber + OrderNumber	PK + SK	userumber, ordernumber

마무리

오늘은 DynamoDB의 모델링하는 과정을 알아보았습니다.

이제 설계된 테이블을 이요해서 실제 DynamoDB 테이블을 만들기만하면 됩니다.

감사합니다.

참고

[1] The DynamoDB Book by Alex Debrie- Steps for Modeling with DynamoDB