feat: Redis Sentinel 기반 자동 Failover 구성

[KimGyeongLock]

변경 사항

• Redis Master 1개, Replica 2개 구성
• Sentinel 3개와 quorum 2 기반 장애 감지 구성
• Spring Boot에서 Sentinel을 통한 Redis Master 탐색 적용
• Redis Master 장애 시 Replica 자동 승격 검증
• k6 기반 Sentinel Failover 장애 실험 추가
• Sentinel 장애 전환 결과 문서화

장애 대응 구조

Redis Master 장애 시 바로 Redis 복구를 기다리지 않고
Circuit Breaker와 MySQL Fallback으로 사용자 요청을 처리한다.

동시에 Sentinel이 Master 장애를 감지해
Replica 하나를 새로운 Master로 승격한다.

애플리케이션은 Sentinel을 통해 새 Master를 탐색하고
Redis Cache 경로로 자동 복귀한다.

실험 조건

• VU: 100
• 실행 시간: 120초
• Master 중단: 실행 30초 후
• 기존 Master 재시작: 실행 약 60초 후
• Redis: Master 1 + Replica 2
• Sentinel: 3
• quorum: 2
• down-after-milliseconds: 5초

결과

• 기존 Master: redis-replica-1
• 새로운 Master: redis-replica-2
• Sentinel Failover: 8.567초
• 총 요청: 938,870
• 처리량: 7,823.30 req/s
• 평균 응답 시간: 12.65ms
• p95: 23.72ms
• 최대 응답 시간: 1.98s
• 요청 실패율: 0%
• Redirect 검증 성공률: 100%

Master 장애 직후 Circuit Breaker와 MySQL Fallback이 동작했고,
Sentinel Failover 이후 Cache Hit 경로가 자동 복구됐다.

한계

• Redis와 Sentinel이 동일한 Docker Desktop 호스트에서 실행돼
  독립 Failure Domain을 구성한 실제 운영 환경과는 차이가 있다.
• Failover 과정에서 최대 1.98초의 tail latency가 발생했다.
• Sentinel은 자동 Failover를 제공하지만 데이터 Sharding은 제공하지 않는다.
• Nginx와 MySQL은 여전히 단일 인스턴스로 남아 있다.