G-gen の今村です。オンプレミスの PostgreSQL から Cloud SQL for PostgreSQL への移行において、postgresql.conf の設定をどのように扱うべきか、マネージドサービスの仕様に基づくパラメータの分類と代替手法を解説します。

概要

Cloud SQL for PostgreSQL をデータベースとして採用する場合や、オンプレミスの PostgreSQL から Cloud SQL for PostgreSQL への移行を検討する際、データベース管理者が直面するのが postgresql.conf で定義するパラメータの扱いです。

Cloud SQL はフルマネージドサービスであるため、OS やインフラストラクチャの運用から解放される半面、すべてのパラメータを自由に設定できるわけではありません。また、設定できる項目とそうでない項目は、Cloud SQL の仕様によってあらかじめ決まっています。

当記事では、オンプレミス版（オープンソース版）の PostgreSQL でよく使用されるパラメータを例に挙げて、それらが Cloud SQL 版では Google が管理するパラメータ（サービスが管理するためユーザー側で設定が不可のパラメータ）とユーザーが管理するパラメータのどちらに分類されるかを解説します。あわせて、設定がサポートされていないパラメータの代替手法についても紹介します。

Cloud SQL の基本的な知識については、以下の記事を参照してください。

blog.g-gen.co.jp

データベースフラグの概要

データベースフラグとは

オンプレミス環境では、PostgreSQL のシステム全体の設定は主に postgresql.conf ファイルで管理します。しかし、Cloud SQL ではマネージドサービスの性質上、このファイルを直接編集できません。

代わりに、Cloud SQL ではデータベースフラグを使用してパラメータを設定します。データベースフラグは MySQL や SQL Server でも同様にサポートされていますが、当記事では PostgreSQL を例に解説します。

参考 : データベースフラグを構成する

フラグ設定時の注意点

データベースフラグを構成する際、以下の2点に注意する必要があります。

1つ目は、サポートされる値や範囲の違いです。各フラグについて、Cloud SQL でサポートされる値や範囲が、対応する PostgreSQL のパラメータやオプションと異なる場合があります。

2つ目は、再起動の発生です。すでに起動しているデータベースインスタンスに対してフラグを設定、変更、または削除すると、インスタンスの再起動が必要になる場合があります。稼働中のシステムに変更を加える際は、ダウンタイムに留意してください。

参考 : データベースフラグを構成する - サポートされているフラグ

設定値の確認と更新

パラメータの確認

Google Cloud コンソールから、現在インスタンスに設定されているデータベースフラグの一覧を確認できます。該当インスタンスの概要ページを開き、データベースフラグのセクションを確認します。

参考 : データベースフラグを構成する - インスタンスに設定されているデータベースフラグを確認する

また現在の設定値は、psql クライアントなどでインスタンスにログインし、以下の SQL 文を実行することでも確認可能です。

SELECT name, setting FROM pg_settings;

参考 : データベースフラグを構成する - データベースフラグの現在の値を表示する

パラメータの更新

Google Cloud コンソールや gcloud コマンドを使用して変更を行います。

システム全体に影響を与えるパラメータの多くは、このデータベースフラグを通じて設定が可能です。

gcloud コマンドでは、以下のようにフラグ名と値を対応させて実行します。

gcloud sql instances patch INSTANCE_NAME \
    --database-flags=FLAG1=VALUE1,FLAG2=VALUE2

参考 : データベースフラグを構成する - データベースフラグを設定する

Google が管理するパラメータ

前提と注意点

当セクションで紹介する「Google が管理するパラメータ」は、Cloud SQL では Google が完全に管理しており、ユーザー側で設定できないものです。これらはデータベースフラグとしてサポートされていません。

なお、当セクションで紹介するパラメータは、よく用いられる設定のごく一部です。実際には、システム要件と公式ドキュメントを照らし合わせ、事前に十分なパラメータ設計を行ってください。

ネットワークと接続管理

オンプレミスでは必須となる listen_addresses や port の設定は、Google Cloud では不要です。

Cloud SQL では、PostgreSQL の標準ポート（5432）が固定で使用されます。アクセス制御は pg_hba.conf を編集するのではなく、VPC ネットワークピアリングや承認済みネットワークなど、Google Cloud のネットワーク機能を使用して管理します。

VPC についての詳細は、以下の記事を参照してください。

blog.g-gen.co.jp

ログ管理

log_destination、logging_collector、log_file_mode などのログファイルの出力先やローテーションに関する設定もマネージドサービスで代替可能です。

Cloud SQL のログは自動的に Cloud Logging に統合されます。ログの検索、監視などはデータベース側で行うのではなく、Google Cloud のオブザーバビリティ機能を使用して行います。

参考 : インスタンスのログを表示する

Cloud Logging についての詳細は、以下の記事を参照してください。

blog.g-gen.co.jp

ハードウェア依存の設定

dynamic_shared_memory_type などの OS やハードウェア基盤に強く依存するパラメータは設定できません。これらは Cloud SQL の基盤側で自動的に最適化されるため、ユーザーが意識する必要はありません。

参考 : マシンシリーズを選択する

ユーザーが管理するパラメータ

前提と注意点

当セクションで紹介する「ユーザーが管理するパラメータ」は、Cloud SQL に移行した後でも、引き続きユーザー側でチューニングや設定を行う必要があるパラメータです。

当セクションで紹介するパラメータは例示であり、ごく一部です。実際には、システム要件を考慮し、どのパラメータに対してフラグや代替手段を用いた設定が必要になるのかを、公式ドキュメントと照らし合わせて十分に精査してください。

パフォーマンスチューニングフラグ

max_connections、shared_buffers、maintenance_work_mem など、データベースのパフォーマンスに直結する重要なパラメータの多くが、データベースフラグとしてサポートされています。

なお、一部のフラグ（max_connections や max_worker_processes など）は、インスタンスのメモリサイズに応じて上限値やデフォルト値が自動的にスケーリングする仕様になっています。オンプレミスの設定値をそのまま移行するのではなく、自動設定されるデフォルト値を確認し、マネージドサービスへ設定を委譲できるかを評価してください。