OhDelivery 프로젝트의 반경 내 조회 기능은 배달 주문이 들어왔을 때, 해당 가게의 반경 Nkm 이내에 있는 배달 가능한 상태의 라이더들을 조회하고 알림을 보내는 기능이다.

이 때, 라이더들의 위치가 실시간으로 변하므로 기존에 구현한 DB에서 조회하는 방식은 성능 저하가 발생할 것으로 예상하였다. 이에 Redis GEO 도입후 Jmeter를 통해 성능을 비교해보고자 한다.

테스트 시나리오

환경

테스트 도구 : Apache JMeter
라이더 수 : 50 / 100 (실시간 위치 업데이트)
조회 요청 스레드 수 : 100 / 200 (동시 조회 요청)

라이더 수와 조회 요청 스레드 수를 조절하며 3가지 테스트 케이스를 진행하고 비교한다.

시나리오

Thread Group 1 : Rider 위치 변경 API 부하
→ 랜덤 라이더 ID 선택 후 랜덤 좌표를 생성하여 실시간으로 위치 업데이트

Thread Group 2 : 라이더 조회 API 부하
→ 가게 좌표 반경 내 10km 이내의 라이더들을 조회
→ 50% DB 조회 / 50% Redis 조회
→ 동시 실행하여 같은 환경에서 비교

실시간으로 변하는 라이더 위치를 업데이트 해야하고 배달 주문이 하나 들어올 때 마다 가게 주변의 라이더를 매번 새롭게 조회해야 하므로 위와 같이 두 개의 테스트 그룹을 설정하여 진행한다.

측정 지표

•	Average Response Time (ms)
•	P50 / P90 / P95 / P99 Response Time (ms)
•	Error %
•	Throughput (TPS)

테스트

Case 1.

• 라이더 수 : 50
• 조회 요청 스레드 수 : 100
• 지속 시간 : 10분

Case 2.

• 라이더 수 : 50
• 조회 요청 스레드 수 : 200
• 지속 시간 : 10분

Case 3.

• 라이더 수 : 100
• 조회 요청 스레드 수 : 100
• 지속 시간 : 10분

인사이트

P95는 95%의 요청이 몇 ms안에 처리되는지 나타낸 지표로 실사용자 경험과 가장 가깝기 때문에 이를 기준으로 세가지 테스트 케이스에 대한 속도 개선을 비교해보도록 하자

P95	DB (ms)	Redis (ms)	개선율 (%)
Case #1	1130	518	54.16%
Case #2	4123	843	79.55%
Case #3	1084	738	31.92%
평균	-	-	55.21%

결과를 보면, DB를 통한 조회 방식보다 Redis GEO를 활용한 방식이 평균적으로 55%의 속도 개선 을 이루었음을 확인할 수 있다. 특히나 조회 요청 스레드가 2배 많은 케이스에서 DB 조회 방식이 눈에 띄게 느려진 것을 확인할 수 있고 이 경우 Redis GEO가 80% 빠른 것을 확인할 수 있었다.

다만 TPS는 모든 테스트 케이스에서 거의 동일한 수치를 보였다.
또한 에러율은 모든 테스트 케이스에서 0.01% 미만으로 안정적인 수치를 보였다.