Aurora PostgreSQL 性能パラメータの検討

はじめに

PostgreSQLの設計・構築を進める中で、性能に関わる各種パラメータについて「どこまで検討すべきか」「どの値をどう決めればよいのか」と悩まれる方も多いのではないでしょうか。

パラメータは数も多く、すべてを網羅的に調整することが必ずしも最適とは限らないため、設計フェーズでの取捨選択が重要になります。

本記事では、システムの詳細設計フェーズや試験フェーズにおいて、性能面でどのような観点を押さえて設計・チューニングを検討すべきかを整理することを目的としています。

単なるパラメータ一覧や設定値の解説ではなく、

· なぜそのパラメータが設計・検討対象になるのか

· どのようなシステム特性や課題がある場合に調整を検討すべきか

といった点を、実務での判断につながる視点でまとめています。

「詳細設計や試験時に、どこに着目してチューニングを考えればよいか」を整理する際の一助となれば幸いです。

対象の読者

PostgreSQL の基本的なアーキテクチャについて一定の理解をお持ちで、パラメータ検討をしようとしている方を対象としています。

具体的には、VACUUM などの各種バックグラウンドプロセスの役割や、SQL の実行プロセス（統計情報、実行計画含む）、メモリ管理の仕組みについて、把握されていることを前提としています。

前提

以下を前提としています。

· DB：Aurora PostgreSQL

· バージョン：PostgreSQL 15.4

· DB用途：オンラインとバッチでの併用

· 拡張機能：以下の性能解析やチューニング時によく用いられる拡張機能を使用

性能に関わる PostgreSQL のパラメータは、Aurora PostgreSQL とオンプレミス／IaaS 上の PostgreSQL では異なる点があります。また、Aurora PostgreSQLにはないパラメータや逆にAurora PostgreSQL特有のパラメータが存在します。

例えば、Aurora PostgreSQL には、オンプレミス／IaaS 上 PostgreSQL のような 従来型のチェックポイント処理が存在しません。

一般的な PostgreSQL では、バッファキャッシュ上で発生した更新（INSERT / UPDATE / DELETE）が、一定間隔のチェックポイント処理によってディスクへ反映されます。一方、Aurora PostgreSQL では、トランザクションの COMMIT ごとに WAL が分散クラスターボリュームへ永続化される仕組みとなっています。そのため、チェックポイント制御を前提としたパラメータ設計は不要になります。

設計が不要なパラメータがある一方で、Aurora PostgreSQL には クラスターキャッシュ管理などのAurora 固有のパラメータ が存在します。これらは、 主にAurora 独自のアーキテクチャや機能に紐づく設定です。

従来のPostgreSQL から共通する知識とともにAurora の機能特性を理解した上で、要件上必要かどうかを判断し、設定値を検討することが必要となります。

また、本番相当の条件での試験を実施し、必要に応じてチューニングすることも重要です。 

以下ではいくつかカテゴリーに分けて、検討すべきパラメータについて説明します。

SQL高速化・実行計画・統計情報

実行計画の選択精度・メモリ使用量・統計情報の鮮度に直接影響するため、ワークロード特性を踏まえた設計が重要となります。

work_mem や並列実行系は瞬間的な負荷増大を許容できるかを前提に調整し、plan_cache_mode や random_page_cost は**実行計画の安定性と環境特性（ストレージ・SQL特性・テーブル構成）を考慮して判断します。

また、default_statistics_target や autovacuum の analyze 系パラメータは、統計情報の精度を見きわめながら設定します。

基本的にヒント句が使用できる環境であれば、統計情報の精度を見きわめつつ、問題のあるSQLには個別にヒント句による実行計画制御を行うような方針でよいかと思います。

ヒント句以外にもAuroraでは、クエリプラン管理（QPM）という機能が使用可能です。SQLに対する実行計画をスナップショットのように取得して、その実行計画を適用させることが可能であり、実行計画を完全固定することも可能です。（ヒント句はあくまで実行計画の誘導であり完全に固定はできない）

実行計画を完全固定化したいなどあれば、QPM使用の検討も必要です。QPMを使用する場合、別途パラメータ設定が必要ですがここでは省略します。

vacuum 関連パラメータは単なる性能チューニングではなく、「更新量・テーブルサイズ・安全性」のバランス設計です。

特に大規模・高更新テーブルでは、デフォルト設定のままでは autovacuum が追いつかず、性能劣化につながる場合もあります。

また、PostgreSQL特有の「XID(トランザクションID)周回問題」の対応としてもvacuum（freeze処理）が用いられています。

特にvacuumのfreeze処理は、処理としては重く、freeze処理を伴うautovacuumがオンラインピークと重なった際に、性能問題となる可能性があります。

本番環境では、テーブル特性ごとの個別調整と、autovacuum と手動 vacuum の役割分離を前提に設計することが重要です。

PostgreSQLにおける性能設計では、「処理を速くかつ安定させる設計」とともに、「遅くなった理由を後から説明できる設計」が重要です。

各種ログ・統計パラメータを目的別に整理して有効化することで、性能試験や本番での性能問題発生時にも、構造的にアプローチできるようにします。

Aurora では、 性能・負荷・待機イベントを横断的に可視化・分析するためのツールとして、Database Insightsを使用することが可能です。

DB視点で「何がボトルネックか」を素早く把握できるようにしたサービスとなっていて、Standardモード、Advancedモードが選択できます。

Standardモード（デフォルトの無料版）とAdvancedモード（有料版）で、取得できる情報が異なり、ログを追加取得する必要があるかはモードによって異なります。そのため、下記の各種ログ・統計パラメータは、Database Insightsの設定モードと一緒に検討することが望ましいです。

（下記内容はStandardモード前提で記載）

不要なクエリや接続・セッションを早期に検知・解消して、リソース安定と性能問題を未然に防ぐこと目的に設定しておくことが重要です。

その他として、以下のパラメータも併せて検討します。

※補足

Aurora PostgreSQL では、インスタンスタイプに応じて 内部的に動的に調整されるパラメータ（max_connections、shared_buffers、max_parallel_workers等） が存在します。これらは Aurora のアーキテクチャと選択したインスタンスクラスを前提に最適化されており、通常はユーザーが個別に調整する必要はありません。そのため、本検討では 原則としてチューニング対象から除外しています。ただし、ワークロード特性や明確な性能課題がある場合には、この限りではなく、意図的に変更を検討する余地はあります。

PostgreSQLの性能は、インスタンスサイズやストレージ性能だけでなく、vacuum処理 や並列実行、プラン管理系パラメータなど設計・運用フェーズでのチューニングによって大きく左右されます。

一方で、ワークロードやシステム構成に合わない設定は、期待した効果が得られないばかりか、逆に性能劣化を招くケースも少なくありません。

そのためには、ワークロードに応じた適切な設計と本番同等のシナリオ及びデータでの検証およびチューニングが重要です。

弊社では、

· PostgreSQL全般の設計・サイジング

· オンプレミス／クラウド環境における性能設計・チューニング支援

· 既存DBからのPostgreSQL移行（設計・検証・移行作業）

· 移行後の性能課題の調査・改善

といった領域まで幅広くご支援しています。

PostgreSQLでお困りの際は、是非当社までご相談ください。