😊 성능 테스트 가이드 시리즈😊 / 클릭 시 이동
1. 성능 테스트_성능 목표 잡기
2. 성능 테스트_HikariCP의 연결 최대 풀 설정
3. 성능 테스트_Caffeine 캐시 설정 및 적용
4. 성능 테스트_인덱싱과 트랜잭션 관리 최적화
5. 성능 테스트_하드웨어 리소스 업그레이드
결과
Total Average response time
- 7575ms → 4,465 ms(41.06%의 성능 향상)
Top 5 slowest requests based on their average response times.
API 성능 개선 요약
각 API별 성능 개선율
| API 엔드포인트 | 평균 응답 시간 개선율 | 90th 응답 시간 개선율 |
| GET /matching/senderList (받은 하트 페이지 조회) | 72.10% | 66.42% |
| GET /matching/getNotificationList (알림 목록 조회) | 21.00% | 7.08% |
| GET /matching/summaryDetail (매칭 현황 페이지 조회) | 43.29% | 37.79% |
| GET /matching/summary (매칭 요약 조회) | 35.74% | 34.25% |
| GET /matching/banner (배너 대칭 목록 조회) | 88.33% | 86.52% |
| GET /matching/getNotification (알림 개수 조회) | 54.33% | 39.83% |
상세 성능 개선 데이터
GET /matching/senderList (받은 하트 페이지 조회)
- 평균 응답 시간: 33,288ms → 9,289ms (72.10% 개선)
- 90th 응답 시간: 44,404ms → 14,911ms (66.42% 개선)
GET /matching/getNotificationList (알림 목록 조회)
- 평균 응답 시간: 23,766ms → 18,774ms (21.00% 개선)
- 90th 응답 시간: 28,215ms → 26,218ms (7.08% 개선)
GET /matching/summaryDetail (매칭 현황 페이지 조회)
- 평균 응답 시간: 23,865ms → 13,533ms (43.29% 개선)
- 90th 응답 시간: 28,220ms → 17,555ms (37.79% 개선)
GET /matching/summary (매칭 요약 조회)
- 평균 응답 시간: 18,525ms → 11,905ms (35.74% 개선)
- 90th 응답 시간: 25,130ms → 16,522ms (34.25% 개선)
GET /matching/banner (배너 대칭 목록 조회)
- 평균 응답 시간: 32,414ms → 3,784ms (88.33% 개선)
- 90th 응답 시간: 50,631ms → 6,825ms (86.52% 개선)
GET /matching/getNotification (알림 개수 조회)
- 평균 응답 시간: 23,766ms → 10,854ms (54.33% 개선)
- 90th 응답 시간: 28,215ms → 16,976ms (39.83% 개선)
전체 평균 개선율
- 평균 응답 시간 개선율: (72.10% + 21.00% + 43.29% + 35.74% + 88.33% + 54.33%) / 6 ≈ 52.47%
- 90th 응답 시간 개선율: (66.42% + 7.08% + 37.79% + 34.25% + 86.52% + 39.83%) / 6 ≈ 45.32%
이와 같이 전체 API 성능이 크게 개선되었다.
평균 응답 시간은 약 약 52.47% 개선되었고, 90th 백분위 응답 시간은 약 45.32% 개선되었다.
이를 통해서 비효율적인 프로세스 개선을 통한 리소스 사용 줄이기 목표는 달성하였다고 생각한다.
사용 방법으로는
- HikariCP의 연결 최대 풀 설정
- Caffeine 캐시 설정 및 적용
- 엔티티 인덱싱
- 트랜잭션 최적화
이고 추가로
- DB 아키텍처 설계할 때 Master - Slave 형태로 설계해 로드 밸런싱한 것
- 스키마 설계할 때 event_id를 기준으로 파티셔닝
을 해 놓은 것은 반영되지 않은 결과이기 때문에 실제로 사용할 때는 더 좋은 성능을 예상할 수 있다.
하지만, 목표 성능 예산이었던 3초는 어떻게 달성할 것인가?
→ 바로 아직 사용하지 않은, 리소스 성능 향상을 사용할 것이다.
GCP에서 훨씬 좋은 성능의 DB 서버를 실제 상용 DB 서버로 사용하기 때문에
리소스 향상이 매우 압도적으로 일어날 것을 예상할 수 있는데
아직 서비스를 개선하기 전에 예산이 없는 상황에서 과도한 금액이 나가는 것을 우려해
로컬 DB를 연결해 리소스 증가시 어느 정도의 성능을 발휘하는지 파악했다.
리소스 자원 업그레이드 테스트
Total Average response time
- 7575ms → 88 ms ( 98.84%의 성능 향상)
Top 5 slowest requests based on their average response times.
결과를 통해서, 프로세스 최적화 진행 전과 진행 후 모두 리소스 자원 업그레이드 한 상황과 비교하면,
프로세스 최적화 진행 전과 비교한 계산 과정
- 개선된 시간 = 7575ms - 88ms = 7487ms
- 개선율 = (개선된 시간 / 원래 시간) * 100 = (7487 / 7575) * 100 ≈ 98.84%
따라서, 7575ms에서 88ms로의 성능 개선은 약 98.84%의 향상
프로세스 최적화 이후와 비교한 계산 과정
- 개선된 시간 = 4,465ms - 88ms = 4,377ms
- 개선율 = (개선된 시간 / 원래 시간) * 100 = (4,377 / 4,465) * 100 ≈ 98.03%
따라서, 4,465ms에서 88ms로의 성능 개선은 약 98.03%의 향상
역시…. 가장 좋은 것은 돈을 들여서 리소스 자원을 업그레이드하는 것이다.
이 경험을 통해서 배운 것은
- 성능 테스트의 중요성
실제로 서비스를 운영하기 전에 테스트 환경에서 성능을 측정하고 개선하는 과정이 얼마나 중요한지 깨달았다.
특히 우리 서비스처럼 축제 때 트래픽이 폭주하는 상황을 고려하면 더욱 그렇다.
500명의 유저가 약 25만 개의 매칭 데이터를 요청하는 상황을 가정하고 테스트했는데
초기에는 평균 응답 시간이 무려 7575ms나 걸렸다. 이런 식으로 미리 문제를 파악하고 개선할 수 있었다. - 단계별 최적화의 효과
문제를 한 번에 해결하려고 하지 않고, 하나씩 파악하고 개선해 나가는 방식이 효과적이었다.
HikariCP 설정 최적화로 연결 풀 고갈 문제를 해결하고, Caffeine 캐시 적용으로 전체 응답 시간을 39.68% 개선했다. 인덱싱과 트랜잭션 최적화를 통해 처음 대비 41.06%의 성능 향상을 이뤘고
이런 식으로 단계별로 접근하니 각 단계에서의 효과를 명확히 볼 수 있었다. - DB 최적화의 중요성
DB 최적화가 전체 성능에 미치는 영향이 엄청나다는 걸 직접 경험했다.
특히 매칭 엔티티에 복합 인덱스를 추가하니까 조회 성능이 크게 향상됐다.
트랜잭션 관리도 중요했는데, 읽기 전용 메서드에 @Transactional(readOnly = true)를
적용하니까 불필요한 락을 방지하고 성능이 개선됐다. - 캐싱의 효과
Caffeine 캐시를 제대로 설정하니 배너 매칭 목록 조회 API의 응답 시간이 32,414ms에서 3,784ms로 줄어들었다.
이건 무려 88.33%의 개선이다. 캐시 설정을 제대로 하니까 전체 응답 시간도 40% 가까이 개선되었다. - 하드웨어 리소스의 영향
소프트웨어 최적화도 중요하지만, 역시 가장 좋은 건 돈을 들여서 리소스 자원을 업그레이드하는 것이다.
로컬 DB로 테스트했을 때 평균 응답 시간이 7575ms에서 88ms로 줄어들었는데
최적화를 진행하지 않았을 때 대비 98.84%의 성능 향상
최적화하고 리소스만 업그레이드 했을 때 대비 98.03% 성능 향상이 되었다. - 아키텍처 설계의 중요성
Master-Slave 구조로 DB를 설계하고, event_id 기준으로 파티셔닝을 해 놓았다.
이런 설계가 성능에 미치는 영향을 고려하면서 개발하는 게 중요하다는 걸 배웠다.
이번 경험을 통해서
성능 최적화가 단순히 코드 몇 줄 바꾸는 게 아니라
전체적인 시스템 설계부터 세세한 설정까지 모든 게 연관되어 있다는 걸 배웠다.
그리고 무엇보다 수치로 개선 정도를 확인할 수 있어서 좋았다.
다음 프로젝트에서는 이런 경험을 바탕으로 처음부터 성능을 고려한 설계를 할 수 있을 것 같다.
