소개
데이터베이스 확장 기술은 현대의 대규모 어플리케이션과 서비스가 급속하게 성장함에 따라 중요성을 더해가고 있어요. 본 블로그에서는 데이터베이스 성능 및 확장성을 향상시키기 위한 주요 기술인 파티셔닝, 샤딩, 그리고 레플리케이션에 중점을 두어 개념에 대해 다루려고 해요.
🚪 파티셔닝
파티셔닝은 데이터베이스에서 큰 테이블을 특정 기준에 따라 작은 테이블로 나누는 기술이에요. 이는 큰 테이블을 관리하기 쉽게 만들어 성능을 향상시킬 수 있어요. vertical 파티셔닝과 horizontal 파티셔닝 두 가지 방식에 대해 알아 봐요.
| Vertical 파티셔닝
Vertical 파티셔닝은 column을 기준으로 테이블을 나누는 방식이에요. 주로 정규화와 유사하게 사용되요.
정규화라는 것은 보통 두 가지 목적을 갖고 있어요.
- 데이터베이스에 중복된 데이터가 저장되는 것을 방지하고,
- 그리고, insert, update, delete 즉, write 작업을 할 때 이상한 현상이 발생하는 것을 방지해요.
즉, 정규화 과정 역시 vertical 파티셔닝으로 볼 수 있어요. 정규화를 간략하게 해볼게요.
Original Table
post
| writer | title | content | Subject | read_count | comment_count |
|---|---|---|---|---|---|
| ODee | 데브옵스란? | … | infra | 100_000_000 | 685 |
| ODee | 백엔드란? | … | develop | 80_000_000 | 562 |
| Candy | 아.. 난 프론트야 | … | develop | 10_000 | 2 |
| Candy | 책임 떠넘기기 주도 개발 | … | develop | 110 | 3 |
정규화 한 Table
post
| id | user_id | title | body | subject_id | read_count | comment_count |
|---|---|---|---|---|---|---|
| 1 | 1 | 데브옵스란? | … | 1 | 100_000_000 | 685 |
| 3 | 1 | 백엔드란? | … | 2 | 80_000_000 | 562 |
| 4 | 2 | 아.. 난 프론트야 | … | 2 | 10_000 | 2 |
| 7 | 2 | 책임 떠넘기기 주도 개발 | … | 2 | 110 | 3 |
user
| id | username |
|---|---|
| 1 | ODee |
| 2 | Candy |
subject
| id | subject_name |
|---|---|
| 1 | infra |
| 2 | develop |
위에처럼 중복 데이터를 다른 테이블로 분리하여 정규화를 아주 간략하게 진행해 보았어요.
하지만, vertical 파티셔닝은 정규화 뿐만 아니라 여러 경우도 있어요. 예를 들면,
(출처: 김오디 ODee의 블로그)
위 처럼 블로그의 글들을 알아보는 페이지를 보면 글 제목, 작성일, 댓글 수가 사용할 데이터에요.즉, post 테이블은 body 데이터를 갖고 있지만 이 상황에서는 body 데이터를 사용하지 않아요. 심지어 body에 많은 내용을 넣다보니 데이터 크기는 다른 column 보다 클 거에요.
즉, body 데이터는 DB와의 I/O에 부담을 주는 column이 되는 거죠.
그래서 다음과 같이 분리해요.
Origin Table
post
| id | user_id | title | body | subject_id | read_count | comment_count |
|---|---|---|---|---|---|---|
| 1 | 1 | 데브옵스란? | … | 1 | 100_000_000 | 685 |
| 3 | 1 | 백엔드란? | … | 2 | 80_000_000 | 562 |
| 4 | 2 | 아.. 난 프론트야 | … | 2 | 10_000 | 2 |
| 7 | 2 | 책임 떠넘기기 주도 개발 | … | 2 | 110 | 3 |
After Vertical Partitioning Table
post
| id | user_id | title | body_id | subject_id | read_count | comment_count |
|---|---|---|---|---|---|---|
| 1 | 1 | 데브옵스란? | 1 | 1 | 100_000_000 | 685 |
| 3 | 1 | 백엔드란? | 3 | 2 | 80_000_000 | 562 |
| 4 | 2 | 아.. 난 프론트야 | 4 | 2 | 10_000 | 2 |
| 7 | 2 | 책임 떠넘기기 주도 개발 | 5 | 2 | 110 | 3 |
body
| id | body |
|---|---|
| 1 | … |
| 3 | … |
| 4 | … |
| 5 | … |
Vertical 파티셔닝은 큰 데이터 중 필요한 부분만 따로 저장하여 I/O 성능을 향상시키는 데 도움이 되요.
ᅳ Horizontal 파티셔닝
horizontal 파티셔닝은 데이터베이스 테이블을 특정 row을 기준으로 나누는 기술로, 주로 row을 기반으로 분할하는 것이에요. 아래 예시에서는 user_id를 기준으로 테이블이 두 개로 나눌거에요. 이는 대용량 테이블을 더 작은 단위로 분할해 각 파티션을 별도로 저장하는 방식이에요.
Original Table
youtube_subscription
| user_id | channel_id | alarm | membership |
|---|---|---|---|
| a | 1 | ... | ... |
| b | 4 | ... | ... |
| c | 2 | ... | ... |
| d | 1 | ... | ... |
After Horizontal Partitioning
youtube_subscription_1
| user_id | channel_id | alarm | membership |
|---|---|---|---|
| a | 1 | ... | ... |
| d | 1 | ... | ... |
youtube_subscription_2
| user_id | channel_id | alarm | membership |
|---|---|---|---|
| b | 4 | ... | ... |
| c | 2 | ... | ... |
horizontal 파티셔닝은 특정 조건에 따라 테이블을 나누어 부하를 분산시키면서도 데이터 무결성을 유지해요. 위 예시에서는 youtube_subscription_1과 youtube_subscription_2가 서로 다른 user_id 값을 갖고 있어 중복 없이 데이터를 분할한 거에요.
위 테이블의 데이터 최대치를 생각해 보아요.
사용자 수 : N 이고,
채널 수 : M 이라면,
최대 데이터 개수 : N * M 이 될 거에요.
우리는 다음과 같은 문제를 발견할 수 있어요.
- 테이블의 크기가 커질수록 인덱스의 크기도 커진다.
- 테이블에 읽기/쓰기가 있을 때 마다 인덱스에서 처리되는 시간도 조금씩 늘어난다.
(한 테이블에서 데이터가 엄청나게 많아지는 경우를 해결하기 위해 horizontal 파티셔닝은 여러가 방법론이 있는데 가장 대중적인 것은 hash-based 기반이에요.)
즉, horizontal 파티셔닝은 테이블의 크기가 커질수록 인덱스 처리 시간이 증가하는 문제를 완화하고 부하를 분산시키는 데 도움이 됩니다.
샤딩 (Sharding)
샤딩은 horizontal 파티셔닝과 유사하지만, 각 파티션을 독립된 데이터베이스 서버에 저장하는 방식이에요. 이를 통해 부하를 분산시키고 성능을 향상시키는 효과가 있어요.
정리해보면, 모든 파티션을 같은 DB 서버에 저장하면 horizontal 파티셔닝이고, 다른 DB 서버에 저장하면 샤딩인거죠.
레플리케이션 (Replication)
레플리케이션은 주 DB 서버(master/primary/leader)와 그로부터 지속적으로 복제되는 보조 DB 서버(slave/secondary/replica)를 가지는 방식이에요. 주로 가용성을 높이고 장애 대응을 위해 사용됩니다.
레플리케이션은 주 DB 서버에 문제가 발생할 경우 자동으로 보조 DB 서버로 전환하여 서비스를 지속할 수 있는 것을 목표로 해요.
우리들이 만든 애플리케이션이 DB서버에 read/write 요청을 보내는데, DB 서버에 문제가 생겨 접근이 되지 않게게 될 거에요. 이 방식을 해결하기 위한 방식이 replication 이에요.
DB 서버를 1개가 아니라 2개 이상으로 두어 주 DB서버와 보조 DB서버로 나누어요. 이렇게 주 DB서버와 주 DB서버로부터 계속 copy를 함으로써 똑같이 복사본을 유지하는 보조 DB 서버가 있는 방식을 replication 이라고 해요.
주 DB서버는 master / primary / leader 로도 불리고
보조 DB서버는 slave/ secondary / replica 로도 불려요.
그렇다면, replication을 왜 구성할까요?
primary DB 서버에 read/write를 하고 있었는데 primary DB서버에 문제가 생기면 그 때는 빠르게 백엔드 서버가 secondary DB 서버에 read/write를 하게 됩니다. 이것을 failover 라고 하는데 이렇게 빠르게 failover를 함으로써 서비스에 최대한 타격이 없도록 만들 수 있게 되요.
이런식으로 어떤 장애 상황이 발생했을 때도 계속해서 서비스를 유지하도록 하는 이러한 특성들을 HA(High availablity) 즉, 고가용성을 보장할 수 있게 되는 것이에요.
정리
| partitioning | sharding | replication |
|---|---|---|
| table을 목적에 따라 작은 table로 나누는 방식 | horizontal partitioning으로 나눈어진 table들을 다른 DB 서버에 저장하는 방식 | DB를 복제해서 여러 대의 DB 서버에 저장하는 방식 |
