본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
강의 요약
오늘 강의에서는 데이터베이스 선택의 핵심인 RDB와 NoSQL의 차이점과 NoSQL 데이터베이스 중 하나인 Apache Cassandra의 기본 개념과 특징을 다루었다. RDB는 ACID 트랜잭션과 정규화된 스키마를 통해 데이터 일관성을 보장하지만 수평 확장에 한계가 있다. 반면 NoSQL은 특정 워크로드에 최적화된 데이터 모델을 제공하며, Cassandra는 그중에서도 대규모 쓰기 성능과 수평 확장성에 강점을 가진 분산 데이터베이스다.
Cassandra의 핵심 특징
카산드라의 핵심 특징을 알아보자.
Masterless 복제 아키텍처
Cassandra의 가장 큰 특징은 마스터 노드가 없는 완전 분산 아키텍처다. 전통적인 데이터베이스는 Master-Slave 구조를 사용하여 마스터는 쓰기를, 슬레이브는 읽기와 복제를 담당한다. 이 구조는 마스터가 단일 장애 지점이 되며, 노드 추가/제거 시 복잡한 재구성이 필요하고, 마스터 장애 시 선출 과정이 필요하다.
Cassandra의 모든 노드는 동등한 역할을 수행한다. 데이터 쓰기 요청은 임의의 노드로 전달되고, 해당 노드는 Replication Factor에 따라 다른 노드들에 데이터를 복제한다. 데이터 조회 시에도 모든 노드가 요청을 처리할 수 있으며, Gossip Protocol을 통해 클러스터 내 노드들이 지속적으로 통신하며 데이터 위치와 노드 상태를 파악한다.
이 구조는 단일 장애 지점을 제거하고, 노드 추가 시 단순히 클러스터에 참여시키기만 하면 되므로 운영이 단순하다. 마스터 선출이나 복잡한 장애 조치 없이 고가용성을 달성할 수 있다.
조정 가능한 일관성 수준
CAP 정리에 따르면 분산 시스템은 일관성, 가용성, 파티션 내성 중 두 가지만 보장할 수 있다. Cassandra는 기본적으로 가용성을 우선하는 AP 시스템이지만, 일관성 수준을 애플리케이션 요구사항에 맞게 조정할 수 있다.
Replication Factor는 데이터가 몇 개의 노드에 복제될지 결정한다. Consistency Level은 읽기와 쓰기 작업 시 몇 개의 노드가 응답해야 성공으로 처리할지 정의한다. 예를 들어 Replication Factor가 3이고 Write Consistency Level이 QUORUM이면, 3개 노드 중 최소 2개가 쓰기를 완료해야 클라이언트에 성공 응답을 반환한다.
강한 일관성이 필요한 경우 READ + WRITE > Replication Factor 조건을 만족하도록 설정할 수 있다. 하지만 이는 가용성을 희생하므로 Cassandra의 강점을 활용하지 못하게 된다. 대부분의 경우 최종 일관성으로 충분하며, 이것이 Cassandra가 선택되는 주요 이유다.
선형 확장성
대부분의 데이터베이스는 비선형적으로 확장된다. 노드를 2배로 늘려도 성능이 2배 향상되지 않는다. 이는 데이터양이 증가하면 단일 작업의 오버헤드도 증가하기 때문이다. 관계형 데이터베이스는 유니크 키 검증, 외래 키 매핑, 강한 일관성 보장 등으로 데이터가 많아질수록 작업이 복잡해진다.
Cassandra는 선형 확장을 제공한다. Netflix의 벤치마크 결과에 따르면 노드 수에 정비례하여 초당 쓰기 처리량이 증가하며, 100만 writes/s 이상에서도 성능 저하 없이 확장 가능했다. 이는 파티션 키를 통한 데이터 분산과 각 노드의 독립적인 쓰기 처리 때문이다.
높은 쓰기 성능
Cassandra는 LSM Tree 기반의 스토리지 엔진을 사용한다. 쓰기 요청은 먼저 메모리의 Memtable에 기록되고, 동시에 Commit Log에 순차적으로 append된다. Memtable이 가득 차면 SSTable로 플러시되며, 백그라운드 컴팩션이 진행된다.
이 구조는 랜덤 쓰기를 순차 쓰기로 변환하여 디스크 I/O를 최소화한다. 또한 다수의 노드가 동시에 쓰기를 처리할 수 있어 단일 마스터 병목이 없다. Netflix는 1백만 writes/s를 처리하면서도 성능 저하 없이 확장 가능함을 검증했다.
Cassandra를 선택해야 하는 경우
그러면 카산드라를 사용해야하는 경우는 언제일까?
대규모 쓰기 워크로드
초당 수천에서 수백만 건의 쓰기가 발생하는 시스템에서 Cassandra는 탁월한 선택이다. IoT 센서 데이터, 시계열 데이터, 로그 수집 시스템이 대표적이다. 선형 확장과 높은 쓰기 처리량은 이러한 워크로드에 최적화되어 있다.
단일 노드의 리소스 한계
단일 노드는 CPU, 메모리, 네트워크 대역폭이 물리적으로 제한된다. 또한 단일 장애 지점이 되며, 트래픽 패턴에 따른 탄력적 확장이 불가능하다. Cassandra는 노드를 추가하여 리소스를 수평적으로 확장하고, 고가용성을 제공하며, 수요에 따라 노드를 동적으로 조정할 수 있다.
선형 확장이 필요한 환경
비즈니스 성장에 따라 데이터와 트래픽이 증가할 때 Cassandra의 선형 확장은 예측 가능한 용량 계획을 가능하게 한다. 노드를 두 배로 늘리면 성능도 두 배가 되므로, 향후 확장에 대한 불확실성을 제거할 수 있다.
Cassandra를 피해야 하는 경우
그러면 피해야하는 경우도 알아보자.
예측 불가능한 쿼리 패턴
Cassandra의 데이터 모델링은 쿼리 패턴에 의존한다. 파티션 키 없는 쿼리는 모든 노드를 스캔해야 하므로 프로덕션에서 비현실적이다. 쿼리 패턴을 미리 정의할 수 없거나 임시 쿼리가 빈번한 경우 적합하지 않다.
강한 ACID 트랜잭션
Cassandra는 파티션 수준의 원자성만 제공하며 롤백을 지원하지 않는다. 여러 파티션에 걸친 트랜잭션이 일부 성공하고 일부 실패할 경우 불일치가 발생할 수 있다. 금융 시스템처럼 강한 ACID 보장이 필수인 경우 PostgreSQL이나 MySQL이 더 적합하다.
복잡한 관계형 쿼리
Cassandra는 JOIN, 외래 키, 복잡한 집계를 지원하지 않는다. 다대다 관계나 복잡한 JOIN 쿼리가 필요한 경우 관계형 데이터베이스를 선택해야 한다.
소규모 시스템
단일 노드로 충분한 시스템에서 Cassandra는 과도한 복잡성을 추가한다. 분산 시스템의 운영 오버헤드, 학습 곡선, 리소스 비용을 고려하면 단순한 단일 노드 데이터베이스가 효율적이다. Cassandra의 진가는 대규모 확장이 필요한 환경에서 발휘된다.
유연한 스키마
개별 레코드가 서로 다른 컬럼을 가져야 하는 경우 MongoDB 같은 문서 데이터베이스가 더 적합하다. Cassandra는 테이블 수준에서 정의된 스키마를 따라야 한다.
참고 출처
- https://medium.com/geekculture/system-design-solutions-when-to-use-cassandra-and-when-not-to-496ba51ef07a
- https://www.geeksforgeeks.org/system-design/system-design-when-to-and-when-not-to-use-cassandra/
