Linux環境で docker compose を使い、複数のWordPressサイトやデータベースをまとめて運用してきた開発者にとって、FreeBSDへの移行は大きなパラダイムシフトを伴います。DockerはLinuxカーネルの機能に依存しているため、FreeBSD上でそのままネイティブ動作させることはできません。しかし、FreeBSDには古くから実績のあるOSレベル仮想化技術 Jail と、極めて堅牢なファイルシステム ZFS が統合されており、適切な設計を行えばDocker以上に安定したマルチテナント環境を構築できます。
本稿では、複数サイトのWordPressをFreeBSD Jailへ移行する際の設計指針と、リバースプロキシやDNSといったエッジ機能を別マシンへ分離する際のハードウェア選定、そしてネットワーク帯域の実態について論理的に整理します。
Linux DockerからFreeBSD Jailへの発想転換
Dockerコンテナは「使い捨て（イミュータブル）」を前提として設計されることが多いのに対し、FreeBSDのJailは「極めて軽量な仮想専用サーバー（ステートフル）」に近い性質を持っています。ホストOSのカーネルを共有しながら、プロセス空間、ファイルシステム、ネットワークスタックを完全に分離できるため、仮想マシン（VM）のような重いオーバーヘッドを発生させずに安全なマルチテナント環境を実現できます。
たとえば4つのWordPressサイトを運用する場合、最も破綻しにくい設計は 各サイトごとにWebサーバー、PHP-FPM、データベースを丸ごと1つのJailに収める「完全分離型」 です。1つのJail内にすべての依存関係が完結しているため、特定サイトのプラグイン不具合やDBクラッシュが他サイトに波及しません。ホストOSのカーネルを共有しているため、プロセスが分かれていてもメモリやCPUの消費は最小限に抑えられます。
この構成を支えるのがZFSの存在です。初期状態のWordPress環境をベースイメージとして用意しておけば、クローン機能によってわずか数秒で新しいテナント用Jailを複製できます。さらに、WordPress本体やPHPのメジャーアップデートを行う直前にスナップショットを取得しておけば、不具合が発生してもミリ秒単位で更新前の状態へロールバックできます。Dockerのイメージビルドとボリューム管理に頼っていた運用が、OSネイティブのストレージ機能だけで完結する点こそがFreeBSD運用の大きな強みです。
エッジ機能（CaddyとDNS）を分離する意義
WordPress群をホストする母艦サーバーを構築する一方で、外部からの通信を受け付けるリバースプロキシ（TLS証明書管理を含む）や、宅内ネットワーク向けのDNSフィルタリングサーバー（AdGuard Homeなど）は、物理的に別のマシンへ切り離す構成が推奨されます。
このエッジ分離を行う最大の目的は 宅内ネットワークの可用性維持とメンテナンス性の向上 です。WordPressをホストする母艦PCでOSの再起動や設定変更、ハードウェア換装を行っている最中でも、DNSサーバーが別マシンで稼働していれば家庭内のインターネット通信が途切れることはありません。
リバースプロキシとして広く使われている Caddy と、DNSサーバーである AdGuard Home は、いずれもGo言語で書かれた単一バイナリの軽量なソフトウェアです。家庭や個人運用のトラフィック規模であれば、両方を常時稼働させてもメモリ消費は数百メガバイト程度、CPU負荷も平常時は数パーセント以下にとどまります。この程度の負荷に対して高性能なPCを割り当てる必要はなく、消費電力の極めて小さい小型マシンが有力な候補となります。
ハードウェア選定における費用対効果の罠
省電力な常時稼働マシンを検討する際、真っ先に候補に挙がりやすいのがシングルボードコンピュータの代表格であるRaspberry Piです。しかし、近年の市場動向を踏まえると慎重な判断が求められます。
初期のRaspberry Piは数千円で購入できる安価な教育・ホビー用ボードとして爆発的に普及しました。しかし世代を重ねるごとに高性能化が進み、Raspberry Pi 4や5では専用の高出力電源、冷却ファン、ケース、安定稼働のためのSSDなどを追加で揃える必要が生じています。その結果、周辺機器を含めた導入コストが1万円台後半から2万円近くに達し、中古の法人向け超小型PC（ThinkCentre TinyやOptiPlex Microなど）やIntel N100搭載ミニPCよりも割高になる逆転現象が起きています。
消費電力の差による電気代だけでこの初期費用の差額を回収しようとすると、5年から10年近く連続稼働させる計算になり、経済的な合理性は薄れてしまいます。手元に余剰のノートPCや小型デスクトップといった機材がすでにあるならば、追加投資をせずに既存の機材を省電力設定にして再利用するほうが、トータルのコストパフォーマンスは圧倒的に優れています。
100Base-TXはボトルネックになるのか
手元に余っている旧型の機材、たとえば Raspberry Pi 3B などをエッジサーバーとして活用しようとする場合、有線LANが100Base-TX（最大100Mbps）である点が懸念材料として浮上します。現代のネットワーク環境において100Mbpsという数値は一見すると非常に遅く感じられますが、処理の内訳を論理的に分解すると、今回の用途では全く問題にならないことが分かります。
第一に、AdGuard HomeによるDNSの名前解決処理は「ドメインに対応するIPアドレス（住所）を端末に教えるだけ」の案内役に過ぎません。DNSの問い合わせパケットは1往復あたり1キロバイト未満の極めて小さな通信であり、宅内の全端末が同時に通信していても消費帯域は1Mbpsにも満たしません。また、一度名前解決が完了した後の動画視聴やファイルダウンロードなどの大容量データは端末とルーターの間で直接送受信されるため、エッジサーバーの中を通過すること自体がありません。
第二に、Caddyを経由するWebリバースプロキシの通信です。こちらは外部からのアクセスデータを実際に中継するためデータが通過しますが、100Base-TXの実効転送能力はおよそ毎秒11〜12メガバイトあります。一般的なWebサイトの1ページあたりのデータ容量を1〜2メガバイトと仮定すると、毎秒5人から10人の訪問者が完全に同時にページをフルリロードし続けてようやく帯域が上限に達する計算です。個人運用のWordPressサイト4つ程度であれば、瞬間的なトラフィックがこの限界に達することは極めて稀です。
数百メガバイトを超える巨大な動画ファイルを直接配布するような用途でない限り、100MbpsのネットワークパイプがWeb表示のボトルネックになることはありません。数値の印象だけで新世代の機材を買い足すのではなく、手元にある旧型資産で稼働させる選択肢は十分に実用的です。
要点のまとめ
- JailとZFSによる強固なマルチテナント: FreeBSD上でのWordPress運用は、サイトごとにWeb・PHP・DBを1つのJailにまとめる完全分離型が安全であり、ZFSのスナップショットやクローンを活用することで柔軟な世代管理と高速展開が可能になります。
- エッジサーバーの物理的分離: Caddy（リバースプロキシ）とAdGuard Home（DNS）を別マシンに逃がすことで、母艦PCのメンテナンス時にも宅内インターネット環境を巻き添えにせず維持できます。
- 高騰したSBCより手持ち資産の活用: Raspberry Pi 4などの最新ボードは周辺パーツを含めると割高になりやすいため、電気代の差額回収を狙って新規購入するよりも、手持ちの旧型機材や省電力化した中古PCを活用するほうが経済的です。
- 100Base-TXでも実用上の問題はない: DNSのデータ転送量は極小であり、Caddyが中継するWebデータ量もテキストや画像中心であれば100Mbpsの実効帯域で十分にお釣りがくるため、旧型のRaspberry Pi 3Bでも性能不足には陥りません。