長い間，ミドルウエアやOSの内部は，システム・インテグレータが触るものではないと思っていた。オープンソース・ソフトウエアが普及しても，実際にミドルウエアやOSのソース・コードを読んだり変更したりするのは，それらの専門家でなければできないと思っていた。業務システム構築の現場で，ソース・コードが公開されている恩恵を直接受けるような場面はほとんどないだろう，と思っていた。
だが，その考えは改めるべきだと反省するようになってきた。ソース・コードの内部を把握し，改良を加えているシステム構築現場の技術者に，たくさん出会うようになってきたからだ。
Java APサーバーのソースを調べ，高速化する方法を提案
野村総合研究所は，LinuxやWebアプリケーション・サーバーのJBossなどを利用してシステムを構築する際に，パフォーマンスが出ないという問題に直面した。株価やニュースの情報を収集し，メールやWebで会員に提供する「アグリゲーション・サービス」システムを構築した際のことだ。
野村総合研究所の開発チームはさまざまなチューニングを試み，JBossのソース・コードも調査した。その結果，JBoss内部でDBMSにアクセスしている部分で，ある変更を加えれば高速化する可能性があることが分かった。具体的には，SQL文を一件ずつ発行するのではなく，まとめて発行する「バッチ更新」と呼ぶ機能を使う，ということである。それをJBossの開発チームに提案したところ，約一週間で「バッチ更新」が使用できるように改良されたJBossが提供された。
「自社で改良することもできた」（野村総合研究所 福岡システム開発部 中野裕隆氏）が，独自バージョンにしてしまうと，今後のバージョン・アップなどに追随するの難しくなる。そのためJBoss開発チームに対する提案する形になったが，提案が容れられなかった場合は，自分でJBossのソース・コードを改良するつもりだった。
ソースを手直しできれば，利用できるプログラムは世界中に
マネースクウェア・ジャパンのインターネット外国為替取引システム「iFX Style」（関連記事）を開発したインテグレータのスター・ロジックは，データベース管理システムのPostgreSQLで問題に突き当たった。PostgreSQLが標準で提供するDBアクセス・モジュール（JDBCドライバ）では，使いたい機能――テーブルが更新された際にPostgreSQLがそれをアプリケーションに通知する「Notify/ Listen」――を利用できなかったのである。
スター・ロジック 代表取締役 CEO 羽生章洋氏らは，問題の答えを探して数日間インターネットをさまよった。そしてついに発見したのが，スイス・ドメインのあるサイトにあったDBアクセス・モジュールだった。
オープンソースとして無料で公開されたモジュールだったが「メモリーが解放されなくなるメモリー・リークが発生するバグがあった」（羽生氏）。このため，バグの修正が必要だったが，ゼロから自社で開発するのに比べ，圧倒的に短期間で必要な機能を実現できた。
iFX StyleでZeusと呼ぶJavaとXMLの変換ツールを拡張して使うなど，スター・ロジックでは様々なツールを探し出し，使いこなしている。羽生氏は「最もよく使うツールはGoogle」という。「自分が悩んでいるようなことは，他にも悩んだ人がいるはずだ。そして，すでにその問題を解決した人もいるはず」（同）であり，多くの場合インターネット上で公開されているプログラムや解決策がある。
もちろん，ネット上にあるオープンソースのプログラムは多くの場合，無償だが無保証であり，バグを含んでいることもある。それを「24時間連続稼働のインターネット金融システムを支えるソフトウエア」にすることができるのは，利用者側にソース・レベルで改良する技術力があってこそである。
Linuxカーネルのソースにツールを組み込み障害原因を調査
日立製作所は，Linuxサーバーが不定期にダウンするという障害を，Linuxカーネルの挙動を解析して解決した。この原因を究明できたのも，ソース・コードを触る力があればこそだった。
この障害は，光ファイバによるインターネット接続サービスを手がけるケイ・オプティコムの工事管理用のシステムを，クラスタリング構成に拡張した際に発生した。サーバーのハングアップにより，バックアップ・サーバーに切り替わってしまう現象が1週間に1～2回起きた。サービスは継続されるため業務に支障はないもののの，ログからは原因が特定できなかった。
日立が原因解明のために使用したのが，LKST（Linux Kernel State Tracer)と呼ぶ，Linuxカーネルに埋め込んでその挙動を記録するツールである。LKSTは，日立，富士通，NEC，日本IBMの4社が「エンタープライズLinux機能強化のための協業」（関連記事）として開発してきた成果の一つだ。カーネルのソース・コードに組み込み，コンパイルして使用する。当然，ソース・コードを自由に使えるからこそ，このようなツールが利用できる。
調査の結果，kswapdと呼ばれるプロセスが，ディスクやメモリーを占有し，他のプロセスがロック待ち状態になっていた。「カーネルのHyper-Threadingへの対応に問題がある可能性が高いと考えた」（日立製作所 システム開発研究所 第三部 平松雅巳氏）。
Hyper-Threadingとは，Intel Xeonプロセッサの機能で，プロセッサ側でスレッドの切り替えを行い性能を向上させる仕組みだ。ソフトウエア側からは，1個のプロセッサがあたかも2個のように見える。このケースでは，物理的には1個のプロセッサの上で動く2つのプロセスがロック競合を起こしていると見られた。Hypert-ThreadingをOFFにしたところ，障害は発生しなくなった。調査を開始してから約1週間後のことである。
ソース・コードを活用できる技術力が価値を生む
目的が業務システムの開発であれば，本来はミドルウエアやOSの中身など気にすることなく，業務ロジックの開発だけに専念できるのが理想だ。ただし現実には，残念ながらミドルウエアやOSの障害はなくならないし，ミドルウエアが，必要なすべての機能や性能を満たしているわけではない。このことはオープンソース・ソフトウエアでも商用ソフトウエアでも同様だろう。
そのような場面で，ミドルウエアやOSのソース・コードを解析し修正する能力は，大きな価値をもたらしている。処理性能の確保や開発の省力化などだ。もし，ここまで紹介したシステムの障害が解決できなかったら，その損失はいくらになっただろうか。お金に換算すれば，その価値ははかりしれない。
現在のコンピュータ産業は水平分業が定着しており，ミドルウエアはブラックボックスであることが当たり前になっている。これに対して，メインフレームは一社ですべてを提供する垂直統合モデルだった。それゆえに高コストになりがちではあったが，（少なくとも初期のメインフレームには）ブラックボックスは存在しなかった。ベテランのエンジニアの中には，メインフレーム用OSやトランザクション処理モニターの内部を触りながら業務システムを開発してきた方も多いのではないだろうか。
オープンソースによって，水平分業だがブラックボックスのない，両方の長所を備えたモデルが作れるかもしれない。その期待は，ただの期待に終わることなく，現実にシステム構築の現場でかなえられつつある。最近は，業務アプリケーションもミドルウエアも，ともにJavaで書かれることが多くなった，という追い風も吹く。アプリケーションはVisual BasicやPerl，ミドルウエアはCという時代に比べれば，アプリケーションの技術者にとってミドルウエアの敷居はずいぶん低くなった。
このようなオープンソースの恩恵を享受できているシステム構築プロジェクトはまだまだ少ない。ソース・コードを使いこなせる技術者はそう多くはないからだ。もちろん，すべての開発者がミドルウエアのソース・コードを読み書きできるようになる必要はない。業務知識やプロジェクト管理を専門とする開発者も必要だ。しかし，ミドルウエアの内部を解析できるような技術者も，もっと育成できないだろうか。そして，その技術力に，もっと高い評価を与えられないだろうか。
「ソースを使え，ルーク(Use the Source, Luke)」――。プログラマに長く語りつがれてきた有名な“格言”である。ルークとはもちろんルーク・スカイウォーカーのことで，ソースはフォース（force:理力）をもじったものだ。オープンソース・ソフトウエアであれば，ソース・コードはライセンス料を払わなくとも，わざわざ入手しなくとも，すでにそこにある。使わない手はない。
（高橋 信頼＝IT Pro編集）
