レベル: 初級 Dustin Amrhein, Staff Software Engineer, IBM
Scott Quint, Cloud Computing Technology Evangelist, IBM
2009年 4月 08日 
ここ最近の技術の動向を振り返ると、分散コンピューティングとその関連技術 (グリッド・コンピューティングや SOA など) が広く採用されるようになって以来、クラウド・コンピューティングが時流に乗ってきたことは明らかです。現在、クラウド・コンピューティングが実際に使われているとは言え、多くの人々はこの新しい技術を十分理解しているわけではありません。この連載記事の第 1 回では、まずクラウド・コンピューティング全般について解説してからクラウドを構成する各層を分析し、続いてそれぞれに異なるクラウドのタイプをその利点および欠点と併せて紹介します。そして最後に、このクラウド・コンピューティングへの移行がエンタープライズ開発者にとって重要である理由を説明します。
IBM WebSphere Developer Technical Journalより.
はじめに
「クラウド・コンピューティングとは何か？」
これは非常に退屈で単純な質問のように思えますが、実はそうでもありません。現在 Web には、数千とはいかないまでも何百ものクラウド・コンピューティングの定義があふれ返っています。この質問に対する的確な答えを見つけるには、クラウド・コンピューティングの定義を検討する前に、まずはクラウド・コンピューティングが何ではないかを理解することが近道だと思います。
一部の人は、クラウド・コンピューティングは Web 2.0 の動きの中心となっていた SaaS (Software as a Service) モデルの別名に過ぎないと意見するかもしれません。あるいは、ユーティリティー・コンピューティングや仮想化、グリッド・コンピューティングといった古い技術に新たな光を与えるための派手な宣伝文句だという意見もあります。この考え方に欠けているのは、クラウド・コンピューティングが対象とする範囲は、これらの特定の技術よりも広いという事実です。確かに、クラウド・ソリューションには上記の技術 (および他の技術) が組み込まれることがよくあります。しかし、クラウド・ソリューションは包括的なストラテジーであって、その点がクラウド・コンピューティングをその前身である技術とは分け隔てています。
この記事を読み進める上では、クラウド・コンピューティングとは、「すべてのコンピューティング・リソース (ハードウェア、ソフトウェア、ネットワーク、ストレージなど) を必要に応じて迅速にユーザーに提供する包括的なソリューション」であると考えてください。提供されるリソース (すなわちサービス) は、高可用性、セキュリティー、品質などを確実にするために調節することができます。この包括的なソリューションにとっての重要な要素はスケール･アップやスケール･ダウンの能力を備えていることで、それによってユーザーがリソースを必要な分だけ (多すぎることも少なすぎることもなく) 手に入れられるようにすることです。
要するに、クラウド・コンピューティング・ソリューションは IT をサービスとして提供することを可能にします。
「なぜクラウド・コンピューティングなのか？」
最近では、クラウド・コンピューティングを組み込んだ IT ソリューションに移行する会社がますます増えています。これにはさまざまな理由がありますが、第一に挙げられる理由は、クラウド・コンピューティングによって IT サービスを提供する際の関連コストを削減できることです。必要なときにだけリソースを取得し、使用した分だけ支払うことにより、資本コストと運用コストの両方を削減することができます。さらに、企業全体にあるさまざまなリソースを管理するという負担の一部が取り除かれるため、主要な社員がビジネスに価値と革新を生み出すことに一層専念することができます。そして最後に挙げる理由として、クラウド・コンピューティング・モデルはビジネスにアジリティーをもたらします。IT インフラストラクチャー全体を必要に応じてスケール・アップまたはスケール・ダウンできることから、ビジネスは急速に変化する市場のニーズに対応しやすくなり、利用者にとって常に最先端のビジネスであることを確実にすることができます。
さまざまな点で、クラウド・コンピューティングは既存のさまざまな技術 (SOA、仮想化、オートノミック・コンピューティング) と新しい構想との組み合わせによる完全な IT ソリューションの具現化と言えます。
クラウドの内部構造
クラウド・コンピューティングの納得のいく定義を見つけられることを期待して、今度はクラウドを構成する各層について調べてみましょう。図 1 はクラウドの内部構造で、ここで明らかに認められるのは、クラウド・モデルは 3 つの主要なコンポーネントで構成されるということです。この図は、コスト、物理的なスペース要件、保守、管理、管理の監視or監視の管理、陳腐化という点で、IT 全体のなかでのそれぞれの層の割合を正確に反映しています。さらに、これらの層はクラウドの内部構造を表しているだけでなく、一般的な IT の内部構造も表しています。
図 1. クラウドの内部構造
クラウドは以下の層で構成されています。
-
アプリケーション・サービス
日常的な Web ユーザーにとっては、クラウドを構成する層のなかで最も馴染み深いのはこの層でしょう。アプリケーション・サービス層は、SaaS モデルに適合するアプリケーションをホストします。これらのアプリケーションがクラウド内で実行され、必要に応じてサービスとしてユーザーに提供されます。アプリケーション・プロバイダーの中には、サービスを無料で使用できるようにして Web 広告などから収益を上げるプロバイダーもあれば、サービスの使用料から直接収益を上げるプロバイダーもあります。この仕組みは、サービスを利用したことがある私たちのほとんどにとって馴染みがあるはずです。Turbo Tax を利用してオンライン確定申告をしたり、Gmail や Yahoo! メールでメールをチェックしたり、Google カレンダーに予定を記録したりした経験があれば、クラウド最上部にあるこの層については馴染みがあるはずです。これらのサービスはこのタイプのアプリケーションのほんの一部の例でしかありません。SaaS アプリケーションは文字通り何千もあり、その数は Web 2.0 技術のおかげで毎日増えています。
一方、一般のユーザーにはそれほど明らかになっていないと思いますが、アプリケーション・サービス層には企業コミュニティー向けのアプリケーションが多数あります。これらのアプリケーションは、給与処理、人事管理、部署間の連携、顧客関係管理、取引先関係管理などを扱うホスト型ソフトウェア・オファリングとして使用することができます。よく利用されているオファリングの例としては、IBM® Lotus® Live、IBM Lotus Sametime®、Unyte、Salesforce.com、Sugar CRM、WebEx が挙げられます。
いずれの場合にしても、SaaS モデルによって提供されるアプリケーションは、利用者がソフトウェアをインストールおよび管理する手間を省けるメリットをもたらし、使用した分だけ支払うというコンセプトをサポートするライセンシング・モデルを適用することができます。
-
プラットフォーム・サービス
この層では、アプリケーションのインフラストラクチャーがサービスのセットという形で表現されます。サービスのセットには、例えばサービスとしてのミドルウェア、サービスとしてのメッセージング、サービスとしての統合、サービスとしての情報、サービスとしての接続性などがありますが、この例に限られるわけではありません。この層でのサービスが目的としているのは、アプリケーションをサポートすることです。サポート対象のアプリケーションはクラウド内で実行されていることもあれば、従来の企業データ・センターで実行されていることもあります。クラウド内で必要となるスケーラビリティーを実現するため、この層で提供される各種のサービスは仮想化されることがよくあります。クラウドのこの部分でのオファリングの例は、IBM® WebSphere® Application Server 仮想イメージ、Amazon Web サービス、Boomi、Cast Iron、Google App Engine などです。プラットフォーム・サービスがオンデマンド・ベースのアプリケーション・インフラストラクチャーを提供することによって、サービスの利用者は、それぞれのアプリケーションにユーザーのニーズを満たす能力を確実に備えることができます。
-
インフラストラクチャー・サービス
クラウドの一番下にある層は、インフラストラクチャー・サービス層です。この層には、プロビジョニングされたサービスとして利用者に提供されるサーバー、ネットワーク機器、ストレージ・ディスクなどの物理資産があります。この層のサービスは、アプリケーションのインフラストラクチャーがクラウドによって提供されているかどうかに関わらず、アプリケーションのインフラストラクチャーとより多くの利用者をサポートします。プラットフォーム・サービスと同じく、この層でも多くの場合、リソースをオンデマンドで割り当てるための手段として仮想化が使用されます。インフラストラクチャー・サービスの例には、IBM BlueHouse、VMWare、Amazon EC2、Microsoft Azure Platform、Sun ParaScale Cloud Storage などがあります。
インフラストラクチャー・サービスは、データ・センターを適切に配備しなければならないという問題に対して、必要なときにコンピューティング能力を使用できることを保証することで対処します。さらに、この層では仮想化技術が一般に採用されることから、一層効率的なリソースの使用によってもたらされるコスト削減を実現することも可能です。
 |
パブリック・クラウド、プライベート・クラウド、ハイブリッド・クラウド
クラウド・コンピューティングとは何か、そしてクラウド・コンピューティング・ソリューションは何によって構成されているのかについて、おおよそ理解したところで、次は 3 つの代表的なクラウドのタイプに目を向けてみましょう。この記事では、クラウド・コンピューティングの利用者が企業の場合に関わってくるクラウドのタイプについて見て行きましょう (図 2 を参照)。
図 2. クラウドのタイプ
- パブリック・クラウドとは、サード・パーティー (ベンダー) によって提供されるクラウド・サービスのことです。パブリック・クラウドは企業のファイアウォールの外側にあり、クラウド・プロバイダーによって完全にホストおよび管理されます。
パブリック・クラウドの目的は、利用者に手間のかからない IT 要素を提供することです。その要素がソフトウェアであったり、アプリケーション・インフラストラクチャーや、物理インフラストラクチャーであったとしても、インストール、管理、プロビジョニング、および保守を行うのはすべてクラウド・プロバイダーの責任となります。利用者に課せられる料金は、リソースを使用した分に対してだけであり、使用していない分に無駄に使用料を支払うことはありません。
しかし、このタイプのクラウドには犠牲も伴います。通常、サービスは「Convention over Configuration (設定より規約)」の原則に従って提供されます。つまり、サービスは最も一般的な使用ケースに対応するようになっているということです。そのため、利用者が直接リソースを制御する場合よりも、一般的には構成オプションの数が限られています。もう 1 つ念頭に置いておかなければならない点は、利用者がインフラストラクチャーを制御することはほとんどできないため、厳重なセキュリティーや法規制の遵守が必要なプロセスには、パブリック・クラウドが適合するとは限らないということです。
- プライベート・クラウドとは、企業内部に提供されるクラウド・サービスのことです。これらのクラウドは企業のファイアウォールの内側にあり、企業によって管理されます。
プライベート・クラウドは、パブリック・クラウドがもたらすのと同様の利点を数多く提供しますが、そこには大きな違いが 1 つあります。それは、クラウドのセットアップと管理は企業が受け持つという点です。内部クラウドを確立する上での困難とコストは、時として対応可能な範囲を超えることがあります。また、プライベート・クラウドを継続的に運用するコストが、パブリック・クラウドを利用する場合のコストを上回ることも考えられます。
プライベート・クラウドにはパブリック・クラウドに勝る利点があります。その 1 つは、クラウドを構成する各種リソースをきめ細かに制御できることです。そのため、企業はあらゆる構成オプションを使用することができます。さらに、行っている業務の性質から、セキュリティーおよび法規制に関する懸念のためにパブリック・クラウドでは実用的でない場合、プライベート・クラウドは理想的なソリューションとなります。
- ハイブリッド・クラウドとは、パブリック・クラウドとプライベート・クラウドを組み合わせたクラウドのことです。通常、ハイブリッド・クラウドは企業が作成し、その管理責任は企業とパブリック・クラウド・プロバイダーとの間で分担されます。ハイブリッド・クラウドはパブリック・スペースとプライベート・スペース両方のサービスを利用します。
企業がパブリック・クラウドとプライベート・クラウド両方のサービスを採用する必要がある場合には、ハイブリッド・クラウドがその答えになります。この場合、企業はサービスの目標とサービスへの要求事項をまとめ、それに応じてパブリック・クラウドまたはプライベート・クラウドのサービスを利用することができます。ハイブリッド・クラウドを上手く構成することで、顧客からの支払い受け取りといった、セキュアでミッション・クリティカルなプロセスだけでなく、ビジネスに伴い生じる従業員への給与処理といったプロセスへのサービス対応が可能になります。
一方、このクラウドの大きな欠点は、このようなソリューションを実際に作成し、管理することの難しさです。異なるソースからサービスを取得し、これらのサービスがあたかも 1 つの場所から生じたサービスであるかのようにプロビジョニングする必要があるだけでなく、プライベート・コンポーネントとパブリック・コンポーネントとの間の相互作用によって、実装がさらに複雑になる可能性があります。ハイブリッド・クラウドはクラウド・コンピューティングにおける比較的新しいアーキテクチャーの概念なので、このパターンに関するベスト・プラクティスとツールはまだ明らかになっていません。このパターンに関してもっと多くのことが知られるようになるまでは、概してその採用は遠慮されがちとなるでしょう。
|
SOA とクラウド・コンピューティング
クラウド・コンピューティングの前身はよく知られた数々の技術で、ユーティリティー・コンピューティング、グリッド・コンピューティング、仮想化、ハイパーバイザーなど数多くの技術があります。しかしクラウドについて語るときに、いつも話題に上らない (それでも当然、関係している) 技術的概念の 1 つは、サービス指向アーキテクチャー (SOA) です。クラウド・コンピューティングが今日の形になったのは SOA のおかげであり、クラウド・コンピューティングが進化する上でも SOA が重要な役割を果たすはずです。
さまざまな点で、クラウド・コンピューティングは SOA のこれまでのアプリケーションを拡張したアプリケーション兼物理インフラストラクチャーとして考えることができます。企業とクラウド・プロバイダーがクラウド・ソリューションを実現しようとするとき、基本的な目標とするのはエンタープライズ IT インフラストラクチャーをサービスとして使用できるようにすることです。これまでエンタープライズ・アプリケーションを統合し、個々のサービスとして提供するために学んだ教訓は、インフラストラクチャー層を編成し、サービスとして提供する際にも生かさなければなりません。アプリケーションと物理インフラストラクチャーは、SOA でのアプリケーションと同じように検出、管理、制御が可能でなければなりません。理想的には、SOA とほとんど同じようにサービスの検出、使用、管理、制御方法をそれぞれに規定するオープン標準が考え出され、これらの標準が 1 つにまとまってクラウド・ソリューションのライフ・サイクル全体を構成するようになることが望まれます。
図 3 は、3 つの層からなるクラウド手法の概念を捉えたもので、基本的にそれぞれの層が SOA 全体に対してサービスを提供する仕組みを示しています。場合によっては、下の 2 つの層にあるサービスは SOA の一部として表されることもありますが、重要な点は、クラウドのすべての層に対してサービス・ベースの手法がとられていることです。
図 3. クラウドのサービス
開発にとってのクラウドの重要性
ソフトウェアの開発者やテスターならば、こう思うかもしれません。これまでの説明はどれも素晴らしいけれども、自分にとって重要なのかどうかには確信が持てない。結局のところ、すべては管理者のためのものではないか、という意見です。初めはこのような意見を持つのが一般的ですが、この意見にはクラウド・コンピューティングが開発チームとテスト・チームにもたらす明らかな利点が考慮されていません。
テストと開発の両方で最大のハードルの例として挙げられるのは、ユニット・テストの作成やプロトタイプ作成、そして完全な製品テストを実行する環境を手に入れ、配備し、構成し、ホストすることです。クラウド・コンピューティング・ソリューションを使用すれば、このような環境を素早く作成してホストできるため、テスト・チームと開発チームの負担を取り除き、問題はクラウドの領域に任せることができます。開発チームにとって、これはコードの継続的インテグレーションとプロトタイプ作成のような作業を簡単に行えるようになることを意味します。なぜなら、更新を行った製品や新規コードを比較的簡単にテストできるからです。テスト・チームにとっては、製品の品質をテストするのに費やす時間が増え、テストを行うための準備に費やす時間を短縮できることになります。
開発チームにランタイム環境を提供するという他に、クラウドには開発者を直接対象にしたサービスがあります。それはサービスとしてのツールという概念で、この概念は開発ツールをクラウドで提供可能にするもので、SaaS の一部となっています。このサービスは、IDE と単純なコード・エディターをインターネットでアクセスできるソフトウェアの一部としてホストするので、開発者はローカル IDE を用意したり、その環境内のすべてのマシンに対応するライセンスを取得したりする必要がなくなります。開発者であれば、共通の開発環境に常時どのマシンからでもアクセスできるということに、どれほどの潜在的な価値があるかを理解できるはずです。
クラウド・コンピューティングが開発者に及ぼす効果はまだあります。標準プログラミング・モデルの API を可能な限りいつでも採用することは、開発者にとって明白な使命です。あらゆる開発者は模範的なプログラマーになろうと厳格に標準に従うように努力しますが、たいていの開発者は時として標準から外れてしまいます。それには、パフォーマンスなどの点で明らかに独自仕様の API に利点があるから、あるいはただ単に「動作させたい」からという理由が考えられます。しかしクラウドでは標準 API から逸脱するのは、それがわずかな逸脱でも特に危険であり、その理由も極めて明白です。利用者は、要求したサービスをクラウド・プロバイダーから取得していることはわかっていても、そのサービスの実装の詳細については認識していない場合があるからです。
例えばあるクラウド・プロバイダーに、J2EE™ アプリケーション・サーバーのサービスを要求したとします。クラウド・プロバイダーはそのアプリケーション・サーバーのサービスを作成しますが、プロバイダーと具体的な契約交渉を行わない限り、取得したサーバーがどのベンダーのサーバーなのかはまったくわからないものです。提供されたサーバーにデプロイすることにしたアプリケーションには、ベンダー固有のコードが一切含まれていてはなりません。なぜなら、期待しているのとは異なるアプリケーション・サーバーの実装になってしまう可能性があるからです。
クラウドのためのツール
上記のセクションで触れたクラウド・コンピューティングでの主要なコンポーネントはツールです。さまざまな点で、ツールはクラウド・コンピューティング・ソリューションの成功に最も重要であると考えられます。市場にはクラウド・コンピューティング・ソリューションを実現するための重要な技術が存在しますが、包括的で理解可能なツールがないという理由で、その技術を実現することが難しい場合がよくあります。
ここで、クラウドのアプリケーション・サービス層を考えてみてください。この層に含まれるツールはクラウド・アプリケーションの開発を支援する環境を提供することが可能ですが、その場合アプリケーションをパッケージ化してクラウド・インフラストラクチャーにデプロイする手段も提供しなければなりません。こうした環境と手段を提供する既存のツールがいくつもあることはわかっていますが、問題は、これらのツールは必ずといっていいほどクラウド・プロバイダーのインフラストラクチャーに結び付けられていることです。このようなツールから最大限の能力と柔軟性を引き出すには、オープン標準が鍵となります。開発者には、毎回クラウド・インフラストラクチャーを変えるたびに新しいツールについて学ぶコストをかけている余裕はありません。さらに開発現場でも、クラウド・インフラストラクチャーが変わったからと言って毎回アプリケーションを作成し直すコストを負担することはできません。そのため、完了したプロジェクトが複数のクラウド・インフラストラクチャーに移植可能になるように、ツールをアプリケーションの開発、パッケージ化、デプロイメントに役立てる必要があります。
ツールにはインフラストラクチャー・サービス層においても非常に明らかな役割があります。クラウド用にインフラストラクチャーを構成するプロセスは簡単なものではありません。内部プロバイダーであるか、外部プロバイダーであるかに関わらず、クラウド・プロバイダーのすべての物理資産を考慮し、適切な物理リソースがクラウドに割り当てられるようにする必要があります。こうしたインフラストラクチャー構成のためのツールは、企業がその IT 資産を可視化し、すべてのリソースがクラウドの考慮に含まれるように支援するはずです。しかし、クラウド構築のために資産を可視化するだけでは十分ではなく、このツールにはクラウドの構築に関する多少の知能も求められます。これまで、IT 管理者は想定される需要に合わせて物理リソースを割り当てるという困難な仕事を抱えていました。これが、割り当てたリソースが十分に使用されていないという問題の原因となっていましたが、この問題こそがクラウドを促進させる大きなきっかけとなっています。ツールによって、システムに想定される需要特性に基づいたクラウドの物理構成が導かれるはずです。
まとめ
クラウド・コンピューティングは現在から近い将来、技術産業で大きな役割を果たそうとしています。最終的には、クラウド・コンピューティングは IT をサービスとして利用者に提供する手段となるはずです。クラウド・コンピューティングの分野での製品とサービスのオファリング数は増え続けていることが、クラウド・コンピューティングへの移行が行われているという現状を如実に物語っています。私たちは、クラウド・コンピューティングが WebSphere 開発者の皆さんに与える可能性に期待しています。以降の記事ではその可能性のいくつかを説明し、クラウド・コンピューティングを 1 つの概念から企業にとって利益をもたらすものへと移行させる WebSphere ソリューションをいくつか調べることにします。
参考文献 学ぶために
議論するために
著者について | | | Dustin Amrhein は、WebSphere Application Server 開発チームのメンバーとして IBM に入社しました。この開発チームに在籍している間、彼が主に取り組んでいたのは Web サービス・インフラストラクチャーと Web サービス・プログラミング・モデルです。さらに、彼は Java ランタイムを対象とした RESTful なサービス・フレームワークの開発にも携わりました。現在の任務は、IBM WebSphere ポートフォリオの新しい技術を広めることです。 |
| | | Scott Quint は 1996年以来、IBM で開発者、主任エンジニア、チーフ・エンジニア、品質保証リーダー兼設計者、シニア・コンサルタント、プロジェクト・マネージャーを務めてきました。最近では WebSphere Virtual Enterprise の主任エンジニアを務め、現在はクラウド・コンピューティング技術の熱心な支持者となっています。 |
記事の評価
| 
