본 문서는 현재 운영 중인 서비스의 핵심 구성 요소인 Redis 및 Redis Sentinel 시스템의 아키텍처, 동작 방식, 그리고 운영 가이드를 기술합니다.

현재 시스템에서 Redis는 단순한 캐시 저장소를 넘어, 여러 서비스 간의 통신을 담당하는 중앙 허브 역할을 수행합니다. 주요 역할은 다음과 같습니다.

• 고가용성 메시지 큐 (High-Availability Message Queue)
  AI 이미지 생성과 같이 시간이 오래 걸리는 작업을 비동기적으로 처리하기 위한 작업 대기열입니다. Sentinel을 통해 중단 없는 서비스를 보장합니다.

• 분산 락 (Distributed Lock)
  여러 서버에서 동시에 실행될 수 있는 백그라운드 작업(예: 클릭 수 집계)이 중복 실행되지 않도록 제어합니다.

• 데이터 집계 및 캐시 (Data Aggregation & Cache)
  실시간으로 발생하는 데이터(예: 상품 클릭 수)를 빠르게 수집하고 임시 저장하는 용도로 사용됩니다.

EKS 클러스터는 **네임스페이스(Namespace)**를 통해 운영(prod) 환경과 개발(dev) 환경을 완벽하게 격리하여 안정성을 확보합니다.

• prod 환경

  • 백엔드: onthetop-backend 네임스페이스
  • Redis: redis 네임스페이스

• dev 환경

  • 백엔드: onthetop-backend-dev 네임스페이스
  • Redis: redis-dev 네임스페이스 (현재는 비어있음)

각 환경의 애플리케이션은 자신에게 할당된 네임스페이스의 Redis와 통신하므로, 개발 환경의 작업이 운영 환경에 영향을 주는 일은 원천적으로 차단됩니다.

prod 환경의 Redis는 Redis Sentinel을 기반으로 한 고가용성 클러스터로 구축되었습니다.

• Master-Slave 복제
  1대의 마스터(Master) 노드와 2대의 슬레이브(Slave) 노드로 구성됩니다. 모든 데이터는 마스터에서 슬레이브로 실시간 복제됩니다.

• 자동 장애 복구 (Automatic Failover)
  총 3대의 Sentinel 감시자가 24시간 마스터 노드의 상태를 감시합니다.
  **Quorum (의사결정 최소 동의 수)**는 2로 설정되어, 최소 2대의 Sentinel이 동의해야만 장애로 판단하고 복구 절차를 시작합니다.
  마스터 장애 시, Sentinel은 자동으로 슬레이브 노드 중 하나를 새로운 마스터로 승격시켜 서비스 중단을 최소화합니다.

• 파드 구성
  redis-node-0, redis-node-1, redis-node-2 각 파드 안에는 redis 컨테이너와 sentinel 컨테이너가 함께 실행되어 리소스를 효율적으로 사용합니다.

클러스터 내부의 모든 Redis 통신은 쿠버네티스 내부 DNS와 서비스를 통해 안정적으로 이루어집니다.

애플리케이션 (백엔드/AI 워커) ↓ 내부 서비스 (redis-sentinel-internal) ↓ Sentinel ↓ 마스터 Redis

애플리케이션은 시시각각 변할 수 있는 파드의 IP 대신, 고정된 내부 서비스 주소
redis-sentinel-internal.redis.svc.cluster.local로 접속합니다.
Sentinel은 이 요청을 받아 현재 활성화된 마스터 Redis 노드로 연결을 중계합니다.

• 역할: 시간이 오래 걸리는 AI 이미지 생성 작업을 비동기적으로 처리하는 파이프라인입니다.
• 동작 방식:
  • Producer (생산자): EKS 백엔드 서버는 사용자 요청을 받으면, 작업 정보를 JSON으로 만들어 original:images 리스트에 RPUSH 명령어로 넣습니다.
  • Consumer (소비자): AI 워커(GPU 서버)는 BLPOP 명령어로 original:images 리스트를 계속 감시하다가, 작업이 들어오면 즉시 가져가 처리합니다.
  • 결과 저장: 처리가 완료되면 AI 워커는 결과물(생성된 이미지 URL 등)을 completed:images 리스트에 RPUSH로 저장합니다.
• 관련 코드: app/main.py의 image_worker, app/utils/redis.py의 pop_original_image, push_completed_image 메서드.

• 역할: 여러 백엔드 서버 인스턴스에서 주기적으로 실행되는 작업(예: 클릭 수 DB 저장)이 동시에 중복 실행되는 것을 방지합니다.
• 동작 방식:
  • 작업을 시작하려는 서버는 먼저 SET key value NX 명령어를 사용해 '잠금(Lock)'을 시도합니다. NX 옵션은 '키가 없을 때만 설정하라'는 의미입니다.
  • 잠금에 성공한 서버만 작업을 수행하고, 작업이 끝나면 DEL 명령어로 잠금을 해제합니다.
• 확인된 로그:
  MONITOR 결과에서 SET "job-lock:default:flush-click-counts" ... "NX" 명령어가 확인되었습니다.

• 역할: 사용자의 상품 클릭과 같이 빈번하게 발생하는 데이터를 DB에 매번 쓰지 않고, Redis에 빠르고 효율적으로 집계합니다.
• 동작 방식:
  • Redis의 Hash 자료구조를 사용하여 상품 ID를 필드로, 클릭 수를 값으로 저장합니다. (HINCRBY 명령어 사용 추정)
  • 주기적인 백그라운드 작업이 HGETALL "productClickCount" 명령어로 모든 클릭 수 데이터를 가져와 DB에 한 번에 저장합니다.

• Prod 환경 Sentinel 접속 주소 (내부 DNS) redis-sentinel-internal.redis.svc.cluster.local:26379

• Dev 환경 Sentinel 접속 주소 현재 redis-dev 네임스페이스에는 Redis 인스턴스가 배포되어 있지 않아, 별도의 개발용 Sentinel 주소는 존재하지 않습니다.

• Prod 환경: sentinel-master

Redis 클러스터는 비밀번호 인증을 사용합니다. 비밀번호는 redis 네임스페이스의 Kubernetes Secret에 저장되어 있으며, 다음 명령어로 확인할 수 있습니다:

export REDIS_PASS=$(kubectl get secret redis -n redis -o jsonpath='{.data.redis-password}' | base64 --decode)

1. Sentinel Pod에 접속

kubectl exec -it <pod-name> -n redis -c sentinel -- redis-cli -p 26379 -a "$REDIS_PASS"

2. Sentinel에 등록된 마스터 목록 확인

127.0.0.1:26379> sentinel masters

3. 현재 활성화된 마스터 주소 확인

127.0.0.1:26379> sentinel get-master-addr-by-name sentinel-master

1. 마스터 Redis Pod에 접속

kubectl exec -it <master-pod-name> -n redis -c redis -- redis-cli -p 6379 -a "$REDIS_PASS"

2. 작업 큐 길이 확인 (예: original:images 큐)

127.0.0.1:6379> LLEN original:images

3. 작업 큐 내용 조회 (최신 10건)

127.0.0.1:6379> LRANGE original:images 0 9

4. 실시간 Redis 명령어 감시 (운영 시 주의)

127.0.0.1:6379> MONITOR

※ MONITOR 명령어는 Redis에 들어오는 모든 명령어를 실시간으로 출력하므로, 테스트 또는 점검 시에만 사용하고 장시간 실행은 피하세요.

필요하시면 이 섹션을 이미지나 다이어그램과 함께 시각화하거나, 팀 운영 위키에 맞는 Markdown 형식으로 변환해드릴 수도 있습니다.