redis 캐시 적용기 ( 부하테스트를 곁들인... )

 

 

처음에 UI가 때문에 부하테스트를 nGrinder로 하다가

 

Jmeter도 써봤는데 인텔리제이랑 UI가 많이 비슷해서 

 

인텔리제이로 개발하다가 , Jmeter 쓰다가 번갈아 하기 좋은 것 같다. 

 

아직은 내 레벨에선 Jmeter 부하테스트 기능상의 불편함도 찾지 못했다!

 

 

본론

 

부하테스트를 진행해보며 redis를 이용한 캐시의 우수성을 직접 확인해보려한다

 

 

 

상황은 다음과 같다.

내가 개발하는 프로젝트의 메인 페이지에서 비 로그인 유저에게는

좋아요 많은 순으로 이미지(url,제목 정보)를 반환한다.

 

우리 서비스에 대한 요청이 메인페이지에서 집중된다는 점을 고려하면

메인 페이지에 대한 효율성 고민이 필요하다고 생각했다.

 

일차적으로, 페이징 처리(무한 스크롤)가 되어있어 부담을 줄였지만.. 더 줄여보자..!!

 

고민

1. 이미지 좋아요에 따라 실시간으로 이미지 순서를 다르게 보여주는게 중요할까?

2. 일정 시간동안은 이미지 순서가 같더라도 사용자에게 빠른 응답으로 이미지를 보여주는게 중요할까?

 

고민에 대한 답은 2번이었다.

짤은 검색해서 쓰는게 많다고 생각했고, 메인에서 굳이 바꿔가며 보여주는거보다 빠른 응답이 더 만족스러운 서비스가 될 것이라 생각했다.

 

또한 원래 프론트 측에서 검색에 대한 이미지 같은 것은 캐싱 작업을 하지만

메인 페이지는 무한스크롤이라 그 이미지를 모두 감당하기엔 사이즈가 좀 커서 백엔드에서 redis 캐시 메모리에 담아 처리하기로했다. 

 

 

 

생각한 해결 방법은 다음과 같다. 

 

사용자의 요청은 was 서버에서 캐시 메모리로 가서 값을 가져온다.

그리고 스케줄러로 일정 시간마다 캐시 메모리를 갱신 해주는 것이다. 

사용자의 요청은 DB로 가지 않아 커넥션 비용을 고려하지 않아도 되고, 사용자에게 빠른 응답을 해줄 수 있을 것이다. 

 

---

테스트 진행

 

스케줄링은 @Scheduled 를 사용

캐시는 Redis를 이용 (추후에 다중 서버로 확장시키고싶은 마음에 로컬 캐시 사용x)

부하테스트 툴은 Jmeter를 사용

 

 

캐시 사용 x

캐시 사용 o

캐시 사용x (10번 평균 50ms 정도)

캐시 사용o (10번 평균)

 

부하테스트에서 중요하게 볼 점

1. TPS (처리량)

2. Response Time (응답 시간) 

 

응답시간은 차이가 굉장히 많이 나는데, 처리량이 비슷하다.

쓰레드나 시간을 잘못 설정해서 그럴수도 있다고 하는데.. 

정확히는 모르겠다. TPS 에 관해서는 공부가 필요할 것 같다. 

 

결과적으로 응답시간이 10배 가까이 올라갔다. 하지만 캐시 메모리가 작은 만큼 좀 더 효율적인 상황에 쓸 수 있도록 더 많은 학습이 필요할 것 같다.