논리적과 스트리밍 복제의 차이 및 사용 사례

 

PostgreSQL에서 데이터 복제(Data Replication)란?

데이터를 배포하거나 문제가 발생할 경우를 대비하여 재해 복구에 사용할 수 있는 백업을 확보하기 위해서는 데이터베이스에 저장된 정보를 복제하는 것이 필수적입니다. 이름에서 알 수 있듯이 복제(replication)는 모든 사용자가 동일한 수준의 정보에 접근할 수 있도록 컴퓨터 서버의 한 데이터베이스에서 다른 서버의 다른 데이터베이스로 데이터를 복사하는 프로세스입니다. 컴퓨팅에서 복제는 디지털 시스템의 결함을 제거할 때 사용됩니다.

 

복제를 함으로써 데이터 사일로를 없애고, 중요한 정보를 보호하며, 개발 프로세스를 간소화시킬 수 있습니다. 

 

PostgreSQL에는 논리적 복제(Logical Replication) 및 스트리밍 복제(Streaming Replication)의 두 가지 옵션이 있습니다. 이 두 가지 방법은 다양한 사용 사례에 적합하며, 개발자마다 어느 한 방법을 더 선호하는 경향이 있을 수 있습니다. 하지만 두 방법을 모두 이해할 수 있다면 다양한 시나리오에서 어떤 방법을 적용할지 결정할 수 있습니다. 

 

그럼 이제 PostgreSQL의 논리적 복제(Logical Replication)와 스트리밍 복제(Streaming Replication)의 장단점 및 사용 사례를 살펴보겠습니다. 

PostgreSQL의 논리적 복제 (Logical Replication)

 

 

PostgreSQL v10부터 도입된 논리적 복제는 복제 ID에 따라 데이터 객체와 그 변경 사항을 복사 및 복제하는 방식으로 작동합니다. 

 

대부분의 경우 데이터 복제 ID는 기본 키(primary key)입니다. PostgreSQL에서는 사용자가 복제된 데이터와 정보 보안을 세밀하게 제어할 수 있도록 해줍니다. 

 

논리적 복제는 게시(publish)와 구독(subscribe) 모델을 통해 하나 이상의 구독자(subscriber)가 게시자(Publisher) 노드에서 하나 이상의 발행물(publication)을 구독할 수 있는 방식으로 작동합니다. 구독자는 발행물에서 정보를 가져와서 계단식 복제(cascade replication) 또는 더 복잡한 구성을 위해 데이터를 다시 게시할 수 있습니다. 

 

논리적 데이터 복제는 트랜잭션 복제의 형태를 취하기도 합니다. 엔지니어가 테이블을 복사하려는 경우 이 복제 방법을 사용하여 게시자 측에서 데이터의 스냅샷을 만들어 구독자의 데이터베이스로 전송할 수 있습니다. 

 

구독자가 원본 데이터를 변경하면 게시자 데이터베이스는 실시간으로 업데이트를 받습니다. 단일 구독을 사용하는 발행물의 트랜잭션 일관성을 보장하려면 구독자가 발행자와 동일한 순서로 데이터를 적용해야 합니다. 

 

PostgreSQL 논리적 복제의 장점

논리적 복제를 통해 사용자는 쓰기(writes)를 위한 대상 서버를 사용할 수 있으며, 개발자는 서로 다른 인덱스와 보안 정의를 사용할 수 있습니다. 이를 통해 퍼블리셔와 구독자 간에 데이터를 전송할 때 향상된 유연성을 제공합니다. 

 

1. 교차 버전 지원 (Cross-version support)

논리적 복제는 교차 버전(cross-version) 지원이 제공되며, PostgreSQL 버전이 다르더라도 복제 설정이 가능합니다. 또한 이벤트 기반 필터링도 제공됩니다. 발행물은 여러 구독을 가질 수 있으므로 광범위한 네트워크에서 데이터를 쉽게 공유할 수 있습니다. 

 

2. 서버 부화 최소화 (Minimum server load)

트리거 기반 솔루션에 비해 서버 부하를 최소화하는 동시에 더 작은 세트 복제를 통해 유연한 스토리지를 제공합니다. 논리적 데이터 복제는 기본 파티션 테이블에 포함된 데이터까지 복사할 수 있습니다. 

 

또한 논리적 복제 사용시 설정 중에도 데이터를 변환할 수 있으며, 게시자 간에 병렬 스트리밍(parallel streaming)이 가능하다는 점도 빼놓을 수 없습니다.  

 

PostgreSQL 논리적 복제의 단점

논리적 복제는 시퀀스, 큰 개체, 구체화된 뷰, 파티션 루트 테이블 및 외부 테이블을 복사하지 않습니다. 

 

PostgreSQL 논리적 복제는 DML 작업에서만 지원됩니다. 개발자는 DDL 또는 잘라내기를 사용할 수 없으며 스키마를 미리 정의해야 합니다. 또한 양방향의 상호 복제를 지원하지 않습니다. 

 

사용자가 테이블의 복제된 데이터에 대한 제약 조건과 충돌하는 경우 복제가 중지됩니다. 충돌의 원인을 해결해야만 복제가 재개됩니다. 

 

의도하지 않은 충돌은 팀의 추진력을 멈출 수 있으므로 문제를 신속하게 해결하는 방법을 이해해야 합니다. 문제를 신속하게 처리하지 않을 경우, 생성된 복제 슬롯이 정지되고, 게시자 노드에 WAL(미리 쓰기 로그)이 누적되기 시작하며, 결국 노드의 디스크 공간이 부족해집니다. 

 

PostgreSQL의 논리적 복제의 사용 사례

수많은 엔지니어가 논리적 복제를 다음과 같은 경우에 사용합니다:

 

- 단일 데이터베이스 또는 데이터베이스 하위 집합 내의 변경 사항을 구독자에게 실시간 배포

- 여러 데이터베이스를 하나의 중앙 데이터베이스로 병합 (분석용으로 사용)

- 다양한 버전의 PostgreSQL에 걸쳐 복제 생성

- 서로 다른 플랫폼(예: Linux to Windows)에 걸쳐 PostgreSQL 인스턴스 간에 복제 배포

- 다른 사용자 또는 그룹과 복제된 데이터 공유

- 여러 데이터베이스 간에 데이터베이스 하위 집합 배포

PostgreSQL의 스트리밍 복제 (Streaming Replication)

 

 

PostgreSQL v9.0에서 도입된 스트리밍 복제는 마스터 또는 기본(primary) 데이터베이스 서버에서 복제본 또는 대기(standby) 데이터베이스로 WAL(미리 쓰기 로그) 파일을 전송 및 적용합니다. WAL은 복제 및 데이터 무결성을 보장하는 데 사용됩니다.

 

스트리밍 복제는 파일 기반 로그 전송에 내재된 데이터 전송 간의 격차를 해소하기 위해 작동하며, WAL이 데이터를 전송할 수 있는 최대 용량에 도달할 때까지 대기합니다. 

 

데이터베이스 서버는 데이터를 동기화하기 위해 청크 단위로 WAL 레코드를 스트리밍 합니다. 대기 서버는 복제본에 연결하여 WAL 청크가 전송될 때 이를 수신합니다. 

 

스트리밍 복제를 사용하면 사용자가 비동기(asynchronous) 또는 동기(synchronous) 복제를 설정할지 여부를 결정해야 합니다. 스트리밍 복제를 처음 배포할 때는 기본적으로 비동기 복제로 설정됩니다. 

 

이는 기본 서버의 초기 변경 사항과 복제본의 변경 사항 반영 사이에 지연이 있음을 나타냅니다. 비동기화는 변경 내용이 복사되기 전에 마스터가 충돌하거나 복제본이 원본과 동기화되지 않아 변경을 위해 관련 데이터를 이미 삭제한 경우 잠재적인 데이터 손실의 가능성을 열어줍니다. 

 

반면 동기 복제는 실시간으로 변경을 수행하기에 훨씬 더 안전한 옵션입니다. 마스터에서 복제본으로의 전송은 두 서버가 정보를 확인할 때까지 불완전한 것으로 간주됩니다. 데이터 변경이 확인되면 두 서버의 WAL에 전송이 기록됩니다.

 

비동기 복제를 사용하든 동기 복제를 사용하든 복제본은 네트워크 연결을 통해 마스터에 연결되어야 합니다. 또한 사용자가 복제본의 WAL 스트림에 대한 접근 권한을 설정해야 정보 손실을 방지할 수 있습니다. 

 

PostgreSQL 스트리밍 복제의 장점

스트리밍 복제의 가장 중요한 장점 중 하나는 기본 서버와 수신 서버가 동시에 충돌하는 경우에만 데이터가 손실된다는 점입니다. 중요한 정보를 전송하는 경우 스트리밍 복제를 사용하면 작업 사본이 모두 저장됩니다.

 

사용자는 하나 이상의 대기 서버를 기본 서버에 연결할 수 있으며, 로그는 기본 서버에서 연결된 각 대기 서버로 스트리밍됩니다. 복제본 중 하나가 지연되거나 연결이 끊어지면 다른 복제본으로 스트리밍이 계속됩니다. 

 

스트리밍 복제를 통해 로그 전송을 설정해도 사용자가 현재 기본 데이터베이스에서 실행 중인 작업은 방해받지 않습니다. 기본 서버를 종료해야 하는 경우, 업데이트된 레코드가 복제본으로 전송될 때까지 기다린 후 전원을 종료합니다. 

 

PostgreSQL 스트리밍 복제의 단점

스트리밍 복제는 정보를 다른 버전이나 아키텍처로 복사하거나 대기 서버의 정보를 변경하지 않으며, 세분화된 복제가 제공되지 않습니다. 

 

특히 비동기 스트리밍 데이터 복제의 경우, 사용자가 마스터를 변경할 때 복제본에 아직 복사되지 않은 과거 WAL 파일이 재활용될 수 있습니다. 중요한 파일이 손실되지 않도록 하기 위해 사용자는 wal_keep_segments를 더 높은 값으로 설정해야 합니다. 

 

복제 서버에 대한 사용자 인증 자격 증명을 설정하지 않으면 중요한 데이터가 쉽게 빠져나갈 수 있습니다. 마스터와 복제본 간에 실시간 업데이트가 이루어지려면 사용자가 직접 복제 방법을 기본 비동기 복제에서 동기 복제로 변경해야 합니다.

 

PostgreSQL의 스트리밍 복제의 사용 사례

수많은 엔지니어가 스트리밍 복제를 다음과 같은 경우에 사용합니다:

 

- 서버 장애 또는 데이터 손실에 대비하여 기본 DB에 대한 백업 생성

- 복제 지연을 최대한 줄이면서 고가용성 솔루션 구축

- 대용량 쿼리를 방전하여 기본 시스템에 대한 스트레스 완화

- 데이터베이스 워크로드를 여러 대의 컴퓨터에 분산 (특히 읽기 전용 형식의 경우)

복제 비교 차트: 논리적 복제 vs 스트리밍 복제

 

	논리적 복제 (Logical)	스트리밍 복제 (Streaming)
모델	Publisher to subscriber	Master to replica
트랜잭션 복제	O	X
복제의 격차	충돌이 발생시 복제 중지	비동기식 - 기본 서버와 복제본 간의 데이터 전송이 지연될 수 있음 동기식 - 연결된 모든 서버가 동시에 충돌하는 경우에만 데이터가 손실됨
타 플랫폼 또는 PostgreSQL 버전 간 복제	O	X
보안	데이터 접근은 구독자로 제한	데이터 보안을 유지하기 위해 접근 자격 증명 설정 필요
복제의 크기	세분화된 복제에 적합	대규모 복제에 적합
유용한 경우	여러 시스템을 하나의 데이터베이스로 병합할 때	백업 데이터베이스를 만들 때

결론

PostgreSQL에서 제공되는 두 복제 기능을 설명하는 글이 도움이 되셨기를 바랍니다. 최근 비트나인의 AgensSQL이 PostgreSQL 14 버전으로 업데이트되면서 오라클 호환성을 포함한 새로운 기능들이 탑재되었는데, 당연히 버전 업데이트를 통해 논리적 및 스트리밍 복제와 같은 기존 PG 기능도 개선되었습니다. 

 

AgensSQL 엔터프라이즈 버전에는 스트리밍 복제가 특히 유용한 Agens HA Manager(AHM)라는 AgensSQL의 서비스의 연속성을 유지시켜 주는 도구가 포함되어 있습니다. Primary 서버에서 장애가 발생할 경우, Secondary 서버가 빠르게 기존 Primary 서버로 전환되어 다운 타임을 최소화합니다. 이를 통해 예상치 못한 시스템 중단이나 장애 발생 시에도 비즈니스를 계속해서 운영할 수 있도록 하여 매출 손실, 생산성 저하, 고객 불만 등을 최소화할 수 있습니다. 

 

비트나인이 PostgreSQL 배포에 어떤 도움을 줄 수 있는지 궁금하시다면, 저희 데이터베이스 전문가에게 언제든지 문의하시기 바랍니다.  

 

 

 

글 : 서준섭 과장 ( 비트나인 글로벌 사업전략팀 )