RDBMS, NoSQL의 클러스터링/리플리케이션 방식
Last updated
Last updated
개념
여러 개의 DB를 수평 구조
로 구축하는 방식(DB 서버 확장)
Fail Over(장애 극복) 시스템을 구축하기 위해 사용
DB가 동작하지 않으면, 전체 서비스가 동작할 수 없다는 문제점을 해결하기 위해 클러스터링을 이용하여 DB 서버를 늘림
동기 방식
으로 노드들 간의 데이터 동기화
DB들 간의 데이터 무결성 검사(데이터가 일치하는지)를 하는 동기 방식으로 데이터를 동기화함
처리 방식
1개의 노드에 쓰기 트랜잭션이 수행되고, COMMIT
을 실행함
실제 디스트에 내용을 쓰기 전에, 다른 노드로 데이터의 복제를 요청함
다른 노드에서 복제 요청을 수락했다는 신호(OK)를 보내고, 디스크에 쓰기를 시작함
다른 노드로부터 신호(OK)를 받으면 실제 디스크에 데이터를 저장함
장점
노드들 간의 데이터를 동기화하기 때문에 항상 일관성있는 데이터를 얻을 수 있음
1개의 노드가 죽어도 다르 노드가 살아 있어 시스템을 계속 장애 없이 운영할 수 있음
여러 대의 DB 서버로 부하를 분산시켜 사용자의 요청을 더 많이 수용할 수 있음(로드 밸런싱
)
여러 대의 DB 서버를 가지므로, 높은 가용성을 보장함
DB 가용성: DB가 동작하고 있는 시간과 정지한 시간의 비율
DB 시스템을 구성할 서버나 스토리지 장비를 각가 2대 이상으로 구성해서, 한 쪽에 장애가 발생하더라도 단 시간내에 운용을 재개할 수 있도록 함
단점
여러 노드들 간의 데이터를 동기화하는 시간이 필요하기 때문에, Replication
에 비해 쓰기 성능이 떨어짐
장애가 전파된 경우, 처리가 까다로우며 데이터 동기화에 의해 스케일링(확장)에 한계가 있음
종류
Active-Active Clustering
DB 서버를 Active
(동작중) 상태로 두는 방식
서버하나가 죽어도 다른 서버가 역할을 바로 수행하기 때문에 중단되는 시간이 없음
여러 개의 서버가 하나의 스토리지를 공유함으로써 병목현상이 발생할 수 있음
병목현상: 전체 시스템의 성능이나 용량이 하나의 구성요소로 인해 제한을 받는 현상
Active-StandBy Clustering
DB 서버 하나는 Active
(동작중), 다른 하나는 StandBy
상태로 두는 방식
운영중인 서버가 정지되었을 경우, StandBy
중인 서버를 Active
상태로 전환하여 문제에 대응할 수 있음
서버가 한 대만 운영되기 때문에 병목 현상을 해결할 수 있음
서버가 다운되었을 경우, 다른 서버가 Active
로 전환되는데 시간이 들어, 서버가 중단되는 시간이 존재함
개념
여러 개의 DB를 권한에 따라 수직 구조
(Master-Slave)로 구축하는 방식
두 개 이상의 DBMS 시스템을 Master/Slave로 나눠서 동일한 데이터를 저장함
Master Node
는 쓰기 작업만 처리(수정사항 반영)하며 Slave Node
는 읽기 작업만 처리(실제 데이터 복사)함(기존의 부하를 분산)
DB 서버와 DB 스토리지 모두 확장
비동기 방식
으로 노드들간의 데이터를 동기화함(Mysql은 기본적으로 비동기 방식)
Master와 Slave간의 데이터 무결성 검사(데이터가 일치하는지)를 하지 않는 비동기방식으로 데이터를 동기화함
처리 방식
Master 노드에 쓰기 트랜잭션이 수행됨
Master 노드는 데이터를 저장하고 트랜잭션에 대한 로그를 파일에 기록함(BIN LOG)
Slave 노드의 IO Thread는 Master 노드의 바이너리 로그 파일(BIN LOG)을 릴레이 로그 파일(Replay Log)에 복사함
Slave 노드의 SQL Thread는 파일(Replay Log)를 한 줄씩 읽으며 데이터를 저장함
장점
DB 요청의 60~80% 정도가 읽기(SELECT
) 작업이기 때문에 Slave
DB 만으로도 충분히 성능을 높일 수 있음
비동기 방식으로 운영되어 지연 시간이 거의 없음
단점
노드들 간의 데이터 동기화가 보장되지 않아 일관성있는 데이터를 얻지 못할 수 있음
Master 노드가 다운되면 복구 및 대처가 까다로움
테이블의 데이터가 엄청나게 많을 경우, Slave DB 서버를 N대로 늘려도 원하는 데이터를 데이블로부터 찾는데 많은 시간이 소요될 수 있음
이때는 Sharding
방식을 활용함
데이터 정합성 문제
비동기 복제(Asynchronous replication)
비동기 리플리케이션은 Master/Slave 서버 간 데이터 동기화까지의 시간이 소요되기 때문에 데이터 정합성 문제가 발생할 수 있음
반동기 복제(Semi-synchronous replication)
Master DB가 Slave DB로부터 Replay Log 기록이 완료되었다는 ACK를 받고 트랜랙션을 진행하는 방식
Replay Log 복제 방식을 통해 Slave DB의 모든 데이터 복제 과정을 기다리지 않고, 여러 Slave 중 단 1대만이라도 Replay Log를 수신했다면, Master DB는 해당 트랜잭션을 완료함
Master DB가 Slave DB에게 DB 변경 내용을 언제 전달하냐에 따라서 AFTER_SYNC, AFTER_COMMIT 2가지 방식으로 구분됨
비동기 리플리케이션 방식에 비해 더 많은 DB 성능저하가 발생하지만, Replay Log 보장으로 최소한의 데이터 정합성을 확보할 수 있음
개념
데이터베이스를 특정 조건을 적용해 여러 부분으로 분할하는 것
하나의 DBMS에 데이터가 너무 큰 테이블이 들어갈 경우, 테이블이나 인덱스를 작은 파티션 단위로 나누어 사용하는 기법
종류
Column 기준
수직 파티셔닝
데이터의 갯수를 기준으로 나누어 파티셔닝 진행
데이터와 인덱스의 갯수가 줄어들어 성능 향상에 도움
데이터를 찾는 과정이 기존보다 복잡하기 때문에 레이턴시 증가
수평 파티셔닝
같은 타입의 데이터가 저장 됨
데이터 압축률을 높일 수 있고 조회 시 필요 없는 컬럼을 조회하지 않아도 됨
수직적 확장과 마찬가지로 데이터 찾는 과정의 복잡
4가지 분할 기준 존재
범위 분할
목록 분할
해시 분할
합성 분할
장점
파티션별 연산으로 I/O분산이 가능하여 성능 향상
파티션별로 백업 및 복구 가능
전체 데이터 손실 가능성 줄어듦
단점
테이블이 여러개로 나누어짐
테이블간 JOIN연산에 대한 비용 증가
테이블과 인덱스를 별도로 파티셔닝할 수 없음
개념
같은 테이블 스키마를 가진 데이터를 다수의 DB에 분산하여 저장하는 방법
테이블을 특정 기준으로 나눠서 저장 및 검색함
다수의 복제본으로 구성하고, 각 샤드에 어떤 데이터가 저장될 지를 Shard Key
를 기준으로 분리
Shard Key
를 어떻게 정의하느냐에 따라 데이터를 효율적으로 분산시키는 것이 결정됨
목적
DB 트래픽을 분산할 목적
데이터가 급격히 증가하게 되거나 트래픽이 특정 DB로 몰리는 상황을 대비해서 빠르고 유연하고 안전하게 DB를 증설할 수 있게 함(DB 서버의 부하를 분산)
Scale-up(수직적 확장)에는 한계가 있고, Scale-out(수평적 확장)은 동기화라는 제약이 따름
DB 서버의 샤딩은 대규모 시스템 설계와 확정성 확보에 필수 불가결인 요소가 됨
특징
여러대의 서버를 사용하여 데이터를 분산 시킴
Request에 대한 부하를 서로 다른 샤드가 있는 여러 서버에 분산 가능
병렬처리로 확장성과 성능 향상 가능
수평적 파티셔닝의 일종으로 볼 수 있음
장점
Scale-Out 가능
DB스키마를 유지하기때문에 DB확장에 유리
스캔 범위를 줄여 빠른 쿼리 반응 속도
샤드 단위의 장애 발생
단점
프로그래밍의 복잡도 증가
데이터가 한 쪽 샤드로 몰릴 경우 무의미 함
하나의 서버가 고장날 시 데이터 무결성이 깨질 수 있음
잘못사용 시 큰 리스크
샤딩 한번 이용시 샤딩 이전의 구조로 돌아가기 힘듦
샤딩을 피하는 대표적인 방법
데이터베이스 서버의 Scale-Up
read의 부하가 클 경우: cache사용, replication
테이블의 일부 컬럼만 주로 사용할 경우: Vertical Partitioning
Shard Key 방식
Hash Sharding: 데이터를 어디에 넣을지 해싱 결과에 따라 DB 서버에 저장
Dynamic Sharding: 테이블 형식의 데이터를 바탕으로 샤드를 결정해서 저장
Entity Group: 관련된 데이터를 하나의 샤드로 사용하는 방식
종류
모듈러 샤딩 (해시 샤딩)
DB id(pk)를 Hashing하여 Shard Key결정
레인지샤딩에 비해 데이터가 균일하게 분산
클러스터가 포함하는 Node갯수를 변경하면 해시크기가 변경되고 key또한 변경되어 ReSharding이 필요
일정 수준에서 유지될 것으로 예상되는 데이터 성격을 가진 곳에 적절
레인지 샤딩(Range Sharding)
해시샤딩에 비해 기본적으로 증설작업에 재정렬 비용이 들지 않고 증설작업에 드는 비용이 크지 않음
활성유저가 몰린 일부 DB에 데이터가 편향될 수 있음
파티셔닝과 샤딩의 차이
수평적 파티셔닝
같은 스키마에 다른 테이블로 쪼개서 저장
동일한 DB 서버 내에서 테이블 분할
샤딩
나눈 데이터들을 Shard key를 기준으로 스키마를 복제하여 다른 DB에 저장
DB 서버 분할
개념
데이터의 일관성을 보장하기 위한 방법으로, Transaction 처리의 동시성을 제어하기 위한 기능
여러 커넥션에서 동시에 동일한 자원을 요청할 경우, 순서대로 한 지점에 하나의 커넥션만 변경할 수 있게 해주는 역할
종류
Shared Lock
(공유락, Read Lock)
데이터를 읽을 때(Select
) 사용하는 Lock
공유락을 설정한 경우, 추가로 공유락을 설정할 수는 있지만, 배타락은 설정할 수 없음
한 프로세스가 보고 있는 데이터를 다른 프로세스가 볼 수는 있지만, 변경할 수는 없음
Exclusive Lock
(배타락, Write Lock)
데이터를 변경할 때(Insert
, Update
, Delete
) 사용하는 Lock
락이 해제되기 전에는 다른 공유락과 배타락을 설정할 수 없음(읽기와 쓰기 모두 불가능)
두 개 이상의 트랜잭션들이 동시에 진행될 때, 서로가 서로에 대한 Lock을 소유한 상태로 대기 상태로 빠져서 더 이상 진행하지 못하는 상황
특정 자원(테이블 또는 행)의 Lock을 획득한 채, 다른 트랜잭션이 소유하고 있는 Lock을 요구하면 발생함
해결 방법
트랜잭션 진행방향을 같은 방향으로 처리
테이블A 업데이트 후, 테이블B 업데이트
트랜잭션 처리 속도를 최소화
트랜잭션 속도가 빠르면 commit 처리도 빠르게 되기 때문에 다른 트랜잭션에서 테이블이 잠길일이 없음
timeout을 이용하여 잠금해제 시간 조절
SET LOCK_TIMEOUT
으로 잠금해제 시간을 설정하여 무기한 대기하지 않고 만료되어 다음 작업을 진행할 수 있음
일반적인 DBMS에서는 데드락 탐지(Deadlock detection) 기능을 제공함
데드락이 발견되면 자동으로 해소해줌
실제 데드락 상황이 아니더라도, 락에 대한 대기시간이 설정된 시간을 초과하면 데드락으로 처리됨