OpenShift Virtualization의 PostgreSQL 고가용성: 기존 VM을 유지하는 EDB 구성
Red Hat OpenShift Virtualization에서 PostgreSQL 고가용성을 구현하면 기존 VM 기반 데이터베이스 운영을 유지하면서 컨테이너 애플리케이션과 플랫폼을 통합할 수 있습니다. EDB가 검증한 M1 아키텍처와 백업·장애 조치·AI 워크로드 구성을 살펴봅니다.
이 글은 EDB 제품 마케팅 매니저 Danny Navo가 공동 작성했습니다.
EDB Postgres AI는 Red Hat OpenShift Virtualization에서 테스트되었으며 지원됩니다. 가상 머신(VM)과 컨테이너가 동일한 컨트롤 플레인에서 함께 실행되므로, 기존 VM 기반 Postgres를 데이터베이스 아키텍처를 다시 설계하지 않고도 Red Hat OpenShift로 옮겨 컨테이너 기반 애플리케이션과 나란히 운영할 수 있습니다.
이 조합이 중요한 이유는 기업의 Postgres® 대부분이 여전히 가상 머신에서 실행되고 있으며, 앞으로도 수년간 그렇게 운영될 것이기 때문입니다. 업계의 논의는 컨테이너로 옮겨 갔지만 실제 운영 자산은 아직 그 단계에 이르지 못했습니다. 데이터베이스 계층은 전체 환경 중에서도 이전 속도가 가장 느린 부분입니다. EDB Postgres AI는 사전 아키텍처 재설계 없이 VM 기반 Postgres를 Red Hat OpenShift Virtualization에서 실행할 수 있도록 검증되고 지원되는 경로를 제공해 이 간극을 메웁니다.
데이터베이스 마이그레이션이 가장 늦어지는 이유
Postgres 자체를 컨테이너화하는 데는 큰 문제가 없지만, VM 안의 구성요소까지 옮기는 일은 더 어렵습니다. Postgres보다 VM에 묶여 있는 요소에는 다음과 같은 것들이 있습니다.
- 백업 보존 정책의 용량 산정 기준이 된 스토리지 구성과 파일 시스템 튜닝
- 장애 조치 동작과 그 앞단의 연결 라우팅
- 컨테이너 이미지가 아닌 VM 운영체제를 기준으로 인증된 외부 백업·모니터링·보안 에이전트
- 특정 호스트를 기준으로 정의된 감사 및 컴플라이언스 범위
- 당직 DBA가 새벽 2시에 실제로 따라야 하는 운영 절차서
데이터베이스 계층을 컨테이너화하려면 이 모든 요소를 한꺼번에 다시 검증해야 합니다. 대개 애플리케이션 팀은 다른 마이그레이션으로 바쁜 상황입니다. 수천 개의 VM을 이전하고 있는 플랫폼 팀이 이 작업까지 우선순위에 올리기는 어렵습니다.
플랫폼 팀이 지금 이러한 압박을 느끼는 직접적인 이유는 아키텍처보다 라이선스에 있습니다. 기존 하이퍼바이저의 갱신 견적이 몇 퍼센트가 아니라 몇 배씩 오를 수 있으며, 원문에서 인용한 분석가들은 2028년까지 해당 워크로드의 약 3분의 1이 다른 플랫폼으로 이동할 것으로 전망합니다. 전환의 계기가 상업적 조건인 만큼 마감일도 아키텍처 로드맵이 아니라 계약 갱신일입니다. 갱신 비용을 피하기 위해 하이퍼바이저를 서둘러 떠나는 팀에게 데이터베이스 계층 재설계까지 추진할 여유는 없습니다. 필요한 것은 데이터베이스 운영 방식을 바꾸거나 예산을 크게 초과하지 않고 기존 하이퍼바이저에서 벗어날 수 있는 방법입니다.
Red Hat OpenShift Virtualization이 제공하는 전환 경로
Red Hat OpenShift Virtualization은 단일 컨트롤 플레인에서 VM과 컨테이너를 함께 실행합니다. 현재 기존 하이퍼바이저에서 Postgres를 운영하는 팀은 기존 VM 기반 아키텍처를 대부분 유지한 채 Red Hat OpenShift로 옮길 수 있습니다. 운영 절차서와 축적한 운영 전문성도 계속 활용할 수 있습니다. 데이터베이스 컨테이너화 프로젝트를 동시에 추진하지 않고도 자체 일정에 따라 레거시 가상화에 대한 의존성을 줄일 수 있습니다.
하이브리드 방식도 가능합니다. 안정적으로 운영 중인 프로덕션은 VM에 유지하고, 신규 프로젝트는 동일한 플랫폼에서 EDB가 지원하는 CloudNativePG 기반 컨테이너로 구축하는 방식입니다.
이미 컨테이너 애플리케이션에 Red Hat OpenShift를 사용하는 조직이라면 실제 운영 사일로를 줄일 수 있습니다. 데이터베이스를 위한 별도 가상화 스택과 다른 워크로드를 위한 Kubernetes 스택을 따로 운영하는 대신, 하나의 플랫폼과 하나의 컨트롤 플레인으로 통합합니다. 새벽 2시에 장애가 나더라도 한곳에서 확인할 수 있습니다.
컨테이너 네이티브 방식도 여전히 EDB 전략의 핵심입니다. CloudNativePG는 EDB가 개발해 Cloud Native Computing Foundation(CNCF)에 기증한 프로젝트로, CNCF는 이를 “PostgreSQL용으로 가장 널리 사용되는 Kubernetes 오퍼레이터”라고 소개합니다. Red Hat OpenShift Virtualization은 플랫폼 통합을 먼저 진행하고 컨테이너화는 나중에 추진하려는 팀을 위한 상호 보완적인 경로입니다.
검증된 PostgreSQL 고가용성 아키텍처
EDB 엔지니어링 팀은 RHEL 9을 실행하는 Red Hat OpenShift Virtualization VM에서 M1 고가용성 패턴 전체를 처음부터 끝까지 검증했습니다. 배포에는 Red Hat Ansible Automation Platform을 사용합니다. 이는 많은 고객이 베어메탈이나 다른 하이퍼바이저에서 프로덕션 VM을 구축할 때 이미 사용하는 방식과 같습니다. 검증된 아키텍처는 다음과 같이 구성됩니다.
- 고가용성: 프라이머리 1개와 스트리밍 복제본 2개로 구성된 3노드 EDB Postgres 18 클러스터
- 장애 조치 관리: 자동 장애 조치와 통제된 스위치오버를 위한 EDB Failover Manager
- 백업 및 복구: 지속적인 WAL 아카이빙과 백업을 처리하는 전용 VM의 Barman
- 관측성: 모니터링과 알림을 위한 Postgres Enterprise Manager
EDB가 수년간 제공해 온 것과 동일한 M1 아키텍처이며, VM이 Red Hat OpenShift에서 실행된다는 차이가 있습니다.
엔터프라이즈 Postgres를 뒷받침하는 EDB의 전문성
EDB는 엔터프라이즈 Postgres의 주요 기여 기업 중 하나로서 현대적인 활용 사례를 지원하는 기술 지식과 전문성을 갖추고 있습니다. Postgres는 소수의 커미터가 관리하며, 소스 트리에 코드를 병합할 수 있는 사람은 이들뿐입니다. Postgres 18 개발 주기에는 EDB 엔지니어 20명이 패치 작성자로 참여해 약 55,000줄의 코드를 기여했습니다. 일반적인 메이저 버전에서도 EDB 엔지니어링 팀이 담당하는 유의미한 기여 비중은 30%를 넘습니다.
대표적인 기여 사례는 다음과 같습니다.
- Postgres 10의 논리적 복제: 서로 다른 Postgres 버전 사이에서 선택한 테이블을 복제할 수 있게 했습니다. 이는 현대적인 무중단 업그레이드 도구가 의존하는 기반입니다.
- Postgres 15의 MERGE와 Postgres 10의 선언적 파티셔닝: Oracle에서 이전하는 팀이 가장 자주 언급하는 두 기능입니다.
- Postgres 17의 JSON_TABLE: 오랫동안 EDB에서 일해 온 PostgreSQL 커미터 Andrew Dunstan은 여러 릴리스에 걸친 SQL/JSON 개발의 핵심 인물이었습니다. JSON_TABLE은 중첩 JSON 문서를 조회 가능한 관계형 행으로 바꾸어, 문서형 데이터와 관계형 데이터를 함께 사용할 때 필요했던 연결 코드를 줄여 줍니다.
- Postgres 17의 증분 백업: 이전 백업 이후 변경된 부분만 수집하므로, 수 테라바이트 규모에서도 잦은 백업을 현실적으로 수행할 수 있습니다.
- Postgres 18의 OAuth 인증: 데이터베이스 자체의 OAuth 인증 흐름으로, EDB의 엔터프라이즈 OAuth 모듈이 기반으로 삼는 업스트림 기능입니다.
EDB의 작업은 Postgres 코어에 그치지 않습니다. CloudNativePG를 개발했을 뿐 아니라 Barman, 외부 데이터 래퍼(Foreign Data Wrappers), 원본 Greenplum의 비공개 소스 전환 이후 만들어진 오픈소스 포크 WarehousePG, 데이터베이스 작업을 NVIDIA GPU로 오프로딩하는 PGPU를 유지·관리합니다. 여기에 투명한 데이터 암호화(Transparent Data Encryption), 데이터 마스킹(Data Redaction), 사용자 프로필(User Profiles), 기업이 실제 사용하는 ID 공급자와 통합되는 OAuth 모듈 등 엔터프라이즈 기능을 더해 업스트림 Postgres를 EDB Postgres AI로 확장합니다.
데이터베이스 커널 수준에서 문제가 발생하면 EDB는 이를 해결할 코드를 직접 작성할 수 있습니다.
동일한 VM에서 실행하는 AI 에이전트와 검색 워크로드
VM 방식을 선택한다고 AI 활용이 제한되는 것은 아닙니다. Red Hat OpenShift Virtualization에서 지원되는 동일한 EDB Postgres AI 배포판에는 벡터 유사도 검색용 pgvector, 더 큰 규모의 인덱싱을 위한 VectorChord, SQL로 정의하는 임베딩 및 검색 파이프라인을 위한 AIDB 확장, 관계가 많은 데이터 모델을 위한 그래프 지원이 포함됩니다. 현재 VM에서 Postgres를 운영하는 팀이 다음 분기에 검색 워크로드를 추가하려 한다면, 동일한 Red Hat OpenShift 플랫폼에서 진행할 수 있습니다.
EDB PG AI는 AI 에이전트도 지원합니다. 데이터베이스 위에 별도의 정책 도구를 두는 대신, Postgres의 기본 역할과 행 수준 보안을 활용해 데이터 계층에서 에이전트 거버넌스를 적용합니다. 제어 기능이 데이터베이스 자체의 속성이므로 VM에서도 컨테이너와 같은 방식으로 동작합니다.
직접 통제하는 하드웨어와 플랫폼에서 실행하고 Postgres 내부에서 거버넌스를 적용하는 것이 데이터 및 AI 주권을 실제로 구현하는 방식입니다. 하이퍼바이저 마이그레이션은 고객이 자신들의 의존성과 소유 주체를 검토하게 되는 계기이므로, 주권에 관한 논의의 출발점이 되곤 합니다.
OpenShift 기반 PostgreSQL 전환을 시작하는 방법
이미 Red Hat OpenShift를 사용하는 팀은 주로 기존 Red Hat Ansible Automation Platform 워크플로의 대상을 현재 Postgres 운영 위치에서 OpenShift Virtualization 네임스페이스로 바꾸면 됩니다.
기존 EDB 고객이라면 담당 계정 팀을 통해 검증된 참조 아키텍처와 실제 환경에 적용하는 방법을 안내받을 수 있습니다. EDB를 처음 도입하며 Red Hat OpenShift Virtualization 활용을 검토하고 있다면 EDB에 문의해 상담을 시작해 보세요.
자주 묻는 질문
OpenShift Virtualization으로 옮기려면 PostgreSQL을 먼저 컨테이너화해야 하나요?
아니요. 본문에서 소개한 방식은 기존 VM 기반 PostgreSQL 아키텍처를 대부분 유지한 채 Red Hat OpenShift Virtualization으로 옮기는 경로입니다. 동일한 플랫폼에서 VM과 컨테이너를 함께 운영할 수 있습니다.
검증된 M1 고가용성 아키텍처는 어떻게 구성되나요?
RHEL 9 기반 VM에서 프라이머리 1개와 스트리밍 복제본 2개로 구성된 3노드 EDB Postgres 18 클러스터를 사용합니다. EDB Failover Manager가 장애 조치를, 전용 VM의 Barman이 WAL 아카이빙과 백업을, Postgres Enterprise Manager가 모니터링과 알림을 담당합니다.
VM 기반 PostgreSQL과 CloudNativePG를 함께 운영할 수 있나요?
네. 기존 프로덕션 워크로드는 VM에 유지하고, 신규 프로젝트는 EDB가 지원하는 CloudNativePG 기반 컨테이너로 구축해 동일한 플랫폼에서 운영하는 방식을 본문에서 소개합니다.
VM 환경에서도 벡터 검색과 AI 에이전트를 활용할 수 있나요?
본문에 따르면 해당 EDB Postgres AI 배포판은 pgvector, VectorChord, AIDB 확장과 그래프 기능을 제공합니다. Postgres 역할과 행 수준 보안을 활용하는 데이터 계층의 에이전트 거버넌스도 VM과 컨테이너에서 같은 방식으로 적용됩니다.
한국어 콘텐츠 최종 수정일: 2026-10-15