카프카 스터디를 통해 데이터의 '흐름'을 배웠다면, 이제 그 데이터가 최종적으로 저장되고 활용되는 '저수지'에 대해 알아볼 차례입니다. 아파치 카산드라(Apache Cassandra)는 대용량의 데이터를 여러 서버에 분산하여 저장하고, 일부 서버에 장애가 발생해도 중단 없이 서비스를 제공하는 데 특화된 NoSQL 데이터베이스입니다.
과거에는 하나의 강력한 RDBMS가 모든 데이터를 책임지는 '만능 데이터베이스' 시대였습니다. 하지만 페이스북, 구글, 아마존과 같은 거대 기업들이 하루에 수십억 건의 데이터를 RDBMS 하나로는 도저히 감당할 수 없게 되면서, 특정 문제에 특화된 다양한 NoSQL 데이터베이스가 등장했습니다.
현대의 아키텍처는 "하나의 DB가 모든 걸 해결하는 시대는 끝났다"는 철학 아래, 문제에 맞는 최적의 DB를 조합해서 사용하는 'Polyglot Persistence(폴리글랏 퍼시스턴스)'가 표준으로 자리 잡았습니다.
요즘 서비스의 백엔드 아키텍처를 열어보면, 여러 DB가 각자의 역할을 나누어 협력하고 있습니다.
| DB 종류 | 대표 주자 | 주요 역할 및 사용 사례 |
|---|---|---|
| RDBMS | MySQL, PostgreSQL | 돈, 회원 정보, 주문 내역 등 데이터 정합성이 목숨처럼 중요한 핵심 데이터 저장 (트랜잭션 보장) |
| Document DB | MongoDB | 스키마가 유연해야 하는 데이터 (e.g., 사용자 프로필, 상품 카탈로그, 로그) |
| In-Memory DB | Redis | 캐시, 세션 스토어, 실시간 랭킹 보드 등 극강의 속도가 필요한 데이터 |
| Wide-Column DB | Cassandra, DynamoDB | 엄청난 쓰기 트래픽과 무중단 운영이 필수적인 데이터 (e.g., 채팅, IoT, 시계열 데이터) |
| Search Engine | Elasticsearch | 복잡한 전문(Full-text) 검색 기능이 필요한 데이터 |
카산드라의 특징을 이해하는 가장 좋은 방법은 우리가 익숙한 관계형 데이터베이스(RDBMS, e.g., MySQL)와 비교하는 것입니다.
모든 책(데이터)이 한 곳에 완벽하게 분류되어 보관됩니다. 복잡한 연관 검색(JOIN)에 강하지만, 도서관 건물(서버)에 문제가 생기면 전체 서비스가 마비(SPOF, Single Point of Failure)될 수 있습니다. 더 많은 책을 보관하려면 도서관을 더 크게 증축(Scale-up)해야 하는데, 이는 비용이 많이 들고 한계가 명확합니다.
똑같은 책들을 여러 동네 도서관(노드)에 복제해 둡니다. A 도서관이 문을 닫아도(노드 장애), B 도서관에서 똑같은 책을 빌릴 수 있어(고가용성) 서비스가 중단되지 않습니다. 손님이 많아지면 C 동네에 도서관을 하나 더 짓기만 하면(수평 확장, Scale-out) 됩니다. 다만, "A 도서관의 역사책과 B 도서관의 과학책을 연관 지어 찾아달라"는 식의 복잡한 요청(JOIN)은 지원하지 않습니다.
위 비유에서 나온 '여러 동네 도서관'이 바로 카산드라의 핵심 구조입니다.
카산드라를 이해하기 위한 가장 중요한 이론적 배경은 CAP 이론입니다. 이 이론은 분산 컴퓨팅 시스템이 아래의 세 가지 특성 중 최대 두 가지만을 동시에 보장할 수 있다는 것을 설명합니다.
현대의 분산 시스템은 언제든 발생할 수 있는 네트워크 장애(P)를 기본적으로 감수해야 하므로, 실질적인 선택은 CP(일관성 우선)와 AP(가용성 우선) 사이에서 이루어집니다.
카산드라는 강력한 일관성(Strong Consistency) 대신 최종적 일관성을 지향합니다. 이는 "지금 당장은 데이터가 다를 수 있지만, 결국에는(eventually) 모든 복제본이 동일한 상태를 갖게 될 것"을 보장하는 모델입니다. 카산드라는 'Read Repair'나 'Hinted Handoff'와 같은 메커니즘을 통해 백그라운드에서 지속적으로 데이터 불일치를 해소합니다.
맞습니다. 대부분의 일반적인 웹 서비스는 쓰기(Write)보다 읽기(Read) 요청이 압도적으로 많습니다. 그래서 RDBMS는 보통 읽기 성능에 더 최적화되어 있습니다.
하지만 카산드라가 주목받는 이유는 평상시의 99%가 아닌, 시스템이 감당하기 어려운 1%의 '쓰기 피크(Peak)' 상황을 해결하기 위함입니다. "선착순 쿠폰 발급" 이벤트처럼 특정 순간에 쓰기 요청이 폭주할 때, RDBMS는 병목 현상으로 멈출 수 있지만 카산드라는 이 요청들을 막힘없이 처리해낼 수 있습니다. 즉, 카산드라는 서비스의 가장 치명적인 순간을 버텨내기 위한 '결전 병기'로 사용되는 경우가 많습니다.
"모든 아이템마다 할인 정보를 계산해야 한다"는 것은 엄청난 읽기 트래픽을 의미합니다. 카산드라는 다음과 같은 특성으로 이 문제를 해결합니다.
WHERE item_id = ?)에 최적화된 방식으로 데이터를 저장합니다. 복잡한 JOIN을 포기하는 대신, 가장 빈번한 핵심 조회의 응답 속도를 극한으로 보장합니다.결론적으로, 카산드라를 선택하는 이유는 단일 요청의 속도 때문이 아니라, 대규모 트래픽 상황에서도 시스템 전체가 예측 가능한 낮은 지연시간을 유지하며 안정적으로 동작할 수 있기 때문입니다.
Q: "RDBMS와 Cassandra의 가장 근본적인 차이점을 CAP 이론과 연관 지어 설명해주세요."
A: "RDBMS는 단일 서버에서 동작하며 데이터의 일관성(Consistency)과 가용성(Availability)을 모두 보장하는 CA 시스템을 지향합니다. 하지만 분산 환경에서는 네트워크 단절(Partition Tolerance)을 피할 수 없으므로 CA는 선택 불가능한 옵션입니다. 카산드라는 이 P를 기본 전제로, C를 다소 희생하는 대신 A(가용성)를 극대화한 AP 시스템입니다. 즉, 어떤 상황에서도 쓰기 요청을 받아내고 응답하는 것을 최우선으로 하며, 데이터는 '최종적 일관성'을 통해 동기화됩니다. 반면 MongoDB 같은 CP 시스템은 가용성을 희생하여 일관성을 지키는 선택을 한 것입니다. 따라서 비즈니스 요구사항이 강력한 일관성인지, 무중단 고가용성인지에 따라 기술 선택이 달라집니다."
Point: 단순히 AP 시스템이라고 말하는 것을 넘어, '왜 분산 환경에서 P가 기본 전제인지', 'C와 A 사이의 트레이드오프 관계'를 명확히 설명하고, 다른 NoSQL(e.g., MongoDB)과 비교하여 답변하면 깊은 이해도를 보여줄 수 있습니다.