自己組織化ネットワーク構築基盤
2007年度上期未踏ユースのオーディションに行ってきました。プレゼン資料を公開します。
対話型QuickTimeムービー (8.5MB)
PDF (1.9MB)
プレゼン本番は制限時間12分で、スライドは約60枚あるので、12秒/スライドというハードスケジュールだったのですが、ブログでは制限時間はないので、全部書きます。
動的
4/1の日記のこと。
ITシステムはユーザーのためにあるものだから、事前に設計を固めるより、ユーザーからの意見を尊重した方が安全に成功しやすい。と言うよりもむしろ、事前に設計を固めてしまうと、ユーザーを無視することになりかねず、危険。
特にユーザーとの距離が近いWebでは、事前に設計を固める従来型からの転換が急激に起こっている。従来型には「静的」、現在の形には「動的」という識別子を与えてみた。自然に考えれば、企業や大学等のITインフラも今後動的になっていくはずであるし、そうでなければそうなっていくべきだと思う。
まずWebサービスは明確に動的になっている。
視点を細かくすると、プログラミング言語で、Javaで静的に→Ruby/PHPで動的に（その後変化に応じてJavaへと動的に拡張）などの変化もあると思う。
システム開発手法では、ウォーターフォールモデル→反復型/Agileへの転換が起こりつつあるらしい。
既に昔の話となりつつあるが、Linuxという、仮にメンテナンス費用が高く付くとしても、非常に初期投資が安く済むOSが利用されるようになったという変化も、静的から動的への変化の一つだと思う。動的であるためには、初期投資の安さは非常に重要な要素である。なぜなら、事前に入念な設計がないために、まぁ成功するであろうという予測すら立てられない（おそらく正確に言うと、立てられないのではなくて、立てない）ためである。仮に初期投資を削ったために問題が起こりそうでも、そういうことは後で考えればいい。ユーザーの反応を見てから考える。
Webサービスのインフラ
Webサービスは動的になっている。そしてある程度は今後も続くはず。
ではWebサービスのインフラはどうなっているのか。
現時点では、静的な手法（設計→構築）が主流だと思う。しかしWebサービスが動的になってきた今、最初にガッチリと設計をやっているようでは間に合わないはず。それに、そもそもその設計が正しい設計かどうか分からない。正しくないと分かったところで、再度設計をやり直しているようでは、せっかくのアイディアが陳腐化してしまうかもしれない。
従って、動的にサーバーを構築する手法が必要である。つまり、まず作る。ユーザーからの反応（直接の意見、あるいはアクセス数が増える、減るなど）に応じて、後から拡張（あるいは縮小）する。初期投資は安く抑えないといけないので、最初は安物サーバー１台で運用したい。その後変化が起こったときに、サーバーを足したり引いたりすると、動的に負荷分散されたり多重化されるといい。
動的な構築手法の確立
ところで、現時点ではそのような動的なインフラは構築できないのか。結論から言うと、できる。
たとえばDSASや、はてなのサーバー（naoyaのはてなダイアリー - さくらインターネット移行記#3 はてなブックマーク移転）、Unohのサーバー（ウノウラボ - ベンチャー流サーバ構築のススメ(ハードウェア編)）（同ソフトウェア編）など。安価な初期投資、動的にサーバーを追加するための工夫など。
では問題は解決しているではないかというと、そうではくて、スーパーなエンジニアがいなくても動的なサーバーが構築できないといけないと思う。動的なサーバー構築手法は、確かに存在しても、一般的に利用されるまでには確立されていない。
なぜ確立されていないのか。それは、ネットワークを構築する手法を共有できないからだと思う。今やソフトウェア単体はコマンド一発でインストールできるほど共有されているが、ネットワークはそうではない。ソフトウェアを配布する時点では、ネットワークの構成を想定できないから、ソフトウェアをインストールする側の人間が、ネットワークの構成をソフトウェアに教えてやらないといけない。
この問題を解決する方法は２つある。１つは、オープンソースソフトウェアを配布するように、「オープンソースネットワーク」を配布してしまうという方法。もう１つは、ソフトウェアがネットワーク構成を制限してしまう方法。
後者は、柔軟性と使いやすさの両立は非常に難しいから、柔軟性を制限して使いやすくしようという発想。HTMLは何でも記述できる柔軟があるけど使いにくいから、書式を制限してWikiにしよう、という発想と似ているかもしれない。
VIVERは、前者の方法を実現しようというもの。ネットワークを構成するマシンを全部１つのCDやUSBメモリからネットワークブートするようにすれば、完成されたネットワークを配布できるはず。
ネットワークの構築
VIVERを開発し、ネットワークブートする基盤は整った。ディストリビューションに依存しないという非常に高いカスタマイズ性を備えつつ、インストールはディレクトリ１つコピーして、ディスクイメージに圧縮するだけという、「柔軟性と使いやすさを両立」できたものだと思う。（が、ドキュメントが揃っていないという問題がある…）
しかしネットワークブートするだけでは、ネットワークは構成できない。ネットワークブートした上で、いろいろなソフトウェアの設定を自動的に行う必要がある。
VIVERではブートしたマシン異なる役割（ロール）を割り当て、ロールごとに異なるプログラムを実行できるようにすることでネットワークを構成しようとした。このような単純な機構では、並列計算環境の構築やNFSでファイル共有するくらいはできるが（すべてのホストが並列しているか、サーバーが１台だけ）、負荷分散や冗長化と言ったネットワーク（サーバーが複数いる、サーバーが変わる）は難しかった。
メタネームサービス
１つのディスクイメージの中にネットワークを封じ込めるためには、ホストのアドレスを指定するために、IPアドレスを使えない。たとえば「設定ファイルにサーバーのIPアドレスを書く」という良くあることでも、ディスクイメージを作るときにはサーバーのIPアドレスはわからない。それは実際にブートしたときに決まる。（静的型付け言語と動的型付けの関係のような）
なので、そこにはもっとメタな情報を記述できる必要がある。たとえば「NFSサーバーをやっているホストの中で、一番最初に起動したホストのIPアドレス」というように。あるいはサーバーとクライアントの方向を逆にして、「自分はNFSサーバーなので、NFSクライアントになりたがっているホストに自分のIPアドレスを教えてやる。クライアントは教えられたIPアドレスを使用」という方法。
つまり、メタな情報を扱えるネームサービスが必要であることが分かる。
スケールアウトする多重化分散ファイルシステム
いろいろ調べていると、動的な運用ができる分散ファイルシステムは、どうやら世の中に存在していないらしいと言うことが分かった。（2007/4/7のエントリ）
Linuxではいろいろなものがファイルに抽象化されているので、ファイルシステムが動的に運用できなくては、Linuxを動的に運用できるわけがない。
そこで、動的な運用ができる分散ファイルシステムが必要になる。
「使える」ようにするために
作った基盤はオープンソースとして公開する予定。しかしそれを使ってもらうようにするには、また別のステップが必要になる。
気づいてもらう 知ってもらう 試してもらう 使ってもらう 宣伝してもらう
このサイクルが、オープンソースソフトウェアには必要になる。
基本的にWebサイトで情報公開していこうと思っているのだけど、Webサイトは完全にPull型なので、まず気づいてもらう時点でかなり難しい。
それから、「知ってもらう」のも非常に難しい。
そこで、実はブログはそこそこ効果的なのではないか、というのが最近の考え。トラックバックがあるので多少Push型でもあり、なんとなく書きやすい気がするので、中身を増やしやすい。
VIVERでは試してもらう段階でCDイメージを配布しようと思っていたのだけど、これはどうやら手間がかかっていけないらしく、Webサイトでそのままデモを体験できるレベルでないといけないと思えてきた。
そして使う段階でも、できる限り簡単に使えなければならない。
プラグイン＝API
ネットワークを構築するのはプラグイン型にする。プラグインはそのままAPIとなり、他のプラグインから利用できる。分散オブジェクトの強力なところ。
これを使って、負荷分散や冗長化を、１行か２行追加するだけで行えるようにしたい。
自動インジェクションを行う。たとえばクラスの宣言に「inject :VRRP」と書いておくと、VRRPプラグインがVRRPという名前のクラス変数に自動的に代入される。これは自動的に依存関係にもなり、inject :VRRPと書くと、VRRPプラグインに依存していることを示す。（プラグインをインストールするときにVRRPプラグインを一緒にインストールする、VRRPプラグインが起動されてから起動する）
