Your free instance will spin down with inactivity, which can delay requests by 50 seconds or more.
내가 Strapi를 배포한 Render의 무료 web service는 15분 동안 뭐가 없으면 꺼진다. 그래서 다시 켤 때 1분의 로딩이 걸린다. Strapi Admin Panel은 1분 기다릴 수 있는데 문제는 프론트엔드 앱에서도 회원가입/로그인 등을 할때 이 서버의 api 엔드포인트에 GET이나 POST를 해야 한다는 거다. 회원가입할 때마다 1분 로딩을 기다리거나 에러를 겪어야 한다면 사용하고 싶지 않을 것이다. 그래서 서버를 하루종일 돌아가게 할 방법을 찾아봤다.
GitHub Actions
Using GitHub Actions to run Python 여기서 했던 것처럼 GitHub Actions를 사용해서 5분에 한 번씩 서버에 리퀘스트를 보내게 해봤다. 근데 이게 딜레이가 될 때가 많고 아예 취소가 되기도 한다. 45분동안 한번도 안 보내기도 했다. 이러면 소용이 없다.
Circle CI
circleci를 써봤다. 근데 yml에 cron job을 쓰면 자꾸 뭐가 틀렸다고 해서 봤더니 yml에는 cron job을 쓸 수 없없고 스케줄 설정은 circleui 웹앱에서만 할 수 있단다. 그래서 설정하러 갔더니 schedule은 OAuth를 사용하는 프로젝트에만 된다고 막아놨다. 그래서 못함.
UptimeRobot
UptimeRobot의 HTTP/website monitoring. 이게 서버 깨우는건줄 알았는데 서버를 깨우는건 아니고 돌아가는지 안 돌아가는지만 체크하는 듯하다. 5분마다 체크해서 다운되면 이메일로 알림을 보내준다.
Cron-job.org
여기서 크론잡을 만들어주면 내가 정한 간격으로 request를 보낼 수 있다. GitHub Action과 다르게 한국 시간으로 설정할 수도 있고 시간도 정확하게 지킨다.
이때 url을 리다이렉트 안되는 정확한 최종 url로 설정해야 한다. 리다이렉트가 되면 Failed (HTTP error) 301 Moved Permanently 또는 Failed (HTTP error) 302 Found가 뜬다.
url을 잘 설정했더니 Successful 200 OK가 뜬다. 🎉
output too large?
다음날 아침 cron job이 너무 많이 실패해서 비활성화되었다는 메일이 와 있었다. 히스토리를 보니 Failed (output too large)와 Failed (HTTP error) 503 Service Unavailable가 번갈아서 찍혀 있었다. 아웃풋이 왜 갑자기 커졌을까? insomnia로 확인해 보니 크지도 않은데.
서버를 켜고 다시 cron job을 활성화했더니 아무 일 없었다는 듯이 성공한다. 내가 cronjob 간격을 15분에 한번씩 설정해놨는데 한번은 render 서버가 15분보다 조금 일찍 다운되어서 cronjob에게 큰 에러 로그를 줬던 게 아닐까? 그럼 간격을 10분으로 좁히고 또 일어나는지 봐야겠다.