[소마 강의 회고] 대규모 서비스 개발 기초 #1 Stateless와 읽기 분배

강의 개요

멘토 : 강대명 멘토님
수강일자 : 2026.04.11 20:00시 ~ 23:00시
온/오프라인 : 온라인(Webex)

---

강의 수강 이유

1) 백엔드 대규모 시스템 설계에 대한 이해

DB Routing, Consistent Hashing, Sharding과 같은 개념들이 나와 흥미로워서 신청하게 되었다. 특히 강대명 멘토님이 진행하시는 '우아한 레디스' 강의를 인상깊게 본 기억이 있어 흥미로웠다.

 

2) 샤딩 파티셔닝 기준별 장단점의 이해

두나무 면접 때 샤딩과 관한 질문을 받았는데 아무래도 경험이 없다보니 뭉뚱그려 개념만 이야기했던 것이 조금 아쉬웠다. 샤딩 시, 파티셔닝 기준별로 장단점이 있는 걸로 알고 있어서 이를 이해하고자 했다.

 

3) 해쉬링과 레디스 클러스터 이해

균등한 자원 분배 및 해쉬링에 대해 이해하고 싶어 수강하게 되었다.

 

본 강의는 핵심적인 내용이 많아 총 3파트로 나누어 요약을 진행해볼 예정이다. 

---

강의 핵심 요약 

- 데이터가 곧 상태고 상태가 곧 데이터다.

- 데이터를 어떻게 조회할 것인가? == 데이터를 어떻게 저장할 것인가?

- Stateless한 아키텍처는 API 서버에 저장되는 데이터를 DB로 옮기는 것이다.

- 상태를 저장하는 서버는 반대로 책임을 모두 옮겨졌으니 스펙이 좋아야 한다.

- 대부분의 서비스는 읽기 요청 비율이 많으므로 읽기 분산을 통해 I/O처리량을 늘릴 수 있다.

- Replication Lag와 Write Heavy 상황을 주의하라.

- Replication 방법은 Async, Semi Sync로 나뉘며 Semi Sync는 AFTER_COMMIT, AFTER_SYNC로 동기화 시점을 조정가능하다.

 

---

강의 내용 상세 요약

-DB 서버 vs API서버 중 무엇을 확장해야하는가? :  DB를 거치는지를 기준으로

    - 독립적인 로직(파일 서빙, I/O, 이미지 리사이징 등 전처리)

    - 복잡한 비즈니스 로직 -> API 서버 확장 필요 

    - DB서버에서 데이터를 가져와 비즈니스 로직 수행 -> DB 서버 확장 필요

  

- 모든 데이터는 상태(지속적 변경되며 저장되어야 하는 정보)를 지닌다

    - 상태가 곧 데이터고, 데이터가 곧 상태다.

    - 데이터를 저장하는 것은 곧 조회와 직결된다.(어떻게 저장할 것인가? == 어떻게 조회할 것인가?)

 

- API Server1에 User1, User3이 저장된 상황

- API Server2에 User2, User4가 저장된 상황

=> 이 상황에서 다음과 같은 질문을 던질 수 있다

- User5를 어디에 저장할 것인가?

- User1을 가져오려면 어떤 서버로 가야하는가?

- API Server 하나가 다운되면?

 

- Stateless 아키텍처

  - API서버가 데이터를 보관하지 않고 외부 Source로 데이터 분리

  - 장애가 나더라도 모든 데이터는 외부에 존재

 

반대로 이렇게 되면 State 서버는 크고, 안정적이어야 함

- 카카오 예시) API 서버는 16GB 파워 1개인 반면 DB서버는 메모리 48GB이상, 파워가 2개라 하나가 다운되어도 그대로 운용됨

 

- Stateless 아키텍처의 명암

장점	단점
- 확장성(스케일 아웃) - 데이터 관리 일원화로 서버 추가, 삭제 시 상태이동 불필요  - 특정 리소스 관리에 집중 가능	- 개별 서버 성능 저하(로컬 Cache hit 효과 감소) - 모든 상태를 저장할 외부의 안정적 저장소 필요

=> 모든 부하가 사라진 것이 아니라 DB로 부담을 옮긴 것 뿐이다

 

- DB Connection 풀 설정시 주의점

   - API 서버 관점에서 목표 TPS 달성을 위한 DB 커넥션 설정도 중요하지만

    -DB 서버 관점에서 max_connection을 유의한 커넥션 개수 설정도 중요하다

 

- 간단한 대규모 서비스 구조

  - LB로 로드밸런싱

   - API 서버 다중화

   - DB Replication

   - 캐시 서버 다중화

 

- DB확장의 첫걸음은 단일 서버의 최적화이다 (인덱스, 레코드 최적화 등)

- 대부분의 웹 서비스는 쓰는 비율보다 읽는 비율이 압도적으로 높다 => 읽기 분배

- Primary에 Read 800 / Write 200 부하 => Replica1(400:200) / Replica2(400:200)으로 분산

=> 왜 200이 유지될까? (복제 과정에서 쓰기 요청이 전파되어야 하기 때문에 쓰기 부하 200이 유지됨)

 

 

주의할 점1. Replication Lag: 복제 지연으로 인한 결과값 정합성 불일치

 

주의할 점2. Wrtie-Heavy 문제

- Replication 자체도 모든 Replica에 Write I/O를 요구

- Write 비율이 압도적이라면-> 쓰기 트래픽이 시스템 전체의 대역폭 잠식

=> Replica를 늘린다고 해서 무한정 전체 성능이 증가하지는 않음

 

복제 방식 : Async vs Semi-Sync

- Async : Primary 커밋 이후에 복제 통신

step1) 클라이언트 COMMIT 요청 > 마스터 바이너리 로그 기록 > OK 응답 반환

 

step2) 별도의 스레드에서 슬레이브로 binlog 전송(응답 무관)

 

- Semi-Sync : 1개(설정 값에서 변경 가능)의 Replica로 부터 릴레이 로그 복제 ACK를 받고 응답

- AFTER_COMMIT(5.5까지 기본) : 스토리지 엔진 커밋 후 binlog 전송 (COMMIT > SYNC)

step1) 클라이언트 commit 요청 > 마스터 binlog 기록

 

step2) 스토리지 엔진 커밋 완료 (다른 트랜잭션에서 이 변경이 보임)

 

step3) 슬레이브로 binlog 전송 > 슬레이브의 ACK > 클라이언트 OK

 

---

 

- AFTER_SYNC (5.7부터 기본): 슬레이브로부터 ACK를 받고 마스터 스토리지 커밋

 

step1) 클라이언트 commit 요청 > 마스터 binlog 기록

 

step2) 슬레이브로 binlog 전송 > 슬레이브의 ACK(릴레이 로그 fsync 완료 확인)

 

step3) 마스터 스토리지 엔진 커밋 -> 클라이언트 OK 응답

---

나의 생각

 

1) 상태에 대한 시각

상태는 곧 데이터이고, 데이터가 곧 상태라는 점, stateless 아키텍처의 핵심은 부하를 많이 견디는 것이 아니라 DB로 상태를 이전함으로써 부하의 책임을 DB로 옮겨지게 하는 것이라는 점이 인상 깊었다.

 

2) Replication에 대한 개념

읽기 분산은 한번 DB Routing을 구축해본 적이 있는 만큼 개념적으로 알고 있었는데 중요 개념들을 짚어주셔서 좋았다. 특히 Async, Semi-Sync각 개념을 톺아볼 수 있었다. 다만 읽기 분산이 안좋은 원인으로 단순 LAG가 아닌 Write Heavy 상황이 있다는 건 처음 인식하게 되어서 해당 상황에서는 샤딩이 오히려 더 좋은 선택지가 될 수 있을 것 같았다.