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

date

Jul 4, 2023

slug

book-system-design-interview-1

author

status

Public

1. 규모 확장성을 위한 준비 - 데이터베이스, 로드밸런서

아래와 같은 경우에는 비-관계형 데이터베이스가 바람직한 선택일 수 있다.

아주 낮은 응답 지연시간(latency)이 요구됨

다루는 데이터가 비정형(instructured)이라 관계형 데이터가 아님

데이터(JSON, YAML, XML)를 직렬화하거나(serialize) 역직렬화(deserialize) 할 수 있기만 하면 됨

아주 많은 양의 데이터를 저장할 필요가 있음

수직적 규모 확장보다 수평적 규모 확장이 적절하다.

Vertical scaling = scale up = 수직적 규모 확장 = 서버에 고사양 자원(더 좋은 CPU, 더 많은 RAM)을 추가

Horizontal scaling = scale out = 수평적 규모 확장 = 더 많은 서버를 추가하여 성능을 개선

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

단점1) 수직적 규모 확장법은 한계가 있다. 한 대의 서버에 CPU나 메모리를 무한대로 증설할 방법은 없다

단점2) 수직적 규모 확장법은 장애에 대한 자동복구 방안이나 다중화 방안을 제시하지 않는다. 서버에 장애가 발생하면 웹사이트/앱은 완전히 중단된다.

⇒ 따라서 대규모 애플리케이션을 지원하는 데에는 수평적 규모 확장이 적절하다.

웹 계층에 너무 많은 사용자가 접속할 때 → 부하 분산기 또는 로드밸런서 도입

웹 서버가 한계 상황에 도달하게 되면 응답 속도가 느려지거나 서버 접속이 불가능해질 수도 있다. 이 문제를 해결하는 데는 부하 분산기 또는 로드밸런서를 도입하는 것이 최선이다.

로드밸런서(load balancer) : 부하 분산 집합에 속한 웹 서버들에게 트래픽 부하를 고르게 분산하는 역할 수행

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

장점1) 서버 1이 다운되면 모든 트래픽은 서버 2로 전송된다. 따라서 웹 사이트 전체가 다운되는 일이 방지된다.

장점2) 웹사이트로 유입되는 트래픽이 가파르게 증가하며 두 대의 서버로 트래픽을 감당할 수 없는 시점이 오는데, 로드밸런서가 있으므로 우아하게 대처할 수 있다. 웹 서버 계층에 더 많은 서버를 추가하기만 하면 된다. 그러면 로드밸런서가 자동적으로 트래픽을 분산하기 시작할 것이다.

데이터 계층에서 발생하는 장애를 방지하기 위해선 → 데이터베이스 다중화

보통은 서버 사이에 주(master)-부(slave) 관계를 설정하고 데이터 원본은 주 서버에, 사본은 slave DB에 저장하는 방식

쓰기 연산(write operation)은 마스터에서만 지원

↔ slave DB는 그 사본을 전달받으며, 읽기 연산(read operation)만을 지원

대부분의 애플리케이션은 읽기 연산의 비중이 쓰기 연산보다 훨씬 높기 때문에 통상 slave의 수가 더 많다.

데이터베이스 다중화를 하면 얻는 이득?

장점1) 더 나은 성능 : 모든 데이터 변경 연산은 master DB로만 전달되는 반면 읽기 연산은 slave 서버로 분산되므로 병렬로 처리될 수 있는 질의(query)의 수가 늘어나고, 성능이 좋아진다.

장점2) 안정성(reliabilty) : DB 서버 가운데 일부가 파괴되어도 데이터는 보존될 것이다. 데이터를 지역적으로 떨어진 여러 장소에 다중화시켜 놓을 수 있기 때문이다.

장점3) 가용성(availability) : 데이터를 여러 지역에 복제해 둠으로써, 하나의 데이터베이스 서버에 장애가 발생하더라도 다른 서버에 있는 데이터를 가져와 계속 서비스 할 수 있게 된다.

데이터베이스 서버 가운데 하나가 다운되면 어떤 일이 벌어지는가?

slave 서버가 다운된 경우

slave 서버가 한 대 뿐인데 다운된 경우라면, 읽기 연산은 한시적으로 모두 master 서버로 전달될 것이다. 또한 즉시 새로운 slave 서버가 장애 서버를 대체할 것이다.

slave 서버가 여러 대인 경우, 읽기 연산은 나머지 slave 서버들로 분산될 것이며, 새로운 slave 서버가 장애 서버를 대체할 것이다.

master 서버가 다운된 경우

master 서버가 다운되면, 한 대의 slave 서버만 있는 경우 해당 서버가 새로운 master 서버가 될 것이며, 모든 DB 연산은 일시적으로 새로운 master 서버에서 수행될 것이다. 그리고 새로운 slave 서버가 추가될 것이다.

프로덕션(production) 환경에서 벌어지는 일은 사실 더 복잡하다. 부 서버에 보관된 데이터가 최신 상태가 아닐 수도 있기 때문이다. 없는 데이터는 복구 스크립트(recovery script)를 돌려서 추가해야 한다. 다중 마스터(multi-master)나 원형 다중화(circular replication) 방식을 도입하면 이런 상황에 대처하는 데 도움이 될 수도 있지만 해당 구성은 훨씬 복잡하다.

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

사용자는 DNS로부터 로드밸런서의 공개 IP 주소를 받는다.

사용자는 해당 IP 주소를 사용해 로드밸런서에 접속한다.

HTTP 요청은 서버 1이나 서버 2로 전달된다.

웹 서버는 사용자의 데이터를 부 데이터베이스 서버에서 읽는다.

웹 서버는 데이터 변경 연산(추가, 삭제, 갱신 등)을 주 데이터베이스 서버로 전달한다.

2. 응답 속도 개선 - 캐시, CDN

응답시간(latency)은 캐시(cache)를 붙이고 정적 콘텐츠를 콘텐츠 전송 네트워크(CDN)으로 옮기면 개선할 수 있다.

캐시 계층은 약간의 실시간성을 배제하고, 빠른 응답을 준다.

별도의 캐시 계층(cache tier)을 두면 성능이 개선될 뿐 아니라 데이터베이스의 부하를 줄일 수 있고, 캐시 계층의 규모를 독립적으로 확장시키는 것도 가능해진다.

대부분의 캐시 서버들이 일반적으로 널리 쓰이는 프로그래밍 언어로 API를 제공하고 있다.

캐시 사용 시 유의할 점

데이터 갱신은 자주 일어나지 않지만 참조는 빈번하게 일어나는 경우에 사용하는 것이 바람직하다.

영속적으로 보관할 데이터를 캐시에 두는 것은 바람직하지 않다. 일반적으로 캐시는 휘발성 메모리에 저장된다. 캐시 서버가 재시작되면 캐시 내의 모든 데이터는 사라진다. 중요한 데이터는 여전히 지속적 저장소(persistent data store)에 두어야 한다.

redis는 persistent store를 지원하긴 한다.

만료 정책을 잘 고려해야 한다. 데이터 만료 정책이 없으면 데이터는 캐시에 계속 남게 된다. 만료 기한이 너무 짧으면 데이터베이스에서 너무 자주 읽어와야 한다. 만료 기한이 너무 길면 실시간성이 떨어져 데이터 일관성을 유지할 수 없게 된다.

데이터 일관성을 잘 유지해야 한다. 저장소의 원본을 갱신하는 연산과 캐시를 갱신하는 연산이 단일 트랜잭션으로 처리되지 않는 경우 이 일관성은 깨질 수 있다. (즉, 데이터베이스 갱신 연산과 캐시 갱신은 단일 트랜잭션으로 처리되어야 한다.)

여러 지역에 걸쳐 캐시 서버를 분산시켜야 한다. SPOF(Single Point Of Failure, 단일 장애 지점)이 되어서는 안된다.

캐시 메모리의 크기를 잘(되도록 크게) 할당해주어야 한다. 너무 작으면 액세스 패턴에 따라서는 데이터가 캐시에서 밀려나버리는 eviction이 너무 자주 일어나서 성능이 오히려 떨어지게 된다. 캐시 메모리를 과할당(overprovision)하는 것도 방법이 될 수 있다.

방출 정책도 잘 고려해야 한다. LRU(Least Recently Used), LFU(Least Frequently Used), FIFO 등 적절한 정책에 따라 정하자.

CDN은 정적 콘텐츠를 캐싱할 수 있는 지리적 분산 서버 네트워크이다.

정적 콘텐츠 : 이미지, 비디오, CSS, JavaScript 파일 등

*동적 콘텐츠 캐싱은 요청 경로(request path), 질의 문자열(query string), 쿠키(cookie), 요청 헤더(request header) 등의 정보에 기반하여 HTML 페이지를 캐시하는 것이다.

다음 그림의 설계는 캐시의 Read-Through 전략과 흡사하다.

CDN 사용 시 고려할 점

자주 사용되지 않는 콘텐츠를 캐싱하는 것은 이득이 크지 않으므로 CDN에서 빼는 것이 좋다. CDN은 보통 제3 사업자(third-party providers)에 의해 운영되며, CDN으로 들어가고 나가는 데이터 전송 양에 따라 요금을 내게 된다.

적절한 만료 시한을 설정해야 한다. 시의성이 중요한(time-sensitive) 콘텐츠의 경우 특히 그렇다. 너무 길면 콘텐츠의 신선도는 떨어지고, 너무 짧으면 원본 서버에 빈번히 접속해야 하므로 성능이 떨어진다.

CDN 장애에 대한 대처 방안을 고려해야 한다. 가령 CDN이 응답하지 않을 경우, 해당 문제를 감지하여 원본 서버로부터 직접 콘텐츠를 가져오도록 클라이언트를 구성하는 것이 필요할 수 있다.

아직 만료되지 않은 콘텐츠이더라도 무효화(invalidation)할 수 있다.

CDN 서비스 사용자가 제공하는 API를 이용하여 콘텐츠 무효화
콘텐츠의 다른 버전을 서비스하도록 오브젝트 버저닝(object versioning)이용. 예를 들어, image.png?v=2 방식으로 버전 번호를 인자로 둔다.

🌐 캐시와 CDN이 추가된 설계안

정적 콘텐츠(JS, CSS, 이미지 등)는 더 이상 웹 서버를 통해 서비스하지 않고 CDN을 통해 더 나은 성능을 보장함

캐시를 통해 데이터베이스 부하를 줄임

3. 웹 계층의 수평적 확장

웹 계층을 수평적으로 확장하기 위해서는 무상태 웹 계층이어야 한다.

상태 정보(사용자 세션 데이터와 같은)를 관계형 데이터베이스나 NoSQL 같은 지속성 저장소에 보관하고 웹 계층에서는 제거하여야 한다.

서버가 상태 정보를 저장하고 있다면 같은 클라이언트로부터의 요청은 항상 같은 서버로 전송되어야 한다는 문제점이 생긴다. 대부분의 로드밸런서가 이를 지원하기 위해 고정 세션(sticky session) 기능을 제공하고 있긴 하지만, 이는 로드밸런서에 부담을 준다. 또한 뒷단에 서버를 추가하거나 제거하기도 까다로워진다. 서버의 장애를 처리하기도 복잡해진다.

무상태 웹 계층을 위하여 상태 정보를 공유 저장소에 저장한다.

사용자로부터의 HTTP 요청은 어떤 웹 서버로도 전달될 수 있다. 웹 서버는 상태 정보가 필요할 경우 공유 저장(shared storage)로부터 데이터를 가져온다. 따라서 상태 정보는 웹 서버로부터 물리적으로 분리되어 있다. 이런 구조는 단순하고, 안정적이며, 규모 확장이 쉽다.

여기서 공유 저장소는 관계형 데이터베이스일 수도 있고, Memcached/Redis 같은 캐시 시스템일 수도 있고, NoSQL일 수도 있다. 그림에서 NoSQL을 예시로 든 것은, 규모 확장이 간편해서다.

①의 자동 규모 확장(autoscaling)은 트래픽 양에 따라 웹 서버를 자동으로 추가하거나 삭제하는 기능인데, 상태 정보가 웹 서버에서 분리되었으므로, 트래픽 양에 따라 웹 서버를 넣거나 빼기만 하면 자동으로 규모를 확장할 수 있다.

다중 데이터 센터 구축은 필수다.

웹 서비스의 가용성을 높이고 전 세계 어디서도 쾌적하게 사용할 수 있도록 하기 위해선 여러 데이터 센터를 지원하는 것이 필수다. 장애가 없는 상황에서는 가장 가까운 데이터 센터로 안내되는데, 통상 이 절차를 지리적 라우팅(geoDNS-routing 또는 geo-routing)이라고 부른다.

*지리적 라우팅 : 사용자의 위치에 따라 도메인 이름을 어떤 IP 주소로 변환할지 결정할 수 있도록 해주는 DNS 서비스

데이터 센터 중 하나에 심각한 장애가 발생하면 모든 트래픽은 장애가 없는 데이터 센터로 전송된다. 이러한 사례와 같은 다중 데이터 센터 아키텍처를 만들기 위해선 몇 가지 기술적 난제를 해결해야 한다.

다중 데이터 센터 아키텍처를 만들기 위해 해결해야 할 몇 가지 기술적 난제

트래픽 우회 : 올바른 데이터 센터로 트래픽을 보내는 효과적인 방법을 찾아야 한다. GeoDNS는 사용자에게서 가장 가까운 데이터 센터로 트래픽을 보낼 수 있도록 해 준다.

데이터 동기화(synchronization) : 데이터 센터마다 별도의 데이터베이스를 사용하고 있는 상황이라면, 장애가 자동으로 복구되어(failover) 트래픽이 다른 데이터베이스로 우회된다 해도, 해당 데이터 센터에는 찾는 데이터가 없을 수 있다. 이런 상황을 막는 보편적 전략은 데이터를 여러 데이터 센터에 걸쳐 다중화하는 것이다. (넷플릭스의 데이터센터 다중화 사례를 참고해도 좋다.)

테스트와 배포(deployment) : 여러 데이터 센터를 사용하도록 시스템이 구성된 상황이라면 웹 사이트 또는 애플리케이션을 여러 위치에서 테스트해 보는 것이 중요하다. 한편, 자동화된 배포 도구는 모든 데이터 센터에 동일한 서비스가 설치되도록 하는 데 중요한 역할을 한다.

메시지 큐를 이용하면 서버 간 결합이 느슨해지고 안정적 애플리케이션을 구성하기 좋다.

메시지 큐는 메시지의 무손실(durability, 메시지 큐에 일단 보관된 메시지는 소비자가 꺼낼 때까지 안전히 보관된다는 특성)을 보장하는, 비동기 통신(asynchronous communication)을 지원하는 컴포넌트다. 메시지의 버퍼 역할을 하며, 비동기적으로 전송한다.

생산자는 소비자 프로세스가 다운되어 있어도 메시지를 발행할 수 있고, 소비자는 생산자 서비스가 가용한 상태가 아니더라도 메시지를 수신할 수 있다.

대규모 웹 서버에 로그, 메트릭, 그리고 자동화는 필수적이다.

로그 : 에러 로그를 모니링하는 것은 중요하다. 시스템의 오류와 문제들을 보다 쉽게 찾아낼 수 있도록 하기 때문이다. 에러 로그는 서버 단위로 모니터링 할 수도 있지만, 로그를 단일 서비스로 모아주는 도구를 활용하면 더 편리하게 검색하고 조회할 수 있다.

메트릭 : 메트릭을 잘 수집하면 사업 현황에 관한 유용한 정보를 얻을 수도 있고, 시스템의 현재 상태를 손쉽게 파악할 수도 있다. 메트릭 가운데 특히 유용한 것을 몇 가지 살펴보면 다음과 같다.

호스트 단위 메트릭 : CPU, 메모리, 디스크 I/O에 관한 메트릭

종합(aggregated) 메트릭 : 데이터베이스 계층의 성능, 캐시 계층의 성능 등

핵심 비즈니스 메트릭 : 일별 능동 사용자(daily active user), 수익(revenue), 재방문(retention) 등

자동화 : 시스템이 크고 복잡해지면 생산성을 높이기 위한 자동화 도구를 활용해야 한다. 지속적 통합(Continuous integration, CI)을 도와주는 도구를 활용하면 개발자가 만드는 코드가 어떤 검증 절차를 자동으로 거치도록 할 수 있어서 문제를 쉽게 감지할 수 있다. 이 외에도 빌드, 테스트, 배포 등의 절차를 자동화할 수 있어서 개발 생산성을 크게 향상시킬 수 있다.

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

메시지 큐는 각 컴포넌트가 보다 느슨히 결합(loosely coupled)될 수 있도록 하고, 결합에 대한 내성을 높인다.

로그, 모니터링, 메트릭, 자동화 등을 지원하기 위한 장치를 추가하였다.

4. 데이터베이스의 수평적 규모 확장

데이터베이스의 수직적 규모 확장에는 한계가 있다.

스케일 업이라고도 부르는 수직적 규모 확장법은 기존 서버에 더 많은, 또는 고성능의 자원(CPU, RAM, 디스크 등)을 증설하는 방법이다. 그러나 이러한 수직적 접근법에는 몇 가지 심각한 약점이 있다.

약점1) 데이터베이스 서버 하드웨어에는 한계가 있으므로 CPU, RAM 등을 무한으로 증설할 수는 없다. 사용자가 계속 늘어나면 한 대 서버로는 결국 감당하기 어렵게 될 것이다.

약점2) SPOF(Single Point Of Failure)로 인한 위험성이 크다.

약점3) 비용이 많이 든다. 고성능 서버로 갈수록 가격이 올라간다.

데이터베이스의 수평적 규모 확장은 샤딩이다.

데이터베이스의 수평적 확장은 샤딩(sharding)이라고도 부른다. 샤딩은 대규모 데이터베이스를 샤드(shard)라고 부르는 작은 단위로 분할하는 기술을 일컫는다. 모든 샤드는 같은 스키마를 쓰지만 샤드에 보관되는 데이터 사이에는 중복이 없다.

샤딩 전략에서 가장 중요한 것은 샤딩 키를 어떻게 정할 것인가이다.

샤딩 키는 파티션 키(partition key)라고도 부르는데, 데이터가 어떻게 분산될지 정하는 하나 이상의 칼럼으로 구성된다. 샤딩 키를 통해 올바른 데이터베이스에 질의를 보내어 데이터 조회나 변경을 처리하므로 효율을 높일 수 있다. 샤딩 키를 정할 때에는 데이터를 고르게 분할할 수 있도록 하는 것이 가장 중요하다.

샤딩을 도입하면 시스템이 복잡해지고 풀어야 할 새로운 문제들도 생기기 마련이다.

데이터의 재 샤딩(resharding) : 재 샤딩은 (1) 데이터가 너무 많아져서 하나의 샤드로는 더 이상 더 이상 감당하기 어려울 때, (2) 샤드 간 데이터 분포가 균등하지 못하여 어떤 샤드에 할당된 공간 소모가 다른 샤드에 비해 빨리 진행될 때 필요하다. 샤드 소진(shard exhaustion)이라고도 부르는 이런 현상이 발생하면 샤드 키를 계산하는 함수를 변경하고 데이터를 재배치하여야 한다. 안정 해시(consistent hashing) 기법을 활용하면 이 문제를 해결할 수 있다.

유명인사(celebrity) 문제 : 핫스팟 키(hotspot key) 문제라고도 부르는데, 특정 샤드에 질의가 집중되어 서버에 과부하가 걸리는 문제다. 가령 유명인사가 전부 같은 샤드에 저장되는 데이터베이스가 있다면 해당 샤드는 read 연산으로 인해 과부하가 걸리게 될 것이다. 디 문제를 풀기 위해선 유명인사 각각에 샤드 하나씩을 할당해야 할 수도 있고, 심지어는 더 잘게 쪼개야 할 수도 있다.

조인과 비정규화(join and de-nomalization) : 일단 하나의 데이터베이스를 여러 샤드 서버로 쪼개고 나면, 여러 샤드에 걸친 데이터를 조인하기가 힘들어진다. 이를 해결하는 한 가지 방법은 데이터베이스를 비정규화하여 하나의 테이블에서 질의가 수행될 수 있도록 하는 것이다.

🌐 데이터베이스 샤딩을 적용한 아키텍처 설계안

5. 시스템 규모 확장을 위한 기법들 정리

웹 계층은 무상태 계층으로

만약 상태 유지 계층이라면 클라이언트는 특정 서버에만 요청을 보낼 수 있다. 로드밸런서에게도 부담이다.

상태 저장소를 따로 분리

모든 계층에 다중화 도입

데이터 센터 다중화

가능한 한 많은 데이터를 캐시할 것

만료, 방출, 메모리 정책

데이터 일관성 유지