[1권 - 11장] 뉴스 피드 시스템 설계

[KimH4nKyul]

1. 첫 한 시간에 2~3명씩 짝지어 조를 이루고, 함께 책을 읽어 나가며 질문 목록을 만들어 주세요. (즉석에서 답변을 해도 상관없으나 반드시 여기에 질문을 생성해 주세요.)
2. 마지막 한 시간에 모두가 이 곳에 준비된 질문에 대해 답변하며 토론하는 시간을 갖고 마무리 합니다.

[yonghanyoon]

각 모델의 장점만을 가져오기 위해 푸시 모델과 풀 모델을 같이 사용한다면 어떻게 구현할까?

[yonghanyoon]

-> 일반 사용자 / 인기 사용자를 나눔
일정 팔로워 이상이 되면 사용자의 상태를 일반 -> 인기로 변경?
애플리케이션 코드 레벨에서 상태별 분기 처리?

[yonghanyoon]

푸시(Push) 모델
새로운 컨텐츠(게시물)가 생성되면 바로 구독자(사용자)에게 전파하는 방식
예: 페이스북, 인스타그램 (친구나 팔로우한 사람의 새 게시물을 피드에 바로 반영)
장점:
빠른 피드 제공 (새로운 콘텐츠가 즉시 반영됨)
서버 부하 감소 (매번 DB 조회 없이 캐시 활용 가능)
단점:
인기 유저(연예인, 인플루언서)의 게시물이 많을 경우, 저장 공간 부담 증가
불필요한 데이터까지 미리 저장할 가능성이 있음

풀(Pull) 모델
사용자가 피드를 요청할 때 DB에서 최신 데이터를 조회하는 방식
예: 트위터, 유튜브 (사용자가 새로고침하면 최신 게시물을 가져옴)
장점:
저장 공간 절약 (사용자가 요청할 때만 데이터 조회)
실시간성이 높음 (항상 최신 데이터 반영 가능)
단점:
매번 DB 조회가 필요해 서버 부하 증가
요청 시점에 따라 응답 속도가 달라질 수 있음

[yonghanyoon]

Timestamp 기준으로 피드 노출
-> 인스타그램의 경우 최근 피드가 없을 경우 광고나 랜덤 피드 노출
-> 피드를 모두 확인한 경우 "최근 게시물을 모두 확인하였습니다." 문구 노출 후 광고나 랜덤 피드 노출

[KimH4nKyul]

추가질문) 갑자기 구독자 수가 늘어났을 때 처리 방안
-> 용한님 피드

[cruellaDev]

인스타그램 팔로잉 0명 상태에서의 실제 메커니즘

• 내 팔로우 계정이 없으니 푸시(팬아웃) 방식으로 받을 게시물이 없음.
• 대신, 인스타그램 내부의 추천 엔진(Explore 탭용 ML 모델 등)이 사용자 나이/위치/앱 사용 이력 등을 바탕으로 “선호할 만한 게시물”을 선별하여,
  해당 추천 게시물 리스트를 DB/검색 인덱스에서 Pull 해와서 표시합니다.
• 사용자에게는 마치 “디폴트 피드”처럼 보여지지만, 내부적으로는 추천 모델이 뽑아온 게시물을 조회해 오는 Pull 작업이라고 볼 수 있습니다.

[hyojin202406]

그래프 데이터 베이스, Rate Limiting 활용 사례

[hyojin202406]

인터셉터, 필터에서 TokenBucket 사용

[hyojin202406]

Q. 인플루언서는 친구가 많은데 모두 가져오나?

[hyojin202406]

• 읽기 시점 팬아웃 사용할경우
  • 포스팅 시 뉴스 피드를 갱신하지 않고,
  • 팔로워가 뉴스 피드를 조회할 때 동적으로 생성

그렇다고 모든 데이터를 가져오는 건 아니고
사용자 정보 캐시에서 친구들의 정보를 가져오지만, 사용자 설정에 따라 일부를 걸러낼 거라 판단함

[KimH4nKyul]

캐시 구조에 인플루언서를 따로 관리하는 건 어떨까요?
문제는 캐시 구조 내에서 인플루언서가 핫키가 되버림? -> 캐시에서도 핫키 문제가 적용되는걸까?

[KimH4nKyul]

인플루언서인지 알빠노 -> 피드 조회 수 제한을 걸어버린다.

[hyojin202406]

그림 11-4에서 캐시와 데이터베이스 이미지 질문

[KimH4nKyul]

책 특성상 모든 건 분산되어 있다고 가정하는 거 같아요.

[cheondongmin96]

LinkedIn의 하이브리드 팬아웃 전략

• 일반 사용자 → 쓰기 시점 팬아웃
• 인플루언서 → 읽기 시점 팬아웃

---

• 팔로워 10만명 이상 → 읽기 시점
• 팔로워 10만명 미만 → 쓰기 시점
• 게시물 인기도가 높아지면 → 쓰기 시점으로 전환

---

• 인기 게시물은 캐시에 적극적으로 저장
• 머신러닝으로 사용자 관심사 기반 필터링
• 비활성 사용자의 피드는 캐시에서 제거

---

참고...

[KimH4nKyul]

• https://f-lab.kr/insight/efficient-newsfeed-implementation-20241005

[KimH4nKyul]

• 실무에서 확인한 FAN-OUT과 대규모 트레픽에서의 FAN-OUT
  

[KimH4nKyul]

거의 모든 고려할 수 있는 경우에서 캐시 미스/스탬피드가 발생할 경우에는 어떻게 대처해야 할까요?

[yonghanyoon]

팀장님 도와줘 응애

[Cheondongmin]

이땐 서버 다시 뜰때까지
운영팀(사용자경험팀) 이 무릎꿇고 싹싹빌어야지 ㄹㅇㅋㅋ

[yonghanyoon]

그동안 저희 서비스를 이용해주셔서 감사했습니다.

[KimH4nKyul]

-> 애초에 설계가 잘못되었다. 라고 생각 @hyojin202406

[KimH4nKyul]

• 복구 프로세스를 정립할 것
• 어느정도 준비 되는데 러닝 타임을 고려해야 하지만 (서킷 브레이커 + 쿠버네티스 Istio) <- 잘 모르겠는데 이런게 있다? @yw7148

[yw7148]

캐시 사용시 고려할 점

1. 캐시가 죽었다가 살아날 때 DB transaction 이 급격하게 늘어나서 DB도 같이 죽을 수 있다.
2. 점검이 끝나는 시점 등 캐시가 비어있을 때도 DB에 Transaction이 늘어날 수 있다.

해결 방법

1. rate limit

• 점검이나 서비스를 오픈할 때 사용자 별로 오픈 시점을 다르게 설정한다.
• DB 접속에 대해 rate limit을 건다

2. 캐시가 죽지 않도록 pod 개수를 늘린다

[yonghanyoon]

일반 / 인기 사용자를 나누어서 분기처리를 한다면
유튜브의 경우 구독자 수가 적은 일반 사용자가 갑자기 알고리즘을 타고 한 번에 구독자가 인기 기준을 넘어가는 경우에 어떤 문제가 발생하며
발생하지 않는다면 어떤식으로 처리했을까?

[Cheondongmin]

조회수 급증이 감지가 된다면,
기존 팬아웃된 캐싱을 정리 후
인기 컨텐츠용 캐시로 이동하지 않을까?...

(인기컨텐츠용, 일반용 캐시서버가 따로 존재해서..)

[Cheondongmin]

생각해보니 일반사용자랑 인플루언서(인기사용자) 파란딱지 등

아예 분리를 해서 팔로워/팔로잉 수를 제한걸어버리는 경우도 있더라구요

[cruellaDev]

Q. 그래프 데이터베이스에서 자동으로 일반인에서 인플루언서로 분류할 수 있는가?

[cruellaDev]

그래프 데이터베이스에서는 사용자(노드)와 관계(엣지)를 기반으로 중앙성(centrality) 분석이나 PageRank 같은 그래프 알고리즘을 적용해, 특정 노드가 네트워크 상에서 얼마나 큰 영향력을 갖는지 자동 분류할 수 있습니다. 예를 들어, 팔로워 수가 일정 기준을 넘거나, (친구/팔로우 그래프에서) 연결 지표가 일정 임계값을 넘으면 “인플루언서”로 태그를 달아줄 수 있습니다.

1. 노드(사용자)의 연결 관계

• “A가 B를 팔로우”한다는 엣지를 명시적으로 표현할 수 있고, 노드(사용자)의 차수(degree)나 팔로워 수를 쉽게 집계할 수 있음.

2. 그래프 알고리즘

• PageRank, 중앙성(centrality), 각종 랭킹 알고리즘으로 노드(사용자)의 네트워크 영향력을 수치화할 수 있음.
  예) Neo4j Graph Data Science 라이브러리, JanusGraph + Gremlin, Amazon Neptune + SPARQL 등에서 그래프 알고리즘을 돌려볼 수 있음.

3. 자동 분류 로직

• 특정 Threshold(예: 팔로워/친구 수, PageRank 점수) 이상이면 “Influencer”로 업데이트하거나,
  머신러닝 기반 모델(노드2vec, GraphSAGE 등)을 통해 노드 벡터(Embedding) 기반 분류를 수행해도 됨.

[cruellaDev]

• 모든 사람과 그 사람의 친구·팔로워 관계를 그래프 형태로 저장한다.
  • 사람마다 팔로워 숫자 체크
  • 연결 지표(PageRank 같은 알고리즘)를 돌려서 어떠한 사람의 노드가 네트워크 중심에 있는지 체크
• 위 사항에 해당 시 인플루언서로 분류

[KimH4nKyul]

추가질문) 캐시 구조에 인플루언서를 따로 관리하는 건 어떨까요?
문제는 캐시 구조 내에서 인플루언서가 핫키가 되버림? -> 캐세에서도 핫키 문제가 적용되는걸까?

[KimH4nKyul]

• 데이터 분포 특성을 먼저 파악해 보면? -> 인플루언서의 피드 자체를 모두 저장할 필요는 없음 (캐시에!), 유저별로 보이는 피드도 제한(최신 몇건만 보인다 등)을 둘 수 있음. 이 경우에 과연 핫키 문제가 발생할 까?

[KimH4nKyul]

[짤막 상식]
팔로워 -> 나를 팔로우 하는 사람들임
팔로잉 -> 내가 팔로우 하는 사람들임

[cruellaDev]

축하합니다!🎉