仲間と始めた会社も軌道に乗り、か なり忙しい日々を送ることになった。私は松江に住んでいるのだが、月に２回 は東京に行っている。シャレで買った5000円のイオカードも、２ヶ月程で使い 切ってしまった。
前にも書いたように、サーバ屋であるので、設置作業とかであちこち歩くこと になるし、どうしようもないトラブル(クラックされたり、ハード交換になっ たり)の時も出て行かなくてはならない。これらの作業は単純と言えば単純な ので、他の人にやって欲しいところなのだが、トラブルシューティングは技術 も必要なので、誰でも出来るというものではないところが厳しい。もっとも今 月からはやまだあきら君が 入社してくれたので、かなり楽になることを期待している。彼はさっそく台風 の中を大阪までクラックの復旧に行ってくれている。
今回はLinuxのサーバ的応用について考察してLinux普及にあたっての盲点を見 てみよう。
まずは、Linuxの特性から、本格的なサーバとして使えるかどうかの考察をし てみよう。ただし、知ってる人にとっては「あたりまえ」のことに過ぎないと は思う。
「私の家」のサーバは、昔からLinuxである。jh4tjw.prug.or.jpのuucpを２年、 linux.or.jpのサーバを１年強運用している。また業務で設置したサーバを４ヶ 月で20台余り出荷しているが、これも全部Linuxである。負荷を見ると、 www.linux.or.jpとwww.nurs.or.jpのヒット数を合計して、月間100万ヒット程 度である。また、いずれもホストでもMLサーバも兼ねているので、かなり負荷 は高い(linux-users MLは分散配送をしているため、うちでの負荷は少ないが、 その他のプロジェクト関係のMLは直接配送なのでsendmailは大量に起動される)。 それでもkernelが原因となってのシステムダウンは起きたことがない。昔、 www.nurs.or.jpとして使っているマシンのメモリが8MBしかなかった頃、perl の関係で深刻なメモリ不足でスラッシングが起きてしまったことがあるのだが、 kernelが強過ぎるのかダウンしないで頑張っていた。内心「いっそ落ちてくれ れば対処も簡単なのに」とか思っていたのであるが、「意地で動いている」と いう雰囲気で動いていた。強度という観点から言えば、文句はない。どころか、 「強過ぎる」と言っても良いくらいである。
処理能力という観点考えてみよう。うちの顧客で使っている例を挙げると、 PentiumPro 200MHzでメモリ64MBくらいあると、64回線くらいのpppを処理しな がら、それに対応したhttpdの処理を行うことが可能である。この時のpppが作 るバンド幅は、数Mbpsに相当するので、仮に専用線でサービスするなら、数 Mbpsくらいの回線でhttpは処理することが可能であるということになる。さら にppp分はそっくりパワーが余るし、処理としてはhttpdよりもpppの方が断然 重いはずなので、実際にはもっと多くのバンドの処理が可能になるはずである。 社内のいわゆるイントラネットのトラフィックはそう高くないので、余程重た い業務プログラムにしなければ、「普通にやる分には何をやっても平気」だと 思って良いだろう。一般にkernelというものは、並行して動くプロセス数が増 えると、加速度的に負荷が大きくなるものであるが、これくらいの負荷ではビ クともしない。私の例では使っているハードウェアは非常に高スペックである かも知れないが、それを割り引いても非常に処理能力が高いと言っても言い過 ぎではないように思われる。この点では、WindowsNTと比べれば、格段に処理 能力が高いと言える。
アプリケーションの種類、特にサーバとして運用するのに必要なものに関して は、もはや「ないものはない」と言っても過言ではないくらい充実して来た。 かつて「UNIXのアプリケーション」が開発される標準のプラットホームは SunOSであることが多かったのであるが、今はLinuxがその位置を占めつつある ようである。多くの開発者が「UNIXとしてLinuxを使っている」という状況に なって来たのである。そのため、「とりあえずLinux版は存在している」といっ たアプリは少なくない。その点では非常に都合が良くなって来た。クライアン ト系のアプリもWindows程ではないが、わりと揃っていたりするので、「Linux を中心に据えたシステムインテグレーション」を行うことは不可能ではなくなっ ている。
以上のように考えれば、「やろうと思えばやってやれないことはない」という レベルまで来ている。「その言い方は控え目に過ぎないか？」という声もある ような気がするが、私がなぜここで控え目な表現を使っているかは、後になる とわかると思う。とにかく、この時点ではこの程度の表現にしておこうと思う。
Linuxを本格的なサーバに使うことを考えた時に、一番最初に誰もが問題点と して挙げるのは、「サポートはどうするのか」ということであろう。確かにフ リーソフトウェアであるから、サポートのことは心配になる。この辺のことは 過去にも触れているのであるが、最近は本誌に広告の出ている「Linuxサポー ト会社」によってはサポートしてくれるところもあるし、私の会社のように 「サポート付きサーバ」を販売している会社もいくつかある。そういった意味 ではこの辺の環境も随分と良くなったものである。
一応安心出来ると言われているメーカのサポートであるが、これは実は案外ア テにならない。大きなユーザとなると「担当ＳＥ」なるものがメーカ(および その関係会社)から来てサポートしてくれているのであるが、この技術レベル に大きなバラツキがあるということは、わりと良く知られた事実である。つま り、タコいサポートが来てしまうのである。そのタコさ加減も「子供の使い」 くらいタコなら、子供の使いとして使えば良いのであるが、なまじ何か知って いると、自分で解決しようとして失敗したり、妙に抱え込んでいつまでも放っ ておかれたりすることも少なくない。ところが、今のところLinuxのサポート をやっている会社の面々は、技術レベルの高い人が多い(そうでなくては、恐 くて手が出せないであろう)ので、良いサポートにあたる確率は高い。そう考 えてみると、むしろメーカ製サーバよりもサポート状況は良いかも知れないの である。これは単なる「逆説遊び」ではなく、真実である(当社のサーバを買 えば、私ややまだ君がサポートするのである^_^)。
また、メーカ製OSで困ることで、「メーカは妙に情報の隠蔽をしたがる」とい ういうのがある。しかも、重大かつ深刻な問題ほど、隠蔽されてしまうことが 多かったりする。ところが、Linuxに関する情報は、何であっても誰に対して もオープンである。これはメーカの情報隠蔽に泣かされた者は涙が出る程嬉し いことである。実はシステムのバグは回避出来れば恐いものではないのである。 情報がオープンであるということは、そのようなバグ情報にもアクセスが出来 るということであるし、それを使ってバグを回避することも出来る。さらに技 術があれば、自分でfixすることも可能である。これもむしろオープンである ことのメリットである。
以前にも書いたのだが、「メーカ製OSはメーカの保証がある」というのは幻想 に過ぎない。嘘だと思うのなら、それらOSに付属しているマニュアルや文書を 読んで見るが良い。一瞬Gnu文書の中にある「無保証告知」の文書を読んだか と思うような錯覚を受けるはずだ(私は実際にそう思って、「きっとこれはBSD コマンドのことなのだろう」と思い、その文書は「誰が誰に」書いたものかと いうことを調べてしまった)。つまり、メーカは保証をしないことを公言して いるのである。だから、何らかの保証を求めてメーカ製OSを購入することは実 は無意味なことなのである。広告に「安心」だの「信頼」だのと書かれている 文句は、全て「単なる宣伝文句」や「幻想(イメージ)」に過ぎないのである。 誰も保証せず、情報も公開されていないOSと、泣く泣くでも自分でメンテが可 能で、そのための情報は氾濫していると言っても良いOS。どちらを選択するの が賢明であるか。幼稚園児でもわかる選択でる。
前述のように、Linuxはメーカ製OSを越えた信頼性と機能を提供してくれるOS である。それはもはや従来の「フリーソフトウェア」としての常識を越えてい るものである。だから、今までの「フリーソフトウェア」としての見方で見る のではなく、「高性能で高信頼のOSがあって、それはソースも全部公開されて て、なぜかそれはフリーで配布されている」といった解釈をしておいた方がよ り現実的である。間違っても「安物のおもちゃ」などとは思ってはいけない。 実際に我々の顧客の中には、月間数1000万の売り上げを当社の作ったサーバで 上げているところもあるのだ。それを見る限りでは、どう考えても「おもちゃ」 でも「安物」でもない。「お金がないからLinux」ではなく、「○○の用途に 最適な選択としてのLinux」という選択がそこに存在しているのである。
だから、仮に自分自身の力でLinuxを使ったサーバを動かそうと思ったら、 「しょせんLinux」といった見方ではなく、「ちゃんとしたUNIXの一種」と思っ ておくべきである。それはLinuxそれ自身に対してもそうであるし、運用体制 等を考える時にでも、そう思っておいた方が間違いがないのである。
また、外部のコンサル会社やサポート会社を使う場合も、「元はタダのOSだか ら」という見方で料金評価するのではなく、「ちゃんとしたサポート料金」と して評価する必要がある。「ちゃんとした」システムのサポート料金はけして 安いものではない。「高性能OS」ならばなおのことである。余談であるが、サ ポートビジネスの観点で言えば、マイクロソフトの「質問一件２万円」は、そ れが有効な回答が得られるものであるとするなら、けして高い金額ではないの である。もっともマイクロソフトの場合は、そのサポートがタコいので、高価 に感じられるわけではあるが。
このように、メリットを挙げてみたり、多少デメリットだと思われることを考 察／弁護してみたりすると、「Linuxをサーバに使わない手はない！」と思う 人も少なくないだろう。確かに私を含め多くの人々がそれを勧めて来たし、そ れは確かに不可能ではない。しかし、サーバビジネスをしばらくやって来た経 験から言うと、「世の中そんなに甘くはない」のである。実は今まで書かなかっ た部分に大きな落し穴が隠されているのである。
問題点はいくつか挙げられるのであるが、その中の最大のものは、「サーバ運 用を十分考慮したパッケージが存在しない」ということである。Linuxは kernelや諸々のアプリ類は十分な実力を持っているのであるが、それをまとめ 上げたパッケージが存在しないのだ。ちょっと考えると、「何でも良いからパッ ケージをインストールして、X serverのようなものを抜いてしまい、各種サー バをインストール」してしまえばサーバシステムは出来上がってしまいそうな ものである。確かにごく小規模なサーバなら、それで何ら問題なく構築出来る。 しかし、それだけではサーバ然としたサーバを作ることは出来ないのである。
機能の点で言うなら、諸々の「システム管理」にあたる作業が効率良く出来な くてはならない。今のままでも自分で手作業をやれば、いくらでもシステム管 理は出来るのであるが、個々の操作があまりにプリミティブであるため、運用 者の力量が重要となってしまう。現在のLinuxのパッケージは、クライアント として使う分にはかなり運用が簡単に出来るようになっていることを考えれば、 あまりに貧弱と言わざるをえない。
また、最近の管理ツールの多くは、Xを使ったGUIで操作出来るものが多くなっ ているのであるが、リモートではそれらは使えない。だから、コマンドライン からでも快適に使える管理ツールが欲しいところなのであるが、最近のパッケー ジはコマンドラインのツールを抜く傾向にあるので、どうにも運用がやりにく いのでる。サーバがどのような環境で使わえるか考えれば、これは致命的と言っ ても良いくらいの問題である。
その他にも、ネットワーク周りの設定に関しても、自由度の低いパッケージが 少なくない。ちょっと複雑な使い方をしようと思うと、結局「環境設定ファイ ル」をいじるだけではなく、/etc/rcあたりにスクリプトを色々書くことになっ てしまう。そうなると一見完成度の高そうな設定システムは、単なる飾りもの になってしまう。
信頼性について考えてみると、これもちょっと首をかしげざるをえないことが ある。もちろんシステムが動くという観点での信頼性は非常に高いので、その 点には不安も不満もないのであるが、セキュリティ的には非常に不安も不満も ある。例えばRHSはバージョンアップの度に旧版での問題点を公開しているの であるが、これがちょっと「公開しすぎ」なのである。見方を変えてこの障害 情報を見ると、「旧版にはこんな穴があるんだよ」という情報であるわけで、 ちょっと古い版を使っていることが知れると、攻撃の対象になりやすい(現に 攻撃されてしまった。これが冒頭に書いた「やまだ君の出張」の原因である)。 もちろんこの情報に従ってまめにバージョンアップをやって行くのが正しい運 用であろうが、そこまで手が回らないとの同時に、「新しくするということの 危険性」を考えると、いくら現状に問題があるからと言って、無闇に新しくし て行くわけにも行かない。そうなると親切で公開されている旧版のバグ情報も、 迷惑になってしまうのである。
サーバというのは長期連続的に使われるものである。だから、セキュリティ絡 みのバージョンアップが要求された時でも、長期連続的使用という利用環境に 対応したバージョンアップが欲しい。しかし、現状これに対応したパッケージ も存在しない。つまり、現状の動作環境を維持しながらバージョンアップする ということが困難なのである。RHSやDebian等はこの辺をかなり頑張っている のであるが、Linuxは日々進歩しているので、諸々のアークテクチャが新しく なることがままある。例えばELFバイナリとかshadow passwordがそうなのであ るが、これらはシステム全体の大きな変更をしないと安全に採り入れることが 出来ない。事故なく採り入れるためには、それらを採用したパッケージを待っ て、システムの再インストールするのが確実である。ところが、サーバはそん なに大規模な変更は極力避けたい(現状動いていることが重要)のであるが、そ のような「最新技術を採用しないでプログラムだけ最新にする」といったパッ ケージのバージョンアップが存在しないのである。これは長期安定に運用する ためには障害となることである。よくWindowsNTが互換性のないバージョンアッ プをすると言ってEDP部門に嫌われるのであるが、実はLinuxも他人事ではない のである。
余分なことをつけ加えると、RHSはサーバとしては全く向かないパッケージで ある。細かく説明するだけの紙面がないので、細かくは書かないのであるが、 RHSは良くも悪くもWindows(95)的であって、サーバとして使うことは全く考慮 されていない。また前述のような問題もあるので、ハマりたくない人は避けた 方がいい。クライアントとしては悪くないパッケージであるが、サーバには使 えない。現在のriccia(www.linux.or.jp)はRHS Ver 4.1を基本に構成してはい るのだが、これはRHSがサーバに適しているから選択したのではなく、ただ単 に最初に「使ってみた」のがRHS Ver 2.3であり、それからの連続性を維持す るためだけである。中身は随分といじられているので、単なるRHSとは随分違 うものである。
もちろん現状のパッケージの持つ問題を克服するのが、我々サーバ屋の腕に見 せどころなのであるし、「素人には無理なんだよ」と言って商売出来るという のはある意味良いことかも知れない。しかし、マーケットというものは、底辺 が広くなってこそ大きくなるものなわけであるから、長い目で見れば我々サー バ屋にとってもマイナスである。もちろん自分でサーバを構築したい人にとっ ても、嬉しいことではないのは当然である。
このように、Linuxにとっては「得意分野」と思われているサーバとしての活 用であるが、非常に大きな可能性を持っていると同時に、実際に使ってみると 多くの問題をはらんでいることがわかると思う。ところが、この辺の問題を意 識している非常に少ないか、「そんなもの」だと思って使っているのだろうと 思う。しかし、「そんなもの」と言って現状を肯定したり、「昔からそうであっ た」と言ってしまっていては、進歩がない。また、Linuxの進歩というのは、 そういった世界の否定によってあったと言っても過言ではない。
そういったわけで、サーバとしてもっと普及をさせるなら、やはり「誰でも運 用出来る」とまでは行かなくても、「それなりの人なら楽に運用出来る」程度 の完成度を持ったパッケージの登場が期待されるのである。