데이터가 많아질수록 응답 시간이 길어진다는 것을 위에 이미지로 확인할 수 있다.
데이터 양이 늘어날수록 응답 속도가 비례하여 느려진다.
서버 로그 를 확인해보면
애플리케이션이 데이터베이스에 쿼리를 실행하거나 요청을 처리할 때,
Hibernate와 같은 ORM 툴은 자동으로 SQL 쿼리 실행 정보를 기록해 준다.
쿼리 로그를 분석해 본 결과
shelter_info 테이블과 관련된 쿼리가 반복 된다
select (생략) from shelter_info si1_0 where si1_0.care_nm=?
특히, care_nm을 기준으로 shelter_info 테이블에서 여러 번 JOIN이 일어나고 있다.
기본적으로 @ManyToOne 관계에서 Lazy Loading이 기본으로 설정되어 있다.
Lazy Loading은 관련된 엔티티가 실제로 필요할 때마다 개별 쿼리로 가져오게 되어, 이로 인해 여러 번의 쿼리가 발생한다.
이 설정은 필요할 때마다 별도의 쿼리로 데이터베이스에서 데이터를 조회하게 만든다.
ShelterInfo 전체 엔티티가 아닌 org_nm 필드만 필요한 상황에서는 불필요한 데이터 조회를 방지하기 위해 필요한 필드만 선택적으로 가져오는 방식으로 쿼리를 수정할 수 있다.
이 방식으로 불필요한 데이터 조회를 줄여서 성능을 최적화할 수 있었다.
그러나 중복된 쿼리가 완전히 줄어들지 않은 이유는 이 방식이 데이터 조회를 제한하는 것에 중점을 두었지만, 여전히 여러 번 호출될 때 동일한 쿼리가 반복적으로 발생할 수 있기 때문이다.
중복된 쿼리를 완전히 제거 하려면 캐시 를 적용하여 이미 조회한 데이터를 재사용하는 방법이 필요하다. (다음 포스팅에 추가)
현재는 필요한 필드만 선택적으로 가져오는 방식으로 처리하여,
캐시가 없기 때문에 중복된 쿼리가 완전히 해결되지 않았다.
데이터베이스 성능을 향상시키기 위해 인덱스를 추가할 수 있다.
특히, 자주 사용되는 care_nm과 같은 칼럼에 인덱스를 추가하면 쿼리 성능이 크게 향상된다.
인덱스는 데이터베이스가 특정 칼럼 기준으로 데이터를 빠르게 검색할 수 있도록 도와준다.
DBeaver를 사용해서 아래와 같이 쿼리를 실행했다.
다만 다른 팀원이 인덱스를 적용해둔 상태였다 ❓❗️
인덱스를 생성했으면 해당 인덱스는 데이터베이스에서 자동으로 적용된다.
코드는 따로 수정할 필요가 없고, MySQL이 자동으로 쿼리를 최적화할 때 인덱스를 활용한다.
해결책
최종 해결책 : 페이지네이션 적용
모든 데이터를 한 번에 가져오는 방식은 성능에 좋지 않다. 많은 데이터를 한꺼번에 불러오면 로딩 시간이 길어질 수밖에 없기 때문이다.
이를 해결하기 위해 페이지네이션을 도입했다. 페이지네이션은 한 번에 모든 데이터를 가져오는 대신, 데이터를 나누어 일부씩 가져오는 방식으로 로딩 시간을 크게 줄여준다.
프론트엔드에서는 페이지네이션 컴포넌트(BoardPagination)을 추가하여 사용자 페이지를 이동하며 데이터 조회를 할 수 있도록 하였다.
성능 비교
| 구분 | 평균 응답 속도 (ms) |
| 기존 방식 (좋아요 누른 유기동물) | 939 ms |
| 개선된 방식 (좋아요 누른 유기동물) | 438.4 ms |
| 개선율 | 53.3% |
응답 시간을 비교한 결과, 데이터 양이 20개든 100개든 응답 시간이 400 ms대로 줄어들며, 페이지네이션을 통해 50% 이상의 성능 개선을 하였다.
결론
페이지네이션 적용을 통해 성능 문제를 해결할 수 있었다.
작업의 핵심은 불필요한 데이터 조회를 줄이고, 데이터베이스 최적화 및 페이지네이션을 적용하여 성능 문제를 해결한 것이다.
앞으로도 캐시를 적용하여 중복된 쿼리 문제도 해결할 계획이다.
그 외 PIN 게시물, 내가 쓴 댓글, 내가 쓴 게시물도 페이지네이션을 적용하였다.
'팀프로젝트_PetHarmony' 카테고리의 다른 글
| Redis를 활용한 인증번호 캐싱 시스템 구현 (0) | 2024.09.30 |
|---|---|
| Redis 도입 시도 ➡️ 보류 (2) | 2024.09.26 |
| 🔍 데이터베이스 수준 랜덤 샘플링으로 성능 개선 (6) | 2024.09.21 |
| 🔍 코드 리팩트링으로 성능 최적화 개선율 분석 (0) | 2024.09.20 |
| Spring Security 기록 (끝) (4) | 2024.09.05 |