ディスクキャッシュを使用してデータベースのパフォーマンスを高速化する

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

このページでは、AlloyDB Omni でディスクキャッシュをプロビジョニング、設定、使用して、AlloyDB Omni のパフォーマンスを向上させる方法について説明します。

AlloyDB Omni ディスクキャッシュでは、標準の PostgreSQL インメモリ共有バッファに加えて、ソリッドステートドライブ（SSD）などの高速ストレージをバッファとして使用できます。ディスクキャッシュを使用すると、データディレクトリが低速なストレージにある AlloyDB Omni インストールでデータの取得が高速化されます。

PostgreSQL の共有バッファと同様に、AlloyDB Omni ディスクキャッシュは永続的ではありません。つまり、キャッシュに保存されたデータは再起動時に失われます。

デフォルトでは、AlloyDB Omni ディスクキャッシュはファイルシステムから報告されたすべてのストレージを使用します。データキャッシュに予約するストレージの量は、omni_disk_cache_file_size パラメータで定義できます。

AlloyDB Omni ディスクキャッシュを有効にする

AlloyDB Omni のディスクキャッシュを有効にする手順は、AlloyDB Omni をコンテナで実行するのか、Kubernetes クラスタで実行するかによって異なります。

汎用ボリュームでディスクキャッシュを有効にする

汎用ボリュームを使用してディスクキャッシュを有効にできます。

AlloyDB Omni Kubernetes オペレーターで汎用ボリュームのディスクキャッシュを有効にするには、事前に準備した永続ボリュームと storageClass が必要です。

たとえば、GKE を使用しているときに永続ボリュームと storageClass が準備できていない場合は、汎用ボリュームでディスクキャッシュを有効にする前に、次のことが完了していることを確認してください。

ローカル SSD ベースのストレージを使用するクラスタを作成する。
ローカルボリュームの静的プロビジョナーを実行するの手順 1 で、ボリュームを ext4 ファイルシステムにフォーマットする。
ストレージデバイス上の永続ストレージを定義する storageClass を使用して、クラスタ内の SSD ごとに永続ボリュームを手動で作成する。

データベースの汎用ボリュームでディスクキャッシュを有効にするには、次の操作を行います。

データベースクラスタマニフェストを変更して、spec セクションの features セクションに ultraFastCache 属性を追加します。
```
      apiVersion: alloydbomni.dbadmin.goog/v1
      kind: DBCluster
      metadata:
        name: CLUSTER_NAME
      spec:
        databaseVersion: "17.5.0"
        primarySpec:
          features:
            ultraFastCache:
              cacheSize: DISK_CACHE_SIZE
              genericVolume:
                storageClass: "STORAGE_CLASS_NAME"
      ...
      
```
次のように置き換えます。
- DB_CLUSTER_NAME: データベースクラスタの名前。これは、作成時に宣言したデータベースクラスタ名と同じです。
- DISK_CACHE_SIZE: キャッシュのサイズ（例: 100Gi）。shared_buffers よりも大きい値にしてください。このフィールドは省略可能です。このフィールドの値を指定しない場合、AlloyDB Omni はディスク上の残りのスペースをすべて使用します。これは、コンテナ内の AlloyDB Omni と Kubernetes クラスタの両方に適用されます。
- STORAGE_CLASS_NAME: 超高速キャッシュボリュームの storage class の名前。例: local-storage
マニフェストを再度適用します。

ローカルボリュームでディスクキャッシュを有効にする

ローカルボリュームを使用する場合は、永続ボリュームを作成する必要はありません。代わりに、次の最適化を行うことができます。

たとえば、GKE を使用しているときに永続ボリュームと storageClass が準備できていない場合は、ローカルボリュームでディスクキャッシュを有効にする前に、次のことが完了していることを確認してください。

ローカル SSD ベースのストレージを使用するクラスタを作成する。
ローカルボリュームの静的プロビジョナーを実行するの手順 1 で、ボリュームを ext4 ファイルシステムにフォーマットする。

データベースのローカルボリュームでディスクキャッシュを有効にするには、次の操作を行います。

データベースクラスタマニフェストを変更して、spec セクションの features セクションに ultraFastCache 属性を追加します。
```
    apiVersion: alloydbomni.dbadmin.goog/v1
    kind: DBCluster
    metadata:
      name: CLUSTER_NAME
    spec:
      databaseVersion: "17.5.0"
      primarySpec:
        features:
          ultraFastCache:
            cacheSize: DISK_CACHE_SIZE
            localVolume:
              path: "LOCAL_VOLUME_PATH"
              nodeAffinity:
                required:
                  nodeSelectorTerms:
                  - matchExpressions:
                    - key: "LABEL_KEY"
                      operator: "OPERATOR_VALUE"
                      values:
                      - "LABEL_KEY_VALUE"
    ...
      
```
次のように置き換えます。
- CLUSTER_NAME: データベースクラスタの名前。これは、作成時に宣言したデータベースクラスタ名と同じです。
- DISK_CACHE_SIZE: キャッシュのサイズ（例: 100Gi）。shared_buffers よりも大きい値にしてください。このフィールドは省略可能です。このフィールドの値を指定しない場合、AlloyDB Omni はディスク上の残りのスペースをすべて使用します。これは、コンテナ内の AlloyDB Omni と Kubernetes クラスタの両方に適用されます。
- STORAGE_CLASS_NAME: ストレージクラスの名前。
- LOCAL_VOLUME_PATH: ローカルボリュームのパス。例: /mnt/disks/raid/0
- LABEL_KEY: ロケーションインジケーターとして機能し、クラスタ全体に Pod を均等に分散するキーのノードラベル。例: cloud.google.com/gke-local-nvme-ssd
- OPERATOR_VALUE: キーと値のセットの関連付け（例: In）。パラメータは次のいずれかに設定します。
  - In: values 配列は空にできません。
  - NotIn: values 配列は空にできません。
  - Exists: values 配列は空にする必要があります。
  - DoesNotExist: values 配列は空にする必要があります。
  - Gt: values 配列には、整数として解釈される単一の要素が必要です。
  - Lt: values 配列には、整数として解釈される単一の要素が必要です。
- LABEL_KEY_VALUE: ラベルキーの値（例: true）。次のように、パラメータに文字列値の配列を設定します。
  - 演算子が In または NotIn の場合、値の配列は空にできません。
  - 演算子が Exists または DoesNotExist の場合、値の配列は空にする必要があります。
  - 演算子が Gt または Lt の場合、値の配列には整数として解釈される単一の要素が必要です。
マニフェストを再度適用します。

エフェメラルボリュームでディスクキャッシュを有効にする

emptyDir ボリュームを使用してディスクキャッシュを有効にできます。このボリュームは、Pod のライフサイクルに直接関連付けられた一時ストレージを提供します。ボリュームは、Pod がノードに割り当てられたときに作成され、Pod がそのノードで実行されている限り存続します。

Pod がノードから削除されると、emptyDir のデータは完全に削除されます。このタイプのボリュームは、一時的な高速ストレージを提供するため、キャッシュに適しています。Pod が再スケジュールされた場合、キャッシュ内のデータを永続化する必要はありません。

データベースの一時ボリュームでディスクキャッシュを有効にするには、次の操作を行います。

データベースクラスタマニフェストを変更して、spec セクションの features セクションに ultraFastCache 属性を追加し、emptyDirVolume を指定します。
```
      apiVersion: alloydbomni.dbadmin.goog/v1
      kind: DBCluster
      metadata:
        name: CLUSTER_NAME
      spec:
        databaseVersion: "17.5.0"
        primarySpec:
          features:
            ultraFastCache:
              cacheSize: DISK_CACHE_SIZE
              emptyDirVolume: {}
        ...
      
```
次のように置き換えます。
- CLUSTER_NAME: データベースクラスタの名前。これは、作成時に宣言したデータベースクラスタ名と同じです。
- DISK_CACHE_SIZE: キャッシュのサイズ（例: 200Gi）。
  重要: emptyDir ボリュームを使用する場合は、cacheSize を指定する必要があります。サイズが指定されていない場合、キャッシュはノードのディスクで使用可能なすべての容量を消費する可能性があります。このディスクは、そのノードで実行されているすべての Pod で共有されるため、ノードで問題が発生する可能性があります。
マニフェストを再度適用します。

注: emptyDir ボリュームは Pod のスケジューリングに影響しません。Pod 仕様でノードアフィニティルールを使用して、Pod が SSD などの高速ストレージメディアでバックアップされたノードにスケジュールされていることを確認する必要があります。

ディスクキャッシュの構成を確認する

AlloyDB Omni ディスクキャッシュを有効にしたら、iotop や iostat などの利用可能なユーティリティを使用してディスクへの読み取り / 書き込みアクティビティをモニタリングし、ディスクキャッシュにアクセスされていることを確認します。

また、AlloyDB Omni ディスクキャッシュが開いているかどうかを確認することもできます。

AlloyDB Omni のディスクキャッシュ構成を確認するには、次のコマンドを使用します。

  kubectl exec -i $DATABASE_POD -c database -n $DBCLUSTER_NAMESPACE -- cat /obs/diagnostic/postgresql.log | grep "opened omni disk cache"

ディスクキャッシュが正しく構成されている場合、ログに Successfully opened omni disk cache ... メッセージが記録されます。

ディスク キャッシュを使用してデータベースのパフォーマンスを高速化する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

AlloyDB Omni ディスク キャッシュを有効にする

汎用ボリュームでディスク キャッシュを有効にする

ローカル ボリュームでディスク キャッシュを有効にする

エフェメラル ボリュームでディスク キャッシュを有効にする

ディスク キャッシュの構成を確認する

次のステップ