영상 인코딩 분산과 워커 회수

요약

업로드 확정 트랜잭션에 인코딩 작업 행을 함께 저장하고, BE EC2와 AI EC2에서 도는 같은 JAR이 FOR UPDATE SKIP LOCKED로 작업을 한 건씩 가져간다. 선점할 때 받은 토큰과 임대 시각이 종결 UPDATE의 조건이라, 죽은 워커의 늦은 결과는 0행으로 끝나고 롤백된다. 별도 큐 서버도, 로드 밸런서도 없다.

인코딩 입력은 10.08초, 15.08초, 19.10초 MP4 세 편이고 3회 모두 같은 SHA-256을 썼다.

고친 문제

이전 인코딩은 스프링의 @Async 실행기, 즉 프로세스 메모리 안의 큐였다. 여기엔 두 가지 약점이 있다.

• 프로세스가 내려가면 대기 작업이 사라진다. 배포나 재시작 한 번에 업로드는 끝났는데 인코딩은 영영 안 도는 영상이 생길 수 있다. 영상 커밋과 작업 등록이 같은 트랜잭션도 아니어서, 영상만 남고 작업이 빠지는 창도 있었다.
• 다른 서버가 도와줄 수 없다. 큐가 메모리에 있으니 AI EC2가 놀고 있어도 BE EC2의 작업을 가져갈 방법이 없다.

수치로 보면, 2026-08-27 dev에서 10초에서 20초짜리 MP4 세 편을 연속 업로드했을 때 READY까지 9.4초, 15.8초, 30.4초가 걸렸다. 한 서버에서 FFmpeg 두 개를 병렬로 돌려 봐도 순차 20.38초 대 병렬 19.60초라 스레드를 늘려서는 처리량이 늘지 않았다. t3.small 한 대의 CPU가 병목이었고, 답은 "다른 서버도 쓰자"였다.

설계

왜 DB 테이블인가

작업 대기열을 어디에 둘지가 첫 결정이었다. 기준은 하나다. 영상 저장과 작업 등록을 한 트랜잭션에 넣을 수 있는가. 그게 안 되면 둘 사이의 유실 창을 닫으려고 outbox와 릴레이가 또 필요해진다.

PostgreSQL 문서는 SKIP LOCKED가 일반 조회에는 맞지 않지만 여러 소비자가 큐 형태의 테이블을 나눠 처리할 때 잠금 경합을 피하는 용도라고 명시한다. 이 작업의 대기 행이 바로 그 용도다.

같은 JAR, 다른 프로필

워커 애플리케이션을 따로 만들지 않았다. AI EC2에 같은 app.jar을 dev,encoding-worker 프로필로 8081 포트에 띄운다. 이 프로필은 인코딩에 필요 없는 것을 전부 끈다. 행사 스케줄러, 블러 폴러, 알림 릴레이와 스케줄러, 시더, Flyway. Redis도 쓰지 않고 DB 커넥션 풀은 최대 2개다. JVM은 -Xmx384m으로 시작한다. 보안그룹에 8081 인바운드를 열지 않아 EC2 밖에서는 접근할 수 없다.

노드마다 인코딩 작업은 한 번에 한 건만 소유한다. 폴러가 1초마다 빈 슬롯을 확인하고, 비어 있으면 한 건을 선점해 스레드 1개짜리 실행기에 넘긴다. CPU를 읽어 작업을 반대 노드로 밀어 주는 분기는 없다. 빈 노드가 다음 행을 먼저 가져가는 경쟁 자체가 분배다.

선점 토큰과 임대

선점하면 claim_token을 새 UUID로 바꾸고 claimed_by, lease_until, attempt_count를 기록한다. 임대는 35분이다. FFmpeg 호출별 상한 10분 × 3(ffprobe, encode, thumbnail)에 S3 입출력 여유 5분을 더한 값이고, 정상 처리 속도를 정하는 값이 아니라 프로세스가 강제 종료됐을 때만 쓰는 최후 회수선이다.

정상 종료는 임대를 기다리지 않는다. ContextClosedEvent를 받으면 새 선점을 막고 현재 claim을 즉시 PENDING으로 되돌린다. 통제된 종료는 처리 실패가 아니므로 attempt_count를 하나 줄여 다음 노드가 같은 시도 번호로 시작한다. SIGKILL이나 EC2 장애처럼 종료 훅을 못 탄 경우에만 35분 임대가 동작한다.

늦은 결과 차단

영상 상태를 쓰는 모든 인코딩 경로는 종결 UPDATE의 WHERE 절에서 네 가지를 확인한다.

job.id          = claim.jobId
job.status      = PROCESSING
job.claim_token = claim.claimToken
job.lease_until > 현재 UTC 시각

READY와 FAILED 종결은 업로더 행과 영상 행을 잠그고 알림 outbox를 INSERT한 뒤, 작업 COMPLETED UPDATE를 트랜잭션의 마지막 문장으로 실행한다. 0행이면 ClaimLostException을 던져 앞선 영상 전이와 알림 INSERT까지 전부 롤백한다. 임대가 만료된 뒤 다른 노드가 재선점해 토큰이 바뀌었다면, 옛 워커가 아무리 늦게 결과를 들고 와도 부분 반영이 없다.

흐름 도해

재시도는 다음 상태 전이를 따른다. 재처리 상한은 코드와 DB CHECK 제약 양쪽에서 3회다.

PENDING -> PROCESSING -> COMPLETED
                    \-> PENDING       처리 오류, 남은 시도 있음 (5초 뒤)
                    \-> DEAD          마지막 시도 중 프로세스 중단
DEAD -> DEAD(completed_at 기록)        영상 FAILED와 같은 트랜잭션

핵심 SQL

선점은 정렬이 고정된 한 행만 UPDATE하고 RETURNING으로 claim을 만든다. PENDING과 임대가 끝난 PROCESSING을 한 문장의 OR로 잡는다. 두 부분 인덱스를 BitmapOr로 합칠 수 있어서다.

WITH clock AS (
    SELECT statement_timestamp() AT TIME ZONE 'utc' AS now_utc
), candidate AS (
    SELECT j.id
    FROM video_encoding_jobs j
    CROSS JOIN clock c
    WHERE (j.status = 'PENDING'    AND j.available_at <= c.now_utc AND j.attempt_count < 3)
       OR (j.status = 'PROCESSING' AND j.lease_until  <= c.now_utc AND j.attempt_count < 3)
    ORDER BY j.available_at, j.id
    FOR UPDATE OF j SKIP LOCKED
    LIMIT 1
)
UPDATE video_encoding_jobs j
SET status = 'PROCESSING',
    attempt_count = j.attempt_count + 1,
    claim_token = :claimToken,
    claimed_by = :nodeId,
    lease_until = c.now_utc + make_interval(secs => :leaseSeconds)
FROM candidate, clock c
WHERE j.id = candidate.id
RETURNING j.id, j.video_id, j.original_s3_key, j.claim_token, j.attempt_count, j.enqueued_at;

현재 시각은 전부 statement_timestamp() AT TIME ZONE 'utc'다. CURRENT_TIMESTAMP는 timestamptz라 KST 세션에서 naive 컬럼과 비교하면 9시간 어긋난다.

정상 종료 때의 반납은 토큰과 살아 있는 임대를 확인하고, 시도 횟수를 하나 돌려준다.

UPDATE video_encoding_jobs
SET status = 'PENDING',
    attempt_count = attempt_count - 1,
    claim_token = NULL, claimed_by = NULL, lease_until = NULL,
    available_at = statement_timestamp() AT TIME ZONE 'utc'
WHERE id = :jobId
  AND status = 'PROCESSING'
  AND claim_token = :claimToken
  AND attempt_count > 0
  AND lease_until > (statement_timestamp() AT TIME ZONE 'utc');

잠금 순서는 users → videos → video_encoding_jobs로 고정했다. 회원 탈퇴 CASCADE와 같은 순서라 교차 대기가 생기지 않는다. 선점은 작업 행만 잠그고 바로 커밋하므로 FFmpeg가 도는 동안 DB 락이나 트랜잭션을 들고 있지 않는다.

장애별 처리

재시도할 때 산출물 키는 시도별 결정적 키를 그대로 쓴다. 앞선 시도가 S3 업로드 뒤 DB 기록 전에 죽어도 다음 시도가 같은 키를 덮어쓰므로 고아 파일이 늘지 않는다.

실측

2026-08-27 dev. 세 편을 병렬로 확정하고 확정 응답 시각부터 READY까지를 500ms 간격으로 조회했다. 한 회차의 세 편이 끝난 뒤 다음 회차를 시작해 3회 반복했다.

막대 순서는 작업 로그의 기록 순서이고 파일 길이 순이 아니다. 노드마다 한 번에 한 건이라 같은 노드에 두 편이 몰리면 뒤 편은 앞 편이 끝나기를 기다린 시간이 포함된다. 1회차 BE의 25.683초가 그 경우다.

아홉 편이 모두 READY와 COMPLETED로 끝났고 작업 유실, 중복 알림, 종료 뒤 미완료 작업은 0건이다. 자원은 처리 전후 순간값이다.

CPU는 처리 전후 유휴 순간값만 저장돼 처리 중 최고값으로 읽지 않는다.

장애 실험

시험이 끝난 뒤 두 노드의 임대는 기본값 35분으로 복구했다.

고쳐 온 것

구현 한 번에 끝나지 않았다. dev에서 실제로 프로세스를 죽여 보고 나서야 드러난 것들이다.

말할 때 주의

용어

출처: docs/spec/MSG-494.md 결정 D1~D7, 12.6 dev 실측, 2026-08-27 작업 로그. 원본 SHA-256과 스크립트는 load-test/measure-msg494.sh. 이 문서는 2026-09-05에 정리했다.