hubtwork commented 2 weeks ago

Chapter Ownership : @zinokim

zinokim commented 1 week ago

1장. 사용자 수에 따른 규모 확장성

단일서버

모든 컴포넌트(웹 앱, 데이터베이스, 캐시 등)가 단 한 대의 서버에서 실행되는 간단한 시스템

사용자 요청이 처리되는 과정

사용자는 도메인 이름(api.mysite.com) 웹사이트 접속
DNS(Domain Name Service)에 질의하여 IP 주소로 변환
IP 주소로 HTTP(HyperText Transfer Protocol) 요청 전달
요청을 받은 웹 서버는 HTML 페이지나 JSON 형태의 응답 반환

데이터베이스

단일서버로 충분하지 않아 여러 서버를 두어야 할 때 웹/모바일 트래픽 처리 서버(웹 계층)와 데이터베이스 서버(데이터 계층)로 분리

데이터베이스 종류

관계형 데이터베이스(Relational Database 또는 Relational Database Management System, RDBMS)
- 자료를 테이블과 열, 칼럼으로 표현
- 테이블에 있는 데이터를 관계에 따라 Join 가능
- 관계형 데이터베이스 종류
  - MySQL
  - Oracle Database
  - PostgreSQL
  - MSSQL(SQL Server)
  - 기타
비 관계형 데이터베이스(NoSQL)
- 비 관계형 데이터베이스 분류
  - key-value store
  - graph store
  - column store
  - documnet-store
- 비 관계형 데이터베이스가 필요한 경우
  - 아주 낮은 응답 지연시간(latency)
  - 비정형 데이터(unstructured)
  - 데이터(JSON, YAML, XML 등)를 직렬화(Serialize) 또는 역직렬화(Deserialize)
  - 아주 많은 양의 데이터 저장
- 비 관계형 데이터베이스 종류
  - CouchDB
  - Neo4j
  - Cassandra
  - HBase
  - Amazon DynamoDB
  - 기타

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

수직적 규모 확장(Scale up): 서버에 고사양 자원(CPU, RAM 등) 추가하는 행위

서버로 유입되는 트래픽의 양이 적을 경우 좋은 선택
단점
- 확장에 한계 존재
- 장애에 대한 자동복구(failover) 방안이나 다중화(redundancy) 방안을 제시하지 않아 서버에 장애가 발생하면 애플리케이션 중단
  수평적 규모 확장(Scale out): 더 많은 서버를 추가하여 성능을 개선하는 행위
대규모 애플리케이션을 지원하는 데 적절한 선택

로드밸런서

부하 분산 집합(load balancing set)에 속한 웹 서버들에게 트래픽 부하를 고르게 분산하는 역할
사용자는 공개 IP 주소(Public IP)로 접속하고 로드밸런서는 사설 IP 주소(Private IP)로 웹 서버와 통신

로드밸런싱 알고리즘

라운드 로빈 방식 (Round Robin Method)

서버로 들어온 요청을 순서대로 돌아가며 배정하는 방식
클라이언트의 요청을 순서대로 분배하기 때문에 서버들이 동일한 스펙을 갖고 있고, 서버와의 연결(세션)이 오래 지속되지 않는 경우에 활용하기 적합

가중 라운드로빈 방식 (Weighted Round Robin Method)

각각의 서버마다 가중치(Weight)를 매기고 가중치가 높은 서버에 클라이언트 요청을 우선적으로 배분
주로 서버의 트래픽 처리 능력이 상이한 경우 사용되는 로드밸런싱 방식
ex) 서버 A의 가중치: 5 / 서버 B의 가중치: 2 => A 서버에 5개의 Request, B 서버에 2개의 Request 할당

IP 해시 방식 (IP Hash Method)

클라이언트의 IP 주소를 특정 서버로 매핑하여 요청을 처리하는 방식
사용자의 IP를 *해싱(Hashing)하여 부하를 분산하기 때문에 사용자가 항상 동일한 서버로 연결되는 것을 보장
경로가 보장되며, 접속자 수가 많을수록 분산 및 효율이 뛰어남
해싱(Hasing) : 임의의 길이를 지닌 데이터를 고정된 길이의 데이터로 매핑하는 것, 또는 그러한 함수

최소 연결 방식 (Least Connection Method)

Request가 들어온 시점에 가장 적은 연결(세션) 상태를 보이는 서버에 우선적으로 트래픽을 할당
자주 세션이 길어지거나, 서버에 분배된 트래픽들이 일정하지 않은 경우에 적합

최소 응답시간 방식 (Least Response Time Method)

서버의 현재 연결 상태와 응답시간(Response Time)을 모두 고려하여, 가장 짧은 응답 시간을 보내는 서버로 트래픽을 할당하는 방식
각 서버들의 가용한 리소스와 성능, 처리중인 데이터 양 등이 상이할 경우 적합

대역폭 방식 (Bandwidth Method)

서버들과의 대역폭을 고려하여 서버에 트래픽을 할당

데이터베이스 다중화

데이터베이스 서버 사이에 주(master) - 부(slave) 관계를 설정하고 데이터 원본은 주 서버에, 사본은 부 서버에 저장하는 방식
쓰기 연산(write operation)은 주 서버에서만 지원하고 부 서버에서는 읽기 연산(read operation)만을 지원

데이터베이스 다중화의 장점
- 더 나은 성능
- 안정성(reliability)
- 가용성(availability)

캐시

값비싼 연산 결과 또는 자주 참조되는 데이터를 메모리 안에 두고, 뒤이은 요청이 보다 빨리 처리될 수 있도록 하는 저장소

캐시 계층(Cache Tier)

데이터가 잠시 보관되는 곳으로 데이터베이스보다 훨씬 빨라서 성능이 개선될 뿐 아니라 데이터베이스의 부하를 줄일 수 있고 캐시 계층의 규모를 확장시키는 것도 가능하다.
웹 서버는 캐시에 응답이 저장되어 있는지를 물어보고 저장되어 있다면 캐시에서 데이터를 클라이언트에 반한화고 없다면 데이터베이스 질의를 통해 데이터를 찾아 캐시에 저장한 뒤 클라이언트에 반환하는데, 이러한 전략을 캐시 우선 읽기 전략(read-through caching strategy)이라 한다.

캐시 사용 시 유의할 점

어떤 상황에 바람직한가?
- 데이터 갱신이 자주 일어나지 않지만 참조는 빈번하게 일어나는 경우
어떤 데이터를 캐시에 두어야 하는가?
- 영속적으로 보관할 데이터가 아닌 경우
캐시에 보관된 데이터는 어떻게 만료(expire)되는가?
일관성(consistency)은 어떻게 유지되는가?
장애에는 어떻게 대처할 것인가?
- 캐시 서버를 한 대만 두는 경우 해당 서버는 단일 장애 지점(Single Point of Failure, SPOF)이 되어버릴 수 있으므로 여러 지역에 걸쳐 캐시 서버를 분산시켜야 한다.
캐시 메모리는 얼마나 크게 잡을 것이니가?
데이터 방출(eviction) 정책은 무엇인가?
- LRU(Least Recently Used): 마지막으로 사용된 시점이 가장 오래된 데이터를 내보내는 정책
- LFU(Least Frequently Used): 사용된 빈도가 가장 낮은 데이터를 내보내는 정책
- FIFO(First In First Out): 가장 먼저 캐시에 들어온 데이터를 가장 먼저 내보내는 정책

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

정적 콘텐츠를 전송하는 데 쓰이는, 지리적으로 분산된 서버의 네트워크로 이미지, 비디오, CSS, JavaScript 파일 등을 캐시할 수 있다.
사용자가 웹사이트를 방문하면, 그 사용자에게 가장 가까운 CDN 서버가 정적 콘텐츠를 전달하게 되며 사용자가 CDN 서버로부터 멀면 멀수록 웹사이트는 천천히 로드

동적 콘텐츠 캐싱은 요청 경로(request path), 질의 문자열(query string), 쿠키(cookie), 요청 헤더(request header) 등의 정보에 기반하여 HTML 페이지를 캐싱하는 것

CDN 사용 시 고려해야 할 사항

비용: 보통 제3사업자(third-party providers)에 의해 운영되며, CDN으로 들어가고 나가는 데이터 전송 양에 따라 요금 발생
적절한 만료 시한 설정: 시의성(time-sensitive) 콘텐츠의 경우 만료 시점 설정 필요
CDN 장애에 대한 대처 방안: CDN이 응답하지 않을 경우 대처 방안 설정

무상태(stateless) 웹 계층

상태 정보 의존적인 아키텍처

상태 정보를 보관하는 서버는 클라이언트 정보, 즉 상태를 유지하여 요청들 사이에 공유되도록 하는데 무상태 서버에는 이런 장치가 없다.
클라이언트로부터의 요청이 항상 같은 서버로 전송되도록 하기 위해 로드밸런서에서는 고정 세선(sticky-session) 기능을 제공하고 있는데, 이는 로드밸런서에 부담이며 로드밸런서 뒷단에 서버를 추가하거나 제거하기도 어려워 서버 장애 처리에 어려움

무상태 아키텍처

웹 서버는 상태 정보가 필요할 경우 공유 저장소(shared storage)로부터 데이터를 가져오는데 상태 정보는 웹 서버로부터 물리적으로 분리되어 있어 구조적으로 단순하고 안정적이며, 규모 확장이 쉽다.

데이터 센터

지리적 라우팅(geoDNS-routing 또는 geo-routing): 장애가 없는 상황에서 사용자는 가장 가까운 데이터 센터로 안내되는 절차

다중 데이터센터 아키텍처를 만들기 위한 기술적 난제

트래픽 우회
데이터 동기화
테스트와 배포

메시지 큐

메시지의 무손실(durability, 즉 메시지 큐에 일단 보관된 메시지는 소비자가 꺼낼 때까지 안전히 보관된다는 특성)을 보장하는 비동기 통신을 지원하는 컴포넌트로 메시지의 버퍼 역할을 하며 비동기적으로 전송한다.
메시지 큐의 기본 아키텍처

생산자 또는 발행자(producer/publisher)라고 불리는 입력 서비스가 메시지를 만들어 메시지 큐에 발행(publish)
큐에 연결된 소비자 혹은 구독자(consumer/subscriber)라 불리는 서비스 혹은 서버가 메시지를 받아 그에 맞는 동작 수행

메시지 큐의 장점

메시지 큐를 이요하면 서비스 또는 서버 간 결합이 느슨해져서, 규모 확장성이 보장되어야 하는 안정적 애플리케이션을 구성하기 좋다.
생산자는 소비가 프로세스가 다운되어 있어도 메시지 발행 가능
소비자는 생산자 서비스가 가용한 상태가 아니더라도 메시지 수신 가능

로그, 메트릭 그리고 자동화

로그: 시스템의 오류와 문제들을 보다 쉽게 찾아낼 수 있도록 하기 때문에 모니터링 하는 것은 중요
메트릭: 메트릭을 잘 수집하면 사업 현황에 관한 유용한 정보를 얻을 수도 있고 시스템의 현재 상태를 손쉽게 파악 가능
- 호스트 단위 메트릭: CPU, 메모리, 디스크 I/O 등
- 종합(aggregated) 메트릭: 데이터베이스 계층의 성능, 캐시 계층의 성능 등
- 핵심 비즈니스 메트릭: 일별 능동 사용자(daily active user), 수익(revenue), 재방문(retention) 등
자동화: 시스템이 크고 복잡해지면 생산성을 높이기 위해 자동화 도구 활용 필요

데이터베이스의 규모 확장

수직적 확장(scale up)

기존 서버에 고성능의 자원(CPU, RAM, 디스크 등)을 증성하는 방법

수직적 접근법의 심각한 약점
- 데이터베이스 서버 하드웨어의 한계
- SPOF(Single Point of Failure)로 인한 위험성
- 고성능 서버로 갈수록 고비용

수평적 확장(scale out)

데이터베이스의 수평적 확장은 샤딩(sharding)이라고도 불리는데 더 많은 서버를 추가함으로써 성능 향상
샤딩은 대규모 데이터베이스를 샤드(shard)라고 부르는 작은 단위로 분할하는 기술을 일컫는데 모든 샤드는 같은 스키마를 쓰지만 샤드에 보관되는 데이터 사이에는 중복이 없다.

샤딩 키(sharding key)

샤딩 전략을 구현할 때 고려해야 할 가장 중요한 것
파티션 키(partition key)라고도 불림
하나 이상의 칼럼으로 구성
샤딩을 도입하면서 풀어야 할 새로운 문제
- 데이터 재 샤딩(resharding): 데이터가 너무 많아져서 하나의 샤드로는 감당하기 어렵거나 샤드 간 데이터 분포가 균등하지 못하여 어던 샤드에 할당된 공간 소모가 다른 샤드에 비해 빨리 진행될 때
- 유명인사(celebrity) 문제: 핫스팟 키(hotspot key) 문제라고도 불리는데, 특정 샤드에 질의가 집중되어 서버에 과부하가 걸리는 문제
- 조인과 비정규화(join and denormalization): 하나으 ㅣ데이터베이스를 여러 샤드 서버로 쪼개고 나면 여러 샤드에 걸친 데이터를 조인하기 힘들어진다.

백만 사용자, 그리고 그 이상

시스템의 규모를 확장하는 것은 지속적이고 반복적(iterative)인 과정

웹 계층은 무상태 계층으로
모든 계층에 다중화 도입
가능한 한 많은 데이터를 캐시할 것
여러 데이터 센터를 지원할 것
정적 콘텐츠는 CDN을 통해 서비스할 것
데이터 계층은 샤딩을 통해 그 규모를 확장할 것
각 계층은 독립적 서비스로 분할할 것
시스템을 지속적으로 모니터링하고, 자동화 도구들을 활용할 것

iamzin commented 1 week ago

초기 서비스를 만들어보고, 서비스가 확장해가는 과정에서 고민했던 내용들이어서 흥미로웠다. 앞으로 이 내용들을 더 자세하고 구체적으로 공부할 생각에 싱낭다

hubtwork commented 1 week ago

소감

기본적인 Infra 의 구조 및 스케일링에 대한 이해도를 쌓기에 좋은 챕터 👍 근데 왜 DB 는 AZ 를 나눠놓고, NoSQL 은 AZ 를 안 나누는지? 서로 다른 AZ 의 DB 간의 동기화 등에 대해서는 좀 설명 없이 그냥 이렇게 하면됩니다~ 식으로 정리되어 있던 부분이 좀 아쉽다 🤣

KangHun-Lee commented 1 week ago

소감

기초를 다진 다는 생각으로 천천히 읽었다. 전반적으로 한번씩 이야기 해주어서 좋긴 했다. 내용을 아는 사람들은 한번씩 다시 본다라는 느낌으로 봤을 거 같은데 아무것도 모르는 사람이 보기에는 조금은 불친절한 책 같았다.

한줄 요약 : 시스템 디자인 Overview 잘 봤다

zinokim commented 1 week ago

소감

단계적으로 반복적으로 시스템을 확장해 나가는 방법을 어렵지 않게 설명해주어서 좋았다. 아직 1장이라 그런지 각 부분에 대한 디테일이 기대된다.

CHOICORE commented 1 week ago

시스템 구조를 한 눈에 볼 수 있어서 좋았다. 역시 그림이 있어야 읽기 쉬운 것 같다. 흠 내용 중에 샤딩에서 키가 중요하다고 하고 키 생성에 mod 방식만 나왔는데, 이거처럼 전체적으로 설명이 얕은 감 있었다. 하지만 키워드들이 머리속에 남기도 하고 찾아보기 좋은 것 같다. 기대된다.

hlab-books / system-design-interview