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

데이터 센터

이전 포스팅의 GSLB 개념에서 잠깐 알 수 있다.

아래 그림에서..

사용자는 두개의 데이터 센터가 장애 없는 상황이라면 가장 가까운 데이터 센터로 안내된다.

(GSLB, 지리적 라우팅)

 

위와 같이 Data center를 두군데 구축 해놨을 때...

한군데에 심각한 장애가 발생 했을 경우 다른 한 군데로 매핑 될 것이다.

 

주의사항

위 그림에서 무상태 아키텍처를 위한 사용자 상태의 저장소는 하나의 공유 저장소를 바라보고 있어서

갑자기 다른 데이터 센터로 변경 매핑될 지라도 문제가 없을 것이다.

 

DB

DB의 경우는 서로 연결이 되어있지 않아 문제가 발생한다.

따라서 여러 데이터 센터에 걸친 데이터 다중화 방법을 검토 해봐야 한다.

 

TEST

웹 서버의 TEST는 반드시 모든 데이터 센터에서 수행 해야 한다.

 

무중단 자동 배포

모든 데이터 센터에 동일한 서비스를 제공할 수 있도록 일괄 배포 기술을 사용해야 할 것이다.

 

 

Beyond

MSA (Micro Service Architecture)

서버 자체도 각 기능별 컴포넌트로 분리하여, 각각 독립적으로 확장 될 수 있도록 해야한다.

 

어느 하나의 기능에 대한 서버가 다운되어도 다른 서버는 살아있기에.. 대처가 용이하다.

(서비스간 결합이 느슨해짐)

어느 하나의 기능에 대한 서버에 트래픽이 몰리면 그 서버만 스케일 아웃하면 된다.

 

이를 위해서는 메세지 큐 기술을 도입해야한다.

-> 메시지 큐

 

메시지 큐

Kafka 와 같은 툴에 해당된다.

보통 데이터 센터내 서버간 메시지를 전달하는 용도로 사용된다.

 

메세지를 생산하는 생산자,

생산된 메세지를 가져가서 그에 따른 처리를 하는 소비자

로 나뉜다.

-> 비동기로 처리 되므로 각 서버를 독립적으로 규모 확장 시킬 수 있다.

 

 

 

데이터 베이스의 규모 확장

데이터가 많아지면 데이터 베이스에 해단 부하도 증가한다.

-> 굳이 관계형 데이터 베이스가 요구 되지 않는 기능들은 NoSQL로 이전한다.

 

그래도 해결이 안되면...

 

수직적 확장

웹서버와 동일하게 데이터베이스 서버 자체의 성능을 끌어올리는 것이다.

->한계 존재

 

수평적 확장

-> 샤딩

 

샤딩(Sharding)

대규모 데이터 베이스를 샤드라고 부르는 작은 단위로 분할 하는 기술이다.

모든 샤드는 같은 스키마를 사용하지만..

샤드에 보관되는 데이터 사이에는 중복이 없다.

(샤딩 키는 파티션 키라고도 불림)

ex. user_id % 4 -> 4개의 샤드에 적재할 수 있다.

 

주의 사항

1. 데이터 재 샤딩

샤드 키를 계산하는 함수 변경 시, 데이터 전체를 재 배치 해야한다.

-> 안정 해시 기법 활용

 

2. 유명인사 문제

특정 샤드에 질의가 집중되는 현상

-> 샤드를 더 잘게 쪼개 거나, 유명인사를 다른 샤드에 배치되도록 한다.

 

3. 조인과 비정규화

여러 샤드에 걸친 데이터를 조인하기가 힘듬

-> 데이터 베이스를 비정규화 하여 하나의 테이블에서 질의가 수행 될 수 있도록 한다.