pgAdmin 4サーバモードの静かなる脅威：セッション肥大化とログ爆発を完全に制圧するアーキテクチャ設計
プロダクション環境や厳格なステージング環境において、PostgreSQLの管理を単一のGUIに依存するべきではないという議論はさておき、チーム開発やマルチテナントでの運用において「pgAdmin 4」のサーバモード（Server Mode）をコンテナまたは専用VM上で稼働させているインフラストラクチャは数多く存在する。
しかし、ここで多くのDevOpsエンジニアが数ヶ月の運用の末に直面する「見えない恐怖」がある。ディスク容量の慢性的圧迫だ。
ログのローテーションが行われないまま肥大化し、さらに背後で静かにうごめくSQLiteのセッションデータベース（`sess_`）が数ギガバイト規模に膨れ上がる。結果として、ヘルスチェックのエンドポイントがタイムアウトし、コンテナがOOM Killerの餌食になる――これは、pgAdmin 4の内部アーキテクチャを理解していない者が踏む、あまりにも典型的な地雷である。
本稿では、pgAdmin 4のサーバモードにおけるストレージ枯渇の根本原因を低レイヤの視点から解き明かし、OSレベル、アプリケーション層、そしてコンテナオーケストレーション層を貫く完全自動クリーンアップの設計図を提示する。
—
1. 内部アーキテクチャの解剖：なぜpgAdmin 4のストレージは肥大化するのか？
サーバモード（WSGI/Gunicorn + Flask構成）で動作するpgAdmin 4は、ステートレスに見えて、実はローカルストレージに大量の「状態」を書き込んでいる。特にディスクを圧迫する主犯格は以下の2つだ。
① SQLiteセッションデータベースの肥大化 (`pgadmin4.db`)
pgAdmin 4は、デフォルトでユーザセッションの管理にSQLiteを使用している。
Webブラウザからログインするたび、あるいはAjaxポーリングやタブの切り替えが行われるたびに、セッションデータがシリアライズされてDBに書き込まれる。
問題なのは、デフォルトの状態では古いセッションの有効期限切れ（TTL）判定や自動パージ（VACUUM）が不十分である点だ。数ヶ月放置されたサーバの `pgadmin4.db` を覗くと、数百万行の古いセッションデータが放置され、ファイルサイズが10GBを超えていることも珍しくない。SQLiteはデフォルトではデータを削除してもファイル自体のサイズ縮小（フリーページの解放）を行わないため、OSから見たディスク容量は圧迫されたままとなる。
② 制御不能なログの肥大化 (`pgadmin4.log`)
Flaskのロギング機構、あるいはSQLAlchemyのクエリロギングが無造作に出力されることで、ログファイルが日単位でギガバイト単位に成長する。コンテナ環境において、標準出力（stdout）へのリダイレクト設定やログローテーション（logrotate）のポリシーが欠如している場合、Dockerデーモンのストレージドライバ（overlay2等）を直撃し、Dockerホスト全体の停止を引き起こす。
—
2. アプリケーション層での最適化：`config_local.py` による根本制御
pgAdmin 4の挙動を根本からコントロールするには、デフォルトの設定ファイル（`config.py`）を直接触るのではなく、オーバーライド用の `config_local.py` を用いる。
サーバモードのルートディレクトリ（通常は `/pgadmin4/config_local.py` またはソースインストール時のパス）に、セッションのライフサイクルとロギングを制御するパラメーターを明示的に記述する。
セッションタイムアウトとクリーンアップのチューニング
不要に長すぎるセッション保持期間を切り詰め、ガベージコレクションを促進させる。
config_local.py
セッションの有効期限を明示的に設定（例: 12時間で強制失効）
PERMANENT_SESSION_LIFETIME = 3600 12
セッションデータのクリーンアップ頻度を最適化
※pgAdmin内部のジョブスケジューラが古いセッションを掃き出す間隔（秒）
SESSION_CLEANUP_INTERVAL = 3600 # 1時間ごとにパージ処理を実行
ログレベルの調整（プロダクションではDEBUGを絶対に排除する）
DEFAULT_LOG_LEVEL = 35 # ERROR (40) と WARNING (30) の間、または INFO (20)
CONSOLE_LOG_LEVEL = 20
FILE_LOG_LEVEL = 20
ログファイルの最大サイズとローテーション世代数
MAX_LOG_SIZE = 10 1024 1024 # 10MB
LOG_BACKUP_COUNT = 5 # 最大5世代まで保持
—
3. データベース層の防衛：SQLiteの強制最適化とパージスクリプト
`config_local.py` による制御だけでは、すでに肥大化した `pgadmin4.db` の物理サイズ（高騰したディスク消費量）を下げることはできない。SQLiteのインプレース削除では空き領域が再利用されるだけで、OSへの返還（ファイルの縮小）が行われないためである。
ここでは、「古いセッションの物理削除」＋「VACUUMによる領域解放」を安全に行うためのメンテナンススクリプトを提示する。これをCron、またはKubernetesのCronJobとして定期実行する。
高速セッションパージ＆VACUUMスクリプト (`pgadmin_vacuum.py`)
!/usr/bin/env python3
“””
pgAdmin 4 Session DB Vacuum & Purge Utility
Author: World-Class Infrastructure Architect
Description: 安全に古いセッションを削除し、SQLiteの断片化を解消してディスクを解放する
“””
import os
import sqlite3
import sys
import time
環境に合わせてパスを調整
DB_PATH = os.getenv(“PGADMIN_DB_PATH”, “/var/lib/pgadmin/pgadmin4.db”)
保持するセッションの最大経過時間（デフォルト: 7日前までのセッションをパージ）
MAX_SESSION_AGE_SEC = 7 24 3600
def optimize_pgadmin_db(db_path: str):
if not os.path.exists(db_path):
print(f”[ERROR] Database file not found: {db_path}”)
sys.exit(1)
print(f”[] Starting optimization for: {db_path}”)
initial_size = os.path.getsize(db_path)
print(
f”[] Initial DB file size: {initial_size / (1024 1024):.2f} MB”)
try:
# トランザクションを安全に張るため、Timeoutを長めに設定
conn = sqlite3.connect(db_path, timeout=30.0)
cursor = conn.cursor()
# WALモード確認・設定（並行性向上）
cursor.execute(“PRAGMA journal_mode=WAL;”)
# セッションテーブルの存在確認（pgAdminのバージョンによってスキーマ差異があるためガード）
cursor.execute(
“SELECT name FROM sqlite_master WHERE type=’table’ AND name=’sessions’;”
)
if not cursor.fetchone():
print(“[WARN] ‘sessions’ table not found in DB. Skipping.”)
conn.close()
return
# 期限切れセッションの削除
# ※FlaskのSessionインタフェース実装依存だが、通常セッションはテーブルに格納される
threshold_time = time.time() – MAX_SESSION_AGE_SEC
# 注: セッションデータの構造に合わせたタイムスタンプ判定が必要な場合があるため、
# ここでは一般的なFlask-SQLAlchemyのセッション管理を想定。
# 厳密にはexpiryカラム等があればそれを利用する。
print(“[] Purging expired sessions…”)
# セッションデータが格納されているテーブル名が異なる場合のフォールバックを考慮
# 安全のため、最終更新から一定期間経過したレコードを削除
cursor.execute(
“DELETE FROM sessions WHERE internal_access_time < ?;",
(threshold_time,)
)
deleted_rows = cursor.rowcount
conn.commit()
print(f"[] Deleted {deleted_rows} expired session records.")
# ディスク領域をOSに返還するためのVACUUM実行
print(
"[] Executing VACUUM (this may take a while for large databases)...")
cursor.execute("VACUUM;")
conn.close()
print("[] Database optimization completed successfully.")
except sqlite3.Error as e:
print(f"[ERROR] SQLite error occurred: {e}", file=sys.stderr)
sys.exit(1)
final_size = os.path.getsize(db_path)
print(f"[] Final DB file size: {final_size / (1024 1024):.2f} MB")
saved_space = (initial_size - final_size) / (1024 1024)
print(f"[] Reclaimed disk space: {saved_space:.2f} MB")
if __name__ == "__main__":
optimize_pgadmin_db(DB_PATH)
---
4. コンテナ/Linux環境における完全自動構成（Ops Automation）
インフラストラクチャ・エンジニアとして、上記の手順を手動で行う運用など論外である。完全に自動化されたパイプラインへ組み込む。
パターンA: Docker Compose環境でのLogrotateサイドカーまたはインテグレーション
Dockerコンテナとして稼働させる場合、ログファイルがコンテナ内部に蓄積されるのを防ぐため、標準出力（stdout）への出力に一本化し、Dockerデーモン側のログローテーションに委譲するのがモダンな設計である。
version: ‘3.8’
services:
pgadmin:
image: dpage/pgadmin4:latest
container_name: pgadmin4
environment:
PGADMIN_DEFAULT_EMAIL: “admin@example.com”
PGADMIN_DEFAULT_PASSWORD: “SuperSecurePassword123!”
PGADMIN_CONFIG_SERVER_MODE: “True”
volumes:
- pgadmin_data:/var/lib/pgadmin
# config_local.py をバインドマウント
- ./config_local.py:/pgadmin4/config_local.py:ro
ports:
- “80:80”
restart: always
# Dockerのログローテーション設定（ローカルドライバを使用する場合）
logging:
driver: “json-file”
options:
max-size: “10m”
max-file: “3”
volumes:
pgadmin_data:
パターンB: Kubernetes環境におけるCronJobによる自律クリーンアップ
Kubernetes（EKS/GKE等）上でpgAdmin 4をDeploymentとして運用している場合、PersistentVolume（PV）上にマウントされたSQLite DBに対して、定期的に `VACUUM` をかけるCronJobをデプロイする。
apiVersion: batch/v1
kind: CronJob
metadata:
name: pgadmin-db-maintenance
namespace: database-admin
spec:
schedule: “0 3 0” # 毎週日曜日の深夜3時に実行
successfulJobsHistoryLimit: 3
failedJobsHistoryLimit: 3
jobTemplate:
spec:
template:
spec:
containers:
- name: vacuum-tool
image: python:3.11-slim
command:
- “/bin/sh”
- “-c”
- |
pip install –no-cache-dir sqlite3 > /dev/null 2>&1
python /scripts/pgadmin_vacuum.py
volumeMounts:
- name: pgadmin-storage
mountPath: /var/lib/pgadmin
- name: maintenance-script
mountPath: /scripts
restartPolicy: OnFailure
volumes:
- name: pgadmin-storage
persistentVolumeClaim:
claimName: pgadmin-pvc
- name: maintenance-script
configMap:
name: pgadmin-maintenance-script-cm
—
5. エキスパートが実践するさらなるベストプラクティス
ここまでの設定で日常的なストレージ肥大化の脅威はほぼ完全に封じ込めることができるが、真に堅牢なシステムを構築するためには、さらに一段階上のアプローチを検討すべきだ。
1. セッションストアの外部化（Redisの活用）
pgAdmin 4の標準機能およびFlaskの拡張性を利用し、セッションストレージをSQLiteからRedisへオフロードすることが可能であれば、それに越したことはない（※pgAdminの標準コード改修が必要になる場合があるため、運用コストとのトレードオフに注意）。Redisであれば、キーに対する `EXPIRE` がネイティブかつ高速に処理されるため、SQLiteのような断片化や手動VACUUMの悩みから完全に解放される。
2. モニタリングとアラートの連動
Prometheusの `node_exporter` を用いて、`/var/lib/pgadmin` が存在するマウントポイントのディスク使用率（`node_filesystem_free_bytes`）を監視し、使用率が85%を超えた段階でPagerDutyやSlackへアラートを飛ばす導線を必ず構築しておくこと。自動化は完全無欠ではないため、最後の砦としての監視メトリクスは不可欠である。
インフラストラクチャの美しさは、日々の手動オペレーションの排除と、予測可能な自動復旧メカニズムの融合にある。pgAdmin 4のストレージ管理においても例外ではない。本稿で示した設計を導入し、深夜のディスク枯渇アラートにおびえる日々から完全に脱却してほしい。