⚙️ 대규모 시스템 설계 강의 정리 (섹션 3)

인프런 강의 섹션 3: 트리 구조, 좋아요 수, 조회수 처리 설계 학습 내용 정리

기간: 8월 30일 ~ 9월 1일

---

📅 8월 30일 (토) — 무한 Depth 트리 구조 설계

🔹 트리 구조의 문제점

게시판, 댓글 등에서는 무한 Depth 구조(대댓글 등)가 자주 등장합니다.

이때, 단순히 부모-자식 관계를 테이블로 관리하면 계층 쿼리 성능이 급격히 저하됩니다.

🔹 해결 방법: Path 기반 정렬

• 각 노드(댓글 등)에 path라는 문자열 컬럼을 둔다.
  
• path 컬럼은 루트부터 현재 노드까지의 경로를 문자열로 저장
  
• 이 path를 기준으로 오름차순 정렬하면 트리 구조를 쉽게 표현 가능
  

예시:

comment_id	parent_id	path
1	NULL	A
2	1	A.B
3	1	A.C
4	2	A.B.D

→ ORDER BY path ASC 만으로 계층 구조 정렬 가능

🔹 Depth 제한

• path 문자열의 길이로 Depth 제한을 둘 수 있음
  
• 길이 5 기준으로 한 Depth에 약 9억 개의 노드 표현 가능
  
• path는 숫자뿐 아니라 대소문자 문자열까지 포함 가능
  

🔹 62진수 기반 Path 인코딩

• 각 Depth의 인덱스를 62진수(0-9, a-z, A-Z) 로 표현
  
• 예:
  • Root: 0
    
  • 첫 번째 자식: 1
    
  • 두 번째 자식: 2
    
  • 61번째 자식: Z
    
  • 이후 자리수가 늘어나면서 계층 표현 가능

→ 문자열 기반 정렬이면서도 수학적으로 Depth 계산이 가능해 효율적

---

📅 8월 31일 (일) — 좋아요 수(Like Count) 설계

🔹 좋아요 수의 특성

• 실시간성이 중요하다. → 사용자에게 즉시 반영되어야 하므로 빠른 조회 필요
  
• 따라서 비정규화(denormalization) 구조가 유리하다.
  

---

🔹 단순한 방식: 게시글 테이블에 좋아요 수 저장

• article 테이블에 like_count 컬럼 추가
  
• 좋아요 발생 시:
  1. like 테이블에 INSERT
  2. article 테이블의 like_count UPDATE

하지만 이 방식은 문제를 일으킨다 👇

⚠️ 문제 1: Record Lock

• 트랜잭션 내에서 article 테이블에 쓰기 잠금(lock)이 걸림
  
• 동시에 여러 사용자가 좋아요를 누르면 트랜잭션 대기 상태 발생
  
• 좋아요 기능과 게시글 수정 기능이 서로 영향을 주게 됨
  

⚠️ 문제 2: 분산 트랜잭션

• 좋아요 테이블과 게시글 테이블이 서로 다른 샤드(DB)에 위치 가능
  
• 예:
  • like 테이블 → article_id 기반 샤딩
    
  • article 테이블 → board_id 기반 샤딩
• 서로 다른 DB 간 트랜잭션은 2PC(분산 트랜잭션) 필요
  
• 이는 복잡하고 느리며, 장애 전파 가능성 존재
  

---

🔹 개선된 구조: 좋아요 수 전용 테이블

• 좋아요 수를 별도의 테이블(like_count)로 분리
  
• like 테이블과 동일하게 article_id를 샤딩 키로 사용
  

Table	Key	역할
like	article_id	사용자별 좋아요 기록
like_count	article_id	게시글별 좋아요 수 집계

→ 이렇게 하면 분산 트랜잭션 없이 빠른 갱신 및 조회 가능

---

📅 9월 1일 (월) — 조회수(View Count) 설계

🔹 조회수의 특성

• 정확한 일관성보다 대략적인 실시간성이 중요
  
• 모든 조회 내역을 저장할 필요 없음 → 단순히 “조회 횟수”만 필요
  
• 따라서 트랜잭션보다는 속도와 효율성 우선
  

---

🔹 문제점

• 조회할 때마다 쓰기 작업 발생 → 쓰기 트래픽이 많음
  
• 디스크 기반 DB(MySQL 등)는 비용이 크고 성능 저하 가능
  

---

🔹 해결 방안: Redis 활용

In-memory DB인 Redis는 조회수 카운팅에 매우 적합하다.

✅ 장점

• 빠른 쓰기 성능 (메모리 기반)
  
• 클러스터 구성으로 확장성, 부하 분산, 고가용성, 안정성 확보
  
• 자동 샤딩 지원
  • 서버 추가 시 데이터 자동 분산
• 데이터 복제 및 영속성 기능 제공
  

---

🔹 Redis의 영속성 관리

• Redis는 디스크 기반 백업 기능 제공
  • AOF(Append Only File)
    
  • RDB(Snapshot)
• 이를 통해 일정 수준의 데이터 안정성을 확보 가능
  

---

🔹 자체 백업 시스템 구축 방안

Redis만으로도 충분하지만, 서비스 레벨에서 보조 백업 로직을 두면 안정성이 향상된다.

1️⃣ 시간 단위 백업

• 배치 또는 스케줄링 시스템으로 일정 주기마다 Redis 데이터를 백업
  
• 예: 매 5분마다 Redis의 조회수 데이터를 MySQL로 저장
  

2️⃣ 개수 단위 백업

• 조회수 누적이 일정 개수에 도달할 때마다 백업
  
• 조회 시점에 간단한 조건문으로 처리 가능
  

---

🧭 마무리

이번 섹션에서는 대규모 트래픽 환경에서의 데이터 관리 전략을 다뤘습니다.

트리 구조, 좋아요, 조회수 모두 단순한 기능이지만,

대량의 데이터가 쌓일 때 성능과 일관성, 확장성을 고려해야 한다는 점이 핵심이었습니다.

주제	주요 포인트
트리 구조	문자열 기반 path 컬럼, 62진수 depth 표현
좋아요	Record Lock, 분산 트랜잭션 회피 → 별도 like_count 테이블
조회수	Redis 기반 In-memory 처리 + 주기적 백업

---

노트에 정리한 내용 GPT로 정리함