クラウド検討の進め方

http://www.koshikivaluehub.jp/ Copyright © 2006-2011 KOSHIKI ValueHub Corporation. All rights reserved. 無断複製、転載を禁ず

コシキ・バリューハブ株式会社

クラウド検討の進め方

2011/06/20

1. クラウドの定義 #1. クラウドへの期待

1

ネットワーク上に存在するサーバが提供するサービスを、それらのサーバ群を意識することなしに利用できるというコンピューティング形態を表す言葉です。

ネットワークを図示するのに雲状の絵を使うことが多いことからきた表現です。

雲の中にはハードウェアやソフトウェアの実体があるが、その中身は見えない（気にしなくてよい）というイメージです。

『クラウド』の言葉の由来は、ネットワーク経由でのサービス提供です。今日『クラウド』が注目を浴びているのは、① 災害対策として② 『クラウド』の仕組みを利用することで、企業ＩＴ部門のミッションに対する効果が期待できる

『クラウド』とは企業ＩＴ部門のミッション

No ミッション

1 システムの安定稼働（災害時の早期業務復旧、継続）

2 顧客（利用者）満足度の向上

3 コストの適正化

顧客満足度：利便性向上への期待

『クラウド』への期待

コストの適正化への期待

災害への対応（ＢＣＰ）

1. クラウドの定義 # 2. クラウドの特徴

2

『クラウド』のメリットとして、種々のキーワードが語られています。「システムの安定稼働（ＢＣＰとしての業務継続性の確保）」「顧客満足度/利便性向上」「コストの適正化」という観点で整理すると、本質は以下の通りであると考えます。

あるサイトでのクラウド紹介文

Webブラウザさえ備えていれば、どんな端末も利用可能。日本はもとより、海外からもアクセス可能。

システム構築に伴う初期費用の削減。サービスを利用した分だけ支払う従量課金。機器やソフトの更新作業や故障対応など、メンテナンスコストが丌要。

現状の規模に合わせた、無駄のないシステム利用が可能。サービス利用者の急増など、システムの増減にもすばやく対応。サービスからネットワークを含めた、柔軟な構成を選択可能。

アメリカ国立標準技術研究所 (NIST)による定義

クラウドコンピューティングとは、コンフィグレーション可能な計算機資源（ネットワーク、サーバ、ストレージ、アプリケーション、サービスなど）の共有プールへの簡便でオンデマンドなネットワーク経由でのアクセスを、最小限の管理手順もしくはサービス提供者とのやりとりで迅速に供給することを可能にするモデルである。

このクラウドモデルは5つの特性、3つのサービスモデル、4つの配置モデルから構成され、可用性を高めている。（特性、サービスモデル、配置モデルは補足資料参照）

所有から利用への変化に伴うコスト適正化

利用量に応じた合理的なコスト負担

機能追加、利用増減に迅速に対応できる

災害対策が施されたサービサー側インフラの利用

http://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%A1%E3%83%AA%E3%82%AB%E5%9B%BD%E7%AB%8B%E6%A8%99%E6%BA%96%E6%8A%80%E8%A1%93%E7%A0%94%E7%A9%B6%E6%89%80

1. クラウドの定義 #3. クラウドの定義

3

1．ＩＴリソースの一部機能をネットワーク経由のサービス利用とすることでコストの適正化を実現できるソリューション

3．利用者に対して、利用量に応じた費用体系をもつソリューション

2．利用量を測定することができるソリューション

4．利用量や機能の増減に、迅速に対応できるソリューション

『クラウド』の定義はサービサー、ベンダにより様々に行われています。弊社では、前述のメリットを踏まえ「利用者視点に立ち」、「本来の目的」を明確にする形で、『クラウド』を定義します。

『クラウド』：コストの適正化、利便性の向上を実現可能な以下の特徴を持つソリューション

1. クラウドの定義 #4. クラウドの形態

4

前述の「ＩＴリソースの一部機能をサービス利用する」について、そのサービス化範囲によって、『クラウド:』の形態を定義します。

データセンター

ハードウェア

基本ソフトウェア

アプリケーションソフトウェア

業務ロジック


ハードウェア



業務ロジック


ハードウェア



業務ロジック


ハードウェア



業務ロジック


ハードウェア



業務ロジック

従来型システム利用形態クラウド

自社資産ｻｰﾋﾞｽ提供

自社運用自社資産を自社センターで運用

ハウジング機器を預けて運用委託

IaaS

（Infrastructure

As a Service)

マシン資源をインターネット上の「サービス」として利用

PaaS

（Platform

As a Service)

システム基盤をインターネット上の「サービス」として利用

SaaS

（Software

As a Service)

ソフトウェア機能をインターネット上の「サービス」として利用


ハードウェア



業務ロジック

ＢＰＯ

ＢＰＯ

（ﾋﾞｼﾞﾈｽ・ﾌﾟﾛｾｽ・ｱｳﾄｿｰｼﾝｸﾞ）

自社専用/他者との共用かでプライベートクラウド/パブリッククラウドに分けられる。

2. クラウド検討の進め方 #1 クラウド導入の目的（1)

5

アジアにおけるクラウドの導入目的を以下に示します。日本における主要なクラウド導入目的は「コスト削減」となっています。他国おいては、主要目的として「戦略投資」（新規ビジネス立上げ時などのビジネスニーズに応じた柔軟な投資の実現）が高くなっています。

出典：ヴイエムウェア社「クラウドコンピューティングに関する企業意識調査」2010/11/9(※アジアと対象とした調査）

2. クラウド検討の進め方 #1 クラウド導入の目的(2)

6出典：日本情報システム・ユーザ協会「企業ＩＴ動向調査2010」

日本における、クラウド導入目的の詳細を左記に示します。

規模の大きな企業ではコスト面だけではなく、クラウドの迅速性も評価されています。

2. クラウド検討の進め方 #2 理想と現実(1)

7

これまでの『アウトソーシング』と『クラウド』の違いを以下に整理しています。『クラウド』の特集や紹介記事等では、『アウトソーシング』で発生した、いくつかの課題について、技術進歩やサービス内容の見直しにより解決されたと言われています。

『アウトソーシング』の課題

①コスト算出方法のブラックボックス化

③資産追加/拡張のコスト増加

④ＩＴ資産の保全性（保守切れ対応が曖昧）

②運用費の高止まり傾向

⑥ＩＴ資産のブラックボックス化

⑤他ベンダへの移行が難しい

『クラウド』における解決策の課題

(A)費用算出方法の提示

(D)仮想化技術の進歩による拡張性の確保

(B)従量課金

(C) 技術の進歩による共有性の向上（シェアリングによる低コスト化）

(E)仮想化技術によりＨＷリプレイスが容易

(Ｆ)アプリケーション基盤のサービス提供形態

課題として残ったまま

サービス提供であるため、資産を意識しなくなる


8

各サービサーとも『クラウド』に力をいれ、各種サービスを提案しています。しかしながら、『クラウド』においても、これまでのアウトソーシングと同様の課題、およびクラウド特化の課題が存在します。

分類課題補足

1従量課金クラウド＝『利用量に応じた課金』のイメージが先行しているが、課金体系がユーザにとって適切な体系となっていない。

利用者数やディスク容量以外の課金体系はまだまだ尐ない。利用者課金ではユーザ数によってはコスト高となる。

2利用量の変動にどんな時間間隔で対応できるかを見極めないと、ユーザの目的に合致しない恐れがある。

1ヶ月単位で変更可能など。

3サービスレベル自社でHW,SWの稼働などをコントロールできないため、サービスレベルの合意が、まずます重要になる。

4運用利用形態によって、運用や監視、保守の役割分担が曖昧になりやすい例:IaasやPaaS時の障害切り分け

5緊急対応が必要な場合に、サービサー側の対応、復旧作業が遅れる可能性がある。（自社でコントロールしている場合と比べ）

6 ＢｌａｃｋＢｏｘ化が進む（⇔サービス利用とのトレードオフ）

7性能/機能専用システムと比べ、レスポンスが低下する恐れがある回線速度やＨＷ資産を共有する他利用者のとの負荷競合

8専用システムと異なり、カスタマイズ可能範囲が制限されるため、現行業務の見直しが必要となる恐れがある。

業務パッケージのＦＩＴ＆ＧＡＰ同様、業務をクラウドサービスに合わせていく必要あり

9汎用的なコンピュータ言語、ＭＷを利用していない場合、カスタマイズ対応できる技術者が丌足する恐れがある。また、カスタマイズのために必要な情報も丌足がちとなりやすい。

クラウド化により特に顕在化する課題


9

分類課題補足

10セキュリティＨＷ資産を共有するための設定ミスによる他ユーザへの情報漏洩サーバを共有しているため１つの設定ミスで他者に情報がもれる。

11 通信経路での漏洩、なりすましの恐れあり

12 セキュリティパッチの適用がサービサー任せとなる

13 新たな脅威に対する解決策の適用がサービサー任せになる

14 サービス解約後のデータ削除が証明されていない/ユーザが確認できない解約後に本当にデータが削除されているか証跡を出せるサービサーは尐ない

15 インターネット経由のサービスでは、ＩＤ管理を厳密にしないと退職者が簡単にデータにアクセスできるどこでもアクセスできるため、退職者が利用しやすい。

16業務継続性サービス終了により、業務ができなくなる恐れ有りサービサーの体力に影響される。

17 他のサービサーへ移行が難しい移行ツール等の丌備

18コンプライアンスデータセンタ設置国の法律に従うため、日本国の法律と異なる理由にて、情報が強制的に閲覧される可能性がある

データセンター立地の法律に従う。

19 ＩＴガバナンス利用者が内部監査を行う場合に、必要な監査証跡をクラウド事業者が提供できない場合がある


10

前述の課題は、クラウドの提供形態によっても異なります。重要データを扱うなど重要な業務については、クラウド化への検討要素が多くなり、おすすめしません。

分類課題

1従量課金クラウド＝『利用量に応じた課金』のイメージが先行しているが、課金体系がユーザにとって適切な体系となっていない。

2利用量の変動にどんな時間間隔で対応できるかを見極めないと、ユーザの目的に合致しない恐れがある。

3サービスレベル自社でHW,SWの稼働などをコントロールできないため、サービスレベルの合意が、まずます重要になる。

4運用利用形態によって、運用や監視、保守の役割分担が曖昧になりやすい

5緊急対応が必要な場合に、サービサー側の対応、復旧作業が遅れる可能性がある。（自社でコントロールしている場合と比べ）

6 ＢｌａｃｋＢｏｘ化が進む（⇔サービス利用とのトレードオフ）

7性能/機能専用システムと比べ、レスポンスが低下する恐れがある

8専用システムと異なり、カスタマイズ可能範囲が制限されるため、現行業務の見直しが必要となる恐れがある。

9汎用的なコンピュータ言語、ＭＷを利用していない場合、カスタマイズ対応できる技術者が丌足する恐れがある。また、カスタマイズのために必要な情報も丌足がちとなりやすい。

10セキュリティＨＷ資産を共有するための設定ミスによる他ユーザへの情報漏洩

11 通信経路での漏洩、なりすましの恐れあり

12 セキュリティパッチの適用がサービサー任せとなる

13 新たな脅威に対する解決策の適用がサービサー任せになる

14サービス解約後のデータ削除が証明されていない/ユーザが確認できない

15インターネット経由のサービスでは、ＩＤ管理を厳密にしないと退職者が簡単にデータにアクセスできる

16業務継続性サービス終了により、業務ができなくなる恐れ有り

17 他のサービサーへ移行が難しい

18コンプライアンスデータセンタ設置国の法律に従うため、日本国の法律と異なる理由にて、情報が強制的に閲覧される可能性がある

19 ＩＴガバナンス利用者が内部監査を行う場合に、必要な監査証跡をクラウド事業者が提供できない場合がある

初期投資は抑えられても、利用条件によっては全ライフサイクルをみるとコスト高に

パブリックプライベート

ＩaaS PaaS SaaS ＩaaS PaaS SaaS

迅速性速速最速やや速

やや速

やや速

サービスレベル合意の難しさ

難難難難難難

運用の難しさ（通常）

易易易同やや易

やや易

運用の難しさ（緊急対応の早さ）

難難最難同やや易

やや易

性能確保の難しさ難難最難同同同

セキュリティ確保の難しさ

難難難同同同

他ベンダへの移行の難しさ

難最難最難難難難

コンプライアンスの確保の難しさ

最難最難最難やや易-難

やや易-難

やや易-難

ガバナンスの難しさ難難難難難難

※自社運用時と比べ「難」「同」「易」で分類

提供形態により、課題に差がある

2. クラウド検討の進め方 #3 クラウド化のための重要検討Point1

11

(A)どのようなＩＴ要件に対して、(B)何を目的とし、(C)その手段としてどのようなクラウドで実現するか？により、重点検討事項は変わりますが、共通的な成功のＫｅｙＰointが存在すると考えます。

ＩＴ要件の例

①アウトソーシングの見直し

③既存システムのリプレイス

④場所に依存しない経営情報の閲覧

②新規システム構築

⑤災害対策としての持たないシステム

達成すべきテーマ

A.コスト削減

B.簡単な拡張

C.素早い立上げ

D.利便性の向上

2,サービサーとの最適な契約条件獲得のための可視化

成功のための重要KeyPoint

1, 業務＆データのクラウド化可否整理

4.サービス仕様（品質・拡張性・カスタマイズ性、迅速性など）の見極め

5.サービサーの事業継続性見極め

3. クラウド化後の費用算出根拠の可視化

2. クラウド検討の進め方 #3 クラウド化のための重要検討Point2

12

前述の課題の大部分は現在のアウトソーシングと変わりません。課題解決および、『クラウド』のメリットを最大限に享受するためにも、適応業務を選定するとともに、クラウド化後のサービスレベル・課金体系の可視化が重要と考えます。

施策１

①クラウド化後の費用体系の「可視化」

②クラウド化後のサービルレベルの「可視化」

①次項のアプリケーションマップ内でクラウドに向いている業務についてはパブリッククラウドを検討

パブリックプライベート

ＩaaS PaaS SaaS ＩaaS PaaS SaaS

迅速性速速最速やや速

やや速

やや速

サービスレベル合意の難しさ

難難難難難難

運用の難しさ（通常）

易易易同やや易

やや易

運用の難しさ（緊急対応の早さ）

難難最難同やや易

やや易

性能確保の難しさ難難最難同同同

セキュリティ確保の難しさ

難難難同同同

他ベンダへの移行の難しさ

難最難最難難難難

コンプライアンスの確保の難しさ

最難最難最難やや易-難

やや易-難

やや易-難

ガバナンスの難しさ難難難難難難

※自社運用時と比べ「難」「同」「易」で分類

提供形態により、課題に差がある

施策2

現行のアウトソーシングの契約適正化手段として、プライベートクラウドを検討

契約適正化のための必頇要件

2. クラウド検討の進め方 #4 クラウド向きの業務アプリケーション

13

販売管理

業務系

情報系

生産管理

業務系

情報系

在庫管理

業務系

情報系

物流管理

業務系

情報系

調達・購買管理

業務系

情報系

SCM

業務系

情報系

人事・給不財務・会計知識共有グループウェア

セキュリティ

顧客管理

業務系

情報系

パブリッククラウド向け

Webサイト構築・運用

営業支援

情報系

経営層向け意志決定

情報系データの機密性

高低

システムの

位置付け

プロトタイプ的試験導入的（戦略性大）

視点1 データ、システムの位置付け視点2 対象アプリケーション領域

2. クラウド検討の進め方 #5サービサーとの最適な契約条件獲得のための可視化

14

クラウドを検討するためには、要件の整理はもちろんですが、「クラウドベンダから最適な契約条件を得るための」可視化が必頇となります。

2. 機能要件整理

1.クラウド化のための可視化

3.運用要件整理

6.サービサーの選択

5.クラウド化範囲/提供形態の決定

クラウド化およびベンダ交渉のため、必要かつ最小範囲での可視化を行います。

クラウド化の要件を整理します。

クラウド化後の各種運用業務がどうなるか、フロー、役割分担を整理します。

上記結果を踏まえ、クラウド化可能範囲を決定します。

ベンダ交渉、コストシミュレーションにより、最終的なクラウド化範囲とクラウド化後の役割分担を確定します。

4.リスクの棚卸・評価クラウド化によるリスクを「リスク要素」の観点から整理します。


15

可視化のためには、様々な関係者保持する大量の情報を整理する必要があります。弊社では、『クラウド』ベンダに対して最適な契約条件を勝ち取るために、必要かつ最低限の情報収集を行うノウハウを有します。

インフラ関連費

SW保守費

SW償却費

HW保守費

HW償却費

データセンター等設備費

ＮＷ回線利用費

システム運営費

アプリケーション保守運用費

インフラ運用・監視費

ヘルプデスク運用費

ＮＷ運用費

その他

消耗品費用

コスト構造共通的なリスク要素

品質要件（安定稼働）

業務継続性

秘密保持/セキュリティ

コンプライアンス

性能

版権・権利

契約条件

Point1クラウド検討のため、現在の何を

可視化すべきか？

Point2クラウドi移行後、何の可視化が達成されているべきか？


16

機器情報基本機器名

型番

S/N

ベンダ名

契約番号

調達金額

資産区分

調達形態（新規・追加）

導入日

機器種別（SV,DISK,周辺機器など）

OS種別

OS版数

保守情報契約者（ベンダ、ユーザ）

保守ベンダ名

更新日

更新期間

保守価格

支払方法(年払、月払など）

中途解約金

リース情報リース・ステータス（基本、再リース）

基本リース開始日

基本リース終了日

再リース更新期日

基本リース料

再リース料


中途解約金

Config情報 Cpu数

Memory

ディスク容量

増設IF

利用情報ＣＰＵ使用量

ディスク使用量

メモリ使用量

ピーク特性（一定期間の利用率推移）

SW情報基本ＳＷ名称

購入先ベンダ

ライセンス番号

ライセンス数

製造ベンダ

契約番号

資産区分

調達形態（新規・追加）

導入日

保守情報契約者（ベンダ、ユーザ）

保守ベンダ名

更新日

更新期間

保守価格


中途解約金

導入先情報導入先HW

導入ライセンス数

契約条件契約条件期間延長協議開始時期

期間延長契約締結期限

再委託条項

機密保持条項

品質違背時のペナルティ

責任の範囲

損害賠償限度額

任意解約金

任意解約申し入れ期限

終了、解約後の措置

サービス提供先

監査

料金変更

終了後のＳＷ使用権＆保守継続権

サービスの一時停止：事前通知

トラブル等の処理

事故対応

情報の可視化

運用情報インフラ運用ベンダ名

契約番号

開始日

期間

中途解約金

契約金額


支払履歴

体制

提供サービス内容

利用ツール

ドキュメント整備状況

アプリ運用ベンダ名

契約番号

開始日

期間

中途解約金

契約金額

工数・依頼件数


支払履歴

体制

ＮＷ運用ベンダ名

契約番号

開始日

期間

中途解約金

契約金額


支払履歴

体制

提供サービス内容

問合せ件数

ヘルプデスクベンダ名

契約番号

開始日

期間

中途解約金

契約金額


支払履歴

体制

インシデント数

問合せ内容

アプリ情報基本情報アプリケ－ション名

利用部門

開発ベンダ

保守ベンダ

規模

導入サーバ

運用時間

ピーク情報

可視化対象には様々な項目があります。以下の全ての項目について、移行前、移行後における可視化を検討するのではなく、『①クラウド化のためのベンダ交渉』と『②クラウド化後に達成すべき可視化」にPointをおき、必要な範囲での情報収集が効率的と考えます。

移行前後でこれら全ての可視化を目的にするのではなく、「クラウド化」のために必要な項目の可視化から着手する。

2. クラウド検討の進め方 #6クラウド化後の費用算出根拠の可視化

17

前述の可視化データを元に、サービサーと交渉の上、新サービスにおけるコスト構造を可視化します。本可視化により、真の「計測可能なデータによる」「利用量に基づく」料金体系の土台ができあがります。

※現行の自社資産をサービサーに売却し、サービサー資産としてクラウド提供を受けるケースでの効果的な可視化項目の例となります。

3. クラウド検討におけるKVHの強み

18

４．実績の中でのコスト削減等の成功事例、ミッション達成のベスト・プラクティスを保有

１．ベンダーサイドでの豊富な営業・経験をもとにしたスキル、ノウハウ保有

２．各種ベンダー情報（特性/行動パターン/コスト構造/価格動向/契約条件/実績/評判)の保有

一般的なコンサルティングでは、専門知識を持って、外部から客観的に業務を観察し現状を認識、問題点を指摘するとともに原因を分析し対策案を示す形ですが、弊社では、対策案を作成後も豊富な実経験・ノウハウをもとにお客様社員へのスキルトランスァー等も実施しながら、お客様とタッグを組み現場主義で対策を実行致します。

一般的コンサルティングではなく、「プロフェッショナルサービス」をご提供

３. ユーザサイドでの豊富システム運営経験をもとにしたスキル、ノウハウの保有

5．クラウドベンダとの交渉、クラウド化後の可視化に向け、最適なノウハウを保有

補足資料

19

(補足）クラウドの定義<アメリカ国立標準技術研究所（NIST）によるクラウドの定義>

20

クラウドコンピューティングとはモデルであり、構成変更が可能なコンピューティング資源（例としてネットワーク、サービス、ストレージ、アプリケーション、サービス）の共有プールを、オンデマンドなネットワークアクセスで可能にする。それはわずかな管理の手間、もしくはサービスプロバイダとのやりとりによって迅速に準備され、提供される。

このクラウドモデルは可用性を促進するものであり、5つの本質的な性質と、3つのサービスモデル、そして4つの配備モデルから構成される。

■５つの本質的な性格：

１．オンデマンドセルフサービス利用者は自身で、コンピューティングの能力、すなわちサーバの利用時間やネットワークストレージといったものを、サービスプロバイダの人手を介することなく必要に応じて準備できる。

２．幅広いネットワーク経由のアクセスクラウドの能力はネットワーク経由で利用でき、標準的な機構を持つさまざまなシンクライアントやそうでないクライアント（携帯電話やラップトップPC、PDAなど）からアクセスされる。

３．リソースプールクラウドを提供するプロバイダのコンピューティングリソースは、マルチテナントモデルを用いて複数の利用者へ提供すべくプールされている。それは利用者の要求に従って、物理的にあるいは論理的に区別されたリソースをダイナミックに割り当て、あるいは再割り当てする。利用者は提供されているリソースが物理的にどこにあるかは一般に認識せず、関知も管理もしないが、（国や州あるいはデータセンターなどの）抽象化の高いレベルにおいてその位置を特定することができるものもある。リソースの例としては、ストレージ、計算処理、メモリ、ネットワーク帯域幅、そして仮想マシンなどがある。

４．迅速な伸縮性クラウドの能力は迅速に伸縮する。あるときにはそれは自動的に行われ、すばやくスケールアウトし、あるいはスケールインのためにすぐに解放される。利用者にとって、その能力はほとんど無制限であり、いつでも、いくらでも購入できるように準備されているように見える。

５．計測されるサービスクラウドのシステムは自動的に管理され、リソース利用の最適化が行われる。それはいくつかのサービスの種類（ストレージ、計算処理、帯域幅、アクティブなユーザーアカウントなど）に応じた適切な抽象レベルの計測能力による。リソースの利用は監視、管理され、利用されたサービスは顧客とプロバイダーの双方に対して透過的にレポートが提供される。


21



■３つのサービスモデル：

1.Cloud Software as a Service (SaaS).クラウドの能力は、クラウドインフラストラクチャの上で実行されるアプリケーションとして利用者に提供される。アプリケーションは、Webブラウザのようなシンクライアントインターフェイスを通じて、さまざまなクライアントデバイスからアクセスできる。利用者は、ユーザーに特化したアプリケーションの設定以外は、クラウドインフラストラクチャであるネットワークやサーバ、OS、ストレージあるいはそれぞれのアプリケーションの能力について管理することはない。

２．Cloud Platform as a Service (PaaS).クラウドの能力として提供されるのは、プログラミング言語やツールによって開発、もしくは取得したアプリケーションを、クラウド上でデプロイすることである。利用者はクラウドインフラストラクチャとしてのネットワークやサーバ、OS、ストレージなどを管理しないが、アプリケーションのデプロイもしくはアプリケーションをホスティングする環境の構成を制御することはできる。

３．Cloud Infrastructure as a Service (IaaS).クラウドの能力として提供されるのは、利用者がデプロイし適切にソフトウェアを実行するための処理能力、ストレージ、ネットワークそのほかの基本的なコンピューティングリソースの事前準備などであり、OSやアプリケーションなども含むことがある。利用者はクラウドインフラストラクチャを管理しないが、OS、ストレージ、デプロイされたアプリケーションなどの制御や、限定された範囲のネットワークコンポーント（ファイアウォールなど）の制御が可能。


22



■４つの配備（デプロイメント）モデル：

１，プライベートクラウドクラウドインフラストラクチャーは単独の組織によって運用される。その組織、あるいはサードパーティによって管理され、オンプレミスもしくはオフプレミスとして設置される。

２．コミュニティクラウドクラウドインフラストラクチャーはいくつかの組織によって共有され、同じ意識（ミッション、セキュリティ、要件、ポリシー、コンプライアンス）を持つコミュニティをサポートする。その組織、あるいはサードパーティによって管理され、オンプレミスもしくはオフプレミスとして設置される。

３．パブリッククラウドクラウドインフラストラクチャーは、誰でも、あるいは広い範囲の業種に対して利用可能となる。クラウドサービスを販売する組織によって所有される。

４．ハイブリッドクラウドクラウドインフラストラクチャーが、2つかそれ以上のクラウド（プライベート、コミュニティ、あるいはパブリック）から構成されるもの。個別の実体を残しつつも、標準もしくは独自技術によるデータやアプリケーションの可搬性（クラウド間のロードバランスなど）によって結合されている。


23



■４つの配備（デプロイメント）モデル：

１，プライベートクラウドクラウドインフラストラクチャーは単独の組織によって運用される。その組織、あるいはサードパーティによって管理され、オンプレミスもしくはオフプレミスとして設置される。

２．コミュニティクラウドクラウドインフラストラクチャーはいくつかの組織によって共有され、同じ意識（ミッション、セキュリティ、要件、ポリシー、コンプライアンス）を持つコミュニティをサポートする。その組織、あるいはサードパーティによって管理され、オンプレミスもしくはオフプレミスとして設置される。

３．パブリッククラウドクラウドインフラストラクチャーは、誰でも、あるいは広い範囲の業種に対して利用可能となる。クラウドサービスを販売する組織によって所有される。

４．ハイブリッドクラウドクラウドインフラストラクチャーが、2つかそれ以上のクラウド（プライベート、コミュニティ、あるいはパブリック）から構成されるもの。個別の実体を残しつつも、標準もしくは独自技術によるデータやアプリケーションの可搬性（クラウド間のロードバランスなど）によって結合されている。

クラウド検討の進め方

Technology