SE関のノーツ/ドミノ徒然草

第36回 移行は一日にして成らず

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: SE関のノーツ/ドミノ徒然草

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:SE関のノーツ/ドミノ徒然草

このシリーズの続きに乞うご期待。

一般のクライアント/サーバーシステムの例から考えてみましょう。サーバーにもクライアントにもソフトウェアが置かれて構成されるているこれらのシステムでは、まじめに考えれば、『土曜日と日曜日を使って一気にリリースアップしてしまおう』とか、『自動配布ツールでなんとかいっせいに送ろう』といったアイデアになるでしょう。この背景には、サーバーとクライアントは同じバージョンでないと動作が保証できないとか、またユーザーにできるだけ迷惑をかけないようにやろう、と言った理由があることでしょう。

しかしノーツ/ドミノの場合はどうでしょう。もちろん一斉に全てのソフトウェアを上げるというのは理想的な移行かもしれません。しかし現実には同じドメインでもサーバーでさえ全国、さらには世界中に配置され、クライアントとなるともはや人海戦術では手も足も出ない、千そして万の位の数が展開されているわけです。たとえシステム管理ツールの自動配布機能を考えても回線幅やPCの不均一さによって、もはや現実的ではないように思えます。

ではクライアントとサーバーの数が百とか千だったら現実的でしょうか。しかしよく考えるとノーツ/ドミノはサーバーとクライアントだけでなくデータベースも、もちろんリリースの影響を受けます。基本的には上位互換性があると言っても一部にエラー処理の対応が変わったり、2000年問題対応で処理が変わったりもしています。そしてデータベースの数はというと、ノーツ/ドミノを長年お使いのユーザーさんでは場合によってはユーザーの数に近いアプリケーションデータベースが存在したりします。百や千といったデータベースの動作を新しいリリースでテストしなおすというのはやはり非現実的としかいいようがありません。

そして決定的な問題としてドメイン間接続という問題があります。他社との情報共有のためデータベースを複製でやりとりしたりするのはよくある話です。データベースの設計は古いままでなんとか持ちこたえるとしても、新しいリリースにあがったクライアントからは、新しいリリースでしかサポートされないコンテンツの表現形式が入り込んでくることでしょう。自社のドメインをリリースアップするからといって、完璧をきして他社も同時にあげてもらうというのはおそらく不可能に近いことでしょう。

このようにクライアント/サーバーシステムの理想的なバージョンアップを頭に描いている限り、ノーツ/ドミノのリリースアップはとてつもなく難しく思えてきます。しかし本当にそうでしょうか。どこかにノーツ/ドミノのような大規模に展開されたクライアントサーバーシステムはないでしょうか。イントラネットにはどうやらこれ以上のものはありそうにありません。すると残されたのは外の世界、インターネットでしょうか。

インターネットに移行は存在するか。もちろんインターネットだってサーバーのソフトウェア、クライアントのブラウザ、そしてサーバー上のアプリケーションがバージョンアップすることは日常茶飯事です。クライアントのブラウザなどは頻繁な新バージョンのリリースによって、インターネット全体とまでいかなくとも、特定のサーバーにやってくるブラウザだけでも、ブラウザの種類もさることながら、新しいバージョンのもの、古いバージョンのままのものなど多種多様です。言いかえればインターネットは極端には常にイントラネットで言う移行の途中の状態と言えるのではないでしょうか。

さてそれでインターネットのユーザーは困っていないのでしょうか。親切なサイトではそのサーバーがブラウザのこのバージョン以上でしかサポートされていないことが明記されています。それがなかったり、無視して中に入っていくと、時々スクリプトエラーとか、または表示できない表現形式が出てきたりもします。ユーザーは何かおかしいと気づいたり、多少いらいらはすることでしょう。しかしユーザーがそのサイトを本当に見たり使ったりする必要があるとすれば、彼らはそこからブラウザのサイトに飛べるリンクをクリックしてブラウザをバージョンアップすることでしょう。またそれが自分でできなければ誰かに助けをもとめてバージョンアップすることでしょう。一方そのページを提供しているサーバー側ではより多くのユーザーに見たり使ったりしてもらうために、ある程度のブラウザの種類とバージョンの幅をもってそのサイトが動作することをテストしていたりします。

このようにインターネットの世界では、ユーザーが主体となって移行が自然と進むように仕向けられているようにも思えますし、と同時にサーバー側もバージョンにそれほど敏感なものを作らないように仕向けられているようにも思えます。ある意味ではそのユーザーとサーバー側がそれぞれ移行に関してそれぞれ負担を持ち、と同時に問題が起きた時点で主体性をもって行動するような場となっているような気がします。インターネットという、さまざまなサーバーが、さまざまなコンテンツやアプリケーションを、さまざまなブラウザで使っている極めて不均一な環境では、移行に対する考え方は自然とこうならざるを得ないのではと思えてきます。

このインターネットの現実は、同じように非常に多くのサーバーが、さまざまなコンテンツやアプリケーションを、いろいろなPCでのクライアントで利用しているという大規模なノーツ/ドミノの環境での移行に関して一つのヒントを与えているようにも思えます。もちろんイントラネットの性格上、確実に正確に動作しなければいけない複雑なアプリケーションの存在はあるでしょう。そのアプリケーションの複雑さゆえクライアントとサーバーのリリースはこれしかテストされていないという場合もあることでしょう。一方、リリースにそう敏感でない大多数のアプリケーションの存在、またアプリケーションデータベースとしては膨大な数が存在していても、すべて共通のテンプレートが使われている場合などもあります。

ノーツ/ドミノでもブラウザが利用されるケースが増えてきました。ブラウザを使うということはイントラネットでもインターネットでも同じクライアントを使うということを意味します。イントラネットの移行に関する考え方も当然インターネットに引きずられていくことは避けられないでしょう。

今まで、問題がないように理想的に一瞬でやってきたクライアント/サーバーシステムの移行は、ノーツ/ドミノのようなインターネット的な不均一であり多様であり広範囲性を持ったシステムの登場によって、不均一さを前提として問題ありきで徐々にかつ分散的に移行していくという考え方を導入していく必要があるというのは言い過ぎでしょうか。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Lotus
ArticleID=339098
ArticleTitle=SE関のノーツ/ドミノ徒然草: 第36回 移行は一日にして成らず
publish-date=11112003