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

## 단일 서버 시스템 설계

* 가장 기본이 되는 서버 시스템 구조이다.
* 다음 순서를 통해 사용자의 UI와 서버가 통신하게 된다.
  * 1️⃣ 웹 브라우저에 도메인 주소를 입력
  * 2️⃣ 도메인을 기반으로 IP 주소를 획득
  * 3️⃣ 실제 해당 IP로 요청을 보냄
  * 4️⃣ 서버로부터 응답을 받아 웹 브라우저가 표현

<figure><img src="https://946524419-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZqOTWctN1y9hEXEl4sKd%2Fuploads%2FgCcz82skKjBMrNgvG8VU%2Fimage.png?alt=media&#x26;token=73f83f99-62cd-4fc6-a2c8-8babc6766381" alt=""><figcaption></figcaption></figure>

* 사용자 단말
  * 서버에 실제 요청을 보내는 근원이다.
  * 웹 앱
    * 비즈니스 로직, 데이터 저장 등을 처리하기 위해 서버 구현용 언어를 사용
    * 뷰를 위해 클라이언트 구현용 언어를 사용
  * 모바일 앱
    * 웹 서버와 통신하기 위해 HTTP 프로토콜을 사용
    * 응답 데이터의 포맷으로 보통 JSON(JavaScript Object Notation)을 사용

## 1️⃣ 데이터베이스 분리

* 여러 서버를 두고 **웹 계층과 데이터 계층을 분리**해 독립적으로 확장할 수 있다.

<figure><img src="https://946524419-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZqOTWctN1y9hEXEl4sKd%2Fuploads%2FcXsgCHrpJDthEEKFhf2j%2Fimage.png?alt=media&#x26;token=1f521e19-4c09-4e08-95f6-f5df8af532bf" alt=""><figcaption></figcaption></figure>

### 데이터베이스 종류

* Relational DB
  * 자료를 테이블, row, column 으로 표현한다.
  * 여러 테이블의 데이터를 join하여 합칠 수 있다.
* NoSQL
  * 종류: key-value 저장소, 그래프 저장소, column 저장소, 문서 저장소
  * 필요한 상황
    * 낮은 응답 latency가 필요할 때 (빠른 속도가 필요할 때)
    * 다루는 데이터가 비정형이라 관계형 데이터가 아닐 때
    * 데이터를 직렬화/역직렬화 할 수 있기만 하면 될 때
    * 아주 많은 양의 데이터를 저장해야 할 때

## 2️⃣ 수직적 vs 수평적 규모 확장

### Scale Up vs Scale Out

* 수직적 확장 (Scale Up)
  * 더 좋은 사양의 자원(CPU, RAM 등)을 기존 서버에 추가하는 방식
  * 장점
    * 서버로 유입되는 트래픽 양이 적을 때 좋다.
    * 비교적 단순하게 확장 가능
  * 단점
    * 한 대의 서버에 사용 가능한 사양에는 한계가 있으며, 확장 시 비용이 비싸다.
    * 장애에 대한 failover(자동복구)나 redundancy(다중화) 방안을 제시하지 않으므로 서비스가 중단될 수 있다.
* 수평적 확장 (Scale Out)
  * 비슷한 사양의 더 많은 서버를 추가하여 성능을 개선하는 방식
  * 수직적 확장의 단점을 해결한다.

### 로드밸런서

* 부하 분산 집합에 속한 웹서버들에게 트래픽 부하를 고르게 분산하는 방식
* 클라이언트의 접속을 부하 분산 집합에 분배하기 때문에 failover가 가능하며 웹 계층의 가용성이 향상된다.
* 트래픽이 가파르게 증가하는 경우 웹 서버 계층에 많은 서버를 추가하면 로드밸런서가 자동으로 트래픽을 분산하여 장애 발생을 막을 수 있다.

### 데이터베이스 다중화

* 데이터의 원본은 master 서버에, 복제본은 slave 서버에 저장한다.
* master 서버에서만 write 연산을 처리할 수 있도록 하며, read 연산은 어디서든 처리 가능하다. 일반적으로 대부분의 요청이 read 연산이기 때문에 요청을 분산하여 처리할 수 있게 된다.
* 장점
  * 성능 완화: 병렬로 처리될 수 있는 질의의 수가 늘어 성능이 좋아진다.
  * 안정성: 데이터 서버 중 일부가 파괴되어도 데이터가 보존될 가능성이 커진다.
  * 가용성: 하나의 데이터베이스 서버에 장애가 발생해도 서비스가 가능하다.

<figure><img src="https://946524419-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZqOTWctN1y9hEXEl4sKd%2Fuploads%2FXoCt90EfoqMA7DqmO9cV%2Fimage.png?alt=media&#x26;token=9ff46899-ffc1-4be4-9791-1160d1ff257a" alt=""><figcaption></figcaption></figure>

* 프로덕션 환경에서는 slave 서버에 보관된 데이터가 최신 상태가 아닐 수 있어, 없는 데이터는 따로 추가해주어야 한다. 혹은 다중 마스터, 원형 다중화 방식을 도입할 수 있다.

## 3️⃣ 응답 시간 개선

* 캐시를 붙이고 정적 콘텐츠를 CDN으로 옮긴다.

### 캐시

* 값비싼 연산 결과 또는 자주 참조되는 데이터를 메모리 안에 두고, 요청이 빨리 처리될 수 있도록 하는 저장소
*   캐시 계층

    * 데이터가 잠시 보관되는 곳
    * 데이터베이스보다 훨씬 빠르고 DB 부하를 줄일 수 있다.

    <figure><img src="https://946524419-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZqOTWctN1y9hEXEl4sKd%2Fuploads%2FwZOUw6kLvTUczqL5Eru8%2Fimage.png?alt=media&#x26;token=331fa0d5-d116-4ab6-9ee3-461945088cb1" alt=""><figcaption></figcaption></figure>
* 읽기 주도형 캐시 전략
  * 캐시에 저장되어 있다면 캐시 데이터를 클라이언트에 반환하고 없는 경우에는 데이터베이스 질의를 통해 데이터를 찾아 캐시에 저장하고 클라이언트에 반환
* 유의할 점
  * 어떤 상황에 캐시가 필요한지 파악해야 한다. 데이터 갱신이 자주일어나지 않지만 참조는 빈번하게 일어나는 경우에 적합하다.
  * 중요한 데이터는 **지속적인 데이터 저장소**에 두어야 한다.
  * 캐시 데이터의 **만료 기한**을 적절하게 설정해야 한다.
  * 데이터 저장소의 원본이 갱신될 때 캐시 내의 사본도 갱신되지 않는다면 **일관성**이 유지되지 않는다.
  * 캐시 서버 하나만 사용할 경우 단일 장애 지점(SPOF)이 되어 전체 시스템의 동작을 중단시킬 수 있다. 따라서 **여러 캐시 서버를 사용해 분산**시켜야 한다.
  * 캐시 메모리의 크기를 적당히 크게 잡아야 캐시 eviction이 자주 발생하지 않을 것이다.
  * 캐시 eviction 정책을 적절히 적용해야 한다. (LRU, LeastFrequentlyUsed, FIFO 등)

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

* 정적 컨텐츠 (이미지, 비디오, CSS 등) 를 전송하는데 쓰이는 지리적으로 분산된 네트워크
* 자주 사용되는 컨텐츠를 CDN에 캐싱하여 빠른 응답성을 얻도록 한다.
* 서버가 위치한 데이터센터와 거리가 먼 사용자들이 많은 경우 응답 속도가 매우 낮아질 수 있으므로, 사용자가 많은 지역 별로 CDN에 컨텐츠를 캐싱해 어디서나 응답 속도가 빠른 서비스를 제공받을 수 있도록 한다.
* object versioning 기능을 이용해 기존 컨텐츠의 버전 번호와 컨텐츠를 함께 업데이트할 수 있다.
  * [https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/UpdatingExistingObjects.html#ReplacingObjects](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/UpdatingExistingObjects.html#ReplacingObjects)

## 4️⃣ 무상태 웹 계층

* ❎ 상태 정보 의존적 아키텍처
  * 상태 정보를 서버에 저장해두는 방식이다. 따라서, 같은 클라이언트로부터의 요청은 항상 같은 서버로 전송되어야 유지된 상태 정보를 확인할 수 있다.
  * 로드밸런서의 고정 세션 기능을 사용하면 구현 가능하지만, 로드밸런서에 부담을 주고 서버를 추가/제거하거나 장애를 처리하기도 복잡해져서 대규모 시스템에서는 사용하지 않는다.
*   ✅ 무상태 아키텍처

    *   상태 정보를 웹 계층이 아닌 RDB/NoSQL 에 보관하고 필요할 때마다 가져오게 한다.

        > 상태 정보: 사용자 세션 데이터 등을 의미
    * 어떤 웹서버로든 요청이 들어갈 수 있다.
    * 상태 정보가 필요한 경우 공유 저장소로부터 데이터를 가져온다.

    <figure><img src="https://946524419-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZqOTWctN1y9hEXEl4sKd%2Fuploads%2FETjDFsbj72Zk9qbRv7An%2Fimage.png?alt=media&#x26;token=ab4a351d-c5af-46b1-bab5-31d921e06468" alt=""><figcaption></figcaption></figure>

    * 상태 정보를 저장하는 공유 저장소는 규모 확장이 간편한 NoSQL을 사용하거나 캐시를 사용할 수 있다.

## 5️⃣ 데이터 센터

### 지역 기반 라우팅

* 지리적 라우팅
  * 장애가 없는 상황에서 가장 사용자에게 가까운 데이터 센터로 안내되는 것을 의미한다.
* geoDNS
  * 사용자의 위치에 따라 도메인 이름을 어떤 IP 주소로 변환할지 결정하도록 해주는 DNS 서비스
  * UltraDNS에서 이를 지원해준다.

### 다중 데이터센터 아키텍처 요구사항

* 올바른 데이터 센터로 트래픽 우회시키는 효과적인 방법을 찾아야 한다.
* 여러 데이터 센터에 걸쳐 데이터를 다중화하지 않을 경우, failover에 의해 트래픽이 우회되어야 하는 상황이 발생하였을 때 요청하는 데이터가 해당 데이터 센터에 없을 수 있다.
* 여러 위치에서 프로그램을 테스트해보는 것이 중요하다.
* 자동화된 배포 도구를 사용해 모든 데이터센터에 동일한 서비스가 설치되도록 해야 한다.

## 6️⃣ 메시지 큐

* 메시지의 무손실을 보장하고 비동기 통신을 지원하는 컴포넌트
* 생산자는 시간이 오래 걸리는 작업들을 메시지 큐에 넣고, 이 작업을 수행하는 프로세스(소비자)가 메시지 큐에서 꺼내 비동기적으로 처리하도록 한다.

<figure><img src="https://946524419-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZqOTWctN1y9hEXEl4sKd%2Fuploads%2FRvaaaNdkywp8cPMivmgl%2Fimage.png?alt=media&#x26;token=0a288a23-0427-4fa8-be56-78059e5c16c8" alt=""><figcaption></figcaption></figure>

* 생산자와 소비자 서비스 규모는 각기 독립적으로 확장될 수 있다.

## 7️⃣ 로그, 메트릭, 자동화

* 로그
  * 에러 로그 모니터링을 통해 시스템의 오류/문제를 찾아낼 수 있다.
  * 단일 서비스로 모아주는 도구를 활용해 편리하게 검색/조회를 할 수 있다.
* 메트릭
  * 시스템의 현재 상태를 손쉽게 파악 가능, 사업 현황에 유용한 정보를 얻을 수 있다.
  * 호스트 단위 메트릭: CPU, 메모리, 디스크 I/O 에 관한 메트릭
  * 종합 메트릭: 데이터베이스/캐시 계층의 성능
  * 핵심 비즈니스 메트릭: daily active user, 수익, 재방문 등
* 자동화
  * 생산성을 높이기 위해 자동화 도구를 활용해 빌드, 테스트, 배포 등의 절차를 자동화
  * 지속적 통합을 도와주는 자동화 도구의 경우, 개발자가 만드는 코드를 검증 절차를 거치도록 해 쉽게 문제를 감지할 수 있다.

## 8️⃣ 데이터베이스 샤딩

* 대규모 데이터베이스를 shard 라는 작은 단위로 분할하는 기술
* 모든 샤드는 같은 스키마를 쓰지만, 샤드에 보관되는 데이터 사이에는 중복이 없다.
* 문제점
  * 하나의 샤드로 감당할 수 없는 만큼 데이터가 늘어나거나, 샤드 간 데이터 분포가 불균형해 특정 샤드에만 데이터 소모가 빠르게 이뤄질 때 재샤딩이 필요하다.
  * 샤드 키를 계산하는 함수를 변경하거나 consistent hashing을 사용해 이러한 문제를 해결할 수 있다.
  * hotspot key 가 존재할 경우 특정 샤드에 요청량이 과도하게 몰릴 수 있어 이러한 키들이 여러 샤드에 적절히 분배되도록 해야 한다.
  * 데이터베이스를 샤딩할 경우 여러 샤드에 걸친 조인 처리를 하기 어렵기 때문에 비정규화하여 하나의 데이터베이스에서 질의가 수행되도록 해야 한다.

## 마무리

수백만 이상의 사용자를 지원하려면 지속적으로 시스템을 최적화하고 더 작은 단위의 서비스로 분할해야 할 것이다.
