크롤링 여러번 하기

이 제목이 무슨 말인지 이해가 잘 안되시죠? 그런데 사실 위의 예제들을 직접 실행시켜보셨다면 무슨 말인지 이해가 가실겁니다. 지금까지는 모든 크롤링 관련 소스파일을 Model 부분에서 처리했습니다. 그렇게 한 이유는 사실 따로 없습니다. 일부러 이 부분을 만들기 위해서 한 것도 있구요. Controller 부분이 Scaffold로 가득차 있어서 그냥 그렇게 한 이유도 있습니다. 사실 크롤링 소스의 위치는 그렇게 중요하지 않습니다. 따로 .rb 파일을 만들어서 객체를 생성하고 돌려도 되고 어느 부분에서 돌리던 그건 자유입니다. 하지만 MVC 패턴을 위해서 만들어진 Rails에서 Controller 부분의 역할을 잘 생각해보면 크롤러를 좀 더 효율적으로 만들 수 있습니다. 이 챕터는 어떻게 보면 Rails의 MVC 패턴에 대해서 설명하는 부분입니다.

Model의 역할은 실제 객체들의 저장소인 DB의 내용을 정의하고 처리하는 부분입니다. 그렇기 때문에 중간에 변화가 일어나지 않는 이상 Model에서 내린 정의는 바뀌지 않아야 합니다. 만약에 이 프로젝트에서 중복 공지를 허용한다 하지 않는다를 정의하지 않고 시작했다면, 골치가 아파지겠죠? 그렇기 때문에 Model 부분은 전체 프로젝트를 빌드했을 때 한 번만 거칩니다. 즉 이 전에서 썼던 대로 소스를 만들어서 넣어버리면, 단 한번만 크롤링 작업이 수행된다는 의미입니다. Crontab에 아무리 해당 URL로 Get 요청을 보내도, Model에서 수행한 작업이기 때문에 첫 페이지 빌드 시에만 작업을 수행하고 다음 부터는 Controller에서는 별 말이 없어서 View의 내용을 게속 반복해서 보여줄 뿐입니다. 실시간 반복 처리가 안됩니다.

그럼 이제부터는 Conrtoller에서 처리하는 방법을 살펴보겠습니다.

#notices_controller.rb
def index
    #여기에 이전에 만든 소스를 넣어서 처리합니다.
end

왜 위처럼 처리했냐고 물어보신다면 index 페이지에 방문했을 때 해당 작업을 수행하고 싶기 때문입니다. 물론 방법은 여러가지 입니다. 하지만 페이지 방문 형태가 이해하기 쉽기 때문에 이렇게 한 겁니다. 여기서 일정 주기로 크롤링 작업을 수행하고 싶다면, 서버를 Background로 계속 띄워놓고 Get Request와 관련된 명령어를 Crontab Job으로 등록해놓으면 됩니다. Rails에서는 이 또한 Gem으로 쉽게 작성할 수 있도록 도와주고 있는데요. Whenever gem이 바로 그것입니다. 이에 대한 내용은 블로그 내용을 참조하시거나 필요 시에는 이 곳에도 추가하겠습니다.