[ TIL ] 최종 프로젝트_Day 29

오늘 진행한 내용들 🧐 

연령대 별 인기 키워드 상위 10개 조회 성능 개선하기

성능 개선 계획

1. 인덱스로 성능을 개선하기
2. 서브 쿼리로 단일 쿼리로 변경하여 성능을 개선하기

두 가지 성능 개선 계획이 있었다.
그래서 현재 쿼리의 상황이 어떤지 먼저 파악해 보기로 했다.

현재 쿼리의 상황

서브 쿼리를 활용한 코드

연령대를 25세~40세로 고정했다. (가장 많은 취업 연령층이라고 생각하고 고정했다.)

그다음 Postman으로 배포 중인 서버와 로컬에서 직접 조회를 진행해 보았다.

[ Local ]

한번 조회하는데 31.49s가 걸렸다…
매우 매우.. 엄청나게 느린 속도였다..

[ 배포 중인 서버 ]

이럴 수가… 심지어 서버에서 조회했을 때는 시간이 너무 오래 걸려서 504 Gateway Time-out이 발생했다..

혹시나 하는 마음에 부하 테스트도 함께 진행해 보았다.
100 스레드 10초로 설정하고 JMeter에서 테스트했을 때 에러율이 90%가 나왔다..
부하 처리가 불가능한 상태였다.

“혹시나 시간 때문인가..?”라는 생각이 들어서 Ramp-up period를 10초에서 120초로 넉넉하게 설정했다.
그랬더니 여전히 에러율이 83%로 높게 나왔다.

서브 쿼리를 활용하여 인기 키워드를 조회 시 성능이 매우 매우 느리고 좋지 않았다..
부하테스트를 진행하는 의미도 없었다..

인덱스로 성능을 개선하든, 쿼리를 변경하여 성능을 최적화하든 개선이 당장 필요한 상황이었다.

그래서 고민이 생겼다..
과연 이렇게 느린 성능을 가진 쿼리를 인덱스 만으로 문제를 해결할 수 있을까..??
집계를 수행하고 있는 서브 쿼리를 해결해야 되는 문제가 아닐까??

그래서 쿼리를 최적화하여 문제를 해결할 수 있는지 찾아보았다.

서브 쿼리를 해결할 수 있는 방법들을 찾다 보니 QueryDSL 라이브러리에서 제공하는 numberTemplate 메서드를 활용하여 집계가 가능했다!!
서브 쿼리를 사용하지 않고 단일 쿼리에서 바로 count 계산이 가능해진 것이다!

서브 쿼리를 단일 쿼리로 변경했다.

단일 쿼리로 변경한 코드

위의 코드처럼 서브 쿼리를 삭제하고 단일 쿼리 내에서 count를 바로 계산할 수 있도록 변경했다.
서브 쿼리가 사라지면서 데이터베이스에서 실행해야 할 쿼리가 1회로 줄어들어, 필요하지 않은 쿼리 실행이 사라진다.

그렇다면 성능이 얼마나 개선되었을까?!

로컬에서 Postman을 활용하여 성능을 확인해 봤다.

와… 31.49s가 걸리던 쿼리가 146ms로 확연하게 줄어든 것을 확인할 수 있었다..

JMeter를 활용하여 부하테스트를 다시 한번 진행해 봤다.
100 스레드 10초로 설정하고 테스트를 진행한 결과..

에러율이 0%에 시간도 50ms로 엄청나게 개선이 된 것을 볼 수 있다!!

100 스레드 120초로 설정하고 테스트를 진행한 결과는

역시나 에러율이 0%였다!!

이로써 서브 쿼리를 해결한 것만으로도 성능 개선이 엄청나다는 것을 알 수 있었다.

그렇다면 여기서 할 수 있는 생각!

user 테이블의 age 컬럼에 인덱스를 적용한다면 성능이 더 개선되지 않을까??

그래서 바로 인덱스를 적용 전후 성능을 비교해 봤다.

인덱스 적용 전 성능

-> Limit: 10 row(s)  (actual time=62.5..62.5 rows=10 loops=1)
    -> Sort: `count(uk1_0.id)` DESC, limit input to 10 row(s) per chunk  (actual time=62.5..62.5 rows=10 loops=1)
        -> Table scan on <temporary>  (actual time=62.4..62.4 rows=45 loops=1)
            -> Aggregate using temporary table  (actual time=62.4..62.4 rows=45 loops=1)
                -> Nested loop inner join  (cost=2547 rows=5073) (actual time=0.372..40.2 rows=26004 loops=1)
                    -> Nested loop inner join  (cost=771 rows=5073) (actual time=0.311..18.2 rows=26004 loops=1)
                        -> Filter: (u1_0.age between 25 and 40)  (cost=205 rows=222) (actual time=0.237..1.2 rows=1118 loops=1)
                            -> Table scan on u1_0  (cost=205 rows=2000) (actual time=0.235..1.03 rows=2000 loops=1)
                        -> Filter: (uk1_0.keyword_id is not null)  (cost=0.278 rows=22.8) (actual time=0.0081..0.0139 rows=23.3 loops=1118)
                            -> Covering index lookup on uk1_0 using UKobffw3p1x4w47vq32puin9a0o (user_id=u1_0.id)  (cost=0.278 rows=22.8) (actual time=0.00799..0.0125 rows=23.3 loops=1118)
                    -> Single-row index lookup on k1_0 using PRIMARY (id=uk1_0.keyword_id)  (cost=0.25 rows=1) (actual time=686e-6..712e-6 rows=1 loops=26004)

 

CREATE INDEX idx_user_age ON user (age);

위 코드를 활용해서 인덱스를 생성해 주고 다시 성능을 확인해 보았다!

인덱스 적용 후 성능

-> Limit: 10 row(s)  (actual time=52.4..52.4 rows=10 loops=1)
    -> Sort: `count(uk1_0.id)` DESC, limit input to 10 row(s) per chunk  (actual time=52.4..52.4 rows=10 loops=1)
        -> Table scan on <temporary>  (actual time=52.3..52.3 rows=45 loops=1)
            -> Aggregate using temporary table  (actual time=52.3..52.3 rows=45 loops=1)
                -> Nested loop inner join  (cost=12010 rows=25524) (actual time=0.742..36 rows=26004 loops=1)
                    -> Nested loop inner join  (cost=3077 rows=25524) (actual time=0.698..16.1 rows=26004 loops=1)
                        -> Filter: (u1_0.age between 25 and 40)  (cost=226 rows=1118) (actual time=0.602..1.18 rows=1118 loops=1)
                            -> Covering index range scan on u1_0 using idx_user_age over (25 <= age <= 40)  (cost=226 rows=1118) (actual time=0.599..1.04 rows=1118 loops=1)
                        -> Filter: (uk1_0.keyword_id is not null)  (cost=0.269 rows=22.8) (actual time=0.00678..0.012 rows=23.3 loops=1118)
                            -> Covering index lookup on uk1_0 using UKobffw3p1x4w47vq32puin9a0o (user_id=u1_0.id)  (cost=0.269 rows=22.8) (actual time=0.00667..0.0107 rows=23.3 loops=1118)
                    -> Single-row index lookup on k1_0 using PRIMARY (id=uk1_0.keyword_id)  (cost=0.25 rows=1) (actual time=607e-6..633e-6 rows=1 loops=26004)

 

항목	인덱스 적용 전	인덱스 적용 후	개선 사항
user 테이블 조회 방식	ALL (Full Table Scan)	range (Index Range Scan)	인덱스 적용으로 최적화
JOIN 방식 (userKeyword 테이블)	ref	ref	동일
keyword 테이블 조회 방식	eq_ref	eq_ref	최적화 유지
Extra (추가 연산)	Using temporary; Using filesort	Using where; Using index; Using temporary	파일 정렬 제거 & 인덱스 활용 증가
실행 시간	62.5ms	52.4ms	약 16% 속도 개선

성능이 좋아지긴 했으나 눈에 띄게 개선된 것은 아닌 것 같다.
실제로 Postman을 실행했을 때의 결과가 인덱스 적용 전보다 응답 속도가 더 늘어난 것을 확인할 수 있다.

JMeter를 활용하여 똑같은 조건에서 부하테스트를 진행해 봤다.

성능이 더 좋아진 모습을 보기 힘들었다.

그렇다면 성능 개선이 크지 않은 인덱스를 적용해야 하는 건가??

고민한 끝에 나온 결론은 인덱스를 적용하지 않는 것이었다.
user 테이블에는 사용자가 회원가입을 진행할 때마다 데이터가 INSERT 되어 추가된다. 그럴 때마다 인덱스가 적용되어 있으면 다시 인덱스를 재정렬이 필요하고 쓰기 연산의 성능이 저하될 가능성이 존재한다.
또한 데이터가 많아질수록 인덱스 관리 비용이 증가하게 된다.

다음과 같은 이유로 쿼리 최적화까지 진행하고 인덱스는 적용하지 않기로 결정했다.
쿼리 최적화를 진행하면서 충분히 응답 속도가 개선되었다고 생각한다!

테스트 코드 작성하기

@Test
@DisplayName("예외 발생: 존재하지 않는 jobOpeningId를 조회할 경우 NotFoundException 발생")
void 채용공고_단건_조회_실패() {
    // given
    Long jobOpeningId = 999L;

    when(jobOpeningRepository.findById(jobOpeningId)).thenReturn(Optional.empty());

    // when & then
    NotFoundException exception = assertThrows(
        NotFoundException.class,
        () -> jobOpeningFindByService.findById(jobOpeningId)
    );

    assertThat(exception.getMessage()).contains(DataErrorCode.JOB_OPENING_NOT_FOUND.getMessage());

    verify(jobOpeningRepository, times(1)).findById(jobOpeningId);
}

@ExtendWith(MockitoExtension.class)
public class SearchHistoryServiceTest {

    @InjectMocks
    private SearchHistoryService searchHistoryService;

    @Mock
    private RedisTemplate<String, String> redisTemplate;

    @Mock
    private ZSetOperations<String, String> zSetOperations;

    @Mock
    private SearchHistoryRepository searchHistoryRepository;

    private static final long EXPIRATION_TIME = 3600;

    @BeforeEach
    void setUp() {
        when(redisTemplate.opsForZSet()).thenReturn(zSetOperations);
    }

    @Test
    @DisplayName("검색어가 Redis에 정상적으로 저장")
    void Redis에_검색어_정상적으로_저장() {
        // given
        Long userId = 1L;
        String searchTerm = "Spring";
        String key = "user:" + userId + ":search_history";

        // when
        searchHistoryService.saveSearchTerm(userId, searchTerm);

        // then
        verify(zSetOperations, times(1)).add(eq(key), eq(searchTerm), anyDouble());
        verify(redisTemplate, times(1)).expire(eq(key), eq(EXPIRATION_TIME), eq(TimeUnit.SECONDS));
    }

    @Test
    @DisplayName("검색어 개수가 MAX_SEARCH_HISOTRY_SIZE를 초과하면 가장 오래된 검색어 삭제")
    void Redis에서_가장_오래된_검색어_삭제() {
        //given
        Long userId = 2L;
        String searchTerm = "Redis";
        String key = "user:" + userId + ":search_history";

        when(zSetOperations.zCard(key)).thenReturn(11L);

        // when
        searchHistoryService.saveSearchTerm(userId, searchTerm);

        // then
        verify(zSetOperations, times(1)).add(eq(key), eq(searchTerm), anyDouble());
        verify(zSetOperations, times(1)).removeRange(eq(key),eq(0L), eq(0L));
        verify(redisTemplate, times(1)).expire(eq(key), eq(EXPIRATION_TIME), eq(TimeUnit.SECONDS));
    }

    @Test
    @DisplayName("Redis에 검색 기록이 존재하면 해당 데이터를 반환")
    void Redis에_검색_기록_존재하면_데이터_반환() {
        // given
        Long userId = 1L;
        String key = "user:" + userId + ":search_history";
        Set<String> searchTermSet = new LinkedHashSet<>(List.of("Java", "Spring"));

        when(zSetOperations.reverseRange(key, 0, 9)).thenReturn(searchTermSet);

        // when
        List<String> searchTermList = searchHistoryService.getRecentSearchTerms(userId);

        // then
        assertThat(searchTermList).containsExactly("Java", "Spring");

        verify(searchHistoryRepository, never()).findTop10ByUserIdOrderByCreatedAtDesc(anyLong());
    }

    @Test
    @DisplayName("Redis에 검색 기록이 없으면 DB에서 데이터를 조회한 후 Redis에 저장하고 반환")
    void Redis에_검색_기록이_없으면_DB에서_데이터_조회하고_Redis에_저장_후_반환() {
        // given
        Long userId = 2L;
        String key = "user:" + userId + ":search_history";
        User mockUser = User.toEntity("test@gmail.com", "사용자1", 27, 1, "password123");

        when(zSetOperations.reverseRange(key, 0, 9)).thenReturn(Collections.emptySet());

        SearchHistory history1 = SearchHistory.toEntity(mockUser, "Elasticsearch");
        SearchHistory history2 = SearchHistory.toEntity(mockUser, "Kafka");

        ReflectionTestUtils.setField(history1, "createdAt", LocalDateTime.now().minusMinutes(10));
        ReflectionTestUtils.setField(history2, "createdAt", LocalDateTime.now().minusMinutes(5));

        List<SearchHistory> searchTermListInDatabase = List.of(history1, history2);

        when(searchHistoryRepository.findTop10ByUserIdOrderByCreatedAtDesc(userId)).thenReturn(searchTermListInDatabase);

        // when
        List<String> resultList = searchHistoryService.getRecentSearchTerms(userId);

        //then
        assertThat(resultList).containsExactly("Kafka", "Elasticsearch");

        verify(searchHistoryRepository, times(1)).findTop10ByUserIdOrderByCreatedAtDesc(userId);

        verify(zSetOperations, times(1)).add(eq(key), eq("Elasticsearch"), anyDouble());
        verify(zSetOperations, times(1)).add(eq(key), eq("Kafka"), anyDouble());
    }
}

 

내일 계획 ⏰

• 테스트 코드 작성
• 커리어 코칭 상담
• 피피티 소감 작성
• 브로셔 작성
• 문서화 작업하기

+ 추가 계획이 더 생길 수도 있습니다~_~