드루팔 성능/속도 올리기 제3탄 - 정기적 작업(크론, CRON)은 예상 외로 중요하다

드루팔에서 정기적 작업(크론, CRON)은 의외로 중요하다.

아니... 아주 중요하다.

어제 이와 관련된 글을 하나 댓글로 썼는데...
http://palpal.org/ko/node/287#comment-249

요약하자면, 정기적 작업인 크론이 제대로 작동하지 않아
accesslog와 watchdog테이블이 (오래된 내용을 삭제하는) 정리가 되지 못했다.
이로 인해 해당 드루팔 DB의 용량이 기하급수적으로 늘어나 백업에 문제가 됐다.

하지만 자세히 살펴보면 백업에만 문제가 되는 게 아니다...
팔팔.오알지의 경우에는 하루 하루 자동 백업을 하면서 CPU 부하 및 HDD 용량부담이
나날이 늘어났고 원인을 뒤늦게 발견해서 그 동안에 사이트 응답이 느린 적도 많았다.
(원래부터 한 서버에 11개의 사이트 운용으로 과중한 부하가 있어왔던 터라 위 문제는 더 심했다)

또한 드루팔 사이트 자체의 DB조회 및 그 응답속도에도 조금은 영향을 미치지 않았을까...

정기적인 크론을 설정하기 편한 Linux 박스의 경우에는 비교적 안정되지만,
호스팅 서버가 유저별로 크론을 지원하지 않거나 크론 설정 및 기동이 쉽지 않은
여타 OS서버의 경우, PoormansCron 모듈이나 Cron Plus 모듈을 대신 사용하곤 한다.

PoormansCron 모듈 - http://drupal.org/project/poormanscron
* 시스템적인 crontab 설정이 불필요해서 설정이 비교적 간단한 편이다.

Cron Plus 모듈 - http://drupal.org/project/cronplus

이 중 PoormansCron 모듈은 엄밀히 말하면 정기적인 크론이 아니라,
반자동 크론이다. 왜냐하면 유저가 방문했을 때를 기점으로 기동이 시작,
지난 번 크론을 수행했던 시간을 비교해서 새로운 크론을 시작할까 말까 판단한다.
이러다 보니 이 모듈은 사이트에 방문자가 없는 경우에는 계속해서
정기적인 작업을 수행할 방아쇠가 없어져 버리는 셈이다. 그러다 오랫만에 누군가
방문하면 그제서야 밀린 정기적인 작업을 일제히 수행하는 바람에 부하가 엄청나다.

예를 들어 접근 로그를 1주일만 보관하게 돼 있도록 설정돼 있고,
정기적 작업이 PoormansCron에만 의존하며, 어느 누구도 8주동안 방문치 않은 경우,
그러다가 누군가가 그 사이트에 드디어 접근한 경우, PoormansCron은 작동을 시작,
밀린 1 더하기 7주동안의 접근 로그를 일시에 삭제코자 한다. 그래서 부하가 걸리고...
모처럼 방문한 8주만의 새 사용자는 "이 사이트 왜 이렇게 느려..."라고 생각할 수도 있다.

어떤가... 크론이 제대로 작동하지 않는 경우의 악순환 시나리오가.
정기적인 작업을 수행치 못하는 드루팔은 확실히... 뭔가 빠진 느낌이다.
그런데 crontab 같은 시스템 레벨의 크론 설정이 쉽지 않는 상황이라면,
아주 신중하고 면밀하게 안정된 정기적 작업환경을 구축해야 한다.

한 가지 일례로 웹사이트에서 정기적인 방문 및 크론 작업을 대신해 주는 서비스가 있다.
http://www.webcron.org/ 같은 곳이 그런 역할을 하는데... 대부분이 유료인가 싶어 아쉽다.

아뭏든 힘을 다해 크론같은 정기적인 작업을 탄탄하게 구축할 필요가 있음을 재차 강조한다.