ラマンチャ通信 eCloud研究会掲示板

eCloud研究会スレッド、” R-0021　ユーザー企業主導クラウド・アーキテクチャの概要”の解説記事を、やっと書き終えました。

　これ以降も、smarter NFR などの提唱など、書き加えていきますが、一応、今までの研究スレッドを
まとめた形でリンクを付けています。

プライベート・クラウドの説明や、次世代データセンター論との違いなども書きました。
相変わらず解りにくい文章ですが、異論反論のフィードバックをお願いいたします。

よろしくお願いいたします。
↑

D-0022 中島の話はやはり支離滅裂か？それともVision形成へのステップか？
　　　2010年7月30日　中島丈夫　投稿

eCloud研究会スレッド、” R-0021　ユーザー企業主導クラウド・アーキテクチャの概要”で、技術の説明をせずに、相変わらずのヨタ話を書いてしまいました。これはきちんとした説明に書き直します。

　実はJEANSの終了に伴って、お伝えしたいチャートが幾つかあって、研究スレッドに掲載していきたいと考えていますが、図でお喋りするのは比較的容易な反面、文章化が大変です。
またTwitter全盛時代に図中心のプリゼン・スタイルも、フットワークの点で課題を感じています。
もっとも、RSSすら採用しないこのサイトがWeb 1.0だと呆れられているのも承知で、無視しています。
しかし、eCloud研究会の方法も限界かな、とも考え始めています。
本当にホメオトシス・パンチョと、独り＋のQuestになってしまいそうです。
PDFか何かで、White Paperにでも纏めた方がいいのかもしれませんね。

　さて、R-0021のヨタ話をこのスレッドに掲載・加筆しながら、くどいようですがeCloud研究会の趣旨を説明させていただき、読者の方の異論反論のフィードバックを是非お願いしたいと思います。
何しろ、当方としては、何方が読んで下さっているのかも、さっぱり掴んでいない状態です。

狙いは、クラウドを素材にした、新時代エンタープライズ・システムのイメージ構築

　約一年かけて、eCloud研究会では新しい時代のエンタープライズ・システム像に夢を馳せてきました。
その出発点はチェンジ＆レジリエンスの一言で済ませていますが、現行企業システムの諸々の課題を解きたいというのが動機です。
今までに、システム開発における多くの優れた考察や方法論が、やはり多くの優れた人々によって形成されてきています。
しかし、eCloud研究会ではそのどれにも傾倒せず、もっと言えば反発しながら、素材をプライベート・クラウド一本に置くことにしました。
なぜなら、今までの考察や方法論が幾ら学問的な見栄えが良くなってきていても、我々IT屋は少しも幸せになっていないからです。日本ITの閉塞感も一向に改善されない。
パブリック・クラウドに距離を置いているのも同じ理由からです。
これも語弊があるかもしれませんが、パブリック・クラウドは踊り場にきているのかもしれません。
しかし、KVSなどの技術はこれからのエンタープライズ・システムでも重要で、データ・パーシスタンスの重要な要素としてR-0021にも図示しました。

　一方で、実現出来ない夢を幾ら論じても、これもまた我々は幸せにはなれません。
ですから、eCloud研究会ではクラウド・プラットフォームや IaaS/PaaS/SaaS で代表されるメーカーが準備し、デリバーしてくるであろう技術や製品をイメージしながら議論を進めてきました。
しかし、プライベート・クラウド系の技術や製品は未だに全貌を現していませんし、eCloud研究会の出発点の思想として、どこかのメーカーの製品に偏ることも避けなければなりません。
ということで、今までの議論はかなり抽象的な回し方をしてきました。

しかしここにきて、メーカーの動きがよりはっきりと見えてきました。そしてより容易にイメージできる PaaS がクラウド論の本流になる気配も感じられます。
で、いかにも唐突に受け取られた方も多いと思いますが、小生は、反 PaaS に取られるような狼煙をITの風景で挙げるにいたりました。
話が見え始めたら反対かよ、という声が聞こえてきそうですが、
しかしこの主張は今に始まったわけではなく、最初から脱 PaaS を目指しているのです。
　eCloud研究会の思想として小生たちは、日本IT再生への貢献の、小さな旗を立てています。
それは、海外メーカー系への追従でも反発でもなく、Win-Win の関係の中で、日本ITがグローバルに成功できるための、アーキテクチャ創りを提言しています。スーパー・アーキテクチャではなく、フレームワークに近いものですね。
それを小生は、ユーザー企業主導のアーキテクチャ、と呼んでいるわけですが、もう少し具体的な一連のイメージを、議論のたたき台として、以降も挫けずに提示させていただきます。
小生がイメージしている海外メーカーとの関係を、R-0022　に図示しました。
メーカー間を超えたアーキテクチャの基本に、DMTF / OVF を置いています。

　JEANSの終了とともにeCloud研究会は脱メーカー色を強く打ち出して行きますが、逆に言えば日本ITのメーカーやソリューション・プロバイダーの方達ともVisionを共有させて頂きたいと思っています。
その一方で、先日のIBM zEnterprise 発表でのキーIBM Evanngilist の北沢強さんや、IBM クラウド事業部のやはりキーIBM Evanngilist の佐々木言さんは、共にJEANSのメンバーだったわけで、これからも日本ITとIBMのWin-Winを訴求されることでしょうから、出来れば共に歩みを進めたいと思います。
よろしくお願いいたします。
↑

D-0021 菅原さん、データ暴発でのストリーム・データ処理論は刺激的ですね！
　　　2010年7月08日　中島丈夫　投稿

菅原さん、

久しぶりの投稿ありがとうございます。

　それにしてもInterop 2010 NC27でのパネル・ディスカッションのまとめはとても刺激的ですね！
今までのクラウド論はWeb2.0が出発点にもかかわらずストアド・データ一本槍でしたものね。
データを集めて処理するデータセンターばかりを論じてきました。
本当は発生しては消えていくストリーム・データが量的にも遥かに膨大だし、それを如何にリアルタイムにキャプチャしてエンリッチして利活用するかが、これからは大変重要なテーマですよね。
我々はあまりにも単純に、なんでも貯め込んでから料理しようというGoogleのサーチ・エンジンと（相対的な時間軸で見れば）巨大バッチ処理の世界観に嵌りすぎていたように思います。
データを発生源で、あるいは通信経路の各エッジで抑え込むストリーム処理によるスケーラビリティは、モバイルやAR (Augmented Reality)、スマート・グリッドなどの新しいインフラにとっては大変重要になるのでしょう。
同期と非同期の上手な絡まりの、本当のICT のアーキテクチャですね。　
新しくストリーム・クラウド(Stream Cloud) とでも呼びたい気分ですね。
”クラウド、それはクラウドよりも遥かに豊か”、ですね。

　この掲示板のスレッドで前に、ISSCC 2010で、IBM STGの（結構昵懇だったDE）Charlie Johnson が,
"A wire-speed processor" なる概念を提唱していることを述べました。
IBM gives birth to 'wire-speed' processor
Charlie Johnson はIBMの粒粒プロセッサーのアーキテクトですが、彼の視界にはこのような風景が見えているのかもしれません。
また、つい最近、東工大のTSUBASA 2.0 がらみで、Nvidia Femili の新世代GPGPUのアーキテクチャを調べました。
TSUBASA 2.0 は過激とはいえ伝統的なHPC(High Performance Computing)の世界の中のチャレンジなのですが、このGPGPUなども巻き込んンで、ストリーム・クラウドと呼ぶような、新しいHPC のジャンルが誕生するのかもしれません。
AMD-ATI も動きがあります。

（AMD、高性能ストリーミングプロセッサ「FireStream 9170」の発売を明らかに）

　小生は2007年のIBM POWER6の発表に先立ってマスコミの方々に、
”IBMがとんでもない事を考えている”、
と報道されたような、ハイブリッド・プロセッサーのSoC という過激な技術動向メッセージを発信したことがありますが、どっかで動き出しているのかもしれませんね。
(なぜXbox 360は45nm化でPS3に後れを取ったのか )

これを機会にeCloud研究会の定款を変更しました
菅原さん、
それにしても、
約２８年間の日本IBMでのお勤めと、２年間の日本ＩＢＭのJTO JEANSのスタディ・チームのリーダー、
ご苦労さまでした。

　JTO JEANSのスタディが完了したことを受けて、eCloud研究会の定款も変更しました。
昨年５月からスタートしたeCloud研究会は、この約一年間はJTO JEANS との共同研究に似たスタンスをとってきましたが、６月３０日をもって終了しました。
これまでもビジネス上の関係は一切ありませんでしたが、これからはさらに明確に日本ＩＢＭとは無関係になります。
　ユーザー企業主導の、新しいクラウド・アーキテクチャ創出に少しでも貢献出来るように頑張ります。
よろしくお願いいたします。

eCloud研究会事務参照

菅原香代子さんのプロファイル

　丁度良い機会ですので菅原さんの簡単なプロファイルを掲載させていただきます。

　お茶の水女子大学修士課程（物理学専攻）終了後、昭和58年3月、株式会社日本ＩＢＭに入社、以来システムズ・エンジニア(SE) として約28年間、主としてＩＢＭ社内SE とお客様に対する技術支援を行ってこられました.。
この間、IBM オープン系DB2の市場投入以来の技術リーダーとしてエバンジリスト活動に専心、数多くの講演会や著作をこなされました。Webを検索されますと菅原さんの記事・著作が一杯でてきます。
最近はIBMストリーム・コンピューティングのエバンジリストとして活躍されていました。
（生まれ続ける「データの奔流」を、どこまで意思決定に生かせるか？--リアルタイムBIの可能性）

　平成16年4月に、ＩＢＭアジア・パシフィックにおける初の女性DE(Distinguished Engineer, 技術理事）に選任され、翌年、IBM科学アカデミー会員にも選出されました。
　DEの貢献活動として、日本IBMの女性技術者コミュニティー、COSMOSの創設と、第1期および第2期のリーダーとして活躍されました。（第3期リーダーはIBM Fellowの浅川智恵子さん）
社外においては日本女性技術者フォーラム（JWEF）の運営委員長に2年間就任されました。
平成21年度より国立大学法人東京農工大学の客員教授に招聘されています。
　入社時は、TSEL (Tokyo System Evaluation Lab.)で、スーパーコンピューターの評価、コンパイラーの評価を行い、特にIBM FORTRANの製品戦略に多大な貢献をされIBM開発部門から大きな賞を獲得。
　これからは、これらの経験を生かし、日本におけるIT産業の発展および女性技術者活性化のための活動を行っていきたいと考えておられます。

菅原さん、.eCloud研究会もよろしくお願いいたします。

↑

D-0020 Interop 2010 NC27パネルディスカッション．データ暴発とスケーラビリティ
　　　2010年7月04日　菅原香代子　投稿

中島さん、
久しぶりの投稿となります。一年ほど中島さんの独演会を楽しませていただきました。
ご存じのようにこの６月末をもって私も日本IBMを去り、中島さんの後を追って自由人になりました。
私の場合は約２８年間のお勤めでした。
丁度NHKの坂本龍馬でも、神戸の海軍塾が解散させられて龍馬をはじめ散っていくシーンがありましたが新しい出発です。eCloud研究会にももう少し貢献させていただきます。
今からが本格的な展開になるストリーム・コンピューティングの推進から抜けるのは心残りなのですが、２年に渡るJTO JEANSのスタディーも一応終えることができ簡単なレポートも出来上がりましたので日本IBMでの一応の区切りはできたと思っています。
　区切りという意味では6月10日(木)に幕張でのInterop 2010 NC27でパネル・ディスカッションに出てまいりました。日本IBMでの最後のエバンジリスト活動です。
「クラウド時代のスケーラビリティ技術」がテーマでした。
日本IBMの濱田正彦さんが司会をされ、パネラーはあの高名な首藤一幸東京工業大学準教授、富士通でクラウドビジネスサポート本部長をされている岡田昭広さん、そして私の３人でした。
ディスカッションでは岡田さんとは良く意見が一致して、KVS権威の首藤さんに二人で挑むような展開が多かったように思います。
以下に事前に濱田さんから頂いたご質問と、それに対して私が準備した簡単な答えのまとめを書いて見ました。

濱田さんからのご質問と私の答え

１．まずは情報の暴発はすでに起きていて、その大きな情報をどう扱うのかがITのテーマになってきていると考えられます。そのとき、もっとも重要な判断基準になるものは何であるのか。重要と思われる根拠は何であるのか？

Ａ：とりあえず情報をここではデータとしておきますが、膨大なデータ量を適切に扱うためには、データの時間属性で区別する、すなわち、ストリーム・データ、ストアド・データ、アーカイブ・データに区別してその処理系を考えることが重要になると考えています。
現在は殆んどのケースをストアド・データ一本槍で考えていますから、全てが分散データベース的な議論になってしまい、スケーラビリティやコンシステンシーなどの話がうまく整理されないのではと考えています。トランザクション処理も対象は結局ストアド・データですよね。
　発生するデータをファイルやデータベースとして先ず静的（スタティック）にイメージし、一旦ストアド・データとして書きだしたり、更新したりする処理アーキテクチャは、それがＫＶＳであろうがSQLであろうが、バッチであろうが、私の考え方で分ければ同じ範疇に入ります。
また媒体がディスクかイン・メモリーかなども、乱暴に言ってしまえば同じです。
　一方で、データをその発生源に近いところで取り込み、流れるデータをストリームとして連続処理してしまい、それで必要な結果を出してしまう処理系が始まっています。。
データの流れに沿ったダイナミックなストリーム処理の処理効率は凄まじいの一言につきます。
（これはあるお客様のシナリオで測定したところ、驚愕のパフォーマンスを達成した経験からです。）
また膨大で不要なデータ、（ゴミ）はその時点で捨ててしまってもよいし、そのデータの永続性が必要であればアーカイブ・データとして別系で残せばよい。勿論アーカイブ・データは別範疇の処理系の話に分けて考えることになります。
ストリーム処理といえども現在は、インプット・データをファイルとして受け取る場合が多いのですが、それでもデータをストリームとして流れ作業で処理させると桁違いの速さが得られます。
ストリーム・データにおいてもデータの永続性やハイアベーラビリティなどが要求される場合がありますが、その場合には時間軸の階層で構成されたアーカイブ的な仕組みで対応することになるでしょう。
　重要なのは暴発するデータをその属性で区別し、処理系をアーキテクチャとして適切に対応させることが重要になるという考え方です。
データをストラクチャード・データとアンストラクチャード・データで区別することも重要ですが、これからはファイル一辺倒の考え方を改めることが重要になると思います。

２．クラウドにおいてユーザーはベースの技術を意識しないでよくなるという話があるが、本当なのか？それぞれの立場で、やられてる分野を照らし合わせ、具体的にこのような時は意識必要とか、不必要であるとかということをご指摘頂けると助かります。

Ａ：クラウドになれば、現在に比べてかなりの程度、ハードウェア資源の手配やセットアップなどを気にしなくともよくなることは期待できますよね。
クラウド・プラットフォームの出来不出来にもよりますが、いずれかなり満足出来るようになると思います。
　しかしクラウドでの課題には２つあると思います。
一つはクラウド・サービスでのソフトウェア・プラットフォームへの依存性ですね。これはミドルウェアやＯＳの種類やバージョンなどを、やはり気にしなければならない。SaaS, PaaS, IaaS,においても、ユーザーはソフトウェア・スタックに制約されるということです。
もう一つはNFRですね。現在作りこんでいるきめ細かなNFRはクラウド・プラットフォームではサポートされないでしょう。なぜなら、NFRほど俗人的で多様な要件はないからです。
それは今のクラウド・プラットフォームの一般解では対応しきれないでしょう。
私たちはJEANSというスタディ・チームでこの２つのテーマに取り組んできました。
ここでは説明できませんが、enterprise classのVirtual Applianceやリンク・アーキテクチャなどで課題解決のアプローチをしています。

３．ストリーミング処理や今流行りのSmarter xxxなどの時代に入った時の、システムデザインはどう考えたらいいのか？ネットワークはどう変化を生んでくるのか？またアプリケーションの作り方はどうなっていくのか私案があるのなら説明ください。

Ａ：ですから、前にいいましたように、データをその時間属性で区別することが大変重要になると思います。すなわち、ストリーム・データ、ストアド・データ、アーカイブ・データに区別して、そしてそれに対応した処理系を個別に考えることが重要になると考えます。
しかし、全体として運用系などの一番大きな括りではまずクラウド・コンピューティングの仕組みで管理されて行くことになると思います。
ユーザー・セルフマネージメントのテンプレートを中心に、資源管理などは適切に行われる。
その大きな仕組みの中で、例えばストリーム・コンピューティングなども、プロビジョニングされていく。そのためには適切なハードウェア構成が準備されている必要があります。
多くの場合には、それらはITアプライアンスとして、クラウドの構成要素として、持ち込まれることになると考えられます。
そしてその上で、ビジネス・ソリューションはリンク・アーキテクチャで疎結合に統合されることになると思います。
　ネットワークで重要なのは、エッジ・サーバーが積極的に導入されることになる点です。
ストリーム・データが無線などで発生源からそのままクラウドに流入することになると、途中のネットワークもクラウド処理も持たなくなるのは眼に見えています。特にバックホールという無線ネットワークをブロードバンドに繋ぐ途中のネットワークがボトルネックになると言われています。
このネットワークを太くするためには膨大な投資が必要になるため、データ発生源の近くでのエッジ処理が重要になります。かなりの部分のストリーム処理もエッジで処理され、クラウドのデータセンターと上下するデータ量の暴発を押さえることになるでしょう。

４．今後、どのような観点に注目して、様々なスケーラビリティ技術を評価すべき

Ａ：スケーラビリティを論じる場合に、現在欠けているのがレイテンシー、遅延の議論だと思います。
スケールが出ないのは、実は分散処理の構成で相互接続のための距離に起因する遅延があるためですよね。
しかしだからといって、一気にBASEの議論のようにアプリケーションの作り方まで変わってしまうという考え方は短絡的だと考えています。
地球規模だけでなく、スケールの範囲をもっと現実的に対応していくべきと考えます。
All or Nothingの極論に陥らなければ、まだまだ新しい技術はいろいろあるわけです。
スケールアウトでの遅延の課題解決には、例えばIBM のDB2 pureScaleがチャレンジしているような、RDMA on Infinibandという超低遅延プロトコルのアプローチもあるわけです。
DB2 pureScale だと、SQLのままでも十分スケラービリティが出せるわけです。
また、MapRedueの高速バッチ処理などをうまく使ったり、低遅延のストリーム処理を持ち込んだりすれば、メーンフレームより遥かに速いバッチ処理も可能になるのではと思っています。
　私が云いたいのは、技術の進歩は多様で、工夫すればいろいろな方法でスケーラビリティを達成する方法があるという点です。
クラウド論でも同じで、あまり決めつけないのが技術者の技術に対する正しいアプローチではないかと思います。

↑

D-0019　クラウドに、空間よりも時間軸のスケーラビリティを求めて
　　　2010年6月27日　中島丈夫　投稿

　先のスレッドで、IBM Fellow, Chief Virtualization Technologist の Jim Rymarczyk との経緯を書きました。そこでは小生がこの一年間意図的に彼との交流を絶ってきたことを述べましたが、最近アップされたITproの記事を見ると、IBMのクラウドの基本が変わっていないことが確認できました。
　ということで、前に進みたいと思います。

　小生はこの４月から新しいMy Questの一貫として、日本ＩＴルネサンスを唱え、ユーザー企業主導のアーキテクチャ構築へ一歩踏み出すように訴えています。
これはこのラマンチャ通信でeCloud研究会を発足した時からの、ま、既定路線でもあります。
　小生が日本IBMでの最後のご奉公としてJTOやJEANSを発起していたことは何回も述べていますが、それはクラウドを梃子にした日本IBMと日本ITの、技術におけるWin-Winな構図再建の提言でした。
でも、当時の日本IBMの中堅のリーダー、管理者ですね、には全く通じませんでした。
目の前のものしか、出来上がったものしか見えない人たち。
想像力がないからいろんな境界が溶けていかない。
　で、耳タコのドン・キホーテのMy Questになっているわけです。

　Jim Rymarczykの記事でもあきらかなように、IBMは垂直統合のメリットを強く主張し始めています。
日経コンピュータ(6/9)で、IBM Sr.VP、STG担当のRod Adkinsも何回も強調しています。
これはOracleのLarry Ellisonも、SAPも取るクラウド時代におけるメジャー・プレイヤーの主戦略ですね。
戦略としては必然だと思いますが、ユーザー企業にとってはプライベート・クラウドやハイブリッド・クラウドでの大きな制約になりかねない。囲い込みのリスクです。
特に遅れ気味の日本ITの現場では、草刈り場にバラバラに生成する夕立雲にされかねない。
きっとISA(Itanium Solution Alliance)のようなメーカー主導のマガイモノの団体も現れるのでしょう。

　ということで、ユーザー企業主導のアーキテクチャ構築が必要だと考えています。

それはそんなに難しいことではないと考えています。
メーカー各社の準備するクラウド・プラットフォームを睨みながら、仮想化、仮想アプライアンス化のフレームワークを上手にリードしていけばいい。
具体的にはDMTFのOVFの仕組みなどをユーザー企業側が仕切る構図が有望です。
昔は、IBMなどではGude/Shareとか、各種のDesign Councilなどがあって、ユーザー企業の技術への関与の風通しは遥かに良かったのです。今はもっと独立した方法が必要のようです。

　さて、舶来のクラウド・アーキテクチャは空間軸のスケーラビリティが売り物です。
空間のスケーラビリティでは距離による遅延が課題ですから、CAPやBASEの定理が論点になります。
これに対して、日本ITのクラウド・アーキテクチャは時間軸のスケーラビリティを訴求したい。
それは、昔も今も、企業ITの最大の課題であるメンテナンスという名のシステム・ライフサイクル管理、そして変化への俊敏で適切な対応の仕組みです。運用がらみの労苦もここに集約されます。
クラウドを上手に使って、企業システムの根幹にある時間軸とのせめぎ合いを、スケーラブルにしたい。

eCloud研究会では一貫してこの視座でクラウド・アーキテクチャを論じてきました。
その出発点となった、”eVAの版化とテスト・ケース縮減への拘り”を研究スレッドに掲載しました。

追記：
eCloud研究会の主張をザックリ表現すれば、”アリケーションの仮想化”となるのですが、これには抵抗感を持つ人が沢山いました。
海外の人たちとも討議したりして、eCloud研究会では一歩踏み込んで”NFRのテンプレート化”となっているのですが、驚いたことにマイクロソフトがインタビューで
”クラウド時代の運用管理では、アプリケーション仮想化が重要に”
ということを述べています。精神的にも近いものがあります。
”programming model agnostic”の主張にしろ、何か近いものがありそうで気持ちが悪いですね。。。

↑

D-0018　見果てぬ夢．"programming model agnostic"な世界を求めて
　　　2010年4月27日　中島丈夫　投稿

　素浪人生活と禊の１年を過ぎて最初のブログは、eCloud研究会の掲示板スレッドにしました。
またその素材となる研究レポートの掲載を再開しました。

２月の終りに、IBM Fellow, Chief Virtualization Technologist の Jim Rymarczyk が来日して、3人のPOWER製品のGURUの一人としてセミナーを行ったようです。
RymarczykはIBMの仮想化の技術リーダーですが、ITproの記事にありますように、IBMクラウド・アーキテクチャーボードのリーダーでもあります。
彼はz（IBMメーンフレーム）LPARの設計者で、Sysplex Design Council のリーダーもやりました。
zの仮想化をPOWERに展開した責任者で、IBMにおけるx86系仮想化の技術戦略の当事者です。
　実は小生はJimとは懇意で、結構昔から技術交流を行ってきました。（今は全くありません）
昨年の３月３１日に小生がＩＢＭを去るまでは特に頻繁に技術論議をやっていました。
という事で、小生はIBMクラウド・アーキテクチャボードとも関係がありましたが、昨年３月３１日を持ってきっぱりと断絶してしまいました。唐突に Jim との交信を全て断ってしまったので、彼は面食らっているでしょう。死んだと思っているかもしれません。本当に申し訳ありません。
　何故そんなバカげた事をしたかと言えば、プライベート・クラウド技術活用による、日本IT活性化の可能性を、日本ITの方々に伝えたかったからです。大変重要な技術変革を起こせる可能性が大だと。
勿論IBMの開発に絡む計画や未発表技術の内容を喋るつもりは全くありませんでしたが、ビジョンとして伝える義務を強く感じていました。
椎名元日本IBM社長の口癖であった、日本とIBMのＷＩＮ・ＷＩＮの価値訴求が小生の錦旗でした。
そして最後のご奉公として日本ＩＢＭに一連の活動を提言したのですが、叶いませんでした。
　という事で、錆びた古い鎧を身にまとったドン・キホーテのクエストになってしまったわけです。
ドン・キホーテのドジで、少しでも迷惑がかからないように、Jimとの交流は100%断ちきりました。
本当は追いだされたのですが、脱藩浪士の志です。

　最近になって、やっと日本IBMからIBMクラウドの技術の方向性が語られ出しました。
内容にはかなり不満はありますが、まぁ、やっとこれでeCloud研究会も再スタート出来そうに思います。
何しろ、ベースにExecution の裏打ちの無いVision のお話など誰も相手にしてくれないわけですから。

ということで、再スタートは思い切りビジョンの風船を膨らませてみました。
未だ書き始めにすぎない研究スレッドの画餅、図を眺めて下さい。
クラウド構成におけるprogramming model agnosticの訴求　です。
小生の見果てぬ夢です。大切な過去を助走台にしたITの未来への飛翔の構図です。
一つ一つのインスタンスしての技術の流れを追うのも必要ですが、一度、あるべき姿、有って欲しいシステム・イメージを描くのも重要です。メタ・システムとしてのアーキテクチャですね。
ウォーターフォールやアジャイルな開発モデルの両方を支える受け皿が無いとSOAは出来ない。
そしてこのagnostic、しなやかさこそが、辺境の日本ITが立ち直れる、一つの方法だと考えています。
内田樹さんが”日本辺境論”で喝破された、日本2000年の英知に立ち戻りたい。
未だ何を云っているのか、何の念仏を唱えているのか全く通じないと思いますが、再スタートします。

”programming model agnostic”の主張は小生の独言ではありません。
少し矮小化されていますが、マイクロソフトのバーマー会長がAzureのビジョンとして語っています。
一方で、小生が永く反BASEに拘っていたのも、BASEが排他的な "Cloud based programming model" 専横への強い主張だと感じたからです。でも、それも是としました。それも受け入れましょう。
しかし、あのダウンサイジング時代の愚は避けたい思いで一杯です。同じ事を繰り返してはならない。
ITProで東葛人さんが、感覚的に良く似た警鐘を打ち鳴らしておられます。
（クラウド最大の問題が国内でも表面化、二枚舌はもう止めよう）
昔も今も、技術の使い分けを主張する人達がいます。
それはそれで現実的な方法ですが、経験論的に、これって大変危ない病魔の囁きでもあります。
技術者の嘘に通じてしまう事が多かった。ダウンサイジング時代にもそんな事が沢山ありました。
誤解が無いように念を押しますが、agnosticというのはこれらをきちんと乗り越えようという事です。

小生は革命を夢見る現実主義者です。無血革命を夢想する一人の甘い元SEです。
↑

D-0017　反省：思考はもっと自由に. カオスの奇跡を求めて多様性に飛翔すべし
　　　2010年3月26日　中島丈夫　投稿

　竹嵜さんとの議論を通じて、またまた反省してしまいました。
小生の論は、真向に刃を切り結ぶというよりも、空中遊泳になっているような。老いたり中島ですね。
先日法事があって、お寺のお坊さんに”仏教にも懺悔というのはあるのですか？”と御伺いしたところ、
まじまじと顔を見詰められてしまいました。
居合わせた回りの人達からも、”？”、という、ある種の訝しさの空気を強く感じてしまいました。。。。

さて、竹嵜さんはホメオトシスに嵌められる危険を強く感じられていますが、そんなことはないのです。
このラマンチャ通信全体の主張は、”アンチ理論ごもり”の、直接戦場で切り結ぶ勇猛果敢な戦士待望論に染め抜かれているはずです。小生の主張するITルネサンスの肝は、深い洞察力とともに、会議や管理を適当にイナシテ、自分の手でどんどん決める、作っちゃう、そういう逞しいリーダー待望論です。
ということで、BASE トランザクションをどんどんやってください。小生の罵詈雑言はひっこめます。
もうBASEやCAPに云いがかりを付けるのはやめます。

　とはいえ、小生にも少々の面子はあるので、またまた余計な理屈を一言。（結局反省していない？）
今のクラウド論は範囲の定まらない雲を掴む”スケール論”に偏っていると思います。
ACIDやSQL退治なんかは、超頭脳や俊敏な手さばきの俊才の方々は、さっさと片付けてください。
今、東証システムのような、レイテンシーの常識をぶっ飛ばすシステム創りがあっちこっちで稼働し始めています。以前から顕在化していた大量メモリーや接続技術のテクノロジーの革新が、システムの常識を覆しているわけですね。勿論そんなことは竹嵜さんの視界には入っておられるのは存じています。
ストリーム・コンピューティングが起こす仰天するような革命が、眼と鼻の先に迫っているようです。
アーキテクチャお下がりのコモディティ化なんてくそ喰らえです。本来の破壊的技術の出現ですね。

ということで、一般の方々に問いかけたい。グーグル超え、アマゾン超えの思考やいかに。
↑

D-0016　竹嵜さんの疑問に対するお答え
　　　2010年3月22日　中島丈夫　投稿

　竹嵜さん、ありがとうございます。そして本当に申し訳ありません。
大変お忙しいなか、貴重な時間を割いてわざわざ"ぶいてく"にご意見を書いていただきました。

今回は、Twitter 全盛時代に信じられない程くどくどと書き綴る、小生の100倍返しはいたしません。
他のスレッドで別にダラダラと書きます。一部既に書いてもいますので暇な折りに眺めて下さい。。

疑問へのお答え
先ず疑問に対する直接のお答えです．

疑問１　結局、CPU単体の能力は無視できないじゃないか
答え１　そうです。
　スパコンの世界でもPrivateクラウドでもプロセッサーが一杯必要です。
チップ内Scale Out などと変な呼び方をするから誤解を招くのですね。すいません。
　アプリケーションが必要とするグロスのCPU性能を満たすために、CPUが一杯必要だとして、それらをどう結合してスケールさせるのが一番適切か？
チップ内のマルチコアやマルチスレッド、チップ間やメモリー、I/Oとの結合、ボックスを超えた結合、ネットワークを介した結合などなど。
ハードウェアのコストは勿論ですが、開発や運用なども含めたTCOで決まるのでしょう。
　論点は、一つのアプリケーションから見たConsistencyとScalability のHW系依存の範囲ですが、　　　Privateクラウドでは、RDMAなどの今見えているHW系技術対応で十分充足出来ると考えています。
少なくともソフトウェアの新たなBASE対応などの大細工は必要ないと思います。
　さて、竹嵜さんの誤解の元になっているのは、ITアプライアンスではないかと思います。
小生が強く主張しているのは仮想アプライアンスの応用で、ITアプライアンスではありません。
ITの風景の”ITアプライアンスと仮想アプライアンスは別物”のラベルを参照ください。

疑問２　同期的処理が必要なのは部分的なのになぜ全体アーキテクチャが必要か
答え２　全くの同感です。
　この分野で業界一の技術リーダーである竹嵜さんに何か云うのもはばかれますが、同じ理由で、逆に、小生はBASE理論が必然だという主張にうんざりしています。
実は、情報処理学会No.11の解説論文の拡がりに、大きな違和感を触発されてしまっています。
　先ず小生が主張したいのはUOWのACIDで、そこはニュ－トン力学の世界に限定していいではないかという点です。クラウド・スケールというマントラがそこまで覆してしまうのか。どうなんですか？
特に我々のeCloud研究会ではアプリケーションの仮想アプライアンスを繋いだ疎結合なサービス・リンク・アーキテクチャを考えていますので、リンク全体に渡るトランザクション設計など困るわけです。
Eventually Consistency などと、クラウドにトップダウンなマントラの網かけを持ち込まないでほしい。
　窮屈なシACID、つまりトランザクション処理の枠組みの限界は既に十分認識されていますし、逆に出来るだけ自動化で処理の定型化とスケールを出したいという願望は今に始まった事ではありません。
例えばWS-*の生い立ちも、まさにそこが出発点でした。
　WS-* の始まりは、間違いなく竹嵜さんの業界初のWeb Service の経験が元になっています。
当時の竹嵜さんの経験を素材に、IBM Academy で始めたものです。その時のタスクの名称は"Intenet Transactional System" で、全てをACIDで押し通すビジョンなど持っていなかったのです。
しかし行けるところまで手作業のジャングルを伐採して、システムの見通しを良くしようと考えていた。
この名称は、小生が深く尊敬するIBM FellowのEd Lassettre の命名です。彼は大部前にMicrosoftに移っています。35年前にKHIの統合化設計で河村さんとPoughkeepsie に彼を訪れた時点で、IBM総本山の技術の中心にいましたから、この業界の大物主の神みたいです。
このタスクには当初から多くのIBM Fellowなどの開発者が乱入してきていて、実のところ小生などは早くから脱落してしまっていました。余談ですが、当時は未だ世界にデビュー以前の大内DEの"Time Out不可知論"が大変受けたりしていました．この辺もまたホメオトシスに書きます。
　さらなる余談ですが、eDatacenterは小生が1999年当時、SWGに提案していたプロポーザルです。
同じような案を当時のSWGも持っていて、それはSMBビジネスに特化したモデルでした。　　　　　
Larry Loucksの取りなしで、Somers New York までその提唱者に会いに行ってきましたが、SMBのアクセス側の仕組みが大きく成り過ぎていて、途中でそのプロジェクトはCancelになってしまいました。

疑問３　BASEトランザクションはそんなにダメなのか
答え３　BASEトランザクション自体ではなく、大上段のBASE理論や開発論はダメだと思っています。
　BASE理論のイデオロギーには、オートノミック・コンピューティングに似た、理論願望先行による全自動化追求のような、底なしの危険な目的が潜んでいるように思っています。
本来、セッション型が重要な部分を占めるようなビジネスのトランザクショナルなプロセスまで自動化し、疎結合の本来の目的やメンテナンス性が歪んでしまうのではと危惧しています。
　小生が一番気にしているのは、クラウドの名の下に、既に確立された現行のシステム作りのノウハウをスクラップにして、またまた現場のシステム造りが混乱するのではないかという心配です。
そんな大層なことにはならないという方もおられますが、小生は心配しています。
努力の割には、余り付加価値を生まない新しいお作法作りや置き換えに、優秀で貴重な頭脳や時間を浪費してしまうのではないかという危惧です。
その意味では、竹嵜さんが苦労された補償トランザクションに似ているのかもしれませんね。
　補償トランザクションは、今大学教授になっている新川さんが最初リードされ、WS-*でも当初から俎板に挙げていましたが、これには当初から大内DEをはじめネガティブな人が多かったですよね。

次にeCloud研究会全体を通した考え方のお答え
・今はPubricクラウドに口出すつもりはありませんが、Hybridクラウドなどで口挟むかもしれません。
　HadoopなどでPrivateクラウドを構築することなどは静観状態で、むしろ成功を祈っています。
・論点は、竹嵜さんが違和感を持っておられる、小生のPrivateクラウドのシステム・イメージですね。
・小生の考えと一般ウラウド論との一番大きい違いは、ConsistencyとScalabilityの優先度です。
　小生はPrivateクラウドをエンタープライズ・システム系の将来として見ていますので、Consistency
の方がScalabilityより重要だと考えています。運用や開発のし易しさを天秤にかけて考えています。
さらに突っ込んで、メンテナンスや変更の柔軟性をPrivateクラウドを活用して抜本的に変革したい。
ですから、Scalabilityを含みながらも一般的なNFRの充足がPrivateクラウドの課題だと考えています。
　これをBASE理論（？）に沿って全てスクラッチから作るとか、思考方法もスクラップにして、アプリケーションやシステム開発の新しい方法論で対応すべきだとかの考えには大いに疑問を持っています。
小生が今まで一貫して訴求してきたのは、ZapthinkもSOAで論述していますように、既に存在するものの再利用です。新しい付加価値を創造するのに、既に機能しているものの作り直しは避けたい。
そこにPubricクラウドとPrivateクラウドの決定的な違いがあると考えています。
　また、Privateクラウドが既存システム系を徐々に吸収・移行する形で両者の共存を図りたい。
それを素直に具現化するのは、仮想化の発展系のPrivateクラウドだと考えています。
運用コストや開発・メンテナンスなども含むTCO、GRC、ビジネス俊敏さなどの総合判断になります。
・それでは、どんなアプリケーションをPrivateクラウドに乗っけるのか。
エンタープライズ・システム系の将来ですから、当然ミッション・クリティカルが必須です。
だからNFR充足が必須です。しかも多様な粒度の対応が必要です。smarter NFRです。
一方で、スマート・グリッドのような新世代の基幹系の世界を考えるとScalabilityは大変重要ですよね
ですから既存のシステムの作り方ではなく Privateクラウドだ、という事です。
で、どの程度のScalabilityが必要なのかですが、Pubricクラウドの主張とは桁が違うのは明らかです。
・重要なのはLatencyの解決です。今、エンタープライズ・システムでホットなのは東証のようなmsオーダーの応答性ですが、これが今までのクラウド・コンピューティングの議論で欠けていると思います。
ストリーム・コンピューティングとして、CEPやBIの世界とともに論じられているテーマですね。
　という事で、Privateクラウドに必要な議論は、
　Availabilityは必須として、Consistency、Scalability、Latency　のバランスやブレンドだと考えまていす。そして上位概念の全体としてのTrustでしょうか。

小生の立ち位置
- 小生の立ち位置は、竹嵜さん達リーダーの邪魔をする事ではありません。お役に立ちたい。
- お役に立つ方法として、小生の見てきた風景、見える風景をお伝えしたいと思っています。
　で、自分のラマンチャ通信で、読まれようが読まれまいが関係なく、勝手に書いています。
　少々踏み込んだ記述も、可能な限り書くようにしています。
- 出身も価値観もSEなので、IT基盤製品に対するスタンスはInstitute、ざっと云えば同好会側です。
　↑

D-0015　RDMA実装で明らかになってきたクラウド時代の新データモデル

Windows Server AppFabric、 OracleのSun買収、そしてIBM pureScaleに見える未来

　　　2010年2月25日　中島丈夫　投稿

　これでまでのこのサイトでの、小生のCAPやBASEに対する決めつけた議論展開に、賛否両論のご意見を頂いています。ま、大半の方は、結果論だよな、という未来待ちの姿勢なのでしょうか。
小生には以前に技術のダウンサイジング論という厭なトラウマがあるために、つい保守反動的な言動に走ってしまうことをお許しください。本当はGoogle的な技術チャレンジが大好きですし尊敬もしています。
　一方でこのeCloud研究会は、もともと日本ＩＢＭ社内のJTOという技術者のボトムアップな未来技術へのチャレンジで、JEANS (JTO Enterprise Appliance for New Service)という、企業システムの課題解決のための一つの研究タスクから派生しています。ですから、どうしても企業ITに固執しています。
そして、一言でいえば、"Change & Resilience"、と謳っているように、着地点と速やかな安定化再帰を強く意識した上での、変化のためのシステム・フレームワーク作りを目指しています。
ま、そういう意味で、CAPやBASEのようには大胆に飛べないDNAを持っています。
そして、”大空を自由に飛び回ったことがありますか？”で書きましたように、着地点を意識した途端に、人は飛べなくなってしまうのでは、と、強い危惧も個人的には持っています。。

クラウド時代のデータモデル

　さて、そのJEANSのリーダーであるIBMの菅原DEが，連続セミナー「渋谷テクニカルナイト」で，

”DB2 pureScale、クラウド時代の DB 基盤へ”

と題されて、ACID対BASEの、大胆なセッションをもたれました。
菅原さんにはeCcloud研究会でも重要な役割を果たしていただいています。
特にクラウド時代のデータモデルについての先行した研究や、JEANSとの協業での強いリーダーシップを発揮していただいています。
このセッションでは、IBMが新時代での大本命と考えているDB2 pureScaleの詳しいお話と、それ以外にもいろいろとプライベート・クラウドやそのデータモデルについてのお考えなどを述べておられます。
菅原さんはIBM Stream Computing、"InfoSphere Streams" のエバンジリストとしてもご活躍されているようですが、そのお話は今回は含まれていないようです。
　YouTubeなどにもアップされている動画を拝見させて頂くと、少し不自然な映像があるので直接お伺いしました。実はWebでは少しカットされているとのことでした。カット部分は菅原さんのお話の肝のところなので、主催されている根本さん（？）の編集の苦労をお察しいたします。
カット部分は、JEANSとプライベート・クラウドとの接点になる、サービス・リンク・ア－キテクチャの部分と、その具体的なプライベート・クラウドへの実装のあたりのようです。
　JEANS、即ちeCloud研究会では、伝統的で制約の多い、HW→OS→MW→Apps というスタック・アーキテクチャから脱出し、クラウドを活用したサービス・リンク・ア－キテクチャを提案しています。
これがJEANS (JTO Enterprise class virtual Appliance for New Service) のコアの考え方です。
この点の詳細は、別途、昨年からストップしたままの”クラウド・データモデル”の研究スレッドへの追記とともに、菅原さんにeCloud研究会の方にも投稿していただく予定です。

RDMA(Remote Direct Memory Access) 実装の背景と将来

　菅原さんのセミナー全体の資料やビデオを見て強く感じたのは、小生が強く持っていたpureScaleに対する先入観の過ちです。pureScaleの技術を、小生の個人的なz の成功体験、つまりSysplexの発展系だと単純に考えていたことの視野の狭小さへの反省です。
pureScaleの技術の一番大きな特徴は、RDMA(Remote Direct Memory Access)の具体的で本格的な戦略製品への実装にあるわけですが、これは恐らくクラウド時代におけるICT業界全体でのRDMA実装の静かな幕開けのように思います。
pureScale自身も、IBMのScale Out環境での戦略的技術としてどんどん展開されていくのでしょう。

　CAP, BASE の論議の背景の一つには、前にも論述しましたように、 ICT における”レイテンシー”、すなわち通信における遅延の宿命との、技術的な対決や解決があるわけです。
一方で、RDMAは以前からInfinibandベースの低レイテンシー・プロトコルとしては良く知られていました。
実際、SolarisやLinuxにもuDAPLなどコードとしては前から実装されているわけです。
それが実用化されなかったのは、プロセッサーやメモリー・アドレス機構などのHW系資源の同期型によるチャネル占有アーキテクチャが高価すぎたわけです。
レイテンシーは大幅に削減されるけれども、そのためにRDMAではCPUが繋がったままで、かつ相手方へのデータ直接書き込みの仕組みのコストが高かった。
それが、マイクロプロセッサーの大幅なマルチスレッド化や仮想化支援機能によって一気に実用化されたわけです。
32マルチスレッドのPOWER7とpureScaleという組み合わせで、LPARの仮想専用マシーンの利活用で、この占有通信チャネル全体を非常に安く占有してしまえるようになったわけです。
　DB2で共有ＤＢの方法として火ぶたは切られましたが、RDMAは本来オープンな通信プロトコルです。
IBM WebsphereのObject Gridが具現化したData Grid、クラスターのUniversal CacheやIn-memoryのコーヒレンス制御、さらには今はやりのKVSの本格的な企業展開においても、このRDMAやTOE, 各種アクセラレータによる低レイテンシー・プロトコル実装への機運が一気に進むことになると考えられます。RDMAも当然IP系の上に梱包され、ネットワークを超え、CAVES(Converged And Virtual Ethernet Switching)　の標準に乗るのでしょう。
　ＩＢＭ次世代スーパーコンピュータのPERCSでもこのRDMAを実装しているそうです。膨大な数のPOWER7を１対１直結しながらも、共有メモリーのアドレス空間を可能にするために、この辺の技術の巧みな活用がなされているようにも見えます。使いやすい汎用スパコンとして目玉になるのでしょう。
　
　少し大胆なようですが、RDMAを活用する製品化の予測は、Windows Server AppFabric のUniversal Cacheの構造や、Oracle Coherence やRACを持ち、Sunを買収したOracle の動機などを推し量ると、小生には当然のことのように思えてきます。

”本当はハードウェアなんてどうでも良くなっていく”、ことにはならない

　前のブログで、”本当にハードウェアなんてどうでも良くなっていくのか”、という疑問を投げかけましたが、答えは明らかに、NO! になると思います。

下図は、クラウド時代を睨んだ、分散処理システムを簡単にモデル化したICT 全体のイメージ図です。

個々のシステムがグローバル展開される中で、ICT のインフラはやはりクラウド化していくのでしょう。
その場合、上で論述しましたように、システム間の高速・低レイテンシー結合の要求は必須となります。
なぜなら、一般の業務系がBASEの設計要件を受け入れるとはいかにも考え難いからです。
一貫性を保証したままでスケールを出すためには、現在よりも遥かに高速・低レイテンシーの連結機構が必須になりますが、それが既にRDMAと仮想化・マルチスレッド化で可能となっているわけです。
これがさらにデータ圧縮化、暗号化などの様々なHWアクセラレータで強化されていくと想われます。
　ここではこれ以上詳しくは論考しませんが、RDMAを活用したシステム構成にも２つのタイプができるのではと考えています。スケール処理中心のデータ・キャッシュ型と、伝統的なデータ中心型のシステム構成が区別されるようになると考えられます。企業系システムの未来形であると考えられるプライベート・クラウドおいては、やはりデータ中心型の開発・運用になると考えられます。

　もう一度、何故RDMAだと高速・低レイテンシー化が可能になるのかを下図で説明します。

従来型の割り込み型の非同期連結に比べて、RDMAの同期型連結&直接データ書き込みでは、送受信両サイドでOSやミドルウェアの割り込みによるオーバーヘッドを削減することができます。
一方で、RDMAでは送受信両サイドでCPUが占有状態になってしまいます。この占有状態をマルチスレッドや仮想化で受けてやることによって、実占有コストを最小限に抑えることが出来るのです。

　これからも、通信系の強い低レイテンシー化の要件に対して、Server, Storage, Network などの技術は、HWアクセラレータを基礎に据えたHolistic Design（全体統合設計）が当たり前になっていくのでしょう。
データの一貫性、永続性、すなわちACID属性は、アプリケーションにその責任を投げるのではなく、やはりプラットフォーム系の技術として解決されていくのだと考えます。
　より自由度の大きい柔軟な非同期通信処理は、一方で大変重要になると想われますが、それはBASEのいう HW 系の進歩がダメになるからではなく、逆にしっかりとしたICT技術をベースにして、ビジネスやセマンティック系のチャレンジなどで、自由奔放に活用されることになると考えます。
↑

D-0014　マイクロプロセッサーの技術論は、クラウド時代ではどうなるのか？
　　　2010年2月14日　中島丈夫　投稿

本当にハードウェアなんてどうでも良くなっていくのか

　最近のクラウド論などを見ていると、益々、コンピュータのハードウェアなんてもう何でもいいのだ、安ければいいのだ、という論が大勢を占めているように見えます。
ま、それだからCAPだ、BASEだ、と論が進むのではないかとも思います。
また、企業システムにおける運用系の大変さ重要さが軽視される遠因なのではとも思っています。
これは今に始まったわけではなく、ダウンサイジング以来、理論的にもビジネス的にもそうですよね。
2000年に一世を風靡したClayton Christensenの"Disruptive Technology“が、IT業界のコモディティ化の宿命の定義のようになってしまい、さらには、Nicholas Carrの"IT Doesn't Matter" も、反語なのかどうかは知りませんが、IT丸投げ論を加速させました。結局はその流れに加担することによって、悲しいかなＩＴ屋自身が先細りのビジネス・モデルを推進しているようにも見えます。。

　何度も勝手に引き合いに出してご本人に申し訳ないのですが、UC BerkeleyのDavid Patterson教授などは、FPGAなどを使って全く新しいプロセッサー・アーキテクチャを模索中のようです。
小生はold SEで、きちんとした教育を受けたこともないずぶの素人ですが、プロセッサー・アーキテクチャが今また革命の前夜にあるように思われます。例えば、SUNの一旦は失敗はしたROCK のようなTransactional Memoryなどのスタイルがマイクロプロセッサー・ア－キテクチャの主流に踊りでるのかもしれません。CAPやBASEが顕在化させているスケーラビリティの要件が、最先端のハードウェア系の学者や開発者を突き動かしているのでしょう。
このISSCC 2010で、IBMの（結構昵懇の）Charlie Johnsonが "A wire-speed processor" なる概念を提唱しているようです。詳しくは存じませんが、SUNのNaiagaraがこの業界に投じた新しいアーキテクチャの雛型が、クラウド時代に向かって、新しい形で動き始めているのかもしれません。
IBM gives birth to 'wire-speed' processor
　日本の国家スパコンの開発についてはかなり辛口の意見を持っていますが、実はこのような常識外れ（？）の挑戦が、この国を強くするのかもしれません。

というこで、マイクロプロセッサー選択の技術論やその背景についてホメオトシスに書くことにしました。
特にIBM POWER7 vs. Intel Tukwilaの比較などをじっくりと書こうかなと思っています。
Intel Nehalemが愈々本格化する時代背景の中で、論がどんな風に展開するのかどうか。
気が向けばザット目を通していただければと思います。
IBM POWER7は次世代IBMスパコンの主役でもあるわけですから、少し丁寧に見る必要がありそうです。

また、クラウド構成論では、リンク・アーキテクチャについてのご質問もいただいています。
これももう少しきっちりと書きたいと考えています。
↑

D-0013　 Scale OutアンチテーゼとeCloud構想：中島の考え
　　　2010年1月30日　中島丈夫　投稿

　竹嵜さん、お久しぶりです。
御社、Virtual Technology、を創立され、インターネット・スケールの世界観をベースにご活躍されている姿を遠くから眺め、大変頼もしく、また尊敬させて頂いています。
Virtual Technology のWebサイト、”ぶいてく”、も時々拝見させて頂いて、相変わらずの鋭い切れ味に感嘆しています。
小生も昨年の３月末に日本ＩＢＭをリタイアし、このサイトを何となく始めてから年を越してしまいました。
その間、Web世界の先輩に一言の連絡もせずで、申し訳ありませんでした。
実のところ、小生の実体は、竹嵜さんとは大違いで、全くのWeb乞食の托鉢僧の体ですので、恥ずかしくて見つからないようにしていたのですが、なんとなく手を出したGoogle AdWords で見つかってしまいました。
本当は、ホメオトシスのスレッドで、竹嵜さんをネタに、北城さんとの昔の顛末を書いてやろうと思っていたのです。
竹嵜さんの勤務時間に対する当時の鷹揚さ（？）が北城会長の眼に触れて、アドミ専門のスタッフを付けられそうになった話です。中島には管理能力が全く無い、というご判断をなされたらしい。
勿論それで研究所長を首になったわけではありませんが。。。

　余談が長くなって、本論を書く時間が減ってしまいました。
http://blog.virtual-tech.net/2010/01/scale-outecloud.html でのご意見を拝見させてもらいました。
竹嵜さんのご指摘のとうり、小生は相変わらずの”無茶苦茶発言”を繰り返しています。
でも、ま、一応は確信犯ではあります。
竹嵜さんのようなバリバリの現役リーダーを差し置いて、リタイアしたポンコツのドン・キホーテがブツブツ言うのも大変オコガマシイのですが、ザックリ言ってしまえばCAPやBASES 理論が気に入りません。
のっけから、”気に入らない”、では議論にもならないのですが、ま、本音のところはそういうことです。
　昨年、（前）日経コンピュータ編集長の谷島さんにもブツクサ申し上げたのですが、今のクラウドに関するITの風景は1990年代のダウンサイジングのころにそっくりだ、ということです。
で、歴史から学ぶことも少しは益があるだろうと、温故知新というテーマで昔話をホメオトシスに書き始めていました。何が似ていて、何が違うのか。
今も昔も、小生には保守的な顔と無茶苦茶をやる顔とが ill-structured にぐちゃぐちゃになっています。
このCAP定理やBASE理論のお話では、猛烈に保守的な顔が出てきそうです。
以下、eCloud研究会のディスカッションというよりはホメオトシスになりそうですが、お許しください。
また内容が冗長なので、適当に拾い読みしてください。

はじめに

　　この話題にあまり造詣の深くない方のための蛇足です。
これらの議論の発祥地は超スケーラブルなＷｅｂサイト開発者の現場にあります。ですから、企業システム中心の元IBMerの小生の小言は所詮戯言になってしまうわけですが、クラウドと企業システムの関係が深まるにつれ敢えて強く踏み込むことにしました。
小生は一貫して仮想化とSWアプライアンスによるプライベート・クラウドを主張していますが、同じクラウドでも見ているＩＴの風景が大きく違います。
　パブリック・クラウドがクラウドの本家であるのは自明です。その文脈では小生のようなプライベート・クラウドの主張は海賊行為そのものなのですが、その動機や技術の主張はこのラマンチャ通信の全体を見て評価していただくしかありません。企業システムの諸々の課題を解きたいわけです。
それにはいろんな技術を活用したい。その体系をプライベート・クラウドと呼称しています。
敢えて老いた首を世界に晒しています。ドン・キホーテです。

ブリュワーの CAP 定理：の三つの要件とは一貫性(Consistency)、可用性(Availability)、分割耐性(Partition Tolerance)で、Webビジネスのような超スケーラブルなシステムでは技術的にこれらのうちの２つしか両立しないという理論です。結果的に一貫性(Consistency)を緩くして工夫しろ、という主張です。

BASE理論：はそれをトランザクション処理に踏み込んだもので、Basically AvailableとSoft State、そしてEventually Consistencyの頭文字を取った呼称です。同じようにConsistencyを緩めろという主張です。
データベース・トランザクションの世界には伝統的なACID(Atomic, Consistency, Iisolation, Durability)があるわけですが、これを乗り越えろということです。
　小生が問題に感じているのはBASEがACIDの一般型であるとの主張と、それ故に現行のシステム開発の常識を根底から覆そうとしているところにあります。
小生は元々ACIDが好きではありませんが、BASEの主張に往年のダウンサイジングの風景がオーバーラップして、逆にACIDを強く守る衝動に走ってています。
BASEは企業系IT技術者が推進してきたWS-*(Web Service astar)と動機的には似ているのですが、一方でグリッド的なコンピューティング・イデオロギーがバックボーンにあるような気がして好きになれません。特にRESTfullというWeb 2.0の正当な成功に紛れ込んだ不純な動機が小生には見えて嫌いです。

KVS:: はKey Value Storeの略です。これはGoogleやAmazonのデータ・モデルとして実績のあるもです。
やはり超スケーラブルなWeb世界のビジネス・モデルが背景にあります。で、企業システム開発の殆んどが依存してしまっている Codd & Date のRDB(Relational Data Base)モデルを大幅に逸脱、ファイルに近い先祖帰りして、クラウドのビジネス／システム要件を達成しています。
ここでも一貫性(Consistency)を緩くしてスケーラビリティを達成する事が主張の狙いです。
KVSはBASEと違ってイデオロギーではなく既に大きな実績があります。
そこで、GoogleやAmazonのデータ・モデルや運用処理系のオープン・ソースのクローンが１０種類以上出現して、これでプライベート・クラウドにビジネス・モデルとして進出する動きが本格化してきています。
Web ServerやJavaの時と同じような大きな成功を収める事ができるのかどうかは、IBMやOracleなどの企業系の動きが鍵を握っていると想われます。

ICTにおいて、”レイテンシー”は根源的な課題．今さらCAP定理だと言い出されても。。。

　さて、CAP定理の主張の技術的な背景は系におけるレイテンシー、遅延にあるわけですよね。
これで真っ先に思い出すのが、ソニーの元副社長兼 COO の久夛良木さんの破天荒な発想と要件です。竹嵜さんは小生を無茶苦茶を云うと仰いますが、久夛良木さんとの比較では小生など全くの赤ん坊のような可愛さです。尤も、久夛良木さんという世界の超大物の方と小生を比較するのがおこがましい限りなのですが。
　久夛良木さんはご存知のようにSCE(Sony Computer Entertainment)のあらゆる意味での父と呼ばれる方ですが、PlayStation 3に手をつけられ始めた2000年年初にほんのチョット接近する機会がありました。
彼の構想が国生み神話のような段階でIBMに協業のお声がかかり、最初のほんの数カ月ですが、小生がなんとそのプロジェクトのIBM側チーフ・アーキテクトを務めていました。ライン管理者を首になった直後で、技術者としてはなんとも心もとない状態でしたが、久夛良木さんの”日本のインターネットを何とかしたい”という大構想と付き合う羽目になってしまいました。当時の日本のブロードバンド化の遅れを、ゲームというエンターティメントを梃子に一気に大変貌させようと考えておられました。
で、世界に張り巡らせるICTの系全体の処理能力を、常識の３桁上を行け！という命題を頂きました。
1000倍にしろという事です。ま、今でいえばクラウド・コンピューティングの世界観ですかね。
で、サーバー系を世界の三極構成で、当時としてはもう滅茶苦茶なスケールの設計をやりました。
その処理能力を支えるために後にCell が発想されることになるわけですが、当方としては、当時のインターネット技術の世界から３桁ジャンプする技術推移を、図一枚に纏めて示す必要がありました。
構想の鳥瞰図のようなものですね。
久夛良木さんの夢をIT的に定義するために、性能要件をトランザクション性とトラフィック性の切り口で、そのコンビネーションとして当時の世界の超大規模Webサイトを俯瞰したかったのですが、３桁のサイジングを描き込めないわけです。３桁を一枚の図にするためには勿論対数チャートが必須ですが、トランザクション性とトラフィック性の両対数表示にすると、当時の世界のインターネットの先進システム群が相対的に全部一点に乗ってしまい、各社の技術の違いを全く表現出来なくなってしまいました。
そこでしょうが無いので、片対数表示でなんとか久夛良木さんにプリゼンしました。
”惜しかったね！両対数で描いて欲しかった。ま、それでも片方が対数表示なのは良しとしましょう”、
これが久夛良木さんから頂いたお言葉です。
　その後米ＩＢＭのDonofrio Sr.VPの下で、John Patrick などのＩＢＭのインターネット系リーダー達が集合させられ、プロジェクトが走り始めるのですが、その辺はまたホメオトシスに書きましょう。
小生は技術要件と現実のあまりのギャップに戦意を無くし、早々と離脱しましたが、最後にワトソン研究所のChris Codellaを引っ張りだすのには成功していました。Chris には1990年にVirtual Realityの日本でのデモ展開で大変お世話にになっていました。余談ですがVRのプロジェクトでは、システムならなんでも強いオールマイティの長野紘元IBM DEの大活躍があったのですが、これもまた改めてということで。
で、そのChris Codella が久夛良木さんに提示したものをベースにして描いたのが下図です。
　久夛良木さんは大変なJazzファンだそうで、東京、ニューヨーク、ロンドンに分散したご指名の各名演奏家の生演奏をリアルタイムなクアルテット構成として休暇先のバリ島で楽しみたい、というシステム要件をお持ちだったそうです。下図は、それはチョット原理的に無理では、、、というご進講図です。
当時はそれで情熱をひっこめられたようですが、今だときっと”実現しろ！”と仰るでしょうね。。。

　そのような意味で、CAP定理という学問的な主張と響きには違和感とともに限界を強く感じています。
Web 3.0の背骨にあたるクラウド・コンピューティングの背景には、いろんな夢や乱暴なアプローチがもともと一杯あって、それが昨今のモーバイルやAR(Augmented Reality)などの切り口で大きく飛翔しようとしています。セマンティックな処理系の面が一杯あるわけですね。それが何故かトランザクション処理の軸だけに議論が集約されて、あろうことか当たり前に作っておけば済む普通のアプリケーションまで作り方を変えないと守旧派だと厳しく弾劾されそうな流れになっている。
本当は、データのConsistencyなんてものをワーワー言わずに、データの前段階の膨大なイベント処理をどうするのかなど、素材の計算機を上手に応用してチャレンジするテーマは一杯あります。
で、計算機系のおおもとのatomicなConsistencyを壊したりしている暇はないと思っています。

左図は2004年3月ににIBMで行われた
”2010年のプロセッサー設計”　シンポジュームで、
UC BerkeleyのDavid Patterson教授の基調講演から引用したものです。
David Patterson教授はSPARCの開発者でプロセッサー・デザインでは今でも超有名人の方です。
分散システムや並列処理においてレイテンシーがシステム設計の最大の課題である事は当然の事としても、系のConsistencyを外してしまうという議論は全くありませんでした。
このシンポジュームには、Rick BaumなどのIBMのHW系研究開発のIBM Fellow達だけではなく、IBM SWグループからもDon FergusonやGrady Booch,などの多くのIBM Fellowが参集し、大変刺激的なミーティングでした。

Scale Outが必然だから、CAP定理も必然であるという議論は短絡すぎる

　さて、長い前置きはこれぐらいにして本論ですね。
クラウドの議論が、どうも計算機系の基本となるConsistencyをまな板にあげてグチャグチャにしようとしているように見えます。で、その背景がプロセッサーのコモディティ化を受けた、安いプロセッサーを上手に使ってビジネスに勝とう！という、相変わらずのClayton Christensenの"Disruptive Technology“ を焼き直した主張の蔓延です。今度はGoogle流のコンテナーにサーバー群をパッキングしたデータセンターのビジネス・モデルですが、それが何故CAP定理に直結するのかが小生にはよく解らない。
大きな処理系でどうデータの鮮度を保つかなどは、理論でもなんでもないわけです。
上にDavid Patterson教授の図を引き合い出しましたが、コンピュータの最先端の研究はそんな事に血道を挙げているようには決して見えない。最新の半導体テクノロジーを使って、いかにスケーラブルなプロセッサー系を構築するか。Consistencyの維持はプロセッサー系としては大前提です。
最近のスパコン国家プロジェクトだって、ダーティ処理で世界１になれるのなら苦労しないでしょう。
　
　ITの風景のスレッドで、Intel NehalemやIBM POWER7のプロセッサーに関する小論でも書きましたが、単体プロセッサー自身のScale Upはもうない。GHz向上や単体プロセッサー内の並列度向上などによるUni-processor 能力の競争は殆んど意味が無くなってきている。
Intel Itaniumの失敗がその典型例です。
　でも、チップあたりのムーアの法則、性能向上の法則は未だ生きている。マルチコア、マルチスレッドの話しですね。この４月頃にはIntel Nehalem-EXやIBM POWER7も８コア／チップで市場に登場しているのでしょう。IBM POWER7は４スレッド／コアですから３２スレッド／チップです。Intelなどのチップでは１６コア、３２コア／チップなどがここ数年のうちにも出てくるのでしょう。
チップ内のプロセッサーScale Outですね。
プロセッサーはどんどんチップ内でScale Outしていく。でそれをサーバー・プラットフォーム、クラウド・プラットフォームとしてどう組み上げると得なのかです。SMPとして組み上げるのか、クラスターとして組むのか、ネットワークを介してグリッドとして組み上げるのか。
Googleなどのパブリック・クラウドでは、そんな話は横眼で睨んで、モジュラーなサーバー群を大量にコンテナーにぶち込み、自社開発のミドルウェアでアベーラビリティやスケーラビリティを達成する。
ここではCAP定理やBASE理論がひょっとすると有効なのかも知れません。。。
一方で標準のIntel x86プロセッサーのSMPサーバーも、信頼性もあげながらどんどん大きくなっていく。
クラウドだとSMPのScale Upな増設課題も一応論外における。サーバーを一杯買う話とは別になる。
肝心なのは、仮想化などでクラウド・プラットフォームを構成した時には、上位のアプリケ－ションはクラウド・サービス化して下位のインフラのサーバー形態はアーキテクチャ的には実は何でもよくなってしまう。Scale Inですね。プロビジョニングで適切に配置していく。そちらの方がプライベート・クラウドでは受けるでしょう。運用・開発も含めた性能／コストが問題になる。資源活用率が大きく影響してきます。
一方で絶対的なスケーラビリティも問題ではあるけれど、単体のものすごい大きなアプリケーションなんてプライベート・クラウド環境では殆んどない。Web世界も含めたイベント処理に対応する大きな処理系では超Scale Outのストリーム・コンピューティングが対応する。
　ということで、バズワードがビジネスとして定着してきたプライベート・クラウドがカバーする企業系のスケーラビリティは、既存の商用系システムで十二分に達成される事になるでしょう。
例えばIBM POWER7だと32チップで1024スレッド／SMPになる。Hot Chip 21では、600万TPMのPOWER6の、プロセッサーだけだと5倍くらいスケールするといっている。今度発表されたpureScaleで100(台)ｘSMPにScale Outさせると、乱暴な概算ですが、(600万ｘ4)x100ｘ0.8 = 200000万TPMぐらいがStrong Consistencyな前提でも組める可能性がある。現行システムのSQL環境との完全互換でも、超スケールのプライベート・クラウドは組めるわけです。

　ということで、普通に考えれば、CAP定理とかBASE理論とかで主張する”アプリケーションから見たプラットフォーム系のConsistency はもう期待するな、システム開発の方法も抜本的に変えろ”、等という企業システム開発から考えるとパンドラの箱を開けてしまうような大変な議論にはならないと思います。
　OracleのSUN買収がやっとクリアされたようですが、IntelやIBM以外でも、SUNがクラウド時代のプロセッサー開発でまた活躍するかもしれません。ROCKで一旦失敗した Transactional MemoryによるConsistency遵守の超スケーラブルなプロセッサー・アーキテクチャも実現する可能性が大変高い。

　下の左図は、企業における仮想化への強いトレンドを説明するIDCの有名な図です。
物理サーバー数の暴発による運用系の管理コストの激増です。これは1990年代に物議を醸したダウンサイジングにおけるHW買い付けコストとTCO（Total Cost Ownership)の比較論とそっくりな議論です。
安いサーバーを一杯使えば一番いい、という考え方は、自前のしっかりとした運用能力を持つGoogleやAmazonのパブリック・クラウドには当てはまるのでしょうが、一般の企業ではとんでもない話です。
下の右図のように、企業システムは既存システムのメンテナンスなどの運用系に捕まって苦痛の塊
になっている。新規アプリをパブリック・クラウドに乗せればいいという展望など描くことさえ未だ難しい。
という事でeCloud研究会ではsmarter NFRを具現化するプライベート・クラウドに的を絞っています。

インフラがScale Outだから企業アプリケーションもCAPだという議論はもっとおかしい

　CAP定理の主張する、インフラやプラットフォームへの素材としてのConsistencyの仮定を外してしまって、アプリケーションに例外処理のループとその対応プロセスを持ち込むのは、いたずらにシステムを複雑にするだけではないでしょうか。そこのところが小生には全く理解できない。
企業システムにおいて、アプリケーションから見たプラットフォームのACID属性は必須でしょう。
Web系システムにおけるKVS(Key Value Store)の価値は十分認めます。
そしてWeb系のインフラ構築が、さらにITの大きな部分を占めていくのも了解です。
一方で、企業系システムが培ってきたRDBMSのConsistencyに依存したアプリケーション群の価値は、質量ともに計り知れないものがあります。ここでのトランザクション・システムの安定したACIDの実績ある枠組みを外して、BASE理論などとして一般化するメリットって、なんでしょうか。
CAP定理やBASE理論をACIDの一般型などと主張していますが、これは全くの別物に考えてアプローチすべきだと思います。でないとシステム開発の現場がいたずらに混乱するだけではないでしょうか。
（いまふと、３層ネットワーク・コンピューティングの設計時点の想いを思い出しました）
KVSの価値とRDBMSの価値は別物でしょう。一緒に論を混ぜて何か得るところがあるのでしょうか。
繰り返しますが、KVSの実効的な価値は十分実証されていますし、RDBMSに囚われないデータモデルの応用領域は幾らでもあるでしょう。事実 CEP(Complex Event Proccesing)やStream Computing の分野ではStreamSQLへの拘りはあまり良い結果を生んでいないようです。他にもインメモリーやオブジェクト・グリッドなど、高速・低遅延のいろんなアプローチはある。
しかしシステムのConsistencyを堂々と外してアプリケーションに委ねてしまう事の必然を語るアプローチは無かった。小生から見れば、このようなシステム観は、グリッド系技術のような計算機系そのものがアプリケーションと一体化している特殊な領域に限られた発想ではないかと切って捨てたくなります。
　以前にも eCloud研究レポートのスレッドR-0013に書いていますように、グリッドの議論は主にIBM STGのFellowであったJeff Nickが推進しました。彼は分散ネットワークOSレベルの計算機資源管理のプロトコルに、より上位の本来アプリケーション層に近いWeb Serviceのプロトコルを持ち込みました。それがWS-RF (Web Services Resource Framework)の採用ですが、その設計で結果的にIBM SWGのFellowであるDon Fergusonと激突してしまい、Jeff NickはIBMを去ってしまいました。其の時点でグリッド開発のエネルギーは停止してしまった。
一方で、本来のWeb ServiceのWS-*においても、やっと出来上がったWS-AtomicTransactionのACID特性がAmazonでのRESTの成功の余波を受けて霞んでしまってもいます。単純なRESTが勝った。
Webベースのシステムにおいては、系全体をACIDで押しまくる事の限界は既に顕在化しています。
また分散処理系の遅延の宿命が抱えるディレクトリー・サービスの大きな課題も残ったままです。
で、クラウド・コンピューティングという新しい革袋の登場となっているわけですが、其々が生い立ちの違う、ビジネスの分散・統合処理にフォーカスするSOAやWS-*の議論と、グリッドを原点とするインフラの分散処理系技術を混ぜて、新たな統一理論などを主張するメリットは少なくとも当面は小生には考えつきません。逆にクラウドの実用面での活力を奪うのではないでしょうか。企業システムの抱える３Ｋ，4Kの重い課題をさらに増し、一層の困難に導くのではないでしょうか。
”One size fits all" のシステムは過去にありませんでした。
小生は、クラウドにおいては以下のような２極化が進むのではないかと考えます。。

?パブリック・クラウド ⇒ 大量サーバー群をコンテナーにパッキング、ネットワーク機器で結合 ⇒ KVS

? プライベート・クラウド ⇒ 大型SMPサーバー + クラスター化 ⇒ 仮想化とスケーラブルDB(SQL)

一方で、Cassandra, Voldemort, Eucalyptus(Amazon Dynamo クローン), HBase (JavaベースのGoogle BigTableクローン)などの、オープンソースのプライベート・クラウドへの展開が加速しつつあるようにも見えます。面白くなりそうですね。

おわりに

　アプリケーションのpartitioning化は重要だと思います。
eCloud研究会では、partitioning化による柔軟性を、eVA(enterprise class Virtual Appliance)の導入によって具現化しようと考えています。
そこでは、OS/360出現以来のITの常識であるスタック構造の上にプラットフォームを積層させていくスタック・アーキテクチャからの決別を意図し、よりフラットなSaaS, PaaS, IaaSなどの多様なクラウド・サービスをソリューションに構成していくリンク・アーキテクチャを訴求していきます。
其の時の個々のクラウド・サービスのUOW(Unit Of Work)はACID属性が必須で、CAP定理やBASE理論でそこを解放してしまっては疎結合なコンポジションが構築出来ないと考えています。

　余談ですが、WS-* の議論の出発は、小生がIBM Academyの研究テーマとして、"Internet Transactional System" のプロポーザルを提言して始まったと考えています。ホメオトシスです。
これは竹嵜さんが、日本でも最初の本格的なWeb Serviceの応用であったヤマト・システムさんのシステム構築で、例外処理が全て”人間系CALL"になってしまうという経験を小生に教えて下さった結果です。
"Transactional System" とは "Transaction System" に非ず。されどCAP定理とかBASE理論とは別物だと考えています。ビジネス・プロセス層での、人間系の判断も入った分散・統合処理のゆるいACID結合です。

　最後に小生の本当の本音をゲロしますが、ACIDなガチンコのシステム設計は大の苦手で好きじゃありません。能力的にも出来ません。しかし、しっかりとした踏み台に頑張ってもらわなければ、ITが自由に飛び立つ事など夢のまた夢だと考えています。大変重要だと思っています。
２０１０年、良い年でありますように。
↑

D-0012　 Scale OutアンチテーゼとeCloud構想：質問
　　　2010年1月22日　竹嵜伸一郎　投稿

　ごぶさたしております。竹嵜です。http://blog.virtual-tech.net/2010/01/scale-outecloud.html に感想を書かせていただきましたが、CAPを同時に満たせるとしているところに疑問を感じております。CPUや単体システムの処理能力向上にフォーカスしていくのでしょうか。あるいは、分散KVSだけどスケールするACIDになるのでしょうか。後者だとするとリアリティに疑問が残ります。

↑

D-0011 eCloud研究会に匿名希望メンバー枠を作成しました
　　　2009年11月06日　中島丈夫　投稿

　以前から不評でしたeCloud研究会のメンバー名のWeb公開を、匿名希望のメンバーの方などは、一切表示しないことにいたしました。
これを機会にeCloud研究会に参画してみませんか？
当会は、日本ＩＢＭのJTO JEANSの研究をベースに、企業などの垣根を超えて、来るべきプライベート・クラウド構築の技術や価値探究を行う研究会です。
日本ＩＢＭのメンバーを核にして、米ＩＢＭの最新技術の応用も視野に入れています。
ビジネス上の他意はありません。ひたすら日本ユーザ企業システムのイノベーションを核にした、日本国ＩＴ加工貿易立国を錦の御旗に立てています。
何故、Intelだったら構わなくって、Oracleだったら許せて、マイクロソフト、Cisco、VMware,、HP、EMC、そしてGoogleだったらＯＫという理由が解りません。使えるものは使わなくては。。。

eCloud研究会への参画

 ↑

D-0010 ”出来ない論議”を展開するのはeCloud研究会の趣旨に反しますよね
　　　2009年8月19日　中島丈夫　投稿

　菅原さん、ありがとうございます。そうですね、eCloud研究会の目的は、新しい技術を積極的に発掘・活用して企業システムの課題の多くを解決するチャレンジにありました。
あれが出来ない、これも出来ない、という”出来ない論議”を展開するのは趣旨に反しますよね。
技術活用のスタディの結果、グーグルのインフラは使わない、ということでした。
　グーグル型のパブリック・クラウドでの大きな論点は、やはり、最重要な企業データを国境をも超えたローケーション・フリーに配置してしまう（？）という点ですね。GRC(Governance, Risk, Compliance) の論考の範囲を超越した物理的な原則です。またレプリケーション型のデータ・モデルでデータ整合性を担保するためには、アプリケーション層で 3-Phase Commit 相応の最終的なコミット・コントロールが必須だ、というところでしょうか。プラットフォーム側の厳密さに期待できないという点でill-structured なわけですね。利用者側の対応に任せられてしまうということです。逆にこの ill-structured さがグーグルのスケールを可能にしているわけですから、”角を矯めて牛を殺す”ことがないようにもしなければならない。
　これを”出来ない論議”で終わらせないためにプライベート・クラウドの主張があるわけですが、このアプローチに対しても出来ない論が強くあります。現行のきめ細かにカストマイズされた多様な NFR (Non-Functional Requirement) 構築に対応出来ないというのも大きなクレームです。
これも実は現行システム基盤が ill-structured なことが原因なわけですね。　語弊があるかもしれませんが、個別のシステム開発や作りこみで無理やり well-structured に見せている。　ということで、例えばNFRを出来あいの松竹梅で選ぶなんてのも”出来ない論”の集中砲火を浴びているのではないでしょうか。　まずこのあたりのベストプラクティスがシステム開発論には無いようです。
　eCloud研究会では、日本IBMのJEANS研究を受けて、"eVA: enterprise class Virtual Appliance" 構想でこの辺りを抜本的に構造改革したいと志しているわけですが、図３ではこれを企業システムのさらなる　"well-structured 化”と表現したわけです。仮想化やソフトウェア・アプライアンス絡みの新しい技術をクラウド・プラットフォーム系に活用し、システム環境をより well-structured にできれば状況は変わるだろうという主張です。チェンジ＆レジリエンスのスローガンの実現です。
また、 well-structured 化されたプライベート・クラウドは、スケールの点で現行の企業システムの範囲を超え、B2Bなどの新しいバリュー・チェーンやグローバル展開のシステム基盤に成長することが期待されます。データなどのGRSを保持しながらクラウドの名に恥じないスケールと新しいビジネス・モデルの実現が考えられる。また、図３の SMB (Small & Medium Business)の受け皿として、B2Bの関係を軸にしてクラウドを構成していく事も考えられます。このあたりの考察はパブリック・クラウドとの対比であらためて議論したいと思います。

　少し突き放した言い方ですが、コモディティ化という言わば”メーンフレームのお下がりの技術”を宿命的な技術動向として受け入れ、プラットフォーム技術の夢とチャレンジを放棄するのは、もうそろそろ終わりにすべきではないでしょうか。
コストが下がれば、プラットフォーム素材はなんでもいい、システム構築で頑張ればなんとか出来る、というSIer論理によるシステム開発論は、遥かに安いクラウド・モデルの登場で大きな岐路にさしかかっていると思います。プラットフォーム自身の改革を伴わない、ソリューション側での既存技術の延長線上でのスケールアウト・アプローチなどは真っ先にその洗礼を受けるのではないかと思います。コモディティ素材に立脚して大きく成長したソリューション開発が、新たな "disruption" に遭遇しているわけです。もう一度プラットフォーム側の可能性を見極める議論を小生は強く望んでいます。未来を切り開く新世代の企業システム基盤は、英知を結集すれば”出来る筈です”。それこそがグーグル的なグローバルの技術攻勢、ビジネス・モデル攻勢を日本のITが凌駕できる道だと信じています。

後半の論議は、このスレッドではなく、ITの風景で論じるべきものですね。また叱られそうです。
↑

D-0009 中島さん、議論が乱暴すぎると思います
　　　2009年8月09日　菅原香代子　投稿

　中島さん、グーグルのデータ・モデルが企業系基幹システムの現状に合わないからといって、錬金術呼ばわりするのは少し乱暴すぎると思います。eCloud研究会の目指すところが企業システムの革新にあるのはJEANSと同じ方向性にありますが、グーグルはグーグルで良いのではないかと思います。
中島さんもグーグルの熱烈なファンだと存じ上げています。あまり道を急がれと仲間が減ってしまいそうで心配です。　それに私たちのモットーは疎結合なシステムですからwell-structured一点張りのの議論もちょっと辛いです。中島さんはいつもill-structureの持つ柔軟性の重要さを訴えてこられたと思います。よろしくお願いいたします。

↑

D-0008 クラウドは新たな錬金術なのか
　　　2009年8月07日中島丈夫　投稿

　クラウド・コンピューティングの議論が大きくブレていると述べましたが、その中でもグーグル・スタイルのパブリック・クラウドが既存企業系システムも殆んど飲み込んでしまうのだ、という主張には異論をはさみたいと思います。　このような”乱暴な”議論に対抗してアンチ・クラウド論、”クラウド・バズワード論”が正統化され、”プライベート・クラウド”の技術によって企業システムの大改革を図りたいという小生の"Quest"はぶっ飛んでしまいかねません。
クラウドは魔術でも幻術でもありません。パブリック・クラウドの持つ大きな可能性が顕在化していますが、それが全てを解決するわけではありません。”one size fits all" なる絶対的なソリューションは過去存在しなかった。またグーグルが豪語する "世界中の情報を取り込む”可能性もほんのほんの一部で限界でしょう。ましてや企業システムのガチンコをやです。それを論考しなければならない。
　そこで”哲学への憧憬”のスレッドに、突然ですがＨ．Ａドレィファスの論文、”錬金術と人工知能”を乱入させました。中島の話はいつも飛びまくってついていけない、煙に巻かれるのが関の山だとよく小言をいわれますが、今回はなんと４０年前の哲学書に飛ばしたわけです。錬金術なんて言葉、フル～っというのっけからの罵声が聞こえてきます。
この論文引用の趣旨は、
グーグルのサーチエンジンを訴求した超大規模計算機網（クラウド）は
① 世界の知識の重要部分を占める "semantic"な情報を上手に利活用しているわけではない
② 企業システムの重要部分を占める"well-structured"なITシステムをカバーしきれない
の2点にあります。
　以下、Ｈ．Ａドレィファスの論文をシステム屋の視座にマップしてみました。この考え方で40年間、小生はシステムの特徴、難易度などを判別してきました。

図の拡大	横軸にForm(形式）を、縦軸にScale(規模）をとり知的活動領域を4分割しました。 Formの特徴を、Structured Data, Un-structured Dataで区別。またWell-Structured, Ill-Structured, Semanticの特徴も区別しています。要点は、いくら大規模なデータセンターを構築しても、Formの切り口の課題解決にはならないという点です。縦横の軸は峻別すべきですが、各軸の象限の境界は動的で可変です。第１象限でいうサービスは、PM　などで議論する”システム構築プロセス”におけるITサービスなどを意味していません。システム構築手法などの知的活動は、この図の象限をマップする、すなわち第１象限を第3象限に持っていくプロセスを指すと考えています。いわばメタ知的作業(link)ですね。
図の拡大	企業システムはWell-Structuredが命です。そのためにITエンジニアが血の出るような努力をしているわけです。それは基本的にはトランザクション処理としてのACID性が基本です。情報系もその延長線上にあります。ill-Structuredなデータ系ではGRCが回りません。翻ってコンテンツ系データのスケール処理を目指したKVSでは課題が多い。eCloud研究スレッドのデータモデルを参照されたい。勿論ユーザー責任のデスクトップＰＣ処理などはこの論の外にあります。
図の拡大	ということで, グーグル型のクラウドのカバーする企業内領域は、エンドユーザーの目の届くill-Structuredな処理系が中心になると考えられます。一方で、eCloud研究会が訴求するプライベート・クラウドは、アプライアンス・アーキテクチャ導入による、よりwell-Structuredな企業システムを目指すことになると考えています。 ”one size fits all" が難しいため、プライベート・パブリックやプライベート・プライベートのハイブリッド・クラウドが重要となると考えられます。

　eCloud (Enterprise Cloud) 研究会の主張は、次世代企業データセンターのあるべき姿の具現化ですが、バズワードである”プライベート・クラウド”の旗を押し立てて、少しづつでも賛同者を増やしながら、課題を克服しながら、理想に近づきたいと思っています。よろしくお願いいたします。

↑

D-0007 バズワードはイノベーションの旗．魔術・幻術ではなく忍術(忍ぶ術）が鍵
　　　2009年8月02日中島丈夫　投稿

　最近小耳にはさむクラウド・コンピューティングの議論が大きくブレているように思います。
例えばクラウドという魔術が、現行の企業システムを（いずれ）、Google型のスケールアウトの別世界に変えてしまうというような、ま、暴論。　あるいは逆に、サーバー貸しに毛の生えたようなハウジングでの仮想化をクラウドの一種のように化けさせてしまうという幻術。　そういう節操の無さが”バズワード”だから、やはり”クラウド・コンピューティング”ってのは典型的なバズワードなんだ、という全面否定論。
小生はこれらの議論・風潮に大きな危惧を覚えます。　
　バズワードはイノベーションを起こす風の流れを顕示する旗として大変重要だと考えています。
しかし明治維新の大きな潮目を作った”錦の御旗”のような魔術・幻術の効果は到底望むべくもありません。そうではなく、賛否バラバラの意識・スタンスを揃えながら一歩一歩目的に近づいていくための旗印だと思います。そのためには、匍匐（ほふく）前進に似た艱難辛苦に耐え忍ぶ、忍術の技量が鍵となります。それは一度は幻滅とともに忘れ去られても粘り強く再起する意思と挑戦です。
　eCloudの主張は、次世代企業データセンターのあるべき姿の具現化ですが、バズワードである”プライベート・クラウド”の旗を押し立てて、少しづつでも賛同者を増やしながら、課題を克服しながら、理想に近づきたいと思っています。よろしくお願いいたします。

↑

D-0006 本当の需要はサーバー・クラウド型にあると考えています
　　　2009年6月23日中島丈夫　投稿

　いいポイントですね。
詳しくは、この話題をいただいて、解説をeCloudの研究レポートの方に書かせていただきます。
R-0007書き込み
ポイントは、
・Stream Computingなど、これからの複合イベント処理などの新しい領域では、データベース構成方法も含めてScale Out志向が当然強い。データベース論も活発になるでしょう。
・一方で、現行のIT投資の70%は現行システムの運用・メンテにあてられている。
・スケールアウト・クラウドのアプリケーション的な拡がりは、現在、5%程度。95%は現行システム。
・お客様のペイン・ポイント、IT世界の3K,4Kの苦渋もこの95%での話し。この面ではテスト・クラウドなどの柔軟な計算機資源のプロビジョニングなどで、サーバー・クラウドへの期待は顕在化している。
・特にSQLなどのデータお作法なども含めた現行企業システムとの互換性の壁は、スケールアウト型にとっては大変大きいチャレンジである。

サーバー・ビジネスのポテンシャルをマーケット分析的にみれば、トランザクション分野の将来は大きくないのですが、インフラをクラウドと捉えて、企業システム・トランスフォーメーションの要に据えれば、サーバー・クラウド型のポテンシャルは大変大きく、小生は本命だと考えています。
いずれにしても、両クラウド論とも、課題はSE側、アプリケーション構築側の技術力にあります。

また、両クラウド間の連携は必須ですから、クラウド・マネージメントやインター・オペラビリティなどの標準化が、JavaやWeb Serviceの過去の例のように当然始まると思います。

↑

D-0005 W/Lとしては　どう分類すればいいのでしょうか？
　　　2009年6月23日匿名希望　投稿

　サーバー・クラウドとスケールアウトですが、W/Lとしては　どう分類すればいいのでしょうか？
たとえば大規模W/Lとありますが、RFIDなどセンサーから発信される情報を処理するという意味では
大規模W/Lになり、それはスケールアウト型（IBM iDataPlexとか）が適しているということになるでしょうか。
IBM zのようなシステムはそのデータを受けてDBでぐるぐる　というところに限定されていくのでしょうか？

↑

D-0004 サーバー・クラウドとスケールアウト・クラウドは別物
　　　2009年6月22日　中島丈夫　投稿

　濱田さん、全く同意です。
クラウドにはクラウドの経済性やグローバル性などの本質的な特徴がありますが、off-Premises(企業外）であることが前提ではありませんよね。その意味で”プライベート・クラウド”が単なるアウトソースのデータセンターに限る話ではなく、次世代企業データセンターの典型になる可能性も大きいわけです。小生は逆にそれが本命だと考えています。
ご存知のように、パブリック対プライベートの区別とは別に、クラウドには次のような２つを区別すべきであるという主張が以前からあります。

”サーバー・クラウドとスケールアウト・クラウドは別物”、NIKKEI COMPUTER 2009.1.15 （原典フォレスター・リサーチ）

“There Are Two Types Of Compute Clouds, Server Clouds And Scale-Out Clouds Serve Very Different Customer Needs”,Forrester Research, November 21, 2008

JEANSはこの区別を強く意識しているわけですが、eCloud研究会としてもこの点を訴求したいと思います。原典には著作権があり掲載できませんので、こちらでズバリ図にしてみました。誤解を生む可能性もあります。R-0007

↑

D-0003 ”eCloud研究会” 参画について．企業システムでの導入ステップ
　　　2009年6月16日濱田正彦　投稿

　濱田と申します。初めて書き込みます。クラウドはバズワード化していろんな意見が出てきています。
特に仮想化技術を使ったカスタマー・データセンターを“プライベート・クラウド”と呼ぶのが気に入らないという意見もありますが、企業の既存のシステムをクラウド環境で使えるためのステップとして“プライベート・クラウド”こそ必要なのではと考えます。企業で使われている現在のIT環境のアプライアンス化をいかに、これまでのIT知識にマップして実現できるかが、このステップの実現の可否につながると考えます。JEANSがこの具現化を進めているようです。多くの意見を取り入れながら稼働可能なアプライアンス化を実現できるよう意見交換したいです。よろしくお願いします。

↑

D-0002 ”eCloud研究会” 参画について．JEANSの背景
　　　2009年6月11日　菅原香代子　投稿

　昨年は中島さんの奮闘努力により、日本IBM社内のJTO (Japan Technology Outlook)タスクの一つとしてJEANS (JTO Enterprise Appliance for New IT Services)が立ち上げられ、それなりの成果を得る事ができました。この結果報告につきましては先日、日本IBMのISE Technical Conferenceで一般にお話しさせていただきました。
中島さんがリタイアされた後、私達は本年も引き続きJEANSのスタディをIBM社内で継続いたしますが、私たちの課題はお客様環境での実証性にあります。多くの技術的な課題が残されていますが、お客さまやパートナーさまと広く技術ディスカッションを進める事が前進のための方法として重要だと考え、１個人としてeCloud研究会に参加させていただくことにしました。よろしくお願いいたします。
　私たちのJEANSは、アプリケーションと基盤を疎結合化し、サーバー・クラウドなどの最新技術でアプライアンス・フレームワークを構築する企業システム革新への提案です。日本のお客様のIT変革を阻む大きな要因として、IT環境における強い安定志向と、それを達成するための案件個別のきめこまかな非機能要件（NFR）の作りこみが考えられると思います。この密結合に起因する変化対応能力の課題を解決できれば、グローバルな競争を凌駕する開発、保守、運用の革新を起こすことができると考えます。アプリケーションと基盤をNFRにフォーカスして疎結合化するために、新しくアプライアンス・フレームワークを設計し、いろいろとお客様実環境での実証性をスタディしたいと考えています。ミッションクリティカル環境にフォーカスし、仮想化技術やクラウド・コンピューティング技術を最大限活用してこの構想の実現をめざしています。

↑

D-0001 ”eCloud研究会” 発足について
　　　2009年6月2日　中島丈夫　投稿

　企業システムの在り方について、随分前からあれこれ思考（？）錯誤を重ねてきました。直接のきっかけは1990年代初頭のダウンサイジングでした。
索敵の意図で当時のダウンサイジング講習会に出席して大きなショックを受けたのを今でも鮮烈に覚えています。エンドユーザ部門の方がスクッと立ち上がって、「IT部門こそが敵である、絶対に打ち倒さなければならない！」と真顔で主張していました。そのIT部門を陰で糸を引いているのがITベンダーだという含意には、正直情けなくなりました。あれは確かに文化大革命だったですね。。。その拠って立つ技術論は、any to any のマルチ型のClient/Serverモデルでしたが、要するにどんなに複雑なものでもエンドユーザーの欲するシステムがアットいう間に安く手に入るというものでした。手品みたいな話でしたが、大変なうねりとなり、IBMが50億ドルの大赤字を出して倒産しかけた程でした。小生はコンピュータ・オタクのプラットフォーム屋でしたが、少なくとも現場育ちのSEとしてこの論を許すことはできませんでした。以来、責任あるプラットフォーム屋として、企業システムの変革を”容器の変革”と志して20年近く取り組んできました。CMOS & SysplexやJava化、Linux化、さらにはSOA化などを米IBMと歩調を合わせながら推進してきました。終わりの無い挑戦ですが、ここ数年は企業システムの”変化と安定”の両立を可能にするフレームワーク作りに挑戦しています。
　ダウンバッシングへの対策として過剰な程の安定化施策が日本ITの大きな特徴ですが、それが故の変化対応能力の欠如が日本のITの大きな課題だと考えています。この課題解決の方法としてクラウド化、仮想化、アプライアンス化を提言します。"Enterprise Appliance"構想です。企業システムをNFRの視点から仮想化、アプライアンス化します。この構想は企業基幹系システムの新世代データセンターへのトランスフォーメーションとして日本IBM社内の有志の技術者で研究されてきたものです。先日のISE Technical ConferenceでIBMの菅原技術理事がセッションを持たれたJEANSがそれですが、それを日本IT業界の共通の研究テーマとして、日本発の技術提言の場として”eCloud研究会”の設立を発起します。

↑