▲

Amazon RDS의 PostgreSQL 17.4 분석 - Snapshot Isolation을 보장하지 않음

 (jepsen.io)
2P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • Amazon RDS for PostgreSQL의 multi-AZ 클러스터는 공식적으로 Snapshot Isolation을 지원하지만, 실제로는 이를 위반하는 G-nonadjacent 사이클과 Long Fork 현상이 자주 발생함
  • 테스트는 직접 구성한 PostgreSQL 트랜잭션 워크로드를 기반으로 수행되었으며, PostgreSQL 13.15부터 17.4까지 모든 버전에서 일관성 오류가 발생함
  • 이러한 오류는 주로 read-only 세컨더리 노드에서 발생하며, "Repeatable Read" 수준에서도 Snapshot Isolation이 깨짐
  • RDS 클러스터는 Parallel Snapshot Isolation 수준의 일관성을 제공할 가능성이 있음, 이는 기본 PostgreSQL 단일 노드보다 더 약한 모델임
  • 읽기 전용 트랜잭션은 서로 다른 트랜잭션 순서를 관찰할 수 있으며, 이러한 불일치는 데이터 무결성 오류로 이어질 수 있음

Background

  • PostgreSQL은 MVCC 기반의 오픈소스 SQL DB로, 다양한 트랜잭션 격리 수준을 제공함. Repeatable Read는 실제로 Snapshot Isolation을 의미함
  • Amazon RDS는 PostgreSQL을 관리형 클러스터로 제공하며, Multi-AZ 구성은 복제와 장애 허용을 위한 아키텍처임
  • 기본 엔드포인트는 읽기/쓰기 가능, 세컨더리는 읽기 전용이며 Serializable 수준을 지원하지 않음

Test Design

  • Jepsen PostgreSQL 테스트 도구를 RDS에 맞게 래핑하여 자동화된 트랜잭션 테스트 수행
  • 트랜잭션은 특정 키에 리스트를 읽거나 고유 정수를 append하는 구조로 설계, Elle checker로 사이클 탐지
  • 150 TPS 쓰기, 1600 TPS 읽기 부하에서 2분 내에 Long Fork 및 G-nonadjacent 발생 확인

Results

  • 4개의 트랜잭션으로 구성된 G-nonadjacent 사이클을 통해 Snapshot Isolation 위반 입증
    • T₂는 T₁의 변경을 관측했지만 T₃는 보지 못함, T₄는 T₃는 보았지만 T₁은 보지 못함 → 시간순서 상호 모순 발생
  • 이는 Long Fork 현상이자 Snapshot Isolation 위반을 증명하는 강한 사례이며,
  • Write Skew은 발견되지 않아 Parallel Snapshot Isolation 가능성을 뒷받침함

Discussion

  • Multi-AZ RDS는 단일 노드 PostgreSQL보다 일관성 수준이 낮음
  • 읽기 전용 노드 사용 시 일관성 오류 가능성이 있으므로, 반드시 쓰기 노드만을 사용하거나 모든 트랜잭션에 최소한 하나의 쓰기를 포함시키는 방안을 검토할 필요 있음
  • 이번 분석은 초기 테스트 수준이며, 문제 존재는 증명하되 부재는 보장하지 않음
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • 기사 제목에 명확히 언급되지 않았지만, 이는 RDS의 새로운 기능인 멀티-AZ 클러스터에 관한 것임

    • 멀티-AZ 인스턴스는 주 DB가 다른 AZ의 보조 DB로 동기 복제되는 오래된 기능임
    • 멀티-AZ 클러스터는 두 개의 보조 DB가 있으며, 트랜잭션이 최소 하나의 보조 DB로 동기 복제됨
    • 이는 보조 DB가 실패하거나 성능이 저하될 경우 더 견고하며, 보조 DB에 읽기 전용 접근을 허용함
    • 멀티-AZ 클러스터는 일반적인 Postgres 기능이 아니며, Jepsen 테스트에서 실패하는 이유일 수 있음

  • 이전 회사에서 백업 스크립트의 pg_dump 명령어를 병렬 작업자(-j 플래그)를 사용하도록 변경했을 때, 백업 복원 시 일관성 문제(중복 키 오류 및 fk 제약 조건 오류)가 발생했음

    • AWS와 Postgres 메일링 리스트에 문제를 보고했으나 쉽게 재현할 수 없어 해결되지 않았음
    • 결국 단일 스레드 덤프로 돌아갔으며, 이 문제가 우리가 겪었던 행동과 관련이 있는지 궁금함

  • Jepsen이 독립적으로 수행한 작업이며, 보상을 받지 않았음

    • RDBMS 이해관계자가 좋은 날에 듣고 싶지 않은 소식임
    • aphyr에게 경의를 표함

  • 이 문제의 실질적인 의미는 동일한 행에 대한 쓰기 후 빠르게 발생하는 읽기가 오래된 데이터를 반환할 수 있다는 것임

    • 쓰기 트랜잭션이 완료로 표시되기 전에 멀티 AZ RDS 인스턴스의 모든 분산 계층이 완전히 업데이트되지 않아 즉각적인 읽기가 존재하지 않는 행이나 오래된 값을 반환할 수 있음
    • PostgreSQL의 스냅샷 방식 때문에 멀티 바이트 열 유형의 일부 바이트만 업데이트되어 읽기가 무의미한 값을 얻는 것은 아님
    • 이는 결국 일관성을 갖게 되는 경쟁 조건처럼 보임

  • 멀티 인스턴스 업스트림 Postgres 클러스터에서는 문제가 없는 것인지 명확하지 않음

    • AWS가 클러스터 구성에 무언가를 추가했거나 이 행동을 유발하는 패치를 추가한 것인지 궁금함

  • 제출된 제목은 핵심을 숨기고 있음: PostgreSQL 17.4용 RDS가 스냅샷 격리를 제대로 구현하지 않음

  • 개발자가 스냅샷 격리를 가정하지만 Amazon RDS for PostgreSQL이 실제로 병렬 스냅샷 격리만 제공할 경우, 특히 읽기 복제본 엔드포인트를 사용하는 멀티-AZ 구성에서 어떤 안전성 또는 애플리케이션 수준의 버그가 발생할 수 있는지 궁금함

  • 13.15부터 17.4까지 테스트된 모든 버전에서 이러한 현상이 발생했음

    • 주요 버전을 업그레이드한 것이 잘못된 선택이었는지 걱정했으나, 이는 회귀가 아닌 기능 요청 또는 오랜 버그임

  • Amazon RDS의 모든 버전을 Jepsen 테스트하면 좋겠음

  • AWS는 문서를 업데이트하여 이를 전달해야 할 것임

    • 스냅샷 격리 수정이 지연 시간이나 처리량에서 성능 회귀를 초래할 것인지, 아니면 현재 상태가 충분히 강력하다고 주장할 것인지 궁금함
    • 어떤 경우든 AWS는 이에 대해 언급해야 할 것임
답변달기