5.2 MAM 전체 아키텍처

#논리 구조

MAM은 제품마다 다르지만 논리적으로는 비슷한 층으로 나눌 수 있습니다.

각 층의 책임은 다음과 같습니다.

#핵심 설계 원칙

#1) 파일과 메타데이터를 분리한다

영상 파일은 스토리지에, 파일에 대한 정보는 DB에 둡니다. DB 안에 파일 자체를 넣지 않습니다. 그리고 두 정보가 어긋나지 않도록 규칙을 정합니다.

• DB에는 파일 경로 대신 논리 위치(스토리지 ID + 상대 경로) 를 저장해 스토리지 이전이 쉽게 합니다.
• 파일의 체크섬과 크기를 DB에 함께 저장해 정합성 검사에 사용합니다.
• 삭제는 DB 상태를 먼저 바꾸고 파일 삭제는 나중에 비동기로 처리해, 중간에 실패해도 정리할 수 있게 합니다.

#2) 무거운 일은 큐로 뺀다

변환, 분석, 전송은 몇 분에서 몇 시간이 걸립니다. API 서버가 이 일을 직접 하면 요청이 막히고 장애에 취약해집니다. API는 작업을 큐에 등록하고 즉시 응답하고, 실제 처리는 별도의 워커가 맡습니다.

사용자 요청 → API(작업 등록, 작업 ID 반환) → 큐 → 워커(처리) → 상태 갱신 → 화면에서 진행률 조회

#3) 작업은 멱등하게 만든다

네트워크 오류나 서버 재시작 때문에 같은 작업이 두 번 실행될 수 있습니다. 그래도 결과가 망가지지 않도록 작업을 설계합니다(4장 배치 변환의 임시 파일 후 교체, 결과가 있으면 건너뛰기).

#4) 상태를 명시적으로 관리한다

소재와 작업에는 상태(예: INGESTING → ANALYZED → PROXY_READY → REGISTERED → ARCHIVED)가 있고, 상태 전이 규칙을 코드와 DB에 명확히 둡니다. "대충 어디까지 처리됐는지" 알 수 없는 시스템은 운영이 불가능합니다.

#5) 검색 엔진은 사본이다

검색 엔진의 데이터는 DB에서 만든 사본입니다. 장애가 나도 DB에서 다시 만들 수 있어야 합니다. 검색 결과에서 상세 정보를 보여줄 때는 DB를 기준으로 확인합니다.

#6) 스토리지 접근 경로를 분리한다

• 원본(고비트레이트): 편집·송출용 고성능 경로
• 프록시(저비트레이트): 웹 서비스용 경로

프록시 재생 트래픽이 원본 편집 성능에 영향을 주지 않도록 분리합니다(스토리지 편에서 설명).

#단일 시스템 vs 서비스 분리

초기에는 하나의 애플리케이션(모놀리식)으로 시작해도 충분합니다. 다만 아래 경계는 처음부터 코드 수준에서 분리해 두면 나중에 서비스로 쪼개기 쉽습니다.

#정리

• MAM은 클라이언트, API, 워크플로우, 워커, DB, 검색, 스토리지의 층으로 구성됩니다.
• 핵심 원칙은 파일과 메타데이터 분리, 무거운 작업의 큐 처리, 멱등한 작업, 명시적 상태 관리입니다.
• 처음에는 단순하게 시작하고, 경계만 코드로 분리해 두세요.