この5年間、私はすべてのソフトウェア開発を仮想マシン（VM）で行ってきました。プロジェクトごとに専用のVMを用意することで、依存関係の衝突やTCPポートの競合といった面倒から解放されています。

3年前、自作のホームラボサーバーを構築してすべてのVMをそこでホストするようにし、さらに一歩進めました。素晴らしい投資でした。多くの開発作業が高速化し、信頼性も向上しました。

ここ数ヶ月で、VMサーバーの限界に直面するようになりました。プロジェクトがより多くのリソースを必要とするようになり、最初の自作で犯したミスが足を引っ張るようになってきたのです。そこで、2020年版としてまったく新しいホームラボVMサーバーを構築することにしました。

前置きはいいから構築内容を見せてくれ！

このプロジェクトの経緯に興味がなければ、構築内容に直接飛んでください。

なぜわざわざVMサーバーを丸ごと作るのか？

当初は、Windowsデスクトップ上のVirtualBoxでVMを動かしていました。しばらくはそれで問題ありませんでしたが、再起動が大きな手間になるようになりました。

Windows Updateによる強制再起動、ソフトウェアのインストールを完了させるための自発的な再起動、そして時折起こるOSクラッシュのせいで、月に3〜5回は開発用VM一式すべてを再起動しなければなりませんでした。

専用のVMサーバーなら、ほとんどの再起動を回避できます。VMホストは最小限のソフトウェアしか動かさないため、クラッシュや必須の再起動はめったに起こりません。

なぜクラウドを使わないのか？

クラウドサーバーでも同じ役割は果たせますし、ハードウェアを自分で維持する手間（楽しみでもありますが）を省けますが、コストが高すぎます。私のホームラボサーバーと同等のVMリソースをAWS EC2インスタンスで用意すると、年間6,000ドル以上かかります：

必要に応じてクラウドインスタンスを起動・停止すればコストは大幅に削減できますが、ワークフローに摩擦が生じます。ローカルのVMサーバーなら、コストを細かく管理する心配をせずに、10〜20台のVMを常時利用可能な状態で維持できます。

過去の失敗から学んだこと

2017年に組んだサーバーはよく働いてくれましたが、3年間使ってきて、改善すべき重要なポイントがいくつか見えてきました。

1. ストレージはローカルに置く

私のSynology NASは10.9TBの容量があります。これだけネットワークストレージがあれば、「ホストOSの起動に必要な最低限以上のディスクをサーバーに積む必要なんてあるのか？」と考えました。

それは愚かな考えでした。

第一に、ネットワークストレージ上でVMを動かすと、ディスクサーバーへの厳密な依存が生じます。Synologyは2ヶ月に一度くらいのペースでOSのアップデートを公開し、そのパッチは必ず再起動を伴います。VMをSynologyのストレージ上で動かしていると、Synologyのアップデートを適用するたびにVM群全体をシャットダウンしなければなりません。WindowsデスクトップでVMを動かしていた時と同じ再起動問題が再発したのです。

第二に、ネットワーク越しのランダムなディスクアクセスはとにかく遅いのです。初代を組んだ当時は、バックエンドのPythonやGoアプリケーションが中心で、大きなディスクI/Oは発生しませんでした。しかしその後、フロントエンドのウェブ開発にも手を広げるようになりました。最近のウェブフレームワークはどれもNode.jsを使っており、どのプロジェクトでも依存関係ツリーに1万〜20万ものランダムなJavaScriptファイルが含まれます。Node.jsのビルドでは大量のランダムディスクアクセスが発生し、これはネットワークストレージにとって最悪のシナリオです。

2. より良いVM管理ソフトウェアを選ぶ

初代サーバーでは、VM管理にKimchiとVMWare ESXiの2つの選択肢を検討しました。VMWareの方がはるかに洗練され成熟していましたが、Kimchiの泥臭い気概とオープンソースという点に惹かれました。

インストールした直後に、Kimchiの開発は止まってしまいました。

時間が経つにつれ、Kimchiの欠点はどんどん明らかになっていきました。VMの「クローン」や「シャットダウン」ボタンを何度もクリックしないと反応しないこともよくありました。そして、クリックする直前にボタンが消えたり位置がずれたりする、腹立たしいUIのバグもありました。

3. リモート管理を見越して計画する

上の内容を読んで、「Kimchiなんてただのソフトウェアじゃないか。なぜ別のVMマネージャーをインストールするためだけにサーバー全体を作り直す必要があったのか？」と思った方もいるでしょう。それは私がリモート管理の重要性を予見できていなかったからです。

私のVMサーバーは、オフィスの隅にモニターもキーボードも繋がずに置かれた、ただのPCです。SSHやウェブインターフェースでアクセスできる99%の場合はそれで十分です。しかし、サーバーが起動に失敗したり、新しいホストOSをインストールしたいといった残り1%の場合には、とても面倒なことになります。サーバーを机まで引きずってきて、デスクトップのキーボードとモニターを取り外し、直すべき箇所を修正してから、オフィスのすべてを元の配置に戻さなければならないのです。

次の構築では、電源を入れた瞬間から物理レベルのアクセスが可能な仮想コンソールが欲しいと思いました。DellのiDRACやHPのiLOのようなものを考えていました。

パーツ選び

CPU

初代VMサーバーのCPUはRyzen 7 1700でした。8コア16スレッドで、当時は話題の最新CPUでした。しかし、Redditのホームラボコミュニティである/r/homelabで自作を披露したところ、コンシューマー向けパーツを使ったことでにわか扱いされ、からかわれました。本格派はエンタープライズ向け機器を使うのだそうです。

二度と/r/homelabに馬鹿にされないと心に誓い、エンタープライズ向けサーバーハードウェアの世界に足を踏み入れました。奮発して2つの物理CPUを搭載するシステムを組むことにしました。

コストパフォーマンスを最大化するため、4〜8年前に発売された中古CPUに絞って探しました。候補ごとにPassMarkでベンチマークスコアを調べ、eBayでそのCPUモデルが中古でいくらで取引されているかをチェックしました。

最もコスト効率が良いのはIntel Xeon E5 v3ファミリー、特に2600番台のようでした。最終的にE5-2680 v3に決めました。平均ベンチマークは15,618で、eBayでの中古価格は約130ドルでした。

参考までに、前回のRyzen 7のベンチマークは14,611でした。つまり、デュアルE5-2680なら旧サーバーから2倍以上の処理能力になります。

マザーボード

デュアルCPUシステムの欠点は、マザーボードの選択肢が限られることでした。デュアルIntel 2011-v3 CPUをサポートするマザーボードはほんの一握りで、価格は300〜850ドルと、マザーボードに払うには想像以上に高額でした。

私はSuperMicro MBD-X10DAL-I-Oを選びました。320ドルと同クラスのマザーボードの中では安い方でしたが、それでも前回買ったものの5倍の価格でした。

メモリ

サーバー用メモリについては、情報に基づいた選択肢がかなり少ないように思えます。コンシューマー向けハードウェアなら、さまざまなRAMのレビューやベンチマークを掲載するサイトがたくさんありますが、サーバー用RAMではそういったものは見当たりませんでした。

ブランドへの信頼からCrucial CT4K16G4RFD4213 64GB（16GB×4）にしました。64GBにしたのは、前回の構成が32GBで、一部のワークフローではその上限に近づいていたため、今後数年は倍の容量で十分だろうと考えたからです。

ストレージ

私はM.2 SSDが大好きです。小さく、性能は抜群で、ケーブルなしでマザーボードにすっきり収まるからです。残念ながら、MBD-X10DALはM.2インターフェースに対応していません。

代わりに、昔ながらのSATAに落ち着きました。1TBのSamsung 860 EVOを購入しました。普段はVM1台あたり40GBの領域を割り当てているので、1TBあれば十分な余裕があります。足りなくなれば、いつでも追加のディスクを買えばいいのです。

電源

電源ユニット（PSU）選びはそれほど面白いものではないので、ここでも信頼できるブランドという基準でCorsair CX550M 550W 80 Plus Bronzeを選びました。

各パーツの消費電力を合計すると400Wだったので、450Wでも十分でした。しかし550W版は10ドルしか高くなかったので、100Wの余裕としては妥当な価格に思えました。

私にとって他に重要だったのはセミモジュラーケーブルでした。前回の構築では非モジュラーケーブルを使ってしまい、すべてのPSUケーブルが常時接続されたままになるという失敗をしました。サーバーには内部コンポーネントがほとんどないため、余分な電源ケーブルがごちゃごちゃしてしまいました。セミモジュラーなら、使わないケーブルをPSUから外してすっきりさせられます。

ファン

デュアルCPU構成にしたことで、冷却が予想外の課題になりました。MBD-X10DALは2つのCPUソケット間のスペースがあまり広くないため、並べて設置できる薄型のファンを慎重に探しました。Cooler Master Hyper 212が2つ並べてぴったり収まりました。

ケース

私のサーバーはオフィスの隅に目立たず置かれているので、透明パネルや派手なライトが付いたケースは避けたいと思いました。

Fractal Design Meshify C Blackは評判が良く、シンプルで静かなケースのようでした。

グラフィックス

ヘッドレスサーバーではグラフィックカードはそれほど重要ではありません。初期インストール時や時折のデバッグで画面を見るために必要ではあるので、手頃で手軽な選択肢としてMSI GeForce GT 710にしました。

リモート管理

リモート管理ソリューションを調べましたが、その高さに驚かされました。当初はDellのiDRACを使おうと考えましたが、リモートコンソールには300ドルのエンタープライズライセンスが必要で、構成もDell製パーツに縛られます。KVM over IPソリューションも調べましたが、さらに高く600〜1,000ドルもしました。

リモート管理を実現するために、私は変わったアプローチを取り、Raspberry Piで自作のKVM over IPデバイスを作りました。TinyPilotと呼んでいます。

TinyPilotはHDMI出力をキャプチャし、ブラウザからのキーボード・マウス入力を転送します。物理的に本物のキーボード、マウス、モニターを直接繋いだのと同じアクセスが得られます。ソフトウェアはオープンソースで、完成品も購入できます。

2020年版サーバーの構成

VM管理： Proxmox

VMの管理にはProxmox VEを使っています。

前回の自作でKimchiに痛い目を見たので、別の無料ソリューションを試すのには慎重になっていました。Proxmoxは12年の歴史があるので、十分安心できると感じました。見た目はKimchiから大きく進化していますが、洗練度ではESXiに及びません。

Proxmoxで最も気に入っているのはスクリプトで操作できる点です。私のよくある作業は、テンプレートから新しいVMを作成し、Ansibleで追加のソフトウェアをインストールすることです。ESXiでは、毎回ウェブUIで手作業でボタンをクリックせずにこれを行う方法が見つかりませんでした。ProxmoxではCLIが非常に強力なので、./create-vm whatgotdone-devと実行するだけで、スクリプトがWhat Got Doneの開発用VMを新規に作成してくれるまでに自動化できています。

最大の不満は、Proxmoxが直感的でないことです。Craft Computingのインストールチュートリアルを見つけるまで、インストール方法すら分かりませんでした。しかし一度使い方を覚えてしまえば、簡単に使えます。

ベンチマーク

旧VMサーバーを退役させる前に、性能向上を測るために普段のワークフローの簡単なベンチマークを取りました。

旧サーバーのVMのほとんどはネットワークストレージ上で動いていました。ローカルSSDには数台分の空きしかなかったためです。以下のベンチマークでは、3つのシナリオで性能を比較しています：

• 2017年版サーバー（NAS）：ネットワークストレージ上に置いていた典型的なVM
• 2017年版サーバー（SSD）：ローカルストレージに置いていた数少ないVM
• 2020年版サーバー：すべてのVMをローカルSSD上で実行するため、NASとSSDの区別なし

新しいVMのプロビジョニング

最初に計測したのは新しいVMのプロビジョニングでした。私はほぼすべてのVMで使う標準的なUbuntu 18.04のVMテンプレートを持っています。新しいVMが必要になるたびに、以下のステップを実行するシェルスクリプトを動かしています：

1. ベーステンプレートからVMをクローンする。
2. VMを起動する。
3. ホスト名をubuntuからVMの名前に変更する。
4. 新しいホスト名を反映させるためにVMを再起動する。
5. apt update && apt upgradeで最新のソフトウェアを取得する。

新しいサーバーではこのワークフローが大幅に高速化しました。VMのクローンは旧サーバーでは15分かかっていましたが、新サーバーでは4分未満になりました。

パッケージのアップグレード手順を省くと、高速化の度合いは少し控えめになります。新サーバーでもNASストレージとの比較では依然として圧倒的で、8分から2分半弱まで短縮されました。SSD同士で比べると、むしろ旧サーバーに負けています。VMのクローンはおそらくディスクに依存する処理で、旧サーバーのM.2 SSDの方が新しいSATA SSDより高速だったためでしょう。

VMの起動

VMの電源を入れた瞬間から、ログイン画面が表示されるまでどれくらいかかるでしょうか？

旧サーバーのVMは48秒で起動しました。旧システムでもSSD上の数少ないVMは少し速く、32秒でログイン画面が表示されました。新しいサーバーはそのどちらも大きく上回り、わずか18秒でVMが起動します。

What Got Doneのエンドツーエンドテストを実行

私の週刊ジャーナルアプリであるWhat Got Doneには、機能をエンドツーエンドで検証する自動テストがあります。これは私のワークフローの中でも最も多様なものの一つで、Goバックエンドのコンパイル、Vueフロントエンドのコンパイル、一連のDockerコンテナのビルド、そしてChromeを自動操作してアプリを検証することが含まれます。これは旧VMではリソースを使い果たしていたワークフローだったので、大幅な向上を期待していました。

驚いたことに、2つのサーバー間で大きな性能差はありませんでした。コールドスタート（すべてのDockerベースイメージをダウンロードする場合）では、新サーバーの方が旧サーバーより2%遅くなっています。ベースのDockerイメージがローカルにある場合は新サーバーが旧サーバーを上回りますが、それでも6%差に過ぎません。ボトルネックは主にディスクとブラウザのやり取りにあるようで、新サーバーにしても大きな違いはありませんでした。

Is It Ketoのビルド

私の頻繁なワークフローの一つに、ケトジェニックダイエット向けリソースであるIs It Ketoのビルドがあります。Vue用の静的サイトジェネレーターであるGridsomeを使ってサイトを生成しています。

ここでは大幅な高速化を期待していたので、ビルドが遅くなったのには驚きました。旧サーバーでは主にCPUバウンドに見えたビルドでしたが、新サーバーでCPUリソースを2倍にしても効果はありませんでした。次にディスクがボトルネックかと考え、ファイルをRAMディスクに移してみましたが、ビルド速度は変わりませんでした。

私の仮説では、このワークフローはCPUバウンドではあるものの、並列化の効率が悪いということです。旧サーバーはCPUコア数は少ないものの、1コアあたりの性能は上です。ビルドが5〜6スレッド程度にしか並列化できないのであれば、新サーバーの48コアを活かせないのです。

新しいZestfulモデルの学習

Zestfulは、レシピの材料を解析するための機械学習ベースのAPIです。数ヶ月に一度、新しいデータで学習させています。これは私のワークフローの中で最もCPUを大量に使うものなので、新システムがどう処理するか興味がありました。

ついに、私の48 CPUコアが真価を発揮するケースです！新サーバーは旧サーバーを圧倒し、モデルの学習を半分以下の時間で完了しました。残念ながら、このワークフローは年に数回しか実行しません。

振り返り

コンシューマー向けハードウェアも恥ではない

/r/homelabからはいつまでも尊敬されないかもしれませんが、次回はコンシューマー向けハードウェアに戻すつもりです。

サーバー向けコンポーネントの最大の利点は、サーバー用ソフトウェアとの互換性が高いことだと思います。2017年当時は、CPUのマルチスレッドを無効にしないとESXiをインストールできず、性能が大幅に低下しました。しかし、それはLinuxカーネルの制限によるもので、後のアップデートで修正されました。

サーバー向けハードウェアが高価なのは、信頼性が高いからです。ユーザー向けサービスではこの特性は重要ですが、開発サーバーではそれほど重要ではありません。開発サーバーでたまにクラッシュやビット反転が起こっても、一日が台無しになることはないでしょう。

デュアルCPUの総コストを考える

デュアルCPUのPCを自作するのは今回が初めてでした。興味深い経験でしたが、苦労に見合う価値はなかったと思います。

ベンチマークを見る限り、CPUがボトルネックになることはほとんどありませんでした。最も分かりやすい証拠は、ProxmoxのCPU使用率の推移グラフです。ここ数ヶ月、CPU負荷が11%を超えたことは一度もないので、明らかにオーバースペックです。

デュアルCPUという要件がマザーボードのコストを大幅に押し上げ、選択肢も限定しました。デュアルIntel 2011-v3 CPUをサポートするマザーボードはごくわずかしかないため、他のマザーボード機能の面でも選択肢は多くありませんでした。

リモート管理がもたらす柔軟性

TinyPilotでサーバーを管理するようになるまで、自分がどれだけ変化を嫌っていたかに気づきませんでした。BIOSやネットワーク設定を変更すると、物理的にマシンを移動させたり周辺機器を繋ぎ直してデバッグや修正に数時間を費やすリスクがありました。そう思うと、そういった設定を変更する気にはなれませんでした。

仮想コンソールがあることで、失敗する自由が得られ、さまざまなOSを試すことにも前向きになれます。新しいOSのインストールや習得には常にそれなりの労力がかかりますが、マシンをあちこち移動させる必要がないと分かれば、ずっと気軽に挑戦できます。TinyPilotを作っていなければ、「十分良い」としてESXiを使い続け、Proxmoxに挑戦することはなかったかもしれません。

1年後

読者から、この構成で後から変えたい点はあるかと尋ねられたので、サーバーを使い始めて1年と少し経った時点でのアップデートを共有したいと思います。

CPU ― 過剰すぎた

デュアルE5-2680 v3は明らかにやりすぎでした。

1年間の使用で、CPU使用率が100%に達したことは一度もなく、50%を超えたのもほんの数回だけだったので、1つのCPUでも十分でした。

SSD ― 足りなかった

1TBのSamsung SSDはほぼ満杯になったので、2TBのSamsung 870 Evoを追加購入し、合計3TBのSSDにしました。ケースにはさらにSSDを追加する十分なスペースがあります。

デフォルトではVMごとに40GBのディスクを割り当てていますが、時にはそれでは足りません。Dockerを使った作業では、コンテナイメージがすぐにディスクを食い尽くします。数週間ごとにVMのディスクが満杯になり、docker system prune --allを実行しなければならないので、追加のディスクでそういった中断がなくなるはずです。

RAM ― 少し足りなかった

64GBのRAMはほぼ十分でしたが、メモリを確保するためにVMを停止しなければならない場面が何度かありました。リソース管理でワークフローを中断したくないので、同じRAMスティックをさらに64GB追加で注文しました。

Proxmox ― 今でも素晴らしい

VMマネージャーとしてProxmoxは今でも気に入っています。ライセンスも購入しましたが、使っている機能で何か新しいことが追加されたかは分かりません。ただ、プロジェクトを支援できて嬉しく思っています。

困ったことに、ライセンスはCPUごとに課金されるため、CPUを買いすぎた恥に加えて、Proxmoxにも2倍の料金を払わなければなりません。

パーツリスト（2021-12-05時点）

* 当初の構築から1年後に購入。