クラウドコンピューティングを理解するための鍵

ユーティリティコンピューティング

1990年代の後半に、ユーティリティ コンピューティングは再度、市場に現れる。

ITベンダーにとってユーティリティモデルは、ハードやソフトウェア を毎回販売して利益を得る「フロー型ビジネス」から、電気、ガス、水道、電話のように毎月ほぼ固定的に利用料を徴収できる「ストック型ビジネス」への、よ り安定性の高いビジネスモデルへの転換だから歓迎だ。むしろ、ユーティリティモデルのようなストック型ビジネスの方が年間の予算は見えるしビジネスは安定 する。しかも、顧客を囲い込むことができるので、毎回激しい競合との価格競争により利益率が悪化する一方の、それまでのビジネス形態から脱却することがで きる。 ユーザにとっても、日々業務に追われながら複雑に進化するIT技術を追いかけるより、従量課金制のサービスとして利用し、月々のコストとして処理するほうがはるかに楽になるはずだった。

しかし、個人情報や機密情報、ビジネス優位性を有するビジネスプロセスなどを完全に企業の外に出してしまい、ITベンダーに預けてサービスとして利用するITには、現時点では様々なリスクを伴う。これらリスクの課題が完全に解決されるまでは、機密情報や企業優位性を有するビジネスプロセスを、完全に企業の外に出した時のリスクに懸念を抱く企業にとって、完全なユーティリティモデルへの移行は不可能だ。もちろん、IT技術がさらに進化し、機密性、安全性が完全に確保され、ユーティリティモデルによるコストメリットを享受できるのであれば、最終的には完全にユーティリティモデルへ移行することが考えられる。この場合は、ユーティリティ データセンターにはサービスを提供する先の複数の企業の変化に対応するための、非常に高い変化対応力が求められる。それだけではなく、提供するサービスの ビジネスにおける重要性に応じてサービス料金もいくつかのレベルを持つ必要がある。可用性、堅牢性が高く求められるミッションクリティカルなサービスと、 そうでないサービスの料金はユーザからすれば当然同じ金額を払うことはできないからだ。もちろん、ユーティリティモデルへの移行時期には例外もある。前述のケースは中堅・大手企業で既に自前のデータセンターを 持っている場合のことで、中小企業などで「サーバを自社購入して、運用管理はサービスを提供しているデータセンターへ実機を置いてお任せしている」、とい う場合は早急にパブリッククラウドへ移行し、全てをコスト化してしまった方が良いケースもある。

中小企業にとってはパブリッククラウド環境が一日も早く安定提供され、最大限の活用による無駄なコストの削減と、IT運用の効率化が競争力の鍵となるだろう。これらのユーティリティモデルへの動きはIT業界における、ITベンダーの垂直統合やグローバル化の動きを見ても、最終形としてのユーティリティモデルによるサービス化をゴールとしていることが伺える。既に飽和状態のIT市場においてフロー型ビジネスではこれ以上の成長は望めない、垂直統合を行い、ユーティリティデータセンターをグローバルに展開し、サービスとしてグローバル企業を取り込むことで30%しか手を出すことができなかったIT市場の100%を視野に入れて成長路線を歩むことができるからだ。

クラウド コンピューティングの登場

現時点でのユーティリティモデルの課題を解決する方法として、提案されたのがクラウドコンピューティングだ。
クラウドには、パブリック クラウドとプライベート クラウドがある。
パブリッククラウドは、SaaS、PaaS、XaaSな どソフトウェア、プラットフォーム、ハードウェアなどをサービスとしてベンダーにより提供され、対してプライベート クラウドは、企業内のユーティリティモデルといえる。企業内ユーティリティモデルでは仮想化された一つのプラットフォーム上で、複数業務に対して組織横断 的にサービスを提供する。仮想化されたリソースプールを効率的に利用することで稼働率90%を実現し、可変的に必要となるリソースは企業外のサービスをパブリック クラウドという形で柔軟に利用する。 また、企業内では優先度や稼働率が低いサービスなどもパブリッククラウドを利用することで無駄な投資を避け、従量課金で最もコスト効率の良いサービスを利用することが可能だ。さらに、企業内にはない優良なシステム（例：SalesForceなど）をサービスとして利用することで、あえて社内でシステム開発をしないで無駄な開発コストや管理コストを抑制することができる。

クラウドにおいては物理的な異機種混合環境を、論理的なリソースプールとして統合し、仮想化することでハードウェアの稼働率の最大化を図る。さらに、管理層により再利用性の高いサービス指向アーキテクチャ(SOA)のアプリケーション層の変更管理を行い、迅速な変更を可能とし、変化対応力を向上する。業務アプリケーションでも、管理アプリケーションでも粒度の粗い、疎結合のシステムにすることで連携や統合を容易にし、サービスとサービスの連携の仕方や、新たなサービスを加えて連携させることで、変化への対応力を高めている。その実装技術としてWebサービスによるHTTPなどを利用したファイアウォール越えの連携がある。今まではAPIを使い、ローカルポートを利用した密結合の連携でしか実現できなかったアプリケーションの連携が、Webサービス技術により、アプリケーションの違いや、開発言語の違いを乗り越えて疎結合の連携を可能とし、比較的簡単に短時間で連携を実現し変化に対して迅速に対応することを可能とした。

そんな疎結合で柔軟性、変化対応力の高いクラウドでより一層明確になったのは管理層の重要性だ。

今までシステムの監視と管理は、開発にくらべ後ろ向きなコストとされ、開発などの投資が30%に対して、運用コストが70%という、後ろ向きなコストを削減するべきだと言われ続けてきた。ところが、異機種混合のハードウェア環境において開発されたアプリケーションを最大限に生かし変化に対応するためには、管理 層の機能は開発同様に戦略的で迅速な対応が求められる。監視と管理という運用における役割は、「再利用性の高いサービスコンポーネントや、仮想化されたプ ラットフォームの変化対応力を最大化する管理層を構築し運用する」という形で、今まで川下と考えられていた運用とは全く異なり、IT戦略の中枢で非常に重要な役割を担うことになる。

クラウド実現の鍵は、「変化対応力を備えた管理層の構築だ」といっても過言ではない。

そして、クラウドの管理層の構築で最も重要なのは、決して管理ツールで自動化すれば解決する問題ではないということだ。管理 ツールは、標準化された運用管理のプロセスをサポートし、自動化、効率化を実現する重要な役割を持っていることは確かだが、ツールの導入で運用管理プロセ スが構築されることはない。変化へ対応するための変更を全てツールにより自動化することは不可能なので、迅速な変化対応を実現するためにはツールを生かすための人によるポリシーベースの変更プロセスが機能しなければならない。

クラウド環境の進化

企業のITのあり方として今日のクラウドコンピューティングに至るまで、「ユーティリティ コンピューティング」や「グリッド コンピューティング」などが提案されている。これらは変化対応力やコストの最適化、投資効率の最大化などを課題として取り組まれてきたもので、今日のクラウド コンピューティングへの進化の過程であり、クラウド コンピューティングとも混同しやすい。

以下にそれぞれの定義を簡単にまとめてみる：

１． グリッド コンピューティング

スーパーコンピュータ、仮想コンピュータがネットワーク化され、疎結合されたコンピュータのクラスターを構成し、膨大なタスクに対して複数のコンピュータが協力して処理する分散処理コンピューティングの形態。

２． ユーティリティ コンピューティング

電気など、公共ユーティリティサービスのように従量課金サービスとして、演算処理やストレージなどのコンピュータリソースを提供するサービスをパッケージ化したもの。

３． クラウド コンピューティング

動的な拡張性があり、仮想化リソースがインターネット上で提供されている。クラウドを利用するユーザは、クラウドをサポートするインフラ技術の制御、専門知識、いかなる知識も必要としない。

クラウドの概念は以下の組み合わせにより構成される：

①IaaS (infrastrucrure as a service)

②PaaS (platform as a service)

③SaaS (software as a service)

④XaaS (everything as a service) その他、最新のインターネット上でユーザのニーズに対応するテクノロジなど。

特にユーティリティ コンピューティングは、クラウド コンピューティングのデリバリ モデルとしての従量課金サービスという共通項があるので混同しやすいが、クラウドはユーティリティ コンピューティングを現在のインターネット時代に合わせて具現化したものと考えた方が良いのかもしれない。

ユーティリティ コンピューティング

コンピュータの演算処理やストレージのようなリソースを必要な時に、必要なだけ利用でき、使用量に応じてサービス料金を支払えたらユーザ企業にとってどんなにかコストの最適化が楽だろうか。

「電気、ガス、水道、電話のような公共サービス(public utility)と同じようにコンピュータも公共インフラサービスのような利用形態を将来とることができる」

1961年当時 MIT で教鞭をとっていたJohn McCarthy が MIT 100年際 で初めてユーティリティ コンピューティングにについてこのように公言した。以来、20年に渡ってIBMなど大型汎用機ベンダーは銀行や大手企業に対して世界規模のデータセンターでユーティリティ コンピューティング モデルを「タイムシェアリング」というサービスで提供した。しかし、ミニコンやオープン系の進化により、ほぼ全ての企業がコンピュータを導入できるようになり、このユーティリティモデルのサービスは廃れていった。

オープン系の進化により、分散処理型のクライアント/サーバ システムによる業務ごとに必要なサーバを立てるという柔軟性の高いシステム構築の方法が紹介されると、必要に応じていくらでもサーバを構築して新たな業務システムを追加できる柔軟性に、次々とサーバが立てられ、新たな業務へと対応が行われた。しかし、あまりに次々とサーバが追加され、そもそもは最終的に80%ぐらいの稼働率を予定して20～30％稼働率で構築されたサーバは、いつまでたっても30%ぐらいの稼働率のまま、ともすると何の業務アプリケーションが使用されているサーバかを管理することすら不可能な状態になっていった。同時期に研究が行われていた技術として、平行/分散処理システムを実現しようとしたのがグリッドコンピューティングだ。グリッド コンピューティングが実現され、 70%もある余剰CPUリソースを集めて分散処理のCPUリソースとして再利用できれば、ユーザは安心して次々とサーバをたて、余剰CPUリソースは新たな業務に仮想的に割り当てることができる。ところが、残念なことにグリッドの技術では余剰CPUを適宜、動的に利用して新たな業務に割り当てるという目的を果たすことは実現されなかった。

なぜ、変更管理が重要か？

今までは「川上の開発」、「川下の運用管理」というイメージで運用管理は捉えられてきた。しかし、その構図こそが全体最適化によるコスト削減の妨げの一因となってきた。

「運用管理のコストがIT投資全体の70%を 占めているからコストを削減しなければならない」長い間、運用管理部門にはこの命題が与えられていた。しかし、そもそも運用コストは上昇する構造だったと したら…川下で帳尻を合わせるということが不可能だったとしたら…以下の図は分散環境における業務システムの新規投入を表している。

非稼動資産＝余剰資産
業務システムの使用度が成長し、導入後に徐々に稼働率が向上することを考慮して、当初導入時は稼働率30%ぐらいで設計し、将来予想されるピーク時を80%ぐらいと考えて構築されたシステムは、結果として稼働率が予定どおりに向上せずに、70%ぐらいの余剰資産が次々に投入されるという事態を招くことになった。

変化に対応する手段として登場した分散システムは、安定稼動のために業務システム毎にCPUを追加し、１OS上に１業務アプリケーションを配置し、必要に応じて次々とサーバを投入するという状態へと導いた。その結果、運用管理部門は増殖するサーバにより複雑化するサーバネットワークの死活監視と管理に追われることとなった。

分散処理の１OS・１業務アプリケーションという構造を見る限り、コストが上昇する結果は明らかだ。

これら課題の解決策として「サーバ統合」によるネットワークの整理と、「仮想化」による稼働率向上が提案されることになる。

一方、業務アプリケーションの開発も、開発効率と変化対応力の向上のために「サービス」という粒度が高く、「再利用性」の高いサービス指向アーキテクチャ（SOA）へと進化していき、稼働率向上をめざす統合されたサーバ環境の仮想化環境上にSOAシステムが構築されていくこととなる。

もちろん、CPU使用率のピークの波を上手く合わせながら稼働率の向 上を図り、変化する市場にたいしてサービスのキャパシティや、システムも変化させていくとなると所有している資産だけでは収まらなくなるケースも出てく る。そうなるとプライベートクラウドが構築されたデータセンターでは必要性に応じて所有しない資産を「利用する」パブリッククラウドのリソースの有効利用 までも念頭においてサービスの提供を構築することが求められる。

クラウド化のけん引役「サーバ統合（コンソリデーション）」と「仮想化（バーチャリゼーション）」は複雑化を進める

サーバ統合と仮想化により稼働率と変化対応力の向上をしながらコスト削減を実現するクラウド環境へ一歩近づいたといえる。

しかし、変化対応力が向上すると期待されるクラウドは、一方では、頻繁に変化する環境をしっかりと管理しないとサービスの品 質の低下や、可用性の問題を発生する可能性が増大するというリスクを抱える。つまり、クラウドの実現にはリソースプールを利用し、必要に応じて構成変更を 行い変化に対応するシステムの管理が鍵となる。

クラウド実現のための仮想化環境における管理対象例

１． １サーバ上に複数のアプリケーションが動作する環境で、共有するリソースの競合の可能性が大きくなるため、共有されるリソースの管理が必要となる

２． サーバ上のレイヤーが多くなり、アプリケーションが依存する複数のレイヤーとCPUなどのサーバリソースの依存関係が変化し続けるため、ハードウェア・ソフトウェアを含めた全ての構成要素のリレーション管理が必要となる

３． 構成変更が頻繁に行われるので複雑なレイヤーを含めた依存関係の遷移を管理する必要がでてくるため、変更前・変更後などのタイミングでの全ての構成要素のリレーションのスナップショットの管理が必要となる

仮想化環境では変化対応力が向上し構成変更が容易に行えるようになる。しかし、このメリットを生かすためには、運用管理のポ リシーにおける変更プロセスを変更の頻度が高くなっても対応可能にしなければならない。具体的には変更に関わる影響分析が複雑なレイヤーや関係するハード ウェア全域、さらにはサービスを構成する全てのアプリケーションと、そのアプリケーションに関係する全てのソフトウェアレイヤーとハードウェアの構成が管 理されていなければならない。

複雑化に対応する運用管理
変化対応力やコストの最適化を実現するとして期待されているクラウドだが、前述のように、その実現には複雑化する環境を運用する管理層の充実が不可欠なことがわかる。

管理層の充実は、すでに運用管理のポリシー策定にとどまらず、「戦略」、「設計」、「導入」、「運用」、「変更」といった全てのフェーズに関わっているといっても過言ではない。

そんな変化対応力を実現する企業ITを実現する一助として注目されているのが「Information Technology Infrastructure Library （ITIL）」なのだ。

ITIL Version 3 への期待

ITIL V2 の当時は運用管理の部分だけが注目を集めたが、実はITIL は運用管理に特化したガイドラインではない。ITをサービスととらえ、あたかもユーティリティサービスを提供する際に必要となるサービス提供の全域に渡ってサービスの品質向上を実現するためのガイドラインとして策定されたのだ。

ITIL V3 ITサービスの５つのライフサイクル

１． サービスストラテジ（戦略）

２． サービスデザイン（設計）

３． サービストランジション（導入・変更）

４． サービスオペレーション（運用）

５． 継続的なサービス改善

ここで重要なことは、管理層の充実は５つのライフサイクル全てに関係しているということだ。すなわち、運用管理部門の関与も 管理層の充実という観点から考えるとライフサイクル全般を意味する。「運用管理が戦略的な役割を担う」というのもクラウド環境において運用管理層を考慮せ ずに前述の5つのフェーズのどれも語れないからだ。

クラウド時代における運用管理は川下ではなく、「運用管理こそがクラウド戦略の要」であるといえる。

変化対応力を実現するための変更管理

迅速な対応が求められる変化への対応。それには変更管理のポリシーやプロセスが機能しなければならない。特に組織横断的に利用されるリソースプールを基礎としたプライベートクラウド環境では、組織横断的にサービスの優先順位が明確化されていなければならない。具体的には、「いざとなった時に、どのサービスから犠牲にするか」ということも管理されていなければならない。全てのサービスが可用性100%を求められるわけではない。時間帯や曜日、季節によっても可用性の要件はことなるはず。

「いやいや、うちのサービスは常に利用可能な状態でなければ困ります」という部門毎の主張を受け入れてしまうと、せっかくの全体最適化実現の可能性を失ってしまう。

つまり、組織横断的にSLAを検討し、サービスの優先順位を明確にしなければ全体最適化によるコスト最適化は不可能だといってもよい。重要な社内システムとはいえ、社員が利用する時間外は可用性が高い必要性はない。一方で、一般のユーザが利用するサービスは特定の曜日、時間帯に平日昼間の数十倍、数百倍のキャパシティを必要とする場合もあるだろう。なんらかの時事的要因で例外的に急激なキャパシティ要求の増加に対応しなければならないことも考えられる。それぞれのサービスが必要とされる時間帯や曜日、季節などを特定し、さらに影響される金額に換算して、実際に企業活動の目的 といえる営業利益にどのような影響を及ぼすのかの金額の大きさを基礎に優先順位を明らかにする必要がある。そもそも企業活動の目的とは利益を生むというこ とであることを営業部門のみならず、全ての部門において理解し、IT戦略においても利益創出活動の優先順位によって明確な優先度を持つべきである。また、稼働の計画性が低いサービスや、使用頻度が低かったりというサービスは、同等のサービスがパブリッククラウドで同等コ ストで提供されていないかを検討する必要もある。この場合は会計的観点から「所有＝資産」であるから、当然「総資産回転率」といった経営指標に影響を及ぼ すことを考慮し、資産回転率に悪影響をおよぼすような要因は排除し、費用計上が可能な「利用」形態をとることを検討する必要があることをIT部門も考慮する必要がある。このように変更管理のポリシーの策定には、企業ITの戦略や方針の策定の成功が大きく関与する。

戦略や方針の策定がしっかりしていないと、サービスの優先順位が明確化されず、変更管理のポリシーが策定できず、変更プロセ スが作られていても機能しなくなる。組織横断的に管理されるサービスの優先順位は、企業戦略の変化や経済の変化により変化し続けるので、これらの変化に合 わせて随時アップデートされ管理されて変更管理のポリシーに反映されなければならない。SLAや優先順位の管理は、変更管理ポリシーの策定では一つの要素にすぎないが、これらを踏まえて、変更管理のプロセスが機能するように策定、運用されなければ変化対応力の向上にはならず、全体最適化の実現もできない。これは変更管理プロセスに限ったことではない、情報セキュリティ管理（ISMS）やソフトウェア資産管理（SAM）などもISO化されコンプライアンスが要求され、形ばかりは遵守しているようにつくろっていても戦略や方針が徹底していなければいずれは綻びが生じ問題が発生する。最も重要な前提条件は、企業戦略に則ったITの戦略や方針が経営者により明示、徹底され、それに基づいて現場のポリシーが策定され、設計されたプロセスにより運用されることだ。こればかりは、運用管理ツールを導入すれば何とかなるという問題ではない。もちろん、運用管理ツールが不要だということではない。複雑化が進むクラウド環境を効率よく運用するには様々な重要な項目を抑えているITIL のようなガイドラインを参照することは有効だ。また、ITIL に 準拠した統合管理ツールベンダーの製品を利用して管理対象の全てを可視化し、制御し、可能な限り自動化しながら、人的プロセスの一助として利用することも 効率的な運用管理には不可欠といっていい。膨大な管理対象や項目を人手だけで管理することは不可能だし、ポリシーに則って自動化できる運用は、自動化し、 空いた工数はポリシーのアップデートや、組織横断的な優先順位の管理や調整などに充てるなどすべきだ。常に最新にアップデートされた優先順位を含むポリ シーや、有効な危機対応プロセスを維持することで、危機レベルの比較的低いエラー一つで無駄に数多くの人員を夜中にたたき起こすなどということは回避され るはずだ。プロセス自体が可視化され、制御可能な状態で、可能な限り自動化されていることも重要だ。「ツールを導入したが、プロセスは属人的」では有効な ポリシーベースのプロセスは機能しない。