[대규모 시스템 설계 기초] 01. 사용자 수에 따른 규모 확장성

in Devlog on Book, Study



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

단일서버 (웹/모바일 트래픽 처리 용도)

데이터 베이스 (DB 서버)

  • 대체적으로 이렇게 사용한다. DB의 부하량과 웹 트래픽의 부하량을 한 서버에 받으면 무리가 되니 분리하여 사용.

어떤 DB 사용?

관계형 데이터 베이스

  • 데이터를 테이블, 열, 칼럼으로 표현
  • 여러 테이블을 관계에 따라 조인하여 데이터 사용

[선택 고려 사항]

  • 데이터의 정합성이 중요

비관계형 데이터 베이스

  • 키-값 저장소, 그래프 저장소, 칼럼 저장소, 문서 저장소 => 4분류로 나뉘어짐
  • 일반적으로 조인 연산 미지원

[선택 고려 사항]

  • 아주 낮은 응답 지연시간 요구
  • 비정형 데이터 사용
  • 데이터의 단순 역/직렬화만 필요함
  • 많은 양의 데이터를 저장할 경우

수직적 vs 수평적 규모 확장

수직적 규모 확장 (Scale Up)

  • 서버에 고사양 자원을 추가하여 성능을 개선

수평적 규모 확장 (Scale Out)

  • 더 많은 서버를 추가하여 성능을 개선

[단점]

  • 하드웨어 증설이다 보니 한계가 있음.
  • 장애의 자동복구나 다중화 방안을 제시하지 않는다.

서버의 폭발적인 트래픽을 핸들링하기 위해서(failover 핸들링) 부하 분산기 혹은 로드밸런서를 도입한다.

로드밸런서

image-20231011181043135

로드밸런서의 공개 IP주소로 사용자가 접속하고, 로드밸런서가 서버에게 요청을 한다.

[장점]

  • 유동적으로 서버를 추가할 수 있다.
  • 일부 서버가 다운되더라도 다른 서버로 트래픽을 옮기면 된다.

데이터베이스 다중화

image-20231011181356994

보통은 서버사이에 master-slave 관계를 설정하고 원본은 주서버에, 사본은 부서버에 저장한다.

  • 쓰기연산은 마스터에서만 지원. 부 DB는 주 DB에서 사본을 전달받고 read만을 지원.

[장점]

  • (더 나은 성능) CQRS처럼 쓰기연산과 읽기연산이 분리되어있어 성능이 좋아짐.
  • (안정성) 여러 디비에 다중화 시키기 때문에 일부가 파괴되어도 데이터는 보존될 수 있음.
  • (가용성) 여러 지역에 복제가 되어 일부 서버에 장애가 발생해도 서비스가 가능함.

로드밸런서와 데이터베이스 다중화를 고려한 설계안

image-20231011181855721

캐시

자주 참조되는 데이터를 메모리 안에 두고 요청 시간을 줄이는 방법.

읽기 주도형 캐시 전략

image-20231018003634050

유의점

  • 어떤 상황에 써야하는가?
    • 데이터 갱신은 자주 일어나지 않지만 참조가 빈번하게 일어난다면.
  • 어떤 데이터를 캐시에 두어야하는가?
    • 영속적인 데이터는 안된다. 참조하기 좋은 데이터.
  • 어떻게 만료되는가?
    • 리텐션. 만료기한은 데이터의 사용 특성에 따라 처리.
  • 일관성은 어떻게 유지되는가?
    • 일관성: 데이터 저장소의 원본과 캐시내의 사본이 같은지?
    • 원본 갱신 연산과 캐시 갱신 연산이 단일 트랜잭션으로 처리되지 않는 경우 깨질 가능성이 있다. ‘쨌든 원래 어렵다.’ 빠르게 처리하는 수밖에.
  • 장애 대처는?
    • 캐시 서버가 한대만 있는경우 단일 장애 지점(SPOF)이 되어버릴 가능성이 있다. 여러 지역에 걸쳐 캐시서버를 분산시켜야 한다.
  • 캐시메모리는 얼마나 크게 잡을 것인지?
    • 너무 작으면 금방 데이터가 밀린다. 과할당하자.
  • 데이터 방출 정책이란?
    • 기존 데이터를 제거하는 것.
    • 가장 널리 쓰이는건 LRU(Least Recently Used), LFU(Least Frequently Used), FIFO

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

정적 콘텐츠를 전송하는데 쓰이는 지리적으로 분산된 서버의 네트워크. (이미지, 비디오, js 파일 등을 캐시)

동작방식

image-20231018005220502

  1. 어떤 사용자가 웹사이트 방문
  2. 가장 가까운 CDN 서버가 정적 콘텐츠 전달

고려사항

  • 비용
    • 보통 서드파티에 의해 운영되기 때문에 데이터 전송양에 따라 요금을 내게 됨.
  • 만료 시한
    • 시의성이 중요한 콘텐츠의 경우 만료 시점을 잘 정해야함. 너무 길지도, 짧지도 않게.
  • 장애에 대한 대처 방안
    • CDN이 무응답일 경우, 문제 감지 후 원본 서버로부터 직접 콘텐츠를 가져오도록 클라이언트 구성.
  • 콘텐츠 무효화
    • 만료되지 않은 콘텐츠라하더라도 아래 방법 가운데 하나를 써서 CDN에서 제거.
      1. CDN 서비스 사업자가 제공하는 API를 이용
      2. 다른 버전을 서비스하도록 오브젝트 버저닝 이용. (URL 마지막에 버전 번호 인자를 줌)

무상태 웹 계층

상태 정보(사용자 세션 데이터 등)를 DB나 NoSQL 같은 지속성 저장소에 보관하고, 필요할 때 가져오도록 하여 웹 계층을 수평적으로 확장 할 수 있는 웹 계층.

상태 정보 의존적 아키텍처

image-20231018014008835

  • 같은 클라이언트로부터의 요청은 항상 같은 서버로 전송 되어야 한다.
    • 대부분의 로드밸런서가 고정 세션(sticky session)이라는 기능을 제공하고 있는데 부담도 되고, 서버를 유동적으로 제어하기 힘들어진다.

무상태 아키텍처

image-20231018014315267

  • 어떠한 웹서버로 전달해도 사용자의 상태정보를 공유 저장소에서 가져올 수 있기 때문에 단순하고 안정적이다.

데이터 센터

사용자의 가장 가까운 데이터 센터로 안내되는 것을 지리적 라우팅이라고 한다.

지리적 라우팅의 geoDNS는 위치에 따라 어떤 IP주소로 변환할지 결정하는 DNS 서비스이다.

image-20231018014701971

다중 데이터 센터 아키텍처를 만드려면

  • 트래픽 우회
    • 올바른 데이터 센터로 트래픽을 보내는 효과적인 방법을 찾아야 함.
  • 데이터 동기화
    • 데이터센터마다 별도 DB를 사용하고 있을 경우 다른 DB로 우회된대도 찾는 데이터가 없을 수 있다. 보편적으로 여러 데이터센터에 걸쳐 다중화 하는 것이 좋은 방법이다.
  • 테스트와 배포
    • 자동화된 배포 도구는 모든 데이터 센터에 동일한 서비스가 설치되도록 하는데 중요한 역할을 한다.

메시지 큐

  • 무손실을 보장하는 비동기 통신을 지원하는 컴포넌트
  • 메시지의 버퍼 역할을 하며, 비동기적으로 전송

작동 방식

image-20231018020508473

  1. 생산자(producer)가 메시지를 만들어 메시지 큐에 발행(publish)한다.
  2. 구독자(consumer)에서 메시지를 받아 그에 맞는 동작을 수행한다.

특징

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

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

대규모의 서비스에는 필수적이다.

로그

  • 에러 로그를 모니터링하자.
  • 단일 서비스로 모아주는 도구를 활용하면 좋다. (ELK 스택 등)

메트릭

  • 메트릭을 잘 수집하면 유용한 정보도 얻을 수 있고, 시스템의 현재 상태를 손쉽게 파악할 수도 있다. (그라파나&프로메테우스, 데이터독 등)
    • 호스트단위 메트릭: CPU, 메모리, 디스크 IO 메트릭
    • 종합 메트릭: 데이터베이스 계층 성능, 캐시 성능
    • 핵심 비즈니스 메트릭: DAU, 수익, 재방문 등

자동화

CI, CD는 중요하다.

데이터베이스의 규모 확장

저장 데이터가 많아지면 데이터베이스에 대한 부하도 증가한다. 이때 데이터베이스를 확장하는 데는 두가지 접근법이 있다.

수직적 확장

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

[단점]

  • 하드웨어는 한계가 있어 무한 증설이 어렵다.
  • SPOF 위험성이 크다.
  • 비용이 많이 든다.

수평적 확장

샤딩이라고도 하며, 많은 서버를 추가함으로써 성능을 향상시키도록 한다.

샤딩

  • 대규모 데이터베이스를 샤드라고 부르는 작은 단위로 분할하는 기술.
  • 모든 샤드는 같은 스키마를 쓰지만 샤드에 보관되는 데이터 사이엔 중복이 없다.
  • 샤딩키를 통해 데이터를 고르게 분할할 수 있도록 하는게 가장 중요.

문제

  • 데이터의 재 샤딩
    • 샤드 소진으로 불리는 현상이 발생하면 샤드키를 계산하는 함수를 변경하고 데이터를 재배치하여야 한다. 안정 해시 기법을 활용하여 문제 해결.
      • 샤드 소진 현상: 데이터가 너무 많아져 하나의 샤드로는 더이상 감당이 불가할 때, 샤드간 데이터 분포가 균등하지 못하여 일부 공간 소모가 빨리 진행될 때
  • 유명인사 문제
    • 특정 샤드에 질의가 집중되어 서버에 과부하가 걸리는 문제. 유명인사 각각에 샤드 하나씩을 할당해야 할 수도 있고, 심지어 더 잘게 쪼개야 할 수도 있다.
  • 조인과 비정규화
    • 여러 샤드에 걸친 데이터를 조인하기가 힘들어진다. 해결 방법은 데이터베이스를 비정규화하여 하나의 테이블에서 질의가 수행될 수 있도록 한다. (일단 샤딩스피어는 지원되었음)

모든걸 적용한 전체 아키텍처

image-20231018033127845

정리

시스템 규모 확장을 위해 필요한 기법들을 다시 정리하자.

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

© 2019. by mintheon

Powered by mintheon