昨日の話の続きです。
アプリケーションには目的にあわせて様々な種類がありますが、ここでその分類作業をまともに始めてしまうと、あっという間に1冊の本が書けるぐらいになってしまいますので、乱暴ですが、あえてアプリケーションは「システム」と「ツール」の二つしかないとします。
ここでいう「システム」と「ツール」の違いは、その使用形態の違いです。
「システム」は、複数の人あるいはコンピュータが同時に使用します。「ツール」はあくまで一人の人の使用が前提です。これで行くとWebサーバーは「システム」ですが、ブラウザは「システム」ではなく「ツール」です。
昨日取り上げたOfficeも、基本的には「ツール」です。
部品が製品に進化できないのと同様、「ツール」から「システム」は産まれないということを、昨日は申し上げたわけです。
これは簡単に考えると自明とは思えません。一見、例えば編集ツールに改良を加えて編集システムにできそうな気がします。が、そう簡単ではないのです。編集ツールは単に個人が使用するためのものですから、必要な機能は編集そのものの機能です。これに対して編集システムは、基本機能としての編集機能だけでなく、複数の人が使うための、いわゆるグループウェアの機能が必要になります。これを考えると、編集システムが100画面あるとすれば、編集ツールは1画面か2画面にすぎません。
つまり、実現すべき機能が明らかに違うということです。
これがアプリケーションの本質です。
アプリケーションオリエンティッドの設計とは、このアプリケーションの機能（の絶対量）をいかにコントロールできるかどうかです。 KAI
昨年、Officeの次期製品のスペックが発表された際も同様のコメントをしていたのですが、部品と製品は明確に区別すべきです。
CNETの記事のMySQL、データベース界の「ホンダシビック」となるかについて。
「自社技術の先進性を売りものにするソフトウェアメーカーが多いなか、MySQLはデータベース界の「ホンダシビック」であることに満足している。MySQLは、ウェブサイトへデータを渡すといった簡単なタスク処理のための考えられた「コモディティ」製品で、最先端の機能は備わっていない。」
このフレーズにそんな深い意味があるわけではないというのは理解していますが、DBエンジンを車に例えるのは抵抗があります（「ホンダシビック」ではなく「シビックのCVCC」なら納得しますが）。DBエンジンは、名前の通りエンジンであって、車ではありません。当たり前の話ですが、エンジンをいくら進化させたところで、絶対にエンジンが車になることもありません。
ところが、ソフトウェアの世界ではこのエンジンという「部品」と、車という「製品」が混同される場合がよくあります。
パーツ屋等で販売され市場に流通しているハードウェアの「部品」も、もちろん製品として扱われますが、あくまで「部品」としての製品です。これに対して例えばOracle等のマスメディアの扱い方を見れば、「製品」そのものです。
何が問題なのか、と反論されそうですが、非常に問題です。
主従が逆転していることが大きな問題なのです。この場合の主とはアプリケーションです。従がDBエンジンになります。
これが逆転しているとはどういうことでしょうか。
製品としての機能と部品としての機能は、同じ機能でも、機能の次元が違います。別の言い方をすると、主であるアプリケーションの機能を実現するために、従であるDBエンジンの機能があるのであって、DBエンジンの機能の延長線上にアプリケーションの機能があるのではありません。
OLAPなどのSQLという「言語」のインターフェイスの機能と、本来のDBエンジンとしてのデータベースの管理の機能は明確に区別するべきものです。言語のインターフェイスとしての機能を進化させていった先にアプリケーションがあると考えるのは、単にDBエンジンメーカーの戦略にはまっているだけです。
冒頭のOfficeの次期製品名が「Microsoft Office System」というのも、全く同じ構造です。OfficeがSystemを産み出すなどと言うのは幻想に過ぎません。
こうまで言い切ると、もう少し「製品発」（アプリケーションオリエンティッド）の技術とは何か説明しないと片手落ちですが、ここら辺はまた明日。 KAI
昨日のエントリーの補足をしておきます。
IT系の仕事を30年近くやってきて、こういった議論は幾度ともなく繰り返してきました。
その結果、たどり着いた結論は、もちろんイノベーターの独創性は素直に認めるけれど、その時代でなければ創造できない、時代の必然性というものがあるということです。
ミッチーケイパーだって、しっかり開発プロセス自体にはこの新しいパラダイムを受け入れているわけですから、何も発想できないのではないのです。
ミッチーケイパーが開発した123で潤っていたLOTUS社は、1990年頃だったと思いますが、ノーツと呼ばれる製品をリリースしました。そうです、今も多くの大手企業で使われているあのノーツです。LOTUS社は、その後、IBM傘下に入りましたが、逆にこのことで多くの大手企業で採用される結果になったと思います。
そのノーツも、「時代の必然性」の賜物です。
ノーツは、ドキュメントの広域管理の技術です。当時の貧弱な通信環境の中で、多地点にあるドキュメントのレプリカ同士の差分をやり取りして最新のバージョンを広域で管理するためのものです。
え？Webの技術と何が違うの？って思うでしょう。まったく同じです。
それでもノーツは時代の必然性の賜物です。ただ実現手段が違っただけです。P2P的な方法も最終的にはドミノでWeb技術の軍門に下りましたが、当時の貧弱な通信環境という「最適環境」の最適解としてはすばらしいものだったと思います。
■CPU＋メモリー＋ストレージ＋通信
これは最適環境のパラメタです。
この4つのパラメタの性能の違いによってその時代の最適環境が生成され、そこに最適解であるアプリケーションが産まれるという概念です。また時間を見て詳説します。 KAI
梅田さんがBlogインターネット時代をリードできない「PC世代の限界」で、その昔123を開発したミッチーケイパーと、彼が開発中のチャンドラーを取り上げています。
「この試みと、GoogleのGmailとを比較してみるといい。世代間で根本的に発想が異なっていること、チャンドラーと比較してのGmailの斬新さが、よくおわかりいただけるであろう。Mitch Kaporには、インターネットの「あちら側」に情報マネジャーを置くなどというパラダイムシフトは発想できない。これが「PC世代の限界」なのである。Mitch Kaporには、Googleに居る連中に代表される若い世代の持つインターネット観は、醸成されていない。」
ミッチーケイパーと聞いて思わずコメントしてしまいましたが、これは「世代の限界」と言った問題というより、「時代の必然性」だと思います。
その時代、時代の特定の機能実現のための最適環境というものがあります。例えばメモリーが大量に安く利用できる環境が整えば整うほどストレージというものがメモリーにシフトしていくとか、通信環境がより高速の常時接続が実現されることでLANとWANの境目がなくなり、ストレージだけでなくCPU自体がネットワーク化していくとか、そういった最適環境の中で植物や動物が繁殖していくがごとくアプリケーションというものが開発されていくのだと思います。
渡辺聡さんがGmailを読み解く(2)：技術的可能性で書いているのも、
「個人的な話になるが、プライベートメールの主環境をＩＳＰの提供するウェブ環境に移行して一年ほどになる。アクセスするマシンを選ばなくなったので、マシンの買い替えや出先でのチェックが実に気楽になった。マシンが突如クラッシュしてもメールに関しては別段困らない。スケジューラーなどローカルマシンのアプリケーションに依存しないものは、確実にウェブ上に移ってきている。」
正にこのことです。
Webで管理しようという発想からではなく、Webで管理する方が便利だから、ということではないでしょうか。
この時代の変化が速ければ速いほど、当然異なる最適環境が混在することになるでしょうから、最適解も一つではないでしょうし、やがてそれらが、時代とともに一つに収斂していくというのが実態ではないかと思います。 KAI
ASPサービスとDBエンジンの関係
この話の冒頭にも触れましたが、私たちはASPサービスをやっています。
ASPサービスとは、会員企業向けにインターネット経由で私たちが開発したアプリケーションを利用できるようにするサービスです。
具体的には、APサーバー上にユーザー毎の環境が準備され、これを、それぞれのユーザー毎の複数のクライアントがブラウザから入って利用することが出来るようになっています。共用サーバーを前提にしたコースの場合、1台のAPサーバーに平均40ユーザー（会員企業）、100クライアント（接続台数）が繋がっています。
もし、このアプリケーションのDBMSをOracleにしていたら、私たちは大変な額のライセンス料を支払う必要があり、当然月額利用料にも反映させざるを得ません。
これは大きなアドバンテージであるのですが、それだけではありません。
私たちのDBエンジンは非常にシンプルに出来ています。1台のサーバー上で、アプリケーションが何本同時に立ち上がっていても、DBエンジン自体の消費するメモリーは必要最小限のアプリケーション毎のバッファメモリーだけです。
ですから、あまり大きな声では言えませんが、APサーバーもDELLから通販で買った最低限のスペックのマシンでも十分なパフォーマンスが出ることになります。結果的にこのことも月額料金を低く押さえることが出来る大きな要因なのです。（1回目に梅田さんのBlogに触れたのもこのことです）
ウォーラブルコンピューティングの世界
私たちのプロジェクトは、2015年私たちの世界はどうなっているか、を考えることからスタートしました。ホームページの中のkaiレポートで書いた
「西暦2015年のオフィス、家庭、お店を想像してみて下さい。そこら中の壁がモニター化しているのが見えませんか？（これを私はウォーラブル（wall+able）コンピューティングと呼んでいます）そうです、2015年には壁一面がモニターになっていて、私たちは、このパーソナル化したモニターを通して、コミュニケーション、エンターテイメント、エデュケーション、メディカルチェック、ショッピングなどに、１日の起きている時間の半分以上を費やしているはずです。
このモニターの中の世界を、現実世界のリアルランドに対するもう一つの世界、アナザーランドと呼びます。」
この世界のインフラとなる製品を作りたいという、夢を実現させるプロジェクトです。
この世界では、コンテンツとソフトウェアが融合した様々なサービスが開発され、提供されています。ここに、私たちが開発したDBエンジンとアプリケーションがどう繋がっていくのか、未だ定かではありませんが、しかし、着実に一歩一歩近づきたいと思っています。 KAI
2002年−2004年
「500台のマシンの接続」を目指して
現在、DBエンジンの更なる改良に取り組んでいます。
その一つは「500台のマシンの接続」です。
4回目にも触れましたが、DBエンジンの性能の良し悪しはこの接続台数にあります。
コールセンターなどの環境で使用する場合、今まで想定する台数はせいぜい100台規模でした。ところがIPセントレックスの普及で500台規模のコールセンターも現実味を帯びてきています。
更にWebサーバー上で動作する場合は、同時に何万アクセスも考えられるため当然その負荷分散が行われるものの、更新系の場合は詰まるところ1台のDBサーバーにアクセスが集中します。
こういった使用方法に対応できるように、当面の接続台数の目標を500台と定め、技術開発を行っています。
この開発のポイントは、APサーバーとDBサーバー（キャッシュサーバー）との間の接続方法の一点にあると考えています。現状のTCP/IPによるLAN接続ではトランザクションの偏りを解消することができません。こういったことを解決するために、SANのようなクローズドシステムではなく、あくまで世の中で流通しているオープンな技術の上に構築していきたいと思っています。 KAI
2000年−2001年
DBエンジンの要の機能と言えば、それは排他制御と言われる、データベースへの同時アクセスの制御です。
何十台のクライアントマシンから同じテーブルに対して更新がかかると、他のマシンの要求を待たせた上で１台ずつ順に要求を処理していく必要があります。ここらへんをいい加減に作ると、ACCESSの初期のバージョンのように原因不明のデータベースの破損が発生します。
私たちのDBエンジンも、このデータベースの破損に見舞われました。
破損と言っても様々な現象があります。
初期の頃は、排他制御を行うための基本の機能であるロックが効かないために同じ出荷番号が採番されるという現象で、本来別々の伝票にならなければならないのに、一つの伝票になってしまうと言うものです。この欠陥は致命的です。こんなことが起きてしまえば、全く使い物にはなりません。
よくよく調べると、ロック機能がおかしいのではなく、コミット命令というWindowsAPIが機能していないことが判明しました。それが判ったのはいいのですが、替わりのAPIが見つかりません。試行錯誤の末、別のAPIで問題が起きなくなることが判りました。問題が起きてから解決するまでの1ヶ月間、ほとんど寝るまもなく調べ続けました。
そして、数十台規模の運用で、最後まで残った破損の現象がインデックスの破損です。
このストーリーの2回目にも出てくるインデックスが、突然おかしくなる現象です。どうおかしくなるかというと、2回目の話でIBと書いたインデックスブロックの一つの中身が、突然まるで関係のない別の内容に置き換わってしまうのです。
これには参りました。全く手がかりがつかめないまま1年以上が経過してしまいました。その間、大規模ユーザーの環境で2ヶ月に1回くらいの割合で発生します。
DBエンジンの完成
これも試行錯誤の末、手がかりを掴みました。2001年1月のことです。
3回目に書いたようにリエントラントな構造にするために、必要なメモリーはすべてdllの中で動的に確保し、それを、呼び出し側から渡されるポインタが指すエリアに格納していました。
この動的にメモリーを確保するAPIが、先のコミット同様機能していないのではという結論でした。リターンコードと呼ぶAPIからの戻り値はゼロ（正常終了）であるにもかかわらず、実際にはメモリーが確保できていなかったのです。何らかのタイミングで何兆回に一度の割合で発生する現象です。
IBを読み込むためのバッファと言われる領域も、当然動的に確保していました。その領域が、実は実際には確保されず、全く関係ない領域を使用していたために、せっかくバッファの内容を更新しても実際に書き込まれる内容が別の内容に置き換わってしまうと言う現象だったのです。
原因が判れば対策可能です。
メモリーの確保は、すべて動的に確保するのを止めて、呼び出し側に最初からマックスの静的メモリーを持たせることで、そのメモリーを使い廻す構造にコードを書き換えたのです。
すぐ対策版を組み込んで内部で入念なチェックの後、ユーザー環境に入れました。これから2ヶ月間、インデックス破損が発生しなければ対策できたことになります。
その期限であった5月31日までの間に、1件のインデックス破損も発生しませんでした。
bisonと私は、8年前とは違う、西麻布のとあるバーのカウンターで二人だけの祝杯を上げました。 KAI
1998年−1999年
1998年1月、約5年を掛けて開発したアプリケーションの製品版を出荷。DBエンジンも最新版を組み込んでいます。
製品版を出荷しても、新たな機能追加と不具合の対策は今まで以上です。この年から翌年にかけてが、アプリケーション、DBエンジンとも開発で一番苦しんだ時期です。
DBエンジンに限っても、ユーザーが増えるに従って様々な環境で使用されるようになり、想定外の現象が色々と発生し、一つ一つ原因を究明して対策していかなければなりませんでした。
私たちが開発した製品は、アプリケーションと言っても企業の基幹の業務に使用するもので、DBエンジンの不具合により業務が停止してしまえば、企業の業績そのものに致命的な影響を及ぼしてしまいます。担当する技術者たちにはこれが無言のプレッシャーとなって、体調を崩すものもいました。
しかし、逆にこのプレッシャーがあったからこそ、これだけの品質、信頼性を要求されるDBエンジンを完成させることができたのだと思います。
50台のロードテスト
それは1999年年明け早々でした。事務所の一室に、50台のマシンが並んでいます。そのマシンの前に座った50人のオペレータがセーノ、ドンで一斉に登録実行ボタンを押します。登録が終わるとその場で手を挙げます。最も早いマシンで2秒、遅いマシンで20秒台。
これは、その年の夏、本稼働を予定しているコールセンター向けのロードテストです。一つの登録の処理を50台が同時に行う確率はきわめて小さいですが、こういった場合でも十分なレスポンスが得られるか、本番前に試験しておく必要があります。
20秒台であればまずまず合格です。
こうしていよいよ、数十台同時運用の本番が始まりました。 KAI
ほんとにCNETのBlogは為になるBlogです。
渡辺聡さんが「全てはＩＰに乗って(2)」の中で
「うっすらと予見出来るマーケットの変化の中でキープレイヤーとして考えられるのは、物理的にではなく、電子的にネットワーク、コンテンツを管理出来るプレイヤーである。」
と書いていますが、全く同感です。
コンテンツをアプリケーションと渾然一体となったサービスとしていかに開発できるかがキーポイントだと私は常々考えています。この話もこのストーリーの最後に具体的に書ければと思います。（宿題が増えてきて大丈夫か？）
さて、開発ストーリーに戻ります。
1996年−1997年
いよいよ試作版を元に、VCに書き換えなければいけません。
1996年の4月頃外部の人間に依頼しましたが、結局できあがらず、元の担当者のK君が仕上げて10月頃完了しました。当初アプリケーションのリリース予定であった1996年12月にぎりぎり間に合わせたという状況です。
そのアプリケーション自体は、遅れて、翌年の4月にやっとベータ版をリリースしたのですが、これ以降、実際のユーザーの元でDBエンジンが試されることになります。
1997年9月、担当者がK君から現在の担当であるbisonに変わりました。
bisonが早速着手したのは、全てのコードの見直しです。DBエンジンはdllと呼ばれるリエントラント（dllを実際にチェックしたところ厳密な意味の再入可能にはなっていないようですが）な常駐プログラムとして動作しますが、これに対応できていなかったからです。
クライアント側で動作する場合、リエントラントでなくても当初は問題ないのですが、現在のアプリケーションサーバーのような使い方をすれば一発でアウトです。
そのためには、dll側には一切スタティックなメモリーを持たず、呼び出し側のポインタですべて管理できるようにしなければなりません。この作業自体はbisonががんばって3ヶ月くらいで完了しました。
この作業が6年後、大きなアドバンテージとして報われることになります。
1998年1月、いよいよ製品版の出荷の時です。 KAI
1994年−1995年
1994年10月、約1年掛けて試作版ができあがりました。
これはVBで書かれたもので、性能的に実用に耐えるものではありませんでしたが、それでも、DBエンジンが備えるべき機能とそのアルゴリズムを検証するには十分でした。
当時のOSは確かWindows3.1だったかと思いますが、この上で動くアプリケーションを開発するのに言語はVBを選択しました。開発予定の画面数が数百画面を想定しており（実際には1200画面以上になりました）工数削減を考えてのことです。（この選択で、あとからずいぶん泣かされることになりましたが）
このアプリケーションに組み込んで更に1年掛けてテストを繰り返しました。
1995年8月頃だったと思います。アプリケーションの開発も進み、いよいよ大量データによる本格的なテストを始めた矢先、とんでもないことが起きてしまいました。
同一キー値のサーチ問題
いわゆる同一キー値のサーチ問題と言われるもので、テスト中に突然アプリケーションがダンマリになってしまい、原因を調べるとDBエンジンがループしているように見えるのです。何分かすると回復するのですが、これでは使い物になりません。
私たちのDBエンジンは、木構造と言われるインデックスを採用しています。このインデックスは、インデックスブロック（IB）という単位で階層構造になっていて、IBにはキー値と下位のIB番号が昇順に格納されています。一番下位のIBに実際のデータのレコード番号を持つという構造です。IBの階層も、数千万レコードのデータベースでもせいぜい10階層もあれば管理できるシンプルな構造になっています。
通常のサーチの場合、目的とするキー値を指定することにより、IBを検索することで同じキー値を持つ目的のレコードを高速に見つけることができます。
ところが、１レコードの内容を更新する場合は、キー値だけでなくレコード番号も指定する必要があります。キー値だけでは同一キー値を持つレコードの特定が出来ないからです。そこで問題になるのが、このレコード番号が最下層のIBにしか格納されていないと言うことです。
試作版のこのロジックを調べると、同一キー値の場合、先頭のレコードから一つ一つレコード番号を最下層のIBまでたどって比較していました。もし値がセットされていない項目のインデックスの場合、何万レコードすべてがスペースという同一キーになっていますので、結果、全件検索と同じ動作になってしまいます。
さて、これをどう直せばいいのか。
すぐにバイナリーサーチというアルゴリズムを応用すればいいのは分かったのですが、階層構造の中の最下層の値のバイナリーサーチというのは初めてです。
10月の頭からアルゴリズムを考え始めて11月の終わりまでかかりました。
すぐにコード化してテストすると、ものの見事に、ループすることなく高速に動作するようになったのです。その後一箇所ロジックを修正しただけで、今も立派に働いてくれています。 KAI
皆さん、こんにちは。
KAIレポートをBlogとして再スタートすることにしました。このBlog版KAIレポートは、今までのレポートと違ってオープンソフトウェア株式会社の立場を離れて、（Blogでもありますので）KAI個人としての考えや情報を発信していきたいと思います。
さて記念すべき最初のエントリーはBlogの面白さを教えてくれた梅田さんのBlogの引用「Googleの本質は新時代のコンピュータメーカ」からスタートします。
「そして、この分散コンピューティングプラットフォームという、98年創業以来磨きに磨き上げてきた自前のインフラがあるからこそ、GoogleはGmailというサービスを構想することができたのだ。競合企業は対抗したくても、コストが見合わないから、そもそもサービスすら提供することができないのではないか、というのが本稿の論点である。 」
GoogleがGmailというサービスを発表して、様々なBlogで取り上げられていますが、梅田さんのこのBlogのおかげで良いヒント（これはこのストーリーの最終回に出てきます）を頂きました。
アナザーランド・サポートというASPサービス
私たちは現在「アナザーランド・サポート」と言うASPサービスを行っています。このサービスは今から3年前の2001年4月にスタートしたのですが、もともとはパッケージ製品として販売を目的に1993年夏頃開発をスタートさせたプロジェクトに始まります。
1993年当時、デジタルランド建国プロジェクトと称するネットワーク上の取引システムの開発を構想しましたが、実際にビジネスとして成立させるためにはオフライン（カタログ）通販企業向けのパッケージ製品として販売する以外に売上を上げる方法はないという結論でした。以来、現在までの開発の経緯はおいおいこのBlogで触れるとしまして、一つだけここで取り上げたいと思います。
それはDBエンジンの開発です。
DBエンジンすなわちDBMS（Data Base Management System）を、例えばOracleなどを使用しないで自前で作るというものです。
始まり
1993年の10月頃だったと思いますが、西麻布のとあるバーのカウンターで担当者であるK君と二人で打合せをしていました。話題はDBエンジンをどうするかです。
私は、その時まで20年近く汎用機のSEをやってきて、アプリケーションにとってDBエンジンがいかに重要な意味を持っているか、身にしみて理解していました。また、直前のプロジェクトでデータベース周りのツールに米国製の製品を使用して開発しましたが、その製品の不具合でとんでもない事態に遭遇する羽目になっていましたので、今回の開発ではできうるならばエンジン自体も自分たちで開発したいと考えていました。
とは言え、DBエンジンの利用経験は豊富といえどもエンジン自体の開発経験は皆無の私にとって、そんな無謀な決断をおいそれとはできません。
そこで当時横浜にあったサザンパシフィックのオフィスを尋ね、片山社長に面会しました。
この会社は、当時パソコン用のデータベースソフトでは恐らく一番シェアが大きかったdBASEIIIの互換製品であるdBXLという製品を開発して販売していた会社です。その片山社長に直接お会いして、Windows用のDBエンジンを供給するつもりはないかお聞きしました。返事はノー。
もう自分たちでやるしかないと、K君に話しました。
「僕が作ります。」
この時の決断が、後のこれから始まる数々の苦闘と予想外の恩恵をもたらすことになるとは知るよしもありませんでした。 KAI