GRC: Governance, Risk, Complianse
クラウド・プラットフォーム、クラウド・サービス、企業アプリケーション、による新しいエンタープライズ・システムの構成
上図において、新システムの目標とする能力を、縦軸のNFRの拡がりと、横軸のアプリケーション（ＦＲ）の拡がりで、現行システムとの違いをアナログ的なスケールで表現しています。
現行システムは、上図の赤枠のように、FRとNFRは各インストレーション毎に一体型としてきめ細かく作りこまれ、システム・ライフサイクルを通して安定しています。しかしこの閉じた安定は、グローバル化などでこれから要求される縦横の急激な拡がりには対応出来ないと考えられます。例えば、多様なユーザ要求への充足や戦略的な攻めの経営環境を考えると、横軸で示されるアプリケーション(FR)のスペクトラムは拡がる一方でしょう。また、縦軸で示される処理量の暴発や24x365運転などのNFRも拡がる一方だと考えられます。
現行システムを支える伝統的なシステム開発では、赤枠のような限られた範囲のスケールの技術で、この両方を満足させることに注力してきました。しかしこれからは、従来の方法のままではスケール的に対応できなくなると考えられます。
クラウド技術を使った新エンタープライズ・システムでは、縦軸のスケーラビリティを中心としたNFRの実装を、クラウド・プラットフォームとクラウド・サービス（ＶＡＣ）の機能として導入し、ＩＴ部門が”クラウド的に”柔軟に利活用することを考えています。一方で、ＩＴ部門は本来のアプリケーション・ロジックの幅広いスペクトラムの充足に積極的に専念する。このようにして縦横の拡がりに対応する。
上図の下半分に、新しいエンタープライズ・システムの構成概念図を埋め込んでいます。
新システムの目的は、NFR実装の重圧から企業アプリケーションを出来るだけ解放し、可能な限り身軽にすることです。出来ればビジネス・ロジックだけの裸にしたいぐらいです。FRとNFRを一体型で作り上げる現行のシステム開発論では限界が見えています。 また、一般のパブリック・クラウドの論議では、企業アプリケーションそのものも明示的に論じていませんので、このようなNFR充足は大変貧弱になっています。
eCloud研究会ではここから出発します。そのために、何回も繰り返して主張している仮想化と仮想イメージ、すなわちＳＷアプライアンス化を使う。図における
eVA(enterprise class Virtual Appliance) と VAC(Value Add Capability)です。
クラウド・プラットフォームの線引き
アプリケーションをプラットフォームやインフラの属性から切り離すためには、マルチ・テナントの項でみたように複数の切り口があります。
上図でいえば、構成図の右端の抽象化の上下のスタックの各層で切り分けることが可能です。理論的にはすべての層での抽象化が仮想化と呼べるわけですが、HW系とＳＷ系との境で切る方法を一般的に仮想化と呼び、ミドルウェアの層などの切り分けはＡＰＩと呼んでいます。
ここでもその用法に従います。
クラウド論の先ず第一の関門は、この切り口の設定の曖昧さです。どこでプラットフォームを切り別けるのか。クラウド・プラットフォームとクラウド・サービスのIaaS,
PaaS, SaaS などとの区別も未だあいまいです。そんな風に切り別ける事にすら違和感を持っている論者もいます。
システム開発か運用系かの論者の立ち位置によっても違ってきます。また、プラットフォームとインフラの呼称のように、時代背景によるシステムの拡がりによって言葉の使い方も曖昧になっています。eCloud研究会でもこの言葉の定義は峻別できていません。
一般にGoogleに傾倒している人達はGoogle API で代表されるミドルウェアの層で切り別けます。このＡＰＩにはＤＢやトランザクショナルな準システムとのＩ／Ｆ(Interface)が入ります。プログラマー、プログラミングからみた外部 Ｉ／Ｆ です。プログラミング・モデルの世界観です。
この切り口はアプリケーション開発から見れば自然ですが、難点は、このＩ／Ｆは多様性があり、歴史的に見ても変転するのが常識です。例えばJavaのプログラミング・モデルも色々変化してきています。技術の革新に率直であれば、ミドルウェアでプラットフォームを固定的に切り別ける考え方の脆弱性は否めないでしょう。問題なのは、既存の企業アプリケーションが簡単な修正だけでは移行できないことです。
SaaSで代表されるアプリケーション層での切り分けは、より狭いプラットフォームとしての限界が問題になります。
これに比してＨ／Ｗ系とＳ／Ｗ系のＩ／Ｆはより安定的です。そして何よりも、理屈抜きで伝統的に企業システムがHWとＳＷを区別し、ＩＴ業界のすみ分けもそうなっているわけです。技術者も違う。また、既に仮想化層によるサーバー・コンソリデーションが一般化してきています。
現行の企業アプリケーションを最少のコストでクラウド環境に移行するにはこの方法が最適でしょう。
確かにＨＷの世界にも多様性があります。例えばＩＢＭにはｚ、ｐ、ｘ８６のマイクロプロセッサーを使った複数の種類のサーバーがありますが、
これらは同類をアンサンブルというミニ・クラウドに一括管理して、利用者側のプロファイル指定で自動的にプロビジョニングされるようです。
一方で、ORACLEのＳＵＮ買収などで、ＨＷとＳＷが垂直統合される流れも議論されています。しかしＨＷとＳＷは容易には融合しない。
ＳＷビジネスのリーダー達が描くＩＴ（ＨＷ）アプライアンスはクラウドとは別物で、ＩＴ業界のメーンストリームにはならないと考えられます。
プライベート・クラウドの第一歩は、仮想化によるアプリケーションのＨＷ系資源との密結合からの解放
ということで、”プライベート・クラウド”を構築する第一歩として、ＨＷ-ＳＷ間の仮想化を前提にする事に異論はないと思います。
いずれにしても、"one size fits all" の世界観は難しいので、Googleなどのパブリック・クラウドとはハイブリッド・クラウド結合になるのでしょう。
また、Amazon, IBM, VMware, Microsoft などのクラウド・プラットフォームは全て仮想化をベースにしています。
次の議論は、ＯＳが，仮想化の上下、どちらに含まれるのかです。結論はＯＳは仮想化の上下両方に存在することになります。
アプリケーションから見れば、ＯＳとＨＷ系はほぼ一体に見えます。アプリケーションとプラットフォームの境界は常識としてＯＳにあります。
ＨＷ資源を適切に管理するＯＳ本来の機能や、通信機能、プロビジョニングの機能などは、ＨＷ中心のクラウド・プラットフォーム側に存在します。 勿論クラウド環境を構成するのは単体のサーバーではなく、サーバー群になるわけですからＯＳは一連のシステム管理のＳＷ群の中の部分として埋没していきます。ＯＳを含んだシステム管理のＳＷ群全体で、ストレーッジ系、通信系などのＨＷ系資源全体から構成されるデータセンターのエラスティック（伸縮自在）な資源活用がなされます。仮想化のHypervisorなどもこの一部となります。
一方で仮想化の上に乗せられる仮想イメージ（ＳＷアプライアンス）に梱包されるＯＳは、アプリケーションやミドルウェアの実行を補助するだけの大変軽いものになっていくのでしょう。できれば消滅してほしいわけですが、ＯＳがなくてはイメージ内の上層のＳＷは動かない。
仮想イメージに梱包されるＯＳは当初は現行システムからの移行が多いでしょうが、メンテナンスやクローン化などの観点からオープン・ソースのLinuxなどに収斂していくのではと考えられます。限りなく隠蔽されていく事になります。人間の尻尾のように退化してほしい。
さて、ＨＷの性能や信頼性や調達や導入や監視やメンテナンスやワランティーなど、ＨＷ系のシステム管理の項目は山のようにあります。サーバー系、ストーレッジ系、ネットワーク系などの構成機器を含めると、その組み合わせも含めてＩＴ部門の負荷は、単にＩＴ予算の７０％を占める費用以上の重々しさでＩＴ部門を圧迫しています。ダウンバッシングの恐ろしさを考えると変更もままなりません。さらにエコ対応や災害対策、ＮＧＮやモバイル対応、より一層のセキュリティ強化など、システム運用に関わる課題は山積しています。これが削減されます。
従来のシステム管理とクラウド・プラットフォームとの一番大きな違いは、資源利用者から見たＨＷ資源のエラスティック（動的で伸縮自在）な活用にあります。例えばサーバー、ストーレッジ、通信などの複合テスト環境のセットアップが数分、数時間レベルで整うことになる筈です。これ等のセットアップはセルフ・マネージメントのＵＩで行うのでしょう。また課金も使った分だけの従量制がベースになります。
クラウド・プラットフォームの導入による運用面におけるメリットは、プライベートの場合にも計り知れないものがあります。
逆に、これからのクラウド・プラットフォームの技術革新を積極的に活用しようというのが、プライベート・クラウド推進の動機です。
アプリケーションとプラットフォームの明確な分離（指向）によるFRとNFRの実装の分担
さて、仮想化で線引きされたクラウド・プラットフォーム上に企業アプリケーションを実装していくことになります。
ミドルウェアでクラウド・プラットフォームが線引きされた場合には、企業アプリケーションの実装はAPIを介して直接プラットフォームと結合されるわけですが、仮想化の線上に乗せるには、アプリケーションを仮想イメージに梱包する必要があります。ということで、ここからはイメージ管理とクラウド・サービスの出番になります。
以下、第２回の考察に続きます。 |
