이 페이지에서는 16.8.0 배포 옵션을 사용하여 AlloyDB Omni 버전 16.8.0을 설명합니다. 다른 배포 옵션을 선택합니다.

I/O 가속을 사용하여 AlloyDB Omni 성능 개선

문서 버전을 선택합니다.

이 페이지에서는 AlloyDB Omni에서 컴퓨팅 및 I/O 리소스 사용률을 개선하여 워크로드와 쿼리 성능을 높이는 데 도움이 되는 I/O 가속 기능 세트를 사용 설정하는 방법을 설명합니다.

포함된 기능은 다음과 같습니다.

잘린 쓰기 보호
O_DIRECT 지원
비동기 I/O(AIO)
스트리밍 읽기

이러한 I/O 가속 기능을 사용 설정하려면 alloydb_omni_atomic GUC(Grand Unified Configuration)를 사용 설정하고 AlloyDB Omni가 GUC를 사용할 수 있도록 설정합니다.

I/O 가속 기능

다음 섹션에서는 alloydb_omni_atomic GUC가 지원하는 I/O 가속 기능에 대해 설명합니다.

잘린 쓰기 보호

alloydb_omni_atomic 구성을 사용 설정할 때 전체 페이지 쓰기를 사용 중지하여 로깅을 위해 전체 페이지 이미지를 생성하는 성능 오버헤드를 방지합니다.

O_DIRECT 지원

O_DIRECT 지원은 원자적 쓰기를 위한 기본 요건입니다. O_DIRECT는 PostgreSQL 데이터 디렉터리 및 AlloyDB Omni 디스크 캐시에 적용됩니다. 자세한 내용은 디스크 캐시를 사용하여 데이터베이스 성능 가속화를 참조하세요.

또한 O_DIRECT는 다음 이점을 제공합니다.

O_DIRECT를 사용하면 PostgreSQL에서 이중 버퍼링 문제를 방지할 수 있습니다. PostgreSQL은 자체 버퍼 캐시를 관리하며 운영체제 커널 버퍼 캐시를 우회할 수 있습니다.
O_DIRECT는 커널 버퍼 캐시를 유지하는 데 필요한 운영체제의 CPU 및 메모리 오버헤드를 줄여줍니다.

비동기 I/O

alloydb_omni_atomic 구성은 io_uring 및 libaio 라이브러리를 사용하여 비동기 I/O(AIO) 기능을 제공합니다. 이전 libaio 라이브러리의 제한사항을 피하려면 io_uring를 사용하는 것이 좋습니다. io_uring 지원이 감지되지 않으면 AlloyDB Omni가 libaio로 대체됩니다. 이러한 방식은 미리 읽기 및 쓰기 결합과 같은 버퍼링된 I/O의 이점이 사라지는 문제를 보완하며, 기본 스토리지에서 제공되는 I/O 대역폭을 최대한 활용할 수 있도록 보장합니다.

스트리밍 읽기

AlloyDB Omni는 PostgreSQL 17 기능과 유사한 스트리밍 읽기를 사용하여 여러 블록을 벡터 I/O로 버퍼 캐시에 읽어 들임으로써 순차 스캔, ANALYZE, pg_prewarm 성능을 향상시킵니다. 벡터화된 I/O는 단일 프러시저 호출이 여러 버퍼에서 데이터를 프리패치할 수 있는 방법으로, 컨텍스트 전환과 시스템 호출을 줄여 효율성을 개선합니다.

AlloyDB Omni는 AIO를 통해 AlloyDB Omni 디스크 캐시에서의 읽기에 스트리밍 읽기를 사용하여 읽기 성능을 증폭하도록 지원을 확장합니다. 이 접근 방식을 사용하면 필요할 때마다 스토리지에서 이러한 블록을 읽는 대신 쿼리가 사용할 수 있도록 스토리지에서 공유 메모리 풀로의 효과적인 버퍼 미리 읽기를 촉진합니다.

시작하기 전에

운영체제 및 파일 시스템의 지원 상태를 확인합니다.
1. 커널이 RWF_ATOMIC을 지원하는지 확인하려면 커널 버전을 점검하세요. 다음 예시에서는 원자적 쓰기를 지원하는 Linux 6.14 커널을 실행하는 Ubuntu 24.10 머신을 사용하고 있습니다.
```
> sudo hostnamectl
 ...
 Operating System: Ubuntu 24.10
      Kernel: Linux 6.14.0-061400rc5-generic
...
```
2. 커널이 RWF_ATOMIC을 지원하지 않는 경우 RWF_ATOMIC을 지원하는 커널 버전으로 업데이트하는 것이 좋습니다.

AlloyDB Omni I/O 가속 기능을 사용하여 잘린 쓰기 보호를 통한 성능 향상을 테스트하려면 alloydb_omni_atomic GUC(Grand Unification Configuration)를 사용 설정하세요. 이 GUC를 사용하려면 원자적 I/O를 제공하고 잘린 쓰기를 방지하는 지원 커널과 파일 시스템이 있어야 합니다.

RWF_ATOMIC 플래그는 원자적 쓰기를 지원하기 위해 사용됩니다. 기본적으로 RWF_ATOMIC 호환성은 시작 시점에 확인됩니다. RWF_ATOMIC 플래그를 사용한 원자적 쓰기 지원이 확인되지 않으면 PostgreSQL이 시작되지 않습니다.

이 기본 동작을 재정의할 수는 있지만, 최적의 구성 설정을 실수로 재정의하지 않도록 지원되는 플랫폼을 사용하고 force 옵션을 사용하는 것이 좋습니다.

force_unsafe 옵션을 사용하면 RWF_ATOMIC 호환성 검사를 재정의할 수 있지만, 이 방식을 사용할 경우 데이터 보안이 보장되지 않습니다. 적절한 커널과 파일 시스템을 사용할 수 있도록 업그레이드할 수 없는 환경에서 AlloyDB Omni를 평가하는 경우가 아니라면 이 옵션을 사용하지 않는 것이 좋습니다.

다음 표에서는 alloydb_omni_atomic 구성 설정과 해당 호환성 검사 항목을 보여줍니다.

`alloydb_omni_atomic` 값	시작 호환성 검사	설명
off	해당 사항 없음	이 값은 원자적 모드를 사용 중지합니다. 기능이 비활성 상태가 됩니다.
force	시작 시 호환성 검사를 수행합니다. `RWF_ATOMIC` 쓰기가 실패하면 시작할 수 없습니다.	원자적 모드 구성을 설정합니다.
force_unsafe	시작 시 호환성 검사를 수행하지 않습니다. `RWF_ATOMIC` 쓰기가 실패하면 경고를 반환하지만 실행은 계속됩니다.	원자적 모드 구성을 설정합니다.

force/force_unsafe 구성에서는 full_page_writes, io_combine_limit, debug_io_direct 구성이 자동으로 설정됩니다. 이러한 설정은 선택적으로 제공되는 on/on_unsafe 구성을 사용하여 재정의할 수 있습니다.

AlloyDB Omni I/O 가속 기능 설정

데이터 디렉터리에 사용할 XFS 파일 시스템을 설정합니다. XFS가 사용되는 이유는 페이지 크기보다 큰 파일 시스템 블록 크기를 지원하기 때문입니다. AlloyDB Omni는 XFS를 사용하여 RWF_ATOMIC을 완전히 지원하는 8KiB 블록을 원자적으로 기록할 수 있습니다.
1. 블록 크기가 8KiB인 XFS 파일 시스템을 만들고 원하는 데이터 디렉터리(DATA_DIR) 위치에 마운트합니다.
```
sudo mkfs.xfs -f -b size=8k /dev/$DEVICE
sudo mount /dev/$DEVICE DATA_DIR
```
  다음과 같이 바꿉니다.
  - DATA_DIR: 데이터 디렉터리 위치
2. 커널 로그에서 8k 블록이 사용되는지 확인하세요.
```
> sudo journalctl -f
...
kernel: XFS (sdc): EXPERIMENTAL large block size feature enabled.  Use at your own risk!
kernel: XFS (sdc): Mounting V5 Filesystem 350aa26a-7555-4566-94c1-74e54ddc9250
...
```
(선택사항) AlloyDB Omni 디스크 캐시를 설정합니다.

다음 예시를 사용하여 ext4, 파일 시스템을 만든 후 해당 파일 시스템을 마운트하세요.
```
sudo /sbin/mkfs.ext4 -m 1 -F -E lazy_itable_init=0,lazy_journal_init=0 /dev/DEVICE
sudo mount --make-shared -o noatime,discard,errors=panic /dev/DEVICE /OMNI_DISK_CACHE_DIRECTORY
```
다음과 같이 바꿉니다.
- DEVICE: 애플리케이션이 I/O 작업(데이터 읽기 또는 쓰기)을 수행하기 위해 상호작용하는 항목
기본 스토리지가 더 높은 초당 입출력 작업 수(IOPS)를 제공하지 않는 경우 AlloyDB Omni I/O 가속 기능의 최적 성능을 지원하려면 AlloyDB Omni 디스크 캐시를 설정하는 것이 좋습니다. 자세한 내용은 디스크 캐시를 사용하여 데이터베이스 성능 가속화를 참조하세요.

참고: 캐시의 데이터는 일시적이므로 디스크 캐시가 원자적 쓰기를 지원하지 않아도 됩니다. 하지만 AlloyDB Omni I/O 가속 기능은 캐시에 액세스할 때 여전히 O_DIRECT를 사용합니다.
AlloyDB Omni를 다운로드하고 실행합니다.
1. 최신 AlloyDB Omni Docker 컨테이너를 다운로드합니다. 자세한 내용은 VM에 AlloyDB Omni 설치를 참조하세요.
2. 디스크 캐시를 사용하려면 디스크 캐시를 사용하여 데이터베이스 성능 가속 안내를 따르세요.
3. io_uring을 허용하려면 --security-opts="seccomp:unconfined" 인수를 추가하세요.
```
docker run -d --name CONTAINER_NAME \
   -e POSTGRES_PASSWORD=NEW_PASSWORD \
   -v DATA_DIR:/var/lib/postgresql/data \
   -v /OMNI_DISK_CACHE_DIRECTORY:/CACHE_DIRECTORY_PATH_INSIDE_CONTAINER \  # Only if disk cache is enabled
   -p HOST_PORT:5432 \
   --security-opts="seccomp:unconfined" \
   --restart=always \
   google/alloydbomni:16
```
  다음을 바꿉니다.
  - CONTAINER_NAME: 호스트 머신의 컨테이너 레지스트리에 있는 AlloyDB Omni 컨테이너의 이름
  - NEW_PASSWORD: 컨테이너의 PostgreSQL 사용자에게 할당된 비밀번호
  - DATA_DIR: 데이터 디렉터리 위치입니다.
  - CACHE_DIRECTORY_PATH_INSIDE_CONTAINER: 컨테이너 내부의 디스크 캐시 디렉터리 경로
  - HOST_PORT: 컨테이너가 자체 포트 5432를 게시해야 하는 호스트 머신의 TCP 포트
원자적 I/O를 사용하도록 AlloyDB Omni를 구성합니다.

alloydb_omni_atomic GUC를 적절한 값으로 설정한 뒤 컨테이너를 다시 시작합니다.
```
alter system set alloydb_omni_atomic='force';
sudo docker restart CONTAINER_NAME;
```
다음을 바꿉니다.
- CONTAINER_NAME: 호스트 머신의 컨테이너 레지스트리에 있는 AlloyDB Omni 컨테이너의 이름

제한사항

PostgreSQL 16에는 단일 블록 I/O를 수행하는 경로가 포함되며, O_DIRECT는 이러한 경로의 성능을 저하시킬 수 있습니다. 데이터베이스 복구(재실행 경로), 배큠 스캔, Omni 디스크 캐시 가동 준비 중에 읽기 속도가 느려질 수 있습니다.
프리뷰에서는 읽기 복제본에서 AlloyDB Omni I/O 가속 기능이 지원되지 않습니다.
워크로드 부하가 많은 환경에서는 아키텍처 차이로 인해 ARM 기반 시스템의 성능이 저하될 수 있습니다.
libaio는 워크로드 증가에 대한 제한사항으로 인해 리소스를 사용할 수 없는 문제가 발생할 수 있습니다. 또한 사용 가능한 시스템 메모리가 부족해지면 io_uring에서도 메모리 할당 문제가 발생할 수 있습니다.