[Celery] Side-Project(Ant Platform) - 4. Celery Logs, Flower Dashboard

[ Celery Logs ]

이번엔 Celery를 통해 로그를 남겨보도록 하겠다.
1. docker-compose.yml파일을 열고 내부에 로그 관련 설정들을 추가해 준다.

version: "3.8"

services:
  web:
    build: .
    image: web
    container_name: web
    ports:
      - 5004:5000
    command: python manage.py run -h 0.0.0.0
    volumes:
      - .:/usr/src/app
    environment:
      - FLASK_DEBUG=1
      - APP_SETTINGS=project.server.config.DevelopmentConfig
      - CELERY_BROKER_URL=redis://redis:6379/0
      - CELERY_RESULT_BACKEND=redis://redis:6379/0
    depends_on:
      - redis

  worker:
    build: .
    command: celery worker --app=project.server.tasks.celery --loglevel=info --logfile=project/logs/celery.log
    volumes:
      - .:/usr/src/app
    environment:
      - FLASK_DEBUG=1
      - APP_SETTINGS=project.server.config.DevelopmentConfig
      - CELERY_BROKER_URL=redis://redis:6379/0
      - CELERY_RESULT_BACKEND=redis://redis:6379/0
    depends_on:
      - web
      - redis

  redis:
    image: redis:6-alpine

2. logfile 옵션에 따라 해당 위치에 로그파일을 올린 다음, 도커를 다시 빌드해준다.

docker-compose up --build

그러면 이런식으로 로그를 남기게 되면 클라이언트 페이지에서 task를 추가해 주었을때, 아래와 같은 요청들이 들어가면

이런식으로 로그들을 자동으로 남겨준다. 

 

 

[ Celery Flower ]

  Celery는 가볍고, 웹상에서 실시간으로 Celery의 상태를 모니터링할 수 있는 툴이다.  설치방법은 간단하다. docker-compose.yml파일에 다음과 같은 dashboard항목을 추가해주고, requirements에는 'flower==0.9.7' 항목을 추가해 설치해 준다.

dashboard:
    build: .
    command:  flower --app=project.server.tasks.celery --port=5555 --broker=redis://redis:6379/0
    ports:
      - 5556:5555
    environment:
      - FLASK_DEBUG=1
      - APP_SETTINGS=project.server.config.DevelopmentConfig
      - CELERY_BROKER_URL=redis://redis:6379/0
      - CELERY_RESULT_BACKEND=redis://redis:6379/0
    depends_on:
      - web
      - redis
      - worker
      

그리고 다시 빌드하면, 다음과 같은 화면을 http://localhost:5556 에서 볼 수 있다.

몇가지 task들을 찍고 task를 보면 다음과 같이 이쁘게 현재 진행중인 task들의 상태와, 완료된 task를 uuid와 함께 볼 수 있다.

[ More Workers,  Final Test ]

이번에는 Worker들을 늘려서 진행해보도록 하겠다. 다음 명령어로 scale을 늘려준다.

docker-compose up -d --build --scale worker=3

그리고 1,2,3에 대한 task를 하나씩 실행하는 테스트 예제코드를 작성하고 실행하면 아래와 같이 대략 60초 정도 걸리는 것을 알 수 있다.

이번에는 worker가 1인 경우와, 3인경우를 비교해보기 위해 웹상에서 9개의 task를 전송하고 flower dashboard로 확인해보기로 했다.

1. 먼저 work가 1개인 상태로 빌드했을 경우 9개의 task가 발생한 경우이다. 

2. 다음은 worker가 3개인 상태로 빌드했을 경우 9개의 task가 3개의 worker에 잘 분산된 경우이다. 결과에서 확인할 수 있듯, Load Average의 첫번째 값이 월등히 줄어들었다. 각 task마다 runtime은 10,20,30초로 각각 고정되어 있으므로  worker를 늘렸다 하더라도 각각의 task는 담당해야 하는 시간이 고정이라 최근  5분,15분의 값은 크게 차이가 나지 않지만 , 최근 1분의 부하 평균은 크게 줄어든 것을 볼 수 있다.