Penpotの心臓部を掌握せよ：PostgreSQLバックアップと運用自動化の極意
Penpotは、ブラウザベースのデザインツールという枠組みを超え、CSS GridやFlexboxといったWeb標準技術をネイティブに扱う、エンジニアリングとデザインの境界を溶かす極めて秀逸なプロダクトだ。
しかし、セルフホスト環境において「デザインデータが消える」ということは、企業の知的財産そのものが霧散することを意味する。Dockerコンテナを立ち上げて終わり、という運用では、いずれ必ず悲劇に見舞われる。
本稿では、Penpotのバックアップと運用を「DevOpsの文脈」で再定義し、PostgreSQLの内部構造に踏み込んだ、堅牢かつスケーラブルな防衛線を構築する術を伝授する。
—
1. Penpotデータ構造の解剖学
Penpotのデータ永続化層は、主にPostgreSQL（メタデータ・デザイン構成）とRedis（セッション・キャッシュ）、そしてMinIO（またはS3、バイナリデータ）の三位一体で成り立っている。
特にPostgreSQLは、複雑なJSONBカラムを多用したスキーマ設計となっている。これはデザインデータの柔軟な拡張性を担保するためだが、反面、バックアップ時には「整合性のあるスナップショット」を取ることが最重要命題となる。
- 注意点: 単なるファイルコピーは厳禁だ。PostgreSQLがトランザクションを処理している最中に物理ファイルをコピーすれば、データ破損は不可避である。
2. ゼロダウンタイムを目指した「論理バックアップ」戦略
PostgreSQLのバックアップには、`pg_dump`を用いた論理バックアップが推奨される。コンテナ停止を伴う物理バックアップ（`pg_basebackup`）はリカバリ時間が短いが、運用の柔軟性では論理バックアップに分がある。
自動バックアップスクリプト：`penpot-backup.sh`
以下のスクリプトは、Dockerコンテナ内からストリーミングで圧縮ダンプを抽出し、S3互換ストレージへ転送するパイプラインの雛形である。
!/bin/bash
Penpot PostgreSQL Backup Pipeline
実行権限: root (またはdockerグループ)
CONTAINER_NAME=”penpot-postgres”
BACKUP_DIR=”/var/backups/penpot”
TIMESTAMP=$(date +”%Y%m%d_%H%M%S”)
FILENAME=”penpot_db_${TIMESTAMP}.sql.gz”
1. コンテナ内でのダンプ実行とストリーム圧縮
pg_dumpの-Fcオプションでカスタムフォーマット（再利用性・圧縮効率高）を採用
docker exec -t $CONTAINER_NAME pg_dump -U penpot -F c penpot | gzip > “${BACKUP_DIR}/${FILENAME}”
2. 整合性チェック（ダンプファイルが空でないか確認）
if [ -s “${BACKUP_DIR}/${FILENAME}” ]; then
# 3. リモートストレージ(AWS S3等)へ非同期アップロード
aws s3 cp “${BACKUP_DIR}/${FILENAME}” s3://my-penpot-backups/
# 4. ローカルの古いキャッシュをクリーンアップ（7日分保持）
find $BACKUP_DIR -type f -name “.sql.gz” -mtime +7 -delete
else
echo “Error: Backup failed” >&2
exit 1
fi
3. メジャーバージョンアップ時のデータ移行：死線を越える手法
Penpotのバージョンアップ時、PostgreSQLのメジャーバージョン移行が必要になるケースがある。この際、単なるコンテナイメージの差し替えはデータ破壊を招く。
鉄則：`pg_dumpall` ではなく `pg_dump` による個別データ移行
異なるメジャーバージョン間では、内部システムテーブルの構造が異なる場合があるため、`pg_dumpall`の使用は避けるべきだ。
1. 現行環境のバックアップ: 上記スクリプトで完全にダンプを取得。
2. 新環境の構築: 新しいPostgreSQLコンテナを立ち上げ、空のDBを作成。
3. リストア: `pg_restore -d penpot -U penpot < backup.dump` を実行。
4. 検証: `SELECT count() FROM pages;` などで、行数に乖離がないかを確認。
4. パフォーマンス最適化ハック：メモリとディスクI/O
PenpotのDB操作は頻繁な読み書きを伴う。負荷が高い環境では、以下のチューニングが劇的な改善をもたらす。
- `shared_buffers` の拡張: コンテナ起動時の環境変数 `POSTGRES_SHARED_BUFFERS` を物理メモリの25%程度に割り当てる。
- `work_mem` の調整: 複雑なクエリが走る際、ディスクへのスワップを防ぐため、セッションごとに十分なメモリを確保する。
- WAL (Write Ahead Log) の配置: 大規模チームでの利用時には、WALファイルをメインのデータ領域とは別の高速なSSD（またはNVMe）へマウントする。これによりI/Oのボトルネックを解消できる。
5. 伝説的アーキテクトからの提言
真のエンジニアリングとは、ツールを「使う」ことではなく、「制御下に置く」ことにある。
Penpotはまだ発展途上のツールだが、そのアーキテクチャは非常にオープンで、ハックのしがいがある。バックアップを自動化するだけでは足りない。監視ツール（Prometheus/Grafana）をPostgreSQLのexporterと連携させ、DBのトランザクション率やコネクション数を常に可視化せよ。
デザインデータは、単なる画像ではない。それはチームの思考の履歴であり、知的財産の結晶だ。その重みを受け止めるインフラを構築して初めて、あなたは「Penpotを使いこなしている」と胸を張れるはずだ。
さあ、今すぐあなたのコンテナ環境を見直し、堅牢なパイプラインを構築してほしい。それが、世界を変えるデザインを生み出すための、唯一の近道である。