クラウド・コンピューティングとグリッド・コンピューティングの比較

サービスのタイプ、類似点と相違点、そして検討しなければならない点

クラウド・コンピューティングとグリッド・コンピューティングについて、もっと知りたいですか?IaaS (Infrastructure as a Service) を使用して、Amazon の EC2 (Elastic Compute Cloud) による完全なコンピューター・インフラストラクチャーを手に入れる方法を学んでください。この記事では、クラウド・コンピューティングとグリッド・コンピューティングの類似点、相違点、そして検討しなければならない問題を取り上げるとともに、クラウドでの Web 開発に伴うセキュリティー上の問題と選択肢、そしてクラウド・コンピューティングを使用することがどのように環境保護につながるかを説明します。

Judith Myerson, Systems Engineer and Architect

Judith M. Myerson はシステム・アーキテクト兼システム・エンジニアです。ミドルウェア・テクノロジー、企業単位のシステム、データベース・テクノロジー、アプリケーション開発、ネットワーク管理、セキュリティー、RFID テクノロジー、そしてプロジェクト管理を含む数多くの分野を得意としています。



2009年 3月 03日

はじめに

皆さんはおそらく、クラウド・コンピューティングとグリッド・コンピューティングの違いについて疑問を持ったことがあるのではないでしょうか。そこでこの記事では、クラウド・コンピューティングのサービス・タイプ、そしてグリッド・コンピューティングと似ている点、異なる点について説明します。そのなかでも、なぜクラウド・コンピューティングを利用したほうがグリッド・コンピューティングよりもメリットがあるのか、またクラウド・コンピューティングとグリッド・コンピューティングで検討しなければならない問題やセキュリティーに関する問題について見て行きます。説明では、Amazon Web サービスを例として引用します。

クラウド・コンピューティングを機能させるために必要になるのは、シン・クライアント (またはシック/シンを切り替えられるクライアント)、グリッド・コンピューティング、ユーティリティー・コンピューティングの 3 つです。グリッド・コンピューティングが個々のコンピューターを結び付けて 1 つの大きなインフラストラクチャーを形成し、使用されていないリソースを利用します。ユーティリティー・コンピューティングは、いわば公共料金 (電気、ガスなど) の支払いと同じく、ユーザーに共用サーバーで使用した分だけ料金を課します。

グリッド・コンピューティングでは、ユーザーがコンピューティング・リソースをオン/オフの切り替えが可能なユーティリティーとしてプロビジョニングすることができます。クラウド・コンピューティングはこれを一歩進めて、需要に応じたリソース・プロビジョニングを可能にします。つまり、クラウド・コンピューティングでは使用した分だけ料金を支払うことになるため、過剰にプロビジョニングすることがなくなります。また、数百万人のユーザーの需要に合わせるために、あらかじめ余裕を持ってプロビジョニングする必要もありません。

IaaS (Infrastructure as a Service)、その他

利用者は、インターネットを介して完全なコンピューター・インフラストラクチャーからサービスを受けられます。このようなサービスは、IaaS (Infrastructure as a Service) と呼ばれます。ストレージやデータベースなどのインターネット・ベースのサービスは、IaaS の一部です。インターネット上でのサービスにはこの他、PaaS (Platform as a Service)、SaaS (Software as a Service) というタイプもあります。PaaS はユーザーがアプリケーションを開発する際に全面的、あるいは部分的に利用することができます。SaaS は、Enterprise Resource Management といったすぐに使用できる完全なターンキー・アプリケーションを、インターネット経由で提供するサービスです。

IaaS が実際にどのように利用されているかを理解するには、36 時間以内に何百もの Amazon の EC2 インスタンスを使用して数テラバイトのアーカイブ・データを処理する The New York Times を考えてみてください。The New York Times が EC2 を使っていなかったとしたら、データの処理に何日も、あるいは何か月もかかっていたことでしょう。

IaaS の利用方法は、パブリックとプライベートの 2 つのタイプに分けられます。Amazon EC2 ではインフラストラクチャー・クラウド内にあるパブリック・サーバー・プールを使用しますが、それよりもプライベートなクラウド・サービスでは企業内部のデータ・センターのパブリックまたはプライベート・サーバー・プールのグループを使用します。企業のデータ・センターの環境内で両方のタイプを使用してソフトウェアを開発し、EC2 によって例えばテストのために一時的に、しかも低価格でリソースを拡張することができます。この組み合わせは、開発サイクルとテスト・サイクルを短縮してアプリケーションおよびサービスをより短期間で開発する方法となるはずです。

Amazon Web サービス

EC2 では、顧客がオペレーティング・システム、アプリケーション、そしてデータが含まれる AMI (Amazon Machine Image) を独自に作成し、AMI ごとに実行するインスタンス数をその時々で制御します。顧客が支払うのは、インスタンスを使用した時間 (そして帯域幅) の分だけです。ピーク時にコンピューティング・リソースを追加する必要も、不要になったときに削除する必要もありません。EC2 や S3 (Simple Storage Service)、そしてその他の Amazon によるサービスがスケール・アップして、数百万人のユーザーに対応できるだけの大容量のサービスをインターネット経由で提供します。

Amazon は、シングルコアの x86 サーバーから 8 つのコアを搭載した x86_64 サーバーまで、5 種類のサーバー・タイプを用意しています。ユーザーは、サービス・インスタンスを提供するためにどのサーバーが使用されているかを知る必要はありません。インスタンスは地理的に分散した場所 (Availability Zone) に配置することが可能です。Amazon では、動的にインスタンスに割り当てることのできるエラスティック IP アドレスを使用できます。

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

クラウド・コンピューティングを利用すると、企業が新しいインフラストラクチャーに投資したり、新しいスタッフをトレーニングしたり、新しいソフトウェアのライセンス契約をしたりすることなく、瞬時に処理容量の大幅なスケール・アップをすることができます。クラウド・コンピューティングがとりわけ利益をもたらすのは、データ・センター・インフラストラクチャーを完全にアウトソースしたいという中小企業や、高いコストをかけて大規模なデータ・センターを社内に構築することなくピーク時の負荷に対応できる容量を確保したいという大企業です。いずれの場合も、サービスの利用者はインターネットで必要なものを使用し、使用した分だけ支払います。

サービスの利用者は、もはや PC を操作したり、PC のアプリケーションを使用したりする必要はありません。スマートフォンや PDA、あるいはその他の機器用に構成された特定バージョンのソフトウェアの購入も不要になります。利用者はクラウド内のインフラストラクチャー、ソフトウェア、プラットフォームを所有するわけではないため、先行投資、資本支出、運営コストを抑えられます。クラウド内のサーバーとネットワークの保守は、利用者の関与するところではありません。利用者は地球上のどこからでも、それがどのサーバーなのか、そしてどこに配置されているかを知ることなく、複数のサーバーにアクセスすることができます。

グリッド・コンピューティング

クラウド・コンピューティングはグリッド・コンピューティングから進化したもので、利用状況に応じてリソースをプロビジョニングすることができます。グリッド・コンピューティングは、これを使用するユーザーのタイプによって、クラウド内に含まれる場合も、含まれない場合もあります。ユーザーがシステム管理者やシステム・インテグレーターであれば、彼らにとってクラウド内での保守方法は重要な関心事であり、サーバーおよびアプリケーションのアップグレード、インストール、仮想化を行います。ユーザーがサービスの利用者である場合には、システム内で何がどのように実行されているかには関心を持ちません。

グリッド・コンピューティングでは、1 つの大規模なシステム・イメージとしてのプログラムを分割し、それぞれの部分を数千台のコンピューターに委託することが可能なソフトウェアを使用する必要があります。グリッドに関する 1 つの懸念事項は、あるノード上でソフトウェアのある部分に障害が発生した場合、別のノードでそのソフトウェアの別の部分に障害が発生する可能性があることです。別のノード上に、そのコンポーネントのフェイルオーバー・コンポーネントがあれば、このような事態が起こる可能性は低くなります。ただし、コンポーネントが 1 つ以上のグリッド・コンピューティング・タスクを実現するためにソフトウェアの別の部分に依存しているとしたら、問題は依然として発生する可能性があります。また、大規模なシステム・イメージとその操作と管理に関連するハードウェアによって、資本支出と運営コストが大きく膨らむことが考えられます。

類似点と相違点

クラウド・コンピューティングとグリッド・コンピューティングはどちらもスケーラブルです。このスケーラビリティーは、アプリケーション・インスタンスを各種のオペレーティング・システムでそれぞれ独立して実行し、Web サービスで接続したこれらのアプリケーション・インスタンスを負荷分散することによって実現されます。CPU とネットワーク帯域幅の割り当て、割り当て解除は使用量に応じて行われます。システムのストレージ容量は、ユーザーの数、インスタンスの数、そしてデータ転送量に応じて常に増減します。

いずれのコンピューティング・タイプにも、マルチテナントおよびマルチタスクが関係します。これはつまり、多数の顧客が異なるタスクを実行して、単一または複数のアプリケーション・インスタンスにアクセスすることが可能であるという意味です。インフラストラクチャーのコスト、およびピーク時の負荷容量は、大規模なユーザーのプールでリソースを共用することによって削減することができます。クラウド・コンピューティングおよびグリッド・コンピューティングが規定するサービス・レベル・アグリーメント (SLA) では、約 99 パーセントのアップタイムを保証しています。もし、この保証しているアップタイムのサービス・レベルを下回った場合、利用者にはデータの受信が遅れたことに対して使用料が控除されることになります。

Amazon S3 では、クラウド内でのデータの保存および取得用の Web サービス・インターフェースを提供しています。S3 に保存できるオブジェクト数は、最大数の設定によって制限されます。オブジェクトのサイズについては、S3 にはわずか 1 バイトのオブジェクトから 5 GB の大きなオブジェクト、さらには数テラバイトのオブジェクトまで保存することができます。S3 ではオブジェクトを保存する各ロケーションのコンテナーとして、バケットの概念を採用しています。データは、Amazon 自体の e-コマース Web サイトに使用されているデータ・ストレージ・インフラストラクチャーと同じインフラストラクチャーを使用して、確実に保存されます。

グリッド・コンピューティングのストレージは大量のデータを保存するには適切ですが、1 バイト程度の小さなオブジェクトを保存する場合には経済的と言えません。データ・グリッドのメリットを最大限に生かすには、大量の分散データであることが条件となります。

計算グリッドが重点を置くのは、計算主体の操作です。一方クラウド・コンピューティングの場合で言うと、Amazon Web サービスではスタンダードと High-CPU という 2 つのインスタンス・タイプを用意しています。

検討すべき問題

クラウド・コンピューティングとグリッド・コンピューティングには、顕著な問題が 4 つあります。それは、しきい値ポリシー、相互運用性の問題、隠れたコスト、そして不測の振る舞いです。

しきい値ポリシー

例えば、クラウド内で使用しているクレジット・カードの検証プログラムが、年末のバーゲン・シーズン中に対応しきれなくなったとします。需要の増加が検出されると、その需要に対応するために追加インスタンスが作成されます。バーゲン・シーズンが過ぎれば、これらの追加インスタンスの必要はなくなるため、リソースのインスタンスの割り当てが解除されて、他の用途に回されることになります。

このプログラムが機能するかどうかをテストするには、プログラムを本番環境に移す前のパイロット環境で、しきい値ポリシーを開発するか、または既存のしきい値ポリシーを改善して実装してください。そのポリシーが突然の需要の増加を検出し、追加のインスタンスを作成して需要を満たす結果になるかどうかを確認します。また、未使用のリソースの割り当てを解除して他の作業に割り当てる方法についても判断する必要があります。

相互運用性の問題

企業がアプリケーションのアウトソースや作成において 1 つのクラウド・コンピューティング・ベンダーだけを利用している場合、独自仕様の API、そしてデータのインポートおよびエクスポートに異なるフォーマットを使用している別のコンピューティング・ベンダーに変えるのは難しい場合があります。このような場合に問題となるのは、この 2 つのクラウド・コンピューティング・ベンダー間でのアプリケーションの相互運用性です。相互運用性をもたらすには、データのフォーマットを設定し直したり、アプリケーションのロジックを変更したりしなければならないことが考えられます。API やデータのインポート/エクスポートに関するクラウド・コンピューティングの業界標準はありませんが、IBM と Amazon Web サービスでは連携して相互運用性を実現しています。

隠れたコスト

クラウド・コンピューティングでは、どのようなコストが発生するかがわかりません。例えば、クラウド内でストレージ・アプリケーションやおよびデータベース・アプリケーションに数テラバイトのデータが含まれることから、サービス・プロバイダーから企業に請求されるネットワーク料金が高くなる場合があります。そうなると、新しいインフラストラクチャーや新しいスタッフのトレーニング、または新しいソフトウェアのライセンスに費用をかけたほうがコスト削減になります。ネットワーク料金を引き上げる原因としては、クラウド・プロバイダーから遠く離れた場所にある企業で起こり得るネットワーク遅延も挙げられます。このような遅延は、特にトラフィックが重いときに発生する可能性が高くなります。

不測の振る舞い

例えば、クレジット・カードの検証アプリケーションが企業内部のデータ・センターで有効に機能しているとします。そうだとしても、このアプリケーションをクラウド内でパイロット環境を使ってテストし、予測できない振る舞いをしないかどうかを調べることが重要です。テストの例には、アプリケーションのクレジット・カード検証動作のテスト、そして年末のバーゲン・セールのシナリオではどのようにリソースを割り当て、未使用のリソースを解放して他の作業に回すかなどのテストがあります。テストによって、クレジット・カードの検証や未使用リソースの解放で予期せぬ結果が示された場合には、クラウド内でアプリケーションを実行する前に、その問題を修正する必要があります。

セキュリティー上の問題

2008年2月、Amazon の S3 および EC2 で 3 時間に及ぶ機能停止が発生しました。SLA ではこの類の停止に対してデータ・リカバリーとサービス料金の控除を規定しているものの、この停止時間中、利用者が販売の機会を逃したことにも、経営陣が重要なビジネス情報から遮断されたことにも変わりありません。

機能停止が発生するまで待つのではなく、利用者は独自のセキュリティー・テストを行って、ベンダーのデータ・リカバリー能力を確認するべきです。このテストは非常に単純で、ツールは一切必要ありません。必要な作業は、すでに保存してある古いデータを要求し、ベンダーがそのデータをリカバリーするまでの時間を調べるというだけです。リカバリーにあまりにも時間がかかるようであれば、ベンダーにその理由と、さまざまな状況でどれだけサービス料金が控除されるかを尋ねてください。また、チェックサムが元のデータと一致するかどうかも確認します。

行うべきセキュリティー・テストの分野として、まずは信用できるアルゴリズムでローカル・コンピューター上のデータを暗号化した後、クラウド内のリモート・サーバー上のデータに復号キーを使ってアクセスしてみます。データにアクセスできてもデータを読み取れないのであれば、復号キーが壊れているか、またはベンダーが独自の暗号化アルゴリズムを使っているということになります。その場合には、そのベンダーが使用しているアルゴリズムに対応しなければなりません。

もう 1 つの問題は、クラウド内でデータに問題が発生する可能性があることです。データを保護するために、独自の秘密鍵を管理しなければならない場合があります。ベンダーによる秘密鍵の管理について確認してください。Amazon では、サインアップしたユーザーに証明書を与えます。

クラウド内でのソフトウェア開発

ハイエンド・データベースを使用してソフトウェアを開発する場合に最も有望な選択肢は、企業の内部データ・センターでクラウド・サーバーのプールを使用し、テストするときにだけ一時的に Amazon Web サービスでリソースを拡大するという方法です。この方法では、プロジェクト・マネージャーがコストおよびセキュリティーを管理しやすくなるとともに、プロジェクトが割り当てられているクラウドにリソースを分配するのも容易になります。また、プロジェクト・マネージャーは、個別のハードウェア・リソースをそれぞれ異なるタイプのクラウド (Web 開発用クラウド、テスト用クラウド、本番用クラウド) に割り当てることもできるようになります。クラウドに伴うコストは、クラウドのタイプによって異なります。開発用クラウドでの 1 時間あたりの使用料は、本番用クラウドよりも大抵は低くなります。その理由は、本番用クラウドには SLA やセキュリティーなどの機能が追加で割り当てられるためです。

プロジェクト・マネージャーは、プロジェクトを特定のクラウドに制限することができます。例えば、本番用クラウドのサービスは本番構成に使用し、開発用クラウドからのサービスは開発にのみ使用することが考えられます。ソフトウェア開発プロジェクトのさまざまな段階でアセットを最適化するには、マネージャーはプロジェクトとユーザーによるアセットの利用状況を追跡して原価計算データを入手するという方法を採ることができます。コストが高くなると判明した場合には、マネージャーは Amazon EC2 を使用して一時的に、しかも非常に少ないコストでリソースを拡張することができます。ただしそれには、セキュリティーとデータ・リカバリーの問題が解決されていなければなりません。

環境に優しいクラウド・コンピューティング

クラウド・コンピューティングを推奨する理由の 1 つは、これが、より環境に優しい方法になる可能性があるからです。第一に、企業の内部データ・センターでアプリケーションを実行するために必要なハードウェア・コンポーネントの数を減らし、代わりにクラウド・コンピューティング・システムを使用すれば、ハードウェアを稼働および冷却するエネルギーの節約となります。これらのシステムをリモート・センターで統合することによって、1 つのまとまったグループとして一層効率的に操作することができます。

第二の理由は、クラウド・コンピューティングの手法は、リモート出力やファイル転送などの通信技術を促進することになるため、必要なオフィス空間が縮小される可能性があることです。オフィス空間が縮小されれば、新たな備品を購入したり、古い備品を廃棄したりすることがなくなり、さらに薬品でオフィスを清掃する必要も、ゴミを処理する必要なども減ってきます。その上、職場までの自動車通勤で排出される二酸化炭素も削減されます。

まとめ

この記事では、クラウドとの連携を前もって計画できるように、クラウド・コンピューティングとグリッド・コンピューティングを比較し、クラウド・コンピューティングとグリッド・コンピューティングでの問題を解決する方法、そして使用量に応じて料金が発生する環境内でのデータ・リカバリーおよび秘密鍵の管理に伴うセキュリティー上の問題について説明しました。潜在的利用者の需要に応じてインターネットで処理容量を増加させることは、プロジェクト・チームの開発者やその他のメンバーにとっての大きな課題です。チームが円滑に作業を進めるためには、Web アプリケーションの設計と考えられるセキュリティー上の問題を認識し、解決することが鍵となります。参考として、Web アプリケーションを構築するための IBM Rational Web Developer for WebSphere Software、そしてアプリケーションの障害および変更を検出して追跡するためのツール、IBM Rational ClearQuest を調べてください (「参考文献」を参照)。

参考文献

学ぶために

製品や技術を入手するために

議論するために

コメント

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=Web development
ArticleID=379514
ArticleTitle=クラウド・コンピューティングとグリッド・コンピューティングの比較
publish-date=03032009