새벽에 운영 장애 터졌을 때 했던 삽질 기록
작년에 새벽 3시에 호출받아서 나갔던 장애 대응기. 다시는 겪고 싶지 않지만 기록은 남겨둔다.
1. 일단 알림이 왔다. DB 커넥션 풀이 꽉 찼다는 경고. 처음엔 서버 재시작부터 했다. 30분 뒤 같은 알림이 다시 왔다.
2. 슬로우 쿼리를 봤다. 특정 API 하나가 40초씩 걸리고 있었다. 인덱스 하나가 빠져 있었다. 새벽 4시에 인덱스를 걸었다. 응답이 정상으로 돌아왔다.
3. 근데 왜 갑자기? 확인해보니 그날 저녁에 배포된 기능이 그 테이블을 처음으로 full scan 하게 만든 거였다.
4. 롤백할까 고민했지만 인덱스 추가가 더 안전하다고 판단해서 유지했다.
배운 건 두 가지다. 첫째, 알림이 오면 제일 먼저 '언제부터'를 봐야 한다. 둘째, 배포 직후엔 반드시 슬로우 쿼리 로그를 확인해야 한다.
지금은 배포 파이프라인에 쿼리 플랜 체크를 넣어뒀다. 같은 실수는 한 번이면 충분하다.
10 개의 답변
ㅇㅈ 인덱스 하나가 사람 잡는 거 진짜 순식간임
새벽 3시에 호출받는 그 기분... 알람 소리만 들어도 심장 철렁해짐 ㅋㅋ
근데 1번에서 재시작부터 한 건 좀 아쉽다. 알림 오면 무조건 '언제부터'랑 '뭐가 바뀌었나' 먼저 보는 게 순서인데, 급하면 손이 먼저 가긴 하지. 나도 그랬음. 그래서 요즘은 알림 오면 대시보드 타임라인부터 캡처해두는 습관 들임.
글쎄 그건 좀. 새벽에 라이브 테이블에 인덱스 추가하는 건 좀 위험하지 않나? 테이블 락 걸려서 더 큰 장애로 번질 수도 있는데. 그때 트래픽 낮아서 다행이었던 거지, 항상 그런 판단이 안전하다고는 못 봄.
비슷한 거 겪었는데 우리는 커넥션 풀 문제가 알고 보니 커넥션 누수였음. 슬로우 쿼리부터 의심했는데 로그 보니까 특정 배치가 커넥션 반납을 안 하고 있었더라. 쿼리만 보면 안 보이는 것도 있으니 참고하셈.
출처 있음? 쿼리 플랜 체크는 어떻게 넣은 거임?
롤백 vs 인덱스 판단 잘한 것 같은데, 4번에서 '더 안전하다'고 판단한 근거가 궁금하다. 그날 배포된 기능이 그 쿼리만 문제였다는 확신 있었던 거임? 다른 쿼리도 full scan 타고 있었으면 롤백이 맞았을 텐데.
롤백이 정답인 케이스도 진짜 많음. 인덱스 추가는 증상 치료고, 원인 배포는 그대로 살아있으니까. 다음 배포 때 또 터질 수도 있는 거 아님?
쿼리 플랜 체크 CI에 넣는 거 나도 해보고 싶은데, 어떻게 구현했는지 조금만 풀어줄 수 있나? EXPLAIN 결과 파싱해서 full scan 나오면 파이프라인 fail 시키는 식? 아니면 임계값 기준? 팀에 설득할 때 근거가 필요해서 ㅠㅠ 도입 효과 있었는지도 궁금.
'같은 실수는 한 번이면 충분하다' 이 말 좋다. 근데 현실은 같은 실수 세 번까지도 함 ㅋㅋ