AlloyDB Omni는 다운로드 가능한 데이터베이스 소프트웨어 패키지로, 자체 컴퓨팅 환경에 간소화된 버전의 PostgreSQL용 AlloyDB를 배포할 수 있습니다. AlloyDB Omni와 Google Cloud 의 완전 관리형 PostgreSQL용 AlloyDB 서비스는 동일한 핵심 구성요소를 공유합니다. PostgreSQL용 AlloyDB는 WAL 성능을 최적화하는 클라우드 네이티브 스토리지 레이어를 사용하는 반면, AlloyDB Omni는 PostgreSQL에서 사용하는 것과 동일한 표준 파일 시스템 인터페이스를 사용합니다.
AlloyDB Omni의 이동성을 통해 다음과 같은 다양한 환경에서 실행할 수 있습니다.
- 데이터 센터
- 노트북
- 클라우드 기반 VM 인스턴스
AlloyDB Omni 사용 사례
AlloyDB Omni은 다음과 같은 시나리오에 적합합니다.
- 확장 가능하고 성능이 우수한 PostgreSQL 버전이 필요하지만 규제 또는 데이터 주권 요구사항으로 인해 클라우드에서 데이터베이스를 실행할 수 없습니다.
- 인터넷 연결이 끊겨도 계속 실행되는 데이터베이스가 필요합니다.
- 지연 시간을 최소화하려면 데이터베이스를 사용자와 지리적으로 최대한 가깝게 배치해야 합니다.
- 전체 클라우드 마이그레이션을 진행하지 않고 기존 데이터베이스에서 이전할 방법을 찾고 있습니다.
AlloyDB Omni에는 Google Cloud의 작업에 의존하는 PostgreSQL용 AlloyDB 기능이 포함되어 있지 않습니다. 프로젝트를 PostgreSQL용 AlloyDB의 완전 관리형 확장, 보안, 가용성 기능으로 업그레이드하려면 다른 초기 데이터 가져오기와 마찬가지로 AlloyDB Omni 데이터를 PostgreSQL용 AlloyDB 클러스터로 이전하면 됩니다.
주요 특징
- PostgreSQL 호환 데이터베이스 서버
- 운영 데이터를 사용하여 엔터프라이즈급 생성형 AI 애플리케이션을 빌드하는 데 도움이 되는 AlloyDB AI 지원
- Vertex AI Model Garden 및 오픈소스 생성형 AI 도구를 비롯한 Google Cloud AI 생태계와 통합할 수 있습니다.
Google Cloud 에서 PostgreSQL용 AlloyDB의 자동 조종 기능을 지원하여 AlloyDB Omni를 자체 관리하고 자체 조정할 수 있습니다.
예를 들어 AlloyDB Omni는 자동 메모리 관리와 오래된 데이터의 적응형 자동 데이터 제거를 지원합니다.
자주 실행되는 쿼리를 분석하고 쿼리 성능을 개선하기 위해 새 색인을 추천하는 색인 자문
AlloyDB Omni 열 형식 엔진: 자주 쿼리되는 데이터를 메모리 내 열 형식으로 보관하여 비즈니스 인텔리전스, 보고, 하이브리드 트랜잭션 및 분석 처리 (HTAP) 워크로드 속도를 향상합니다.
성능 테스트 결과, AlloyDB Omni의 트랜잭션 워크로드는 표준 PostgreSQL보다 2배 이상 빠르고 분석 쿼리는 최대 100배 더 빠른 것으로 확인되었습니다.
AlloyDB Omni 작동 방식
AlloyDB Omni는 독립형 서버로 또는 Kubernetes 환경의 일부로 설치할 수 있습니다.
AlloyDB Omni는 자체 환경에 설치하는 Docker 컨테이너에서 실행됩니다. SSD 스토리지와 CPU당 8GB 이상의 메모리가 있는 Linux 시스템에서 AlloyDB Omni를 실행하는 것이 좋습니다.
AlloyDB Omni Kubernetes 연산자는 대부분의 CNCF 호환 Kubernetes 환경에서 AlloyDB Omni를 실행할 수 있는 Kubernetes API 확장 프로그램입니다. 자세한 내용은 Kubernetes에 AlloyDB Omni 설치를 참고하세요.
애플리케이션이 PostgreSQL 데이터베이스 서버의 표준에 연결하고 통신하는 것처럼 애플리케이션은 AlloyDB Omni 설치에 연결하고 통신합니다. 사용자 액세스 제어도 PostgreSQL 표준을 사용합니다.
로깅에서부터 진공 청소, 열 기반 엔진에 이르기까지 데이터베이스 플래그를 사용하여 AlloyDB Omni의 데이터베이스 동작을 구성할 수 있습니다.
AlloyDB Omni를 컨테이너로 실행하는 이점
Google은 Docker 및 Podman과 같은 컨테이너 런타임으로 실행할 수 있는 컨테이너로 AlloyDB Omni를 배포합니다. 운영 측면에서 컨테이너는 다음과 같은 이점을 제공합니다.
- 투명한 종속 항목 관리: 필요한 모든 종속 항목이 컨테이너에 번들로 제공되며 Google에서 테스트하여 AlloyDB Omni과 완전히 호환되는지 확인합니다.
- 이식성: AlloyDB Omni는 여러 환경에서 일관되게 작동합니다.
- 보안 격리: AlloyDB Omni 컨테이너가 호스트 머신에서 액세스할 수 있는 항목을 선택합니다.
- 리소스 관리: AlloyDB Omni 컨테이너에서 사용할 컴퓨팅 리소스의 양을 정의할 수 있습니다.
- 원활한 패치 및 업그레이드: 컨테이너를 패치하려면 기존 이미지를 새 이미지로 교체하기만 하면 됩니다.
데이터 백업 및 재해 복구
AlloyDB Omni에는 조정 가능한 보관 기간 내의 특정 시점을 기준으로 새 데이터베이스 클러스터를 만들 수 있는 지속적 백업 및 복구 시스템이 있습니다. 이를 통해 데이터 손실 사고로부터 빠르게 복구할 수 있습니다.
또한 AlloyDB Omni는 주문형으로 또는 정기적인 일정에 따라 데이터베이스 클러스터의 데이터의 완전한 백업을 생성하고 저장할 수 있습니다. 언제든지 백업에서 백업 생성 시점의 원본 데이터베이스 클러스터의 모든 데이터가 포함된 AlloyDB Omni 데이터베이스 클러스터로 복원할 수 있습니다.
자세한 내용은 AlloyDB Omni 백업 및 복원을 참고하세요.
재해 복구의 추가 방법으로 별도의 데이터 센터에 보조 데이터베이스 클러스터를 만들어 교차 데이터 센터 복제를 실행할 수 있습니다. AlloyDB Omni는 지정된 기본 데이터베이스 클러스터에서 각 보조 클러스터로 데이터를 비동기식으로 스트리밍합니다. 필요한 경우 보조 데이터베이스 클러스터를 기본 AlloyDB Omni 데이터베이스 클러스터로 승격할 수 있습니다.
자세한 내용은 교차 데이터 센터 복제 정보를 참고하세요.
AlloyDB Omni VM 구성요소
VM의 AlloyDB Omni는 PostgreSQL용 AlloyDB 개선사항이 포함된 PostgreSQL 구성요소와 PostgreSQL용 AlloyDB 구성요소라는 두 가지 아키텍처 구성요소 세트로 구성됩니다. 다음 다이어그램은 두 구성요소 집합, VM 또는 서버의 인프라 레이어, 각 구성요소에서 기대할 수 있는 관련 기능을 간략히 보여줍니다.
그림 1. AlloyDB Omni 아키텍처
데이터베이스 엔진
이 문서에서는 컨테이너의 AlloyDB Omni 데이터베이스 아키텍처를 설명합니다. 이 문서에서는 사용자가 PostgreSQL에 익숙하다고 가정합니다.
데이터베이스 엔진은 다음 작업을 실행합니다.
- 클라이언트의 쿼리를 실행 가능한 계획으로 변환합니다.
- 쿼리를 충족하는 데 필요한 데이터를 찾습니다.
- 필요한 필터링, 정렬, 집계를 실행합니다.
- 클라이언트에 결과를 반환합니다.
클라이언트 애플리케이션이 AlloyDB Omni에 쿼리를 전송하면 다음 작업이 실행됩니다.
- 쿼리 처리 레이어는 쿼리를 쿼리 실행 레이어로 전달되는 실행 계획으로 변환합니다.
- 쿼리 실행 레이어는 쿼리에 대한 응답을 계산하는 데 필요한 작업을 실행합니다.
- 실행 중에 데이터는 버퍼 캐시에서 로드되거나 저장소에서 직접 로드될 수 있습니다. 데이터가 저장소에서 로드되면 저장소의 데이터가 나중에 사용할 수 있도록 캐시에 저장됩니다.
클라이언트의 쿼리를 처리할 때 사용되는 리소스에는 CPU, 메모리, I/O, 네트워크, 데이터베이스 잠금과 같은 동기화 프리미티브가 포함됩니다. 성능 조정은 쿼리 실행의 각 단계에서 리소스 사용률을 최적화하는 것을 목표로 합니다.
성능이 우수한 데이터베이스 엔진의 목표는 필요한 리소스를 가장 적게 사용하여 쿼리에 응답하는 것입니다. 이 목표는 우수한 데이터 모델과 쿼리 설계로 시작됩니다.
- 최소한의 데이터를 확인하면서 쿼리에 응답하려면 어떻게 해야 하나요?
- 검색 공간과 I/O를 줄이려면 어떤 색인이 필요한가요?
- 데이터를 정렬하려면 CPU가 필요하며 대규모 데이터 세트의 경우 디스크 액세스가 필요한 경우가 많습니다. 데이터 정렬을 피하려면 어떻게 해야 하나요?
데이터 스토리지
AlloyDB Omni는 기본 파일 시스템에 저장된 고정 크기 페이지에 데이터를 저장합니다. 쿼리가 데이터에 액세스해야 할 때 AlloyDB Omni는 먼저 버퍼 풀을 확인합니다. 필요한 데이터가 포함된 페이지가 버퍼 풀에 없으면 AlloyDB Omni는 파일 시스템에서 필요한 페이지를 읽습니다. 버퍼 풀에서 데이터에 액세스하는 것이 파일 시스템에서 읽는 것보다 훨씬 빠르므로 애플리케이션에서 액세스할 데이터의 양에 맞게 버퍼 풀의 크기를 최대화하는 것이 중요합니다.
리소스 관리
AlloyDB Omni는 동적 메모리 관리를 사용하여 버퍼 풀이 시스템의 메모리 요구사항에 따라 구성된 경계 내에서 동적으로 확장 및 축소되도록 합니다. 따라서 버퍼 풀 크기를 조정할 필요가 없습니다. 성능 문제를 진단할 때 가장 먼저 고려해야 할 측정항목은 버퍼 풀 히트율과 읽기 속도로, 애플리케이션이 버퍼 풀의 이점을 누리고 있는지 확인합니다. 그렇지 않으면 애플리케이션의 데이터 세트가 버퍼 풀에 맞지 않는 것이므로 메모리가 더 많은 더 큰 머신으로 크기를 조절해 보세요.
데이터를 검색, 필터링, 집계, 정렬, 프로젝션하는 모든 프로세스에는 데이터베이스 서버의 CPU 리소스가 필요합니다. 이 프로세스에 필요한 CPU 리소스 양을 줄이려면 조작해야 하는 데이터의 양을 최소화하세요. 데이터베이스 서버의 CPU 사용률을 모니터링하여 안정적인 사용률이 약 70%인지 확인합니다. 이 양은 서버에 사용량 급증이나 시간 경과에 따른 액세스 패턴 변경에 충분한 여유를 남겨 줍니다. 100% 에 가까운 사용률로 실행하면 프로세스 예약 및 컨텍스트 전환으로 인한 오버헤드가 발생하고 시스템의 다른 부분에 병목 현상이 발생할 수 있습니다. 높은 CPU 사용률은 머신 사양을 결정할 때 사용할 수 있는 또 다른 주요 측정항목입니다.
초당 입력/출력 작업 수 (IOPS)는 데이터베이스 애플리케이션 성능에 중요한 요소입니다. 즉, 기본 스토리지 기기가 데이터베이스에 전송할 수 있는 초당 입력 또는 출력 작업 수입니다. 데이터베이스 저장소의 IOPS 한도를 초과하지 않으려면 버퍼 풀에 들어갈 수 있는 데이터의 양을 극대화하여 저장소에 대한 읽기 및 쓰기를 최소화합니다.
열 기반 엔진
열 기반 엔진은 다음 구성요소를 제공하여 스캔, 조인, 집계의 SQL 쿼리 처리 속도를 높입니다.
인메모리 열 저장소: 선택한 열의 테이블 및 materialized-view 데이터를 열 중심 형식으로 포함합니다. 기본적으로 열 스토어는 사용 가능한 메모리 1GB를 사용합니다. 열 스토어에서 사용할 수 있는 메모리 양을 변경하려면 AlloyDB Omni 인스턴스에서 사용하는
postgresql.conf에서google_columnar_engine.memory_size_in_mb매개변수를 설정하세요.매개변수를 변경하는 방법에 관한 자세한 내용은 구성 매개변수 변경을 참고하세요.
열 형식 쿼리 계획자 및 실행 엔진: 쿼리에서 열 스토어 사용을 지원합니다.
자동 메모리 관리
자동 메모리 관리자는 전체 AlloyDB Omni 인스턴스에서 메모리 사용량을 지속적으로 모니터링하고 최적화합니다. 워크로드를 실행하면 이 모듈은 메모리 압력에 따라 공유 버퍼 캐시 크기를 조정합니다. 기본적으로 자동 메모리 관리자는 상한값을 시스템 메모리의 80%로 설정하고 공유 버퍼 캐시용으로 시스템 메모리의 10% 를 할당합니다.
공유 버퍼 캐시 크기의 상한을 변경하려면 AlloyDB Omni 인스턴스에서 사용하는 postgresql.conf에 shared_buffers 매개변수를 설정합니다.
자세한 내용은 자동 메모리 관리를 참고하세요.
적응형 자동 정리
적응형 자동 청소기는 데이터베이스의 워크로드를 기반으로 작업을 분석하고 청소 빈도를 자동으로 조정합니다. 이 자동 조정은 진공 프로세스의 간섭 없이 워크로드가 변경되더라도 데이터베이스가 최대 성능으로 실행되도록 도와줍니다.
적응형 자동 정리 기능은 다음 요소를 사용하여 정리 작업의 빈도와 강도를 결정합니다.
- 데이터베이스 크기
- 데이터베이스의 비활성 튜플 수
- 데이터베이스의 데이터 사용 기간
- 초당 트랜잭션 수와 예상 진공 속도 비교
적응형 자동 정리에는 다음과 같은 이점이 있습니다.
- 동적 진공 리소스 관리: AlloyDB Omni는 고정 비용 한도를 사용하는 대신 실시간 리소스 통계를 사용하여 진공 작업자를 조정합니다. 시스템이 사용 중이면 진공 프로세스와 관련 리소스 사용이 제한됩니다. 사용 가능한 메모리가 충분하면
maintenance_work_mem에 추가 메모리가 할당되어 엔드 투 엔드 진공 시간을 줄입니다. - 동적 XID 제한: 진공 청소 진행 상황과 트랜잭션 ID 소비 속도를 자동으로 지속적으로 모니터링합니다. 트랜잭션 ID 랩어라운드 위험이 감지되면 AlloyDB Omni는 트랜잭션 속도를 느리게 하여 ID 소비를 제한합니다. 또한 AlloyDB Omni는 진공 작업자에게 더 많은 리소스를 할당하여 트랜잭션 ID 공간의 전진 및 해제를 차단하는 테이블을 처리합니다. 이 프로세스 중에 거래 ID가 안전한 영역 (
AdaptiveVacuumNewXidDelay를 기다리는 세션으로 관찰됨)이 될 때까지 초당 전체 거래 수가 감소합니다. 거래 ID 기간이 증가하면 진공 작업자가 동적으로 증가합니다. - 대용량 테이블의 효율적인 진공 청소: 테이블을 진공 청소할 시기를 결정하는 데 사용되는 기본 PostgreSQL 로직은 비활성 튜플 비율이 포함된
pg_stat_all_tables에 저장된 테이블별 통계를 기반으로 합니다. 이 로직은 작은 테이블에는 적합하지만 자주 업데이트되는 대규모 테이블에는 효율적으로 작동하지 않을 수 있습니다. AlloyDB Omni는 autovacuum을 더 자주 트리거하는 데 도움이 되는 업데이트된 스캔 메커니즘을 제공합니다. 이 스캔 메커니즘은 대용량 테이블의 청크를 스캔하고 기본 PostgreSQL 로직보다 더 효율적으로 비활성 튜플을 삭제합니다. - 경고 메시지 로깅: AlloyDB Omni에서는 장기 실행 트랜잭션, 준비된 트랜잭션, 타겟을 잃은 복제 슬롯과 같은 진공 차단기가 감지되고 문제를 적시에 해결할 수 있도록 PostgreSQL 로그에 경고가 등록됩니다.
AI/ML 작업자
AlloyDB Omni에서 AI/ML 백그라운드 작업자는 데이터베이스에서 직접 Vertex AI 모델을 호출하는 데 필요한 모든 기능을 제공합니다. AI/ML 워커는 omni ml worker라는 프로세스로 실행됩니다.
자세한 내용은 AlloyDB AI를 사용하여 생성형 AI 애플리케이션 빌드를 참고하세요.