본문 바로가기

[Python]/[Flask & Django]

[Celery] Side-Project(Ant Platform) - 2. Flask에서 Celery로 비동기작업 수행하기(실습환경 구축)

728x90

[ 이게... 확실히 포스팅 한번엔 안끝나겠네...]

  외국 유툽이나 강좌를 찾아봐도, 보통 Celery를 Django랑은 많이 연결해서 쓰는데, Flask에 적용시킨 예제는 없어서 난감했다;; 어짜피 전체적인 로직은 똑같아 그냥 쓰면 될것 같으면서도, 배움이 짧은 탓에 더 좋은 적용방식을 알고 싶었기 때문이다. 그러다가 좋은 실습하나를 발견해서 처음부터 끝까지 뜯어보면서 공부하기로 했다.

지난 포스팅 :  buildabetterworld.tistory.com/139

 

[Celery] Side-Project(Ant Platform) - 1. Celery를 사용해 보자!

이전 포스팅 : Cloud-Monitoring으로 VM인스턴스 로그 분석하기 buildabetterworld.tistory.com/124?category=859595 [GCP] Cloud Monitoring 로 VM 인스턴스 로그 수집하기 - 2. 부하테스트(Locust) [ 부하테스트..

buildabetterworld.tistory.com

    이번에는 실제 프로젝트에 적용시키기 위해, flask와 celery를 통합하는 과정을 공부해두기로 했다. 가장 핵심이 되는 내용은 아래의 포스팅을 참고했다. 내가 알고 싶어하는 내용들이 너무 잘 포스팅되어 있어서 하나씩 뜯어보기로 했고, 추가적인 내용은 포스팅 하단 세 링크를 참고했다.

testdriven.io/blog/flask-and-celery/

 

Asynchronous Tasks with Flask and Celery

This post looks at how to configure Celery to handle long-running tasks in a Flask app.

testdriven.io

 

[ 실습 요약 ]

간단한 예제를 통해, Docker, Celery, Redis를 이용한 long-running Flask app이 어떤 구조로 이루어져 있는지 이해한다.

 

[ 소개된 WorkFlow ]

매번 개념을 따로따로 이해하고 있었는데 블로그에 소개된 이 flow-chart를 보니까 한눈에 이해가 되었다!

1. 먼저 Client단에서 서버단으로 요청이 가면 Flask에서는 Broker(메세지(task)를 전달하는놈, 전 포스트 참고)에게 작업을 넘겨주고, 
    Client에게는 Task-ID를 돌려준다.

2. (그와 동시에 백엔드에서는 Worker(일하는놈)가 Broker에서 작업을 계속 따오고 결과를 다시 Backend(저장소)에 저장한다. 이 작업은        계속해서 백그라운드로 돌아가고 있다)

3. AJAX를 이용해서, task의 상태를 확인하고, 결과를 Backend에서 가져와 응답한다. -> 여기서 궁금한 점은 status를 broker에서 확인한다는 점이였다. 결과는 backend에 저장되니까 status는 backend에서 확인하는 것이 맞는것 아닌지.. 공부를 좀 더 해봐야겠다.

 

[ 프로젝트 설치과정 ]

1. 먼저 깃에서 해당 프로젝트를 클론해온뒤, branch를 master로 변경해준다.

git clone https://github.com/testdrivenio/flask-celery --branch v1 --single-branch
cd flask-celery
git checkout v1 -b master

 

2. root dir에 미리 만들어진 yml파일을 사용해 docker-compose로 프로젝트를 실행한다. (-d 플래그는 백그라운드)

docker-compose up -d --build

그리고 http://localhost:5004 에 접속하면 다음과 같은 화면을 볼 수 있다. 우측은 빌드 완료후 테스트 수행 화면이다.

3. 테스트를 수행하여 정상적으로 동작하는지를 확인한다.

docker-compose exec web python -m pytest

[ 동작 확인 ] 

    Task를 몇개 찍어보니 ID와 Result에 undefined값이 뜨면서, docker log를 통해서 get요청이 다수 발생한 것을 알 수 있었다. 아마 저 short,mid,long term의 작업을 요청했을 때, background상에서 어떤식으로 작업처리가 이루어 지는지를 간략화하여 보여주는 예제인듯 하다(이런 멋진 사람들!!)

일단 여기까지 하고, docker-compose down으로 실행을 종료시켰다.  대충 어떤 방식인지 감이 오기 시작했다. 다음에는 이 요상한 Task-Trigger부터 시작해서 전체적인 프로젝트 구성을 살펴보고 하나씩 뜯어볼 예정이다.

 

다음 포스팅 내용 : 이어서 Task-Trigger부분 학습

 

참고:

docs.celeryproject.org/en/stable/getting-started/index.html

 

Getting Started — Celery 5.0.5 documentation

 

docs.celeryproject.org

prettyprinted.com/

 

Pretty Printed

Copyright © PrettyPrinted.com 2019

prettyprinted.com

728x90