카산드라의 고가용성과 확장성의 비밀은 바로 링(Ring) 아키텍처에 있습니다. 카산드라 클러스터에는 리더나 마스터와 같은 특별한 노드가 존재하지 않으며, 모든 노드가 동등한 P2P(Peer-to-Peer) 방식으로 통신합니다. 이 노드들이 모여 하나의 거대한 가상의 링을 형성하고 데이터를 분산하여 책임집니다.
이 링 아키텍처를 이해하기 위해서는 네 가지 핵심 구성요소의 역할을 알아야 합니다.
링 아키텍처의 구성 요소를 살펴보기 전에, 카산드라의 전체적인 계층 구조를 이해하면 큰 그림을 잡는 데 도움이 됩니다. 각 용어가 어떤 관계를 가지는지 아파트 단지에 비유한 다이어그램으로 확인해 보겠습니다.
(내부 구조는 101동과 유사)
하나의 클러스터는 여러 데이터 센터로 구성될 수 있고, 각 데이터 센터는 여러 랙으로, 각 랙은 여러 노드(서버)로 구성됩니다. 그리고 실제 데이터는 파티션이라는 단위로 묶여 각 노드에 분산 저장됩니다. 이제 이 구조를 기반으로 각 컴포넌트가 어떻게 상호작용하는지 자세히 알아보겠습니다.
이 거대한 링(클러스터)이 문제없이 돌아가도록 만드는 네 명의 핵심 플레이어(컴포넌트)가 있습니다. 이들의 역할을 먼저 이해하면 뒤따르는 내용이 훨씬 쉬워집니다.
이제 이 4인방이 각자 어떤 일을 하는지 자세히 살펴보겠습니다.
클라이언트로 부터 데이터가 들어왔을 때, 클러스터 내의 수많은 노드 중 어떤 노드에 저장할지를 결정하는 컴포넌트입니다.
링을 360도짜리 원형 운동장, 노드를 각 구역의 관리자라고 상상해봅시다. 입장하는 관객(데이터)은 고유 번호(파티션 키)가 적힌 티켓을 가지고 있습니다. 파티셔너는 이 티켓 번호를 보고 "당신은 180번 좌석으로 가세요!"라고 위치(토큰)를 지정해줍니다. 그러면 180번 좌석이 있는 구역의 관리자(노드)가 관객을 안내하는 것과 같습니다.
마스터 노드가 없는 카산드라에서 노드들은 서로의 상태(Up/Down, Load 등)를 어떻게 파악할까요? 바로 '가십(Gossip, 뜬소문)'을 통해 알게 됩니다.
이 가십 프로토콜 덕분에 특정 노드에 장애가 발생하거나 새로운 노드가 추가되었을 때, 클러스터가 외부의 개입 없이 자율적으로 상황을 인지하고 대처할 수 있습니다.
카산드라는 단일 장애점(SPOF)을 없애고 데이터 유실을 방지하기 위해 데이터를 여러 노드에 복제합니다. 이때 "어떻게, 어디에 복제할 것인가"를 결정하는 것이 복제 전략과 스니치의 역할입니다.
데이터를 몇 개, 그리고 어떤 노드에 복제할지를 결정하는 규칙입니다.
RF=3이면 원본 1개와 복제본 2개, 총 3개의 노드에 데이터가 저장됩니다.
NetworkTopologyStrategy가 "어떤 노드가 어떤 DC의 어떤 랙에 있는지"를 알 수 있도록 네트워크 토폴로지 정보를 제공하는 컴포넌트입니다. 스니치가 '지리 정보 전문가'라면, 복제 전략은 그 정보를 활용하는 '보험 설계사'인 셈입니다.
EC2Snitch, GoogleCloudSnitch)이나 직접 구성하는 환경에 따라 적절한 것을 선택해야 합니다.GossipingPropertyFileSnitch는 운영 환경에서 자주 사용되는 스니치로, 각 노드의 DC/랙 정보를 설정 파일에 정의하면 이 정보가 가십 프로토콜을 통해 클러스터 전체에 전파됩니다.이러한 유기적인 협력을 통해 카산드라는 뛰어난 확장성과 장애 허용(Fault Tolerance)을 달성합니다.
Q: "Cassandra는 Master 노드가 없는데 어떻게 클러스터의 상태를 관리하고 장애를 감지하나요?"
A: "카산드라는 가십(Gossip) 프로토콜을 사용하여 탈중앙화된 방식으로 클러스터 상태를 관리합니다. 각 노드는 1초마다 무작위로 선택된 다른 노드와 통신하며 자신의 상태 정보와 다른 노드로부터 들은 정보를 교환합니다. 이 정보가 소문처럼 클러스터 전체로 빠르게 퍼져나가, 모든 노드가 중앙 컨트롤러 없이도 전체 클러스터의 멤버십과 각 노드의 상태를 거의 실시간으로 파악할 수 있습니다. 특정 노드로부터 일정 시간 이상 가십 메시지가 수신되지 않으면, 다른 노드들은 해당 노드를 다운 상태로 간주하고 요청을 보내지 않는 방식으로 장애를 감지하고 격리합니다."
Q: "NetworkTopologyStrategy가 SimpleStrategy에 비해 실무에서 왜 필수적인가요? 실제 장애 시나리오를 예로 들어 설명해주세요."
A: "SimpleStrategy는 단순히 링의 순서에 따라 데이터를 복제하기 때문에, 물리적으로 같은 랙(Rack)에 있는 노드들에 복제본이 몰릴 수 있습니다. 만약 이 랙의 스위치나 전원 공급 장치에 장애가 발생하면, 원본과 모든 복제본이 동시에 유실되어 데이터가 영구적으로 손실될 수 있습니다.
반면 NetworkTopologyStrategy는 스니치(Snitch)가 제공하는 데이터센터(DC)와 랙 정보를 바탕으로, 복제본을 의도적으로 다른 랙, 더 나아가 다른 데이터센터에 분산시킵니다. 예를 들어 서울 IDC 1번 랙에 원본을 저장했다면, 복제본은 서울 IDC 2번 랙과 부산 IDC 1번 랙에 저장하는 식입니다. 이렇게 하면 랙 단위의 장애는 물론, 데이터센터 전체가 마비되는 최악의 재해 상황에서도 데이터를 안전하게 보호하고 서비스 연속성을 확보할 수 있기 때문에 운영 환경에서는 NetworkTopologyStrategy가 필수적입니다."