개요
새로운 이미지를 첨부할 때 API 요청이 정상적으로 동작하지 않았다.
또한 사이트에 접속하면 이미지 액박이 뜨는 문제가 발생했다.
터미널로 ec2에 접속해 로그 파일을 확인해보니 아래와 같은 에러가 발견됐다.
Next.js에서는 이미지 파일을 자동으로 캐싱해주는데 현재는 이미지를 캐싱할 수 없다고 메시지를 보내는 것 같다.
경로를 따라 /home/ubuntu/deploy/.next/cache/images 폴더를 확인해 보니 실제로 무수히 많은 이미지 폴더들이 존재했다.
"그럼 이미지를 더 이상 캐싱 하지 않으면 에러가 사라지겠네?"라는 생각이 먼저 들었지만
Next.js의 좋은 기능을 막는 건 그다지 좋은 생각은 아니라고 생각이 들었고, 소규모 프로젝트에서 이미지 캐싱으로 용량이 벌써 꽉 찬다는 게 말이 안 된다고 생각했다.
근본적인 원인은 결국 용량이 부족해서 이미지를 캐싱 하지 못하는 것이고 어느 부분에서 디스크의 용량을 상당 부분 차지하고 있는지 확인해 보았다.
디스크 용량 확인
/dev/root를 보면 디스크 사용률이 100%인 것을 발견했다.
처음에는 단순히 /home/ubuntu/deploy/.next/cache/images의 이미지 파일들을 삭제해 보았지만 사이트에 접속해서 이미지를 렌더링 하면 다시 원상복구되는 일이 발생했다. (그리고 그다지 용량이 확보되지 않았다...)
해결 방법
필자는 CodeDeploy를 이용하여 배포 자동화를 적용해놓은 상태다. CodeDeploy로 자동 배포를 하다 보면 아래 경로에 배포 폴더가 계속 쌓이게 된다.
cd /opt/codedeploy-agent/deployment-root/배포ID/따로 설정을 건들지 않았으면 아래와 같은 배포 폴더가 5개가 있을 것이다. (스샷을 이후에 찍어서 필자는 2개이다.)
하나의 배포 폴더가 5GB라고 가정하면 5 * 5 = 25GB의 용량을 차지하고 있다.
codedeployagent.yml 안의 max_revisions 값으로 저장되는 배포 폴더의 개수를 원하는 값으로 수정할 수 있다.
sudo vi /etc/codedeploy-agent/conf/codedeployagent.yml
필자는 위 처럼 파일 편집을 하고 저장하려는 순간 디스크의 용량이 부족해서 파일 편집이 제한된다는 에러가 발생하였고 배포 폴더의 ID를 기준으로 이전것부터 수동으로 삭제했다.
변경한 뒤에 sudo service codedeploy-agent restart로 agent를 재시작한다.
이제 배포를 진행해도 더 이상 배포 폴더가 2개 이상으로 저장되지 않는다.
디스크 용량을 확인해 보니 100% -> 86%로 줄어들고 더 이상 에러도 발생하지 않았다!
참고
