매장 리뷰수 계산 api 성능 문제

사용 기술 : Nest.js - mongoDB

 

현제 서비스 중인 어플리케이션은 유저별 리뷰수를 지원을 하고 있다.

유저는 리뷰를 지울 수는 없으며, 개발자 혹은 기획자는 리뷰를 차단 할 수 있다.

 

이 글은 리뷰마다 유저들의 리뷰수를 보여주기 위하여 실제 서비스 운영중에 기능을 추가했던 상황과 대략적인 방식 그리고

현제 업데이트될 방식과 상황에 대한 글이다.

 

<2023년 2월 28일 기준 누적 유저 265 명이 회원가입을 했다>

 

 

데이터를 보자

 

유저의 리뷰 숫자가 , 리뷰 도큐먼트 안에 들어가 있다.

 

또한 유저의 데이터에도 유저 리뷰 카운트의 숫자가 들어가 있다.

 

- 리뷰의 숫자를 추가하는 기능이 리뷰를 만드는 기능보다 나중에 나와서 , 리뷰의 숫자를 계산하는 기능을 새롭게 업데이트를 할때 업데이트시 초기화 해주는 유저의 리뷰수 데이터 필드와 실제 리뷰수가 일치하지 않는 다라는 문제가 있었다.

 

user_review_count 가 모두 0으로 시작하는 상황을 생각해보자.

 

 

이러한 문제를 해결하기 위하여 다음과 같이 유저가 리뷰들의 목록을 조회하면 리뷰수를 갱신해주는 방향으로 조회 기능을 구성했었다.

 

  async reviewList(query: ReviewQuery) {
    const items = await this.reviewModel
      .find(query.Query())
      .skip(query.Skip())
      .limit(query.count)
      .sort({ review_created_at: -1 });
    items.map((e) => this.resetUserReviewCount(e.user.uid));
    return items;
  }

resetUserReviewCount 가, 유저가 존재한다며 , 리뷰 도큐멘트의 리뷰 수를 초기화 해준다.

 

이러한 방법이 가능했던 이유는 당시 유저수가 20 명이였고 , 리뷰수도 적었으니 서버에 무리가 가지 않겠다고 생각을 하고 빠르게 개선을 하는 방향으로 개발 방향을 정했다.

 

위의 코드를 실행시 91ms 의 대략적인 postman 의 응답 속도를 보인다.

 

수정한 현제의 리뷰 리스트 호출 함수이다.

async reviewList(query: ReviewQuery) {
    const items = await this.reviewModel
      .find(query.Query())
      .skip(query.Skip())
      .limit(query.count)
      .sort({ review_created_at: -1 });
    return items;
  }

 

현제의 상황은 조회를 요청하는 api 를 호출시 각 유저의 맞는 리뷰 도큐먼트를 모두 찾아서 리뷰 숫자를 업데이트를 하지 않아도 되며

유저 도큐먼트의 유저의 리뷰 숫자("user_review_count ")와 실제 리뷰 숫자가 일치한다.

 

그렇므로 특정 유저가 리뷰를 추가할때만  관련된 리뷰 숫자들을 업데이트 해주면 된다.

 

1. 유저 도큐먼트의 리뷰수를 리뷰리스트를 호출할때 마다 조회를 하는것이 더 좋을 것 같다라는 판단

vs

2. 리뷰 리스트 조회시 도큐 먼트만 읽고 리뷰를 추가할때만 본인의 전체 리뷰 도큐먼트를 업데이트 하는것

 

위 두 상황을 비교했을때 , 자주 호출되는 api 는 리뷰수를 조회하는 비율이 생성하는 비율보다 높다 라는 판단과 각종 지표 및 경험으로

 

후자 2번을 선택했다.

 

 

상당하게 속도가 좋아졌다.

 

 

 

 

 

 

정리 :

mongoDB 의 경우 관계형 데이터 베이스보다 조회의 측면에서는 성능이 좋고 데이터를 업데이트나 수정시 성능이 나쁘다라는것을 공부했으며 데이터 베이스의 특성에 맞게 코드를 짜야 하며 , 그로 인하여 여러번의 테스 결과 평균적으로 30~40% 성능이 좋아졌다.

 

남은 과제

 

1. 부하 테스트 :

현제 프로세스는 node.js 기반의 서버 어플리케이션이며  pm2 를 이용하여 띄운다. , pm2 의 클러스터링을 도입을 시도하기 위해서는 우선적으로 얼마만큼의 유저가 얼만큼의 api 를 호출하는것을 버티는지 테스트 환경이 필요하다.

 

2. 정확한 지표

지금처럼 postman 을 사용하는 지표가 아닌 더 정확한 지표가 필요한 시점이다.