14. 시스템 설계 기초 요약 (1) - 패스트캠퍼스 백엔드 부트캠프 3기

시스템 설계 기초 정리

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

1. 단일 서버의 기본 구조와 요청 흐름

- 사용자 요청 시작 : 사용자는 브라우저에 도메인 이름을 입력한다.
- DNS 조회 : 도메인 이름을 DNS에서 조회, IP 주소가 반환된다.
- HTTP요청 전송 : 해당 IP 주소로 HTTP 요청이 전달된다.
- 응답 반환 : 요청을 받은 웹 서버는 HTML 페이지나 JSON 형태로 응답을 반환한다.

2. 사용자 수 증가에 따른 데이터베이스 설계

- 초기 : 단일 데이터베이스(하나의 웹 서버와 데이터베이스가 같이 있다.)
- 단일 데이터베이스의 특징 : 낮은 지연시간, 관리 간편, 확장성 거의 없음

- DB 서버 분리 : 웹 서버와 데이터베이스 서버를 물리적으로 분리한다.

3. 어떤 데이터베이스를 사용할 것인가?

비-관계형 데이터베이스(NoSQL)
- 아주 낮은 응답 지연시간이 요구됨
- 다루는 데이터가 비정형이라 관계형 데이터가 아님
- 데이터를 직렬화하거나 역직렬화 할 수 있기만 하면 됨
- 아주 많은 양의 데이터를 저장할 필요가 있음

4. 확장

- 수직적 규모 확장(scale up) : 서버에 고사양 자원을 추가하는 행위

수직적 규모 확장의 단점
- 확장성에 한계가 있다.
- 서버에 장애가 발생하면 웹/앱 완전 중단

- 수평적 규모 확장(scale out) : 서버를 추가하여 성능을 개선하는 행위

수평적 규모 확장의 단점
- 데이터 일관성 유지 어려움

5. 로드밸런서

- 로드밸런서 : 부하 분산 집합에 속한 웹 서버들에게 트래픽 부하를 고르게 분산하는 역할

6. 데이터베이스 다중화

- 주 서버(master) : 쓰기 작업, 원본 데이터
- 부 서버(slave) : 읽기 작업, 사본 데이터

데이터베이스 다중화의 장점
- 더 나은 성능 : 읽기 부하 분산
- 안정성 : 데이터 백업 및 복제
- 가용성 : 서버 장애 대응 가능

7. 다중 서버의 기본 구조와 요청 흐름 

- 사용자는 DNS로부터 로드밸런서의 공개 IP 주소를 받는다.
- 사용자는 해당 IP주소를 사용해 로드밸런서에 접속한다.
- HTTP 요청은 서버1 혹은 서버2로 전달된다.
- 웹 서버는 사용자의 데이터를 부 데이터베이스 서버에서 읽는다.
- 웹 서버는 데이터 변경 연산은 주 데이터베이스로 전달한다.

8. 캐시

- 응답 시간의 개선 : 캐시를 붙이고 정적 콘텐츠를 콘텐츠 전송 네트워크(CDN)로 옮기면 개선할 수 있다.
- 캐시 : 비싼 연산 결과 또는 자주 참조되는 데이터를 메모리에 두고 요청이 빨리 처리될 수 있도록 하는 저장소
- 캐시 우선 읽기 전략 : 요청을 받은 웹 서버는 캐시에 응답이 저장되어 있는지 보고, 없을 경우 DB에서 읽어온다.

캐시 사용 시 고려할 점
- 캐시 사용 상황 : 데이터 갱신이 자주 일어나지 않고 참조가 자주 발생할 사용
- 캐시 저장 데이터 : 자주 조회되고, 변경이 적은 데이터, 조회 비용이 높은 데이터를 저장
- 캐시에 보관된 데이터의 만료 : 만료 기한이 짧으면 DB를 자주 읽고, 길면 원본과 차이가 날 가능성이 높아진다.
- 일관성 유지 : 저장소의 원본을 갱신하는 연산과 캐시를 갱신하는 연산이 단일 Tx 처리되지 않는 경우 일관성이 깨질 수 있다.
- 캐시 메모리 크기 : 캐시 메모리가 너무 작으면 데이터가 자주 캐시에서 밀려나 캐시의 성능이 떨어지게 된다.
- 데이터 방출 정책 : 캐시가 꽉 찰 경우 기존 데이터를 내보내야 한다.

만료 정책
- 절대 만료 : 저장한 순간부터 고정된 시간 후 만료
- 슬라이딩 만료 : 접근할 때마다 만료 시간 리셋

일관성 정책
- Write-through 캐시 : 데이터베이스에 쓸 때 캐시도 함께 업데이트
- Write-around 캐시 : 데이터베이스에만 쓰고, 캐시는 건드리지않음(읽을 때 다시 채움)
- Write-back 캐시 : 먼저 캐시에만 쓰고, 나중에 DB 반영(데이터 유실 리스크)
- Cache Invalidation(무효화) 전략 : 데이터 변경 시 해당 캐시 키를 삭제하거나 갱신

장애 대처 정책
- Circuit Breaker 패턴 : 캐시 서버 장애 감지 시 일정 시간 동안 캐시 요청을 막고 DB로 요청을 보냄

데이터 방출 정책
- LRU(Least Recently Used) : 가장 오래 사용되지 않은 데이터부터 삭제
- LFU(Least Frequently Used) : 가장 적게 사용된 데이터부터 삭제
- FIFO(First In First Out) : 가장 먼저 들어온 데이터부터 삭제

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

- CDN : 정적 콘텐츠를 전송하는 데 쓰이는, 지리적으로 분산된 서버의 네트워크

CDN의 동작 흐름
- 사용자가 URL에 접근 : 사용자가 웹 브라우저에 콘텐츠 URL을 입력하거나 클릭
- CDN 서버 캐시 확인 : CDN 서버는 요청받은 URL에 해당하는 파일이 캐시에 존재하는지 확인한다.
- 캐시에 파일이 없는 경우 : CND 서버가 원본 서버에 요청을 보낸다.
- 원본 서버가 파일을 반환 : 원본 서버는 요청받은 파일을 CDN서버로 반환한다.
- CDN 서버 캐시 저장 : CDN 서버는 받은 파일을 자신의 캐시에 저장하고 사용자에게 파일을 응답한다.

CDN 사용 시 고려해야 할 사항
- 비용 : CDN으로 들어가고 나가는 데이터 전송 양에 따라 요금을 내게 된다.
- 적절한 만료 시한 설정 : 만료 시점이 짧으면 캐시 재생성이 자주 발생
- CDN 장애에 대한 대처 방안 : CDN 자체에 장애가 발생할 경우, 사용자 요청이 실패할 수 있다.
- 콘텐츠 무효화 : 이미 CDN 서버에 저장된 파일을 업데이트해야 할 때, 무효화가 필요하다.

CDN과 캐시가 추가된 설계의 장점
- 정적 콘텐츠는 CDN을 통해 제공하여 더 나은 성능을 보장한다.
- 캐시가 데이터베이스 부하를 줄여준다.

10. 무상태(stateless) 웹 계층

- 무상태 웹 계층 : 상태 정보를 DB 저장소에 보관하고 필요할 때 가져오게 구성된 웹

- 상태 정보 의존적인 아키텍처 : 서버가 사용자마다 세션을 기억해야 하는 구조
- 고정 세션 : 로드밸런서가 클라이언트-서버 매핑 테이블을 따로 관리하는 기능
- 단점 : 로드밸런서의 부담 증가

- 무상태 아키텍처 : 서버가 클라이언트의 이전 요청 상태를 기억하지 않는 구조, 확장성과 유연성이 뛰어나다.

11. 데이터 센터

다중 데이터 센터 아키텍처를 만들 때 고려해야 할 사항
- 트래픽 우회 : 사용자의 위치나 상황에 따라 가장 가까운 데이터 센터로 요청을 유도
- 데이터 동기화 : 데이터 센터마다 별도의 데이터베이스를 사용하고 있다면 데이터 일관성 문제가 발생함
- 테스트와 배포 : 각 데이터 센터가 동일한 코드를 실행하고 있어야 함

12. 메시지 큐

- 메시지 큐 : 메시지의 무손실을 보장하는 비동기 통신을 지원하는 컴포넌트, 서비스 또는 서버 간 결합을 느슨하게 한다.

- 컴포넌트 : 시스템을 구성하는 하나의 독립된 기능 단위

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

시스템 운영의 필수 3요소
- 로그 : 시스템이 수행한 이벤트의 상세 기록(과거 추적)
- 메트릭 : 시스템 상태나 성능을 수치로 표현한 데이터(현재 상태)
- 자동화 : 사람이 개입하지 않고 반복적인 작업을 자동으로 처리하는 체계(미래 대응)

14. 데이터 베이스 확장

- 수평적 확장 : 샤딩이라고도 부르며, 더 많은 서버를 추가해 성능을 향상시키는 방법

샤딩을 구현할 때 고려해야 할 사항
- 샤딩 키 : 분산 데이터베이스에서 데이터를 어떻게 나눌지를 결정하는 기준 컬럼
- 데이터의 재 샤딩(샤드 소진) : 데이터가 너무 많아져서 하나의 샤드로 감당 할 수 없을 때, 샤드 간 데이터 분포가 불균등 할 때
- 유명인사 문제(핫스팟 키) : 특정 샤드에 질의가 집중되어 서버에 과부하가 걸리는 문제
- 조인과 비정규화 : 하나의 DB를 여러 샤드 서버로 쪼개면 여러 샤드에 걸친 데이터를 조인하기 힘들어진다.

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

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