Cloud SQL PostgreSQLのlog_statement_statsの設定について

2025.08.15

このブログシリーズ「クラウドセキュリティ実践集」では、一般的なセキュリティ課題を取り上げ、「なぜ危険なのか？」というリスクの解説から、「どうやって直すのか？」という具体的な修復手順（コンソール、gcloud CLI、Terraformなど）まで、分かりやすく解説します。

この記事では、Cloud SQL PostgreSQLインスタンスでlog_statement_statsパラメータが有効化されている問題について、リスクと対策を解説します。

ポリシーの説明

Cloud SQLのPostgreSQLインスタンスにおける「log_statement_stats」パラメータは、各SQLステートメントの実行統計情報をログに出力する機能を制御します。このパラメータは、より詳細な統計情報を提供する包括的な設定で、log_parser_stats、log_planner_stats、log_executor_statsを個別に有効化した場合と同等の効果があります。

デフォルト値は「off」で、本番環境では無効化することが強く推奨されます。このパラメータが有効化されていると、各クエリ実行の詳細な統計情報（パース時間、プランニング時間、実行時間など）がサーバーログに記録され、パフォーマンスに深刻な影響を与える可能性があります。

この統計情報には、パーサー、プランナー、エグゼキューターの各コンポーネントの実行時間やメモリ使用量が含まれ、デバッグには有用ですが、各クエリ実行ごとに生成されるためログ量が膨大になります。

リスク

log_statement_statsパラメータが有効化されている場合、以下のリスクと運用上の問題が発生する可能性があります：

深刻なパフォーマンス劣化: ステートメント統計の収集により、各クエリ実行時に大幅なオーバーヘッドが発生し、データベース全体の応答性が著しく低下します。特に、高頻度で実行されるクエリでは、CPU使用率が20-30%上昇し、レスポンス時間が2-3倍に増加することがあります。
ログストレージの急速な枯渇: パーサー、プランナー、エグゼキューターの全統計情報が記録されるため、ログファイルが極めて速いペースで肥大化します。中規模のシステムでも、1日あたり50-100GBのログが生成され、Cloud Loggingのストレージコストが大幅に増加する可能性があります。
クエリパターンの露出: 詳細な実行統計には、テーブル構造、インデックス使用状況、結合順序などの内部情報が含まれ、データベーススキーマのリバースエンジニアリングに悪用される可能性があります。特に、実行計画の詳細が露出することで、データベースの内部構造や最適化の弱点が攻撃者に知られるリスクがあります。
重要ログの埋没: 過剰な統計情報により、SQLインジェクション攻撃の兆候や不正アクセスの試みなどのセキュリティアラートが大量のログに埋もれ、インシデント対応が遅れる可能性があります。
インフラコストの増大: ログストレージの増加（最大10倍）とCPU使用率の上昇（20-30%増）により、インスタンスのアップグレードが必要となり、月額コストが倍増する可能性があります。

修復方法

コンソールでの修復手順

Google Cloud コンソールを使用して、log_statement_statsパラメータを無効化します。

Google Cloud Consoleにログイン
- Cloud SQLインスタンスページに移動します
対象のPostgreSQLインスタンスを選択
- 設定を変更したいPostgreSQLインスタンスをクリックします
インスタンスの編集画面を開く
- インスタンス詳細ページで「編集」ボタンをクリックします
フラグセクションまでスクロール
- 設定画面を下にスクロールし、「フラグ」セクションを見つけます
log_statement_statsフラグを確認
- 「データベースフラグ」に「log_statement_stats」エントリがあるか確認します
- 存在する場合は、その値が「on」になっているはずです
フラグを削除または無効化
- オプション1: フラグエントリの横にある削除アイコンをクリックして削除します
- オプション2: 値を「off」に変更します
競合する統計フラグの確認
- log_statement_statsを有効にする場合、以下のフラグは無効である必要があります：
  - log_parser_stats: 「off」に設定
  - log_planner_stats: 「off」に設定
  - log_executor_stats: 「off」に設定
変更を保存
- ページ下部の「保存」ボタンをクリックして変更を適用します
- 注意: インスタンスが一時的に再起動される場合があります
設定の確認
- インスタンスの概要ページに戻り、「データベースフラグ」セクションで設定が正しく適用されていることを確認します

Terraformでの修復手順

Cloud SQL PostgreSQLインスタンスのlog_statement_statsパラメータを無効化するTerraformコードと、主要な修正ポイントを説明します。

# Cloud SQL PostgreSQLインスタンスの最適化設定
resource "google_sql_database_instance" "postgresql_performance_optimized" {
  >>>>> Skip
  settings {
    # ステートメント統計ログを明示的に無効化
    database_flags {
      name  = "log_statement_stats"
      value = "off"  # 重要: 本番環境では必ず無効化
    }

    # 注意: log_statement_statsがtrueの場合、以下の3つのフラグを
    # 同時に有効化できない（PostgreSQLの制約）
    # 個別の統計フラグも明示的に無効化
    database_flags {
      name  = "log_parser_stats"
      value = "off"
    }

    database_flags {
      name  = "log_planner_stats"
      value = "off"
    }

    database_flags {
      name  = "log_executor_stats"
      value = "off"
    }
  }
}

ベストプラクティス

統計フラグの互換性に注意

log_statement_statsは包括的な設定で、以下の3つのフラグと同時に有効化できません：
- log_parser_stats
- log_planner_stats
- log_executor_stats
これらのフラグはすべて無効化することを推奨します
フラグを有効化しようとした際にエラーが発生する場合は、競合するフラグが有効化されていないか確認

代替のパフォーマンス監視方法

Query Insights: Cloud SQLの標準機能でクエリパフォーマンスを可視化（オーバーヘッドが最小）
- リアルタイムでクエリパフォーマンスを分析
- CPUやメモリ使用率との相関を表示
- 問題のあるクエリを簡単に特定
pg_stat_statements: クエリ統計を収集するPostgreSQL拡張（軽量で実用的）
- 実行回数、合計実行時間、平均実行時間を記録
- オーバーヘッドは5%未満
- SQLクエリで結果を取得可能
Cloud Monitoring: CPU、メモリ、ディスクI/Oのメトリクスを監視
- インフラレベルのメトリクスを収集
- カスタムダッシュボードの作成が可能
- アラート設定で自動通知
auto_explain: 特定の遅いクエリのみ実行計画をログに出力
- log_min_duration_statementと組み合わせて使用
- 遅いクエリのみを対象とするためオーバーヘッドが少ない
- EXPLAIN ANALYZE相当の情報を自動収集

環境別の推奨設定

開発環境/ステージング環境など
- デバッグ時のみ一時的に有効化（最大15分程度）
- 使用後は必ず無効化
- auto_explainの使用を検討
- Query Insights + pg_stat_statementsを活用
本番環境:
- 無効化すること
- Query Insightsをメインに使用
- 重要なパフォーマンス問題はテスト環境で再現させる