Greenplum 데이터 웨어하우스 현대화: WarehousePG 아키텍처와 전환 방법

Dunith Danushka
2025년 4월 10일
이 블로그는 두니스 다누쉬카(Dunith Danushka)와 오크 바렛(Oak Barrett)이 공동 작성했습니다.

Greenplum 데이터 웨어하우스 현대화와 WarehousePG

최근 EDB는 Greenplum Database의 새로운 Apache 라이선스 기반 포크(fork)인 WarehousePG와 함께 EDB Postgres AI – Support for Greenplum Workloads를 공식 출시했습니다. Greenplum이 소스 폐쇄 모델로 전환됨에 따라 신뢰할 수 있는 대안을 찾는 기업에 EDB Postgres AI – Support for Greenplum Workloads와 WarehousePG는 기존 투자를 보호하면서 전환 리스크를 줄일 수 있는 대안을 제공합니다.

이 글에서는 EDB의 데이터 웨어하우스 현대화 솔루션의 기반이 되는 Greenplum의 역사와 오픈소스 포크인 WarehousePG를 기술적으로 살펴봅니다. Greenplum과 WarehousePG의 아키텍처, 대규모 병렬 처리(MPP), Postgres 호환성 및 전환 절차를 중심으로 기존 Greenplum 인프라와 기술 역량을 활용하는 방법을 설명합니다.

Greenplum Database란 무엇이며 어떻게 발전했는가?

Greenplum은 대규모 분석 워크로드를 처리하도록 설계된 MPP 기반 Postgres 데이터베이스 시스템입니다. 페타바이트 규모의 데이터를 여러 노드에 분산해 처리하며, Postgres 아키텍처를 기반으로 분산 데이터베이스의 성능과 확장성을 제공합니다.

Greenplum의 개발 주체 변화는 제품의 발전과 배포 방식에도 전환점이 되었습니다. 초기에는 Greenplum Corporation이 개발했으며, 2010년 EMC Corporation이 이를 인수했습니다. 이후 2012년 EMC와 VMware가 합작해 Pivotal을 설립하면서 Greenplum은 오픈소스 프로젝트로 성장했고 커뮤니티 협업도 확대되었습니다.

2020년 VMware가 Pivotal과 Greenplum을 인수한 이후에도 오픈소스 프로젝트의 전통은 이어졌습니다. 그러나 2023년 Broadcom이 VMware를 인수한 이후 Greenplum을 소스 폐쇄 모델로 전환할 계획이 발표됐습니다.

Greenplum의 주요 변화 이력

Greenplum 소스 폐쇄 전환에 따른 주요 과제

Greenplum의 소스 폐쇄 전환은 기존 사용자에게 다음과 같은 과제를 제기했습니다.

• 기술 수명 종료(EOL) 리스크: 기존 오픈소스 버전을 계속 사용할 경우 보안 취약점과 호환성 문제가 누적될 가능성
• 벤더 종속(Vendor Lock-in) 리스크: 폐쇄형 소스 모델 도입에 따른 지원 정책 변경과 비용 증가 가능성
• 비즈니스 연속성 리스크: 비즈니스 크리티컬 시스템과 기존 Greenplum 투자 자산에 미칠 수 있는 영향
• 혁신의 한계: 커스터마이징과 커뮤니티 기여가 제한되면서 최적화 및 기능 개발에 제약이 발생할 가능성
• 데이터 마이그레이션 부담: 새로운 조건을 수용하거나 비용 부담이 큰 대체 솔루션으로 전환해야 하는 상황

이러한 과제로 인해 많은 기업이 데이터 웨어하우스 전략을 재검토하고 있으며, 예측 가능한 비용 구조와 데이터 인프라에 대한 통제력을 제공하는 대안을 찾고 있습니다. 이러한 환경에서 EDB Postgres AI – Support for Greenplum Workloads는 Greenplum 호환성을 지원하는 오픈소스 기반 대안으로 주목받고 있습니다.

EDB Postgres AI – Support for Greenplum Workloads를 선택하는 이유

EDB Postgres AI – Support for Greenplum Workloads는 기존 Greenplum 고객이 WarehousePG로 전환할 수 있도록 지원하는 솔루션입니다. Greenplum 6.x 및 7.x 버전과의 바이너리 호환성을 통해 별도의 재교육이나 애플리케이션 리팩토링 부담을 줄이면서 데이터 웨어하우스 현대화를 추진할 수 있습니다.

또한 EDB는 연중무휴 기술 지원, 보안 취약점(CVE) 패치 및 EDB 서명 패키지를 제공합니다.

WarehousePG는 고급 분석 및 AI 활용 기능과 Postgres 확장성을 지원해 기존 Greenplum 환경을 현대화할 수 있도록 돕습니다.

WarehousePG와 Greenplum의 아키텍처 및 핵심 기능

MPP 아키텍처와 분산 쿼리 처리 방식

대규모 병렬 처리(Massively Parallel Processing, MPP)는 여러 프로세서가 동시에 하나의 프로그램을 실행하는 구조입니다. 데이터베이스에서는 대용량 데이터를 여러 독립 노드에 분산해 처리함으로써 성능과 확장성을 높이는 방식으로 활용됩니다.

Greenplum은 MPP 아키텍처를 기반으로 설계됐으며, Greenplum에서 포크된 WarehousePG도 동일한 기본 아키텍처를 따릅니다. 이 구조는 Coordinator 노드와 여러 Segment 노드로 구성됩니다.

• Coordinator 노드는 클라이언트 연결 진입점으로, 쿼리 실행 계획을 수립하고 분산 처리 작업을 총괄합니다. 시스템 메타데이터를 관리하며 쿼리 제출과 결과 집계도 처리합니다.
• Segment 노드는 실질적인 데이터 처리와 저장을 담당하며, 각 노드는 독립적인 Postgres 데이터베이스로 작동합니다. 일반적으로 서버 사양에 따라 하나의 Segment 노드에서 2개 이상의 Segment 프로세스가 실행됩니다.

사용자가 쿼리를 제출하면 Coordinator 노드는 최적화된 실행 계획을 수립해 전체 Segment에 작업을 분배합니다. 각 Segment는 할당된 데이터를 병렬로 처리한 뒤 결과를 Coordinator 노드로 보내며, Coordinator가 이를 집계해 반환합니다.

이러한 병렬 처리 구조를 통해 WarehousePG는 페타바이트 규모의 데이터를 처리할 수 있습니다. 최적의 성능을 확보하려면 모든 Segment 노드를 동일한 하드웨어 사양으로 구성하는 것이 권장됩니다.

WarehousePG의 장애 대응 및 고가용성 아키텍처

Coordinator 노드 장애 시 동작 방식

WarehousePG는 고가용성을 위해 Standby Coordinator 노드를 통한 장애 조치(failover) 기능을 제공합니다. Standby Coordinator는 Primary Coordinator의 데이터와 메타데이터를 Write-Ahead Logging(WAL) 스트리밍 복제로 동기화하며, Primary Coordinator에 장애가 발생하면 주 노드로 승격됩니다. 이러한 Warm Standby 방식은 안정적인 장애 복구를 지원합니다.

Segment 노드 장애 시 동작 방식

Segment 계층에서는 미러링(mirroring) 기능을 통해 장애에 대응할 수 있습니다. 각 Primary Segment와 동일한 데이터를 보유한 Mirror Segment가 별도의 호스트에 구성되며, Primary Segment에 장애가 발생하면 Mirror Segment로 장애 조치가 이루어집니다.

Greenplum과 WarehousePG는 다음 두 가지 미러링 구성 옵션을 지원합니다.

• Group Mirroring: Mirror Segment를 하나의 백업 호스트에 집중 배치
• Spread Mirroring: Mirror Segment를 여러 호스트에 분산 배치해 가용성 강화

Greenplum Interconnect 기반 고속 네트워크 통신

Coordinator와 Segment 사이의 빠르고 안정적인 통신은 대규모 병렬 쿼리 처리 성능에 중요한 역할을 합니다. WarehousePG는 Greenplum Interconnect라는 네트워크 계층을 통해 노드 간 통신, 데이터 분산 및 쿼리 결과 집계를 처리합니다. Interconnect는 전체 클러스터의 데이터 흐름을 조정하는 MPP 아키텍처의 핵심 구성 요소입니다.

WarehousePG의 Postgres 호환성

WarehousePG는 Postgres와 높은 수준의 호환성을 제공합니다. 단순한 SQL 문법 지원을 넘어 다음과 같은 주요 Postgres 기능을 사용할 수 있습니다.

• 공통 테이블 표현식(Common Table Expressions, CTE)
• 윈도우 함수(Window Functions)
• 고급 인덱싱 기능
• Postgres 확장(Extension)

기존에 사용하던 Postgres 클라이언트 도구인 psql과 pgcli 등을 활용할 수 있으며, 다음 명령어로 WarehousePG에 접속할 수 있습니다.

psql -h hostname -p 5432 -d database -U username

Postgres 생태계와 확장 기능을 활용할 수 있으며, 특화된 워크로드를 위한 사용자 정의 확장 개발도 지원합니다.

WarehousePG의 대표적인 확장 모듈

WarehousePG는 익숙한 Postgres 인터페이스를 제공하므로 개발자와 DBA가 기존 Postgres 기술 역량을 활용할 수 있습니다.

추가 패키지와 엔터프라이즈 기술 지원

WarehousePG는 Greenplum의 상용 모듈을 대체할 수 있는 개발 기능, 파트너 솔루션 및 EDB Postgres AI 통합 기능 등을 제공합니다. EDB는 글로벌 연중무휴 기술 지원 서비스를 통해 운영을 지원합니다.

Greenplum에서 WarehousePG로 전환하는 방법

WarehousePG는 기존 인프라를 유지하면서 Greenplum 환경을 현대화할 수 있도록 설계됐습니다. 본문에서 소개하는 기본적인 바이너리 교체 절차는 다음과 같습니다.

1. 기존 Greenplum 프로세스 중지
2. 기존 패키지 제거
3. WarehousePG 패키지 설치
4. 데이터베이스 재시작

포트 설정, 기존 AI·BI·DBA 도구와 정기적인 관리 작업 등 기존 시스템 구성을 유지하면서 적용할 수 있습니다.

Greenplum 6.x와 같은 구버전을 사용하는 고객은 EDB 프로페셔널 서비스의 업그레이드 지원을 통해 바이너리를 교체한 뒤 WarehousePG 7.x로 전환할 수 있습니다. 실제 전환 전에는 현재 버전과 시스템 구성에 따른 적용 가능 여부 및 절차를 확인해야 합니다.

Greenplum 데이터 웨어하우스 현대화의 핵심

이번 기술 분석에서는 Greenplum이 엔터프라이즈 데이터 웨어하우스 솔루션으로 발전해 온 과정과 EDB Postgres AI – Support for Greenplum Workloads가 기존 Greenplum 사용자에게 제공하는 대안을 살펴봤습니다. 특히 Apache 라이선스 기반의 WarehousePG를 통해 기존 환경을 현대화할 수 있다는 점이 핵심입니다.

WarehousePG는 MPP 아키텍처를 기반으로 대규모 데이터 세트를 병렬 처리하도록 설계됐습니다. 또한 Postgres 호환성을 제공해 기존 데이터베이스 도구 및 워크플로와 통합할 수 있으며, 다양한 Postgres 확장 기능도 활용할 수 있습니다.

EDB의 엔터프라이즈 기술 지원 및 보안 역량을 함께 활용하면 EDB Postgres AI – Support for Greenplum Workloads를 기반으로 Greenplum 분석 환경을 현대화할 수 있습니다.

Greenplum에서 WarehousePG로 전환하는 방법을 자세히 알아보려면 EDB Postgres AI – Support for Greenplum Workloads 제품 페이지를 방문하거나 WarehousePG GitHub 저장소를 참고하세요. 기술 전문가 상담과 무상 워크로드 진단이 필요한 경우 EDB에 문의할 수 있습니다.

WarehousePG와 Greenplum FAQ

WarehousePG란 무엇인가요?

WarehousePG는 Greenplum Database를 기반으로 개발된 Apache 라이선스 기반의 오픈소스 포크입니다. MPP 아키텍처와 Postgres 호환성을 바탕으로 대규모 데이터 웨어하우스 및 분석 워크로드를 지원합니다.

WarehousePG는 Greenplum 6.x 및 7.x와 호환되나요?

EDB Postgres AI – Support for Greenplum Workloads는 Greenplum 6.x 및 7.x와의 바이너리 호환성을 제공합니다. 구체적인 전환 및 업그레이드 절차는 현재 운영 환경을 기준으로 EDB 전문가와 검토하는 것이 좋습니다.

WarehousePG의 MPP 아키텍처는 어떻게 작동하나요?

Coordinator 노드가 쿼리 실행 계획을 수립하고 작업을 여러 Segment 노드에 분배합니다. 각 Segment는 할당된 데이터를 병렬로 처리하며, 처리 결과는 Coordinator 노드에서 집계되어 사용자에게 반환됩니다.

WarehousePG는 노드 장애에 어떻게 대응하나요?

Coordinator 계층에서는 Standby Coordinator를 사용하고, Segment 계층에서는 Mirror Segment를 구성해 장애에 대응합니다. Segment 미러링은 Group Mirroring 또는 Spread Mirroring 방식으로 구성할 수 있습니다.

Greenplum에서 WarehousePG로 전환할 때 데이터를 마이그레이션해야 하나요?

본문에서 설명한 바이너리 교체 방식은 기존 인프라와 데이터를 유지하면서 패키지를 교체하는 절차입니다. 실제 적용 가능 여부와 세부 절차는 사용 중인 Greenplum 버전과 시스템 구성을 기준으로 사전에 확인해야 합니다.

안내사항

Greenplum®은 Broadcom Inc.의 등록 상표입니다. EDB 및 EDB Postgres AI는 Broadcom Inc.와 아무런 제휴, 후원 또는 승인 관계가 없습니다. 본 문서에서 Greenplum에 대한 언급은 비교, 교육 및 상호운용성 목적을 위한 것입니다.

원문: Data warehouse modernization with EDB Postgres AI and Greenplum compatibility

이메일: salesinquiry@enterprisedb.com