본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
https://fastcampus.info/4n8ztzq
안녕하세요 :)
오늘은 "50일의 기적 AI 환급반_ 대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 " 챌린지에 도전하는 서른 한번째 날입니다.
서른번째 날에는 왜 샤딩이 필요한가에 대해 배웠었는데요. 오늘은 과연 어떤 내용들을 배울 수 있을지 공부하고 포스팅 하도록 하겠습니다.
오늘 학습할 내용의 제목은,
Part 5. 모놀리틱 서비스 분해 > Ch 2. 레디스의 고가용성과 확장성 확보를 위한 클러스터링 >
01. 왜 레디스 클러스터가 필요한가
입니다.
🧱 왜 Redis 클러스터가 필요한가?
- 단일 노드 구조의 한계와 고가용성 확보를 위한 첫걸음
- 이번 포스팅에서는 Redis의 고가용성과 확장성 확보를 위해 왜 클러스터 구성이 필요한지를 중심으로 이야기해보려 합니다. 단일 Redis 인스턴스로 운영하던 시스템이 실제 서비스 수준으로 진입하면서 어떤 문제에 직면하게 되는지, 그리고 이를 어떻게 개선해나갈 수 있는지를 살펴봅니다.
🧩 현재 구조와 그 한계
- 현재 우리 시스템은 Redis를 단일 노드로 운영 중입니다. 이 방식은 초기 구성과 사용이 간편하다는 장점이 있어 지금까지는 무리 없이 사용해왔습니다. 하지만 본격적으로 서비스를 운영하기 시작하면 이 단순한 구조가 심각한 병목과 장애 지점(SPOF, Single Point of Failure) 이 될 수 있습니다.
- 특히 Redis는 메모리 기반의 고속 데이터 저장소이기 때문에, 쓰기/읽기 요청이 많아질수록 단일 노드가 감당할 수 있는 처리량에는 한계가 생깁니다. 물론 서버의 CPU, 메모리 등의 리소스를 계속 증설하는 스케일 업 방식으로 버틸 수는 있지만, 물리적인 한계는 언젠가는 도달하게 됩니다.
- 그보다 더 큰 문제는 장애 복원력입니다. 단일 노드가 다운되면 Redis 자체에 전혀 접근할 수 없게 되어 전체 서비스에 심각한 영향을 미칠 수 있습니다.
⚠️ Redis 다운 시 발생하는 문제
- 우리 시스템에서는 Redis를 단순 캐시가 아니라 세션 저장소와 메시지 시퀀스 ID 발급기로 핵심 기능에 사용하고 있습니다. 이 상황에서 Redis가 다운되면 다음과 같은 문제가 발생합니다:
- 사용자는 새로 로그인할 수 없습니다.
- 기존 WebSocket 연결이 끊어지면 재접속이 불가능합니다.
- 메시지 시퀀스를 발급받을 수 없어 새 메시지를 보낼 수 없습니다.
- 일부 연결된 기능만 제한적으로 동작하며, 그마저도 Redis가 복구될 때까지 불안정합니다.
- 즉, Redis 하나가 사라지는 순간 서비스 전체에 치명적인 장애가 발생하는 구조인 것입니다.
☁️ SPOF(Single Point of Failure) 제거가 핵심
- 현재 시스템에서 SPOF가 될 수 있는 요소는 Redis 외에도 NGINX, 메시지 서버 등이 있지만, 인증 서버나 DB처럼 이미 수평 확장이 가능한 구조로 구성된 컴포넌트도 존재합니다. 이번 단계에서는 Redis를 SPOF에서 제외시키는 것이 핵심 과제입니다.
- 이를 해결하기 위해 Redis를 클러스터링하여 다중 노드 구성으로 전환하려고 합니다.
🛠 Redis 클러스터링 방식 두 가지
- Redis Sentinel
- 하나의 프라이머리와 다수의 리플리카로 구성.
- 장애 발생 시 자동으로 리플리카를 승격시켜 고가용성 확보.
- 하지만 모든 쓰기/읽기 요청은 프라이머리 하나에 집중되며, 처리량이나 저장 용량은 증가하지 않음.
- 목표는 오직 “장애 복구”입니다.
- Redis Cluster
- 여러 개의 프라이머리를 운영하며 데이터를 샤딩하여 분산 저장.
- 예: 6개 노드 구성 시 3개는 프라이머리, 3개는 해당 프라이머리의 리플리카로 구성.
- 읽기/쓰기가 각각의 프라이머리로 분산되므로 성능과 용량이 선형적으로 증가.
- 리플리카는 장애 시 해당 프라이머리를 자동 승격하여 데이터 유실 없이 복구 가능.
- 고가용성과 함께 확장성도 동시에 확보할 수 있는 구조입니다.
- 최근 Redis 공식 문서와 커뮤니티에서도 센티널보다는 클러스터 구성을 권장하는 추세이며, 우리도 이 방향으로 도입을 준비 중입니다.
- Redis 클러스터 도입은 단순한 성능 개선이 아니라, 서비스의 안정성과 신뢰도를 위한 본질적인 구조 개선이라고 생각합니다. 장애는 언젠가 반드시 발생하기 때문에, 중요한 것은 장애가 나도 서비스를 멈추지 않는 아키텍처를 만드는 것이죠.
- 이번 클러스터 전환을 통해 "장애에 강한 시스템"을 향한 기반을 다질 수 있을 것 같고, 나아가 향후 멀티 리전 구성이나 글로벌 확장성까지 고려할 수 있는 기회를 만들 수 있다고 느끼게 되었습니다.
