4장. 데이터베이스와 아키텍쳐 구성 - (2) 리플리케이션

이번 포스팅에서는 리플리케이션에 대해 알아본다.

 

리플리케이션

리플리케이션이 나오게된 배경은 다음과 같다. '저장된 데이터가 손실되면 어떻게 하지?'

이전 포스팅에서 설명한 Active - Active, Active - Stand by 클러스터 구성에서
서버 부분은 다중화할 수 있어도 저장소는 다중화할 수 없어서 데이터를 다중화할 수 없는 단점이 존재한다.

즉, 저장소가 날아가면 데이터를 잃게 된다.

 

 

이런 상황에 대응하기 위해 '실제 데이터가 저장되는 저장소도 복제하자!' 가 해결 방안이였으며

이에 대한 클러스터 구성을 리플리케이션 한다.

* 리플리케이션이란? Replication, 즉 복제를 뜻한다.

DB 서버와 저장소 세트를 복제하여 복수로 준비하는 것을 뜻한다.

 

 

리플리케이션은 서버와 저장소가 동시에 사용 불능일 때 멀리 떨어진 다른 세트가 서비스를 계속 실행할 수 있는 점에서 매우 가용성이 높은 아키텍처이다. => '달걀을 한 바구니에 다 담지 않는 대책'

 

동기화하는 측의 부모(Active) 데이터베이스를 마스터

동기화되는 측의 자식(Stand by) 데이터베이스를 슬레이브 라고 부른다.

 

리플리케이션 구성을 함으로써 마스터 - 슬레이브 구조에서 클라이언트가 마스터 디비에 crud를 거치면

그 데이터는 슬레이브에 동기화하여 백업 용도로 사용할 수 있는 장점과

 

더 나아가 슬레이브 디비를 백업용으로 하기엔 아쉽기 때문에
슬레이브 디비를 클라이언트 요청중 Read 용으로만 나눠 부하를 분산하는 용도의 장점도 있다.

 

 

리플리케이션 주의할 점

Active 측 저장소의 데이터는 항상 사용자로부터 갱신된다는 점을 기억해야 한다.

그렇기에 Stand by 측 데이터에 갱신을 하지 않으면 Active 측과의 데이터 정합성을 유지할 수 없다.

리플리케이션에서 Active 측의 데이터를 Stand by 측 서버에 갱신해야 하는데
주기를 얼마로 할 것인가와 성능은 항상 고려해야 한다.

 

오래된 데이터라도 좋으니 참조밖에 하지 않는 경우라면 피라미드 형태의 리플리케이션으로 구성한다.

손자나 증손사 세트를 만들어 데이터가 오래되도 참조만 하면 될 경우 처리를 손자나 증손자 세트에 하도록

하여 부모가 담당하는 부하를 분산할 수 있다.

다만, 이 형태 또한 DB 서버의 라이선스료, 저장소 비용 등이 증가함으로 고려해야 한다.

 

피라미드형 리플리케이션

 

---

이전 포스팅과 이번 포스팅을 통해 4장 데이터베이스 아키택쳐를 간략하게 공부할 수 있었다.

하지만 아직 데이터 정합성에 대한 방법은 어떻게 하는지 궁금점이 해결되지 않았기에

다음 포스팅은 데이터 정합성을 어떻게 유지하는지에 대해 포스팅할 예정이다.