[고민] 공감(좋아요) 기능 구현 방법

[EunjiShin]

💁‍♀️ 고민 사항

• 2차 MVP때 추가되는 '리뷰에 공감했어요(=좋아요)' 기능의 설계 및 구현 방법

👀 배경 설명

요구사항

• 유저는 리뷰에 좋아요를 남기거나, 좋아요를 취소할 수 있다.
  • 유저는 자신이 남긴 리뷰에는 좋아요를 누를 수 없다.
  • 유저는 동일 리뷰에 한 번만 공감할 수 있다.
• 유저는 자신이 받은 전체 좋아요 수를 확인할 수 있어야 한다.
• 리뷰를 좋아요 (공감) 순으로 정렬할 수 있어야 한다.

고려사항

• 좋아요 횟수가 카운트 되는 것이 화면에 실시간으로 보여야 해요.
• 따라서, 리뷰 공감순 정렬도 새로고침을 할 때마다 갱신되어야 해요.
• 현재는 없지만, '내가 공감한 리뷰 모아보기' 기능이 생길 수도 있어요.

✅ 참고 사항

• 코멘트로 생각한 구현 방법을 하나씩 추가할게요! 하나씩 확인하고 의견 남겨주세요

[EunjiShin]

0. 전제

✨ review_likes 테이블 설계

요구사항에 따라, 유저가 어떤 리뷰에 공감했는지 기록을 남겨야 해요. 따라서 review_likes 테이블을 새롭게 만들고 관리하는 건 필수라고 생각되어서 공통 전제로 깔고 시작할게요.

필드명	자료형	제약사항	Description
id	BIGINT	PK, AI	primary key
review_id	BIGINT	NN	review pk
user_id	BIGINT	NN	user pk

(created_at, updated_at 생략 & 삭제=좋아요 취소 이므로 soft delete 적용할 필요 없음)

✨ 좋아요 API 설계 관련

1. API 하나로 공감 / 공감 취소를 모두 처리하는 방법 (이전에 좋아요 한 리뷰라면 좋아요 취소로 동작)
2. 공감 API와 공감 취소 API를 각각 관리하는 방법

둘 중 어떤 방식으로 구현할 지는 AOS와의 논의가 필요해요. 일단 1번 방법을 고려하고 있어요.

[EunjiShin]

1. MySQL만 활용하여 구현하기

✨ 설명

review_likes 테이블만을 활용하여 기능을 구현해요.

좋아요 프로세스

1. 유저가 리뷰에 좋아요를 남긴다 (API call)
2. review_likes 테이블에 새로운 레코드를 insert 한다.

리뷰 정렬 프로세스

left join 또는 서브 쿼리를 활용, 블록에 포함된 리뷰를 조회할 때 review_likes 테이블에서 count 연산을 수행하고 이를 이용해 리뷰를 정렬한다.

✨ 장점

• 외부 infra 스택 없이 구현 가능
• 서로 다른 유저가 같은 review_likes 레코드에 접근할 일이 없기 때문에 동시성 이슈에서 비교적 자유로움.

✨ 단점

• 계산 로직 처리 중 부하 발생
  • 요청이 들어올 때마다 review별 공감 수를 count 해야 하므로, 집계 연산이 비싸지고 latency가 길어짐.
  • 리뷰 공감 수가 변하지 않았다면 count 연산이 불필요하게 중복됨.
  • 유저 수, 리뷰 수, 좋아요 수가 증가할 수록 비용이 계속 커질 것
• 쿼리 복잡도 증가
  • 지금 리뷰 조회하는 쿼리를 보면 이미 꽤 복잡함..!
  • 여기에 join이나 sub query를 더 추가하는게 좋은 선택인지 잘 모르겠음 🤔

[EunjiShin]

2. MySQL만 활용 + reviews 테이블에서 공감 수 직접 관리

✨ 설명

review_likes 테이블에서 유저 좋아요 관련 작업을 수행하고, reviews 테이블에 likes_count 필드를 추가해 공감순 정렬 구현

좋아요 프로세스

1. 유저가 리뷰에 좋아요를 남긴다 (API call)
2. review_likes 테이블에 새로운 레코드를 insert 한다.
3. reviews.likes_count 필드를 증가시킨다.

리뷰 정렬 프로세스

reviews의 likes_count 필드를 이용해 order by 해주면 끝~

✨ 장점

• 외부 infra 스택 없이 구현 가능2
• 리뷰 테이블에 좋아요 수가 이미 존재하므로, 불필요한 집계 연산이 필요 없음 (= 방법 1에서 성능 개선한 버전)

✨ 단점

• reviews.likes_count의 증감 과정에서 동시성 이슈 발생 가능.
  • 이때 데이터 정합성 문제가 발생할 수 있으니 batch나 스케줄러 등으로 대사작업을 구현해야 할 지도..? 그럼 외부 인프라가 필요할지도..?
  • 락 거는 과정에서 성능 저하 발생 가능 (유의미한 성능 저하인지는 확인 필요)

[EunjiShin]

3. 2번 방법 + redis 분산락

✨ 설명

2번 방법과 전부 동일한데, 동시성 이슈 보완을 위해 어플리케이션 락인 분산락을 적용한다.

좋아요 프로세스

1. 유저가 리뷰에 좋아요를 남긴다 (API call)
2. redis를 활용해 락을 획득한다.
3. review_likes 테이블에 새로운 레코드를 insert 한다.
4. reviews.likes_count 필드를 증가시킨다.
5. 락을 반환한다.

리뷰 정렬 프로세스

reviews의 likes_count 필드를 이용해 order by 해주면 끝~22

✨ 장점

• redis를 활용하므로 DB락인 비관적락 등에 비해 성능이 좋다.
• 서버나 DB 등이 분산될 상황을 가정하면 (스케일아웃이나...primary-secondary DB라던가..)유리한 방법이다.

✨ 단점

• redis를 추가로 사용해야 하고, 분산락 구현이 필요하다.
• 정말정말 동시성에 예민하게 처리할거라면 분산락과 비관적락을 동시에 사용하는 것도 고려해야 한다. (토스가 글케 한다고 합니다)
  • 하지만 우리에게 고려사항일지는..?

[EunjiShin]

4. mysql + redis + spring batch

✨ 설명

redis는 싱글스레드라 원자성이 보장되므로, 어플리케이션에서 동시성 보장하지말고 redis에서 공감수를 관리하자.

좋아요 프로세스

1. 유저가 리뷰에 좋아요를 남긴다 (API call)
2. review_likes 테이블에 새로운 레코드를 insert 한다.
3. redis에 리뷰별 좋아요 수를 update 한다.
4. 하루 단위로 batch를 돌면서 redis에 저장된 리뷰 공감수를 mysql에 반영한다.

리뷰 정렬 프로세스

• redis에 저장된 좋아요를 활용할 수 있다면
  • mysql에서 리뷰 데이터 조회하기
  • redis에서 리뷰별 공감수 조회하기
  • 둘을 활용하여 리뷰 정렬하기
• 복합 쿼리 등이 필요해서 redis에 저장된 좋아요를 활용할 수 없다면
  • reviews.like_count를 활용해 정렬하기
  • 단, 이 경우 batch가 돌기 전에는 실시간 좋아요 수가 반영 안되었을 가능성 있음

✨ 장점

• 비교적 동시성 이슈에서 자유롭다
• 좋아요 수와 관련된 작업(count라던지, update라던지..)를 대부분 redis에서 처리하므로 DB 부하가 줄어든다.

✨ 단점

• redis와 batch를 추가로 사용해야 한다.
  • batch 없이 redis만 이용하면 안되나요?
  • redis에 좋아요 수를 영구적으로 (TTL 무한) 저장할거라면.... 근데 한번도 이렇게 해본적이 없어서 안전한지 모르겠음! redis도 디스크에 스냅샷 남길 수 있다고 듣긴 했는데 굳이??
  • 하지만 한방쿼리로 해결해야 하는 등의 상황이 있다면 구현 복잡해질듯
    • 리뷰 데이터랑 리뷰 좋아요 데이터가 서로 다른 저장소에 있으니 관리도 복잡해질듯22
• 말로 표현이 잘 안되는데... 좀 많이 굳이?? 싶다
  • 아예 redis만 쓰는 것도 아니고, 좋아요 / 정렬 둘 다 mysql 접근이 필수적이라 딱히 성능적으로 좋을 것 같지도 않음
  • 기능 스펙에 비해 너무 오버엔지니어링이 아닌지? 배치까지 필요한 작업이 맞나 이게 🤔 관리 포인트가 갑자기 수수수수퍼노바

[EunjiShin]

~~ 인 마이 어피니언 ~~

SPOT 서비스의 트래픽과 개발 리소스를 고려했을 때, 3번 방법이 제일 적합할 것 같음! 2번 방법도 충분히 간단하고 효율적이지만, 아키텍처 확장이나 공부 목적(사이드플젝이니까ㅎ.ㅎ)으로 분산락을 적용해봐도 문제 없는 상황이라고 판단했어~ (redisson 라이브러리 사용하면 구현 난이도가 그렇게 높지 않기도 하고)

우리가 mysql 8.0 버전을 사용하니 Materialized view를 이용하거나, 메세지큐를 활용해 비동기 방식으로 구현하거나... 구현 방법은 더 여러가지가 있을 수 있겠으나, 그쯤되면 더 이상 기능 구현이 주가 아닐 것 같아서 😅 일단은 위의 저 방법들만 고려했다!

이제 @pminsung12 @wjdwnsdnjs13 의견 받고, 이견 없으면 작업 고고할게잉

[wjdwnsdnjs13]

내가 좋아요 구현할 때엔 1, 2번 밖에 안 해보긴 했는데 확실히 2번은 동시성 이슈가 있긴 하더라구

2번 방법도 충분히 간단하고 효율적이지만, 아키텍처 확장이나 공부 목적(사이드플젝이니까ㅎ.ㅎ)으로 분산락을 적용해봐도 문제 없는 상황이라고 판단했어~ (redisson 라이브러리 사용하면 구현 난이도가 그렇게 높지 않기도 하고)

이런 거라면 3번 나도 동의!

근데, 궁금한 거 한 가지는 리뷰가 삭제되었을 때엔 좋아요는 어떻게 처리할 예정이야?? soft 딜리트라 좋아요는 건들지 않고 놔두는 게 나으려나??

[pminsung12]

와 갓은지... 정리가 진짜 👍 👍 👍 👍 👍 👍

나는 2번, 3번을 고민을 좀 해봤는데 우리 지금 앱의 규모나 지출 등을 고려했을 때 2번이 제일 나은 것 같더라고.

그런데 확장성과 공부를 위해서~ 나도 3번으로 진행하면 제일 좋을 것 같아~. (비용만 괜찮다면..!)

p.s.) spring batch에 대해서 잘 몰라서 질문하는데, 4번 방법은 그러면 redis를 통해서 캐시로 저장하다가 crontab 같이 일정한 주기로 작동하는 스케줄러를 통해서 한번에 업데이트 한다는거지?

[EunjiShin]

@wjdwnsdnjs13

근데, 궁금한 거 한 가지는 리뷰가 삭제되었을 때엔 좋아요는 어떻게 처리할 예정이야??

이거는 이슈내용이랑은 무관한 주제인 것 같아서.. 따로 스레드 팔게! 소프트딜리트 목적이 백업이냐, 내부 데이터 수집 용도냐에 따라 달라질 것 같으니 디자인 파트도 확인해보아야 할 것 같아~

• 스레드 링크 추가) LINK

[EunjiShin]

@pminsung12

(비용만 괜찮다면..!)

얍 그래서 redis를 어떻게 세팅할 것인지 한번 찾아보고, 예상 견적 짜서 작업 시작 전에 먼저 공유할게! 만약 금액이 에바라면 2번 방안으로 유턴하면 될듯~

p.s.)

비슷해~ 배치 작업은 일괄적으로 대량의 작업을 처리하는 방식이고, spring batch는 그런 배치 작업을 스프링 프레임워크에서 제공해주는거야. @Scheduler 대신 spring batch를 굳이 쓰는 이유는, spring batch에 이것저것 이점이 있어서! (스케줄러는 정해진 시간에 자동으로 동작하고 개발자가 직접 실행할 수 없지만, 배치는 개발자가 컨트롤 가능 & 실패한 작업이 있다면 그 작업부터 재시작 가능 등등..)

[EunjiShin]

aws elastiCache (redis oss)를 cache.t2micro로 사용할 경우 750시간 free-tier 사용 가능함을 확인 논클러스터 모드를 이용, 단일 노드로 띄우면 충분히 비용 문제 없이 활용 가능할 것으로 판단

=> 3번 방법으로 진행 확정 땅땅! @pminsung12 @wjdwnsdnjs13

[EunjiShin]

((( 좋아요 수만 관리하는 테이블 따로 관리하는 방법, redis의 pub/sub 이용해서 batch 대신 쓰는 방법, 이벤트 활용하는 방법 등등... 다양하게 고민해보자 )))