변화탐지 AI 모델을 사용해서 15000x15000 크기의 영상 두 개를 비교했을 때 약 100MB 크기의 탐지 결과가 저장되는 것을 확인했다. 100MB 탐지 결과를 프론트에서 그대로 보여주면 조회 속도가 매우 느릴 것으로 예상됐다. 변화 탐지 결과를 조회하는 기능이 정상적으로 동작할 수 있는지 확인하기 위해 조회 성능 측정을 진행했다.
먼저 랜덤하게 변화 탐지 결과를 생성하여 약 20MB 크기로 테스트 데이터를 구성했다. 그 후 테스트 서버의 데이터베이스에 테스트 데이터를 저장한 후 해당 결과를 조회하는 API를 호출했다. API가 1분 이상 소요되어 504(Gateway Timeout) 에러가 발생했다.
정확하게 어느 로직에서 오랜 시간이 소요되는지 확인하기 위해 20MB 크기의 변화 탐지 결과를 저장하고 조회하는 테스트 코드를 작성한 후 소요 시간을 확인했다. Repository에서 쿼리를 통해 데이터베이스에서 데이터를 불러올 때 50초 이상 소요되는 것을 확인했다.
20MB 크기의 데이터를 데이터베이스에서 조회하는 것이 단순히 크기가 커서 오래 걸리는 것인지 아니면 Geometry 정보이기 때문에 느린 것인지 확인이 필요하다. 20MB인 일반 문자열을 조회했을 때 빠르게 조회될 경우 일반 문자열로 조회하도록 변경하기 위함이다.
사이드 프로젝트
알림 기능 구현
사용자가 구매한 전자책을 리뷰하거나 리뷰에 댓글을 작성할 때 이벤트를 발행하여 알림을 저장하도록 구현하는 것을 진행했다. 이벤트 발행 로직은 대부분 비슷하며 다음과 같이 데이터를 조회하고 이벤트를 생성한 후 발행하도록 구현했다.
이처럼 서비스 객체가 다른 서비스 객체를 호출하도록 했으며, Spring의 ApplicationEventPublisher 객체를 활용해 이벤트를 발행했다. 유지보수 측면에서 더 좋은 코드 구조를 고민해봤으나 먼저 개발을 완료하고 배포한 후에 리팩토링을 진행하기로 결정했다.
그 후, 알림을 저장하고 조회하는 부분을 조금 수정했다. 기존에는 알림 내용이 어떤 알림인지에 따라 달라질 수 있으므로 알림 객체를 Json으로 변환한 후 Json을 String으로 DB에 저장하도록 구현했다. 하지만 String으로 프론트에 전달할 경우 값을 다루기 힘들 것으로 예상되어 Map 타입으로 저장하고 응답하도록 수정을 진행했다.
다음과 같이 두 컨버터를 추가하고 R2DBC 설정 클래스에 등록해준 후 저장 타입을 변경했다. 기존의 테스트 코드를 돌려보니 정상 동작하는 것을 볼 수 있었다.
