redis적용전과 적용후를 비교해보자.

Definition Access

• 문제

  • 채팅과 관련하여 채팅방에 입장 할 때 이전 메세지를 불러오는 부분에서 Jpa Query Method로 DB의 채팅메시지를 저장하는 테이블을 조회하여 채팅메시지를 출력하였는데, RDB의 테이블을 조회하는 횟수가 많아지게 되면 서버에 부담이 많이 발생할 것이라는 생각과 함께 조회속도 또한 느려질 수 있다는 결론으로 조회방식에 대한 최적화를 고민함.

• 선택지

  • 채팅메시지를 redis를 이용하여 cache memory에 저장하고 DB에도 저장 후 조회하는 방식
  • 이유: Jpa Query Method를 사용하여 RDB에서 조회하는 방식보다 조회 속도 및 서버의 부담이 줄어든다는 것을 멘토님들과의 회의를 통해 알게 됨

• 결과

  • 메세지를 저장할 때는 Redis와 DB에 같이 저장하고, 메세지를 조회할 경우에는 Redis Cache를 사용하는 로직 적용 후 테스트 결과 RDB에서 조회 하는 것 대비 80%~ 138% 성능 향상을 확인함.

Retrospection

• 직렬화와 역직렬화 오류를 수정하면서 redis에 대해서 공부해보았는데, 실제로 유의미한 결과를 실제 서비스에서 볼수 있으려면 엄청난 양의 데이터가 필요했다.(적어도 천만건 이상의 데이터)

• 실제로 그만한 양의 데이터를 넣을 시간과 비용이 부족하기때문에 효과적으로 이것을 측정해볼 수 있는 Jmeter를 사용해서 측정해보았다.

• 우리는 경매라는 실시간성을 중시하고 또한 채팅을 하면서도 가격이 변동 될 수 있기때문에 채팅목록 또한 빠르게 불러올 수 있어야 했다.

• 실제로 우리가 만든 서비스에서는 사용자가 유의미하지 않아서 db에서 조회해오는 속도나 redis를 통해서 조회해오는 속도가 똑같아 보였다.그래서 사실 redis를 써도 안써도 똑같은거 아닌가?라는 의심이 조금씩 올라왔다.

• 위의 표에서 보이듯이 실제로 jmeter에서 측정을 하는 중에도 redis로 조회해왔을때가 눈에 띄게 빠르다는 것을 알게되었다.

• 실제로 우리가 기준으로 한 10000명이 동시접속했을때라는 가정하에서
  db에서 조회해왔을때 0.24초에서 0.13초로 극적으로 속도가 상승한것을 보니까 정말로 내가 redis를 적용했구나라는 것을 알게되었다. 정말 어마어마 한 기술이라고 느꼈다.