ホームラボを長く運用していると、機材がいつの間にか増え、配線とサービスが絡み合い、「結局これは何に繋がっているのか」を自分でも即答できなくなる瞬間が来ます。所長の環境も一度その状態に陥り、さらにディスク故障で一式を失った経験から、現在の構成へと組み直されました。
今回は連載「自宅の物理構成」の入口として、個々の手順ではなく全体像を俯瞰します。どんな塊が、なぜそう繋がっているのか。そこさえ掴めれば、続く各回（ネットワーク／ストレージ／計算／電源／無人運用）の位置づけが見えてきます。
設計の三本柱
現在の構成は、三つの方針の上に成り立っています。
- 高速化 — 10Gbps／2.5Gbps を背骨に据える。ボトルネックを配線側に作らない。
- 分離 — 人間が使う機器、サーバ（ラボ）、IoT・家電、公開系を論理的に分ける。事故や侵害の影響範囲を、その区画の中に閉じ込めるためです。
- 可観測性 — 動いているものを常に見える化し、異常を早い段階で掴む。
この三つは互いに支え合っています。速くしても切り分けができていなければ障害は全体に波及しますし、分けても見えていなければ異常に気づけません。
層ごとの全体像
公開して差し支えのない粒度で、上流から順に並べます。
- 回線／ルータ：光回線（IPv6系のIPoE）に、YAMAHA RTX クラスのルータを据えています。
- スイッチング：MikroTik のコア／エッジスイッチで、10GbE／2.5GbE のバックボーンを構成。
- セグメント分離：「人間が使う機器」「サーバ／ラボ」「IoT・家電」「公開サービス」を分けています。サーバ群から人間側・管理側へは原則閉じる思想です（具体的なルールは伏せます）。
- 仮想化基盤：Proxmox を複数台。汎用・監視系・AI検証用と、役割で機材を分けています。
- ストレージ：QNAP NAS を主データ、外付けRAIDをバックアップ域、クラウド（rclone）を遠隔コピーに。いわゆる 3-2-1 の土台です。
- 計算ノード：常時稼働の汎用ノードに加え、GPU計算ノードを2系統。メインは RTX 4090、サブは RTX 3090 Ti クラスです。サブは普段は落としておき、必要なときだけ Wake on LAN で起こします。省電力と能力のトレードオフを、物理で分けています。
- オーケストレータ：常時稼働の小型ノードが、運用の中継役を担います（以前は Mac mini を使っていました）。
- 監視：ダッシュボード（Homepage）に Uptime Kuma、Grafana／Prometheus 系を組み合わせています。
- リモートアクセス：各社の公式アプリで入口を絞り、外からの経路を一本化しています。
なぜ「役割で分ける」のか
要点は、これが「全部盛り」ではなく、役割ごとに機材と経路を分けた構成だということです。理由は三つに集約されます。
- 影響範囲：ある区画でトラブルが起きても、他の区画に波及しにくい。
- 速度：用途の異なるトラフィックを混ぜないことで、必要な帯域を確保しやすい。
- 運用のしやすさ：1台に詰め込まないことで、片方を止めても全体が止まらず、入れ替えや検証もしやすい。
1台に何でも載せる構成は省スペースで手軽ですが、その1台が落ちるとすべてが同時に止まり、検証中の作業が本番に影響する危険もあります。役割で分けるのは、その同時被災を避けるための投資です。
比較：どこまで分けるか
読者の方が実際に迷うのは、「1台にまとめるか、分けるか」という判断だと思います。代表的な選択肢を並べます。
| 観点 | 1台に全部盛り | 役割ごとに分離（本構成） |
|---|---|---|
| 初期コスト | 低い | 高め（台数が増える） |
| 消費電力 | 抑えやすい | 常時稼働分は増える（サブGPUはWoLで節約） |
| 障害の波及 | 1台落ちると全停止 | 区画内に閉じ込めやすい |
| 検証と本番の分離 | 混在しがち | 物理的に分けられる |
| 管理の手間 | 少ない | 台数分だけ増える |
ネットワークも同様に、フラットな1セグメントで通すか、用途ごとにセグメントを切るかで、事故時の被害範囲が大きく変わります。
こう分けるべき人／まだ要らない人
- 分けたほうがよい：公開サービスや検証環境を抱えていて、家族の端末や家電と同じ網に同居させたくない方。一度の故障で全部を失う事態を避けたい方。
- まだ急がない：機材が数台で、止まっても困らない用途しかない場合。先に監視とバックアップを整えるほうが、費用対効果は高いことが多いです。
この構成に行き着いた経緯
現在の整理は、最初から設計されたものではありません。一度ディスク故障で全データを失い、ゼロから作り直す過程で、「混ぜない」「見える化する」「遠隔にコピーを残す」という方針が固まりました。失敗が設計思想に変わった、という順番です。
各回への入口
ここから先は、要素ごとに掘り下げていきます。すでに公開済みの回は、以下から辿れます。
- 監視の作り込み（わざとDownと通知失敗を起こして確かめる手法）は、Uptime Kumaの死活監視はDownと通知失敗を作って見るでまとめています。
- バックアップ（3-2-1の検証）は、resticのrestore／prune／checkを実際に回して確かめた回へ。
- 外からの入口を絞るリモートアクセスは、入口を一本化したリモートアクセスの回を参照してください。
全体像はここまでです。次回以降、ネットワーク・ストレージ・計算・電源・無人運用を順に開けていきます。
この検証を回している環境
この検証は、自宅の常設ラボ（使い捨てVM/LXCを回す母艦＋GPU＋VLAN分離ネットワーク）で動かしています。使っている機材と選定理由、全体構成は1本にまとめています。
ラボ構成のまとめを見る →
