AlloyDB Omni 개요

문서 버전을 선택합니다.

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 생태계와의 통합

  • AlloyDB Omni가 자체 관리 및 자체 조정할 수 있도록Google Cloud 에서 PostgreSQL용 AlloyDB의 Autopilot 기능 지원

    예를 들어 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 또는 서버에서 상주하는 인프라 레이어, 각 구성요소에 예상되는 관련 기능을 간략하게 보여줍니다.

PostgreSQL 구성요소에서 PostgreSQL용 AlloyDB 전용 구성요소를 분리하는 AlloyDB Omni 구성요소 아키텍처 다이어그램

그림 1. AlloyDB Omni 아키텍처

데이터베이스 엔진

이 문서에서는 컨테이너의 AlloyDB Omni 데이터베이스 아키텍처를 설명합니다. 이 문서에서는 사용자가 PostgreSQL에 익숙하다고 가정합니다.

데이터베이스 엔진은 다음 작업을 수행합니다.

  1. 클라이언트의 쿼리를 실행 가능한 계획으로 변환합니다.
  2. 쿼리를 충족하는 데 필요한 데이터를 찾습니다.
  3. 필요한 필터링, 정렬, 집계를 실행합니다.
  4. 클라이언트에 결과를 반환합니다.
클라이언트 애플리케이션이 데이터베이스 레이어와 상호작용하는 방식을 보여주는 다이어그램
그림 1. 클라이언트 애플리케이션의 쿼리에 응답하기 위해 함께 작동하는 데이터베이스 레이어를 보여줍니다.

클라이언트 애플리케이션이 AlloyDB Omni에 쿼리를 전송하면 다음 작업이 발생합니다.

  1. 쿼리 처리 레이어는 쿼리를 쿼리 실행 레이어로 이동하는 실행 계획으로 변환합니다.
  2. 쿼리 실행 레이어는 쿼리에 대한 응답을 계산하는 데 필요한 작업을 실행합니다.
  3. 실행 중에 데이터는 버퍼 캐시에서 로드되거나 저장소에서 직접 로드될 수 있습니다. 저장소에서 데이터를 로드하면 저장소의 데이터가 향후 사용을 위해 캐시에 저장됩니다.

클라이언트의 쿼리를 처리할 때 사용되는 리소스에는 CPU, 메모리, I/O, 네트워크, 데이터베이스 잠금과 같은 동기화 기본 요소가 포함됩니다. 성능 조정은 쿼리 실행의 각 단계에서 리소스 사용률을 최적화하는 것을 목표로 합니다.

성능이 우수한 데이터베이스 엔진의 목표는 필요한 최소한의 리소스를 사용하여 쿼리에 응답하는 것입니다. 이 목표는 적절한 데이터 모델과 쿼리 설계에서 시작됩니다.

  • 최소한의 데이터를 보면서 질문에 답변하려면 어떻게 해야 하나요?
  • 검색 공간과 I/O를 줄이는 데 필요한 색인은 무엇인가요?
  • 데이터를 정렬하려면 CPU가 필요하며 대규모 데이터 세트의 경우 디스크 액세스가 필요한 경우가 많습니다. 그렇다면 데이터 정렬을 피하려면 어떻게 해야 할까요?

데이터 스토리지

AlloyDB Omni는 기본 파일 시스템에 저장된 고정 크기 페이지에 데이터를 저장합니다. 쿼리에서 데이터에 액세스해야 하는 경우 AlloyDB Omni는 먼저 버퍼 풀을 확인합니다. 필요한 데이터를 보유한 페이지가 버퍼 풀에 없으면 AlloyDB Omni는 파일 시스템에서 필요한 페이지를 읽습니다. 버퍼 풀에서 데이터에 액세스하는 것이 파일 시스템에서 읽는 것보다 훨씬 빠르므로 애플리케이션에서 액세스할 데이터 양에 맞게 버퍼 풀 크기를 최대화하는 것이 중요합니다.

리소스 관리

AlloyDB Omni는 동적 메모리 관리를 사용하여 시스템의 메모리 요구에 따라 구성된 범위 내에서 버퍼 풀이 동적으로 확장 및 축소되도록 합니다. 따라서 버퍼 풀 크기를 조정할 필요가 없습니다. 성능 문제를 진단할 때 가장 먼저 고려해야 하는 측정항목은 버퍼 풀 적중률과 읽기 비율입니다. 이를 통해 애플리케이션이 버퍼 풀의 이점을 얻고 있는지 확인할 수 있습니다. 그렇지 않다면 애플리케이션의 데이터 세트가 버퍼 풀에 맞지 않는다는 의미이므로 메모리가 더 많은 큰 머신으로 크기를 조정하는 것이 좋습니다.

데이터를 가져오고, 필터링하고, 집계하고, 정렬하고, 프로젝션하는 프로세스에는 모두 데이터베이스 서버의 CPU 리소스가 필요합니다. 이 프로세스에 필요한 CPU 리소스의 양을 줄이려면 조작해야 하는 데이터의 양을 최소화하세요. 데이터베이스 서버의 CPU 사용률을 모니터링하여 정상 상태 사용률이 70% 정도인지 확인합니다. 이 양은 시간이 지남에 따라 사용률이 급증하거나 액세스 패턴이 변경될 때 서버에 충분한 여유 공간을 남겨 줍니다. 100% 에 가까운 사용률로 실행하면 프로세스 예약 및 컨텍스트 전환으로 인해 오버헤드가 발생하고 시스템의 다른 부분에서 병목 현상이 발생할 수 있습니다. 높은 CPU 사용률은 머신 사양에 관한 결정을 내릴 때 사용할 수 있는 또 다른 주요 측정항목입니다.

초당 입출력 작업 수 (IOPS)는 데이터베이스 애플리케이션 성능에 중요한 요소입니다. 즉, 기본 스토리지 기기가 데이터베이스에 제공할 수 있는 초당 입력 또는 출력 작업 수입니다. 데이터베이스 스토리지의 IOPS 제한에 도달하지 않으려면 버퍼 풀에 맞출 수 있는 데이터 양을 최대화하여 스토리지에 대한 읽기 및 쓰기를 최소화하세요.

열 기반 엔진

열 기반 엔진은 다음 구성요소를 제공하여 스캔, 조인, 집계의 SQL 쿼리 처리 속도를 높여줍니다.

  • 인메모리 열 저장소: 열 중심 형식으로 선택된 열의 테이블 및 구체화된 뷰 데이터를 포함합니다. 기본적으로 열 저장소는 사용 가능한 메모리 1GB를 사용합니다. 열 스토어에서 사용할 수 있는 메모리 양을 변경하려면 AlloyDB Omni 인스턴스에서 사용하는 postgresql.conf에서 google_columnar_engine.memory_size_in_mb 매개변수를 설정하세요.

    매개변수를 변경하는 방법에 관한 자세한 내용은 구성 매개변수 변경을 참고하세요.

  • 열 형식 쿼리 플래너 및 실행 엔진: 쿼리에서 열 저장소 사용을 지원합니다.

자동 메모리 관리

자동 메모리 관리자는 전체 AlloyDB Omni 인스턴스에서 메모리 소비를 지속적으로 모니터링하고 최적화합니다. 워크로드를 실행하면 이 모듈이 메모리 압력에 따라 공유 버퍼 캐시 크기를 조정합니다. 기본적으로 자동 메모리 관리자는 상한을 시스템 메모리의 80%로 설정하고 공유 버퍼 캐시에 시스템 메모리의 10% 를 할당합니다. 공유 버퍼 캐시의 크기 상한을 변경하려면 AlloyDB Omni 인스턴스에서 사용하는 postgresql.conf에서 shared_buffers 매개변수를 설정하세요.

자세한 내용은 자동 메모리 관리를 참고하세요.

적응형 자동 진공 청소

적응형 자동 청소기는 데이터베이스의 워크로드를 기반으로 작업을 분석하고 청소 빈도를 자동으로 조정합니다. 이 자동 조정은 작업 부하가 변경되더라도 데이터베이스가 진공 프로세스의 방해 없이 최고 성능으로 실행되도록 지원합니다.

적응형 자동 청소는 다음 요소를 사용하여 청소 작업의 빈도와 강도를 결정합니다.

  • 데이터베이스 크기
  • 데이터베이스의 비활성화된 튜플 수
  • 데이터베이스의 데이터 사용 기간
  • 초당 트랜잭션 수와 예상 진공 속도

적응형 자동 진공 청소는 다음과 같은 이점을 제공합니다.

  • 동적 vacuum 리소스 관리: AlloyDB Omni는 고정 비용 한도를 사용하는 대신 실시간 리소스 통계를 사용하여 vacuum 작업자를 조정합니다. 시스템이 사용 중이면 진공 프로세스 및 관련 리소스 사용량이 제한됩니다. 사용 가능한 메모리가 충분한 경우 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 애플리케이션 빌드를 참고하세요.

다음 단계