개발일지 - 15일차: 목표 랭킹 알고리즘 수정 및 오류 직면

어제 계획한 대로 튜터님께 내가 구상한 실시간 랭킹 알고리즘에 대해 어떤지 여쭈어봤다.

 

물어본 내용은 단순이 랭킹 조회 API에 redis를 사용하는게 맞는지, 아니면 RDB에 접근하는 방식으로 구현해도 되는지, 알고리즘에 문제는 없는지였다.

 

 

 

일단 redis를 사용하는 것은 좋은 방법이라고 하셨다. 

 

팀이 구상한 비즈니스 서비스에서 랭킹은 상당히 노출이 많이 되는 api다. 첫 페이지에 들어가도 존재하며, 실시간 랭킹인 만큼 일정 시간마다 같은 api를 호출함으로써 갱신도 해야 한다. 즉 서비스를 이용하는 인원이 많아질 수록 랭킹 조회 api 또한 사용량이 급격해질 것이다. 때문에 redis를 캐시처럼 이용하면 RDB에 직접 접근하지 않고 redis에 접근하여 서비스의 성능을 개선할 수 있을 것이다.

 

그렇다면 알고리즘은 어떨까?

 

결론부터 말하자면 그다지 좋은 알고리즘이 아니였다. 오히려 redis를 사용하고자 한 후 처음 생각했던 아이디어가 있었는데, 그 아이디어가 훨씬 좋은 알고리즘이였다.

 

내가 구상했던 알고리즘은 다음과 같다.

 

1. SortedSet 사용해서 각 post의 ID를 멤버로, 좋아요 수를 스코어로 사용하여 정렬된 세트에 저장

2. post의 좋아요 수가 변경될 때마다 Redis의 SortedSet에 있는 해당 post의 점수를 업데이트하여 실시간으로 랭킹 갱신

3. 사용자가 랭킹을 조회할 때, Redis에서 정렬된 세트의 상위 N개 항목을 즉시 가져와 빠르게 랭킹 정보를 제공

 

이 알고리즘의 문제는 redis를 사용하는 의미가 퇴색된다는 것이였다. RDB에 직접 쿼리문을 전송해 받아오는 것과 별로 다를게 없다는 것이다. redis는 결국 데이터의 읽고 쓰기가 빠른 것이 장점이므로 캐시처럼 사용되는 편이 도움이 된다고 한다.

 

하지만 위에서 내가 제시한 알고리즘은 redis를 캐시처럼 사용한다고는 말할 수 없다.

 

그렇다면 튜터님이 추천해 주신, 그리고 내가 처음 구상했던 아이디어에 대해 살펴보자.

 

1. 좋아요가 발생하면 RDB에서 likeCount를 증가시킨다.

2. 스케줄러를 이용해 일정 시간마다 RDB에서 좋아요 top10을 redis에 저장한다.

3. 랭킹을 조회하는 api의 로직은 오직 redis만 바라보기만 하면 된다.

 

이런 식으로 알고리즘을 구상하면 redis를 캐시처럼 사용할 수 있게 된다.

 

 

일단 알고리즘에 대한 자문도 받았고 실제 코드로 구현해보기로 했다.

 

하지만 오류 하나가 발견됐는데... 이 오류를 해결하는 과정은 내일 일지에서 풀어보도록 하겠다. 솔직히 아직 못풀었다...