RedisReadOnlyException - READONLY You can't write against a read only replica.

분명히 저번에는 문제가 없었는데 갑자기 로그인, 이메일 전송이 안 되는 문제가 생겼다. 예외처리가 제대로 안 되어있길래 예외처리 추가하고, 하는 김에 로그 유틸도 손을 좀 봐서 root cause를 출력하게끔 수정했다.

 

그리고나서 로그를 확인해보니

2025-09-08T07:53:35.558Z ERROR 1 --- [back] [nio-8080-exec-2] c.p.b.c.e.h.InternalExceptionHandler     : [❌ ERROR GLOBAL] POST /api/members/login | code=SYS000, message=서버 내부 오류가 발생했습니다., exception=Error in execution, , rootCause=RedisReadOnlyException - READONLY You can't write against a read only replica.

 

Redis가 readonly라서 생긴 문제라는 걸 확인할 수 있었다.

현재 redis를 직접 설치해서 사용하는 것이 아니라, 컨테이너를 실행시킨 것이기 때문에 컨테이너의 redis-cli에 접속해보았다.

role 명령을 입력하면 slave 또는 master가 뜨는데 slave로 뜬다는 것은 readonly라서 문제가 발생한 것이다.

 

그래서 일단은 임시방편으로 

REPLICAOF NO ONE

명령으로 master로 변경해놓고, 근본적인 이유를 찾아보기로 했다..

docker 명령어로 redis의 로그를 확인해보니 이상한 ip에서 계속 접속을 시도하는 것 같았다.

이게 대체 무엇인가 했는데 복제를 시도하는 것이란다....

그래서 일단 ec2 인스턴스 보안그룹을 확인해봤는데 6379 포트를 열어놨었다.. 왜 그랬는지는 모르겠지만 일단 6379 포트를 다시 닫아놨다.

 

이번 일을 겪고 예외 처리와 로그의 중요성을 다시 한 번 느꼈다. 로컬에서는 IDE 디버깅으로 원인을 금방 찾을 수 있지만, 배포 환경에서는 원인 추적이 쉽지 않다. 어떤 요청(URI)이 어떤 도메인에서 실패했는지, 그리고 근본 원인(root cause, 서버 오류라면 스택 추적) 을 로그로 남겨 두면 해결이 훨씬 수월해지는 것 같다.

최근 개인 및 팀 프로젝트에서 배포와 CI/CD를 주로 맡다 보니, 문제가 생기면 내가 로그를 확인한다. 그러다 보니 예외 처리와 로깅에 더 집착하게 되는 것 같다...(안 하면 내가 힘듦) 특히 문제가 발생했는데 로그가 하나도 없으면 정말 난감하다.

 

1. 코드의 문제인지

2. 서버의 문제인지

3. 통신의 문제인지

4. 중간 서버 (프록시 등)의 문제인지,,, 등

가능한 원인이 너무 많다. 지금이야 대형 프로젝트가 아니기 때문에 이 정도인데 더 큰 프로젝트를 하게 된다면 예외가 발생할 수 있는 경우를 체계적으로 나누고 관리해야 할 것 같다. 힘들긴 하지만 재미있고 이런 경험이 쌓이면 분명 배울 게 많다고 믿는다.