Redis 세션 TTL 드리프트 장애 복구 플레이북

월요일 아침 배포 20분 뒤부터 고객센터에 "로그인이 자꾸 풀린다"는 문의가 급격히 늘었습니다. 처음엔 인증 서버 CPU와 Redis 메모리 모두 정상이라 프론트 쿠키 이슈로 보였지만, API 로그를 묶어 보니 같은 사용자 토큰이 3~5분 간격으로 재발급되는 패턴이 반복됐습니다. 온콜 채널에서는 Redis 클러스터 증설 의견이 바로 나왔지만, 이전 분기에도 용량 증설로 증상만 늦추고 재발했던 경험이 있어 접근 순서를 바꿨습니다. 우선 모바일 앱의 자동 재로그인 재시도를 2회에서 1회로 낮추고, 웹의 백그라운드 세션 갱신 요청 간격을 60초에서 180초로 임시 상향해 트래픽 피크를 눌렀습니다. 15분 뒤 인증 실패율은 8.4%에서 3.1%로 떨어졌고, 그제야 원인 분석을 진행할 여유가 생겼습니다. 당시 핵심 단서는 "만료" 에러와 "서명 불일치" 에러가 같은 계정에서 번갈아 발생했다는 점이었고, 이는 단순 장애가 아니라 세션 정책 충돌 가능성을 강하게 시사했습니다.

판단 기준은 감이 아니라 수치 네 가지로 고정했습니다. 첫째, Redis 키 TTL 분포를 사용자군별로 샘플링해 0~60초 구간 비율이 비정상적으로 높은지 확인합니다. 둘째, API 게이트웨이에서 발급한 JWT 만료 시간과 Redis 세션 만료 시간이 얼마나 벌어져 있는지 측정합니다. 셋째, 세션 갱신 엔드포인트의 p95 지연과 동시성 급증 시점을 대조해 "지연으로 늦게 갱신돼 만료를 밟는지"를 봅니다. 넷째, 최근 배포 diff에서 EXPIRE와 SETEX 혼용, 타임존 변환, 밀리초/초 단위 혼동을 우선 확인합니다. 이번 사고에서는 신규 배치가 사용자 활동 로그를 정리하면서 일부 세션 키를 EXPIRE key 300으로 재설정하고 있었고, 인증 서비스는 여전히 1800초 TTL을 기대하고 있었습니다. 팀 내에서 바로 공유한 결론은 명확했습니다. "Redis 상태는 정상, 정책은 비정상." 이 구분이 잡히자 증설·재시작 같은 무거운 조치를 피하고 정확한 수정으로 곧장 이동할 수 있었습니다.

실행 절차는 완화 단계와 수정 단계를 분리해 흔들림을 줄였습니다. 완화 단계에서는 먼저 사용자 영향이 큰 플랫폼부터 보호했습니다. 결제·주문 경로는 기존 세션을 최대 10분 연장하는 임시 패치를 적용하고, 관리자 화면처럼 재로그인이 상대적으로 덜 치명적인 경로는 강제 재인증을 유지해 보안 리스크를 통제했습니다. 수정 단계에서는 세션 TTL 산정 로직을 인증 서비스 단일 모듈로 통합하고, 다른 서비스는 TTL 값을 직접 쓰지 못하게 인터페이스를 막았습니다. 이어서 Redis 키 갱신 코드를 SET key value EX 1800 XX 패턴으로 통일해 키 존재 시에만 만료를 연장하도록 바꿨고, 배치 잡의 만료 재설정 코드는 즉시 롤백했습니다. 배포 직전에는 롤백 기준도 숫자로 박았습니다. 인증 실패율 5분 평균이 2%를 넘거나, 세션 재발급 요청이 분당 2,000건을 초과하면 즉시 이전 릴리스로 복귀. 기준을 합의해 둔 덕분에 불필요한 토론 없이 대응했고, 재배포 40분 뒤 실패율은 0.6%로 안정화됐습니다.

운영 체크리스트에서 실제로 효과가 컸던 항목은 세 가지였습니다. 첫째, 세션 TTL 관련 상수는 서비스별 선언을 금지하고 중앙 설정만 허용합니다. 둘째, 배치나 이벤트 컨슈머가 세션 키를 건드릴 경우 PR 템플릿에 "TTL 변경 근거"를 의무 기재합니다. 셋째, 스테이징 부하 테스트에 "동시 갱신 폭주 + 느린 네트워크" 시나리오를 넣어 TTL 드리프트를 사전에 재현합니다. 특히 이번 회고에서 얻은 교훈은, 로그인 장애를 인증 기능 문제로만 보면 늦는다는 점이었습니다. 세션은 인증·배치·클라이언트 재시도 정책이 함께 만드는 운영 시스템이라, 한쪽만 고치면 다시 흔들립니다. 우리 팀은 이후 릴리스 노트에 "세션 TTL, 갱신 주기, 재시도 횟수" 세 값을 항상 함께 기록하도록 바꿨고, 온콜 인수인계 문서에도 같은 항목을 고정 필드로 넣었습니다. 이 습관 하나로 비슷한 징후가 보일 때 원인 가설을 30분 안에 좁히는 속도가 확실히 빨라졌습니다.