미미키 서버가 왜 자꾸 죽었을까?
상상도 못한 정체
사건의 발단
미미키 운영 과정에서 이상한 문제가 생겼다.
사건의 시작
추석 동안 시간을 내서 미미키 검색 고도화를 위해 AI 를 붙였다.
지금은 DB match 방식으로 진행하고 있고, 이를 prompt + DB match + vector store + reranker + RAG 를 통해 고도화하는 PoC 를 해 보았다.
그리고 이 vector store 에 데이터 갱신 시점을 [운영툴에서 갱신 버튼 누르기] or [밈 갱신 시점(생성/수정/삭제)] 두개로 해놨다.
처음에 붙였을 때에는 별다른 이슈가 없을 거라고 생각을 했는데, 나중에 밈 추가 과정에서 문제가 생겼다.
명절 연휴가 끝나서 가지 말라는 짤을 올렸는데 (https://meme-wiki.net/meme/11787) 이게 안올라갔다.
계속 업로드는 안되고 빙글빙글 돌면서 멈춰있길래 가볍게 'pinecone vector store 갱신이 오래 걸리나보다' 하고 다른짓을 하고 있었는데 나중에 보니까 서버가 꺼져있었다!!
그래서 아무도 몰래 서버 복구를 시도하고(바로 걸림)
어디가 문제인지는 모르겠지만 일단 혹시 문제가 생길 수 있으니 밈 갱신 시점에 vector store 갱신하는 기능을 지우고 재배포했다.
그리고 이 과정에서 뭔가 커넥션 풀을 서버가 계속 잡고 있길래 서버에 직접 접속해서 돌아가는 도커를 내리고 git action 으로 재배포했다.
그랬더니 일단 서버는 떴는데 이미지 수정을 하면 계속 안됐다.
일단 명절 연휴가 끝나서 가지 말라는 짤을 올렸(https://meme-wiki.net/meme/11787)던 이유는 당연히 명절 연휴가 끝나서였고, 위의 카톡 내용을 보면 밤이었기 때문에 아무튼 조회는 되니 내일 해결해야겠다 싶어서 저대로 잤다.
그리고 다음날...
퇴근하면서 슬쩍 미미키를 열어 봤는데 서버가 작동을 안하고 있었다.
여전히 원인은 커넥션 풀이었고, 미미키 서버 변화는 두개 정도가 있었다.
1. AI 붙이기
2. FCM 붙이기
서버 : 죽을게
대체 뭐가 문제였는지 다른 서버 개발자랑 확인을 해 보는데 이상한 점이 조금 있었다.
1. 분명 master branch 에서 vector store 갱신 기능을 뺐는데 그 기능이 안빠진 버전으로 배포됨
2. git action 으로 재배포되지 않음
3. vector store이 문제라면 이를 활용하는 검색이 안돼야 하는데 검색은 개잘됨
4. 수정/삭제/입력 기능이 아예 안되는데 그것도 계속 멈춰있음
쓰고 보니 조금은 아니고 많이 있었다.
아무튼 이것 때문에 AI 를 의심해 보고, 다른 클라 개발자를 의심해 보고, FCM을 의심해 보고, Watchtower 도 의심해 보고 모든 의심을 다 해봤다.
꼬꼬무얘기를 하는 도중에 한가지 큰 힌트가 나왔다.
insert 는 안되고 select 는 된다.
복선 GOAT조회 -> 됨
로그 -> 안남음
미미키는 유저의 활동을 기반으로 다양한 인기있는 밈을 보여주는 수준높은 서비스이기 때문에 다양한 활동 지표를 수집한다.
그런데 이 지표 수집의 insert 는 안되는데 조회는 또 됐다.
1. DB 프로세스 상태 확인하기
select 가 되는데 insert가 안되면, 뭔가 프로세스가 멈춰 있는건가? 하는 생각이 들었다.
그래서
SHOW PROCESSLIST;
요 명령어를 통해 확인을 해 보았다.
그리고 확인 결과 'COMMIT' 작업인 프로세스들이 'waiting for handler commit' 상태로 멈춰 있었다.
그 중 하나의 데이터를 가져와 보면
'PID','DB_USER','IP','DB_NAME','Query','136012','waiting for handler commit','COMMIT'
대충 이런 식이었다.
즉, 뭔가뭔가가 있어서 commit 이 되지 않는 상태였고, 그게 136012초 동안 유지되고 있는 상황이었다.
2. DB 상태 확인
그러면 뭐 DB 가 read-only 인건가? 하면
당연히 그런 설정을 켜는 일은 없었다.
애초에 read-only 였으면 저렇게 무한대기가 아니라 Exception 이 나왔을 것이기도 하고.
3. 그렇다고 디스크가 꽉찬건 아닐 거 아니야
그래도 우리가 뭐 엄청 작은 서버를 쓰는것도 아니고, image 도 R2에 따로 보관하는데 이게 디스크가 꽉찰 수가 있나? 싶었다.
다만 우리가 백엔드 서버랑 DB가 같은 VM 내에 있으니 다른 것이 문제가 될 수 있기도 하고, 저런 식으로 DB가 계속 hang 되는건 설정보다는 뭔가 잡고 있으니 그럴 수 있다 싶어서 속는셈 치고 bash 명령어를 통해 확인해 봤다.
bash-5.1# df -h
그 결과
Filesystem Size Used Avail Use% Mounted on
overlay 9.8G 9.4G 0 100% /
tmpfs 64M 0 64M 0% /dev
shm 64M 0 64M 0% /dev/shm
/dev/vda2 9.8G 9.4G 0 100% /docker-entrypoint-initdb.d
tmpfs 3.9G 0 3.9G 0% /proc/acpi
tmpfs 3.9G 0 3.9G 0% /proc/scsi
tmpfs 3.9G 0 3.9G 0% /sys/firmware
진짜 살면서 처음봤다.
저게 저렇게 차는게 가능하구나...? 싶었다.
어떤 이유로 발생했던 거지?
결론적으로는 이거였다.
select 은 되는데 insert 는 안되는 이유
1. 모종의 이유로 서버 디스크가 가득 참
2. 디스크가 꽉찼으니 DB에 insert 하면 계속 대기
3. 근데 우리는 조회하면 조회 데이터를 보내준 후 insert 를 통해 메타데이터 입력
4. insert 는 행됨
서버가 죽어버리는 이유
위의 내용에서 계속 insert COMMIT transaction 이 hang되어 DB 연결되는 connection pool 폭파
다시 띄어도 문제가 되는 이유
1. git action 에서 우리 서버 이미지 push
2. watchtower 이 우리 서버 이미지를 pull 받고 띄어줌
3. 근데 pull 받을 공간이 안되니 최신 이미지를 띄우면 그건 사실 옛날꺼
결국은 공간이 부족해서 버틸 수가 없는 상황이었다
해결 방법
짱큰 도커 이미지가 계속 쌓이고 있던 것이 문제였다.
그래서
1. 아무튼 지금 동작중이 아닌 Image 삭제하기 (임시해결)
docker image prune -a -f
2. 새로운 서버 동작 후 기존 안쓰는 + 일정 기간이 지난 docker image clean up (master 에 무한푸시 안하면 ㄱㅊ)
이렇게 진행했다.
그 결과
와! 해결!
결론
1. 참 신기한 경험을 했다.
2. 이제 미미키 서버는 다시 완벽해졌다.
3. 생각보다 재밌었기는 한데 다시 하고싶지는 않은 경험이다.
4. 디스크 크기 관리를 잘 해야겠다 + Docker image 는 몇개만 남기고 지우도록 하는 것도 좋을듯
끝.
