* [開発談義] 大規模災害時における情報収集・整理・提供の基盤環境としてのWikiのようなシステム [#medbeabe]
- ページ: [[BugTrack2]]
- 投稿者: 名無しさん
- 優先順位: 低
- 状態: 提案
- カテゴリー: その他
- 投稿日: 2007-03-16 (金) 23:03:30
- バージョン:
** メッセージ [#bb87c53c]
([[開発談義]]より移動)
-これまで、個人的に、たまに細々と、開発のお手伝いをしたりしてきましたが、正式な研究テーマとしてWikiに関われないかなと、最近、思うようになりました(ちなみに、私は、一応、大学・情報系研究科の助手っす)。[[新潟中越地震 被災者救援本部@2ch>http://eq.maido3.com/]] のように、大規模災害時における情報収集・整理・提供を、全国の情報ボランティアの手を借りて迅速に行う為のシステムとして、Wikiをベースに使うことを想定し、集中アクセスに耐えられる仕組みを実装できないかな、ってなことを考えとります。今やってる研究とはだいぶ毛色が違うんで、なかなか、踏み出すのは難しいんですが‥‥。なんか、ご意見とか頂けると嬉しいです。 -- [[三浦克介]] &new{2005-10-05 (水) 18:30:56};
-- お疲れ様です。[[BugTrack2/114]]を拝見する限り、既に実用化されているようですね :) -- [[henoheno]] &new{2005-10-05 (水) 23:16:33};
-- Wikiのダイナミックさを活かしながら素の閲覧性能を高められたいのであれば、上のBugTrackで触れたようなハイブリッド型にして、閲覧に関してはPHPではなくApacheの素の能力に任せるというのはいかがでしょうか。別途rsyncによるミラーを狙う場合は、htmlをミラーするではなく、DATA_DIRの元テキストの方をミラーしてそれを普通のPukiWiki + readonlyで見せるのが楽だと思います(ハイブリッド型では出てしまう#commentなどが出なくなりますので)。 -- [[henoheno]] &new{2005-10-05 (水) 23:18:37};
--私はその新潟中越地震のWikiに(少し遅れて)一部関わったのですが、その頃には(初期に問題となったらしい)ハードウェアと回線は BIG-server.com さんの支援で乗り越えた状態となっていました。 -- [[henoheno]] &new{2005-10-05 (水) 23:39:34};
--その後の問題はほぼ全て運用の問題ではなかったかと思います。とっかかりの問題はWikiを構築した方が、残念ながら暫くして消息不明になってしまった(引き継ぐアクションを起こしたものの連絡つかず)という点がありました。この辺りの消息不明や burn out については、Wikiに限った話ではありませんが、公共性のあるものであれば特に、(可能なら)複数人で行動する事でそもそも管理に冗長性を持たせるべきである、という事を示唆していると思います。 -- [[henoheno]] &new{2005-10-05 (水) 23:40:46};
--それ以外は、広域地域災害をホットなテーマにしたWikiサイトの情報構築に関する話題です。将来の運用対策という点ではこちらテーマの方が重たいでしょう。このWikiで行われていた事(ニュースサイトからの情報収集、テーマ別情報集etc)をカテゴリ別に調査し、それぞれの運用ノウハウ(成長の様子、整理の様子、デマ防止の工夫など含む)や実態と改善点などをまとめておくと、いつか同様の状況になった時に生かすことができると思います。 -- [[henoheno]] &new{2005-10-05 (水) 23:42:22};
--[[henoheno]] さん。たくさんのコメントありがとうございます。運用面にももちろん切り込んでいくつもりではいますが、技術屋ですので、まずは、技術面からアプローチを考えています。狙っているのは、PukiWikiの機能のを制限しない、対負荷スケーラビリティのあるシステムです。[[BugTrack2/114]] のようなお手軽な解決方法ではなく、専用のデータ同期デーモンを作るなどして、%%分散された%%複数台あるどのサーバで書き込みを行っても、その変更情報がダイナミックに全サーバーに伝達されるような仕組みにしたいなと思っていますが‥‥、正式な研究テーマにできるかどうかは、政治的な要素も絡んできますから、はてさて、どうかな。 -- [[三浦克介]] &new{2005-10-06 (木) 00:45:39};
--tomixです。とても興味深いお話ですね。ぼくは技術畑ではないので、その方面からなかなか意見はいえませんが、ずいぶん以前、まだインターネットが一般的でなかったころ、いまでいうエクストラネットのような運営に[[ファーストクラス>http://www.fcm.co.jp/firstclass/product/index.html]]というパソコン通信ホストソフト（いまはグループウエアといっているようですが）を使っていた事があります。その過程で、[[メディアキッズ>http://fyw.sue.shiga-u.ac.jp/chkd97/chkd9739.htm]]というプロジェクトをやっている方と出会い、お話を聞いてみると、このファーストクラスサーバーを100の小学校に分散配置し、各学校の特色ある電子会議室をリアルタイムに共有し子供たちが交流するという、今考えてもすごいことをやってらしゃいました。分散されたサーバーがまるで一つのサーバーように統合して管理されていくのか、それともとある地域の災害に対して、市町村、部落レベルのサーバーや、テーマ別のサーバーが雨後のタケノコのように立ち上がり、何らかのルールの上で共有すべき情報を分散しつつも共同編集されていくのか.....この学校プロジェクトは後者のスタイルでしたが、コミュニケーションのチャンネル数という視点から考えると、後者のほうがより多種のニーズをもった人々に情報が届き、さらにフィードバックを共有できるかもしれませんね。技術的にはRSSが双方向性をもったようなもの？((それってトラックバック？))しかしこれではPukiwikiの機能を生かしきれませんよね。分散編集を広げると、やっぱり編集競合の問題に行き着いてしまうのかな....-- [[tomix]] 2005-10-06 (木) 01:58:04
--すんません、tomixさん。「分散されたサーバー」という所に反応されたのだと思いますが、物理的位置が分散されている、という意味ではなく、負荷分散の為に複数台用意された、という意味です。言葉がまずかったですね。 -- [[三浦克介]] &new{2005-10-06 (木) 08:44:25};
---こちらこそ早とちりしちゃいました。ごめんなさい。ロードバランシング的な話ですね。災害ってことで、分散したほうがよいのかなぁとお持ったりしてたので.... -- [[tomix]] &new{2005-10-07 (金) 17:47:35};
---こちらこそ早とちりしちゃいました。ごめんなさい。ロードバランシング的な話ですね。災害ってことで、分散＝負荷分散っていうP2P的なことを考えてしまっていました。 -- [[tomix]] &new{2005-10-07 (金) 17:48:42};
---[[tomix]]さんの言われているような「分散管理」も、研究としては面白いのですが、私個人的には、「集中管理」の方に興味を感じています。これまで、インターネット関連の技術は、旧来の「中央の大型コンピュータとそれに接続された端末」という集中管理型のシステムから、メールやDNSといった分散サーバ＆クライアントという分散管理型のシステムへと発展してきました。「集中管理」なんて古いというのが一般的な考えかたのようですが、インターネットが日常生活に不可欠なインフラストラクチャーとなりつつある現在、増え続けるSPAMや [[DNSの危機的な状況>http://www.nic.ad.jp/ja/newsletter/No22/020.html]] を見ていると、分散管理型のシステムは、その信頼性に疑念を感じずにはおれません。フォールトトレランス (耐障害性) に十分配慮した堅牢な集中管理型のシステムの方が、みんなが幸せになれるのではないかと、思っています。ということで、ここで考えている大規模災害時用情報収集・整理・提供Wikiサーバーも、負荷対策の為に複数台のサーバーを使いはしますが、管理は集中型です。責任ある組織が、十分な予算を以って運用することを考えています。緊急時とはいえ、責任ある組織がWikiを運用するということが、果たして受け入れられるのだろうか‥‥、というのが、心配事なんですが (^^;) -- [[三浦克介]] &new{2005-10-08 (土) 11:17:25};
--------
#comment
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
