DynamoDB란? 기본 개념설명

AWS를 사용하는 사용자라면, NoSQL을 사용하려고 고려하는 사용자라면, 누구나 한번쯤 들어봤을 수 있는 DB 솔루션입니다.

 

Google의 BigTable 과 NoSQL의 발전을 위해 노력하고 있는 AWS DynamoDB에 대해서 설명하겠습니다.

 

 

 

DynamoDB의 특징

 

- 배포가 단순하고 신속합니다. 이 의미는 설계를 해서 그 데이터베이스를 적용하기까지 오랜 시간이 걸리지 않는다는 이야기입니다.

 

- 확장이 단순하고 신속합니다. 수백만 IOPS를 처리할 수 있는 시스템 설계해두었기 때문에 단순한 인터페이스의 조작만으로 규모를 확장시키기 수월합니다.

 

- 데이터는 자동으로 복제됩니다. 데이터의 손실을 방지하기 위해서 데이터 베이스를 자동으로 백업해서 복사본을 두고 손실율을 낮추고 있습니다.

 

- 빠르고 일관된 응답시간. 일단 IO를 하는 시간이 빠른 것은 기본이고 아무리 규모가 증가하고 어떤 장애가 와도 일관적인 응답시간을 보여줍니다.

 

- 보조 인덱스를 통한 빠른 조회. NoSQL 특성상 관계가 없기 때문에 일반적으로 데이터를 찾기에는 인덱싱이 없으면 속도가 느려지지만 그 부분을 해결해줍니다.

 

- 사용한만큼 사용료를 지불합니다. 저장소의 사용과 사용하려는 퍼포먼스의 정도에 따라서 사용료를 지불합니다. 그래서 최적화시 킬 수 있습니다.

 

 

DynamoDB를 사용하는 목적

 

DynamoDB를 사용해야 하는 이유는 성능과 편의성, 대규모 DB를 구축하는데 필요한 비용들을 줄일 수 있습니다.

 

서비스를 구현한다고 하면 서비스는 빈번한 읽기 쓰기로 처리 속도는 빠릅니다.

 

작은 용량의 데이터를 처리할 경우, DynamoDB는 아주 효과적으로 사용될 수 있습니다.

 

데이터베이스를 확장해야하고 확장하는 과정에서 분산된 데이터베이스를 관리하기에 힘든 경우 사용하면 유리합니다.

 

즉, 모바일 게임이나 소셜 네트워크 같은 짧은 작업들을 처리하는 경우 아주 유용하게 사용될 수 있습니다.

 

DBMS처럼 트랜잭션, JOIN 과 같은 복잡한 테이블 데이터 처리과정이 있는 경우에는 비적합합니다.

 

NoSQL은 RDBMS처럼 스키마가 정해져 있지않고 비정형적인 데이터를 저장하는데 유용합니다.

 

정형화된 데이터를 저장해도 되긴 하지만 비정형화된 데이터를 저장해서 Denormalization을 적극적으로 활용하는데에 큰 장점이 있습니다.

 

적극 Denormailzation을 활용하라는 의미는 기존의 RDBMS에서 정형화하여 모든 종속관계니 도메인 원자값이니 하는 정규화(Normalization)과정을 거쳤는데,

 

여기 DynamoDB에서는 그런 규약에 얽매히지 않고 데이터를 처리할 수 있는 환경을 구성할 수 있습니다. 단, 스토리지 용량은 늘어나긴 합니다.

 

DynamoDB는 자동으로 AWS의 Region별로 데이터를 가용영역 3곳에 보통 복제해서 저장을 합니다.

 

가용 영역 중에 하나가 장애가 발생하여 정지하더라도 DB를 정상적으로 사용이 가능합니다.

 

높은 가용성과 지속성을 제공하기때문에 사용자가 따로 데이터를 백업할 필요가 전혀 없습니다.

 

DBA입장에서 보면 엄청나게 큰 강점입니다.

 

DynamoDB의 저장할 수 있는 용량은 같은 AWS의 S3와 같이 무제한입니다.

 

데이터 용량이 증가하게되면 스토리지를 늘리고 클러스터를 확장하여 데이터를 분산합니다.

 

기존의 다른 데이터베이스를 사용하면, 용량이 커지면서 샤딩(Sharding)이라는 방법을 통해 테이블의 데이터를 여러 서버에 분산시키는 작업을 직접해야합니다.

 

DynamoDB는 Read/Write Thoughput을 직접지정할 수 있습니다. 트래픽이 증가하여 사용량이 많아지면 처리량을 늘리고, 사용량이 적어지면 처리량을 줄입니다.

 

지정한 처리량은 DynamoDB가 알아서 일관되게 유지합니다.

 

요금표는 http://aws.amazon.com/ko/dynamodb/pricing/  여기를 참고하시면 됩니다.

 

DynamoDB의 모든 데이터는 SSD(Solid State Drive)에 저장하기에 손실될 위험과 성능의 보장이 가능한 이유 중에 하나가 됩니다.
* DynamoDB 테이블의 처리량의 변경

: 이미 생성된 DynamoDB 테이블의 처리량은 한 번에 최대 2배까지 높일 수 있습니다.

갑자기 트래픽이 많아져서 처리량을 높이려고 해도 기본 처리량이 낮게 설정된 상태에서는 한꺼번에 처리량을 높일 수 없습니다.

처리량을 높이는데에 반영 시간이 오래걸리므로 실무에서는 처리량을 적당히 높여놔야합니다.

처리량을 낮추는 횟수는 하루에 4번으로 제한됩니다.

그렇다고 비용면에서 너무 많은 부담을 안하셔도 됩니다. EC2를 이용해서 데이터 베이스를 돌리는 것보다 가격은 저렴합니다.

 

 

DynamoDB의 데이터 모델 기본 개념

 

기본적으로 구성요소에 대한 개념으로는 Table, Item, Attribute가 있습니다.

 

일단 하나하나씩 구성요소에 대해서 설명하겠습니다.

 

1) Table

- Table은 Item들의 모임.

 

- 들어갈 수 있는 아이템의 개수의 제한은 없습니다.

 

- 그리고 Table은 기본키를 반드시 지정을 해야합니다.

 

- 리전 당 생성할 수 있는 최대 갯수는 256개.

 

- AWS에 요청하여 더 늘릴 순 있습니다.

 

2) Item

- Item은 Attribute들의 모임.

 

- 들어갈 수 있는 Attribute의 개수는 제한이 없음.

 

- 아이템의 크기는 속성이름과 값을 포함하여, 64KB까지 입니다.

 

- 기본 키는 필수로 포함하고 있어야하고 복합키와 기타 속성을 가질 수 있습니다.

 

3) Attribute

- Attribute는 Key-Value 방식입니다. Key는 문자열이라야 합니다.

 

- Attribute이 지원하는 값 데이터 형식은 1) 스칼라 데이터 형식(Scalar data types) 2) 다중 값 형식(Multi-valued types) 두가지 입니다.

 

- 1) 스칼라 데이터 형식(Scalar data types) : 숫자(Number), 문자열(String), 바이너리(Binary)가 있습니다.

* 숫자 : 정수와 실수를 지원하며 실수는 소수점 이하 38자리입니다. 숫자는 0을 트림(Trim)해서 다룹니다. 예를 들어, 0.3->.3 , 00300->300

* 문자열 : UTF-8 형식이고 대소를 비교할 때는 ASCII Code를 기준이로 합니다.

* 바이너리 : 바이너리 데이터는 BASE64 형식으로 인코딩하여 저장하면 됩니다. 대소를 비교할 때는 각 바이트를 부호없는 정수로 취급합니다.

 

- 2) 다중 값 형식(Multi-valued types) : 스칼라 데이터 형식의 배열 형태로, 숫자 세트(Number Set), 문자열 세트(String Set), 바이너리 세트(Binary Set)가 있습니다.

* 다중 값 형식은 들어가는 값이 중복될 수 없으며, 값이 하나라도 들어가 있어야 합니다..

* 값들은 정렬되지 않고 정렬 순서도 저장되지 않습니다.

* 다중 값 형식은 기본 키로 사용할 수 없습니다.

* NULL이나 빈 문자열은 저장이 불가합니다.

 

 

DynamoDB 사용 로직

 

DynamoDB에서 검색을 하려면 기본키로 인덱스를 생성해야합니다. 기본키는 테이블이 생성될 때 무조건 반드시 지정되어야하고,

 

이 기본 키로 생성되는 인덱스를 테이블 인덱스라고 합니다.

 

기본키 형식은 두가지 키를 복합적으로 사용하는 방식쓰는데 설명하자면,

 

1) Hash 형식 기본키 : Attribute 하나를 기본 키로 사용. 키본 키의 값은 스칼라 데이터 형식만 가능. 다중값 형식은 지원하지 않습니다.

 

2) Hash와 Range 형식 기본키 : Attribute 2개를 기본키로 사용(복합키), 첫 Attribute은 해시 기본키로 사용, 두번째 Attribute는 범위 기본 키로 사용합니다.

 

해시 기본키는 일치(Equal)방식의 검색만 지원합니다.

 

범위 기본키는 일치. 부등호, 포함, ~로 시작하는 범위를 지정할 수 있는 검색을 지원합니다.

 

해시 기본 키 Attribute의 최대 크기는 2048Bytes(2MB)이고, 범위 기본 키 Attribute의 크기는 1024Bytes(1MB)입니다.

 

DynamoDB는 기본키로 생성하는 테이블 인덱스 이외에도, 보조 인덱스인 Secondary Index를 생성할 수 있습니다.

 

기본 키로 생성한 인덱스 하나만으로는 검색기능이 부족합니다.

 

보조 인덱스는 사용이 빈번하기 때문에 성능을 위해서 사용하고 Read/Write 용량 유닛을 따로 설정이 가능합니다.

 

보조 인덱스는 두가지로 나뉩니다.

 

1) Local Secondary Index    2) Global Secondary Index

 

각 보조 인덱스를 하나씩 설명하겠습니다.

 

1) 로컬 보조 인덱스(Local Secondary Index)

해시 키는 테이블 인덱스의 해시 키본 키와 같고, 범위 키는 목적에 따라 다르게 설정 가능합니다.

로컬 보조 인덱스는 테이블당 5개까지 생성이 가능하고, 테이블을 생성할 때 함께 생성해야 하며,

테이블이 생성된 이후에는 추가, 수정, 삭제가 되지 않습니다.

로컬 보조 인덱스는 테이블에서 해시 기본 키와 범위 기본키를 사용할 때만 사용할 수 있습니다.

 

2) 글로벌 보조 인덱스(Global Secondary Index)

해시 키와 범위 키 모두 테이블 인덱스와 다르게 설정한 것.

범위키는 생략 가능하다.

테이블당 5개까지 생성이 가능합니다.

글로벌 보조 인덱스는 테이블 생성시 함께 생성해야하고 테이블이 생성된 이후는 추가, 수정, 삭제가 가능합니다.

 

두가지 보조 인덱스 키의 차이점은 해시키와 범위키와 상관없이 인덱스 기능을 하기 위해 검색을 사용하는데,

 

검색 기능을 하나의 테이블에서 로컬하게 해시키를 기본키를 두고 인덱싱을 할 것인가?

 

아니면 모든 테이블에 완전 따로 해시 키, 범위 키와 다르게 설정해서 사용하는 것인 가에 차이입니다.

 

DynamoDB는 데이터를 읽을 때, 

1) Eventually Consistent Read

2) Strongly Consistent Read

를 사용가능합니다.

 

1) Eventually Consistent Read

: 읽기 처리량(Read Throughput)을 최대화하지만 읽은 데이터가 최근 완료된 쓰기 결과를 반영하지 못했을 수 있습니다.

쓰기가 데이터의 모든 복사본에 반영되는 것은 1초내에 이루어지는데, 최신 데이터를 얻으려면 짧은 시간 내에 읽기를 반복해야 합니다.

 

2) Strongly Consistent Read

: 위의 Eventually Consistent Read 에서 가지는 복사본에 반영되는 데이터의 시간 1초내에 읽기를 요청하는 경우,

데이터를 최신 데이터로 못가져오는 결과가 있는데 그러한 경우를 없애고 최근 완료된 쓰기 결과가 모두 반영된 데이터를 가져옵니다.

 

Provisioned Throughput은 사용자가 원하는 수치를 지정하면 DynamoDB가 알아서 지정된 수치만큼 처리량을 제공해주는 것을 말합니다.

- 필요한 읽기 용량 유닛(Read Capacity Units) : 초당 읽은 아이템 수 X KB 단위 아이템 크기 (근사치 반올림) (Eventually Consistent Read를 사용하는 경우 초당 읽은 아이템 용량은 두배가 됩니다.)

- 필요한 쓰기 용량 유닛(Write Capacity Units) : 초당 쓴 아이템 수 X KB 단위 아이템 크기 (근사치 반올림)

으로 필요한 Read/Write Capacity Units을 설정합니다.

 

예를 들면, 

512Bytes(1KB로 반올림 됨)을 초당 200개 항목을 읽거나(쓰면), 1KB X 200 = 200 유닛 필요,

 

1.6KB(2KB로 반올림 됨)을 초당 200개 항목을 읽거나(쓰면), 2KB X 200 = 400 유닛 필요.

 

예를 들어왔던 것들과 같이 유닛을 계산합니다.

 

Eventually Consistent Read는 500 읽기 용량 유닛으로 1KB 짜리 아이템을 1000번 읽을 수 있으며,

 

Strongly Consistent Read는 1000 읽기 용량 유닛으로 1KB짜리 아이템을 초당 1000번 읽을 수 있습니다.

 

그리고 읽기 용량의 유닛 수는 API 호출 수가 아닌 초당 읽은 아이템 수로 결정됩니다.

 

500 유닛을 읽는다라고 가정 하면,

 

1KB 짜리 아이템을 GetItem(아이템을 1개 읽는 메서드)로 500번 호출하는 것과,

 

BatchGetItem(아이템을 군집하여 읽는 메서드)를 호출하여 아이템을 10개씩 읽는 것으로하여 50번 호출하는 것과 같습니다.

 

즉, API 호출의 수가 유닛의 수가 되지 않는다는 것입니다.

 

DynamoDB의 데이터 조회 방법은 두 가지입니다. 두 가지 모두 한 번에 조회할 수 있는 용량은 1MB입니다.

- Scan : 조건 없이 모든 데이터를 가져옵니다.

- Query : 해시(기본)키에 특정 값을 지정하고, 범위(기본)키에 조건을 지정하여 원하는 데이터를 가져옵니다. 범위(기본)키에 조건을 지정하는 것은 생략할 수 있습니다.

 

* DynamoDB의 제약 조건

DynamoDB의 기술적 제약 및 한계(Limit)에 대해서는 다음 링크를 참조하기 바랍니다.

http://docs.aws.amazon.com/amazondynamodb/lastest/developerguide/Limits.html

 

 

DynamoDB 사용 예시

 

Table 안에 어떤 식으로 구성이 되어있는지 보겠습니다.

 

다음과 같이 테이블 안에 item이 들어가 있고,

 

각 Item 안에는 기본 자료형이나 Document로 내부에 정의되어있습니다.

 

각 Item 내부의 구성은 같은 Table이라고 해도 굳이 같을 필요는 없습니다.

 

다음의 예에서 attack 속성이랑, defense 속성이랑 다르게 저장할 수 있습니다.

 

즉, 하나의 Table안에 있는 각 Item의 Attribute 구성은 다를 수 있습니다.

 

저장할 수 있는 데이터 유형

 

크게 두 가지의 데이터 유형을 다룰 수 있습니다.

- Key-Value Store Model

- Document Store Model

 

Key-Value Store Model에는 

1) String(S)

2) Number(N)

3) Binary(B)

4) String Set(SS)

5) Number Set(NS)

6) Binary Set(BS)

이 사용, 저장이 가능하고,

 

Document Store Model에는

1) Boolean(BOOL)

2) Null(NULL)

3) List(L)

4) Map(M)

이 사용, 저장이 가능합니다.

 

다음으로 DynamoDB의 기본 키 사용에 대해서 크게 두가지 사용 형태에 대해서 설명하겠습니다.

 

1. 해시키만 사용하는 기본 키 형태 = 기본키(해시키)

 

2. 해시키와 범위기를 이용하는 기본 키 형태 = 기본키(해시키 + 범위키)

 

기본 키 (해시 키)

 

해시키를 기준으로 데이터를 분산시켜서 저장하고 데이터 모델을 보다 단순하게하고,

 

정렬을 하지 않고 사용하는 저장형태를 비정렬 형태를 띄게 됩니다.

 

기본 키인 Hash key는 고유 값을 가져야 합니다. 다른 키들과 중복 조회 되면 안됩니다.

 

키 안에 속하는 Element는 다를 수 있지만 기본 키인 Hash key는 달라야합니다.

 

달라야 하는 이유는 해시키를 기준으로 기본적인 데이터 모델링이 되어지는 기준이기 때문입니다.

 

그렇기 때문에 기본 키로 해시를 하나로만 설정되어 있는 경우에는 구분할 여지가 없어지기 때문에 해시키가 동일한 것이 있으면 안됩니다.

 

기본 키(해시키 + 범위키)

 

위에 기본 키를 해시 키로만 사용했을 경우에는 해시키가 동일하면 저장자체가 안되는 경우가 발생했습니다.

 

지금 설명하는 복합 키는 그 점을 해결합니다.

 

해시 키와 범위 키를 복합 기본 키로 설정해서 사용할 수 있습니다. 기본키의 경우에는 데이터 모델 복합 / 정렬 / 범위 값을 이용한 조회가 가능합니다.

 

구성되는 해시 키와 범위 키의 복합 기본키의 형태는 다음과 같습니다.

 

그런데 해시와 범위 키를 이용하면 복합 키로써 기본키가 설정이 되어지기 때문에 해시키가 같고 범위키가 다른 경우가 가능합니다.

 

즉, 위에서 기본 키로 해시키만을 사용하던 경우에서 해결하지 못했던 중복된 해시 키에 대한 해결책을 제시하는 것입니다.

 

다음은 범위키를 추가함으로써 해시키를 중복되게 사용할 수 있는 모습을 보여줍니다.

 

또한, 로컬 보조 인덱스 = 범위키를 대안으로 사용할 수 있는 LSI(Local Secondary Index) 가 있습니다.

 

LSI는 범위키를 사용하는데 어떤 범위에 들어가 있는 들어가 있는지를 구분하여 쿼리하는 데에 사용할 수 있습니다.

 

다음은 해시 키가 같은 Item에 대해서 LSI를 Date를 기록하는 형식으로 사용하여 검색할 수 있습니다.

 

보조 인덱스로 사용하는데에 Local Secondary Index 와 Global Secondary Index 가 있습니다.

 

위에서 범위키를 이용해서 같은 테이블 안에서 Date를 Local Secondary Index로 사용해서 쿼리를 하여 사용하는 것을 보았고,

 

GSI(Global Secondary Index)에 대해서 이야기 하겠습니다. 다음과 같은 그림으로 보여집니다.

 

다음 그림은 딱히 바로 이해가 가지 않는 관계로 쉽게 설명하면 동일 테이블에 해시 키를 변경하면서 그 안으로 GSI의 값을 넣어서 보조 인덱스로 활용하겠다는 것입니다.

 

위의 그림이 너무 어려워서 아래에 예를 든 그림을 보고 설명을 하겠습니다.

 

상단에 뒷 부분으로 가려진 테이블이 기본에 테이블이고, 여기에 GSI를 넣어서 활용하기 위해서 테이블을 바꾸는 과정입니다.

 

(=>는 이동함을 뜻합니다.)

해시 키=> 범위키

범위키=>속성

LSI=>속성

메인 식별 기본키를 GSI(Global Secondary Index)로 활용하는 방식입니다.

 

프로비저닝된 처리 용량

 

프로비저닝된 처리 용량 조정이 자유롭기 까진 아니더라도 서비스의 요청이 몰려 트래픽이 몰리는 경우 동적으로 조정이 가능합니다.

 

프로비저닝이라는 뜻은 "특정한 서비스를 제공받기 위해서 서비스의 실행부터 시작해서 서비스를 제공받기 전 단계까지의 처리되는 일련의 절차를 말합니다.".

 

즉, AWS에서 말하고자 하는 것은 우리가 떠먹여줄게 원하는 만큼 편하게 조절해서 사용해라는 뜻입니다. 

 

앞서 이야기 한 것처럼 Write Capacity units, Read Capacity units을 조절할 수 있습니다.

 

단점은, 올릴때는 편리하게 되는데 내릴 때는 제약이 있습니다.

 

 

 

다음은 프로비저닝된 처리 용량에 대한 상하향 정책입니다. AWS Manual에서 캡쳐한 그림입니다.

 

 

DynamoDB Streams

 

DynamoDB Streams에 대해서 이야기 하겠습니다.

 

DynamoDB는 데이터를 저장하는 방식이 Stream 형식으로 다룹니다. 즉, FIFO 형식으로 저장이 됩니다.

 

먼저 들어온 정보가 먼저 바뀌고 하나의 Stream으로 다루기 때문에 다음 그림에서 나오는 장점들을 가지게 됩니다.

 

비동기 식으로 끊어서 테이블에 정보를 저장할 수 있기때문에 높은 내구성을 가질 수 있고,

 

따로 따로 저장이 가능하기에 확장할 때도 편리합니다. 순서가 부여되어 있기때문에 처리 저장시에 기준은 동기적으로 에러없이 저장될 수 있습니다.

 

 

DynamoDB Stream 데이터 읽기 및 프로세싱

 

요청에 대해서 다음과 같이 Stream을 활용해서 저장을 합니다.

 

 

DynamoDB의 Cross Region Replication을 통한 글로벌 DB 복제/동기화

 

다음과 같이 현재 Tokyo의 리전에 있는 DynamoDB의 데이터들을 다른 리전으로 옮길 수 있습니다.

 

DynamoDB의 Point-In-Time Recovery를 통한 DynamoDB Table 시점 복구

 

DynamoDB는 해당 테이블 단위로 저장하는 Stream 구조를 활용해서 Recovery Table을 활용해서 원하는 해당 시점의 Table 상태로 복구할 수 있습니다.

 

 

이상 가장 기본이 되는 AWS의 DynamoDB의 가장 기본적인 개념에 대해서 설명을 마치겠습니다.

 

 

* Reference

1. DynamoDB의 데이터 모델 - http://pyrasis.com/book/TheArtOfAmazonWebServices/Chapter14/01

2. 그림자료 - AWS 공식 사이트