Google Cloud SQL PostgreSQLでの一時ファイルログ（log_temp_files）有効化について

2025.08.15

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

この記事では、Google Cloud SQL PostgreSQLインスタンスでlog_temp_filesパラメータが無効化されている問題について、パフォーマンス監視とセキュリティの観点からの詳細なリスク分析と、gcloud CLI、Terraform、Cloud Consoleを使用した包括的な修復方法を解説します。2025年1月時点の最新のCloud SQL機能とPostgreSQL 16に対応しています。

ポリシーの説明

log_temp_filesパラメータは、PostgreSQLデータベースで一時ファイルの生成と削除を監視する重要なパフォーマンス監視機能です。このパラメータにより、指定されたサイズ以上の一時ファイルがデータベースによって作成・削除される際に、その詳細がpostgresql.logに記録されます。

Cloud SQLでは、これらのログはCloud Loggingに自動的に統合され、以下の情報が記録されます：

  • 一時ファイルのファイル名と完全パス
  • ファイルサイズ（バイト単位）
  • 作成したプロセスIDとセッション情報
  • 一時ファイルを生成したクエリの情報

PostgreSQLは以下の操作で一時ファイルを作成します：

  • ソート操作がwork_memを超える場合
  • ハッシュテーブルがwork_memを超える場合
  • マテリアライズド結果セットの保存
  • CREATE INDEX操作での中間結果
  • 大量データのCOPY操作

修復方法

前提条件

  • Cloud SQL Admin役割（roles/cloudsql.admin）または同等の権限
  • 対象のCloud SQL PostgreSQLインスタンスへのアクセス権
  • インスタンスの再起動は不要（オンラインで設定変更可能）

コンソールでの修復手順

Google Cloud コンソールを使用した修復方法：

  1. Google Cloud Consoleにログインします
  2. ナビゲーションメニューから「SQL」を選択します
  1. 対象のPostgreSQLインスタンスをクリックします
  1. 「編集」ボタンをクリックします
  1. 「構成オプション」セクションまでスクロールし、「フラグ」を展開します
  2. 「項目を追加」をクリックします
  3. ドロップダウンメニューから「log_temp_files」を選択します
  4. 値を「0」に設定します（すべての一時ファイルをログに記録）
  1. 「保存」をクリックして変更を適用します

注意: この設定変更はインスタンスの再起動を必要としないため、実行中のインスタンスに安全に適用できます。

Terraformでの修復手順

Infrastructure as Codeを使用した本番環境向けの包括的な実装例です。

resource "google_sql_database_instance" "postgresql" {
  >>>> Skip
  settings {
    # 一時ファイルログの有効化（必須）
    database_flags {
      name  = "log_temp_files"
      value = "0"  # すべての一時ファイルをログに記録
    }
  }
}

 

ベストプラクティス

log_temp_filesの推奨設定

環境推奨値説明
開発0すべての一時ファイルを記録して最適化機会を発見
ステージング1024 (1MB)大きな一時ファイルのみを追跡
本番0パフォーマンス問題の早期発見のため全て記録

メモリ設定の最適化

  1. work_memの調整 
    -- 現在の設定を確認
SHOW work_mem;

-- セッションレベルで一時的に変更してテスト
SET work_mem = '16MB';

-- 全体設定の計算式
-- work_mem = (全体RAM - shared_buffers) / (max_connections * 3)

     

  2. maintenance_work_memの設定
    • VACUUM, CREATE INDEXなどのメンテナンス操作用
    • 通常work_memの4-8倍に設定
    • デフォルト64MB→ 256MB-512MBを推奨
  3. temp_file_limitの設定 
    -- セッションあたり1GBに制限
ALTER SYSTEM SET temp_file_limit = '1GB';

     

監視とアラート戦略

  1. 一時ファイル使用量の闾値
    • 警告: 1時間で1GB以上
    • エラー: 1時間で10GB以上
    • 緊急: 1時間で100GB以上
  2. ダッシュボードの構築
    • 一時ファイル使用量のトレンド
    • クエリ別の一時ファイル使用量
    • ユーザー別のリソース消費
  3. 定期的なレポート 
    -- 週次レポート用クエリ
SELECT
    DATE_TRUNC('day', stats_reset) as date,
    SUM(temp_files) as total_temp_files,
    pg_size_pretty(SUM(temp_bytes)) as total_size
FROM pg_stat_database
WHERE temp_files > 0
GROUP BY DATE_TRUNC('day', stats_reset)
ORDER BY date DESC;

     

クエリ最適化テクニック

  1. インデックスの追加 
    -- ソートを回避するインデックス
CREATE INDEX idx_covering ON table_name(col1, col2) INCLUDE (col3, col4);

     

  2. クエリの書き換え 
    -- EXISTSを使用して結合を回避
SELECT * FROM orders o
WHERE EXISTS (
    SELECT 1 FROM customers c
    WHERE c.id = o.customer_id
    AND c.country = 'Japan'
);

     

  3. パーティションの活用
    • 大量データのテーブルをパーティション化
    • パーティションプルーニングの活用

まとめ

この記事では、Google Cloud SQL PostgreSQLインスタンスでlog_temp_filesパラメータを有効化する包括的な方法を解説しました。

重要なポイント：

  • 一時ファイルログはパフォーマンス問題の早期発見に不可欠
  • work_memとtemp_file_limitの適切な設定が重要
  • Cloud LoggingやBigQueryとの統合で高度な分析が実現

この問題の検出は弊社が提供するSecurifyのCSPM機能で簡単に検出及び管理する事が可能です。 運用が非常に楽に出来る製品になっていますので、ぜひ興味がある方はお問い合わせお待ちしております。 最後までお読みいただきありがとうございました。この記事が皆さんの役に立てば幸いです。

参考情報

Google Cloud公式ドキュメント（2025年1月確認）

PostgreSQL公式ドキュメント

パフォーマンス最適化リソース

この記事をシェアする

クラウドセキュリティ対策実践集一覧へ戻る

貴社の利用状況に合わせた見積もりを作成します。

見積もりを希望する
資料ダウンロード

料金プランを詳しく見る