Redis

Lumie는 두 개의 별도 Redis 릴리스를 사용합니다.

• lumie-cache의 프로덕션 스타일 캐시 인프라
• lumie-dev의 더 단순한 dev 전용 릴리스

둘 다 lumie-infra/storage/redis/** 아래에 선언되어 있습니다.

소스 경로

• lumie-infra/storage/redis/argocd.yaml
• lumie-infra/storage/redis/argocd-dev.yaml
• lumie-infra/storage/redis/base-values.yaml
• lumie-infra/storage/redis/overlays/prod-values.yaml
• lumie-infra/storage/redis/overlays/dev-values.yaml

런타임 형태

퍼블릭 표면

• 백엔드의 auth 경로는 Sentinel discovery를 사용합니다.
  • SPRING_DATA_REDIS_SENTINEL_MASTER=mymaster
  • SPRING_DATA_REDIS_SENTINEL_NODES=redis.lumie-cache.svc:26379
• 프로덕션 Redis는 replication mode에 replica 2개와 Sentinel 활성화로 실행됩니다.
• dev Redis는 metrics 비활성화된 standalone으로 실행됩니다.

운영 계약

• base-values.yaml은 내부 클러스터 통신을 위해 Redis auth를 비활성화합니다.
• prod-values.yaml은 다음을 활성화합니다.
  • architecture: replication
  • sentinel.enabled: true
  • metrics.enabled: true
• dev-values.yaml은 다음으로 전환합니다.
  • architecture: standalone
  • metrics.enabled: false

이 분리는 의도적입니다. 프로덕션은 가용성과 observability를 우선하고, dev는 최소한의 클러스터 footprint를 우선합니다.

의존성

• 두 릴리스 모두에 대한 ArgoCD
• 프로덕션 metrics.serviceMonitor를 위한 Prometheus
• Redis 시크릿이나 서비스 이름을 소비하는 애플리케이션 네임스페이스

장애 지점

• auth가 비활성화되어 있으므로 Redis는 내부 신뢰 서비스이며, 네임스페이스와 네트워크 경계 뒤의 클러스터 내부에 머물러야 합니다.
• dev와 prod 동작은 다릅니다. Sentinel이나 exporter metrics를 전제로 한 troubleshooting은 redis-dev에 적용되지 않습니다.
• replica 또는 Sentinel 실패는 failover나 reconnect 경로가 실제로 실행되기 전까지 애플리케이션 계층에서는 릴리스가 healthy해 보일 수 있습니다.

검증

kubectl get applications.argoproj.io -n argocd redis redis-dev
kubectl get pods -n lumie-cache
kubectl get pods -n lumie-dev | rg redis
kubectl get svc -n lumie-cache
kubectl get servicemonitors -n lumie-cache

관측성

• 프로덕션은 차트의 Redis exporter와 ServiceMonitor를 통해 메트릭을 내보냅니다.
• dev는 메트릭을 완전히 비활성화하므로, Prometheus 기반 대시보드나 알림은 프로덕션 릴리스만 대상으로 해야 합니다.

관련 페이지

• Storage Overview
• Prometheus