[강의] 대규모 시스템 설계 내용 정리 (4)

---

🗓️ 09/29 (월)

📌 게시판 서비스의 특성

• 읽기 트래픽이 쓰기 트래픽보다 압도적으로 많음
  
• 단순히 게시글 데이터만이 아니라, 좋아요 수 / 댓글 수 / 조회 수 등 여러 데이터를 함께 보여줘야 함.
  

⚙️ 문제점

• 데이터가 분산되어 있는 환경에서 Client가 여러 서비스를 거쳐야 함
  
• ArticleService는 게시글을 읽기 위해 여러 서비스(댓글, 좋아요, 조회수 등)를 의존함.
  
• 반대로 각 서비스들도 데이터 유효성을 위해 ArticleService를 의존 → 양방향 의존 발생.
  

💡 해결 방안: Article Read Service

• 읽기 전용 서비스를 분리하여 단방향 의존으로 개선.
  
• 그러나 여전히 다음 문제들이 남음:
  • 여러 서비스/DB에 분산된 데이터를 조합해야 함.
    
  • 네트워크 비용 증가.
    
  • 서비스 간 부하 전파.
    
  • 조인/질의 비용 증가.

👉 이러한 문제는 CQRS 패턴으로 해결 가능.

---

⚙️ CQRS (Command Query Responsibility Segregation)

• 명령(Command) 과 조회(Query) 책임을 분리하는 패턴.
  
• 데이터의 변경과 조회를 다른 경로로 수행한다.
  

📐 CQRS 적용 설계

1. Command 서버: CUD(Create, Update, Delete) 담당

   Query 서버: R(Read) 담당 (별도의 서버로 분리)

2. Query 서버가 Command 서버에 직접 질의하면 부하 전파 →

   Query 서버 전용 DB를 구축

3. Query DB 데이터 동기화는 Message Broker(Kafka) 활용.

   • 이미 메시지 브로커 인프라가 존재하므로, Consumer만 추가하면 됨.
     

4. Query Model은 Command Model과 동일할 필요 없음

   • 조회 최적화를 위해 비정규화된 데이터 모델 사용 가능.
     

5. DB는 Redis (In-memory DB) 사용

   • 최신글 위주로 조회됨 → TTL=24시간 설정
     
   • 24시간 이전 글은 Command 서버에서 직접 조회 (트래픽 부담 낮음)
     

🧩 조회수 데이터 비정규화 제외 이유

• 조회수는 조회 트래픽에 비례해 변동이 매우 잦음
  
• 변경마다 Query Model을 갱신하면 비효율적
  
• 이미 조회수 서비스에서 Redis로 관리 중
  
• 따라서 조회수는 조회수 서비스에 직접 요청
  • 단, 짧은 TTL 캐싱(Caffeine 등 인메모리 캐시) 으로 부하 완화

---

🗓️ 10/03 (금)

📊 게시글 목록 조회 최적화 전략

🎯 목표

• 게시글 서비스의 DB 부하를 줄이면서, 조회 성능을 극대화
  

🧠 기본 접근: @Cacheable 캐싱

• 게시글 작성/삭제 시 캐시 만료 필요 → 캐시 만료가 잦고 히트율 저하
  
• 만료 시간을 늘리면 최신 데이터 반영 어려움 → 데이터 불일치 발생
  
• 즉, 단순 캐시로는 해결 불가능.
  

---

🔥 개선 접근: 게시판 사용 패턴 기반 캐시 전략

• Hot Data: 자주 조회되는 최신 글
  
• Cold Data: 거의 조회되지 않는 과거 글 → Hot Data에만 캐시 적용해도 충분히 효율적.
  

---

⚙️ 설계: Redis 기반 최신글 캐싱

1. 게시글 조회 서비스는 Kafka로부터 게시글 생성/삭제 이벤트 수신.

2. 이벤트 수신 시, Redis Sorted Set 에 게시판별 게시글 목록 저장.

   • 정렬 기준: 생성 시각 (최신순)
     
   • 최대 유지 개수: 1000건
     

3. 클라이언트가 목록 조회 시:

   • 최신 1000건 이내 데이터 → Redis에서 즉시 응답
     
   • 그 외의 과거 데이터 → 게시글 서비스(DB)에서 조회
     

---

🧭 핵심 요약

구분	내용
읽기 트래픽 최적화	CQRS로 Command/Query 서버 분리
데이터 분산 문제	메시지 브로커 기반으로 비동기 데이터 동기화
조회 성능 개선	Redis 캐시 + Sorted Set 구조
조회수 처리	별도 서비스 요청 + 인메모리 캐시 적용
캐시 전략	최신글(Hot Data)만 캐싱, 과거글은 DB 직접 조회

---

메모장에 정리한 내용 GPT로 재정리함