요청을 받은 뒤에도 합성은 계속된다
Harucut에서는 사진 네 장과 프레임으로 네 컷 이미지를 만듭니다. 합성을 맡은 Lambda를 EVENT 방식으로 호출하고 결과를 SQS로 받도록 바꾸면서, 요청을 접수한 시점과 결과 파일이 완성된 시점이 나뉘었습니다. 작업 상태는 DB에 저장해 처리 결과와 복구 대상을 확인하도록 했습니다.
사용자가 결과를 내려받으려면 접수 응답 이후에도 합성이 끝날 때까지 기다려야 합니다. 구조 변경 전후를 비교할 때 접수 응답 시간과 함께 완료·실패 건수, 가장 늦은 작업이 끝나는 시간을 기록했습니다.
30건 중 21건 완료에서 30건 완료로
소형 이미지로 합성 요청 30건을 보냈습니다. 개선 전 pool20 조건과 개선 후 결과는 다음과 같습니다.
| 항목 | 개선 전 pool20 | 개선 후 |
|---|---|---|
| 요청 수 | 30건 | 30건 |
| 완료 | 21건 | 30건 |
| 실패 | 9건 | 0건 |
| 최대 완료 시간 | 약 10초 | 약 53초 |
| 접수 p95 | 1,446ms | 1,520ms |
개선 후에는 30건이 모두 완료됐지만, 가장 늦게 끝난 작업은 약 53초가 걸렸습니다. 실패 건수와 함께 사용자가 결과를 기다리는 시간도 다음 검증에서 확인해야 할 항목으로 남았습니다.
pool2에서도 30건은 모두 완료됐다
기존 구조 역시 pool2 조건에서는 30건을 모두 완료했습니다. 실패 9건은 pool20 조건에서 발생한 결과입니다. 따라서 이번 결과는 기존 구조가 항상 실패한다는 의미로 일반화할 수 없으며, 두 구조를 비교할 때 동시 처리 조건을 함께 봐야 합니다.
실험 환경은 2 CPU·2GB, MySQL 8·Redis 7, Lambda 메모리 2,048MB·제한 시간 60초·동시성 10이었습니다. 소형 이미지 30건을 대상으로 한 비교이므로 큰 이미지나 지속적인 부하에서의 결과는 아직 확인이 필요합니다.
다음 실험에서 확인할 내용
이미지 크기와 부하 지속 시간을 늘렸을 때의 완료·실패 건수와 대기 시간은 추가 검증이 필요합니다. 결과 처리 도중 장애가 발생했을 때 SQS 메시지가 재전달되는지, DB에 남은 작업을 다시 찾아 복구할 수 있는지도 검증할 항목입니다.
Harucut 프로젝트에는 작업 저장, 선점, 결과 수신과 복구 흐름을 정리했습니다.