클러스터링 / 레플리케이션

 데이터 베이스는 현대 정보 시스템에서 필수적인 역할을 한다.

사용자 요청이 폭증하는 환경에서도 안정성과 성능을 유지하는 것이 매우 중요하다. 이를 위해 시스템은 데이터 손실 없이 지속적으로 서비스를 제공해야 하고, 처리 속도와 확장성도 확보해야 한다.

 

 클러스터링(Database Clustering)과 레플리케이션(Replication)은 이러한 요구사항을 충족하기 위해 널리 사용되는 기술이다. 클러스터링은 여러 서버를 하나의 시스템으로 동작하게 만들어 부하 분산과 장애 복구를 지원하고, 레플리케이션은 데이터를 복제하여 읽기 성능을 최적화하고 데이터 가용성을 보장한다.

 

클러스터링

클러스터링은 여러 데이터베이스 서버를 하나의 논리적 시스템처럼 동작하도록 구성하는 기술로, 단일 데이터베이스를 연결하는 둘 이상의 서버 또는 인스턴스를 결합하는 프로세스이다.

DB 클러스터링 자체가 속도를 개선한다 보다는, 여러 대의 DB 서버로 클러스터링 했기 때문에, 이를 이용해 로드밸런싱을 통한 속도 개선으로 더 많은 사용자의 용청에 대한 수용 능력의 증가로 DB 속도 개선에 영향을 준다고 생각할 수 있다.

 

클러스터링의 주요 구조

1. 활성-활성 클러스터링 (Active-Active Clustering)
   모든 서버가 동시에 활성화되어 데이터 요청을 처리한다. 부하 분산을 통해 각 서버로 작업이 고르게 분배되며, 각 서버에서 처리한 데이터는 실시간으로 동기화된다.

   

   • 특징 : 
     • 부하 분산 : 작업 요청이 클러스터에 연결된 모든 서버로 분산된다. 트래픽 증가 시 확장 가능하다.
     • 데이터 동기화 : 서버들이 실시간으로 데이터를 공유하며, 데이터 일관성을 유지해야 한다.
     • 장애 복구 : 한 서버가 장애를 일으켜도 다른 서버가 계속 요청을 처리한다.
   • 장점 :
     • 모든 서버를 활용하여 높은 성능을 유지.
     • 서버 장애 시 다른 활성 서버가 즉시 작업을 이어받아 안정성이 뛰어남.
   • 단점 :
     • 데이터 동기화 비용이 증가하며, 성능 저하 가능.
     • 동시 쓰기 작업에서 데이터 충돌 위험.
   • 사용 사례 :
     • 금융 거래 시스템 : 초당 수백 건의 트랜잭션을 처리.
     • 실시간 분석 플랫폼 : 대량의 데이터를 실시간으로 처리.
2. 활성-대기 클러스터링 (Active-Passive Clustering)
   하나의 노드가 활성 상태로 모든 요청을 처리하며, 나머지 노드는 대기 상태로 유지된다. 활성 노드에 장애가 발생하면 대기 노드가 자동으로 활성화(Failover)되어 서비스를 이어간다.

   

   • 특징 : 
     • Failover 메커니즘 : 대기 서버는 활성 서버의 상태를 지속적으로 모니터링한다.
     • 단일 처리 서버 : 작업을 하나의 활성 서버가 처리하므로, 동시 요청 처리량이 제한될 수 있다.
   • 장점 :
     • 데이터 충돌 위험이 없음.
     • 장애 복구(Failover)가 간단하며 신뢰도가 높음.
   • 단점 :
     • 대기 노드가 작업을 수행하지 않으므로 리소스 활용도가 낮음.
   • 사용 사례 :
     • 은행 고객 정보 시스템: 장애 시 빠른 복구가 필수.
     • 재난 복구 시스템: 데이터 손실을 최소화.

 

레플리케이션

레플리케이션(Replication)은 데이터를 여러 서버에 복제하여 데이터 가용성을 높이고, 읽기 성능을 최적화하는 기술로, 이 방식은 데이터베이스의 주요 작업을 분산 처리하며, 장애 복구, 성능 최적화, 데이터 백업과 같은 목적에 활용된다.

클러스터링과는 달리, 각 서버가 독립적으로 동작하며, 복제된 데이터는 사용자가 지정된 서버에서 읽기/쓰기 작업을 수행한다.

레플리케이션의 주요 구조

1. 단방향 복제 (Primary-Secondary Replication)

- 한 서버(Primary)가 데이터를 작성하면, 다른 서버(Secondary)가 이를 복제한다. Secondary 서버는 읽기 요청을 처리하여 Primary 서버의 부하를 줄인다.

특징:

• 읽기 작업은 Secondary 서버에서 수행.
• 쓰기 작업은 Primary 서버에서만 가능.
• Secondary 서버는 Primary 서버의 바이너리 로그(Binary Log)를 통해 데이터를 동기화.

장점 :

• 읽기 성능 최적화, Primary 서버의 부하를 줄임.
• 장애 복구 및 데이터 백업으로 활용 가능.

단점 :

• Secondary 서버에서는 쓰기 작업 불가능.
• 데이터 복제 지연 발생 가능.

사용 사례:

• 콘텐츠 배포 네트워크(CDN): 대량의 읽기 요청 처리.
• 읽기 중심 애플리케이션: 블로그, 뉴스 사이트.

 

2. 양방향 복제 (Multi-Master Replication)

모든 서버가 데이터를 쓰고 읽을 수 있으며, 각 서버 간 데이터를 동기화한다. 주로 지리적으로 분산된 환경에서 사용된다.

특징:

• 읽기 및 쓰기 요청을 여러 서버로 분산하여 성능 향상.
• 데이터 충돌 방지를 위해 추가 관리 필요.
• GTID(Global Transaction ID)와 같은 기술을 활용하여 트랜잭션을 식별.

장점 :

• 쓰기 작업 분산 가능.
• 고가용성과 데이터 일관성을 유지.

단점 :

• 데이터 충돌 문제 발생 가능(동시 쓰기).
• 복잡한 동기화 관리가 필요.

사용 사례:

• 글로벌 분산 데이터베이스: 여러 지역에서 데이터를 쓰고 읽는 환경.
• 협업 도구: Google Docs처럼 동시 작업이 많은 시스템.

 

3. 체인 복제 (Chained Replication)

Primary 서버가 Secondary 서버들에 순차적으로 데이터를 복제하는 방식이다.

Primary 서버 → Secondary 1 → Secondary 2 → Secondary 3 형태로 데이터를 전달한다.

특징:

• 복제 경로가 길어질수록 데이터 복제 지연 시간이 증가.
• 관리가 단순하며 데이터 복제가 자동으로 이루어짐.

장점 :

• 설정과 유지 관리가 간단.
• 특정 환경에서 효율적인 데이터 복제 제공.

단점 :

• 복제 지연 가능성.
• 복제 체인의 일부 서버가 실패하면 전체 복제에 영향을 미칠 수 있음.

사용 사례:

• 로그 관리 시스템: 데이터 일관성이 덜 중요한 환경.
• 백업 아카이브: 여러 단계로 데이터를 복제해 저장.

 

레플리케이션의 데이터 복제 방법

1. 바이너리 로그 기반 복제 (Binary Log-Based Replication)

• Primary 서버의 **바이너리 로그(Binary Log)**에 기록된 데이터를 Secondary 서버가 읽어와 적용.
• MySQL과 MariaDB에서 널리 사용.

장점: Primary 서버의 성능에 큰 영향을 주지 않음. 비동기식 복제와 결합하여 유연성 제공.

단점: 복제 지연 발생 가능.

 

2. 이벤트 기반 복제 (Event-Based Replication)

• 데이터 변경 작업이 발생할 때 이벤트 단위로 복제.
• 데이터 변경 트래커나 트리거(Trigger)를 통해 데이터 동기화 수행.

장점 : 실시간 복제 가능, 트랜잭션 기반 데이터 동기화 제공.

단점 : 관리 및 설정이 복잡할 수 있음.

 

3. 스냅샷 기반 복제 (Snapshot-Based Replication)

• 데이터베이스의 특정 시점(Snapshot)에서 데이터를 복사하여 복제.
• 초기 동기화 또는 정기 백업에 적합.

장점 : 데이터베이스를 특정 시점으로 복구 가능, 초기 대규모 데이터 동기화에 적합.

단점 : 실시간 복제에는 적합하지 않음.

 

4. GTID 기반 복제 (Global Transaction ID-Based Replication)

• 모든 트랜잭션에 고유 식별자(GTID)를 부여하여 복제 관리.
• 데이터 일관성을 강화하고, 장애 복구를 단순화.

장점 : 장애 복구 용이, 데이터 일관성 유지.

단점 : 설정 및 관리가 복잡할 수 있음.

 

5. 스트리밍 복제 (Streaming Replication)

• 데이터 변경 내용을 실시간 스트림으로 Secondary 서버에 전송.
• PostgreSQL에서 주로 사용.

장점 : 낮은 복제 지연, 장애 복구에 적합.

단점 : 네트워크 성능에 의존.

 

레플리케이션 방식 선택 시 고려사항

1. 읽기 성능 최적화: 단방향 복제.
2. 쓰기 요청 분산: 양방향 복제.
3. 장애 복구 단순화: GTID 기반 복제.
4. 데이터 백업 및 복구: 스냅샷 기반 복제.
5. 실시간 복제: 이벤트 기반 또는 스트리밍 복제.

 

클러스터링 vs 레플리케이션

	클러스터링	레플리케이션
목적	고가용성과 부하 분산 확보	데이터 가용성과 읽기 성능 최적화
구성 요소	여러 서버와 클러스터 관리 SW	주 DB(Master)와 복제 DB(Slave)
동작 방식	하나의 논리적 시스템으로 작동	데이터를 복제하여 독립적으로 읽기/쓰기 분담
주요 특징	부하 분산, 장애 복구 지원	데이터 동기화, 읽기 작업 분산
단점	동기화 비용, 설정 복잡성	동기화 지연, 데이터 일관성 문제 발생 가능
사용 사례	실시간 트랜잭션 시스템, 대규모 온라인 서비스	읽기 중심 서비스, 데이터 백업

 

 

 

 

- 클러스터링 방식에는 동작 방식에 따라 활성-활성, 활성-대기로 나뉘고 구현 방식에 따라 공유 스토리지, 분산 방식으로도 나눌 수 있다. 이 부분에 대해서는 나중에 추가로 학습하면 좋을 것 같다.

- 클러스터링과 레플리케이션은 함께 사용하면 더 강력한 DB를 구축할 수 있다. 시스템의 요구사항에 맞게 알맞은 방식을 선택해 설계에 알맞은 DB를 구축할 수 있도록 노력하자. 

 

출처

https://velog.io/@kwontae1313/DB-%ED%81%B4%EB%9F%AC%EC%8A%A4%ED%84%B0%EB%A7%81DB-Clustering%EC%9D%B4%EB%9E%80

DB 클러스터링(DB Clustering)이란?

https://tecoble.techcourse.co.kr/post/2021-09-18-replication_clustering/

Replication과 Clustering

 

https://nesoy.github.io/articles/2018-02/Database-Replication

Database의 리플리케이션(Replication)이란?

 

https://mangkyu.tistory.com/97

[Database] 리플리케이션(Replication) vs 클러스터링(Clustering)