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

가상 면접 사례로 배우는 대규모 시스템 설계 기초를 공부하고 요약 정리한 글입니다

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

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

CDN 동작원리

1. 사용자 A가 이미지 url을 통해 image.png에 접근합니다.
2. CDN 서버의 캐시에 해당 이미지가 없는 경우, 서버는 원본 서버에 요청하여 파일을 가져옵니다.
3. 원본 서버가 파일을 CDN 서버에 반환합니다. 응답의 HTTP 헤더에는 해당 파일이 얼마나 오래 캐시 되는지 알려주는 TTL 값이 들어있습니다.
4. CDN 서버는 파일을 캐시하고 사용자 A에게 반환합니다. 이미지는 TTL에 명시된 시간이 끝날때까지 캐시됩니다.
5. 사용자 B가 같은 이미지에 대한 요청을 CDN 서버에 전송합니다.
6. 만료되지 않는 이미지에 대한 요청은 캐시를 통해 처리됩니다

CDN 사용 시 고려해야 할 상항

• 비용: CDN은 보통 제 3사업자에 의해 운영됩니다. 따라서 CDN으로 들어가고 나가는 데이터 전송 양에 따라 요금을 내야합니다. 그러므로 자주 사용되지 않는 콘텐츠는 CDN에서 빼는 것을 고려해야합니다
• 적절한 만료 시한 설정: 시의성이 중요한 콘텐츠의 경우 만료 시점을 잘 설정해야합니다. 너무 길지도 않고 짧지도 않아야합니다. 너무 길면 원본과 달라질 가능성이 높고 너무 짧으면 원본 서버에 자주 접근해야 합니다
• CDN 장애에 대한 대처 방안: CDN자체가 장애가 생겼을 때 어플리케이션은 원본 서버로부터 직접 컨텐츠를 가져오도록 클라이언트를 구성하는 것이 필요 할 수 있습니다
• 콘텐츠 무효화 방법: 아직 만료되지 않는 콘텐츠라 하더라도 아래 방법 가운데 하나를 쓰면 CDN에서 제거 할 수 있습니다
  • CDN 서비스 사업자가 제공하는 API를 통해 콘텐츠 무효화
  • 콘텐츠의 다른 버전을 서비스하도록 오브젝트 버저닝 이용

무상태(stateless) 웹 계층

웹 계층을 수평적으로 확장하는 방법을 고민해봐야 합니다.

이를 위해서는 상태정보를 웹 계층에서 제거해야합니다. 바람직한 전략은 상태정보는 데이터베이스에 저장하고 필요할 때 가져오는 것입니다.

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

상태 정보를 보관하는 서버는 클라이언트 정보, 즉 상태를 유지하여 요청들 사이에 공유되도록 합니다.

각각의 사용자 정보들은 해당하는 서버에 저장되어 있기 때문에 해당하는 서버로 요청하지 않으면 인증은 실패하게 될 것입니다. 이렇게 된 설계의 문제점은 같은 클라이언트로부터의 요청은 항상 같은 서버로 전송되어야 한다는 점입니다. 대부분 로드밸런서가 이를 지원하기 위해 고정세션 기능을 제공하지만 이 기능은 로드밸런서에 부담을 줍니다.

무상태 아키텍처

이 구조에서는 사용자로부터 HTTP 요청은 어떤 웹서버로도 전달 될 수 있습니다. 웹 서버는 상태 정보가 필요할 경우 공유 저장소로부터 데이터를 가져와서 처리하면 됩니다. 이런 구조는 단순하고 안정적이며, 규모 확장이 쉽습니다.

이런 구조에서는 상태 정보가 웹 서버로들부터 제거되었으므로, 트래픽 양에 따라 웹 서버를 넣거나 빼기만 하면 자동으로 규모를 확장할 수 있습니다.

데이터 센터

위의 설계는 두 개의 데이터 센터를 이용하는 사례입니다. 장애가 없는 평소의 상황에서는 사용자는 가장 가까운 데이터 센터로 안내되는데 이를 지리적 라우팅이라고 부릅니다. 지리적 라우팅에서의 geoDNS는 사용자의 위치에 따라 도메인 이름을 어떤 ip주소로 변환할지 결정해주는 DNS서비스입니다

두 개의 데이터 센터에서 하나에 장애가 터지면 모든 트래픽은 한 곳으로 몰리게 됩니다.

이 사례와 같은 다중 데이터 센터 아키텍처를 만드려면 몇가지 기술적 난제를 해결해야합니다.

• 트래픽 우회: 올바른 데이터 센터로 트래픽을 보내는 효과적인 방법을 찾아야합니다
• 데이터 동기화: 데이터 센터마다 별도의 데이터 베이스를 사용하고 있는 상황이라면, 장애가 복구되어 다른 데이터 베이스를 참조한다 해도 찾는 데이터가 없을 수 있습니다. 이런 상황을 막는 보편적 전략은 데이터를 여러 데이터 센터에 걸쳐 다중화 하는 것입니다.
• 테스트와 배포: 여러 데이터 센터를 사용하도록 시스템이 구성된 상황이라면 웹 사이트 또는 애플리케이션을 여러 위치에서 테스트 해보는 것이 중요합니다.

메세지 큐

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

메세지의 버퍼 역할을 하며, 비동기 적으로 전송합니다. 메세지 큐의 기본 아키텍처는 Pub/Sub 구조입니다. 입력서비스가 메세지를 만들어 큐에 publish를 하면 소비자가 subscribe를 하는 구조입니다.

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

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

서비스의 규모가 커지면 로그나 메트릭, 자동화 도구에 필수적으로 투자해야합니다.

• 로그: 에러 로그를 모니터링하는 것은 중요합니다. 오류나 문제들을 쉽게 찾아내서 디버깅의 효율을 높여줍니다.
• 메트릭: 메트릭을 잘 수집하면 사업 현황에 관한 유용한 정보를 얻을 수도 있고, 시스템의 현재 상태를 손쉽게 파악할 수도 있습니다.
• 자동화: 시스템이 크고 복잡해지면 생산성을 높이기 위해 자동화 도구를 활용해야 합니다. CI/CD를 지원하는 자동화 도구를 세팅해놓으면 문제를 쉽게 감지 해낼 수 있고 빌드, 테스트, 배포 절차를 자동화 할 수 있어서 개발생산성을 크게 향상시킬 수 있습니다.

데이터베이스의 규모 확장

저장할 데이터가 많아지며 데이터베이스에 대한 부하도 증가합니다. 그때가 오면 데이터베이스를 증설할 방법을 찾아야합니다.

그 방법에 두 가지 접근법이 있는데 하나는 수직적 규모 확장과 다른 하나는 수평적 규모 확장이 있습니다.

수직적 확장

스케일업이라고 불리는 이 방법은 고성능의 자원을 투자해 증설하는 방법입니다.

몇가지 단점이 있습니다

• 서버 하드웨어 한계로 인해 무한 증설이 불가능 합니다.
• SPOP(단일 장애 포인트)로 인한 위험성이 큽니다
• 비용이 많이 듭니다

수평적 확장

데이터베이스의 수평적 확장은 샤딩이라고 불립니다. 더 많은 서버를 추가함으로써 성능을 향상 시킬수 있도록 합니다

샤딩을 도입하면서 고려해야할 것들

• 데이터의 재 샤딩
• 유명인사 문제
• 조인과 비정규화

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

시스템 규모확장을 위한 살펴본 기법들을 다시 한번 정리해보면 다음과 같습니다

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