이 문서에서는 컨테이너 런타임을 지원하는 Linux 환경에서 AlloyDB Omni를 실행하기 위해 준비하는 방법을 설명합니다.
AlloyDB Omni 개요는 AlloyDB Omni 개요를 참조하세요.
크기 및 용량
크기와 용량은 AlloyDB Omni 인스턴스의 성능, 안정성, 비용 효율성에 직접적인 영향을 미칩니다. 기존 데이터베이스를 마이그레이션할 때 필요한 CPU 및 메모리 리소스는 소스 데이터베이스 시스템의 요구사항과 유사합니다.
일치하는 CPU, RAM, 디스크 리소스를 사용하는 배포로 시작하고 소스 시스템 구성을 AlloyDB Omni 기준 구성으로 사용합니다. AlloyDB Omni 인스턴스를 충분히 테스트한 후 리소스 소비를 줄일 수 있습니다.
AlloyDB Omni 환경 크기 조정에는 다음 단계가 포함됩니다.
워크로드를 정의합니다.
데이터 볼륨: AlloyDB Omni에 저장할 총 데이터 양을 추정합니다. 현재 데이터와 시간 경과에 따른 예상 증가율을 모두 고려합니다.
트랜잭션 속도: 읽기, 쓰기, 업데이트, 삭제를 포함한 초당 예상 트랜잭션 수(TPS)를 결정합니다.
동시 실행: 데이터베이스에 액세스하는 동시 사용자 또는 연결 수를 추정합니다.
성능 요구사항: 다양한 유형의 쿼리 및 작업에 허용되는 응답 시간을 정의합니다.
하드웨어가 크기 조정 요구사항을 지원하는지 확인합니다.
CPU: AlloyDB Omni는 여러 CPU 코어를 사용하는 시스템에서 이점을 얻을 수 있으며, 워크로드에 따라 선형으로 확장됩니다. 하지만 오픈소스 PostgreSQL은 일반적으로 vCPU가 16개를 초과하는 경우 이점을 얻지 못합니다. 다음 사항을 고려하세요.
- 워크로드 동시 실행 및 컴퓨팅 요구사항에 따른 코어 수
- CPU 세대 또는 플랫폼의 변경으로 인해 발생할 수 있는 이점
메모리: 데이터 캐싱을 위한 AlloyDB Omni의 공유 버퍼와 쿼리 처리를 위한 작업 메모리에 충분한 RAM을 할당합니다. 정확한 요구사항은 워크로드에 따라 다릅니다. vCPU당 8GB의 RAM으로 시작합니다.
스토리지
유형: 필요에 따라 성능을 위한 로컬 NVMe 스토리지를 선택하거나 확장성과 데이터 공유를 위한 SAN 스토리지를 선택합니다.
용량: 데이터 볼륨, 색인, 미리 쓰기 로그(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을 선택합니다.
- 성능과 공유의 균형을 맞춰야 하는 경우 더 빠른 액세스를 위해 NVMe over Fabrics를 사용하는 SAN을 고려합니다.
로컬 NVMe 스토리지
NVMe는 솔리드 스테이트 드라이브(SSD)를 위해 설계된 고성능 프로토콜입니다. 빠른 데이터 액세스가 필요한 애플리케이션의 경우 로컬 NVMe 스토리지는 다음과 같은 이점을 제공합니다.
- NVMe SSD는 Peripheral Component Interconnect Express(PCIe) 버스에 직접 연결되어 빠른 읽기 및 쓰기 속도를 제공합니다.
- 로컬 NVMe 스토리지는 가장 짧은 지연 시간을 제공합니다.
- 로컬 NVMe 스토리지는 가장 높은 처리량을 제공합니다.
로컬 NVMe 스토리지를 확장하려면 개별 서버에 드라이브를 추가해야 합니다. 하지만 개별 서버에 드라이브를 추가하면 스토리지 풀이 조각화되고 관리가 복잡해질 수 있습니다. 로컬 NVMe 스토리지는 여러 서버 간의 데이터 공유를 위해 설계되지 않았습니다. 로컬 NVMe 스토리지는 로컬이므로 서버 관리자는 하드웨어 또는 소프트웨어 Redundant Array of Inexpensive Disks(RAID)를 사용하여 디스크 장애를 방지해야 합니다. 그렇지 않으면 단일 NVMe 기기 오류로 인해 데이터가 손실됩니다.
SAN 스토리지
SAN은 여러 서버를 공유 스토리지 기기 풀(일반적으로 SSD 또는 중앙 집중식 NVMe 스토리지)에 연결하는 전용 스토리지 네트워크입니다. SAN은 로컬 NVMe만큼 빠르지는 않지만 최신 SAN, 특히 NVMe over Fabrics를 사용하는 SAN은 대부분의 엔터프라이즈 워크로드에 여전히 우수한 성능을 제공합니다.
SAN은 확장성이 뛰어납니다. 저장용량이나 성능을 추가하려면 새 스토리지 어레이를 추가하거나 기존 스토리지 어레이를 업그레이드하세요. SAN은 스토리지 레이어에서 중복성을 제공하여 스토리지 미디어 장애를 방지합니다.
SAN은 데이터 공유에 탁월합니다. 높은 가용성이 필요한 엔터프라이즈 환경의 경우 여러 서버에서 SAN에 저장된 데이터에 액세스하고 공유할 수 있습니다. 서버 오류가 발생할 경우 데이터 센터의 다른 서버에 SAN 스토리지를 제공하여 더 빠르게 복구할 수 있습니다.