섬네일 생성 자동화 - 미션2. 처리속도 높이기

섬네일 생성 자동화 2부로, 1부에서 해시로 중복 요청을 걸러낸 뒤 남은 요청을 어떻게 더 빨리 처리했는지 다룬다. 동기 API 를 포기하고 DB 배치로 바꾼 뒤, 병목 구간만 병렬화해 딜 하나 처리 시간을 22초에서 6초로 줄였다.

핵심 포인트

섬네일 서버는 이미지 장당 약 0.5초가 걸리고 딜 하나에 원본이 42장이라 20초가 넘는다. 하루 1만 딜이면 56시간, 약 2.3일이 든다.
동기 방식으로는 성립하지 않는다고 보고 비동기 후보 세 가지(새 스레드, 메시지 큐, DB 배치)를 비교했다.
새 스레드는 최악의 경우 CPU 점유율이 치솟아 다른 작업을 방해하고 장애 복구가 어려워 제외했다.
메시지 큐는 큐를 메모리에 쌓아 빠르지만, 접근이 드문 섬네일 서비스에는 자원 낭비라 제외하고 DB 배치를 골랐다.
병렬 처리 후 스레드 8개 고정 할당으로 딜당 6초, 기존 22초 대비 약 4배 개선했다.

상세 정리

DB 배치를 고른 이유는 구현이 상대적으로 쉽고 하드디스크 기반이라 분석 대상을 사실상 무제한으로 쌓아 둘 수 있어서다.
배치만으로는 부족했다는 점을 분명히 한다. 지금 당장 계산하지 않아도 될 뿐 딜 하나를 처리하는 시간 자체는 그대로였다.
기존 단일 스레드 로직: 이미지 콘텐츠 DB 에서 딜의 이미지 정보를 가져와 JSON 을 파싱해 URL 을 뽑고, 기존 섬네일 정보도 함께 가져와 비교한다.
분기 규칙: URL 이 기존 정보에 있으면 아무것도 하지 않고, 없으면 이미지를 내려받아 해시를 계산한다. 해시가 이미 있으면 URL 만 다른 같은 이미지로 보고 기존 섬네일 정보를 복사해 매칭하며, 없으면 신규 생성을 요청한다.
병목 측정: 샘플 딜 테스트에서 섬네일 서버에 이미지를 보내고 결과를 받는 구간이 전체 연산 시간의 70% 를 차지했다. 2위는 서버에서 이미지를 내려받아 저장하는 시간이었다.
개선 설계의 핵심은 분류와 요청을 분리한 것이다. 기존에는 이미지 분류와 섬네일 요청이 뒤섞여 있었는데, 먼저 플래그로 전부 분류한 뒤 필요한 것만 모아 처리한다.
분류 4가지: ① URL 이 이미 있으면 종료 ② 해시는 있고 섬네일 정보도 있으면 복사해 저장 ③ 해시는 있으나 섬네일 정보가 없으면 참조 URL 과 함께 `LOOKUP_NEED` 표시 ④ 해시도 없으면 `REQUEST_NEED` 표시.
실행 순서: `REQUEST_NEED` 만 필터링해 멀티 스레드로 한 번에 요청·저장하고, 그다음 `LOOKUP_NEED` 항목이 참조 URL 의 섬네일 정보를 복사해 저장한 뒤, 마지막에 DB 를 갱신한다.
스레드 수는 서버를 공유하는 상황에서 너무 많이 할당하면 다른 서비스에 지장을 줄 수 있어 8개로 고정했다.
처리 속도는 스레드 개수에 비례해 향상됐다고 밝히며, 무한정 늘리지 않은 이유를 함께 남긴다.