게시물 관련 정보들을 캐시했을 때와 하지 않았을 때의 성능(응답속도)을 비교해보자!!

게시물 조회 로직에 캐시를 적용해야하는 이유

• 유저가 게시물 단건 조회 시 아래와 같이 많은 정보를 모아서 리턴한다.

  1. 게시물 정보
  2. 이미지 정보
  3. 게시물의 댓글 정보
  4. 게시물 작성자 유저 정보

• 이 정보들을 모두 DB에 질의해서 모아서 게시물 종합 정보를 리턴한다.

문제점

• 위 경우, posts/100 으로 게시물을 하나 조회하게 되면 DB에 최소 4번의 쿼리를 날려야 된다.

• SNS 도메인 특성 상, WRITE보단 READ의 비중이 훨씬 크기 때문에 READ의 성능을 개선할 필요가 있다.

• 그래서 각 정보들을 Redis에 캐시해놓고 캐시된 데이터들을 조합해서 리턴하도록 코드를 리팩토링했다.

  • 각각 따로 캐시해놓고 조합해서 리턴하는 이유는 조합된 데이터를 캐시해놓는다면 댓글이나, 좋아요 개수, 게시물 수정 등 변경이 일어날 때마다 캐시를 내렸다가 다시 올려야되기 때문에 오히려 오버헤드가 발생할 수 있기 때문이다.

🔨 세팅

nGrinder를 통해 트래픽 부어보기

• vuser 301명이 각각 30분동안 계속 게시물 49,000개 중 랜덤으로 200개씩 조회하는 상황

• 캐시가 있을 때와 없을 때를 비교해보자!

✅ 캐시 없는 경우, 부하 테스트 결과

✅ 캐시 있는 경우, 부하 테스트 결과

⭐ 비교 결과

• 캐시를 도입했을 때, 성능이 70% 이상 개선되었다고 볼 수 있다.

• 로그를 살펴본 결과, 캐시가 없을 때는 조회 api가 500ms까지 소요될 때가 있었지만, 캐시가 있을 때는 100ms 넘어가는 경우가 거의 없었다.

• 30분간 수행한 테스트의 개수도 캐시가 있을 때, 3배 가까이 소화했다.

• 테스트당 api를 203개씩 호출하는데 캐시가 있을 때가 없을 때보다 테스트를 34,602개 더 수행했다. 즉, 캐시가 있을 때, 7,024,206개의 api를 더 감당했다는 것이다.

조회 비중이 많은 서비스일 수록 캐시 유무에 따른 성능 차이가 극대화되는 것 같다.