상황
서버 CPU나 메모리가 일정 임계선을 넘어 서, 서비스에 장애가 생기는 경우 복구를 위해 서비스 재부팅 + 알림 메일이 오게 설정해두었는데,
3일 연속 자정에 서버가 임계선을 넘어가 재부팅 되었다는 알림 경보 메일을 받게 되어, 3일차에 문제 해결에 들어가게 되었다.
(처음 1일 때는 일시적인 현상으로 지켜보면서 모니터링 만 하다가, 2~3일 때 반복적인 발생하는 이슈로 보았음)
문제 파악
다른 시간대에는 문제가 없고, 자정에만 문제가 생기는 것으로 보아, 자정에 실행되는 이벤트 들에 문제가 있다고 생각하여 해당 크론들을 파악하게 되었다.
(아래 AWS 지표를 볼 때, AWS는 기본 5분 단위로 평균을 집계(옵션 및 추가 비용을 내면 1분마다 집계 가능) 하여 그래프로 나타내준다. 23시 55분 ~ 00시에 리소스가 서서히 증가한 것 처럼 보이지만, 평균 값들의 점을 선으로 이은 것이기에 증가하는 것 처럼 보이는 것)
매일 자정(0시)에 돌아가는 크론들이 존재하였고,
- S3 더미 이미지 (하루치) 삭제 (temp/)
- DB RefreshToken 유효기간 지난 장기 정보 flush
- 당일 시작되어야 하는 서비스 이벤트 처리 (시작 및 종료 등)
- ...
문제가 될 만한 각각의 크론들을 테스트로 돌려보며, 리소스를 많이 요구하는 크론을 찾아보았지만 각각의 크론은 문제가 없었고,
개개인들의 크론들이 시간대가 자정(0시에) 몰려있어, 동시에 돌리다보니 문제가 되는 것으로 최종 결론 내렸다.
해결
기존에 서버 장애로 수행되지 못한 작업들은
-> 크론 작성시 같이 작성해둔 API를 통해 작업을 보완하였고
크론 작업 시간 재분배
-> 각각의 크론 테스트시 문제가 없었기에
-> 꼭 자정에 실행되어야 하는 서비스 크론들은 냅두고, 상관 없는 크론들을 다른 시간대로 분리하였다.
-> 최종 해당 시간대에 리소스가 임계선을 넘어서지 않는 것을 확인하였다.
크론 작업 시간 재분배 내용
-> 서비스 이벤트 처리 (시작 및 종료 등) : 00시
-> S3 더미 이미지 (하루치) 삭제 (temp/) : 02시
-> DB RefreshToken 유효기간 지난 장기 정보 flush : 04시
-> 등..
만약 위 크론 작업 시간 분배로, 해결되지 않았을 때 작업도 고려 해두었었는데
-> 일정 텀을 두고, 배치(batch) 만큼 작업을 수행하도록 하거나
-> 해당 시간대에 Scale-out 이나, Scale-up 등을 고려해 볼 수 있을 것 같다.
'프로젝트 경험기 > 기타 경험기' 카테고리의 다른 글
[기타] 슬랙 커스텀 앱 봇 만들기 (0) | 2024.04.14 |
---|---|
[기타] 임시 저장 서비스 경험기 (1) | 2024.01.30 |
[기타] 에러 핸들링 (Error Handling) 처리 경험기 (0) | 2023.10.01 |