대규모 설계 기초

[System Design Interview] 1장 사용자 수에 따른 규모 확장성

Wanderer Kim 2023. 6. 11. 16:30
728x90

 

단일 서버

사용자 처리 흐름

1. 사용자는 도메인 이름을 이용하여 웹사이트에 접속한다.

2. DNS 조회 결과로 IP 주소가 반환된다.

3. 해당 IP 주소로 HTTP요청이 전달된다.

4. 요청을 받은 웹 서버는 HTML 페이지나 JSON 형태의 응답을 반환한다.

데이터베이스

사용자가 늘면 서버 하나로는 충부낳지 않아서 여러 서버를 두어야 한다. 하나는 웹/모바일 트래픽 용도고, 다른 하나는 데이터베이스 용이다. 이렇게 분리하면 각각을 독립적으로 확장해 나갈 수 있게 된다.

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

관계형 데이터베이스와 비-관게형 데이터베이스 사이에서 고를 수 있다.

대부분의 경우 관계형 데이터베이스가 최선일 것인데, 40년 이상 시장에서 살아남아 잘 사용되어 온 시스템이기 때문이다. 하지만 아래와 같은 경우에는 비-관계형 데이터베이스가 바람직한 선택일 수 있다.

  • 아주 낮은 응답 지연시간이 요구됨
  • 다루는 데이터가 비정형이라 관계형 데이터가 아님
  • 데이터를 직렬화하거나 역직렬화 할 수 있기만 하면 됨
  • 아주 많은 양의 데이터를 저장할 필요가 있음

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

  • 스케일 업(수직적 규모 확장) : 서버에 고사향 자원을 추가하는 행위를 말한다.
  • 스케일 아웃(수평적 규모 확장) : 더 많은 서버를 추가하여 성능을 개선하는 행위를 말한다.

서버로 유입되는 트래픽의 양이 적을 때는 수직적 확장이 좋은 선택이며, 이 방법의 가장 큰 장점은 단순함이다. 그러나 이 방법에는 몇가지 단점이 있다.

  • 수직적 규모 확장에는 한계가 있다. 한 대의 서버에 CPU나 메모리를 무한대로 증설할 방법은 없다.
  • 수직적 규모 확장법은 장애에 대한 자동복구 방안이나 다중화 방안을 제시하지 않는다. 서버에 장애가 발생하면 웹사이트/앱은 완전 중단된다.

이러한 단점 때문에, 대규모 애플리케이션을 지원하는 데는 수평적 규모 확장법이 보다 적절하다.

로드밸런서

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

부하 분산 집합에 또 하나의 웹 서버를 추가하고 나면 장애를 자동복구하지 못하는 문제는 해소되며, 웹 계층의 가용성을 향상된다.

데이터베이스 다중화

데이터베이스 다중화를 통해 데이터베이스 서버 장애시 대처를 할 수 있다.

보통 서버 사이에 주-부 관계를 설정하고 데이터 원본은 주 서버에, 사본은 부 서버에 저장하는 방식을 사용한다.

쓰기 연산은 마스터에서만 지원한다. 부 데이터베이스는 주 데이터베이스로부터 그 사본을 전달받으며, 읽기 연산만을 지원한다. 대부분의 애플리케이션은 읽기 연산의 비중이 쓰기 연산보다 훨씬 높다. 따라서 통상 부 데이터베이스의 수가 주 데이터베이스의 수보다 많다.

데이터베이스를 다중화하면 다음과 같은 이득이 있다.

  • 더 나은 성능 : 모든 데이터 변경 연산은 주 데이터베이스 서버로만 전달되는 반면 읽기 연산은 부 데이터베이스 서버들로 분산된다. 병렬로 처리될 수 있는 질의의 수가 늘어나므로, 성능이 좋아진다.
  • 안정성 : 자연 재해 등의 이유로 데이터베이스 서버 가운데 일부가 파괴되어도 데이터는 보존될 것이다.
  • 가용성 : 데이터를 여러 지역에 복제해 둠으로써, 하나의 데이터베이스 서버에 장애가 발생하더라도 다른 서버에 있는 데이터를 가져와 계속 서비스할 수 있게 된다.

그림1-6은 로드밸런서와 데이터베이스 다중화를 고려한 설계안이다.이 설계안은 다음과 같이 동작한다.

  • 사용자는 DNS로부터 로드밸랜서의 공개 IP 주소를 받는다.
  • 사용자는 해당 IP 주소를 사용해 로드밸런서에 접속한다.
  • HTTP 요청은 서버 1이나 서버 2로 전달된다.
  • 웹 서버는 사용자의 데이터를 부 데이터베이스 서버에서 읽는다.
  • 웹 서버는 데이터 변경 연산을 주 데이터베이스로 전달한다.

캐시

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

캐시 계층

캐시 계층은 데이터가 잠시 보관되는 곳으로 데이터베이스보다 훨씬 빠르다. 별도의 캐시 계층을 두면 성능이 개선될 뿐 아니라 데이터베이스의 부하를 줄일 수 있고, 캐시 계층의 규모를 독립적으로 확장시키는 것도 가능해진다.

  • 읽기 주도형 캐시 전략(read-through caching strategy) : 요청을 받은 웹 서버는 캐시에 응답이 저자오디어 있는지를 본다. 만일 저장되어 있다면 해당 데이터를 클라이언트에 반환한다. 없는 경우에는 데이터베이스 질의를 통해 데이터를 찾아 캐시에 저장한 뒤 클라이언트에 반환하는 전략.

캐시 사용 시 유의할 점

  • 데이터 갱신은 자주 일어나지 않지만 참조는 빈번하게 일어난다면 캐시를 고려해볼 만하다.
  • 캐시는 데이터를 휘발성 메모리에 두므로, 영속적으로 보관할 데이터를 캐시에 두는 것은 바람직하지 않다.
  • 캐시에 보관된 데이터의 만료 정책을 마련해 두는 것이 좋다.
  • 일관성 유지를 위한 전략을 잘 마련해 놓는 것이 좋다.
  • 장애 대처에 대한 정책을 마련해 놓는다.
  • 캐시 메모리에 대한 정책을 마련해 놓는다.
  • 데이터 방출 정책을 마련해 놓는다.

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

CDN은 정적 콘텐츠를 전송하는 데 쓰이는, 지리적으로 분산된 서버의 네트워크이다. 이미지, 비디오, CSS, JavaScript 파일 등을 캐시할 수 있다.

CDN 사용 시 고려해야 할 사항

  • 비용
  • 적절한 만료 시한 설정
  • CDN 장애에 대한 대처 방안
  • 콘텐츠 무효화 방법

그림 1-11은 CDN이 추가된 설계이다.

무상태 웹 계층

웹 계층을 수평적으로 확장하기 위해서는 상태 정보를 웹 계층에서 제거하여야 한다. 좋은 방법은 상태 정보를 관계형 데이터베이스나 NoSQL 같은 지속성 저장소에 보관하고, 필요할 때 가져오도록 하는 것이다.

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

무상태 아키텍쳐

그림 1-13과 같은 구조에서 웹 서버는 상태 정보가 필요할 경우 공유 저장소로부터 데이터를 가져온다. 따라서 상태 정보는 웹 서버로부터 물리적으로 분리되어 있다.

그림 1-14는 무상태 웹 계층을 갖도록 변경한 설계이다.

 

데이터 센터

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

만약 데이터 센터 중 하나에 심각한 장애가 발생하면 모든 트래픽은 장애가 없는 데이터 센처로 전송된다.

메시지 큐

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

메시지 큐를 이용하면 서비스 또는 서버 간 결합이 느슨해져서, 규모 확장성이 보장되어야 하는 안정적 애플리케이션을 구성하기 좋다.

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

  • 로그 : 에러 로그를 모니터링하는 것은 중요하다. 에러 로그를 단일 서비스로 모아주는 도구를 활용하면 더 편리하게 검색하고 조회할 수 있다.
  • 메트릭 : 메트릭을 잘 수집하면 사업 현황에 관한 유용한 정보를 얻을 수도 있고, 시스템의 현재 상태를 손쉽게 파악할 수도 있다.
    • 호스트 단위 메트릭 : CPU, 메모리, 디스크 I/O에 관한 메트릭이다.
    • 종합 메트릭 : 데이터베이스 계층의 성능, 캐시 계층의 성능 같은 것이 여기에 해당한다.
    • 핵심 비즈니스 메트릭 : 일별 능동 사용자, 수익, 재방문 같은 것이 여기에 해당한다.
  • 자동화 : 시스템이 크고 복잡해지면 생산성을 높이기 위해 자동화 도구를 활용해야 한다. CI/CD 도구 같은 것을디 여기에 해당한다.

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

반응형