Mercuryの誕生から崩壊まで (1994 $\sim$ 2001)

一昔前になりますが、バブル時代末期の1993年には「新社会資本」という言葉が流行っ ていたそうです。これは公共投資による社会資本整備の対象を、道路や橋といっ た土木・建築関係だけでなく、大学や研究機関の整備・小中学校へのコンピュー タの配置などにも広げよう、というものでした。

この新社会資本の中に「大学等におけるキャンパスネットワークの整備」とい う項目がありました。というわけで平成5年度の第1〜3次補正予算で、大部分 の国立大学にキャンパスネットワークの整備予算がつくのですが、一橋大学に も運良く(?)そのオコボレが廻ってきました(当時の関係者曰く「平成の神風」)。 こうして一橋大学初の本格的なキャンパスネットワーク Mercuryが構築され ることになりました([7])。

Mercuryは 1994年10月に運用を開始しています。基幹系として、西キャンパ ス内に3重のFDDIリングを張りめぐらし、建物内の幹線として 10BASE-5 を、 末端には 10BASE-T を採用したこのネットワークは、イーサネットの芋蔓接続 だった森社工LANに比べて、かなり画期的に感じられたのではないかと想像さ れます。 なお、この後、1995年に西キャンパス内での拡張工事(事務棟や本館など)があ り、1996年には東キャンパス内専用のFDDIリングが増設される、といった拡張 がおこなわれています。

さて、Mercuryが構築された直後の 1995 年に、爆発的なインターネットブー ムが日本で巻き起こります。パーソナルコンピュータの急速な普及・高性能化 とあいまって、利用者の急増と利用形態の大幅な変化が始まりました。メール やWWWの普及・各種業務のネットワーク化が進んだことにより、かつては 一部の物好きな人々が半ば実験的に利用するマイナーなサービスであったキャ ンパスネットワークが、いつのまにか全構成員が利用する研究・教育・事務の インフラストラクチャへと変貌してしまったわけです。 このような情勢変化のため、Mercuryについての次のような問題点が生じて きました。

末端での帯域不足
Mercuryでは建物内のネットワークとして 10BASE-5 を採用していました。 そのため同一建物内にあるノード全体で半二重10Mbpsの帯域を共有することに なります。利用者の急速な増加のため、1998年ころには、ひとつの10BASE-5ネッ トワークに数百のノードが接続している建物も珍しくなくなりました。こうな りますと、1ノードあたりのスループットがダイヤルアップ接続と大差なくな る状態が多発するので、利用者の不満が高まります。とくに、初期の頃からの 利用者は、運用開始時の数人からせいぜい数十人でひとつのネットワークを専 有していた古き良き(?)時代を記憶していますから、非常な不満を持っていた のではないでしょうか。
\scalebox{1}{\includegraphics{p1.eps}}

障害が他所へ波及しやすい
上述したように Mercuryでは建物内の基幹ネットワークとして 10BASE-5 を 採用していました(構築当時には他に選択枝がなかったのだろうと思われます)。 このため1本の同軸ケーブルを全ノードで共有する形になり、トランシーバの 故障や異常機器の接続といった局所的な障害が即、ネットワーク(セグメント) 全体へと波及してしまうような事故が多発していました。
\scalebox{1}{\includegraphics{p2.eps}}

遠隔管理が困難
Mercuryを構成するネットワーク機器は、事実上、遠隔管理に対応していま せんでした(構築当時には他に選択枝がなかったのだろうと思われます)。その ため、リモートではせいぜいある建物内で障害が発生している、という程度し か状況を把握できませんでした。実際に障害発生箇所を特定するためには、現 地に人員を派遣して「20の扉」方式で徐々に絞りこむしかありません。これで は障害対応に時間がかかりますし、ネットワーク管理者にも多大な負担がかかっ てしまいます。
\scalebox{1}{\includegraphics{p3.eps}}

サブネット構成の柔軟性に欠ける
一橋大学には、建物や部屋の割り振りが「長屋」的である、という特徴があり ます。すなわち、大学内での行政的な組織構成と物理的なレイアウトがあまり 一致していません。 Mercuryでは建物や部屋の物理的なレイアウトに対応してサブネットが構 築されています。そのため といったような悲喜劇(?)が頻発してしまいました。その結果として、次のよ うな問題が生じてしまいます。
\scalebox{1}{\includegraphics{p4.eps}}
きめ細かいネットワーク運用がむずかしい
◯◯学部や××課といった単位でサブネットを専有できれば、その部署の ポリシーに応じたネットワークの運用を自分達でおこなうことができます。 しかし他の部署との混在状態では共通の運用ポリシーを作ることができない かぎり、そのような自主的なネットワーク運用はできません。
セキュリティの問題
上記に含まれることではあるのですが、とくにセキュリティ面では非常に問 題のあるネットワーク運用になってしまいました。たとえば業務で使うファ イル共有などは同一サブネット内だけにアクセス制限をかければよさそうな ものですが、別のサブネットにも利用者がいるとそうもいきません。ホスト 単位での細かいアクセス制限をかけるのは面倒ですから、けっきょく世界中 から丸見えでいいや、といった運用になりがちです。 またサブネット単位でファイアウォールを導入しようとしても、雑居してい る部署同士での合意が得られませんから不可能です。

こうした Mercuryの問題点はかなり構造的なものですから、小手先の改良で どうにかなるものではありません。そのため、1997年頃から次期キャンパスネッ トワーク構築へ向けての予算獲得運動が始まっています。しかし といった情勢のため、けっきょく20世紀中にキャンパスネットワークの再構築 をおこなうことはきませんでした。

1998年も終わりに近づきますと Mercuryの構築から5年近くが経過し、 ネットワーク機器の老朽化が問題になってきました。機器が老朽化したのなら ば新品と交換すればよさそうなものですが、

といった難点があるので一筋縄ではいきません。やむをえず という両面作戦をとることになりました。

さて、1999年3月に、情報処理センター・情報教育棟内のシステム更新(4年に1 度)がありました。このときに情報処理センター・情報教育棟内のネットワー ク設備を一新したため、局所的には先に述べた Mercuryの構造的な問題を解 消することができました。また副産物として、不要になった Mercury用のルー タを予備機として確保することができました。2000年4月に開館した東キャン パスの国際研究館のネットワークにはこのルータを転用したため、けっこう予 算の節約ができました。

また、1999年度末の学内残予算から1000万円ちょっとを融通してもらうことに 成功したので、当時もっとも劣悪な状況であった第2研究館内のネットワーク を全面的に再構築することができました(2000年6月)。この第2研究館の新ネッ トワークは Mercury2のプロトタイプ的な役割を果たします([8])。

2000年に入りますと、いよいよネットワーク機器の老朽化が激しくなり、故障 が頻発するようになります。このままでは Mercury崩壊の日も遠くありませ ん。 一方では新ネットワーク(Mercury2)の予算がつく、という噂も流れてきます。 お役所特有の曖昧な言い方に悩まされましたが、けっきょく2000年度の「IT関 連補正予算」(2000年10月に内示があり、12月に公式に通知がきました)で Mercury2の構築が認められることになりました。とはいえ、Mercury2の 運用開始は早くても2001年の6月以後になるので、それまでいかに Mercury を延命させるかが当面の課題となりました。

2001年に入ると次々と Mercuryを構成するネットワーク機器(主にルータ)が 壊れはじめます (附属図書館・東本館・第1講義棟・イノベーション研究センター…)。 Mercury2の運用開始が目前に迫っている以上、Mercuryに投資するのは もったいないですから、中古部品の流用などをおこない、なんとかしのいでい たのですが、6月になると手持ちの中古部品も尽きてしまいました。こうなる と手の打ちようがありませんので、あとは Mercuryの崩壊を見守るのみです。

並行しておこなわれていた Mercury2の構築はいくつかのトラブルがあり遅 れていました。もうすこし初期調整に時間をかけたかったのですが Mercury が崩壊しかかっている以上、やむをえません。6月中に最低限の準備を終えて、 Mercuryから Mercury2への全面移行を決行しました(2001年7月2$\sim$3日)。

こうして Mercuryは歴史的使命を終えました。実際には経済研究所や東本館 などで一部まだ運用がおこなわれていますが、これも年内には Mercury2へ の移行が完了する予定です。その後のMercuryは解体を待つのみです。古く からのネットワーク利用者にとってはちょっと哀しい結末かもしれませんね。



Footnotes

... 文部科学省[*]
当時は「文部省」。