공유 상태 제거와 인증 저장소 DB 이주의 설계적 함정

대규모 분산 시스템에서 인증 토큰 관리와 실시간 메시지 전송은 주로 Redis에 의존해 왔다. Redis의 높은 처리량과 TTL 기능은 개발자를 편리하게 했지만, 이는 시스템에 '공유 상태'라는 단일 장애점(SPOF)과 깊은 결합을 강요했다. 상태 저장소 제거는 단순한 기술 교체가 아니라, 인증 구조와 배포 파이프라인 전반의 재설계를 의미한다. 우리 솔루션은 이 과정에서 Redis의 완전 제거를 결정했고, 그 대가로 데이터 정합성 검증과 배포 안정성 확보라는 명확한 비용을 치렀다.

제약

이전 작업의 경계는 명확했다. 첫째, 인증된 사용자의 세션 무효화(로그아웃) 능력이 완전히 사라져서는 안 된다. 둘째, 실시간 채팅과 알림 전송의 신뢰성이 저하되어서는 안 된다. 셋째, 외부 인증 서버나 별도 키--value 저장소와의 네트워크 왕복으로 인한 지연이 허용 범위(수십 밀리초)를 초과해서는 안 된다. 마지막으로, 기존 서비스의 가용성을 해치지 않는 점진적 전환이 필수였다.

선택지

대안 1: Redis 유지 및 최적화

• 장점: 기존 아키텍처 변경 최소화로 인한 빠른 구현.
• 단점: Redis 클러스터 확장성 한계와 네트워크 장애 시 전체 인증 마비 리스크가 지속됨.

대안 2: Redis 완전 제거 및 DB 이관

• 장점: 인프라 의존성 제거로 배포 파이프라인 단순화, 데이터 영구성 확보.
• 단점: DB의 쓰기 지연과 GC(쓰레기 수집) 관리 부담 증가, 트랜잭션 격리 수준에 따른 동시성 제어 필요.

대안 3: 분산 캐시 대신 로컬 캐시 적용

• 장점: 네트워크 왕복 제거로 인한 극저지연.
• 단점: 멀티 인스턴스 환경에서 토큰 무효화 동기화 불가능, 서버 재시작 시 세션 손실.

결정

Refresh Token 저장소와 메시지 전송 경로를 모두 DB와 REST로 이전하기로 결정했다. 이 선택의 핵심 기준은 '운영 부담의 최소화'와 '장애 반경의 분리'였다.

Refresh Token의 경우, Redis의 TTL 대신 DB의 크론 잡(GC)으로 만료된 레코드를 정리하는 방식으로 TTL 기능을 대체했다. 이는 Redis 의존성을 완전히 끊되, 서버 측 무효화 능력을 유지하는 균형점이다. 메시지 전송의 경우, 기존 Redis Pub/Sub를 Publisher 서비스의 내부 REST API로 일원화했다. 이를 통해 '쓰기 주인'을 명확히 하고, 네트워크 계층의 복잡성을 애플리케이션 로직으로 옮겼다.

DB 이관은 쓰기 성능 저하를 감수하는 대신, 인프라 장애에 대한 서비스의 복원력을 확보하는 선택이었다.

결과와 한계

• 얻은 것: Redis 클러스터 운영 부담 제거, 배포 시 별도 설정 매핑 불필요, 데이터 영구성 확보로 인한 디버깅 용이성.
• 잃은 것: DB 쓰기 지연으로 인한 토큰 검증 시 수 ms 단위의 추가 지연, GC 크론 운영 및 DB 인덱스 관리 부담 증가.
• 되돌릴 조건: DB 쓰기 지연이 SLA를 지속적으로 위반하거나, GC 실패로 인한 스토리지 누적이 관리 한계를 초과할 경우.

다른 시스템에 적용할 때, 공유 상태 제거는 항상 '데이터 정합성 검증'과 '배포 파이프라인 안정화'라는 숨은 비용을 수반한다. 단순한 기술 교체로 보기보다, 운영 프로세스의 재설계로 접근해야 한다.

팀에 남긴 규칙: '인프라 의존성 제거는 코드 수정이 아닌, 테스트와 배포 검증의 확장을 의미한다.' 이 결정을 다시 봐야 할 조건: DB 쓰기 지연이 서비스 SLA를 지속적으로 위반할 때.