Streambed: Postgres 데이터를 Apache Iceberg로 간소화하기

PostgreSQL을 사용하는 조직의 경우, 운영 데이터에서 분석 인사이트로 전환하는 과정은 종종 번거로운 아키텍처적 도약이 수반됩니다. 전통적으로, 이는 리소스를 압박할 수 있는 여러 개의 읽기 복제본(read replicas)을 생성하거나, 데이터를 전용 분석 웨어하우스로 이동하기 위해 복잡한 ETL (Extract, Transform, Load) 파이프라인을 구현해야 함을 의미합니다. 이러한 패턴은 종종 지연 시간, 운영 오버헤드, 그리고 맞춤형 구성 요소의 급증을 초래합니다.

Streambed은 이러한 마찰을 해결하기 위한 솔루션으로 등장했으며, 트랜잭션 데이터베이스에서 쿼리 가능한 분석 형식으로 데이터를 이동하는 데 필요한 구성 요소를 최소화하는 것을 목표로 합니다. Postgres wire protocol과 Apache Iceberg를 활용함으로써, Streambed은 Write-Ahead Log (WAL)에서 S3로 가는 더 직접적인 경로를 제공합니다.

Streambed의 아키텍처

Streambed은 아키텍처의 미니멀리즘 원칙을 중심으로 설계되었습니다. 무거운 미들웨어 계층을 도입하는 대신, 논리적 복제 구독자(logical replication subscriber)로 작동합니다. 이는 Postgres 읽기 복제본에서 사용하는 것과 동일한 메커니즘으로, Streambed이 WAL에서 실시간으로 변경 사항을 캡처할 수 있게 해줍니다.

캡처된 변경 사항은 Amazon S3에 저장된 Apache Iceberg 테이블로 직접 스트리밍됩니다. 이 데이터를 즉시 유용하게 만들기 위해, Streambed은 내장된 DuckDB 인스턴스를 통합하여 사용자가 psql을 통해 Iceberg 테이블을 쿼리할 수 있도록 합니다. 이를 통해 사용자는 데이터가 객체 스토리지의 컬럼형 형식으로 존재함에도 불구하고, 익숙한 Postgres-compatible 도구를 사용하여 분석 데이터를 상호작용할 수 있는 원활한 경험을 제공합니다.

"분석 쿼리" 병목 현상 해결

Streambed의 동기는 고규모 환경에서의 흔한 페인 포인트(pain point)에서 비롯됩니다. Cloudflare의 Postgres 팀 전직 테크 리드(tech lead)인 저자가 언급했듯이, BI 및 대시보드 팀은 종종 기본 운영 데이터베이스의 성능을 저하시킬 수 있는 장기 실행 분석 쿼리를 실행해야 합니다.

역사적으로, 해결책은 다음과 같았습니다:

맞춤형 읽기 복제본: 특정 분석 워크로드에 대해 특정 복제본을 생성.
ETL 덤프: 주기적으로 데이터를 분석용 데이터베이스로 덤프.

Streambed은 S3/Iceberg 계층을 주요 분석 목적지로 취급함으로써 이러한 옵션들을 우회하려고 시도하며, 결과적으로 전체 규모의 데이터 웨어하우스 마이그레이션이라는 전통적인 오버헤드 없이 분석 워크로드를 운영 데이터베이스로부터 효과적으로 분리합니다.

기술적 과제 및 고려 사항

"저구성 요소" 아키텍처의 약속은 매력적이지만, 커뮤니티는 이 패턴을 구현하는 사람들을 위해 몇몇 가지 중요한 고려 사항을 강조했습니다.

ELT vs. ETL 논쟁

데이터를 이동하는 것과 사용을 위해 준비하는 것 사이의 차이점이 주요 비판 중 하나입니다. Streambed은 파이프라인의 "Extract"와 "Load" 부분을 처리하지만, 변환(transformation)의 부담을 프로세스 끝으로 넘깁니다. 이는 ELT (Extract, Load, Transform) 패턴입니다.

"실제적인 분석을 위해 이를 사용하려는 사람은 어느 시점에서든 데이터를 변환해야 할 것입니다. 만약 어떤 조직이 이 솔루션과 같은 것을 사용하여 DuckDB에 접속해 바로 보고서를 뽑아내기만 하면 된다고 생각한다면, 정말 좋지 않은 경험을 하게 될 것입니다."

단순한 보고용으로는 이 접근 방식이 효율적입니다. 하지만 복잡한 비즈니스 인텔리전스(BI)를 위해서는 사용자가 데이터 품질과 성능을을 보장하기 위해 여전히 변환 계층을 구현해야 합니다.

CDC의 복잡성

Change Data Capture (CDC)를 안정적으로 구현하는 것은 사소한 작업이 아닙니다. 데이터를 유실실하거나 상당한 지연을 초래하지 않고 WAL 변경 사항을을 캡처하는 것은 Postgres 내부 구조에 대한 깊은 깊은 이해를가장합니다. Streambed의 구현에 Go를 사용한 것은 주목할 만한 선택입니다. Go에서 신뢰할 수 있는 CDC 라이브러리가 상대적으로 부족하기 때문에, 개발자가 Postgres 복제 프로토콜의 특정 문제들을 처리하기 위해 직접 로직을 "hand-roll"해야 하는 경우가 많기 때문입니다.

요약

Streambed은 운영 데이터베이스와 분석용 레이크하우스(lakehouse) 사이의 거리를 좁힘으로써 데이터 스택을 단순화하는 매력적인 변화를 나타냅니다. 논리적 복제, Apache Iceberg, 그리고 DuckDB를 것을으로써, 최소한의 인프라로 실시간 분석을 위한 경로를 제공합니다. 하지만, 모든 ELT 도구와 마찬가지로, 그 성공은 스트리밍된 원시 데이터(raw data)를 실행 가능한 인사이트로 변환하는 사용자의 능력에에 의릅니다.