[PostgreSQL(4)] PostgreSQL Replication

📌 Database Replication이란

---

💡 원본 데이터베이스에서 데이터의 복제본을 생성하는 기술로,
데이터베이스의 부하 분산, 고가용성, 백업 등을 목적으로 사용한다.

✅ 부하 분산

일반적인 서비스는 쓰기 작업보다 읽기 작업의 빈도가 높다.

Replication을 통해 읽기 작업을 별도의 복제본(읽기 전용 데이터베이스)에 할당하여 주 데이터베이스의 읽기 작업 부하를 분산함으로써, 시스템의 전반의 응답 시간을 향상시킨다.

✅ 고가용성

주 데이터베이스에 장애가 발생했을 때, 복제본을 사용하여 서비스의 지속성을 보장함으로써 서비스 중단을 방지하고 안정성을 보장한다.

📌 WAL (Write-Ahead Logging)

---

대부분의 Replication은 WAL을 기반으로 동작하기 때문에,
PostgreSQL Replication을 설명하기 앞서, WAL에 대해 이해해야 한다.

✅ WAL이란

💡 데이터 무결성을 보장하는 DBMS 표준 방법으로, 트랜잭션 로깅 방식 중 하나이다.

• 데이터베이스에서 발생하는 모든 변경 사항을 로그로 남기는 방법으로,
  데이터 변경을 디스크에 기록하기 전에 로그에 먼저 기록한다.

• 주 데이터베이스의 변경 사항을 복제본으로 동기화하는데 활용될 수 있다.

📌 PostgreSQL Replication 종류

---

PostgreSQL에서 제공하는 Replication 방식은 다음과 같다.

PostgreSQL Replication은 크게 Physical Replication과 Logical Replication으로 구분할 수 있다.

Physical Replication 은

• 1️⃣ : WAL 파일 자체를 전달하는 Log Shipping과,
• 2️⃣ : WAL 파일 저장 여부와 관계없이 WAL Record를 전달하는 Streaming Replication으로 구분할 수 있다.

💡 하나의 WAL 파일은 여러 개의 WAL Record로 구성된다.
변경 사항이 발생할 때, 하나의 변경 사항은 하나의 WAL Record로 볼 수 있다.

Logical Replication 은
WAL을 기반으로 작동하지만, DML 발생 시 walsender 프로세스가 WAL Record를 Logical Decoding 처리 후 전송한다.

💡 Logical Decoding

: WAL 내용을 Tuple 또는 SQL문과 같은 응용 프로그램 형식으로 디코딩하는 프로세스
= 변경 사항을 해석 가능한 일관되고, 이해하기 쉬운 형식으로 디코딩

📌 Physical Replication

---

✅ File-based Log Shipping

💡 완성된 WAL 파일을 복제본으로 동기화(전달 및 적용)하는 방식

즉, 주 데이터베이스의 WAL 파일이 정해진 크기 (기본 값 : 16MB)를 다 채운 후 새로운 파일이 생성되어야 비로소 기존 WAL 파일을 복제본에 전달하는 것이 가능해진다.

따라서, 현재 사용 중인 WAL 파일이 채워지는 동안
주 데이터베이스와 복제본 간의 Data Lag이 발생할 수 있으며,
이는 장애 발생 시 변경 사항이 최대 WAL 파일 크기만큼 소실되는 문제를 야기한다.

📢 active_timeout 파라미터를 통해 WAL 파일을 주기적으로 전환하는 시간을 지정함으로써, Data Lac을 줄일 수 있다.

📍 장점

• 다른 Replication 방식에 비해 구성이 간단하다.

• archive_command 파라미터를 이용하여 복제본으로 WAL 파일을 전달하기 쉽다.

• 다중 복제본을 구성할 수 있다.

📍 단점

• 주 데이터베이스와 복제본 간의 major 버전 (Ex: PostgreSQL 10, 11등) 및 bit (Ex: 32bits, 64bits)가 동일해야 구성 가능하다.

  • 다른 버전 또는 비트에서는 데이터베이스 파일 및 구조가 다를 수 있기 때문이다.

• WAL 파일이 가득차거나, archive_time에 의해 교체되지 않은 상황에서
  주 데이터베이스에 장애가 발생하면, 아직 복제본으로 동기화되지 않은 변경 사항에 대한 유실이 발생할 수 있다.

✅ Streaming Replication

---

💡 주 데이터베이스의 WAL 파일이 완성될 때까지 기다리지 않고, WAL Record를 실시간으로 Streaming 하는 방식

주 데이터베이스의 WAL Record를 복제본으로 전달하기 위해,

• 주 데이터베이스에는 WAL Sender
• 복제본에는 WAL Receiver

라는 프로세스가 필요하며, 이 프로세스들이 주 데이터베이스와 복제본 간의 동기화를 수행한다.

📍 장점

• 다른 Replication 방식에 비해 구성이 간단하다.

• File-based Log Shipping 방식에 비해 주 데이터베이스의 변경 사항을 거의 실시간으로 복제본에 동기화한다.

• WAL 파일의 교체 여부와 관계 없이 동기화 가능하다.

📍 단점

• 아직 동기화되지 않은 WAL Record가 포함된 WAL 파일이 삭제된 경우,
  더 이상 동기화를 진행할 수 없으므로 복제본을 재구성 해야 한다.

• 주 데이터베이스의 변경 사항을 계속 복제본에 스트리밍해야 하므로 주 데이터베이스의 성능에 영향을 미칠 수 있다.

✅ Physical Replication의 한계점

Physical Replication은 구성이 비교적 간단하다는 장점이 있지만,
다음과 같은 공통적인 제약 사항이 존재한다.

• Physical Replication은 데이터베이스 전체를 복제하기 때문에, 특정 부분만 선택적으로 복제하는 것이 불가능하다.

• PostgreSQL의 Major 버전이 다르다면 복제가 불가능하다.

• PostgreSQL이 설치된 운영체제가 다르다면 복제가 불가능하다.

Physical Replication의 위와 같은 한계를 극복하기 위해,
다음으로 설명할 Logical Replication이 도입되었다.

📌 Logical Replication

---

Logical Replication은 Physical Replication의 한계를 극복하기 위해 도입되었으며, PostgreSQL 10 버전부터 사용 가능하다.

Logical Replication은 하나의 게시자와, 하나 이상의 구독자로 구성된다.
구독자는 자신이 구독중인 게시자의 데이터를 가져와, 이를 게시하여 게시자가 될 수 있다.

구독과 게시 간의 Replication은 복제 ID(Replication Identify)를 기반으로 수행되며, 복제 ID는 기본 키 또는 고유 키가 될 수 있다.

기본 키와 고유 키가 존재하지 않는다면 REPLICA IDENTITY FULL 옵션으로 Table 속성을 변경하여 사용할 수 있다.

ALTER REPLICATION my_publication ADD TABLE publication_table WITH (REPLICA IDENTITY FULL);

하지만 이 방법은 Table 변경 사항이 있을 때마다 전체 Table을 복제하므로, 자주 업데이트 되는 대용량 Table에 대해서는 비효율적이며 자원을 많이 소모한다.

✅ Logical Replication 사용 사례

• 여러 데이터 베이스 간의 데이터 통합
  (ex : 여러 응용 프로그램의 데이터를 중앙 집계 시스템에 전달하는 경우)

• 서로 다른 Major 버전 간의 Replication

• 서로 다른 데이터베이스 간 데이터 마이그레이션

📍 장점

• 특정 데이터베이스 또는 테이블만 선택적으로 복제하는 것이 가능하다.
• 서로 다른 Major 버전, 운영 체제 간 복제가 가능하다.
• 구독자가 게시자가 되는 다중 형태를 구성할 수 있다.
• 구독에는 게시보다 많은 Column 정의가 가능하며, Column의 순서에 영향을 받지 않는다.

📍 단점

• Physical Replication보다 더 많은 오버헤드와 변환 작업을 필요로 하므로, 성능에 영향을 줄 수 있다.

• 양방향 Replication이 불가능하다.

📌 결론

---

이번 포스팅에서는 Replication의 개념과 목적, 그리고 PostgreSQL에서 제공하는 다양한 Replication 방식의 종류와 각각의 장단점에 대해 알아보았다.

그리고, 다음과 같은 이유로 OurHour 서비스의 메인 데이터베이스인 PostgreSQL을 Streaming Replication을 사용하여 읽기 전용 데이터베이스와 쓰기 전용 데이터베이스로 분리하기로 결정했다.

• 쓰기 전용 데이터베이스의 변경 사항이 거의 실시간으로 전파되어 동기화 되기 때문에, 읽기 전용 데이터베이스가 항상 최신 상태를 유지할 수 있다.

• 읽기 전용 데이터베이스를 여러 대 두어 읽기 작업 부하를 분산 시킬 수 있어 확장성이 좋다.

• PostgreSQL에서 기본적으로 제공하는 기능으로, 구성 및 유지 보수가 용이하다.

• 주 데이터베이스(쓰기 전용 데이터베이스) 장애 시, 복제본(읽기 전용 데이터베이스)로 쉽게 전환이 가능해 서비스의 가용성을 향상 시킬 수 있다.

사실, 위에 서술한 네가지 장점 중 세가지는 Steaming Replication 방식의 고유한 장점이라기 보다는 Physical Replication의 장점이라고 볼 수 있다.

Logical Replication은 주로 데이터베이스 마이그레이션이나, 통합에 사용되는 방식으로 목적과 맞지 않아 애초에 고려 대상에서 배제되었고,

결국, 동기화 속도와 주 데이터 베이스와 복제본 모두에 영향을 미치는 시스템 부하 사이에 무엇을 취하고, 무엇을 포기할 것인지에 따라 File-based Log Shipping과 Streaming 방식 중 어떤 방식을 사용할 것인지 결정되는데, 이 갈림길에서 나는 동기화 속도를 취하기로 선택했다.

🙋🏻‍♀️ 그래서 나는 Streaming Replication 방식을 사용하기로 결정했다!

참고 링크 : https://blog.ex-em.com/1781