Yeoooo

아무튼 해보는게 중요해.

업데이트:

1 분 소요

개요

파일 처리와 작업 서버 구조를 고민했다.

처음에는 API 서버가 파일 업로드와 처리를 모두 담당해도 되지 않을까 생각했다.
하지만 처리 시간이 길어질 수 있는 작업이라면 API 서버와 분리하는 편이 낫다고 판단했다.

메시징 시스템 고민

처음에는 메시징 시스템도 떠올렸다.
Kafka 같은 것을 붙이면 구조적으로 멋있어 보일 수 있다.

하지만 다시 생각해보니 지금 필요한 것은 대규모 이벤트 스트리밍이 아니었다.
필요한 것은 실패했을 때 재시도할 수 있고, 상태를 추적할 수 있는 작업 처리에 가까웠다.

그래서 지금 단계에서는 Kafka나 별도 메시징 워커는 과하다고 봤다.

초기: DB 기반 job/status 관리
필요 시: worker 분리
더 필요 시: queue 도입

파일 저장

파일 원본 저장도 고민했다.

DB에 저장하거나 API 서버 디스크에 저장하는 방식은 피하고, Object Storage를 쓰기로 했다.

파일 검증
-> Object Storage 업로드
-> DB에 요청 상태 저장
-> 작업 서버 호출
-> 처리 결과 저장

이렇게 하면 API 서버는 파일 자체를 오래 들고 있지 않아도 된다.
DB에는 파일의 위치와 처리 상태만 저장하면 된다.

이미지 byte 반환 제외

조회 API에서 파일 byte를 바로 반환하는 것도 제외했다.

처음에는 API 서버가 Object Storage에서 파일을 받아 그대로 내려주면 편할 것 같았다.
하지만 그렇게 하면 API 서버가 파일 프록시가 된다.

Object Storage
-> API Server
-> Client

사용자가 많아지면 API 서버가 파일 다운로드 트래픽까지 떠안게 된다.
그래서 초기에는 파일 자체를 내려주는 API는 만들지 않기로 했다.

정리

API 서버는 상태와 권한 관리에 집중하고, 파일 저장과 무거운 처리는 별도 책임으로 분리하는 것이 더 적절하다고 판단했다.

처음부터 복잡한 메시징 시스템을 도입하기보다, 현재 필요한 수준에서 단순하게 시작하는 것이 맞다고 봤다.

댓글남기기

참고