여러 NestJS 노드에서 cron 작업을 어떻게 조정하나요?

Question

IT Interview Practice · Accepted Answer

먼저 ‘한 노드만 cronjob을 실행한다’의 의미를 정의합니다. **동시 실행 방지와 업무 효과의 중복 방지는 다른 요구입니다.** 공유 스케줄러가 실행을 조정하더라도 작업 자체가 장애 후 재시도에 안전해야 합니다.

세 NestJS 노드에 배포된 일일 청구 작업을 생각해 봅시다. 예정된 일은 수행하되 워커가 재시작할 때 청구서를 또 만들지 않아야 합니다.

## 1. 모든 노드가 작업을 시작하는 이유를 이해합니다

각 애플리케이션 인스턴스는 자체 cron 콜백을 등록합니다. 정해진 시간이 되면 각각 독립적으로 시작할 수 있습니다.

```text
00:00 -> Node A -> invoice task
      -> Node B -> invoice task
      -> Node C -> invoice task
```

로컬 isRunning 플래그는 한 프로세스에만 존재합니다. NestJS waitForCompletion은 해당 인스턴스의 콜백 중첩을 막지만 다른 노드와 조정하지 않습니다. 세 노드에 같은 플래그를 넣어도 독립된 판단 세 개가 남습니다. [NestJS 스케줄링](https://docs.nestjs.com/techniques/task-scheduling).

따라서 어떤 작업이 존재하고 누가 처리할지를 결정하는 공유 지점이 필요합니다.

## 2. 조정 모델을 선택합니다

| 상황 | 검토할 방식 | 남는 책임 |
| --- | --- | --- |
| 플랫폼에 예약 작업 기능이 있음 | 웹 인스턴스 밖에서 스케줄링 | 중첩, 복구, 누락 실행 동작을 설정합니다. |
| 팀이 BullMQ를 운영 중 | 공유 Job Scheduler와 전용 큐 | 전역 동시성과 안전한 재시도를 설정합니다. |
| 작업이 앱 노드에 남아야 함 | 공유 잠금 또는 임대 | 소유권, 만료, 오래된 워커를 정확히 처리합니다. |

청구 예시에서 Redis와 BullMQ가 이미 있다면 안정적인 스케줄러 ID를 가진 공유 스케줄러가 실용적인 후보입니다. 스케줄과 워커를 분리해 웹 노드 추가가 독립 스케줄을 만들지 않게 합니다.

지원하는 BullMQ 버전에서 전용 큐의 전역 동시성을 1로 설정합니다. 전체 워커의 활성 작업 수를 제한합니다. 각 워커의 로컬 동시성을 1로 두는 것만으로는 여러 워커가 서로 다른 작업을 동시에 실행할 수 있습니다. [전역 동시성](https://docs.bullmq.io/guide/queues/global-concurrency).

어제 작업이 아직 실행 중이면 기다릴지, 건너뛸지, 실행분을 합칠지 결정합니다. 시간대와 중단 중 빠진 업무 날짜를 나중에 처리할지도 정합니다.

## 3. 작업뿐 아니라 청구서를 보호합니다

워커가 청구서를 만든 뒤 완료 기록 전에 죽었다고 가정합니다. 청구서가 이미 있어도 복구 과정에서 작업이 다시 실행될 수 있습니다.

```text
[Create invoice] -> [Crash before completion]
                              |
                            [Retry]
                              |
                  [Same business key: reuse result]
```

고객과 청구 기간처럼 안정적인 업무 키를 사용합니다. 로컬 데이터베이스에서는 고유 제약과 트랜잭션으로 청구서 생성과 완료 기록을 묶을 수 있습니다. 재시도는 새 청구서를 만들지 않고 기존 결과를 찾습니다.

외부 제공자에는 지원되는 멱등성 키를 쓰고 불확실한 결과를 대조합니다. 큐 작업 ID나 보존된 작업 기록만으로 업무 동작이 영구적으로 중복되지 않는다고 보장할 수는 없습니다. [멱등 작업](https://docs.bullmq.io/patterns/idempotent-jobs).

## 4. 잠금의 보장과 한계를 이해합니다

공유 잠금은 원자적으로 획득해야 합니다. 소유 토큰, 만료, 갱신을 사용하고 토큰이 여전히 일치할 때만 해제합니다. 그렇지 않으면 오래된 워커가 새 워커의 잠금을 해제할 수 있습니다.

만료에는 또 다른 경우가 있습니다. 멈췄던 워커가 임대 만료 뒤 재개할 때 새 워커가 이미 실행 중일 수 있습니다. 중요한 쓰기에는 증가하는 소유 번호를 목적지가 검사해 오래된 워커를 거부하는 fencing token이 필요할 수 있습니다. 긴 timeout만으로 이 위험이 없어지지 않습니다.

조정 기능이 없을 때 소유권 없이 실행하기보다 기다릴지 결정합니다. 중요한 결과를 만드는 작업에는 대기가 더 안전한 경우가 많습니다.

## 5. 실패 사례를 검증합니다

여러 노드, 청구서 생성 직후 장애, 임대보다 긴 정지, Redis 연결 단절, 롤링 배포를 시험합니다. 업무 날짜, 워커, 시도, 결과를 기록해 반복 시도와 중복 효과를 구분합니다.

**기억할 점:** 스케줄 조정 → 공유 실행 제한 → 업무 동작을 재시도에 안전하게 설계 → 복구 시험. ‘활성 작업 하나’만으로 업무 효과가 정확히 한 번임을 증명하지 못합니다.

상황	검토할 방식	남는 책임
플랫폼에 예약 작업 기능이 있음	웹 인스턴스 밖에서 스케줄링	중첩, 복구, 누락 실행 동작을 설정합니다.
팀이 BullMQ를 운영 중	공유 Job Scheduler와 전용 큐	전역 동시성과 안전한 재시도를 설정합니다.
작업이 앱 노드에 남아야 함	공유 잠금 또는 임대	소유권, 만료, 오래된 워커를 정확히 처리합니다.

1. 모든 노드가 작업을 시작하는 이유를 이해합니다

2. 조정 모델을 선택합니다

3. 작업뿐 아니라 청구서를 보호합니다

4. 잠금의 보장과 한계를 이해합니다

5. 실패 사례를 검증합니다

관련 질문