[DB, REDIS] PostgreSQL 및 Redis Cluster 관련 이슈

 

팀원이 운영하는 서비스에 장애가 났었습니다.

그래서 같이 원인을 찾아봤습니다.

 

1. 문제 상황

PostgreSQL 를 사용하고 있습니다.

 

 

여기서 문제는 해당 Table 을 조회하는 쿼리를 잘못 전송해서 db disk 사용량이 급격히 증가했고, 이 타이밍에 partition table 만드는 작업이 수행이 되어서 db lock이 걸려서 문제가 되었습니다.

 

 

Redis의 경우에는 master node가 종료됨에 따라서 데이터를 write를 못하는 현상이 있었고, 서비스를 사용자에게 제공하기 까지의 시간이 매우 오래 걸리는 문제가 있었습니다.

 

 

2. 원인

PostgreSQL의 disk 사용량이 급격하기 늘어난 이유는 temp file 때문입니다.

PostgreSQL은 sorting을 할 때, worker memory를 이용하게 되는데 이를 다 사용하게 되면 temp file을 만들게 됩니다.

 

여기서 문제는 파티션 테이블에 where 절 없이 조회를 해서 파티셔닝 된 모든 테이블을 조회했는데, 이 테이블의 데이터 크기가 꽤 큽니다. 그래서 temp file이 엄청나게 만들어져서 문제가 되었습니다.

 

또한 temp file limit을 걸어주는 옵션도 걸려있지 않아서 disk 문제가 생겼었습니다.

 

lock이 걸린 이유는 위에서 설명한 select 문 때문입니다.

이 쿼리를 실행한 상태에서 create table .... partition of  ... 쿼리가 실행이 되었습니다.

문제는 create table .. partition of... 는 상위 테이블에 AccessExclusive lock이 걸리게 됩니다.

 

그래서 위의 select문이 종료될 때까지 기다리고, create table을 하려고 기다립니다. 그리고 이 테이블에 값을 쓰려고 하는 쿼리는 계속 대기하게 됩니다.

 

 

 

Redis의 문제는 Lettuce의 topology를 refresh 하는 설정이 빠져있었습니다.

(예전에 이 부분 빠져 있어서 문제 된다고 제가 피드백 했었지만... 수정을 하지 않았네요...)

 

없으니까 master에 데이터를 보내게 되는데, 문제는 master가 다운 되어서 아무 응답이 없습니다.

단순히 master가 slave로 바뀌었다면, MOVED로 다시 master node에 전달해서 큰 문제는 없었겠지만, 다운이 되어서 문제였습니다.

 

심지어 command time out도 설정이 되어 있지 않아서, 기본값인 1분을 기다립니다.

오래 걸리는 요청이 많아져서 서킷 브레이커가 발동하여 문제가 있다는 것을 알 수 있었습니다.

 

만약 topology를 refresh 하는 옵션이 있었다면, 이러한 이슈는 없었을 것이고 connection time out이 짧게 설정되어 있으면 해당 데이터는 쌓지 못하지만 사용자에게는 정상적으로 서비스를 제공했을 것 입니다.(redis에 write하는 작업은 사용자에게 영향이 없는 작업 입니다.)

 

 

 

 

3. 느낀점

사실 select를 잘못 날려서 이러한 문제가 발생할 줄은 몰랐네요...

disk 뿐만이 아니라 그 뒤의 작업도 전부 밀리게 되면서 엄청 큰 이슈가 발생했었습니다.

 

만약 팀원이 아니라 제가 해당 작업을 진행했어도 이 이슈는 발생할 수 있었을 것 같습니다.

저도 이 내용은 몰랐거든요....

특히 자신이 사용하고 있는 툴을 깊이 있게 알 필요성이 있다는 것을 다시 한 번 느꼈습니다.

 

DB나 분산 시스템에 대해 공부할 필요성을 느꼈습니다.

데이터 중심 애플리케이션 설계 책으로 공부를 해봐야겠네요.

 

 

 

redis 이슈는 미리 예방을 할 수 있었는데, 못해서 아쉽네요.

저도 해당 내용을 알고 있었고 작년 여름 ~ 가을 쯤에 한 번 팀원에게 말씀을 드렸고, 7일 전 쯤에도 한 번 더 드렸었습니다.

 

피드백만 주고 끝내는 것이 아니라 저도 한 번 더 확인을 하거나 제가 직접 나서서 하는 것이 좋았을 것 같네요.

 

좋은 교훈이 되었습니다.