가상면접사례로 배우는 대규모 시스템 설계 기초(3)

오늘 배운 것

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

앞서 로드밸런서로 웹 서버 부하분산, DB 다중화로 DB부하 분산 성공.

응답시간을 줄이기 위해 캐시와 정적 콘텐츠는 CDN을 도입하라. (동적 콘텐츠도 되긴 하는데 범위를 벗어남)

Stateless 웹 계층

이제 웹 계층을 수평적으로 확장해 보자. 이를 위해서는 상태정보를 웹 계층에서 제거해야 한다.

바람직한 전략은 상태정보를 RDB, NoSQL에 넣어두고 필요할때 가져오는거다.

state 의존적인 아키텍처

state를 보관하는 서버는 클라이언트 정보, 즉 state를 유지해서 요청들 사이에 공유되게 해야 한다.

문제는 같은 클라이언트로부터의 요청은 항상 같은 서버로 전송되어야 한다는 것이다. 대부분의 로드밸런서가 이를 지원하기위해 고정 세션 이라는 기능을 제공하고 있는데, 로드밸런서에 부담을 준다. 뒷단에 서버를 추가하거나 제거하기도 까다로워진다.

stateless 아키텍처

상태정보를 여러 서버의 공유 저장소에 두는 경우

데이터센터

만약에 더욱 서비스가 커진다면, 데이터 센터를 지원하는 것이 필수다.로드밸런서 이후 원래는 바로 웹서버 집합으로 연결이 됐다면, 이제는 지리적 라우팅 을 통해 가까운 서버 집합으로 이동한다. US-east, Asia-Seoul… / 70%는 us-east, 나머지 30%는 us-west라던지..

그리고 한쪽이 장애 나도 다른쪽으로 라우팅된다.

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

1. 트래픽 우회

   올바른 데이터 센터로 트래픽을 보내는 방법을 찾아야 한다. GeoDNS는 사용자에게 가장 가까운 데이터 센터로 트래픽을 보낸다.

2. 데이터 동기화

   데이터 센터마다 별도의 데이터베이스를 사용한다면, 장애가 자동으로 복구(failover)되어 트래픽이 다른 DB로 우회된다 하더라도 해당 DB에는 찾는 데이터가 없을 수 있다. 이런 상황을 막기위해 데이터를 여러 데이터센터에 걸쳐 다중화 하는 것이다. Neflix가 어떻게 데이터를 다중화 하는지 찾아보라. https://netflixtechblog.com/active-active-for-multi-regional-resiliency-c47719f6685b

메시지 큐

메시지 큐는 메시지의 무손실(durability)을 보장하는, 비동기 통신 을 지원하는 컴포넌트다. 메시지 큐의 기본 아키텍처는 pub sub구조다.

메세지 큐를 이용하면 서버 간 결합이 느슨해져서, 규모 확장성이 보장되야 하는 안정적 가능

왜? 생산자는 소비자가 다운되어도 메시지를 발행할 수 있고, 소비자는 생산자가 죽어도 남은걸로 메세지를 수신 가능하다.

시간이 오래걸리는 배치작업에 대해, 요청을 일단 보내놓고 다른일 하다보면 작업 다 했다고 오면 그때 응답을 보면 된다.

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

웹사이트와 사업규모가 커지면 이런것들이 중요해진다.

• 로그 : 에러 로그를 모니터링하면 시스템의 오류와 문제를 잘 찾을 수 있다. 서버 단위로 모니터링 할 수도 있지만, 단일 서비스로 모아주는 도구를 활용하면 더 편하다.

• 메트릭 : 잘 수집하면 사업 현황 정보를 얻을 수 있다. 시스템의 현재 상태도 쉽게 파악.

  • 호스트 단위 메트릭 : CPU, 메모리, Disk I/O에 관한 메트릭
  • 종합(aggregated)메트릭 : DB 계층의 성능, 캐시 계층의 성능
  • 핵심 비즈니스 메트릭 : 일별 능동 사용자(DAU), 수익, 재방문

• 자동화 : 시스템이 크고 복잡해지면 자동화 도구를 활용해야 한다. CI를 도와주는 도구를 쓴다거나.

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

메세지 큐를 도입해 요청서버-작업서버를 분리해서 느슨히 결합, 결함 내성 상승 로그, 메트릭 자동화 툴 도입.

데이터베이스의 규모 확장

두가지 접근법, 서버와 마찬가지로 수직, 수평적 확장.

수직적 확장 = 스케일 업

고성능의 자원(cpu, ram, ssd)을 증설. 예를들어, 스택오버플로우는 2013년 1년에 방문한 10,000,000명의 사용자 전부를 1대의 마스터 DB로 처리했다.

그러나 웹서버와 마찬가지로 약점이 있다.

1. 무한한 스케일업 불가능
2. SPOF 가능성 (단일 장애 지점)
3. 비용이 많이 든다.

수평적 확장

웹서버의 수평적 확장은 로드밸런서.

DB의 수평적 확장은 샤딩.

샤딩이란 대규모 DB를 샤드 라고 하는 작은 단위로 분할하는 기술을 말한다. 모든 샤드는 같은 스키마를 갖지만, 중복이 없다.

예를들어, user_id % 4를 통해 4개의 샤드에 샤딩이 가능하다.

샤딩 전략을 구현할때 가장 중요한 것은, 샤딩 키 를 어떻게 정하느냐 이다. 샤딩 키 = 파티션 키 는 데이터가 어떻게 분산될 지 정하는 하나 이상의 칼럼이다. 샤딩을 도입하면 시스템이 복잡해지고, 새로운 기술 문제가 생긴다.

1. 데이터의 재 샤딩은 다음 경우 필요하다.

   • 데이터가 너무 많아서 하나의 샤드로 감당할 수 없는 경우
   • 분포가 균등하지 않아 샤드 소진이 일어날 경우 (5장의 안정 해시)

2. 유명인사 문제, 핫스팟 키 라고도 한다. : 특정 샤드에 query가 집중되어 서버 과부하. sns 서비스 DB에서 레이디 가가, 저스틴 비버 가 하나의 샤드에 몰려있으면 쏠린다.

3. 조인과 비정규화 : 일단 하나의 DB를 여러 샤드로 쪼개고 나면, 여러 샤드에 걸친 데이터를 조인하기 힘들어진다. 이를 해결하는 한 가지 방법은 비정규화를 통해 하나의 테이블에서 쿼리를 하는것이다.

1M 사용자, 그 이상

시스템의 규모 확장은 지속적이고, 반복적인 작업이다. 이번 장에서 다룬 내용. 웹 서버 - 로드밸런서, DB - 다중 마스터, 응답시간 - 캐시 CDN, 웹 계층 - stateless, 데이터 센터, 메시지큐 , DB규모확장 - 샤딩

근데 수백만 사용자 이상을 감당하려면 새로운 전략이 필요하다.

하여튼 이 장에서 다룬 원칙은 다음과 같다.

• 웹 계층은 stateless로
• 모든 계층에 다중화 도입 (로드밸런서, DB)
• 가능한 많은 데이터를 캐시
• 여러 데이터 센터를 지원
• 정적 콘텐츠는 CDN으로 지원
• 데이터 계층은 샤딩을 통해 규모를 확장하라.
• 각 계층은 독립적 서비스로 분할하라.
• 시스템을 지속적으로 모니터링하고 자동화 도구를 활용하라.