비동기 큐 & 관측성

개요

무거운 STT+요약을 Celery 백그라운드로 처리하고, 실패를 추적·통보하는 운영 기반.

• 동기인 Celery 태스크와 async 파이프라인을 안전하게 잇는다
• async DB 커넥션은 멀티프로세스 환경에서 NullPool로 운용한다
• 구조화 JSON 로깅 + 에러 로그 테이블 + 통합 헬스체크로 관측성을 확보했다

---

왜 이 설계가 필요했는가 (Problem)

---

핵심 설계 결정

1. 동기↔async 브리지 + 결과는 DB 직접 저장

# 동기 Celery 태스크 → async 파이프라인 실행
@Celery 태스크
def 전사·요약 파이프라인(작업 ID, 오디오 경로):
    try:
        return asyncio.run(배치 파이프라인(작업 ID, 오디오 경로))
    except 예외 as e:
        async def 실패 처리():  # 새 이벤트 루프에서 후처리
            await 에러 로그 기록(작업 ID, 단계, e)
            await 상태 갱신(작업 ID, 실패, 메시지=e)
        asyncio.run(실패 처리())

2. NullPool — 멀티프로세스/루프 안전

# 멀티프로세스/루프 환경에선 풀링을 끈 NullPool 로
from sqlalchemy.pool import NullPool
엔진 = create_async_engine(DB 주소, poolclass=NullPool, ...)

3. 구조화 JSON 로깅 + 환경별 포맷

# JSON 포매터 — 로그 한 건을 JSON 한 줄로
로그 = {시각(UTC), 레벨, 로거 이름, 메시지}
if 추가 데이터가 있으면: 로그에 합침  # 작업 ID, 수치 등
if 예외 정보가 있으면: 로그["exception"] = 예외 포맷(예외 정보)
return JSON 문자열(로그)  # 한글 그대로

4. 에러 로그 테이블 + 통합 헬스체크

# 헬스체크 — 핵심 의존성 점검, 하나라도 실패면 503
DB = 연결 확인 결과
STT = 모델 로드 여부
서비스 = {api: ok, DB, Redis, STT, LLM 제공자}
if LLM 을 뺀 항목 중 하나라도 ok 가 아니면:
    return 503 + 점검 결과

---

설계가 만든 결과 (Result)

검증 결과

실패 후처리 테스트 · 13/13 통과 (pytest)

진짜 가치는 3단계 수행이 아니라 부분 실패 내성이다

마지막 항목이 핵심이다 — 후처리 실패가 원인 예외를 가려버리면 디버깅이 불가능해진다.

대역을 쓰되 원본과의 어긋남을 자동 감지한다

이 검증이 말하지 않는 것

---

주요 설정값

---

관측성의 실제 공백 — 실패는 남지만 느림은 안 남는다 (2026-08-30)

무엇이 막혔나

실시간 스트리밍의 자막 지연 5.5초를 구간별로 분해하려 했으나, 아래까지만 확인하고 멈췄다.

필요한 계측 (미구현)

부수 발견 — 설정이 코드에 가려 무력화돼 있었다