본문 바로가기
Back/DB

[DB] Replication (복제)

by 오엥?은 2023. 4. 27.
반응형

 

Replication

Replication은 복제를 뜻하며 2대 이상의 DBMS를 나눠서 데이터를 저장하는 방식이며, 사용하기 위한 최소 구성은

Master / Slave 구성이어야 한다.

 

Master DBMS 역할

 : 웹서버로 부터 데이터 등록, 수정, 삭제 요청 시 바이너리로그(Binarylog)를 생성하여 Slave 서버로 전달한다.

 (웹 서버로부터 요청한 데이터 등록, 수정, 삭제 기능을 하는 DBMS로 많이 사용된다.)

• Slave DBMS 역할

 : Master DBMS로 부터 전달받은 바이너리로그를 데이터로 반영하게 된다. 

 (웹 서버로부터 요청을 통해 데이터를 불러오는 DBMS로 많이 사용된다.)

 

 

Replication을 사용하는 이유

 

① 스케일 아웃(Scale-out)

→ 사용자가 늘어남에 따라 커지는 트래픽으로 인한 DB 서버의 부하를 분산할 수 있다.

→ 갑자기 늘어나는 트래픽에도 유연하게 대처할 수 있다.

 

② 데이터 백업

→ 의도치 않게 데이터가 삭제되면 백업을 진행하게 된다.

→ 동일한 서버 내에서 백업이 실행되는 경우 DB 서버의 부하가 크게 발생한다.

→ 데이터 백업을 레플리카 서버에서 실행한다.

 

③ 데이터 분석

→ 서비스에서 사용되는 쿼리가 아닌 차세대 비즈니스 모델 발굴을 위해 분석용 쿼리를 실행하기도 한다.

→ 대량 데이터 조회 및 집계 연산도 많기 때문에 실제 DB 서버에는 부하가 없도록 한다.

→ 여분의 레플리카 서버를 분석용 쿼리 전용으로 사용할 수 있다.

 

④ 데이터의 지리적 분산

→ 서비스에서 사용되는 애플리케이션 서버가 DB 서버와 장거리로 떨어져 있을 수도 있다.

→ 이 경우 두 서버의 통신 시간은 거리에 비례한다.

→ 애플리케이션 서버와 가까운 위치에 레플리카 서버를 구축해서 응답 시간을 개선한다.

→ 소스 서버에 문제가 생겼을 때 대체 서버의 역할을 한다. 

 

 

◽ Replication을 구성하였을 때의 장점과 단점

 

 장점

① 가용성이 높아진다.

 Master DB 가 장애로 죽을 경우, Slave 서버를 마스터로 승격시켜서 서비스를 빠르게 복구할 수 있다.

② 부하분산이 가능하다.

 Master DB에서는 WRITE(Insert, Update, Delete) 작업을, Slave DB에서는 READ(Select) 작업을 처리하게 하여 부하를 분산시킬 수 있다.인덱스가 걸려있는 테이블의 WRITE 작업은 READ 작업보다 상대적으로 더 많은 시간이 걸릴 뿐 아니라, 웹 서비스는 일반적으로 WRITE보다 READ의 작업비중이 높다. 그렇기 때문에 WRITE/READ를 분리하여 처리하게 된다면 부하를 분산시키는 데 효과가 있다.

(Slave DB는 보통 ReadOnly 설정을 해두는 것이 일반적이다.)

 

• 단점

① 각각의 서로 다른 서버로 운영하다보니 버전을 관리해야 한다. 

 버전을 같게해 주는 것이 좋은데, 버전이 다를 경우 적어도 Slave 서버가 상위버전이어야 한다.

② Master에서 Slave로 비동기 방식으로 데이터를 초기화 하기 때문에 일관성있는 데이터를 얻지 못할 수도 있다.

 동기 방식으로 Replication을 할 수는 있지만 이럴 경우 속도가 느려진다는 문제점이 있다.

③ Master 서버가 다운이 될 경우, 복구 및 대처가 까다롭다.

 

반응형

'Back > DB' 카테고리의 다른 글

[DB] JPA  (0) 2023.05.12
[DB] MyBatis  (0) 2023.05.09
[DB] JdbcTemplate  (0) 2023.05.08
[DB] H2 데이터베이스 설치  (0) 2023.05.04
[DB] Sharding (샤딩)  (0) 2023.04.27