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는 비활성 데이터의 자동 메모리 관리와 적응형 자동 배큠을 지원합니다.
자주 실행되는 쿼리를 분석하고 쿼리 성능이 향상되도록 새 색인을 추천하는 색인 도우미
자주 쿼리되는 데이터를 메모리 내 열 형식으로 보관하여 비즈니스 인텔리전스, 보고, 하이브리드 트랜잭션 및 분석 처리(HTAP) 워크로드 속도를 향상시키는 AlloyDB Omni 열 기반 엔진
자체 성능 테스트 결과, 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 쿼리 처리 속도를 높여줍니다.
인메모리 열 스토어: 선택된 열의 테이블 및 구체화된 뷰 데이터를 포함하며 열 중심 형식입니다. 기본적으로 열 스토어는 사용 가능한 메모리 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는 자동 배큠을 더 자주 트리거하는 데 도움이 되는 업데이트된 스캔 메커니즘을 제공합니다. 이 스캔 메커니즘은 대형 테이블 청크를 스캔하고 기본 PostgreSQL 로직보다 더 효율적으로 데드 튜플을 삭제합니다. - 경고 메시지 로깅: AlloyDB Omni에서는 장기 실행 트랜잭션이나 준비된 트랜잭션 또는 대상이 손실된 복제 슬롯과 같은 배큠 차단기가 감지되고 경고가 PostgreSQL 로그에 등록되므로 문제를 적시에 해결할 수 있습니다.
AI/ML 작업자
AlloyDB Omni에서 AI/ML 백그라운드 작업자는 데이터베이스에서 직접 Vertex AI 모델을 호출하는 데 필요한 모든 기능을 제공합니다. AI/ML 작업자는 omni ml worker 프로세스로 실행됩니다.
자세한 내용은 AlloyDB AI를 사용하여 생성형 AI 애플리케이션 빌드를 참조하세요.
다음 단계
- AlloyDB Omni 다운로드 및 설치 옵션 알아보기
- 빠른 시작을 수행하여 VM에 AlloyDB Omni 설치
- Linux VM에 AlloyDB Omni 단일 인스턴스 설치 수행
- Kubernetes에 AlloyDB Omni를 설치하는 방법 알아보기