Edu/Support

쿠버네티스(Kubernetes) 환경에서 Redis 구성 종합 평가

Redis 구성 종합 평가

레디스/파드 구성	HA Status (고가용성)	Scalability (확장성)	*3-Pod 제한
Redis-Cluster (6 Pods) (3 Masters, 3 Replicas)	O (Pass)	O (Pass)	X (Fail)
Redis-Sentinel (6 Pods) (1 Master, 2 Replicas, 3 Sentinels)	O (Pass)	X (Fail)	X (Fail)
Redis-Sentinel (3 Pods) (Sidecar 패턴: Redis와 Sentinel을 한 파드에 구성)	△ (Warning)	X (Fail)	O (Pass)
Redis-Standalone (1Pod) (Master 1대)	X (Fail)	X (Fail)	O (Pass)

* 3-Pod 제한: 소규모 인프라나 제약 조건으로 인해 파드 개수를 최대 3개로 제한하는 환경을 가정한 평가 항목입니다 (초기 기획 시 Sentinel 구성이나 HA/확장성 요구사항을 충분히 반영하지 못했을 때 주로 발생합니다). 파드 개수에 제한이 없는 환경이라면 해당 항목은 평가에서 제외해도 무방합니다.

🧑‍💻 아키텍처 최종 검토 결론

Redis-Cluster (6 Pods): 고가용성(HA) 확보와 향후 데이터/트래픽 증가에 따른 가용 확장성(Scalability)을 모두 충족하므로 운영 환경 최우선 권장안입니다.
✅ 마스터 1대가 다운되더라도 나머지 2대의 마스터는 중단 없이 정상 동작합니다. 즉, 시스템 전체 마비가 아닌 '1/3 구역의 부분 장애'로 피해가 국한됩니다.
Redis-Sentinel (6 Pods): 단일 Master 구조 특성상 쓰기(Write) 트래픽 집중 시 성능 병목이 발생할 수 있습니다. 조회(Read) 분산은 복제 노드(Replica)로 가능하나, 복제 노드를 추가 증설하더라도 쓰기 병목 해소에는 한계가 있습니다.
Redis-Sentinel Sidecar 패턴 (3 Pods): 단일 파드 장애 시 Redis와 Sentinel 프로세스가 동시에 중단되므로 운용 안정성이 떨어집니다. 특히 2개 파드 동시 장애 시 Sentinel 정족수(Quorum) 미달로 인해 자동 장애조치(Failover) 및 복구가 지연되거나 불가능해질 위험이 있습니다.
Redis-Standalone(단독) (1 Pod): 레디스 사용 메모리가 1GB 이하이고, 레디스가 약 30초 정도 다운되어도 서비스에 큰 지장이 없는 환경이라면 레디스(마스터) 1대 단독으로 운영할 수도 있습니다. (사용 메모리를 1GB 이하로 제한하는 이유는 메모리 사용량이 더 커지면 AOF 파일을 읽어오는데 시간이 많이 걸리기 때문입니다. 만약 AOF/RDB를 사용하지 않는 것으로 설정했다면 메모리 사용량 제한은 무시하셔도 됩니다.)

<< K8s Redis Scale-Out (확장)

Email 답글이 올라오면 이메일로 알려드리겠습니다.