企業向け Linux の選択

この記事のURLhttp://japan.internet.com/webtech/20060904/6.html

■変化する Linux ディストリビュータの戦略

Linux kernel メンテナーの Andrew Morton が最近、 某メディアのインタビューで「現在カーネルは2.6だが、次のバージョンの予定があるか」と聞かれて、「2.7 の計画はない」と答えている。

これはどういうことだろうか。

Linux が成熟したということが一つの理由だろう。

以前はバージョンアップに非常に大きな期待がかけられていた。 なぜかというと、現バージョンに足りないものがたくさんあったからだ。 また、やってほしいこと、 やりたいことがたくさんあったので、 メジャーなバージョンアップが頻繁に行われた。 だから機能が充実し、企業向けにも浸透しはじめた、 2.0 から 2.2、2.4、そして現在の2.6へと、ここ数年の間に版を重ね、 どんどん進化した。

だが、それは2、3年前までのことだ。 最近になってメジャーなバージョンアップの速度が少しゆっくりになった。 だから、Andrew Morton が「2.7の計画はない」と言えるまで成熟したのだろう。

Linux カーネルのソーストリーは今までも一つしかないが、 どのバージョンで固定し、 そこにどんな機能を追加してパッケージにしていくかということが、 各ディストリビュータの技術的な基本となっている。 そのパッケージ化のノウハウが他の Linux ディストリビュータとの差別化を図る、 というのが普通の戦い方だった。

しかし、バージョンアップの頻度がゆっくりになってくると、 そういう戦略だけでは戦えなくなるだろう。

なぜなら、ユーザーの観点に立つと、 どのディストリビューションを選んでも、 パッケージ自体はたいした変わりがない、と思えるからだ。 同じようなものなら、自分が少しでも気に入ったものを選んでおこう、 ということになりそうだ。 しかし、実はそれも必ずしも正しい考え方ではない。ここがポイントだ。

そもそも Linux には、 ディストリビューション間で違いがあるのはよくない、という考え方もある。 これは互換性という話だ。 ベンダーやユーザーから見ると、互換性を維持してほしいから、 そのような言い方をされる。 とは言うものの、違いを出すために、 メインストリームから外れたもので勝負するという考え方もある。 しかし、これは互換性の問題だけではなく、 誰がその特殊な機能をサポートし続けるのか、という問題である。 メインストリームから外れたものを維持していくのは大変な作業であり、効率も悪い。それではオープンソースのメリットが生きないという考え方もある。

つまり互換性の維持と、将来のサポートの効率の問題で、 Linux はできるだけ共通である方がいいのだ、という見方である。 しかし、カーネルが同じようなレベルになってきたのであれば、 もうそういう心配はなくなるのであろうか。 実はそうではない。

Linux のもっとも基本的な部分は、OS としてのパッケージである。 つまり、カーネルと、それを生かすためのコマンド群、ライブラリ、 コンパイラなどの開発環境がセットとなり、最小構成となる。 この時点での互換性の程度は、 主に、それぞれのバージョン、ライブラリの種類、そして、 OS の環境をどのように構成するかを決めるコンフィグレーションファイル群の違いでほぼ決まってしまう。 カーネル自体は概ね互換性があると言っていい。 つまり、カーネル自体が及ぼす互換性の影響は相対的には高くない。 したがって、Linux の互換性の問題の解決は、 手間さえかければ、ユーザー側でも理論的には対処可能なのである。

世界の2大ディストリビューションである、Red Hat と SUSE の違いもまさにそういうことであり、大きな意味で互換性はある。 企業から見ると、つまり、 どちらを選んでも大差ない、とも言えるのだ。 にもかかわらず、どうして、Red Hat のシェアが、SUSE よりも上なのか。

Red Hat の大きな売りは、Linux カーネルフォーカスだということだ。 OS フォーカスと言ってもいい。 SUSE と比較しても、OS まわりの技術陣は定評があるし、 コミュニティにもしっかり浸透している。 SUSE もこの部分では同じように評価はされているが、比較の問題では、 一般には Red Hat ということになっていた。

OS の分野での SUSE の売りは、コンフィグレーションのしやすさである。 SUSE と言えば、YaST（ヤスト）であり、 YaST と言えば SUSE の代名詞のように言われる。 YaST は OS のコンフィグレーションを施すためのコマンドであり、 Windows におけるコントロールパネルのような位置付けである。 地味な機能ではあるが、とても重要である。 私も長年、Red Hat のユーザーであったが、 いつも苦労させられた。 この部分では SUSE のポリシーの方がしっかりしており、 コンフィグレーションの操作性は SUSE に軍配が上がる。

これを機会に、Linux のコンフィグレーションのポイントについて、 概説してみようと思う。

■洗練された Linux コンフィギュレーションツールを

Linux ではコンフィギュレーションファイルはテキストファイルのようなものになっていて、 多くはエディタで直接書き換えることができる。 コンフィギュレーションを変更するときは、 このようにコンフィグレーションファイルを直接書き換える、という方式が一般的だ、と長く信じられてきた。 しかしこれが、Linux のハードルを高くしている一因にもなっている。

Windows の場合はどうか。 コンフィグレーションファイルを直接エディタで編集するなどということは一切許されないのである。 昔、MS-DOS や Windows 3.0 くらいまではそれが許されていたのだが、 ある時期から、勝手にコンフィギュレーションファイルを書き換えると、 Windows 自体が思い通りに動かなくなったり、クラッシュしたりするようになった。 マニアや、"にわか"プロは、こうした事態に困ったものだ。 だから Windows が嫌いになった人もいる。

最近の Windows はいわゆる"バカチョン"であり、 コンフィグレーションは、すべてハイレベルなコマンドや GUI で操作する。 だから素人であっても何とか操作することができるのだ。

しかし、ハッカータイプのエンジニアにとっては、 Windows はおもしろくない。 ユーザーに勝手にいじられないようにする堅牢な「バカよけ」があるからだ。

ハッカータイプの対極に、 システムアドミニストレータ（シスアド）タイプのエンジニアがいる。 企業内では、このシスアドタイプのエンジニアが主要な位置を占める。 この「バカよけ」のおかげで、 シスアドにとっては Windows は理想的なものになっている。 マニアックな手法に頼らずとも、 マニュアルをきちんと読んで手続きどおりにやると、 コンフィグレーションができたり、 場合によって問題も解決する。

マニュアルなしでも画面の指示通りに順番に行うと案外うまく操作できたりす ることもある。 シスアドにはこのほうが望ましい。

ところが、Linux は歴史的に UNIX の流れを汲んでおり、 コンフィグレーションファイルを直接いじる文化が非常に色濃く残っている。 今、書店にならんでいる Linux の技術解説書の中にすら、 そのような記述が堂々とまかりとおっている。 Linux のトレーニングはあまたあるが、 多くはコンフィグレーションのノウハウを各ディストリビューションごとに解説するものである。

企業にとっては、これは大きな問題だ。 Linux に強いシスアドを養成する場合、 Linux のトレーニングを受けさせるのが手っ取り早い。 ところがこのトレーニングの中身は、 如何にコンフィグレーションするかという部分に重きが置かれている。 これ自体はノウハウではあっても、 応用範囲は狭い。 つまり、暗記物の受験勉強のようなものなのだ。 とりあえず、クリアしてしまえば、忘れてしまうかもしれない。 基本的なスキルの養成とまで言い切れないのだ。

エンジニアにとっても、 ある Linux ディストリビューションのコンフィギュレーションファイルの専門家になるということは、 それが必要な場面ではヒーローになれるかもしれないが、ただそれだけのことである。そのようなことでエンジニアのノウハウや時間を消費させ、 将来性をつぶしてしまうのはあまりいいことだとは思えない。 ハッカーはもともとそういうことが自然にこなせるので、 問題はないということだけなのである。

そうではなくて、基本的なことをマスターしていれば、 Linux も Windows も操作できるようになっているほうが、 企業にとって望ましいのは言うまでもない。 したがって、今後 Linux が企業により浸透するためには、 そのような方向にもっていくべきだ。

■Linux の生き残る道

IBM が世界的に進める ISL（Integrated Stack for Linux）というプロジェクトがある。 これは、Linux の上に、RDBMS である DB2 と、 WAS（Websphere Application Server）を搭載したものだ。 WAS というのは一言でいうと、 Apache Geronimo だ。つまり、LAMP の代替である。 ただ、データベースが DB2 で、Javaである。 つまり J2EE アプリケーションサーバーとなるものだ。 Red Hat の JBoss の代替にもなっている。

ここで言いたかったのは、その機能の説明や比較ではない。 コンフィグレーションの話だ。 ISL の特長は、Linux のインストールを含め、 ISL のソフトウェアスタック自体が自動でインストールできるようになっている。 コンフィグレーションも自動化されており、GUI 化されている。 これが実は YaST に組み込まれているのだ。

ISL のアプローチは、 SUSE の特長をよく表している。 つまり、機能だけではなく、操作性や管理の効率を重要視している点だ。 そのために YaST が重要な役割を占めており、 したがって、ISL は今のところ、SUSE でしかサポートされていない。

ディストリビュータは今後、 コアなカーネルの相違といった OS そのもので勝負するのではなく、 むしろ全体的な完成度で勝負する方向に進むだろう。 もちろんこれまでも、全体の出来具合での戦いだったのだが、 その意味合いがコンフィギュレーションやソフトウエアスタックとの連携にまでレベルアップするはずだ。

最近、話題の仮想化技術 XEN（ゼン）についてもこれに関連する話がある。 XEN の機能の技術的な話は多いが、 使い勝手の話は少ない。 実はコンフィグレーションが極めて難しい機能なのである。 XEN の機能自体はどのディストリビュータに取り込まれても似たり寄ったりになるはずだが、 正しく簡単に構成するのは難しい。 もう想像がつくと思うが、 SUSE の場合は XEN のコンフィグレーションを YaST に取り込んでいる。 したがって XEN の中身にあまり詳しくなくても確実に使うことができる。 このことはあまり知られていない。

つまり、これからの Linux は、ファンクションそのものでの戦いではなく、 ファンクションの組合せと操作性およびメンテナンスの戦いになる。 環境に合わせていかに OS を効率良く、簡単に操作し、管理するか、 これが非常に重要となる。 そのような方向に合わせたサポート体制の充実が急務なのは言うまでもない。

そしてこれらはコミュニティだけの力では解決しない。 このようなビジネスのモデルは、 ディストリビュータやハードベンダーが連携しながら確立するものであり、 それによって、 企業ユーザーが十分に満足できる環境を整えていく必要があるのだ。