서버 관련 기초 사항을 익히고 나니 코드를 많이 변경해야된다는 생각이 들어서 적용 해볼 수 있는 부분은 적용하려고 한다.
장고 서버 실행시 크롤링 바로 작동
: 코드를 자세히 보니 서버를 실행시 자동으로 크롤링 관련 코드가 작동되도록 설정하지 않았다는 것을 확인하였다... 맙소사.. init.py를 손봐서 바로 스케쥴러가 실행될수 있도록 하였다. 문제는 원래 잘실행되던 스크립트들이 circular import 문제를 일으키면서 작동을 안해서, 현재 해결중에 있다. 하지만, 생각을 발전시키다보니 특정한 시간에 작동하는 크롤링을 하는 작업이 비동기적으로 일어나면 더 좋을 것이라고 판단하여 아래의 비동기 작동을 위해 추가한 Celery를 이용하여 관련한 함수를 실행하는 것이 더 좋을 것이라고 판단하여 task로 추가할 예정이다. 진행중(각 앱마다 celery.py를 만들고 init.py를 설정해야한다. 각 앱에 설정되는 경우, app decorator가 아니고 shared_app decorator를 이용해야한다.)
메세지 큐 및 비동기 작동
: 클로닝을 하면서 기능적 구현에만 앞서 생각을 한 것이 뼈저리게 느껴졌다. 바로바로 응답이 되면 좋지만 반드시 바로 응답해야되는 기능은 현재의 프로젝트에서는 사실 없는 것 같았다. 따라서, 대부분의 기능들이 비동기적으로 작동을 안할 이유가 없다고 판단하여 Celery를 사용하여 비동기적으로 작동을 할 수 있는 환경을 만들기로 하였다. 비동기적으로 작동되는 부분은 일단 튜토리얼에서 나오는 간단한 기능을 실행해보는 것으로 실험을 해보았다. 또한, 이를 위해서 Redis를 메세지 큐로 사용하기로 하였다. 과정은 아래와 같다.
첫번째로, we_market 폴더 내 celery.py 생성 및 아래의 코드 작성한다. 특징은 MQ로 Redis를 사용할 것이기 때문에 app = Celery('we_market')이 아닌 app = Celery('we_market', broker=BROKER_URL, backend=CELERY_RESULT_BACKEND)로 작성해야 실행이 된다는 점이다. 전자와 같이 작성하면 MQ를 RabbitMQ로 인식하기 때문에 amqp와 관련된 오류를 뿜어낸다.
#we_market/celery.py
from __future__ import absolute_import, unicode_literals
import os
from celery import Celery
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'we_market.settings')
BROKER_URL = 'redis://localhost:6379/0'
CELERY_RESULT_BACKEND = 'redis://localhost:6379/0'
app = Celery('we_market', broker=BROKER_URL, backend=CELERY_RESULT_BACKEND)
app.config_from_object('django.conf:settings', namespace='CELERY')
app.autodiscover_tasks()두번째로, we_market 폴더 내 init.py에 아래와 같은 코드를 추가한다. 이는 서버가 실행될시에 자동으로 celery가 실행 될 수 있도록 하는 역할을 한다.
# we_market/__init__.py
from __future__ import absolute_import, unicode_literals
from .celery import app as celery_app
__all__ = ('celery_app',)이후, redis-server로 redis 서버를 키고 celery -A we_market.celery worker --loglevel=info로 celery를 실행하고 django shell에서 비동기적으로 실행하려는 함수를 import하여 celery에 해당 함수가 제대로 들어갔는지 확인하여 문제없이 동작하는 것을 확인하였다.
아쉬웠던 점
-
크롤링한 데이터를 저장하는 table을 만들때 각 데이터 객체마다 크롤링이 진행된 시간을 저장하는 컬럼을 만들었어야 됬을 것 같다. 현재, 크롤링 관련 함수들이 돌아갈때 데이터 용량 관리를 위해 기존에 크롤링한 데이터를 모두 지우고 크롤링을 다시 진행하여 데이터들을 저장하는 방식이다. 이는 현재 crawl_product 데이터 테이블이 가장 최신의 데이터를 가지고 있게 하는 방법일 것이다라는 생각에서 사용한 방법이다. 하지만, 시간 항목을 추가하여 데이터 테이블을 구성하면 관련한 중고 거래글을 봤을 때 언제 업데이트되어진 새가격인지를 알 수 있다는 장점이 있기 때문에 비슷한 환경을 구성하게 된다면 다음에는 데이터 추가 시간을 넣는 선택을 할 것 같다.
-
설계에서 비동기적으로 돌아가야하는 기능, 동기적으로 돌아가야하는 기능에 대해서 큰 생각을 하지 않고 설계를 하여 아쉽다. 다음 프로젝트에서는 이를 가만하여 설계를 진행해 각 기능을 보다 넓게 사용하고 싶다.
아직 부족한게 많다.. 하지만 새로운 걸 공부하고 적용해보는 건 매우 재밌는 것 같다.
