사용자 수에 따른 규모 확장성 (대규모 시스템 설계 기초)

단일 서버

웹 앱, DB, 캐시 등이 모두 서버 한 대에서 실행되는 구조

데이터베이스

사용자가 늘면 서버 하나로는 충분하지 않아서 여러 서버를 두어야 한다.

1. 웹/모바일 트래픽 처리 용도(웹 계층)
2. 데이터베이스 서버(데이터 계층)

DB 선택 기준

대부분은 관계형 데이터베이스가 최선이지만 특정한 경우에는 비-관계형 데이터베이스를 사용한다.

1. 아주 낮은 응답 지연시간(latency)이 요구될 때
2. 다루는 데이터가 비정형이라 관계형 데이터가 아닐 때
3. 데이터를 직렬화하거나 역직렬화 할 수 있기만 하면 될 때
4. 아주 많은 양의 데이터를 저장할 필요가 있을 때

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

스케일 업 : 고사양 자원을 추가하는 행위(수직적 규모 확장)

스케일 아웃 : 더 많은 서버를 추가해 성능을 개선하는 행위(수평적 규모 확장)

수직적 규모 확장에는 한계가 있고, 장애에 대한 failover 방안이나 다중와 방안을 제시할 수 없다.

따라서 대규모 애플리케이션을 지원하는 데는 수평적 규모 확장법이 적절하다.

로드밸런서

부하 분산 집합(load balancing set)에 속한 웹 서버들에게 트래픽 부하를 고르게 분산하는 역할

로드밸런서를 이용해 서버를 이중화 했지만 여전히 데이터 계층은 불안하다.

데이터베이스 다중화

쓰기 연산은 마스터에서만 지원

읽기 연산은 마스터, 슬레이브 둘 다 지원

대부분의 애플리케이션은 읽기 연산의 비중이 쓰기 연산보다 훨씬 높기 때문에 많은 부 데이터베이스 서버를 갖는다.

만약 주 데이터베이스에 문제가 생겼다면 부 데이터베이스 하나를 주 데이터베이스로 지정하고 장애를 극복한다.

부 데이터베이스가 최신 상태가 아니라면 복구 스크립트를 돌려서 추가해야 한다.

캐시

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

캐시 계층

데이터가 잠시 보관되는 곳으로 데이터베이스보다 훨씬 빠르다.

성능 개선 및 데이터베이스의 부하를 줄일 수 있다.

캐시 사용 시 유의할 점

• 데이터 갱신은 자주 일어나지 않지만 참조가 빈번할 때 사용
• 중요 데이터는 여전히 지속적 저장소에 두자
• 만료 기간을 적절한 기간으로 설정해놓자
• 캐시 서버를 한 대만 두는 경우 해당 서버가 단일 장애 지점(Single Point of Failure, SPOF)이 될 수 있다. → 여러 지역에 걸쳐 캐시 서버를 분산시켜야 한다.
• 캐시 메모리가 작으면 데이터가 자주 캐시에서 밀려나(eviction) 캐시 성능이 저하된다. → 캐시 메모리를 과할당(overprovision) 시켜 캐시에 보관될 데이터가 갑자기 늘어났을 때 문제를 방지한다.
• 데이터 방출 정책(eviction)은 캐시가 꽉 찼을 때, 기존 데이터를 내보내는 것이다. 가장 많이 사용하는 것은 LRU(Least Recently Used). LFU(Least Frequency Used)와 FIFO 정책도 있다.

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

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

이미지, 비디오, CSS, JS파일 등을 캐시할 수 있다.

CDN 사용 시 고려해야 할 사항

• 비용
• 만료 시한 설정
• CDN 장애에 대한 대처 방안
• 콘텐츠 무효화(invalidation) 방법
  • CDN 서비스 사업자가 제공하는 API 이용
  • 콘텐츠의 다른 버전을 서비스하도록 오브젝트 버저닝 이용

무상태(stateless) 웹 계층

웹 계층을 수평적으로 확장하는 방법을 고민해보자.

상태 정보(사용자 세션 데이터 같은)를 웹 계층에서 제거해야 한다. → 상태 정보를 저장소에 보관하고 필요할 때 가져온다.

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

같은 클라이언트의 요청은 항상 같은 서버로 전송되어야 한다.

대부분 로드밸런서가 sticky session 기능을 제공하고 있는데, 이는 로드밸런서에 부담을 준다.

무상태 아키텍처

상태 정보가 필요할 경우 공유 저장소로부터 데이터를 가져온다.

데이터 센터

장애가 없는 상황에서 가장 가까운 데이터 센터로 안내되는데, 이 절차를 지리적 라우팅(geoDNS-routing 또는 geo-routing)이라고 부른다.

다중 데이터센터 아키텍처를 만들려면 몇 가지 기술적 난제를 해결해야 한다.

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

메시지 큐

메시지 큐는 메시지의 무손실을 보장하는, 비동기 통신을 지원한다.

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

• 로그 : 에러 로그를 모니터링하는 것은 중요하다.
• 메트릭 : 메트릭을 잘 수집하면 사업에 대한 유용한 정보를 얻거나 시스템의 상태를 빠르게 파악할 수 있다.
  • 호스트 단위 메트릭 : CPU, 메모리, 디스크 I/O
  • 종합(aggregated) 메트릭: 데이터베이스 계층의 성능, 캐시 계층의 성능
  • 핵심 비즈니스 메트릭: 일별 능동 사용자, 수익, 재방문
• 자동화 : CI, 빌드, 테스트, 배포 등의 절차를 자동화할 수 있다.

데이터베이스의 규모 확장

저장할 데이터가 많아지면 데이터베이스에 대한 부하도 증가한다.

데이터베이스의 규모 확장법

1. 수직적 확장
2. 수평적 확장 : 샤딩(sharding)이라고도 부르는데, 더 많은 서버를 추가함으로써 성능을 향상시킨다.

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

시스템을 최적화하고 더 작은 단위의 서비스로 분할해야 한다.

(대규모 시스템 설계 기초)