I/O アクセラレーションを使用して AlloyDB Omni のパフォーマンスを向上させる

ドキュメントのバージョンを選択してください。

プレビュー版 - AlloyDB Omni

この機能は、サービス固有の規約の「一般サービス規約」セクションの「一般提供前サービス規約」の対象となります。お客様はこの機能の個人データを Cloud のデータ処理に関する追加条項に記載されているとおりに処理できます。ただし、Google Cloud へのアクセスに関する契約に記載されている義務と制限事項が適用されます。一般提供前の機能は「現状のまま」で提供されるものであり、サポートが制限されることがあります。詳細については、リリースステージの説明をご覧ください。

このページでは、AlloyDB Omni で I/O アクセラレーション機能セットを有効にして、コンピューティングリソースと I/O リソースの使用率を改善し、ワークロードとクエリのパフォーマンスを向上させる方法について説明します。

利用可能な機能は次のとおりです。

Torn Write Prevention
O_DIRECT サポート
非同期 I/O（AIO）
ストリーミング読み取り

これらの I/O 高速化機能を有効にするには、alloydb_omni_atomic Grand Unified Configuration（GUC）を有効にして、GUC を使用できるように AlloyDB Omni を設定します。

I/O アクセラレーション機能

以降のセクションでは、alloydb_omni_atomic GUC で利用できる I/O アクセラレーション機能について説明します。

Torn Write Prevention

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 は、1 つのプロシージャ呼び出しで複数のバッファからデータを取得できる方法です。これにより、コンテキストスイッチとシステム呼び出しが減り、効率が向上します。

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 高速化機能を使用して、Torn Write Prevention によるパフォーマンスの向上をテストするには、alloydb_omni_atomic Grand Unification Configuration（GUC）を有効にします。この 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 を完全にサポートしながら 8 KiB のブロックをアトミックに書き込むことができます。
1. ブロックサイズが 8 KiB の XFS ファイルシステムを作成し、目的のデータディレクトリ（DATA_DIR）にマウントします。
```
sudo mkfs.xfs -f -b size=8k /dev/$DEVICE
sudo mount /dev/$DEVICE DATA_DIR
```
  次のように置き換えます。
  - DATA_DIR: データディレクトリの場所。
2. カーネルログを調べて、8,000 ブロックが使用されていることを確認します。
```
> 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 オペレーション（データの読み取りまたは書き込み）を実行するためにやり取りするエンティティ。
プライマリストレージで 1 秒あたりの入出力オペレーション数（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 の速度が低下します。データベースの復元（REDO パス）、バキュームスキャン、Omni ディスクキャッシュのプレウォーミング中に読み取り速度が低下することがあります。
読み取りレプリカの AlloyDB Omni I/O 高速化機能は、プレビュー版でサポートされていません。
負荷の高いワークロードでは、アーキテクチャの違いにより、ARM ベースのシステムのパフォーマンスが低下する可能性があります。
ワークロードの増加に対する制限により、libaio はリソースの使用不可の影響を受けやすくなります。io_uring では、使用可能なシステムメモリが不足している場合にメモリ割り当ての問題が発生することがあります。