Life is beautiful

　ここのところ技術系ブロガーの間で話題になっている、「C10K問題（参照１、参照２）」は、ひとことで言えば、多くのウェブ・サーバーで採用されているmulti-threadやmulti-processに頼った（もしくは頼りすぎた）多重処理というアーキテクチャーのスケーラビリティに対する極めてまっとうな警告である。

　この話は、決して最近になって始まった話ではなく、パソコン業界ではパソコンのOSにpreemptiveなマルチタスクが導入されはじめた９０年代の前半から、さらに遡ると、DECを中心にテクノロジーが進化したミニコンの時代から、ソフトウェア・エンジニアたちの間で盛んに討論されてきたテーマである（さすがに、メインフレーム時代の話は私は知らない）。

　十数年を経た今でも、いまだに決着が付いていないこの問題は、私の大好きなテーマの一つでもあるし、もし私が博士号をこれから取得しようとするのであれば、博士論文のテーマに最適だと思っている。この論争は、ある意味では、ミニコンから降りてきたmulti-threadを多用した多重処理を支持する一派と、１６ビットパソコンの時代のnon pre-emptiveなOSの上で別の進化をしてきたasynchronous I/Oを利用した多重処理のアーキテクチャを支持する一派とのぶつかり合い、ということも出来るぐらい根が深いものだ。

　「単純化しすぎ」と批判されることを承知で、便宜上、前者を「multi-thread派」、後者を「asynchronous I/O派」と呼ぶことにする。両派の主張は以下のようなものである。

multi-thread派の主張

　人間は、一つの仕事を処理するときには、それを小さな仕事に分割して、順番に処理する。それゆえ、プログラミングもそんな人間の頭の構造を反映して、呼びたいAPIを順番に羅列して行く「手続き型プログラミング」が適している。もちろん、APIによっては、ファイルIOやネットワークIOのように遅延を持つものもあるが、そこはプログラマーにはできるだけ意識させず、OS内部で自動的にcontext switchを行って、それによって多重処理を可能にすれば良い。せっかく、CPUやOSのレベルでmulti-thread、multi-processをサポートしているし、context-switchのコストは相対的にものすごく小さくなったのだから、それを最大限活用すべきである。

asynchronous I/O派の主張

　multi-threadを多用した「手続き型プログラミング」による多重処理は、一見とっつきやすく簡単に見えるが、実はシステムの安定性、保守性、スケーラビリティの面で色々と問題がある。複数のthread（もしくはprocess）で共有するリソースへのアクセスをシリアライズするためのクリティカル・セクションをアプリケーションレベルできちんと使いこなすことは容易ではないし、I/O待ちのthreadの数が莫大になった時にそれぞれのthreadのcontextを保つために必要なリソースが膨大になる。それに加え、APIによる遅延をプログラマーが意識しないというスタイルのプログラミングでは、そういったAPI呼び出しによる遅延をユーザーから隠してレスポンスの良いアプリケーションを作ることが難しくなる。それよりは、できるだけ少ない数のthreadで、遅延を持つI/Oはすべてasynchronous APIを使ったメッセージ・ドリブン（もしくはイベント・ドリブン）なプログラミングによる多重化の方が優れている。

　この二つのプログラミング・スタイルに関するディベートは、９０年代前半にOSの設計に関わっていたMicrosoft、IBM、Appleなどの企業内部でさかんに行われ、GUI OS上でのthreadの使い方に関しては一応の決着を見たようにみえたが、それが９０年代中ごろから、インターネットを介した数百msecという桁外れに大きなの遅延に向き合わなければならないWWWブラウザーやHTTPサーバーが出てきた時に、さらに別のディベートとさまざまな試行錯誤が行われながらも、今に至っても（業界のトップクラスのエンジニアたちの間ですら）まだ決着が付いていない、というのが実情である。

　たまたまnon-preemptive OS（Windows 3.1）、preemptive OS（Windows 95）、WWWブラウザー（Internet Explorer）、HTTPサーバー（IIS/Personal Web Server）の設計・開発のどれにも深く関わってきた私としては、さまざまな失敗と成功を通して、それなりのノウハウも蓄積してきたし、言いたいこともたくさんある。しかし、そういったことを全部書くと、一冊の本になりそうなぐらいの量になるし、思いっきりテクニカルになってしまってエンジニア以外の読者をこのブログから失ってしまいそうなので、ここで書き続けるべきか少し悩んでいる（ひょっとしたら、以前から試してみたかった自費出版向きのテーマかもしれない…１０００部ぐらいならこのブログを通して売れそうだし^^）。とりあえず今日のところは、渡辺千賀さんの本のタイトル風に「その１（かもしれない）」とお茶を濁しておく。