Evan's garden

Search

Search IconIcon to open search

대규모 시스템 설계 기초 1장

Last updated Unknown Edit Source

한명의 사용자를 지원하는 시스템에서 시작하여, 최종적으로는 몇백만 사용자를 지원하는 시스템을 설계할 것이다

# 단일 서버

웹앱, 데이터베이스 , 캐시 드잉 전부 한 대에서 실행

# 데이터 베이스

사용자가 늘면 서버 하나로 처리는 충분치 않아, 데이터 서버 를 분리 하면 각가을 독립적으로 확장할 수있음

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

  1. 관계형 데이터베이스
    1. 자료를 테이블과 열, 칼럼으로 표현
  2. 비관계형 데이터 베이스
    1. 키-값 저장소, 그래프 저장소, 칼럼 저장소, 문서 저장소

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

트래픽이 많아질 경우, 수직적 규모의 경우에 failover, redundancy 등의 방안 제시가 되지 않음.

수평적 규모 확장이 대규모 어플리케이션 지원에 적절

너무 많은 트래픽이 단일 서버에 몰리게 되면 서비스가 다운 되므로 트래픽 분산이 필요함 그로 인해 로드밸런서를 도입하는게 적절

# 로드 밸런서

부하 분산 집합에 속한 웹 서버들에게 트래픽 부하를 고르게 분산하는 역할을 한다.

A 가 다운 되면 모든 트래픽은 B 로 전송

웹 서버 계층은 이로 인해 가용성이 증대되었지만, 데이터 계층이 문제다 이제 그럼 데이터베이스를 다중화 해야한다

# 데이터 베이스 다중화

보통은 서버 사이에 Mater - Slave 를 설정하고 데이터 원본은 주 서버에 사본은 부 서버에 저장하는 방식이다. 일반적으로 Read 연산이 더 많이 일어나므로, 부 서버에서 Read 연산을 처리하고 Write 연산은 주서버에서 처리한다.

데이터 동기화 문제가 발생할 수있는데, 복구 스크립트를 돌리거나 다중 마스터나 원형다중화 등을 구성할 수있다.

웹 계층과 데이터 계층은 어느정도 해결 되었으니, 응답 시간을 개선 해보자 응답 시간은 Cache 를 붙이고 정적 콘텐츠를 CDN 으로 옮기면 개선 할 수있다.

# 캐시

캐시는 값비싼 연산 결과 또는 자주 참조되는 데이터를 메모리 안에 두고, 뒤이은 요청이 보다 빨리 처리될 수있도록 하는 저장소다. 어플리케이션의 성능은 데이터베이스를 얼마나 자주 호출하느냐에 크게 좌우되는데, 캐시는 그런 문제를 완화 할 수있다.

# 캐시 계층

Cache tier 데이터가 잠시 보관 되는 곳으로 데이터 베이스보다 훨씬 빠르며, 데이터베이스의 부하를 줄일수있음. 캐시 계층의 규모를 독립적으로 확장시키는 것도 가능

캐시 전략 종류는 다양함

# 캐시 사용시 유의점

# 컨텐츠 전송 네트워크 (CDN)

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

# 고려해야 할 사항

  1. 정적 컨텐츠를 CDN 통해 제공하여 웹 계층의 부하 줄이기
  2. 캐시를 통한 데이터 계층 부하 줄이기

# 무상태(Stateless) 웹 계층

웹 계층을 수평적으로 확장하는 방법을 고민해 보자. 상태 정보 (사용자 세션 데이터 등)을 웹 계층에서 제거해야한다. 바람직한 전략으로는, 상태 정보를 데이터 베이스에 보관하고 필요할 때 가져오도록 하는 것. 이렇게 구성된 웹 계층을 무상태 웹 계층이라고 한다.

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

서버 1 , 서버 2, 서버 3 에서 각각 사용자의 상태정보를 갖고 있게 된다면 사용자가 다른 서버로 접속시 인증이 실패하는 현상이 발생한다. 그렇기에 같은 클라이언트로 부터의 요청은 항상 같은 서버로 전송되어야하는 문제가 생긴다. 대부분의 로드 밸런서가 이를 지원하기 위해 고정 세션 (Sticky session) 이라는 기능을 제공하는데, 이는 로드밸런서에 부담을 준다. 게다가 로드 밸런서 뒷단에 서버를 추가하거나 제거하기도 까다롭고. 이들 서버의 장애를 처리하기도 복잡해진다.

# 무상태 아키텍처

웹서버는 상태정보가 필요한 경우 공유 저장소(Shared Storage) 로부터 데이터를 가져온다. 상태 정보는 웹 서버로부터 물리적으로 분리 되어있다.

이러한 구조는 안정적이고, 단순하며, 규모 확장이 쉽다.

전 세계 대상으로 쾌적하게 서비스를 제공하기 위해서는, 여러 데이터 센터를 지원하는게 필수다.

# 데이터 센터

두 개의 데이터 센터를 이용할 때, 장애가 없는 상황에서 사용자는 가장 가까운 데이터 센터로 안내되게 되는데 이 절차를 지리적 라우팅 (geoDNS-routing, geo-routing) 이라고 부른다. 지리적 라우팅에서의 geoDNS 는 사용자의 위치에 따라 도메인의 이름을 어떤 IP 주소로 변환할지 결정 할 수있도록 도와주는 DNS 서비스다.

데이터 센터에서 장애가 발생하면, 모든 트래픽이 다른 하나로 전송되는 상황이 발생한다. 이러한 다중 데이터 센터 아키텍처를 구축하기 위해서는 몇 가지 기술적인 난제를 해결해야한다.

시스템을 더 큰 규모로 확장하기 위해서는 시스템의 컴포넌트를 분리하여, 각기 독립적으로 확장 될 수 있도록 하여야한다. 메세지 큐는 많은 실제 분산 시스템이 이 문제를 풀기 위해 채용하고 있는 핵심적 전략 가운데 하나

# 메시지 큐

메시지 큐는 메시지의 무손실(durability, 메시지 큐에 일단 보관된 메시지는 소비자가 꺼낼 때까지 안전히 보관된다는 특성)을 보장하는 비동기 통신을 지원하는 컴포넌트 다. 메시지의 버퍼역할을 하며, 비동기적으로 전송한다. 생산자 또는 발행자라고 불리는 입력 서비스가 메시지를 만들어 메시지 큐에 발행 한다.

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

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

저장할 데이터가 많아지면 부하도 증가 두가지 접근 법이 있음

  1. 수직적 규모 확장
    1. 스케일 업으로, 고성능의 자원을 증설 스택오버플로는 2013년 한 해 방문한 천만 명의 사용자 전부를 한대의 마스터 데이터베이스로 처리했음
      1. 문제점
        1. 데이터 베이스 서버 하드웨어 한계가 있으므로 무한 증설은 안됨
        2. SPOF
        3. 비용이 많이듬
  2. 수평적 규모 확장
    1. 샤딩(Sharding) 이라고도 부르는데, 더 많은 서버를 추가함 으로서 성능 향상

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

다시 한번 정리하기