레디스 조회 기록 저장 방법

[songsunkook]

관련 이슈

• GET /articles/hot/list #105 (인기 게시글 조회)

고민사항

조회 정보 임시 저장을 위해 레디스를 사용해보려고 하는데 고민을 혼자서 너무 오래 붙잡고 있는 것 같아 팀원분들의 조언을 받아보고 싶습니다.

인기 게시글 판단 기준을 조회 정보가 많이 남아있는 순서대로 하려고 합니다. 조회 정보는 간단한 정보이고 타 정보와 연관이 없기 때문에 레디스를 통해 빠른 I/O를 추구하고자 합니다.

기존 리프레시 토큰을 저장하는 방법처럼 @RedisHash를 적용한 도메인 클래스를 작성해볼까 하다가 랭킹 구현에 적절한 Sorted Set(ZSet) 자료구조를 발견했습니다. 해당 자료구조는 KEY:VALUE(inclue SCORE) 구조로 score 값을 통해 자동으로 정렬 상태를 유지합니다. 그렇기에 조회수가 높은 게시글부터 빠르게 조회하는 데 가장 적절한 자료구조라고 판단했습니다.

하지만 해당 자료구조의 경우 유효기간(TTL) 설정을 지원하지 않습니다. 따라서 여러 방안을 모색해 보았고, 최종적으로 다음과 같은 방안들을 구상했습니다.

1. Sorted Set 자료구조를 사용한다. 단, 유효기간을 설정할 별도의 방법을 적용한다. (참고 자료)
   1. Sorted Set에는 게시글 ID와 조회수(score)를 두고, 별도의 자료구조에 게시글 ID와 만료시간을 저장한다. 이후 만료시간이 지나면 Sorted Set에서 해당 게시글 score를 -1한다.
      • 2개의 자료구조를 사용하기 때문에 메모리 공간이 상대적으로 많이 필요합니다.
      • 그냥 @RedisHash 형태로 작성하는 것이 더 나아보이기도 합니다.
   2. Sorted Set에 데이터를 저장할 때 게시글 ID, 조회수와 함께 만료시간을 끼워넣는다. 이후 문자열을 분리하여 만료시간이 지난 경우 score를 -1한다.
      • 구현 방법을 잘 모르겠습니다.
      • 만료시간을 하나하나 점검해야 한다면 Sorted Set으로서의 가치가 있을지 고민됩니다.
2. 기존 리프레시 토큰 저장 방법과 같이 @RedisHash 형태로 구현한다.
   • RedisTemplate를 사용하지 않고 엔티티 형태의 로직을 일관적으로 유지할 수 있습니다.
   • ORDER BY 방법으로 정렬하게 될 것 같은데, 시간복잡도가 높아질 우려가 됩니다.

저는 며칠 간 찾아보면서 1-2 혹은 2번 방법으로 눈길이 가는데, 혹시 여러분들은 어떻게 생각하시는지 궁금합니다!

[daheeParkk]

저는 1-2번 방법이 좋아 보입니다!
Sorted Set을 안 쓴다고 해도 어차피 점수 순으로 정렬을 해야 하기 때문에 자동으로 정렬해 주는 Sorted Set을 사용하는 게 더 좋을 것 같다는 생각이 듭니다.
1-1번과 1-2번이 둘 다 된다면 1-2번이 메모리 공간을 덜 낭비하는 방식이라고 생각이 되기 때문에 1-2번이 좋을 것 같습니다!

[songsunkook]

2번 방법의 경우 만료시간 지정 외에도 정렬을 해야한다는 패널티가 있었네요!
확실히 Sorted Set을 사용하는 방법이 메리트있어 보입니다.
소중한 의견 내주셔서 감사합니다. 😊

[Choi-JJunho]

Sorted Set이라는 자료구조가 있군요! 새로운 내용 배워갑니다 👍

생각

몇가지 생각이 들어 정리해서 공유드립니다.

제안해준 방식 내에서

1-1 번의 경우 현재 무중단배포 환경이 아닐 뿐더러 서버를 다시 배포할 때 마다(WAS가 다시뜰 때 마다) 인기 게시글이 초기화될것 같아요 😅
1-2 번의 경우 WAS와 별개의 환경으로 동작하여 크게 문제는 없을 것 같다는 생각이 드는군요

혹시 Redis에 articleId를 Key로, score, TTL, 기타 정보 등을 value로 갖는 HashSet 구조를 가져간뒤 이를 조회한 결과물을 SortedSet에 초기화하여 조회하는 방법은 안되는걸까요? (제가 Sorted Set에 대한 이해가 부족한걸 수도 있어 한번 여쭤봅니당)

ex)

var hotArticles = hotArticleRepository.findAll();
new TreeSet(hotArticles);
...

궁금증

다만 한가지 궁금한 점이 생겼어요~!

인기 게시글 판단 기준을 조회 정보가 많이 남아있는 순서대로 하려고 합니다.

해당 문구에서 TTL을 사용하고자 하는 목적이 보이지 않는데 인기 게시글이 조회수 많은 순서와 어떤 차이점이 있나요?
일주일마다 최다 조회 게시물을 초기화하고 싶다는 니즈가 맞을까요? (최근 일주일간 조회수 통계로 인기게시글 판단.)

만약 아니라면 RDB에 있는 article 중 최근 10개의 게시글을 조회하고 hit 기준으로 정렬하는게 낫지 않나 싶네요.

ex)

// sudo code라서 named Query 문법은 안맞을 수 있습니다.
List<Article> articles = articleRepository.findAllTop10ByOrderByCreatedAt();
getOrderedHotArticles(articles)
...

Sorted Set

Sorted Set의 만료시간 설정은 뭔가 어렵군요.. java Level에서 TTL 설정이나 Event Publishing 혹은 pub/sub 구조와 expired 등등의 키워드로부터 관련된 방안을 얻을 수 있을까 싶지만 아직 미지의 영역이기도 하고 그렇게까지 했을 때 되려 redis에서 불러오는 것 보다 효율적일지는 모르겠네요.

[songsunkook]

답변

혹시 Redis에 articleId를 Key로, score, TTL, 기타 정보 등을 value로 갖는 HashSet 구조를 가져간뒤 이를 조회한 결과물을 SortedSet에 초기화하여 조회하는 방법은 안되는걸까요?

말씀해주신 방법이 어떤 구조인지 정확하게 이해하지 못했습니다... 2번 방법으로 redis에 저장 후 조회 시에는 SortedSet에 한 번 새로 저장한 후 그 내용을 다시 가져오는 방향으로 이해했는데, 저도 redis를 잘 모르다 보니 redis에서 시간복잡도나 메모리상으로 효율적일지 잘 모르겠습니다.

인기 게시글 판단 기준을 조회 정보가 많이 남아있는 순서대로 하려고 합니다.

해당 문구에서 TTL을 사용하고자 하는 목적이 보이지 않는데 인기 게시글이 조회수 많은 순서와 어떤 차이점이 있나요?

제가 생각했던 로직은 다음과 같습니다.

1. 게시글 조회수 증가 시 레디스 Sorted Set에 조회 정보를 기록한다. <Sorted Set KEY> : <VALUE> article-id : <SCORE> hit
   1. 해당 게시글 조회 정보가 이미 존재하면 hit를 1 증가시킨다.
   2. 만료 기간을 각 hit별로 할당한다.
      • 제가 고민할 때 이 부분에 대해 오해하고 있었습니다.
      • 각 hit별로 별도의 데이터가 저장될 것이라고 생각하고 있었는데 실제 로직은 하나의 score마다 하나의 value만 존재합니다.
      • 1-2 방법으로 value에 여러 만료시간을 기입하고 일정 시각마다 만료 여부를 파악하면 구현 가능해 보이긴 합니다. (1-1도 원래대로 가능)
2. 인기 게시글 조회 시 Sorted Set에서 (score가 높은) 순서대로 10개를 반환한다.
3. 일정 시간마다 cron을 통해 만료 시간을 점검한다. (레디스에서 자동으로 만료가 안될 경우, 즉 Sorted Set을 사용할 경우)
   • 만료 시간이 지난 hit는 제거한다.
   • 다만 본문의 내용처럼 만료시간을 하나하나 점검해야 한다면 Sorted Set으로서의 가치가 있을지 고민됩니다.

위의 로직을 수행하면 인기 게시글 조회 시 최근 특정 기간동안 가장 많은 조회를 기록한 게시글을 순서대로 불러올 수 있습니다.

일주일마다 최다 조회 게시물을 초기화하고 싶다는 니즈가 맞을까요? (최근 일주일간 조회수 통계로 인기게시글 판단.)

아닙니다. 제 목적은 게시글 조회 로그를 "초기화"하지 않고 유기적으로 순위가 변동되는 것입니다. 일정 기간마다 전부 초기화하고자 한다면 만료시간 처리 없이 cron을 통해 매주 조회 로그를 초기화하면 해결할 수 있습니다. (실제로 에타에서 "어제 가장 인기많은 게시글" 기능은 조회수 기준이 매일 초기화되는 로직으로 추측됩니다.)

만약 아니라면 RDB에 있는 article 중 최근 10개의 게시글을 조회하고 hit 기준으로 정렬하는게 낫지 않나 싶네요.

동의합니다. 가장 쉽게 구현할 수 있는 방법이 RDB에서 특정 기간 혹은 특정 개수의 접속 로그를 조회하여 hit로 정렬하는 것입니다.
하지만 위 방법의 경우 아래와 같은 걱정이 있어 배제해둔 상황입니다. (인기가 많은 서비스라고 가정하고 봐주세요!)

1. 인기 게시글 조회에 대해 매 요청마다 아래 과정을 수행하는 것이 비효율적으로 보입니다.
   1. RDB에 접근한다.
   2. 조회 로그를 일부 불러온다. (WHERE)
   3. hit를 기준으로 정렬한다. (ORDER BY)
   4. 연산 결과를 반환한다.
2. 특정 개수의 접속 로그를 조회하는 것은 부정확할 수 있습니다.
   • 예를 들어, 최근 100개의 게시글을 읽도록 구현했는데 1분에 100개의 게시글이 작성되는 상황이 된다면 인기 게시글 조회 API는 최근 1분에 대해서만 인기 순위를 매길 수 있게 됩니다.
3. 특정 기간 동안의 접속 로그를 전부 조회 및 정렬하는 것은 서버에 부하를 줄 수 있습니다.
   • 위의 예처럼 1분에 100개의 글이 작성될 때 일주일 간 조회수를 기반으로 판단한다면 약 100만 개의 로그를 전부 조회 및 정렬하는 것이 됩니다.
4. (이 부분은 Redis에도 해당됩니다.) 최적화를 위해 요청마다 매 번 실제로 조회하는 것이 아니라 cron으로 특정 기간에 한 번씩 조회를 한다면(ex. 매일 새벽 4시, 가장 트래픽이 적은 시간대), 해당 API는 실시간 인기 게시글이라고 보기는 어렵습니다. 이 경우 1시간 전에 조회수 1000 게시글이 발생하더라도 다음날이 되서야 반영되는 상황이 나타날 수 있습니다.

결론

생각하면 할수록 점점 꼬이는 것 같아서 제가 너무 어렵게 생각했나 싶기도 합니다. 사실 쉽게 구현하려면 말씀해주신 것처럼 RDB를 직접 거치거나 @RedisHash 방식으로 redis에 접근한 후 애플리케이션 단에서 정렬 과정을 수행할 수도 있습니다. 그리고 1-2 방법이 그나마 SortedSet을 사용하는 실용적인 방안으로 보이지만 Redis에 대해 추가적인 학습이 많이 필요해 보입니다(관련 자료)... 기준을 낮추고 어느 정도 타협을 봐야 하나 하는 고민도 있습니다...

정리

• 1-1: 직관적이고 단조롭다. 공간 복잡도가 비교적 높다.
• 1-2: 시간 복잡도가 높아질 우려가 있다(모든 만료시간을 일일이 점검해야 한다.). 직관적이지 못하다.
• 2: 쉽고 직관적이다. 시간 복잡도가 높아질 우려가 있다(만료는 자동으로 되나 조회 및 정렬이 부담스러울 수 있다.).

[Choi-JJunho]

사용자가 1억명이라면? 이라는 생각은 정말 좋은 학습 원동력이 되는 것 같습니다 👍

실시간이라는 개념이 정말 어려운 것 같아요
진짜 실시간을 원한다면 hit(조회수 증가)가 동시에 이뤄지는 순간도 있을거고 1초마다 인기 게시글 순위가 달라지고 마치 자동차 경주보다 빠르게 순위가 변경되는 실시간 인기 게시물 서비스가 될 것 같네요!

조회수에 TTL을 적용한다는 발상도 정말 좋은 발상인 것 같아요. 나중에 해당 생각이 이벤트 발행으로 이어진다면 조금 더 명확한 인사이트를 얻을 수 있지 않을까 싶네요
하지만 여기서 지금 말씀드리고싶은건 현실적으로 실시간 인기 게시물 기능이 필요한가? 입니다.
서비스 적으로 실시간 인기 게시물을 구현할 만큼의 트래픽이 발생하지 않을 뿐더러 들이는 공수 대비 트래픽을 받지 못하는 경우 그것대로 아쉬울 것 같다고 생각되네요 😅

따라서 현재 제안드리는 바는 2번으로 서비스에 적용해본 뒤 bench mark를 확인하여 I/O 속도가 정말 우려한 만큼 유의미한 성능 이슈가 발생하는지 확인해보는 것을 추천드려봅니다.

Redis에서 읽고, 정렬하는게 과연 유의미할 정도의 Timeout을 내는가? 를 직접 두눈으로 확인해보시죠!
원한다면 Stage 서버에 데이터 1억건을 넣고 RDB로 조회해보는 경험도 해보는게 재밌을 것 같네요

[songsunkook]

지금으로써는 제안해주신 방향이 최선으로 보이네요. 간단하게 만들어보고 "성능 확인 후 개선"이라는 방법은 미처 생각 못했는데 굉장히 마음에 듭니다!

2번 방향으로 우선 구성해보고 로컬에서 직접 벤치마크 해보겠습니다! 그리고 큰 이슈가 발생하지 않는다면 그대로 진행하겠습니다. 코인에서 이 API는 중요도가 그리 크지 않으니까요.

그리고 스테이지에 1억건 넣는 건 조금.. 무섭네요...

소중한 답변 감사드립니다!

[Choi-JJunho]

선권님을 위해서라면 10억건도 넣어드리겠습니다...