FreeBSD開発に対する1年間の支援
(daemonology.net)- Amazonの支援を受け、1年間 FreeBSDリリースエンジニアリング と FreeBSD/EC2 開発を進めた
- リリース管理 と EC2 関連の改善を並行しながら、月平均50時間の作業時間を投入した
- Gravitonインスタンスの電源管理、ホットプラグ対応、起動性能改善など、主要機能の問題解決と品質向上を達成した
- AMIの種類拡張 とビルド自動化により、FreeBSD AMI 配布の多様性と効率を高めた
- 支援終了後は、開発速度の鈍化と一部機能開発の停滞が予想される
FreeBSD開発支援の1年を振り返る
# 開始の背景と支援に至る経緯
- 2010年から FreeBSD/EC2 プラットフォームを管理しており、2023年11月からは FreeBSD リリースエンジニアリングのリード役も務めている
- Antithesis、Patreon などから少額の支援は受けていたが、リリースエンジニアリング業務が FreeBSD/EC2 開発時間を大きく圧迫する状況に直面していた
- Amazon 側とは数年にわたり EC2 作業に対するスポンサーの話し合いを続けており、2024年4月に予算確保担当者とつながって、1年間の支援を受けることになった
- 支援は GitHub Sponsors 経由で実施され、Amazon が意図した期間と実際の入金時期は異なる場合がある
# 支援と作業時間の配分
- Amazon の要請により、毎月40時間 の FreeBSD リリースエンジニアリングおよび EC2 開発時間を提供することを約束した
- 実際には月ごとに50時間程度を投入し、EC2 の課題に20時間、リリース作業に20時間、その他のエンジニアリングに10時間を配分した
- 月ごとの作業時間には大きな変動があった
# FreeBSDリリース管理
- FreeBSD の四半期リリース日程を導入・管理しながら、1年間で4回のリリースを実施した: FreeBSD 13.4(2024.9)、14.2(2024.12)、13.5(2025.3)、14.3(2025.6予定)
- 各リリースには、開発者へのコード締め切りの督促、マージ要求の承認と調整、イメージのビルド・テスト、案内文の作成、各種リリースビルドエラーの修正が含まれる
- リリースエンジニアリングに要した時間は四半期ごとに33.5〜79時間程度で、後半に進むほど安定化により作業量が減少する傾向だった
# 主なEC2機能改善と品質向上
Gravitonインスタンス電源ドライバ、ホットプラグ対応
-
Graviton インスタンスで、EC2 API の正常終了シグナルを FreeBSD が認識できなかった問題を解決した
- ACPI _AEI オブジェクトを活用し、GPIO ベースの "power button" シグナルとドライバロジックを接続した
- EC2 提供 ACPI テーブルの Pull Up フラグ設定不一致によるデバイス無効化問題には、FreeBSD/EC2 AMI に ACPI_Q_AEI_NOPULL 設定を追加して対応した
-
EC2 Graviton および x86 インスタンスのデバイス ホットプラグ（特にホットアンプラグの問題） を複合的に診断・修正した
- IRQ リーク、PCI 電源状態と OS シグナルの不一致、"幽霊" PCI デバイスなど、さまざまな種類のバグに対応した
- 暫定策として ACPI quirk（例: ACPI_Q_CLEAR_PME_ON_DETACH、ACPI_Q_DELAY_BEFORE_EJECT_RESCAN）を適用し、EC2 側のバグは今後修正予定である
ホットプラグ試験の自動化と品質改善
- EC2 環境で EBS ボリュームを繰り返し接続・切断するスクリプトを開発し、300回連続テストによって安定性を検証した
- PCIe ホットプラグの不要な5秒遅延（物理システムでのみ意味がある）を、EC2 では0秒に設定して品質を改善した
起動性能の改善
- FreeBSD/EC2 の起動速度の課題を、データ収集と分析によって体系的に改善した
- 2024年初頭のルートディスク容量拡張による起動3倍遅延、Graviton2 インスタンスのカーネルエントロピーシーディング遅延、ZFS 起動時間の増加、IMDSv2 関連の IPv6 対応問題などを順次解決した
- ファイルシステムごとの起動性能差、エントロピー取得の非効率、ネットワーク初期化遅延など、多方面で最適化が行われた
# FreeBSD AMIの多様化拡大とビルド/配布自動化
- 既存の base、cloud-init AMI に加え、small AMI（不要なデバッグ・テストコード/ツールを削除、1GBサイズ）、builder AMI（ユーザーのカスタム用ビルダー） を追加した
- 4種類の AMI * 2ファイルシステム(UFS/ZFS) * 2アーキテクチャ(amd64/arm64) * 3バージョン(13, 14, 15)へとイメージの組み合わせが拡大したことで、古いイメージの自動削除とスクリプト化を進め、336TB の EBS スナップショットを整理した
# エンジニアリング全般の改善
- FreeBSD AMI/リリースビルドの 並列化 により、全体のビルド時間を約22時間→13時間へ短縮し、より多くの AMI 種類追加の余地を確保した
- EC2 インスタンスベースの自動テストと diffoscope 比較により、ビルド再現性（リプロデューシブルビルド） の問題診断と解決を進めた
- ENA ドライバパッチのレビュー、OCI コンテナビルドとレジストリアップロード、AWS 関連ツールの改善、セキュリティ問題のレポートなど、さまざまな小規模業務も並行して行った
# 今後の展望と限界
- FreeBSD リリースエンジニアリングおよび EC2 プラットフォーム維持の役割は続けるが、以前より投入可能な時間は減る見込みである
- FreeBSD 15.0(2024年12月)、14.4/15.1/14.5/15.2(2026年) のリリースは予定どおり進むが、機能追加やバグ修正の速度は低下すると見られる
- 自動ファイルシステム拡張、複数 NIC とホットプラグ自動化、事前パッチ適用済み AMI 配布、EC2 ユーザー向け Web ツール、FreeBSD/Firecracker 対応などの未完了課題は、長期的に停滞が予想される
# 結び
- Amazon による今回の支援は、オープンソース開発者にとって極めてまれな機会であり、これまでの成果に誇りと感謝を感じている
1件のコメント
Hacker Newsのコメント
今日 ziglang.org のダウンロードページに FreeBSD が追加されたという話。これで FreeBSD ユーザーは、CI で自動ビルドされた master ブランチのビルドを簡単に入手できるようになった。
FreeBSD は теперь 公式なクロスコンパイル対象として完全にサポートされており、
zig cc -o hello hello.c -target riscv64-freebsdのように Linux と同様の感覚で FreeBSD 向けにコンパイルできる。C/C++ 依存関係がある場合でも、zig のビルドシステムに簡単に取り込んでビルドできるので、かなり複雑なプロジェクトでも容易に FreeBSD 向けクロスコンパイルが可能。
このことをきっかけに、より多くのプロジェクトが CI に FreeBSD サポートやテストを追加してくれることを期待している。
読みながら面白い部分がたくさんあった。
2024年の最初の週から、FreeBSD のブートプロセスが突然 3 倍遅くなったという事例があり、コミットを追跡し続けた末に、原因はルートディスクのサイズが 5GB から 6GB に増えたことだった。
Amazon の知人に尋ねてみたところ、まるで魔法のような返答で、「正確には分からないが、知らないほうがいいかもしれない」といった感じだった。
重要なのは、ルートディスクのサイズを 8GB に増やしたところ、性能が元の水準に戻ったこと。
こういう話を聞くと、もう本当に理由が知りたくなる。
こうした問題を見つけるためにコミットのバイセクションに実際どれくらい時間がかかったのか気になる。
毎回イメージを作って VM を再起動していたのだろうか、と想像してしまう。
S3 の元々のオブジェクトサイズ上限が 5GB だったという、自分の 2006 年のブログ記事に言及。
https://aws.amazon.com/blogs/aws/amazon_s3/
これが FreeBSD の性能低下と直接関係しているかは分からない。
ノート PC 対応についても多くの作業が進んでいる。
BSD Foundation が 75 万ドルを投じて、S0ix Sleep State の実装などさまざまな機能に注力しているという話を読んだ。
関連プロジェクトは https://github.com/FreeBSDFoundation/proj-laptop で確認できる。
Amazon がもっと支援・貢献してくれればと思っていたが、現実には FreeBSD への支援は最小限にとどまっているように見える。
Amazon は FreeBSD のスポンサー一覧にも載っておらず、Google も昨年はわずか 9K ドルの寄付だけで、Apple や Meta/Facebook も見当たらない。
その一方で、Microsoft が一覧に載っている点は評価したい。
これらの大企業が FreeBSD や OpenBSD から大きな恩恵を受けていながら、毎年自動的に寄付していないのは意外だ。
スポンサー情報は https://freebsdfoundation.org/our-donors/donors/?donationYear=2024 で確認できる。
Amazon にもっと FreeBSD を支援してほしいという気持ちには同意する。
ただし、FreeBSD Foundation の寄付者一覧に名前がないからといって、支援がないとは限らない。
自分が受けた開発費も財団経由ではなかったし、実際には財団が支援する開発は企業支援全体の 10% 程度にすぎない。
財団が支援する開発は FreeBSD そのもののための作業に集中できるので重要だが、全体から見れば少数派だ。
このコメントだけでは全体像は分からないという指摘。
年ごとの財団への寄付のスナップショットを示しているだけで、実際の開発貢献は各リリースのリリースノートに要約されている。
https://www.freebsd.org/releases/
Microsoft がなぜ FreeBSD を支援しているのか気になる。
Hyper-V 拡張も Linux ほど完全ではなく、.NET の公式ポートもなく、Microsoft が FreeBSD ベースのサービスを運用しているようにも見えない。
Amazon は FAANG の中で FOSS への貢献が最も少ない企業だという意見。
cperciva に大きな敬意を表したい。
Tarsnap と FreeBSD をどうやって同時に回しているのか気になる。
簡単な修理なら自分でやるか、専門家を呼ぶかを選べる。
この FreeBSD 作業に費やした時間のうち、Tarsnap から得られた時間は一部だけで、思ったより多くはなかった。
以前 FreeBSD をワークステーションとして使ったことがあり、印象的だった。
自宅のゲートウェイ / ファイアウォール / DNS / DHCP サーバーとして FreeBSD を使いたかったが、10GbE NIC ドライバーが対応しておらず、結局 Nix を選んだ。
FreeBSD が今もなおしっかり維持されているのを見るのはうれしい。
FreeBSD/EC2 の大口ユーザーが誰なのか気になる。
自分もよく分からない。
実際に自分に連絡してくるユーザーは、FreeBSD/EC2 全体の 0.1% にも満たない気がする。
誰が EC2 で FreeBSD を使っているのか本当に知りたい。
Netflix は FreeBSD をエッジボックスだけで使っているのだろうか。
FreeBSD が Unix 系でどんなニッチを埋めているのか気になる。
なぜ OpenBSD や NetBSD より複雑な FreeBSD を使うのか、ZFS や Nvidia、ELF が必要なら Linux のほうがよいのではないか、という疑問。
GNU の問題は理解しているが、Musl Void のような代替もある中で、FreeBSD ならではの明確な「アイデンティティ」が何なのかを純粋に知りたい、という話。
金融業界で、FreeBSD を EC2 と自社データセンターのベアメタルサーバーの両方で使った経験がある。
zfs と jails を多用していた。
すべてのサービスを各 jail で独立して動かし、非常にコスト効率が高かった。
一部をクラウドへ移し、Linux(k8s)+FreeBSD のハイブリッド運用にしたところ、コストが急増した。
自前データセンターの運用には、ディスク交換や火災対応など面倒な点もあるが、AWS にはマルチリージョンなど多くの機能がある（その分コストもかかる）。
zfs は、本番 DB テーブルが誤って削除されたとき、スナップショットのおかげですぐにロールバックできて非常に助かったし、バックアップにも zfs を活用していた。
本番環境で dtrace を使ってトラブルシューティングしたこともある。
サーバーを FreeBSD だけで運用していた頃は、OS 群が一つだけなので管理が容易だったが、Linux を導入すると各チームがばらばらのディストリビューションを使って混乱が生じた。
FreeBSD を、カーネルと OS が統合された構造として好んでいる。
自分にとって FreeBSD は、OpenBSD と NetBSD の長所をうまく混ぜ合わせたような存在だ。
かつての FreeBSD は Intel CPU 最適化と堅牢なセキュリティを誇っており、特に ZFS 対応が決定的な差別化要因だった。
nvidia ドライバーも最近になってようやくネイティブな FreeBSD 対応が実現した。
結局のところ、FreeBSD は他の BSD の利点とハードウェア面での安定性をうまく組み合わせている。
FreeBSD は OpenBSD や NetBSD よりはるかに大きなユーザーベースを持っている。
ソフトウェアカタログ自体もより大規模で、デスクトップの日常利用にも十分耐えられる。
なぜ Linux を使わないのかというと、Linux は企業の利益にあまりにも強く結びついているからだ。
FreeBSD は ZFS 対応において Linux より一枚上手だという意見。
ライセンス問題のおかげで、FreeBSD のほうがよりよい環境を提供している。
FreeBSD は OpenBSD よりネットワーク処理性能の面で優れている。
一般に BSD は変化のスピードが遅めなので、統合プラットフォームとして使うのに向いている。
この記事を読むと、FreeBSD の開発環境はあまり良く描かれていないという意見。
これほど複雑な OS なのだから、少なくとも誰か一人はフルタイムのリリースマネージャーを務めるべきなのに、1年間パートタイムだけだったという現実は惜しい。
それでも、Linux だけが唯一の選択肢ではないという点で、FreeBSD の存在は重要だ。