Notice
Recent Posts
Recent Comments
Link
«   2025/03   »
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31
Archives
Today
Total
관리 메뉴

장미정원

[DB] 파티셔닝, 샤딩, 레플리케이션 본문

Back-end

[DB] 파티셔닝, 샤딩, 레플리케이션

신희성 2024. 12. 16. 19:24

들어가며

서버 애플리케이션의 규모가 커질 수록 트래픽이 많아지며 데이터베이스에 쓰기, 수정, 읽기 등등의 작업이 빈번하게 일어나게 됩니다. 이러한 상황에서 서비스에 예상치 못한 장애가 발생할 수 있습니다. 그렇기 때문에 높은 트래픽의 상황에 대비하여 시스템의 확장성, 고가용성, 성능을 높히기 위한 노력이 필요합니다. 데이터베이스의 성능 향상을 위한 기술은 파티셔닝, 샤딩, 레플리케이션에 대해 알아보겠습니다.

 

파티셔닝

데이터베이스 파티셔닝은 데이터베이스의 테이블을 분활하여 저장하는 기술입니다. 데이터베이스에 데이터가 많이 저장되어있다면 그만큼 인덱스 자료구조의 크기가 큰 것이며 쓰기 작업시 B-Tree 재구조화 시간도 오래걸리는등 성능이 많이 떨어지게 됩니다.

파티셔닝은 수직(Vertical) 파티셔닝, 수평(Horizontal) 파티션닝으로 나뉩니다.

 

수직 파티셔닝

 

수직 파티셔닝은 column을 기준으로 테이블을 분리하는 것입니다. 정규화를 진행하면서 테이블을 수직으로 분리하는 작업도 수직 파티셔닝에 해당 될 수 있습니다.

 

 

한가지 예로 큰 용량을 가진 컬럼이 있다면 해당 row 조회시 불필요한 연산이 발생하여 성능이 저하될 수 있습니다. 이럴때 해당 컬럼을 다른 테이블로 분리하여 필요할 때만 조인하여 조회할 수 있어 성능을 향상할 수 있습니다.

 

수평 파티셔닝

 

수평 파티셔닝은 테이블의 row를 기준으로 테이블을 분리하는 것입니다. 수평 파티셔닝은 테이블의 스키마를 변경하지 않으며 주로 테이블에 심각하게 많은 양의 데이터를 저장하고 있을 때 수평으로 테이블을 분리하여 부하를 분산합니다.

 

 

이러한 수평 파티셔닝은 데이터 추가, 조회시 적절한 파티션에 분활하는 것이 중요합니다. 이때 여러가지 방법들 중 hash-based partitioning(해시 기반 분활)에 대해 설명해보겠습니다.

 

partition key를 설정하여 partition key를 hash function에 넣어 나온 값에 따라 적절한 파티션에 데이터를 추가하는 방식입니다. 데이터 조회시 partition key를 활용하여 조회시 하나의 파티션에 대해서만 탐색하면 되기 때문에 성능이 좋지만 partition key를 활용하지 않고 조회한다면 모든 파티션을 조회해야하는 문제가 있습니다. 그렇기 때문에 조회시 많이 사용되는 attribute를 partition key로 설정해야합니다~!

 

샤딩

 

샤딩은 수평 파티셔닝된 테이블을 각각의 데이터베이스에 분산 저장하는 기술입니다. 수평 파티셔닝은 테이블을 row 기준으로 분활하여 저장하지만 하나의 데이터베이스 안의 여러 테이블로 저장하기 때문에 테이블을 분활한다고 해도 데이터베이스 자체의 부하를 줄일 수는 없었습니다. 하지만 분활된 테이블을 각각의 데이터베이스에 저장한다면 부하가 분산되는 효과를 얻을 수 있어 효율적입니다.

 

이때 기존에 partition key라고 말하는 key는 shard key라고 불리며 각각의 파티션은 shard라고 부릅니다.

 

샤딩스피어

 

샤딩스피어는 분산된 샤드들을 모아 하나의 논리적 테이블로 접근할 수 있게 해주는 기술입니다.

 

레플리케이션

 

레플리케이션은 데이터베이스의 복제본을 두어 데이터베이스의 고가용성과 안정성을 높히는 기술입니다. 레플리케이션을 사용하면 데이터베이스의 변경사항을 여러 복제본에 적용하여 만약 하나의 데이터베이스에 장애가 발생시 다른 복제본 데이터베이스에 작업을 처리하여 가용성을 높힐 수 있습니다.

 

원본 서버는 Master, Primary 등으로 불리며 복제 서버는 Salve, Secondary 등으로 불립니다. Master 데이터베이스에서 장애가 발생시 Salve를 빠르게 Master로 승격시켜 빠른 서비스 복구가 가능합니다. 하지만 물리적으로 다른 데이터베이스이기 때문에 데이터 동기화가 어렵습니다.

 

 

이러한 구조로 Msater 데이터베이스에서는 Write 작업만 담당하고 Salve 서버에서는 Read 작업만 담당하는 CQRS 패턴을 구현하여 조회 성능을 끌어올릴 수 있습니다.

 

ref. 쉬운코드