Minseok's Daily

카테고리

게시일

Jan 5, 2026

Worker-Dispatcher 모델

Worker-Diapatcher 모델은 Dispatchar가 job을 받아오면 Worker 들에게 Job을 뿌리는 모델이다. 대부분의 worker-dispatcher모델은 중간에 redis와 같은 메시지브로커를 사용해, queue로 들어온 job들을 dispatcher가 worker들에게 할당한다. 중요한건 dispatcher와 worker들은 절대로 직접소통하지 않고, 오직 메시지브로커, redis로만 통신을 한다는 것이다.

메시지브로커를 둔 이 모델은 worker 하나가 망가져도 다른 worker가 자동으로 대체할 수 있어 가용성을 크게 늘릴 수 있고, 유연하게 확장도 쉽게 가능하다.

Kubernetes와 Docker와 함께 사용하면, 가상 컨테이너 단위로 Worker를 쪼개 가용성과 확장성을 더욱 늘릴 수 있다.

Dramatiq가 뭐죠?

Dramatiq는 파이썬에서 Worker-Dispatcher 모델을 구현하는 툴킷이다. Dramatiq에서는 Worker를 Actor라고 부른다. Actor를 정의하고, 브로커로 redis를 연결한 다음 dramatiq 명령어로 actor를 시동 하면, 알아서 redis에서 job을 받아와 실행한다.

Dramatiq의 가장 큰 특징은 “심플”하다는 것이다. Dramatiq Actor에게 job을 주려면, 아래 두 내용만 알면 된다.

Actor-Name

인자

이 두개만 알면, 다른 파이썬 프로젝트에서 마치 함수 호출하듯 job을 쉽게 주는게 가능하다. 별도로 actor의 코드를 import할 필요도 없다. 이게 가능한 이유는 메세지브로커에 함수 호출문을 직렬화하면, Dramatiq에서 역직렬화하기 때문이다. 알아서 준비된 Actor가 redis에 enqueue된 직렬화된 함수 호출문을 보고 가져와서 실행한다.

프로젝트 구조 예시

아래 예시는 그저 예시일 뿐, Dramatiq에서는 명확한 폴더 규칙을 강제하지 않는다.


repo/
├─ common/
│  └─ tasks.py <- 여기에 actor를 호출할 수 있는 함수 원형
├─ api/
│  └─ main.py <- 여기에 FastAPI 나 Django 등
└─ workers/
   └─ email.py  <- 여기에 dramatiq actor 코드

/wokers/* - Dramatiq Actor 정의


# workers/email.py
import dramatiq

@dramatiq.actor
def send_email(user_id: int) -> None:
    print(f"send email to user {user_id}")

/common/tasks.py - actor를 호출하는 원형 함수


# common/tasks.py
from workers.email import send_email

def request_send_email(user_id: int) -> None:
    send_email.send(user_id)

각자 이걸 import하면 된다.

/api - 다른 프로젝트에서 사용 (예제 : FastAPI)


# workers/email.py
import dramatiq

@dramatiq.actor
def send_email(user_id: int) -> None:
    print(f"send email to user {user_id}")

만약 Docker 배포를 하려면?

각 프로젝트의 결합도와 코드베이스 크기를 보고 Docker Image 배포단위를 설정하면 된다.

각 worker 배포

각 worker는 한 docker image에 두고, entrypoint를 차별화하여 여러 worker를 docker별로 돌리는 방법이 간단하지만, 만약 각 worker가 엄청 커진다면 이것도 worker별로 docker image를 나누는 것이 좋다.

workers와 API 통합 배포

1. workers와 api가 다른 docker image로 배포될 경우

workers와 api는 각자의 dockerfile을 갖고, 각자 docker image를 가지게 될 것이다.

이 경우에는 각 docker image에 common workers와 api가 둘 다 갖출 수 있도록 해야한다.

2. workers와 api가 같은 docker image로 배포될 경우

worker와 api는 서로 결합도가 높다고 볼 수 있다. (둘 다common/tasks 를 import해야 하니) 이 경우에는 차라리 docker image안에 두 프로젝트를 함께 넣고, entrypoint로 제어하는게 나을 수도 있다.