▲

pgactive - Postgres 액티브-액티브 복제 확장

 (github.com/aws)
7P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • AWS가 만들어서 공개한 PostgreSQL을 위한 active-active 복제 확장
  • 여러 PostgreSQL 인스턴스에서 데이터 쓰기·수정이 필요할 때, 특정 인스턴스가 단독으로 변경을 수용하는 기존의 액티브-스탠바이 모델 대신, 여러 인스턴스에서 동시 변경과 복제가 가능한 구조를 구축할 수 있음
  • 여러 리전에서 고가용성 데이터베이스 구성이나, 쓰기 지연 최소화, 애플리케이션의 블루/그린 업데이트, 양방향 데이터 마이그레이션 같은 시나리오에 적합함
  • 논리적 복제를 활용하여 충돌 감지, 쓰기 충돌 해결, 타겟 데이터베이스 포맷 변환 등을 지원

액티브-액티브 복제 개념

  • 복제(Replication) 는 데이터베이스 간 변경 내용을 동기화하는 기술
  • 기존 PostgreSQL의 액티브-스탠바이 구조는 한 인스턴스만 변경을 수용하고 나머지는 읽기 전용 형태이므로, 한 곳이 단일 데이터 소스 역할을 함
  • pgactive는 액티브-액티브 복제 토폴로지를 제공함으로써 여러 인스턴스에서 동시에 데이터 쓰기를 허용함
  • 이런 방식은 여러 쓰기 지점이 필요한 환경, 예를 들어 멀티 리전 배포나 양방향 마이그레이션 등에 적합함
  • 액티브-액티브 모델에서는 충돌, 지연, 일부 기능 제약에 대한 별도 관리가 필요함

핵심 기술: 논리적 복제

  • 논리적 복제(Logical Replication) 는 데이터를 외부 시스템이 해석 가능한 포맷으로 전송함
  • 논리적 복제를 통해 대상 데이터베이스에서 충돌 탐지, 쓰기 충돌 해결, 쿼리 변환 등 다양한 부가기능을 구현할 수 있음
  • PostgreSQL은 2017년 버전 10에서 기본 논리적 복제를 도입하였으나, 액티브-액티브 복제에는 추가적인 기능이 요구됨
  • PostgreSQL의 설계 특성으로 인해 이러한 기능은 확장(extension) 형태로 개발 및 적용이 가능함
  • PostgreSQL 개발 커뮤니티도 점차적으로 해당 기능을 기본 프로젝트에 추가하고 있음
▲
GN⁺ 1일전  [-]
Hacker News 의견
  • 2nd Quadrant와 EDB 팀 동료들에게서 들은 BDR와 pglogical, pgactive, 그리고 Postgres Distributed(PGD)의 발전사를 정리해봄
    가장 처음 나왔고 지금도 오픈소스인 것이 BDR1임 (링크), 그리고 여기에 기반한 게 pgactive임
    BDR2는 BDR1을 폐쇄소스로 리라이트한 거였고, 결국엔 폐기됨
    pglogical v1과 v2(둘 다 오픈소스, 링크)가 출시되었고, 이 중 v1이 대폭 수정되어 Postgres 10에 병합됨
    Postgres 10의 논리적 복제 기능 경험을 토대로 2nd Quadrant는 pglogical v2 개발을 시작했고, 여기에서 pgEdge도 나옴
    이후 2nd Quadrant는 폐쇄소스 버전인 pglogical v3와 BDR v3를 만들었고, 둘을 합쳐 BDR v4가 됨
    그 후 BDR 제품명이 Postgres Distributed(PGD, 링크)로 변경됨
    2ndQuadrant가 EDB에 인수되며 EDB에서 PGD v6을 출시함
    • PostgresPro에서도 별도의 multi-master 복제 시스템이 있음 문서 링크
    • PGDv6이 여전히 폐쇄소스인지 질문함
  • 이 시스템은 Postgres의 Logical replication을 사용해서 한 인스턴스의 변경사항을 다른 인스턴스에 전달함
    충돌이 발생하면 timestamp 기준으로 마지막에 기록된 값이 최종적으로 적용되는 방식임
    충돌이 발생한 내역은 pgactive_conflict_history라는 특수 테이블에 남기 때문에 히스토리 파악, 수동 해결 등이 가능함
    자세한 내용 및 문서는 여기 참고
    • 이게 multi-master replication에 해당하는지 궁금함
      만약 그 기능을 공식적으로 Postgres에 받아들일 수 있다면 흥미로울 듯함
    • 사용자 입장에서는 자신의 쓰기가 즉각적으로 승인이 되는지, 아니면 결국엔 수렴되는 것인지 알고 싶음
  • 최근에 Bloomberg의 데이터베이스(comdb2)를 직접 사용해 본 사람이 있는지 궁금함
  • 관련은 있지만 약간 벗어난 이야기로, "로컬에서 쓰기가 가능한(read replica 기반) 복제"가 가능한 방법이 있는지 궁금함
    예를 들어 프로덕션이나 스테이징에서 데이터를 읽지만, 로컬에서만 수정 가능하고 그 결과가 다시 upstream에는 반영되지 않는 2차 데이터베이스를 쓰고 싶음
    현재는 주기적으로 스크립트(cron 등)로 데이터 덤프 혹은 질의를 날려서 스냅샷을 만들고, 그걸 S3에 저장한 뒤 로컬에서 받아서 데이터를 복원하는 방식이 대부분임
    이 방법은 대부분 효과적이지만 인덱스 빌드에 시간이 너무 오래 걸릴 때가 있음
    • 참고로, 개인정보 등 민감 정보 문제 때문에 이런식으로 staging이나 dev 환경에 데이터가 바로 들어가면 위험함
      법적, 윤리적 이슈가 크기 때문에 대부분의 회사에서는 이런 방식 권장하지 않음
    • Postgres의 logical replication을 필터와 함께 쓰면 단방향 복제가 가능해서, 복제 슬롯만 해제하면 로컬에서 자유롭게 변경 가능함
      이렇게 하면 primary에는 영향 없이 로컬 테이블만 수정할 수 있음
    • "순정" 상태의 로컬 데이터베이스를 백업용으로 두고, 필요할 때마다 이걸 복제해서 개발용 데이터베이스로 쓰면 인덱스 빌드 없이 복사가 매우 빠름
      createdb --template 명령어 추천
    • 로컬 쓰기와 원격 업데이트가 충돌하면 어떻게 처리하는지 궁금함
      모든 상황에 적용 가능한 머지 전략이 떠오르지 않음
    • 내가 아는 한, Postgres 논리적 복제 세팅에서는 이게 표준적인 동작임
      replica에서 쓰기를 막는 게 아니라, 단지 그 결과가 다른 곳으로 퍼지지 않을 뿐임
  • "Conflict resolution"이란 용어는 결국 "이미 커밋되고 승인된 데이터를 버림으로써 내구성을 깬다"는 의미라는 사실을 항상 상기해야 함
    모든 active 인스턴스에 걸쳐 쓸 데이터 영역 겹침이 없게 아키텍처를 설계하는 게 최선임
    이런 경우엔 pgactive 같은 툴이 쓸만함
    아니면 아예 처음부터 분산 데이터베이스(Yugabyte 등)를 쓰는 게 맞음
    • 공식 문서에도 충돌 회피 방법으로 master마다 schema를 나눠서 "각 master는 각 schema의 유일한 writer"가 되도록 추천함
      모든 master가 모든 schema를 읽긴 하지만, 쓸 땐 자기만 담당하는 방식을 제안함
      schema 말고, partition 등도 책임 분산에 쓸 수 있는지 궁금함
  • AWS가 이걸 왜 만들었을까 고민하게 됨
    자사 제품에서 직접 이 기능을 쓰는 게 떠오르지 않음
    RDS는 block replication, Aurora는 고유 SAN replication 사용함
    DMS 정도에서 활용하려는 의도인지 추측함
    • 아마도 최근 출시한 Aurora DSQL 때문일 수 있음
    • 사실 큰 효용을 잘 모르겠음
      강한 ACID 관계형 데이터베이스에서 굳이 이걸 왜 해야 하는지 의문임
    • Aurora의 SAN replication은 cross region replication에는 쓰이지 않는 걸로 알고 있음
    • 해당 저장소 readme에도 "Multi-Region 고가용성 데이터베이스 클러스터 구축이 주요 용도"라고 명시되어 있음
    • 실제로 RDS Postgres에는 2년 전부터 제공되던 기능이었다고 함 (관련 링크)
      그런데 1달 전에 커뮤니티에 오픈소스로 공식 공개했다는 소식이 있었음 (공식 소식)
  • repmgr, patroni를 써서 완전 무중단 환경으로 여러 클러스터를 운영해봤는데, 이 플러그인은 정말 마지막으로만 설치하고 싶음
    밤에 잘 자기 위해서는 최대한 피하고 싶음
  • 우연히도 최근에 "자동 페일오버, 노드 복구, 시점 복구" 가능한 고가용성 Postgres 클러스터를 쉽게 만드는 방법을 찾고 있었음
    patroni+etcd+haproxy 조합이 많이 추천되던데, 실제로 써 본 분들이 흥분해서 추천하는 걸 보면 그만한 이유가 있을 듯함
    다만 docker compose로 예시 파일을 봤을 때는 좀 부담스럽게 느껴짐
    pgpool은 각 postgres 앞에 두기만 하면 되는 것 같아 간단해 보임
    실제 현업에서 Postgres 좋아하는 분들의 추천이나 경험이 궁금함
    docker compose 기반으로 최대한 쉽게, 높은 가용성과 (최소) 무손실, 시점 복구까지 가능한 클러스터 구축을 목표로 하고 있음
    • Barman 같은 툴을 찾는 건지 질문함
    • cloudnativepg를 쓰고 있는데, 이것만으로 필요한 기능이 대부분 바로 동작함
  • pgactive, 관련 사례 등 다른 자료 없을지 공유함
    <i>Pgactive: Active-Active Replication Extension for PostgreSQL on Amazon RDS</i>
    Hacker News 글 (2023년 10월글, 1개 댓글)
  • 비동기 방식인 것 같고, 트랜잭션 격리성에는 큰 이슈가 있을 듯함
    • 결국은 트레이드오프라는 입장임
      즉 각자 상황에 따라 장단점 수용이 필요함
답변달기