Web屋のネタ帳

メモ。技術的な話。

Linuxはもちろん多くののUNIXではログの入出力にsyslogdが使われている。 標準でついているものだし、古くからあるものだしバグも枯れてるし、 様々な入門書やWebサイトで広く解説されていて、しかしその問題点に触れているものは少ないせいか、 何の疑問も持たずに日々使っている人も多いだろう。

そう。実はsyslogデーモンは大きな問題点を抱えている。

1. ディスクI/Oの方式がかなり非効率的（というか今風ではない）なため、重いし遅い。
2. リモートでログ情報をやり取りしようとすると漏れが発生しやすい。

上記の２はともかく１は、実は致命的とも言えるほどの遅さなのだ。

で、syslog から daemontool へ変更した結果、top で監視したところ、 iowait が 50 ％超→15 ％前後まで軽減されました。
syslog は I/O 負荷が高い → daemontool に移行しよう！ (Drk7jp 2006.5)

なんでそんなにsyslogdは遅いのよ？！という話は以下の記事が詳しい。

99syslog - syslog() 及び syslogd の考察(最終更新：2003/5/30)

上の記事にある話は筆者も前々からうわさ程度には知っていたものの、 じゃあsyslogdじゃない選択肢ってどんだけある？(種類とか実績とか)ってあたりで詰まっていた。

が、そろそろ本気でsyslogd以外の選択肢を考えるころあいなのかもしれない。

• daemontoolsによるロギングとプロセス監視（1/3）(@IT 2002/5)
• ＠IT：止められないUNIXサーバの管理対策 第9回(@IT 2004/3)
• syslog-ngへの切り替え(1) (LunaTear 2003/12)
• ログ管理 ～syslogとその周辺～ 【応用編】syslogd の代替ツールについて

動作ログというものは記録という目的以外に、その内容の監視という側面もある。 syslogdには監視機能はないため、swatchなどを併用しているケースが多いのだが、 swatchがこれまたperlでできていて、重い。perlプロセスの常駐というのは結構なリソースを食う。 apacheのmod_perlのように、多少重いのは承知のうえで使うメリットのほうが大きいというのならともかく、 あまりリソースを食わないに越したことはない。 そもそもログデーモン自体に監視機能もついているべきと考えるのが妥当であり、daemontoolsやsyslog-ngはそれを実践してくれている。

ただ、qmailやdjb-dnsをはじめとするD. J. Bernsteinさん提唱のツール群は独特すぎるっていうかもはや宗教っぽくて（笑）筆者はどうも気が進まない。syslog-ngかなぁやっぱり。でもsyslog-ngは基本としてFreeBSD向けに作られてるっぽいのでLinux屋としてはやっぱり気が進まない。まあぼちぼち情報集めるか。

see also:
syslogとswatchからsyslog-ng乗り換えについて雑多メモ

ウェブ進化論という新書がバカ売れだそうだ。 ちなみに筆者はまだ読んでない。というか興味ない。でも客とその話になったとき読んでませんじゃカッコつかないからしょうがない、読むけど。

1995年。Windows95が話題をさらった年。「ビーイングデジタル」という本がＩＴ業界で流行った。 筆者も読んで「うーん、革命だな」とか思ったものだ。若かったなあ（遠い目）。

そういえば「夢がかなうなんとか手帳」のたぐいも、 書籍や文具業界の人に言わせると「だいたい5年か10年周期で似たようなブームがある」ということらしい。

なお、ウェブ進化論やビーイングデジタルはつまらん本だということではない。むしろ逆だ。 この業界で食ってる人なら読むべきだろう。 でも夢を膨らませるばかりで本質や現実を見失っては本末転倒だということを忘れてはならないと思う。

See Also:
ショッピングモールというビジネスモデルの寿命はそろそろ尽きる論について雑感

最近、PHP言語のとある有名なライブラリにバグを見つけたのでレポートしたら、即座に修正版がリリースされた。 別に大したことではないのだが、ついでなので、オープンソースソフトというものの品質とその管理サイクルはこういうものなんだよという話をつらつらと。

PHP言語にはPEARと呼ばれるライブラリ群がある。perlでいうところのCPANにあたると思ってもらえばいい。Javaで言うとjakartaがそれなのかな。

PEARのひとつとしてCache_Liteモジュールと言うものがある。様々なリソースをキャッシュ（一時保存）してくれる便利なクラスだ。PHP関係の書籍でもたいてい紹介されていて、これに依存しているほかのモジュールも少なくない。メンテナはこの人で、フランス人らしい。

ここからは時系列で書こう。すべて日本時間。

2006年2月21日	Cache_Liteのバージョン1.7.0(stable)がリリースされる。stableとは安定版の意
2006年5月13日15時54分	上記のバージョン1.7.0を使った筆者がたまたまバグを発見。バグレポートを投稿する
2006年5月13日19時32分	バグのステータスがOpenからVerified（確認済）に変わる。誰かが（たぶんメンテナが）確かにバグであることを確認したということだ。この作業日時はWebの記録には残らないらしいが、通報者である筆者の下には自動でメールが届いていた。
2006年5月14日7時12分	修正版がCVS(ソースコード管理サーバ)上に格納される。同時にステータスがclosedに変わる。これでバグ管理データベース上での作業は完了となる。この段階ではユーザーはcvsに匿名アクセスすればコードをダウンロード可能だがそこまでやる人は少ない。大したバグではない場合にはこの状態でしばらくの間放置され、他のバグの修正や機能追加とあわせて数日から数ヵ月後のリリースとなることが多い。
2006年5月14日7時21分	10分とたたずに1.7.1とバージョン番号を上げてstable版としてリリースされた。大したバグだったらしい（笑）。 この段階ではユーザーはpear upgradeコマンドなどを叩くだけで自動アップデートすることが可能になる。

先にバグの内容について触れておくが、同じキャッシュIDを使った複数回のキャッシュ保存＆読み出しができない（最初の1回目しかうまくできない）というものだ。コードを読める人はこちらで一目瞭然。使い方がおかしいとか意地悪すぎるテストコードだとかいうものではない、普通に実装されうる使い方を、ちょっと短く書き直したものだ。 はっきり言ってかなり致命的というか基本的なバグである。

ここからは、それぞれの事象について適当に述べてゆくことにするので適当に読んでいただきたい。

まず、基本的かつ致命的なバグを抱えたコードがStable（安定版）として公開されていたという事実。と言うと「ひどいもんだなぁ」という人と「そんくらいかわいいもんだろ」という人とに分かれる。後者は当然ソフト開発やその業界の現場の人に多い。客観的に言うと、この程度の現象はソフト業界ではしょっちゅう起こりうることである。

さらに、2ヵ月半も誰もバグに気づかなかったという事実。あるいは気づいた人は世界中のどこかに一人か二人くらいいたのかもしれないが、報告はされなかった。あるいはバグにぶちあたるような書き方のソフトが少なかったため見つからなかったせいもあるだろう。もっとも多いと思われる理由は、皆が最新の1.7.0よりも古いバージョンを使っていたということだろう。

しかし、誰でもいい、世界中の開発者のうちの一人でもいいから、バグに気づき「バグじゃね？」とひとこと報告した瞬間にあっという間にソフトは修正される。上の表で、筆者がバグを報告してから次のバージョンができるまでに24時間もかかっていないことにご注目いただきたい。企業組織にはマネのできないスピードである。もちろんバグの程度にもよる。ちなみに今回修正されたのはたったの一行である。（笑）

今回、メンテナーさんは筆者が投稿したバグの再現コードにちょっと手を加えただけでそのまま テストコードにしたようだ。自動単体テストと呼ばれる仕組みである。以後、すべての開発者はいつでもコマンド一発でこのテストを実施できる。二度と同じバグを発生させないための仕組みだ。多くの企業の開発現場で機能追加やバグ修正のためにコードに手を入れるたびにけだるそうな顔をしたプログラマーがMS-Excel上にずらりとならんだ単体テスト項目に沿ってひとつずつテストしなおしているのと比べると、なんと合理的なことか。

オープンソースはいい面ばかりではない。Cache_Liteのメンテナーは現在のところfab氏だけのようだ。cvsの履歴を追うと他の2,3人もかかわっているようだが、もしもfabさんがやる気をなくしたり車で事故ってもうそれどころじゃないとかなったら？ もちろん他のだれかが引き継いでくれるだろうが、そうならないケースもある。 XML_Beautifierモジュールはもう長いことメンテナー募集の状態のままだ。

「GMOインターネット証券はJBoss，MySQL，PHPなどオープンソースを活用」だそうだ。 ネット証券のシステムでつまらないバグを出したりしたらただじゃすまないのでテストはしっかりやっているのだろう。それでも、そのシステムが土台としているオープンソースソフトウェアたちの品質とその修正プロセスは、実はこんな感じなんだよ、ということは知っておくべきだろう。

see also:
「CVSの言い訳」と途方にくれるユーザ(japan.linux.com 2006/5)