CAP 이론으로 보는 RDBMS vs NoSQL

RDBMS vs NoSQL

이 글에서는 RDB와 NoSQL에 대해 알아보기 전에 CAP 이론을 살펴보고, CAP 이론을 통해 RDB와 NoSQL에서는 어떤 속성을 희생했는지에 대해서 살펴보자.

CAP 이론

RDBMS와 NoSQL를 살펴볼 때 CAP이론을 살펴보면 좋다. CAP 이론은 분산 시스템에서 위 3가지 속성인 일관성(Consistency), 가용성(Availability), 분할 내성(Partition Tolerance) 중 두 가지만 동시에 보장할 수 있다는 이론이다. 즉, 완벽한 일관성, 가용성, 분할 허용성을 모두 동시에 보장하는 것은 불가능하며 다음 3가지 속성의 특징을 통해 어떠한 상황에서 속성을 희생해야 하는지에 대한 고려를 제공해준다. 하지만 완벽한 CP, AP 시스템은 사용할 수 없으며 대부분 분산 시스템은 CP와 AP의 중간쯤이다.

일관성(Consistency)

모든 노드가 동일한 데이터를 보는 것을 의미한다. 즉, 어떤 노드에서 데이터가 변경되면 다른 모든 노드에서도 일관적으로 변경되어야 하고, 사용자가 분산 데이터베이스 상의 어떤 노드와 통신하는지 상관없이 같은 데이터를 조회할 수 있어야 한다. 따라서 만약 하나의 노드에 쓰기 작업이 이루어졌다면, 이는 모든 복제본에 반영이 되며, 이는 사용자가 어떤 노드와 통신하는 지와 상관없이 같은 데이터를 보여줄 수 있도록 해야 한다. 그러나 시스템이 모든 인스턴스에 변경 내용을 즉각 반영하는 것은 사실상 불가능에 가깝기 때문에 일관성의 목표는 데이터의 동기화가 충분히 빨라 사용상의 문제가 없게끔 해야 한다.

예를 들어, 고객센터에 첫 번째 상담원에게 정보를 얻고, 바로 두 번째 통화에서 다른 상담원과 연결되었다고 하더라도 같은 정보를 공유해야 한다. 이를 일관성이라고 한다.

가용성(Availablity)

가용성은 모든 요청이 응답을 받을 수 있어야 한다는 것을 의미한다. 사용자가 읽기 작업을 하든 쓰기 작업을 하든, 작업이 실패했더라도 사용자는 응답을 받을 수 있어야 하는데 이 때 노드 중 일부가 실패하더라도 시스템은 중단되는 일 없이 계속해서 서비스를 제공할 수 있어야 한다.

예를 들어, 고객센터는 언제든지 연락이 가능하고, 고객은 필요한 정보를 고객센터를 통해 언제든지 알아낼 수 있어야 한다.

분할 허용성(Partition Tolerance)

분할이란 노드 간 통신이 끊어지는 것을 의미한다. 즉, 네트워크 장애나 서버 장애 혹은 다른 이유로 한 노드가 다른 노드와 통신할 수 없을 때 분할이 생겼다고 한다. 이때 분할 허용성이란 네트워크의 분할이 발생하더라도 시스템은 정상 동작해야 한다는 것을 의미한다. 즉, 노드 간의 통신이 실패하거나 지연되더라도 다른 복제 노드가 사용자 요청에 응답하여 시스템은 중단없이 계속해서 동작할 수 있어야 한다. 이는 데이터의 복제본을 여러 다른 노드에 저장하여 처리하는 것을 의미한다. 따라서 분할이 생기더라도 복제본으로부터 데이터를 조회할 수 있고, 분할 허용성은 분산 데이터베이스 시스템에서 필수적이다.

예를 들어, 고객센터에서 본사에 문제가 생겨 통신할 수 없지만 고객센터는 정상적으로 운영되며 통신이 복구될 때까지 잠시 기다리거나 변경을 적용하되, 잠시동안 예전 정보를 알고 있을 수 있어야 한다. 이를 분할 허용성이라고 한다.

RDBMS

RDBMS는 일반적으로 CA 시스템을 만족한다. 이 때, C는 트랜잭션 내 ACID를 보장하는 것이고, A는 Replication을 통해서 지원한다. 이를 통한 RDB를 사용하는 이유에 대해서 얘기하자면 일관성과 가용성을 만족하는 DBMS로 트랜잭션을 통해 동시성을 어느 정도 포기하면서 데이터 무결성 및 정합성을 지원하는 것이라고 할 수 있다. 하지만 CA를 만족하는 대신 스케일 아웃이 어려운 구조라 할 수 있다.

스케일 아웃이 어려운 이유

RDB는 하나의 소스 서버와 두 대 이상의 레플리카 서버를 둘 수 있다. 소스 서버는 원본 데이터를 가진 서버로 모든 쓰기, 수정 삭제 등의 업데이트 작업은 해당 서버에서 이루어진다. 즉, 데이터 일관성과 정합성을 유지하기 위해 소스 서버는 주로 트랜잭션 처리 및 데이터 관리를 담당한다. 하지만 서비스의 80% 이상을 차지하는 읽기 작업은 성능 향상시키기 위해 여러 레플리카 서버에 부하를 분산시킬 수 있다.

만약 RDB의 소스 서버를 여러 대로 운영할 경우, 데이터 일관성과 정합성을 유지하는 것이 복잡해진다. 분산된 서버 간에 데이터 동기화와 일관성을 유지하기 위한 별도의 기술이 필요하고, 여러 RDB 소스 서버 간에 걸쳐 트랜잭션을 관리하는 복잡하며, 분산 환경에서의 트랜잭션 일관성을 보장하기 매우 어렵다. 따라서 RDBMS의 경우에는 스케일 아웃 보다는 스케일 업만 가능하다.

ACID

그리고 위에서 얘기했듯이 RDBMS의 경우에는 여러 클라이언트가 동시에 요청할 때 업데이트 작업에서 데이터 부정합을 방지하고자 트랜잭션을 사용하고, 트랜잭션의 특성인 ACID는 데이터베이스 트랜잭션이 안전하게 수행된다는 것을 보장하는 성질을 가리킨다. ACID의 종류는 다음과 같다.

원자성(Atomicity): 모든 작업이 반영되거나 모두 롤백되어야 한다.
일관성(Consistency): 모든 트랜잭션은 일관성 있는 데이터베이스 상태를 유지해야 한다.
격리성(Isolation): 동시에 실행되는 트랜잭션들이 서로에게 영향을 미치지 않도록 격리해야 한다.
지속성(Durability): 트랜잭션을 성공적으로 끝내면 그 결과가 항상 기록되어야 한다.

RDMBS의 한계

만약 채팅 메시지 데이터를 RDBMS에 넣게 된다면 짧은 시간에 많은 데이터 입력이 처리가 되고, 한정된 규모의 복잡성이 높은 데이터에서 단순한 대량의 데이터가 쌓이며 조회, 삽입이 빈번하게 일어난다. 따라서 데이터가 쌓이게 되면 데이터베이스를 분산시켜야 하지만 위에서 얘기했듯이 RDBMS는 스케일 아웃이 어려운 구조이기 때문에 NoSQL을 사용하여 이를 해결할 수 있다.

NoSQL

NoSQL은 "Not Only SQL"의 약자로, DBMS와는 다른 DB 모델을 지칭하는 용어이다. NoSQL 데이터베이스는 RDB 저장 방식을 사용하지 않고, 다양한 데이터 모델을 통해 데이터를 저장하고 검색하는 방법을 제공한다. 주로 다음과 같은 이유로 대량의 분산 데이터나 유연한 스키마를 다루는데 효과적이여서 RDMBS의 스케일 아웃을 극복할 수 있다.

비정형 데이터 지원 및 유연한 스키마: NoSQL은 스키마가 유연하고, 비정형 데이터를 효과적으로 다룰 수 있는 특성을 가지고 있다. 이는 데이터 모델의 확장을 더욱 용이하게 만들어줄 수 있다. 또한 데이터 모델이 자주 변경되거나, 스키마가 고정적이지 않은 경우 NoSQL은 유연성을 제공하여 스키마 변경이 더 쉽다.
분산 아키텍처 및 대용량 읽기/쓰기 작업: NoSQL 데이터베이스는 여러 노드에 데이터를 분산 저장하고 처리함으로써 스케일 아웃이 가능하다. 분산 아키텍처를 통해 대용량의 데이터 및 높은 트래픽에 대해 효율적으로 처리하여 데이터베이스 시스템에 필요한 성능을 확장하는데 큰 도움이 된다.

이러한 NoSQL은 데이터의 신뢰성 보다는 분산에 중점을 둔 방식으로 약간의 데이터의 유실, 변형 등이 발생할 수 있다. 하지만 빠르게 확장을 하여 대규모 데이터를 저장하고 핸들링할 수 있는 구조를 갖출 수 있어 기존의 RDBMS 형태에는 없는 특징을 가져가는 대신 CP 형태를 가진 NoSQL의 경우에는 A를 포기하고, AP 형태를 가진 NoSQL은 C를 포기해야 한다.

CP(Consistency + Partition Tolerant)

가용성을 포기한 MongoDB, Redis와 같은 NoSQL의 경우에는 데이터를 하나 혹은 여러 개의 프라이머리 노드에 이진 JSON 형태로 저장한다. 각 프라이머리 노드는 로그를 이용해 비동기적으로 업데이트 되는 복제본을 가진 여러 개의 세컨더리 노드를 가진다. 각 노드는 다른 모든 노드와 통신하여 서로의 상태를 확인하고, 만약 몇 초 동안 응답을 받지 못하면 해당 노드는 접근 불가능한 상태로 지정된다.

MongoDB의 경우 Replica Set은 여러 노드 간의 데이터 복제를 제공하여 Primary 노드와 여러 Secondary 노드로 구성된다. 프라이머리 노드가 중단되었다면 세컨더리 노드 중 하나가 프라이머리 노드로 승격된다. 그리고 새로운 프라이머리 노드가 선출되는 동안 시스템은 모든 쓰기 작업은 잠시 사용 불가능(unavailable)한 상태가 된다. 따라서 NoSQL은 CP 시스템으로 분류된다.

Sharding

RDB의 샤딩은 파티션을 통한 수평 분할을 기반으로 하며 특정 테이블의 로우를 여러 서버로 나누어 저장하지만 ACID 트랜잭션을 보장해야 하기 때문에 각 서버에 일부 데이터가 저장되어 있어도, 전체 데이터는 정합성을 유지해야 한다.

반면, NoSQL의 샤딩은 스케일 아웃을 위한 핵심 기술로 데이터를 여러 샤드로 분할하여 분산 저장 및 처리를 가능하게 한다. 각 샤드는 독립적인 MongoDB 인스턴스로 구성되어 샤드 키를 기반으로 데이터를 분산하여 각 샤드에 부하를 균등하게 분배할 수 있다.

NoSQL 유형

키-값 스토어(Key-Value Store): 간단히 키와 해당 키에 연결된 값을 저장한다. 빠르고 간단한 데이터 모델을 가지고 있어 주로 캐싱이나 세션 관리 등에 사용된다. 예로 Redis와 Amazon DynamoDB가 있다.
문서 지향 데이터베이스(Document Stores): 문서 지향 데이터베이스는 JSON이나 BSON과 같은 형식의 문서를 저장한다. 문서는 여러 필드의 컬렉션으로 구성되며, MongoDB가 대표적인 예다.
열 지향 데이터베이스(Column-Family Stores): 데이터를 열 단위로 저장하며, 키를 통해 여러 열을 그룹화한다.