home
블로그
home

Search

문제

•
백엔드 API 기능 구현을 하면서 파트를 나눠서 API를 구현했습니다.
•
각자의 방식으로 작업 하다 보니 응답 값이 제각각인 상황이 발생했습니다.

해결 방법

•
프론트엔드 작업 시 응답값을 명확히 확인하기 위해 공통된 응답 값을 만들 필요가 있다고 판단했습니다.
•
ResponseDto를 사용하여 공통된 응답 값을 만들었습니다.
•
안티패턴인 any타입의 사용을 제한하기 위해 제네릭을 사용했습니다.
응답값 오류

문제

•
알림을 생성하기 위해 다음 결제일을 조회 후, 내일 날짜와 비교하는 로직에서 문제가 발생했습니다.
•
날짜가 동일한 상황에서 알림 목록이 모두 빈 배열로 반환이 되는 현상이 발생했습니다.
•
문제의 원인은 다음 결제일을 계산하기 위해 new Date()를 사용하여 내일 날짜를 생성하면, 날짜와 시간이 함께 저장되는 상황이었습니다.
•
이에 따라, 날짜가 동일해도 시간이 일치하지 않아 비교문에서 불일치가 발생하였습니다.
알림 빈배열 발생

문제

•
초기 알림 생성 로직에서는 반복문을 통해 모든 데이터를 가져온 후 필요한 데이터를 필터링하여 사용했습니다.
•
그러나 이 방식은 데이터가 많아질수록 처리속도가 크게 저하되었습니다.
•
불필요하게 전체 데이터를 가져오는 방식은 메모리와 처리 시간을 낭비하게 만들며, 규모가 커질수록 이러한 문제는 더욱 심각해지는 것을 확인했습니다.

해결 방법

•
이러한 비효율성을 개선하기 위해 where 조건절을 사용하여 필요한 데이터만 직접 조회하도록 코드를 수정하였습니다.
반복문 처리속도

문제

•
플랫폼의 랭킹 정보를 Redis 캐시에 저장하는 전략 중 Look-aside설정 후 부하 테스트를 진행했습니다.
•
TTL(Time To Live)을 15초로 짧게 설정하여 테스트 한 결과, TTL이 끝나고 Redis 캐시에 데이터가 없을 때 응답 시간이 많이 늘어났습니다.
•
Look-aside 전략 설정으로, TTL이 만료될 때마다 DB에서 데이터를 재조회하고, 캐시를 갱신하는 과정에서 응답 속도가 느려지게 됩니다.
Redis캐시 전략

문제

•
TypeORM에서 save 메서드를 사용할 때 발생하는 비효율적인 데이터 처리 방식입니다.
•
save 메서드가 실행되면 데이터를 저장할 때마다 INSERT 후 해당 데이터를 SELECT하는 과정이 발생하는 것을 확인했습니다.
•
한 번에 1,000개의 데이터를 저장해야 하는 경우, 1000번의 SELECT가 추가로 실행되어, 전체 응답 시간에 큰 영향을 미칠 수 있다고 판단했습니다.

해결 방법

•
대량의 데이터를 삽입하는 상황에서는 INSERT만 처리하는 것이 효율적이라고 생각했고, 로직을 수정하여, 한 번에 가능한 많은 데이터를 삽입할 수 있는 Bulk Insert 방식을 사용했습니다.
SAVE / INSERT 비교