クラウドなるべきもの

クラウドという言葉がはやりになっている。クラウド＝雲というのは、インターネットを表現するのに、もくもくと雲のような絵を描くというのはよく以前から行っていて、そこにユーザが繋がっていたり、コンピュータがぶら下がっているという表現をプレゼンテーションで行ってきたことに由来する。

しかし、その意味には、雲を分割しても、雲、雲と雲をくっつけると大きな雲になるというフラクタル的な意味を込めていたと思うのだが、今のクラウドという言葉では、雲の中になにかわからないけれども何でもある、というような感じのちょっと違う方向になっているような気がする。

さて、そのクラウド、あるいはクラウドコンピューティングだが、従来 ASP (Application Service Provider) とか、SaaS (Software as a Service) というものと、コンピューティングリソースを、オンデマンドで提供するホスティング型のサービスとを取り込んで増殖していると思われるのだが、その大きなメリットというのが、普及してきた高速のインターネットを経由して、雲の中にあるさまざまなリソースを利用して、機能を実現するということだ。

手元には単純なブラウザ機能だけを配置し、ソフトウエアもデータも、ネットワークを介して使うことで、データの保全も、コンピュータやソフトウエアのメンテナンスも手放して、サービスとして提供を受けるという方向性だ。

こうした方向性は、グラフィでもCMSを提供し、情報共有をCMSをベースとして管理し、編集し、交換することを目指して行ってきていることだ。

このシステムを利用するときに問題になるのは、クラウド側に配置する機能やリソースと、こちら側の手元に配置するリソースの配分である。またネットワークの構成やネットワークそのものの構築も問題になるだろう。

インターネットは、ネットワークを介して、接続するノードは対等であり、ネットワークはデータグラムを中継するのみで、そこに接続されているノードの機能によってさまざまなサービスを提供するというのが根本的な思想である。

しかし、現実はそう簡単ではなく、こうして運用されるのは、バックボーンネットワークに近い、ごく一部のネットワークであって、セキュリティや運用管理の点で、末端までこうしたネットワークが運用されているケースは少ない。

かつて、インターネットで電子メールやWebサーバを運用するには、組織としてそのサーバを運用する必要があったので、なかなか大変だったが、ホスティングサービスの普及で自ら、ハードウエアを購入して設置する必要はなくなり、Goole Apps などの登場により、OS レベルのオペレーションも必要なくなり、普通のアプリケーション操作のレベルでインターネットの基本的なサービスをブラウザが動いていれば利用できるようになった。

これを、業務アプリケーションにまで広げたのが、Salesforce.com などのサービスであり、クラウドコンピューティングの一つの方向性である。

従来の、サーバとパッケージソフトを購入して行わなければできなかったことが、サービス料金を支払えば、ニーズにあったサービスが得られるということで、小規模の事業者、プロジェクトには非常に有利であり、かつ導入のために必要となる時間を大幅に短縮できるというメリットがある。しかし、一定以上の規模となると表面的な価格としては劇的な低下は起こらない。それよりも価格が上昇することもある。しかし、これには継続的な運用コストを含んでいるので、自組織で抱えていた対応する運用コストを移転しなければ、コストメリットを適切に評価することはできない。こうしたサービスは、冗長化、高可用化が十分に図られており、データのバックアップやシステムのバックアップを自ら行う必要がないという大きなメリットがある。全体としては、集約的な運用による効果と、この自ら行うにはコスト的に困難であったバックアップ体制のコストを考えると長期的に確実に有利になる。

この種のサービスでは、顧客ごとに専用のクライアントソフトを提供するということはよほどでなければ行うことはなく、基本的に Web ブラウザ経由でユーザインターフェースを提供する。

クラウド的なサービスを考えていく上で、ユーザインターフェースのあり方は重要なポイントになっていくだろう。Web ブラウザで操作するというレベルのものであれば、そう大きな問題ではないが、ネットワークというものがもたらすサービスはそれだけにとどまるものではないし、とどまるべきではない。

この問題で思い出されるのが、電話の高度化として考えられた、B-ISDN 計画である。現実には、一部 INS ネットとしてサービスが提供されただけで、その後のインターネット時代の到来で、インターネットへのアクセス手段としての高速回線の役割だけを担わされることになってしまったものであるが、実際には電話網としての交換網を高度化することで、通信サービスを提供しようというものであった。電話という仕組みは、端末（電話機）側には、通信先や通信内容を判別する機能はほとんど持たず、交換網側がそれを提供することを基本とするものである。実際にはこうした研究開発の成果は、現在のインターネット技術の中にとりこまれて実現しているものもある。

さて、インターネットの技術は、LAN間接続の技術をベースにして、それこそ雲と雲をくっつければ大きな雲になるという代物である。しかし、クラウドの方向性はそうではなく、クラウドの中にすべての機能を共通して集約し、ユーザ側にはシンプルなネットワークとターミナル（ブラウザ、PC、PDAなど）を配置してユーザインターフェースと一部の補完的機能を提供するのみである。

あえて電話に戻って電話サービスを考えてみる。多くの企業では、内線網というのを持っている。小規模な場合、ビジネスホンと呼ばれる、交換機と多ボタン型の電話機を組み合わせたシステムだったりする。この背景には、電話の料金体系の問題もあるのだが、これをクラウド化することを考えてみる。個々の組織は内線交換機を持たず、電話事業者によって集約される。利用者側はすべての電話回線は電話事業者に収容されている。内線通話というのは、同一の契約者間の通話あるいは、収容局での折り返し通話である。料金のことは後で考えるとして、このときのユーザインターフェースの違いは、番号の長さだけである。内線で桁数の少なかったものが、7から8桁になるわけだ。それ以外には全く変わりはない。

さて料金は問題どうなるかというと、各回線ごとに基本料金がかかる。通話ごとに最悪市内通話料金がかかる。しかし、交換機は持たない。最近は携帯電話が圧倒的な普及をしているわけだが、携帯電話サービスでは何が起こっているだろうか？同一法人契約の場合、通話料無料だったり、個人では家族間通話は無料だったりする。電話番号のユーザインターフェースはどうか？携帯電話ではメモリの機能が充実していて、電話番号は記録されいてよく通話する相手は、これを呼び出してボタンを押すだけだ。固定電話でも家庭用の電話機では、いまやメモリが充実している機種も多く、携帯電話と変わらないこともできる。

携帯電話に内線という概念はそもそもないが、通話料無料であれば利便性を考えればそちらを使うことが多く、単身者の場合、いまや固定電話を家に引かない人も増えているといわれている。

ネットワークは社内にサーバがあって、そこで情報を共有したり管理しているので、社内LANを構築し、ゲートウエイ、ファイアウォールを設置して、インターネットに接続し、電話は内線交換機を設置して、内線網を構築し。。。。。

あれ？サーバはクラウドサービスを利用していて、社内にはないので、社内ネットワークは必要ないし、どこからでもインターネットを使って仕事はできますよ。

さて、こうしてサービスを利用すると自ら設備を持たなくて済むようになることは明らかだ。あえて電話を例に出したのは、コンピュータやコンピュータネットワークのほうは、まだマーケットや仕組みが確立しているとはいえないので、その利用形態を変革するのは比較的簡単だと思われる。しかし、電話はもっとも確立しているものの一つなので、これを変革するのは、料金体系から、予算の執行から大変なことだろう。

しかし、電話も携帯電話も全部ネットワークサービスで、いずれは多くの部分を共用するサービスとして統合されていくことは必然で、クラウドへの流れが避けられないとすれば考えを変えなければならないだろう。

クラウド的な考え方は、おそらく通信サービスだけにとどまらず、経済、社会の仕組みに大きな影響を与えていくだろう。お金の使い方に影響を与えはじめていることは疑いはない。

せっかく政権交代が起こったのだから、個別のサービスとして利用するだけでなく、予算の執行のありかた自体にもクラウド的な発想を取り入れてくれると効率よくなると思うのだが。

最終更新日: $Date: 2010-01-11 11:32:26+09 $

大学のネットワーク

今月から、東京大学大学院総合文化研究科情報ネットワークアドバイザー という肩書をいただいた。

大学院総合文化研究科というのは、分かりにくいのだが、教養学部の教官の所属で、実際には教養学部すなわち駒場キャンパスの情報ネットワークに関するアドバイザという立場である。

私は、1982年から1995年まで、教養学部に助手（当時は、文部教官助手、現在では助教にあたる）として在籍した。その間、教育用計算機センターのシステム更新と、教養学部へのセンターの設置、学内ネットワーク（UTnet）の建設などをお手伝いした。

1984年に JUNET の実験が始まり、WIDE Project の開始が 1986年であるので、ちょうど日本のインターネットの草創期であり、私はこの仕事をしたあと、東大を辞めて、日本でのインターネットプロバイダの草分けである IIJ (インターネットイニシアティブ）の立ち上げに加わった。

そういう時期に作られたのが東大の学内ネットワークの原形であり、インターネットは大学にしかなかった。大学のネットワークとそれを結んだ日本のネットワークこそがインターネットの原形であった。

さて、そういう時期にできた東大の学内ネットワークは最先端のものであり、私たちがオペレーションしていた最高のネットワークであった。もちろんその時期としてはである。大学の学内ネットワークは当時は大学にしかこの種のネットワークがなかったということもあるが、大学内のコンピュータ資源を共有する環境として整備することが基本的な目的である。

その後も東大のネットワークは数年ごとに更新され、現在もそれなりに規模と機能を持っているが、基本路線は同じだし、物理的なネットワークを自営で建設するので、トポロジーもそう大きく変わっていない。

しかし、この間に大学の外、すなわち一般社会でおこったインターネットの普及と利用の変化は比べ物にならないほど大きなものであり、大学でのネットワーク利用など特別なものではないものとなってしまった。

むろん、大学では依然ネットワークの研究に携わる人々や、ネットワークを活用して研究を行っている人は多く、超高速、高性能のネットワークが必要とされている。しかし、それ以上に社会インフラとして成長したインターネットは、日々の業務から教育からなにからなにまで使われ、必要とされるものとなっている。

全ての大学人、学生にとって、欠くべからざるものになったインターネットは、私たちが作って動かした学内ネットワークとは期待されているものが大きく異なってきていると思われる。

理学部や、法学部など専門学部では、ある程度ネットワーク利用に対する意識がそろっていると思われるが、東大教養学部というところは、1，2年生が全員在籍するいわゆる他大学でいうところの教養課程の役割を独立して担っており、全ての分野の教官が先ほどの大学院組織として在籍している他、非常に多くの非常勤講師の先生方がかかわっている。

今回私がお手伝いをすることになったのは、こうしたネットワークのユーザのサポートが追いつかないので、何かよい手立てはないかということであった。それだけ、ネットワークが多くの人にさまざまな形で欠くべからざるものとなっている証拠である。

私は、かねてより日本のインターネットの運用は世界最高水準であると言っているが、大きな発展を支えてきたいわゆるプロバイダは優れた運用を行っている。こうしたプロバイダにサポートの部分だけを手伝ってもらうという手がなくはないが、現に運用しているプロバイダのネットワーク設備と、大学のネットワーク設備ではエンドユーザをサポートするとい観点においては大きな差がある。

現在のインターネットでは、さまざまな脅威が存在している。コンピュータウイルス、不正アクセス、DDos 攻撃、スパムメール等々。プロバイダはこうした問題に対して対策するための監視、管理機器を導入したネットワークを構築している。これに対して、大学のネットワーク、特に東大などのネットワークでは完全に透過的なネットワークをサービスするということが、やはり基本にあり、こうした問題に手厚く対応するということは行っていない。研究用のネットワークであり、あくまでこうした問題に対して対応するのはユーザの個々の事情において行うべきというのは、当然であるのだが、問題は件の教養学部のユーザ層と、サポート体制である。

それなら、一層のこと学内のネットワークを一般の家庭等と同じようにプロバイダのサービスを直接持ち込んでしまうという考え方はできないだろうかと思っている。むろん、研究用のネットワークが必要な研究者は現状のネットワークを使えばよい。

このやりかたをすると、メリットがたくさん生まれる。大学には、共同した研究であったり、学会、会議などで外部から来訪する方も多い。こうした人々も今の時代どこでもインターネットを使いたいと思うのは当然である。しかし、現実はこうした人々にネットワークコネクティビティをサポートするだけで、数名のスタッフが完全に忙殺されているというのが事実となっている。ならば、一般のプロバイダ、無線LANのホットスポット同様に学内でインターネットを利用できる環境が提供されていれば、そのために特別なサポートをする必要がなくなる。

いまや、学生は入学してからインターネットを使い始めるのではなく、入学前からインターネットは使っているし、役立てている。これも同様に自分が自宅で使っているのと同じようにラップトップや、PDAで使うことができるようになる。

大学がインターネット環境が一段優れているという時代ではなく、いまやどこででもインターネット環境を求めることができるにもかかわらず、大学内は特別なネットワークが作られている。専門的研究機関であるなら、それは別にして、駒場キャンパスのネットワークはそうした一般のインターネットプロバイダの提供する環境をみんなが求めることができるほうが望ましいのではないかと考えているわけである。

今後、さまざまな調査を行い、実現の可能性を探っていくことになる。これが私の肩書のわけである。

最終更新日: $Date: 2009-11-09 16:17:55+09 $

ネットワークアプリケーションの将来は？

Webの仕組みは、非常にシンプルである。シンプルだからこそ、ここまで普及したのだと思う。原則的には、html をブラウザが解釈することと、それを表示することだけである。どこからその html を持ってくるかを指示するのが URL である。URL は、転送プロトコルと、所在情報の組み合わせでできていて、もちろん指示するリソースは、html とは限らないが、ブラウザにデザインされた表示を行うのは html で書かれたページである。

ブラウザは、html を解釈して表示する。html の中にはページを構成する要素となる素材が指示されているので、それをさらに取得してページを構成する。取得すべき情報は html 中にその方法が URLの形で埋め込まれている。最近は javascript を活用してより複雑な、インタラクティブな要素を含んだページを構成することができるが、本質は同じである。

URLには、あるものを全部くださいというような乱暴な指示はない。知らないものは持ってこられないし、サーバ側も渡さない。サーバの中にあるものが全部見えてしまうような設定をすることはできるが、特に意図してそういう設定をするときはともかくとして、Webシステムの意図する使いかたではないと思う。仮にサーバ側には、入っていて、転送可能であっても、正確な名前が分からない限り、それを取得することはできない。これは、Web は見せたいものだけを見せるという立場で作られているからである。

これに対して、従来のコンピュータの操作では、そこにあるものを全部表示するとか、ある文字列を含むファイルだけをコピーするという操作を行うということをキーボードからコマンドを叩いて行うということが多いし、ファイルの一覧表を見るコマンドは基本中の基本だ。

ところが、最近の Windows などのユーザインターフェースでは、ブラウザを介してファイルの操作を行うほうが一般的になってきたので、どちらも変わらなくなってきている。Windows ではどちらも「エクスプローラ」という名前である。この場合のブラウザの機能は、あるものを全部見たり、スクリーニングしたり、探したりするものだ。

このように、ユーザが情報を管理するという点だけでは、ネットワークのあちらとこちらにすでにあまり区別がない。むしろ見せたいものとそうでないもの、自分だけが見えるものという区別だったり、保持している場所によって、使えるアプリケーションが異なることだったり、大量のデータをコピーしたり移動したりするのには、ネットワークが遅いことだろう。広域ネットワークも高速化しているが、扱うデータ量もそれ以上に増大している。

現在、よく耳にする技術がクラウドコンピューティングである。この言葉はもともとは広く分散処理技術を統合、発展する概念であったと思われるのだが、現在、市場で使われている意味は、現在の SaaS 等の概念をさらに進めたもので、高度化されたブラウザの向こう側にすべての情報を預けてしまうというものである。ディスクや、CPU リソースをもサービスとして買うという方式の発展形である。Google のアプリケーション提供の形態はこれに近づいている。

複数の事業者間であっても、アプリケーションが動作するコンピュータと、データ（情報）を保持しているサーバはネットワークで接続されている。アプリケーションが加工すべき情報の所在を xml などで指示し、適切な認証情報をやりとりしアクセスする。こうしたことができれば理想的だろう。おそらくこのような方式は確実に進歩、発展していくだろう。

しかし、現実には広域ネットワークは遅い。これが将来解決するかといえばちょっと厳しいだろう。コンピュータの内部や、LAN の速度は非常に高速であり、これは、コンピュータシステムの性能を支える本質的な部分でもあるので、高速化はまだ進むだろう。また高速な処理を必要とする CPU リソースをサーバ側に全部依存するというのは現実的とも思えない。手元で発生する画像、映像、音声などの処理と入出力を考えると、こちら側のワークステーションが全部なくなるとは思えない。

それに、Google アプリケーションのようなオンラインアプリケーションに過度に依存するとネットワークがつながってないと何もできないという事態にもなるので、特に編集型のアプリケーションは手元のほうが望ましいだろう。非同期的な作業を可能にする余地は残しておくべきだと思う。手元で動作するアプリケーションにサーバとの情報のアップロード・ダウンロードを支援するプラグインを用意するのが一つの解法ではないかと思う。

ビジネスとしてSaaS型のサービスを提供している事業者はさまざまな理由ですべてブラウザの向こうで作業することを勧めている。もちろん運用上のコスト面などさまざまな理由でそれが望ましいこともある。これは、それぞれの利用環境に応じて使いわければよいだろう。

それでも、インターネットにつながっているサーバ上に情報が蓄積していく方向性には間違いない。

そうなると、サーバ上には、見せたいものと見せたくないものがあって、見せたいものだけを見せたいように Web として見せるというのができれば一番いいわけである。業務型 SaaSアプリケーションのアウトプットの中にも見せたいものもあるかもしれない。

我々はここに注目して、グラフィCMSの機能の開発を行っている。まず、ここで、必要となるのが、見せたいものをどう指示、表現するかの記述性と操作性である。グラフィCMSは、まずグループ内での共有ツールとして、通常のディレクトリ構造同様の情報保持機能を有している。

この上に、現在のところ、Wiki 型の簡易記法の拡張として、コンベンショナルな記述方法によって表現を実現している。Image の指定や、他の文書の Include の記述に、一般的なワイルドカードの記法を採用している。今後、メディアブラウザからのスクリーニング機能を強化していく方針である。

そして、公開機能によって、任意のサブツリーを Web サイトに仕立てることを実装しており、見せたいものだけ選択的に見せるようにするという方式を実現したのである。従来の Web は、場所が先に決められている。これは、アドレスや DNS が別の管理として存在しているためで、DNSに登録された名前と、あるサーバの特定のディレクトリがサイトになる。グラフィCMSではこの設定管理を自動化することで、先に作った情報に、あとからサイト名を自由に付けられるようにした。この機能によって、情報流通に自由度を与えたと思う。

最終更新日: $Date: 2008-12-14 22:56:27+09 $

ネットワークアプリケーションの将来は？

それでも、インターネットにつながっているサーバ上に情報が蓄積していく方向性には間違いない。

最終更新日: $Date: 2008-12-14 22:56:27+09 $

つながることとつながらないこと

Ubiquitous という言葉が数年前から使われるようになった。

Ubiquitous の語源はラテン語で、いたるところに存在する（遍在）という意味である。

現在この言葉は、「いつでも、どこでも、インターネットなどの情報ネットワークにアクセスできる環境」を指すものとして使われる。

Ubiquitous computing は、メインフレーム(複数で一台を使用)、PC(一人一台)、に続く、一人が複数のコンピュータを使う第3世代を示したもので、マーク・ワイザー氏が提唱した。

確かに自分自身ずっとこういう仕事をしてきているので、自分の使うネットワーク環境の整備も行ってきている。オフィス、自宅はもちろんのこと、出先でも携帯電話やPHSを使ってなんとか接続するということを行ってきた。最近はホテルでもインターネットサービスは一般的になったし、公衆無線LANが利用できる場所も増えた。いつでもどこでもネットワークに接続できる環境が整ってきた。

この数日、テレビで「携帯依存」という話題が取り上げられている。これは、携帯電話をいつも持ち歩き、メールと電話で連絡を取り合いながら生活していて、携帯電話がないと不安になるという精神状態から始まり、さらにそれが高じて、携帯電話で提供されるさまざまなネットサービスに過剰にはまり込み、挙句の果てにその中の有害なサービスの被害に会うということで社会問題化しつつある。特に子どもがそうした有害サービスにアクセスし、巻き込まれることが大きな問題になっている。

情報ネットワーク技術はあらゆる分野に浸透し、生活を便利にしてきたことも確かである。産業もこの技術によって大きく発展してきた。この技術のおかげで間違いなく、変化は早く、激しく起こるようになっただろう。あふれる情報の中で生きていると、その情報から途絶することは大きな不安を感じる。経済活動はそういうものだからやむをえないといってしまえばそれまでだ。しかし、間違いなく、この中でストレスは増大しているだろう。最近の経済危機は、金融問題に始まり、実体経済に確実に波及しつつある。情報に一喜一憂し、株価は乱高下している。

たしかに情報ネットワークが途絶すると、デマやうわさが飛び交うようになり、これはよくない。災害時の正確な情報伝達は重要な課題だ。災害時にこうしたサービスをいきなり使えといっても使えるものではないので、平常時からそれに慣れておく必要がある。私も荒川コミュニティネットのプロジェクトでは、平常時の利用の促進、コンテンツの充実を訴えてきた。これは訓練が必要ということであって、依存を求めているものではない。

依存というより、中毒の問題は別の原因があるのではないだろうか？

さて、つながることで便利なことを考えるには、つながってなくてもできることやつながらないときにどうするかをもう少し考えてもいいのではないかと思っている。「そんなことをわざわざネットにつながなくても。。。」ということである。これは中毒のことにも関係するかもしれないが、つながらないときの工夫を、もっとちゃんと考えてもいいと思う。

ネットワークにつながれば簡単に問題を解決できる。しかし、そうしなくても手元にちゃんとそれなりの能力とリソースが存在している。まず先にそれを活用することを考えてもいいのではないだろうか？そして、手元のリソース、能力、アプリケーションとの連携をもっと積極的に考えることで、もっとネットワークサービスは充実するはずだ。つながっていないとなにもできないというサービスの構築方法は、決して望ましいものではないだろう。つながっていないとできないものは最小限にとどめる必要がある。

それこそが、本来の分散コンピューティングのあるべき姿ではないだろうか？

最終更新日: $Date: 2008-11-24 09:19:13+09 $

ドメイン名雑感

今日の日経のニュースに、2009年夏に、TLD (Top Level Domain) として、”.日本” を総務省が認めるという記事があった。その中に、現在 .jp　を日本レジストリーサービスが管理などの業務を一括しており、業務の開放を求める意見も出ていた、というくだりがあった。

日本のインターネットは最初、.junet から始まった。実験ネットワークのJUNETである。この時期まだ、DNS (Domain Name System)の運用はまともには行われていなかった。電子メールのアドレスとして、階層的ドメインの概念が導入されはじめていたが、電子メールの配送は、静的なルールセットを用いたもので、電子メール配送システム自身の設定ファイル (sendmail.cf など）に直接記述されていた。

いわゆる IP ネットワークが整備されるようになり、日本も接続するという段階になって、ISO3166の2文字の国コードを、TLDにする DNS を運用するという方向になり、日本も、.junet から、.ac.jp, .co.jp, .go.jp, .ad.jp というドメイン名に移行した。このときに属性をあらわす2文字を入れるということになった。国際的にもこのような属性を示す文字列を第二レベル (SLD) に入れることは多いのだが、日本の場合、これは同じ5文字にするためだったという裏話もあったりする（これは完全に余談だが）。電子メールアドレスは、イギリスではまったく逆順に書いていて、user@uk.ac.college というのを使っていたこともある。

さてドメイン名の割当は日本では、属性の上の第三レベルの割当ということだったわけだが、JUNETの時代から、JNIC が創設されるまで、junet-admin という管理者グループが長く独占的に行っていた。研究グループのボランタリな活動だったのと、ドメイン名に対する独特の意識があったので、結構うるさいことを言っていた時代がある。3文字はいけないとか、なぜそのドメイン名にするのか理由を述べよとかやっていた。この時代には、よく知られた企業でアルファベット三文字の略称を持っているところでも、結構揉めた。

その後、ドメイン名取得のニーズが増えたこともあり、JNIC の創設によって、明確なルール化が行われ、割当はスムーズに行われるようになった。その後、JPNIC に引き継がれていった。インターネットの発展と WWW の急速な流行は、電子メールアドレスが主目的であった、ドメイン名の使い方を変えていった。

名前としての意味合いが非常に強くなり、紛争も起こるようになった。アメリカでは、ドメイン名の売買が行われ、高値での取引事例も生まれた。紛争の処理ルールも作られた。社団法人としての JPNIC では、その作業量が多くなりすぎて、処理できなくなったことや、.com, .net などの TLD は、日本のルールよりゆるく、割当が民間に委託されて取りやすくなり、日本でもこれらの TLD を使う企業が増えてきていた。しかし、トラブルも多く、取るのは簡単だが、なにか起こるとどうしていいか分からないということがかなり頻発した。

そこで、日本でもより、取りやすいドメイン名としての、汎用 JP ドメインのアイディアが持ち上がり、それを含めて、ドメインの管理運用組織としての、JPRS (日本レジストリサービス）が創設された。JPNIC も出資する株式会社組織として誕生した。これは、需要に変化に機敏に対応して、資金調達も柔軟にできるようにと、民間企業として設立された。

汎用 .jp ドメインは、不足しているニーズを補う形で、増え続け、100万ドメインを突破した。しかし、TLD 間の国際競争ということもあり、より安価に利用できる TLD もたくさん登場した。ISO3166 の国コード (行政区画または地域に割り当てられる、ISO3166-2を含む）を使うものが、ccTLD、それ以外の .com, .net, 新しいのでは、.info などもあるが、これらの国をあらわさないのが、gTLD と呼ばれる。

ccTLD の中でも、.tv (ツバル) など、その地域で使われるのではなく、テレビジョンの意味に流用しているものもある。本来使うべき地域との関係はさまざまで、企業が買い取っているようなケースもあるようだ。

さて、こうやってドメイン名のニーズは大きくなってきていて、最近の Web では、半ば使い捨てのように利用されるものもある。どのドメイン名でも一定の維持費を払う必要があり、払わなければ抹消されるだけなので、それまでだといえばかまわないのだが、やはり業者によっては、取るのはやさしく、そのセットのまま使うにはいいのだが、ちょっと変更したいというときには、分からないとか、仲介した業者がつぶれてしまったとかで、大切な名前として使っているのに困ったという相談は後を絶たない。

ドメイン名は、原則早いもの勝ちなので、すでに取られていると同じものは取れない。これを取得に要する費用との兼ね合いでどうも市場が形成されていると思われる。もう一つは、ドメイン名は、WWW のために使うのが主で、メールアドレスには使われる量は非常に少なくなったということもある。そのため使い捨て感覚なのである。それと、できるだけ短い名前を使いたいという希望は、依然として非常に大きいようだ。

さて、.jp は、JPRS が独占的に扱っているので、けしからんというのが冒頭のニュースの意味の中に含まれているのだろう。別に、”.日本” もただの文字列なので、使いたい人が使えばいいだろう。.jpn という TLD も誰か割当をするというニュースがあったようだが、今はどうなったのだろう。

まあ、エッチティティーピーコロンスラッシュスラッシュダブリュダブリュダブリュ…というのもアナウンサーの皆さんも慣れたみたいだけれど、さらに読みやすい短い名前が欲しいのだろう。

しかし、おそらく技術の進歩は、わずらわしいものの存在を消し去っていく方向にすすむだろうから、使い捨てドメイン名はシステム的（特に DNS）な合理性から考えれば、消え行く方向にあるものだと思う。検索ですべて解決するわけではないとは思うが、エッチティティーピーコロンスラッシュスラッシュダブリュダブリュダブリュ…というのを読み上げるのは、もうしばらくの辛抱ではないだろうか。

最終更新日: $Date: 2008-11-03 14:09:47+09 $

ネットワークの距離

昨日、CSI (中四国インターネット協議会）のFinalシンポジウムに行ってきた。

JNICの発足などの日本のインターネットの黎明期の中で、早い時期に活動を開始した地域ネットワークプロジェクトである。私も初期には、何回か講師を務めた。約15年前のビデオなども紹介され、さすがに若かったなあと、懐かしく思った。

今回、15年間の活動にピリオドを打つわけだが、記念のシンポジウムで、札幌医科大学の辰巳さんが、話をした。彼が医療におけるインターネットやITの活用を本当にこの15年ずっと続けている人で、北海道の地域ネットワークプロジェクトの NORTH の中心人物でもある。

講演の主題は、医療関連の話なのだが、久しぶりにこの話を聞いた。

「数百メートルしか離れていない別の病院との間の通信でも、東京を経由するので、遅い」

というやつである。

同じ ISP につながっていれば、同一都道府県内あるいは、悪くても関東、東北、北海道といった地域内の POP で折り返して、通信が行われるので、最近のBフレッツだと往復で遅延が 10ミリ秒程度で収まっている。しかし、これが異なる ISP に加入している場合、東京でしか相互接続していないので、北海道の場合、往復で約2000Km で、50～70ミリ秒かかるのではないかと思われる。まあ、昔にくらべればネットワークが高速になっているので、たいしたことないといえばそれまでだが、より高速な通信を必要とするアプリケーションでは、この程度の遅延でも、不便なことは起こりうる。

現在、ISP間の相互接続は、主に東京と大阪で行われている。それ以外での接続は非常にすくない。そのためこういうことが起こるのである。P2Pトラフィックが異なる ISP 間で行われるとき、相互接続点にかかる負荷が非常に大きくなるというのも、P2Pが嫌われる問題の一つである。

これは、たとえ同じ NTT のBフレッツを使っていても、一旦それぞれの ISP のバックボーンネットワークに集められて、そこから別の ISP への接続される。隣の家との間であっても、別の ISP であれば、1000Km　以上の距離があることになるということが起こる。通常のフレッツのサービス形態である。

これを解消するために、地域 IX を各地域ネットワークが中心となって推進した時代があった。もっとネットワークが細い時代には遅いという問題は深刻だった。しかし、実際には、全体のトラフィックという点では、一般の利用は、東京のデータセンターにあるサーバを見に行くトラフィックや、海外へのトラフィックが支配的であるため、ISPの経営的に見た場合、成り立たないということになり、結局実現しなかった。

しかし、ここで問題なのは、結局、同じ ISP であれば、フレッツだと、少なくとも各都道府県内の POP で折りかえすということである。なので、隣の病院が同じ ISP に加入すれば問題ない。

さて、NTTの Bフレッツを利用している人は多いと思われるが、ISP はばらばらだろう。ところが、現在 Bフレッツについては、IPv6が利用できるようになっている。この IPv6は NTT 東日本はその域内のみ (NTT東日本は、ドットネットの契約が必要なことがある）で、NTT西日本もその域内のみで、この両者も相互には接続されてはいない。

しかし、加入者同士の間は IPv6での通信が、ISP とは無関係にできる。それに、IPv4のように PPPoE などのトンネルをすることもなく、いわばネイティブな(自然な） IPv6のネットワークなので、隣は本当に隣で最短のルータで折りかえす。実はこういうネットワークがすでに運用されているのである。これは、その筋ではよくしられた事実であり、知っている人は、拠点間の接続にこれを利用している。専用線に比べて圧倒的に安価であり、VPN に比べてパフォーマンスが高い。

同じことは、PPPoE を採用してはいないヤフーBBでは、やはり同じヤフーBBの中では最短で通信できる（セキュリティ面の問題で加入者同士の通信を禁止している場合を除く）。

ネットワークにはこうした特性、問題点があるので、相互に通信をしたい場合には同じ事業者を選択する（これをネットワークの外部性と言う）ということになる。インターネットはつながっているからまだいいようなもので、それ以外のネットワークサービスではそもそもつながらないので、同じ事業者サービスを利用せざるを得ない。

こういう事実が存在するが、現実には、全体としては加入者同士の通信量は非常に少ないので、民間企業ISPでは、経済性から考えるとそういう運用、構築形態を優先することはない。結局、自分で運用して、隣との間に直接線を引いてくださいということになる。

BフレッツのIPv6では、すでにこういう世界が実現しつつあるので、これを相互接続して欲しいという要望はあるのだが、他の要素が十分に優先するというのが現実である。

最終更新日: $Date: 2008-10-25 09:54:21+09 $

Poorman’s Technology

文字通り訳すと、「貧乏人の技術」なのだが、意味は、サービスとして提供してもらうのではなく、（内緒で、）安い素材を使っても、高い機能を実現する、という感じの意味合いである。

トンネリングや、VPNなどでキャリアに全く設定をしてもらうことなく、end-to-end の機材の設定だけで実現してしまうというものを我々は自虐的にこういう呼び方をしている。

お大尽は専用線を張ることができるところを、ISDNを使ったり、ADSLやフレッツ網を使ったり、インターネットのコネクティビティがあるところならなんでも利用して、別のネットワーク間接続を行ったりするという感じだろう。

もちろん、この種のことは、何のトラフィックがそこを流れているかわからなくなるので、セキュリティ的な面からは嫌われ者になる。そのため、ちゃんと管理することが必要なネットワークでは、End-to-end で、安易にこういうことをしないで、サービスを受けたほうがいい。あとで、訳のわからない接続が出てきて、混乱して、それに対するトラブルシューティングをすることで、大変な思いをすることになりかねず、高くつくことになりかねない。

また、バックドアセキュリティホールになる危険性も持っているので十分気をつけるべきである。SSL-VPN などで社内ネットワークへのアクセスを行っているケースも未だに多いようだが、不用意な設定をしてしまうと、ウイルスに感染したパソコンをつながれて、壊滅的な事態になることも起こりうる。

今や、セキュリティに対する考え方は、こうしたアドレス空間を基本にしたファイアウォール型の外と内の区別というやり方は、よい方策ではないと思う。

ネットワークリソース、サーバリソース、情報リソースそれぞれをグループ化して、ぞれぞれの利用についての資格や権限を管理し、相互にアクセスする場合の認証方式と権限管理を慎重に検討するほうが、望ましいと思われる。そうしたことを実現できる技術は十分に整っていると思われる。

最終更新日: $Date: 2008-10-23 15:25:41+09 $

コンピュータネットワークとは

コンピュータネットワークというものは、ネットワークだけではありません。この場合のネットワークとは、通信回線と中継装置から構成されるものを指します。

デジタルネットワークにおいては、中継装置上のメモリにおいて、書込みと読み出し、すなわちコピーが行われますので、複製が可能です。しかし、これはアナログネットワークにおける電気的増幅の変わりをするものであって、応用事例としてのコンピュータネットワークにおいて行われる蓄積交換とは異なります。

ネットワークの古典的なアプリケーションは電話です。もっぱら同時に通話できることが最大の特徴です。一般的にネットワークの概念は同時性（リアルタイム性）を追求するものです。放送ネットワークにおいても、生中継を実現することが非常に大きなミッションです。

さて、われわれが提供しているのは、これではなく、コンピュータネットワークシステムです。通信回線を経由してコンピュータ同士を接続したことによって生まれるシステムであって、「ネットワーク」ではないのです。

電子メールは、コンピュータネットワークのもっとも古いアプリケーションですが、メールはコンピュータ上に記録（記憶）されており、それを非同期的に読み出すことでコミュニケーションを実現しています。同時性を追求するものではないのです。

そのため、コンピュータネットワークはネットワークの持つ空間超越性のほかに、非同期的時間超越性を持っています。すなわち、記録して保存しておくことで過去にアクセスすることができるわけです。これが時間的超越性です。ネットワークが時間を超えるという言い方をすることがありますが、これは遠方にいる相手が移動することなくコミュニケーションをはかることができるという移動時間の省略であって、過去の自身にアクセスするということとは本質的に異なります。

そして、記録は記憶へとつながり知識に発展します。

同時ではないことは、デメリットでしょうか？現在の我々は同時であることを強要されすぎていると考えるべきです。ネットワークの速度が遅い時代、極端にいえば電気通信がなかった時代を考えてみてください。通信手段は書状の配送、あるいは伝言がもっとも早いもので、その手段の中には、編集と想像が含まれています。時間的な制約を意識してコミュニケーションをすることで、時間を有効に使う行動、思考をします。そしてそこから創造につながることがあります。

非同期的コミュニケーションのメリットは、発信者、受信者側、あるいは中継者がそれぞれ情報に編集を加えるということです。現在のコンピュータネットワークにおいては、それが改ざんにつながるということを避ける技術が存在していますから、恣意的な情報操作を意味するものではありません。

過去の情報を積み重ねていく過程で必ず編集が起こります。編集とは、簡単に言えば、情報にメリハリをつけることです。もちろん編集者の意図がそこにあらわれることもありますが、それだけではないでしょう。

ただ情報が集まっていることだけでも無価値であるとはいえませんが、では検索はそこに十分な解決を与えるのでしょうか？検索で、求めるものを発見することは、実は非常に知的な作業です。逆に言えば、そのコンテンツで訴求するものがはっきりしていなければ、見出されることもありませんし、知識に到達することはできません。

コンピュータネットワーク技術が知の創造につながるのは、この時間の経過とともに編集作業を加えながら蓄積していくことに他ならないでしょう。難しいことではありません。これが二者のやりとりであっても実際に起こることを経験している人は少なくないと思います。

最終更新日: $Date: 2008-12-08 09:28:32+09 $

IPアドレスの割当

IPアドレスが枯渇する。IPv6へ移行しなければならない。

と言っているのだが、どういうわけか一向に進まない。危機感があるようには思えない。なぜなんだろうか。

IPアドレスの不足が声高に言われるようになり、アドレスの割り当てが異常に厳しくなったため、アドレスを節約する技術もたくさん生まれた。アドレスを接続の都度、割り当てる方法、内部のプライベートアドレスをゲートウエイの1つのアドレスに対して読み替える方法などである。

割り当ての方針はどうなっているかというと、実は私も、JPNIC発足初期にIPアドレス割当の担当の委員会の委員長を１年間していたことがある。IPアドレスの割り当ては、新規に割り当てを受けようと思うものには非常に厳しい。私の時には、必要なものには割り当てられるように、しかし、無駄が出ないようにということで、原則小さいブロックを割り当てる。この場合には特に審査をしない。これを使い切ったら、次を割り当てる。ユーザが不便を被らないように、最初の割り当て時には、一定期間、となりのブロックを開けておき、すぐに使いきったときには、連続のブロックを割り当てるようにする。というような単純なルールを設けた。

現在は、小さいブロックは接続を実際に行う ISP に割り当てを委任しており、大きなブロックの割り当てを受けた ISP がサブブロックの割り当てを行っている。概ね上記のような方法で行っている。

この方式は、アドレスの割り当ての無駄をなくすだけではなく、経路情報を ISP ごとに集積 (aggregate) できるようにすることも目的である。インターネットの経路情報は、インターネットの発展とともに増え続けている。できれば細かい経路情報を流さずに、集積できれば減らすことができる。この方式の欠点は、接続する ISP を変更するとアドレス変更をしなければならないということである。

ところが、これは JPNIC ができたあとの話で、IPアドレスはその前から割り当てられていた。インターネット発祥のアメリカでは言うまでもない。日本でも、古い割り当てのなごりがある。

133/8 という JAPAN-INETというブロックがある。これは、JPNIC 発足前に割り当てられたもので、前半はおおむね大学に、後半が民間企業に割り当てられている。これは、村井研究室で割り当てを行った時代のものである。これは、現在もほぼ当時の割り当てのままになっている。

43/8 というブロックもあったが、こちらは再割り当てが行われ、ISPのアクセス網用に使われている。ただし、これに関しては IPv6 への移行までの暫定的な割り当てということで割り当てされたが、現に移行は起こっていないので、そのまま使われている。

133/8 の割り当て状況は、JPNIC の whoisデータベースで参照することができる。大学では、すべてのコンピュータがグローバルアドレスである必要があるが、民間企業でそのような運用を行っていることは皆無といってもよく、ISPでユーザ用に割り当てるのでなければ、有効に利用されている部分はごく小数だと考えられる。

それに、10年前ならいざ知らず、現在はPCにアドレスを自動的に割り当てる技術も格段に進歩しており、むしろ、そのような管理をできる機材を用いたほうが、セキュリティ的にも優れていると思われる。こうした機材は、ホテルや、公衆無線LANなどを管理するのに使われていることが多いが、一般企業内で使う場合にも優れた機能が多数備わっている。

アドレスを変えられませんというほうが、技術的に劣っていることを露呈しているようなもので、極端にいえば、内部の一般のネットワーク利用者にはほとんど気づかれることなく、アドレス変更を行い、こうした貴重なアドレスを返上することができるのである。

世界的に、このようなインターネットが世界的なオープンなネットワークになる以前に割り当てられたアドレスの存在があり、そして実はいまの技術水準からすれば、事実上まだ膨大な量、埋蔵されているということになる。

IPv6が不要で、いまのIPv4 で十分という人の主張はこうした部分にある。

経済学者などの中には、こうしたアドレスをオークションで再割り当てすれば、IPv6は不要であるということをいう人もいる。これは経路情報の問題があるので、小さいブロックの再割り当ては、かえって害になる。そうすると大きなブロックが対象になるが、そうしたブロックを昔割り当てをうけたのは、それこそ世界でも名だたる大企業ばかりである。

そうした企業になにも経済的利得を与える必要はない。なぜなら、いまアドレスを必要としている国の多くは途上国であるからだ。

しかしながら、こんなつまらないことで争うより、さっさと IPv6 に移行するほうが得策であるし、経済効果も高いのではないだろうか。2011年にアナログ放送が終了するなら、2012年にIPv4の利用を終了すると宣言してはどうか。きっと、2000年問題同様に、第3次ネットバブルがやってくるのではないだろうか。半分冗談のような話だが今の経済状況とインターネットの重要性を考えたら、最大の景気刺激策になるかもしれない。

最終更新日: $Date: 2008-11-08 00:14:12+09 $

YAMAHA RT-100i誕生秘話

IIJが設立して間もない、オフィスが溜池の現在NTTdocomoのビルの建っている場所にあったときのことだったと思う。たぶん、村井さんがこちらに振ったのだと思うが、ヤマハの方がたずねて見えた。

YAMAHAは、ISDNのコントロールを行うチップセットを持っており、これでプロダクトを作りたいのだが、どんなものがいいかということであった。おそらくいろんな人に相談に回っておられたんだろうと思う。

WIDE Project では、Sun のワークステーションを使い、Sunのシリアル回線用のルータソフトウエアの Sunlink IR を使って、ISDN の 64Kbps での利用を実験していた。しかし一般にはまだ、PPPは普及していなかったので、PCで直接ダイアルアップIP接続を行うということは始まっていなかったと思う。

ヤマハの人は、RS-232Cでは、38400bpsまでなので、64Kbps を使いきれないということで、Ethernet で接続して擬似的にモデムのように見せるような箱はどうかというようなことを言っておられたような気がする。

私は、「普通のルータを作ってください」とお願いした。まあ、実は WIDE でSunを利用して作っていたものは、ヤマハの人も知っていたので、同じ機能を実現することはそんなに難しいことではないという認識だったが、それがニーズがあるかは当時の状況では確信は得られなかったであろう。

数ヵ月後、RT-100i のプロトタイプが出来上がってきた。完成度の点では十分であった。0.1～0.3秒程度で ISDN 回線の接続が確立する。たぶん、ISDN を使っているといわなければ、64Kbps の専用線で接続していると言っても分からないというものだった。外見の大きさは、後に製品となるものとほぼ同じものであった。数台のプロトタイプをお借りして、テストを重ね、ファームウエアのアップデートに協力した。NATや、IPマスカレードの機能も初期から実現していたし、簡単なフィルタリングもでき、「ちゃんとしたルータ」として完成してきた。

さて、ちょうど IIJ 東海のオープニングのために、名古屋を訪れていたときに、ヤマハの方も来ていた。そこで、どう販売するのかという話になったら、ネットワーク機器ベンダーから OEM販売するという計画を聞いた。なんで YAMAHAブランドで出さないのか、となんであんなに熱くなったのかと思うくらい熱弁をふるった。YAMAHAのブランドは、楽器やバイクなど非常にイメージがよく、ネットワーク、コンピュータでは実績はないが、候補になっているベンダーよりはるかに一般に対するイメージがよい。これからインターネットは一般のものになるのだから、マイナーなネットワークベンダーよりいいんだ、みたいな感じだったと思う。

ちょうど、そこに住友商事の名古屋支社で部長をしておられた、吉井氏がいて、私がすごい剣幕だったので、なにごとかということで間に入られた。住友商事はYAMAHAと取引もあり、住友商事が販売に協力するということを検討するということで引き取っていただき、そして、「YAMAHA RT-100i」が誕生した。

最終更新日: $Date: 2008-10-17 23:02:31+09 $

RT100i-usersメーリングリスト

こうして稀有の国産ルータとしてYAMAHA RT-100iは、デビューした。住友商事には、ネットワーク機器を扱う子会社があったので、主にそこでの取り扱いになった。新たに、ヤマハのルータを売るために加わった、谷山さんという、現在は独立して、匠技術研究所の代表をしている人が中心になって販売に奔走した。

RT-100i は、ISDNだけでなく、64Kbps, 128Kbps の専用線にも対応していたし、機能はどんどん向上していった。実売価格は、10万円を切っていたはずなので、当時の環境としてはネットワーク構築においては、画期的な製品だったはずだ。

いろんな機会にインターネットをプロモーションしたい私にとっては、ISDNがあればネットワーク間接続までできて、完全なプレゼンテーションができるツールだったので、いろんなところに持って歩いた。

それに、私もああいってしまった以上なんとか応援しないといけないし、若干のロイヤリティもいただけるということになったので、いろいろとやってみることにした。当時まだ、NIFTYのインターネットフォーラムの SYSOP も続けていたが、どちらかというと凋落傾向にあり、フォーラムでサポートするというよりは、もっとオープンな仕組みのほうがいいだろうと思った。

そこで、当時 IIJメディアコミュニケーション(IIJ-MC)という IIJ の子会社でさまざまなサービスを検討していて、たわいもない話だがメーリングリストをやろうということにした。メーリングリストは、自分でサーバの管理をしていれば何の問題もなく設定できるが、パブリックなメーリングリストを管理するのは結構骨が折れる。私たちは、そのようなものは慣れっこだったので、Majordomo と、distribute を組み合わせてメーリングリストをサービスとして提供してみた。今にして思えば、これだけで、有料にできるようなものではないわけだが、いろいろなものを誰でも使える状態にするというのも当時は重要なミッションだったと思う。

ところが、メーカーとしては、そうした場を設けると、クレームばっかりがあがってきて対応に苦慮するのではないかという懸念があり、抵抗があった。結局位置づけとして、正式サポート窓口ではないが、半ばファンクラブ的な位置づけではじめたのではないかと思う。

現在までに延べ 40,000通に近いメールが飛び交ったメーリングリストには、最初は私も加わって使い方の情報交換をした。ヤマハの若い技術者の人たちも参加して、おそらく当時としては画期的なコミュニティを形成したのではないかと思う。

私はこのほか、UNIX magazine の連載で、ネットワーク構築の解説をするときには、ことあるたびに、RT-100i の設定を事例として取り上げるなどして、盛り上げていった。

IIJ が三番町のオフィスに移ったあとだったと思う。当時IIJ はCISCOのルータを利用していたし販売もしていた。CISCOもたしかISDNルータを出していた。IIJの専用線サービスでは CISCO を使っていて、そこを置き換えるような話ではなかったのだが、当時の日本CISCO の役員だったかに、突然電話をいただき、お小言を頂戴した。

しかし、電話を切ったあと、おもいっきり万歳を叫んだのは言うまでもない。

YAMAHA のルータは、まちがいなく大ヒット商品になった。

私がかかわったのは、RT-200iという、ISDN4ポートの商品ごろまでだったと思う。その後は、MEXで高速ネットワークの構築に移っていったので、ヤマハとRTは、件の谷山氏とヤマハの広瀬さんが中心になってサポートし、育てていったと思う。

現在は、YAMAHAルータはISDNだけではないが、この分野では信頼あるメーカとしての地位を確立していると確信している。

最終更新日: $Date: 2008-10-17 22:51:49+09 $