Celery 관련 기사/튜토리얼/How-To를 읽고 메모한 내용
Celery 관련 자료를 읽고 요약(이라 쓰고 '선택적 집중', '취사선택', '선호에 의한 정보 전달')
한글 / 한국어 가능/능통자가 읽기에 가장 좋음. 이거 읽으면 대충 다 이해 됨. 모르는건 따로 메모해서 검색하면 구글에서 알려줌. 그런데 구글에서 알려주는 자료의 단점은 영어 / 잉글리쉬 능통자에게 유리하다는 점.
2. 기타 읽은 자료 목록(거의가 Full Stack Python에서 검색해서 읽음)
설정 노하우를 전수해주는 글 임([...] few essential configuration tips I’ve taken away from the experience.)
-
전역 'time out'을 설정하고, '안'전역도 'time out'을 적당하게 설정하는 것을 권장함. 'time out'에 관한 더 자세한 사항은 Soft time limits in Celery, 그러나 가보지 않았음~~(난 그런 사람이 아니였음)~~
-
-Ofair옵션은 큐에 넘쳐나는 작업들이 지연의 원인이 되기도 하는데 이럴 때 조금 더 'fair~~(헬조선의 fair함이 아님)~~'하게 배치시켜 준다고 함. 이 옵션으로 'cost penalty'를 부담하게 될꺼라고 말했지만, IO-bound task의 경우 좀 더 예측 가능한 형태로 처리 가능하다는 장점이 있다고 함.
나라면 예측 가능성에 한표 던지겠음 -
retry delays, 급격한 재실행은 우리를 혼돈의
탈라도르대지로 인도하기 때문에 이런 일이 발생하지 않도로 재실행 과정을 잘 인도하자(오오!! 라임!!)
3가지 명심해야 할 점을 설명하고 있으나, 사이트가 사라졌는지
archive.is에서 검색해서 부활시켜 읽음
-
Celery 작업 중에 프로세스를 생성 할 수 없음, 유닉스가 daemonized processes에서 쉽게 orphaned processes를 생성할 수 있기 때문에 sub-processes 생성을 허용하지 않음(The underlying problem is that UNIX doesn't allow daemonized processes to create sub-processes as it would easily lead to orphaned processes.). 해결책은 Celery 3.0.x를 사용하거나 multiprocessing 라이브러리를 사용하지 않도록 함
(이토록 완벽한 해결책이라니!) -
체인 작업시 매개변수 제한됨. 특히 매개변수를 튜플 형태로 전달하게 되기 때문의 주의해야 한다고 함. 해결책은 튜플을 풀어서 넘기거나, 단일 매개변수를 사용하는 것. 해당 기사에서 튜플을 풀어서 넘기는 멋진 코드를 선보이고 있음. 그러나 이런 복잡한 일을 하진 않을꺼임. 비즈니스 로직을 극도로 단순화 시킬 수 있도록 권력을 가저야겠음
-
조별 과제 상황이 발생하기도 함. 한 명이 열심히 일하는 동안 다른 애들은 열심히 대기타고 있는 현상이 목격. 왜냐하면 브로커가 메세지를 인증하는 방법 때문. 이러한 문제를 해결하는 방법은 ACK 시점을 조절하는 것임(필요하다면 본문에 소개되어 있으니 링크타고 고고씽!).
-
이 글의 말미에 " I recommend you spend some time reading the official documentation. "라는 아름다운 조언이 등장함. 매우 공감하고 격하게 동의함.
그럼에도 이렇게 튜토리얼을 찾아서 돌아다니는건 내가 게을러서가 아니라 귀찮기 때문이라고 노트에 메모해 두었음.
정말 베스트임. 꼭 읽어보길 권함
-
AMQP 브로커를 DB처럼 사용하지 말 것을 권장함. 다른 어떤 구절보다 'you get 4 processes polling the database' 이 정도 구절이면 쓰지 말아야 할 이유로 충분함
-
다른 큐도 만들어서 사용할 수 있음. 서로 다른 일은 서로 다른 큐에 담아서 사용하는 것이 관리를 위해서 좋음.
-
우선순위 Worker를 활용.
-
Celery의 error handling을 잘 사용하는 방법 소개. 특히 default_retry_delay, max_retries 활용법을 소개하고 있음
-
모니터링은 'Flower'를 추천. Web 기반의 모니터링은 Flower를 추천. 그럼에도 불구하고 난 'events' 선호
-
'CELERY_IGNORE_RESULT = True'. 이 옵션에 대해선 너무 많은 곳에서 다루고 있으니 P!A!S!S!
-
DB/ORM 오브젝트를 task에 전달하지 말 것. 직렬화된 객체는 쓸모없는 데이터를 포함하고 있기 때문에 주의 할 것
RabbitMQ를 사용하려고 마음 먹고 있었지만 절대 흔들리지 않는 마음을 가지게 해주었음
-
Large Setup. 여러개의 worker를 소환해서 사용하는 방법 소개
-
Scaling Features. I/O 작업이 큰 일의 경우
eventlet이나gevent를 활용하는 방법을 추천 -
Common Patterns. good best practices 읽어보면 django를 배웠어야 했음을 온 몸으로 느낄 수 있음
-
Key Choices. 브로커로 RabbitMQ 사용을 추천함. Redis도 좋으나 Redis의 경우 '오빠는 좋은사람이지만, 난 저 오빠가 좋아'같은 느낌~~(눈물이)~~을 받게 됨. 그런데, 'result store'의 경우 Redis를 추천. 봐, '오빠(==redis)는 좋은 사람'인건 확실하나 브로커는 아닌 것 같음