NoSQL과 Cassandra: 분산 시스템 시대의 데이터베이스 선택
이번 글에서는 분산 시스템 관련 데이터베이스의 새로운 물결인 NoSQL과 그 대표 주자 중 하나인 Cassandra DB에 대해 깊이 있게 다뤄보려고 한다. 왜 기존의 데이터베이스로는 급증하는 데이터를 감당하기 어려워졌는지부터 시작해, NoSQL이 가져온 변화와 그 이면의 한계점 및 주의사항까지 살펴보도록 하자.
1. ⚙️ RDBMS의 한계: 왜 NoSQL이 필요해졌는가?
전통적인 관계형 데이터베이스(RDBMS)는 데이터의 정합성과 무결성을 최우선으로 하는 ACID (원자성, 일관성, 고립성, 지속성) 특성을 철저히 준수한다.
하지만 인터넷 트래픽과 데이터양이 폭발적으로 증가하면서 RDBMS는 근본적인 한계에 부딪히기 시작했다.
- 확장성의 한계: RDBMS는 기본적으로 하나의 강력한 서버에 의존하는 수직 확장(Scale-up) 방식을 취한다. 이는 비용적, 물리적 한계가 명확하다.
- 가용성 및 성능 저하: 데이터가 너무 커지면 Join 연산 시 성능 저하가 발생하며, 단일 서버 장애 시 전체 서비스의 가용성(Availability)이 위협받는다.
이러한 배경에서 대규모 트래픽을 저렴한 서버 여러 대에 분산하여 처리하는 수평 확장(Scale-out)이 가능한 새로운 데이터베이스 패러다임이 요구되었다.
2. ✨ NoSQL의 등장과 특징
NoSQL(Not Only SQL)은 RDBMS가 가지는 확장성의 한계를 극복하기 위해 등장한 데이터베이스의 총칭이다.
- 수평 확장 (Scale-out): 저렴한 범용 서버 여러 대에 데이터를 분산 저장하여 성능을 높인다.
- 유연한 스키마 (Schema-less): 정형화되지 않은 다양한 형태의 데이터를 저장하기 쉽다.
- 다양한 모델: Key-Value, Document, Column Family, Graph 등 서비스의 목적에 최적화된 모델을 선택할 수 있다.
3. 💡 NoSQL의 이론적 배경: CAP 정리와 BASE 모델
NoSQL을 이해하는 핵심은 분산 시스템의 철학을 담고 있는 CAP 정리(CAP Theorem)와 ACID vs BASE 패러다임의 변화에 있다.
A. CAP 정리 (Brewer's Theorem)
분산 시스템은 다음 세 가지 특성 중 단 두 가지만 동시에 만족할 수 있다.
- 일관성 (Consistency, C): 모든 사용자에게 동일한 최신 데이터가 보여야 한다. (RDBMS의 ACID 일관성)
- 가용성 (Availability, A): 시스템은 항상 사용 가능하며, 모든 요청에 대해 응답할 수 있어야 한다.
- 분할 내성 (Partition Tolerance, P): 네트워크 오류로 노드 간 통신이 단절(Partition)되는 상황에서도 시스템이 동작해야 한다.
실제 인터넷 환경은 네트워크 오류(P)를 피할 수 없기 때문에, 분산 DB는 현실적으로 P를 필수로 선택하고, C와 A 중 하나를 선택해야 한다. NoSQL DB들은 대개 가용성(A)과 분할 내성(P)을 선택하고, 일관성(C)을 일부 포기하는 방식으로 확장성을 확보한다.
B. ACID vs BASE
| 구분 | ACID (RDBMS); 데이터 무결성 및 강력한 일관성 | BASE (NoSQL); 확장성 및 고가용성 |
| 특징 | Atomicity, Consistency, Isolation, Durability | Basically Available (기본적인 가용성) Soft state (부드러운 상태) Eventually consistent (최종 일관성) |
NoSQL은 ACID를 포기하고 BASE 모델을 채택한다. 즉, 일시적으로 데이터가 불일치할 수 있지만(Soft state), 시간이 지나면 결국 일관된 상태로 수렴하는 최종 일관성(Eventually consistent)을 허용함으로써 고가용성(Basically Available)을 확보한다.
4. 🛡️ Cassandra DB 집중 분석: 대규모 분산 환경의 해결사
Cassandra DB는 페이스북에서 개발한 뒤 아파치 프로젝트로 이관된 대표적인 Column Family 기반 NoSQL 데이터베이스다. AP(가용성 + 분할 내성)를 선택한 대표적인 사례라고 할 수 있다.
- 특징:
- Peer-to-Peer 분산 구조: 마스터 노드 없이 모든 노드가 동등하여 단일 장애 지점(Single Point of Failure)이 없다. 이는 최고의 고가용성을 보장한다.
- 선형적 확장성: 노드를 추가하는 만큼 성능이 선형적으로 증가하는 뛰어난 수평 확장성을 제공한다.
- "Always-on" 가용성: 높은 부하 환경에서도 서비스 중단 없이 운영될 수 있도록 설계되었다.
5. ⚠️ NoSQL 및 Cassandra의 한계와 주의사항
NoSQL과 Cassandra는 강력한 장점을 가졌지만, RDBMS가 아니기에 발생하는 명확한 한계와 주의사항이 있다.
- NoSQL의 공통적 한계:
- 트랜잭션 및 Join의 어려움: ACID를 완벽히 보장하는 복잡한 트랜잭션 처리나 여러 테이블에 걸친 Join 연산이 어렵다.
- 데이터 모델링의 복잡성: 관계형 사고방식 대신 쿼리 패턴에 맞춰 데이터를 중복 저장하며 모델링해야 한다.
- Cassandra의 주요 한계:
- 복잡한 쿼리 제약: Primary Key나 Secondary Index가 없는 컬럼으로는 검색이 사실상 불가능하다. 복잡한 조건을 가진 Ad-hoc 쿼리에 취약하다.
- 높은 학습 곡선: 데이터 모델링, 복제 전략(Replication Strategy), 튜닝 등 운영을 위한 학습 비용이 높다.
6. 💔 사이드 이펙트: 최종 일관성 (Eventual Consistency)과 모델링
NoSQL, 특히 Cassandra를 도입할 때 발생하는 주요 사이드 이펙트는 데이터 일관성 문제이다.
- 최종 일관성 (Eventual Consistency): Cassandra는 BASE 모델에 따라 데이터가 모든 노드에 복제되는 데 시간차가 있을 수 있다. 이로 인해 짧은 순간 동안 사용자가 최신 데이터가 아닌 과거 데이터를 읽을 수 있다.
- 쿼리 기반 모델링: RDBMS 방식처럼 데이터를 정규화하는 것은 금지된다. 읽기(Read)의 효율을 극대화하기 위해 데이터를 미리 비정규화(De-normalization)하여 중복 저장하는 것이 Cassandra 설계의 핵심이다. 만약 RDBMS처럼 모델링하면 성능을 전혀 활용할 수 없다.
7. 🧐 결론: 최적의 선택을 위한 고민
NoSQL과 Cassandra는 대규모 분산 환경에서 확장성과 가용성이라는 강력한 무기를 제공한다. 하지만 이는 일관성과 트랜잭션이라는 RDBMS의 핵심 가치를 포기하고 얻어낸 결과이다.
데이터베이스를 선택할 때는 CAP 정리의 교훈처럼, '무엇이 더 좋은가'가 아니라 '우리 서비스의 워크로드가 C, A, P 중 무엇을 최우선으로 요구하는가'에 대한 질문에 답해야 합니다. 일관성이 최우선이라면 RDBMS를, 대용량 트래픽과 가용성이 핵심이라면 NoSQL(Cassandra)을 선택하는 것이 현명한 방법이다.
'Newly I Learned' 카테고리의 다른 글
| 분산 락 시스템 (0) | 2025.11.05 |
|---|---|
| 분산 컴퓨팅, RAID의 한계를 넘어 분산 플랫폼의 시대로(대본) (0) | 2025.11.05 |
| 모놀리식 아키텍쳐(MA)의 한계와 마이크로서비스 아키텍쳐(MSA)의 등장 (0) | 2025.10.12 |
| 왜 Entity를 그대로 반환하면 안 될까? – 백엔드 계층 분리의 이유 (3) | 2025.05.22 |
| WebRTC와 디스코드 스트림 세션 (2) | 2025.05.18 |