[대규모 시스템 설계] Ch 01. 사용자 수에 따른 규모 확장성

 책 "가상  면접 사례로 배우는 대규모 시스템 설계 기초"를 읽고 정리하는 글입니다.

 

단일 서버

동작

1. [사용자] 웹 사이트의 도메인 이름으로 DNS 서버에 질의
2. [DNS] 사용자에게 해당 IP 주소 반환
3. [사용자] 해당 IP 주소로 HTTP 요청 전달
4. [웹서버] HTML 또는 JSON 형태의 응답 반환

---

데이터베이스

사용자가 늘어나면 단일 서버로는 트래픽을 감당할 수 없기 때문에 여러 서버를 두어야 한다.

하나는 웹/모바일 트래픽 처리 용도, 다른 하나는 데이터베이스용이다.

단일 서버 형태에 DB가 웹 서버와 연결된다.

데이터베이스 선택

관계형 DB (RDBMS)

• 전통적인 DB
• MySQL, Oracle DB 등
• 자료를 테이블과 열, 칼럼으로 표현한다.
• Join을 이용해 여러 테이블을 병합한다.

비관계형 DB (NoSQL)

• 네 종류
  1. Key-Value 저장소
  2. Graph 저장소
  3. Column 저장소
  4. Document 저장소
• 아래와 같은 케이스일 때 이용한다.
  • 아주 낮은 레이턴시를 필요로 할 때
  • 비정형 데이터를 다룰 때
  • 데이터를 직렬화/역직렬화 하기만 하면 될 때
    • RDBMS와 달리, 객체를 테이블 구조에 맞춰 변환 할 필요가 없음 → 직렬화를 통해 한번에 저장
  • 아주 많은 양의 데이터를 저장할 때

---

수직적 규모 확장 vs. 수평적 규모 확장

수직적 규모 확장 (Scale up)

정의

한 서버에 고사양 자원을 추가하여 성능을 개선하는 방식 (CPU 업그레이드, 메모리 추가 등)

장점

• 방법이 간단하며, 트래픽이 적을 때 사용

단점

• 확장에 한계가 있다.
• 자동 복구 방안이나 다중화 방안이 없음 → 서버 장애 시 웹사이트가 완전히 중단

수평적 규모 확장 (Scale out)

정의

더 많은 서버를 추가하여 성능을 개선하는 방식

장점

• 높은 확장성: 무한대로 서버를 추가할 수 있음 → 대규모 트래픽 처리에 유리
• 비용 효율성: 비교적 저렴한 범용 서버 여러 대를 연결 → 초기 비용 부담 감소
• 고가용성: 일부 서버 장애 발생에도 나머지 서버를 이용하여 무중단 이용 가능
• 유연성: 트래픽에 따라 서버 수를 유연하게 증감 가능

단점

• 데이터 일관성: 분산된 서버 간 데이터 동기화 필요
• 상태 관리 복잡성: 세선과 상태를 여러 서버가 공유하기 어려움
• 네트워크 오버헤드 증가: 노드 간 통신 비용, 요청 라우팅, 부하분산 트래픽 증가

로드밸런서

Scale out 방식의 고가용성을 구현하기 위해서는 로드밸런서가 필요하다.

정의

• 사용자는 로드밸런서의 공개IP주소로 접속한다. (웹서버는 클라이언트의 접속을 직접 처리하지 않는다)
• 로드밸런서는 부하 분산 집합에 속한 서버들에게 트래픽 부하를 고르게 분산시켜준다.
• 보안을 위해 서버 간 통신에는 사설 IP주소를 사용한다. (외부에서 접근 불가)

장점

• 서버 하나가 다운되면, 다른 서버들로 트래픽이 분산됨 → 서버 전체 다운 방지
• 트래픽이 지속적으로 증가할 때, 웹서버 계층에 서버를 추가하면 로드밸런서가 자동으로 트래픽을 분산시켜준다.

데이터베이스 다중화

정의

• DB를 다중화할 때, 데이터의 원본은 주 서버에, 사본은 부 서버에 저장된다.
• C, U, D 연산은 주 서버에서 진행하고, Read 연산은 부 서버에서 진행된다.
• 통상적으로 주 DB의 수보다 부 DB의 수가 많다. (읽기 연산 비중 > 쓰기 연산 비중)

장점

1. 연산의 분할 → 병렬 처리 가능한 query 수 증가 → 성능 증가
2. 안정성: 서버 중 일부가 파괴되어도 데이터 보전 가능
3. 가용성: 하나의 서버에 장애가 발생해도 다른 서버의 데이터를 가져와 계속 서비스 가능

---

캐시

정의

• 값비싼 연산 결과 또는 자주 참조되는 데이터를 메모리 안에 두고, 뒤이은 요청이 보다 빨리 처리될 수 있게 하는 저장소
• 캐시를 이용하여 잦은 DB 호출로 인한 성능 저하 문제를 완화할 수 있다.

캐시 계층

정의

• 데이터가 잠시 보관되는 곳
• 처리 속도가 빠름
• 독립적으로 확장 가능

읽기 주도형 캐시 전략

• 원하는 데이터가 캐시에 있는 경우
  1. 웹서버는 캐시에서 바로 데이터를 읽는다.
• 원하는 데이터가 캐시에 없는 경우
  1. DB에서 해당 데이터를 읽어 캐시에 쓴다.
  2. 캐시는 웹서버에 데이터를 전달한다.

주의할 점

• 캐시에는 갱신이 자주 일어나지 않지만, 참조가 빈번하게 일어나는 데이터를 보관해야한다.
• 영속적으로 보관할 데이터를 캐시에 보관하지 말아야 한다. (휘발성이기 때문에)
• 캐시 데이터의 만료기간 정책을 마련하는 것이 좋다.
  • 너무 짧으면 DB를 자주 읽게 된다.
  • 너무 길면 원본과 차이가 날 수 있다.
• 캐시 서버를 한 대만 둘 경우, 서버 장애 시 전체 시스템의 동작이 중단된다.
• 캐시 메모리의 크기가 작을 경우, 데이터가 너무 자주 캐시에서 밀려난다 → 과할당해야 한다.
• 데이터 방출 정책
  • LRU: 마지막으로 사용된 시점이 가장 오래된 데이터를 내보내는 방식
  • LFU: 사용 빈도가 가장 낮은 데이터를 내보내는 방식
  • FIFO: 가장 먼저 캐시에 들어온 데이터를 내보내는 방식

---

콘텐츠 전송 네트워크 (CDN)

정의

• 정적 콘텐츠를 전송하는 데 쓰이는 지리적으로 분산된 서버의 네트워크
• 이미지, 비디오, CSS, JavaScript 파일 등을 캐시할 수 있다.
• CDN을 통해 정적 콘텐츠의 로딩 속도를 단축시킬 수 있다.

동작

1. [사용자] image1.png 파일에 액세스
2. [CDN] image1.png 존재 여부 확인
   • 존재
     1. image1.png를 사용자에게 반환
   • 부재 (TTL 종료로 인한 캐시 만료)
     1. 원본 서버에서 image1.png를 가져와 CDN에 저장
     2. image1.png를 사용자에게 반환

주의할 점

• CDN은 보통 제3 사업자에 의해 운영되므로, 데이터 전송량에 따라 요금을 내야 한다. → 자주 사용되지 않는 콘텐츠의 캐싱은 제외하는 것이 좋음.
• 원본과의 일관성과 접속 시간의 단축 위한 적절한 TTL(Time To Live)을 설정해야 한다.
• CDN 장애 시 대처 방안을 마련해야 한다. (직접 원본 서버 참조 등)

---

무상태(stateless) 웹 계층

정의

• 웹 계층을 수평적으로 확장하기 위해 사용
• 상태 정보(사용자 세션 등)를 웹 계층이 아닌, DB에 저장 후 필요할 때 인출하는 방식

상태 정보 의존적 아키텍처

정의

• 상태 정보를 서버에 저장한다.

단점

• 사용자 1의 세션 정보가 서버 A에 저장되어있다면, 사용자 1의 요청이 서버 B로 전송되면 인증에 실패한다.
• 위 문제 해결을 위해 로드밸런서는 고정 세선(sticky session) 기능을 제공하지만, 로드밸런서에 부담을 준다.
• 또한 로드밸런서 뒷단에 서버를 추가하거나 제거하기도 까다로워지며, 서버 장애의 처리도 복잡해진다.

무상태 아키텍처

동작

• 사용자 1이 웹 서버에 HTTP요청을 할 때 세션 정보가 필요하다면, 웹서버는 공유 저장소(DB)로부터 데이터를 가져온다. (즉, 상태정보가 웹 서버와 분리되어 있다)

장점

• 단순, 안정적, 확장 용이

---

데이터 센터

웹 사이트가 대규모가 되었을 때, 어느 지역에서든지 쾌적한 이용을 하기 위해서는 여러 곳에 데이터 센터를 마련해야 한다.

동작

1. [사용자] 로드밸런서에 요청한다.
2. [로드밸런서] 지리적 라우팅(geo-routing)을 통해 사용자와 가장 가까운 데이터 센터로 라우팅해준다.

문제

• 올바른 데이터 센터로 트래픽을 보내는 효과적인 방법을 찾아야 한다.
• 데이터 센터마다 데이터가 달라지지 않도록 동기화(다중화)할 방법을 찾아야 한다.

---

메시지 큐

시스템을 더 큰 규모로 확장하기 위해서는 시스템의 각 컴포넌트(기능)을 분리하여, 독립적으로 확장될 수 있도록 해야 한다.

이를 위해 메시지 큐가 널리 사용된다.

정의 / 동작

• 생산자(웹 서버): 메시지를 만들어 메시지 큐에 발행한다
• 메시지 큐: 발행한 메시지를 보관한다.
• 소비자(컴포넌트): 메시지를 받아 그에 맞는 동작을 수행한다.

예시: 온라인 쇼핑

1. [생산자] 사용자가 상품을 주문 시, “주문이 발생했다”는 메시지를 메시지 큐에 전송한다.
2. [생산자] 실제 처리는 메시지 큐에 맡기고 사용자에게 주문이 완료되었음을 알린다.
3. [메시지 큐] 메시지를 일시적으로 저장하고, 여러 소비자(컴포넌트)에게 순차적으로 전달한다.
4. [소비자] 큐에서 메시지를 꺼내어 작업을 수행한다.
   1. 소비자 A: 영수증 메일 발송
   2. 소비자 B: 포인트 적립
   3. 소비자 C: 재고 감소 처리

장점

• 각 서비스의 독립적 규모 확장 용이
• 메시지 큐를 통한 부하 분산
• 비동기 처리를 통한 응답 지연 감소

---

로그, 메트릭, 자동화

시스템의 규모가 커지면 로그, 메트릭, 자동화 도구에 필수적으로 투자해야 한다.

로그

에러 로그를 서버 단위로 모니터링하기보다, 단일 서비스로 모아주는 도구를 활용하면 더욱 편리하게 검색하고 조회할 수 있다.

메트릭

= 수치, 지표

호스트 단위 메트릭

CPU, 메모리, 디스크 I/O 등

종합 메트릭

DB 계층의 성능, 캐시 계층의 성능 등

비즈니스 메트릭

일별 사용자, 수익, 재방문률 등

자동화

시스템이 크고 복잡해지면 자동화 도구를 활용하여 개발 생산성을 향상시켜야 한다.

---

데이터베이스의 규모 확장

수직적 규모 확장 (scale up)

정의

기존 서버에 더 많은 고성능의 자원을 증설하는 방법

단점

• 무한 증설 불가
• SPOF(Single Point Of Failure)으로 인한 위험성 증대
• 비용이 많이 든다.

수평적 확장 (sharding)

정의

• 대규모 DB를 shard라는 작은 단위로 분할하는 기술
• 모든 shard는 같은 스키마를 사용
• shard마다 보관되는 데이터에는 중복이 없음
• 더 많은 서버 추가하는 방식

sharding key

• 데이터가 어떻게 분산될 지 정하는 하나 이상의 칼럼으로 구성
• 예를 들어 key가 “user_id % 4”이면, 네 종류의 샤드로 분산된다.

주의할 점

• 재 샤딩: 데이터가 너무 많아지거나, 샤드 간 데이터 분포가 균등하지 못할 때 샤드 함수를 재정의해야 한다.
• 유명인사: 특정 샤드에 질의가 집중되어 과부하가 걸리는 문제.
• 조인과 비정규화: 하나의 DB를 여러 샤드로 쪼개고 나면, 여러 샤드에 걸친 데이터를 조인하기 힘들다. 이를 위해 데이터를 비정규화해야 한다.

 

---

위 모든 개념들을 도식화하면 아래와 같다.