캘린더 조회 Redis를 활용해 성능 개선하기

캘린더 조회 Redis를 활용해 성능 개선하기

1. 증상

LounGe 서비스는 캘린더에서 본인의 일정도 추가할 수 있으면서 가입되어 있는 그룹의 일정도 캘린더에서 함께 보여준다.
이는 많은 그룹에 가입되어 있으면 많은 일정을 한 번에 불러와 서비스에서 가장 부하가 쉽게 걸릴 곳으로 예상을 했다.

• 많은 데이터를 조회하기 때문에 성능 저하가 가장 빈번하게 일어남

 

2. 해결방법

사과 그룹과 망고 그룹이 있다.
사과 그룹에는 100명의 인원이 가입되어 있고 망고에는 10명의 인원이 가입되어 있다.
만약 두 개의 그룹 일정이 같다면
사과는 한 사람이 한 번씩 일정을 확인하더라도 망고보다 90번의 그룹 일정을 추가적으로 더 불러오는 것이다.
그렇다면 사과라는 그룹의 일정은 캐시에 저장하여 데이터 베이스와의 통신 횟수를 줄여 성능을 개선할 수 있지 않을까?
즉 그룹의 인원이 많은 경우 일정을 조회하는 횟수가 높을 것이다.
또한 그룹의 인원이 많을 경우 일정이 더 많을 확률이 높다는 결론이 나왔다.
특정 인원을 넘어가거나 인원수 상위 그룹을 기준으로 일정을 캐시에 저장하여 조회하는 방식을 생각해 보았고 이를 도입하기로 하였다.

• 조건을 설정하여 조건에 충족되는 그룹의 일정을 캐시에 저장

기존의 코드는 가독성도 매우 떨어지고 반복되는 코드들도 많이 존재한다.

기존 코드

클라이언트가 가입한 그룹 중 상위 그룹의 일정을 어떤 방식으로 캐시에 저장해야 하는가??

클라이언트가 가입되어 있는 그룹 중 해당하는 기간에 일정이 존재하는 그룹 리스트와 모든 그룹 중 상위 그룹 리스트를 데이터 베이스에서 가져와서 filter를 통해 클라이언트가 가입되어 있는 상위 그룹과 하위 그룹을 나눠줬다.

그리고 상위 그룹 중 클라이언트가 가입되어 있는 그룹을 반복문을 통해 데이터가 캐시에 존재하는지를 확인한 뒤 있다면 cacheData 배열에 넣어주고 없다면 nullCacheGroups 배열에 넣어줬다.

하위 그룹의 배열과 상위 그룹 중 캐시에 데이터가 존재하지 않는 그룹의 배열을 합쳐 데이터 베이스에서 데이터를 가져와서 상위 그룹에 대한 데이터는 캐시에 저장해주는 방식으로 코드를 리팩토링 하였다.

 

개선 후 코드

 

3. 결과

기존 성능에서 약 48% 성능이 개선되었다.

• 기존 성능

• 개선한 성능

클린 코드 리팩토링!

코드가 너무 지저분하니 가독성이 매우 안좋았다.

클린코드 리팩토링을 진행했고 최대한 함수로 분리 하였다.

아래와 같은 코드로 리팩토링을 할 수 있었다.

가독성을 높여보자!