eCloud研究会が考える、サンプルとしての”ユーザー企業主導クラウド・アーキテクチャ”の基本的な形を、上図に示します。
ここでは、今までの研究レポートを集約する形で、アーキテクチャとして、その概要についてまとめます。
ここでのテーマは、
・ （サンプル）アーキテクチャの概要
・ 前提となる、一般的なプライベート・クラウド論の簡単な整理
・ （サンプル）ユーザー企業主導クラウド・アーキテクチャの位置づけと技術的なフィージビリティ
・ 過去、枚挙に暇がないほど行われてきた数多くの標準化作業や、製品調達の業界標準などと、何が違うのか
になります
（サンプル）アーキテクチャの概要
サンプルとしての”ユーザー企業主導クラウド・アーキテクチャ”の基本的な形を、上図に示します。
プライベート・クラウドのワーディングなどの一般論を先ず確認されたい方は、ここをスキップして、次節を先にお読みください。
以下この節は、ですます調の箇条書きスタイルで記述します。
・ アーキテクチャのクラウド・プラットフォーム（システム管理系）の部分は、標準化が進んでいるDMTF、及びその OVF (Open Virtual
Machine Format) を基礎に置きます。
・ OVFは、仮想サーバー内で実行される多様な仮想マシン・イメージ(vmイメージ）を、XML記述によって、実行時点で必要なIT資源や、複数vmイメージ間の連携などの実行環境を記述したメタファイルと、実行形式そのものを一括フアイル化したものである。
各社・各種Hypervisor間のファイル形式でのポータビリティを確立する標準フォーマットである。
OVF は、各社のx86系Hypervisor のファイル形式の標準化から始まったが、IBMの zVM、POWER Hypervisor なども準拠の予定。
国産メーンフレーム系、Unix系 などのオリジナルなHypervisor でも準拠するものと考えられる。
さらに、これに付随したイメージ管理用の各種パッケージが出そろうものと考えれる。
・ ポーティングされたOVFが、各ITメーカー準備のクラウド・プラットフォームのメタ・データ解析を経て、各ITメーカーの実行用vmイメージ群が構成され、プロビジョニング機能により、実資源上に配置される。
・ 実資源上での実行制御は、各ITメーカーのHW固有のシステム管理となり、プライベート・クラウドではヘテロな環境が前提となる。
命令セットやOSレベルなどの異種混合（ヘテロ）環境を、過去のグリッド・コンピューティングでは標準化で統一しようとしたがほぼ失敗。
クラウドでは、IBMが進めているアンサンブルのような、グルーピングのアーキテクチャが普及するものと考えられる。
アンサンブルは、まずヘテロで詳細な実行環境を同種・同類にグループ化して管理し、そのグループ群をさらにクラウド管理する。
vmイメージのヘテロな個別性はOVFからのメタ情報で認識され、プロビジョニングによって適切に各HWプラットフォームに配置される。
・ クラウド・プラットフォームのユーザー・インターフェースは、vmイメージのライフサイクル管理補助で、セルフ・マネージメントになる。
クラウド・ユーザーは、Amazon EC2のようなセルフ・マネージメントなテンプレート対話によって、クラウド・サービスを選択・実行する。
・ クラウド・サービスは上記クラウド・プラットフォームで生成されるvmイメージが、SaaS / PaaS / IaaS/ xaaS などにパターン化される。
・ IaaS が最も原初的で、選択テンプレートのSW構成が白紙に近く、OVFを素にしたvmイメージはHW構成要件を基に動的に構成される。クラウド・ユーザーは選択したIaaSパターンに、アプリケーションや必要なミドルウェアなどを自由に構築できる。
・ PaaS のパターンでは、選択テンプレートにミドルウェアなどが実装されており、ユーザーはアプリケーション開発・実行の面で、IaaSに比較してより簡単に、素早くスタートすることができる。またHA (High Availability) などの実装も準備されることになる。
一方で、PaaSに導入済みのミドルウェア実行環境に依存することになり、ベンダーロックインの危険性は高まる。
上図の、SaaS / PaaS のスタック型のvmイメージがこれを表現している。図ではJ2EEや.NETを実行環境として例示している。
以上までが、比較的一般的なプライベート・クラウドの構成である。
以下それにアドオンされる、（サンプル）ユーザー企業主導クラウド・アーキテクチャについて記述する。
・ eCloud研究会が例示する、ユーザー企業主導クラウド・アーキテクチャは、変更の容易性と安定性を志向する。
それを実現するために、伝統的なOS、ミドルウェア、アプリケーションの明示的なスタック構造からの脱皮を指向する。
eCloud研究会ではこれをリンク・アーキテクチャと呼んでいる。縦にSW機能を積層するのではなく、横に展開・連携させるからである。
・ 伝統的なスタック・アーキテクチャを脱皮し、リンク・アーキテクチャを実現することは、これまでの常識を覆すことになり困難を伴う。
一方で、IT部門の課題である企業システムの変化対応への俊敏性、メンテを、安定稼働を保持したまま実現する上で、効果が大きい。
・ 技術的に最も容易なのは、PaaS / SaaS のスタック構造を維持したまま、バージョン(版）管理を徹底的に追及する方法である。
いわゆる、”塩漬け”の明示的な確立と強化である。安定した現行版を保持したまま、修正・拡張した新版を生成していく。
この場合、柔軟なバージョン（版）間の前後の移動をリンク構造として確立する。
・ バージョン管理の基礎として、仮想アプライアンス(Virtual Appliance) の技術/製品を活用する。
仮想アプライアンスは、技術的にはvmイメージとほぼ同じものであるが、vmイメージ内のSWスタックを隠蔽・保護し、バージョン（版）による可搬性、永続性を思想的に持つ。さらにSOAのコモナリティとバリアビリティの思想を具現化する具体的な方法となる。
一方で、DMTF OVF 系の標準ツール群の利活用が可能になる。
・ さらに企業システムの基幹系への適用のため、smarter NFRを指向し、eVA (enterprise class Virtual Appliance) をアーキテキトする。
eVAは上図のように、基本的にIaaS 指向であるが、明示的に版管理された SaaS / PaaS も包含する。
・ ITメーカーSW製品の”塩漬け”は、保守料金などの面で現在は課題が大きいが、クラウド時代の新しいTs&Csとして確立を図る。
ITメーカー製品の採用とは別に、仮想アプライアンス内に隠蔽された OS、ミドルウェア系の、オープン・ソース化も推進する。
・ 本格的なリンク・アーキテクチャを実現するためには、積層型に導入されたミドルウェアなどの機能部分を、仮想化上で横に括りだして連携する必要がある。 これはクライアント・サーバー・モデル以来、DB機能に関しては常識となっている。
クラウド環境では、上図のデータ・パーシスタンスの VAC / PaaS で示しているように、従来からのRDB以外にも、KVSやインメモリーDBなども搭載することになる。Hot Stanby や Active / Active などのHA(High Availability)実現もここで導入される。
・ VAC (Value Add Capability) は、somarter NFRを実現するために、eVAと対になってアーキテクトする。
一般に、ITメーカー系が準備するクラウド・プラットフォームのNFRはクラウド・サービスをサポートするための一般解であってその粒度は粗い。一方で、企業システムで要求されるNFRは多様でその粒度も細かいものが要求される。
そのギャップを埋めるために、文字通りVACとしてアドオンのクラウド・サービスをクラウド・プラットフォーム上に導入する。
これを、クラウド・プラットフォーム内に直接入れ込むことは、ベンダー・ロックインの危険も増え、本来の変更容易性にも問題が生じる。
・ VACがリンク・アーキテクチャの主要要素として定着すると、より一般的で柔軟性のあるアドオンのPaaS として、多様な準システム機能製品化が行われることになると考える。セキュリティの強化、モバイルとの連携、AR (Augumented Reality)のクラウド側サポートなど、
企業システムにおけるイノベーションと、ベンチャー企業の挑戦に大きな展望が開けよう。
一般的なプライベート・クラウド論の簡単な整理
一般的に、クラウド・コンピューティング（以下クラウドと省略）とは、IT実資源を利用者が簡単にクラウド・サービスとして利活用できることをさしますが、Google以外の形は、上図のような、（緑色の）仮想化の境界の上下によって、下部のIT実資源管理の部分と、上部に展開されるクラウド・サービスの部分とに、概念的に分離して構成されています。
通常、下部のIT実資源管理の部分をクラウド・プラットフォームと呼んで、上部の概念的なクラウド・サービスと区別しています。
IT実資源は、通常、サーバー（コンピュート資源）、ストーレッジ、ネットワークで構成され、その各々に管理体系がありますが、
ソフトウェアも含めたIT実資源を、クラウド・サービスとして多様に組み合わせて利用者側に切り出すために、クラウド・プラットフォームという全体を統御する管理体系がクラウド開発事業者によって準備されます。
このクラウド・プラットフォームを所有・運用し、多様なクラウド・サービスを販売する事業を、パブリック・クラウドと呼んでいます。
一方で、このクラウド・プラットフォームを商品として入手し、企業などが所有・運用する形態を、プライベート・クラウドと呼んでいます。
全社をオフプレミス（Off-premise）、後者をオンプレミス（On-premise）として区別され、クラウドは本来オフプレミスを目指すので、プライベート・クラウドをクラウドとしては認めないという議論も当初はありました。
また、クラウドのサイズ、スケールの大きさを判定基準にして、プライベート・クラウドをクラウドとして認定しないという議論もあります。
しかしクラウドの価値をクラウド・サービスの機能に置く限り、両者に大きな違いはなく、企業にとって必須のGRC (Governance, Risk, Compliance)の面で逆にオンプレミス（On-premise）、すなわちプライベート・クラウドが重要であるという考えが強くなってきています。
また一方で、プライベート・クラウドでは、上部のクラウド・サービスにあたる部分も自社用にプライベートに運用する以上、実質的に、次世代データセンターとの区別がつかない、という議論もクラウド論の最初からありました。
しかし、プライベート・クラウドに於いても、、パブリック・クラウドと同様に SaaS / PaaS / IaaS / などのクラウド・サービスの機能形態は準備され、これがパブリック・クラウドと同様に、企業内
ITの開発・導入・テスト・保守・運用などでの俊敏性を実現することになります。
次世代データセンター論に於いては、IBMのNEDCに見られるように、ダイナミックなデータセンター運用論が抽象的には述べられていましたが、この面での具体的な詳細は言及されていませんでした。
クラウド・プラットフォームを商品として出荷する ITメーカーによっては、次世代データーセンター構成のための機能部品を再利用する形で拡張・強化させているものがありますが、そのような場合でも、パブリック・クラウド
/ プライベート・クラウドのクラウド・サービスを実現するために、ビジョンや内容が大きく変更されています。
特に仮想化の面で区別がつき難いのが現状ですが、仮想アプライアンスなどの展開で、将来的には大きく違ってきます。
また、プライベート・クラウドの言葉に違和感を持つ論拠として、クラウド開発事業者が従前のサーバー賃貸のデータセンターを仮想サーバー活用に拡張しただけで、クラウドと呼んでいることへの反発もあります。
しかしこの議論も、多様なクラウド・サービスが現実になれば、自然消滅していくものと考えられます。
さて、以上がプライベート・クラウドの常識的な議論ですが、eCloud研究会では、さらに知の冒険を志します。
永年の懸案だったユーザー企業IT課題の解決に於いて、クラウド技術活用によって一歩でも前進できないか、というチャレンジです。
ユーザー企業主導クラウド・アーキテクチャの展望
先ず確認しておかなければならないことは、小生達の目指すユーザー企業主導クラウド・アーキテクチャは、あくまで、IT企業が準備するクラウド・アーキテクチャや商品を基盤にして展開する戦略にあります。またそれ以上のことは甚だ難しい。
ということで、ユーザー企業主導クラウド・アーキテクチャは、まず上図のプライベート・クラウド構成の基本に則ることになります。
ITの風景で記述したように、かっての富士通JEFの成功例などを参考にして、前後処理のアドオン的に構成することを考えています。
志は高く、されど技術的にはSE的発想による柔軟性と応用性に富んだ方法、ま、日本人の適性をフルに発揮しようということです。
海外の連中はこういう方法をあまり好まないし、不得手のようですので、これを逆に競争力に使う。
具体的には、クラウド開発事業者が出すクラウド・プラットフォームやクラウド・サービスを上手に包み込んでしまおうということです。
しかし従来のフレームワークの方法では後手を踏んでいたので、今回のクラウドでは先手を打ちたい。それがアーキテクチャです。
特に ”オバマ大統領のプライベート・クラウド” の項で述べた、クラウドの標準化、ベンダロックインの排除、そしてイノベーションの加速
、を達成するために、あらかじめアーキテクチャとしてマクロに押さえておこうということです。
さて、上図の（緑色の）仮想化の境界の上下によって、IT実資源管理と、ユーザー企業アプリケーションの展開に分離します。
下部のIT実資源管理は、通常、クラウド・プラットフォームと呼ばれ、ここの仕組みは、殆どITメーカー側が準備することになります。
そして、上部のSaaS / PaaS / IaaS などのクラウド・サービスと呼ばれる部分も、通常はITメーカーが差配することになるわけですが、
ここに”ユーザー企業主導クラウド・アーキテクチャ”を構成して、エンタープライズ・システム構築でのユーザー企業のリーダーシップを確保しよう、といのが
eCloud研究会の主張です。
勿論単体のプライベート・クラウドだけで企業システム全体をカバーすることができないので、パブリック・クラウドや他のプライベート・クラウド、既存システムとの連携を包含する、ハイブリッド・クラウドを視野に入れる必要があります。
これらの全体像は、リンク・アーキテクチャの提唱という形で議論しておきました。
その場合でも、上図のようなユーザー企業主導クラウド・アーキテクチャの構造が基本になります。
今までの企業システム構築は、特殊なケースを除いて、 ITメーカーが準備したアーキテクチャや商品を受け入れる形で実現してきました。
今回は、クラウドという大きな技術とビジネスの変曲点を積極的に利活用して、日本のIT業界やIT部門が先手を打とうということです。
実現への技術的なフィージビリティ
さて構想の技術的なフィージビリティを抑えておきましょう。
ここでは、今までeCloud研究会のレポートを振り返りながら、期待される価値と、技術的な可能性の背景について見ます。
さて、上図に於いて、上部左端の仮想サーバーは、十分に熟した技術となってきました。
しかしこのままでは、次世代データセンターの範疇のままです。クラウドとはいえません。
そこで、右側のクラウド・サービスのvmイメージの構成となるわけですが、この辺も既に十分に議論しましたし、標準化も進んでいます。
細かい仕様を別にすれば、vmイメージの形で SaaS / PaaS / IaaS などのクラウド・サービスを提供していくことになります。
例えば既に広く利活用されている Amazon.comのEC2の AMI (Amazon Machine Image)も、このvmイメージの範疇に入ります。
小生らは、ユーザー企業主導クラウド・アーキテクチャの主目的を、エンタープライズ・システムの革新においています。
そしてその革新を可能にするためには、チェンジ＆レジリエンス、即ち変更の容易性と安定性の確保が必須と考えています。
そしてさらに、変更の容易性と安定性の確保のためには、伝統的なスタック・アーキテクチャからの脱皮が必要だと考えています。
チェンジ＆レジリエンスを担保する 構造が、イノベーションを実現・加速することになります。
このようなイノベーションの例として、
”企業グローバル化対応でのプライベート・クラウドの活用”
”イノベーションの試行を可能にするスケーラブルなフレームワーク”
”SOAサービスのクラウド・サービス化がSOA実現の切り札”
”クラウド技術による新エンタープライズシステム・モデルと、IT業界の展望-１”
などを研究例として解説しました。
さらに、クラウドの標準化やベンダロックインの排除も、このアーキテクチャの主たる目的です。
eCloud研究会では、企業システムの解決すべき一番の課題を、”固有プラットフォーム環境への依存性からの脱却”においています。
この目的を実現するために、伝統的なスタック・アーキテクチャからの脱皮を試みます。問題の根源から解決しようと考えています。
この点が、従来行われてきた業界主導のAPIを新たに作り出すような、伝統的な標準化やベンダ独立の方法と異なるところです。
クラウドという、新しいコンピューティング・モデルへの転換点を積極的に活用して、アーキテクチャとして解決しようという挑戦です。
具体的な方法としては、”仮想化とアプライアンス化の視座”をアーキテクチャの思想基盤とし、
仮想アプライアンスの企業モデルへの積極的な導入を提唱しました。
”クラウド・アーキテクチャ：HW資源の仮想化とvmイメージ”
そして、PaaS に代表されるスタック・アーキテクチャがベンダー・ロックインの危険性が大きいことを指摘し、その脱皮も提唱しました。
”ユーザ企業主導のクラウド・アーキテクチャ。リンク・アーキテクチャ構想”
そして、先ず取り組むべきスタック・アーキテクチャからの脱皮の方法として、バージョン（版）管理の積極的な導入を提唱しました。
”eVAにおける明示的な版導入とテスト・ケース縮減への拘り”
これ等の一連のアーキテクチャのターゲットは、結局、過去・現在・未来を通した多様なプログラミング・モデル依存性からの脱却です。
”クラウド構成におけるprogramming model agnosticの訴求”
そして、先ず始めようというのが、DMTF OVF 系の標準化を基礎にしたアーキテクチャ創りで、ベンダー・ロックインを回避した、クラウド時代の新しいエンタープライズ・システムを構築しようということです。
”クラウド構成における、ユーザー主導アーキテクチャの関係”
これはとりも直さず、日本IT再生の出発点になるのでは、と主張しています。
過去、枚挙に暇がないほど行われてきた数多くの標準化作業や、製品調達の業界標準などと、何が違うのか
ユーザー主導の標準化やアーキテクチャなどで、ベンダー・ロックインを回避しようという試みは過去にもありました。
それどころか、枚挙に暇がないほど行われてきたわけです。
例えば、NTTは，1960年代から1980年代の旧電々公社時代に，特定のベンダに依存しないNTT標準仕様のコン ピュータDIPS (Denden-Kosha
Information Processing System）を構築していました。
さらには、その後のオープン化の流れに先んじて、MIA(Multivendor Integration Architecture) を開発、マルチベンダ間
のAPポータビリティやインタオペラビリティを保つための仕様を作成、調達の前提にもしていました。
テレコムの業界では、 業界 団体（Parlay Group）のテレコムアプリケーションのI/F使用（ＰａｒｌａｙＡＰＩ）が詳細に規定されています。
XML利用による業界標準のビジネス・プロトコルや、変更容易性追求のJava DI(Dependency Injection)などもここに入るのでしょう。
今回、小生達が主張しているユーザー企業主導アーキテクチャは、これらと何が違うのでしょうか。
|
