サービス・レベル・ アグリーメントの紹介

第 4 版で追加された内容 - SLA

クラウド・コンピューティング ユース・ケース ホワイト・ペーパー

第 4.0 版

Cloud Computing Use Cases Discussion Group

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

Cloud Computing Use Case Discussion Group

第 4.0 版

2010 年 7 月 2 日 コントリビューター: Miha Ahronovitz, Dustin Amrhein, Patrick Anderson, Andrew de Andrade, Joe Armstrong, Ezhil Arasan B, James Bartlett, Richard Bruklis, Ken Cameron, Mark Carlson, Reuven Cohen, Tim M. Crawford, Vikas Deolaliker, Pete Downing, Andrew Easton, Rodrigo Flores, Gaston Fourcade, Thomas Freund, Tom Hanan, Valery Herrington, Babak Hosseinzadeh, Steve Hughes, William Jay Huie, Nguyen Quang Hung, Pam Isom, Shobha Rani J, Sam Johnston, Ravi Kulkarni, Anil Kunjunny, Edmond Lau, Thomas Lukasik, Bob Marcus, Gary Mazzaferro, Craig McClanahan, Meredith Medley, Walt Melo, Andres Monroy-Hernandez, Ayman Nassar, Dirk Nicol, Lisa Noon, Santosh Padhy, Gilad Parann-Nissany, Greg Pfister, Thomas Plunkett, Ling Qian, Balu Ramachandran, Jason Reed, German Retana, Bhaskar Prasad Rimal, Dave Russell, Matt F. Rutkowski, Clark Sanford, Krishna Sankar, Alfonso Olias Sanz, Mark B. Sigler, Wil Sinclair, Erik Sliman, Patrick Stingley, Phillip Straton, Robert Syputa, Robert J. Taylor, Doug Tidwell, Kris Walker, Kurt Williams, John M Willis, Yutaka Sasaki, Michael Vesace, Eric Windisch, Pavan Yara and Fred Zappert. この文書に関するコメントは http://cloudusecases.org にお寄せください。 皆様のコメントをお待ちしています。

この著作物は、Creative Commons Attribution Share Alike 3.0 Unported License の 下で認可されています。

『クラウド・コンピューティング・ユース・ケース ホワイト・ペーパー』は、オープン・コミュニティーのアプローチを用いて作成され、1,400 を超える世界中のメンバーからなるコミュニティーからのインプットがベースとなっています。メンバーには小規模および大規模企業、政府機関、コンサルタント、サプライヤーも含まれており、クラウド・コンピューティング・コミュニティーの要件を反映する構成となっています。 このホワイト・ペーパーでは、以下の 3 つの非常に重要な原則を採用しています。 1) 利用者は共通の要件を定めるために協力する 2) 要件には「オープン・クラウド」を反映させる 3) 可能な限り既存のオープン・スタンダードを使用する この文書は、コミュニティーからより多くの情報を受け取り、新しいトピックを追加することで改訂されます。第 3 版から日本語への翻訳が開始され、今後も続けられる予定です。 Cloud Computing Use Case Discussion Group は、このホワイト・ペーパーが日本の IT コミュニティーに価値を提供することを確信しています。Japan Cloud Computing Use Cases (http://groups.google.com/group/japan-cloud-computing-use-cases?hl=ja) にもぜひコメントをお寄せください。 すべてのディスカッション・グループには、http://www.cloudusecases.org からアクセスできます。日本語版のホワイト・ペーパーはこちらのサイトにも掲載されています。また上記Googleグループに開設されたJapan Cloud Computing Use Casesの「ファイル」セクションにも掲載されています。

下で認可されています。 この著作物は、Creative Commons Attribution Share Alike 3.0 Unported License の

Cloud Computing Use Cases White Paper Version 4.0

目次

1 はじめに.......................................................................................................................5

2 定義および分類 ............................................................................................................7

2.1 クラウド・コンピューティングの概念の定義 ......................................................7

2.2 分類..................................................................................................................... 11

2.3 標準と分類との関係............................................................................................14

2.4 アプリケーション・プログラミング・インターフェース (API) ........................16

3 ユース・ケース・シナリオ ........................................................................................19

3.1 エンド・ユーザーとクラウド .............................................................................20

3.2 企業とクラウドとエンド・ユーザー...................................................................21

3.3 企業とクラウド...................................................................................................24

3.4 企業とクラウドと企業 ........................................................................................25

3.5 プライベート・クラウド ....................................................................................27

3.6 クラウド・ベンダーの変更 .................................................................................28

3.7 ハイブリッド・クラウド ....................................................................................30

3.8 相互参照: 要件およびユース・ケース................................................................32

4 お客様のシナリオ ......................................................................................................34

4.1 お客様のシナリオ: クラウドでの給与計算処理 .................................................34

4.2 お客様のシナリオ: クラウドでのロジスティクスとプロジェクト・

マネジメント ......................................................................................................36

4.3 お客様のシナリオ: クラウドでの中央官庁サービス ..........................................37

4.4 お客様のシナリオ: ハイブリッド・クラウドでの地方自治体サービス..............38

4.5 お客様のシナリオ: 天文データの処理................................................................39

5 開発者の要件 .............................................................................................................41

6 セキュリティー・シナリオ ........................................................................................44

6.1 規制.....................................................................................................................44

6.2 セキュリティー・コントロール..........................................................................45

6.3 セキュリティーフェデレーション・パターン ....................................................47

7 セキュリティーに関するユース・ケース・シナリオ.................................................49

7.1 クラウド・コンピューティング性能...................................................................49

7.2 クラウド・ベースの開発およびテスト ...............................................................50

7.3 ストレージ・クラウド ........................................................................................52

2 July 2010 3

Cloud Computing Use Cases White Paper Version 4.0

7.4 相互参照: セキュリティー・コントロールとお客様のシナリオ ........................53

7.5 相互参照: セキュリティーフェデレーション・パターンとお客様のシナリオ ...54

8. サービス・レベル・アグリーメント (SLA)...............................................................55

8.1 SLA とは ............................................................................................................55

8.2 サービス・レベル目標 ........................................................................................56

8.3 サービス・レベル管理 ........................................................................................57

8.4 SLA に関する考慮事項.......................................................................................57

8.5 SLA の要件.........................................................................................................60

8.6 信頼性に関する注意事項 ....................................................................................63

8.7 相互参照: SLA の要件とクラウド・デリバリー・モデル...................................64

8.8 相互参照: SLA の要件とユース・ケース・シナリオ ..........................................64

9. 結論と推奨事項 ..........................................................................................................66

変更の要約 ......................................................................................................................68 第 4.0 版について: 第 4.0 版では、「セクション 8 サービス・レベル・アグリーメント (SLA)」を新たに追加しました。詳細については、68 ページの「変更の要約」を参照してください。

2 July 2010 4

Cloud Computing Use Cases White Paper Version 4.0

1 はじめに Cloud Computing Use Case Group は、クラウドのコンシューマー (利用者) とベンダーとから構成され、クラウド・コンピューティングにおける共通のユース・ケース・シナリオの定義をおこなっています。ここで紹介するユース・ケース・シナリオでは、クラウド・コンピューティングのパフォーマンスおよび経済的利益について示しています。また、これらのユース・ケース・シナリオは、考えうる も広い範囲でのコンシューマー（利用者）のニーズに合わせて作成されています。 このホワイト・ペーパーでは、相互運用性、統合の容易性、および可搬性を確保するためにクラウド環境で標準化する必要がある機能および要求を浮き彫りにすることを目的としています。このホワイト・ペーパーで取り上げるすべてのユース・ケースは、クローズな独自技術を使用せずとも実装できる必要があります。 クラウド・コンピューティングは、ベンダーによる囲い込みを 小限に抑え、お客様の選択の幅を広げながら、オープンな環境として発展しなければならないのです。 これらのユース・ケースは、以下のような役割を果たします。

相互運用性および標準に関する議論を進めるための、実践的でお客様の体験に基づく文脈を提供します。

既存の標準を使用すべき部分を明確にします。

オープンなクラウド・コンピューティングの重要性に対する業界の注目を喚起します。

• 標準化作業が必要な部分を明確にします。現時点で特定のユース・ケースを構築できない、あるいは独自の API および製品を使用しない限り構築できない場合は、そのユース・ケースを構築できるよう、業界にて標準を策定していく必要があります。

共通の作業を明確に表現し、その作業を遂行するにあたっての問題点を大まかに示すユース・ケースは、あらゆる標準化作業にとって 高の理由付けとなります。 Open Cloud Manifesto (opencloudmanifesto.org) は、クラウド・コンピューティングのオープン性を保持していくための原則について述べたものです。発表から 2 カ月も経たないうちに 250 の組織がこの原則についてのサポートを表明しました。このグループでは、以下のような Open Cloud Manifesto で定める 6 つの原則を踏まえたかたちで活動を行っています。

クラウド・プロバイダーは、オープンなコラボレーションと標準の適切な利用により、クラウド適用の課題に協力して取り組む必要があります。

クラウド・プロバイダーは、可能な限り、既存の標準を利用および適用する必要があります。IT 業界では既存の標準策定ならびに標準化団体に対し多大な投資を行っているため、似たような作業を重複して行ったり、策定のし直しを行ったりする必要はありません。

2 July 2010 5

Cloud Computing Use Cases White Paper Version 4.0

新しい標準 (または既存の標準の修正) が必要な場合は、標準の乱立を避けるために賢明かつ実用的な態度を取る必要があります。標準は技術革新を促進するものであり、妨げるものであってはなりません。

オープンなクラウドに向けたあらゆるコミュニティー活動は、お客様のニーズに基づき推進されるべきであり、クラウド・プロバイダーの技術的な必要性にのみ基づいて進められるべきではありません。また、テストや検証も、実際のお客様の要件に基づいて行われるべきです。

クラウド・コンピューティングの標準化団体、支持団体、およびコミュニティーは、お互いの活動が矛盾または重複しないよう協業をし、調和を保つ必要があります。

クラウド・プロバイダーは、市場での立場を利用して特定のプラットフォームにお客様を囲い込み、選択できるプロバイダーを狭めてはなりません。

このホワイト・ペーパーは、上記の原則を現実化するための進行中の活動の一環として作成されました。

2 July 2010 6

Cloud Computing Use Cases White Paper Version 4.0

2 定義および分類 クラウド・コンピューティングの概念の概要を示すために、以下に定義およびその分類を示します。ただし、このホワイト・ペーパーの焦点は、現実の世界におけるアプリケーションや要件に基づき、クラウドのシナリオやユース・ケースを定義することであり、クラウド・コンピューティング自体の定義をすることではありません。目的は、シナリオがどのように定義されるか、または分類のなかでどこに位置するかにかかわらず、明確で興味深く実用的なユース・ケース・シナリオを提供することです。 2.1 クラウド・コンピューティングの概念の定義 クラウド・コンピューティング: クラウド・コンピューティングは、構成可能なコンピューター・リソース (ネットワーク、サーバー、ストレージ、アプリケーション、サービスなど) の共有プールにネットワーク経由でどこからでも便利にオンデマンドでアクセスすることができるモデルであり、 小限の管理作業やサービス・プロバイダーとのやり取りにより、迅速にサービスの提供や公開が可能となります。 (これは米国国立標準技術研究所が発行している『NIST Working Definition of Cloud Computing』の 新ドラフトにおける定義になります 1)。 2.1.1 デリバリー・モデル NIST によるクラウド・コンピューティングの定義では、以下の 3 つのデリバリー・モデルを定義しています。

Software as a Service (SaaS): 利用者はアプリケーションを利用しますが、アプリケーションが稼動するオペレーティング・システム、ハードウェア、またはネットワーク・インフラストラクチャーの制御はしません。

Platform as a Service (PaaS): 利用者は、アプリケーションのホスティング環境を利用します。利用者はその環境で実行されるアプリケーションを制御します(また場合によっては、ホスティング環境もある程度制御することができます) が、アプリケーションが実行されるオペレーティング・システム、ハードウェア、またはネットワーク・インフラストラクチャーは制御できません。プラットフォームは、通常、アプリケーション・フレームワークです。

Infrastructure as a Service (IaaS): 利用者は、プロセッシング・パワー、ストレージ、ネットワーク・コンポーネント、ミドルウェアなどの「基本的なコンピューター・リソース」を利用します。利用者は、オペレーティング・システムやストレージ、デプロイされているアプリケーション、また場合によっては、ファイアウォールやロード・バランサーなどのネットワーク・コンポーネントを制御できますが、その下のクラウド・インフラストラクチャーは制御できません。

1 全文は NIST のクラウド・コンピューティングのページ (http://csrc.nist.gov/groups/SNS/cloud-computing/) に掲載されています。この文書には、「この資料の所

有権は NIST に帰属しますが、どなたでもご利用いただけます。また自由に複製または翻訳していただ

くことも可能です。」と記載されています。このホワイト・ペーパーで取り上げる基本的な特徴、デリ

バリー・モデル、および実装モデルは、2009 年 8 月 19 日発行の第 15 版を基にしています。

2 July 2010 7

Cloud Computing Use Cases White Paper Version 4.0

2.1.2 実装モデル NIST の定義では、以下の 4 つの実装モデルが定義されています。

パブリック・クラウド: 簡単に言うと、パブリック・クラウド・サービスは、サード・パーティーであるサービス・プロバイダーからインターネット経由でお客様に提供されることを特徴としています。無料またはかなり低価格で利用できる場合もありますが、「パブリック」という言葉が必ずしも無料を意味するわけではありません。また、パブリック・クラウドは、ユーザーのデータが誰からでも閲覧可能であるということでもありません。一般にパブリック・クラウド・ベンダーは、ユーザーにアクセス制御の仕組みを提供しています。パブリック・クラウドでは、弾力的で費用対効果に優れた手段によりソリューションを展開しています。

プライベート・クラウド: プライベート・クラウドは、弾力性やサービス指向といった、パブリック・クラウド・コンピューティング環境のもつ利点の多くを提供します。プライベート・クラウドとパブリック・クラウドの違いは、プライベート・クラウド・ベースのサービスでは、パブリック・クラウド・サービスの利用に伴い発生するネットワーク帯域幅や機密漏れ、法的要件における制約を受けることなく、組織内でデータおよび処理が管理されるという点です。また、プライベート・クラウド・サービスでは、ユーザーのアクセスや使用するネットワークが制約かつ明確化されているため、プロバイダーやユーザーがクラウド・インフラストラクチャーをより制御でき、セキュリティーや弾力性を強化することができます。2

コミュニティー・クラウド: コミュニティー・クラウドは、特定のセキュリティー要件や共通の業務といった共通の興味を持つ組織グループによって制御および利用されます。コミュニティーのメンバーは、クラウド内のデータおよびアプリケーションへのアクセスを共有します。

ハイブリッド・クラウド: ハイブリッド・クラウドは、パブリック・クラウドとプライベート・クラウドの組み合わせにより、相互運用されるものです。このモデルでは、ユーザーは、通常、業務上重要ではない情報および処理をパブリック・クラウドに外部委託し、業務上重要なサービスおよびデータは自らの制御下に保ちます。3

2.1.3 基本的な特徴 NIST の定義では、クラウド・コンピューティングの 5 つの基本的な特徴が説明されています。

迅速な弾力性: 弾力性とは、必要に応じてリソースを拡張または縮小できる機能と定義されています。利用者側から見ると、クラウドは無限のリソースに見え、利用者は多い場合も少ない場合も必要な量のコンピューティング性

2 プライベート・クラウドはサード・パーティーによって管理され、物理的には使用する組織の敷地の

外にある場合もあります。必ずしもプライベート・クラウドを使用する組織がプライベート・クラウド

を管理し、ホストするわけではありません。 3 ハイブリッド・クラウドは、コミュニティー・クラウドで使用される技術の上位集合です。このため、

セクション 3.7 では、「ハイブリッド・クラウド」という見出しの下、この 2 つの実装モデルに対す

る要件をまとめて説明します。

2 July 2010 8

Cloud Computing Use Cases White Paper Version 4.0

能を購入できます。弾力性は、NIST の定義におけるクラウド・コンピューティングの基本的な特徴の 1 つです。

従量制サービス: 従量制サービスでは、クラウド・プロバイダーがクラウド・サービスの状況を制御、監視しています。このような機能は、請求やアクセス制御、リソースの 適化、キャパシティー・プランニング、その他タスクにおいて非常に重要となってきます。

オンデマンドなセルフサービス: クラウド・コンピューティングのオンデマンドなセルフサービスとは、利用者がクラウド・プロバイダーと人を介したやり取りを一切行わず、に必要に応じてクラウド・サービスを使用できることを意味します。

どこからでも利用できるネットワーク・アクセス: どこからでも利用できるネットワーク・アクセスとは、クラウド・プロバイダーが提供する機能をネットワーク経由で利用でき、ファット・クライアントおよびシン・クライアントの両方が標準的な仕組みを経由してこれら機能にアクセスできることを意味します。4

リソースのプール化: リソースをプール化することにより、クラウド・プロバイダーはマルチテナント・モデルを使用して利用者にサービスを提供できます。物理リソースおよび仮想リソースは、利用者の需要によって割り当てまたは再割り当てされます。お客様は一般的に提供されるリソースの正確な位置を制御できず、正確な位置を把握していないが、より高い抽象化レベル (国、州、データ・センターなど) で場所を指定できる場合があるという意味で場所からの独立性があります。5

2.1.4 その他の用語 相互運用性: 相互運用性は、システム間の通信機能に関係します。相互運用性を実現するには、情報を受信するシステムが伝えられる情報を理解する必要があります。クラウド・コンピューティングの世界では、これは、プロバイダー間の相違点にかかわらず 2 つ以上のクラウド・プロバイダーが同時に使用できるコードを作成できることを意味します。6

可搬性: 可搬性とは、ある環境向けに作成されたコンポーネントまたはシステムを別の環境で実行できることです。クラウド・コンピューティングの世界では、ソフトウェアおよびハードウェア環境 (物理環境と仮想環境の両方) が対象となります。

4 必ずしもインターネット・アクセスとは限りません。定義上、プライベート・クラウドには、ファイ

アウォールの中でのみアクセスが可能です。ネットワークのタイプにかかわらず、一般的にクラウドへ

のアクセスが特定のタイプのクライアントに限定されることはありません。 5 多くの場合、プライバシー法などの規制により、クラウド・プロバイダーのリソースをある特定の 1 カ所に置くことが求められます。クラウド・プロバイダーおよびクラウド利用者は、これらの規制を順守

するために協力しなければなりません。 6 相互運用性、可搬性、および統合の定義は、http://www.testingstandards.co.uk/interop_et_al.htm の内

容に基づいています。

2 July 2010 9

Cloud Computing Use Cases White Paper Version 4.0

統合: 統合とは、コンポーネントやシステムを 1 つの総合システムに一体化するプロセスです。クラウド・ベースのコンポーネントおよびシステム間の統合は、マルチテナンシー、フェデレーション、政府による規制などの問題によって複雑化する場合があります。 サービス・レベル合意書 (SLA): SLA はプロバイダーと利用者間で定める規約で、利用者の要件と、その要件に対するプロバイダーの実施義務を定義しています。一般的に SLA には、サービスの使用可能な時間、プライバシー、セキュリティー、バックアップ手順などが定められます。 フェデレーション: フェデレーションとは、複数のシステム間でデータや ID 情報を連携させることです。フェデレーションは、クラウド・プロバイダーまたはクラウド・ブローカーによって行われる場合があります。 ブローカー: ブローカーは、自らはクラウド・リソースを持たず、利用者が求める SLA に基づき、利用者とプロバイダーとを引き合わせます。利用者は、ブローカーがリソースを管理していないことを認識しません。 マルチテナンシー: マルチテナンシーとは、同じ物理ハードウェア上で複数の企業の複数のシステム、アプリケーション、またはデータをホストする機能です。マルチテナンシーはクラウド・ベースのほとんどのシステムに共通する特性です。 クラウド・バースティング: クラウド・バースティングは、ハイブリッド・クラウドにおいて、必要に応じてプライベート・クラウドに対し追加リソースを提供する手法です。プライベート・クラウドにワークロードを処理する処理能力がある場合には、ハイブリッド・クラウドは使用されません。ワークロードがプライベート・クラウドの容量を上回ると、ハイブリッド・クラウドは自動的に追加リソースをプライベート・クラウドに割り当てます。 ポリシー: ポリシーとは運用手順に関わる一般用語です。たとえば、セキュリティー・ポリシーでは、ある特定のクラウド・サービスへのすべてのリクエストは暗号化されている必要があるといった内容が定められている場合があります。 ガバナンス: ガバナンスとは、ポリシーを確実に実施されるための制御およびプロセスを指します。 仮想マシン (VM): 稼動時に、ユーザーからは本物のマシンのように見えるファイルです (一般的に、イメージと呼ばれます)。IaaS では、多くの場合、仮想マシン・イメージを提供しており、必要に応じて起動または停止をすることができます。仮想マシンの動作中に仮想マシンに対して加えられた変更は、持続性を持たせるためにディスクに保存できます。 アプリケーション・プログラミング・インターフェース (API): アプリケーション・プログラミング・インターフェースは、ある種類のシステムとやり取りするためのコードの作成方法を開発者に伝える規約です。API では、システムがサポートするオペレーションの構文規則が規定されています。API では、システムに送信する情報、システムが送り返す情報、起こりうるすべてのエラー状態がオペレーションごとに指定されています。

2 July 2010 10

Cloud Computing Use Cases White Paper Version 4.0

API は、特定のプログラミング言語として、または WSDL や IDL といったより中立なフォーマットで定義されます。REST 仕様では一般的にはマシン・リーダブルな言語は含まず、API が定義されています。

API には、プロトコル (HTTP など) およびデータ形式 (JSON や XML スキーマなど) の詳細も含めることができます。

API では、データおよびオペレーションの意味を理解するために人間のインテリジェンスが必要となります。マシンはメソッド x では、パラメーターとして 2 つの整数が必要なことを検知できますが、人間である開発者は、無限にある整数のうちどの 2 つを使用すべきかを判断する必要があります。

2.2 分類 下の図は、クラウド・コンピューティングの分類を表しています。 この図では、サービス利用者がクラウドを介して提供されるサービスを利用し、サービス・プロバイダーがクラウド・インフラストラクチャーを管理し、サービス開発者がサービス自体を作成しています (これらの役割の間のやり取りのためには、オープン・スタンダードが必要です)。それぞれの役割については、以降のセクションでより詳しく取り上げます。

2 July 2010 11

Cloud Computing Use Cases White Paper Version 4.0

2.2.1 サービス利用者 サービス利用者とは、サービスが SaaS、PaaS、または IaaS のいずれかにかかわらずサービスを実際に使用するエンド・ユーザーまたは企業です。 利用者は、サービスのタイプと自分の役割によって、異なるユーザー・インターフェースおよびプログラミング・インターフェースを使用します。表示が他のアプリケーションと同じようなユーザー・インターフェースもあり、この場合、利用者は、アプリケーショを使用するにあたってクラウド・コンピューティングについて知る必要はありません。また、仮想マシンの起動や停止、クラウド・ストレージの管理などの管理機能を提供するユーザー・インターフェースもあります。アプリケーション・コードを作成する利用者は、作成するアプリケーションによって異なるプログラミング・インターフェースを使用します。 利用者は SLA および契約も使用します。一般的に、SLA および契約については、人が介入して利用者とプロバイダー間で交渉されます。この交渉においては、利用者の期待とプロバイダーの評判が重要な部分となってきます。 2.2.2 サービス・プロバイダー

2 July 2010 12

Cloud Computing Use Cases White Paper Version 4.0

サービス・プロバイダーは利用者にサービスを提供します。プロバイダーの実際の作業は、以下のようにサービスのタイプによって多岐にわたります。

SaaS を提供する場合、プロバイダーはソフトウェアのインストール、管理、および保守を行います。必ずしもプロバイダーがソフトウェアを実行する物理インフラを所有しているとは限りません。いずれにせよ、利用者がインフラにアクセスすることはできません。利用者は、アプリケーションにのみアクセスできます。

PaaS を提供する場合、プロバイダーは、プラットフォーム用のクラウド・インフラストラクチャー、一般的には特定のタイプのアプリケーション用のフレームワークを管理します。プラットフォームの下のインフラに利用者のアプリケーションがアクセスすることはできません。

IaaS を提供する場合、プロバイダーはストレージ、データベース、メッセージ・キューまたはその他のミドルウェア、もしくは仮想マシン向けのホスティング環境の保守を行います。利用者は、ディスク・ドライブ、データベース、メッセージ・キュー、またはマシンであるかのようにサービスを使用しますが、サービスのホストとなるインフラにアクセスすることはできません。

サービス・プロバイダーの図において、スタックの 下層は、他のすべての土台となるファームウェアおよびハードウェアになります。その上にはソフトウェア・カーネルがあります。ソフトウェア・カーネルは、クラウドの下にあるインフラのホストとして機能するオペレーティング・システムまたは仮想マシン（VM）管理機能になります。仮想化リソースおよびイメージには、処理能力、ストレージ、ミドルウェアといった基本的なクラウド・コンピューティング・サービスが含まれます。仮想マシン管理機能によって制御される仮想イメージには、イメージ自体とイメージの管理に必要なメタデータの両方が含まれます。 サービス・プロバイダーの業務にとって非常に重要なのは管理層です。下位レベルの管理では、サービスを誰がどの程度使用しているかを決定するメータリング、リソースをどのように利用者に割り振るかを決定するプロビジョニング、システムおよびそのリソースの状態を監視するモニタリングが必要です。 より上位レベルの管理では、コストを回収するための請求、利用者の要求を満たすためのキャパシティー・プランニング、プロバイダーおよび利用者が合意したサービス条件を順守するための SLA 管理、および管理者へのレポーティングが必要となります。 セキュリティーは、サービス・プロバイダーのオペレーションのあらゆる面に適用されます (セキュリティー要件には多くのレベルがありますが、このホワイト・ペーパーでは取り上げません)。プロバイダーのオペレーションにはオープン・スタンダードも適用されます。包括的なスタンダードのセットにより、プロバイダー内のオペレーションおよび他のプロバイダーとの相互運用性を容易にすることができます。

2 July 2010 13

Cloud Computing Use Cases White Paper Version 4.0

2.2.3 サービス開発者 サービス開発者は、クラウド・サービスを作成、公開、および監視します。これらは一般的に SaaS モデルを使用してエンド・ユーザーに直接提供される「業務別」アプリケーションです。IaaS および PaaS レベルで作成されたアプリケーションは、作成後、SaaS 開発者およびクラウド・プロバイダーによって使用されます。 サービスを作成するための開発環境はさまざまです。SaaS アプリケーションを作成する場合、開発者はおそらくある１つのクラウド・プロバイダーがホストとなる環境用のコードを作成します。この場合、クラウド・プロバイダーのインフラへのデプロイメントがサービスの公開となります。 サービス作成時には、分析において、利用者にサービスを公開する前にリモート・デバッグによるサービスの検証を行います。サービス公開後は、分析により、サービスのパフォーマンスを監視し、必要に応じて変更を加えることができます。 2.3 標準と分類との関係 クラウドのユース・ケース・シナリオには、4 つの異なる形で標準が影響してきます。それぞれのタイプのクラウド・サービス内、異なるタイプのクラウド・サービス間、企業とクラウド間、および企業におけるプライベート・クラウド内で、それぞれ標準が影響をしてきます。

2 July 2010 14

Cloud Computing Use Cases White Paper Version 4.0

2.3.1 各種クラウド・サービス間の標準 クラウド・コンピューティングが一般化するにつれ、アプリケーションで異なるタイプのクラウド・サービスが使用される可能性が高くなります。あるアプリケーションでは、クラウド・ストレージ・サービスやクラウド・メッセージ・キューを使用し、クラウドで実行される仮想マシンを管理 (起動/停止/監視) する可能性があります。これらの異なるサービスがどのように連携するかを定義する標準があれば有意義です。 2.3.2 各クラウド・サービス・タイプ内の標準 それぞれのタイプのクラウド・サービス (IaaS、PaaS、または SaaS) 内では、オープン・スタンダードによりベンダーによる囲い込みを避けることができます。 IaaS の場合、クラウド・データベースを使用するための API の標準セットにより、アプリケーションで複数のベンダーのデータを使用できるようになります。この共通 API により、ユーザーは大きな変更なしに別のクラウド・データベース・プロバイダーに自由に移行でき、また新しいデータ・ソースの既存アプリケーションとの統合をはるかに容易に行うことができるようになります。ストレージ、メッセージ・キュー、MapReduce などのその他のクラウド・インフラストラクチャー・サービスの共通 API も、データおよびデータ交換の共通フォーマットを提供するため、同様の利点を提供します。仮想マシンの場合、共通の仮想マシン・フォーマットが非常に重要です。ユーザーは、あるクラウド・プロバイダーで構築およびデプロイされた仮想マシンを、変更せずに別のクラウド・プロバイダーにデプロイできる必要があります。 PaaS の場合、クラウドで提供されているプラットフォームの多くはアプリケーション・フレームワークです。アプリケーション・フレームワークは、通常、ユーザー・インターフェース、ストレージ、データベースなどの一般的なサービスを提供しますが、フレームワークの API を使用しないとこれらのサービスを利用することはできません。 SaaS の場合、アプリケーション・レベルでオープン・スタンダードが適用されます。ここでの標準化作業でクラウド固有のものはほとんどないので、これらの標準についてはこのホワイト・ペーパーでは取り上げません。たとえば、クラウド・ベースのワード・プロセッサー・アプリケーションは、文書の可搬性を実現するための標準を順守する必要がありますが、ワード・プロセッサー・アプリケーションが標準を順守する必要があるかどうかは、そのアプリケーションがクラウドで実行されているかどうかとは何の関係もありません。 2.3.3 クラウドと企業間の標準 クラウド・コンピューティングが出現しても、Java EE などのエンタープライズ・アーキテクチャーがなくなることはありません。企業アプリケーションがクラウド・データベースやクラウド・メッセージ・キューなどのリソースと通信を行う方法を定める標準があれば、これらのアプリケーションは非常に少ない変更またはまったく変更なしにクラウド・サービスを使用できるようになります。このように既存のアーキテクチャーおよび開発の枠組みとクラウド・コンピューティングとをどのように統合していくかを考え出すことは、このグループにおける主なチャレンジになります。

2 July 2010 15

Cloud Computing Use Cases White Paper Version 4.0

2.3.4 企業内の標準 企業内の標準は相互運用性、監査能力、セキュリティー、管理などの要件によって決定され、企業とクラウド間に適用される標準を基に作成されます。企業は、プライベート、パブリック、およびハイブリッド・クラウドの組み合わせとやり取りを行います。 2.4 アプリケーション・プログラミング・インターフェース (API) クラウド・コンピューティング・ソリューションを構築するための主な仕組みは、クラウド・プロバイダーによって提供される API です。クラウド API は 4 つの異なるレベルで動作し、5 つの基本カテゴリーに分類されます。 2.4.1 API のレベル API には 4 つの異なるレベルがあります。開発者は、レベルごとに異なる作業およびデータ構造に焦点を置く必要があります。 レベル 1 – 通信: このレベルでは、開発者が直接リクエストの通信フォーマットを記述します。サービスが REST ベースで提供される場合、開発者は適切なHTTP ヘッダーを作成し、リクエストのペイロードを作成、サービスに対する HTTP コネクションをオープンします。REST サービスは付随する HTTP レスポンス・コードとともにデータを返します。多くの REST サービスは複雑でないため、このレベルでは比較的効率的なコードを作成できます。 サービスが SOAP ベースの場合、開発者は SOAP エンベロープを作成し、適切なSOAP ヘッダーを追加し、SOAP エンベロープのボディにペイロード・データを入れます。SOAP サービスは、リクエストの結果を含んだ SOAP エンベロープで応答します。SOAP サービスを使用するには、エンベロープの XML コンテンツを構文解析する必要があります。このため、ほとんどの SOAP サービスはより高いレベルの API で呼び出されます。 レベル 2 – 言語固有のツールキット: このレベルの開発者は、言語固有のツールキットを使用して SOAP または REST リクエストを処理します。このレベルでも、開発者は通信されるデータのフォーマットや構造を意識する必要がありますが、詳細部分の多く (たとえば応答コードの処理や署名の計算など) はツールキットによって処理されます。 レベル 3 – サービス固有のツールキット: 開発者はより高いレベルのツールキットを使用して、特定のサービスを処理します。このレベルでの作業では、開発者はビジネス・オブジェクトやビジネス・プロセスにフォーカスすることができます。通信プロトコルにフォーカスする代わりに、組織にとって重要なデータやプロセスにフォーカスすることで、開発者は生産性を大幅に向上させることができます。 レベル 4 – サービスに中立なツールキット: これは 上位レベルの API になります。このレベルで作業を行う開発者は、複数のクラウド・コンピューティング・プロバイダーにおいて共通のインターフェースを使用します。また、レベル 3 と同様に、開発者はビジネス・オブジェクトおよびビジネス・プロセスにフォーカスします。レ

2 July 2010 16

Cloud Computing Use Cases White Paper Version 4.0

ベル 3 とは異なり、レベル 4 で作業を行う開発者は、どのクラウド・サービスを使用しているかを意識する必要がありません。サービスに中立なツールキットで作成されたアプリケーションは、もし何らかの変更が必要な場合でもコードの変更を 小限に抑えて、別のクラウド・ベンダーでも使用することができます (28 ページの「クラウド・ベンダーの変更」を参照してください)。 2.4.2 API のカテゴリー プログラミング・インターフェースは、以下の 5 つのカテゴリーに分類できます。 カテゴリー 1 – 通常のプログラミング: C#、PHP、Java などにおける通常のアプリケーション・プログラミング・インターフェースです。このカテゴリーではクラウド固有の内容はありません。 カテゴリー 2 – デプロイメント: クラウドにアプリケーションをデプロイするためのプログラミング・インターフェースです。このカテゴリーには、クラウド固有のパッケージ化技術に加えて、.Net アセンブリや EAR/WAR ファイルなどの従来のパッケージ化メカニズムも含まれます。 カテゴリー 3 – クラウド・サービス: クラウド・サービスを使用するプログラミング・インターフェース。前セクションでの説明のとおり、クラウド・サービス API にはサービス固有のものとサービスに中立なものとがあります。これらの API は、クラウド・ストレージ・サービス、クラウド・データベース、クラウド・メッセージ・キュー、およびその他のクラウド・サービスといったサブカテゴリーに分類できます。クラウド・サービス API を使用してコードを作成する開発者は、クラウドを使用していることを認識しています。 カテゴリー 4 – イメージとインフラの管理: 仮想マシン・イメージおよびインフラの詳細を制御するためのプログラミング・インターフェースです。イメージ用の API では、イメージのアップロード、デプロイメント、起動、停止、再起動、および削除がサポートされています。インフラ管理用 API では、ファイアウォール、ノード管理、ネットワーク管理、ロード・バランシングなどの詳細を制御します。 カテゴリー 5 – 内部インターフェース: クラウド・インフラストラクチャーの異なるパーツ間での内部インターフェース用のプログラミング・インターフェースです。たとえば、クラウド・アーキテクチャー内のストレージ層のベンダーを変更する場合に使用するような API になります。 2.4.3 開発者の役割 開発者の要件について話をするめるにあたり、開発者が担う複数の役割について整理しておく必要があります。API およびクラウド・サービスの要件は、役割ごとに異なってきます。以下、この文書で取り上げる役割を、その役割で使用される API のカテゴリーとともに示します。

2 July 2010 17

Cloud Computing Use Cases White Paper Version 4.0

クライアント・アプリケーション開発者: エンド・ユーザー用クラウド・ベースのクライアント・アプリケーションを作成します。この開発者は、クラウド・サービス用の API (カテゴリー 3) を使用します。 アプリケーション開発者: クラウドを使用する従来型のアプリケーションを作成します。この開発者は、通常の API (カテゴリー 1) およびクラウド・サービス用の API (カテゴリー 3) を使用します。 デプロイヤー: クラウドを使用するアプリケーションのパッケージ化、デプロイメント、および保守を行います。ここではライフサイクル管理も考慮されます。この開発者は、デプロイメント、クラウド・サービス、およびイメージ管理用の API (カテゴリー 2、3、および 4) を使用します。 アドミニストレーター: デプロイメントおよびインフラ管理を含む複数のレベルでアプリケーションに関わります。この開発者は、カテゴリー 2、3、および 4 の API を使用します。 クラウド・プロバイダー: クラウドで提供されるサービスを支えるインフラに関わります。この開発者は、カテゴリー 5 の API を使用します。

2 July 2010 18

Cloud Computing Use Cases White Paper Version 4.0

3 ユース・ケース・シナリオ この企業のクラウド使用シナリオは、 も一般的なクラウドのユース・ケースを説明したものです。クラウド環境内で実現されるケースの網羅的なリストを意図したものではありません。 このセクションの各図には、共通の要素があります。特定のユース・ケースに当てはまらない要素は、色をグレイで目立たなくするか、点線で表記します。たとえば、プライベート・クラウドのユース・ケースにはエンド・ユーザーやパブリック・クラウドは関係しないので、企業だけをカラーで表示します。

エンド・ユーザーとクラウド

アプリケーションはクラウド上で実行され、エンド・ユーザーによってアクセスされます。

企業とクラウドとエンド・ユーザー

アプリケーションはパブリック・クラウド上で実行され、企業の従業員およびお客様によってアクセスされます。

企業とクラウドクラウド・アプリケーションは企業内部の IT 機能と統合されています。

2 July 2010 19

Cloud Computing Use Cases White Paper Version 4.0

企業とクラウドと企業

クラウド・アプリケーションはパブリック・クラウド上で実行され、パートナーのアプリケーション(サプライ・チェーン) と相互運用されます。

プライベート・ クラウド

ある組織が、その組織のファイアウォール内でホスティングするクラウド。

クラウド・ ベンダーの変更

クラウド・サービスを使用するある組織が、クラウド・プロバイダーを切り替える、またはプロバイダーを追加する決定をします。

ハイブリッド・ クラウド

複数のクラウドが連携して処理を行います。クラウド・ブローカーが、データ、アプリケーション、ユーザー ID 情報、セキュリティーなどの詳細をフェデレーションして調整します

3.1 エンド・ユーザーとクラウド このシナリオでは、エンド・ユーザーがクラウド内のデータやアプリケーションにアクセスします。このタイプの一般的なアプリケーションとしては、電子メールのホスティングやソーシャル・ネットワーキング・サイトなどがあります。Gmail、Facebook、または LinkedIn のユーザーは、任意のデバイスの任意のブラウザーを通してアプリケーションおよびデータにアクセスします。ユーザーはパスワード以上のシステム情報には関心を持っておらず、ユーザーのデータはクラウドで保存および管理されます。

2 July 2010 20

Cloud Computing Use Cases White Paper Version 4.0

重要なことは、ユーザーは基本的なアーキテクチャーの仕組みをまったく知らないということです。ユーザーはインターネットさえ利用できれば、データを利用できます。 3.1.1 要件

ID 情報: クラウド・サービスは、エンド・ユーザーを認証しなければなりません。

オープン・クライアント: クラウド・サービスへのアクセスのために、特定のプラットフォームやテクノロジーが必要になることは避けなければなりません。

セキュリティー: セキュリティー (プライバシーを含む) はすべてのユース・ケースに共通の要件ですが、セキュリティー要件の詳細の内容はユース・ケースによって多岐にわたります。クラウド・コンピューティングのセキュリティーに関する詳しい議論は、このホワイト・ペーパーでは行いません。

SLA: エンド・ユーザー向けのサービス・レベル・アグリーメントは、一般的に、企業向けのものよりはるかにシンプルですが、クラウド・ベンダーは提供するサービスが保証する内容を明確にする必要があります

3.2 企業とクラウドとエンド・ユーザー このシナリオでは、企業がクラウドを利用して、エンド・ユーザーにデータおよびサービスを提供します。エンド・ユーザーが企業とやり取りを行うとき、企業はクラウド

2 July 2010 21

Cloud Computing Use Cases White Paper Version 4.0

にアクセスしてデータの検索や処理を行い、その結果をエンド・ユーザーに送ります。エンド・ユーザーは企業内にいる場合も外部のお客様である場合もあります。 3.2.1 要件

ID 情報: クラウド・サービスはエンド・ユーザーを認証する必要があります。

オープン・クライアント: 特定のプラットフォームや技術がなければクラウド・サービスにアクセスできないという状況は避けるようにします。

ID 情報のフェデレーション: エンド・ユーザーにとって必要な基本的な ID 情報以外に、企業ユーザーは高い可能性で企業との関係における ID 情報を持っています。クラウド・サービスで必要になる他の ID 情報と連携させ、企業ユーザーが 1 つの ID だけを管理するという状態が理想です。

ロケーションの認識: ユーザーに代わって企業が管理するデータの種類によっては、データを保存する物理サーバーの場所に関する法規制が存在する場合があります。ユーザーが物理インフラの詳細を知る必要がないというクラウド・コンピューティングの理想には反しますが、この要件は非常に重要です。クラウド・ベンダーがクラウド・サービスを提供する物理ハードウェアの場所を特定するための API を提供するまではクラウドに移行できないアプリケーションも多くあります。

2 July 2010 22

Cloud Computing Use Cases White Paper Version 4.0

メータリングとモニタリング: すべてのクラウド・サービスは、コスト管理、チャージバック、およびプロビジョニングを目的とし、メータリングとモニタリングが行われる必要があります。

管理とガバナンス: パブリック・クラウド・プロバイダーのアカウントを開設し、クラウド・サービスの使用を開始するのは非常に簡単です。この使い勝手のよさにより、企業内の個人が勝手にクラウド・サービスを使用するリスクが生じます。仮想マシンならびにストレージ、データベース、メッセージ・キューなどのクラウド・サービスの管理において、どのサービスが使用されているか追跡する必要があります。 ガバナンスは、そこがどこであれクラウド・コンピューティングを使用する場所の政策および政府規制を確実に遵守するために非常に重要です。ガバナンスに関するその他の要件は業界や地域によります。

セキュリティー: 企業が関係するすべてのユース・ケースには、1 人のエンド・ユーザーが関係するユース・ケースよりも高度なセキュリティー要件が存在します。同様に、企業のユース・ケースが高度になればなるほど、セキュリティー要件も同じように高度になります。

仮想マシンの共通ファイル・フォーマット: あるクラウド・ベンダーのプラットフォーム用に作成された仮想マシンを他のベンダーのプラットフォームにも移植できるようにする必要があります。この要件への対応では、各クラウド・ベンダーが仮想マシンにストレージを接続する方法の違いを必ず考慮する必要があります。

クラウド・ストレージおよびミドルウェアの共通 API: 企業のユース・ケースでは、クラウド・ストレージ・サービス、クラウド・データベース、メッセージ・キューなどのその他のクラウド・ミドルウェア・サービスにアクセスするための共通の API が必要です。 特定のベンダーのクラウド・サービスでのみ機能するカスタム・コードを作成すると、そのコードを使用する企業がそのベンダーのシステムに囲い込まれ、クラウド・コンピューティングが提供する経済的利益および柔軟性の一部が失われます。

データとアプリケーションのフェデレーション: エンタープライズ・アプリケーションでは、複数のクラウド・ベースのデータをまとめ、異なるクラウドで実行されるアプリケーションの稼働を調整する必要があります。

SLA およびベンチマーク: SLA に基づく契約を締結する企業では、エンド・ユーザーが求める基本 SLA 以外に、性能のベンチマーク評価を行う標準的な方法が必要です。また、クラウド・プロバイダーが提供する内容を定義する明確な方法と実際に提供されたものを測る明確な方法が必要です (SLA にはクラウドのセキュリティーについて追加の要件があります。詳細については、セクション 6 の SLA、監査、およびモニタリングに関する説明を参照してください)。

ライフサイクル管理: 企業は、アプリケーションおよび文書のライフサイクルを管理できなければなりません。この要件には、アプリケーションのバー

2 July 2010 23

Cloud Computing Use Cases White Paper Version 4.0

ジョン管理やデータの保存と破棄が含まれます。多くの組織にとって、データ管理は大きな問題です。入手できなくなったデータによっては、重大な法的責任が生じます。データの保存に加え、ある時点でデータが破棄されたことを確認する必要がある場合もあります。

3.3 企業とクラウド このユース・ケースでは、企業が内部のプロセスにクラウド・サービスを使用します。企業が制御する割合が も大きいため、クラウド・コンピューティングの初期段階では も一般的なユース・ケースと言えるかもしれません。 このシナリオでは、企業がクラウド・サービスを利用して必要なリソースを以下のように補完します。

ほとんど使用されないデータのバックアップまたは保存にクラウド・ストレージを使用する

クラウド内の仮想マシンを使用して、ピーク時の負荷を処理するための追加プロセッサーを活性化する (不要になった時点でこれらの仮想マシンを停止する)

企業で使用される特定の機能 (E メール、カレンダー、CRM など) にクラウド内のアプリケーション (SaaS) を使用する。

2 July 2010 24

Cloud Computing Use Cases White Paper Version 4.0

アプリケーション処理の一部としてクラウド・データベースを使用する。この運用は、パートナー、政府機関などとデータベースを共有する場合に非常に役立つ場合があります。

3.3.1 要件 企業とクラウドのユース・ケースの基本要件は、企業とクラウドとエンド・ユーザーのユース・ケースとほとんど同じです。オープン・クライアント、ID 情報のフェデレーション、ロケーションの認識、メータリングおよびモニタリング、管理とガバナンス、セキュリティー、仮想マシンの共通ファイル・フォーマット、クラウド・ストレージおよびミドルウェアの共通 API、データおよびアプリケーションのフェデレーション、SLA、およびライフサイクル管理がすべて適用されます。 このユース・ケースのその他の要件を以下に示します。

デプロイメント: 仮想マシン・イメージを容易に作成でき、必要に応じてクラウドへ容易にデプロイメントできる必要があります。仮想マシン・イメージを作成する場合、各ベンダーが仮想マシンをストレージ上に配置する異なるメカニズムを補い、そのイメージが 1 つのクラウド・プロバイダーから他のプロバイダーへ移植できるようにすべきです。クラウドへのアプリケーションのデプロイメントも簡単でなければなりません。

業界固有の標準およびプロトコル: 企業間で使用されている多くのクラウド・コンピューティング・ソリューションでは、RosettaNet や OAGIS などの既存の標準が使用されます。適用される標準はアプリケーションおよび業界によって異なります。

3.4 企業とクラウドと企業 このユース・ケースでは、2 社の企業が同じクラウドを使用します。ここでの注目点は、各社のアプリケーションを相互運用するため、リソースがクラウドでホスティングされることです。このユース・ケースの も分かりやすい例は、サプライ・チェーンです。

2 July 2010 25

Cloud Computing Use Cases White Paper Version 4.0

3.4.1 要件 企業とクラウドと企業のユース・ケースの基本要件は、企業とクラウドのユース・ケースとほとんど同じです。ID 情報、オープン・クライアント、ID 情報のフェデレーション、ロケーションの認識、メータリングおよびモニタリング、管理とガバナンス、セキュリティー、業界固有の標準、ストレージおよびミドルウェアの共通 API、データおよびアプリケーションのフェデレーション、SLA、およびライフサイクル管理がすべて適用されます。 このユース・ケースのその他の要件を以下に示します。

トランザクションと並行性: 複数の企業が共有するアプリケーションおよびデータにとって、トランザクションおよび並行性は極めて重要です。2 社の企業がクラウドでホスティングされる同一のアプリケーション、仮想マシン、ミドルウェア、またはストレージを使用する場合、いずれの企業による変更も、すべて確実に行われることが重要です。

2 July 2010 26

Cloud Computing Use Cases White Paper Version 4.0

相互運用性: 複数の企業が関係するので、企業間の相互運用性は必要不可欠です。

3.5 プライベート・クラウド プライベート・クラウドのユース・ケースは、クラウドが企業の内部 にあるという点で他とは異なります。プライベート・クラウドは、比較的大きな企業にとって便利です。たとえば、給与計算部門のワークロードが毎月 15 日と 30 日に急増する場合は、15 日と 30 日以外の毎日のワークロードがこの 2 日よりもはるかに少なくても、

大のワークロードを処理するために十分なコンピューティング性能が必要となります。プライベート・クラウドを使用すると、コンピューティング性能が全社に分散され、給与計算部門も他の部門も必要なときに追加サイクルを利用できます。これにより、企業全体として大きな節約ができます。 3.5.1 要件 プライベート・クラウドのユース・ケースの基本要件は、オープン・クライアント、メータリングおよびモニタリング、管理とガバナンス、セキュリティー、デプロイメント、相互運用性、共通の仮想マシン・フォーマット、および SLA です。

2 July 2010 27

Cloud Computing Use Cases White Paper Version 4.0

プライベート・クラウドでは、ID 情報、ID 情報のフェデレーション、ロケーションの認識、トランザクション、業界標準、クラウド・ミドルウェアの共通 API、およびライフサイクル管理は必要ありません。多くの場合、利用者は、ロケーションの認識が問題とならないようにプライベート・クラウドを使用する必要があります。クラウドを企業内部にとどめておくと、ID 情報管理、標準、および共通の API に対する要件の多くが不要になります。 3.6 クラウド・ベンダーの変更 このユース・ケースでは、ベンダーを追加するか、既存のベンダーに替えて別のクラウド・ベンダーを利用します。このユース・ケースは、このホワイト・ペーパーで取り上げる他のすべてのユース・ケースに適用されます。大きな変更を伴わずに、他のクラウド・ベンダーの利用を開始できることは、オープン性および標準化による大きな利点の 1 つです。 ここでは、要件が少し異なる 4 つのシナリオを紹介します。クラウド・ベンダーを変更するためには、一般的に、オープン・クライアント、ロケーションの認識、セキュリティー、SLA、仮想マシンの共通ファイル・フォーマット、クラウド・ストレージおよびミドルウェアの共通 API が必要となります。これらの要件の詳細については、以下の各サブセクションで説明します。

2 July 2010 28

Cloud Computing Use Cases White Paper Version 4.0

3.6.1 シナリオ 1: SaaS ベンダーの変更 このシナリオでは、クラウドを使用するお客様が SaaS ベンダーを変更します。変更前と変更後の SaaS ベンダーは、同じアプリケーション (CRM、会計処理、ワード・プロセッサーなど) を提供します。あるベンダーのソフトウェアで作成した文書およびデータを別のベンダーのソフトウェアでインポートできる必要があります。お客様が 2 つのベンダーを交互に使用することが必要な場合もあります。 3.6.1.1 要件

業界固有の標準: ベンダーのアプリケーション間で文書やデータを移動するには、両方のアプリケーションが共通のフォーマットをサポートしている必要があります。必要なフォーマットは、アプリケーションのタイプにより異なります。

異なるタイプのアプリケーション間で、標準 API が必要な場合もあります。

これらの要件はクラウド固有の内容ではありません。Zoho から Google Docs に文書を移動するための標準と、Microsoft Office から OpenOffice に文書を移動するための標準は同じです。 3.6.2 シナリオ 2: ミドルウェア・ベンダーの変更 このシナリオでは、クラウドを使用するお客様がクラウド・ミドルウェア・ベンダーを変更します。既存のデータ、照会、メッセージ・キュー、およびアプリケーションをベンダーからエクスポートし、別のベンダーにインポートできることが必要です。7

3.6.2.1 要件

業界固有の標準: ベンダーのミドルウェア間で文書やデータを移動するには、両方のアプリケーションが共通のフォーマットをサポートしている必要があります。必要なフォーマットは、アプリケーションのタイプにより異なります。

クラウド・ミドルウェアの共通 API: これは、クラウド・データベース、クラウド・メッセージ・キュー、その他のミドルウェアをはじめとする現時点のクラウド・サービスがサポートするすべての業務が含まれます。データベースおよび表への接続、作成、削除を行うための API です。

クラウド・データベース・ベンダーは、製品の弾力性を高め、大量リソースが必要な大規模データ・セットへの照会を限定するため、一定の制約を実装しています。たとえば、表間の結合を禁止しているクラウド・データベースや、本当の意味でのデータベース・スキーマをサポートしていないクラウド・

7 クラウド・ストレージは人気があるので、クラウド・ミドルウェア (データベース、メッセージ・キュー、

Map Reduce) とクラウド・ストレージは、どちらも PaaS と分類されますが、別々のシナリオと考え

ています。

2 July 2010 29

Cloud Computing Use Cases White Paper Version 4.0

データベースなどがあります。このような制約は、特に本当の意味でリレーショナル・モデルに基づいて構築されるアプリケーションにとっては、クラウド・データベース・ベンダー間の移動に対する大きな課題となります。

メッセージ・キューなどのその他のミドルウェア・サービスはより類似しているので、これらの共通点はより簡単に見つけることができます。

3.6.3 シナリオ 3: クラウド・ストレージ・ベンダーの変更 このシナリオでは、クラウドを使用するお客様がクラウド・ストレージ・ベンダーを変更します。 3.6.3.1 要件

クラウド・ストレージの共通 API: あるクラウド・ストレージ・システムでデータを読み書きするコードは、できるだけ少ない変更で別のシステムでも使用できることが必要です。つまり、変更を加える場合は、構成コードだけを変更すればよいことになります。たとえば、JDBC アプリケーションでは、URL およびドライバー名のフォーマットはデータベース・ベンダーによって異なりますが、データベースとやり取りするためのコードはまったく同じです。

3.6.4 シナリオ 4: 仮想マシン・ホストの変更 このシナリオでは、クラウドを使用するお客様が、あるクラウド・ベンダーのシステムで構築した仮想マシンを取り出して別のクラウド・ベンダーのシステムで実行します。 3.6.4.1 要件

仮想マシンの共通フォーマット: 仮想マシンのフォーマットはどのオペレーティング・システムでも利用できることが必要です。

ここでは、仮想マシン自体が Windows や Linux などのオペレーティング・システムを実行していると想定します。これは、仮想マシンのユーザーがクラウド用の仮想マシンを構築する前にプラットフォームを選択しているため、仮想マシン内部で実行されるソフトウェアに対するクラウド固有の要件はないことを意味します。

3.7 ハイブリッド・クラウド このユース・ケースでは、パブリック・クラウドとプライベート・クラウドの両方を含む複数のクラウドが連携して処理を行います。ハイブリッド・クラウドを提供できるのは、自社のリソースを他のプロバイダーのリソースと組み合わせるフェデレーション・クラウド・プロバイダーです。また、ブローカーもハイブリッド・クラウドを提供できます。ブローカーは自社のクラウド・リソースをまったく持たないというところが違います。ハイブリッド・クラウドのプロバイダーは、利用者の条件を基にクラウド・リソースを管理する必要があります。

2 July 2010 30

Cloud Computing Use Cases White Paper Version 4.0

ハイブリッド・クラウドの利用者にとって、このユース・ケースは前述のエンド・ユーザーとクラウドのユース・ケースとまったく同じです。ユーザーは、ハイブリッド・クラウド・プロバイダーが実際に何を行っているかを知りません。 3.7.1 要件

これまでのユース・ケースのすべての要件 (トランザクションおよび並行性は除く) が適用されます。特にセキュリティー、データおよびアプリケーションのフェデレーション、相互運用性が重要です。

SLA: SLA を表現するための機械可読の標準フォーマットが必要です。ハイブリッド・クラウド・プロバイダーは、このフォーマットを使用することにより、人の介入なしで利用者の条件に従ってリソースを選択できます。

セクション 2.1.2 に記載されているとおり、コミュニティー・クラウドに対する要件は、ハイブリッド・クラウドに対する要件の一部です。コミュニティー・クラウドには、共通の目的を持つ企業間で共有されるインフラがあります。コミュニティー・クラウドの図を以下に示します。

2 July 2010 31

Cloud Computing Use Cases White Paper Version 4.0

コミュニティーとコミュニティー・クラウド間の通信は、イントラネット経由で行われます。イントラネットが VPN となる場合もありますが、アクセスがパブリック・インターネットを経由することはありません。 3.8 相互参照: 要件およびユース・ケース 要件とユース・ケース間の関係を下の表に要約します。

要件

エンド・ユー

ザーとクラウド

企業とクラウド

とエンド・

ユーザー

企業とクラウド

企業とクラウド

と企業

プライベート・

クラウド

クラウド・

ベンダーの変更

ハイブリッド・

クラウド

ID 情報

オープン・ クライアント

ID 情報のフェデレーション

ロケーションの認識

2 July 2010 32

Cloud Computing Use Cases White Paper Version 4.0

要件

エンド・ユー

ザーとクラウド

企業とクラウド

とエンド・

ユーザー

企業とクラウド

企業とクラウド

と企業

プライベート・

クラウド

クラウド・

ベンダーの変更

ハイブリッド・

クラウド

メータリングと モニタリング

管理と ガバナンス

セキュリティー

デプロイメント

トランザクションと並行性

相互運用性

業界固有の標準

仮想マシン・イメージ・フォーマット

クラウド・ ストレージ API

クラウド・データベース API

クラウド・ミドルウェア API

データとアプリケーションの フェデレーション

SLA

ライフサイクル管理

2 July 2010 33

Cloud Computing Use Cases White Paper Version 4.0

4 お客様のシナリオ このセクションでは、お客様のユース・ケース経験を説明します。お客様のシナリオは以下のように要約できます。

お客様のシナリオ 解決されるお客様の問題 要件と機能 該当する ユース・ケース

給与計算処理

処理時間の短縮 ハードウェア要件の低減 将来の拡張に向けた弾力

性の実現

IaaS (VM)、 クラウド・ ストレージ

企業とクラウド

ロジスティクスとプロジェクト・ マネジメント

処理時間の短縮 手作業の除去 開発環境の更新と合理化

PaaS (アプリケーション・ フレームワーク)、クラウド・ストレージ

企業とクラウドとエンド・ ユーザー

中央官庁 IT 専門知識の統合 ハードウェア要件の低減

IaaS、PaaS プライベート・クラウド

地方自治体 IT 専門知識の統合 ハードウェア要件の低減

IaaS、PaaS ハイブリッド・クラウド

天文データの処理

ハードウェア費用の大幅な削減 (処理能力とストレージ)

エネルギー費の大幅な 削減

管理の簡素化

IaaS(仮想マシン)、クラウド・ストレージ

企業とクラウドとエンド・ ユーザー

4.1 お客様のシナリオ: クラウドでの給与計算処理 4.1.1 該当するセクション 3 のユース・ケース・シナリオ 企業とクラウド

2 July 2010 34

Cloud Computing Use Cases White Paper Version 4.0

4.1.2 お客様のシナリオ このシナリオでは、2 台のサーバーを複雑で時間のかかる給与計算処理専用に使用していました。この組織で、クラウドでの給与計算処理がどれだけ実用的かを確かめることが決まりました。既存の給与計算システムは分散アプリケーションとして構築されていたため、クラウドへの移行は比較的容易でした。 この給与計算アプリケーションでは、従業員データの処理に SQL データベースが使用されていました。クラウド・データベース・サービスを利用するためにアプリケーションを書き換えるのではなく、データベース・サーバーを持つ仮想マシンをデプロイすることで対応しました。このデータベース・サーバーがクラウド・ストレージ・システムからデータを取り出し、取り出したデータから関係表を作成しました。元の (企業内) データベースが大きかったため、抽出ツールを使用して、給与計算処理に必要な情報だけが選択されました。抽出した情報はクラウド・ストレージ・サービスに転送され、データベース・サーバーによって利用されました。 給与計算アプリケーションは、同時に動作する 4 台の仮想マシンにデプロイされました。これらの仮想マシンは、データベース・サーバーのホストである仮想マシンと連携して処理を行います。給与計算アプリケーションの構成は、データベース・サーバーのホストである仮想マシンを使用するためにその構成変更されましたが、その他の点については、アプリケーションは変更されていません。 4.1.3 解決されるお客様の問題 クラウド・ベース・バージョンのアプリケーションでは、給与計算作業の処理時間を 80% 短縮できました。追加の利点として、以前は給与計算処理専用だった 2 台のサーバーを他の作業にも使用できるようになりました。 後に、クラウド・ベース・バージョンでは大幅に拡張性が増加しました。これは、組織が拡大するにつれて、大きな強みとなります。 4.1.4 要件と機能 使用されたクラウド・サービスは、仮想マシンおよびクラウド・ストレージ (IaaS) です。給与計算アプリケーションを変更する必要はなく、仮想マシンにデプロイするだけで済みました。元のアプリケーションではリレーショナル・データベースが使用されていました。データ構造とアプリケーションを、クラウド・データベースを使用するために変更しなくて済むように、リレーショナル・データベース・サーバーをクラウドにデプロイする方法を選択しました。 使用した API は S3 クラウド・ストレージ API だけです。 4.1.5 可搬性に関する懸念 この給与計算アプリケーションは Fedora および Java 1.5 で動作するので、Fedora をサポートするすべてのクラウド・プロバイダーのプラットフォームで変更を加えなくても動作します。別のクラウド・ストレージ・プロバイダーを使用するためにアプリケーションを変更する場合、特にそのベンダーが給与計算処理で使用されている固有の S3 API をサポートしていない場合は、問題が発生する可能性があります。 後

2 July 2010 35

Cloud Computing Use Cases White Paper Version 4.0

に、特にリレーショナル・モデルをサポートしていないクラウド・データベースへの移行が必要な場合、クラウド・データベースを使用するためのアプリケーションの変更は極めて難しい可能性があります。 4.2 お客様のシナリオ: クラウドでのロジスティクスとプロジェクト・

マネジメント 4.2.1 該当するセクション 3 のユース・ケース・シナリオ 企業とクラウドとエンド・ユーザー 4.2.2 お客様のシナリオ 約 20 人の事務員がいる小規模な建設会社があります。この会社は、リソースを管理し、プロジェクトのスケジュール管理を 適化し、仕事の諸費用を追跡する方法が必要でした。この会社には通常のシステムでは対応できない非常に特殊な要件があったため、Quickbook と表計算を組み合わせて使用していました。このシステムには弾力性がなく、大量の人材が無駄になっていました。 この問題の解決策は、カスタム・クライアント・アプリケーションを構築することでした。このアプリケーションでは、すべてのビジネス・ロジックがクライアントに常駐します。アプリケーションのデータは、Google App Engine (GAE) データ・ストアから処理されます。このデータ・ストアは RDF-OWL オントロジーのホストとして機能していますが、RDF グラフ以外のスキーマは強制されません。クライアントはこのオントロジーを使用して、ユーザーに表示したり GAE に送り返したりする前にデータを確認します。 データ処理は、アプリケーション固有の RESTful プロトコルを使用し、HTTP 経由でデータ・ストアと送受信されます。データ・ストアは、サーバーで管理される各単位で、サービスを提供するアプリケーションに固有の RDF グラフを維持管理します。セキュリティーは、特定のデータ単位を使用するアプリケーションの要件により、単位ごとに個別に実装されます。このシステムを使用すると、アプリケーションが数の制限なく、またそれぞれに新しいコード・ベースを構築しなくても、データ・ストアを使用できます。 データは、GAE データ・ストアにアップロードする前にデータを調整する一回限りのデータ移行スクリプトを使用して、ローカルでホスティングされている Quickbooks SQL サーバーおよびカスタム表計算シートから GAE 上のデータ・ストアに移動されました。データ・セットは小さく、ローカル・リソースを使用して簡単に処理できました。 クライアント・アプリケーションは、データの 近の変更のサブセットを含むローカル・データ・ストアを維持管理します。このアプリケーションの REST アーキテクチャーにより、HTTP の組み込みキャッシュのサポートを利用して、変更をマスター・データ・ストアからクライアントに自動的に伝搬できます。この設計により、データのサブセットを使用するというパフォーマンス上の利点が実現されるのに加え、セキュリティーがシンプルになります。クライアント・アプリケーションが特定

2 July 2010 36

Cloud Computing Use Cases White Paper Version 4.0

のフィールドまたはレコードにアクセスする必要がない場合、そのデータ・ストアがサーバーを出ることはありません。 4.2.3 解決されるお客様の問題 ソフトウェアおよび表計算シートのマクロで構成される非効率的なシステムからクラウド・ベースのシステムにデータを移動できました。この結果作成されたデータ・ストアは幅広いアプリケーションで使用できるので、今後の開発および保守が大幅に容易になります。 移行後も元のアプリケーションのインフラが使用されていますが、このインフラ上で構築されたアプリケーションでは、データの分析および処理で表計算シートに頼らなくても済むようになりました。表計算シートの維持管理が不要になったため、コストを大きく節約できます。さらに、処理の一環から手作業でのデータの切り取りがなくなり、面倒な作業を廃止するとともにエラーの原因を取り除くことができました。 4.2.4 要件と機能 クラウド・サービスでは、データベースのサポートを提供する PaaS 実装である Google App Engine を使用しました。RESTful API とクラウド・データ・ストアを組み合わせ、従来のリレーショナル・データベースを中心として構築されたアプリケーションに比べてアプリケーションの弾力性を高めることができました。 4.2.5 可搬性に関する懸念 このアプリケーションは、Google App Engine および Google App Engine の BigTable データベースで実行されます。BigTable は、正規化よりも非正規化を優先することによって弾力性を実現した、スパースで分散しかつパーシステントな多次元のソート済みマップです。これが大部分のデータ・ストアとの重要な違いで、アプリケーション開発を根本的に再考する必要があります。より従来型のデータ・ストア上で実行する目的でアプリケーションを移植する場合は、アプリケーションのアーキテクチャーを大幅に変更する必要があります。 4.3 お客様のシナリオ: クラウドでの中央官庁サービス 4.3.1 該当するセクション 3 のユース・ケース・シナリオ プライベート・クラウド 4.3.2 お客様のシナリオ 日本政府の各省庁が使用するインフラには何千台ものサーバーが含まれています。日本の中央官庁は、政府のアプリケーションをホスティングするセキュアな中央インフラストラクチャーを提供するための「霞が関」プライベート・クラウド環境を発表しました。 給与計算、会計、人事などを管理する既存の事務処理システムは仮想化され、プライベート・クラウドでホスティングされます。電子調達などの一部の窓口業務システム

2 July 2010 37

Cloud Computing Use Cases White Paper Version 4.0

はパブリック・クラウドに仮想化されますが、これはこのプロジェクトの範囲外です。プロジェクトの 終目的は、システムの無駄を省き、省庁ごとに管理者を置く必要をなくして、総所有コストを削減することです。 4.3.3 解決されるお客様の問題 霞が関クラウドによって、コスト削減、消費電力の削減、および IT 担当者の削減という 3 つの課題が解決されます。 4.3.4 要件と機能 このクラウド・インフラストラクチャーは、日本の通信会社が構築するプライベート・ネットワーク上に構築されます。プライバシーとセキュリティーが重視されるので、プライベート・クラウドが必要です。あらゆる個人データは、日本国外のサーバーに保存されることを法律で禁じられています。 4.3.5 可搬性に関する懸念 政府が独自のアプリケーションをホスティングする独自のプライベート・クラウドを構築するため、可搬性は問題になりません。政府には、集中化したアプリケーションとデータをプライベート・クラウドからパブリック・クラウドに移行する意思はありません。 4.4 お客様のシナリオ: ハイブリッド・クラウドでの地方自治体サービス 4.4.1 該当するセクション 3 のユース・ケース・シナリオ ハイブリッド・クラウド 4.4.2 お客様のシナリオ 日本全国には 1,800 を超える地方自治体があり、それぞれがサーバーを保有し、IT 担当者を抱えています。霞が関クラウドの 2 つ目の目標は、ハイブリッド・クラウド環境を提供することです。日本の中央官庁は、霞が関クラウドに加えて、地方自治体を県レベルでグループ化することを決定しています。各県がプライベート・クラウドを持ち、霞が関ハイブリッド・クラウドに接続します。内部作業および一部のデータは県のプライベート・クラウド内でホスティングされますが、他のデータはローカルに保存します。既存のシステムはできるだけ仮想化され、霞が関クラウドでホスティングされます。 4.4.3 解決されるお客様の問題 ハイブリッド・クラウドによって、コスト削減、消費電力の削減、および IT 担当者の削減という 3 つの問題が解決されます。

2 July 2010 38

Cloud Computing Use Cases White Paper Version 4.0

4.4.4 要件と機能 このシナリオでは、プライバシーとセキュリティーが非常に重要です。日本の法律では一部のタイプのデータは地方自治体のサーバーの外部に保存できないので、アプリケーションとデータを霞が関クラウドに移行するという選択肢はありません。一部の処理は地方自治体のインフラ上で行われるため、ハイブリッド・クラウド内でのアプリケーションとデータのフェデレーションが非常に重要になります。 4.4.5 可搬性に関する懸念 前述のお客様のシナリオと同じく、政府が独自のプライベート・クラウドを構築するので、可搬性は問題になりません。政府には、集中化したアプリケーションとデータをプライベート・クラウドからパブリック・クラウドに移行する意思はありません。 4.5 お客様のシナリオ: 天文データの処理 4.5.1 該当するセクション 3 のユース・ケース・シナリオ エンド・ユーザーとクラウド 4.5.2 お客様のシナリオ Gaia8 は、銀河系の 10 億個の恒星を調査する欧州宇宙機関 (ESA) の宇宙探査計画です。この計画では、対象となる各恒星を 5 年間で約 70 回観測し、それらの位置、距離、動き、および光度の変化を正確に図示します。太陽系外惑星や褐色矮星と呼ばれる恒星になれなかった天体など、数十万個の新しい天体を発見することが期待されています。 この探査では、分析が必要な大量のデータを収集します。ESA は、このデータを分析するクラウド・ベースのシステムの試作品を構築することを決定しました。目的は、クラウド・コンピューティングを使用した大量のデータ・セットの処理の技術的側面と経済的側面を判断することです。 試作システムには、科学データおよび計算ジョブの公開に使用するホワイトボードが含まれています。ジョブの実行およびデータ処理には、分散コンピューティングのフレームワーク (内部で開発) を使用します。このフレームワークは、AGIS (Astrometric Global Iterative Solution) を実行できるように構成されています。この処理では、データが収束するまで、何度も処理を行います。 各作業ノードは、処理を行うためにデータベースからジョブ記述を取得し、データを取り出して処理し、結果を中間サーバーに送信します。中間サーバーは、次の反復処理を行うためにデータを更新します。 試作システムでは、200 万個の恒星の 5 年分のデータを評価しました。これは、実

8 このプロジェクトの概要については、http://www.esa.int/esaSC/120377_index_0_m.html を参照して

ください。

2 July 2010 39

Cloud Computing Use Cases White Paper Version 4.0

際のプロジェクトで処理する必要があるデータ全体のごく一部です。試作システムはそれぞれ 100 分の処理を 24 回反復しました。これは、20 台の仮想マシンで構成されるグリッドを 40 時間実行するのに相当します。10 億個の恒星を対象とするこのプロジェクト全体では、1 億個の主星を 6 年分のデータで分析する予定です。このためには、20 台の仮想マシンのクラスターを 16,200 時間動作させる必要があります。 試作システムでは、クラウド・ベースのソリューションの弾力性を評価するため、120 台の高速 CPU を搭載する超大型仮想マシンを使用して 2 回目のテストを実行しました。仮想マシンごとに 12 のスレッドを実行し、1,440 の処理を並列して実行しました。 4.5.3 解決されるお客様の問題 このクラウド・ベースのソリューションの推定費用は、内製型のソリューションの半分以下です。この費用推定額には内製型のソリューションで追加される電気代やシステム管理費用は含まれていないので、実際にはさらに大きな金額を節約できます。データ・セットの保存もクラウド・ベースで行われます。 2 回目のテストでは、データベースの SQL 照会やロックの競合に関するパフォーマンス上の問題をいくつか検出し、解決しました。現行の内製システムでは、これらの問題を検出できなかった可能性もあります。この試作システムにより、実稼働に移行する前にパフォーマンス上の問題と弾力性の問題を発見し、解決することができました。 4.5.4 要件と機能 この試作システムでは、AGIS ソフトウェアとデータベースに仮想マシンを使用しました。データベースは、仮想マシン内部で運用される従来のデータベースです。完全なリレーショナル・データベースで、クラウド・データベース・サービスではありません。ストレージについては、クラウド・ベースのストレージ・ボリューム (各自 100GB) 5 つをデータベース・サーバーに接続しました。 4.5.5 可搬性に関する懸念 すべての仮想マシンは標準オペレーティング・システムを実行し、プロジェクトで使用するソフトウェアにクラウド固有のものはありません。このアプリケーションの可搬性については、これらの仮想マシン・イメージを、イメージの再構築や再構成をせずに別のプロバイダーに移行できるかどうかが問題です。

2 July 2010 40

Cloud Computing Use Cases White Paper Version 4.0

5 開発者の要件 開発者の要件は、すべてのユース・ケースとお客様のシナリオに影響を及ぼします。本章以降の議論を簡単にするため、すべての開発者の要件を以下に示します。

キャッシュ: クラウド・リソースのキャッシュをサポートするプログラミング・ツールキットが、クラウド・アプリケーションの性能を向上させます。開発者はキャッシュをフラッシュするための API が必要となります。また、オブジェクトやリソースに限定してキャッシュするための API が必要な場合もあります。

ロギングの集中化: ロギングは、その役割や作成するアプリケーションのタイプにかかわらず、すべての開発者に共通の要件です。ログの書き込み、ログ項目の点検、ログの作成、およびログ・ファイルのオープン・クローズをサポートする API が必要になります。

データベース: クラウド・データベースにアクセスする方法が必要です。クラウド・データベースの設計は多岐にわたるので (スキーマ主導型のリレーショナル・データベースもありますが、多くのデータベースでは別の設計が採用されます)、クラウド・アプリケーションを作成する開発者は、各アプリケーションの要求を基にクラウド・データベース・プロバイダーを選択します。データベースに関する API は、基本の CRUD オペレーションをサポートする必要があります。

ID 情報管理: アイデンティティー(identity)を管理する方法が必要となります。も単純な場合は、ユーザーの認証です。アプリケーションが複数のデータ・

ソースおよびアプリケーションと連動している場合には、ユーザーの認証情報をフェデレーション（federation）する方法が必要になります。フェデレーテッド・アイデンティティー管理システム(federated identity management system)を用いることで、サービスとユーザーが互いを知らなくても、あるユーザーが特定のサービスにアクセスできるように認証情報を生成できます。 ID 情報管理用の API では、このような認証情報を適宜キャッシュに保存、または削除します。

メッセージング – ポイント・ツー・ポイント: 開発者はメッセージをキューに送り、それを取り出すための API を必要とします。また、メッセージを検査 (キューから取り出さずに内容を点検) できる必要もあります。

メッセージング - パブリッシュ・サブスクライブ: メッセージ・キューイング・システムでトピックを処理するための API が必要です。この API により、開発者がメッセージをトピックに送り、またトピックからメッセージを取得できるようにします。

未加工の計算/ジョブ処理: Hadoop フォーマットのデータ・マイニングなどの大量処理ジョブを実行する API も必要になります。この API により、開発者は処理ジョブの開始、停止、監視、および一時停止が可能になります。

2 July 2010 41

Cloud Computing Use Cases White Paper Version 4.0

セッション管理: 特にクラウド環境では、ユーザー・セッションの管理機能が非常に重要です。クラウドのインフラは冗長性があり、マシン障害時に回復力を発揮するので、特定のクラウド・ノードが作動しなくなった場合もセッションを維持する必要があります。セッション API により、ユーザー・セッションの現在の状態のアクセスや操作を容易にする必要があります。

サービス検索機能: 開発者は利用可能なクラウド・サービスを見つけ出す方法を必要とします。API が各サービス・タイプに適した追加機能を API として提供することで、サービスのタイプ別にクラウド・サービスを検索できるようにします。

SLA: サービス検索機能を使用する開発者は、プログラムによって検索されたサービスのポリシーを判断する自動的な方法を必要とします。このような API を使用すると、クラウド・サービスを検索し、アプリケーションの SLA 基準に も適したサービスを選択するアプリケーションを作成することができます。

ストレージ: 開発者はクラウド・ストレージ・サービスにアクセスする方法を必要とします。API では、データとメタデータの両方を保存および取得する API を提供する必要があります。

セクション 2.4.2 で説明した API の 5 つのカテゴリーと開発者の要件の相互参照を下の表に示します。

開発者の要件

通常の

プログラミング

デプロイメント

クラウド・

サービス

イメージおよび

インフラ管理

内部インター

フェース

キャッシュ

ロギングの集中化

データベース

ID 情報管理

メッセージング － ポイント・ツー・ポイント

メッセージング － パブリッシュ・サブスクライブ

2 July 2010 42

Cloud Computing Use Cases White Paper Version 4.0

開発者の要件

通常の

プログラミング

デプロイメント

クラウド・

サービス

イメージおよび

インフラ管理

内部インター

フェース

未加工の計算/ジョブ処理

サービス検索機能

セッション管理

SLA

ストレージ

2 July 2010 43

Cloud Computing Use Cases White Paper Version 4.0

6 セキュリティー・シナリオ クラウドでもそれ以外の状況でも、セキュリティーは、書き始めると相当なページ数を割くことになる非常に重要なトピックです。ここでの目的は、クラウドに移行するにあたって設計者および開発者が検討すべきセキュリティー上の問題に焦点を当てることです。 留意するべき重要なポイントは、クラウドによって新たなセキュリティー上の脅威や問題が生じるわけではないということです。セキュリティーを大局的に見てみましょう。クラウド実装モデルにかかわらず、クラウド・コンピューティング全体を、標準に基づく一貫した透明なセキュリティー・フレームワークの必要性を強調するための理想的なユース・ケースとみなすことができます。ソリューションをクラウドに移行する、またはクラウドで構築する際は、この一貫したセキュリティー・モデルを持つことが、開発を単純化し、ベンダーの囲い込みを避け、IT 投資を保護するために必要不可欠です。 クラウドの観点からセキュリティーを考える際の も重要な違いは、特定の技術的な課題とは異なり、企業がセキュリティーを制御できないという点です。内部アプリケーションでは、機密データおよびアプリケーションへのアクセス制御が非常に重要です。クラウド・ベースのアプリケーションでもアクセス制御は同じように重要ですが、セキュリティーのインフラ、プラットフォーム、およびアプリケーションは、クラウド・プロバイダーが直接制御しています。 この章では、セキュリティーに関するトピックを以下の順序で取り上げます。

規制: 規制は技術的な問題ではありませんが、対応が必要です。法律および規制により、機能に関する要件よりも優先されるセキュリティー要件が決まります。

セキュリティー・コントロール: セキュリティー・コントロールをすべて必要とする利用者がいるかもしれませんが、利用者は、すべてを提供できるインフラを持たずにセキュリティー関連の宣伝文句で安心させるクラウド・プロバイダーに気を付けるべきです。

セキュリティーフェデレーション・パターン: 上記のセキュリティー・コントロールを実装するには、複数のフェデレーション・パターンが必要です。クラウド・プロバイダーは、既存のセキュリティー標準によりこれらのパターンを提供する必要があります。

上記の情報は次の章のユーザー・シナリオの説明の原則となっています。 6.1 規制 クラウド・コンピューティングを使用する際のすべての技術的な問題の前提となるのが、規制の厳しい現実です (規制についてはこのホワイト・ペーパーでもすでに言及していますが、セキュリティーの文脈でさらに論じる価値があります)。

2 July 2010 44

Cloud Computing Use Cases White Paper Version 4.0

世界各国の政府は、さまざまな理由により、クラウド・コンピューティングの使用に懸念を抱いています。多くの国には、国外に実体があるマシンに特定のデータを保存することを禁止する厳しいプライバシー法があります。多くの場合、これらの法律に違反した組織 (場合によっては、組織の幹部) に科される厳しい罰則が存在します。クラウドで機密データを保存するすべての組織は、使用するクラウド・プロバイダーは、データが特定の地域外にある物理サーバーに決して保存されないことを証明できなければなりません。 政府機関に加え、多くの貿易および業界団体も規制を制定しています。これらの規制は法律で義務付けられていない場合もありますが、ベスト・プラクティスとして提供されています。 同様の懸念は、クラウドで実行されるアプリケーションにも当てはまります。仮想マシンをクラウドで実行する場合、その仮想マシンで実行されているアプリケーションは機密データにアクセスしてよいのでしょうか。新しい法律や規制が次々に制定されていますが、これは多くの国がまだ対応していないあいまいな領域です。 このような法律および規制の遵守は、他のいかなる要件よりも優先されます。新しい法律により、機能の追加ではなくアプリケーションのインフラの変更に資金を費やすことが求められる場合もあります。CIO は、このような変更を管理し、新しい法律および規制の制定に従って、制定された法律および規制に注意を払う必要があります。 6.2 セキュリティー・コントロール どのシステムの場合も、システムを適切に保護するには、多数のコントロールが必要です。複数のユース・ケースとそれぞれのセキュリティー要件については、次の章で説明します。その中で、ユース・ケースの要件と以下に定義するコントロールの関係を示します。

セキュリティー・コントロール 説明

資産管理

クラウド・インフラストラクチャーを構成するすべてのハー

ドウェア、ネットワーク、およびソフトウェア資産 (物理また

は仮想) を管理できなければなりません。これには、監査およ

びコンプライアンスのために、資産への物理的またはネット

ワークを介したアクセスを記録できることが含まれます。

暗号化: 鍵と証明書の管理

セキュアなシステムには、暗号鍵と証明書を使用し管理する

ためのインフラが必要です。これには、停止時と動作時の機

密保護をサポートするために、標準ベースの暗号化機能と

サービスを使用することが含まれます。

データとストレージの セキュリティー

データを暗号化されたフォーマットで保存できなければなり

ません。また、一部の利用者は、自分のデータを他の利用者

のデータとは別に保存する必要があります。

2 July 2010 45

Cloud Computing Use Cases White Paper Version 4.0

セキュリティー・コントロール 説明

エンドポイントの セキュリティー

利用者は、クラウド・リソースへ接続するエンドポイントを

保護できなければなりません。これには、ネットワーク・プ

ロトコルやデバイス・タイプにより接続するエンドポイント

を制限できることが含まれます。

イベントの監査と レポーティング

利用者は、クラウドで発生するイベント、特にシステム障害

とセキュリティー・ブリーチ (抜け穴) に関するデータにアク

セスできなければなりません。イベントへのアクセスには、

過去のイベントを調査できることや、新たにイベントが発生

したときにそれをレポートすることが含まれます。タイミン

グ良くイベントをレポートできなければ、クラウド・プロバ

イダーの評判は失墜します。

ID 情報、役割、 アクセス制御、および属性

効果的にアクセス制御を実装し、クラウド・ベースのリソー

スに対するセキュリティー・ポリシーを実施するために、個

人およびサービスの ID 情報、役割、資格、およびその他の

属性を一貫した、システムで扱える形式で定義できなければ

なりません。

ネットワーク・ セキュリティー

スイッチ、ルーター、およびパケット・レベルでネットワー

ク・トラフィックを保護できなければなりません。IP スタッ

ク自体も保護される必要があります。

セキュリティー・ポリシー

アクセス制御、リソース割り振りはその他の決定事項をサ

ポートするように、一貫したシステムで扱える形式でポリ

シーを定義し、決定を行い、セキュリティー・ポリシーを適

用する必要があります。ポリシーを定義する方法には、SLA および使用許諾契約を自動的に適用するのに十分に堅固である

必要があります。

サービスの自動化

セキュリティー・コンプライアンス監査をサポートする形で

セキュリティー管理の流れやプロセスを管理および分析する

ための自動化が必要です。これには、セキュリティー・ポリ

シーや使用許諾契約書への違反の報告も含まれます。

ワークロードおよび サービス・マネジメント

定義されたセキュリティー・ポリシーおよび使用許諾契約書

に従い、サービスを構成、配置し、監視できる必要がありま

す。 上記のコントロールには以下に示されるような標準を適用できます。

セキュリティー・コントロール 関連標準

暗号化: 鍵と証明書の管理 KMIP (OASIS の Key Management Interoperability Protocol) (http://www.oasis-open.org/committees/kmip/)

2 July 2010 46

Cloud Computing Use Cases White Paper Version 4.0

セキュリティー・コントロール 関連標準

データとストレージのセキュ

リティー IEEE P1619 IEEE Security in Storage Working Group 策定(https://siswg.net/)

ID 情報、役割、アクセス制御、

および属性 SAML (OASIS の Security Assertion Markup Language) (http://saml.xml.org/)

ID 情報、役割、アクセス制御、

および属性

X.509 証明書 ITU Public Key and Attribute Certificate Frameworks Recommendations の一部 (http://www.itu.int/rec/T-REC-X.509)

セキュリティー・ポリシー XACML (OASIS eXtensible Access Control Markup Language) (http://www.oasis-open.org/committees/xacml/)

ワークロードおよびサービ

ス・マネジメント SPML (OASIS Service Provisioning Markup Language) (http://www.oasis-open.org/committees/provision/)

6.3 セキュリティーフェデレーション・パターン フェデレーションは、独立した複数のリソースを単一のリソースのように動作させる機能です。クラウド・コンピューティング自体がリソースのフェデレーションなので、クラウド・コンピューティングを実用化するには、多くの資産、ID 情報、構成などのクラウド・コンピューティング・ソリューションをフェデレーションする必要があります。 前のセクションの要件は、以下のフェデレーション・パターンによって実装されます。

トラスト: 2 つの関係者が認証機関との信頼関係を定義できる機能です。認証機関は認証情報 (一般的に X.509 証明書) を交換し、交換した資格情報を使用してメッセージを保護し、署名付きのセキュリティー・トークン (一般的に SAML) を作成できます。フェデレーテッド・トラストは、他のすべてのセキュアなフェデレーション・パターンの土台です。

ID 情報管理: ユーザーの資格情報 (ユーザー ID とパスワードまたは証明書など) を受け付け、そのユーザーを識別する署名付きセキュリティー・トークンを返す ID プロバイダーを定義できる機能です。ID プロバイダーを信頼するサービス・プロバイダーは、ユーザーを知らない場合でも、このトークンを使用してユーザーに適切なアクセス権を付与できます。

アクセス管理: セキュリティー・トークンを評価し、クラウド・リソースへのアクセスを管理するポリシーを (一般的に XACML で) 作成できる機能です。リソースへのアクセスは、複数の要因で制御される場合があります。たとえば、特定の役割を持つユーザーについて、一日の中のある時間帯だけ特定のプロトコルを使用する場合のみリソースへのアクセスが制限されるような場合です。

2 July 2010 47

Cloud Computing Use Cases White Paper Version 4.0

シングル・サインオン / サインオフ: 信頼する認証機関からの資格情報を基にログイン処理をフェデレーションする機能です。特定の役割を持つ認証済みのユーザーを想定すると、そのユーザーは、フェデレーションされているシングル・サインオンにより 1 つのアプリケーションにログインすると、同じ認証機関を信頼するその他のアプリケーションにもアクセスできます。フェデレーションされているシングル・サインオフもこのパターンの一部です。多くの状況では、あるアプリケーションからログアウトしたユーザーが他のすべてのアプリケーションからもログアウトすることが極めて重要です。シングル・サインオン・パターンは、ID 情報管理パターンが前提となります。

監査とコンプライアンス: ハイブリッド・クラウドを含む複数のドメインに分散されている監査とコンプライアンスのデータを収集する機能です。監査のフェデレーションは、SLA および法的な要件のコンプライアンスを確保し、それを文書化するために必要です。

構成管理: サービス、アプリケーション、および仮想マシンの構成データをフェデレーションする機能です。このデータには、複数のドメインにわたるアクセス・ポリシーおよびライセンス情報を含めることができます。

クラウドにはセキュリティーの既存のベスト・プラクティスが当てはまるため、プロバイダーは、既存の標準を利用してこれらのフェデレーション・パターンを提供するべきでしょう。

2 July 2010 48

Cloud Computing Use Cases White Paper Version 4.0

7 セキュリティーに関するユース・ケース・シナリオ このセクションでは、セキュリティー要件を満たしながらクラウド・コンピューティングを使用しているお客様事例を紹介します。要件およびパターンを定義した上で実環境のシナリオを見て、現実におけるクラウド・セキュリティーを例示します。紹介されるシナリオでは、さまざまなアプリケーションのタイプ、実装モデル、パターン、および役割が取り上げられています。 7.1 クラウド・コンピューティング性能 7.1.1 お客様のシナリオ ある保険会社では、保険金支払要求アプリケーションを使用して、保険契約者および保険契約者が被った物的損害に関するデータを収集しています。現在、ハリケーンが米国の湾岸地域に上陸することが予想されており、莫大な物的損害が発生する可能性があります。そうなった場合は保険金支払要求が激増し、この企業の IT インフラストラクチャーに多大な負荷がかかります。 この会社は、パブリック・クラウド・プロバイダーを利用し、予想される需要を処理する仮想マシンを使用することを決定しました。この場合、企業システムと、クラウド・プロバイダーがホスティングする仮想マシンの間のアクセスを制御し、社内の許可された外交員だけにアクセスを限定する必要があります。また、アプリケーションのクラウド・ベースのインスタンスによって作成されたすべてのデータを企業のファイアウォール内部にセキュアに転送する必要もあります。 後に、クラウド・プロバイダーは、仮想マシンをシャットダウンする度に、アプリケーションやアプリケーション・データの痕跡を確実に消去する必要があります。 7.1.2 解決されるお客様の問題 この会社は、パブリック・クラウドを使用することにより、通常の 10 倍になる可能性があるワークロードを処理できます。想定される 大のワークロードを処理するために十分な追加システムを事前に購入し、維持し、電力を供給し、冷却するのは、コスト・パフォーマンスが良くありません。この会社では日常業務であれば社内システムで処理可能ですが、必要に応じて追加コンピューティング性能を自動的に割り振ることができます。 7.1.3 要件とコントロール このユース・ケースの要件および関連するコントロールを以下に示します。 要件 コントロール

特定の役割に限定された映像への アクセス

ID 情報、役割、アクセス制御、および属性 資産管理 ネットワーク・セキュリティー

2 July 2010 49

Cloud Computing Use Cases White Paper Version 4.0

要件 コントロール

仮想マシンのシャットダウン時にアプリケーションやデータのすべての痕跡を削除する必要がある

ワークロードおよびサービス・マネジメント

7.1.4 フェデレーション・パターン トラスト、アクセス管理、構成管理 7.1.5 役割 損害査定人、保険外交員、監査人 7.2 クラウド・ベースの開発およびテスト 7.2.1 お客様のシナリオ あるオンライン小売業者では新しい Web 2.0 店頭アプリケーションを開発する必要がありますが、自社の IT 担当者および既存のリソースに負担をかけたくないと考えています。この会社は、クラウド・ベースの開発環境と共に、ホスティングされている開発ツールおよびソース・コード・リポジトリーも提供するクラウド・プロバイダーを選択しました。新しいアプリケーションが多様なタイプのマシンおよび大量のワークロードを扱えるようにするため、テスト環境用には、別のクラウド・プロバイダーを選択しました。 クラウド・ベースの開発およびテスト用に 2 社のプロバイダーを選択しているので、フェデレーションが非常に重要となります。 7.2.2 解決されるお客様の問題 開発の観点からすると、クラウドでホスティングされる開発ツールを使用することにより、各開発者のマシンでツールをインストール、構成、および管理する必要がなくなります。ツールの更新は、クラウド・プロバイダーのサイトで一度にインストールされ、すべての開発者が同じバージョンのツールに自動的に移行されます。 大規模開発において、クラウド・プロバイダーのインフラの拡張容易性を利用できるので、製品をはるかに短期間で開発できます。また、クラウド・ベースの開発では、クラウド・ベースのリポジトリーから 新のソース・コードを取得できます。 テストの観点からすると、従来のインターフェースから Web 2.0 インターフェースに移行する際のサーバーへの追加負担は未知数です。Web 2.0 インターフェースでは静的 Web ページよりもサーバーとのやり取りがはるかに多いので、テスト・チームは、クラウドで新しいアプリケーションをテストすることにより、新しいインターフェースの影響を測ることができます。 クラウドでは、新しいアプリケーションの負荷テストをはるかに簡単に実行できます。

2 July 2010 50

Cloud Computing Use Cases White Paper Version 4.0

毎秒 500 台の異なるマシンからリクエストが入って来る場合のアプリケーションの動作を確認する場合は、クラウドで 500 台の仮想マシンを起動して負荷テストを実行することができます。さまざまな仮想マシン・イメージがあるので、各種マシン (オペレーティング・システム、バージョン、プロトコルなど) を使用してアプリケーションを簡単にテストすることができます。1,000 台または 10,000 台のマシンで同じテストを実行する場合は、社内でインフラを構築するのに比べ、クラウドで実行するとコスト・パフォーマンスが良くなります。 7.2.3 要件とコントロール このユース・ケースの要件および関連するコントロールを以下に示します。 要件 コントロール

開発者ツールのインストールと保守を 1 カ所で集中的に行う

資産管理

仮想マシンのシャットダウン時にアプリ

ケーションやデータのすべての痕跡を削

除する必要がある ワークロードおよびサービス・マネジメント

開発およびテスト・クラウドでのシング

ル・サインオン

暗号化 エンドポイントのセキュリティー ID 情報、役割、アクセス制御、および属性 ネットワーク・セキュリティー

ソース・コードおよびテスト計画への制御

されたアクセス 資産管理 ID 情報、役割、アクセス制御、および属性

開発およびテストで 仮想マシンを自動的

に起動およびシャットダウンできなけれ

ばならない サービスの自動化

開発およびテストで仮想マシンの使用量

および性能に関する統計情報を報告でき

なければならない イベントの監査とレポーティング

7.2.4 フェデレーション・パターン トラスト、ID 情報管理、アクセス管理、シングル・サインオン、監査とコンプライアンス、構成管理 7.2.5 役割 開発者、テスト担当者、管理者、監査人

2 July 2010 51

Cloud Computing Use Cases White Paper Version 4.0

7.3 ストレージ・クラウド 7.3.1 お客様のシナリオ ある金融投資会社は、代理店および系列会社に新しい投資商品を発売する予定です。会社の代理店および系列会社に新商品の利点と特徴を伝えるために多くの商品映像を制作しています。これらの映像データは非常に大容量であり、オンデマンドで提供することを実現するために、クラウド環境に映像データを保存することにより、企業のインフラへの要求を軽減します。ただし、これらの映像データへのアクセスは厳しく制御する必要があります。商品競争上の理由で、認定を受けている代理店のみが映像を表示できるようにする必要があります。さらに強力な制約として、規制により、商品発売前の沈黙期間中は映像データを含む商品の詳細を内密にしておく必要があります。 この会社は、映像データのセキュアなホスティングおよび配信のために、実現可能なパブリック・クラウド・ストレージ・プロバイダーを使用することを決定しました。クラウド・ソリューションは、会社のセキュリティー・ポリシーを実現する監査可能なアクセス制御メカニズムで映像データを制御する必要があります。 7.3.2 解決されるお客様の問題 お客様は、パブリック・クラウド・ストレージ・サービスを使用することにより、お客様のデータ・センターの物理リソースを増強せずに膨大なデータ・ファイルおよび帯域幅の拡張需要に対応することができます。ただし、政府規制および組織の要件によりセキュリティーが非常に重視されます。したがって、コンプライアンスを保証できないパブリック・クラウド・ストレージ・プロバイダーは、そのプロバイダーが提供する性能、価格、または拡張容易性にかかわらず、選択肢に入りません。 7.3.3 要件とコントロール このユース・ケースの要件および関連するコントロールを以下に示します。 要件 コントロール

特定の役割に限定されたアプリケーショ

ンへのアクセス

ID 情報、役割、アクセス制御、および属性 資産管理 ネットワーク・セキュリティー ポリシー

クラウド環境に保存されているデータを

安全に保護する必要がある 暗号化 データとストレージのセキュリティー

クラウド環境に保存されているデータを

会社のファイアウォールの内部に転送す

る必要がある

暗号化 データとストレージのセキュリティー エンドポイントのセキュリティー ネットワーク・セキュリティー

2 July 2010 52

Cloud Computing Use Cases White Paper Version 4.0

7.3.4 フェデレーション・パターン トラスト、ID 情報管理、アクセス管理、監査とコンプライアンス 7.3.5 役割 映像制作者、代理店、関係会社、監査人、規制機関 7.4 相互参照: セキュリティー・コントロールとお客様のシナリオ セキュリティー・コントロールとお客様のシナリオとの関係を下の表に要約します。

セキュリティー・ コントロール

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

開発および テスト・クラウド

ストレージ・ クラウド

資産管理

暗号化: 鍵と 証明書の管理

データとストレージのセキュリティー

エンドポイントの セキュリティー

イベントの監査と レポーティング

ID 情報、役割、 アクセス制御、および属性

ネットワーク・ セキュリティー

ポリシー

サービスの自動化

ワークロードおよびサービス・ マネジメント

2 July 2010 53

Cloud Computing Use Cases White Paper Version 4.0

7.5 相互参照: セキュリティーフェデレーション・パターンとお客様の シナリオ

セキュリティーフェデレーション・パターンとお客様のシナリオとの関係を下の表に要約します。

セキュリティー フェデレーション・

パターン

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

開発および テスト・クラウド

ストレージ・ クラウド

トラスト

ID 情報管理

アクセス管理

シングル・サインオン

監査と コンプライアンス

構成管理

2 July 2010 54

Cloud Computing Use Cases White Paper Version 4.0

8. サービス・レベル・アグリーメント (SLA) クラウド・プロバイダーとクラウドの利用者との関係は、サービス・レベル・アグリーメントで規定される必要があります。クラウドの利用者はクラウド・プロバイダーがある一定のインフラ・サービスを提供してくれることを想定しているため、そのサービスがどのようなものであり、どのように提供されるか、またどのような使われ方をするのかに関し規定することは極めて重要になります。 SLA は、プロバイダーに対する利用者のトラストの基礎になります。SLA がよく書かれているかどうかが、プロバイダーの評判を分けることにもなってきます。 SLA には、利用者とプロバイダーの関係の定義に加え、サービスを客観的に評価できる条件を定めたサービス・レベル目標 (SLO) も含まれます。利用者は、SLA の規約とそれに対する SLO が自らのビジネス目標と合うかを検討し、クラウド・プロバイダーを選択する必要があります。 クラウド・サービスの利用者がプロバイダーの SLA のすべての規約を十分に理解し、合意書に署名する前に、そのサービスが自分の組織にとって必要かを検討することが非常に重要です。 8.1 SLA とは SLA は、クラウド・サービスのプロバイダーとクラウド・サービスの利用者の相互関係を定義します。SLA には以下の項目が含まれます。

プロバイダーが提供するサービスのセット

各サービス内容の完全で明確な定義

プロバイダーと利用者の責任範囲

プロバイダーが約束したとおりにサービスを提供しているかどうかを判断するための測定基準のセット

サービスを監視するための監査の仕組み

SLA の規約が満たされなかった場合に利用者やプロバイダーが利用できる対策

長期的に SLA がどのように変更されるかの規定 市場には 2 つのタイプの SLA があります。1 つはあらかじめ用意されている SLA で、もう 1 つは利用者固有のニーズを満たすためにプロバイダーと利用者が交渉して策定する SLA です。重要なデータやアプリケーションを持つ利用者が前者のタイプの SLA を利用できることはまずありません。このため、SLA (およびクラウド全般) に取り組むにあたってまず利用者が 初に行うのは、データとアプリケーションの重要度を判断することになります。

2 July 2010 55

Cloud Computing Use Cases White Paper Version 4.0

大多数のパブリック・クラウド・サービスは交渉不可の SLA を提供します。要件が満たされない利用者は、こうしたプロバイダーに対して以下の 2 つの対策を講じることができます。

1. (当月の請求額を全額支払った後で) 翌月の請求額での返金を受け入れる

2. サービスの利用を中止する ミッション・クリティカルなアプリケーションやデータについてこのような規約の SLA を許容できないのは明らかです。他方、このような規約の SLA は、交渉によって策定した SLA の下で提供されるクラウド・サービスよりもはるかに安価です。 8.2 サービス・レベル目標 SLO は、明確かつ測定可能な文言でサービスの特徴を定義します。以下に SLO の例をいくつか示します。

システム内の保留中のリクエストが 10 件を超えてはならない。

リクエストのスループットは 3 秒未満でなくてはならない。

読み取りリクエストのデータ・ストリーミングは 2 秒以内に始まらなくてはならない。

仮想マシンの少なくとも 5 つのインスタンスは 99.99999% の可用性がなければならず、また、プロバイダーの 3 つのデータ・センターそれぞれで少なくとも 1 つのインスタンスが利用できなければならない。

当然ながら、異なるユース・ケース、アプリケーション、およびデータ・タイプには異なるサービス・レベル目標が適用されます。また、SLO には、他の SLO との相対的な重要性を示す緊急度レートを含めることもできます。クラウド・プロバイダーが両方の SLO を達成できない場合、利用者は緊急度レートを使用して、応答時間よりも可用性が重要であることを示せます。 また、役割も適用される SLO に影響します。たとえば、クラウドの利用者が作成し、クラウド・プロバイダーがホスティングし、エンド・ユーザーがアクセスするアプリケーションがあるとします。アプリケーションとそのデータが同じクラウド・プロバイダーでホスティングされている場合、アプリケーションはおそらくプロバイダーのデータ・センターの中だけでデータにアクセスできます。クラウドの利用者は、アプリケーションがデータにアクセスするときはいつでも非常に速い応答を期待します。他方、エンド・ユーザーが Web 経由でアプリケーションにアクセスする場合は、応答時間に対する利用者の期待は低くなります。

2 July 2010 56

Cloud Computing Use Cases White Paper Version 4.0

8.3 サービス・レベル管理 サービスのパフォーマンスの監視も測定もせずに SLA の規約が満たされているかどうかを把握することはできません。サービス・レベル管理は、そうしたパフォーマンス情報の収集と処理の手段です。サービスの測定の基準になるのは、SLA のサービス・レベル目標です。 クラウド・プロバイダーは、サービス・レベル管理を利用してインフラについての決定を下します。たとえば、あるプロバイダーが、特定のサービスのスループットが利用者の要件をほとんど満たしていないことに気付いたとします。このプロバイダーは、帯域幅の再割り当てやオンラインになった物理ハードウェアの増加により、この状況に対応することができます。ただし、より多くのリソースをある利用者に与えると別の利用者の SLA の規約を満たせなくなる場合、このプロバイダーはあるお客様を犠牲にして別のお客様を満足させることもあります。サービス・レベル管理の目的は、プロバイダーがビジネス目標および技術的な状況に基づいて賢明な意思決定を下すために役立つことです。 クラウドの利用者は、サービス・レベル管理を利用してクラウド・サービスの使い方を決めます。たとえば、ある利用者が、特定の仮想マシンの CPU 負荷が 90% を上回っていることに気付いたとします。この利用者は、これを受けて別の仮想マシンを起動するかもしれません。しかし、 初の 100 台の仮想マシンにはある料金が適用され、仮想マシンの台数が 100 台を超えるとより高い料金が適用されることが利用者の SLA で定められている場合、利用者は、別の仮想マシンを作成してより高い料金を負担することはしないという決定をするかもしれません。プロバイダーの場合と同じように、サービス・レベル管理は、利用者がクラウド・サービスの利用方法についての決定を行う (場合によっては決定を自動化する) ために役立ちます。 8.4 SLA に関する考慮事項 利用者が SLA でどのような条件が必要となるかを判断する際に考慮すべき要素がいくつか存在します。 8.4.1 ビジネス・レベルの目標 組織がビジネス・レベルの目標を定めていなければ、SLA の規約について議論しても意味がありません。利用者は、組織の目的に基づいてプロバイダーとサービスを選択する必要があります。組織がサービスを利用する理由を 初に定義しなければ、利用するサービスを正確に定義しても価値がありません。 これは、 も困難な問題は技術上の問題ではなく、組織内の駆け引きであるというクラウド・コンピューティングの一面を表しています。上記の目的に関して組織のすべての部門で同意を形成するために、予算削減を受け入れなければならないグループや、インフラのコントロールを失うグループ、その他難しい選択を迫られるグループも出てくるでしょう。これらの困難はありますが、ビジネス・レベルの目標が定められるまでクラウド・コンピューティング (またはこれに関する何らかの技術) を 大限活用することはできません。

2 July 2010 57

Cloud Computing Use Cases White Paper Version 4.0

利用者は、クラウド・コンピューティングをどのように 利用するのかを決める前に、クラウド・コンピューティングを利用する理由を把握しておくべきです。 8.4.2 プロバイダーと利用者の責任 SLA はプロバイダーの責任を定義すると一般的に思われていますが、利用者の責任についても明確にすべきです。利用者の責任には、システムの使用に関する制限、保存可能なデータのタイプに関する制約事項、プロバイダーのシステムで利用するすべてのソフトウェアの有効なライセンスの存在などがあります。プロバイダーと利用者の責任のバランスは、サービスのタイプによって異なります。たとえば、SaaS に対する責任の大部分はクラウド・プロバイダーが負います。一方、ライセンスを受けたソフトウェアがインストールされており、機密データを処理する仮想マシンの利用については、はるかに多くの責任がこれを構築および管理する利用者に課せられます。 8.4.3 事業継続性と災害復旧 多くの利用者は、事業継続性を実現するためにクラウドを利用します。ある利用者は重要データのコピーをバックアップのために複数のクラウドに保存し、他の利用者は自前のデータ・センターで処理負荷に対応できない場合にクラウド・バースティングを利用します。クラウドは自前のシステムが故障した際に組織の運営を続けるための非常に貴重なリソースとなりえますが、クラウド・プロバイダー自体が適切な継続性および災害復旧手順を持っていなければまったく意味がありません。利用者は、クラウド・プロバイダーが災害発生時に適切な防御策を提供できることを確認すべきです。 8.4.4 システムの冗長性 多くのクラウド・プロバイダーは、非常に冗長なシステムを経由してサービスを提供します。これらのシステムは、ハード・ディスク、ネットワーク接続、またはサーバーで障害が起こっても、利用者がその影響をまったく受けずにすむように設計されています。常に利用可能でなくてはならないデータとアプリケーションを動かす利用者は、プロバイダーのシステムの冗長性を考慮すべきです。 8.4.5 保守 インフラの保守はプロバイダーが実施するため、利用者自身が実施する必要はありません。しかし、利用者はプロバイダーが保守作業をいつどのように行うのかを把握すべきです。保守作業中はサービスを利用できなくなるのか、サービスは利用できるがスループットが大幅に低下するのか、保守が利用者のアプリケーションに影響を及ぼす可能性がある場合、利用者が更新されるサービスに対してアプリケーションをテストする機会はあるのかといった内容についてです。保守はクラウドで提供されるあらゆるタイプのサービスに影響を及ぼす可能性がありますし、これはソフトウェアにもハードウェアにも当てはまるということに注意する必要があります。

2 July 2010 58

Cloud Computing Use Cases White Paper Version 4.0

8.4.6 データのロケーション 多くのタイプのデータの物理的なロケーションは制約されています。たとえば、国民の個人情報を国外のマシンに保存することは、多くの国で禁止されています。利用者のデータが特定のロケーションにしか保存されないことをクラウド・プロバイダーが保証できない場合、利用者はそのプロバイダーのサービスを利用できません。クラウド・サービスのプロバイダーがデータのロケーションの規制を実施することを約束する場合は、利用者がプロバイダーを監査して規制が遵守されていることを証明できる必要があります。 8.4.7 データの差し押さえ 捜査当局者がホスティング会社の資産を差し押さえた複数の事例が広く報道されています。捜査当局の標的がある特定の利用者に関連するデータとアプリケーションだったとしても、クラウド・コンピューティングのマルチテナント性により、他の利用者も影響を受ける可能性があります。SLA がカバーできる内容には限界がありますが、利用者はプロバイダーに適用される法律を考慮しなければなりません。また、利用者は、サード・パーティーを使用してデータとアプリケーションとのバックアップを取得することも検討すべきです。 8.4.8 プロバイダーの破綻 どのクラウド・プロバイダーにも倒産したり他社に買収されたりする可能性はあります。利用者はプロバイダーの経営状態を考慮し、プロバイダーが営業を停止した場合の緊急時対応計画を作成すべきです。さらに、利用者のアカウントの料金が滞納されている場合や、利用者のアカウントが係争中の場合、その利用者のデータとアプリケーションへのアクセスに関するプロバイダーのポリシーも明確化されている必要があります。 8.4.9 裁判管轄 利用者は検討するクラウド・プロバイダーに適用される法律を理解する必要があります。たとえば、クラウド・プロバイダーがある国に存在し、その国では、そのクラウド・プロバイダーの提供するサービスを利用する、あらゆるデータやアプリケーションを閲覧することができる権利をもっているといった場合もあります。このような場合、利用者のデータとアプリケーションの性質から、これを許容できないこともあります。 8.4.10 クラウド・ブローカーとクラウド再販業者 クラウド・プロバイダーが実際には別のクラウド・プロバイダーのブローカーまたは再販業者の場合には、SLA の規約において、ブローカー、再販業者、またはプロバイダーの施設内で何か問題が発生した場合の責任または義務に関するあらゆる疑問いついて明文化しておく必要があります。

2 July 2010 59

Cloud Computing Use Cases White Paper Version 4.0

8.5 SLA の要件 8.5.1 セキュリティー 一般要件としてのセキュリティーについては、このホワイト・ペーパーのセクション 6 とセクション 7 において議論されています。SLA のセキュリティーに関する側面は、セクション 6 のセキュリティー・コントロールおよびフェデレーション・パターンを念頭に記述される必要があります。クラウドの利用者は、自らのセキュリティー要件およびそれらの要件を満たすために必要なコントロールおよびフェデレーション・パターンを理解する必要があります。一方で、クラウド・プロバイダーは、適切なコントロールおよびフェデレーション・パターンを実現するために利用者に何を提供しなければならないかを理解する必要があります。 8.5.2 データの暗号化 利用者がクラウド上に重要なデータを保存する場合、そのデータを転送している間や保存されている間、データが暗号化されていることが重要になります。暗号化のアルゴリズムやアクセス制御ポリシーの詳細は SLA の中で規定されている必要があります。 8.5.3 プライバシー プライバシーに関する基本的な懸念に対しては、データの暗号化や保存、削除などの要件によって対応します。また、クラウド・プロバイダーは、マルチテナント環境において、どのようにして利用者毎にデータとアプリケーションを分離するかについて SLA で明確化する必要があります。 8.5.4 データの保存と削除 多くの組織においては、データを一定期間保管しておかなければならないという法的要件があります。ある組織では、一定期間の後、データは削除されなければならないという要件もあります。クラウド・プロバイダーは、これらのポリシーに準拠していることを証明できなければなりません。 8.5.5 ハードウェアの消去と破棄 情報漏えいのよくある原因は、ハードウェアの不適切な廃棄です。クラウド・プロバイダーのハード・ディスクが故障した場合、そのディスクを廃棄またはリサイクルする前にディスクの媒体にゼロ書き込みをするなどの必要があります。これと同じように、多くのクラウド・プロバイダーは、利用者が仮想マシンの電源をオフした後でメモリー領域をゼロで埋めるといった追加保護を実施しています。 8.5.6 法規制の遵守 (コンプライアンス) 多くのタイプのデータとアプリケーションは、規制の対象となります。規制には法律 (米国の医療記録に関する HIPAA) や、業界固有の規制 (クレジット・カードを受け付ける小売店の PCI DSS) があります。規制が施行される際には、クラウド・プロバ

2 July 2010 60

Cloud Computing Use Cases White Paper Version 4.0

イダーはその規制に対し遵守していることを証明できなければなりません。 8.5.7 透明性 一部のクラウド・プロバイダーの SLA では、プロバイダーが SLA の規約を満たせなかったことを証明する負担を利用者が負います。プロバイダーのサービスが数時間停止しても、ダウン時間を証明できなければ、利用者はいかなる種類の補償も受けられません。 重要なデータとアプリケーションに関する SLA の規約を履行できない場合、プロバイダーは利用者に積極的に通知する必要があります。これには、機能停止などのインフラの問題やパフォーマンスの問題、セキュリティー・インシデントが含まれます。 8.5.8 認可 特定のタイプのデータとアプリケーションに適用されるさまざまな認可があります。たとえば、クラウド・プロバイダーが ISO 27001 認可を取得していることが、利用者にとっての要件であることもあります。プロバイダーは、認可を取得していることを証明し、認可を 新の状態に保つ責任があります。 8.5.9 KPI に用いる用語 「サービスの使用可能な時間」という用語は何通りにも定義できます。多くの場合、その定義はプロバイダーのアーキテクチャーに固有のものです。プロバイダーが 6 大陸にデータ・センターを持つ場合、「サービスの使用可能な時間」は特定のデータ・センターのものでしょうか。それとも任意のデータ・センターのものでしょうか。利用可能な唯一のデータ・センターが別の大陸にある場合、その「サービスの使用可能な時間」が受け入れられることはできないでしょう。さらに悪いことに、別のクラウド・プロバイダーは、各自のアーキテクチャーに固有の定義を使用します。このため、クラウド・サービスの比較が難しくなります。 各種 KPI に用いる用語を業界で定義すれば、特に SLA (およびクラウド・サービス全般) の比較ははるかに容易になります。 8.5.10 モニタリング SLA の規約を満たさないと金銭的または法的責任が生じる場合は、プロバイダーのパフォーマンスを誰が監視すべきか (また利用者も責任を果たしているかどうか)という点が非常に重要になってきます。サービスの使用可能な時間を可能な限り広義に定義することがプロバイダーの利益にかなう一方、利用者は発生するすべてのシステム障害についてプロバイダーを責めたくなるかもしれません。この問題の 良の解決策は、プロバイダーのパフォーマンスを監視する中立の第三者組織を置くことです。中立の第三者組織を置くことで、プロバイダーが独自の裁量で機能停止をレポートする場合や、機能停止が発生したことを証明する責任を利用者が負う場合に、利害の対立を避けられます。

2 July 2010 61

Cloud Computing Use Cases White Paper Version 4.0

8.5.11 対監査性 多くの利用者要件には、法規制や業界標準の遵守が含まれています。利用者が発生した不履行の責任を負うため、利用者がプロバイダーのシステムおよび手順を監査できることが不可欠です。SLA では、監査の実施方法と監査のタイミングを明確化します。監査を行うと混乱と費用が生じるため、多くの場合、プロバイダーは監査に制限と料金を課します。 8.5.12 測定基準 モニタリングと監査では、発生時に監視でき、事後に監査できる有形のものが必要です。SLA の測定基準は客観的かつ明確に定められる必要があります。クラウドの利用者は、アプリケーションとデータの性質により際限ない種類の測定基準を必要とするかもしれません。すべての測定基準を一覧化することはできませんが、 も一般的な測定基準の一部を以下に示します。

スループット – サービスの応答時間

信頼性 – サービスを利用できる頻度

ロード・バランシング – 弾力性が効果を発揮するタイミング (新しい仮想マシンのブートや終了など)

耐久性 – データ損失の可能性

弾力性 – 明確に示された制限 (ストレージや帯域幅の 大量など) 内で特定のリソースを無限に拡張できること

線形性 – 負荷が増加したときのシステムのパフォーマンス

迅速性 – 利用者のリソース負荷の増減に対するプロバイダーの対応時間

自動化 – 人が介入せずに処理されるプロバイダーへのリクエストのパーセンテージ

お客様サービスの応答時間 – プロバイダーがサービス・リクエストへの応答に要する時間。クラウドのオンデマンド・セルフサービスに問題が生じた場合に必要となる人を介したやり取りを指します。

8.5.13 マシン･リーダブルな SLA SLA 用のマシン･リーダブルな言語を使用すれば、クラウド・プロバイダーを動的に選択できる自動クラウド・ブローカーを実現できます。クラウド・コンピューティングの基本的な特徴の 1 つは、オンデマンド・セルフサービスです。自動クラウド・ブローカーでは、この特徴を拡張し、クラウド・プロバイダーもオンデマンドに選択できるようにします。ブローカーは、利用者が定めるビジネス基準に基づいてクラウド・プロバイダーを選択できます。たとえば、利用者のポリシーで、ブローカーが一部のタスクには可能な限り も安いプロバイダーを使用し、それ以外のタスクにはもセキュアなプロバイダーを利用するように規定する場合もあります。この要件に対する市場の実質的な要求が形作られるにはある程度時間がかかりますが、SLA の標

2 July 2010 62

Cloud Computing Use Cases White Paper Version 4.0

準化に関するすべての作業はこのことを念頭に行われるべきです。 8.5.14 人を介したやり取り クラウド・コンピューティングの基本的な特徴の 1 つはオンデマンド・セルフサービスですが、人を介したやり取りでしか解決できない問題が常に存在するという事実は残ります。このような状態は稀なはずですが、多くの SLA には、サポート目的でのリクエストに対するプロバイダーの対応に関する保証が含まれています。一般的な保証では、利用者が行えるリクエストの件数、リクエストにかかる費用、プロバイダーの対応時間がカバーされます。 8.6 信頼性に関する注意事項 信頼性の議論において、よく使われることが多い測定基準は、プロバイダーが提供する「9」の数です。たとえば、「ファイブ・ナイン」 (9 が 5 つ)の信頼性は 99.999% の時間サービスを利用できることを意味します。これは、システムの停止時間の合計が 12 カ月当たりおよそ 5 分であると言い換えることができます。この測定基準の問題は、停止の明確な定義がないと、すぐに無意味になるということです (インシデントが停止に相当するかどうかをクラウド・プロバイダーが決定できる場合、この測定基準はさらに無意味になります)。 「9」の数の漠然とした性質以外に重要なのは、クラウドで提供される多くのサービスは、クラウドで提供される他のサービスの上に構築されていることを考慮することです。複数のインフラを組み合わせることができれば大きな柔軟性とパワーを実現できますが、プロバイダーを追加するたびにシステムの信頼性は低下します。あるクラウド・プロバイダーが別のクラウド・プロバイダーのストレージ・サービスとさらに別のクラウド・プロバイダーのデータベース・サービスの上に構築されているサービスを提供しており、これらのプロバイダーがすべて 99.999% （「ファイブ・ナイン」） の信頼性を提供している場合でも、システム全体の信頼性は 99.999% 未満となります。 初のクラウド・プロバイダーのシステムが停止すると、サービスは利用できなくなります。2 つ目または 3 つ目のプロバイダーのシステムで問題が発生した場合も、サービスは同様に利用できなくなります。関与するクラウド・プロバイダーが増えれば増えるほど、システム全体のダウン時間も増加します。

後に、クラウド・プロバイダーが増えると、外部要因も増加します。仮想マシンとクラウド・データベースが同じデータ・センター内にある場合、仮想マシンとデータベース間の通信にはネットワーク・アクセスは必要ありません。これに対し、クラウド・データベースが別のプロバイダーによって提供される場合は、仮想マシンとデータベース間で利用できる帯域幅がシステム全体のパフォーマンスと信頼性に影響します。正常なシステムでは両方のクラウド・プロバイダーのクラウドが稼働できますが、プロバイダー間のネットワーク接続で障害が起こるとシステム全体が停止します。 要約すると、クラウド・サービスの信頼性を評価する必要があるすべての利用者は、直接的であれ間接的であれ、そのサービスを提供するクラウド・プロバイダーについてできるだけ多くのことを知っておく必要があります。

2 July 2010 63

Cloud Computing Use Cases White Paper Version 4.0

8.7 相互参照: SLA の要件とクラウド・デリバリー・モデル セクション 2.1.1 の 3 つの NIST デリバリー・モデルとこのセクションで示した SLA の要件の相互参照を下の表に示します。

要件 PaaS IaaS SaaS

データの暗号化 ✓ ✓

プライバシー ✓ ✓ ✓

データの保存と削除 ✓ ✓

ハードウェアの消去と破棄 ✓ ✓

法規制の遵守 (コンプライアンス) ✓ ✓ ✓

透明性 ✓ ✓ ✓

認可 ✓ ✓ ✓

KPI に用いる用語 ✓ ✓

測定基準 ✓ ✓ ✓

対監査性 ✓ ✓ ✓

モニタリング ✓ ✓ ✓

マシン･リーダブルな SLA ✓

8.8 相互参照: SLA の要件とユース・ケース・シナリオ できる限りにおいて、SLA はクラウドの利用者とクラウド・プロバイダーの両方の利益を保護します。特定の SLA がすべての利用者のニーズを満たすことはないのとまったく同じように、このセクションで説明されているすべての要件がすべてのお客様のシナリオに当てはまることはありません。セクション 3 の 7 つのユース・ケース・シナリオとこのセクションで示した SLA の要件の相互参照を下の表に示します。

2 July 2010 64

Cloud Computing Use Cases White Paper Version 4.0

要件

エンド・ユー

ザーとクラウド

企業とクラウド

とエンド・

ユーザー

企業とクラウド

企業とクラウド

と企業

プライベート・

クラウド

クラウド・

ベンダーの変更

ハイブリッド・

クラウド

データの暗号化 ✓

プライバシー ✓ ✓ ✓ ✓ ✓ ✓ ✓

データの保存と 削除 ✓ ✓ ✓

ハードウェアの 消去と破棄 ✓ ✓ ✓

法規制の遵守 (コンプライアンス) ✓ ✓ ✓ ✓ ✓ ✓ ✓

透明性 ✓ ✓ ✓ ✓ ✓ ✓ ✓

認可 ✓ ✓ ✓ ✓ ✓ ✓

KPI に用いる用語 ✓ ✓ ✓ ✓ ✓

測定基準 ✓ ✓ ✓ ✓ ✓ ✓

対監査性 ✓

モニタリング ✓ ✓ ✓ ✓ ✓ ✓

マシン･ リーダブルな SLA ✓

2 July 2010 65

Cloud Computing Use Cases White Paper Version 4.0

9. 結論と推奨事項 クラウド・コンピューティングは、仮想化、SOA、および Web 2.0 をはじめとする多くの業界トレンドを基に構築されており、これらのトレンドを補完しています。結果的に、このホワイト・ペーパーで明示した多くの要件について標準が存在しています。Cloud Computing Use Case Discussion Group は前進しながら、コミュニティーとして協力し合い、お客様のニーズに合った既存の標準を具現化し、既に進行中の標準化作業をてこ入れし、既存の標準で明記されていない差分を埋めるために必要な対応を特定します。 このホワイト・ペーパーは、1,400 人を超える参加者で構成されるオープンな Web コミュニティーによって作成されました。このグループは当初 Open Cloud Manifesto の支援者で構成されていましたが、すぐに世界中の多くの個人の参加により拡大しました。このコミュニティーには、大企業および中小企業、政府機関、コンサルタント、およびベンダーの代表者も参加しています。 このホワイト・ペーパーは、以下の Open Cloud Manifesto の 3 つの原則を重視して作成されました。 1) 利用者は協力して作業する、2) お客様主導で行うクラウドのオープン性を維持する活動を行う、3) 可能な限り既存の標準を使用する。このホワイト・ペーパーでは、これらの原則が有効であることが検証されました。これらの原則は、今後の作業でも中心となるでしょう。 このホワイト・ペーパーで紹介されているユース・ケースでは、以下の一般的な利用者要件を示しています。

共通の仮想マシン・フォーマット、データ・フォーマット、および API: あるクラウド・プロバイダー向けに構築された仮想マシン、データ、およびアプリケーションは、変更せずに別のクラウド・プロバイダーで再利用可能である必要があります。

クラウド管理: サービス・マネジメント、ガバナンス、メータリング、モニタリング、ID 情報のフェデレーション、SLA とベンチマーク、データおよびアプリケーションのフェデレーション、デプロイメント、およびライフサイクル管理がなければクラウド・コンピューティングを実現することはできません。これらの要件は、セクション 3 で定義されています。

セキュリティー: セキュリティー要件はアプリケーションおよびデータのタイプによって広く変わりますが、クラウド・コンピューティングのセキュリティーは非常に重要です。

ロケーションの認識: クラウド・インフラストラクチャーをホスティングする物理マシンの場所を特定する方法は、多くの政府規制の絶対条件です。

利用者が、特定のベンダーのオープンでない独自のソリューションに固執せずに、このホワイト・ペーパーで概説されているすべてのユース・ケースを実装できることが可能となります。

2 July 2010 66

Cloud Computing Use Cases White Paper Version 4.0

このホワイト・ペーパーで説明されている開発者の要件は、以下の 2 つの広義のカテゴリーにグループ分けできます。

サービスの API: データベース、メッセージング (ポイント・ツー・ポイントとパブリッシュ/サブスクライブの両方)、未加工のコンピューティング性能、およびストレージに対するすべての API 要件は、クラウド・サービスと直接関係します。

API のサポート: クラウド・サービスを効果的に使用するには、キャッシュ、ロギング、ID 情報管理、サービス検索機能、セッション管理、および SLA に対する API 要件が必要です。

開発者が、特定のベンダーのオープンでない独自の API を使わずに、このホワイト・ペーパーで概説されているすべてのユース・ケースを実装できなければなりません。 利用者がデータおよびアプリケーションをクラウドに移行しようとする際に、 も多く生じる質問は、一貫してセキュリティーに関するものです。クラウド・コンピューティングでは、一般的な IT のセキュリティーで取り上げられない全てのセキュリティー問題を明らかにしている訳ではありません。クラウド環境への移行における関心事は、セキュリティー・ポリシーの実装および実施にサード・パーティーが関与するようになる点です。適切な管理を実現するために、クラウド・プロバイダーからの透過的な対応が強く要求されています。このホワイト・ペーパーのセキュリティーに関する説明は、クラウド・プロバイダーが提供すべき、セキュリティー・コントロール、フェデレーション・パターン、および標準をカバーしています。 組織がクラウド・サービスを利用する際は、利用者とプロバイダーの両方の責任をサービス・レベル・アグリーメントで明確に定義する必要があります。SLA では、利用者がサービスを利用する方法とプロバイダーがサービスを提供する方法を定めます。クラウド・サービスの利用者がプロバイダーの SLA のすべての規約を十分に理解し、アグリーメントに署名する前に自分の組織における必要性について検討することが非常に重要です。 クラウド・コンピューティングのあらゆる面を通じて、既存の標準が要件を満たす場合には、それらを全面的に一貫して実施する必要があります。既存の標準が要件を満たさない場合は、要件を満たすために必要な標準を定義し、実施しなければなりません。本コミュニティーによって作成されたホワイト・ペーパーは、真の意味でオープンなクラウド・コンピューティング環境を確立するための基準となることを目的としています。

2 July 2010 67

Cloud Computing Use Cases White Paper Version 4.0

変更の要約 第 2 版、2009 年 10 月 30 日

開発者の要件に関する新しいセクションを追加しました。API の異なるレベル、API のカテゴリー、および開発者の役割に関する説明をセクション 2.4 に追加しました。第 2 版で新たに追加された主な内容は、開発者および開発者の要件です。

適当な場合は、「scalable (拡張が容易)」という言葉を「elastic (弾力的)」に置き換えました。

NIST のクラウド・コンピューティングの定義の変更を反映して、セクション 2.1 の分類の説明を更新しました。

セクション 4.4 のお客様のシナリオを更新しました。

一貫したデプロイメントおよび共通の仮想マシン・フォーマットの要件の説明を補強し、クラウド・ベンダーがストレージを仮想マシンに接続するさまざまな方法を追加しました。

第 3 版、2010 年 2 月 2 日

• セキュリティーを念頭に、セクション 3.2.1 のサービス・レベル・アグリーメントの説明を若干変更しました。

• セキュリティー・シナリオおよび要件に関するセクション 6 およびセキュリティーに関するユース・ケースに関するセクション 7 を追加しました。

• 「結論と推奨事項」にセキュリティーの簡潔な要約を追加しました。

第 4 版、2010 年 6 月 30 日

• 「セクション 8 サービス・レベル・アグリーメント (SLA)」を追加しました。

• 「結論と推奨事項」にサービス・レベル・アグリーメントの簡潔な要約を追加しました。

• セクション 3.2.1 の誤植を修正しました (「basic the identity」を「the basic identity」に修正)。※

※ 原文における修正のみ

2 July 2010 68