DynamoDB의 구조

다이나모는 분산 DB 환경에 있어서 중요한 제반을 쌓은 데이터베이스 시스템 중 하나다.
그 개략적인 구조에 대해서 정리해본다.

역사

DynamoDB는 처음부터 서비스로 공개하려고 만든게 아니라, 아마존에서 내부 시스템 관리용으로 사용하던 것을 고도화하던 것이 어쩌다보니 공개 서비스가 된 것이다.
아마존도 처음에는 RDB를 쓰다가, 나중에는 팀마다 가벼운 Dynamo의 프로토타입 - KV DB를 단일 노드로 띄워서 구성하곤 했었다. 그러다가 매번 설치하고 구성하는게 불편하니까 이래저래 엮다보니 분산 DB가 탄생한 것이다.

이게 AWS 서비스로서 출시된건 2012년이지만, 그 이전부터 어느 정도 내부적으로 완성해서 사용하기는 했을 것이다. 한참 전인 2007년에 설계를 어느 정도 마치고 이론적 기반을 "DynamoDB 백서"로 공개했다. 지금도 자유롭게 읽을 수 있다.

게다가 DynamoDB 자체는 오픈소스가 아니지만 DynamoDB 개발자들이 오픈소스 활동도 많이 하고 해서 전반적인 분산 DB 환경에 큰 영향을 끼쳤다.
대표적으로 CassandraDB가 DynamoDB의 아이디어를 상당수 가져가서 만들어진 오픈소스 DB다.

인덱스 구조: LSM 트리

CassandraDB를 포함한 NoSQL DB들이 전통적인 RDB들과 차별화되는 부분이 인덱스 구조다.

LSM 기반의 인덱스 시스템을 사용하고, 이를 기반으로 데이터를 저장하기 때문에 RDB 대비해서 write 성능, 그 중에서도 append(insert) 성능이 매우 뛰어나다.

자세한 원리나 구조는 별도 포스트를 참조한다.

https://blog.naver.com/sssang97/223232181952

테이블 구조

DynamoDB는 단순한 Key-Value 데이터베이스라서, 스키마를 엄밀하게 정의하지는 않고 쓴다.
일반 값들은 그때그때 아무렇게나 쑤셔넣을 수 있고, 중요한건 파티션 키와 정렬 키다. 이건 사전에 정의해야 한다.

https://medium.com/rate-labs/%EC%95%84-%ED%95%B4%EB%B4%90-dynamodb-%EB%93%A4%EC%96%B4%EA%B0%84%EB%8B%A4-f8da282bc625
파티션 키는 가장 기본이 되는 키로, 저 값을 기준으로 어떤 파티션에 저장할지를 결정한다.
파티션키만 사용하고 정렬키를 사용하지 않는다면 파티션 키가 데이터의 유일성을 보장한다.

파티션키와 정렬키를 사용할 경우에는 파티션키+정렬키의 조합으로 데이터 유일성이 보장된다.

데이터를 탐색할 때는 항상 데이터가 저장된 파티션을 찾고 -> 파티션에서 정렬 키를 기준으로 스캔을 하기 때문에 파티션키+정렬키가 항상 조건에 포함되는 것이 이상적인 사용 방식이다.

테이블 사용 설계 관련해서는 별도 포스트를 참조한다.
https://blog.naver.com/sssang97/223680577129

CAP

https://blog.naver.com/sssang97/223115732041
DynamoDB는 multi master 구조로 일관성을 희생하는 대신, 매우 높은 가용성과 쓰기/읽기 확장능력을 달성한 시스템이다.

그래서 일반적으로 읽기를 해서 값을 가져오더라도 그게 최신 값이 아닐 수도 있다.

하지만 강력한 일관성 옵션 ConsistentRead를 사용해서 읽기를 요청한다면 최신 값을 가져오도록 할 수 있다. 대신 읽기 비용 단위가 2배로 과금된다.

트랜잭션

DynamoDB에도 의외로 트랜잭션 단위가 제공된다.

TransactWriteItems API를 사용하면 최대 100개의 쓰기 작업을 한번에 묶어서 원자적으로 처리되게 할 수 있다. 여러 테이블에 동시에 날리는 것도 가능하다.
https://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/transaction-apis.html

DynamoDB의 분산 트랜잭션은 2단계 커밋을 응용해서 만들어졌다.
https://blog.naver.com/sssang97/223465481384

트랜잭션 처리도 통상적으로 기존 쓰기/읽기와 비교해서 2배 정도의 요금 단위가 부과된다고 보면 된다.

이건 경쟁자인 카산드라에 비해 우위를 가지는 부분이다. 카산드라는 트랜잭션 단위가 없다.

동시 쓰기 처리

DynamoDB에서 동시에 동일 데이터에 대해서 수정을 시도한다면 어떻게 될까?

DynamoDB는 시간값, 타임스탬프를 기준으로 최신의 값만을 반영하고 예전 값은 버리는 방식을 취한다.
근데 구글처럼 원자시계 달고 요란법석을 떤 것 아니라서 미세한 시간 오차로 인해서 먼저 들어온 수정이 반영될 수도 있다는게 단점이다.

동시 처리를 엄밀하게 처리하고 싶다면 낙관적 락을 조건절 Update 기반으로 직접 구현해야 한다.

서버리스 구조

DynamoDB는 온디맨드 모드로 사용하면 초기 비용이 매우 낮고, 꽤 저렴하게 사용할 수 있다.
이런 비용 효율성은 어떻게 나오는 걸까?

사실 이것도 Lambda 등과 비슷한 방식으로 리소스 활용도를 높이는 거라고 보면 된다.
그래서 하나의 물리 장비에 여러명의 데이터를 우겨넣는다. 당신이 방금 넣은 DynamoDB의 데이터는 다른 사용자의 것들과 섞여있을 수 있다.

일관된 해싱?

분산DB에서 가장 중요한 것 중 하나가 또 지속적으로 노드를 추가하고 데이터를 분배하는 것이다.

DynamoDB의 초기 버전에서는 일관된 해싱 매커니즘을 사용해서 지속적으로 노드가 추가되는 상황에서도 최대한 고르게 데이터를 분배하고, 데이터의 이동을 최소화했었다.
https://blog.naver.com/sssang97/223457713545
하지만 엄밀하게 말해서, 서비스로서 완성된 AWS DynamoDB에서는 이러한 방식을 사용하지 않는다. 각각의 마이크로서비스를 기반으로 비교적 느슨하게 연결되어있기 때문이다.

스토리지 노드

DynamoDB에서 가장 근간이 되는 밑바닥은 "스토리지 노드" 단위다.
이건 말이 노드지, 사실 하나의 클러스터다.

여기에는 쓰기를 담당하는 master 노드 하나, 읽기를 담당하는 slave 노드가 둘이 들어있고, 각각의 노드를 고가용성을 위해 별도의 가용영역에 프로비저닝된다.

합의 알고리즘은 Paxos를 사용하고, master 노드에 문제가 생긴하면 다른 노드를 master로 선출한다.
복제는 항상 비동기적이기 때문이 Slave는 낮은 일관성, 최종 일관성만을 제공한다.

그리고 유저가 API를 사용해서 DynamoDB에 접근한다면, 내부 라우터를 거쳐서 스토리지 노드를 선택하고 DB 작업을 처리하게 되는 것이다.

경쟁자: CassandraDB

CassandraDB는 애초에 DynamoDB 개발자가 만든 것이기도 하고, 전반적인 구조와 목표에 있어서 DynamoDB와 많은 부분을 공유한다. 같이 알아두면 좋을 것이다.
https://blog.naver.com/sssang97/223706344662

참조
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBMapper.OptimisticLocking.html
https://cassandra.apache.org/doc/latest/cassandra/architecture/dynamo.html
https://www.scylladb.com/learn/dynamodb/introduction-to-dynamodb/
https://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/transaction-apis.html#transaction-capacity-handling
https://medium.com/rate-labs/%EC%95%84-%ED%95%B4%EB%B4%90-dynamodb-%EB%93%A4%EC%96%B4%EA%B0%84%EB%8B%A4-f8da282bc625
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.Partitions.html
https://www.usenix.org/system/files/atc23-idziorek.pdf
https://medium.com/@syedshamail3/understanding-the-internal-architecture-of-amazon-dynamodb-e9dccb8be8de
https://www.usenix.org/conference/atc22/presentation/elhemali