Gridable Type構想 (2)

このエントリーではMovable Typeを用いて「グリッドする」ことを目的としたGridable Type構想を紹介する。(2)はGridable Typeの基盤となる「トラックバックパッシングモデル」について議論する。

トラックバックパッシングモデル

Gridable Typeで用いられる代表的なプログラミングモデルであるトラックバックパッシングモデルについてここでは述べる。このモデルは、ブログで用いると不愉快でしかないトラックバックを有効に活用した並列プログラミングモデルである。

メッセージパッシングは分散メモリ型の並列計算機やクラスタ上で広く利用されているが、トラックバックパッシングはほとんど使われていない。よく見かけるのはトラックバックバッシングである。

トラックバックパッシングモデルでは、アプリケーションは自律したプロセスの集合として動作し、各プロセスが独立した記憶域を持つ。このモデルでは、プロセスはトラックバックを受信することで起動し、トラックバックを送信することで他のプロセスと通信する。メッセージパッシングモデルではメッセージを通信する送信側プロセスと受信側プロセスが明示的にメッセージのやり取りを行う必要があるが、トラックバックパッシングモデルではトラックバックの通信は常に新規のプロセスの生成を伴うためこのような必要はない。

トラックバックパッシングモデルのセマンティックスは、並列計算技術におけるActive Messagesのものに類似していると言える。Active Messages同様、トラックバックの受信側メッセージハンドラ(この場合プロセスとほぼ同義)は非同期に実行されなければならない。また、トラックバックのメッセージングもPUT型・GET型の二種類に分類できる。

PUTメッセージ送信時には非同期に起動された受信側ハンドラがメッセージの受信を行い、計算を行う。送信側はブロックする必要はない。GETメッセージ送信時には非同期に起動された受信側ハンドラがメッセージの受信を行い、少量の計算を行い、送信側に戻り値を返す。ただし、送信側が戻り値が返されるまでブロックすると処理が直列化されてしまうので意味がない。

PUT/GETのいずれにしても送信側が別プロセスを起動してバックグラウンドでトラックバックパッシングすることが性能上の要求から望ましい。そのためのコンストラクトとしてMTにはMT::Util::start_background_taskが用意されている。

さらに続きます。そろそろ「ブログを使ってバカ論文を書く」試みであることは伝わっているのだろうか。嘘は書いていないし、普通に実装すればプログラミングシンポジウムくらいなら出せる。「MTのアプリケーション」としては面白い試みかもしれないが、問題は「グリッド技術」としては意味がないことだ。面白いだけでは意味がない。

Gridable Type構想 (1)

このエントリーではMovable Typeを用いて「グリッドする」ことを目的としたGridable Type構想を紹介する。(1)は導入として概念の説明を行う。

アプリケーションプラットフォームとしてのMovable Type

Movable Typeはユニークなソフトウェアである。利用ユーザー数という意味ではASP型のブログサービスに及ばないが、インストール数という点では他のとは比較にならないほど多いブログシステムである。対象をブログシステムに限らず一般のWebアプリケーションまで広げたとしてもおそらく最大のインストールベースになるであろうと推測される。

このことは、ブログの効用としての「プラットフォーム化」(Permalinkの実現、RSS/Atomによるメタデータサービス、XMLRPCなどによる外部インタフェース)とは異なる意味で、単一のソフトウェアレイヤーによるアプリケーションプラットフォームが広範に実現されていることに他ならない。言い換えると、Apache Web ServerにおいてCGIやPHPが利用可能であるのと同程度に、Movable Typeの提供するアプリケーションスタックが利用可能である、ということである。

このプラットフォームは、ブログを構成する各種オブジェクトを表現するクラスライブラリ(それらを操作するメソッド群を含む)と、それらライブラリを使って実現されている標準アプリケーション群(CMS、Comments、Trackbackなど)からなる^*1。また、標準アプリケーションには(自己反映ではないが)自身の振る舞いを拡張あるいは変更するためのPluginインタフェースが用意されている。

例えば、標準アプリケーションの一つであるTrackbackは、基本的には単にショートメッセージを受信して保存する機能しか持たない^*2。しかし、Pluginインタフェースを用いて振る舞いをカスタマイズすれば、メッセージに応じて必要な処理を行うアプリケーションとしても利用できる。

^*1 無論ライブラリを使って固有のアプリケーションを記述することもできる。

^*2 外部からのトラックバックメッセージが「トラックバック」として機能するのは、CMSアプリケーションが保存されたメッセージを読み込んでトラックバックデータとして利用するからである。

グリッド環境としての利用

まず最初にグリッドについて解説しておく。

まず現状認識として「資源はどこにでもあるはずなのになぜか(マーフィー則のように)常に不足する」という現象がある。つまり、広域的に見れば資源の効率的な利用がなされていない状態にある。また費用対効果ということを考えると、ユーザーは実行効率を向上させたい、サービスの利用継続性を維持したいなどといった資源に対するある種の「最適化」効果を期待している。資源保有者は資源の保有コストや追加コストを効果的に避けたいと考えており、コストと資源量が相対的なものであるという事実を勘案すれば、要するに「資源の稼働率を上げたい」と考えている。

これらを全部合わせて「広域的に資源の稼働率を上げて実行効率を上げる」というのがグリッドであり、それを実現したのがグリッド環境であり、実現する技術がグリッド技術である。

ここではMovable Typeを用いて、BerkeleyのSETI@HomeやNTTデータのセル・コンピューティングのように遊休リソースをad hocに統合して利用するグリッド環境「Gridable Type」を実現することを考える。Movable Typeをプラットフォームとして用いることにはメリットがある。Movable Typeのアプリケーションプラットフォームを利用できるという以外、Web Serverであるという性質から次のようなメリットが期待できる：

• 個人用計算機に比べてネットワークトポロジー上の制約を受けない。つまり、すべての資源が均一なグローバルネットワーク空間上にあるものと見做せる。
• 個人用計算機に比べてダウンタイムが極めて少ない。したがって長時間に及ぶアプリケーションを実行でき、ダウン時の対処も容易である。
• 資源の低負荷時間帯をマクロに予測でき、それは概ね正しい。つまり、適切に利用時間帯を定めるだけでスケジューリングできる。

当然ながらPerlによる実行効率とセキュリティという問題は残る。後者は、例えばどこかからコードをダウンロードして中身をevalするだけのプラグインを考えてみれば自明である。

こんにちはエレクトリシティー、秋葉原。

お引っ越し先は秋葉原クロスフィールド(CROSS FIELD)のダイビルです。なんかジャリ(大人気ないお子様方)の集団を結構見かけるのでアキバなのにおかしいなあと思っていたら、どうも7階にデジハリ大学様が同居していたらしいです。狩られそうな気配(藁)。

こんな感じのかっちょえ～ビルです。

オフィスはまだ伽藍堂(≠ギャランドゥー)。配線のみ完了状態。

そして私の机の置かれる予定地からは、ヨドバシカメラ予定地が。

ふははは、愚民どもがー！
という感じでもない(Rヒルズに比べると)殺伐とした見下ろしビュー。

さようならブツダンシティー、稲荷町。

今日はオフィスのお引っ越しです。

さようならオフィス。

さようなら住友不動産ビル。

さようならブツダンシティー、稲荷町。

ガッツ入れてインストール

OracleWorld Tokyo

Oracle 10g

GRIDがもたらす、 ITの新たなパラダイムの始まり。 日本で初めて、その全貌が明らかになる。

エンタープライズグリッドの世界を現実にするOracle 10gの衝撃を、日本で初めて体験してみませんか。Oracle 10gの製品群を中心にメインシアターにてまとめてご紹介。また、キャンプグランドでは、あらゆる技術的な質問に対応するスタッフがあなたの疑問にお答えします。さらに、スペシャルシアターでは、超大規模データベースの世界、LBS(衛星)を使った超時空間のスケール感あふれるデモ、ガッツ石松氏による超簡単インストールデモなど、魅力のイベントが目白押し。またJ2EEベンチマークテストを行い、世界記録を会場で更新する様子も皆様に目撃していただきます。

グリッド研究センター所属に託けて紹介するわけだが、とんでもないデモだ。

Grid Playstation

現状のビデオゲームで1000倍の処理性能は必要ない。1000倍の処理性能が必要になるのは、1000倍細かい計算が必要なシミュレーションや、1000倍広いマップを持ち1000人が同時に参加できるロールプレイングのように、領域毎にローカリティのある計算を同時並行に処理するという要求があるアプリケーションだろう。Centralized Serverではスケールしない規模として、1000という数字が適当かどうかは分からないが。