5.1 KiB

Raw Blame History

Critical Architecture Decision: Synology VMM (Finalized)

Date: 2026-01-19
Status: FINAL (Aligned with Claude & Antigravity)
Verdict: Agreed on "Host 12GB / Guest 4GB" split.
Last Updated: 2026-01-19 (IP addresses recorded)

🌐 Network Configuration (Verified ✅ 2026-01-19)

Host (Synology DSM):
  Tailscale IP: 100.77.67.102     # Remote access to DSM
  Local IP: 192.168.31.172        # Fast access within home network
  DSM Web UI: http://192.168.31.172:5000

VM (Posimai_lab):
  Tailscale IP: 100.76.7.3        # SSH from Company PC
  Local IP: 192.168.31.89         # VM ↔ Host communication
  Memory: 4GB (3.9Gi total, 2.9Gi available)
  User: mai

Connection Examples:

# 1. Company PC → VM (SSH via Tailscale)
ssh mai@100.76.7.3

# 2. VM → PostgreSQL on Host (high-speed local network)
postgresql://192.168.31.172:5432/database_name

# 3. Dokploy App Container → PostgreSQL
# Use Host's LOCAL IP (NOT Tailscale), for <1ms latency:
DATABASE_URL=postgresql://user:password@192.168.31.172:5432/posimai_db

# 4. Remote access to DSM (from anywhere)
http://100.77.67.102:5000

Important Rules:

✅ Always use LOCAL IPs (192.168.31.x) for VM ↔ Host communication (fastest)
✅ Use Tailscale IPs (100.x.x.x) ONLY for remote access from outside
❌ NEVER use Tailscale IP for DB connections (adds unnecessary latency)

1. 批判的フィードバックへの回答 (Agree)

Claudeの指摘は100%正しいです。私の前回のドキュメントにおける「DSM 2GB」という記述は、OS本体のみを指しており、Docker（Postgres/Immich）を含めていませんでした。 Claudeの言う通り、実運用では 「Host (データ/AI層) に 12GB を残す」 のが必須です。

🚨 緊急アクション

VMのメモリ設定を 8GB → 4GB に今すぐ減らしてください。
これにより、Synology本体（Host）が呼吸できるようになります。

2. AI解析はどこで行われるのか？ (Location Map)

「AI解析」と一言で言っても、実は3つの場所で分担して行われます。

機能	AIモデル	実行場所	理由
リアルタイム画像認識 (酒ラベル/お香)	Gemini 2.5	Google Cloud (API)	SynologyにはGPUがないため、高品質な即時応答はクラウド一択です。コスト: 無料枠で十分 (1500回/日)。
写真の意味検索 (CLIP)	Immich (Machine Learning)	Synology Host (Docker)	「猫」「日本酒」などのキーワード検索用の軽量AI。 CPUでも動きます。
夜間のデータ分析 (バッチ)	Ollama	Synology Host (Docker)	例えば「今月の飲酒傾向」などの要約。遅くてもいいので、夜中にCPUをぶん回して無料で行います。

3. 最終構成図 (Memory Optimized)

[ Synology NAS (Total 16GB) ]
├── [ Host OS (DSM) ] -------------- 12GB Use ---------
│   ├── PostgreSQL (Database)
│   ├── Redis (Cache)
│   ├── Immich (Photos + CLIP AI)  <-- Heavy!
│   └── Ollama (Nightly AI)        <-- Heavy!
│
└── [ Guest VM (Ubuntu) ] ---------- 4GB Use ----------
    ├── Dokploy (Manager)
    ├── Sake App API (Container)
    └── Incense App API (Container)

4. 最適化と安全策 (Geminiからの追加提言)

ビジネスレベルの堅牢性を確保するため、以下の戦略を追加採用します。

オフライン時のフォールバック:
- ネット切断時やGemini障害時は、Synology内のOllama で簡易解析を行います（精度は落ちますが、サービス停止は防げます）。
スケジュール制御:
- Immichの重い処理（写真スキャン）は、アプリ利用者がいない 深夜3時 に実行するよう設定します。これによりVMへの影響をゼロにします。
スマート・キャッシュ (Vector Search):
- 単純な画像一致だけでなく、「同じ銘柄の別アングル写真」 をローカルAI（ベクトル検索）で判定し、Gemini APIを節約する仕組みを将来的に導入します。
破産防止 (Quota):
- Google Cloud Consoleで 「1日あたりの予算上限」 を設定済みです。無限ループバグが起きても、破産することはありません。

5. 最後の砦 (Contingency Plan)

万が一、計画通りにいかなかった場合の「プランB」を定義します。

** Dokployがコケた場合**:
- プランB: Portainer + Watchtower に切り替えます。
- 自動化レベルは下がりますが、GUI管理は維持できます。Dokployに固執しません。
メモリがどうしても足りない場合:
- プランB: Immich (3GB) を諦め、Photoprism (1GB) に変更します。
- 機能は似ていますが、Photoprismの方が圧倒的に軽量です。Host側のメモリ枯渇が見えたら即座に切り替えます。

5.1 KiB Raw Blame History Unescape Escape