ユメのチカラ

memcached Night in Tokyo #1

先日開催された memcached Night in Tokyo #1 というのに参加してきた。

http://groups.google.com/group/memcached-ja/web/memcached-night-in-tokyo-1

夕方6時開催という昨今の勉強会としては早めの開始時刻なので、あたふたと会社を出た。場所は原宿である。おされな場所である。浮足立つ。ということはどうでも良くて会場であるmixiに初めていったのだが綺麗なオフィスであった。

memcachedというのは、データベースに対する分散メモリキャッシュ技術みたいなもので昨今のWebではよく利用されている。国内ではmixiでの事例がよく知られている。

http://ja.wikipedia.org/wiki/Memcached

この話を初めて聞いたとき、うーん随分乱暴な話だな、RDBMSでやるべき仕事だろ、そーゆーことはと思った。由緒正しいRDBMSではこーゆーのはいかんだろう的なことを思った。しかし発想の転換というかちょっとしたハックというか、実際memcachedのソースコードは6千行位のきわめてシンプルな実装になっていて、MySQLとかスケールしねーよなあとか思っていたハッカーが自分の問題を素早く解決するために作ちゃったという感じなんだろうな、などとも思う。作ってみたら思いのほかいい感じで使いやすくて、どんどん適用事例も生まれ、ソースコードもオープンなので、米国あたりのWeb2.0系企業でがしがし使われるようになったと。

昨今OSやらRDBMSやらアプリケーションサーバやらWebサーバやらありとあらゆるものがオープンソースなので、どこで問題を最適化してもよくてRDBMSの上にちょっとしたキャッシュをおいて擬似的に高速化をはかってみたというのがmemcachedなのだろうなと思う。

mixiでは135台のmemcachedサーバを利用していて(この数もすごいな、国内最大級かな)、メモリを3GBほどわりあてているらしい。マシンはPentium 4との事なので発熱とかもすごそうな気がする。

KLABの安井さんのお話はmemcachedのreplicationだった。memcachedはシステムが死ぬとデータが消失するので、リプリケートをして永続性を持たせたいなあというお話である。永続性とかフェールオーバーとか信頼性とか、そーゆー事を言いだすと、話がどんどん複雑になるのでmemcachedとは相性が悪いのではないだろうかと思うのだけど、どうなんだろう。この手の話も昔からあって、本当の信頼性を求めるなら完全二重化とか、そーゆー話になるのだけど、コストと拡張性のバランスも必要で、さらにはスケーラビリティをどうするかという問題もあって難しい。また非同期の更新だとどうしても原子性をどう担保するかという問題もある。いっそのこと楽観的にやっちゃて、矛盾が発生したらリトライという感じでもいいのかもしれない。

すずききよたか(kiyotaka)さんのお話はmemcachedの利用をいろいろな角度からしていた。まあ、消える可能性のある汎用DBというのは言いえて妙である。Solarisで運用しているので、Solarisのお友達を募集していた。困っている事を自分から晒すというのは勉強会メソッドとしては黄金のパターンかと思う。そして同志と出あう。memcachedを使っているだけではなくSolarisで使っているという同志の結束は固そうに見えた。

mixiの長野(kazeburo)さんは大規模事例で、特にがりがりチューニングをしているという感じではなかった。

はてなの田中(stanaka)さん、30台のcore2 quad メモリ8GBで運用している。それぞれにはXenでmemcachedサーバとアプリケーションサーバを起動しているらしい。こちらも特にチューニングしているという感じではなかった。

mixiの前坂(tmaesaka)さんはmemcached Binary Protocolの解説である。こーゆープロトコルの設計の話は好きだ。速度命だし。テキストのプロトコルだとパースデコードのコストがかかるのであらかじめ定義したバイナリのプロトコルで高速化をはかろうというお話である。バイナリプロトコルであればインジェクションは簡単ではないのでセキュリティ向上にもつながるよ。

固定長のヘッダ(16バイト)+可変長のオマケのフィールドというデータ構造になっている。

http://code.sixapart.com/svn/memcached/branches/binary/server/doc/protocol-binary.txt

opcodeが1バイトなので要素256個の配列で命令実行ルーチンが書ける。デコードのコストは表引きだ。これがASCIIテキストだとstrcmp(command,"hogehoge")みたいなものを延々コマンドの数だけ書くはめになって、コマンドの数に比例したデコードコストがかかったりする。(まあパーフェクトハッシュ関数とか書けばいいのだがカジュアルに命令を追加したりとかはいろいろ面倒なので、結局はstrcmpで延々比較という泥仕事になる)

opcodeを固定長にするというのは王道中の王道のテクニックである。CISCに対するRISC的なアプローチと言ってもさしつかえない。

まあ、そんなことを思ったのだが、この手の古典的な高速化のテクニックというのは昔からずうっと変化していなくて、再発見、再発明が延々繰替えされているような気もする。

温故知新なのである。

でもって現在の実装についてちゃんとoprofileとかでミクロのプロファイリングを取って、チューニングをはじめたという事ではなく、なんとなく直観でぐわっとやっているらしい。まあ、それでもいいっちゃいいのだけど、ちゃんとベンチマークを定義して、oprofileなどでプロファイリングをして、ボトルネックを数字で示し、チューニング大会をするというのが正しい大人の姿である。

いろいろ設定準備とか大変だとは思うが、一度そのような環境を構築してしまえば、開発の最中、運用時等々貴重なデータを入手でき、パフォーマンスデバッグ(チューニング)のインフラになる。開発のプロセスに組込むというお作法は重要だ。なかなか実践するのは難しいが。

プロファイリングしてチューニングをする。王道中の王道だ。

まあ、こーゆーことをお酒を飲みながら、わいわいがやがや語るというのも勉強会の醍醐味でもある。

おまけ：

ソースコードはgithubで公開されているのでためしにゲットしてみた。

$ time git-clone git://github.com/tmaesaka/memcached.git
Initialized empty Git repository in /proj/memcached/.git/
remote: Counting objects: 1602, done.
remote: Compressing objects: 100% (472/472), done.
remote: Total 1602 (delta 1161), reused 1537 (delta 1108)
Receiving objects: 100% (1602/1602), 592.77 KiB | 237 KiB/s, done.
Resolving deltas: 100% (1161/1161), done.

real    0m4.901s
user    0m0.612s
sys    0m0.084s

memcached.c の dispatch_bin_command() はバイナリプロトコルのディスパッチルーチンであるが、だめじゃん。

switch(c->cmd) {
    case PROTOCOL_BINARY_CMD_VERSION:
略
とかしている。ここは表引きだろう。しかもc->cmdの定義はuint8_tではない。だめじゃん。深入りしないことにした。

第89回カーネル読書会

第89回カーネル読書会のおしらせ

日時：08月22日、18時半開場、19時ころ開始

お題： Ottawa Linux Symposium 2008出張報告
発表者： 中村(日立ソフトウェアエンジニアリング)さん、須崎(産業技術総合研究所)さん、吉藤(Usagi Project)さん、大和さん(ミラクル・リナックス)、海外(NEC)さん(順不同)飛び入り発表歓迎です。
内容： OLS2008参加の皆様に今年度のOLSについてお土産話をしていただきます。技術的なことから、単なるオタワ旅行記まで、硬軟とりまぜ、ざっくばらんに語っていただきます。

18:30頃、開場、LTないし自己紹介など
19:00頃、お題開始
20:00頃、懇親会開始

場所は楽天タワー
http://www.rakuten.co.jp/info/map/shinagawa.html
●りんかい線「品川シーサイド駅」出口Cより徒歩1分
(1-minute walk from SHINAGAWA SEASIDE Station, RINKAI LINE)

●京浜急行線「青物横丁駅」より徒歩7分
(7-minute walk from AOMONO-YOKOCHO Station, KEIHIN-KYUKO LINE)

会場の都合上、18:30より以前には開場しませんので、ご注意ください。また受付の都合のため、なるべく遅刻のないようにお願いいたします。

開場した後は、だらだらと自己紹介やら小ネタやらをやりますので、時間の許す限り早めに来た方が面白いお話をきけるかもしれません。

会場で、ピザとビールの懇親会つき。（予定価格1500円。微妙に値上がり中）懇親会参加希望の方は、懇親会参加と明記してください。
学生さんは無料なのでそれも明記してください。

会場の都合で80名で締切ます。

なおセミナー内容につきましては、にこにこ動画などで配信予定です。ustream.tvでのインターネット中継も可能であれば実施します。チャンネル名は未定

登録はいつもの宴会君
http://utage.org/enkai/
宴会コード kernel080822

ＹＬＵＧ年表
http://www.ylug.jp/modules/pukiwiki/index.php?history

ＹＬＵＧ会合、読書会資料
http://www.ylug.jp/modules/pukiwiki/index.php?reading

Emacs勉強会 - tokyo-emacs

Emacs勉強会に参加した。なんやかんやで30人を越える参加登録である。

自分は随分昔からEmacsを利用しているのだが、全然使いこなしている感じがしない。最近、Emacsを勉強しなおそうと思っていたので、早速参加することにした。

http://wiki.livedoor.jp/harg/d/FrontPage

Emacsの基本を勉強しなおそう市民連合(笑)の代表として一言挨拶をした。今回は同市民連合の決起集会(嘘)なので、大いにアジったのであるが、みんなでEmacsの基本を勉強しなおしたいと思った。

早水さんのEmacs Lisp講座は初心者に向けての優しい講座であった。

メモをはりつけておくが、これだけじゃあ、何が何だかわからないなあ。

Emacs Lispは怖くない
括弧は空気
EmacsのことはEmacsに聞け
  ヘルプの使い方
Lispは単純
リストが全て
  ドット対
関数名と変数名の名前空間は別

実践編
.emacsを眺める
  (server-start)
  ansi-term
入門書
  もうひとつのScheme入門
  独習Scheme三週間
  プログラミングGauche
---------------------

files.el

K1LoW
  moz.el
  pabbrev.el
  dabbrev.el

  drill-instructor.el

yuki_neko_nyan
  yasnippet

jj1bdx
  face
  color-theme

IMAKADO
  anything
  補完が凄い

Misho
  Emacs for Latex

naoya_t

.emacs
  IMAKADO

Emacsについて語り合う人が自分のまわりにいない人達にとってtokyo-emacsはとてもいいところだ。大変勉強になった。懇親会で、メモ用紙にマクロの解説をしている早水さんや、それを囲んでわいわいがやがや議論している。楽しかった。またやりたいと思った。

早水さん、参加の皆さんお疲れさまでした。ありがとうございました。

追記：資料を公開した。tokyo-emacs-080628.pdfをダウンロード

Googleを支える技術

Googleという不思議なサービスを提供するそのコンピュータシステムの内側に公開された資料だけを利用して迫った良書である。

Internetの向う側のGoogleというシステムについて、われわれは日々利用しているにもかかわらず殆ど何も知らない。少なくともわたしは技術的な側面について殆ど何も知らない。神秘的な、都市伝説的なもの、例えば、20%ルールとか、そんなことぐらいしか寡聞にして知らない。

本書はGoogleの分散ストレージ(GFS/BigTable/Chubby)、分散データ処理(MapReduce/Sawzall)、運用コスト、開発体制などについて公開された論文などを引きながら解説している。

コンピュータシステムというのは極論すれば、いかに速くするか、いかに安くするかという2軸で発展してきたようなものだから、Googleという巨大システムをどのようにエンジニアリングするかという観点からもこの速くすること、安くすることの実務的な教訓というのは大変興味深い。

RDBMS(関係データベース管理システム)というソフトウェアは多量なデータをいかに格納し、検索するかという観点から開発発展してきたものだが、Googleは、それを地球規模の巨大システムに実装したものと言える。

わたしが本書で最も興味を引かれたものは、分散ストレージや分散データ処理の話ではなく、運用コストの章であった。そしてわたしはこの章が本書の最もユニークなところでしかも最も重要なところかと思う。

フツーのプログラマが計算コストと言うときアルゴリズムの計算量の事を指す場合がおおいと思うが、計算にいくらかかっているかという観点から議論するということは、あまりないと思う。

ムーアの法則のすごいところは、18ヶ月で半導体の集積度は倍になる、すなわちコストが半分になると言い切って、フツーのプログラマにそれを意識させたことである。コストが半分になるのだから、それを意識したプログラミング、すなわちメモリがどんどん増えていく、あるいはメモリがどんどん安くなることを前提としたプログラミングが正しいこととされた。そのようなパラダイムでソフトウェアサイエンスは進化していったようなものである。

コンピュータの高速化の流れも、ムーアの法則にのとって、クロックを高速化する事によって、命令セットアーキテクチャを変更する事なく、様々な実装上の工夫によって、高速化していった。ソフトウェアにとっては、ほとんど何もしないで高速化していったわけであるから楽な時代であったと言える。

ところがクロックをどんどん上げて行くことによって、電力消費量もそれに比例してどんどん増加していって、発熱の問題などが顕在化してきた。そこで、クロックを上げることによる高速化ではなく、マルチコア化等による高速化などが必要になってきた。同様に消費電力あたりの性能を上げるための様々な工夫が必要になってきた(←今ここ)

計算機の消費電力は電気代というお金になる。Googleが利用している計算機は、2000ドル〜3000ドル程度の普通のIAマシンのようであるが、その消費電力が増加の一途をたどり、年間運用コストがそれを上まわるかどうかという事である。

電気代だけではなくてデータセンターの建設費、効率的な電力消費設計などがコスト負担にどんどかかってくる。プログラマは昔はムーアの法則をメモリ空間の増大などと一次元的に考えていればよかったが、今後はメモリ空間はまあそこそこあるとして、消費電力をどう効率的に利用するか、省電力プログラミングが求められてきているような気がする。

消費電力を半分にできれば運用コスト(電気代)は半分になるし、ばかでかいデータセンターの建設も先送りにできる。サーバー機の重要なコストファクタが電気代というのが常識になってくるとプログラマのプログラミングパラダイムも随分変化してくる。

速くするだけではなく、電気代を節約する速さが求められるのである。

モバイル機器なんかは電池の持ちが商品価値そのものを決めたりするので、もっと重要である。バッテリーのサイズが半分になればデザインの自由度も随分増すだろうし、なにより軽くできるし、ハードウェアコストも安くできる。プログラムが物理的なデザインに影響を与えるのである。

プログラマがもっとコストなどの側面に意識を持つべきだと思うのだが、その意味で本書の第5章などは大変興味深くかつ意義深いと思う。

省電力プログラミングというパラダイムをそろそろ真面目に考えないといけない時期である。

Googleを支える技術 ……巨大システムの内側の世界
サポートページ
http://gihyo.jp/book/2008/978-4-7741-3432-1/support

Happy Hacking Diary(著者：西田圭介氏の日記)
http://d.hatena.ne.jp/nishidakeisuke/20080428

Papers Written by Googlers
http://research.google.com/pubs/papers.html

未来のいつか/hyoshiokの日記(電気代)
http://d.hatena.ne.jp/hyoshiok/searchdiary?word=%c5%c5%b5%a4%c2%e5

未来のいつか/hyoshiokの日記(省電力)
http://d.hatena.ne.jp/hyoshiok/searchdiary?word=%be%ca%c5%c5%ce%cf

勉強会のこと

ここのブログの読者の皆様にはご存知のこととは思うが、ほそぼそとカーネル読書会という名の宴会、もとい、勉強会みたいなものをやっている。

最近特に思うのだが、東京界隈ではそれこそ毎日のようにあちらこちらで勉強会など開催されている。定期的な開催もあれば不定期な開催もある。カーネル読書会のようなゆるゆるな運営もあれば、きちんとした運営のもと何百人もあつめるカンファレンス形式のものもある。

まあ、感覚的には結構頻繁にいろいろやっているよねと思っていたのだが、下記のIT勉強会カレンダーを見てほしい。

https://www.google.com/calendar/embed?src=fvijvohm91uifvd9hratehf65k%40group.calendar.google.com

本当に毎日毎日いろいろな勉強会をやっている。このカレンダーは、はなずきんさん(http://d.hatena.ne.jp/hanazukin/)が個人で編集されているものなので、おそらくもれや抜けはすくなからずあるだろう。例えば、仲間うちでやっている読書会とか、広く募集していない勉強会などは当然載っていない。

これらの勉強会の特徴を一つだけあげるとしたら有志がボランティアでやっているものだ。商用のセミナーではない。IT系のカレンダーなので、業界の人達が集まるLinux World Expoとかの日程などももちろん掲載されているが、圧倒的多数はボランティアが自主的に開催している勉強会である。

個人が主催しているので、会費も無償か、あってもかかった経費を割り勘というのが多い。

内容も千差万別だが、それにしてもこれだけのコンテンツをほぼ無償でよりどりみどり勉強できる環境がこの地にはある。

勉強会によっては、勉強会のあと懇親会(宴会だよ宴会)がついてくる。これがまた楽しい。カーネル読書会は宴会があってのカーネル読書会のようなものである。

発表者に直に質問する絶好のチャンスである。宴会で隣に座った人が実は業界で知らぬ人はいない神様みたいな人だったりすることもある。あるいは一度も会ったことはなかったけど日記は良く読んでいたという、ああ、あの人かという人だったりすることもある。

確かに初めて勉強会に行くのはちょっとした勇気が必要だ。周りの人は皆初対面だったりするのはなかなか踏ん切りがつかない。行っても打ち解けないかもしれない。常連の人達は楽しそうにやっているかもしれないが部外者が行っても場違いではないか。などなど行かない理屈はいくらでもつけられる。

しかし、別にそんなに大袈裟に考えることはないと思う。ためしに行ってみて、だめだったら、自分にあわなかったら、別の勉強会に行けばいいだけの話だ。経済的なダメージがあるわけではないし、何がしかの知識が得られ、ひょっとしたらもっとすごい何かを得られるかもしれないチャンスなのである。

だめもとである。

いろいろな勉強会に参加してみて本当に思うのだが、このゆるい参加者の繋がりはとてつもない可能性を持っている。

カーネルの技術者もいれば、Web 2.0の開発者もいる。Perlのエラい人もいれば、Rubyの開発者もいる。ユーザーもいればばりばりのハッカーもいる。皆楽しそうにくっちゃべっている。わたしみたいにビールでヘロヘロになりながらキャッシュミスがどーだこーだなどと延々ヨタ話をかましている奴もいれば、大所高所から日本のIT産業の未来について、おまえはこの国の首相かみたいなツッコミを入れたくなるような論調でべきろんをぶっているやつもいる。

若い人もいれば年寄もいる。

オープンソースの技術論についてはとどまる事をしらない。MySQLやPostgreSQLのスケーラビリティについて、それこそ重箱の隅をつつきながら議論している。LAMPなどの定番のオープンソースについては共通の基盤として語彙がそろっている感じである。

そして単なる参加者だけではなくより積極的に発表者になろうというのが、1000人スピーカプロジェクトである。

http://ja.doukaku.org/wiki/index.php/1000speakers

自分を晒そう
恥ずかしがるための プライドなんて捨てちまえ！
それが自分のためにも 人のためにもなる

1000人スピーカ プロジェクトは、発表経験の少ない人に「自分の技術をさらけだす場」を提供することを目的としたプロジェクトです。

カンファレンスで自分のやったことについて発表することはとても重要です。しかし、参加者が100人を超えるようなカンファレンスで発表するのは敷居が高いです。また、そういうカンファレンスではどうしても参加者同士のつながりが薄くなりがちです。そこで、30人程度の規模のカンファレンスを繰り返し行うことで、敷居を低く、間口を広く、密度を濃くしていこうと考えています。

これだよこれ。こーゆープロジェクトがどんどん増えていって、勉強会の幹事もどんどん増えていって、参加者も発表者もどんどん増えていって、知が流通している。そんな実感がある。

日本にはGoogleはない。

だけど嘆くことはない。

われわれは勉強会、読書会という知のネットワークをここに持っている。

そしてプラットフォームとしてのインターネットを使いこなしている人々がいる。

巨大なバーチャルな学びの場をわれわれは持った。梅田望夫が「私塾のすすめ」で語っているような「私塾」があるような気がする。

参考：

カーネル読書会に必要なことは宴会で学んだ/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/08/post_5135.html
勉強会の幹事に向けて書いた。勉強会の運営のイロハである。

ちょっとした勇気と行動力(オフ会編)/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/12/post_fbd6.html
こちらは参加者へのメッセージだ。最低限、初対面の人と知り合いになろう。名刺交換をしようという、ちょっとしたコツを伝授(大袈裟だな)している。

勉強会でのエピソードなども早速ブログのネタにしちゃったりする。

Web2.0時代のソフトウェア開発のスピード/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/04/web20_5b1a.html
勉強会の後の懇親会で教えてもらったエピソードをネタにしちゃっている。金曜日の飲み会で企画会議をするという。

そしてこのエピソードはいろいろなところで使い回しをさせてもらった。
NDD (Nomikai Driven Development)/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/06/ndd_nomikai_dri.html

カーネル読書会のめざすもの/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/06/post_d222.html
なぜ、わたしはカーネル読書会なるものを始めたのかについて記した。

カーネル読書会とよしおかの野望/ユメのチカラ
http://blog.miraclelinux.com/yume/2006/07/post_69b1.html
ゆるい感じのカーネル読書会の実態を記している。

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

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

1000 Speakers Conference/ユメのチカラ
http://blog.miraclelinux.com/yume/2008/02/1000-speakers-1.html
先に紹介した1000 Speakers Conferenceに参加した時のレポートだ。発表がニコニコ動画にアップされているのも嬉しい。インターネットのおかげで時間も空間も超越できるようになった。

梅田望夫著「ウェブ時代 ５つの定理」

シリコンバレーという地域の競争力はどこにあるのだろう。あの底抜けの明るさはいったいなんなんだろう。と思う。

梅田望夫の［ウェブ時代　５つの定理」はシリコンバレーの空気をビジョナリーの言葉によって表現しようと試みている。

梅田にならって、「ウェブ時代 ５つの定理」でYahoo!ブログ検索、Googleブログ検索をしてみた。このブログを書いている時点でYahoo!で318件、Googleで約272件とでた。発売されてから1週間たつかたたないかで約300件ほどの記事が執筆されたということになる。それを梅田はすべて読むという。

毎日毎日自著の感想を何時間もかけてへとへとになりながら読む。読み続ける。それはなぜだろうと思う。

素人が書きなぐった感想をひたすら読みまくる。

リトマス試験紙として、「コンピュータによって社会を変える」という言葉を考えよう。あるいは「コンピュータによって社会を変えたい」という願望でもいい。あなたはこの言葉に共感を覚えるか、それともそうではないか。強くそう思う、そう思う、どちらでもない、そうは思わない、強くそうは思わない。

「コンピュータ」という言葉を「プログラム」という言葉に置き換えても、あるいは「技術」に置き換えてもいい。

技術者であるあなたはあなたの技術によって社会を変えたいと思っているのか。いつの日か自分の作った製品が世の中のどこかで使われて、何がしかの利便性を誰かに提供し何がしかの価値を発生させる。その様なイメージをあなたは持つのか。

ハッカーと呼ばれる人は、このプログラムによって何が変わるかをイメージできる人であり、プログラムによって社会を変えたいと思っている人のような気がする。

日本という地域で「コンピュータによって社会を変えたい」などというと、頭おかしいんじゃないの、宗教がかっていて気持ち悪いよと思われなくもない。

しかし、シリコンバレーの地には、そのような技術に対するオプティミズが蔓延しているような気がする。

それが彼の地の競争力の源泉なのだろうか？

もしそうだとしたら、それを日本という地域でコピーできないのだろうか？

ウェブという時代に一人一人が生き生きと幸せに生きるために。

高校時代マイクロプロセッサというものを知って、これで社会が変わると高校生ながら思った。就職してインターネットにふれて、これで社会が変わると新入社員ながら思った。オープンソースとであって、これで社会が変わると思った。

そしてWeb2.0の時代。

PCでもなく、携帯でもない。ワイヤレスブロードバンド時代。次の10年に何が来るのか。

東京の地で若い連中とくっちゃべりながら、この連中によって、いろいろ面白いことが始まっていることを確信する。LL (Lightweight Language)やらLAMPやら軽やかに使いこなす彼らが軽やかにWebサービスを立ち上げ緩やかな連携を会社の壁をいとも簡単に乗り越えて行なっている。

素敵だ。

それを目の当たりにすると、日本始まったな、と強く思うのである。

シリコンバレーの空気を日本語で発信し続け、若い人を励まし、彼がやらない限り世に起こらないことを梅田望夫はやる。

日本ならではの強さとシリコンバレーならではの強さの融合という最終定理に向けてわたしも微力ながら何がしか試行錯誤をしたいと思った次第である。

技術セミナー「技術は会社のものではない。みんなのものだ」をYouTubeでも公開しました。

YouTubeでも公開しました。 実は先週中にアップされていたのですが、皆様への公開アナウンスが遅れてすいませんでした。

カーネル読書会、初めてのストリーミング中継

第83回カーネル読書会はささださんの「高速なRuby用仮想マシンの開発」というお題であった。Ruby 1.9.0リリース直後ということもあり、ミラクル・リナックスのセミナールームは立ち見の大入り満員であった。

今回のカーネル読書会の目玉はそれにもまして、初めてストリーミング中継を行なったことである。途中、若干中継が途切れることもあったが、概ね音声、映像とも問題なく中継ができたようだ。インターネット経由で参加した人は60人程度いたようである。こちらも満員御礼であった。

びぎねっとの伊藤さんはじめ撮影隊の皆さん、ありがとうございました。
下記のURLにあるPast Clipsをクリックすると録画した中継映像が見られる。
http://ustream.tv/channel/ylug-83th-kernel-reading-party

ログインすると同時にチャットもできるので、ささださんのプレゼン資料を向かって右、ustream.tvの画面（チャット）を中央のプロジェクトに流した。午後7時の開始前から映像のテストをかねてだらだらと映像を配信したのだけど、音声も予想以上に明瞭に流れていたようである。通常は質問の声とかは拾えないのであるが、小さいながらも質問も聞こえていたようである。

チャット画面で質問やツッコミがあって、それに適宜答えるというスタイルも面白かった。

しかし、それよりなによりびっくりなのは、ビデオとPCとインターネット接続さえあれば、いとも簡単にストリーミング中継ができてしまうことだ。サーバの設定とか回線の確保とか一昔前だったらインターネット中継というのは超大げさな準備が必要で、毎回毎回それを行なうというのは、カーネル読書会のような100%ボランティア活動では人的コストがかかってしまい、現実的には難しかった。それが、本当に簡単に中継＆チャットができて、うは～～すげ～～という感想である。心底たまげた。

今回の講演については、複数台のビデオカメラを回していたので、途中中継が切れた部分も含めニコニコ動画やGoogle Videoなどに再度アップロードする予定である。中継が切れたとき、チャットの画面で、映像が切れた～～という悲鳴が上がったのであるが、そーゆーことなので、もう少しお時間を頂きたく。

ストリーミング中継をしたおかげで、日頃カーネル読書会とは縁もゆかりもない人や（今回はRubyistが多かったと思う）、コアな勉強会は殺伐としていて参加しにくいと思っている人なども気楽に参加できたのではないかと思う。

中継をみて、カーネル読書会って、すげ～～楽しそう、殺伐としていて怖いなんてことは全然ないじゃん、とか認識を新たにしていただくきっかけになったようで望外の喜びである。

質問もがんがんでて、それが愛のある質問だったりして、発表者も参加者も一体となって楽しむというカーネル読書会のスタイルは、すげ～～楽しいのである。

中継のあった部分も予定1時間のところが30分オーバというくらい熱気があったし、中継オフになった後のピザ＆ビアパーティも空前絶後の大盛り上がりであった。

VMとOSの境界線をまたぐような何か新しい試みが出来ると、それはそれで大変面白いと思う。そんな妄想について夜遅くまで盛り上がったのである。

インターネット中継あるいは、映像を見て、カーネル読書会に興味を持った方はぜひ次回のカーネル読書会に参加してほしい。アナウンスはYLUGのメーリングリストに流すので、メーリングリストを購読して次回の参加をお待ちする。http://www.ylug.jp/modules/pukiwiki/

カーネル読書会は83回を数えるのであるが、技術系勉強会のスタンダード（笑）として、もっともっと進化していきたい。いろいろなことを試して行きたいと思う。

mixiのスケーラビリティ

mixiの生みの親“バタラ氏”が語るMySQLの意外な利用法

サービス開始から3年余りで会員数が1000万人を超えたSNSの「mixi」。そのシステムはOSSで構築されており、データベース管理システム（DBMS）には「MySQL」を使う。急増するトラフィックをさばくために負荷分散を重ねた結果、現在ではサーバ1000台以上が連なる超分散システムへ。その中でMySQLが果たす役割とは。http://techtarget.itmedia.co.jp/tt/news/0709/12/news01.html

という記事があった。

日記だけで4億件。サーバは1000台以上。アクティブユーザは6割を超える。すさまじい規模のサービスである。すべてOSSで構成されていて、自社開発のコードでサービスをささえる。

当初一人のユーザから始まったサービスも2ヵ月後には1万人を超え、さらに半年ほどでデータベースをサービスごとに分割（水平分割と呼んでいる）し負荷対策した。しかし1年4ヶ月で100万人を超える会員数の増加は、それだけでは持たず各種IDごとにテーブルを分割している。これを垂直分割と呼んでいるが、DBMS的にはテーブルを水平方向に切っているので水平分割と呼ぶのが正しい。垂直分割というのは通常は列を縦に切ることをいう。例えばあるテーブルに（ID、A、B、C）列があったとして、それをテーブル１（ID、A、B）、テーブル２（ID、C）などと分割することを垂直分割という。

それはさておき、ユメのチカラでもmixiのスケーラビリティは何度か取り上げた。昨年の7月第65回のカーネル読書会でバタラさんに発表してもらったときのレポートである。下記二つをあわせてお読みいただきたい。

５００万倍のスケーラビリティ
http://blog.miraclelinux.com/yume/2006/07/post_7ad0.html

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

LiveJournalのアーキテクチャ
http://blog.miraclelinux.com/yume/2006/07/livejournal_a718.html
こちらはmixiが利用している、mod_perlやmemcachedなどのコンポーネントの話で、それはLiveJournalと同様のアプローチである。

大規模Webサービスを提供するためには、様々なレイヤーでの経験が必要になって、ネットワーク、データベース、OSなどなどどんどん深堀をしていく必要がある。OSSの場合はすべてホワイトボックスなので、やろうと思えばいくらでも深堀をすることができる。それはサービス提供者にとっては価値を生み出す源泉となる。

ソースコードの読み方

ソフトウェア工学の標準的なカリキュラムにソースコードの読み方というのがあるのかないのか知らないが、プログラマとして最も重要な資質の一つにコードの読解力というのがある。

ついでに言えば、大学や専門学校であまり教えられているとはいえないけど、実践では常に必要とされているものとして、テストの方法論、デバッグの方法論、性能向上の方法論、メモリなど各種資源の削減方法論などなどがある。国際化、移植性なども重要な単元であるがソフトウェア工学の中で教授されていると言う話はあまり聞かない。コードのハック一般についてどこかで議論されているのだろうか。経団連あたりで議論しているのだろうか？

閑話休題。

ソースコードの読み方ということで、最近では「コード・リーディング」というそのものずばりの教科書も出ているので状況は好転しつつある。コードの読み方はオープンソースの時代になり、間違いなく広く情報を共有できるようになった。これはいいことである。時代の進歩といっても差し支えない。

カーネル読書会ではその道の優れたプログラマにお話を聞くが、わたしは時々、どうやってデバッグをしているかとか、どうやってコードを読むかというような質問をする。暗黙知としてハッカーがもっているものを言語化してもらってどうにか形式知にしたいと思っている。

しかし、そうは言ってもまだまだ職人芸の世界で、なかなか優れたプログラマの技法というのが形式知化されているとは言いがたい。定石を集めたいところである。

ユメのチカラでは下記のエントリを記した。

コードを読むな、理解しろ
http://blog.miraclelinux.com/yume/2006/10/post_e3d6.html

これはoprofileを利用してrubyをハックした事例である。コードを読むのは端から端まで直列で読んでいたらいくら時間があっても読みきれない。コードを読むには、コードを読まないテクニックが必要でそれを紹介した。ブックマークやトラックバックもいっぱいいただいた。

トラブルシューティングの実際
http://blog.miraclelinux.com/yume/2006/10/post_5353.html
実際にあった問題を、ソースコードの観点から理解するという事例である。使っている道具立てはgrep/findなどなど標準的なものばかりだ。別段トリッキーなことをしているわけではない。包丁とフライパンだけで料理を作るようなものである。職人は道具を使いこなす。その技を見てほしい。

なぜソースコードを読むのか？
http://blog.miraclelinux.com/yume/2006/08/post_3771.html
そのものずばりの話題について記した1999年ころの記事である。大聖堂のプログラマであったわたしがオープンソースの潮流に触れその可能性にわくわくしていた感覚がある。「ソースコードを読む。その基礎的な技術がオープン・ソースの時代には最も必要とされているのである。」と断言しているが、その確信は今でもゆるぎない。

下記は大規模ソフトウェアの効率的な理解という観点で記した。ざっくり通しで読んでいただければ幸いである。

大規模ソフトウェアの効率的な理解
http://blog.miraclelinux.com/yume/2006/08/post_cae5.html
「OSSの時代こそ大規模ソフトウェアの実装の効率的な理解の方法論が求められている。企業が自分が作ったソフトウェアを自社のエンジニアに教育（OJT）するのと違って、OSSはそのような内部構造の教育コースがない。自分のすぐそばにコア開発者がいないので簡単に聞くことが難しい。
中略
その実践的な方法論についていろいろ議論していきたいと思う。」

大規模ソフトウェアの効率的な理解（その2）
http://blog.miraclelinux.com/yume/2006/08/2_2d39.html
ソフトウェアの規模を下記のように定義した。
    規模         行数
    小規模       10万行以内
    中規模       10万〜100万行程度
    大規模       100万行以上
ソフトウェアを構成する行数でおおざっぱにくくっている。あるいは開発に関与する人数によっても同様にくくれる。
    規模         人数
    小規模       10人以内
    中規模       10人〜100人程度
    大規模       100人以上

大規模ソフトウェアの効率的な理解（その3）
http://blog.miraclelinux.com/yume/2006/08/3_dc26.html
規模の把握。

大規模ソフトウェアの効率的な理解（その4）
http://blog.miraclelinux.com/yume/2006/08/4_4b7e.html
巨視的、微視的な理解という観点を提示している。

大規模ソフトウェアの効率的な理解（その5）
http://blog.miraclelinux.com/yume/2006/08/5_de60.html
「動的というのはソフトウェアを実行した時の挙動のことをさし、静的というのはソフトウェア(プログラム)の字面をさす。」
動的理解、静的理解という側面から解説した。

大規模ソフトウェアの効率的な理解（その6）、リグレッションテスト
http://blog.miraclelinux.com/yume/2006/08/6_570e.html
「OSSの実装も単にソースコードやドキュメントを整備するだけではなく、リグレッションテストをどれだけ充実するかという視点で議論、評価される時が来ているように感じる。よりOSSが大規模になり、修正が頻繁に求められるようになるとリグレッションテストが整備されているかいないかで、その変化に対する対応力が全然かわってくるのである。」

gdbの実践的使い方
http://blog.miraclelinux.com/yume/2006/09/post_fa59.html
gdbをデバッガとしてしか利用していないとしたらその威力の10%も利用していない。gdbはソースコードを読むためのツールである。「gdbはソースコードの理解を助ける偉大なツールなのである。」

gdb/xemacs/cscopeの使い方
http://blog.miraclelinux.com/yume/2006/09/gdbxemacscscope_e0da.html
「プログラムの状態は変数の値の変化によって変化していくわけだが、変数は、宣言され、値を代入され、参照されるなどして利用される。」

おまけ：
カーネル読書会とよしおかの野望
http://blog.miraclelinux.com/yume/2006/07/post_69b1.html
「ソースコードを読むことは楽しい。そういうと、多くの人は怪訝な顔をする。無理強いはしないしするつもりもないし、もちろんできないのであるが、ソースコードを読むことが楽しいということを少しでも多くの人に伝えたくて、あるいはそのような同好の士を発掘したく、ぼそぼそと続けている。」

本日のエントリーはソースコードの読み方という観点からまとめてみたが、テストの仕方、デバッグの仕方、性能問題の発見とチューニングなどなどについてもいつかは記していきたいと思う。コメント、トラックバックなどをお待ちする。

追記：
はてなブックマークを多数の方に付けていただいている。（これを書いている時点で100を越えている。）どうもありがとうございます。下記も参考になると思う。
大規模ソフトウェアをgdbを利用して微視的視点から理解をする
http://blog.miraclelinux.com/yume/2006/09/post_8096.html
gdbを利用して、どのようにソースコードを理解するか事例を紹介している。実際にあった事例なので、瑣末なめんどくさい事も含めて参考になると思う。現場はそのような瑣末なことがらにみちみちているのである。

ウィキノミクス

マスコラボレーションはいかに世界を変えたか。

ピアプロダクションでは、財産権という概念が逆転する、なんていう話は俄かには理解しがたい現象ではないか。成果物を他者が勝手に利用しないように制限をかけるのではなく、無償で他人に利用させむしろそれを奨励するというようなことが理解できるだろうか。

インターネットによってコストゼロでマスコラボレーションが仮に可能になったとして、その事例を見せられたとして、自分のビジネスには関係ないどこか別の世界で起きていることではないかと思うのがほとんどなのではないだろうか。

自分のこととして理解してあらたな行動をこの本から起こすと言うのはほとんど考えられない。既にマスコラボレーションのことを十分理解しそこにビジネスチャンスがあると考えている人は、この本があろうがなかろうが行動しているだろうし、そうでない人は、この本があろうがなかろうが何もしないだろう。

オープンソースは既に市民権を得られたといっても過言ではないが、それでもいまだにそれを信頼していない人は少なくはない。

フリーソフトウェアから始まったソフトウェア開発の新しい潮流は、その華々しい成果にも関わらず、多くの人はそのメカニズムに注意を払おうとしていないし、払うつもりもない。

ソフトウェアがどのように作られるかと言うのは多くの人たちにとってどうでもいいことである。それは否定しないが、ソフトウェア企業の中にもそのような無理解な人が数多くいる。

ソフトウェア企業に勤務している人々はソフトウェア企業がオープンソースと言う破壊的イノベーションに侵食されている事実に早く気がついたほうがいいと思う。

自分は関係ないというのは単なる願望で、事実はそうでない。

この潮流は誰にも止められない。

産業経済における知識の独占が急速に崩れつつあるときに企業はどのように行動すべきか。もちろん答はでていないし、完璧な回答というのも見出されていない。

社内に研究開発の組織を持つのではなく社外にそれを求める。そんなことがありうるのか。そんなことを実施できるのか。それによってビジネスを行なえるのか。多くの人は戸惑いいぶかしく思う。

資本主義が高度に発達した結果、地球規模のコラボレーションのインフラを我々は手に入れた。著作権をはじめとする財産権の概念も我々の幸福を追求するために様々な変容を迫られている。

社会的共有資本としてのオープンソースを位置つけたときそれを健全に発展させるにはどのような制度設計が必要なのだろうか。社会としてのコンセンサスをどのように醸造させるべきなのだろうか。

それは、ウィキノミクスという潮流に乗り遅れまいとビジネスパーソンをあおるのではなく、もう少し大所高所から、「カネ儲け」だけではない何物かを、議論すべきではないか。

公的基盤と私企業のバランス。それをどのようにすることが地球規模での幸せにつながるか。

インターネットは誰にも所有されていない。誰でも自由に使える。このアナーキーなメカニズムによって芳醇なコミュニケーションのメディアを我々は手に入れた。

地球規模のマスコラボレーションを当たり前のように空気のような存在として使いこなす人々が間違いなく増えている。

その人々は企業という枠組みをいとも簡単に乗り越える力を持つ。そのような世界ができつつあるのである。

書評 - ウィキノミクス/404 Blog Not Found
http://blog.livedoor.jp/dankogai/archives/50835758.html

カーネル読書会のめざすもの

YLUG(横浜Linux Users Group)のカーネル読書会FAQページがあまりにも古いので更新しようと思ったのだが、どっから手をつけていいやら。

この手のFAQは個別のエントリに回答を重ねて更新する事はもちろん可能なのだが、ロードマップというかカーネル読書会をなぜ開催したいと思ったのかとか、なぜ続けているのかとか、どうしたいのか、とかいう明確な意志の表明なんかがあるといいかもしれないと思った。企業のビジョンステートメントみたいなものである。

おいおい、たかが趣味の世界でビジョンステートメントはいくらなんでもやりすぎだろう。大袈裟すぎやしないか、という声もある。そう思う人もすくなからづいそうだ。わたしもそう思わなくもない。

コミュニティ(？)のビジョンとかミッションというのは通常明文化されないし、されたためしも(ほとんど)ない。LinusのJust For Funという書籍は、ある意味その手のものかもしれないけど例外である。あ、StallmanのGNU Manifestというのがあるなあ。これは例外中の例外だ。

まあ、楽しいから続けていたら続いちゃったというのが本当のことであるが、どうせなら試しに、カーネル読書会にまつわる「よしおかの野望」を明示しておこうと思う。

わたしは、90年代中頃、シリコンバレーの大手データベースベンダーでRDBMS(リレーショナル・データベース管理システム)の開発をしていた。シリコンバレーのフリーペーパーには各種ユーザー会や勉強会の日程が載っていて、その量とバラエティに圧倒された。プログラマとしてプロフェッショナルな道を歩むために、ぜひその手の会合に出ようと思った。機会をみつけて参加したいと思った。たまたま参加した、SVLUG(Silicon Valley Linux Users Group)の活気、熱気には圧倒されたことを鮮明に覚えている。

会社の壁とか人種とか国籍とか性別とか年齢とか、そんなもの一切合切関係なく、ひとつのことについて自由に語りあっている場というのが、どんなにか素晴しいかというのを実感した。

99年に日本に帰ってきて、自分の生活圏にそーゆー場があったら素敵だなと思った。

これからはオープンソースでしょ。みたいなノリもあった。

自由命みたいなノリもあった。

自分が勤めている会社とは対極にあるムーブメントにしびれていたのである。

日本に帰って、たまたまYLUGというのを発見し、早速メーリングリストに参加した。特に会費も会則もないのが気にいった。時々宴会をしているらしい。楽しそうである。

そこで、カーネルのソースコードを読む宴会(？)というのを提案したところ、あれよあれよという間に参加者が集まって第一回のカーネル読書会が開催されたのである。

前半の勉強会形式のディスカッション、後半の宴会という黄金のパターンも第一回で確立された伝統芸みたいなものである。

当初は結構地味にソースコードを追っていたのであるが、何度もやるとさすがにあきるし、準備も大変なので、もちっとお気楽に行こうということで、お題提供者が適当にお題を披露する形式になった。

第８回から場所を渋谷マークシティのサンブリッジのセミナールームにうつしてそれが2001年末まで続き、その後天王町(保土が谷)OSDLジャパンの会議室で2004年にOSDLが引越すまでお世話になった。その後、固定した会場をもたない流浪の旅がはじまったのだが、NTTデータ、ミラクル・リナックス、日本SGI、日本HPなどおかりして開催し現在にいたる。
YLUG年表参照（http://www.ylug.jp/modules/pukiwiki/index.php?history）

時々出張か〜ねる読書会というのをやって新規参加者のリクルーティングをやっているのだが、なかなか思うように参加者が増えない。特に若い人と女子が少ないというのが構造的な問題だと認識している。やはり新規参加者が少ないとマンネリ化してしまうし刺激が少ない。

YLUG年表を見ると、よくもまあこんなにバラエティのあるお題を継続してやったなあと思う。発表者と参加者の皆様に心より感謝したいと思う。また会場を提供していただいた関係各位にも深く感謝したい。どうもありがとうございました。(ぺこり)

一つ一つの発表に思い出がつまっている。どれも大変楽しかったし、勉強になった。多くのことを学んだ。感謝につきない。そんなこんなで現在まで続いているのである。

と、ここまで書いていて、歴史を振り替えるところで力が尽きてしまって、「よしおかの野望」を記すまでには行かなかった。カーネル読書会のめざすところは次に記すことにする。(続く)

NDD (Nomikai Driven Development)

昨日、日本SGIソリューション・キュービック・フォーラムのOSS/Linux　パネルディスカッション−第4回目『OSSはビジネスの道具。もっとクリエイティブな作業を 』に参加した。

モデレータの高澤さんとは旧OSDL時代からのおつきあいで彼の要請であれば出ないわけにはいかない。カーネル読書会の会場にSGIホール(恵比寿)をお借りしているのでおなじみの方も多いと思う。

さて、自己紹介のあと、日本のIT産業が学生や若い人に人気のない3K職種じゃないかという刺激的な横河フィールドエンジニアリングサービス株式会社の丸茂さんのお話から口火を切ったのだが、とりあえづそれを受けてのわたしのお話が下記のNDDだ。

わたしは、カーネル読書会とかいろいろな勉強会で若いWeb2.0系にお勤めの人とお話をする機会があるのですが、彼らは本当に仕事が好きで、毎週金曜日に飲み会かなんかをよくやるそうで、そうすると仕事が好きなものだから、仕事の話になっちゃって、朝までブレーンストーミングみたいな感じになるそうです(若いから朝までオールでもへいちゃら)。そんでもって、いいアイデアかなんか出ると(飲み会の時は自分は天才じゃないかなんてよく思うもんなあ)、そのまま会社に戻って、土日つぶしてちゃかちゃかプロトタイプ作って月曜日にデリバーですよ。アイデアから実装まで数日。まあ、飲み会ドリブンデベロップメント(NDD)ですね。

一方で従来型の開発だと要求定義に半年、実装に半年、テストに半年とか、そーゆー単位で、今回の開発は速くて数ヶ月だったなんていく感じです。経験というのは何回そのサイクルを回したかできいてくるので、2週間で一回経験値を積むのと2年で経験値を積むのでは、その学習曲線の立ち上がりが全然違う。

さらに言えば、mixiなんてのはバタラさんが一人で自分のPCでプロトタイプ作って、会社の人に見せて、10人ユーザで、そのユーザが友達招待して100人で、その次1000人で、1万人、10万人、2年半で500万人ですよ。つい最近1000万人突破っていうプレスがでてましたけど、3年で1人から1000万倍スケールしちゃったわけです。1000万ユーザの基幹システムというのはあるけど、ユーザが10倍になるというのを設計時点で作りこんでいるというのはほとんどない。開発の方法論がまったく違う。mixiはミッションクリティカルシステムではないけど、そーゆーシステムの作りかたが従来のSI現場とは違うところでおこっている。

先週末RubyKaigi2007というのがあって、プログラミング言語のRubyというのがあって、まつもとゆきひろさんという人が一人で作ったんだけど、その会議に400人参加していて、情報を交換している。オープンソースの場合、技術情報というのは社内にあるのではなく、社外にある。自分の問題と同じ問題を持っている人は社内にいるのではなく社外にいて、そーゆー人たちとカジュアルに気楽に情報交換をして教えあっている。コミュニティベースで開発して助けあっている。そーゆー勉強会がいたるところにあって、情報共有をWeb2.0系の人たちは自然にやっている。

その人達の学習曲線は驚異的で一年もたてば、その道のエキスパートになっている。そーゆー世界がいまここにあるのだけど、なかなか大手企業の偉い人たちには、彼等のレーダにはそーゆー世界の話がうつっていない。

わたしが言うとすぐに大企業批判みたいに受けとられちゃうけど、そうではなくて、聞いたこともないちっちゃな会社と大手企業のコラボレーションができたらおもしろいなあと。

日本という地域でもっともっとコミュニティーベースの開発というのを根付かせたい。企業の壁をのりこえた開発の素晴しさ。それば企業にとってもビジネスになるし、利益にもなるということをもっと訴えたい。

というようなヨタ話(記憶にもとづいて書いているので相当脚色構成あり)をかましたのだけど、伝わっただろうか。

パネルで話したエピソードのまとめ。(順不同)

従業員意識調査のはなし。(人手が足りないという状況と、会社をもっともっと良くするために貢献したいというモチベーションの高い従業員)
人材/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/01/post_6962.html

mixiのスケーラビリティのお話。(たくさんブックマークされている(58個))
500万倍のスケーラビリティ/ユメのチカラ
http://blog.miraclelinux.com/yume/2006/07/post_7ad0.html

mixiのスケーラビリティをささえるアーキテクチャ。
LiveJournalのアーキテクチャ/ユメのチカラ
http://blog.miraclelinux.com/yume/2006/07/livejournal_a718.html

金曜日の飲み会でアイデアを得て土日開発し月曜日に公開するという、おじさんには理解不能なスタイル。
Web2.0時代のソフトウェア開発のスピード/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/04/web20_5b1a.html

国内OSベンダーでISO/IEC 15408を取得しているのは弊社だけ。歯を食いしばってもOSを作らないといけない。
ISO/IEC 15408の取得/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/02/isoiec_15408_6bd3.html

ISO/IEC15408認証を取得しました/アジアのペンギン
http://blog.miraclelinux.com/asianpen/2007/02/isoiec_15408_e90c.html

Linux Kernel 2.6.20を開発した人の所属はどこかを調べた記事の紹介。それによると日本の企業でリストにはいっているのはMiracle Linux1社だけで、18位であった。
Who wrote 2.6.20? 誰がlinux 2.6.20を書いたのか？
http://blog.miraclelinux.com/yume/2007/06/who_wrote_2620__4b18.html

RubyKaigi 2007については下記
日本Ruby会議2007/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/06/ruby2007_cdaf.html

RejectKaigi2007/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/06/rejectkaigi2007.html

ムーアの法則を理解すること

Matzにっき (2007-05-30)
インテル：「ソフトウェアもムーアの法則に従う必要がある」 - CNET Japan
http://www.rubyist.net/~matz/20070530.html#p07

「今まではハードがどんどん高速化してきたので、ソフトウェアの皆さんは(マシンのアップグレードで)自動的に性能向上を享受できていましたが、これからは諸般の事情でそういうことはできなくなります。ソフトウェアの皆さんもご協力を」という話。

っていうか、最初からそういう風に言ってほしいものだ。

このブログの読者ならご存知かと思うが、わたしは昔DEC (Digital Equipment Corporation)という会社に勤務していた。わたしがエンジニアリングのイロハを習った会社である。VAXそしてAlpha AXPというコンピュータ史に残るアーキテクチャを開発した会社でも知られている（若い人は知らないかもしれないけれど）。商業的にはその後コンパックに売却され、コンパックはHPに売却され今はその名はない。

さて、そこでソフトウェアエンジニアとしてのキャリアを積んでいったのであるが、そのエンジニアリングコミュニティは間違いなくムーアの法則をコミュニティとして理解していた。(マルチプロセッサ向けソフトウェアパラダイムとは、マルチプロセッサ向けソフトウェアパラダイムとは？(その２)を参照のこと)

Alphaの開発チームはVAX開発チームの後継で、ある意味DNAを受けついでいるのだが、当時の論文(90年ごろ)で、マイクロプロセッサのスケーラ ビリティを、クロックの向上で10倍、アーキテクチャの進歩で10倍、マルチプロセッサで10倍、10x10x10=1000倍の性能向上を達成するとか しないとか書いてあって、感心したのを覚えている。

http://blog.miraclelinux.com/yume/2007/01/post_ab8c.html

アーキテクチャの設計寿命で紹介した論文をふたたび引用する。1992年の論文であることに注意されたい。
Alpha AXP Architecture
by Richard L. Sites
http://www.hpl.hp.com/hpjournal/dtj/vol4num4/vol4num4art1.pdf

The remaining factor of 10 will come from multiple processors. A single
system will contain perhaps ten processors and share memory. We therefore
designed a multiprocessor memory model and matching instructions
from the beginning. This early accommodation for multiple processors
also distinguishes the Alpha AXP architecture from many other RISC
architectures, which try to add the proper primitives later.

今後15年から25年のレンジで性能向上をはかるためにクロックレートで10倍、それ以外の設計要素(投機的な実行、Out of Order、スーパーパイプライン、スーパースケラー等々)で10倍、そして残りはマルチプロセッサ技術で10倍、合計10*10*10=1000倍のスケーラビリティを確保する、という事である。

この論文が発表されたのは92年でAlpha AXPの開発が開始されたのは88年あたりだからAlpha AXPチームは約20年前には、間違いなく今後の性能向上にはマルチプロセッサの技術が必要になるというビジョンを持っていた。

商用OSはSMP性能でのボトルネックを発見し修正するという地味な作業を延々おこなってきたし、ミドルウエア(RDBMSなど)もSMPでの性能向上に力をそそいできた。今後も益々SMPの重要性は増すであろう。

そして、ソフトウェアコミュニティでも、それを理解する必要がどんどん増しているのである。

つい最近までハードウェアの性能向上にあぐらをかいてソフトウェア側の性能向上の努力というのはほとんどなかった(というのは言いすぎかもしれないけれど)。汎用的な性能向上という点から言うと進歩はゆっくりしていると言っても過言ではない。

ムーアの法則をもう一度よく理解する必要がある。

そして、もう一つ重要な点、増加したトランジスタ(向上した集積度)をどう使うかについては、後に記す(かもしれない)。

インテル：「ソフトウェアもムーアの法則に従う必要がある」
http://japan.cnet.com/news/biz/story/0,2000056020,20349605,00.htm

アーキテクチャの設計寿命/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/02/post_e9f1.html

マルチプロセッサ向けのソフトウェアパラダイムとは/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/01/post_ab8c.html

マルチプロセッサ向けソフトウェアパラダイムとは？(その２)/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/01/post_95e7.html

マルチプロセッサとマイクロカーネル/ひら
http://d.hatena.ne.jp/hira_sosuke/20070604/1180968495