![[대규모 시스템 설계 기초] ch1. 사용자 수에 따른 규모 확장성](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FdUd7sU%2FbtsDVoBBQ6e%2FnZUmIVlwa7w8K8H2uC0Kk0%2Fimg.png)
본문은 '가상 면접 사례로 배우는 대규모 시스템 설계 기초’를 읽고 정리한 내용을 기반으로 작성된 글입니다.
[단일 서버]
☑️ 단일 서버 구성에서의 사용자 요청 처리 흐름
- 사용자는 도메인 이름(api.site.com)을 통해 웹사이트에 접속함
- 이 접속을 위해서는 도메인 이름을 DNS(Domain Name Service)에 질의하여 IP주로 변환하는 과정 필요
- DNS는 보통 제 3사업자(third party) ↔ 우리 시스템의 일부는 아님
- DNS 조회 결과로 IP주소 반환 (15.123 …)
- 해당 IP주소로 HTTP(HyperText Transfer Protocol) 요청이 전달됨
- 요청을 받은 웹 서버는 HTML페이지나 JSON형태의 응답 반환
[데이터베이스]
사용자가 늘면 서버 하나로는 충분하지 않아서 여러 서버를 두어야 한다.
- 웹/모바일 트래픽 처리 용도
- 데이터베이스용
☑️ 관계형 데이터베이스(RDBMS)
- 여러 테이블의 데이터를 관계에 따라 조인(join)하여 합칠 수 있음
☑️ 비-관계형 데이터베이스(NoSQL)
대부분의 개발자에게는 관계형이 최선일 것이지만,,
- 아주 낮은 응답 지연시간이 요구되는 경우
- 다루는 데이터가 비정형이라 관계형이 아닌 경우
- 데이터를 직렬화, 역직렬화 할 수 있기만 하면 되는 경우
- 아주 많은 양의 데이터를 저장할 필요가 있는 경우
NoSQL이 바람직한 선택일 수 있다.
[수직적 규모 확장 vs 수평적 규모 확장]
‘스케일 업(scale up)’ ↔ 수직적 규모 확장 : 서버에 고사양 자원(CPU, RAM 등)을 추가하는 행위
‘스케일 아웃(scale out)’ ↔ 수평적 규모 확장 : 더 많은 서버를 추가하여 성능을 개선하는 행위
서버로 유입되는 트래픽 양이 적을 때는 수직적 확장이 좋고 단순하다. 그러나
- 수직적 규모 확장은 한계가 있음 (무한대로 CPU나 메모리 증설 불가)
- 수직적 규모 확장은 장애에 대한 자동복구(failover) 방안이나 다중화(re-dundancy) 방안을 제시하지 않음 → 서버 장애가 발생하면 서비스는 완전히 중단된다.
따라서 대규모 애플리케이션을 지원하는 데는 수평적 규모 확장법이 보다 적절하다.
[로드밸런서]
: 부하 분산 집합(load balancing set)에 속한 웹 서버들에게 트래픽 부하를 고르게 분산하는 역할을 한다.
웹 서버가 다운되거나 사용자 증가로 서버가 한계 상황에 도달 → 웹 서버 다운, 접속 불가 문제를 해결하기 위해 도입하는 것이 최선이다.
- 사용자는 로드밸런서의 공개 IP주소로 접근함
- 웹 서버는 클라이언트의 접속을 직접 처리하지 않음
- 서버 간 통신에는 사설 IP주소가 이용됨
- 사설 IP주소 ↔ 같은 네트워크에 속한 서버 사이의 통신에만 쓰이는 주소
- 서버1이 다운되면 → 모든 트래픽은 서버2로 전송됨
- 웹 서버 계층에 더 많은 서버를 추가하기만 하면 로드밸런스가 자동적으로 트래픽을 분산하기 시작한다.
그렇다면 데이터 계층은??
[데이터베이스 다중화]
: 보통은 서버 사이에 주(master)-부(slave) 관계를 설정하고, 데이터 원본은 주 서버, 사본은 부 서버에 저장하는 방식
- 쓰기 연산은 마스터에서만 지원
- 부 데이터베이스는 읽기 연산만 지원
☑️ 데이터베이스 다중화로 얻는 이득
- 성능 : 병렬로 처리될 수 있는 질의(query)수가 늘어남
- 안정성 : 데이터베이스 서버 일부가 파괴되어도 데이터는 보존됨
- 가용성 : 데이터를 여러 지역에 복제해 둠 → 서버 장애가 생겨도 계속 서비스 가능
☑️ 주 데이터베이스 서버가 다운되면?
- 부 데이터베이스가 한 대
- 해당 부 데이터베이스 서버가 새로운 주 서버가 됨
- 새로운 부 데이터서버가 추가됨
사실 프로덕션 환경에서는 부 데이터서버의 데이터가 최신이 아니기 때문에 훨신 복잡함 ↔ 복구 스크립트 (다중 마스터, 원형 다중화 방식 도입)
☑️ 로드밸런서와 데이터베이스 다중화를 고려한 설계안
- 사용자는 DNS로부터 로드밸런서의 공개 IP주소를 받음
- 사용자는 해당 IP주소를 사용해 로드밸런서에 접속
- HTTP 요청은 서버1, 서버2로 전달됨
- 웹 서버는 사용자의 데이터를 부 데이터베이스 서버에서 읽음
- 웹 서버는 데이터 변경 연산 → 주 데이터베이스로 전달함
이제 응답시간을 개선해보자.
[캐시]
응답시간은 캐시(cache)를 붙이고 정적 콘텐츠를 콘텐츠 전송 네트워크(Content Delivery Network, CDN)로 옮기면 개선할 수 있다.
☑️ 캐시
: 값비싼 연산 결과 또는 자주 참조되는 데이터를 메모리 안에 두고, 뒤이은 요청이 보다 빨리 처리될 수 있도록 하는 저장소
애플리케이션의 성능은 데이터베이스를 얼마나 자주 호출하느냐에 크게 좌우됨 ↔ 캐시는 이 문제를 완화 가능
☑️ 캐시 계층
: 데이터가 잠시 보관되는 곳 → 데이터베이스보다 훨씬 빠르다.
별도의 계층을 둠 → 성능 개선, DB부하 감소, 캐시 계층 규모의 독립적 확장 가능
[읽기 주도형 캐시 전략]
- 요청을 받은 웹 서버 → 캐시에 응답이 저장되어 있는지 확인
- 있다면 해당 데이터를 클라에게 반환
- 없다면 데이터베이스 질의를 통해 데이터를 찾아 캐시에 저장한 뒤 클라에게 반환
읽기 주도형 외에도 다양한 전략이 있음
☑️ 캐시 사용 시 유의할 점
Q : 어떤 상황에 바람직한가?
A : 갱신은 자주 일어나지 않지만 참조는 빈번하게 일어나는 상황
Q : 캐시에 보관된 데이터는 어떻게 만료(expire)되는가?
A : 영속적으로 보관할 데이터 제외
Q : 일관성(consistency)은 어떻게 유지되는가?
A : 트랜잭션 관리, 자동 업데이트 메커니즘 등
Q : 장애에는 어떻게 대처할 것인가?
A : 여러 지역에 걸쳐 캐시 서버 분산하기
Q : 캐시 메모리는 얼마나 크게 잡을 것인가?
A : 과할당하는게 좋다
Q : 데이터 방출(eviction) 정책은 무엇인가?
A : LRU(Least Recently Used), LFU(Least Frequently Used), FIFO(First In First Out) 등등
[콘텐츠 전송 네트워크(CDN)]
: 정적 콘텐츠를 전송하는 데 쓰이는, 지리적으로 분산된 서버의 네트워크 ↔ 이미지, 비디오, CSS, JavaSrcipt 파일 등을 캐시
사용자가 웹사이트 방문 → 그 사용자에게 가장 가까운 CDN 서버가 정적 콘텐츠를 전달
☑️ CDN 동작 과정
- 사용자 A가 이미지 URL을 통해 이미지에 접근함 (URL의 도메인은 CDN 서비스 사업자가 제공)
- CDN 서버의 캐시에 해당 이미지가 없는 경우, 원본 서버에 요청하여 파일을 가져옴
- 원본 서버가 파일을 CDN 서버에 반환하고, 응답의 HTTP 헤더에는 TTL값도 같이 반환
- CDN 서버는 파일을 캐시하고 사용자에게 반환함 → 이미지는 TTL에 명시된 시간이 끝날 때까지 캐시됨
- 사용자 B가 CDN 서버에 요청 → 만료되지 않은 이미지에 대한 요청은 캐시를 통해 처리된다.
☑️ CDN 사용 시 고려해야 할 사항
- 비용 : CDN은 보통 제3 사업자(third-party providers)에 의해 운영되기 때문
- 적절한 만료 시한 설정 : 너무 길면 콘텐츠의 신선도가 떨어지고, 너무 짧으면 원본 서버에 빈번히 접속해야 함
- CDN 장애에 대한 대처 방안 : CDN 자체가 죽었을 경우 동작방안
- 콘텐츠 무효화 : 만료되지 않은 콘텐츠라도 제거할 수 있어야 함
☑️ CDN과 캐시가 추가된 설계
[무상태(stateless) 웹 계층]
웹 계층을 수평적으로 확장하려면 상태 정보(사용자 세션 데이터 같은)를 웹 계층에서 제거해야 한다.
: 상태 정보를 관계형 데이터베이스나 NoSQL같은 지속성 저장소에 보관하는 웹 계층
☑️ 상태 정보 의존적인 아키텍처
: 클라이언트 정보(상태)를 유지하여 요청들 사이에 공유되도록 함
문제점 : 같은 클라이언트로부터의 요청은 항상 같은 서버로 전송되어야 함
☑️ 무상태 아키텍처
- 사용자로부터의 HTTP 요청은 어떤 웹 서버로도 전달될 수 있음
- 상태 정보가 필요한 경우 공유 저장소로부터 데이터를 가져옴
- 상태 정보, 웹 서버가 물리적으로 분리되어 있음 → 단순, 안정적, 규모확장이 쉬움
☑️ 무상태 웹 계층을 갖도록 설계 변경
상태 정보가 웹 서버들로부터 제거됨 → 트래픽 양에 따라 웹 서버를 넣거나 빼기만 하면 자동으로 규모 확장 가능
[데이터 센터]
웹사이트가 매우 빨리 성장하여 전 세계 사용자의 이목을 받는 경우,
가용성을 높이고 전 세계 어디서도 쾌적하게 사용할 수 있도록 하기 위해 여러 데이터 센터를 지원하는 것이 필수다.
☑️ 지리적 라우팅
: 사용자를 가장 가까운 데이터 센터로 안내해주는 절차
☑️ 기술적 난제
- 트래픽 우회 : 올바른 데이터 센터로 트래픽을 보내는 효과적 방법 찾기
- 데이터 동기화 : 장애가 생겼을 때 → 트래픽 우회 → 다른 데이터센터에도 찾는 데이터가 있어야 함
- 테스트와 배포 : 여러 위치에서 테스트하고, 모든 데이터 센터에 동일한 서비스가 설치되도록 배포해야 함
[메시지 큐]
: 메시지의 무손실을 보장하는 비동기 통신을 지원하는 컴포넌트
↔ 메시지 큐에 일단 보관된 메시지는 소비자가 꺼낼 때까지 안전히 보관됨을 보장함
→ 서비스 또는 서버 간 결합이 느슨해져서, 규모 확장성에 용이함
☑️ 메시지 큐의 기본 아키텍쳐
- 생산자 또는 발행자(producer/publisher)가 메시지를 만들어 메시지 큐에 발행함
- 소비자 혹은 구독자(consumer/subscriber)가 메시지를 받아 그에 맞는 동작 수행
생산자/발행자 ↔ 입력 서비스
소비자/구독자 ↔ 서비스, 서버
[로그, 메트릭 그리고 자동화]
: 규모가 커지면 필수적으로 투자해야 하는 도구
[데이터베이스의 규모 확장]
[수직적 확장(scale-up)]
☑️ 수직적 접근법의 심각한 약점
- DB 서버의 CPU, RAM등을 무한 증설할 순 없음 → 결국에는 한 대로는 감당하기 어렵게 됨
- SPOF(Single Point Of Failure)로 인한 위험성이 크다.
- 고성능 서버일수록 비용이 많이 든다.
[수평적 확장]
☑️ 샤딩
: DB를 샤드(shard)라고 부르는 작은 단위로 분할하는 기술 ↔ DB의 수평적 확장
- 모든 샤드는 같은 스키마를 쓰지만, 샤드에 보관되는 데이터 사이에는 중복이 없음
- ex) 4개의 샤드 ↔ (user_id % 4)를 해시 함수로 사용하여 데이터가 보관되는 샤드를 정함
☑️ 샤딩에서 고려할 부분
- 샤딩 키를 어떻게 정하느냐 !!
- 데이터가 어떻게 분산될지 정하는 하나 이상의 칼럼(ex. user_id)
- 데이터를 고르게 분할할 수 있도록 하는 게 중요함
- 데이터의 재 샤딩
- 하나의 샤드로는 감당하기 어려울 때
- 데이터 분포가 균등하지 못할 때
- 유명인사 문제
- ㅋㅋㅋ
- 조인과 비정규화
- 하나의 DB를 여러개로 쪼개면, 여러 샤드에 걸친 데이터를 조인하기 힘들다 → DB를 비정규화하여 하나의 테이블에서 질의가 수행되도록 한다.
- ex) 인덱싱 추가, 요약 테이블 추가
☑️ 샤딩 + 여러 도구들을 적용한 아키텍쳐
정리하면,
- 웹 계층은 무상태 계층으로
- 모든 계층에 다중화 도입
- 가능한 한 많은 데이터 캐시
- 여러 데이터 센터 지원
- 정적 콘텐츠는 CDN을 통해 서비스
- 데이터 계층은 샤딩을 통해 규모 확장
- 각 계층은 독립적 서비스로 분할
- 시스템 지속적 모니터링, 자동화 도구 활용
재밌다~