이 문서에서는 컨테이너 런타임을 지원하는 모든 Linux 환경에서 AlloyDB Omni를 실행할 준비를 하는 방법을 설명합니다.
AlloyDB Omni에 관한 개요는 AlloyDB Omni 개요를 참고하세요.
크기 및 용량
크기와 용량은 AlloyDB Omni 인스턴스의 성능, 안정성, 비용 효율성에 직접적인 영향을 미칩니다. 기존 데이터베이스를 마이그레이션할 때 필요한 CPU 및 메모리 리소스는 소스 데이터베이스 시스템의 요구사항과 유사합니다.
일치하는 CPU, RAM, 디스크 리소스를 사용하는 배포로 시작하고 소스 시스템 구성을 AlloyDB Omni 기준 구성으로 사용하는 것이 좋습니다. AlloyDB Omni 인스턴스를 충분히 테스트한 후 리소스 사용량을 줄일 수 있습니다.
AlloyDB Omni 환경의 크기를 조정하려면 다음 단계를 따르세요.
워크로드를 정의합니다.
데이터 양: AlloyDB Omni에 저장할 총 데이터 양을 추정합니다. 현재 데이터와 시간 경과에 따른 예상 성장률을 모두 고려하세요.
트랜잭션 속도: 읽기, 쓰기, 업데이트, 삭제를 포함하여 초당 예상 트랜잭션 수 (TPS)를 확인합니다.
동시 실행: 데이터베이스에 액세스하는 동시 사용자 수 또는 연결 수를 추정합니다.
성능 요구사항: 다양한 유형의 쿼리 및 작업에 허용되는 응답 시간을 정의합니다.
하드웨어가 크기 요구사항을 지원하는지 확인합니다.
CPU: AlloyDB Omni는 64개 코어까지 선형으로 확장되는 여러 CPU 코어의 이점을 누립니다. 하지만 오픈소스 PostgreSQL은 일반적으로 16개가 넘는 vCPU의 이점을 얻지 못합니다. 워크로드의 동시 실행 및 계산 요구사항에 따라 코어 수를 고려하세요. CPU 세대 또는 플랫폼 변경으로 인해 발생할 수 있는 이득을 고려합니다.
메모리: 데이터 캐싱을 위한 AlloyDB Omni의 공유 버퍼와 쿼리 처리를 위한 작업 메모리에 충분한 RAM을 할당합니다. 정확한 요구사항은 워크로드에 따라 다릅니다. vCPU당 8GB의 RAM으로 시작합니다.
스토리지
유형: 필요에 따라 성능을 위한 로컬 NVMe 스토리지 또는 확장성과 데이터 공유를 위한 SAN 스토리지 중에서 선택합니다.
용량: 데이터 양, 색인, Write-Ahead Log (WAL), 백업, 향후 확장에 충분한 스토리지를 확보합니다.
IOPS: 워크로드의 읽기 및 쓰기 패턴을 기반으로 필요한 초당 입출력 작업 수(IOPS)를 추정합니다. 퍼블릭 클라우드에서 AlloyDB Omni를 실행할 때는 스토리지 유형의 성능 특성을 고려하여 특정 IOPS 타겟을 충족하기 위해 스토리지 용량을 늘려야 하는지 파악합니다.
AlloyDB Omni 실행의 기본 요건
AlloyDB Omni를 실행하기 전에 다음 하드웨어 및 소프트웨어 요구사항을 충족하는지 확인하세요.
하드웨어 요구사항
| OS/플랫폼 | 최소 하드웨어 | 권장 하드웨어 |
|---|---|---|
| Linux |
|
|
| macOS |
|
|
- 데이터를 저장할 때는 전용 솔리드 스테이트 드라이브 (SSD) 스토리지 기기를 사용하는 것이 좋습니다. 이 용도로 실제 기기를 사용하는 경우 호스트 머신에 직접 연결하는 것이 좋습니다.
소프트웨어 요구사항
| OS/플랫폼 | 최소 소프트웨어 | 권장 소프트웨어 |
|---|---|---|
| Linux1 |
|
|
| macOS |
|
|
- AlloyDB Omni는 SELinux가 있는 경우 호스트에서 파일 시스템 액세스를 비롯하여 컨테이너가 실행되도록 구성되어 있다고 가정합니다 (또는 SELinux가 허용으로 설정되어 있음).
지원되는 저장소 유형
AlloyDB Omni는 데이터베이스 인스턴스의 블록 스토리지 볼륨에 있는 파일 시스템을 지원합니다. 소규모 개발 또는 체험판 시스템의 경우 컨테이너가 실행 중인 호스트의 로컬 파일 시스템을 사용합니다. 엔터프라이즈 워크로드의 경우 AlloyDB Omni 인스턴스에 예약된 스토리지를 사용하세요. 데이터베이스 워크로드에서 설정한 요구사항에 따라 스토리지 기기를 각 컨테이너에 하나의 디스크 기기가 있는 싱글톤 구성으로 구성하거나 여러 컨테이너가 동일한 디스크 기기에서 읽고 쓰는 통합 구성으로 구성합니다.
로컬 NVMe 또는 SAN 스토리지
로컬 비휘발성 메모리 익스프레스 (NVMe) 스토리지와 스토리지 영역 네트워크(SAN) 스토리지 모두 고유한 이점을 제공합니다. 적절한 솔루션을 선택하는 것은 특정 워크로드 요구사항, 예산, 향후 확장성 요구사항에 따라 달라집니다.
가장 적합한 스토리지 옵션을 결정하려면 다음을 고려하세요.
- 절대적인 성능을 우선하는 경우 로컬 NVMe를 선택하세요.
- 대규모 공유 스토리지가 필요한 경우 SAN을 선택하세요.
- 성능과 공유의 균형을 맞춰야 하는 경우 Fabrics를 통한 NVMe를 사용한 SAN을 고려하여 액세스 속도를 높이세요.
로컬 NVMe 스토리지
NVMe는 솔리드 스테이트 드라이브 (SSD)용으로 설계된 고성능 프로토콜입니다. 빠른 데이터 액세스가 필요한 애플리케이션의 경우 로컬 NVMe 저장소는 다음과 같은 이점을 제공합니다.
- NVMe SSD는 주변기기 구성요소 상호 연결 익스프레스(PCIe) 버스에 직접 연결되어 빠른 읽기 및 쓰기 속도를 제공합니다.
- 로컬 NVMe 스토리지는 가장 짧은 지연 시간을 제공합니다.
- 로컬 NVMe 스토리지는 가장 높은 처리량을 제공합니다.
로컬 NVMe 스토리지를 확장하려면 개별 서버에 더 많은 드라이브를 추가해야 합니다. 하지만 개별 서버에 더 많은 드라이브를 추가하면 저장소 풀이 분산되고 관리가 복잡해질 수 있습니다. 로컬 NVMe 스토리지는 여러 서버 간의 데이터 공유를 위해 설계되지 않았습니다. 로컬 NVMe 스토리지는 로컬이므로 서버 관리자는 하드웨어 또는 소프트웨어 저렴한 디스크의 중복 어레이 (RAID)를 사용하여 디스크 오류를 방지해야 합니다. 그렇지 않으면 단일 NVMe 기기의 오류로 인해 데이터가 손실됩니다.
SAN 스토리지
SAN은 여러 서버를 공유 스토리지 기기 풀(일반적으로 SSD 또는 중앙 집중식 NVMe 스토리지)에 연결하는 전용 스토리지 네트워크입니다. SAN은 로컬 NVMe만큼 빠르지는 않지만, 최신 SAN, 특히 Fabrics를 통해 NVMe를 사용하는 SAN은 여전히 대부분의 엔터프라이즈 워크로드에 우수한 성능을 제공합니다.
SAN은 확장성이 뛰어납니다. 저장용량 또는 성능을 추가하려면 새 스토리지 어레이를 추가하거나 기존 어레이를 업그레이드하세요. SAN은 스토리지 레이어에서 중복을 제공하여 스토리지 미디어 장애를 방지합니다.
SAN은 데이터 공유에 탁월합니다. 가용성이 높은 엔터프라이즈 환경의 경우 여러 서버가 SAN에 저장된 데이터에 액세스하고 공유할 수 있습니다. 서버 오류가 발생하면 데이터 센터의 다른 서버에 SAN 스토리지를 표시하여 더 빠르게 복구할 수 있습니다.