【3/18〜】Amazon、VMwareが語る『クラウドの未来』        

[Analysis]

Web2.0の先にあるC10K問題

2007/01/09

　個々のクライアントがサーバに要求する処理量は小さなものでハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする――。これが最近Web開発者の間で話題となっている「C10K問題」（クライアント1万台問題）だ。

プロセス番号が足りなくなる

　パンクするのは例えばプロセス番号だ。

　Ajaxの実装として最近注目されている技術に“Comet”（コメット）と呼ばれるものがある。HTTPのセッションをあえて切断せずに、サーバとクライアント間でつなぎっぱなしにするテクニックだ。Cometを使えばクライアントからのリクエストに応えるだけでなく、サーバ側からも不定期に情報を送り出すことができる。例えば、Web上でチャットサービスを実装するには、通常はクライアント側からサーバに一定間隔でポーリングすることで、ほかのユーザーの発言分をサーバから取得して表示するが、Cometのモデルを使えば、誰かが発言したとたん、サーバ側からすべてのクライアントに差分の発言テキストを送信できる。

　CometとAjaxを組み合わせることで、きわめてリアルタイム性の高いWebアプリケーションを作成できる。チャットサービスの「Lingr」、Wikiのように編集できてリアルタイムに編集内容が変化する付箋紙サービス「Wema3」、Web上のホワイトボード共有サービス「Thinkature」などは、すべてCometを使ったサービスだ。

　Lingrのような軽いサービスでネックとなるのはプロセッサパワーでもストレージのI/O速度でもネットワーク帯域でもない。同時接続ユーザー数が万のオーダーに達したとき、現在のOSやサーバのプログラミングモデルが現実に合わなくなってくることだ。

　LinuxなどUNIX系のOSでは、メモリ上で実行中のプログラムに与えられるプロセス番号は符号付き16ビット整数だ。つまり、デーモン（サーバプロセス）も含め、すべての実行中のプロセスには1〜32767までのユニークな番号が与えられていることになる。ところが、HTTPサーバのApacheなどはクライアント1台からのリクエストに対して1つのプロセスを生成するため、必然的に同時接続数は3万クライアント程度が上限となる。IRCのように参加者が能動的に発言するとは限らず、時間があるときや必要なときにだけ発言するような利用法であれば、ハードウェア性能的にもネットワーク性能的にも1台のサーバで10万クライアントを扱うことができても、プロセス番号が足りないという理由でこのモデルは破綻する。

　このように、1万クライアントには対応できても10万クライアントには対応できないという状況が「C10K問題」だ。Cはクライアント、10Kは1万を示す。

1スレッドで多数のクライアントに応える

　1クライアントに1プロセスというモデルは、軽い処理をこなすには、いかにも無駄が多い。では、マルチスレッドにして1スレッドに1クライアントを割り当てればいいかというと、それでもまだ別の問題がある。多くのOSでは、万単位のスレッド生成ということを前提として設計されていない。例えば、特別な設定をしていないLinuxでは、1スレッド当たりデフォルトで2MB程度のスタックメモリを割り当てる。1万クライアント＝1万スレッドであれば20GBのメモリが必要になる。これでは、仮想メモリを使うとしてもパンクしてしまう。

　もちろん、64bit対応のLinuxを使って力技で解決してもいい。プロセス番号不足も、仮想化技術を使って1台の物理サーバ上に仮想サーバをパラレルに走らせれば、ある程度はスケールアウトが可能だろう。しかし、C10K問題の本質は、やはりOSやサーバプロセスの設計が、Web2.0的なサービスに不向きになってきていることにある。最新のLinuxでは3万2000個を超えるスレッドを扱ったり、スレッドごとに消費するスタックの量を減らすことも、カーネルパラメータの設定で可能だが、まだ標準的といえるほど普及したテクニックではない。

進むノウハウの蓄積と開発環境の整備

　C10K問題が及ぶ範囲は広い。すでに書いたようにサーバ側ではOSのスレッドやサーバの設計モデルがネックとなっている。膨大な数の「軽い処理」を要求してくるクライアント1万台環境では、細かなI/Oが多数発生するため、I/O関連のライブラリの整備も始まっている。現在、一部の先進的な開発者が試行錯誤しながら個別に実装しているCometについても、HTTPサーバでの対応やライブラリの整備が望まれる。実際、その名もずばり「Cometd」というプロジェクトなどが始まっている。

　クライアントについても、同時接続セッション数の上限が比較的小さな数値に設定されていることも、いずれ問題となってくるかもしれない。例えばタブブラウザを使って多数のチャットルームに同時にログインしたとき、今のところ何が起こるかよく分からない。特定の実装に対する個別の組み合わせの検証はできるが、一般論としての挙動は、あまり前例がなく予測不能だ。

　Ajax普及が本格化してきたのが、ノウハウの蓄積や開発環境の整備が一巡したからだとすると、Cometのようにクライアント1万台（あるいは1万セッション）を扱うC10K時代のWebアプリケーションの時代の幕開けも、もうすぐそこまで来ているのかもしれない。

（＠IT 西村賢）

情報をお寄せください：