Hatena::ブログ(Diary)

Cafe Babe RSSフィード

2005-08-30 ネットワーク生態学研究会 第1回サマースクール

[] Gfarm

産総研の首藤さんに,グリッド関係ではMapReduce+GFSのような計算とデータの協調的な分散に関する研究をやっていないのか?と聞いたところ,Gfarmというグリッド用の分散ファイルシステムを紹介してくれた.

http://datafarm.apgrid.org/index.ja.html

これも大規模ファイルに対するものだが,GFSとの大きな違いは,GFSがチャンクと呼ばれる固定ブロック単位で分散格納するのに対して,Gfarmはファイル単位で格納すること.つまり,Gfarmが前提とするのは,GFSのような細粒度分散並列処理ではなく,単一プログラムが複数ファイルを処理するような粗粒度分散処理のようだ.このために複数のスレッドないしはプロセスが単一ファイルに書き込む場合には,ファイル排他的ロックすることになる.

追記:首藤さんによると,これはv2の新しい設計で,まだ配布されていないとのことである.

これは,広域分散を対象としたグリッドコンピューティングと,データセンタ内に閉じた計算機クラスタの分散並列計算の対象の性質の違いによるのだろう.広域細粒度分散は非常に効率が悪いし,POSIXに準拠することにしたのも,プログラミングを容易にすると思われる.

追記:GFSとGfarmは,同様にデータインテンシブ・コンピューティングを目指しているのだが,アプローチが違ってきたのは,対象とするデータの性質と処理の性質が違うからと思われる.

たとえば,GFSが対象とするテキスト処理で言えば,次のような特徴がある.

  • 大容量のデータに,細粒度の独立性が存在していること.たとえば,Webから収集してきた多量のHTMLファイルログファイルは,各部で独立に処理できる.データの部分間の依存性が強い(←たぶん,Gfarmが目指すような大量データ処理はこちら)場合は,そうはいかない.
  • データの部分に関する処理が比較的遅い,または高速化できないこと.たとえば,Webロボットサーバに対する収集速度は負荷が集中しないようにするためには上げるわけにはいかない.そこで,大量のスレッドを複数台のマシンに分散させて収集して,全体としてスループットを上げるようなことがおこなわれる.また,各ファイルテキストの解析に形態素解析などを用いてしまうと,どうしても遅くなる.そこで,細粒度並列化でスループットを向上させることになる.

注意すべきは,これは目的指向で設計されていることを示すだけで,(目的が達成されているならば)どちらが良い,悪いというものではない.結局,「何でもできる=全部中途半端」なのだから.

[] 防災におけるネットワーク技術

立命館大学の仲谷善雄教授の招待講演なのだが,これが非常に面白かった.

http://www.jaist.ac.jp/~yhayashi/sum05_presen/nakatani.pdf

たとえば,兵庫県阪神大震災の後防災に非常に力を入れ,フェニックス防災システムと呼ばれる,先進的な災害対応総合情報ネットワークシステムを作った.しかし,2004年の豊岡豪雨で,このシステムがまったく役に立たなかった.

なぜ,こんな結果になったかというと,地方自治体で災害に対処する人員は,ほとんどが災害活動における十分な経験を持っていないし,そもそも人数的に十分と言えない状態なので,実際の現場では目の前の問題の対処に追われて,せっかくのシステムに入力する時間がなくなるからである.

他にも,災害特有の興味深い性質としては,地震のような場合に災害対応システムが動作開始するのは,そのシステムがダメージを受けた後から…つまり,使用開始時に,すでに何らかのダメージがある可能性が高いのだ.センサやカメラは壊れ,ネットワークは分断され,電源の供給は絶たれ,建物や計算機さえも壊れているかもしれない.

そのような状況下でも,ちゃんと機能しなければいけないのだが,現状のシステムは満点とは言い難いそうである.それは,システム設計者が必ず災害のことを知っているわけではないからだ.たとえ,通常の業務システムと同じ業者が受注しても,災害対応システムはまったく別の設計をしなければいけないのだが,そのノウハウが蓄積できていない.

一つ,その例を示せば,津波時の水門を閉じる例である.従来は人手で占めていたが,もちろんこれでは地震発生後に津波が来るまでの10〜20分の間におこなうことはできない(ある県で実際に試したら,4時間かかったらしい).その対処には二種類あり,一つは職員が職場の近くに居住し,職場から集中的に水門を閉めるようにすること.実際に,このシステム北海道地震で適切に対処でいたそうだ.もう一つは,水門に地震センサーを配置し,自律的に閉じるようにすることである.人間がいると困るので,警報を発するだけでなく,カメラで人の影を検出することもあるらしい(が,先生曰く,もし取り残されたら,水門の横に設置してある梯子を登ってくださいとのことだ(笑)).

ただし,前者の場合はネットワーク障害に,後者はセンサの故障の問題がつきまとうわけだし,それ以上に地震で水門がゆがんで閉めれない可能性すらあるのだ.さて,どのようなシステム構成が最適なのだろうか?地震国に住む日本人としては,この分野の研究開発の発展と実現がうまくいくことを願ってやまない.

なお,先生が言われた印象的な事例として,確かこの種で先進的な三重県庁から「オフィスみたいな外見で,各自のパソコンで使えるようにしてください」という要求があったそうだが,これは専門家でも一見笑い飛ばしてしまいそうだが,実は見事な洞察力を示している.

この言葉は,「中央集権的なシステムだとネットワーク障害があるだけで使えないので,個々に独立して動作するプログラムが,必要に応じて通信するシステムにしてください」ということと,「プログラムのユーザインタフェースオフィスと似せることで,非常時にしか使わない災害対応システムでも,うまく使えるようにしてください」ということを示唆しているのである.深い….

Connection: close