[AWS] Serverless Service - DynamoDB 편(1)

(출처:  https://www.youtube.com/watch?v=U_GJYMUjiwA&t=2s )

DynamoDB

• Key-Value 형식의 NoSQL
• 다수의 서비스들과 컴퓨팅이 결합된 분산 시스템 구조
• 3 AZ - 3 copy / 수백만의 요청에 한자리 ms 지연시간(모든 규모에서 10ms 미만)
• Data types: String, Number, Binary, Bool, Null, List, Set of String/Number, Map

 

동작 방식

• Item: 테이블에 저장되는 레코드
• 각 Item들은 RDBMS에서 Column 이라 부르는 Attributes로 구성
• 하나의 테이블은 Partition Key를 기준으로 분산됨
  • Partition Key 필수(사용자 ID와 같은 unique한 데이터)
  • 결국 Partition Key는 물리적인 공간인 파티션을 특정하는 키
• Partition Key + Sort Key = PK(Primary Key)
  • PK는 유일 조건을 만족해야 함
  • Sort Key: 파티션 내에서 정렬하는 기준 값
• DynamoDB Secondary Index:
  • LSI(Local Secondary Indexes): 원본 테이블과 파티션 키를 같이 가져감 → 테이블에 속한 인덱스
  • GSI(Global Secondary Indexes):  원본 테이블로부터 복사본을 갖는 별도의 테이블(원본 테이블과 다른 파티션 키를 생성 가능) → Item을 조회하기 위한 또 다른 (PK + SK)를 추가할 수 있음!!
• DynamoDB의 성능: RCU / WCU

 

SQL / NoSQL

• RDBMS와 다르게 정규화 과정이 없으며 액세스 패턴에 따라 Item의 Attribute들이 달라질 수 있음
• 기존에 테이블들로 분리했던 데이터들은 Document 형식으로 데이터 처리 가능

 

 DynamoDB 테이블

• partition key에 의해 분산되며 같은 노드에서 sort key로 정렬됨
• 각 Item의 Attribute들은 schemaless 방식으로 순서 및 개수에 상관 없이 저장 가능

 

Partitioning

• OrderId가 Partition Key, 해당 OrderId는 해시함수에 의해 물리적으로 Partition된 노드로 전환
  • 요청 받은 파티션 키를 파라미터로 Hash Value를 도출하여 파티션이 결정되기 때문에 테이블이 아무리 커져도 Hash Value를 도출해 빠른 속도로 해당 데이터에 접근하기 때문에 일관된 응답 시간을 제공할 수 있음!!
  • Partition Key 연산은 "Equal" 만 가능!!
• 설정된 용량은 각 노드에 균등하게 배분되어 리소스로 사용됨
  • 1 Partition 의 크기 = 10GB / 1 Item = Max 400 KB / 1 Partition에는 25000개의 Item이 들어감
  • 1 Partition의 최고 RCU = 3000 / 최고 WCU = 1000

• Sort Key는 동일 파티션 키에 대해서 정렬 기준으로 사용 됨
  
  • 연산: 선택, 범위 연산 가능(>, >=, <, <=, begin_withs, between)
• Customer#가 같은 애들은 같은 파티션에 저장되며 Order#에 대해 정렬됨

 

LSI(Local secondary index)

• Table과 같은 파티션 키를 가지고 sort key를 별도로 구성이 가능하다
• 용량은 10GB(테이블당 5개)
• Projection: 인덱스에 어떤 Attribute를 추가할지 결정하는 것
  • KEYS_ONLY / INCLUDE / ALL
• 최대한 안쓰는 걸 추천!
  • LSI는 파티션 키를 테이블의 파티션 키와 동일하게 설정해야하기 떄문에 두 파티션 키가 같은 데이터를 바라보고 연산한다는 점에서 별루.. 또, 테이블 생성 시에만 생성 가능하고, 삭제 불가능

 

GSI(Global secondary index)

• Table과 다른 파티션 키를 가질 수 있음 → Item을 조회하기 위한 또다른 (PK + SK) 추가
• 원본 Table로 부터 새로운 테이블을 만드는 방식(원본 테이블 변경되면 GSI의 테이블도 동기화 되는 구조)
• 별도의 저장공간 필요(용량 제한 없음)하기 때문에 RCUs/WCUs 설정해야함
  • 원본 Table의 저장 성능을 보장하기 위해 같은 Capacity설정 권장
• 중요한게... Eventual Consistent Read / Strong Consistent Read 가 있는데 GSI는 Strong Consistent Read 불가!!
  • Eventual Consistent Read: 응답 속도는 빠르지만 최근 완료된 쓰기 작업 결과가 반영되지 않아 최종적인 데이터를 가져오지 않음(3 AZ에서 젤 빠른거 가져옴)
  • Strong Consistent Read: 응답 속도는 느리지만 최근 완료된 쓰기 작업 결과가 반영됨(3 AZ 변경 다 하고 나서 가져옴, GSI 사용 불가)

 

Burst capacity

• Partition당 사용되지 않는 용량을 최대 5분동안 저장
• 설정된 용량 이상의 요청이 들어올 경우 저장된 용량을 사용할 수 있음

• Partition 1,2,3에 미사용 용량이 Partition 4로 넘어가 초과되는 용량을 커버쳐줌
• 커버를 치지 못할 경우 Throttling 발생 → "Hot Partition"
  • 500 Error 리턴 후 write 요청 실패
  • 특정 파티션에 지속적으로 예기치 않은 요청이 오는 것을 막을 수 있도록 파티션 키의 변경이 필요함
  • 만약 워크로드가 예상된다면, provisioned 모드에서 on-demand 모드로 변경

 

테이블 설계 예시

Hierarchical data structures as items

• ProductID 2에 대해 type을 보면, albumID의 track에 대해 Attributes가 존재하도록 구성 가능

as documents (JSON)

• 하나의 ProductID에 대해서 Attribute에 document 형식으로 데이터 관리 가능

 

 

 

❗ 아래의 링크는 DynamoDB 데이터 설계할 때 도움이 많이 될만한 블로그 이다.. ❗

https://zuminternet.github.io/DynamoDB/