【実務・中級編】pgAdmin 4のストレージ肥大化を防ぐ！セッションファイルとログの自動クリーンアップ設定 – データベース・API管理活用バイブル

pgAdmin 4のストレージ肥大化を防ぐ！セッションファイルとログの自動クリーンアップ設計

テックリードの私たちが本番・検証インフラを運用する中で、最も不毛なインシデントの一つが「ログや一時ファイルの肥大化によるディスク枯渇」だ。特に、複数人でチーム開発を行うために`Server Mode`（Webサーバーモード）で常時稼働させているpgAdmin 4は、放置すると驚異的なスピードでストレージを食いつぶしていく。

「ある日突然、pgAdminが500 Internal Server Errorを吐いてログインできなくなった」
「確認したら、内部のSQLiteデータベースとセッションファイルだけで数十GBも消費していた」

こうしたトラブルは、ツールのアーキテクチャを理解し、適切なライフサイクル管理を行うことで完全に防ぐことができる。本稿では、pgAdmin 4のストレージ肥大化の根本原因を解き明かし、現場の生産性を落とさずにクリーンな状態を維持するための実践的な自動クリーンアップ設計を伝授する。

—

1. なぜpgAdmin 4のストレージは肥大化するのか？

pgAdmin 4をデスクトップモードではなく、DockerやLinuxサーバー上でServer Modeとして動かしている場合、以下の3つの要素がストレージ圧迫の主原因となる。

1. SQLiteセッションデータベース（`sess_` テーブルの肥大化）
pgAdminはユーザーのログインセッションやUIの状態管理にSQLiteを使用している。特にチームメンバーがブラウザタブを閉じずに放置したり、頻繁にリロードを繰り返したりすると、無数のセッションデータがゴミとして蓄積される。これらが自動削除されないまま、数ヶ月放置されると数GB規模に膨れ上がる。
2. バックアップ・インポート/エクスポートの残骸ファイル
GUI経由で実行されたダンプファイル（`.sql`や`.tar`）やストレージ上の一時アップロードファイルが、デフォルトのストレージディレクトリ（通常は `/var/lib/pgadmin/storage` など）に残り続ける。
3. ローテーションされないログファイル
デバッグレベルが適切に設定されていない、あるいはログローテーションのポリシーが定義されていない場合、アプリケーションログやWebサーバー（Gunicorn/uWSGI/Apache）のログがディスクを圧迫する。

—

2. 現場で即効性を発揮するストレージ解放メンテナンス手順

まずは、すでに肥大化してしまった環境を安全にクリーンアップする手順を押さこう。運用中のコンテナやサーバーを止めずに、安全に領域を回収するための実戦的アプローチだ。

Step A: SQLiteセッションDBのバキュームとデッドタプル（セッション）の削除

pgAdminのセッションデータは、内部のSQLite（通常 `sess.db` または設定されたデータベースファイル）に格納されている。以下のPythonスクリプト、またはシェルスクリプトを定期実行することで、期限切れのセッションをパージし、データベースファイルを圧縮（VACUUM）できる。

!/bin/bash
—————————————————————–
pgAdmin 4 Session DB Cleanup Script
—————————————————————–
対象: サーバモードで稼働するpgAdminのSQLiteセッションDB
効能: 30日以上更新されていないセッションの削除とVACUUMによる領域解放
—————————————————————–

DB_PATH=”/var/lib/pgadmin/sessions.db” # 環境に応じたパスに変更

if [ -f “$DB_PATH” ]; then
echo “Starting pgAdmin session cleanup for: $DB_PATH”

# SQLiteを直接叩いて古いセッションを削除
sqlite3 “$DB_PATH” <&2
exit 1
fi

Step B: 孤立したストレージファイルのパージ

ユーザーがGUIからアップロードしたファイルや、バックアップ機能で作成された一時ファイルは以下のディレクトリに蓄積される。ここに対し、例えば「7日以上アクセスがないファイル」を自動削除するfindコマンドをcronに組み込む。

7日以上更新のないアップロード・ストレージファイルを削除
find /var/lib/pgadmin/storage/ -type f -mtime +7 -delete

—

3. チーム開発を加速する！環境のコード化（ベストプラクティス構成例）

アドホックなスクリプトに頼るだけでなく、そもそも肥大化しにくいアーキテクチャをコード（Docker Compose）として定義するのがテックリードの仕事だ。

以下の `docker-compose.yml` は、リソース制限、ログローテーション、および環境変数のベストプラクティスを網羅したプロダクションレディな構成例である。

`docker-compose.yml` (pgAdmin 4 Production Config)

version: ‘3.8’

services:
pgadmin:
image: dpage/pgadmin4:7.8
container_name: pgadmin4_prod
restart: unless-stopped
environment:
PGADMIN_DEFAULT_EMAIL: “admin@example.com”
PGADMIN_DEFAULT_PASSWORD: “${PGADMIN_PASSWORD:-SuperSecretPassword!}”
# セッションの有効期限を短縮し、ゴミの蓄積を抑制（秒単位: 例は7日間）
PGADMIN_SESSION_TTL: “604800”
# ログレベルの調整（DEBUGはディスクを爆発させるためINFOやWARNING推奨）
PGADMIN_LOG_LEVEL: “WARNING”
ports:

  • “80:80”

volumes:
# 永続化領域を明確に分離

  • pgadmin_data:/var/lib/pgadmin

# 設定の共有化用config.jsonをマウントする場合

  • ./config_local.py:/pgadmin4/config_local.py:ro

# Dockerのログローテーション設定でホスト側のディスク枯渇を防ぐ
logging:
driver: “json-file”
options:
max-size: “10m”
max-file: “3”
resources:
limits:
cpus: ‘1.0’
memory: 1G

volumes:
pgadmin_data:
driver: local

—

4. チーム全体で共有すべき `config_local.py` の極意

pgAdmin 4の挙動を深く制御するためには、環境変数だけでなくPythonによる設定ファイル（`config_local.py`）を活用するべきだ。これをGitでチーム管理（機密情報を除く）し、CI/CDやデプロイ時に適用することで、組織全体のpgAdmin品質が底上げされる。

`config_local.py` ベストプラクティス

=====================================================================
pgAdmin 4 Local Configuration (Production-Ready)
=====================================================================

セキュリティとストレージ肥大化対策のためのオーバーライド設定

セッションの有効期限 (秒単位) – デフォルトは長すぎるため14日に制限
SESSION_EXPIRE_AT_BROWSER_CLOSE = False
SESSION_COOKIE_AGE = 1209600 # 14 days

最大アップロードファイルサイズ制限 (MB) – ディスク圧迫の元凶を防ぐ
MAX_CONTENT_LENGTH = 100 1024 1024 # 100MB

サーバー設定の自動マイグレーションと最適化
サーバモードでのSQLiteのビジータイムアウトを設定し、ロック競合を防ぐ
SQLITE_TIMEOUT = 20.0

ログ設定: ファイルへの過剰な書き込みを抑制し、標準出力に逃がしてDocker側で管理させる
CONSOLE_LOG_LEVEL = 30 # WARNING
FILE_LOG_LEVEL = 40 # ERROR (致命的なエラー以外ファイル出力しない)

—

5. 開発スピードを劇的に高めるプロの知見（おまけ）

ストレージ管理と並行して、日々の開発スピードを限界まで引き上げるためのpgAdmin 4の「隠し武器」を共有しよう。

  • ショートカットキーの極み:
  • クエリツールを開いた状態で `Ctrl + Space`（Macは `Cmd + Space`）によるインテリセンス（補完）の強制呼び出し。
  • `F5` によるクエリ実行は基本だが、複数行を選択して実行すれば、該当部分だけが即座に走ることを忘れてはならない。
  • 神プラグイン・機能の活用:
  • Storage Manager: GUIの左メニューからアクセスできるストレージマネージャーを定期的に開き、古いバックアップファイルをブラウザ経由で即座にパージする習慣をチームでつける。
  • Server Groupsの共有: 開発環境の接続情報をJSON形式でエクスポートし、チームの新メンバーに配布することで、手動入力のミスや接続情報の属人化をゼロにできる。

—

テックリードからのメッセージ

データベースやマネジメントツールの保守は地味な作業に見える。しかし、こうしたストレージ肥大化のメカニズムをコードレベルで把握し、自動化の網を張っておくことこそが、夜間や休日にインシデントアラートで叩き起こされないための唯一にして最大の防衛策だ。

「動いているから放置する」のではなく、「持続可能なインフラとして管理する」。この姿勢をチーム全体に浸透させ、開発に集中できる美しい環境を構築してほしい。

スポンサーリンク
タイトルとURLをコピーしました