카카오TV, 쿠버네티스 오퍼레이터 패턴으로 Redis 클러스터 구축

카카오TV 백엔드 팀은 온프레미스 PM 장비에서 운영하던 Redis 클러스터의 스케일링 한계를 극복하기 위해 **쿠버네티스(Kubernetes)**로 이전했습니다. 대형 스포츠 경기나 단독 송출 이벤트 시 트래픽 폭증에 대응하기 위해, 기존 방식으로는 즉각적인 리소스 증설이 어렵고 평상시 리소스 비효율이 발생했기 때문입니다.

구축 과정에서는 Kubernetes Operator Pattern을 적용해 커스텀 리소스(CRD) 정의와 컨트롤러 개발을 통해 클러스터 생성, 스케일 인/아웃, HA 처리를 자동화했습니다. 컨트롤러는 리컨사일(reconcile) 로직으로 커스텀 리소스와 실제 클러스터 상태의 일치 여부를 주기적으로 확인하며, 마스터 파드 장애 시 레플리카 승격 및 신규 파드 생성을 자동으로 수행합니다.

네트워크 및 성능 최적화

Redis 클러스터의 성능 저하를 방지하고 개발 복잡도를 낮추기 위해 Host Network를 사용했습니다. 인그레스를 통한 접근 방식은 파드 생성 시마다 ConfigMap 업데이트가 필요하고 성능 오버헤드가 발생할 수 있어, 커스텀 리소스의 basePort를 기반으로 순차적으로 포트를 할당하는 방식을 채택했습니다. 이를 통해 단일 쿠버네티스 클러스터당 약 5,000개의 Redis 파드 운영이 가능합니다.

고가용성(HA) 및 모니터링

마스터와 레플리카가 동일한 워커 노드에 배포되어 단일 장애점(SPOF)이 발생하는 것을 방지하기 위해 Pod Affinity를 적용했습니다. 또한 Redis Exporter, Prometheus, Grafana를 연동해 메트릭을 수집하고 시각화했으며, 컨트롤러 장애 시에도 Action 스택 기반의 롤백 메커니즘으로 일관성을 유지하도록 설계했습니다.

운영 효과 및 고려사항

쿠버네티스 도입으로 트래픽 변동에 따른 리소스 효율성이 향상되고, 정확한 용량 산정 없이도 스케일링이 가능해졌습니다. 다만, 컨트롤러 코드 오류 시 복구 지연 가능성과 일부 Redis 라이브러리(jedis 등)의 레플리카 리드 미지원 문제는 단점으로 지적되었습니다. 메모리 사용량이 완만하게 증가하는 특성상, 긴급 상황이 아닌 경우 신규 클러스터 생성 후 데이터 이관 전략도 병행됩니다.