[DynamoDB] 왜 DynamoDB와 같은 Wide Columns DB는 RDB에 비해서 더 확장성(scalability)을 가지는가 ?

개요

안녕하세요. DynamoDB는 Wide Columns DB의 일종입니다. 일반적으로 알려져 있기로 DynamoDB는 RDB 보다 훨씬 좋은 확장성(scalability)를 가지고 있다고 알려져있습니다. 그렇다면 어떻게해서 이러한 구조를 가질 수 있을까요 ? 오늘은 확장성이란 무엇인지 먼저 확인하고 RDB와 DynamoDB에서 어떻게 확장성을 가져가는지에 대해서 알아보는 시간을 가져보겠습니다.

확장성(Scalability) 란 ?

먼저 확장성(Scalability)이란 서비스의 요구사항 및 트래픽, 데이터가 증가됨에 따라 이를 처리할 때 성능적인 저하 없이 성장할 수 있는 능력이라고 정의할 수 있습니다.

확장성은 크게 2가지 방식으로 달성할 수 있습니다. 수직적 확장(Scale-Up)과 수평적 확장(Scale-Out)입니다. 수직적 확장은 기존 서버의 하드웨어적인 성능을 업그레이드 시켜 성능을 향상시키는 방식입니다. 반대로 수평적 확장은 서버를 추가하여 서버의 부하를 분산 시키는 방식입니다.

수직적 확장(Scale-Up)

수직적 확장을 하는 방법으로는 서버의 성능을 향상시키는 방식으로 CPU, RAM, 그리고 저장 공간을 추가하여 업그레이드 시킬 수 있습니다. 이는 한 서버가 최대로 수용할 수 있는 CPU, RAM, 저장 공간이 있기 때문에 물리적인 한계를 가집니다. 반면 이는 한 서버의 성능을 업그레이드 하기 때문에 서버의 성능이 유지되는것이 아니라 향상될 수 있습니다.

예시

• 16GB RAM 서버를 64GB RAM 서버로 업그레이드
• 싱글 코어 CPU에서 멀티코어 CPU로 업그레이드

일반적으로 단일 Master Node를 가지는 RDB 데이터베이스에서 많이 사용됩니다.

수평적 확장(Scale-Out)

수평적 확장을 하는 방법으로는 서버(Node)의 수를 늘리는 방식입니다. 이는 서버를 늘리고 앞에 Load Balancer 등을 두어 부하를 분산 시키는 방식으로 확장성을 달성하는 방식입니다. 서버의 갯수를 통하여 확장성을 달성하기 때문에 이론적으로는 물리적인 한계를 가지진 않습니다.

어플리케이션에서는 서버를 여러대를 두어 분산 배치하는 방식으로 구현할 수 있고, DB의 경우에는 샤딩을 하여 여러 서버에 데이터를 나눠서 저장하는 방식으로 사용할 수 있습니다.

결론

이러한 특성으로 수평적 확장이 수직적 확장 보다는 더 확장성을 가지고 있다고 말할 수 있겠습니다.

RDB 구조 개요

위에서 수평적 확장이 물리적 한계가 없기 때문에 상대적으로 수직적 확장 보다는 확장성이 높다는 결론을 내었습니다. 그렇다면 RDB의 구조와 확장성을 달성하는 방법에 대해서 알아보도록 하겠습니다. 기본적인 RDB는 수평적 확장을 통해서 확장성을 확보할 수 있을까요 ?

답은 아니오입니다. 그 이유는 Join에 있습니다.

RDB의 경우 정규화를 통한 Join 메커니즘을 통해서 Entity 간의 연관관계를 달성합니다. 정규화란 데이터베이스의 중복을 최소화하고 데이터 무결성을 유지하기 위한 과정인데요. E-Commerce라고 하였을 때 유저가 주문한 리스트를 나타낸다고한다면 RDB의 경우 아래와 같이 데이터를 구성하는것이 일반적입니다.

• 1 정규화 : 모든 컬럼이 원자적(Atomic)인 값을 가져야 하며, 중복된 컬럼이나 중첩된 데이터가 없어야 한다.
• 2 정규화 : 1NF를 만족하고, 기본 키(Primary Key)에 부분 함수 종속(Partial Dependency)이 없어야 한다.
• 3 정규화 : 기본 키에 이행적 함수 종속(Transitive Dependency)이 없어야 한다.

User와 Order의 관계는 1 : N 이라는 관계를 가지는것을 알게되며 정규화를 통해서 나온 테이블 구조가 아래와 같게됩니다.

select order.* from order o join user u on u.id = o.user_id where user_id = ?

여기서 알 수 있는 점은 Join을 하기 위해서는 동일한 서버(샤드)에 두 테이블의 데이터가 모두 존재해야한다는 사실입니다. 만약 두 테이블이 각 다른 노드에 존재한다면 네트워크를 통해서 조인이 이루어지고 이는 성능에 지대한 영향을 주게됩니다.

RDB는 모든 테이블은 어떠한 방법을 통해서도 Join을 할 수 있습니다. 따라서 테이블을 분산할 수 없는 구조를 가지고 있는것입니다. Key-Base 샤딩, 범위 기반 샤딩 등이 있을 수 있지만 이것은 RDB의 복잡도가 기하급수적으로 늘어납니다. 추가저긍로 사실상 일부 데이터들에 대해서는 서로간의 Join을 포기한다는 것을 내포하고 있음을 의미합니다. 즉, 특정 쿼리에 대한 최적화일 뿐, 범용적인 해결책은 아닙니다.

DynamoDB 구조 개요

전통적인 관계형 데이터베이스(RDB)는 정규화된 테이블을 기반으로 데이터를 저장하고, 여러 테이블 간 Join을 통해 데이터를 조회하는 방식이 일반적입니다. 하지만 이러한 구조는 수평적 확장을 어렵게 만들며, 데이터가 여러 노드로 분산될 경우 Join을 수행하기 위해 네트워크 통신이 발생하여 성능이 저하됩니다. 반면 NoSQL 데이터베이스, 특히 AWS DynamoDB는 설계 단계부터 수평적 확장(Scale-Out)에 최적화된 구조를 가지고 있습니다.

왜냐하면, DynamoDB는 NoSQL의 Key-Value Store 모델을 기반으로 하여 데이터를 비정규화(Denormalization)하여 저장하며, 자동 샤딩(Auto-Partitioning) 기능을 제공하여 수평적 확장이 매우 용이합니다. 이러한 특성 덕분에 DynamoDB는 대량의 데이터를 처리하는 글로벌 서비스, 트래픽이 급격히 증가하는 애플리케이션, 실시간 데이터 처리가 중요한 환경에서 뛰어난 성능을 발휘합니다.

위의 RDB의 동일한 예제를 가지고 DynamoDB에 적재한다고 해보겠습니다. 그러면 아래와 같은 데이터 구조를 가질 수 있습니다. Partition Key로 User_Id를 가지고 Sorted_Key로 Order_Id를 가지도록 했습니다.

위 테이블 구조를 보시면 1개의 테이블에서 1 : N의 구조를 가지게해서 Partition Key로 조회시 한번에 쿼리할 수 있도록 합니다. 또한 User 정보 조회 또는 주문 정보만 조회도 Query 할 수 있는 구조입니다. 이러한 비정규화(Denormalization) 방법은 다음에 제대로 알아보도록 하겠습니다.

근본적으로 DynamoDB에서는 Partition Key와 Sorted Key가 DynamoDB의 Primary Key로 사용자는 위 2개의 Key를 통해서만 데이터에 접근을 할 수 있습니다. 이것은 Join을 할 수 없다는 제약 조건과 합쳐져 확장성을 낮추는 케이스를 방지하게 하여 높은 확장성을 가질 수 있도록 해줍니다.

이렇듯 DynamoDB는 Join이 없다는 제약 조건으로 Partition Key를 통해서만 접근하기 때문에 이를 Hashing Key로 사용해서 데이터를 조회하고 이렇기 때문에 무한히 부하분산을하여 우월한 확장성을 가질 수 있게 되는것입니다.

실제로 Data를 저장 및 읽는 매커니즘은 아래와 같습니다. Partion Key를 기준으로 Node에 분산되어 저장되고 읽을 수 있습니다.

마무리

오늘은 DynamoDB가 RDB 보다 좋은 확장성을 가져가는 방법에 대해서 알아보았습니다.

물론 이러한 확장성을 가져가기 위해서 포기한 부분도 분명히 존재하고 RDB 와는 접근하는 방법도 다르게 가져가야하는 것도 사실입니다.

모든 것은 트레이드 오프가 있다는 것을 리마인드 하게됩니다.

이러한 부분에 대해서는 다음 포스팅에서 천천히 알아보도록 하겠습니다.

감사합니다.

참조

[1] The DynamoDB Book by Alex DeBrie