ありがとう梅田さん。
創造に関して、正式ないわゆるアカデミックな手続きなど全く無意味であることは、今や明らかであるにもかかわらず、そのいまある仕掛けが壊されると、多少無力感を感じたエントリーです。
レオナルド・ダ・ヴィンチの手記 上 岩波文庫 青 550-1はすばらしいです。すぐ読みます。
筆者はベンチャー企業の経営者であると同時に、昔、中学生から高校生にかけてアインシュタインの相対論がすべて！、の世界で大学受験、学生生活を過ごしてきて、いまなお精神的に青年のままです（笑）。学生時代から初期のストリングセオリーに傾注し、それを数学的に立証するために、数学科の位相幾何学、いわゆるトポロジーの授業を越境履修しました。30年前です。以来30年間、筆者はストリングセオリーを追い続けています。その結果、多くのことが見えて来ました。
同時に、今のこのBlogの主要テーマである自己組織化アプリケーションと言うソフトウェアと関わることで、実は、ほとんどの世界問題は、ソフトウェアと言う人間の認識問題に帰結できることを明確に、理解しています。いわゆる、理論問題における「バカの壁」です。
自己組織化について、次のエントリーで予告編パート２を書きますが、有限である人間の認識と言う装置によって、無限に近づく大量問題をいかに認識し、最終的にどうこれを制御するか、いやその前に制御できるのか、を議論するつもりです。 KAI
なるほどとんでもですか・・・。とんでもこそ創造性なんですが。
光ジャイロについて10年前に議論したことがありましたが、半径30CMの光の積分軌道の計算式で一般相対論を説明する輩がいましたが、この半径を軌道にする光とはブラックホール以上の重力が必要になるのですが。
底の浅さを実感しました。 KAI
以前からシンクロニシティについて、つくば万博時代（わたしのルーツである大阪万博と今のあいち万博と万博がシンクロニシティのキーになっていますが）盛んに取り上げられた気功と直結しています。
結局、レニンで有名な村上和雄がいみじくも言った遺伝子配列に神を見た感覚こそ、気功に力学的パワーを付与しています。
マジカルパワーでもなく、霊媒師でもない、意味的パワーを与えるのがシンクロニシティです。クオリア南麻布！です。
SNSに欠けているのはこのシンクロニシティです。ただのリンク関係では価値をうみだすことはありません。 KAI
「脳と創造性」を読了しました。ミラーシステムであるとか偶有性とか、もやもやと今考えている自己組織化アプリケーション問題に解を与える、大きなヒントになりました。
時間軸のパラメタでいけば、全く同時刻に何万と言う量子状態が存在していて、その量子状態自体が人間と言う存在の「実体」です。
その量子状態の中で言語化と言う量子化を行うと同時に、その反応であるフィードバックと言う外部刺激をあわせた自己システム内部の量子状態の中で更に量子化を行うと言う、量子化の連鎖である自己組織化の中に人間は生きています。
夢、寝言、感情、意識、すべてが量子状態の量子化の一形態です。
脳は、この量子状態を保持し動的に記憶するメカニズムと量子化と言うインスタンス化する機能を併せ持った臓器です。あわせて意味と言う価値観自体が量子化されることにより、量子化と言う連鎖自体の発散を防ぎます。
シンクロニシティ、セレンディピティとは、この意味と言う価値観の量子化を説明する概念だと考えています。クオリアについても、クオリア南麻布と言う看板には驚かされましたが、量子状態が意味の量子化と言う２回量子化前の１回量子化状態であると言うのは説明するまでもありません。 KAI
なんか一遍に、多くの問題が、一つの概念に集約してしまいました。
おととい本屋で集めてきた本の中のこの二冊（「セレンディピティ・マシン」、「脳と創造性」）。
単にタイトルだけで買ってきたのですが、しっかり内容もシンクロニシティです。
茂木さんの世界はまだ半分しか読んでいませんが、社会学的アプローチにだけはならないことを期待します。
要は、複雑系とは単にモード問題であって、モード別の理論は本質ではないと言うことです。
モードをこえるためには、量を次元パラメータとしてもつ理論が必要と考えます。2000億個のMPUと1個（ないし数百個）のMPUの動作原理は誰が考えても別物であるのは明らかです。 KAI
これも論理構造（ゲージ構造）のレトリックの罠に引っかかっている典型です。
不確定性原理とは、二つの物理量の間のトレードオフの原理ですが、よくよく考えてみれば全く次元の異なる（一見同次元に見える）物理量を、「観念的同時性」と言う概念で評価することにより、一方の物理量の決定ともう一方の物理量の決定があたかも共存できないかの原理です。
しかし、考えてみれば、次元の違い＝観念的同時性と言う恒等式こそ疑うべきであるのです。
つまり、不確定であるのは物理構造ではなく、今われわれが採用しているゲージ構造であって、当の物理構造自体は、初めも終わりも、全くの連続性が保証されていると考えます。
この連続性について、不連続の概念を明確にしたのが広中平祐です。広中平祐のフィールズ賞受賞論文である多様体の特異点解消のアイデアはシンプルです。不連続を始めとした特異点は、それが存在する世界の次元を、適当なレベルに上げることで特異点を消すことができることを証明しました。
これはまるでストリングセオリーそのものではありませんか。
実は不確定性原理とは、物理法則の原理ではなく、概念法則の原理であって、全く異なる概念定理を選択する余地があると言うことです。
これと同じ流れで、C（光速）＝C（定数）と言う恒等式も、恒等式ではないと言うのが明らかになりつつあります。これを証明するのは光ジャイロなのですが、なかなかこの光ジャイロの原理を世の中の人に理解していただけません（全く広報して（論文に書いて）いませんが（笑））。 KAI
いつものテーマから多少はずれますが、ITmediaに興味深いレポート「ゲームデベロッパーズカンファレンス2005:肥大化するデータ製作に新手法 ウィル・ライト氏が新作で見せたのは……」が掲載されています。
微生物から宇宙の神になるという突拍子もないゲームをゲームシステムの異なるステージをシームレスにつないで実現し、さらにそのプレイスタイルをプレイヤーに委ねるという本作のデモが終わると聴講者全員がスタンディングオベーション。
この記述を読むだけで、リリースが楽しみなゲームであることが伝わってきます。
記事の話しの流れと前後しますが、冒頭こんなことが書かれています。
ライト氏はまず、現在のゲーム開発の現状から説明。データ量の増加とそれによる開発人数の増加、さらにコストの増加に対し、バリューの向上が比例しないことを語っている。ここで、ザ・シムズ2を例にとって、ユーザーがコンテンツを集め、共有することを好むことを説明。また、ストーリーを予め作っておくのでなく、自分でゲームの内容を操作できるようなゲームがユーザーに好まれることも語った。そこでライト氏が見せたものはMaxisで極秘開発中の新作だった。
これを実現するアイデアの一端が次の記述。
「Spore」と呼ばれる本タイトルは、最初は2D風のアクションから始まる。プレイヤーキャラが捕食者から逃げ回りながら餌を取っていくことで成長・進化する。進化するパーツはプレイヤーの意思で選択することができ、攻撃することも可能。パーツの動きはプロシージャで書かれているので、どんなパーツをつけてもちゃんとしたアニメーションが見られる。
この「パーツの動きはプロシージャで書かれている」と言うのは、正にLISP言語を彷彿とさせられます。
更に、ゲームの流れである＜微生物→次世代生物→村落→都市→惑星→太陽系→外宇宙＞と言う次元の拡がりは、この間からのテーマである自己組織化そのものでもあります。また一つ自己組織化のヒントになる話しが出てきました。 KAI
YAHOO!のサーバーの問題点とは何か。これはGoogle型サーバーにはない、一般的なサーバーの特徴から来る問題です。
つまり、前回のエントリーで述べた、
一般的なインターネットサーバーと言うのは、一次的な障害対策として、ハードディスクの障害に対してはRAIDを、CPUダウンに対してはクラスターを採用しています。
このRAIDとクラスターと言う二つの技術に大きな問題があります。
私たちも当然がごとくRAIDサーバーを利用していますが、以前はRAID5であったものを、現在RAID1に統一しています。これは、私たちが体験した信じられないトラブルから、この設定にしたものです。
信じられないトラブルとは。私たちの製品であるERPパッケージを、ASPサービスではなくパッケージ販売していた時代のある日、あるユーザーのサーバーがダウンしました。サーバーベンダーのCEが、ユーザーの事務所にかけつけ調査し、復旧作業を行いましたが、結果的に48時間たっても回復できませんでした。当然RAID構成ですのでダウンそのものが発生しないはずのサーバーが丸2日、まったく動かないと言う異常事態です。
どうしようもないため、ハードウェア自体を全とっかえした上、私たちのSEが、たまたま別のサーバーに保管していた1週間前のバックアップデータを使用して復旧させました。
通常、RAIDと言う二重化だけでなく、万一のためのバックアップを、1日1回別の外部記憶装置にとる仕掛けになっていますが、なんと最悪なことに、RAIDで切り替わったはずの障害状態のディスクの内容をそのまま、正常な前日のバックアップに上書きしていたのです。
原因は、後日のサーバーベンダーからの報告書では明らかになっていませんが、RAID5のファームウェアと言うソフトウェアのバグであるのは間違いありません。RAID5とRAID1の違いは、ハードウェアではなくソフトウェアの違いです。ですので、現在バグの心配の少ないと思われるRAID1を採用していると言う訳です。
次に、クラスターの問題です。
これについては@ITに「フェイルオーバーの仕組みと問題点」と言う題で分かりやすい説明があります。
クラスタソフトウェアが業務引き継ぎの最後に行う仕事は、アプリケーションの引き継ぎです。フォールトトレラントコンピュータ（FTC）とは異なり、一般的なフェイルオーバークラスタでは、アプリケーション実行中のメモリ内容を含むプロセス状態などを引き継ぎません。すなわち、障害が発生していたサーバで実行していたアプリケーションを健全なサーバで再実行することでアプリケーションの引き継ぎを行います。
要はクラスターと言っても、FTCではないと言うことです。
これでは実際問題使い物にならない（恐らく今回のYAHOO!サーバーダウンの問題はこれと思われます）のは明らかです。つまり、業務アプリケーションにおいて一体どこにリアルタイムに「リラン」がきくプログラムなど存在すると言うのでしょうか。
まさに検索系でしかクラスターは使えないと言っているだけです。
これらの問題が「アーキテクチャ」の問題に帰するということを含めて次回以降に論じますが、そもそもインターネットのアーキテクチャそのものが、RAIDやクラスターと言う概念と折り合いが付いていないことが、今回指摘する問題点の根本の問題なのです。 KAI
一般的なインターネットサーバーと言うのは、一次的な障害対策として、ハードディスクの障害に対してはRAIDを、CPUダウンに対してはクラスターを採用しています。二次的には、ロードバランサーによるファイアウォール、Webサーバー、キャッシュサーバー等の振り分けが考えられます。
これに対して、Googleのサーバーは、上記の二次的対策は一部を当然採用していますが、一次的対策の方はこれを実施しないでも障害対応ができる仕掛けになっています。しかも、サーバー自体、グリッドでも何でもないラックマウントのサーバーを、プラグインで交換できるようになっているだけです。
この両者のサーバーの仕掛けの違いは、その維持費用という形で、大きく影響を与えます。前者の仕掛けでは、数千万人レベルの大規模ユーザーに対応できるようにするためには1台億円単位のサーバーが必要になり、かつてサンが潤っていたのは、これが理由です。後者は1台せいぜい千ドル単位の費用しかかかりません。
更に後者は、アプリケーション自体の不具合に対する障害対策として、アプリケーションサーバー自体を物理的に世代管理することで、瞬間的に1世代前のアプリケーションに戻すことも可能です。
しかしながら、後者の仕掛けで対応できるのは「検索」と言う特殊用途に限られ、リアルタイムのアプリケーションなど「更新系」には対応できないのでは、と言う意見も根強くあります。
これについては、以前のエントリー「Googleの技術はオンラインゲーム用サーバーに適用できる！」で詳細に検討していますが、今回は視点を変えて、もう少し別の検討を行います。
Google型サーバーでリアルタイムのアプリケーションを実行する場合を考えます。
まず、Webサーバーによって起動されるアプリケーションサーバーであるプールマシンは、1トランザクション毎に最低2台以上割り当てられ、それぞれ全く同じ処理を実行します。一番最初に結果を返したプールマシンの結果のみを採用し、以降の他のマシンの応答は無視します。逆に応答のないマシンは、自動的に切り離されて、マシン自体のプラグイン交換リストに登録されます。データベースサーバーも細分化されたインデックスシャードの複製を最低2台以上保持していて、対応するプールマシンのアプリケーションによってデータベースの内容が更新されます。この時の処理方法にアイデアがあるのですが、複製マシンすべてに更新をかけ、この時、先の説明の通り、複数のプールマシンから同じ内容の更新がかかることになりますから、これもプールマシンの応答と同じく、一番最初の更新のみ反映させます。更新の応答のないシャードマシンが自動的に切り離されるのは、プールマシンの場合と同様です。
この仕掛けによって、ハードウェア、ソフトウェアいずれの障害に対しても、二重化、三重化されることになり、耐障害性が格段に向上します。
これらの処理方法をよくよく考えてみれば、RAIDやクラスターで実行している内容を、領域単位、処理単位に分割して、これをマシン単位に振り分けて実行すると言う、マシンレベルによる超並列処理を実現していると言うことが分かるはずです。
実は、この仕掛けが、自己組織化するアプリケーションを構築するためのアーキテクチャを考えるヒントになるのですが、これは次回にと言うことで。 KAI
さんざん梅田さんのBlogで議論してきた内容ですが、久しぶりにCNETの記事「いま明かされる、グーグル・データセンターの秘密」から。
Googleは、比較的低価格のマシンを大量に購入することで、通常なら数千万ドルもかかるようなコンピュータインフラを、わずか数百万ドルで構築してしまった。この方法を選んだのは、ハードウェアのコストを検討していた同社のエンジニアが、強力なプロセッサを8基以上搭載するようなハイエンドサーバを数台購入するのに比べ、もっと簡単なつくりの「コモディティ」サーバを何十台も購入するほうが、はるかに安上がりなことに気付いたからだ。このアプローチを成功させるにはちょっとしたコツが必要になる。それは、数多くのサーバをうまく連動させ、あるマシンで障害が発生しても、クエリに対する検索結果の表示や広告の表示といった業務に支障がでないようにする、ということだ。
これについては筆者も以前のエントリーで詳細をレポートしていますのでご覧いただければと思います。
このCNETの記事に呼応するかのように、先週金曜日にYAHOO!がサーバー障害を起こして、YAHOO!メールを初めとした各種機能が利用できない状態が続きました。
YAHOO!の問題点について、以下のエントリーで何度か取り上げています。
YAHOO!の技術的バックボーンの詳細は明かではありませんが、Googleのサーバーの仕掛けと違ってごく一般的なWebサーバーの仕掛けを利用しているとすれば、YAHOO!の技術陣は今後この問題に対して相当性根を入れて取り組まなければ、こう言ったサーバー障害を根絶することは不可能です。
具体的に言えば、インターネットのサーバーを支えるハードウェアおよびソフトウェア、さらに個別のアプリケーションにおいて、耐障害性に対するアーキテクチャをどう設計するか、この1点に問題解決の方法は集約されると、筆者は考えています。
これは、先日からの話題である、自己組織化するアプリケーションを設計するためのアーキテクチャの話しにも通じる話であり、ここにきて世の中の技術の流れの必然性、共時性をいやでも痛感せざるを得ないと言う状況です。 KAI