ユメのチカラ

頭に豆電球がともる瞬間

よく、アイデアが閃いた時、頭に豆電球がともる絵を書くが、デバッグをしていて延々試行錯誤をしているのだけど全然解決の糸口すらつかめないとき、ひょんなところからぱっと解決策を思いつくことがある。

そのぱっと閃くまでの手順というのは通常再現することは難しい。思いついっちゃったんだからしょうがない。なんかいろいろ試行錯誤していたうちにたどり着いたというのが正直なところである。

その豆電球がともるまでの道のりは闇の中を彷徨しているようなものでストレスがたまるがぱっと閃いた瞬間の快感は経験したものでないと分からない。言語化するのが難しい。しかし、そのような経験をぜひ若手のエンジニアにも味わって欲しいと思う。そのぱっと閃く経験を積み重ねれば積み重ねるほどエンジニアとしての経験値、力量は上がっていくわけで、引出しの多いエンジニアになる。

コアテクの路地からのトラックバックを貰ってそんなことを考えた。

日常的な仕事の中では毎日毎日そんなに豆電球はともらないかもしれないが難しい問題でうんうんと唸っていた後に到達した場合は問題の難しさに比例する快感がある。山登りみたいなものかもしれない。

実はわたしは昔からカーネル開発者にあこがれていて、いつかはカーネルコミュニティにデビューしたいと思っていた。できることならばLinuxカーネルの性能向上に微力ながらでも貢献したいと漠然と思っていた。正真正銘のカーネルハッカーならば、鼻歌交じりに性能上の問題を発見しそれを修正するだろうがわたしのような素人は手も足もでなかった。

そこで、性能上のボトルネックを発見するにはカーネルプロファイリングツールが必要だということでhardmeterというツールを３年ほど前に開発した。そのアイデアは幸運にも未踏ソフトウェア創造事業に採択された。パフォーマンスチューニングをするときにプロファイリングをとってそのデータをもとに分析するというのはチューニングの王道中に王道である。しかし、hardmeterの開発では精密なカーネルプロファイリングが取得できるようになったが、それを利用して実際カーネルをチューニングするまでにはいたらなかった。（残念）

後に日本OSS推進フォーラム開発基盤WGのプロジェクトでカーネルの性能評価をしたときにhardmeter開発の経験が役に立ったことは言うまでもない。oprofileという2.6に採用されたカーネルプロファイリングツールを利用してデータを収集した。当初は全く問題点が見えていなかったが約一月ほどプロファイリングデータを分析したところある日突然頭に豆電球が閃いた。その結果はCache Pollution Aware Patchという形になったのだが、後にhardmeterで採取したデータを見ていたら、oprofileで発見した問題の兆候がくっきりとあった。2003年では発見できなかったものを2005年には発見できるようになったのである。

歳をとっても人間は意外と進歩しているのである。脳みそをフル回転してときには頭に豆電球をともさないとと思った瞬間であった。

意外と読まれていない新聞

昨日、朝日新聞の朝刊の「ウェブが変える」という記事の中でわたしの名前が出ていたのだが、知人友人から読んだよという連絡はほとんどない（一人メールをいただいた）。朝日を購読している人でも気がついた人はあんまりないようだ。ところが梅田望夫氏の「ウェブ進化論」に引用された時は、わざわざメールで「よしおかさん、ウェブ進化論に載ってましたね」と知らせてくれる人が何人かいたし、リアルで会った時の話題にもなったりした。

新聞は毎日毎日配達はされるけど、情報としてはどんどん流れていってしまうので、昨日の新聞記事の話題なんかはもはや言及することすらできないような感じである。ウェブ版にでも掲載されていれば引用もできるのだが紙だとそれもできない。

本日の朝日新聞に梅田望夫氏と西垣通氏の対論が載っているがブログ界隈ではほとんど言及されていない感じである。新聞と言うのは誰が読むのだろうか？一面と言う特等席ですらじっくり読む人はそれほど多くはいないような気がした。少なくともわたしは新聞をざっと眺めることはあっても日々じっくり読むと言うことはほとんどしていない。

会社負担の社会保険料の計算

あるプロジェクトでプロジェクトメンバーごとの人件費単価（社会保険料の会社負担分）を算出する必要があっていろいろ調べたのだけど、非常に複雑であった。

社会保険料として、健康保険、厚生年金、雇用保険、労災保険、児童手当拠出金、介護保険などがあるのだけど、会社負担分と個人負担分が微妙に違うので、個人負担分を元に簡単にちゃかちゃかっと求めることができない。

個人負担分は賃金台帳（各人の給与明細みたいなもの）を見ればすぐにわかる。それぞれの項目について、年間いくら支払われているかがわかる。

月額の報酬に会社負担分の健康保険料率、厚生年金保険料率、雇用保険料率、労災保険料率、児童手当拠出金、介護保険料率などを掛け合わせて電卓でぱちぱちすると、一人一人分の社会保険料がでてくる。話がややこしいのが、昨年の4月から雇用保険料が変更になり、10月から厚生年金が変更になった。

雇用保険料率の会社負担分は、10.5/1000（平成17年3月まで）、11.5/1000（平成17年4月から）、労災保険料率は、5/1000である。児童手当拠出金率は0.9/1000で、厚生年金は69.67/1000(平成17年9月まで）、71.44/1000(平成17年10月から）、介護保険料率（40歳以上）、4.1/1000（平成17年3月まで）、4.8/1000（平成17年4月から）、健康保険料率は27.5/1000となっている。会社負担と個人負担の率が違うので給与明細の社会保険料の合計だけでは会社負担分が求まらないのである。

何度聞いてもよくわからない。表計算ソフトを駆使するのだが結果の正しさに自信がもてない。経理の専門家にいろいろ教えてもらってどうにかしたのだが、Googleだけでは一発で正解にたどり着かない例であった。（とほほ）

7月27日の朝日新聞朝刊

本日（7月27日）の朝日新聞の朝刊第一面、「ウェブが変える」という記事の中で下記のように、わたしの発言が引用されています。

リナックス関連製品を開発するミラクル・リナックス社(東京)の吉岡弘隆・最高技術責任者は言う。「こんなやり方はうまくいくはづがないとだれもが思う。失敗例も山ほどある。だけど、ものすごい知的資産が生まれている」

ウィキペディアなどの仕組を解説した囲み記事です。御覧ください。

デバッグの話（昔の日記から）

わたしは、90年代にシリコンバレーにいたとき、シリコンバレー日記と言うものを書いていてWebで公開していた。今そのサイトはないのであるが、インターネットのWebアーカイブにその内容が残っている。先日「プロセスプログラミングの実践方法」というエントリでデバッグの話を書いたので、それつながりということで、当時、記した日記を全文転載し、ちょっと長くなるが後書き的な解説を加えたい。文体が微妙に違うがご愛嬌と言うことでご勘弁願いたい。

転載始まり

デバッグ

誰もが使っている言葉なんだけど，実のところよく分からない言葉というのがある．少なくとも，なんとなくの定義はあるのだけど厳密な全員が納得できるような定義があるようでない言葉というのがある．

デバッグというのも実はわかったようでいてよく分からない．とりあえづ，デバッグというのはプログラムのバグを直す作業だとしよう．そうするとプログラムのバグとは何か？という当然すぎる疑問が湧く．バグというのを，仕様書と実際の動作との差という風にも定義できそうである．これはプログラムの予期せぬ動作を，「いや，それは仕様です」といういいわけに使えるので，プログラマには好まれる定義かもしれない．しかしもう少し広範囲にとらえれば，やはり，利用者の期待する動作と実際の動作の差をバグという風に言えなくもない．期待する動作より，いいほうに実際の動作があればだれも文句を言わないだろうから，不都合側の動作ということにしてみよう．

というわけで，とりあえづの定義として，デバッグという作業はそのプログラムのバグを直すことだとしよう．

さて，そのデバッグをあなたはどのようにしているのだろうか？ワークステーションの前に座って，コーヒーをがぶがぶ飲みながら時にはハンバーグをほお張りつつ何時間か格闘するといつのまにかにバグが直っている．そーゆーなぞのプロセスなのだろうか？

そのプロセスをわれわれは記述できないだろうか？どーゆーステップをもってわれわれはデバッグをしているのか？

それを記述する事にどのような意味があるのか？一つはそのようなプロセスが記述できれば，無駄や，無理や重複作業などを発見する手がかりになるのではないか？つまり理解していない事は決して改善できないのだという大前提の元，プロセスを理解すればそれを改善するきっかけをつかめるのではないかという立場である．

あるいは新人エンジニア（彼らは往々にしてデバッグ作業の効率が悪い）に対してのお手本になるのではないだろうか？

わたしは大胆にも自分のデバッグのプロセスをここで記す事を試みてみたいと思う．皆様の忌憚なきコメント，サジェスチョンを頂ければ幸いである．

バグの発見：なんらかの方法でバグが発見される．われわれはバグが誰によってどのように発見されるか実はそれほど深く理解していない事実にも驚かされる．

実のところ，その前にバグの作成というプロセスがあるのだが，ここの部分もまったくと言っていいほど解明されていない．一つだけ確かな事があるとしたら，バグが誰によって作られるかという事実である．もちろんプログラマによって作られる．すなわち，わたしや，プログラマであるあなたによって，作られるのである．作られるという受け身な態度は潔くない．バグはわたしやあなたが作るのである．バグが自然発生することは決してない．しかしながらどのようにバグを作るか，なぜ作るかという点に関してはわれわれは十分理解はしていない．

ここでは，バグがなぜ発生するかという問題にはとりあえづ触れない事にする．ともかく，誰かが作ったバグを誰かが発見する．そして誰かが直す．すなわちわたしやあなただ．

バグの再現：誰かが発見したバグの現象を再現する．ある操作をすると，システムがクラッシュすると報告されたのならその操作を繰り返してみる．それで再現できればいいのだが，タイミングや作動環境の違いで再現できない場合が多々ある．その場合は，作動環境，例えば，OSの種類や，各種ハードウェアなどをできるだけ同一の条件にする必要がある．それでも再現できなければ，バグを発見した実機の環境で同様な作業を繰り返し，バグを発生する条件を確認する．場合によってはここで座礁する事もある．試行錯誤の繰り返しでもある．

バグを再現する事に成功したとしよう．条件がよければ，エラーメッセージや，コアダンプなどの資料が入手できるかもしれない．

どこでメッセージを出しているかを見つける：どのルーチンがどのエラーメッセージを出しているか？通常はスタックフレームを見れば，どのルーチンで異常終了しているかがわかる．当面はそのルーチンの界隈から，狭義のデバッグ作業が始まる．

当該ファイルをデバッグオプションでコンパイルする：OS付属のデバッガーを利用して，デバッグオプション付きで再コンパイルしたプログラムを実行する．異常終了するルーチンにブレークポイントを設定して，異常終了する直前の各種の変数の値などを調べる．

それからのプロセスは，ちょうどプログラムの実行を逆順に戻っていく作業になる．例えば，ある変数がXなので異常終了したとしたら，なぜその変数がYでなくXになったのか？それを探っていく．変数の場合は代入されない限り，値は変更されないので，代入されている場所を特定する事がポイントになる．

情報をいかに検索するかがデバッグの効率を左右する．全体像を理解するためにソースコードの理解がかかせない．どのルーチンがどのルーチンから呼ばれているか，呼んでいるか，というコールグラフ．どの変数がどこで定義され，どこで代入され，どこで利用されているか．そのような理解をする．

原因の特定：プログラムの挙動を詳細に理解すれば，自ずとバグの原因は発見できるであろう．わたしには原因の特定の瞬間のプロセスを記述する事はできない．手に余る．ともかくわかるときにはわかるのである．

修正案の検討：バグの原因は特定できたとしよう．特定できれば，それをどのように修正すればいいかのいくつかの案を検討する．実装上のコスト，修正の容易さ，その他の要因を勘案の上，修正案を比較検討する．修正が現実的なコストでできない場合もありうる．そのコストとバグの影響と比較検討して，バグを修正しないというオプションもありうるという事に注意する．

修正：上記の修正を実施する．

テスト：修正の結果，確かにバグが直っていることを確認する．テストは原則として日々のリグレッションテストに組み入れる．

リグレッションテスト：修正が従来の機能に影響（リグレッション）を与えていない事を確認するために，リグレッションテストを流す．

ソースコードレビュー：変更したソースコードを担当のプログラマとレビューする．変更が軽微なものなら，変更分をメールで何人かのプログラマに送ってコメントをもらう．

チェックイン：修正をソースコード管理システムに登録する．

それ以降：これでバグを一つ修正した．それ以上なにが必要なのだろうか？デバッグのプロセスを通じてわたしはなにを学んだろうか？もっとうまい方法はないだろうか？この修正はベストだったのだろうか？それともデバッグというのは黒魔術と一緒で，学習可能なものではないし習得可能なものではないのだろうか？

わたしはデバッグというもっともプログラミング上で神秘的なこのプロセスをもっと深く理解したい．そしてもっと熟達したい．エキスパートになりたい．そのために，自分の作ったバグを記録し，デバッグの記録を取っている．そして記述を通して，自分の稚拙なプログラミングテクニックを再確認しいかにしてそれを向上させるかを学んでいきたい．できれば，あなたのデバッグプロセスからも学びたい．われわれがプログラミングについて理解するために，そしてそれによって少しでも賢くなるため，このような微視的な記述やデータが必要だと思うのである．

はげましのお便りは よしおかひろたか
までどーぞ．
日記のページへもどる．
一覧へもどる．

よ

シリコンバレー日記／未来のいつか
http://web.archive.org/web/20000928213350/www.best.com/~yoshioka/d/98/i980301.html
文字化けするときは、
Microsoft Internet Explore 表示＞エンコード＞日本語（シフトJIS）
Mozilla Firefox  表示＞文字エンコーディング＞日本語（Shift_JIS）

転載終わり

1998年3月1日に書いた日記である。デバッグのプロセスというのはほとんど変わっていないように思う。技術の進歩と言うのは速いのだろうか？遅いのだろうか？ソフトウェア開発に対する理解というのがこの10年どのくらい進歩したのだろうか進歩していないのだろうか？

マクロでみるとソフトウェアのテスト＆デバッグのプロセスはかなり定式化できることがわかる。またある程度自動化することもできる。そしてそれがデイリービルド＆リグレッションテストとしてよく知られているベストプラクティスである。

ソフトウェア開発の非常に人間的な部分であるデバッグのプロセスをもっともっと深く理解したい。その思いは10年位前と変わらない。しかしながらこの10年で自分がどれほど進歩したかと言うと正直言って忸怩たるものがある。商用ソフトウェアを作っていた当時と比べて自分の専門性がどれだけ研ぎ澄まされたかと言うとほとんど進歩していないのではないだろうか。そう考えると道はとてつもなく長く険しい。

しかし10年前と現在で大きく変わったことがある。OSSとインターネットである。

10年前わたしが記述したバグ情報はすべてプロプライエタリな情報として企業の壁の中にあり同僚以外と共有することができなかった。わたしの書いたコードは門外不出だし、変更記録も、バグデータベースの記述ももちろん知的所有権の名の元に幽閉されている。

10年前はわたしとあなたは微視的なデバッグの記述を共有できなかった。

ところが10年たってわれわれはオープンソースと出会い、わたしはわたしのコードだけではなく、わたしのつたないデバッグのプロセスをあなたや世界中の誰かと自由に分かち合うことができるようになった。

なんていうことだ。

この情報をインターネットに公開しておけば、未来のいつか、世界の誰かがこの情報を発見してくれるかもしれない。ひょっとしたらデバッグのプロセスをチューニングしてくれるかもしれない。それはあたかもソースコードを公開すれば、そのコードが利用するに値するだけの価値があり、利用者の注目を浴びて、多くの人に利用されるのならば、世界の誰かがコードを改良するという、ソフトウェア開発におけるバザールモデルのように、このデバッグというプロセスをより高度にチューニングしてくれるかもしれない、などと夢想するのである。

8年前に書いたわたしの日記を8年後に自分自身が再発見し、それをきっかけに一つのブログを書き、それを読んだあなたがひょっとしたらいつの日かソフトウェアプロセスのチューニングに参加してくれるかもしれないと考えると、インターネットというのはすごいメディアだとつくづく思うのである。世の中まだまだ捨てたものではないなあなどと妄想するのである。

デバッグのプロセスを詳細に記述する。そこからデバッグに対する深い理解が生じるようになる。
そしてその記述はインターネットによって時間と空間を越えて共有できる。それはデバッグに対する深い理解として人類共有の財産になりうる。

OSSとインターネットというのはすごい環境である。

プロセスプログラミングの実践方法

学ぶ方法を学ぶことは重要だ。知識は陳腐化する。しかし、学ぶ方法というのは、道具立てが変わってもかなり安定的で変化は少ない。

インターネットのおかげで確かに知識の取得方法は劇的に変化した。量的な変化が質的な変化に転換した。なんでもかんでもインターネットで検索してからことをはじめるという感じになってしまった。あんまりじっくり考える機会がなくなったような気がしないでもない。

かつてプロセスプログラミングと言う概念が流行った。最近ではあんまり言わないがソフトウェア開発の究極の姿だと言われた。ソフトウェアは人が作るのだが（当たり前だけど）、そのプロセスを厳密に記述していければ、つまりコンピュータが理解可能なくらい精密に記述できれば、ソフトウェア作製も自動化できるのではないかというアイデアである。随分荒唐無稽なことを言うとあなたは思うかもしれないがあながち夢物語ではない。

例えば、ソフトウェア開発では誰でも利用している make ファイルと言うのがある。これは実行可能なソフトウェアを作成するプロセスを厳密に記述したものといえる。コード自体はもちろん人間が書くのであるが、それを環境に合わせて設定をして、コンパイルしてリンクして様々なディレクトリに配置するという細々とした作業は make システムが Makefile に記述したとおり自動的に行なう。ソフトウェアを作成するというプロセスを自動化したため、些細なタイプミスとかがなくなり生産性は劇的に向上する。

プログラミングの一部分の自動化からもう少し広い範囲でソフトウェアの設計、製造、テスト、デバッグを自動化してやろうというのがプロセスプログラミングのアイデアである。ソフトウェア開発を自動化するためにはどのようなプロセスでわれわれがソフトウェアを作っているかわれわれ自身が知らなければならないのだが、それを記述するのがプロセスプログラミング言語ということになる。機械が実行可能というということで言えばある種のスクリプト言語であるわけだが、人間とのインタラクションがどうしてもはいるので、掲示板とか、コード管理システムとか、バグデータベースとか、カレンダー等々の機能が必要になってくる。あれ、これって、ソフトウェア開発用のグループウェアか？ということである。

オープンソースソフトウェアプロジェクトを立ち上げると取りあえず、sourceforgeあたりにプロジェクト用のサイトを立ち上げる。厳密なスケジュール管理をするわけではないが、大まかなプロセスとして、プロジェクトマネージャのわたしの頭の中にあるものを書き物にして（通常それをロードマップとか言うのだけど）、プロジェクトのポータルサイトに貼り付けたりする。メーリングリスト、Wikiのような双方向の掲示板、バグデータベース、コード管理システム、カレンダーなどなど標準的なツールを利用してプロジェクトを発足させる。

ロードマップを実装するのは人間で機械ではない。コードを書き、テストをし、デバッグをするのも人間で機械ではない。しかし、バグデータベースにバグを登録すると誰かにそれが通知され、誰かがそれを修正し、コード管理システムにその修正を登録する。その流れは、コードを直すという行為など人間が関与する部分とコードを管理するなど機械が関与する部分とに記述可能である。

テストなどもデイリービルドとリグレッションテストという黄金のパターン、王道中の王道があるわけだが、それは自動化でき、ベストプラクティスとして広く利用されている。

コードを書く部分など人間の創造的な部分はもちろんある程度は残るが部品と部品を組み合わせて高い生産性でソフトウェアを作ると言う流れはある。最近フレームワークが流行っている。

デバッグのところはどうだろうか？

問題解析というもっとも人間的な部分はそもそも記述可能なのだろうか？記述可能であればなんらかの方法で機械化、自動化できるかもしれないけど。

デバッグは一つ一つが特殊でそれを記述することは不可能であると多くの人が言う。本当にそうなのであろうか？

デバッガを利用して、デバッグすることを考えよう。わたしは定番の gdb というデバッガを利用して日々デバッグしているのだが、そのプロセスは下記のとおりだ。

1. gdb を起動する
2. 適当な位置にブレークポイントを設定する
3. 実行開始する
4. ブレークポイントで停止する
5. 問題となっている変数の値を確認する
6. 値が期待する値なら、2に戻る
7. 値が期待する値でないならば、実行開始してから停止した間のどこかにバグの原因があるはづなので、それ発見するために当初設定したブレークポイントより実行位置が早い部署にブレークポイントを設定し、1から実行する。
8. 正常に実行終了したら終わり

ほら記述できるではないか。

記述できると何がうれしいか？上記のプロセスを誰かに伝えることができる。「ソフトウェアのデバッグと言うのは試行錯誤でやるんだよ」、「気合だよ気合」、「まあ経験と勘だな」という先輩の言葉よりはるかに具体的でかつ再現可能である。「ブレークポイントをどうやって見つけるんですか？」という本質的な質問を後輩がしてきても心配いらない。力ずくの方法であれば実行位置の真ん中あたりに適当にブレークポイントを設定して何度か試行錯誤をすればいい。もう少し気の利いた方法であれば、ソースコードをよく読んであたりをつけるのであるが、こっちは経験と勘の感じがするのでちょっと説明が難しい。しかし前者の力ずくの方法は必ずしも悪くない。2分検索で効率的に問題領域を絞り込むことができる。(2分検索の具体的なイメージはみたのブログBisection searches あたりを参考にしてほしい）

デバッグの方法は記述可能だし、gdbのコマンドとして実行可能ですらある。

xemacsとgdbという黄金のツールを日々わたしは利用しているのであるが、コマンド履歴はxemacsのバッファに残るので、それをファイルに保存しておけば、自分がどのように問題を解決しているかコマンドレベルで記録できる。それを見れば自分の試行錯誤の足跡がはっきりと見て取れる。それを見ながら時々 hisotory コマンドを利用してトラブルシューティングを繰り返すのである。

コマンドのオプションを忘れたら man を見ればいい。ソースコードをまとめて　tarball にするという作業の度に man するというのもいいがかつてどうやったかを hisotry で確認してそれをカット＆ペーストすれば間違いが少ない。

昨日までのデバッグの足跡もgdbのバッファに残っているので、デバッグのプロセスを再開してもすぐにフルスピードでデバッグに復帰できる。makeしてテストしてデバッグしての履歴もすべてxemacsのバッファに残っている。ファイルの落としておけば数ヵ月後にバグが見つかってすぐにトラブルシューティングしなければいけないとき、そのファイルを見ながら、～という設定をしてXXということをやってmakeしてテストしてデバッグして…というプロセスにすぐに復帰できる。人間の記憶は当てにならないがコマンドの履歴は厳密である。

プロセスプログラミングの第一歩はシェルの履歴を保存することにある。

そして、それはプログラマとしての自分自身の生産性を劇的に向上させる。一度お試しあれ。

ミラクルブログが微妙な味を出している件について

なぜだかわからないのだが、弊社の技術系ブログが微妙な味を出している。

まあ、きっかけは正直言って、単なる思い付きレベルの企画だったわけであるが（わが社もブログの一つもやらにゃ～あかんだろうなんてことを会議で誰かが言った）素人なりに試行錯誤しつつ技術陣がいろいろ書き始めたころから風向きが変わった。

まづ、みたのブログだ。人気順でブックマークをソートしてみた。Ext3ファイルシステムで削除したファイルを復元するにはどうしたらいいかというネタが堂々一位である。わたしもかつてやったがファイルの復元ネタはいつの時代にも必要とされている黄金のネタだ。カーネルハッカーらしいネタが満載である。ちなみに、http://kernel.org/git/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git&a=search&h=HEAD&s=miraclelinux をみると彼の出したパッチがいろいろ見られる。ばりばりのカーネルハッカーである。

で、注目は武田の路地裏ソース解読研究所だ。カーネルダンプという究極の技術ネタを持ってきた。コメントやらトラックバックやら確実に常連をつかんでいる。ひらメソッドでおなじみの平さんや、革命の日々！（57は素数でが何か？）の小崎さんなど確実にいいパスを出してくる。カーネル勉強方法として crash というカーネルダンプ解析ツールを使うという方法を提案しているが、これを洗練していけば「やすまメソッド」が誕生するのではないだろうか？楽しみである。

ぐんぐん、コアな濃いネタに爆走している「みたのブログ」と「路地裏ソース解読研究所」だが、エンジニアの持ち回りの「コアテクの路地」は、硬軟取り混ぜたエントリーで微妙にがんばっている。五十嵐さんの奥さんのご指摘の濃すぎて誰も読まないんじゃないかというご懸念は中途半端にやわらかいともっと読まれないという数字になって出ている。まあ、考えてみれば、世の中、山のようにブログがあってよっぽど特徴がないとわざわざ企業系のブログまで見に来てくれる人はいないわけで、単なる雑談系ブログならそこらじゅうに最強のブログがあるので、簡単に埋没してしまうのである。

わたしのブログは 先日のmixiのお話が好評をいただいが、それ以外はしょぼい結果になっている。やはり、オリジナルコンテンツを地道に発信してリピータを増やしていく必要がありそうだ。

LiveJournalのアーキテクチャ

先日、mixiのお話を書いた(500万倍のスケーラビリティ)が、幸いにも多くの方からブックマークをいただく。ブックマークのコメントを眺めているとmixiのアーキテクチャはkazuhookuさんとmiyagawaさんからLiveJournalと同様なアーキテクチャだとの指摘をいただく。早速Googleで検索してみた。

LiveJournal's Backend -- A history of scalling, August 2005, Brad Fitzpatrick,
4ページ目の図を見るとmod_perlやらmemcachedやらmixiのお話のとき出てきたおなじみのコンポーネントが見える。ふむふむ。ユーザが増えてくるとDBをマスター・スレーブ構成にしてマスターに書き込みそれをreplicate（複製）する。読み込みはスレーブから行なうので、スレーブを増やせば読み込みはスケールするが、マスターへの書き込みがボトルネックになる。ふむふむ。そこで、partition（分割）だ（24ページ）。分割するとジョインができなくなるが、気にしない。user idでパーティションを決定している。一つのテーブルを複数に分けているイメージである。キャッシュはmemcachedがつかさどっている。ロードバランシングにはPerlbalを利用する。分散ファイルシステムはMogileFSである。そのほかストレージ関連のTipsとしてイメージなどblob（バイナリーオブジェクト）は通常のファイルシステムに置く。RDBMSはMySQLのInnoDBで4.xを利用する。ところによってはMyISAMも使う。

memcachedというのはRDBMSのキュエリーをキャッシュする。本来ならRDBMSがやるべき仕事のような気がするがアプリケーションに特化して高速化するというのは一つの方法である。

mixiとの違いをあえて探すとmixiの場合は複数のテーブルをジョインするがLiveJournalはしない（ように見える）。そのためにmixiは複数のテーブルをジョインするためにアプリケーション側で対処している。

というようなことを、今回初めて知った無知なおじさんである。そんな無知なおじさんにもわざわざ教えてくれる元気のいい人たちがネットワークの向こう側にいる。ありがたいことである。ブログを書いて良かったなあと思う瞬間だ。

頭の固いおじさんからみれば、複数のテーブルをジョインするために、SELECT文を2回使って、それをアプリケーションで処理すると言うのは、リレーショナルデータベースの存在を否定（？）しているようなものだから、初めからそんなことはしない。そのような「常識」に凝り固まっていて到底思いつかない。memcachedみたいなものもそれはRDBMSの仕事だろう、RDBMSがキュエリーをキャッシュしないのだったらRDBMSを直せよとか思うのだが、OSSの世界ではまったく違ったレイヤーで軽やかに解決できるのなら、それでいいではないかという割りきりがある。テーブルの水平分割も垂直分割も、データベースのスケーラビリティもOracle RACでいいじゃんという発想からは到達しないアーキテクチャである。

今回のお話は本当にいろいろな意味で勉強になった。オープンソースの技術系カンファレンスは、わたしみたいな無知なおじさんを若者が教育する機会になる。それを世界中で一番必要としているのはわたしである。だから、どーにかして実現したいなあと妄想は膨らむのである。

蛇足だけど、memcachedやそれが利用しているlibeventの性能をoprofileで計測してチューニングしたいなあという遊び心がむくむくと芽生えてきている。わたしが作ったcache pollution aware patchが生きる応用かもしれないなどと思っていたりする。

５００万倍のスケーラビリティ

カーネル読書会で、mixiのバタラさんにmixiのシステムをどのようにスケールアップしたかの話を聞く。開催以来最多の90名の登録（会場の都合で90名で登録を終了した）で、会場は立ち見が出るほどの盛況であった。宴会も50数名の参加をえてこれも大盛況であった。（大よっぱらいの人もいたけど（笑））

内容はYAPCでの発表をアレンジしたものである。ようさんの日記に詳しい報告がある。

システムを1ユーザから500万ユーザまで約2年半でスケールアップしたというお話で、苦労話満載の非常に興味深いものであった。様様な試行錯誤をへて現在のシステムにいたっているが、1ユーザから500万ものユーザをサポートするなどというスケーラビリティはあらかじめ設計されていたものではない。問題にぶつかるたびに一つ一つ問題を解決していって今に至るということである。この500万倍のスケールアップと言うのは本当にとてつもないことである。そのとてつもないことを飄々とこなしているバタラさんのお話が興味深かった。

これがシリコンバレーなら、次のようなシナリオになるだろう。

3年ほど前に誰かがSNS（Social Networking Services)的なものを考え付いたとして、仮に500万ユーザを集めるとしよう。そのビジネスプランが実行可能で期待する収益がそこそこあるのなら、それに対しVC(Venture Capital)がどんと掛け金を張る。

通常、ユーザを獲得するところが最もコストがかかるわけだが、昔のネットベンチャーはそこに莫大なコストをかけユーザを獲得していた【例えば一人当たり100ドルとか(mixiはある意味ユーザ獲得に全くコストをかけていない。口コミで友達の輪を広げていく。)】。3年前に500万ユーザを獲得するというビジネスプランを書いたとしてもたぶん誰も相手にしなかっただろう。

まあ、そんなこんなをすべて取っ払って、仮にVCがどんとお金を提供したとしよう。

ネットバブルのころだと、VCからどんと資金を調達したら、Sunのサーバ（最近はもちろんLinuxだ）をいっぱいたててDBは当然OracleRACだ。掛け金が高いので定番の部品でSIをやる。時間をお金で買う。

最初から５００万人分のシステムを構築するのは非常に高価なのであるが、あらかじめ５００万人分の負荷に耐えられるような設計にはしておく。１人のユーザにはもちろんオーバースペックでコスト高である。

シリコンバレー的なアプローチはトップダウンでキャパシティプランニングをしてそれに必要な人モノ金を調達する。人は人材の流動性が高いのでその道のエキスパートを適切なコストで調達可能である。お金が集まらなくて十分な収益が上げられなかったら、お金が尽きたところで、終わりである。The End。お金が尽きる前に収益をあげられれば生き残ることになる。

一方mixiはそのようなシリコンバレー的な発展の仕方をしたわけではない。バタラさんが一人で始める。ユーザも一人。まさかそれが2年半後に500万ユーザになるなんて自分自身も思っていなかった。だけど、ちょっと面白そうだからやってみた。そんな感じである。

だから今からみると、その時その時の場当たり的な対処方法に見えなくもないが、その時その時のベストエフォート、最善策を適用していくことによってシステムを育てていった。いかにして限られた資源の中で低コストでシステムをスケールアップしていくか。そしてそのアプローチは、お金も、人も、様々な資源も乏しいネットベンチャーならではの知恵とちょっとした工夫でしのいでいくのである。リスクを最小限にしながらのスケールアップというのはGoogleやYahoo!のような巨艦企業とは違ったベンチャーが取るべき賢いアプローチなのではないかとお話を聞いていて思った。

東京はシリコンバレーではない。シリコンバレーをコピーするのではなく東京ならではのユニークな方法で問題を解決していく。そのようなヒントに満ちたお話であった。

そしてカーネル読書会である。東京にはmixiやらGreeやらはてながある。

カーネル読書会とよしおかの野望
http://blog.miraclelinux.com/yume/2006/07/post_69b1.html

OSSの技術カンファレンス、縦串横串
http://blog.miraclelinux.com/yume/2006/07/oss_f5f1.html

カーネル読書会をきっかけにいろいろなコラボレーションが有機的に発生し様々な専門性をもった人たちとの核融合がおこれば面白いと思う。臨界点には達しているような気がする。

OSSの技術カンファレンス、縦串横串

カーネル読書会とよしおかの野望に平さんからトラックバックをいただいた。ありがとうございます。

弊社の場合、Linux OSのベンダーなのでLinuxの専門家がいるわけだが、同時にOracleとかRDBMSの専門家もいて、それを一つのウリにしている（わたしも元はと言えばRDBMSの開発者だったので、データベースには土地勘がある）。

SIをしていると当然ながら様々なコンポーネントの組み合わせ問題が発生し、その時々にノウハウTipsを組み合わせて対処するわけだが、それぞれの部品がブラックボックスだと、正直言って問題が発生しないようなバッドノウハウを組み合わせることがSIになってしまい、全体最適を目指すと言うことはなかなかできない。

トラブルが起こったときブラックボックスだと対処のしようがないので、結果として定番の部品の組み合わせでなるべく冒険をしないようにする。万が一ドラブったとしてもワークアラウンドに終始して抜本的な対策が取られることは少ない。定番の部品はそのようなバッドノウハウが積み重なっているのである意味安心して使われてさらにバッドノウハウが積み重なるというフィードバックがかかる。

そこでOSSだ。OSSはホワイトボックスなので業者に技術力さえあればとことん原因を追究できる。性能上の問題だろうが機能上の問題だろうが時間とコストの制約の元最適化ができる。OS層、RDBMS層、Web層、アプリケーション層、そして運用それぞれの層で「すり合わせ」が可能である。ある場合はRDBMS側で対処するのが最適だとか、OS側で対処するのが正しいとかそのような判断がホワイトボックスがゆえにできる。

オープンシステムというのが既存のプロプライエタリな定番製品の「部品の組み合わせ」であったのが、OSSで構築したシステムの場合は「部品のすり合わせ」である。従ってシステムとしてより最適なものを構築できる可能性がある。

徐々にOSSの開発者コミュニティも量的にも質的にも増えてきたので日本で一つ集まっちゃおうということである。それぞれの層で困っている問題を公開して共有してみんなでわいわい考えようということである。プラットフォームから見ると下から上まで縦串を通している感じだし、それぞれの層で見るとPostgreSQLだMySQLだ、あるいはJBOSSだTomcatだ、さらにはPerlだRubyだPHPだというような横串でもある。そのメッシュの中で共通の問題、例えばスケーラビリティをどう確保するかとか、運用コストをどう下げるかとか、あるいは楽しいハックの方法とか、さらにはプログラマとして幸せな社会とはとか、まあなんでもいいのだけどごった煮風にいろいろ議論できたら楽しいのではないかなあなどと思った次第である。

僕はカーネル専門だが、カーネルを読んでいると特定アプリ（DBMSとか）のパフォーマンス
を上げるための工夫を見つける。
そういったものを見ていると、どうしてもカーネル単体として説明するのではなく、ア
プリを含めた全体として説明したくなる。そうなるとすごく面白いんじゃないかと。

中略

つまり、上から下まで、特定アプリからCPUレイヤまで通して説明したい。縦串である。
でも実際問題、こういうのは難しいと思ってた・・・。
ところが7月のLMSに、難しいと思ってたコラボが実現できた。kosakiさんが、遠方はる
ばる参加してくれることによりアプリ→glibc→カーネル→CPUのストーリーを作ること
ができる。縦に上から下まで説明できる。これは本当にすごいことだ。
ひら／縦串　http://d.hatena.ne.jp/hira_sosuke/20060702/1151836228

弊社の武田のブログも微妙にからんできて、

今回は、mixiのシステムの成長に関するお話ということで、ちょっと興味があります。ここ数年カーネルのお仕事中心でやってきましたが、この知識をもっと上のレイヤに生かせないかと思っていた丁度このごろでした。ぜひ、現実のシステムでの課題を聞いてみたいと思います。最近mixiを使い始めたこともあって、私の琴線にものすごくヒットしています。
カーネルとアプリケーションの関係 http://blog.miraclelinux.com/uraura/2006/07/post_98f8.html

いい感じである。

日本にはGoogleはないけど、OSの専門家やRDBMSの専門家やWebアプリケーションの専門家がバーチャルにコラボレートして世界にないものを創造していく、そーゆー緩い場ができると面白いなあなどど最近思っているのだ。それを東京と言う地域でやれないかなあと。

カーネル読書会とよしおかの野望

カーネル読書会という奇妙な名前のコミュニティ活動を行っている。横浜Linuxユーザグループ（YLUG)の有志と一緒になってわいわいがやがや回数を重ねること60数回である。次回は7月6日にmixi.jpのバタラさんを招いてmixiの急速な会員増にどうシステムをスケールアップしたかというお話を伺う。

発端は1999年の春頃YLUGのメーリングリストにLinuxカーネルのシステムコールの実装方法についてわたしが質問していろいろなやりとりの後、ソースコードをみんなで読むという会があったら面白いですねという話になり、言い出しっぺの法則ということで、第一回カーネル読書会が、1999年4月28日に開催されることになった。http://www.ylug.jp/modules/pukiwiki/index.php?history 参照。

最初のうちはまじめに（？）、ソースコードの断片を持ってきて皆でわいわいあーだこーだ言いながら読んだりしたのだが、参加者が増えるとともになかなかみんなでコードを読みながらやり取りするというのが難しくなっていった。

場所も当初は溝口の市民会館でやっていたのだが、後に渋谷のマークシティにあるサンブリッジのりっぱな会議室になり、しばらくそこをお借りしていたが、2002年に横浜にOSDL Japanがオープンしたこともあって、そこを長らくお借りしていた。横浜ばっかりだと東京にお勤め、あるいはお住まいが千葉、埼玉方面の人が参加しにくいということもあり、NTTデータさんの会議室（茅場町、豊洲）などで何回か開催した。後にOSDL Japanが有楽町に引っ越して大きな会議室がなくなったので、その後は、HP（市ヶ谷）、ミラクル・リナックス（新橋）、日本SGI（恵比寿）など転転としている。また、読書会のようなユーザグループ活動を多くの人に楽しんで知ってもらおうという趣旨のもと、OSC(Opensource Conference)、KOF（関西オープンソースフリーウェア）、CELF テクノジャンボリーなどで出張カーネル読書会を何回か開催している。

ソースコードを読むことは楽しい。そういうと、多くの人は怪訝な顔をする。無理強いはしないしするつもりもないし、もちろんできないのであるが、ソースコードを読むことが楽しいということを少しでも多くの人に伝えたくて、あるいはそのような同好の士を発掘したく、ぼそぼそと続けている。

毎回時間を作って参加してくれる人もいれば初参加ですという人もいる。別に参加人数を増やすことが目的ではなく、みんなでLinuxカーネルやそれの周辺のことを肴にわいわい楽しめればいいと思っているので非常に緩やかに運営（？）をしている。会則もなければ、会費もないし、来たい時に都合のつくときにふらっと参加していただければいいという感じである。発表のあとは懇親会（単なる宴会である）が絶対ついている。これは読書会のデファクトスタンダードといってもいい。宴会の席でさらに議論はヒートアップしたりする。わたしは、時々ビールを飲みすぎて、いい議論をしても翌日すっかり内容を忘れたりしていていかがなものかなと思うのであるが、楽しい印象だけはくっきりと残っている。

カーネル読書会という名前が初心者にとって敷居が高いというご指摘も何回もうけた。実際はコードを一行一行読むわけではないので名前が体を表してはいないのだが、まあ、いいじゃないですか、ということでお茶を濁している。

第61回カーネル読書会の平さんの発表のときだったと思うのだが、参加者のどなたかが「コードを読むことは楽しいんです。みんなでその経験を共有したいのです」というような趣旨の言葉をおっしゃっていたのだが、そうそうその感覚を共有するためにぼそぼそとこの会を続けているんだよ、やって本当に良かったなあと思った。平さんは関東にお住まいでないので毎回参加ということはできないけど。

カーネル読書会の活動そのものはまったく会社の仕事とかビジネスとかには連動していない純粋なコミュニティ活動である。しかし一人のエンジニアとしてこのような活動をすることによって有形無形のメリットがあることも間違いない。私自身毎回なんらかの勉強をし発見をしているので、わたしにとっては大変なメリットがあり、それがひいては自分のエンジニアとしての価値を高め、会社になんらかのほとんど目に見えないくらいの、言ってみれば誤差の範囲ではあるが、メリットがあるのではないかと考えている。

読書会は毎回勤務時間後の夜7時ころから開始しているのであるが、先日のOSDL Japan Linux Symposiumの盛況を見ているとたまには平日昼間開催も悪くないかなあとも思い始めている。

仕事としてLinuxとかOSSに関わっている人の横のつながりを持ったゆるい形の技術的カンファレンスというようなコンセプトである。内容的には今のカーネル読書会の内容で全然問題はないと思う。そのような会合の中で会社や組織の枠を越えた技術的な議論を自由にできるというイメージである。学会とか業界団体とはちょっとちがった空気のカンファレンス・勉強会である。CELFのジャンボリーみたいな感じである。

さらに言うと、今はLinuxのカーネル周りの話題が中心であるが、RDBMSやWebサーバーさらにはWebアプリケーションまで含めた下から上までごった煮の技術的なカンファレンスという感じのものができたら面白いのではないかと思っている。昔ビットバレーという会合があったらしいが（胡散臭いといったら失礼かもしれないけど）、オープンソースの技術で世界を変えてやろうなどという志を持った人々で、だけど技術的な議論をとことんやりたいという人向けのゆるいカンファレンスというイメージである。

最近ではPerlやRubyがいい感じのカンファレンスをしているし、PostgreSQLもMySQLも開発陣の活動が活発である。それら個別のコミュニティをゆるく横串を通して自由闊達に議論できたら面白いと思う。

こんな野望を持っているのだけど賛同者、一緒にやってくれる人いませんかね？