이 참조 아키텍처는 Google Distributed Cloud (GDC) 에어 갭에서 고객 관리형 PostgreSQL 데이터베이스를 배포하고 운영하기 위한 개념적 프레임워크를 제공합니다. 이 솔루션을 사용하면 조직에서 가상 머신에 배포된 고가용성 (HA) 멀티 영역 클러스터를 활용하여 중요한 데이터베이스 워크로드를 유지할 수 있습니다.
이 아키텍처는 단일 영역 또는 인프라 장애가 발생해도 데이터베이스 가용성을 보장하는 복원력이 뛰어난 3노드 구성에 중점을 둡니다. 자동 프로비저닝 및 네트워킹부터 고가용성, 백업, 복원, 관측 가능성과 같은 프로덕션급 운영까지 전체 수명 주기를 다룹니다.
특징 및 기능
이 솔루션은 데이터베이스 관리를 위한 여러 핵심 기능 구성요소를 제공합니다.
- 자동 고가용성: Patroni 및 etcd를 사용하여 자동 리더 선택 및 장애 조치를 제공하여 수동 개입 없이 데이터베이스가 계속 작동하도록 합니다.
- 멀티 영역 복원력: 데이터베이스 노드를 세 개의 개별 가용성 영역에 분산하여 로컬 하드웨어 또는 인프라 서비스 중단을 방지합니다.
- 표준화된 자동화: Autobase가 포함된 Ansible 기반 플레이북을 사용하여 전체 스택을 프로비저닝하여 반복 가능하고 일관된 배포를 보장합니다.
- 연결 풀링: 통합된 PgBouncer 서비스로 높은 연결 수를 관리하고 데이터베이스 노드의 리소스 소비를 안정화합니다.
- 전역 부하 분산: 플랫폼 관리형 전역 L4 부하 분산기 를 사용하여 모든 영역에서 액세스할 수 있는 단일의 안정적인 가상 IP (VIP)를 제공합니다.
- 에어 갭 준비: 연결이 끊긴 환경에 배포하는 데 필요한 모든 운영체제 종속 항목과 바이너리를 패키징하는 특수 워크플로입니다.
- 데이터 보호: GDC 스토리지 스냅샷과 함께
pg_dump및pg_basebackup과 같은 표준 도구를 활용하여 강력한 백업 및 복구 전략을 유지합니다.
아키텍처
이 아키텍처는 세 개의 가용성 영역에 분산된 3개의 VM 환경으로 구성되며, 이 환경은 공동 배치된 서비스 스택을 실행합니다.
아키텍처 원칙
- 다수 기반 합의: 노드의 대다수 (3개 중 2개)가 클러스터 상태에 동의해야 하는 쿼럼 기반 모델을 사용하여 '분할 브레인' 시나리오를 방지하고 데이터 무결성을 보장합니다.
- 관심사 분리: 각 VM은 공동 배치되지만 고유한 서비스 스택 (데이터베이스, HA 관리자, 합의, 풀러)을 실행하여 자체 포함되고 복원력이 뛰어난 노드를 제공합니다.
- 데이터베이스 인식 장애 조치: Patroni의 REST API를 사용하여 데이터베이스 상태 측정항목의 우선순위를 지정하여 플랫폼 부하 분산기를 통해 트래픽 리디렉션을 조정합니다.
- 코드형 인프라: 모든 구성 작업에 자동화된 플레이북을 사용하여 배포 및 확장 중에 인적 오류가 발생할 위험을 줄입니다.
개념 및 기술
이 섹션에서는 기능 구성요소, 책임, 시스템 내에서 통신하는 방법을 자세히 설명합니다.
인프라 및 플랫폼
- 가상 머신 (VM): 데이터베이스 스택을 호스팅하기 위해 영역에 분산된 전용 컴퓨팅 인스턴스입니다.
- 전역 L4 부하 분산기: 트래픽을 현재 클러스터 리더로 라우팅하는 안정적인 가상 IP (VIP)를 제공하는 플랫폼 관리형 서비스입니다.
- 영구 스토리지: 합의 레이어의 미리 쓰기 로그에 대한 엄격한 지연 시간 요구사항을 충족하려면 고성능 SSD 지원 스토리지가 필요합니다.
서비스 및 로직
- PostgreSQL 17: 데이터 지속성 및 쿼리 실행을 담당하는 핵심 관계형 데이터베이스 엔진입니다.
- Patroni: 로컬 PostgreSQL 프로세스를 모니터링하고 etcd를 사용하여 리더 선택을 조정하는 고가용성 관리자입니다.
- etcd: 합의 레이어를 제공하고 클러스터의 신뢰할 수 있는 상태를 유지하는 분산 구성 저장소입니다.
- PgBouncer: PostgreSQL 앞에 위치하여 수신 애플리케이션 연결을 효율적으로 처리하는 경량 연결 풀러입니다.
데이터 흐름 및 인터페이스
- PgBouncer (포트 6432): 애플리케이션 데이터베이스 트래픽의 기본 진입점입니다.
- Patroni API (포트 8008): 부하 분산기에서 상태 점검을 실행하고
/primary엔드포인트를 사용하여 현재 리더를 식별하는 데 사용하는 HTTPS REST 인터페이스입니다. - etcd (포트 2379): 상태를 유지하고 선택을 실행하는 합의 클러스터의 통신 채널입니다.
고려사항
- 확장성 및 성능:
- 데이터베이스 노드는 워크로드를 기반으로 크기가 조정되어야 하며 최소 2개의 vCPU와 8GiB RAM이 있어야 합니다. 프로덕션 워크로드는 일반적으로 8개의 vCPU와 32GiB에서 시작됩니다.
- 성능은 짧은 지연 시간 스토리지를 사용합니다. etcd가 10ms 이내에 데이터 동기화를 처리할 수 있도록 SSD가 필요합니다.
- 동기 복제: 동기 복제의 오버헤드는 영역 간 네트워크 지연 시간에 직접적으로 의존합니다. 데이터 손실이 없는 구성의 최적 성능을 보장하려면 영역 간 지연 시간이 짧아야 합니다.
- 리소스 관리 및 라이선스:
- 이 솔루션은 무료 오픈소스 데이터베이스 구성요소를 사용합니다.
- Autobase는 HA 스택의 설치 및 구성을 간소화하는 참조 자동화 도구로 사용됩니다. 하지만 이 아키텍처는 Autobase에만 연결되지 않으며 기본 오픈소스 구성요소는 커스텀 파이프라인을 사용하여 관리할 수 있습니다.
- 자동화 패키지에 대한 공식 지원이 필요한 조직의 경우 서드 파티 유료 지원을 사용할 수 있습니다.
- PgBouncer를 사용한 연결 풀링은 높은 사용자 연결 수로 인한 CPU 및 메모리 소진을 방지하는 데 필수적입니다.
- 가용성 및 안정성:
- 고가용성은 3노드 쿼럼을 통해 달성됩니다. 단일 노드 또는 영역의 장애가 발생해도 서비스가 중단되지 않습니다.
- 클러스터 안정성: 안정적인 쿼럼을 유지하려면 노드 간 네트워크 지연 시간이 짧아야 합니다. 선택 시간 초과 및 클러스터 불안정을 방지하려면 평균 왕복 시간 (RTT)이 10ms 미만이어야 합니다.
- 운영 관리:
- 부 버전 패치 및 주요 업그레이드와 같은 일상적인 작업은 고객의 운영팀에서 계속 담당합니다.
- VM의
stdout출력은 GDC 에어 갭 모니터링 플랫폼으로 자동으로 수집됩니다. 개별 구성요소에 대한 더 자세한 모니터링을 통합하는 방법에 관한 가이드가 향후 게시될 예정입니다. - 데이터베이스 기본 도구 및 플랫폼 스냅샷을 사용하여 강력한 백업 전략을 구현해야 합니다. 이 절차에 관한 자세한 가이드가 별도로 게시될 예정입니다.
설계 결정
이 솔루션의 아키텍처 선택은 멀티 영역 배포를 위한 복원력이 뛰어난 경로를 제공합니다.
Kubernetes를 통한 가상 머신
멀티 영역 고가용성을 제공하기 위해 VM 기반 접근 방식이 선택되었습니다. GDC는 여러 물리적 영역에 걸쳐 있는 Kubernetes 클러스터를 지원하지 않습니다. 따라서 강력한 교차 영역 아키텍처를 구현하려면 전용 VM을 별도의 영역에 배포해야 합니다. 이 구성은 단일 인프라 영역의 완전한 장애를 견딜 수 있습니다.
플랫폼 기본 전역 부하 분산
이 아키텍처는 VM의 소프트웨어 기반 프록시 대신 GDC 전역 L4 부하 분산기를 활용합니다. 이 접근 방식은 다음과 같은 여러 이점을 제공합니다.
- 전역 도달범위: 모든 영역에서 액세스할 수 있는 안정적인 가상 IP를 제공합니다.
- 플랫폼 관리: VIP는 플랫폼의 컨트롤 플레인에서 독립적으로 관리됩니다.
- 간소화된 장애 조치: 장애 조치는 복잡한 로컬 소프트웨어 구성이 아닌 표준 상태 점검 프로브를 통해 관리됩니다.
- 고가용성: 로컬 프록시에 대한 의존도를 없애면 데이터베이스 트래픽의 진입점이 복원력을 유지할 수 있습니다.
가정 및 제한사항
가정
- 환경에 패키징된 OS 종속 항목과 바이너리를 가져오는 로컬 레지스트리 또는 메커니즘이 있습니다.
- Ansible 기반 자동화를 위해 모든 대상 VM에서 키 기반 SSH 액세스를 사용할 수 있습니다.
- 프로젝트에 멀티 영역 VM 및 부하 분산기 프로비저닝을 위한 할당량이 충분합니다.
제한사항
- 수동 유지보수: 운영체제 패치 및 PostgreSQL 버전 업그레이드는 수동 작업이며 솔루션에서 자동화되지 않습니다.
- 스토리지 민감도: 합의 레이어 (etcd)는 디스크 지연 시간에 매우 민감합니다. 지속적인 높은 스토리지 경합은 합의 레이어의 안정성에 영향을 미칠 수 있습니다.
- 네트워크 안정성: 고가용성 관리자는 영역 간 일관되고 짧은 지연 시간의 네트워크 연결에 의존합니다. 지연 또는 네트워크 지터는 클러스터 조정 및 역할 전환의 타이밍에 영향을 미칠 수 있습니다.
추가 자료
- 참조 자동화 코드 저장소: GitHub의 Autobase 소스 코드
- PostgreSQL 데이터베이스 참조 구현