[독서] 가상면접 사례로 배우는 대규모 시스템 설계 기초 - 사용자 수에 따른 규모 확장성

확장가능한 아키텍쳐

수직적 규모 확장(Scale up) vs 수평적 규모 확장(Scale out)

수직적 규모 확장(Scale up)의 문제점

• 한대의 서버에 CPU나 메모리를 무한대로 증설할 방법은 없기에 한계가 있다.
• 장애에 대한 자동복구(failover)나 다중화(re-dundancy)방안을 제시하지않는다. 따라서 서버에 장애가 발생하면 어플리케이션은 중단된다.

로드 밸런서

역할

• 트래픽 분산: 클라이언트 요청을 여러 서버에 분산시켜 각 서버의 부하를 줄인다.
• 고가용성: 서버 장애 시에도 서비스를 지속할 수 있도록 Health Check 및 Fail Over를 수행한다.
• 성능 향상: 서버 간의 트래픽을 균등하게 분배하여 응답 시간을 줄이고 성능을 최적화한다.

종류

• 소프트웨어 로드 밸런서: NGINX, Apache Traffic Server등
• 클라우드 기반 로드 밸런서: AWS Elastic Load Balancing (ELB), Google Cloud Load Balancing, Azure Load Balancer등

---

데이터베이스 다중화

서버 사이에 master와 slave 관계를 설정하고 데이터 원본을 master 서버에, 사본은 slave 서버에 저장하는 방식이다.

• master 서버: 데이터 원본 저장, 쓰기 연산(write)
• slave 서버: 데이터 사본 저장, 읽기 연산(read)

장점

• 데이터 변경 연산은 master 서버, 읽기 연산은 slave 서버로 분산된다. 따라서 병렬로 처리될 수 있는 query의 수가 늘어나서 성능이 좋아진다.
• 데이터를 지역적으로 떨어진 장소에 다중화 시킴으로써 자연재해등의 이유로 데이터베이스 서버의 일부가 파괴되어도 데이터를 보존할 수 있다. 
• 데이터를 여러 지역에 복제함으로써 데이터베이스 서버에 장애가 발생해도 다른 서버에 있는 데이터로 서비스를 유지할 수 있다. 

예시

• slave 서버가 1대인데 다운된 경우, 읽기 연산은 한시적으로 master 서버로 전달된다. 또한 즉시 새로운 slave 서버가 장애 서버를 대체한다. slave 서버가 여러대인 경우, 읽기 연산은 나머지 slave 서버로 분산될 것이며 새로운 slave 서버가 장애 서버를 대체한다.
• master 서버가 다운되면, 한대의 slave 서버만 있는 경우 해당 slave 서버가 새로운 master 서버가 된다. 모든 데이터베이스 연산은 일시적으로 새로운 master 서버에서 처리된다. 그리고 새로운 slave 서버가 추가된다. 

---

캐시

응답 시간은 캐시를 붙이고 정적 콘텐츠를 CDN으로 옮기면 개선할 수 있다. 

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

캐시 계층(cache tier)

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

읽기 주도형 캐시 전략(read-through caching strategy)

읽기 주도형 캐시 전략은 다음의 순서로 진행된다.

1. 요청을 받은 웹서버는 캐시에 응답이 저장되어있는지 본다.
2. 만일 저장되어있다면 해당 데이터를 클라이언트에 반환한다.
3. 없는 경우라면 데이터베이스 query를 통해 데이터를 찾아 캐시에 저장한 뒤 클라이언트에 반환한다.

캐시 사용시 유의할 점

• 데이터갱신은 자주 일어나지 않지만 참조가 빈번하게 일어나는 경우 캐시가 적합하다.
• 캐시는 데이터를 휘발성 메모리에 저장하므로 영구적으로 보관할 데이터는 캐시에 저장하면 안된다.
• 만료된 데이터는 캐시에서 삭제해야한다. 따라서 만료기한을 적절하게 설정해야한다.
• 저장소의 원본을 갱신하는 연산과 캐시를 갱신하는 연산이 단일 트랜잭션으로 처리되지않는 경우 일관성이 깨질 수 있다.
• 캐시 서버를 한대만 두는 경우, 장애 발생시 해당 서버는 단일 장애 지점(Single point of failure, SPOF)가 될 수 있다. 따라서 여러 지역에 걸쳐 캐시 서버를 분산해야한다. 
• 적절한 캐시 데이터 방출 정책을 적용해야한다.

단일 장애 지점(Single point of failure, SPOF)

어떤 특정 지점에서의 장애가 전체 시스템의 동작을 중단 시키는 경우이다.

 

캐시 데이터 방출 정책

캐시가 꽉 찼는데 추가로 캐시에 데이터를 넣어야하는 경우 기존 데이터를 내보내는 정책이다. 대표적으로 LRU(Least recently used) -- 마지막으로 사용된 시점이 가장 오래된 데이터를 내보내는 알고리즘-- 이나 LFU(Least frequently used) --사용된 빈도가 가장 낮은 데이터를 내보내는 알고리즘이 있다.

---

CDN

CDN은 정적 컨텐츠를 전송하는데 사용되는 지리적으로 분산된 서버의 네트워크이다. 이미지, 비디오, CSS, Javascript 파일등을 캐시할 수 있다.  사용자가 웹사이트를 방문하면 사용자에게 가장 가까운 CDN 서버가 정적 컨텐츠를 전달한다. 

무상태(Stateless) 계층 

상태 웹 계층

웹 계층을 수평적으로 확장하기위해서 상태 정보(사용자의 세션)를 웹계층에서 제거해야한다. 상태정보를 관계형 데이터베이스나 NoSQL 같은 저장소에 보관하고 필요할 때 가져오도록 하는 것이다. 상태정보가 웹서버에서 제거되었으므로, 트래픽 양에 따라 웹서버를 넣거나 빼기만하면 자동적으로 규모를 확장 할 수 있다. 

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

상태 정보를 보관하는 서버는 클라이언트 정보를 요청 사이에서 공유한다. 따라서 같은 클라이언트의 요청은 항상 같은 서버로 전송되어야한다. 대부분의 로드밸런서는 고정 세션(sticky session) 기능으로 이를 지원하는데, 이는 로드밸런서에 부담을 준다. 

메세지큐

메세지큐는 데이터의 무손실을 보장하고 비동기 통신을 지원하는 컴포넌트이다. 메세지큐를 이용하면 서비스 또는 서버간의 결합이 느슨해져서 규모 확장성이 보장되어야하는 안정적 애플리케이션을 구성하기좋다.

기본 아키텍쳐

• Producer/Publisher: 메세지를 만들어 메제시큐에 publish한다. 생산자는 소비자 프로세스가 다운되어도 메세지를 발행할 수 있다.
• Consumer/Subscriber: 메세지를 받아 그에 맞는 동작을 수행한다. 소비자는 생산자 서비스가 가용가능한 상태가 아니여도 메세지를 수신할 수 있다. 

예시

사진 보정 애플리케이션을 만든다고 가정해보자. 보정은 시간이 오래 걸릴 수 있으므로 비동기로 처리하면 편리하다. 메세지큐를 이용해서 다음과 같이 구상할 수 있다. 

1. 웹서버는 사진 보정 작업을 메세지 큐에 넣는다.
2. 사진 보정 작업 프로세스는 이 작업을 메세지큐에서 꺼내어 비동기적으로 완료한다.

데이터베이스의 규모 확장

Sharding

데이터베이스의 수평적 확장은 sharding이라고 부르는데, 더 많은 서버를 추가함으로써 성능을 향상시킬 수 있다. 샤딩은 대규모 데이터베이스를 Shard라고 부르는 작은 단위로 분할하는 기술을 말한다. 

Sharding Key(Partition Key)

샤딩 전략을 구현할 때 가장 중요한 것은 샤딩키를 어떻게 정하느냐이다. 샤딩 키는 데이터가 어떻게 분산될지 정하는 하나 이상의 컬럼으로 구성된다. 샤딩 키를 정할 때 데이터를 고르게 분할할 수 있도록 하는 것이 가장 중요하다.

고려사항

• 샤드 소진(Shard exhaustion) 현상이 발생하면, 샤드 키를 계산하는 함수를 변경하고 데이터를 재배치해야한다.
• 유명인사(Celebrity)/핫스팟 키(Hotspot key) 문제 발생시, 유명인사 각각에 샤드 하나씩을 할당하거나 더 잘게 쪼개야한다.
• 여러샤드에 걸친 데이터를 조인하기가 힘든 경우, 데이터베이스를 비정규화하여 하나의 테이블에서 질의가 수행될 수 있도록 한다.

 

샤드 소진(Shard exhaustion)

데이터가 너무 많아서 하나의 샤드로는 감당불가한 경우, 또는 샤드간 데이터 분포가 균등하지못해서 어떤 샤드에 할당된 공간 소모가 다른 샤드에 비해 빠르게 진행되는 경우를 의미한다.

 

유명인사(Celebrity)/핫스팟 키(Hotspot key) 문제

특정 샤드에 질의가 집중되어 서버에 과부하가 걸리는 문제이다.