オープンレガシーに学ぶこと。ユーザ企業主導のクラウド・アーキテクチャ構想が必要とされる背景
ここではユーザ企業側がクラウド・アーキテクチャを構想、主導する必要性について論述します。
クラウドを準備するプラットフォーム供給側のクラウド・アーキテクチャは、何回も述べていますように、Google以外は全て仮想化をベースに組み上げられています。伝統的なSUN
SolarisのSMPサーバーに自社開発のCRMパッケージをマルチテナント化していたSalesforce.comのシステムも、VMwareの仮想化ベースに転換しつつあります。
上図の上側の構造がその共通モデルです。
さて、そのようなプラットフォーム供給側のクラウドが本格的に市場投入されると、ユーザ企業の現行システムの課題、”既存システムの運用・メンテナンスが70%を占めている”、を解決できるのでしょうか。
クラウドの効果は大きなものと考えていますが、クラウドだけでは、小生は残念ながらそうはならないと考えています。
Googleのような、現行システムをWebアーキテクチャでスクラッチから作り変えてしまうという全く新しい方向性を持った方法以外では、、逆に運用上、ダウンサイジングの二の舞を踏む恐れも非常に強いと考えています。特に仮想化の方法に危険が大きい。
端的に言えば、今、企業ITを悩ませているであろうオープンレガシー・マイグレーションのどんずまりの再現の可能性ですね。
物理サーバーの単純な仮想サーバー化は、問題の先送りになってしまう可能性がありますし、そのさらなるクラウド化、ユーザのセルフマネージメント化は強力な麻薬として、ITガバナンス上の破綻をもたらす恐れが多分にあります。
下手をすると、新技術の後追いが、将来、IT部門にとって如何に危険かを身を持って知ることになるのかも知れません。
アマゾンＥＣ２では、IaaS/PaaSとしてユーザー側が選択出来るテンプレートが千種類以上あるやに聞きますが、これらのメンテナンスを
ＩＴ部門に投げ込まれたら何が起こるのでしょうか。
プライベート・クラウドでも同様の、運用上の柔軟性とガバナンスのトレードオフが顕在化すると考えられます。
さて話を進めます。オープンレガシーの出発点は、当時のIBMに代表されるメーンフレーマの垂直統合モデルから、マルチベンダーによる技術の自由な組み合わせ、水平モデルへの脱皮だったわけです。
ところが、自由で柔軟なシステム作りの教訓は、オープンレガシー・マイグレーションのどんずまりということになってしまいました。
最初のクライアント・サーバー・モデルでは、確かにOSとサーバー側のDBの組み合わせしかない水平モデルだったわけですが、そのモデルの性能・効率面での限界から、直ちにTuxedoやEncinaなどのTPモニターが出現し、ミドルウェア積層の垂直統合モデルに戻ってしまいました。
上図で示すスタック・アーキテクチャですね。
スタックの積層構成がマルチベンダーの組み合わせになった分、メーンフレームよりも遥かに複雑な管理となってしまった。
スタック構造をそのまま保持して、仮想サーバーの延長線上にIaaS/PaaSを置いてしまうと、何が起こるのかは容易に想像がつきます。
スタック型アーキテクチャの本質にある親ガメ子亀の相互依存性と、メンテによる輻輳が時間と共に両者を不可分にしてしまう罠です。
これはなんとしても避ける必要があります。
一方で、プラットフォーム供給側のクラウドが本格的に市場投入されることによるユーザ企業側の危惧は、クラウドの囲い込みです。
以前から識者の方々が警鐘を鳴らしておられましたが小生はたかを食っていました。先ずクラウド化への流れを作ることが大事で、囲い込みは各社固有の技術や戦略が見えてきてからの心配だと考えていました。
でも、それが愈々顕在化し始めました。
IT業界の垂直統合への動きとクラウド・モデルのハイブリッド・クラウド化への加速です。
垂直統合では先ずLarry Ellisonがそのラッパを鳴らしましたが、先日SAPもSybase買収とともに明確にその意思表示をしました。
IBMなどもその成長モデルを企業買収にさらに大きく傾斜することを表明しています。
さらにハイブリッド・クラウドへの流れも、最近のマイクロソフトの製品発表などを見ると急速に進みそうです。
ＩＴＩＬされどＩＴＩＬ。一見、ハイブリッド・クラウドの方法はユーザ企業にとってのメリットの大きい現実解に見えますが、先陣争いが過熱すると、準備されたハイブリッドの色合いが急速に増し、プライベート・クラウドとあまり変わらない選択枝の強要になりかねません。
システム管理製品群による囲い込みによって、自由な雲に乗る筈がいつの間にか蜘蛛の巣に絡まる可能性が強く成ります。
ということで、クラウド化への流れはユーザ企業にとって大きな救世主になる可能性があるものの、逆に、あのダウンサイジングの変革と同じ文脈での危うさが内包されていることが解ります。
ここでの主張は、そうならないための、ユーザ企業のアーキテクチャ的な準備が必須だという点にあります。
垂直統合は、ITアプライアンスによるスタック構造強化への回帰モデル
さて垂直統合は、技術的に見れば、IT業界成長の最大のブレーキになっている技術と製品の複雑さを克服するために、アプライアンス化を積極的に図るビジネス・モデルということになるでしょう。ハードウェアからアプリケーションまで全部一式バンドルしてしまう事で、個々の製品内部の複雑な構造や組み合わせを全て隠蔽して単純化してしまう。スタック構造の強化です。
価格付けの面でも、いろいろと面倒で足を引っ張る個々の価格付けの詳細を隠蔽してドンブリ勘定で販売する。
ユーザー企業には最終価値を買っていただく。
ユーザーにとっては "out of the box" と云う事で、利活用の便宜さ、”コンシューマビリティ”の点で大きく改善されることにはなります。
このようなハードウェア同梱（？）のアプライアンスをITアプライアンスと呼びます。従来の比較的単機能型のアプライアンスをハードウェア・アプライアンスと呼び、これからは区別されていくでしょう。
例えばLarry Ellisonが昨年Sun買収発表時に発した雄叫びではExadata Version 2 が主役でしたから、彼の頭にはこのITアプライアンスが戦略の要として占めているのは確かだと思います。
しかし、今さらながらの垂直統合モデル、ある意味では囲い込みのビジネスが成功するのでしょうか？
IBMが法務省との争いに苦しんだ末、ソフトとハードとをアンバンドルしたあの独禁法に触れることにはならないのでしょうか。
Foebesの記事では、IBMがダウンサイジングに屈したのは技術のせいではなく、一般企業ユーザー部門が、IBM一社の囲い込みに対して激しい憎悪を持ったせいだと書いています。IBM = IT部門だった。
小生もこの見方に全く同感です。前にも書きましたが、当時の企業ユーザー部門の、ある意味横柄だったIT部門への激しい憎悪を目の当たりにして、身震いした思いがあります。
そして今、オープン・コミュニティが成熟し、クラウドが始動する現在、小生には囲い込みなどとても出来るとは思えません。
IT企業の蹉跌はそれはそれとしても、ユーザ企業にとっても大きな混乱をもたらすことが危惧されます。
ダウンサイジング時のIT企業側の混乱で、ユーザ企業IT部門が被った損失は大変大きかった
垂直統合やクラウド化で見せるIT企業の積極的な動きはそれはそれで期待すべき面が大きいわけですが、じっくりその動きを見据えると、必ずしも現状の企業ITの課題、運用とメンテナンスの大きな課題を解決してくれそうにありません。
それどころか、大きな混乱が待ち受けている可能性が大きいように見えます。
ミッションクリティカルな仮想アプライアンス、eVA(enterprise class Virtual Appliance)の提案
またまたのホメオトシスになってしまいますが、我々eCloud研究会の前身であるJEANS旗揚げの最初の動機は、現在ソフトウェア業界とユーザ企業が共に落ち込んでしまった、ソフトウェアの複雑さに起因する負のメンテナンス・スパイラル解決への挑戦でした。
このような負の循環を構造的に打開したいという願いでした。そしてその方法論として、アプリケーションをOS やMWとの密結合から解放したかった。またOSやMWのバックバージョンがもたらす新技術採用の停滞による企業ITの進化阻害要因を打破したかった。
そして、この動機が、新しくクラウド時代の進行と共に大変重要になってきたわけです。
クラウド時代では、このソフトウェアの構造的な課題が、クラウド故に決定的な問題としてIT部門に襲いかかる可能性があります。
企業の内外でハイブリッド・クラウド化が進むと考えられますが、この問題を放置したままでは、ハイブリッド化も、実現性の意味でSOAの二の舞になりかねません。逆にハイブリッドの名の下に垂直統合という囲い込みが進むことも考えられます。
クラウド時代を迎えるにあたり、IT企業の言いなりではないユーザ企業自身の構想や準備が必要だと考えます。
eCloud研究会のレポートにくどく書いてありますように、 小生自身はこの問題を解決する方法として、IBM S/360市場投入以来の業界常識、スタック・アーキテクチャからの脱皮を強く主張しています。
Larry Ellisonが回帰を主張する、1960年代のIBMの技術モデルそのものが問題なのだと考えています。
40年以上前に登場したIBM S/360以来、メーンフレームやUnixなどの違いを超えて、コンピュータ・アーキテクチャは積層型、すなわちソフトウェア・スタックの構造を常識にしています。このスタックの積層でシステムを構成する考え方はあらゆるアーキテクチャで常識とされ空気のような存在になっていますが、この構造こそがシステムの柔軟性を奪っていると考えているのです。（eCloud研究会1参照）
eCloud研究会では、ダーウィン的な世代交代のメカニズムによる生物界のチェンジ＆レジリエンスを真似た世代管理により、OSやミドルウェア変更や、アプリケーション修正のメンテの範囲を徹底的に限定して、テストケースの大幅な削減を提案しています。
そのために、VMwareが提唱した、クラウドの基本となる仮想アプライアンスVA（Virtual Appliance)の技術を積極的に活用します。
さらに、VAの技術をベースにして、eVＡ (enterprise class Virtual Appliance) フレームワークをプライベート・クラウドのインフラ上に構成することを構想しています。VAが比較的軽いアプリケーション環境を前提として考えられているので、これを強化したい。
eVAに明示的な版管理を導入して、OSやミドルウェアへの変更の際に旧版を分離・凍結し、実質的なアプリケーションのアプライアンス化をはかったり、さらに現行のミドルウェア・プラットフォームに相当する準システム的な共通機能をVAC(Value Add Capability)としてeVAから外に括りだしてリンクすることにより、アプリケーションのプラットフォーム従属性を薄めることを意図しています。
積層構造からの脱却を可能な限り進める。
これをさらにハイブリッド・クラウドの文脈まで拡張したのが上図のリンク・アーキテクチャです。
クラウドのPaaSアプローチは要検討
クラウド・サービスの大きな部分を占めて行くと考えられているPaaS (Platform as a Service) の積層構造は、結局は従来の固いスタック構造をクラウド上に再現するだけなので、Zapthinkのレポートでも、現在嵌まっているソフトウェアの課題を解決出来ずに禍根を残すことになるだろうと評価しています。実は、PaaSの範囲も依然として曖昧です。
この辺の突っ込んだ議論は、IT企業の製品動向を睨みながら、eCloud研究会のスレッドでこれからも論じて行くことになりますが、大変重要だと考えています。VACは積層型ではないPaaSを訴求していきます。DaaSとも呼ばれるDB系では比較的楽に達成できそうです。
勿論上図に描いていますように、リンク・アーキテクチャでは、PaaSも含めた全ての部分構成をリンク出来なければなりません。
話がそれますが、上図の共通アーキテクチャではvmイメージを中心に描いていますが、vmイメージと仮想アプライアンスVA（Virtual Appliance)はほぼ同じものと考えて問題ありません。詳細はここ（eCloud研究会12参照）を参照ください。
さて、重要なことは、ITアプライアンスと仮想アプライアンス VA(eVA)の技術上の厳密な区別です。
ITアプライアンスはハードウェアとソフトウェアをバンドルした垂直統合の技術的な代表モデルであり、企業オンプレミスのコンシューマビリティを追求します。本来クラウドとは対極にある考え方のアプライアンス・モデルです。
通常ユーザ・アプリケーション実装のための汎用サーバーとは別に作りあげられます。
”Exadata Version 2” の講演でLarry Ellisonが主張しているモデルです。
一方で、仮想アプライアンスはクラウド・プラットフォーム上に展開する純粋にソフトウェアだけのアプライアンス・モデルで、アプリケーション実装の受け皿になります。（eCloud研究会2参照） 両者は本来対局にあるアプライアンス化のアプローチです。
eCloud研究会では、アプリケーションは仮想アプライアンスeVA内に、特別な機能追求は外付けのITアプライアンスにと、区別します。
小生はIBM FellowでWebSphereのVPであるクオモとこの件で激論をかわしたことがあります。
彼は以前からIBM DataPowerというITアプライアンスの主導者でもあり、大きな成果も収めています。
素直に考えると、ITアプライアンスとPaaSとは非常に近い関係にあるわけですが、アプリケーションを上に載せるのがPaaSです。
大変紛らわしいことには、ITベンダーがITアプライアンスをクラウド・プラットフォームとして売り出していることです。これはIBMがCloudBurstとWebSphere
CloudBuurstなどのブランド名で始めたことですが、各社が追従し、日経コンピュータでは”クラウド基盤アプライアンスが続々登場”という記事にしています
リンク・アーキテクチャではITアプライアンスも勿論構成要素となります。特にセキュリティやストリーム処理などの性能必須の分野ではITアプライアンスもVACとしてクラウドのコアになる機能を果たす事になると考えています。
リンク・アーキテクチャを実現する技術的な背景は十分に整っています
この研究レポートで主張したいことは、クラウド時代を踏まえて、ユーザ企業がアーキテクチャを構想・主導する必要があるということでした。そしてその一例として疎結合を徹底的に追及したリンク・アーキテクチャを構想してみました。
ITベンダーを差し置いて、ユーザ企業がアーキテクチャで主導することなど出来るのか、という反論が聞こえてきそうですが、それは充分可能だと考えています。
事実、このクラウド時代をけん引しているのは、元をただせばユーザ企業だったGoogleであり、Amazonです。
勿論規模が違うわけですが、Web 2.0で大きく前進したITコミュニティの実力は計り知れないものがあります。
ＩＴの風景のスレッドで、小生は体育会系と同好会の比喩で、メーカー系技術者とコミュニティ系技術者の役割を揶揄しましたが、
それは勝手な言い分ではありますが、日本のメーカー系技術者の奮起を促す意図がありました。
ここでの構想なども、同好会の乗りに違いありませんが、問題意識の深刻さの点で同じではないと考えています。
脱スタック構造の雛型は昔から沢山あります。IBMのIMS、MVS、VM/370、初期のクライアント・サーバ・モデルなどなど数え上げればきりがありません。最近の例ではSOAであり、ESBもそうですね。ただアプリケーションの層から直接切り離してしまおうという試みはあまりないと思います。
一方で、Javaの脱EJBに始まったRESTやFastCGI、POJOへの回帰は、Webコンテナーという横置き型のアーキテクチャの単純さへの衝動として、リンク・アーキテクチャとほぼ同じ動機にあるとと考えられます。
M&Aでベンチャー系技術の導入・統合を急ぐITベンダーにおいても、リンク・アーキテクチャ整備の必然性は充分にあります。
スタック構造の性能要件を凌駕するためには、リンク構造は大きなハンディを抱えることになりますが、IBM pureScaleで実装されたRDMAプロトコルのさらなる浸透や、インメモリーのクラスター展開など、Scale
Outの技術を中心に解決されていくものと考えています。
eCloud研究会のベースとなっている、IBM JEANSが愈々終了し、最終のレポート作りに入っています。
この成果を踏まえて、クラウド時代におけるソリューション・アーキテクチャの展望を引き続きレポートしていきます。
|
