LinuxやBSDなどUNIX系のOSを使ってWebアプリケーションを開発するプログラマは,少なくとも一度は何らかのアプリケーションで実行バイナリ・データをconfigureからmakeコマンドを使って生成したことがあるに違いない。LAMP(Linux,Apache,MySQL,Perl/PHP/Python)で有名なApacheやMySQLはこのようなビルド(実行バイナリを生成すること)を自分で行うことができる。だが,テスト用途で利用するならともかく,本番環境で自分でビルドしたバイナリを使ってはいけない。様々な点で弊害がある。

 プログラミングの上級者ならば,自分でビルド・オプションを指定してビルドした方が,既に提供されているバイナリよりも高速に実行できるバイナリを作ることができるかもしれない。MySQLならば6.5.4. MySQL 5.1 リファレンスマニュアル :: MySQL の速度に対するコンパイルとリンクの影響を見ると,自分でビルドした方がより高速なバイナリを作れるケースがあることが分かる。

 しかし,これは例外的と見るべきだ。MySQLの場合は,提供されているパッケージ形式であるRPM版は,ほとんどの場合,既にそうしたプラットフォーム別のチューニングが施されたバイナリになっている。自分でビルドする利点はパフォーマンス面ではほとんどないと考えた方がよい。

保守性が悪くなる

 Apacheの場合はどうだろう。Apacheは,RPMでのインストールではDSO(Dynamic Shared Object)という,動的に組み込んだり外したりできるモジュールとして,様々な拡張が提供されている。これらはApacheの設定ファイルの中で,LoadModuleディレクティブという書式によってモジュールの動的リンクを行っている。動的リンクよりも静的リンクの方が速いので,必要なモジュールだけを静的リンクとして自分でビルドしてしまった方が実行速度は速くなる。

 ただし,静的リンクはモジュールとして提供されている機能を一つのバイナリに含めてしまう。そのため,後から不要になったモジュールを切り離すことができない。そうした場合は再度ビルド直すことになるので,多少は高速になったとしても,保守性が著しく落ちてしまうというデメリットがある。

 「ちょっとした一時的なメンテナンスのために,mod_rewriteというリクエスト・データの書き換えを行うモジュールを使いたい」とか,「サーバーの移転のために柔軟にリクエスト・データの転送などを行うmod_proxyを使いたい」といった一時的なニーズが発生する場合がある。Apacheの最適化を本気でやるのであれば,これらのモジュールは定常的に使うことが無ければ外すことを検討したいモジュールだろう。しかし,上記のような一時的なニーズのために静的リンクしていた場合は,再びApacheそのものをビルドし直さねばなならなくなる。業務システムの日常的な運用保守の中でそうした作業を行うのは,あまり現実的ではない。

 DSOを使って動的リンクしていれば,ビルド後なら設定を書き換えるだけで済む。ビルド前であれば,当該モジュールだけをビルドして設定ファイルを書き換えるだけで済む。例えばmod_proxyを外したい場合は下記のようにすればよい。

#LoadModule proxy_module modules/mod_proxy.so

 LoadModuleの部分をコメントアウトしておくだけである。とても簡単だ。そうした点も考慮してか,ApacheのRPMではほとんどのモジュールがDSOとして提供されている。

バージョンアップへの追従も問題

 自分でビルドすることの問題はほかにもある。もし,使っているソフトウエアにセキュリティ上の問題点が発覚し,バージョン・アップしなければならなくなったらどうなるだろう。バージョンアップ後のソフトウエアは,ひょっとしたらビルド・オプションが変わっているかもしれない。以前のconfigureオプションが,また次に期待通り動くとも限らない。さらに,バージョンアップに伴い,そのソフトウエアが依存している別のソフトウエアも新しいバージョンにしなければならないかもしれない。それらの依存性も自分でビルドした場合は自分で解決しなければならない。

 例えば,ソフトウエアの「httpd」を修正しようとしたとき,httpdと依存関係にある「httpd-devel」というソフトウエアに影響するだけでなく,httpd-develと依存関係にあるほかのソフトウエア(「apr-devel」など)にも影響する可能性がある。「rpm」などのパッケージ管理システムを使えば,そのような依存関係も管理してくれる。

 開発元が正規に提供するバイナリやパッケージを使っていれば,少なくとも一通りの動作確認はされているだろうし,自分たちがやるよりは安心して使えるケースがほとんどだろう。もちろん検証を怠ってはいけないが。

配布や適用に対する手間の問題

 手間をかければ,こうした問題は全く解決できないものではない。実際,Makefileやシェル・スクリプトでビルドの手続きを記述して,それを複数台のサーバーに配布して,そこでその自家製ビルド・システムを実行する,といった話を少なからず聞く。あるいはもっと徹底している環境では,rpmやdebファイルといったOS固有のパッケージ・システムに沿った形で配布しているところもあるようだ。

 これらの手法を取れば複数台のサーバーに特定のパッケージをインストールさせるという目的自体は達成できる。また,OS固有のパッケージ・システムに載せたファイルを使えば依存性解決も問題なく行える。しかし,これらもなかなか手間だ。

 そこまで管理できる体制が整っているのであればやる価値はあるかもしれない。しかし,多くのケースでは,そこまで手間をかけてそれを上回る効果を得られるかどうかは疑問だ。

 プログラムをより深く理解するという意味では,自分でビルドするという経験は,開発者ならば必ず一度は通りたい道(むしろ何度やってもよい)。ただし,それを本番環境で使うとなると話は別。受けられる恩恵よりも管理上の問題の方が多い。


山口徹
サイボウズ・ラボ
 サイボウズ・ラボ株式会社のプログラマ。バーテンダーからIT業界に転身後,様々なWeb制作を行い,大規模コミュニティ・サイトの開発・運用を経て,現在は研究開発の日々。Perl使い。Perlを中心とした開発のノウハウやネタをShibuya Perl Mongersのイベントで発表するなど講演活動も行う。個人の開発日記は「Yet Another Hackadelic」。仕事のブログは「log4ZIGOROu」。
■変更履歴
筆者の肩書きで,社名がライボウズ・ラボとなっていましたが,サイボウズ・ラボです。お詫びして訂正します。修正済みです。 [2008/04/01 21:10]