クラウド・コンピューティングのサービス・モデル: 第 2 回、Platform as a Service

PaaS (Platform as a Service) を利用すると、開発者はクラウド・コンピューティングを利用するメリットをどのような形で得られるのか、また経営者および意思決定者は、事前にどのようにして PaaS ベンダーの適格性を調べ、取り返しのつかない誤りが起きる可能性をどのようにして最小限に抑えるのかを学んでください。

この全 3 回の連載では、クラウド・コンピューティングの概念にまつわる混乱がなくなるように、クラウド・コンピューティングを実際に使用する際に関係してくるさまざまな事項をわかりやすい例として取り上げます。そして、連載の記事ごとにクラウド・コンピューティングの 3 つのサービス・モデルである、IaaS (Infrastructure as a Service)、PaaS、SaaS (Software as a Service) のそれぞれに話題を絞って説明します。連載を読み終える頃には、クラウド・コンピューティングは単なる流行語ではなくなっているはずです。

Dan Orlando, CEO, Creative RIA

Photo of Dan OrlandoDan Orlando は、エンタープライズ開発コミュニティーでリーダーとして広く認められています。経験豊かなコンサルタントとして、彼の Adobe 技術プラットフォームに関する専門知識は、業界のリーダーだけでなく、IBM developerWorks や Adobe Developer Connection などの出版物、そして Amazon Web Services からも度々必要とされています。DanOrlando.com でも、定期的にブログを投稿しています。



2011年 12月 02日

PaaS (Platform as a Service) は、識別するのが難しく、IaaS (Infrastructure as a Service) や SaaS (Software as a Service) と混同されやすいことから、クラウド・コンピューティングの 3 つのタイプのなかで、最もわかりにくいタイプです。全 3 回からなる連載の第 2 回となるこの記事で、PaaS を IaaS や SaaS と異なるものにしている要素、そしてビジネスで PaaS を活用する方法を学んでください。

よく使われる頭文字語

  • API: Application Programming Interface
  • HTTPS: HyperText Transfer Protocol over SSL
  • IDE: Integrated Development Environment
  • ROI: Return On Investment
  • SQL: Structured Query Language
  • SSL: Secure Sockets Layer
  • UI: User Interface

PaaS を IaaS や SaaS と異なるものにしている決定的な要素は、PaaS では、開発者はホストされたインフラストラクチャー上で Web アプリケーションを構築し、そのインフラストラクチャーにデプロイできることにあります。別の言葉で言うと、PaaS を使用することで、クラウド・インフラストラクチャーの無限とも思えるコンピューティング・リソースを利用できるようになります。

無限のコンピューティング・リソースのように見えても、もちろんそれは錯覚であり、使用できるコンピューティング・リソースの量はインフラストラクチャーのサイズによって制限されます。けれども、この連載の第 1 回の記事で学んだように、Google のインフラストラクチャーでは 100 万台を超える x86 ベースのコンピューターが使われていると推定されています。さらに、PaaS のインフラストラクチャーには弾力性 (同じく第 1 回で説明した概念) があり、クラウドは必要に応じてさらに追加のコンピューティング・リソースが提供されるように拡張できるため、無限のリソースという錯覚は完全に想像上のものであるとは言えません。

開発者にとっての PaaS

開発者はよく、クラウド・コンピューティングはネットワーク管理者のみに適用されるものであると誤解していますが、このような誤解をする開発者はクラウド・コンピューティングが開発チームと品質保証チームにもたらす多くの可能性を見落としています。

ソフトウェア開発ライフサイクルの中で問題になりがちなプロセスを考えてみてください。私の経験上、Web アプリケーションを構築する開発チームが手配された後、その Web アプリケーションをホストするサーバー環境を構築するプロセスは、かなり面倒な作業になり得ます。大規模な企業でさえも、通常は 1 人のネットワーク管理者がいくつもの開発チームを担当することになります。PaaS を使用していない場合、開発/テスト環境を構築するためには、一般に以下のタスクが課せられます。

  • サーバーを購入して配備する。
  • オペレーティング・システム、ランタイム環境、ソース管理リポジトリー、およびその他の必要なミドルウェアをインストールする。
  • オペレーティング・システム、ランタイム環境、リポジトリー、および追加のミドルウェアを構成する。
  • 既存のコードを移すか、コピーする。
  • コードをテストおよび実行して、すべてが正常に機能することを確認する。

大抵の場合、管理者にはすでに手に余るほどの仕事が任されているため、新しい環境を配備するのは苦痛のプロセスになる可能性があります。さらに、クライアント・サイドとサーバー・サイド両方の Web アプリケーション開発者にとっては、テストをするためにランタイム環境をローカルに再現するのも大きな問題となります。

ここで、開発チームの一員として、PaaS を使用したとしたらどうなるでしょうか。この場合、サーバー環境がまるごと含まれる仮想マシン (VM) を、USB メモリーで文字通りどこにでも持ち運べることになります。

この連載の話題が PaaS の分析に移るのに伴い、参照用として第 1 回の記事で記載した概念比較表を表 1 にもう一度記載するので、改めてこの表に目を通してみてください。

表 1. クラウド・コンピューティングの 3 つのタイプの概念比較表
パラダイム・シフト特徴鍵となる用語利点欠点およびリスク使用すべきでない場合
IaaS資産としてのインフラストラクチャー通常はプラットフォームに依存しません。インフラストラクチャーにかかるコストは共同で負担されることから、コストが削減される結果となります。その他、SLA、従量課金制、自動スケーリングという特徴があります。グリッド・コンピューティング、ユーティリティー・コンピューティング、コンピューティング・インスタンス、ハイパーバイザー、クラウド・バースティング、マルチテナント・コンピューティング、リソース・プーリングハードウェアおよび人的リソースへの資本支出が不要になります。ROI リスクの軽減、参入障壁の低さ、効率化された自動スケーリングという利点もあります。ビジネスの効率性と生産性は、ベンダーの能力に大きく依存します。長期的な支出が大きくなる可能性があります。一元化には新しい、あるいは異なるセキュリティー対策が必要です。資本予算が運用資産を上回る場合
PaaSライセンス購入クラウド・インフラストラクチャーを使用します。アジャイルなプロジェクト管理手法の必要に応えます。ソリューション・スタックバージョン・デプロイメントの効率化一元化には新しい、あるいは異なるセキュリティー対策が必要です。該当なし
SaaS資産としてのソフトウェア (企業およびコンシューマー)SLA。シン・クライアント・アプリケーションで駆動する UI。クラウドのコンポーネント。API を介した通信。ステートレス。疎結合。モジュール式。セマンティック相互運用性。シン・クライアント。クライアント・サーバー型アプリケーション。ソフトウェアおよび開発リソースへの資本支出が不要になります。RIO リスクが軽減されます。更新は効率的に繰り返し行われます。データの一元化には新しい、あるいは今までとは異なるセキュリティー対策が必要です。該当なし

PaaS の主な構成要素

PaaS を理解するための最も効果的な方法は、PaaS を主要な構成要素、つまりプラットフォームとサービスに分けて考えることでしょう。ここで、PaaS が提供するサービスは「ソリューション・スタック」と呼ばれることを考えると、PaaS の主な構成要素はコンピューティング・プラットフォームとソリューション・スタックであるとするのが理にかなっています。

この 2 つの「構成要素」について説明するために、それぞれの定義をもっと明確にします。コンピューティング・プラットフォームとは、その最も単純な形で言うと、ソフトウェアのコードがそのプラットフォームの基準を満たす限り、一貫した形でそのソフトウェアを起動できる場所のことです。プラットフォームの一般的な例を挙げると、オペレーティング・システムとしては Windows、Apple Mac OS X、Linux、モバイル・コンピューティングの場合は Google Android、Windows Mobile、Apple iOS、ソフトウェア・フレームワークとしては Adobe AIR、Microsoft .NET Framework などがあります。忘れてはならない重要な点として、ここで話題としているのはソフトウェア自体ではなく、ソフトウェアを作成して実行する場所としてのプラットフォームです。図 1 に、この関係を理解できるように図解します。

図 1. クラウド・コンピューティングの他の 2 つのタイプと PaaS の要素との相互関係
クラウド・コンピューティングの他の 2 つのタイプと PaaS の要素との相互関係を示す図

コンピューティング・プラットフォームの概念についての説明は以上です。次に、ソリューション・スタックの定義について説明すると、ソリューション・スタックは開発プロセスを支援するアプリケーション、そしてアプリケーションのデプロイメントを支援するアプリケーションからなります。これらのアプリケーションとは、オペレーティング・システム、ランタイム環境、ソース管理リポジトリー、およびその他の必要なミドルウェアのことです。


プロバイダーの選択

ソリューション・スタックもまた、PaaS プロバイダーを差別化する要因となります。したがって、どの PaaS プロバイダーを使用するかを決定する前に、ソリューション・スタックを細かく検討する必要があります。

特定の PaaS プロバイダーと契約する前に、プロバイダーに確認しておくとよい、いくつかの点を以下に挙げます。

  • サポートされるフレームワークおよび言語。本来、PaaS はそのプラットフォームで使われている言語をベースとするフレームワークのすべてをサポートするべきです。
  • 作成できるアプリケーションの数。ほとんどの PaaS プロバイダーでは、ユーザーが契約したプランまたはパッケージに応じて、作成可能なアプリケーションの数を制限します。自分たちの要求を満たすプランまたはパッケージをプロバイダーが提供していることを確認してください。
  • 許容されるコンテンツのタイプ。通常、PaaS オファリングをサポートするインフラストラクチャーには、マルチテナント・コンピューティングとして知られる概念が使用されています。マルチテナント・コンピューティングでは、複数のテナントが 1 台のサーバー上に共存します。それぞれのテナントは、ハイパーバイザーが管理する VM インスタンスによって互いに隔離されます。このことから、ユーザーがホストするアプリケーションおよびコンテンツのタイプに関して、PaaS プロバイダーが特定の制限を設けている可能性があります。
  • サポートされるデータベースの種類。これは、アプリケーションの一部としてデータも移動しようとしている場合にはプロバイダーを決定する非常に重要な要因となります。プロバイダーが提供するデータベースが、データをインポートするために使用するフォーマットに対応することを必ず確認してください。
  • SSL (HTTPS) をサポートするかどうか。この要因も、セキュリティー上の理由から重要です。アプリケーションでトランザクションを実行する予定でいる場合、後から SSL がサポートされてないことが判明したとしたら、重大な問題に突き当たることになります。

PaaS に関する分析

PaaS についてかなりの知識を得たところで、今度は PaaS プロバイダーを比較するときに検討しなければならない特性を探ります。

  • アプリケーション開発フレームワーク。広く使用されている技術をベースとした堅牢なアプリケーション開発フレームワークであるかどうかを検討してください。本来、ここで注意しなければならないのは、ベンダー・ロックインの可能性です。その点から言うと、通常は Java 技術などのオープンソース・プラットフォームが手堅い選択肢となります。
  • 使いやすさ。事前ビルドされたウィジェット、あらかじめ準備された UI コンポーネント、ドラッグ・アンド・ドロップ・ツール、そして標準 IDE のサポートが揃った、使いやすい WYSIWYG ツールが PaaS に提供されていることを確認してください。それによって、迅速な反復型アプリケーション開発が促進されることになります。
  • BPM (Business Process Modeling) ツール。ビジネス・プロセスをモデル化し、そのモデルを中心にアプリケーションを構築するには、強力な BPM フレームワークが必要です。
  • 可用性。いつでも、どこからでもアクセスして使用できるプラットフォームを選択する必要があります。
  • スケーラビリティー。プラットフォームは、アプリケーションに対する負荷を処理するために、インフラストラクチャーの弾力性を利用できるだけの賢さを持ち合わせていなければなりません。
  • セキュリティー。セキュリティー上の脅威と効果的に戦うには、プラットフォームがクロスサイト・スクリプティング、SQL インジェクション、DoS (Denial of Service: サービス拒否) 攻撃、そしてトラフィックの暗号化に対処し、その対処法をアプリケーション開発の奥深くに根付かせるようにする必要があります。さらにプラットフォームはシングル・サインオン機能をサポートし、その機能を社内の他のアプリケーションや社外のあらゆるクラウド・アプリケーションと統合できるようでなければなりません。
  • 統合機能。プラットフォームには、同じプラットフォームまたは別のプラットフォームで作成された他のアプリケーションを配置、インストール、そして統合できるようにする機能が用意されている必要があります。
  • 移植性。インフラストラクチャーにとらわれず、企業がアプリケーションを IaaS 間で移植できるようなプラットフォームでなければなりません。
  • 移植用ツール。社内のレガシー・アプリケーションから新しいプラットフォームのアプリケーションにデータを迅速かつ簡単に移植できるように、プラットフォームのツールキットには一括インポート変換ツールが含まれていなければなりません。
  • API。ユーザー認証や、ファイル (Web アプリケーション・ファイルや資産など) の保存および取得などのタスク、さらに場合によってはデータベースの直接呼び出しなどのタスクを行うには、プラットフォームには十分なドキュメントが用意された API が必要です。こうした API のドキュメントを参照することで、ビジネスでは企業の特定の要求を満たすプラットフォームとのインターフェースを取るソフトウェア・アプリケーションを柔軟に作成、カスタマイズすることが可能になります。

ベンダー・ロックインへの対処

ベンダー・ロックインとは、顧客が特定のベンダーに依存し、多大な切り替えコストを費やさない限り、別のベンダーを使用できない状態を意味します。まだ普及しつつある段階の、比較的新しい技術には、ベンダー・ロックインを助長する環境を作り出す可能性があります。まさに、クラウド・コンピューティングもそのような技術の 1 つです。IaaS や PaaS を早期に導入する場合は、すぐに長期契約を結ばずに、まず自分が何に関わろうとしているのかを自覚する必要があります。

ベンダー・ロックインを防ぐ 1 つの方法は、API およびプラットフォーム技術を標準化することです。すでに Simple Cloud (「参考文献」を参照) などの組織では、このオープン・プロジェクトへの参加をあらゆる規模のベンダーに呼びかけ、クラウドでの PHP に一貫性をもたらすための取り組みを始めています。プラットフォーム間で共通の抽象化層を提供することを目的に、Zend Technologies、Microsoft、IBM、および Rackspace が協力して Simple Cloud の作成に取り組んでいます。

Simple Cloud API で目標としているのは、ファイル・ストレージ、文書ストレージ、そして単純なキュー・サービスに共通のインターフェースを作成することです。このような共通インターフェースがあれば、主要なクラウド・ベンダー間で移植可能なアプリケーションを作成できるようになります。このプロジェクトのようにクラウド・コンピューティングの標準化を率先しているベンダーに対しては、そのイニシアチブに対して高い評価がなされ、取り組みの継続が奨励されるようにすべきです。企業に PaaS サービスを提供するベンダーを選択するときには、標準化をサポートするプロバイダーに特に注目して詳しく検討することを強くお勧めします。標準は IT 部門の人の作業を楽にするだけでなく、最も重要なことに、企業のコスト削減につながります。

PaaS 市場からベンダー・ロックインの可能性を排除するには、複数のサービス・プロバイダーが 1 つの API を共通してサポートしなければなりません。これを実現するための答えは簡単です。専有技術に依存しているサービス・プロバイダーが、Simple Cloud のような標準化イニシアチブをサポートすることに同意すればよいのです。


まとめ

クラウド・コンピューティングを分析する全 3 回連載の 2 回目となるこの記事では、PaaS の特徴を明らかにし、IaaS や SaaS と識別する方法を説明しました。また、PaaS プロバイダーを選択する際に、プロバイダーに確認しておくとよい事項、そしてベンダー・ロックインなど、プロバイダーを選ぶときに注意すべき問題についても説明しました。この連載の最後となる次回の記事では、SaaS について詳しく調べ、その特徴を明らかにし、IaaS や PaaS と識別する方法を説明します。さらに、SaaS プロバイダーを選択する際に、ビジネスを守るために注意しなければならない事項についても学ぶ予定です。次回の記事までは、「参考文献」セクションに記載されているリンクで PaaS についてさらに詳細を調べてください。

参考文献

学ぶために

議論するために

  • My developerWorks コミュニティーに加わってください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者が主導するブログ、フォーラム、グループ、ウィキを調べることができます。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing
ArticleID=776856
ArticleTitle=クラウド・コンピューティングのサービス・モデル: 第 2 回、Platform as a Service
publish-date=12022011