Throughput Capacity

Table 이나 Index 를 생성할 때 읽기(RCU : Read Capacity Units) 및 쓰기(WCU : Write Capacity Units) 에 대한 처리량(capacity) 을 지정해야 한다.

처리량을 미리 정의함으로써, DynamoDB 는 읽기 및 쓰기 작업량에 충족할 만큼의 리소스를 예약하여 일관되고 낮은 대기 시간의 성능을 보장한다.

• 1 RCU 는 4 KB 크기의 Item 의 경우, 초당 strongly consistent read 1 또는 초당 eventually consistent read 2 를 나타낸다. 4 KB 미만의 Item 은 4 KB 단위로 반올림 된다.
• 1 WCU 는 1 KB 크기의 Item 의 경우, 초당 쓰기 1 을 나타낸다. 1 KB 미만의 Item 은 1 KB 단위로 반올림 된다.

Secondary Indexes 가 있는 Table 의 경우, Table 용과 별도로 해당 Index 의 RCU/WCU 가 더 필요하다.

Burst Capacity

읽기나 쓰기 요청이 Table 의 프로비저닝된 처리량을 초과하더라도 300초에 해당하는 미사용 용량의 일부를 남겨 두어 어느 정도를 처리해 주는 기능이다

이 용량이 모두 소진된다면 HTTP 400 코드(Bad Request) 가 ProvisionedThroughputExceededException 과 함께 표시되면서 요청이 실패한다.

AWS SDK 에서 제한된 요청을 다시 시도할 수 있으며, 모니터링을 하여 처리량 설정을 변경할 수 있다.

예를 들어, WCU 를 5 로 설정했다고 하자. 

그럼 1초에 5번의 putItem 요청을 처리할 수 있는데, 1초에 1500 개의 요청을 보냈다고 치자.

WCU 처리량의 5 를 넘어서는 순간 바로 에러를 발생시키는게 정상이겠지만, Burst Capacity 덕분에 즉시 처리하지 못하는 요청들은 대기열에 쌓이며 처리될 것이다.

Burst Capacity 의 처리량을 넘어가는 순간 에러를 발생할 것이고, SDK 를 이용하는 경우 에러를 catch 하여 재시도 간 대기 시간을 점진적으로 늘려주는 것이 좋다.
언제 다시 300초의 Burst Capacity 가 충전되는지는 정확하게 알 수 없지만, Burst Capacity 자체가 순간적인 병목현상을 방지하기 위한 기능이니, 이를 활용하여 처리량을 설정하려고 하는 것은 좋지 않다. 일반적으로 에러난지 1분 뒤의 재요청에도 계속해서 에러가 발생한다면 처리량을 높이는 것이 좋다.

Consistent Read

읽기는 두가지 옵션이 있다.

• Eventually Consistent Read
  DynamoDB 테이블의 데이터를 읽을 때, 응답은 최근 완료된 쓰기 작업에 대해서 부실 데이터가 일부 포함될 수 있다.
  잠시 후 읽기 요청을 반복하면 응답이 최신 데이터를 반환한다.(기본값)
  
  
• Strongly Consistent Read
  strongly consistent read를 요청하면 DynamoDB는 성공한 모든 이전 쓰기 작업의 업데이트를 반영하여 가장 최신 데이터로 응답을 반환한다. 
  API 사용시 ConsistentRead 파라미터를 true 로 설정하면 Strongly Consistent Read 사용.

RCU / WCU 설정 예)

Naming Rules

DynamoDB 의 Table 및 Attribute 등에 지정할 수 있는 허용 문자와 규칙.

• a-z, A-Z, 0-9, _(밑줄), -(대시), .(점)
• 대소문자 구분
• 속성에 예약어(웬만한 프로그래밍 명령어 같은...) 는 사용하지 않는 것이 좋음. 
• #(해시) 나 :(콜론) 도 표현식에서 사용되므로 사용하지 않는 것이 좋음.

Data Types

DynamoDB 가 Attribute 에 지원하는 데이터 타입을 다음처럼 분류할 수 있다.

• Scalar Types : number, string, binary, Boolean, null 중 하나의 값만 표현.
• Document Types : list 나 map 같은 복잡한 구조 표현.
• Set Types : string set, number set, binary set 등 여러 Scalar 값 표현.

Scalar Types

1. String

• UTF-8 인코딩 사용.
• 빈문자열 허용하지 않음.
• 한 Item 의 최대 크기는 400KB.
• Partition Key 가 String 일 경우 최대 허용 길이는 2KB.
• Sort Key 가 String 일 경우 최대 허용 길이는 1KB.
• 날짜 / 타임스탬프 표현 가능.

2. Number

• 양수, 음수, 0, 최대 38 자릿수까지 허용.
• 모든 Number Type 은 문자열 형태로 DynamoDB 에 전송되고 연산시 숫자 형태로 처리.
• 날짜 / 타임스탬프 / epoch 시간 표현 가능.

3. Binary

• 압축 텍스트, 암호화 데이터, 이미지 등과 같은 모든 Binary 데이터 저장.
• 해당 데이터를 DynamoDB 로 보낼 때는 Base64 인코딩 형식으로 Bynary 값을 인코딩 해야 한다.
• DynamoDB 는 Base64 인코딩 데이터를 받아, 부호가 없는 바이트 배열로 디코딩하고 Bynary 속성 길이로 사용.
• Partition Key 가 Binary 일 경우 최대 허용 길이는 2KB.
• Sort Key 가 Binary 일 경우 최대 허용 길이는 1KB.

4. Boolean

5. Null

Document Types

List, Map 이 있으며, 서로 중첩이 가능하고 32 Depth 까지 설정 가능.

Attribute 값으로 빈 List 나 Map 허용하지만, 빈 String 이나 빈 Set 은 허용하지 않음.

1. List

• 순서가 지정된 값들을 대괄호[...] 로 묶어 저장 가능.
• List 에 저장될 값은 테이터 타입의 제한이 없음.
• JSON 배열과 유사.

2. Map

• 정렬되지 않은 name-value 집합들을 중괄호{...} 로 묶어 저장 가능.
• Map 에 저장될 값은테이터 타입의 제한이 없음.
• JSON 객체와 유사.
• JSON 문서를 저장하는 데 이상적.

Set Types

• String, Number, Binary Set 을 지원.
• Set 값의 모든 요소 형식은 동일해야 함.
• Set 값의 모든 요소는 중복이 없어야 함.
• 순서가 유지되지 않음.
• 빈 Set 을 허용하지 않음.

DynamoDB 를 어플리케이션에서 사용할 수 있는 몇가지 API 카테고리이다.
심플하게 데이터 올리기, 가져오기, 수정하기 정도가 전부이다.

Control Plane : Table 및 Key, Index 관련.

• CreateTable
  Table 생성. Secondary Indexes 및 DynamoDB Stream 설정 가능.
  
  
• DescribeTable
  Table 정보 반환 (Primary key 스키마, 처리량 설정, Index 정보)
  
  
• ListTables
  모든 Table 의 이름을 목록으로 반환.
  
  
• UpdateTable
  Table, Index, Stream 수정.
  
  
• DeleteTable
  Table 및 해당 종속적 객체 모두를 삭제.

Data Plane : Table 의 데이터에 대해 생성, 읽기, 업데이트 및 삭제(CRUD) 작업을 수행.

• PutItem
  단일 Item 생성. primary key 는 반드시 지정.
  
  
• BatchWriteItem
  한번에 최대 25개의 Item 을 생성. PutItem 을 여러 번 호출하는 것보다 이 작업이 효율적.
  
  
• GetItem
  단일 Item 읽기. 원하는 Item 의 primary key 지정. 전체 Items 또는 Attribute 일부를 가져올 수 있다.
  
  
• BatchGetItem
  하나 이상의 Table 에서 최대 100개의 Items 를 가져온다. GetItem 을 여러 번 호출하는 것보다 이 작업이 효율적.
  
  
• DeleteItem
  단일 Item 삭제. 삭제하려는 Item 의 primary key 지정.
  
  
• BatchWriteItem
  하나 이상의 Table 에서 최대 25개의 Items 를 삭제. DeleteItem을 여러 번 호출하는 것보다 이 작업이 효율적.
  
  
• UpdateItem
  Item 에서 하나 이상의 Attribute 수정, 추가, 제거 가능. 수정하려는 Item 의 Primary key 를 지정. 사용자 정의 조건부 업데이트를 수행 가능. 숫자 속성 증감 원자성 카운터를 구현 가능.
  
  
  
• Query
  Partition key 를 지정하여 해당 Partition key 를 갖는 모든 Item 을 가져온다. 전체 Item 또는 Attribute 일부만 가져올 수 있다. sort key 값에 조건을 적용하여 동일한 Partition key 의 데이터 일부만 검색할 수도 있다. 테이블에 Partition key 와 sort key 가 모두 있는 경우 이러한 작업을 테이블 및 Index 에 사용할 수 있다.
  
  
• Scan
  지정한 Table 또는 Index 의 모든 Items 를 가져온다. 전체 Items 또는 Attributes 일부만 가져올 수 있다. 필터링 조건을 적용하여 필요한 값만 반환할 수 있다. 풀스캔을 하므로 대용량 테이블에 사용하지 않아야 한다. 작은 테이블이나 불가피하게 데이터를 대량으로 내보낼 경우 정도에 사용한다.

DynamoDB Streams : Table에 Stream 설정/해제, Stream 의 데이터 수정 레코드에 액세스 가능.

• ListStreams
  모든 스트림 목록 또는 특정 테이블의 스트림 반환.
  
  
• DescribeStream
  Amazon 리소스 이름(ARN) 및 애플리케이션이 첫 스트림 레코드를 읽기 시작할 수 있는 위치와 같은 정보를 반환.
  
  
• GetShardIterator
  샤드 반복자(shard iterator) 를 반환. 샤드 반복자는 애플리케이션이 스트림으로부터 레코드를 가져오는 데 사용하는 데이터 구조이다.
  
  
• GetRecords
  지정된 샤드 반복자를 사용하여 하나 이상의 스트림 레코드를 가져온다.

DynamoDB 의 구성요소

• Tables
  데이터(Items) 를 저장하는 공간이다 (RDS 의 table 과 유사)
  
  
• Items
  여러 속성들(Attribues) 로 구성된 집합으로 각 Item 은 모두 유일해야 한다. (RDS 의 row, record, tuple 과 유사)
  각 Item 을 유일하게 만들 하나 이상의 Primary key Attributes 를 가진다. (한 Item 의 최대 크기는 400KB)
  
  
• Attributes
  더 이상 분리할 수 없는 기본적인 데이터 요소. (RDS 의 field, column 과 유사)
  대부분의 Attribute 는 문자열이나 숫자같은 스칼라 값을 가진다.
  일부 Attribute 는 내포(nested) Attribute 로 32 Level 까지 지원한다. {key1:{key2:{key3:...{key32:value}}}}

Primary key

Attribute 중 각 Item 을 다른 Items 와 구별해 주는 Attribute 로 테이블 생성시 지정해야 한다. (RDS 의 Index 와 유사)

이 Privary key 를 제외하고는 Attributes 나 데이터 타입을 미리 정의할 필요가 없다. Item 을 업로드할 때 특정 Attribute 를 지정하여 값을 넣으면 생성된다.

각 Privary key 값은 스칼라여야 하며(즉, 단일 값만 가질 수 있음), 데이터 타입은 String, Number, Binary 만 허용된다.

• Partition key
  Primary key 로 Partition key 하나만 사용하여 item 식별할 수 있다. Partition key 중복 불가.
  DynamoDB 는 Partition key 로 Item 을 파티션(DynamoDB 내부의 물리적 스토리지) 에 균등하게 분산하는데 내부 해시 기능을 사용해서 hash attribute 라고도 한다.
  
  
• Partition key & sort key
  Partition key 와 sort key 두 개의 Attributes 를 사용하여 item 을 식별할 수 있다.
  Partition key 중복 허용. Partition key 와 sort key 모두 중복 불가.
  Partition key 가 동일한 모든 Items 는 sort key 값을 기준으로 정렬되어 함께 파티션에 저장되며, range attribute 라고도 한다.

쉽게 말해, Partition key 하나만으로 Item 을 유일하게 만들 수 있으면 Partition key 만 사용하면 되고,

Partition key 의 중복이 예상되면 조합했을 때 Item 을 유일하게 만들 수 있는 Attribute 를 Sort key 로 지정하면 된다.

Secondary Indexes

테이블에 하나 이상의 보조 인덱스(Secondary Indexes) 를 생성할 수 있다.

Secondary Indexes 는 Primary key 에 대한 쿼리는 물론이고 대체 키(alternate key) 를 사용한 쿼리 실행이 가능하다.

Primary key 만으로 원하는 데이터를 조회할 수 없을 때, 다른 Attributes 로 Items 를 조회를 해야 할 때 필요하다.

• Global secondary index
  Index 의 Partition key & sort key 가 Table 의 Partition key & sort key 와 다를 수 있는 Index.
  
  
• Local secondary index 
  Table 과 Partition key 는 동일하지만 sort key 는 다른 Index.

테이블당 최대 5개의 Global secondary index 및 5개의 Local secondary index 를 정의할 수 있다.

DynamoDB 는 기본 테이블의 Item 에 추가, 업데이트, 삭제가 발생하면, 해당 테이블에 속하는 모든 Index 에도 해당하는 Attribues 를 자동으로 동기화 한다.

기본 테이블에서 Index 로 복사되는 Attribute 를 따로 지정하지 않으면 기본 테이블의 key attribues 만 가져온다.

DynamoDB Streams

DynamoDB 의 테이블에서 Streams 을 설정하면, Item 의 추가, 업데이트, 삭제 같은 이벤트이 발생할 때마다 Streams 레코드를 기록한다.

Stream 레코드에는 테이블의 이름, 이벤트 타임스탬프 및 다른 메타데이터가 포함되어 있으며 24시간 후에는 Stream 에서 자동으로 제거된다.
주로 Stream 과 AWS Lambda 를 함께 사용하여 트리거를 만드는데 사용할 수 있다. (예: 회원 데이터가 들어오면 가입 메일 발송하기 등)

작년에도 DynamoDB 글을 하나 올렸었군; 기억이 안나...ㅡ.ㅡ 어쨌든 다시!

DynamoDB 는 AWS 에서 제공하는 NoSQL 데이터베이스 서비스이다.
굳이 DynamoDB 를 추천할 이유는 없지만,
어플리케이션이 AWS 플랫폼 상에서 돌아간다면 다른 NoSQL 에 비해 운영/관리에 노력을 덜 들일 수 있는 장점이 있으므로 사용해 볼 만하다.
RDS 에서 사용하던 관계성을 다 풀면서 DynamoDB 로 마이그레이션하여 사용하는게 가능할 수도 있겠지만 웹 서비스에서 그래야할 이유는 딱히 모르겠다.
우리 조직은 각종 통계를 위한 빅데이터 자료 및 각종 로그 등을 DynamoDB 에서 수집한다.

DynamoDB 의 장점

• 용도에 맞게 예측하여, 테이블 생성시 파티션키와 읽기(RCU : Read Capacity Units) 및 쓰기(WCU : Write Capacity Units) 에 대한 처리량(capacity) 만 지정하면 됨.
• 하드웨어 프로비저닝, 설정 및 구성, 복제, 소프트웨어 패치 또는 클러스터 조정 등의 관리에 대해 신경 쓸 필요가 없음.
• 테이블 처리량을 조절하기 위해 가동 중지나 성능 저하가 나타나지 않음.
• AWS Management Console 을 사용하여 리소스 사용률과 성능 측정치를 모니터링 가능.
• TTL 설정으로 만료된 항목이 테이블에서 자동으로 삭제되므로 스토리지 사용량을 줄일 수 있음.
• 모든 데이터가 SSD 에 저장되고 AWS 리전의 여러 가용 영역에 걸쳐 자동 복제되기 때문에 확실한 고가용성과 데이터 내구성을 보장.
• 다른 AWS 서비스와의 편리한 통합 기능.

DynamoDB 의 단점

• RCU / WCU 를 불필요하게 높게만 설정하면 과금 폭탄.

DynamoDB 의 과금

• RCU 1 당 / WCU 1 당 / Table 데이터 차지 용량 GB 당 과금.

테이블에 데이터를 업로드할 때 할당된 모든 서버에 데이터를 동시에 업로드하면 설정한 처리량을 완전히 활용할 수 있다.
DynamoDB는 파티션 키가 중복되지 않으면 테이블 데이터를 여러 서버에 분할하므로, 데이터의 파티션 키가 중복되지 않게 만들어주는 약간의 꼼수가 필요하다.
파티션 키 뒤에 난수나 유닉스 타임등을 붙여 유일한 파티션 키로 만들어 주면 여러 서버에 분산 업로드가 될 것이다.

첫번째는 특정 파티션에만 워크로드가 발생하지 않도록 유일한 파티션 키를 만드는 것이 중요하고,
꾸준한 모니터링으로 적절한 처리량을 할당하는 것이 다음으로 중요하다.

다른 NoSQL 도 마찬가지겠지만 성능을 효율적으로 극대화 시키는 등의 작업은 많은 학습, 시행착오로 다져진 노하우와 꾸준한 모니터링 등이 필요할 수 있다.