ストレージと PVC のサイズを計画する

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

ストレージの枯渇によるデータベースのダウンタイムとデータ損失を防ぐには、AlloyDB Omni データベース クラスタ（DBCluster）のストレージと Persistent Volume Claim（PVC）の容量を適切に計画する必要があります。これらのサイズ設定の推奨事項を使用して、AlloyDB Omni Kubernetes オペレーターを使用して Kubernetes にデプロイするときにボリュームを構成します。

DBCluster カスタム リソースを作成すると、AlloyDB Omni Operator は、次のフィールドで定義したディスクに基づいて Kubernetes PVC をプロビジョニングします。

  • プライマリ インスタンスと高可用性（HA）スタンバイ インスタンス: DBCluster カスタム リソースの spec.primarySpec.resources.disks フィールドで構成されます。spec.availability.numberOfStandbys フィールドを構成して高可用性を有効にすると、各スタンバイ レプリカはプライマリ インスタンスと同じディスク構成を使用します。
  • 読み取りプール インスタンス: 各 DBInstance カスタム リソースの spec.resources.disks で構成されます。ここで、instanceType は ReadPool に設定されます。DBInstance リソースで spec.resources セクションを省略すると、読み取りプール インスタンスは親 DBCluster リソースの spec.primarySpec.resources フィールドからディスク構成を継承します。

サポートされている PVC ボリューム

AlloyDB Omni Operator は、すべての PVC ボリュームを同時にプロビジョニングしません。

  • 常にプロビジョニング: オペレーターは、すべてのプライマリ、HA スタンバイ、読み取りプール データベース インスタンス Pod に対して、常に DataDisk、ObsDisk、BackupDisk、LogDisk をプロビジョニングします。マニフェストで DataDisk とそのサイズを明示的に指定する必要があります。マニフェストで ObsDisk、BackupDisk、LogDisk を指定することは任意です。基本的なインストール マニフェストに示すように、これらのパラメータを省略した場合でも、オペレーターはデフォルトのサイズを使用してこれらの PVC をプロビジョニングします。
  • デフォルトでプロビジョニングされない: スタンドアロンの DBCluster リソースを作成するとき、または Cloud Storage または Amazon S3 にバックアップを保存するときに、オペレータは BackupRepoDisk ボリュームをプロビジョニングしません。バックアップ リポジトリ Pod とその BackupRepoDisk PVC は、Kubernetes クラスタにバックアップをローカルに保存する BackupPlan リソースを作成する場合（つまり、リモート backupLocation フィールドのない BackupPlan リソース）にのみプロビジョニングされます。

次の表に、AlloyDB Omni Operator が管理する永続ボリュームを示します。

ディスク名 マウントパス ターゲット Pod マニフェストの構成 プロビジョニングの動作 目的
DataDisk /mnt/disks/pgsql データベース Pod 必須 各データベース Pod に常にプロビジョニングされます。 PostgreSQL データベース クラスタ ディレクトリ（PGDATA）、テーブル、インデックス、一時ファイル、アクティブな write-ahead log（WAL）セグメントを保存します。
ObsDisk /obs データベース Pod 省略可（デフォルト: 2Gi） 各データベース Pod に常にプロビジョニングされます。 PostgreSQL サーバーログ（postgresql.log）、pgAudit ログ（postgresql.audit）、内部ログ（postgresql.internal）、ローテーションされた .gz ログ アーカイブなどのオブザーバビリティ データを保存します。
BackupDisk /backup データベース Pod 省略可（デフォルト: 10Gi） 各データベース Pod に常にプロビジョニングされます。 データベース Pod のバックアップ オペレーション用のローカル ステージング ディレクトリを提供します。
LogDisk /archive データベース Pod 省略可（デフォルト: 2Gi） 各データベース Pod に常にプロビジョニングされます。 カスタムまたはサードパーティのバックアップ サイドカー専用の WAL アーカイブの宛先を提供します。カスタム WAL アーカイブ サイドカーを使用しない場合は、このディスクをマニフェストから省略して、デフォルトの 2Gi サイズのままにできます。
BackupRepoDisk /backup バックアップ リポジトリ Pod 省略可（デフォルト: 10Gi） デフォルトではプロビジョニングされません。BackupPlan リソースがバックアップをローカルに保存する場合にのみプロビジョニングされます（BackupPlan が構成されていない場合、またはバックアップで Cloud Storage または Amazon S3 が使用されている場合はプロビジョニングされません）。 ローカル ストレージ バックアップを使用する場合に、物理データベース バックアップ、増分バックアップと差分バックアップ、アーカイブされた WAL ファイルを保存する専用ボリュームを提供します。

PVC のサイズ設定に関する推奨事項

次のガイドラインに沿って、ワークロード、ロギング構成、バックアップ戦略に基づいて各 PVC ボリュームのサイズを設定します。

プライマリ データベース ストレージの DataDisk ボリューム

AlloyDB Omni Operator は、すべてのデータベース Pod に DataDisk ボリュームを常にプロビジョニングします。マニフェストでサイズを明示的に指定する必要があります。DataDisk の最小容量を推定するには、次の式を使用します。

DataDisk capacity = (initial_dataset_size + projected_growth + max_wal_size) * 1.30

DataDisk ボリュームのサイズを設定する際は、次の要素を考慮してください。

  • インデックスのオーバーヘッド: PostgreSQL のインデックスとシステム カタログ テーブルでは、通常、テーブルの生データに加えて 20 ～ 50% のストレージが必要です。
  • アクティブな WAL ヘッドルーム: スループットの高い書き込みトランザクションでは、チェックポイントが完了するまで pg_wal ディレクトリに WAL ファイルが蓄積されます。構成した max_wal_size データベース パラメータに対応できる十分なストレージを割り当てます（通常は、ワークロードに応じて数 GB から数十 GB）。max_wal_size などのデータベース パラメータを表示または変更するには、データベース パラメータを構成するをご覧ください。
  • 一時ファイルとバキューム オペレーション: クエリの並べ替え、インデックスの作成、再インデックス作成、自動バキューム オペレーションには、追加の一時ディスク容量が必要です。
  • 一般的なサイジング ルール: データベースの元のサイズの 1.5 ～ 2 倍を割り当てます。これには、少なくとも 30% の安全バッファが含まれます。

診断ログと監査ログ用の ObsDisk ボリューム

AlloyDB Omni Operator は、すべてのデータベース Pod に常に ObsDisk ボリュームをプロビジョニングします（マニフェストで省略した場合は、デフォルト サイズの 2Gi）。ObsDisk ボリュームがいっぱいになると、PostgreSQL は新しいログエントリを書き込むことができず、ログローテーションが停止する可能性があります。ObsDisk ボリュームのログローテーションと保持の設定を構成する方法については、ログローテーションを構成するをご覧ください。

ObsDisk ボリュームのサイズを設定する際は、次のガイドラインを考慮してください。

  • 標準ロギング: デフォルトのログローテーション設定（200 MB のローテーションしきい値と 7 日間の保持）では、標準の運用ロギングに 4 ～ 10 GiB の容量で十分です。
  • 監査ロギング（pgAudit）: pgAudit で監査ロギングを有効にすると、監査ロギングによって生成されるログの量が大幅に増加します。クエリ率と監査ルールの詳細度に応じて、20 GiB から 50 GiB 以上を割り当てます。

ローカル バックアップ リポジトリの BackupRepoDisk ボリューム

データベース Pod ディスクとは異なり、BackupRepoDisk はデフォルトでプロビジョニングされません。AlloyDB Omni Operator は、リモート backupLocation フィールドのない Kubernetes クラスタに バックアップをローカルに保存する BackupPlan リソースを作成した場合にのみ、バックアップ リポジトリ Pod とその BackupRepoDisk PVC をプロビジョニングします。このディスクを DBCluster マニフェストから省略すると、デフォルトのサイズ 10Gi が使用されます。BackupPlan リソースを構成しない場合、または BackupPlan リソースが GCS タイプの Cloud Storage または S3 タイプの Amazon S3 を使用している場合、オペレーターは BackupRepoDisk をプロビジョニングしません。バックアップ プランの構成とバックアップ ストレージのサイズ変更の詳細については、Kubernetes でのバックアップと復元とバックアップ ディスクのサイズを変更するをご覧ください。

バックアップをローカルに保存すると、BackupRepoDisk ボリュームに、圧縮された完全バックアップ、差分バックアップ、増分バックアップと、アーカイブされた WAL ファイルが保存されます。必要な合計ストレージは、データベースのサイズ、1 日のデータ変更率、backupSchedules で定義されたバックアップ スケジュール、backupRetainDays で設定された保持期間によって異なります。

  • バックアップの圧縮: 圧縮されたバックアップは通常、圧縮されていないデータベース サイズの 37 ～ 38% を使用します。これは、サイズが 62 ～ 63% 削減されたことを意味します。たとえば、50 GiB のデータベースは約 18.5 GiB に圧縮されます。
  • バックアップ スケジュールと保持: 週単位の完全バックアップと日単位の増分バックアップまたは差分バックアップを組み合わせると、日単位の完全バックアップを行うよりもストレージの必要量が大幅に少なくなります。

次の表に、100 GiB のデータベースで、1 日あたりのデータ変更率が 10% で、デフォルトの 14 日間の保持期間（backupRetainDays: 14）の場合に、さまざまなバックアップ スケジュールでベンチマークされたピーク ストレージ使用量と推奨される BackupRepoDisk サイズ（20% のバッファを含む）を示します。

バックアップ スケジュール（backupSchedules） ピーク時のフル バックアップ 差分バックアップ 増分バックアップ アーカイブされた WAL ファイル ピーク時のストレージ使用量 推奨される BackupRepoDisk サイズ（+20% のバッファ）
週次完全 + 日次増分 148.0 GiB 0 GiB 66.6 GiB 155.4 GiB 370.0 GiB 444 GiB（データベース サイズの約 4.4 倍）
週次完全 + 週次差分 + 日次増分 148.0 GiB 22.2 GiB 44.4 GiB 155.4 GiB 370.0 GiB 444 GiB（データベース サイズの約 4.4 倍）
週次完全 + 日次差分 148.0 GiB 155.4 GiB 0 GiB 155.4 GiB 458.8 GiB 551 GiB（データベース サイズの約 5.5 倍）
毎日完全バックアップのみ（デフォルトのスケジュール） 592.0 GiB 0 GiB 0 GiB 111.0 GiB 703.0 GiB 844 GiB（データベース サイズの約 8.4 倍）

データベース Pod のバックアップ ステージング用の BackupDisk ボリューム

AlloyDB Omni Operator は、すべてのデータベース Pod に常に BackupDisk ボリュームをプロビジョニングします。デフォルトのサイズは 10 GiB（10Gi）です。AlloyDB Omni は、バックアップ オペレーション中に BackupDisk ボリュームをローカル ステージング ディレクトリとして使用します。デフォルトの 10 GiB のサイズは標準オペレーションに十分であるため、DBCluster マニフェストから BackupDisk を省略してデフォルトのサイズを使用できます。

カスタム WAL アーカイブ用の LogDisk ボリューム

AlloyDB Omni Operator は、すべてのデータベース Pod に LogDisk ボリュームをデフォルト サイズの 2 GiB（2Gi）で常にプロビジョニングします。/archive ディレクトリに WAL ファイルをアーカイブするカスタムまたはサードパーティのサイドカー コンテナをデプロイする場合にのみ、LogDisk ボリュームのカスタム サイズを指定する必要があります。組み込みバックアップを使用する標準の AlloyDB Omni Operator Deployment の場合、DBCluster マニフェストから LogDisk を省略し、デフォルトの 2Gi サイズのままにできます。

データセットのサイズ別のサイズ設定の参考情報

次の表に、一般的な未加工データセット サイズにおすすめの PVC サイズを示します。

元データのサイズ 推奨される DataDisk サイズ 推奨される ObsDisk サイズ 推奨される BackupRepoDisk サイズ（ローカル バックアップ用にのみプロビジョニング） 推奨される BackupDisk サイズ 推奨される LogDisk サイズ
50 GiB 100 GiB 4 GiB（pgAudit を使用する場合は 10 ～ 20 GiB） 150 GiB 10 GiB（デフォルト） 2 GiB（デフォルト）
200 GiB 400 GiB 10 GiB（pgAudit を使用する場合は 20 ～ 50 GiB） 600 GiB 10 GiB（デフォルト） 2 GiB（デフォルト）
500 GiB 1,000 GiB（1 TiB） 15 GiB（pgAudit を使用する場合は 30 ～ 60 GiB） 1,500 GiB（1.5 TiB） 10 GiB（デフォルト） 2 GiB（デフォルト）
1 TiB 2,000 GiB（2 TiB） 20 GiB（pgAudit を使用する場合は 50 ～ 100 GiB） 3,000 GiB（3 TiB） 10 GiB（デフォルト） 2 GiB（デフォルト）

ディスク使用量と I/O 指標をモニタリングする

kubectl を使用するか、AlloyDB Omni によってエクスポートされた Prometheus 指標を収集することで、データベースとバックアップ リポジトリ Pod 内のディスク使用量を直接モニタリングできます。

kubectl を使用してディスク使用量を確認する

データベース Pod とバックアップ リポジトリ Pod 内でマウントされた PVC ボリュームの現在のディスク容量の使用量を確認するには、次のコマンドを実行します。

  1. DBCluster リソースのデータベース Pod の名前を取得します。

    export DB_POD=$(kubectl get pod -n NAMESPACE -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -o jsonpath='{.items[0].metadata.name}')

    次のように置き換えます。

    • NAMESPACE: データベース クラスタがデプロイされている Kubernetes Namespace。
    • DB_CLUSTER_NAME: データベース クラスタの名前。

  2. データベース コンテナ内で df -h を実行して、DataDisk（/mnt/disks/pgsql）、ObsDisk（/obs）、BackupDisk（/backup）、LogDisk（/archive）ボリュームの容量と使用状況を表示します。

    kubectl exec -n NAMESPACE "${DB_POD}" -c database -- df -h /mnt/disks/pgsql /obs /backup /archive

  3. バックアップをローカルに保存するように BackupPlan リソースを構成した場合は、バックアップ リポジトリ Pod の名前を取得し、df -h を実行して BackupRepoDisk ボリューム（/backup）の容量と使用状況を表示します。

    export BACKUP_REPO_POD=$(kubectl get pod -n NAMESPACE -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/backup-repository -o jsonpath='{.items[0].metadata.name}')
kubectl exec -n NAMESPACE "${BACKUP_REPO_POD}" -c backuprepo -- df -h /backup

Prometheus を使用してストレージ指標をモニタリングする

AlloyDB Omni は、al-INSTANCE_ID-DB_CLUSTER_NAME-monitoring-system サービス（ポート 9187）でストレージとディスク I/O の指標をエクスポートします。これらの指標をスクレイピングしてクエリする方法については、AlloyDB Omni をモニタリングするをご覧ください。使用可能な指標の一覧については、AlloyDB Omni の指標をご覧ください。

次のディスク指標をモニタリングします。

  • ストレージの使用量と容量: alloydb_omni_node_storage_usage_per_disk_byte 指標と alloydb_omni_node_storage_limit_per_disk_byte 指標をモニタリングします。これらの指標は、disk ラベル（DataDisk、ObsDisk、BackupDisk など）を使用して、各ボリュームの使用済みストレージと合計容量をバイト単位でレポートします。ディスク使用量が容量の 80% と 90% に達したときにアラートを構成して、容量が不足する前にボリュームを拡張できるようにします。
  • ディスク スループットと I/O オペレーション: ディスクの読み取り / 書き込みスループットの alloydb_omni_node_storage_read_bytes_count_total 指標と alloydb_omni_node_storage_write_bytes_count_total 指標、読み取り / 書き込み I/O オペレーションの alloydb_omni_node_storage_read_ops_count_total 指標と alloydb_omni_node_storage_write_ops_count_total 指標をモニタリングします。

既存の DBCluster の PVC のサイズを変更する

データベース クラスタを作成するに沿って DBCluster リソースをすでに作成している場合、最初のマニフェストでは DataDisk ボリューム（10Gi など）のみが指定されている可能性があります。一方、AlloyDB Omni Operator は、デフォルト サイズで ObsDisk（2Gi）、BackupDisk（10Gi）、LogDisk（2Gi）ボリュームをプロビジョニングしています。これらの PVC は、DBCluster マニフェストを更新することで拡張できます。

PVC のサイズを変更する前に、次の要件と制限事項を確認してください。

  • StorageClass ボリュームの拡張: ディスクのサイズを増やすことができるのは、Kubernetes StorageClass リソースで allowVolumeExpansion: true が設定されている場合のみです。詳細については、永続ボリュームの要求の拡張をご覧ください。
  • 縮小や StorageClass の変更は不可: ディスクサイズを縮小することはできません。また、既存の PVC の storageClass フィールドは、プロビジョニング後に変更できません。
  • デフォルト サイズのディスクのサイズ変更: マニフェストから以前に除外したディスク（ObsDisk ボリュームや BackupRepoDisk ボリュームなど）を拡張するには、そのディスクのエントリを spec.primarySpec.resources.disks フィールドに追加し、size フィールドを現在のデフォルト容量よりも大きくします。マニフェストを更新するときは、DataDisk とその他の既存のディスク エントリを常に disks リストに保持してください。
  • Pod の再起動動作: resources.disks フィールドを変更すると、AlloyDB Omni Operator は基盤となる PVC を更新し、データベース インスタンス Pod を再起動して新しいリソース仕様を適用します。計画的なメンテナンスの時間枠でストレージ拡張を行うか、高可用性を構成してダウンタイムを最小限に抑えます。

DBCluster の PVC を検査してサイズを変更する手順は次のとおりです。

  1. データベース クラスタの名前空間にある PVC を一覧表示して、現在の容量と StorageClass リソースを確認します。

    kubectl get pvc -n NAMESPACE

    NAMESPACE は、DBCluster をデプロイした Namespace（default など）に置き換えます。

    my-db-cluster という名前のクラスタの場合、出力は次のようになります。

    NAME                                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
backupdisk-al-1060-my-db-cluster-0  Bound    pvc-45a28be2-a111-40ed-9641-61b9d25f313b   10Gi       RWO            standard-rwo   10m
datadisk-al-1060-my-db-cluster-0    Bound    pvc-c23a1ab8-f97c-4449-9072-502b6d9ba869   10Gi       RWO            standard-rwo   10m
logdisk-al-1060-my-db-cluster-0     Bound    pvc-f0c41d15-bb13-4d28-b94b-01a28dc67ef6   2Gi        RWO            standard-rwo   10m
obsdisk-al-1060-my-db-cluster-0     Bound    pvc-69ea1ca7-a868-4dc9-a9f8-503d5e5f2387   2Gi        RWO            standard-rwo   10m

  2. PVC で使用されている StorageClass リソースがボリューム拡張をサポートしていることを確認します。

    kubectl get storageclass STORAGE_CLASS_NAME -o jsonpath='{.allowVolumeExpansion}{"\n"}'

    STORAGE_CLASS_NAME は、前の出力の STORAGECLASS 列のストレージ クラス名（standard-rwo など）に置き換えます。コマンドが true を返すことを確認します。

  3. DBCluster マニフェストの spec.primarySpec.resources.disks フィールドを更新して、DataDisk ボリュームの size 値を増やし、拡張する必要があるデフォルト サイズのディスク（ObsDisk ボリュームや BackupRepoDisk ボリュームなど）を追加します。

    次のマニフェストの例では、DataDisk ボリュームを 400Gi に拡張し、ObsDisk ボリュームをデフォルトの 2Gi から 10Gi に拡張し、200 GiB のワークロード用に 600Gi で BackupRepoDisk ボリュームを構成します。

    apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
  name: DB_CLUSTER_NAME
  namespace: NAMESPACE
spec:
  databaseVersion: "18.3.0"
  primarySpec:
    adminUser:
      passwordRef:
        name: db-pw-DB_CLUSTER_NAME
    resources:
      cpu: 4
      memory: 32Gi
      disks:
      - name: DataDisk
        size: 400Gi
        storageClass: STORAGE_CLASS_NAME
      - name: ObsDisk
        size: 10Gi
        storageClass: STORAGE_CLASS_NAME
      - name: BackupRepoDisk
        size: 600Gi
        storageClass: STORAGE_CLASS_NAME

    次のように置き換えます。

    • DB_CLUSTER_NAME: データベース クラスタの名前（例: my-db-cluster）。
    • NAMESPACE: データベース クラスタの Namespace。
    • STORAGE_CLASS_NAME: 永続ボリュームで使用される Kubernetes StorageClass リソースの名前（例: standard-rwo）。クラスタの作成時に storageClass フィールドを省略した場合は、オペレータがクラスタのデフォルトの StorageClass を使用するように、引き続き省略できます。

  4. 更新された DBCluster マニフェストを適用します。

    kubectl apply -f DB_CLUSTER_MANIFEST.yaml

    DB_CLUSTER_MANIFEST は、DBCluster マニフェスト ファイルのパスに置き換えます。

  5. PVC と DBCluster のステータスに拡張されたサイズが反映されていることを確認します。

    kubectl get pvc -n NAMESPACE

    DBCluster リソースの allocatedResources.disks ステータス フィールドを調べることもできます。

    kubectl get dbcluster DB_CLUSTER_NAME -n NAMESPACE -o jsonpath='{.status.primary.allocatedResources.disks}{"\n"}'

    次のように置き換えます。

    • NAMESPACE: データベース クラスタの Namespace。
    • DB_CLUSTER_NAME: データベース クラスタの名前。

コンピューティング リソースとストレージ リソースのサイズ変更の詳細については、Kubernetes ベースのデータベース クラスタのサイズを変更するをご覧ください。

次のステップ