테스트 설명전에 제가 왜 소모임 다건 목록 조회 부분에 왜 Redis를 사용했는지 설명드리겠습니다.
총 4가지로 설명드리겠습니다.
1. 고속 데이터 조회 및 응답 속도 개선
- 이유: 소모임 목록을 여러 사용자가 빈번하게 조회할 경우, 데이터베이스에 직접 접근하여 조회할 때마다 시간이 많이 소요되고, 서버에 과부하가 발생할 수 있습니다.
- Redis 사용 목적: Redis는 인메모리 데이터 저장소로, 데이터베이스보다 훨씬 빠르게 데이터를 읽어올 수 있습니다. Redis에 소모임 목록 데이터를 캐시하면 데이터베이스를 거치지 않고 빠르게 응답을 반환할 수 있어 사용자 경험이 개선됩니다.
2. 데이터베이스 부하 경감
- 이유: 소모임 목록은 많은 사용자가 동시에 조회하는 가능성이 높고, 지속적인 데이터베이스 조회는 서버 부하를 증가시키며 성능 저하를 초래할 수 있습니다.
- Redis 사용 목적: Redis에 캐싱을 하면 동일한 데이터에 대한 반복적인 데이터베이스 쿼리를 줄일 수 있습니다. 이를 통해 데이터베이스의 부하가 경감되고, 서버의 안정성이 향상됩니다.
3. 높은 트래픽에 대한 확장성 및 안정성 확보
- 이유: 소모임 목록 조회 기능은 트래픽이 급증할 수 있으며, 이 경우 데이터베이스에 직접 의존하게 되면 서버가 쉽게 과부하에 걸릴 수 있습니다.
- Redis 사용 목적: Redis는 높은 트래픽 상황에서도 빠르게 응답을 처리할 수 있는 구조이기 때문에, 대량의 요청이 들어오더라도 안정적인 성능을 유지할 수 있습니다. 이는 서버의 확장성과 안정성을 확보하는 데 매우 중요한 역할을 합니다.
4. 일관된 사용자 경험 제공
- 이유: 데이터베이스의 부하가 높은 상황에서는 응답 속도가 느려져 사용자가 소모임 목록을 로드하는 데 시간이 오래 걸릴 수 있습니다.
- Redis 사용 목적: Redis에 캐시된 데이터를 이용하면 일정한 속도로 데이터를 제공할 수 있어, 사용자는 항상 일관된 속도로 소모임 목록을 조회할 수 있게 됩니다.
그래서 Redis를 사용함으로써 데이터베이스 부하를 줄이고, 빠르 응답 속도로 사용자가 원할하게 소모임 목록을 조회할 수 있게 하며, 대량 트래픽 상황에서도 서버의 안정성을 보장할 수 있었습니다. 이러한 이유로 Redis는 소모임 목록 조회에 필수적이며, Redis를 통해 효율적인 데이터 관리와 성능 최적화를 이루게 되었습니다.
성능에 관에 얼마나 향상되었는 Redis 적용 전 적용 후의 데이터를 토대로 설명드리겠습니다
Redis 적용 전
한번 다건 조회시 조회될 소모임 목록: 35건
Number of Threads (users) : 5000
Ramp-up period (seconds): 10
Loop Count: 2
더미 유저를 5000명으로 설정하고 테스트 돌리니 컴퓨터 성능 이슈로 8104번째에 테스트가 멈추어 더미 유저를 3000명으로 낮추고 다시 시도해 보았습니다.
Number of Threads (users) : 3000
Ramp-up period (seconds): 10
Loop Count: 2
데이터 해석
Samples: 테스트에 사용된 요청의 개수. gathering get 요청에 대해 총 6000개의 샘플이 실행되었다.
Average (평균 응답 시간): 모든 요청의 평균 응답 시간. 1610ms로, 모든 요청의 평균 응답 시간이 1.61초임을 나타낸다.
Median (중앙값): 응답 시간의 중앙값. 1747ms로, 전체 요청 중 절반의 응답 시간이 이 값 이하이며 나머지 절반은 이 값 이상임을 의미한다.
90% Line: 전체 응답 시간의 90%가 1923ms 이하였음을 나타낸다. 즉, 90%의 요청이 1.923초 이내에 응답을 받았다.
95% Line: 전체 응답 시간의 95%가 1932ms 이하였음을 의미한다.
99% Line: 전체 응답 시간의 99%가 2139ms 이하였음을 나타낸다.
Min (최소 응답 시간): 가장 빠른 응답 시간으로 148ms
Max (최대 응답 시간): 가장 느린 응답 시간으로 2534ms
Error %: 에러 비율. 에러가 발생하지 않았기 때문에 0.00%로 표시
Throughput: 초당 처리량을 나타낸다. 514.7/sec로, 초당 약 515개의 요청이 처리됨.
Received KB/sec: 초당 수신된 데이터 양. 1629.59 KB/sec로, 매초 약 1.63MB의 데이터가 수신.
Sent KB/sec: 초당 전송된 데이터 양. 218.15 KB/sec로, 매초 약 0.218MB의 데이터가 전송됨.
그래프 해석
그래프는 평균, 중앙값, 90% Line, 95% Line, 99% Line, 최소 및 최대 응답 시간을 시각적으로 보여줌.
평균 응답 시간과 중앙값이 유사하게 나타나며, 대부분의 요청이 약 1600~2000ms 범위 내에서 응답을 받는 것을 알 수 있다.
최대 응답 시간이 2534ms로, 일부 요청은 응답이 지연되었음을 알 수 있다.
결론은?
이 테스트 결과는 대부분의 요청이 약 1.6~2초 내에 응답을 받는 성능을 보여주며, 오류는 발생하지 않았다. Throughput(처리량)도 초당 515개 요청을 처리하는 안정적인 성능을 나타낸다.
Graph Result
그래프 설명
Y축 (ms): 응답 시간으로, 밀리초(ms) 단위로 나타냅니다. 높은 값일수록 응답 시간이 길어진다.
X축: 샘플(요청) 수로, 총 6000개의 요청이 수행되었음.
색상별 라인
파란색 (Average): 평균 응답 시간. 이 값은 지속적으로 추적되어 평균 응답 시간이 어떻게 변했는지 보여준다.
보라색 (Median): 중앙값 응답 시간으로, 전체 응답 시간의 중간값을 나타낸다.
빨간색 (Deviation): 편차로, 응답 시간의 변동성을 나타내며, 값이 클수록 응답 시간의 일관성이 떨어진다.
초록색 (Throughput): 초당 처리량으로, 초당 얼마나 많은 요청이 처리되었는지를 보여줍니다. 값이 높을수록 더 많은 요청이 처리되었음을 의미한다.
주요 해석
평균 및 중앙값 응답 시간:
그래프 상에서 파란색(평균)과 보라색(중앙값)이 안정적으로 유지되는 모습을 보여준다. 이 값들이 일정하다는 것은 응답 시간이 비교적 일관되게 유지되었음을 의미한다.
평균 응답 시간은 약 1610ms이고, 중앙값은 1747ms로 확인된다.
편차 (Deviation):
빨간색 편차 값이 조금씩 증가하는 모습을 보여준다. 이는 요청마다 응답 시간의 변동성이 증가했음을 나타낸다.
응답 시간의 편차가 커진다는 것은 시스템 부하가 증가하거나, 서버의 응답 일관성이 떨어질 수 있음을 시사한다.
처리량 (Throughput):
초록색 선은 초당 처리량을 나타내며, 초기에는 낮았다가 점차 증가하여 최대 30,882.731/min에 도달.
처리량이 증가하고 일정하게 유지되었다는 것은 서버가 많은 요청을 효과적으로 처리했음을 의미한.
응답 시간의 일관성:
평균, 중앙값, 90%/95%/99% 라인이 큰 변동 없이 유지되는 것으로 보아, 대다수의 요청이 안정적인 응답 시간을 가졌다.
결론은?
이 그래프는 6000개의 요청에 대해 응답 시간이 안정적으로 유지되었고, 처리량도 증가하며 고르게 분포된 것을 보여줍니다.
편차가 점차 커진 점은 응답 시간의 변동성이 다소 증가했음을 나타냅니다.
전체적으로 봤을 때, 성능이 비교적 안정적이며 요청에 대한 처리량과 응답 시간의 일관성이 높습니다.
그리고 Redis를 적용한 후 결과
Number of Threads (users) : 3001
Ramp-up period (seconds): 10
Loop Count: 2
거의 동일한 조건에서 테스트를 시행하였다.
Samples: 총 요청 수. 6002번의 요청이 수행됨
Average: 평균 응답 시간(밀리초). 평균적으로 7ms가 소요됨.
Median: 중앙값 응답 시간. 50%의 요청이 2ms 이하의 응답 시간을 가짐.
90% Line: 상위 90% 요청의 응답 시간이 5ms 이하.
95% Line: 상위 95% 요청의 응답 시간이 56ms 이하.
99% Line: 상위 99% 요청의 응답 시간이 117ms 이하.
Min: 최저 응답 시간, 1ms
Max: 최대 응답 시간, 198ms
Error %: 요청 중 실패한 비율. 0.02%로, 에러 발생이 거의 없다.
Throughput: 초당 처리된 요청 수로, 94.0/sec
Received KB/sec: 초당 받은 데이터 양(KB), 297.67KB/sec
Sent KB/sec: 초당 보낸 데이터 양(KB), 39.85KB/sec
전체적으로 평균 응답 시간이 7ms로 우수한 성능을 보이고, 오류율도 매우 낮아 안정적인 요청 처리가 이루어졌다고 평가할 수 있습니다.
Redis 적용 전하고 비교하면 성능이 얼마나 차이나는가?
1. Samples (요청 개수)
Redis 적용 전: 6000개
Redis 적용 후: 6002개
2. Average (평균 응답 시간)
Redis 적용 전: 1610ms
Redis 적용 후: 7ms
개선 정도: 평균 응답 시간이 99.6% 감소
3. Median (중앙값 응답 시간)
Redis 적용 전: 1747ms
Redis 적용 후: 2ms개선 정도: 중앙값 응답 시간이 99.9% 감소했습니다.
개선 정도: 중앙값 응답 시간이 99.9% 감소
4. 90% Line
Redis 적용 전: 1923ms
Redis 적용 후: 5ms
개선 정도: 90%의 응답 시간 상한이 99.7% 감소
5. 95% Line
Redis 적용 전: 1932ms
Redis 적용 후: 56ms
개선 정도: 95% 응답 시간이 97.1% 감소
6. 99% Line
Redis 적용 전: 2139ms
Redis 적용 후: 117ms
개선 정도: 99% 응답 시간이 94.5% 감소
7. Min (최소 응답 시간)
Redis 적용 전: 148ms
Redis 적용 후: 1ms
개선 정도: 최소 응답 시간이 99.3% 감소
8. Max (최대 응답 시간)
Redis 적용 전: 2534ms
Redis 적용 후: 198ms
개선 정도: 최대 응답 시간이 92.2% 감소
9. Error % (에러 비율)
Redis 적용 전: 0.00%
Redis 적용 후: 0.02%
변화 없음: 에러 비율은 거의 발생하지 않으며, Redis 적용 후에도 안정성이 유지됨.
10. Throughput (처리량)
Redis 적용 전: 514.7/sec
Redis 적용 후: 94.0/sec
감소: Redis 적용 후 처리량이 감소했으나, 이는 요청당 처리 속도가 훨씬 빨라졌기 때문으로 보인다. Redis 캐시가 적은 리소스로 빠르게 데이터를 제공해 높은 성능을 보여준다.
결론
Redis를 적용함으로써 전반적으로 응답 시간이 평균적으로 99% 이상 개선되었습니다. 또한 대부분의 응답에서 Redis 캐시가 큰 효과를 보였으며, 특히 중앙값 및 90% 이상 응답 시간에서 눈에 띄는 성능 향상이 이루어졌습니다. Throughput 수치는 줄어들었지만, 이는 요청당 리소스 소모가 줄어든 것으로 해석할 수 있습니다.
따라서 Redis 적용으로 인해 요청 처리 속도는 대폭 향상되었으며, 시스템의 안정성 또한 유지되었습니다.
Redis를 적용한 Graph Result를 보면?
Samples: 6002개의 샘플이 테스트에 사용
Deviation: 편차가 20ms로, 응답 시간의 변동이 크지 않음
Throughput: 초당 약 5,642개의 요청이 처리되고 있어 매우 높은 처리량을 나타냄
Latest Sample: 가장 최근 요청의 응답 시간은 3ms
Average: 평균 응답 시간은 7ms
Median: 중앙값 응답 시간은 2ms
이 그래프는 응답 시간의 평균 및 중앙값이 매우 낮고 편차가 일정하다는 점에서 일관되고 빠른 성능을 보여줍니다
처리량(Throughput)이 초당 약 5,642개라는 점에서 Redis를 활용한 캐싱이 성능을 크게 향상시켰고, 시스템이 높은 부하에서도 안정적으로 작동하고 있음을 알 수 있습니다.
그리고 Redis 적용을 통해 전체적으로 응답 시간, 일관성, 리소스 효율성이 크게 개선되었습니다. 특히, 평균, 중앙값, 최대 응답 시간에서 90% 이상의 성능 향상이 이루어졌으며, 처리 속도에서 Redis 캐싱의 긍정적인 효과를 확인할 수 있습니다. Throughput이 줄어든 것은 효율적인 리소스 사용의 결과로 해석되며, Redis를 통한 데이터 캐싱이 고성능 시스템 구축에 유리하다는 점을 보여줍니다.
표로 간단히 보면?
지표 | Redis 적용 전 | Redis 적용 후 | 개선도 |
Samples | 6000 | 6002 | - |
Average | 1610 ms | 7 ms | 99.6% 감소 |
Median | 1747 ms | 2ms | 99.9% 감소 |
90% Line | 1923 ms | 5 ms | 99.7% 감소 |
95% Line | 1932 ms | 5 ms | 97.1% 감소 |
99% Line | 2139 ms | 117 ms | 94.5% 감소 |
Min | 148 ms | 1 ms | 99.3% 감소 |
Max | 2534 ms | 198 ms | 92.2% 감소 |
Deviation | 344 ms | 20 ms | 94.2% 감소 |
Throughput | 30,882.731 requests/minute | 5,642.126 requests/minute | 감소(성능 향상) |
'우리 지금 만나' 카테고리의 다른 글
인프라 난항2-(7)(우리 지금 만나) (2) | 2024.11.03 |
---|---|
소모임 단건 조회에 RedisLimiter를 적용 후 Jmeter 테스트-(6)(우리 지금 만나) (0) | 2024.10.30 |
인프라 난항-(4)(우리 지금 만나) (2) | 2024.10.27 |
인프라 설계 -(3)(우리 지금 만나) (8) | 2024.10.23 |
AWS S3 첨부파일-(2)(우리 지금 만나) (2) | 2024.10.23 |