Data Eng Wiki

Disaggregated OLTP Architecture

9 min read

Disaggregated OLTP Architecture

모놀리식 DB의 거의 모든 고통은 “WAL과 데이터 파일이 한 머신 안에 있다”는 한 가지 사실에서 나온다

핵심 개념

전통적 OLTP DB(Postgres, MySQL, Oracle)는 모놀리스다. 한 머신이 엔진과 스토리지를 모두 돌리고, 디스크에는 두 가지가 중요하다.

  • WAL (Write-Ahead Log) — 쓰기를 빠르고 안전하게. 트랜잭션 커밋은 순차 append 하나로 끝난다
  • 데이터 파일 — 읽기를 빠르게. 로그를 처음부터 재생하지 않고 현재 상태를 직접 읽는다

Disaggregated OLTP는 이 둘을 독립적으로 확장 가능한 외부 서비스로 분리해 컴퓨트를 stateless로 만드는 아키텍처다. Neon → Databricks Lakebase가 대표 구현이다.

모놀리스 구성요소외부화된 서비스바뀌는 것
로컬 디스크의 WALSafeKeeper (Paxos 쿼럼 복제)durability 기준이 “디스크 flush”에서 “네트워크 쿼럼”으로
로컬 디스크의 데이터 파일PageServer (오브젝트 스토리지 write-through 캐시)스토리지가 사실상 무한, 컴퓨트와 독립 확장

모놀리스의 5가지 고통과 그 뿌리

  1. misconfiguration으로 인한 데이터 유실 — WAL 쓰기가 실제 flush 전에 클라이언트에 ack되면 커밋이 사라진다. 설정은 미묘하고 실패는 조용하다 (OS가 flush했다고 거짓말하기도 한다)
  2. 노드 손실로 인한 데이터 유실 — WAL과 데이터 파일이 한 머신에 있으므로 그 디스크가 죽으면 데이터도 죽는다. RAID/NAS는 완화일 뿐
  3. 읽기 확장에 물리적 클론 필요 — read replica는 전체 데이터셋의 물리 복사본. 큰 DB에서는 프로비저닝이 원본을 다운시킬 수도 있다
  4. HA에도 물리적 클론 필요 — 최소 2배(실무 권장 3+) 인프라 비용
  5. 분석이 트랜잭션과 하드웨어 경합 — 리포팅 쿼리 하나, GDPR 정리 작업 하나가 OLTP를 망가뜨린다

다섯 가지 모두 같은 뿌리다: WAL과 데이터 파일이 한 머신 안에 있다.

레이턴시 우려에 대한 답

  • 쓰기: SafeKeeper 네트워크 홉이 추가되지 않나? → durability와 가용성을 진지하게 챙기는 Postgres 배포는 어차피 synchronous replication 홉이 필요하다. 추가 오버헤드가 아니다
  • 읽기: PageServer 홉은? → 다층 캐싱으로 흡수. Postgres buffer pool(로컬 메모리) → 로컬 디스크 캐시 → PageServer. 컴퓨트 노드에 모놀리스와 동일한 메모리·디스크를 주면 로컬 캐시 히트율이 그대로이므로 대부분의 연산에서 구분이 안 된다

해제되는 능력

  • 무제한 스토리지 (박스 용량 천장 없음)
  • scale-to-zero 서버리스 컴퓨트 — stateless라서 즉시 스케일업, 유휴 시 0
  • zero data loss, 단순한 HA (durable 상태가 이미 컴퓨트와 독립된 복제 레이어에 있음)
  • 즉시 브랜칭/클로닝/PITR — 물리 복사가 아닌 메타데이터 연산. 대형 프로덕션 DB를 초 단위로 브랜치해 위험한 마이그레이션을 실험하고 버릴 수 있다. “DB가 드디어 코드만큼 빨리 움직인다”

LTAP — 스토리지 레이어에서의 통합

PageServer가 페이지를 오브젝트 스토리지에 materialize하는 그 순간이, row 포맷을 Parquet columnar로 transcode하기에 정확히 알맞은 지점이다. 여기서 LTAP이 나온다.

  • 엔진이 아닌 스토리지에서 통합한다. Postgres는 트랜잭션, Lakehouse 엔진은 분석 — 각자 최선의 도구를 유지하고 밑의 데이터만 하나로 만든다
  • 타입 시스템: 대부분 Parquet 네이티브에 직접 매핑. NaN·±Inf·범위 밖 NUMERIC·exotic 타입은 같은 테이블의 structured overflow 필드에 canonical Postgres 텍스트로 병기 → 쿼리 가능하면서 원본 바이트 복원 가능
  • 멀티버저닝: durability와 visibility를 분리. columnar row마다 물리 heap 주소(block, offset)를 실어 heap 페이지를 재구성 가능하게 하고, 중간 row 버전은 MVCC/PITR용으로 보존하되 Iceberg/Delta 리더에는 노출하지 않는다. Postgres heap page는 point read 가속 캐시가 되고 durable source of truth는 columnar 파일
  • freshness: 분석 쿼리 시작 시 Postgres에 현재 LSN만 묻고(값싼 메타데이터 조회), 대부분을 오브젝트 스토리지에서 읽고 아직 materialize 안 된 최근 변경분만 PageServer에서 merge. Postgres는 숫자 하나만 반환하므로 분석 트래픽을 서빙하지 않는다

CDC/미러링과의 차이

Change Data Capture 기반 “zero-ETL”, “mirroring”은 복제 파이프라인에 비용이 들기 때문에 테이블을 골라야 하고 지연이 따른다. LTAP은 opt-in이 없다 — 존재하는 테이블은 구조상 이미 lake에 있다. 복제가 없으므로 두 뷰가 drift할 수 없다.

HTAP은 왜 실패했나

단일 엔진으로 두 워크로드를 처리하려는 시도의 세 가지 귀결:

  • 불완전한 기능 셋 — FK 같은 기본기, 성숙한 옵티마이저까지 도달하는 데 필요한 투자가 배가된다
  • 생태계 부재 — Postgres와 Spark는 각자 드라이버·확장·도구·수십 년의 운영 지식의 중심에 있다
  • 성능 격리 없음 — 같은 하드웨어에서 경합하면 모놀리스의 원래 실패로 돌아간다

남은 비판 지점

RegattaDB 등은 LTAP도 충분치 않다고 본다:

  • 두 개의 consistency domain이 남는다 (Postgres ACID ↔ Delta snapshot isolation). 그 사이 flush window가 공개되지 않았고, 커밋됐지만 아직 flush 안 된 트랜잭션 때문에 분석 쿼리가 stale을 넘어 incorrect할 수 있다는 우려
  • 벤치마크가 조인을 테스트하지 않음 (TPC-H Q6는 단일 테이블 스캔+필터+집계)
  • 세 번째 워크로드인 벡터 검색을 다루지 않음. 에이전트는 트랜잭션·분석·시맨틱 검색을 동시에 요구하는데 벡터는 여전히 Postgres 확장에 bolt-on

즉 LTAP은 데이터 동기화 비용은 없앴지만 엔진 경계 자체를 없애지는 않았다. 진짜 통합의 난제는 단일 concurrency 모델이라는 것이 반대 진영의 주장이다. → Database Concurrency Control

연관 개념

Source: From monolith to Lakebase to LTAP, Databricks LTAP and the Unfinished Problem of Unified Data

그래프 뷰

백링크