Distributed Database

데이터베이스 트래픽을 분산하는 방법(Sharding), 고가용성을 확보하는 방법(Replica)을 알아보자.

---

분산 데이터베이스

서비스가 활성화 되면서 DB에 저장할 데이터와 트래픽이 많아졌다.

먼저 Scale-Up을 적용했으나 얼마 후 서비스가 더욱 활성화되면서 단일 DB로 처리하기엔 부담이 커졌다.

Scale-Out을 적용해 DB를 하나 더 늘렸다.

데이터베이스에 대한 하나의 분산 시스템이 구성된 것이다.

 

그렇다면, 데이터는 각 DB에 어떻게 분산될 수 있을까?

---

Sharding

샤딩을 이용해 데이터를 여러 DB에 분산할 수 있다.

• Sharding: 데이터를 여러 데이터베이스에 분산하여 저장하는 기술
• Shard: 샤딩된 각각의 데이터 단위

샤딩을 이용하면

• 각 샤드에 데이터가 분산 저장되므로 성능 및 공간 이점이 생긴다.
• 하지만, 데이터의 분리로 인해 조인 및 트랜잭션 관리가 복잡해질 수 있다.

 

샤딩 기법

샤딩에는 다양한 방법이 있다.

먼저 수직 샤딩과 수평 샤딩을 알아보자.

수직 사딩(Vertical Sharding)

데이터를 수직으로(컬럼 단위) 분할하는 방식

 - 수직으로 분할되므로 수평적 확장에 제한(ex. 컬럼 단위로 분할되면 컬럼 수 만큼만 확장 가능한가?)

식별자(article_id)를 이용하여 좌측 샤드에 title/content 컬럼을, 우측 샤드에 board_id, created_at을 분산 저장

 

 

수평 샤딩(Horizontal Sharding)

데이터를 수평으로(행 단위) 분할하는 방식

- 수평으로 분할되므로 수평적 확장에 용이하다

좌측 샤드 article_id=1~5000, 우측 샤드 article_id=5001~10000으로 분산 저장

 

수직 샤딩과 수평 샤딩의 특성을 이해하고, 적절히 선택(또는 혼합)하여 사용할 수 있다.

 

위 개념들을 적용한 몇가지 구체적인 샤딩 기법들을 살펴보자.

 

Range-based Sharding (범위 기반 샤딩)

데이터를 특정 값(Shard Key)의 특정 범위에 따라 분할하는 기법

- 범위 데이터 조회에 유리 (id 100부터 30개 조회한다면 좌측 샤드에서 모든 데이터를 찾을 수 있음)

- 데이터 쏠림 현상 발생 가능 (데이터가 6000개라면 우측에는 1000개만 저장)

좌측 샤드 article_id = 1 ~ 5000 우측 샤드 article_id = 5001 ~ 10000

 

Hash-based Sharding (해시 기반 샤딩)

데이터를 특정 값(Shard Key)의 해시 함수에 따라 분할하는 기법

 - 균등한 분산을 위한 Shard Key와 해시 함수가 필요 (균등하지 않으면 데이터 쏠림 현상 발생 가능)

 - 범위 데이터 조회에 불리할 수 있다. 

hash_function = article_id -> article_id % 2

 

Directory-based Sharding (디렉토리 기반 샤딩)

디렉토리를 이용하여 데이터가 저장된 샤드를 관리하는 기법

- 디렉토리 관리 비용이 있으나, 데이터 규모에 따라 유연한 관리가 가능

매핑 데이블을 이용하여 각 데이터가 저장된 샤드를 관리한다

 

외에도 데이터의 특성 또는 시스템 요구사항에 따라 다양한 샤딩 기법이 있고, 자신의 시스템에 알맞은 샤딩 기법을 직접 만들 수도 있다. 샤딩의 개념과 각 기법의 특성을 이해하고, 시스템 특성에 따라 적절한 기법을 선택하는 것이 중요하다.

 

---

데이터베이스 확장성

물리적 샤드와 논리적 샤드

물리적 샤드 (Physical Shard)

아래 그림에서는 DB가 2대로 물리적 분리되었다. 2개의 물리적 샤드를 가지는 것이다.

각 샤드가 더이상 데이터를 감당할 수 없어서, 샤드를 늘려야 하는 상황이 왔다.

물리적 샤드를 4개로 늘리고, 데이터를 재배치 했다.

Client는 이제 4개의 Shard로 요청해야 하므로, 애플리케이션 코드를 수정하는 등 새로운 Shard의 정보를 알아야한다..!

 

Client와 데이터베이스는 독립적으로 구성 및 운영될 수 있는 시스템임에도,

데이터베이스의 확장(변경)으로 인해 Client의 수정이 요구된다.

 

Client의 수정없이 DB만 유연하게 확장하는 방법은 없을까?

 

논리적 샤드(Logical Shard)

이번에는 실제 물리적인 샤드의 개수와 관계없이 개념적으로 데이터를 분할하는 가상의 샤드가 4개 있다고 가정해보자.

물리적 샤드는 2개이지만, Client는 4개의 샤드가 있다고 가정하고 분리하는 것이다.

이러한 가사의 샤드를 논리적 샤드라고 한다. Client는 논리적 샤드의 접근 방법으로만 DB에 연결하는 것이다.

hash_function = article_id -> article_id % 4 Router가 DB 시스템 내부에 포함된다고 가정

그렇다면, Client가 요청한 논리적 샤드가 어떤 물리적 샤드에 속해있는지 알아야하므로 라우팅이 필요하다.

DB 시스템 내부 또는 DB와 Client를 연결해주는 중간에 독립적으로 라우터가 만들어질 수 있다.

Client는 논리적 샤드를 기반으로 Router에 요처하면, DB 시스템 내부의 Router는 물리적 샤드로 라우팅해준다.

 

여기서 데이터베이스 확장을 위해 물리적 샤드를 4개로 늘려보자.

논리적 샤드를 물리적 샤드가 늘어남에 따라 재배치한 후, Router가 물리적으로 늘어난 새로운 샤드 정보를 알도록 한다.

이번에는 Client는 어떠한 수정도 필요없다. 새로운 물리적 샤드를 알 책임이 있는 Router는 DB 시스템 내부에 있기 때문이다.

 

논리적 샤드 개념을 이용하여, 물리적 샤드를 확장하더라도 Client의 변경없이 DB를 유연하게 확장할 수 있다.

 

---

데이터 복제

고가용성, 안정성, 성능과 관련된 개념인 데이터 복제의 필요성에 대해 알아보자.

 

좌측 샤드에 장애가 발생할 경우, 데이터는 복구 전까지 또는 영구적으로 사용할 수 없는 것일까?

 

이러한 문제를 해결하기 위해 데이터 복제본을 관리할 수 있다.

Primary(주 데이터베이스)에 데이터를 쓰고, Replica(복제본)에 데이터를 복제한다.

Primary/Replica, Leader/Follower, Master/Slave, Main/Standby 등 유사한 개념이지만, 시스템이나 목적에 따라 다르게 사용되기도 한다

이러한 복제는 동기적 또는 비동기적으로 처리될 수 있다.

• Synchronous(동기적) : 데이터 일관성을 보장하나, 쓰기 성능 저하된다.
• Asynchronous(비동기적) : 쓰기 성능 유지되나, 복제본에 최신 데이터가 즉시 반영되지 않을 수 있다.

이러한 복제본은 고가용성을 위해 동일한 데이터 센터 내에 관리될 수도 있고, 다른 지역의 데이터 센터에서 관리될 수도 있다.

이러한 데이터의 분산을 통해 데이터는 안전하게 관리된다.

 

이제 좌측 샤드에 장애가 발생하더라도,

• Replica에서 데이터 조회를 수행할 수도 있고,
• Replica를 Primary로 재선출하여 쓰기 작업을 이어서 수행할 수도 있다.

 

이러한 시스템을 통해,

• 고가용성(Primary 재선출을 통한 서비스 지속성),
• 데이터 유실 방지 및 데이터 백업(Replica 복제본 관리),
• 부하 분산(Replica 또는 각 샤드로 요청 분산)

등의 다양한 이점을 가질 수 있다.

---

 

참고 자료 & 이미지 출처
스프링부트로 직접 만들면서 배우는 대규모 시스템 설계 - 게시판