論文

Beyond The Web — Homeless Data Server＊
Kenji Arisawa(Aichi University, Nagoya, Japan arisawa@aichi-u.ac.jp)

Abstract
A new type of data server is presented. The server is designed for grid computing. The distinctive
feature of the server is that enables to execute programs from clients without allowing any byte to be
written to the server. Therefore we need not allocate storage space for clients, which means the timeand labor will be reduced greatly, and in addition, we can keep the server perfectly clean.

Keywords: grid computing, data server, Plan 9

1．近頃巷に流行るものに置いているからであって，その場合に個人あるいは小さな組織もコンピュー

近頃ネット社会では「クラウド」とか

ティグバワーやデータをインターネット「ビッグデータ」なる言葉が流行ってい上に提供していくことになる。

る。ここでは「クラウド」上の「ビッグ「ビッグデータ」も盛んに使われる言データ」の処理について考察する。ただ葉であるが，一般に既存のデータベース

し「クラウド」とか「ビッグデータ」な

管理ソフトでは扱えないほどの巨大なる言葉はバズワードと化しているので，データを指しており，サイズはテラバイ

定義をはっきりさせる必要がある。

トクラスに昇る。幾つかのネット企業で一般に「クラウド」と言えば，インターはユーザの動向を逐一記録し販売促進に

ネット上の信頼できる企業にデータの保活用している。またネット上には膨大な存や管理を任せることを意味するが，こ情報が公開されている。そうした情報もこではもっと一般的にインターネット上

マーケッティングに利用可能である。そにあるサーバとして定義する。このよううして蓄積された情報は膨大になりすぎに定義するのは，将来普及するかも知れて，管理の方法や利用のためのツールをないグリッドコンピューティングを念頭見直す必要に迫られているのである。
Web は 現 在 の イ ン タ ー ネ ッ ト 社 会 に＊

この論文は筆者の Web の記事［1］を基に書かれている。論文としての多少の修正が加えられている。

愛知大学情報メディアセンター

おいて最も重要な役割を果たしている情報共有の技術である。テラバイトクラス－ 19 －

Vol.27, No.1, 2017

を想定する「ビッグデータ」に対して，

データを処理し，処理結果を受け取る方

Web の サ ー バ が 扱 う デ ー タ は 遥 か に 小が速い。

さい。そのサイズはせいぜいメガバイト

こ の よ う に Web の 実 用 限 界 と の 関 係

クラスである。Web ではクライアントので語られるデータサイズを何と言えば良求めに応じてデータをクライアントに送いのだろうか？

信する。データ転送に要する時間は回線問題に関しては広く知られた用語は存在の能力とデータサイズに依存する。そのしない。「ビッグデータ」を既存技術がため，ユーザの忍耐力を超えるような大適用できないほどの巨大なデータである

きなデータを扱うわけにはいかないのでと定義すれば，情報共有技術である Webある。

の技術が使えないギガバイトクラスの筆者の知る限り，このではサーバのデータがメガバイトクラ

データも「ビッグデータ」の仲間であるスを超え，ギガバイトクラスになると何と考えることもできる。しかし以下ではが問題になるか？

混乱を避けるために，インターネット回

ここではこの問題に焦点を当てる。

線を通じて転送するのに適さないデータ

データサイズがギガバイトクラスになを「大きなデータ」と言うこととする。

るとデータをインターネット回線を通言うまでもなく，いわゆる「ビッグデー

して転送するのに適さなくなる。他方，

タ」は「大きなデータ」である。

データサイズに比べるとプログラムのサ「大きなデータ」はインターネット回

イズは遥かに小さい。データを処理する

線を通じて転送するのに適さないのでのに必要なプログラムのサイズはせいぜ

サーバ上で処理される必要がある。従っい数メガバイトである。従って，プログて，処理に必要なプログラムはクライア

ラムをサーバ側に送信して，サーバ側でントがサーバにアップロードすることになる。クライアントの任意のプログラム
を使って，サーバ上でデータ処理をする

Bigとなればセキュリティが大問題となる。
従って以下では，セキュリティ問題に話?

を限定し，安全にサーバを運用し，かつWeb

クライアント側のニーズとセキュリティを確保するための方策に議論の焦点を当

B

図1

KB

MB

GB

てることにする。

TB

Web データとビッグデータの間

愛知大学情報メディアセンター

－ 20 －

Vol.27, No.1, 2017

2．リモート実行

行のニーズが少なくなっている。ホーム
ページを運用している場合には保守のた

2.1

リモート実行の過去，現在，未来

めにリモート実行が要求されることがあ
るが，それ以外の場合には高性能なコン

ここではクライアントのプログラム

ピュータを使った特殊な計算を行いたい

を，遠く離れているサーバ上で実行する

場合と，サーバにしかない大きなデータことをリモート実行と言うことにする。

にアクセスしたい場合に限られるだろこの意味でのリモート実行の歴史はインう。いずれも現在では普通の人々にとっターネット胎動期（1970 年前後）に現れては縁のない世界である。

た Telnet と FTP から始まる。サーバのしかし，将来はどうであろうか？

利用者はサーバ上に利用者の個人スペー学の発展にとって収集したデータは可能

ス（ホームディレクトリ）を与えられ，な限り公開すべきである。生に近いデー

アクセスに必要なパスワードをサーバのタが公開されていれば多様な視点からの管理者から知らされる。このスタイルは分析が可能になる。視点が異なれば予想

現在でも変わらない。

していなかったような発見があるかも知科

現在では個人所有のコンピュータ，いれない。現在は残念ながら特定の視点かわゆるパーソナルコンピュータが普及

らの調理済みのデータしか公開されな

し，大抵のことはパーソナルコンピューい。 公 開 を Web で 行 っ て い る 限 り， そタで処理できる。そのためにリモート実のようになる。また，IT 化された社会の中では自動収集された膨大なデータが蓄積される。そのようなデータが適切に公開されていけば，社会にとって有用な情報が得られる可能性がある。分析視点の多様性を重視するならば，分析者のプロ
グラムをサーバ側で実行できる必要がある。
2.2

ホ ー ム デ ィ レ ク ト リ が 必 要 と さ れる理由

図2

リモート実行

データが大きいときにはリモート実行の方が理にかなっている。データよりもプログラムの方がはるかに小さいのだ
愛知大学情報メディアセンター

現在，サーバの利用者はサーバ上に利用者の個人スペース（ホームディレクト－ 21 －

Vol.27, No.1, 2017リ）を必ず与えられる。なぜ与えられる

することが可能となった。高い処理能力のか？

が必要な場合には共同利用のホストが使マイクロプロセッサが現れる前の時代

えた。ホストにはこれまで通りに利用者には，コンピュータと言えば大きく高価の個人スペースが与えられた（図 3）。プ

で，個人が独占的に使用できるような装ログラムを編集し保存するためと，FTP

置 で は な く， 共 同 で 利 用 せ ざ る を え なによるファイルの受け皿として，ユーザかった。当時のコンピュータはホストとごとのスペース（ディレクトリ＝フォルも呼ばれていた。利用者は端末と呼ばれダ）が必要であると信じられてきた。こる装置を使ってホストを利用していた。

の状況は現在でも変わらない。

端末の処理能力は不十分で，利用者が打ち込んだ命令をホストに伝えるだけで

3．ネットワークベースのマウントあった。そのために，ホストには利用者ごとの記憶スペースが割り当てられ，利3.1

リモートマウント

用者は端末を通じてホスト側にプログラ
ムを作成し，ホスト側でプログラムを実行する他はなかった。

リモートマウントはサーバのファイルシステムをクライアントのファイルシス

マイクロプロセッサが現れて，個人がテムの一部であるかのように見せる技術独占的に使用できるコンピュータが出現である（図 4）。この技術を使えば，サー

した。それらはワークステーションと呼バ へ の フ ァ イ ル 転 送 の た め に FTP は 不

ばれ，その上でプログラムを作成し実行要になる。FTP でやっていたことは OS

図3

リモート実行とホームディレクトリ

愛知大学情報メディアセンター

－ 22 －

図4

リモートマウント
Vol.27, No.1, 2017

付属のコピーコマンドでやっていけるのツールがサーバ上のファイルに対して一である。

様に適用可能であるので，開発あるいはリモートマウントのメリットとしては，普通のユーザにとっては管理が容易になるなどの利点を挙げるだろう。

・ク ライアント側でサーバのファイルが編集できる図 5 はリモートマウントを利用してサーバで実行可能なプログラムが完成

・ D rag & Drop で サ ー バ へ の フ ァ イ
ル転送ができるするまでの流れを FTP と比較している。
マウント方式の方が手間が省けているこ・マ ウスを使ってサーバのファイルをとに注意する。

ブラウズできるなどが挙げられようが，パワーユーザあ

3.2

リモートマウントのレイテンシ

るいはシステム管理者にとっては見方が違うであろう。彼らにとっては OS 標準

ネット上にはマウントはレイテンシの基本的なツールだけでサーバのファイ（ 遅 延 時 間 ） が 大 き す ぎ て LAN レ ベ ル

ルを扱えるのが大きい。例えば scp コマ

でしか実用にならないと述べている記事

ンドを使わず，クライアントから実行すがいくつか存在する。インターネットでる cp コ マ ン ド で サ ー バ と ク ラ イ ア ン トのマウントレイテンシは原理的な問題

間 の フ ァ イ ル 転 送 が 可 能 で あ る。 さ らが 絡 ん で 改 善 し に く い と 言 う［3，4］。

に，クライアントで実行可能な馴染みのそ の 根 拠 は， 光 の 伝 達 速 度 が 有 限 で あり（ 光 フ ァ イ バ ー の 中 で の 光 の 伝 達 速度は，真空中の光速の 2/3 程度である），
マウントのプロセスでは RPC（Remote
Procedure Call）の技術が使われている
ために，マウントが完了するまでにサーバとクライアントの間で多数のメッセー
ジのやり取りが発生する。そのために地球規模での WAN でのマウントでは時間が掛かりすぎて実用にならないと言う。
こ う し た 議 論 は い ず れ も LAN 環 境 を 前提にして設計された NFS や CIFS を話題に採り上げている。また記事が作成され

図5

プログラムが完成するまでの流れ

愛知大学情報メディアセンター

た時期も古い。現在では実際にどの程度－ 23 －

Vol.27, No.1, 2017

のものか？

Plan9 の例を紹介する 1 。

ングによってレイテンシが大幅に短縮さ

まずマウントレイテンシの定義であるれる。欲しいデータはキャッシングの影が，ネットの議論にはリモートマウント

響を排除した時間である。そのためにはされたファイルの転送速度との混同があクライアントを立ち上げた直後に測定するように思えるのではっきりさせておる こ と に な る。 そ う し て 得 ら れ た 筆 者

く。ここではマウントの開始要求からマの環境でのレイテンシは殆どの場合 1 秒

ウントが完了するまでの時間を問題にす台であるが，時には数秒かかることもある。具体的には time コマンドを使ってる。なお筆者の自宅はインターネットとtime マウントコマンド

1Gbps の光回線で繋がっている。実験にのように測定する。測定値の中には DNS

使用したクライアントは WiFi（ 802.11n）の名前解決や認証に要する時間も含まれを 使 っ て 家 庭 内 LAN と 繋 が っ て い る のている。パスワードの手入力の時間を測でバンド幅は 1/2 程度に小さくなるので

定 値 か ら 排 除 す る た め に， 認 証 は 認 証

あるが，結果には大きな影響はないであエージェントを使った自動認証の仕組み

ろ う。 イ ン タ ー ネ ッ ト 回 線 に お け る 実を使う必要がある。

効的なバンド幅はさらに小さいだろうか

紹 介 す る の は 筆 者 の 自 宅 か ら Bellら。

Labs の サ ー バ を マ ウ ン ト す る 時 の レ イ

Plan9 では生まれた当初（1992 年）か

テンシである。日本からアメリカまでのら，Bell Labs の フ ァ イ ル シ ス テ ム を

距離でのレイテンシの目安になるであろ

ローカル側にマウントすることによってう。測定してみると，レイテンシには結

ソースプログラムの更新を行っている。

構なばらつきがある。ネットワークの混

他の OS の場合は全体をダウンロードしみ具合も関係するが，2 回目以降のマウて初めて更新の内容が分かるのである

ントの場合にはクライアントのキャッシ

が，マウント方式だと，改訂されたファ1

イルの一覧を基にして必要なファイルのPlan9 とは 1992 年に Bell Labs（ベル研究所）からリリースされた OS である。開発グループは
Ken Thompson や Rob Pike など Unix の生みの親たちであり，ネットワーク時代の前に生まれた Unix をネットワーク時代に正しく適応させることが開発の目標となっていた。また Unix の経験の上に立って，問題点を洗い出し，その解決のための新しい仕組みが提供された。なお，
Plan9 の正式名称は“Plan 9 from Bell Labs”であり，この省略形は正式には“Plan 9”であるが，ここではさらに簡単に，ネット界で普通に使われている“Plan9”を用いる。Plan9 については文献［50］及び文献［51］に詳しい。

愛知大学情報メディアセンター

みをコピーすれば済む。ネットワークのバンド幅がまだ大きくない時代においてもマウント方式は実用的に使われていたのである。
マ ウ ン ト に 必 要 な RPC の 回 数 や マ ウントによるファイルコピーの速度は分散
ファイルシステムの設計に強く依存する。ここに述べたのは Plan9 によるマウ－ 24 －

Vol.27, No.1, 2017

図6

Mac のファイルブラウザ

図7

ントで他のシステムの参考にはならない

3.3

分散ファイルシステム

分散ファイルシステムであろう。例えば文献［5］には sshfs が非常に遅いという苦情がある。残念ながクライアントやサーバにネットワー

ら Plan9 以外でのマウントレイテンシのクを通じてファイルシステムを提供

実測値が手に入らない。

しているのが分散ファイルシステム
2

マウントレイテンシに関する誤解の一（Distributed File System） である。こつに，ファイルブラウザに表示されるまこにはリモートマウントの仕組みが使わでの時間との混同がある。マウント要求れている（図 7）。

を出してファイルブラウザにファイルの分散ファイルシステムは大学などの一覧が表示されるまでの時間は，マウンLAN 環 境 で は 既 に 古 く か ら 整 備 さ れ てトされるのに要する時間と，ファイルブいる。これによって，学生用のパソコン

ラウザの表示に要する時間との和であ教室では，どのコンピュータを使ってもる。後者はファイルブラウザの設計と深

学生はサーバに保存されている自分のく関わっている。

ファイルにアクセスできるのである。

図 6 のようにファイルブラウザがファ

表 1 に 示 す よ う に， い ろ い ろ な 分 散

イルの内容を表示している場合には，要フ ァ イ ル シ ス テ ム が 存 在 し，OS 依 存 性する時間は，フォルダーの中のファイルが強い。（強かった）

数，ファイルの総サイズ，ネットワークの 実 効 速 度 が 関 わ っ て い る。 そ の た めに， 大 抵 の 場 合 に は LAN の 中 で し か 実
用 に な ら な い で あ ろ う。 こ こ で は Macの 例 を 挙 げ た が Windows で も 同 様 で ある。

愛知大学情報メディアセンター

2「分散ファイルシステム」よりも「ネットワー
クファイルシステム」の方が分かりやすい呼称
だが，この名前は既に特定の製品を指す名前として使われている（Sun NFS）［6］。なお，「分散ファイルシステム」の呼称は普通名詞として広く使われてきたにも関わらず Microsoft が自社の製品名を表す名前として使い出したので混乱している。ここでは「分散ファイルシステム」
を製品名ではなく普通名詞として使っている。

－ 25 －

Vol.27, No.1, 2017

表1server client

よく知られている分散ファイルシステム
名称

製作者

適用範囲

公表年度

Unix

Unix

NFS（Network File System）ver.2

Sun Microsystem

LAN

1984

Unix

Unix

NFS（Network File System）ver.4

IETF

LAN/WAN

2003

Unix

Win

Samba aOpen Source

LAN

1992

Win

Win

DFS（Distribute File System）

Microsoft

LAN/WAN2008

Microsoft

LAN/WAN?

1996

Microsoft

LAN

1999

Win

Win

CIFS（Common Internet File System）

Win

Unix

Windows NFS ClientbaUnix には Samba［10，11］をクライアントとして利用するのもある［11，12］b

一応 WAN 環境でも使えるようであるが，問題はありそう［9］。なお，CIFS は廃止になりそうである［7，8］

こ の 表 で「Win」 と は Windows のこ と で あ る。 ま た「WAN」 と は イ ン

も FUSE ベースで再設計する動きがある［14］。

タ ー ネ ッ ト 環 境 を 指 す。LAN を VPN

FUSE（Filesystem in Userspace）と（Virtual Private Network） で 結 ん だは，ファイルシステムのプログラムコー

ネ ッ ト ワ ー ク は， 管 理 面 か ら 見 て LAN

ド を カ ー ネ ル の 外 に 置 く 技 術 で あ る。

の一種だと考える。この表からは多くのカーネルには FUSE を実現するための汎ものが省かれている。例えば分散 OS で用の小さなコードが含まれている必要ある Plan9 は生まれた時から高性能な分が あ る。 最 近 で は 主 要 な OS で FUSE が散ファイルシステムを備えていた。またサポートされている。（アイデア自体は最 近 の Unix 系 の 分 散 フ ァ イ ル シ ス テ ム

1990 年前後に発表された Mach や Plan9

は FUSE をベースにしているが，それらに由来する）

も表から省かれている。

ファイルシステムがカーネルと固く結び付いていると，ファイルシステムの開

3.4

FUSE

発 自 体 が 困 難 で あ る ば か り か， 新 し いファイルシステムの導入が OS 提供者に

現 在， フ ァ イ ル シ ス テ ム の OS 依 存 性

限定され，ユーザニーズが反映され難くを弱めるための新しい技術（FUSE）がなる。また分散ファイルシステムを構築

注目されている。そして Ceph，Gfarm，する場合には OS を統一しなくてはなら

GlusterFS など最近の分散ファイルシス

なくなる。FUSE によって，このようなテムの設計は FUSE ベースになっている

制約から解放される。

［13］。さらに，既存のファイルシステム
愛知大学情報メディアセンター

FUSE を応用したファイルシステムは－ 26 －

Vol.27, No.1, 2017

多数ある。FUSE ベースの分散ファイル
システムはグリッドコンピューティングとの関係で注目されており，いくつか開発されている。その中でも Gfarm［15，16］は国際的にも高い評価を受けている
分散ファイルシステムである。Gfarm は
日本発の技術であり，ホームディレクト
リを自動マウントできるように工夫されている［17］。
図8

個 人 が 手 軽 に 使 え る FUSE ベ ー ス のPlan9 の逆向きマウントフ ァ イ ル シ ス テ ム と し て sshfs が 注 目
さ れ て い る。 こ れ ま で の Unix 系 の 分 散

サーバ側の OS は（現在のところ）Plan9

ファイルシステムに比べてだけである。クライアント側は Plan9 の・個 人利用として手軽に使える（インストールと管理が簡単）

他，Unix，Linux，Mac，Windows などでサポートされている。逆向きマウント

・ WAN 環境でも使えるだけでは意味がないので，実際にはクラ・家 庭 内 LAN の 中 で の デ ー タ 共 有 に

イアントのリモート実行コマンドと組に便利なっている。リモート実行コマンドを実・多様な OS 間で共通に使える

行すると，同時に自動的にクライアントなどの特徴がある。

のファイルシステムがサーバ側にマウン
3トされるのである 。リモート実行コマン
3.5

ドとしては Plan9 端末（Plan9 クライアン

Plan9 の逆向きマウント

ト）では cpu，Plan9 以外のクライアント
分散ファイルシステムにおける通常のでは drawterm を使う［18，19］。

マウントは，サーバ側のファイルシステ

正方向のマウント（サーバのファイル

ムをクライアント側のファイルシステム

をクライアントに見せるマウント）の場にマウントするのであるが，それに対し合 に は， ク ラ イ ア ン ト の プ ロ グ ラ ム をて，Plan9 では逆向きマウントが実現している。つまりクライアントのファイルシステムをサーバ側にマウントする（図8）。
逆向きマウントをサポートしている
愛知大学情報メディアセンター

3

ローカルシステムをリモートシステムにマウントするのに必要な通信チャネルは，コマンドを送る通信チャネルと兼ねている。そのためにファイアウォールの中からでも問題なく接続できる。これが可能なのは，通信チャネルが多重化されているからである。

－ 27 －

Vol.27, No.1, 2017

サーバで実行するプロセスは次のようになるであろう。
1．サーバをローカル側にマウントする
2．プログラムをサーバ側にコピーする
3．ssh コマンドでリモートログインする
図94．プログラムを実行する

情報の抽出

これに対して Plan9 の逆方向マウントだと4.1

データの解析

1．cpu コマンドでリモートログインする
2．プログラムを実行する

データを還元処理によって得られたも4と手順が簡略化される。この簡略化はグのが情報である 。極端には 1 ビットにま

リットコンピューティングでは決定的にで還元される。還元処理は問題意識（目重 要 な 意 味 を 持 っ て い る。 な ぜ な ら グ的）に依存し，大きなデータではさらにリットコンピューティングでは膨大な数技術が求められる（図 9）。

のサーバによる並列実行が想定されてい記録メディアの価格が低下し続けた結るからである。正方向マウントしか持た果，最近では膨大なデータを保持するよな い Unix ベ ー ス の グ リ ッ ト コ ン ピ ュ ー

うになった。データ収集時にデータを厳ティングでは最初の 2 つ（サーバをロー選するよりも，集められるデータは片っカ ル 側 に マ ウ ン ト す る， プ ロ グ ラ ム を端から集め，後で整理するやり方が可能

サーバ側にコピーする）を 1 回で済ませになっているのである。そこで，我々はるための仕掛けが望まれる。

データに対して次の見方を採ることがで
きる：

4

データサーバ・データ : そのままではゴミの山・情 報の抽出には，問題意識と技術が必要

ここではデータの提供とデータ処理のた め の CPU パ ワ ー を 提 供 す る サ ー バ に情報の抽出は一意的ではない。多様なついて考えて見る。以下，これをデータ

問題意識が存在し，そこから多様な情報

サーバと言う。データサーバにはどのような特性が求められているのだろうか？

愛知大学情報メディアセンター

4

データと情報の関係に関しては多様な見解が存在する。概ね，データは計算機寄りのもの，
情報は人間寄りのものと理解されているようである。しかしここでは情報量で説明する。

－ 28 －

Vol.27, No.1, 2017

が生まれる。分析する視点が異なれば，が要求される。「会話型実行」を含めたの意外な結論も得られるであろう。従って

は，情報抽出の過程で多くの試行錯誤を

データを公開し，多様な視点で検討でき必要とするからである。

5

るようにすることが重要である 。

こ れ ら を 行 う た め に， 現 在 の 方 式

データが小さい場合には既存技術でも（Unix のリモート実行）ではユーザ登録

やっていける。サーバからユーザがダウの際にパスワードとホームディレクトリ

ンロードすればよい。しかし，大きい場が与えられる。

合には…

しかし，データサーバにとって，利用

Web で は サ ー バ 運 営 者 の 問 題 意 識 に者は一時的である。必要な結果が得られそって情報が抽出される。今はそれで我ればアクセスするニーズがなくなるであ慢しているのである。

ろう。そうした利用者にホームディレク
トリを与えるのは合理的ではない。サー4.2

ホ ー ム デ ィ レ ク ト リ は 本 当 に 必 要

バにそのためのディスクスペースが要求か？

され，しかも必要な大きさは前もってはわからない。サーバ側としては十分な大大きなデータの処理にはリモート実行を許す必要がある。つまり，データを移動させないで，サーバ上で直接処理する

きさのディスクスペースを提供するしかないであろう。
利用者が彼らのスペースに保存して必要がある。その場合にはいるファイルは，一時的に必要とされ，・データへのアクセス

使い終わったものなのかも知れないし，・ユ ーザが作成したプログラムの実行

後々に必要とされる大切なものかも知れ

許可ない。また他人には見られたくないもの

・結果の受け取りなのかも知れない。サーバの管理者には・会話的実行

適切な管理義務が発生する。

5

データが公開されない原因には社会的なものと技術的なものがある。社会的なものは，過度な競争の結果として研究成果の抱え込みを必要悪と考える風潮，データの1次発掘者が低く見られている風潮（分析しないと研究成果にならない）が考えられる。技術的なものとしては，大きなデータを公表する手段を欠いていたために，
これまでは還元した情報しか公表できなかったことが挙げられよう。1 次データを公表しない
で成果だけを発表しているアカデミーの習慣が研究不正の温床になっている。

愛知大学情報メディアセンター

ホームディレクトリは本当に必要なのだろうか？

必要ではないなら，こうしたことに悩まされることはないのである。ホームディレクトリが必要とされる
理由は，FTP などによるファイル転送の際にファイルの受け皿が必要と考えられ－ 29 －

Vol.27, No.1, 2017

るからである 6 。しかし図 8 について考え・ク ライアントのプログラムはサーバてみよう。クライアントのプログラムを側で実行可能サーバ側で実行するにあたって，Plan9・ク ラ イ ア ン ト の プ ロ グ ラ ム 編 集 はの場合には，実はホームディレクトリは

ローカルサイドで行うことが可能

大した役割を果たしていないのである。

・ク ライアントはサーバ側で実行されたプログラムの実行結果を受け取る

5．ホームレスデータサーバ

ことが可能・ク ライアントにサーバでの会話的実

5.1

データサーバの新しい方向性

行を許す
サーバ側の要求は厳しい。

サーバの管理者にとってグリッドユー

この実現には Plan9 の逆方向マウント

ザは特殊な存在である。ボランティア的を利用すれば可能である。逆向きマウンにサービスを提供しているにすぎない相トによってサーバ上で直接クライアン手である。しかも顔が見えない相手であト の プ ロ グ ラ ム を 参 照 で き る。 た だ しる。彼らに対して貴重な記憶装置を特別

Plan9 自体はホームディレクトリの存在に準備するのは抵抗があるだろう。ユーを想定しているので，多少の手直しが要

ザのデータはユーザが所有する記憶装置求される。特にセキュリティ上の理由かに保管するのが管理者側とユーザの双方

らカーネルのパッチが要求される。このの利益である。そこで図 10 に示すサーバ

仕様は，実際に筆者のグリッドサーバ 7側の要求は実現可能か否かを考える。

で実現されている［2］。
ホームレスデータサーバの場合には，

具体的には次の要求仕様を考えてみ

ク ラ イ ア ン ト と サ ー バ と の 関 係 は 図 11

る：のようになる。

・クライアントの認証は行う

図 11 は図 8 と似ているがホームディレ・ク ライアントごとにホームディレク

クトリが存在しない。工夫すればホームトリを与えない・ク ライアントに一切の書き込みを許
さない
6

7

他にも OS ごとに存在理由があるが，除去可能な理由か否かが問題である。例えば公開鍵を使った ssh 認証方式があるが，ホームディレク
トリにログイン認証に必要な情報が置かれる。
そのような場合にはホームディレクトリは必須になる。

愛知大学情報メディアセンター

ディレクトリ無しにやっていけるのであグリッドサーバとは，コミュニティーのメン
バーが自由に使えるサーバ群であり，リモート実行を許す。通常は多数のサーバ上での並列実
行によって 1 個のコンビュータでは実現できないような大きな処理能力を得るために使われる。もちろん個々のサーバでユーザ登録しない
で，ユーザ登録は一箇所で済ませる仕組みを持つ。

－ 30 －

Vol.27, No.1, 2017

チケットで利用可能になっている。
さらにグリッドサーバを踏み台とした
不正アクセスを防ぐために，サーバからのネットワークアクセスを防止してい
る 8。
5.2

実行例

次の実行例は Plan9 のユーザを想定し
図 10

Don't write to me!

ている。彼らの多くは Bell Labs のアカ
ウントを持っている。そこで，このアカウントの保有者に対してサーバへのアクセスを許可するようにサーバが設定されて い る。 サ ー バ に ロ グ イ ン す る た め には，Plan9 の認証エージェント factotumに対して次の認証キーを登録しておく。
key dom=outside.plan9.bell-labs.com
proto=p9sk1 user=XXXXX!password=YYYYY
ここでは，紙面の都合上，3 行で書い

図 11

 ームディレクトリ無しの逆向き
ホマウントて い る が， 実 際 に は 1 行 で あ る。 ま た，
XXXXX は Bell Labs の ア カ ウ ン ト 名
で あ り，YYYYY は Bell Labs で の パ ス

る。

ワードである。ドメイン名が指定されて筆者のサーバはグリッドコンピューい る こ と に 注 意 す る。 こ の サ ー バ は マ

ティング用に設計されている。そのためルチドメイン認証に対応しており，サーに認証はマルチドメイン認証に対応してバ側は他のドメインのユーザも受け付けいる。しかも，認証の対象となるサーバる。

の所属ドメインがマルチであるばかりでサーバにログインするには cpu コマン

はなく，認証チケットを発行するドメイ

ドを使う：

ンもマルチである。現在は Bell Labs の8

チケットあるいは筆者が独自に発行する
愛知大学情報メディアセンター

完全を期してカーネルへのパッチで実現している。

－ 31 －

Vol.27, No.1, 2017

cpu -h grid.nyx.linkの利用を許し，プロセスが干渉しない保-k 'dom=outside.plan9.bell-labs.com'

障を得るためには，このようにプロセス

ここでも，紙面の都合上，2 行で書いのオーナ名にドメイン名を含めざるを得て い る が， 実 際 に は 1 行 で あ る。 ま た，ないであろう。なお，ps の表示が“bell-”grid.nyx.link は 筆 者 の サ ー バ で あ り，

で切られているのは，単に表示幅の節約

outside.plan9.bell-labs.com の ア カ ウ ンのためである。

トを使うことを指定している。一般的に

次に言 え ば factotum に は 複 数 の 認 証 キ ー が

ls /usr

登録されているので，その内のどれを使を実行してみる。するとホームディレク

うかを指示しているのである。ログイン

トリの一覧が表示される。その中には /に成功すれば“grid%”のプロンプトがusr/none と /usr/arisawa の他に，クラ表示される。

イアント側のユーザの一覧が見えるはず

ま ず 最 初 に ps コ マ ン ド を 実 行 し て みである。例えばクライアントのユーザ名

るとよい。図 12 は筆者が Bell Labs のアが bob であれば，/usr/bob が見える。もカウントでログインした場合の結果であ

ち ろ ん /usr/bob の 下 に あ る デ ィ レ ク トる。Bell Labs のアカウントでログイン

リやファイルはクライアントのものであした場合にはプロセスのオーナはる。bob はそれらを使って，自由に自分

XXXXX@outside.plan9.bell-labs.comとなっている。多様なドメインのユーザのプログラムを実行できる。
も し も bob の 他 に carol も ロ グ イ ン し

grid% psarisawa

1

0:00

0:00

256K Await

bootrcarisawa

2

0:00

0:00

0K Wakememouse...				
none

369

0:00

0:00

132K Open

listen

none

370

0:00

0:00

132K Open

listenarisawa@outside.plan9.bell-		20188

0:00

0:00		 124K Await

gcpu

arisawa@outside.plan9.bell-		20195

0:00

0:00		 240K Await

rcarisawa@outside.plan9.bell-		20196

0:00

0:00		 124K Pread

gcpu

arisawa@outside.plan9.bell-		20247

0:00

0:00		 116K Preadramfs

arisawa@outside.plan9.bell-		20252

0:00

0:00		 92K Pread

ps

grid%

図 12
愛知大学情報メディアセンター

ps コマンドの出力－ 32 －

Vol.27, No.1, 2017て い た ら ど う な る か？

Plan9 と Unix

い。

との大きな違いの一つにユーザが見る名グリッドユーザが見る名前空間は，シ前空間の根本的な違いがある。Plan9 にステムユーザが見る名前空間の一部でおいては異なるユーザは異なる名前空間

あ る。Unix で は フ ァ イ ル の 保 護 は 許 可に属している。その結果，carol は /usr/

ビットで与えるが，Plan9 ではその他に

bob を見ることはないし，逆もまた然り

カプセル化によって隠蔽できる。例えばである。

システムユーザの個人的なファイルの最 後 に Plan9 の テ キ ス ト エ デ ィ タacme を実行してみる。このエディタは他，/sys/log，/mail などがグリッドユー
ザには隠蔽されている。

（サーバ側で実行しているにもかかわらず）マウスを使え，そしてファイルブラ

5.3

ウザを兼ねているのでサーバの様子をホ ー ム レ ス デ ー タ サ ー バ の レ イ テ
ンシ

ざっと見るのに良いであろう。もちろんファイルの編集もできるが，編集はロー

世間一般の認識では世界規模の WAN

カル側で行った方がレスポンスが良い。

レベルのマウントは遅くて実用になるは筆者のサーバではシステム領域や他ずがないと言うことらしい。このようなユーザの領域への書き込みは禁止されて認識は著名な雑誌のレフリーですら持っいる。書き込みはクライアント側にあるている 。彼らは Unix や Windows の常識

ユーザの領域と，ユーザの便宜のためにで考えている。しかし Plan9 のマウント準備された ramfs にのみ許される。

は速い。既に述べたように，日本からア9ramfs とはメモリーの中のファイルシメリカ（Bell Labs）までのマウントレイ

ステムであり，Plan9 ではユーザごとにテンシは数秒である。マウント後に続く割り当てられる。ramfs は，ログインでユーザの作業時間を考えた時には，この生成され，ログアウトで消滅する。一時

時間は完全に無視できるだろう。
ではホームレスデータサーバのレイテファイル用のディレクトリである /tmp
は ramfs で実装されている。どのユーザ

ンシはどうか？

具体的にはも /tmp である。/tmp も Plan9 の私的なtime cpu -h grid.nyx.link

名前空間の中にあり，他のユーザと干渉-k 'dom ＝ outside.plan9.bell-labs.com'

し合うことはない。またクライアントの-c pwdファイルシステムは /mnt にマウントされるが，他のクライアントとは別の名前空間にあるために干渉し合うことはな
愛知大学情報メディアセンター

9

筆者はこの理由によって論文への掲載が拒否された。

－ 33 －

Vol.27, No.1, 2017

をアメリカから実行して貰い 10 ，レイテ比べて数倍に昇るので，妥当な数値であンシを測定する。アメリカから日本の筆

ろう 12 。この数値が大き過ぎて実用にな者のサーバに接続して，pwd を実行するらないのか否かは行われる内容に依存すのに必要な時間の測定である。

るが，殆どの場合には問題にはならない

認証サーバとしては Bell Labs のものが使われているので，cpu コマンドの実であろう。特に，会話的実行環境では完
全に無視できる。

行によってログインするまでには次の 3ステップが内部で実行される 11 。

5.4

ホ ー ム レ ス デ ー タ サ ー バ を 支 え る
技術

1．ク ラ イ ア ン ト は ま ず 筆 者 の サ ー バに ア ク セ ス し， チ ケ ッ ト を 入 手 するのに必要な情報を受け取る

筆者のホームレスデータサーバは

2．ク ラ イ ア ン ト は そ の 情 報 を Bell

Plan9 の技術に基礎を置いている。最もLabs の 認 証 サ ー バ に 提 示 し， チ

重要で困難な部分は Plan9 の標準環境のケットを受け取る

中で既に実現している。すなわち

3．ク ラ イ ア ン ト は， そ の チ ケ ッ ト を・ c pu コマンドによるリモートアクセ

筆 者 の サ ー バ に 提 示 し， ロ グ イ ン

スの技術の許可を請う・逆 向きマウントの技術

さらに筆者のサーバではユーザの使い

・認 証エージェントに基づく認証技術

心地を向上させるために，クライアント・プ ロセスごとに自由に構築できる名と交信しながら幾つかの内部処理を行っ

前空間のカプセル化技術ており，この事がレイテンシを幾分大きなどである。Plan9 の標準的なリモート

くする。

アクセスではサーバ側にホームディレク

幸いシアトルに住む友人が実験に協力

トリの存在を前提にしているが，この要してくれた。報告によれば 3 回の実験で件を省いたのが筆者が提唱するホームレ

結果は各々7.58 秒，7.22 秒，8.17 秒であスデータサーバである。それでもデータる。この値は Plan9 による日本からアメサーバとしてのニーズが満足されるようリカまでのマウントレイテンシの数倍に，またセキュリティ上の問題が発生しである。cpu コマンドが完了するまでのないようにサーバの設計を行う必要があ

サーバとの交信回数は通常のマウントに

12

10

これも 1 行のコマンドであるが，紙面の都合
上 3 行で表示されている。
11
詳しくは文献［2］の Appendix を見よ。

愛知大学情報メディアセンター

Plan9 にも幾つかの変種が存在する。筆者のは 9front である。これは，このままではレイテンシがいささか大きい。そのために筆者は少しだけ手を加えている。その結果，標準環境に比べてレイテンシは 1/3 程度になっている。

－ 34 －

Vol.27, No.1, 2017

る。以下に設計の要点を解説する。筆者

ト オ ー ナ と none と そ の 他 で あ る。 そ ののサーバではユーザを次のように分類しためにグリッドユーザとシステムユーザている：の区別ができないのである。Plan9 のホ・グリッドユーザス ト オ ー ナ は Unix の root に 相 当 す る。

・システムユーザ

Unix と 異 な り ホ ス ト オ ー ナ に 固 定 し た・ホストオーナ

名前はない。マシンを立ち上げたユーザ

・ユーザ none

がホストオーナになるのである。

グリッドユーザにはホームディレクト

ユ ー ザ none は Unix の nobody に 相 当

リを与えない。筆者はグリッドユーザとし， 主 に ネ ッ ト ワ ー ク サ ー ビ ス を 受 け

し て BellLabs に 登 録 さ れ た ユ ー ザ を 想

持 っ て い る。Unix で は nobody の 他 に定している。従って，ここに登録されたも，八百万の神様（デモン）を持っていユーザは筆者のサーバを使えるように設るが，Plan9 では none 一個で済ませてい定 し て い る。 と こ ろ が 筆 者 は BellLabs

る。

にユーザ登録されたユーザのリストはPlan9 では名前空間をカプセル化でき

持 っ て い な い の で あ る。 従 っ て ホ ー ム

る。Unix で も あ る 程 度 は で き る が 実 用

ディレクトリは与えようがない。筆者のの域には達していない。筆者のグリッド

グリッドユーザを Bell Labs のユーザにサーバは筆者が普段使っているファイル

完全に限定してしまえば，ユーザ登録にサーバの下で動いている。従ってそこに関する一切の作業は必要がなくなり，まは 私 的 な フ ァ イ ル も 存 在 し， グ リ ッ ドたグリッドユーザは利用にあたって筆者

ユーザからは，そうしたファイルの存在と連絡をとる必要もない。

自 体 を 隠 し た い の で あ る。 そ の た め に

Plan9 ではシステムユーザは本来ならネットワークが許されている。しかし，
このシステムではグリッドユーザの巻き添えを食ってシステムユーザもネット

Plan9 の名前空間のカプセル化が利用されている。
以上の説明をまとめると表 2 のようになる。

ワークができないようになっている。こホームレスサーバ自体は Plan9 の標準の サ ー バ は 家 庭 内 の LAN の 中 に 置 か れ

環境に多少の手を加えれば実現できる。

て い る た め に， セ キ ュ リ テ ィ の 関 係 で次の 2 つのコマンド：

ネ ッ ト ワ ー ク は 困 る の で あ る。 ネ ッ ト・認証エージェント factotum

ワークの禁止は完全を期してカーネル

・ cpu コマンド

レベルで行っている。Plan9 のカーネルにわずかのパッチを当てれば済む。クラは，ユーザを 3 つに分類している。ホス

イアント側は標準環境のままで構わな

愛知大学情報メディアセンター

－ 35 －

Vol.27, No.1, 2017

表2

筆者のホームレスグリットサーバにおけるユーザの分類

ユーザ

ネットワーク

名前空間

ホームディレクトリ

グリッドユーザ

不可

限定する

無

システムユーザ

不可

限定せず

有

ホストオーナ可限定せず

有システムメンテナンス

none

可

限定せず

有

ネットワークサービス

6

い。

仕事

グリッドコンピューティング

しかし Plan9 は筆者のようなサーバの使い方を想定していないので，そこから

6.1

グ リ ッ ド コ ン ピ ュ ー テ ィ ン グ の パ
ラダイム

発生するセキュリティ上の問題を解決
し な く て は な ら な い。 例 え ば， 本 来 のPlan9 で は， ど の ユ ー ザ も none に な れ

筆者がホームレスサーバを考える動機るとされている。しかしグリッドユーザになったのはグリッドコンピューティン

も none に な れ る よ う で あ れ ば， 表 2 にグである。グリッドコンピューティング

示した分類自体が意味をなさないのであが 目 指 す パ ラ ダ イ ム は 図 13 で 上 手 に 表る。表 2 の通りに働くためにはカーネル現されている。

のパッチ当てが必要になる。筆者のサー図を注意深く観察すると，小さな魚はバの場合以下のようなパッチが当てられ

実は PC ではなく，ワークステーションている。

（PC よ り 少 し 上 位 ク ラ ス の コ ン ピ ュ ー・ホ ス ト オ ー ナ だ け が ユ ー ザ none に

グ を 上 手 に こ な す に は，Unix ワ ー ク ス

なれる・グ リッドユーザによるサーバ内からのネットワークを防止するタ）である。グリッドコンピューティン

13

テーションクラスのコンピュータが必要と考えたのであろう。

・グ リッドユーザに提供されている名前空間を完全にロックする

こ の 図 に 示 す 考 え は， 実 は Google やAmazon など著名なネット企業がシステムを組む際に既に採用しており，クラス
ターコンピューティングとも呼ばれてい13

既に述べたように，カーネルレベルではグリッドユーザとシステムユーザの区別はできない。従ってホストオーナと none 以外は内部からのネットワークが防止されていると言う意味である。

愛知大学情報メディアセンター

る。高価なスーパーコンピュータでシステムを組むよりも，安価な市販品を多数組み合わせてシステムを組む方が安く済むからである。さらに大規模なデータ処－ 36 －

Vol.27, No.1, 2017

図 13

PC の大群がスーパーコンピュータ
を飲み込む（文献［20］）

理はこの方が効率的で，また障害に対す

図 14

Grid Computing Evolution（ 文 献
［27］）

14
力が必要とされているのである 。

る耐久性が高い。
グリッドコンピューティングに結びつ

6.2

グ リ ッ ド コ ン ピ ュ ー テ ィ ン グ の 分
類

く 考 え は 1990 年 代 の 初 頭 か ら す で に 提唱 さ れ， 研 究 機 関 で 模 索 さ れ た。1990
年代末に至るまでのグリッドコンピュー次の図 14 は Globus のホームページにティングの研究と将来への展望は，Ian

載 っ て い る Gentzsch の 論 文［27］ か ら

Foster た ち の 本 に 詳 し く 纏 め ら れ て い

借 用 し て い る。Gentzsch は， デ ー タ セる［21］。 研 究 機 関 へ の グ リ ッ ド コ ン

ンターの中で実現されているクラスター

ピューティング普及の中心的な役割を

コンピューティング（Cluster Grid）と担ったのは Globus［49］で，現在におけ研究機関を結ぶグリッドコンピューティ

るグリッドコンピューティングのソフト

ン グ（Global Grid） の 間 に， 中 間 的 な

ウェア基盤を築き上げた。

形 態 が あ る と 言 う。 分 類 の 視 点 は， グ

データセンターにおけるクラスターコ
ンピューティングに対する，研究機関をリ ッ ド の 運 用 人 員（team） と 運 用 組 織（organization）である。
中間的な形態として図では“Campus

結ぶグリッドコンビューティングの難しさは，参加するコンピュータの多様性にあ る。 デ ー タ セ ン タ ー の 場 合 に は コ ン
ピュータは仕様を統一できる。しかし，研究機関を結びつけるグリッドネット
ワークでは管理主体が異なっているために仕様を統一するのは難しい。特別の努
愛知大学情報メディアセンター

14

日本では 2008 年に東大，京大，筑波大を結ぶ
グリッドコンピューティングの実証実験が開始されたが，その時には基本仕様を統一するために，3 大学による共同入札が行われている［23］。
2012 年には実証実験に関するシンポジュームで認証基盤にかんする問題が取り上げられている［24］。

－ 37 －

Vol.27, No.1, 2017

Grid”となっている。しかし，この著者

Collaboration グ リ ッ ド で は， 認 証 シ スの 図 の キ ャ プ シ ョ ン で は“Enterprise”

テムは統一されていないであろう。既にとなっているのである。両者に共通して述べたように，異なる組織で認証システ

いるのは，単一組織が運用している点でムを統一するとなると大きな努力が必要

あ る。 こ の 場 合 に は シ ス テ ム を 組 む にである。9grid で「統一不要」と書いたの当たって認証システムは 1 つに統一されは，認証を与える組織を統一する必要がる。それではクラスターとの違いはどこないという意味である。認証メカニズム

にあるか？

15
は統一する必要がある 。

クラスターでは認証はもっとシンプルなはずである。もちろんクラ表の「分散ファイルシステム」の欄でスターの外から中へのアクセスは認証がは，サーバとクライアント間で分散ファ求められるはずであるが，クラスターのイルシステムが利用可能か否かを問題に内部で行われているコンピュータ相互のしている。グリッドコンピューティング

アクセスでは認証は不要であろう。

に利用可能な多数のサーバが一つの組織

図 の“Global Grid” に つ い て も 他 のに属していれば，それらを分散ファイル

呼 び 方 が あ る。 例 え ば“Collaboration

システムで結ぶのは現在では当たり前

Grid” で あ る［25］。“Global Grid” はの こ と と 考 え て よ い。Collaboration グ

インターネットレベルのグリッドであ

リッドでは，分散ファイルシステムにつる こ と が 強 調 さ れ て い る の に 対 し て，

いて「採用困難」と書いたが，最新の技“Collaboration Grid”はグリッドを構成術 で あ る Gfarm を 使 う と 実 用 の レ ベ ルする組織が単一ではないことが強調されに達しているかも知れない。しかし筆者ている。グリッドの難しさの本質は，グは評価の手段を持たないし，性能を評価

リッドの管理にあることを考え，ここでした文献も知らない。

は“Collaboration Grid”を採用する。
そこで次ページ表 3 に筆者による分類

6.3

9grid

をまとめる。ついでに筆者のホームレス
9grid と 呼 ば れ る グ リ ッ ド は， 今 回 のグリッドサーバ（9grid）も表に組み込ん

筆者のホームレスデータサーバの以前でいる。
表の認証システムについて補足が必要に，歴史上 2 度現れ異なるグリッドプロ

で あ ろ う。Campus/Enterprise グ リ ッ
ド で は， 認 証 シ ス テ ム は シ ス テ ム 導 入の際に既に統一されていると考えてよい。そのために導入は容易である。他方
愛知大学情報メディアセンター

15

Plan9 の 中 で は 既 に 統 一 さ れ て い る。 正 確に言えば，Plan9 は複数の認証メカニズムをサポートしているが，それらは認証エージェント
factotum を通じて統一されている。

－ 38 －

Vol.27, No.1, 2017

表3

Grid の分類

分類

認証システム

分散ファイルシステム

適用範囲

Cluster不要

統一可能

LINK aCampus/Enterprise

必要（統一可能）

統一可能

LAN b

Collaboration

必要（統一困難）

採用困難→ FTP

WAN

（9grid）

必要（統一不要）

不要

WAN

a

リンクというのは LAN よりも狭い範囲で，イーサーネットのブロードキャストが届く範囲である。セグメントb

物理的な LAN よりも，単一ドメイン構成になっていることが本質的である。この場合，仕様を統一できるとも呼ばれるジェクトに対して使われている。最初にら れ て い る［30］。Wiki に は グ リ ッ ド

現 れ た の は Bell Labs と University of

サーバに対する新しいアイデアも述べら

Calgary と の 共 同 研 究 プ ロ ジ ェ ク ト のれている。しかしながら，それらのアイ

グリッドである［30］。この成果は文献

デアは実現されることもなく第 2 期は終［28］に纏められている。この内容はま息した。9fans に集まるユーザの関心はた Mirtchovski の博士論文に詳しく解説

もっぱら技術的な問題にあり，その解決

さ れ て い る［29］。 こ れ ら の 論 文 で は，のメドが立った段階で関心を無くしたと

Plan9 はグリッドコンピューティングに思われる。

適した OS であると主張された。

もしかすると何十年か先に 9fans によ

彼らに刺激されて，メーリングリスト

るこの時期の活動は別の視点から歴史家

9fans に 集 ま る Plan9 ユ ー ザ が グ リ ッ ドの評価を受けるようになるかも知れな

コンピューティングの実験を始めた。グい。 す な わ ち， 研 究 所 の 高 性 能 な コ ン

リッドサーバがボランティア的に提供さピュータとネットワークの中で生まれれ，各自が各自のやり方でグリッドサー

育まれたグリッドコンピューティング

バを構成した。筆者もサーバを提供し，が，Plan9 による新しい技術によって初

並列コンピューティングの実験を行い，めて研究所の外に踏み出し，普通のコン

そのソフトを公開している［31，32］。こピュータと普通のネットワーク回線の中れが9grid の第2期である。このユーザーで実験されたと。

ズグループによって，標準配布の Plan99grid の 第 3 期 に な る か 否 か は 不 明 だに少し手を加えるだけでマルチドメイン

が，あれから 10 年，筆者は 9grid を再び認証が可能になることが見つけられた。

考えてみることとした。グリッドサーバ

彼 ら の 実 験 の 成 果 は Plan9 Wiki に 纏 めの必要用件からホームディレクトリを除愛知大学情報メディアセンター

－ 39 －

Vol.27, No.1, 2017

去できるのではないかと考えたからであコンピューティングを進めている［45］。

る。ホームディレクトリをグリッドユー

Wikipedia によると2009年現在42大学がザに提供しなくてもよいのなら，グリッOSG に参加しているという［46］。

ドサーバを気楽にユーザに提供できるだ

EGI と OSG に 基 礎 を 置 い て， 世 界 最ろう。これをホームレスグリッドサーバ

大のグリッド WLCG（Worldwide LHCとは言わないのは，グリッドサーバは複Computing Grid）が組織されている。こ数個の存在を想定しているのであるが，の 組 織 を 調 整 し て い る の は CERN で あ

ホームレスデータサーバは今の所世界でり，LHC（Large Hadron Collider）か

ただ一つしか存在しないからである。

ら生み出される巨大なデータを世界中の研究者の間で共有することを使命として

6.4

グ リ ッ ド コ ン ピ ュ ー テ ィ ン グ の 現
在と未来いる［43］。
ある雑誌の記事［47］を次に紹介する。

グリッドコンピューティングに関する 2000 年 頃 ま で の 状 況 に 関 し て は 文 献［34，35］に詳しいので，ここでは省略「e-Science」という言葉をお聞きになったことがあるでしょうか。聞いたことのある方は「高度に分散化する。現在，研究機関でのグリッドコン

されたネットワーク環境で実施されピューティングは，研究の基本インフラ

るコンピュータを多用した科学など

としてヨーロッパとアメリカで定着してと 言 わ れ， 主 に 自 然 科 学 の 分 野 で，いるようである。

研究成果や研究過程で生み出されるヨーロッパでは 2002 年から 2004 年の大量のデータを共有し，新たな研究

Data-Grid プ ロ ジ ェ ク ト［36］，2004 年への利活用を行おうとする取組み等

か ら 2010 年 の EGEE（Enabling Grids

といった理解をされているかと思い

for E-sciencE）プロジェクト［37］を経ます。一方で近年，大量のデータをて，2010 年からは EGI（European Grid
Infrastructure）プロジェクト［38］に引き継がれている。ここには 2016 年現在，世界中から 200 以上の研究機関が参加している［39］。アメリカでは早くも 1988
年から大学でのグリッドプロジェクトが動いており［44］，現在では OSG（Open共 有， 活 用 す る と い う e-Science と似た取り組みが，あらゆる分野で盛んに行われつつあります。ビジネスの分野では「ビッグデータ」や「クラウドコンピューティング」と呼ばれるさまざまな技術やサービスが普及し，ログ等の大量の生データを解Science Grid）が中心になってグリッド
愛知大学情報メディアセンター

－ 40 －

Vol.27, No.1, 2017析し，ビジネスに活きる知見を引き出す「データサイエンティスト」という専門家が注目を集めつつあります。自中 の IT 化 が さ ら に 進 行 し た 時 に グ リ ッ
ドコンピューティングが研究機関の外に広がる可能性はどうだろうか？

World

然 科 学 分 野 で は「 オ ー プ ン サ イ エ ン

Wide Web は CERN か ら 始 ま り， 研 究ス」，「ビッグサイエンス」，「e リサー

機関に広がり，現在では世界中の人々にチ」等と呼ばれる取り組みが進みつつとってなくてはならない存在となってあり，一方で人文科学分野では Digital

い る。 同 様 な プ ロ セ ス を 辿 る の だ ろ う

Humanities と い う 分 野 が 隆 盛 し， 研

か？

究分野を超えた学際的な研究も盛んにがインターネットと接続すると予想されなりつつあります。

ている。そのコンセプトは「モノのイン

将来には家庭のあらゆるデバイス「e-Science とその周辺～現状とこれから～」の編集に

ターネット（IoT）」と呼ばれている。そあたって［47］。（下線は筆者）のような時代には研究所のスタイルではない新しいグリッドが求められる可能性

グリッドコンピューティングを支えるが残されている。そこでは高性能なコン

理念は e-Science に示されている研究者

ピュータや高性能なネットワークを求め間でのデータ共有であり，単に高速の計ることはできないし，またグリッドのた算環境を提供したいと言うことではない

めに提供できる資源は限られてくる。さの である［34，41，46］。こうした欧米らに家庭内にサーバを設置するとなれの動きに比べると日本は非常に遅れていば完全なセキュリティが求められるだろる 16 。

う。そしてグリッドユーザごとのホーム

現 在 の Collaboration グ リ ッ ド は 研 究

ディレクトリの提供はできそうもない

機 関 の グ リ ッ ド で あ る。 こ の 分 野 は グだろう。筆者のホームレスデータサーバ

リッドコンピューティングのニーズがは，そうした未来を視野に置いた一つの高く，多数の高性能なコンピュータを集提案である。

めやすい。また高速なネットワークが研
究機関の間で整備されている。つまりグ

References

リッドコンピューティングが発展しやす［ 1 ］K e n j i A r i s a w a : “ B e y o n d T h e W e b

い分野なのである。しかし，将来，世の16

日本では 2008 年にようやく 3 大学のグリッドから始まり，現在では旧七帝大を中心とした共同利用の環境が整っている。もちろん成果に関しては公開されており，他に毎年シンポジュウ
ムが開かれている［48］。

愛知大学情報メディアセンター

Homeless Data Server̶”（2016）
http://plan9.aichi-u.ac.jp/9grid2/beyond1.
html
http://p9.nyx.link/9grid2/beyond1.html（mirror）－ 41 －

Vol.27, No.1, 2017

［2］Kenji Arisawa:“A New Grid Server”（2013）［10］Wikipedia:“Server Message Block”（2015）
http://plan9.aichi-u.ac.jp/9grid2/9grid.html

https://en.wikipedia.org/wiki/Server_

http://p9.nyx.link/9grid2/9grid.html

Message_Block（参照 2016）［11］Wikipedia:“Samba（software）”（mirror）［3］EETimes:“File Sharing on the WAN: A

https://en.wikipedia.org/wiki/Samba_（software）（参照 2016）

Matter of Latency”
http://www.eetimes.com/document.

［12］Wikipedia: “Windows Services forUNIX”

asp?doc_id ＝ 1272058（2004）［4］acmqueue: “Bound by the Speed ofhttps://en.wikipedia.org/wiki/Windows_
Services_for_UNIX（参照 2016）

Light”
http://queue.acm.org/detail.cfm?id ＝［13］Wikipedia: “List of file systems”
https://en.wikipedia.org/wiki/List_of_file_

1900007（2010）［5］Super User: “faster way to mount asystems（参照 2016）［14］Ubuntu:“FuseSmb”

remote file system than sshfs?”
http://superuser.com/questions/344255/

https://help.ubuntu.com/community/
FuseSmb（参照 2016）［6］Wikipedia:“Network File System”
https://en.wikipedia.org/wiki/Network_［15］産総研：「世界中のストレージを統合する
グリッド基本ソフトウェア「Gfarm」を無償

File_System（参照 2016）

公開」［7］デジタルアドバンテージ：「ファイル共有プロトコル，SMB と CIFS のhttp://www.aist.go.jp/aist_j/press_

違いを正しく理解できていますか？（前編）」

release/pr2003/pr20031125/pr20031125.

http://www.atmarkit.co.jp/ait/

html（2003）［16］oss-Tsukuba:「つくば OSS 技術支援セン

articles/1501/19/news092.html（2015）［8］デジタルアドバンテージ：「ファイル共有

ター：Gfarm ファイルシステム」

プロトコル SMB/CIFS（その 1）（1/3）」

http://oss-tsukuba.org/software/gfarm（参http://www.atmarkit.co.jp/ait/

照 2016）［17］oss-Tsukuba:「Gfarm ファイルシステム

articles/0410/29/news103.html（2004）［9］Rem system:「Windows を利用していてを automount する」

WAN 越しのファイル共有が遅い場合の検討

http://oss-tsukuba.org/tech/automount事項」（2013）

http://www.rem-system.com/post-304/

愛知大学情報メディアセンター

［18］Russ Cox:“Drawterm”－ 42 －

Vol.27, No.1, 2017

https://swtch.com/drawterm/［27］Wolfgang Gentzsch:“Grid Computing［19］Cinap Lenrek:“DRAWTERM”

Adoption in Research and Industry”
http://toolkit.globus.org/ftppub/liming/

http://drawterm.9front.org/［20］M a y a H a r i d a s a n : “ C l u s t e r / G r i d

GridCompfeb03.doc（2003）［28］Andrey Mirtchovski，Rob Simmonds

Computing”
http://www.cs.cornell.edu/courses/

and Ron Minnich:“Plan 9 — an Integrated

cs614/2004sp/slides/Clusters4.ppt（2004）

Approach to Grid Computing”
Parallel and Distributed Processing［21］Ian Foster and Carl Kesselman:“The Grid: Blueprint for a New Computing

Symposium，2004. Proceedings. 18th

Infrastructure”

International

Morgan Kaufmann Publishers Inc. San［29］Andrey A. Mirtchovski:

Francisco, CA, USA ⓒ 1999

“Grid Computing with Plan 9̶ an［22］Globus: “Research data management

Alternative Solution for Grid Computing”

simplified”

http://mirtchovski.com/p9/thesis.pdf

https://www.globus.org/（参照 2016）（2005）［23］朴泰祐：「T2K 筑波システムの概要と利［30］Bell Labs:“Plan 9 Wiki ̶9grid”

用プログラム計画」

http://plan9.bell-labs.com/wiki/

http://www2.ccs.tsukuba.ac.jp/workshop/

plan9/9grid/（参照 2015）［31］K e n j i A r i s a w a : “ P l a n 9 G r i d

t2k-sympo2008/file/boku.pdf（2008）［24］ 合 田 憲 人， 他：「 高 性 能 分 散 計 算 環 境Computing”の た め の 認 証 基 盤 の 設 計 」Symposium

http://plan9.aichi-u.ac.jp/9grid/（2005）

on Advanced Computing System andhttp://p9.nyx.link/9grid/（2005）

Infrastructures 先進的計算基盤システムシ［32］Kenji Arisawa:「グリッドツールキット」
http://p9.nyx.link/9grid/gtk.html（2005）

ンポジウム SACSIS2012（2012）［25］Vassiliki Pouli, Yuri Demchenko，［33］Edited by Fran Berman，Geoﬀrey C. Fox

Constantinos Marinos，Diego R. Lopez，andand Anthony J. G. Hey:“Grid Computing

Mary Gram- matikou:

̶Making the Global Infrastructure a“Chapter 9: Composable Service

Reality — ”（John Wiley & Sons，2003）［34］Fran Berman，Geoﬀrey Fox and Tony

Architecture for Grid”（文献［26］）［26］Nikolaos P. Preve:“Grid Computing”“Toward a Global Interconnected
Infrastructure”（Springer, 2011）愛知大学情報メディアセンター

Hey:“The Grid: past，present，future”（ref.
［33］, pp.9-50）［35］I a n F o s t e r : “ T h e G r i d : A n e w－ 43 －

Vol.27, No.1, 2017

infrastructure for 21st century science”

https://en.wikipedia.org/wiki/Open_（ref.［33］, pp.51-65）

Science_Grid_Consortium/（参照 2016）［47］ 情 報 科 学 技 術 協 会：2013. 9 特 集［36］CERN:“The DataGrid Project”
http://eu-datagrid.web.cern.ch/eu-datagrid/「e-Science とその周辺～現状とこれから～」（参照 2016）

http://www.infosta.or.jp/journals/201309ja/（2013）［37］EGEE:“Welcome”
http://eu-egee-org.web.cern.ch/eu-egee-［48］JHPCN:「学際大規模情報基盤共同利用・共同研究拠点」

org/（参照 2016）

http://jhpcn-kyoten.itc.u-tokyo.ac.jp/ja/（参［38］EGI:“HOME”

照 2016）

http://www.egi.eu/ （参照 2016）［49］Globus，“Research data management［39］EGI:“Virtual organisations”
http://www.egi.eu/community/vos/（参照simplified”

2016）

https://www.globus.org/［50］Bell Labs: “Plan 9̶Programmer’s［40］EGI:“Wiki”
https://wiki.egi.eu/wiki/Intranet/（ 参 照Manual（Volume 1）”2016）

http://plan9.bell-labs.com/sys/man/［41］EGI:“Weaving The Internet Of Data”
http://www.egi.eu/blog/2016/03/21/
weaving_the_internet_of_data.html（ 参 照

http://plan9.bell-labs.com/sys/man/vol1.
pdf［51］Bell Labs: “Plan 9̶The Documents（Volume 2）”

2016）［42］WLCG: “Welcome to the Worldwide

http://plan9.bell-labs.com/sys/doc/［52］Russ Cox，Eric Grosse，Rob Pike，Dave

LHC Computing Grid”

Presotto and Sean Quinlan: “Security in

http://wlcg.web.cern.ch/（参照 2016）

Plan 9”Proceedings of the 11th USENIX［43］WLCG:“Welcome”
http://wlcg-public.web.cern.ch/（参照 2016）［44］HTCondor:“Computing with HTCondor”
https://research.cs.wisc.edu/htcondor/（参Security Symposium，2002
https://www.usenix.org/legacy/event/sec02/cox/cox.pdf

照 2016）［45］OSG:“Open Science Grid”
http://www.opensciencegrid.org/（参照 2016）［46］W i k i p e d i a : “ O p e n S c i e n c e G r i d
Consortium”

愛知大学情報メディアセンター

－ 44 －

Vol.27, No.1, 2017