Airflow Worker가 32개인데 왜 모니터링에는 10개만 보일까

Airflow를 운영하다 보면 숫자가 직관을 배신하는 순간이 있습니다. 설정상 worker 수는 32 인데, 모니터링 화면을 보면 동작 중인 worker가 많아야 10개 정도로만 보이는 경우가 그렇습니다.

처음 보면 꽤 헷갈립니다.

• worker를 32개까지 늘릴 수 있다면서 왜 10개만 보이지
• Celery라서 뭔가 다른 건가
• 실제로는 더 적게 돌고 있는 건가

저도 처음에는 worker 개수 자체만 보고 생각했습니다. 그런데 이건 worker 수 와 worker concurrency 를 같이 봐야 이해되는 문제였습니다.

헷갈렸던 포인트는 이것입니다

Airflow에서 보이는 worker 는 말 그대로 프로세스를 받아서 태스크를 실행하는 실행 주체입니다. 그런데 한 worker가 동시에 하나의 task만 처리하는 구조는 아닙니다.

CeleryExecutor 환경에서는 worker 하나가 여러 task를 동시에 처리할 수 있습니다. 즉 아래 두 숫자를 같이 봐야 합니다.

• 최대 worker 수
• worker 1개당 동시 실행 가능한 task 수

이 두 숫자를 분리해서 보지 않으면 “worker가 적게 뜨는데 태스크는 왜 많이 돌아가지?” 혹은 “worker가 충분한데 왜 더 안 늘지?” 같은 오해가 생깁니다.

현재 저희 회사에서 운영 중인 구조를 보면

현재 저희 회사에서 운영 중인 구조를 보면, Airflow는 Celery 기반 worker를 사용하고 있고, 실제 계산 작업은 외부 실행 엔진으로 넘기는 경우가 많습니다. 그래서 worker는 단순 계산 노드라기보다 태스크 실행과 상태 관리를 담당하는 실행 슬롯에 더 가깝습니다.

흐름을 보면 아래와 같습니다.

graph LR
    S["Scheduler"] --> Q["Celery Queue"]
    Q --> W1["Worker 1"]
    Q --> W2["Worker 2"]
    Q --> W3["Worker N"]
    W1 --> T1["Task x 여러 개"]
    W2 --> T2["Task x 여러 개"]
    W3 --> T3["Task x 여러 개"]

여기서 핵심은 worker 하나가 task 하나만 들고 있는 구조가 아니라는 점입니다.

이번 케이스에서는 계산이 이렇게 됩니다

정리하면 이번 환경은 아래와 같습니다.

• 최대 worker 수: 32
• worker 1개당 동시 실행 가능한 task 수: 12

즉 이 환경에서 동시에 처리 가능한 전체 task 수는 아래처럼 계산할 수 있습니다.

32 * 12 = 384

즉 worker가 최대 32개까지 늘어날 수 있다고 해서, 항상 32개의 worker가 떠 있어야 정상이라는 뜻은 아닙니다. 현재 실행 중인 task 수와 queue 에 쌓인 task 수를 worker concurrency로 충분히 소화할 수 있다면, worker 수는 더 적게 보여도 됩니다.

그래서 모니터링에 10개만 보여도 이상하지 않을 수 있습니다

Cloud Composer 공식 설명을 보면 autoscaling은 단순히 최대 worker 수를 향해 바로 늘어나는 것이 아니라, Running Tasks + Queued Tasks 를 기준으로 worker_concurrency 로 나눠 필요한 worker 수를 계산하는 방식에 가깝습니다.

예를 들어 동시 실행 중인 task가 120개이고, queue 에 대기 중인 task는 거의 없다고 가정하면 계산은 아래처럼 됩니다.

running 120 + queued 0 = 120
120 / 12 = worker 10개

즉 이 경우 모니터링에서 활성 worker가 10개 정도만 보여도 이상한 상황이 아닙니다. 오히려 현재 부하를 기준으로는 자연스러운 상태일 수 있습니다.

구성도를 보면 아래처럼 이해할 수 있습니다.

graph TD
    A["동시 실행 task 120개"] --> B["worker concurrency 12"]
    B --> C["필요 worker 약 10개"]
    C --> D["모니터링상 active worker 10개"]

즉 화면에 보이는 worker 수는 “최대치” 가 아니라 현재 running + queued 상태를 감안해 실제로 활성화된 worker 수 에 더 가깝습니다.

Celery라서 이런가

어느 정도는 맞습니다. 정확히는 CeleryExecutor + worker concurrency 모델을 같이 봐야 합니다.

worker가 단순히 1:1 로 task를 처리하는 구조였다면, worker 수와 동시 실행 task 수를 거의 비슷하게 볼 수 있었을 것입니다. 하지만 Celery worker는 내부에서 여러 task를 병렬로 처리할 수 있기 때문에, worker 수만 보고 전체 처리량을 판단하면 자주 틀립니다.

즉 “worker가 10개밖에 안 보인다”는 사실만으로는 병목인지 아닌지 바로 판단할 수 없습니다. 아래를 같이 봐야 합니다.

• 현재 동시 실행 중인 task 수
• queue 에 쌓여 있는 task 수
• worker concurrency 설정
• autoscaling 조건

실무에서는 어떤 숫자를 봐야 하나

이런 상황에서는 worker count 자체보다 아래 숫자가 더 중요합니다.

1. 현재 실행 중인 task 수

지금 몇 개의 task가 동시에 돌아가고 있는지가 먼저입니다. worker 수는 그 다음입니다.

2. worker concurrency

worker 하나가 몇 개까지 동시에 처리할 수 있는지 봐야 합니다. 이 값을 모르면 모니터링 해석이 거의 안 됩니다.

3. queue가 밀리고 있는지

활성 worker 수가 적어 보여도 queue가 밀리지 않고 있다면 큰 문제는 아닐 수 있습니다. 반대로 worker는 충분해 보여도 queue backlog가 쌓이면 병목입니다.

4. autoscaling이 실제로 필요한 상태인지

최대 worker 수는 말 그대로 ceiling입니다. 항상 그 숫자까지 떠 있어야 정상이라는 뜻이 아닙니다.

데이터 엔지니어 관점에서 보면

이건 단순히 Airflow 설정 하나의 문제가 아니라, 오케스트레이터 리소스를 어떤 단위로 이해할 것인가의 문제에 가깝습니다.

Airflow에서는 자주 아래 두 층을 구분해서 봐야 합니다.

• 실행 주체 수: worker 몇 개가 떠 있는가
• 처리 슬롯 수: 동시에 몇 개의 task를 소화할 수 있는가

실무에서는 두 번째가 더 중요할 때가 많습니다. worker 수는 적어 보여도 슬롯 수가 충분하면 시스템은 정상입니다. 반대로 worker 수가 많아도 concurrency가 낮거나 queue가 밀리면 체감 성능은 좋지 않을 수 있습니다.

즉 worker 개수는 인프라 숫자이고, concurrency는 처리량 숫자입니다. 운영에서 더 중요한 것은 보통 처리량 숫자 쪽입니다.

정리

worker 수가 32인데 모니터링에는 왜 10개만 보이지 라는 질문은 꽤 자연스럽습니다. 다만 이건 worker 수만 보면 잘 안 풀립니다.

핵심은 아래입니다.

• 최대 worker 수는 32
• worker 하나당 동시 처리 가능한 task 수는 12
• 따라서 전체 처리 가능량은 384
• 현재 부하가 그보다 훨씬 작다면 활성 worker는 10개 안팎으로만 보여도 이상하지 않습니다

결국 이 문제는 “worker가 적게 떴다”가 아니라, 현재 running + queued task 규모를 worker concurrency가 충분히 커버하고 있다 로 읽는 편이 더 정확합니다.