Skip to main content

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

단일 서버#

  • 웹 앱, 데이터베이스, 캐시 등이 전부 서버 한 대에서 실행

사용자 흐름

  • 단말은 2개 입니다.
    • 웹 애플리케이션
    • 모바일 앱

데이터베이스#

  • 사용자가 늘면 서버 하나로는 충분하지 않아, 트래픽 용과 데이터베이스용으로 분리합니다.

데이터베이스 추가

어떤 데이터베이스#

  • 대부분의 경우, 관계형 데이터베이스가 좋음
  • 비 관계형 데이터베이스가 좋은 경우는 다음과 같습니다.
    • 아주 낮은 응답 지연시간(latency)이 요구됨
    • 다루는 데이터가 비정형(unstructured)이라 관계형 데이터가 아님
    • 데이터(JSON, YAML, XML 등)를 직렬화하거나(serialize) 역직렬화(deserialize) 할 수 있기만 하면 됨
    • 아주 많은 양의 데이터를 저장할 필요가 있음.

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

  • 서버로 유입되는 트래픽의 양이 적을 때는 수직적 확장이 좋은 선택이며, 이 방법의 가장 큰 장점은 단순함입니다.
  • 그러나 아래의 단점이 있습니다.
    • 수직적 규모 확장에는 한계가 있습니다. 한 대의 서버에 CPU나 메모리를 무한대로 증설할 방법은 없습니다.
    • 수직적 규모 확장법은 장애에 대한 자동복구(failover) 방안이나 다중화(redundancy) 방안을 제시하지 않습니다. 서버에 장애가 발생시 웹사이트/앱은 완전히 중단됩니다.

로드밸런서#

  • 부하 분산 집합(load balancing set)에 속한 웹 서버들에게 트래픽 부하를 고르게 분산하는 역할을 합니다.
  • 웹 계정에서는 이와 같은 방법으로 처리합니다.

데이터베이스 다중화#

  • 많은 데이터베이스 관리 시스템이 다중화를 지원합니다. 일반적으로 주(master)과 부(slave) 관계를 설정합니다.
  • 대부분의 애플리케이션은 읽기 연산의 비중이 쓰기 연산보다 훨씬 높습니다.
  • 데이터베이스를 다중화하면 다음과 같은 이득이 있습니다.
    • 더 나은 성능 : 읽기 연산은 분산되므로, 처리될 수 있는 질의(query) 수가 늘어나서 성능이 좋습니다.
    • 안정성 : 일부가 파괴되어도 데이터는 보존 가능
    • 가용성 : 장애 발생 시, 다른 서버의 데이터로 서비스 가능

로드밸런서와 데이터베이스 다중화


캐시#

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

캐시 계층#

  • 캐시 계층은 데이터가 잠시 보관되는 곳으로 데이터베이스보다 훨신 빠릅니다.

캐시 사용시 유의점#

  • 캐시는 어떤 상황에 바람직한지?
    • 데이터 갱신은 자주 일어나지 않지만 참조는 빈번하게 일어나는 경우 고려
  • 어떤 데이터를 캐시에 두어야 하는가?
    • 캐시에 영속적 보관할 데이터를 캐시에 두는 것은 바람직하지 않습니다.
    • 캐시가 재시작되면 캐시 내의 모든 데이터는 사라집니다.
  • 캐시에 보관된 데이터는 어떻게 만료(expire)되는가?
    • 정책을 마련해 두는 것은 좋은 습관입니다.
    • 너무 짧아도 데이터베이스를 자주 읽게 때문에 문제가 되고, 너무 길어도 곤란합니다.
  • 일관성(consistency)은 어떻게 유지되는가?
    • 일관성은 데이터 저장소의 원본과 캐시 내의 사본이 같은지 여부입니다.
  • 장애에는 어떻게 대처할 것인가?
    • SPOF(단일 장애 지점)을 피하려면 여러 지역에 걸쳐 캐시 서버를 분산시켜야 합니다.
  • 캐시 메모리는 얼마나 크게 잡을 것인가?
    • 캐시 메모리가 너무 작으면 액세스 패턴에 따라서는 데이터가 너무 자주 캐시에서 밀려나서 캐시 성능이 떨어집니다.
  • 데이터 방출(eviction) 정책은 무엇인가?
    • 캐시가 꽉 차버리면 추가로 캐시에 데이터를 넣어야 할 경우 기존 데이터를 내보내야 합니다.

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

  • 정적 콘텐츠를 전송하는 데 쓰이는, 지리적으로 분산된 서버의 네트워크입니다.
  • 동적 콘텐츠 캐싱은 상대적으로 새로운 개념도 있습니다.
    • 간단하게 이야기하면, 경로, 질의 문자열, 쿠키, 요청 헤더 등의 정보에 기반하여 HTML 페이지를 캐시하는 것입니다.
  • 아래에서는 정적 CDN에 대해서만 이야기합니다.

CDN 사용 시 고려해야 할 사항#

  • 비용 : 자주 사용되지 않는 콘텐츠를 캐싱하는 것은 이득이 크지 않습니다.
  • 적절한 만료 시한 설정 : 시의성이 중요한(Time-sensitive) 콘텐츠의 경우 만료 시점을 잘 정해야 합니다.
  • CDN 장애에 대한 대처 방안 : CDN 자체가 죽었을 때 웹사이트/애플리케이션이 어떻게 동작해야 하는지 고려해야 합니다.
  • 콘텐츠 무효화(invalidation) 방법
    • CDN 서비스 사업자가 제공하는 API를 이용하여 콘텐츠 무효화
    • 콘텐츠의 다른 버전을 서비스하도록 오브젝트 버저닝(object versioning) 이용

무상태(stateless) 웹 계층#

  • 웹 계층을 수평적으로 확장하는 방법은 다음과 같습니다.

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

  • 상태 정보를 보관하는 서버는 클라이언트 정보, 즉 상태를 유지하여 요청들 사이에 공유되도록 합니다.
  • 무상태 서버에는 이러한 장치가 없습니다.
  • 문제 중 하나는 같은 클라이언트로부터의 요청은 항상 같은 서버로 전송해야 한다는 문제가 있습니다.
  • 이는 로드밸런서에 부담을 줍니다.

무상태 아키텍처#

무상태 아키텍처

  • 단순하고, 안정적이며, 규모 확장이 쉽습니다.

데이터 센터#

  • 데이터 센터를 이용하는 사례는 다음과 같습니다.

다중 데이터센터

  • 다음의 난제를 해결해야 합니다.
    • 트래픽 우회: 올바른 데이터 센터로 트래픽을 보내는 효과적인 방법을 찾아야합니다. (ex. GeoDNS)
    • 데이터 동기화(synchronization): 데이터 센터마다 별도의 데이터베이스를 사용하려면 이를 다중화 해야합니다.
    • 테스트와 배포(deployment): 여러 테스트 및 자동화 배포 도구 등이 필요합니다.
  • 시스템을 더 큰 규모로 확장하기 위해서는 시스템의 컴포넌트를 분리하여 각기 독립적으로 확장될 수 있도록 하여야 합니다.

메시지 큐#

  • 메시지 큐는 메시지의 무손실(durability))을 보장하는 비동기 통신을 지원하는 컴포넌트입니다.
  • 메시지 큐를 이용하면 서비스 또는 서비스 또는 서버 간 결합이 느슨해져서, 규모 확장성이 보장되어야 하는 안정적 애플리케이션을 구성하기 좋습니다.

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

  • 서비스가 커질 수록, 여러 도구들이 반드시 필요합니다.
    • 로그: 에러 로그를 모니터링하는 것은 중요합니다.
    • 메트릭: 메트릭을 잘 수집하면 사업 현황에 관한 유용한 정보를 얻을 수 있습니다.
      • 호스트 단위 매ㅔ트릭: CPU, 메모리, 디스크 I/O 등
      • 종합(aggregated) 메트릭: 데이터베이스 계층의 성능, 캐시 계층의 성능 등
      • 핵심 비즈니스 메트릭: 일별 능동 사용자, 수익, 재방문 등
    • 자동화: 시스템이 크고 복잡해지면 생산성을 높이기 위해 자동화 도구를 활용해야 합니다.

메시지 큐, 로그, 메트릭, 자동화 등을 반영하여 수정한 설계안#

메시지 큐, 로그 등 추가


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

  • 저장할 데이터가 많아지면 데이터베이스에 대한 부하도 증가합니다.
  • 두가지 접근법이 있습니다.

수직적 확장#

  • 기존 서버에 더 좋은 고성능의 자원을 증설하는 방법입니다.
  • 다음의 약점이 있습니다.
    • 한계가 있습니다.
    • SPOF(Single Point of Failure)로 인한 위험성이 큽니다.
    • 비용이 많이 듭니다. 고성능 서버로 갈수록 가격이 올라갑니다.

수평적 확장#

  • 수평적 확장은 샤딩입니다.
  • 샤딩은 대규모 데이터베이스를 샤드라고 부르는 작은 단위로 분할하는 기술을 의미합니다.
  • 샤딩 전략에서 가장 중요한 것은 샤딩 키를 어떻게 정하느냐의 문제입니다.
  • 다음의 문제를 고려해야합니다.
    • 데이터의 재샤딩 : 데이터가 너무 많아져서 하나의 샤드로 감당이 힘들때 분리합니다.
    • 유명인사 문제: 핫스팟 키, 특정 샤드에 질의가 집중되는 문제입니다.
    • 조인과 비정규화: 여러 샤드에 걸치 데이터를 조인하기가 힘들어집니다.

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

  • 시스템의 규모를 확정하는 것은 지속적이고 반복적(iterative)인 과정입니다.
  • 시스템을 최적화하고 더 작은 단위의 서비스로 분할해야 할 수도 있습니다.
  • 기법을 정리하면 다음과 같습니다.
    • 웹 계층은 무상태 계층으로
    • 모든 계층에 다중화 도입
    • 가능한 한 많은 데이터를 캐시할 것
    • 여러 데이터 센터를 지원할 것
    • 정적 콘텐츠는 CDN을 통해 서비스할 것
    • 데이터 계층은 샤딩을 통해 그 규모를 확장할 것
    • 각 계층은 독립적 서비스로 분할할 것
    • 시스템을 지속적으로 모니터링하고, 자동화 도구를 활용할 것
Edit this page
Last updated on