본문 바로가기

AWS Database/AWS DynamoDB

[AWS Certificate]-DynamoDB

Amazon DynamoDB - Overview

 

  • Non-relational Key-Value store
  • 클라우드 완전 관리형, 서버리스, NoSQL 데이터베이스
  • Fast, Flexible, Cost-effective, Fault Tolerant, Secure
  • Multi-region, multi-master database (Global Tables)
  • Backup and restore with PITR (Point-in-time Recovery)
  • 모든 규모에서 한 자리수 밀리초 성능 제공(Single-digit millisecond performance at any scale)
  • DAX를 사용한 In-memory 캐싱 (DynamoDB Accelerator, microsecond latency)
  • API를 통한 CRUD (Create/Read/Update/Delete) 작업 지원
  • 여러 테이블에 걸친 Transaction 지원 (ACID support)
  • 직접 분석 쿼리 없음 (No joins)
  • 효율적인 설계 및 성능을 위해 Access Pattern을 알아야 함

Demo


DynamoDB Terminology Compared to SQL

 

SQL / RDBMS DynamoDB
Tables Tables
Rows Items
Columns Attributes
Primary Keys
- 다중 열 및 선택 사항
Primary Keys
- 필수, 최소 1개 및 최대 2개의 속성
Indexs Local Secondary Indexes
Views Global Secondary Indexes

DynamoDB Tables

 

  • Tables은 최상위 Entity
  • 엄격한 테이블간 관계 없음 (Independent Entities)
  • Table 수준에서 성능 제어
  • JSON으로 저장된 테이블 항목 (DynamoDB-specific JSON)
  • 기본키(Primary key)는 필수, 나머지 스키마는 유연함(flexible)
  • 기본키(Primary Key)는 단순(simple) 또는 복합(composite) 일수 있다.
  • 단순키(Simple Key)는 단일 속성 (=partition key or hash key)
  • 복합키(Composite Key)는 두 가지 속성(=partition/hash key + sort/range key)
  • 키가 아닌 속성(including secondary key attributes)은 선택 사항(Optional) 

DynamoDB Table Items

 

단순 기본 키(Simple Primary Key)가 있는 테이블

{
     "partition_key":"...",
     "attribute_1":"...",
     "attribute_2":"..."
}

{
     "partition_key":"...",
     "attribute_1":"...",
     "attribute_4":"...",
     "attribute_5":"..."
}

복합 기본 키(Composite Primary Key)가 있는 테이블

{
     "partition_key":"...",
     "sort_key":"...",
     "attribute_1":"...",
     "attribute_3":"..."
}

{
     "partition_key":"...",
     "sort_key":"...",
     "attribute_3":"...",
     "attribute_4":"..."
}

 


DynamoDB의 Data Type

 

  • Scalar Types
    • 정확히 하나의 값
    • 예: 문자열(string), 숫자(number), 이진(binary), boolean, Null
    • Keys 또는 index 속성은 문자열, 숫자 및 이진(binary) Scalar 유형만 지원

 

  • Set Types
    • 다중 스칼라 값 (Multiple scalar values)
    • 예: 문자열 집합(string set), 숫자 집합 (number set and binary set

 

  • Document Types
    • 중첩된 속성(nested attributes)이 있는 복잡한 구조
    • 예: 목록 및 지도

 


AWS Global Infrastructure

  • 전 세계 여러 AWS 리전 보유
  • 각 지역에는 하나 이상의 AZ(Availability Zones)가 존재
  • 각 AZ에는 하나 이상의 시설(=Data Centers)
  • DynamoDB AWS region 내의 여러 시설 간에 데이터를 자동으로 복제
  • 준 실시간 복제(Real-time Replication)
  • AZ는 독립적인 장애 Doamin 역할을 함

DynamoDB Consistency(일관성)

 

  • 읽기 일관성(Read Consistency):
     강력한 일관성(strong consistency), 최종 일관성(eventual consistency) 및 트랜잭선( transaction)
  • 쓰기 일관성(Write Consistency):
     표준(standard) 및 트랜잭션(transaction)

 

  • 강력한 일관성(Strong Consistency)
     최신 데이터
     명시적으로 요청해야 함
  • 최종 일관성(Eventual Consistency)
    최신 데이터 사본을 반영하거나 반영하지 않을 수 있음
    모든 작업에 대한 기본 일관성
    강력한 일관성(Strong consistency)보다 50% 저렴
  • 트랜잭션 읽기 및 쓰기 (Transactional Reads and Writes)
    단일 AWS 계정 및 리전 내의 하나 이상의 테이블에서 ACID 지원
    강력한 일관된(Strong Consistency) 읽기 비용의 2배
    표준 쓰기(Standard Write) 비용의 2배

 

Strongly Consistent Read vs Eventually Consistent Read

 

  • 최종 일관된 읽기(Eventually Consistent Read): 쓰기 직후에 읽는 경우 복제로 인해 예기치 않은 응답을 받을 수 있음

 

  • 강력한 일관된 읽기(Strongly Consistent Read): 쓰기 직후에 읽어도 올바른 데이털르 얻을 수 있음.

 

  • 기본: DynamoDB는 최종 읽관된 읽기(Eventually Consistent Reads)를 사용하지만 GetItem, Query & Scan은 True로 설정할 수 있는 "ConsistentRead" parameter를 제공

 

DynamoDB Transactions - 트랜잭션 일관성(transactional consistency)

 

  • 계정 잔액 테이블(AccountBalance Table)
Account_id balance Last_transaction_ts
Acct_21 230 1562503085
Acct_45 120 1562503085
  • 은행 거래 테이블(BankTransactions Table)
Transaction_id Transaction_time From_account_id To_account_id value
Tx_12345 1561483349 Acct_45 Acct_21 45
Tx_23456 1562503085 Acct_21 Acct_45 100
  • 트랜잭션은 두 테이블 모두에 Write가 되거나 모두 되지 않는 것

DynamoDB Pricing Model

 

Provisioned Capacity

  • 프로비저닝한 용량에 대해 비용 지불 (= 초당 읽기 및 쓰기 수)
  • Auto-Scaling을 사용하여 프로비저닝된 용량 조정 가능
  • 용량 단위(Capacity Units) 사용:
    읽기 용량 단위 (Read Capacity Units(RCUs)) and 쓰기 용량 단위 (Write Capacity Units (WCUs))
  • 프로비저닝된 용량을 초과하여 소비하면 Throttling(사용 제한) 발생할 수 있음
  • 1년 또는 3년 약정을 통한 할인에 예약 용량(Reserved Capacity) 사용
    (100 RCU 및 WCU당 1회 요금 + 시간당 요금 부과)

 

On-Demand Capacity

  • 요청당 비용 지불 (=애플리케이션에서 수행하는 읽기 및 쓰기 요청 수)
  • 용량 단위(Capacity Unit)를 프로비저닝할 필요가 없음
  • DynamoDB는 증가 또는 감소하는 워크로드를 즉시 수용
  • 요청 단위(Request Units) 사용: 읽기 요청 단위(Read Request Units) 및 쓰기 요청 단위 (Write Request Units)
  • On-Demand 모드에서는 예약 용량(Reserved Capacity) 사용 불가
  • 처리량 계산을 위해 요청 단위(request unit)는 용량 단위(capacity unit)와 동일
  • storage, backup, replication, streams, caching, data transfer out은 추가 요금 발생

DynamoDB Throughput

 

Provisioned Capacity mode

  • 용량 단위(Capacity Units) 사용
       1 용량 단위 (capacity unit) = 1 요청/초 (request/sec)

  • RCUs (읽기 용량 단위, Read Capacity Units)
       4KB 블록에서 마지막 블록은 항상 반올림
       1 강력한 일관된 테이블 (strongly consistent table) 읽기/초 (read/sec) = 1 RCU
       2 최종 일관된 테이블 (eventually consistent table) 읽기/초 (reads/sec) = 1 RCU
       1 트랜잭션 읽기/초 (transactional read/sec) = 2 RCUs

  • WCUs (Write Capacity Units)
       1KB 블록에서 마지막 블록은 항상 반올림
       1 테이블 쓰기/초 (write/sec) = 1 WCU
       1 트랜잭션 쓰기/초 (transactional write/sec) = 2 WCUs

On-Demand Capacity mode

  • 요청 단위 사용 (Request Units)
       계산 목적의 용량 단위와 동일
  • RRUs (읽기 요청 단위, Read Request Units)
       4KB 블록에서 마지막 블록은 항상 반올림
       1 강력하게 일관된(Strongly Consistent) 테이블 읽기 요청 = 1 RRU
       2 최종 일관성(Eventually Consistent) 테이블 읽기 요청 = 1 RRU
       1 트랜잭션 읽기/초 = 2 RRU
  • WRUs (쓰기 요청 단위, Write Request Units)
       1KB 블록에서 마지막 블록은 항상 반올림
       1 테이블 쓰기 요청 = 1 WRU
       1 트랜잭션 쓰기 요청 = 2 WRU

Provisioned Capacity vs On-Demand Mode

Provisioned Capacity Mode On-Demand Capacity Mode
일반적으로 Production 환경에서 사용 일반적으로 개발/테스트 환경 또는 소규모 애플리케이션에서 사용
예측 가능한 트래픽이 있을 때 사용 가변적이고 예측할 수 없는 트래픽이 있을 때 사용
비용 절감을 위해 안정적이고 예측 가능한 트래픽이 있는 경우 예약 용량 사용을 고려 테이블에서 이전 최대 트래픽의 최대 2배를 즉시 수용
소비가 급증하면 조절(Throttling) 발생 가능 30분 이내 이전 Peak의 2배를 초과하면 조절(Throttling) 발생 가능
Ondemand Capacity Mode에 비해 비용 효율적 2배 이상 driving 하기 전에 최소 30분 이상  Space Traffic 증가하는 것을 권장

Example 1: Calculating Capacity Units

 

15KB Item을 읽고(read) 쓰기(write)위한 용량 단위(capacity units) 계산

  • 강력한 일관성(Strong Consistency)의 RCUs:
    • 15KB/4KB = 3.75 =>  반올림  => 4 RCU
  • 최종 일관성(eventual consistency)의 RCUs:
    • (1/2) x 4 RCUs = 2 RCUs
  • 트랜잭션 읽기용 RCUs:
    • 2 x 4 RCUs = 8 RCUs
  • WCUs:
    • 15KB/1KB = 15 WCUs
  • 트랜잭션 쓰기용 WCUs:
    • 2 x 15 WCUs = 30WCUs

Example 2: Calculating Capacity Units

 

1.5KB 항목을 읽고 쓰기 위한 용량 단위 계산

  • 강력한 일관성(Strong Consistency)의 RCUs::
    • 1.5KB/4KB = 0.375 => rounded up => 1 RCU
  • 최종 일관성(eventual consistency)의 RCUs:
    • (1/2) x 1 RCUs = 0.5 RCU => rounded up = 1 RCU
  • 트랜잭션 읽기용 RCUs:
    • 2 x 1 RCU = 2 RCUs
  • WCUs:
    • 1.5KB/1KB = 1.5 => rounded up => 2 WCUs
  • 트랜잭션 쓰기용 WCUs::
    • 2 x 2 WCUs = 4 WCUs

Example 3: 처리량(Throughput) 계산

A DynamoDB 테이블에는 10개의 RCU와 10개의 WCU 용량이 Provisioning 되어 있다, Application이 지원할 수 있는 처리량을 계산:

  • Read throughput with strong consistency = 4KB x 10 = 40KB/sec
  • Read throughput (eventual) = 2 (40KB/sec) = 80KB/sec
  • Transactional read througput = (1/2) x (40KB/sec) = 20KB/sec
  • Write throughput = 1KB x 10 = 10KB/sec
  • Transactional write throughput = (1/2) x (10KB/sec) = 5KB/sec

DynamoDB Burst Capacity

  • 간헐적인 Burst 또는 Spike 제공
  • 5분 또는 300초 동안의 사용되지 않는 Read 및 Write 용량
  • 빠르게 소모 가능
  • 의존해서는 안됨.

DynamoDB Adaptive Capacity

 

  • 총 프로비저닝된 용량 = 초당 600 WCUs
  • 파티션당 프로비저닝된 용량  = 200 WCUs per sec
  • 사용되지 않은 용량 = 200 WCUs per sec
  • Hot 파티션은 할당된 용량을 초과하여 이러한  초당 200개 미사용 WCU 소비 가능
  • 이 이상의 소비는 조절(Throttling)으로 이어짐
  • 비 균일(Non-uniform) 워크로드(Workloads)의 경우 자동으로 작동하며 실시간으로 적용
  • 무보증

DynamoDB LSI (Local Secondary Index)

  • 최대 5개의 LSI 정의
  • 테이블읭 기본 인덱스(Primary Index)와 동일한 파티션/해시 키 속성을 갖음
  • 테이블의 기본 인덱스(Primary Index)와 다른 정렬키(Sort Key)/범위(Range Key)가 있음
  • 정렬키(Sort Key)와 범위키(Range Key)(=복합키, Composite Key)가 반드시 있어야 함
  • Indexing된 항목(Item)은 10GB보다 작아야 함.
  • 오직 테이블 생성시에만 생성되며 그 이후 삭제 불가

  • 단일 파티션 쿼리만 가능(해쉬키로 지정)
  • 최종(Eventual) / 강력(Strong) / Transaction 일관성(Consistency) 지원
  • 기본 테이블의 프로비저닝된 처리량을 사용
  • 속성(Attributes)이 Index에 프로젝션되지 않은 경우에도 모든 테이블 속성을 쿼리할 수 있음
    (전체 또는 최대 20개의 개별 속성을 프로젝션 할 수 있음)

DynamoDB GSI (Global Secondary Index)

  • 최대 20개의 GSI 정의 가능 (Soft limit)
  • 테이블의 기본 인덱스와 같거나 다른 파티션/해쉬 키를 갖을 수 있음
  • 테이블의 기본 인덱스와 같거나 다른 정렬/범위 키를 갖을 수 있음
  • 정렬/범위 키 생략 가능(=단순 및 복합)
  • 인덱싱된 항목에 대한 크기 제한 없음

  • 언제든지 생성하거나 삭제 가능, 하지만 한번에 하나의 GSI만 삭제 가능
  • 파티션 전체에 쿼리 가능 (전체 테이블에 대해)
  • 최종 일관성(Eventual Consistency)만 지원
  • 자체 프로비저닝된 처리량 보유
  • 프로젝션된 속성만 쿼리 가능 (Index에 포함된 속성)

 


When to choose which index?

 

Local Secondary Indexs Global Secondary Indexes
애플리케이션에 테이블과 동일한 파티션 키가 필요한 경우 애플리케이션이 테이블과 다르거나 동일한 파티션 키를 필요로 하는 경우
추가비용을 피해야 하는 경우 애플리케이션에 더 정밀한 처리량 제어가 필요한 경우
애플리케이션에 강력한 일관된(Strong Consistency) Index 읽기가 필요한 경우  애플리케이션에 최종 일관된(Eventual Consistency) Index 읽기만 필요한 경우

DynamoDB Indexes and Throttling

 

 

Local Secondary Indexes Global Secondary Indexes
기본 테이블의 WCU와 RCU 사용 쓰기가 GSI에서 throttle(조절)되면 메인 Table이 Throtle 됨
(메인 테이블의 WCU가 정상인 경우)
특별한 조절 고려 사항 없음 GSI 파티션 키를 신중하게 선택
  WCU 용량을 신중하게 할당

Simple design patterns with DynamoDB

  • 1:1, 1:N, N:N과 같은 다양한 Entity Relationship을 모델링 할 수 있음
  • 플레이어의 게임 상태 저장 - 1:1 모델링, 1:N 모델링
      user_id를 PK(기본키)로, game_id를 SK(정렬키)로 1:N 모델링
  • 선수들의 게임 이력 - 1:N 모델링
      user_id는 PK, game_ts는 SK(1:N 모델링)
  • 게임 리더 보드 - N:M 모델링
      game_id가 PK이고 점수가 SK인 GSI

DynamoDB Write Sharding

 

  • Candidate A와 Candidate B의 두 후보자가 있는 투표 신청서가 있다고 가정
  • Candidate_Id의 파티션 키를 사용하면 파티션이 두개뿐이므로  파티션 문제 발생
  • 솔루션: 접미사 추가(일반적으로 임의의 접미사(suffix), 때로는 계산된 접미사(suffix))

Error and Exceptions in DynamoDB

  • Common Exceptions
    • 액세스 거부 예외 (Access Denied Exception)
    • 조건부 확인 실패 예외 (Conditional Check Failed Exception)
    • 항목 수집 크기 제한 초과 예외 (Item Collection Size Limit Exceeded Exception)
    • 제한 초과 예외 (Limit Exceeded Exception)
    • 사용 중인 리소스 예외 (Resource In Use Exception)
    • 검증 예외 (Validation Exception)
    • 프로비저닝 처리량 예외 초과
        오류 재시도
        지수 백오프