아니!! 블로그 완성하고 이력서까지 제출했는데.. 오늘 들어가보니깐 이런 에러가 나고 있었다니 🫠
빠르게 서버를 확인해보았으나,
예?
분명 어제까지만 해도 잘 작동하고 있는것을 확인했는데 왜이럴까..
원인
EC2 서버가 문제는 아니었고,
EC2 서버 내에서 Docker로 실행해둔 WAS를 담당한 컨테이너가 종료되어 있었다.
여기서 중요한 점은 어떻게 종료되었는가이다.
- 0 → 정상 종료
- 1 → 일반적인 에러
- 137 → OOM(메모리 부족) 등 강제 종료
- 139 → Segmentation fault
위에 내 사진에서는 137번이므로 메모리 부족으로 인해 강제 종료된 것이다…!
로그 확인
내가 급한 마음으로 로그를 확인하지 않고 인스턴스를 재부팅해버려서 로그 파일이 날라갔다 😅
이래서 로그 파일을 관리도 정말 중요하구나..!
이번 문제의 원인은 다음에 똑같은 이슈가 생기면 작성하도록 하겠다!
2025년 9월 23일.. 또 터졌다..
이번엔 진짜 로그를 확인해보자.
docker logs <container_id_or_name>
위 방법으로 하니 로그 전체가 출력되고 끝에는 에러 원인은 따로 나와있지 않았다.
그러나 내가 만든 동기화 스케줄러가 있는데 그게 마지막인걸 보니 이게 문제였던 것 같다.
docker inspect <container_id_or_name> --format='{{.State.ExitCode}}' docker inspect <container_id_or_name> --format='{{.State.Error}}'
이렇게 했더니 Error는 아무것도 나오지 않았다.
docker inspect notion-blog-web-1 --format='{{.State.OOMKilled}}' docker inspect notion-blog-web-1 --format='{{.HostConfig.Memory}}'
아무튼 메모리가 부족해서 컨테이너가 종료된 것이 맞다.
근데 뭐 때문에 메모리가 부족했는지는 여전히 모르겠다.
정확한 로그를 확인하지는 못했지만 그래도 내 생각으로는,
커버 이미지 다운로드와 Notion 결과 일괄 처리로 인한 “피크 메모리”가 가장 유력하다.
notion.py의 _download_cover_if_available가 requests.get(...).content로 전체 파일을 메모리에 올린 뒤 파일로 작성하고 있다.
고해상도 이미지가 많으면 한 번의 동기화에서 메모리 피크가 크게 발생할 것이다.
이것들을 어떻게 처리할지는 다른 글에서 구체적으로 작성해야겠다.
