비교해보기
체육관 검색 API를 비교해 보기위해서 API를 두가지 v1(캐시)와 v2(인메모리)를 만들어서 성능 비교
테스트 환경
- 총 데이터 건수 : 5,000,000건 이상 (500만건 이상의 체육관 데이터)
- 100,000 ~ 500,000만 건에서는 캐시와 인메모리 두 환경에서 큰 차이가 없어 데이터를 많이 입력
테스트 시나리오
1. Postman 개별 요청 테스트
-
API엔드포인트 :
http://localhost:8080/search/gyms/v1와(...)v2 -
검색 키워드 : "홍대", "강남" 각각 검색
-
측정 지표 : 개별 요청 응답 시간
v1(캐시)를 사용한 검색 키워드 : "홍대"
첫번째 검색
두번째 검색
최댓값
최솟값
v2(인메모리)를 사용한 검색 키워드 : "홍대"
첫번째 검색
두번째 검색
최댓값
실수로 인한 누락
최솟값
실수로 인한 누락
첫번째 검색과 두번째 검색의 기준으로 비교를 해보고 이두값을 최댓값과 최솟값을 넣는다고 가정을 했을 때 유의미한 수치 비교가 아닌거 같다.
v1(캐시)를 사용한 검색 키워드 : "강남"
첫번째 검색
두번째 검색
최댓값
최솟값
v2(인메모리)를 사용한 검색 키워드 : "강남"
첫번째 검색
두번째 검색
최댓값
실수로 인한 누락
최솟값
실수로 인한 누락
홍대키워드와 같은 사유로 누락이 되었지만 유의미한 수치가 아님.
이 두가지를 표로 만들어본다면
홍대 검색 결과 ("홍대" 키워드)
| 구분 | v1 (캐시) | v2 (인메모리) | v1이 v2보다 빠른 정도 |
|---|---|---|---|
| 1차 | 8.49s | 8.43s | v2가 0.7% 빠름 |
| 2차 | 45ms | 4.70s | v1이 99.0% 빠름 |
| 최솟값 | 24ms | 4.70s | v1이 99.5% 빠름 |
| 최댓값 | 30ms | 8.43s | v1이 99.6% 빠름 |
| 평균 | 4.27초 | 6.57초 | v1이 35% 빠름 |
강남 검색 결과 ("강남" 키워드)
| 구분 | v1 (캐시) | v2 (인메모리) | v1이 v2보다 빠른 정도 |
|---|---|---|---|
| 1차 | 10.86s | 8.52s | v2가 27.5% 빠름 |
| 2차 | 40ms | 4.19s | v1이 99.0% 빠름 |
| 최솟값 | 20ms | 4.19s | v1이 99.5% 빠름 |
| 최댓값 | 36ms | 8.52s | v1이 99.6% 빠름 |
| 평균 | 5.45초 | 6.36초 | v1이 14.2% 빠름 |
2. JMeter 부하테스트
-
동시 사용자 : 1500 명
-
총 요청 수 : 1500 회
-
측정 지표 : 평균 응답시간, 처리량, 백분위수 성능
v1 (캐시 방식) 부하 테스트 결과
| 지표 항목 | 수치 | 설명 |
|---|---|---|
| 평균 응답시간 | 3,737ms | 대용량 데이터 처리 고려 시 우수 |
| 중간값 (Median) | 3,454ms | 안정적인 중앙값 |
| 90% Line | 5,392ms | 90% 사용자가 5.4초 이내 응답 |
| 95% Line | 6,242ms | 95% 사용자가 6.2초 이내 응답 |
| 99% Line | 7,021ms | 거의 모든 사용자가 7초 이내 응답 |
| 최소값 | 580ms | 최적 조건에서의 응답 시간 |
| 최대값 | 8,453ms | 최악 조건에서도 8.5초 이내 응답 |
| 에러율 | 0.00% | 500만 건에서도 완벽한 안정성 |
| 처리량 (TPS) | 78.4/sec | 초당 78건의 검색 요청 처리 가능 |
v2 (인메모리 방식) 부하 테스트 결과
| 지표 항목 | 수치 | 설명 |
|---|---|---|
| 평균 응답시간 | 65,101ms | 대용량 데이터 처리에 부적합 |
| 중간값 (Median) | 67,564ms | 일관되게 느린 성능 |
| 90% Line | 86,858ms | 90% 사용자가 1분 30초 이상 대기 |
| 95% Line | 88,178ms | 거의 모든 사용자가 장시간 대기 |
| 99% Line | 91,894ms | 최악의 경우 1분 30초 이상 소요 |
| 최소값 | 6,698ms | 최선 조건에서도 6.7초 소요 |
| 최대값 | 93,901ms | 최악 시 94초, 사실상 타임아웃 수준 |
| 에러율 | 69.33% | 500만 건 처리 시 시스템 과부하 발생 |
| 처리량 (TPS) | 6.1/sec | 매우 낮은 초당 처리량 |
대용량 데이터 환경 성능
- 500만 건 데이터에서의 성능 특성
캐시 효율성
- 검색 속도 : 500만 건 중 키워드 검색이 웜업 후 평균 22-45ms
- 캐시 히트율 : 효율적인 캐시 전략으로 빠른 응답
- 확장성 : 캐시 레이어로 데이터베이스 부하 분산
- 콜드 스타트 : 초기 8-10초 후 극적인 성능 향상
인메모리 시스템 한계
- 메모리 부족 : 500만 건 전체 로딩 시 메모리 오버헤드
- GC 압박 : 대용량 힙 사용으로 가비지 컬렉션 지연
- 일관된 저성능 : 웜업 효과 없이 지속적으로 느린 응답
- 고부하 취약성 : 동시 사용자 증가 시 심각한 성능 저하
- 부하 수준별 성능 스케일링
| 성능 지표 | v1 (캐시) | v2 (인메모리) | v1이 v2보다 우수한 정도 |
|---|---|---|---|
| 평균 응답시간 | 3,737ms | 65,101ms | 94.3% 빠름 |
| 처리량 (TPS) | 78.4/sec | 6.1/sec | 1,185% 높음 |
| 에러율 | 0.00% | 69.33% | 완벽한 안정성 |
메모리 사용량 및 리소스 분석
500만 건 데이터 메모리 사용량 추정
캐시 방식 메모리 사용량 :
- 자주 사용되는 데이터만 캐시 : 약 500MB - 1GB
- 캐시 히트율에 따른 동적 메모리 사용
- LRU 등 캐시 교체 알고리즘으로 효율적 관리
인메모리 방식 메모리 사용량 :
- 체육관 정보 평균 크기: 1KB/건
- 총 원시 데이터 : 5GB
- 인덱스 구조: 추가 500MB
- 총 메모리 사용량: 약 5.5GB
K6 부하 테스트
K6를 이용해서 캐시시스템만을 대상으로 웜업 후 최적 성능을 측정
키워드 : "강남", "홍대" 순서를 임의로 검색
성능 지표
| 지표 항목 | 수치 | 설명 |
|---|---|---|
| 평균 응답시간 | 22.25ms | 500만 건 중 실시간 검색 결과 |
| 최소 응답시간 | 11.97ms | 최적 조건에서의 검색 속도 |
| 중간값 (Median) | 19.1ms | 일반적인 검색 응답 시간 |
| 최대 응답시간 | 77.57ms | 최악 조건에서도 100ms 미만 |
| 90% Line | 32.48ms | 사용자 90%가 32ms 이내 응답 체험 |
| 95% Line | 45.58ms | 거의 모든 사용자가 50ms 이내 응답 |
| 실패율 | 0.00% (0/100) | 대용량 데이터에서도 100% 안정성 |
| 요청 처리량 | 9.749395/s | 초당 약 10건의 검색 처리 |
실행 및 네트워크 성능
| 지표 항목 | 수치 | 설명 |
|---|---|---|
| 실행 지속시간 평균 | 1.02s | 안정적인 처리 시간 |
| 실행 지속시간 중간값 | 1.01s | 일관된 성능 |
| 90% Line | 1.03s | 90% 요청에 대한 일관된 처리 시간 |
| 95% Line | 1.05s | 95% 요청에 대한 예측 가능한 응답 |
| 총 반복 수행 | 100회 | 모든 요청 성공 |
| 데이터 수신량 | 566 kB (55 kB/s) | 효율적인 검색 결과 전송 |
| 데이터 송신량 | 12 kB (1.2 kB/s) | 최소한의 요청 데이터 |
K6 테스트 목적과 결과
- 테스트 대상 : 캐시 시스템
- 테스트 목적 : 캐시 웜업 후 최적 성능 검증 및 네트워크 효율성 측정
- 테스트 환경 : 10명의 동시 사용자, 실제 운영 환경과 유사한 부하
- 핵심 결과 : 5000만 건 데이터에서 평균 22.25ms 응답시간 달성
- 독립성 : JMeter와 별도 목적으로 수행된 독립적인 테스트
네트워크 효율성 -> 캐시 웜업 후 성능
- 압축률 : 47:1(12kB 요청 -> 566kB 응답)
- 검색 결과 최적화 : 필요한 데이터만 선별적 전송
- 대역폭 효율성 : 초당 55kb 수신으로 안정적 처리
- 웜업 후 응답시간 : 평균 22.25ms로 실시간 검색
실제 운영 환경 고려사항
- 캐시 관리 전략
- 캐시 히트율 최적화 : 자주 검색되는 키워드 우선 캐시
- TTL 설정 : 데이터 신선도 유지를 위한 적절한 만료 시간 -> 현재 5분으로 적용중
- 캐시 워밍 : 서비스 시작 시 주요 데이터 사전 로딩
- 인메모리 시스템 문제점
- 메모리 부족 : 5.5GB 메모리 요구사항으로 인한 높은 인프라 비용
- 시작 지연 : 500만 건 이라는 대용량 데이터를 로딩이 길어 지고 그로 인해 애플리 케이션 부팅 시간도 증가
- GC 튜닝 복잡성 : 대용량 힙 관리의 어려움
- 확장성 고려사항
- 캐시 클러스터링 : Redis Cluster 등을 통한 수평 확장
- 부하 분산 : 캐시 레이어 분산으로 고가용성 확보
- 모니터링 : 캐시 히트율, 메모리 사용량 실시간 추적
종합 성능 비교 요약
핵심 성능 지표 비교 (캐시 기준)
| 테스트 시나리오 | v1 (캐시) 성능 | v2 (인메모리) 성능 | v1이 v2보다 빠른 정도 |
|---|---|---|---|
| 개별 요청 (안정화 후) | 20-45ms | 4-8초 | 99% 빠름 |
| 고부하 (1,500 VU) | 3,737ms | 65,101ms | 94.3% 빠름 |
| 처리량 (TPS) | 78.4/sec | 6.1/sec | 1,185% 높음 |
| 에러율 | 0% | 69.33% | 완벽한 안정성 |
성능 패턴 분석
캐시 시스템의 특성
- 콜드 스타트 : 초기에는 캐시 미스로 인해 8-10초의 느린 성능
- 웜업 효과 : 캐시가 채워진 후 20-45ms로 극적인 성능 향상
- 일관성 : 웜업 후 안정적인 고성능 유지
- 확장성 : 고부하 상황에서도 0% 에러율로 안정적 서비스
여기서 보여지는 것은 캐시 시스템을 너무 잘보여준다는 점
- 초기에는 캐시 미스로 느리지만, 캐시가 워밍업 된 후에는 압도적으로 빠른 성능을 보여줌
결론
대용량 환경에서의 성능 : 캐시 시스템
압도적인 성능 지표
- 응답 시간 : 인메모리 대비 캐시 시스템 94.3% 빠름
- 처리량 : 인메모리 대비 캐시 시스템 12.8배 높음
- 안정성 : 인메모리 에러율 69.33% 인 반면 캐시시스템은 0%
- 확장성 : 대용량 데이터에서도 ms 단위 응답
으로 압도 적인 성능 차이를 보여준 다는 것을 확인
비즈니스 임팩트
- 사용자 경험 : 웜업 후 22-45ms 라는 평균 응답으로 빠른 검색기능 사용
- 시스템 효율성 : 500만 건 에서도 안정적인 서비스 제공
- 운영 비용 : 효율적인 메모리 사용으로 인프라 비용 최적화
인메모리 방식의 근본적 문제
- 성능 저하 : 극도로 느린 응답시간
- 높은 에러율 : 69.33% 에러율로 실운영 부적합
- 처리량 부족 : 낮은 TPS로 대용량 트래픽 처리 불가
- 메모리 오버헤드 : 5.5GB라는 메모리를 요구, 따라서 높은 인프라 비용 발생
따라서, 데이터량의 증가 및 많은 사용자 접속을 고려 해봤을 때 캐시 시스템이 확연히 좋다는 것을 확인
INTP