알림 전송의 큐와 실행 자리를 함께 나누기

알림 전송도 대시보드 작업의 빈자리를 기다렸다

LearningX의 스마트 알림 전송 작업은 원래 dashboard 큐에 들어갔다. 대시보드 집계와 알림 전송이 같은 소비 워커를 쓰면, 집계가 실행 자리를 차지하는 동안 알림도 그 줄에서 기다려야 한다. 알림 작업 자체를 가볍게 만들어도 앞서 실행 중인 다른 종류의 작업은 끝나지 않는다.

변경은 콘텐츠별 스마트 알림 전송을 smart-notification 큐로 옮기고 전용 워커를 추가했다. 이것은 알림에 우선순위 숫자를 주는 수정이 아니다. 알림을 실행할 자리를 대시보드 작업과 따로 배정한 변경이다.

보내는 큐를 바꾸려면 받는 워커도 있어야 한다

SendSmartNotificationByContentJob 생성자는 작업의 큐를 지정한다. 아래는 라우팅에 해당하는 한 줄이다.

$this->queue = 'smart-notification';

이 한 줄만 바꾸면 알림이 전용 큐에 쌓여도 소비자가 없을 수 있다. 함께 추가된 PM2 설정은 같은 큐 이름을 명시해 두 프로세스를 띄운다. 아래는 해당 워커 설정의 발췌다.

- name: learningx-smart-notification-worker
  script: artisan
  exec_mode: fork
  interpreter: php
  instances: 2
  args:
    - queue:work
    - --queue=smart-notification
    - --timeout=3600
    - --tries=1

일반 워커에 --queue가 없다는 것을 “이 서버의 모든 큐를 처리한다”로 읽으면 안 된다. 일반 워커는 연결의 기본 큐를 쓰고, 여기서 분리한 두 큐는 각각 명시된 소비자가 맡는다. 생산자의 큐 이름, 소비자의 인자, 프로세스 수가 함께 실행 구조를 결정한다.

대시보드 대기는 분리하지만 공용 자원은 남는다

전용 워커 두 개를 배정하면 대시보드 워커가 모두 바빠도 알림 소비자가 작업을 시작할 수 있다. 대가는 추가 프로세스와 메모리다. 알림이 없을 때 그 실행 자리는 놀 수 있고, 대시보드가 바쁘다는 이유만으로 그 자리를 자동으로 빌려주지는 않는다.

DB와 네트워크는 여전히 공유한다. 알림끼리 밀리는 상황도 전용 큐 안에 남는다. 따라서 이 설정에서 특정 전송 시한, 공정한 분배, 자동 확장까지 보장되지는 않는다. --timeout=3600과 --tries=1 역시 소비 워커의 실행 설정이지 알림이 한 시간 안에 반드시 전달된다는 약속은 아니다.

변화 없는 출결 이벤트를 줄인 변경은 만들어지는 후속 작업의 양을 다룬다. 전용 큐는 남은 작업이 어느 실행 자리를 기다리는지를 다룬다. 두 변경은 서로 다른 지점에 작용한다.

워커 설정을 추가한 것과 실행 중인 것은 다르다

배포 명령에는 PM2 설정 파일을 시작하고 상태를 저장하는 queue:add-queue-worker 호출도 연결됐다. 기존 일반 워커가 온라인이 아니었던 서버에서는 시작한 워커들을 다시 중지하는 분기가 있다. 같은 배포 절차를 실행해도 그 서버가 실제 소비 역할을 맡는지는 이 분기를 함께 봐야 한다.

배포 명령의 권한 분기 테스트는 권한 확인을 모킹해 비관리자 실행의 거부를 검사한다. 실제 PM2 기동이나 알림 전달을 확인하는 시험은 아니다. 더구나 프로세스 실행 도우미는 명령 실패를 출력한 뒤 반환할 수 있으므로, 배포 호출이 끝났다는 사실만으로 모든 워커가 정상 실행 중이라고 판단할 수 없다. 이 사례의 핵심은 큐를 나눌 때 생산자와 소비자의 설정을 함께 맞추고, 실행 상태는 별도로 확인해야 한다는 점이다.