Ubuntu 16.04からFreeBSDへ：10年にわたる移行の旅

多くの開発者にとって、個人のブログや小規模なプロジェクトサーバーは、「一度設定したらあとは放置」というインフラになりがちです。ある開発者にとって、これはUbuntu 16.04 LTS上で10年以上稼働し続けるブログという結果をもたらしました。このシステムは、公式サポートが終了してから5年が経過していました。サーバー自体は驚くほど安定していましたが、パッチの当たっていないカーネルや古いリポジトリを使い続けることによるセキュリティリスクは、最終的に無視できないほど大きくなりました。

この移行は単なるOSのアップデートではありませんでした。より良い価格設定のためにDigitalOceanからHetznerへ移行し、さらに、その安定性、統合された設計、そして強力な仮想化機能で高く評価されているFreeBSDを試す機会でもありました。

移行の動機：セキュリティとコスト

サポート終了（EOL）のディストリビューションを使用し続けることは、aptパッケージリポジトリが更新されなくなることを意味し、既知の脆弱性に対してシステムを無防備にします。著者は、重大な侵害は発生していないと述べていますが、ボットが不正なリンクを注入したり、ノードを侵害したりするリスクは、オープンなウェブ上では常に存在する脅威です。

セキュリティに加え、この移行は大幅なコストパフォーマンスの向上をもたらしました。元のDigitalOceanのドロップレット（2GB RAM, 1 vCPU, 50GB disk）は月額13ドルでした。対照的に、CPUとメモリが2倍になった、より強力なHetznerのVPSは、月額6ユーロ未満で取得できました。これにより、計算能力を増やしながら、月間のコストを半分以下に抑えることができました。

なぜFreeBSDなのか？

他のLinuxディストリビューションではなくFreeBSDを選択した理由は、システム管理における異なるアーキテクチャ的アプローチを試したいという欲求からでした。FreeBSDを特に魅力的にした2つの主要な機能があります。

1. FreeBSD Jails

Jailsは、Dockerが登場する数十年も前から存在するOSレベルの仮想化技術です。Dockerがアプリケーションのパッケージングのための使い捨てで不変的なコンテナに焦点を当てているのに対し、Jailsは同じカーネルを共有する「ミニVM」のように機能します。Jailsはサブシステムに対して堅牢なサンドボックスを提供し、各サイトを独自の隔離された環境で実行させることができます。

2. ZFS (Zettabyte File System)

ZFSは、高度なデータ整合性とスナップショット機能を提供します。VPSユーザーにとって、これはプロバイダー独自のバックアップシステムに頼ったり（そしてその費用を支払ったり）することなく、頻繁にシステムスナップショットを取得できることを意味します。

新しいスタックの設計

目標は、中央のリバースプロキシによって管理される、各ウェブサイトが独自のJail内で動作するモジュール式環境を作成することでした。

Bastilleによる管理

手動でのJail作成の複雑さを簡素化するために、著者はBastilleを使用しました。これは、Jailの作成、一覧表示、管理を行うための合理化されたCLIを提供する管理フレームワークです。

ネットワーク層

Jails間で通信を可能にするために、仮想ネットワークインターフェース（bastille0）が作成されました。その後、ネットワークスタックはFreeBSDのファイアウォールである**PF (Packet Filter)**を使用して保護され、アウトバウンドトラフィックのNAT処理、および、ウェブサーバー用に予約された特定の内部IPアドレスへのインカミングHTTP/HTTPSトラフィック（ポート80および443）のリダイレクト処理が行われます。

ウェブ層：CaddyとNginx

すべてをNginxで行うのではなく、著者はプライマリなエントリーポイントとしてCaddyを実装しました。Caddyは、その自動SSL証明書管理機能により、手動のcertbot更新の必要性を排除するために特別に選ばれました。

結果として構築されたアーキテクチャ:

  • Caddy Jail: リバースプロキシとして機能し、SSLとトラフィックのルーティングを処理します。
  • Site Jails: 各サイト（例：Hugoで生成されたブログ）は、独自のJail内でNginxを動かして静的コンテンツを配信します。
  • Host System: gitリポジトリを保持し、nullfsを介して特定のディレクトリをJailへ読み取り専用としてマウントします。これにより、Jailsがソースファイルを変更できないようにします。

パフォーマンス・ベンチマーク

新しいセットアップを検証するために、著者はwrkとheyを使用して、複数のグローバルリージョン（London, São Paulo, Silicon Valley, and Tokyo）にわたって広範な負荷テストを実施しました。

結果

パフォーマンスの差は歴然でした。高負荷（10kの同時リクエスト）のテストでは、古いUbuntuサーバーは非常に苦戦し、リクエストの約7%しか完了できませんでした。FreeBSDサーバーは、kern.ipc.somaxconn（ソケットキューのサイズ）を増やすための素早いsysctlの調整を行った後、リクエストの94%を成功させることができました。

生のスループットに関しては、新しいサーバーは、1秒あたりのリクエスト数（RPS）において、古いサーバーの3倍から11倍の性能を発揮しました。

利益の分析

結果は素晴らしいものでしたが、著者は、その向上は単なるOSの違いだけでなく、いくつかの要因が組み組み合わさった結果である可能性が高いと述べています。

  • ハードウェア: 1 vCPUから4 vCPUsへ移行したことで、より多くの同時並行処理が可能になりました。
  • 設定: 古いUbuntuシステムは、高負荷シナリオにおいて設定が誤っていた可能性があります。
  • インフラストラクチャ: 新しいテストは、新しいサーバーと同じデータセンター内から実行されたため、レイテンシが減少しました。

コミュニティの視点と反論

この移行は、Hacker Newsコミュニティの間で議論を議論を巻き起こし、サーバー管理の哲学の違いを浮材にしました。

ベンチマークについて: 一部のユーザーは、ベンチマークが偏っていると主張しました。現代的で適切に設定されたUbuntuのインストールであれば、FreeBSDと同様、あるいはそれ以上に高い性能を発揮する可能性があるからです。

ホスティング戦略について: 一部の批判的なユーザーは、静的なHugoサイトをVPSにホスティングすることは、GitHub PagesやS3 + CloudFrontのような、無料で、世界的に分散されたオプションを使用することと比較して「客観的に劣っている」と指摘しました。

「設定して放置」の罠について: 多くのユーザーが、長期間稼働し続けるサーバーの更新に対する恐怖に共感しました。あるユーザーは、高いアップタイムの危険性について次のように述べています。

"The biggest mistake I made was high uptime... by the time they wanted to sunset the machine underlying I had no idea what my teenage selfが何をセットアップしたのか分からなくなっていました。"

最終的な教訓

10年ほど前のUbuntuサーバーから現代的なFreeBSDセットアップへ移行したことは、Linuxが業界標準である一方で、BSDエコシステムが、OSの内部構造をいらじりながらいじりながら楽しむ人々にとって、やりがいのある、クリーンで統合された体験を提供することを示しています。

開発者にとっての主な教訓は、Ubuntuサーバーが非常に堅牢であった（1,491日のアップタイムを誇っていた）ものの、手動での移行を通じてネットワーク、ファイアウォール設定、仮想化を学ぶプロセスは、非常に貴重な技術的な演習となりました。

Sources