캐시하기 어려울 때는 캐시할 수 있도록 정책을 바꿔보기

엄밀히 말하면 내 업무는 아니긴 한데, 다른 분 리뷰를 봐주다가 COUNT 쿼리가 엄청 느린 케이스가 있었다. 상품에 대한 리뷰 보여주는 방법을 변경하는 실험이었다. 다른 경우에는 괜찮은데, 상품에 대해 리뷰가 많을 경우 리뷰에 대한 COUNT가 너무 느려지는 케이스가 있어 문제가 되었다. 대략 리뷰 수가 N만개가 넘어가면 느려지는 걸로 보였다.

 

이걸 어떻게 풀까 고민하면서 일단 1. 캐싱 2. 인덱스 3. 쿼리튜닝 정도가 생각났다. 그런데 리뷰 수가 많은 거면 인기 상품이라는 의미라 리뷰가 얼마든지 더 달릴 수 있는 거고, 리뷰 프로세스가 존재해서 특정 상태의 리뷰들만 사용자에게 노출하다 보니 캐싱하기 어려워서 어째저째 쿼리를 다시 짜는 걸로 해결했다. (기존 쿼리에선 DISTINCT 때문에 임시 테이블을 만들고 있었다.)

 

그런데 이걸 다른 시니어 분에게 여쭤보자, 일단 이런 경우 캐싱이 가장 간단한 방법이라고 제안을 주셨다. 일단 이 기획에서 리뷰 수가 정확히 나오는 것이 중요한 것인지 여쭤보셨다. 나는 작업자가 아니기 때문에 잘 몰라서 이유는 따로 묻진 않았지만, 다시 생각해 보니 상품에 리뷰를 표현하는 이유 자체가 "이 상품에는 리뷰가 많아요" => "리뷰가 많은 상품이므로 다른 사람들이 좋아하는 상품이에요" => "이 상품은 사면 좋은 상품이에요"를 어필하는 수단이라는 생각이 들었다.

 

다시 시니어 분께선 아마 위와 같은 이유일텐데, 사용자가 보기에는 12,345만개든 +9,999든 둘 다 리뷰 수가 많아 보이기에는 마찬가지일 것 같다고 하셨다. 그런데 +9,999 이런 식으로 표현하면 캐싱할 수 있는데, 이 방법은 어떤지 제안을 주셨다.

 

이걸 듣고 많은 배움을 얻은 것 같다. 그래서 우리 앱을 살펴보니 생각보다 앱 내에서 COUNT를 내려주고 있는 경우가 많았다. 그래서 팀 내에 다음 실험으로는 +9,999로 바꿨을 때 지표에 큰 변화가 없는지 A/B 테스트 해보는 게 어떤지 제안 해봤는데 생각보다 괜찮은 제안 같았다.

 

+) 오늘 안건데, 트위치에서도 채팅 수가 많으면 +999 이렇게 나오는데 치지직에서는 1,352 이런 식으로 나온다고 한다. 오픈한지 얼마 안 된 서비스라 아직 문제를 안 겪어서 그런건가 싶다.