home
블로그
home

Search

문제

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

해결 방법

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

문제

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

해결 방법

•
문제를 해결하기 위해, setHours 메서드를 사용하여 시간을 맞추는 방법을 적용했습니다.
•
setHours(0, 0, 0, 0)를 통해 시간을 초기화함으로써, 다음 결제일과 비교가 정확하게 이루어질 수 있도록 했습니다.
•
이를 통해 날짜만 정확하게 비교할 수 있게 되었고, 문제가 해결되어 알림이 정상적으로 생성되었습니다.
알림 빈배열 발생

문제

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

해결 방법

•
이러한 비효율성을 개선하기 위해 where 조건절을 사용하여 필요한 데이터만 직접 조회하도록 코드를 수정하였습니다.
•
수정 후, 약 6만 개의 구독 중 1만 개의 알림을 보내야 하는 상황을 테스트했습니다.
•
반복문의 경우에는 5분 30초가 소요되었고, where 조건절을 사용한 경우에는 2분 53초가 소요되었습니다.
•
테스트를 통해 데이터 조회 시 where 조건절을 사용하여 필요한 정보만 검색하는 방식이 데이터 검색의 효율성을 크게 높일 수 있음을 알게 되었습니다.
반복문 처리속도

문제

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

해결 방법

•
Scheduler를 통해 1시간마다 Redis 캐시에 데이터를 저장했습니다.
•
TTL을 2시간으로 설정하여 Redis 캐시에 데이터가 비어있는 시간을 없앴고, 일정한 처리 속도를 유지할 수 있었습니다.
Redis캐시 전략

문제

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

해결 방법

•
대량의 데이터를 삽입하는 상황에서는 INSERT만 처리하는 것이 효율적이라고 생각했고, 로직을 수정하여, 한 번에 가능한 많은 데이터를 삽입할 수 있는 Bulk Insert 방식을 사용했습니다.
•
save 메서드 대신, 직접 INSERT 쿼리를 작성하여 데이터를 한 번에 DB에 저장하는 방법으로 변경하였고, 각 데이터 삽입 후에 발생하는 불필요한 SELECT 쿼리의 실행을 피할 수 있었습니다.
•
해당 코드 수정을 통해 결제 알림 데이터를 일괄 삽입함으로써, 불필요한 쿼리 실행을 줄이고 성능을 개선할 수 있었습니다.
•
이 변경 사항의 성능을 확인하기 위해 console.time() 메서드를 사용하여 각 방법의 응답 시간을 기록했습니다.
•
아래 표는 알림 개수에 따른 save 메서드와 INSERT 쿼리문 사용의 응답 시간을 비교한 것입니다.
•
평균을 나타내는 그래프에서 볼 수 있듯이, INSERT 쿼리문을 사용하는 방법이 save 메서드를 사용하는 것보다 훨씬 더 효율적임을 확인할 수 있습니다.
SAVE / INSERT 비교