[DynamoDB] 아키텍처 구조 이해하기 (flow, RR, Partition)

목차

• DynamoDB와 같은 Wide Columns DB는 RDB에 비해서 더 확장성(scalability)을 가지는가 ?
• 그거 알아요 ? DynamoDB는 HTTP로 통신한다는거 (RDB 운영 이슈, Transaction, Conflict)
• DynamoDB에서 사용하는 용어 정리
• DynamoDB는 사용한 만큼 비용을 냅니다
• http API 실습히가 - Write 편
• http API 실습히가 - Read 편
• 제약사항과 그 철학
• 아키텍처 구조 이해하기
• Schema Modeling 하는 과정

개요

안녕하세요. DynamoDB의 사용에 대해서 알아보는 과정도 어느덧 후반부에 접어들었습니다. 제가 생각했던 Contents는 이제 이것과 Single Table Design, 그리고 DynamoDB Table을 설계하는 과정이 남아있습니다. 남은 아티클도 재미있게 봐주세요.

오늘은 DynamoDB의 아키텍처 구조에 대해서 알아보는 시간을 가져보도록하겠습니다. 이전 [DynamoDB] 왜 DynamoDB와 같은 Wide Columns DB는 RDB에 비해서 더 확장성(scalability)을 가지는가 ? 시간에 몇번 구조를 이야기했습니다만 구조만을 제대로 이해하는 시간이 별도로 필요하다고 판단하여 이렇게 다시한번 가져오게 되었습니다.

Request Router system flow

DynamoDB는 HTTP로 통신한다는 것을 이전 [DynamoDB] 그거 알아요 ? DynamoDB는 HTTP로 통신한다는거 (RDB 운영 이슈, Transaction, Conflict 시간에 이야기했습니다. 그리고 실제 HTTP 스키마도 알아보았는데요. 그렇다면 실제로 DynamoDB 내부에서는 어떤 flow를 가져갈까요 ?

도식화하면 아래와 같습니다. 아래 이미지는 https://youtu.be/OhKVFQBYnYY?si=HuJbNytmPCnyqRcH 에서 가져온 것입니다.

1. 클라이언트가 DynamoDB로 요청을 전송
2. HTTP를 통해서 데이터가 DynamoDB에 도달
3. Authentication System을 통해서 인증 및 인가 확인
4. Partition Metadata System을 통해서 올바른 leader partition을 선택
5. Table에 남아있는 WCU와 RCU를 분석하여 남아있는 Token이 있는지 확인
6. Storage Node인 Partition에 데이터를 저장 또는 데이터 읽기

Consistency

위 Flow에서 Storage 노드에 저장할 때의 메커니즘만 추가로 확인해보도록 하겠습니다. 저장에 대한 Flow를 나열해보면 아래와 같습니다.

1. 데이터를 저장할 때 Request Router는 Leader Parittion에만 요청하여 저장
2. 내부의 Logs Propagation을 통해서 비동기적으로 데이터를 타 region의 2개의 replica data를 옮기는 과정
3. 결과적으로 1개의 Leader Partition과 2개의 Replica Partition에 데이터 저장

결과적으로 데이터가 완전히 저장되는것은 Eventually Consistency를 따른다는 것을 알 수 있습니다. 그리고 Repolica에 전달되기는 수 ms 가 걸린다고 알려져있습니다.

반대로 데이터를 읽는다고 했을 때는 아래와 같은 flow를 가집니다.

1. Request Router는 Leader Partition 뿐만 아니라 Replica Partition 또한 확인
2. 확인된 결과를 반환.

Eventually Consistency가 기본이기 때문에 쓰고 바로 읽는 요청을 하면 최신 데이터를 못읽어오는 케이스가 생길 수 있습니다.

이러한 내용을 그림으로 나타내면 아래와 같습니다.

이러한 이슈를 해결하기 위해서 DynamoDB는 Read에 대해서 Strong Consistency를 제공합니다.

• Read 에 Strong Consistency로 요청하면 Lead Partition으로 요청을 보냅니다.

Strong Consistency는 결과적으로 Lead Partition에 부하가 가기 때문에 이는 기본 요청에 비해서 2배의 RCU 소모를 가집니다. CU를 기반으로하여 부하를 제어하는 로직이 동일하게 적용되고 관리되는 것입니다.

추가로 핫 파티션에 대해서 내부적으로 부하를 분산하기 위해서 Partition split을 제공한다고 합니다. Partition Split은 아래의 Flow로 이루어집니다. https://www.youtube.com/watch?v=ld-xoehkJuU 을 참고했을 때 Partition Split에 대해서 아래와 같이 대응할 수 있도록 DynamoDB의 내부 구조가 되어있다고 확인할 수 있었습니다.

1. 테이블에 hot key가 생겨, 특정 파티션에 write 트래픽이 몰림.
2. GAC(Global Admission Control)가 이를 감지.
3. 해당 파티션을 두 개로 split함 (예: key range 기준으로 나눔).
4. 내부적으로 쓰기 라우팅 로직이 업데이트됨.
5. 이후의 쓰기 요청은 새로운 파티션으로 정확히 분배됨.

Patition (Storage)

Storage Node의 구성요소를 간단히 알아보도록 하겠습니다. 간단히 요약하면 Storage의 구성요소는 B-Tree와 Replication Log가 있습니다.

DynamoDB의 Storage 구조는 B-Tree로 되어있습니다. 따라서 Write시에 O(logn), 그리고 Read시에 O(logn)을 보장하는 자료구조입니다.

그리고 Replication Log가 있습니다. 이것은 RDB의 Redo Log라고 보시면 됩니다. 이를 통해서 다양한 작업이 이루어 집니다. 첫번째로 Replica Partition으로의 전송되는 Source Of Trues의 역할을 합니다. 여기에 로그가 기록되면 이를 토대로 전파되어지는 것입니다. 두번째로 Dynamo Stream에서 이를 통해서 CDC를 구현하고 있습니다.

이미지로 나타내면 아래와 같습니다.

Auto Admin

DynamoDB 안에는 저희는 직접 건드릴 수 없지만 굉장히 중요한 일을 하는 Auto Admin이 있습니다. 이는 DynamoDB 내부적으로 자동화된 DBA로써 여라가지 일을 합니다. 하는 역할에 대해서 간단하게 리스팅만 해보겠습니다.

• Partition Repair
• Create Tables
• Table Provisioning
• Split Partition

마무리

오늘은 DynamoDB의 아키텍처 구조를 이해하기 위한 글을 작성해보았습니다.

다음 시간에는 RDB와는 다른 Dynamo Table을 설계하는 과정에 대해서 알아보도로 하겠습니다.

감사합니다.

참조

[1] [https://www.youtube.com/watch?v=yvBR71D0nAQ&t=1s]https://www.youtube.com/watch?v=yvBR71D0nAQ&t=1s

[2] https://timothya.com/learning/amazon-dynamodb-under-the-hood/?utm_source=chatgpt.com

[3] https://youtu.be/ld-xoehkJuU?si=Kg3U7iHfYo_3HAsr