はじめに

私事の忙しさが一段落し、ようやく余暇を得ることができたため、セルフホストサービスの移行計画に再び着手しました。サーバーを直接自宅に設置することで、技術的な探求と実験の幅を広げるとともに、深い知識を習得する絶好の機会となります。こうした背景から、工業用マイクロコンピューターを購入し、サーバーとして設定することを決定しました。自らの手で管理し、カスタマイズする楽しさに加え、新たな技術的な挑戦に対する期待感が高まっています。

2024年の途中、Dockerへのサービス移行を試みましたが、Docker Composeとサーバー保守の知識不足に加え、体調不良も重なり、作業を中断せざるを得ませんでした。この時期に時間を有効活用し、ようやく作業をほぼ完成させることができました。自身の技術的な成長とサービス構築のポイントを振り返るために、この記事を書きました。

この記事シリーズでは、サーバーを自宅で設置するまでの初歩的な過程、つまりハードウェアの選定からサービスアーキテクチャの構築に至るまでの詳細を、順を追って説明していきます。この移行は、技術的な見地だけでなく、私の個人的な成長にとっても一大事業であるため、その一部始終を共有することで、同じ道を歩もうとする他の技術愛好者の皆さんにも役立つことを願っています。

ハードウェアの選定

選択したハードウェア

ハードウェア選定にあたっては、ホームサーバーであるため、24時間365日の稼働を目指します。また、自宅でサーバーを設置する場合、電気代は自己負担となるため、消費電力を最小限に抑えることも重要です。さらに、部屋の空間が限られているため、サーバー筐体のサイズや稼働時の騒音も考慮する必要があります。また、ホストするサービスは高スペックを必要とせず、予想されるアクセス数も多くないため、これらの要件を総合的に考慮し、最終的にTaobao（タオバオ）で工業用マイクロコンピューターを購入し、ホームサーバーの本体としました。スペックは以下の通りです。

価格：CNY ￥948 (約JPY ￥20299.89) (2024/11/05の時点)

プロセッサー：Intel® Celeron® J6412
グラフィックス：Intel® UHD Graphics for 10th Gen Intel® Processors
メモリー：8G DDR4（ブランドが不明）
ネットワークインターフェース：Realtek Semiconductor Co., Ltd. RTL8111/8168/8411
ストレージ：256G mSATA（ブランドが不明）
ポート：
- USB 3.0 x 2 + USB 2.0 x 2
- DP (バージョン不明) x 1 + HDMI (バージョン不明 x 2)
- ネットワークインターフェース 1000 BaseT x 2
- COMシリアルポート x 2
- Audio x 1 + Mic x 1
- SODIMM x 1
- M.2 x 1 + mSATA x 1
- WiFi (PCIe) x 1

マイクロコントローラーの外観：

マイクロコントローラーの内部：

もし、私と同じようにTaobao（タオバオ）から工業用マイクロコンピューターを購入してサーバーを構築しようと考えており、中国大陸以外にお住まいの方であれば、現地の電気規格に特に注意が必要です。本体に同梱されている電源コード（トランスフォーマー）は、お住まいの地域の電気規格に合わない場合が多々あります。そのため、Taobao（タオバオ）または地元の店舗で、同じ出力仕様を持ち、現地の電気規格に適した電源コード（トランスフォーマー）を別途購入する必要があります。

使用感想（半年後）

約半年間、工業用マイクロコンピューターをホームサーバーとして運用した結果、いくつかの重要な気づきと改善点が得られた。

静音性と放熱性能について

購入したモデルは被動散熱（ファンレス設計）であり、動作音が一切発生しない点は非常に快適であった。特に1Kや寝室といった生活空間内で設置する場合、静音性の重要性を実感する場面が多かった。家庭内ネットワーク向けに軽負荷なサービスを提供する限り、放熱性能に問題はなく、被動散熱の利点を十分に享受することができた。

しかし、運用が進むにつれて、サービスの数が増加し、外部からのアクセスを許可するようになると、負荷の増加に伴い、放熱性能の不足が徐々に問題となった。特に夏季には、サーバー内部の温度が過度に上昇し、稀にシステムが自動シャットダウンする事態が発生した。

改善策：簡易的なアクティブ冷却

これらの課題に対処するため、PC更新時に余ったNoctua NF-A15ファンを再利用し、USB-PWM変換ケーブルを用いて外部電源から回転数を調整可能な簡易的なアクティブ冷却システムを構築した。図が以下です：

見た目は少しジャンク感がありますが、その効果は抜群。温度が大幅に下がった上、騒音もほとんど感じません。さすがNoctuaさんといったところです！

今回の経験から得られた知見

本経験を通じて、被動散熱タイプの小型サーバーを選択する際には、運用するサービスの負荷を事前に正確に見積もることの重要性を改めて実感した。以下に、実際の運用状況に基づくおすすめの選択基準を示す：

家庭内ネットワーク限定の場合：
軽負荷なサービス（例：NAS、DLNA、スマートホーム制御など）のみを運用する場合、被動散熱モデルで十分対応可能である。
外部アクセスを伴う場合：
公開サービスを提供する場合や、潜在的なアクセス数が多い環境では、放熱性能の強化が必要となる。事前に冷却方法を計画するか、初めから静音性の高いアクティブ冷却モデルを選択するのが望ましい。

UPS（無停電電源装置）の導入について

ホームサーバーの安定稼働を実現するためには、UPS（無停電電源装置）の導入が重要である。予期せぬ停電や電力品質の問題は、サーバーの正常な稼働に深刻な影響を与える可能性がある。こうしたリスクを軽減するため、UPSは短時間ながら安定した電力を供給することで、サーバーを安全にシャットダウンする猶予を与える。これにより、ストレージ損傷やOSクラッシュといった致命的な問題を未然に防ぐことが可能となる。

また、一部のUPSモデルには、電源波形を安定させ、ノイズや突発的な電圧変動を吸収する機能が備わっている。これらの機能により、サーバーやネットワーク機器にかかる電気的負荷を軽減し、機器の寿命を延ばす効果が期待できる。特に24時間365日稼働するホームサーバーでは、こうした電源品質の改善が長期的な投資効率向上に寄与する。

UPS選定のポイント

UPSを導入する際には、いくつかの重要なポイントを考慮する必要がある：

1.電池タイプの選択

UPSに使用されるバッテリーには主に鉛蓄電池（VRLA）とリチウムイオン電池の2種類がある。それぞれの特徴を以下にまとめる：

鉛蓄電池（VRLA）：
初期コストが低い点が最大のメリットである。ただし、寿命が短く、定期的な交換が必要なため、維持管理コストがかさむ場合がある。また、使用状況によっては劣化が早まるため、定期的な点検と交換が欠かせない。
リチウムイオン電池：
高いエネルギー密度を持ち、同等容量でより軽量・コンパクトな設計が可能。さらに、寿命が長くメンテナンスの頻度が低いという特徴がある。初期コストは鉛蓄電池より高いものの、長期的な維持費用や交換の手間を考慮すれば、トータルコストパフォーマンスで優位性がある。また、環境負荷が低い点も魅力的である。

2. 静音モデルと商用モデルの選択

UPSには「静音モデル」と「商用モデル（非静音モデル）」の選択肢がある。それぞれの特徴と適切な用途を以下にまとめる：

静音モデル：
- 利点：ファンや動作音が極めて静かで、リビングや寝室といった静音性が求められる場所に適している。また、家庭向けに設計されたモデルはコンパクトで軽量な傾向があり、設置場所を選びにくい。
- 欠点：静音設計のため、放熱性能や負荷耐性が商用モデルほど高くない場合がある。特に高負荷時や長時間連続運転時には注意が必要。
商用モデル（非静音モデル）：
- 利点：高い冷却性能を持ち、大容量バッテリーを搭載しているため、サーバーラックやデータセンターなど高負荷環境での運用に適している。また、停電時のバックアップ時間が長く、多数の機器を同時に接続可能なモデルも多い。
- 欠点：動作中にファンの回転音が発生するため、騒音が気になる環境には不向き。さらに、商用向けモデルは家庭向けに比べて大きく重い場合が多い。

3. 設置場所と騒音の考慮

UPSを設置する際には、設置場所に応じたモデル選定が重要である：

リビングや寝室：静音モデルが最適である。小型で動作音が静かなため、日常生活に影響を与えない。
専用ラックや作業部屋：商用モデルが適している。高負荷対応の冷却性能と長時間バックアップが必要な場合、商用モデルの方が信頼性が高い。
その他の注意点：UPSを設置する場所は、通気性が良く、湿度や温度が適切な環境を選ぶ必要がある。特に高温多湿の場所では、機器寿命が著しく短くなる可能性があるため避けるべきである。

サービスアーキテクチャ

サービスアーキテクチャに関して、先述のDocker Composeでの失敗を踏まえ、単一のDocker Composeファイルによる設計は不合理であることが明らかになりました。そこで、メンテナンスが少なくLTS（Long Term Support）バージョンのサービスはローカルに実装し、頻繁なアップグレードやメンテナンスが必要なサービスはDockerを用い、Web UIを介して管理することにしました。サービスアーキテクチャの全体像は以下の通りです。

サービス全体では、CloudflareのDNS名前解決サービスを使用して基本的なセキュリティを確保しています。さらに、CloudflareのZero Trustを活用し、特定のプライベートサービスへのアクセスを制御しています。また、ホームサーバーに実装したddclientをCloudflareと連携させ、DDNSを実現しています。さらに、ホームサーバーではローカルに設置したNginxを使用し、リバースプロキシを介してサービスを提供しています。大まかなアーキテクチャは以上の通りですが、実装の詳細は次回の記事で解説します。