webCron - 웹 스케쥴러 플러그인
webCron은 Unix 시스템상의 cron 스케쥴러를 무버블 타입에서 에뮬레이트하는 pseudo 스케쥴러입니다. Unix의 cron이나 윈도 플렛폼상의 스케쥴러는 미리 정한 시간 간격으로 특정한 작업을 수행하는 도구입니다. 독자적인 서버를 가지거나 고급 호스팅 서비스를 사용한다면, 이 cron 서비스를 이용할 수 있지만, 일반적인 저가의 웹 호스팅을 이용하는 다수의 블로거에게 스케쥴러 서비스 이용은 거의 불가능한게 현실입니다.
무버블 타입에서 엔트리의 글 상태를 "Scheduled"로 지정해 줄 수 있는데, 이것은 미래의 특정한 시간 이후에 해당 엔트리가 publishing되어 공개되도록 하는 기능입니다. 하지만, 이 기능은 당연히 cron 류의 스케쥴러 서비스의 이용을 전제합니다. 따라서 대부분의 블로거에겐 그림의 떡인 기능에 지나지 않게 됩니다. 이 플러그인은 저처럼 가난한 블로거들도 기죽지 않고 남보란 듯이 이 기능을 에뮬레이트해서, "Scheduled" 상태의 글 이용 뿐만 아니라, 다른 여타 기능에도 사용할 수 있도록 도와주는 "친절한 플러그인"입니다.
* 이 플러그인은 동적파일생성(Dynamic Publishing)도 지원합니다.
Scheduled Tasks
블로그 시스템 상에서 과연 어떤 작업이 스케쥴링 서비스를 요할까요? 앞서 말한대로, MT에서 새로 선보인 "Scheduled" 상태의 엔트리 지정이 가장 대표적인 작업일 것입니다. 글 상태(Post Status)를 Scheduled 로 설정하고 Authored On 을 미래의 특정 시간으로 정해 저장한 후에, cron 서비스의 테이블에 특정 명령을 주면, 일정한 간격으로 해당 시간을 체크해서 그 엔트리를 퍼블리싱해 주는 식입니다. 그럼 이 외에는 어떤 작업이 "블로그" 시스템과 관련이 있을까요?
가장 먼저 생각나는 것은, 모블로깅입니다. 각종 모바일 장치에서 간단한 글을 쓰거나 혹은 사진을 찍어 자신의 메일로 전송합니다. 그럼 자신의 스케쥴러에 등록한 특정 명령작업이 일정 간격으로 자신의 메일계정을 확인하고, 모블로깅 메일이 도착했으면 이를 엔트리화 시켜서 퍼블리싱해주는 일련의 과정에 스케쥴러는 거의 필수로 요구된다 할 것입니다.
또 다른 예로는 각종 피드(feed)의 업데이트 목록 만들기로의 적용이 있습니다. XML형식으로된 피드에서 최근 새로 업데이트된 엔트리 관련 제목/주소만을 추려서 이를 블로그의 사이드바 등에 박는 것은 기술적으로 어렵지 않습니다. 여러 피드파일을 서버에 읽어와서 이를 파싱을 통해 원하는 필드를 뽑아내서 다시 이를 현재 블로그의 메인 인덱스 페이지의 사이드바 서브메뉴 형식으로 삽입할 때, 가장 문제가 되는 것은 바로 실시간으로 다수의 서버에서 피드를 읽어와서 파싱하는 단계입니다. 매번 방문자가 메인 인덱스 페이지를 접근할 때마다, 다수의 피드를 실시간으로 읽어와서 이를 페이지에 나타내는 것은, 실제로는 트래픽 지연 등의 문제로 비현실적이게 됩니다. 따라서 이런 경우에도 특정한 시간 간격으로 지정한 다수의 피드를 읽어와서 이를 별도의 파일에 정리해 주고, 블로그의 메인인덱스 페이지에선 이 정리된 하나의 파일만을 include하는 식이 정석이라 할 것입니다. 즉, 이 경우에도 스케쥴러에 의한 작업이 필수로 요구됩니다.
이 플러그인은 이런 상황에서 사용되어 스케쥴러의 역할을 수행할 목적으로 개발되었습니다.
Installation
압축파일을 다운받은 후에, (mt home) 폴더 바로 밑에서 $ tar xvfz webCron.tar.gz 식으로 풀어주면, 아래와 같은 폴더 구조에 파일들이 생성됩니다. 만약 telnet 등과 같은 터미널 환경을 사용할 수 없는 경우에는, ftp로 아래 폴더 구조밑에 개개의 파일들을 업로드하면 됩니다.
- (mt home)/plugins/alogblog/webCron.pl
- (mt home)/plugins/alogblog/webCron.cgi
- (mt home)/php/plugins/function.MTWebCronTrigger.php
설치 후 webCron.cgi을 열고, 아래 두 변수를 자신의 환경에 맞게 수정합니다.
$url_of_this = 'http:/www.example.com/mt/plugins/alogblog/webCron.cgi';
$alogblog_path = '/path/to/your/mt/plugins/alogblog';
Tag Usages
<MTWebCronTrigger> : 이 태그를 Main Index 템플릿이나 Individual Entry Archive 템플릿 등의 가장 밑 부분에 삽입하십시요. 보통 </body> 태그 바로 앞부분에 삽입하면 됩니다. 그 후 해당 템플릿을 리빌딩하면 됩니다.(물론 동적 파일생성 이용시엔 리빌딩이 필요없습니다.)
이 태그의 역할: 방문객이 위 트리거(trigger) 태그를 삽입한 페이지를 요구하게 되면(브라우져로 열게 되면), 그 페이지에 삽입된 위 태그가 webCron.cgi 를 자바스크립트를 통해 실행하게됩니다. 위 트리거 태그를 페이지의 가장 밑에 삽입하는 이유는, 방문객이 요구한 모든 페이지를 브라우져로 다 보낸 후에, 이 작업이 뒤에서 일어나도록 하기 위해서입니다. 요구(requested)된 webCron.cgi는 스케쥴링 테이블을 참조해서 특정한 작업을 위한 시간이 지났는지 체크해서, 만약 그렇다면 테이블에 적힌 작업을 수행하게 됩니다. 이때 보통 해당 작업은 최소 5초 이상의 시간이 걸리는 경우가 대부분입니다. 하지만 이 CGI는 내부적으로 그 정도의 시간을 기다릴 필요없이 바로 브라우져로 되돌리게 되어 있습니다.(즉 실제 작업 완료시까지 페이지 로딩이 지연되지 않는다는 것입니다. 이 점이 웹을 통한 트리거 구현의 메인 아이디어입니다.)
설치단계에서 plugins/alogblog/ 밑에 설치한 webCron.cgi를 어떤 이유로 다른 곳으로 옮겼다면, <MTWebCronTrigger src="http://www.example.com/some/path/to/webCron.cgi"> 식으로 태그에 src 속성으로 변경해 줄 수 있습니다.
Setting scheduling Tasks
각 블로그 마다 자신만의 스케쥴링 작업을 가질 수 있습니다. 엠티 메뉴의 Weblog Configuration -> Plugins 메뉴 페이지로 갑니다.

그럼 그 플러그인 목록에 webCron이 있고, 그 설정을 누르면 위와 같이 설정할 수 있는 화면이 나타납니다. textarea에 스케쥴링 작업을 한 줄에 하나씩 엔터키로 구분해서 복수개를 입력할 수 있습니다. 하나의 줄은 Interval이라는 부분과 Commands라는 부분, 두 부분으로 나뉘어 집니다. 두 부분은 "공백" 문자(들)로 구분됩니다.
처음 Interval 부분은 말 그대로 얼마만한 시간 간격으로 작업시간 도달여부를 확인할 것인가를 나타냅니다. 10(혹은 10s)은 10초, 20m 은 20분, 34h는 34시간, 31d는 31일 간격을 의미합니다. 0은 작업을 하지 않음을 의미합니다. 이때 "1h 20m" 같은 식으로 복수의 시간개념으로 Interval을 나타낼 수 없습니다. 즉, 오로지 하나의 시간 단위로만 적절히 입력해야 합니다. 또한 45m 의 경우를 예로 들면, 이 의미는 45분 마다... 이지, 매 시 45분 마다...의 의미가 아닙니다.
매 줄의 두번째 부분은 Commands 부분으로서, 시간 도달시 실행할 명령어 목록입니다. 즉 하나의 명령만 가능한게 아니라, 순차적으로 세미콜론(;)으로 구분해서 복수개의 명령을 적을 수 있습니다. 이때 쉽게 사용하실려면, 모든 파일등의 경로를 절대경로로 적는게 좋습니다.
디폴트 상태에서 "0 cd /path/to/your/mt/; perl tools/run-periodic-tasks" 한 줄이 예로 나타날 것입니다. 이것은 엠티의 미래공개(Scheduled 상태) 엔트리를 위한 명령어 세트입니다. 앞의 0은 실제 사용시엔 원하는 시간간격으로 수정하면 됩니다. 뒤의 명령세트를 보면, cd /path/to/mt; 는 자신의 서버에 설치된 MT인스턴스 폴더까지 cd(change directory) 명령으로 이동해서, 현재 폴더위치(Current working directory)를 (mt home)으로 바꿔주는 역을 수행합니다. 그런 뒤, perl tools/run-periodic-tasks 를 실행하는데, 이 run-periodic-tasks는 (mt home)/tools/ 폴더 밑에 MT가 디폴트로 제공하는 툴 스크립트입니다. 실제 cron 서비스를 이용할 경우에도 이런 식으로 명령세트를 입력합니다.
실제 원하는 값으로 설정한 후에 "Save Changes" 버튼을 눌러 저장하게 되면, 해당 작업테이블이 plugins/alogblog/webCron/ 폴더 밑에 쓰여집니다. 만약 이 폴더를 생성하고 그 밑에 파일을 작성할 권한이 없다면 MT가 에러 메시지를 보이는데, 이럴 경우에는 직접 webCron폴더를 alogblog/ 밑에 생성하고 쓰기권한을 부여해줘야 합니다.
Taste a Pie
아래 단계를 거쳐 시험삼아 스케쥴러의 작동 확인을 해 봅니다.
- 먼저 플러그인을 설치합니다.
- <$MTWebCronTrigger$> 태그를 Main Index 템플릿의 맨 밑 body 태그 앞부분에 삽입하고 "Save and Rebuild" 해줍니다.
- 테스트 엔트리를 하나 작성하고 Post Status를 "Scheduled"로 정한 후, Authored On을 미래의 시간으로 정합니다.(지금은 테스트 단계이므로 금방 알아보기 위해서 현재시간보다 1분 정도의 미래 시간으로 정합니다.). 엔트리를 저장한 후에, 엔트리 목록(Entries) 페이지로 가서 전체 엔트리 목록을 보면, 지금 작성한 엔트리가 "Scheduled" 상태로 나타남을 볼 수 있습니다.
- 이제 남은 작업은 스케쥴링 작업 테이블을 작성하는 것입니다. 현재 블로그의 플러그인 메뉴 페이지로 가서 WebCron 설정 부분에서 Interval 값을 디폴트 0에서 다른 간격값으로 바꿉니다. 지금은 테스트 단계이므로 금방 적용해보기 위해 10 정도의 값으로 해봅니다. 즉, 10초 간격으로 확인한다는 의미인데, 실제 상황에서는 너무 잦은 확인 값입니다. 물론 이 간격이 좁을 수록, 실제 스케쥴링 작업의 시간 정확도는 커지겠지만, 그만큼 자주 확인을 해야하므로 이는 곳 서버의 로드를 증가시크는 작은 원인이 될 것입니다. 설사 로드 자체가 크진 않다 하더라도, 자신이 미래공개 설정을 자주 사용하지 않거나 혹은 모블로깅을 1주일에 2~3번 보내는 환경에서 1분,10분 등의 확인은 쓸데 없는 오버로드가 될 것입니다.
- 이제 모든 설정은 끝났습니다. 여기서 하나 알아두실 것은 이 플러그인은 pseduo cron 플러그인이라는 점입니다. 즉 스케쥴링의 확인을 서버의 서비스 차원에서 매초 확인하는 메카니즘이 아니라, 바로 방문객의 블로그 방문에 의한 특정(보통 메인 인덱스 페이지) 페이지 요구를 trigger삼아 작업을 확인하고 실행한 다는 점입니다. 고로 이제 여러분이 잠시 블로그의 방문객 역할을 수행해야 합니다. 즉, 트리거 태그를 삽입한 페이지를 브라우져로 열어 봅니다. 만약 Interval 시간간격을 넘어서 접근했다면, 해당 작업이 백그라운드로 수행이 될 것입니다. 해당 작업시간(이 경우엔 리빌딩 시간)이 지난 후에, 결과를 확인할 수 있게 됩니다. 해당 엔트리의 상태를 "Publish"로 바꾸고 다시 이를 리빌딩하는데 수 초 정도의 시간이 소요되니까, 적당한 시간 후에, 메인 인덱스 페이지를 다시 열어보면, 테스트 엔트리가 퍼블리시되어 나타남을 볼 수 있습니다. 와우~ 친절한 webCron.
Note
만약 여러분이 미래의 특정한 시각에 어떤 작업이 정확히 수행되길 원하신다면, 이 플러그인은 마땅한 해결책이 되지 못합니다. 예를 들어, 알람 시스템처럼 특정한 시간에 1~2초의 오차범위 내에서 어떤 작업이 수행되길 원하신다면, 돈을 많이 버셔서 cron 서비스를 이용하시는 수 밖에 없습니다.(사실 그 정도 오차는 cron서비스를 이용한다해도 실제 작업시간의 소용을 감안한다면 힘들다 보이지만...) 하지만, 대부분의 블로그 시스템에서 필요한 스케쥴링 작업은 이처럼 특정한 시각에 수행되어야 하는 것 보단, 임의의 시간 간격내에서 처리만 되면 충분한 성격이 훨씬 많습니다. 이 플러그인은 그런 경우에 적합합니다.
Question:
어떤 엔트리를 올해 마지막날 자정으로 시간을 맞춰서 "Scheduled"상태로 저장한 후에, 작업 테이블까지 설정을 끝냈습니다. 그런데 재수없게도(?) 내년 정초부터 한 달 동안, 블로그에 아무런 방문객이 없는 경우에, 그 엔트리는 어떻게 되는 겁니까?
Answer:
아무런 방문객이(즉, trigger되지 않는) 없는 그 한 달 동안, 정초에 실행(즉 퍼블리싱되도록)되도록 설정한 그 엔트리는 여전히 MT 데이터베이스 내에만 존재하고, 정초 이후에도 실제로 퍼블리싱되어 블로그에 나타나지 않을 것입니다. 이런 경우에도 cron 서비스를 통해 스케쥴링을 했다면, 방문객의 존재 여부와 상관없이 정초 후에는 블로그에 나타날 것입니다. 이 점이 돈내고 쓰는 서비스와 의사 서비스의 차이점입니다.
그럼에도 다행스러운(?) 점은, 방문객이 없는 동안에는 설사 블로그에 공개해 퍼블리싱해놓았다손 치더라도, 없는거랑 하나도 다를게 없다는 점입니다. "관객 한 명 없는 공연장에서의 세기의 열창은 아무런 의미가 없다" 가 이 플러그인의 바탕에 깔린 사상(?)입니다.
License
Released under the Creative Commons License.
Version History
- 3.2.01: for MT 3.2
Post a comment