들어가기
게시글을 등록하는 API와 S3에 이미지를 업로드하는 API를 한 곳에서 처리하다 보면 응답 대기시간이 이미지 개수에 비례해 증가하게 됩니다.
컨트롤러에서 게시글 데이터와 이미지 데이터를 한꺼번에 받아서 처리중인 코드입니다.
게시글을 저장한 뒤에 파일들을 S3에 저장하는 서비스 코드입니다.
위 컨트롤러를 포스트맨으로 테스트 해보겠습니다.
테스트는 간단한 게시글의 제목과 내용 그리고 이미지 7장을 서버에 전송했습니다.
933ms 소요됐습니다. 거의 1초라고 봐도 무방합니다.
이 수치는 이미지의 수가 늘어날 수록 증가하게됩니다.
이번엔 이미지 파일을 3장 추가해서 총 10장을 서버에게 요청해 보겠습니다.
응답대기 시간은 약 1370ms로 이미지 개수 증가에 따라 응답시간이 46%로 크게 증가합니다.
추가적인 문제
이미지를 묶음으로 전송하면 응답대기 시간이 늘어지는 것도 문제이지만 이미지 전송이 실패하게 됐을 땐 더 큰 문제가 발생합니다.
사용자가 등록 요청한 모든 이미지를 다시 요청 받아야 하기때문에 사용성이 크게 저하됩니다.
이미지와 게시글 등록 API 분리
이미지를 등록하면 곧 바로 S3에 업로드 되도록 새로운 컨트롤러를 작성했습니다.
만약 업로드가 실패한다면 사용자는 해당 이미지만 재업로드하면 되기 때문에 사용성도 개선됩니다.
이미지는 7개로 구성한 게시글을 작성해보겠습니다.
당연히 이미지는 먼저 S3에 올라가있기 때문에 통합된 API형태보다는 훨씬 빠를 것으로 예상됩니다.
먼저 각각의 이미지를 등록하는데 소요되는 시간을 알아보고 게시글 등록 소요시간을 알아보겠습니다.
각각의 이미지는 평균 123ms 소요됩니다.
이미지 개수 증가에 따라서 트래픽도 증가하겠지만 사용편이성이란 측면에서 더 나은 선택이라 생각합니다.
다음은 이미지 7개를 포함한 게시글 최종 등록 요청입니다.
결과는 872ms로 제가 예상하던 결과와 매우 상이합니다.
기존에 이미지와 게시글을 같이 등록하던 방식은 933ms 였고 API를 분리한 방식은 872ms로 6%가 개선됐지만
네트워크 상황이나 서버 상황에 따른 오차범위를 생각하면 개선이라 할 수 없습니다.
다음 시간에 이런 상황이 벌어진 이유를 살펴보고 추가적으로 개선해보겠습니다.
'Spring' 카테고리의 다른 글
적정 스레드 풀 크기를 고민해보자 (0) | 2024.06.19 |
---|---|
게시글과 이미지 등록 API 분리로 API Latency 개선기 (2) (0) | 2024.06.19 |
회원 도메인 객체 코드 개선하기 (0) | 2024.04.12 |
@Value 감옥에서 벗어나기 [@ConfigurationProperties] (0) | 2024.04.03 |
[Spring Security JWT 로그인 (3)] DelegatingFilterProxy Deep Dive (0) | 2024.03.15 |