104 lines
5.1 KiB
Markdown
104 lines
5.1 KiB
Markdown
|
# 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)
|
|||
|
|
|
|||
|
|
```yaml
|
|||
|
|
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:**
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
# 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がないため、高品質な即時応答はクラウド一択です。<br>コスト: 無料枠で十分 (1500回/日)。 |
|
|||
|
|
| **写真の意味検索** (CLIP) | **Immich (Machine Learning)** | **Synology Host (Docker)** | 「猫」「日本酒」などのキーワード検索用の軽量AI。<br>CPUでも動きます。 |
|
|||
|
|
| **夜間のデータ分析** (バッチ) | **Ollama** | **Synology Host (Docker)** | 例えば「今月の飲酒傾向」などの要約。<br>遅くてもいいので、夜中に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側のメモリ枯渇が見えたら即座に切り替えます。
|