検索
特集/連載

【徹底比較】安心・安全なクラウドはどれだ? 35のIaaSを比較クラウドガバナンス現在進行形【比較編・2012年夏】

クラウドの本質的特徴とガバナンス要求を基に、35のIaaSを比較した。第三者認証の対応状況や約款掲示の有無、そしてハイブリッドクラウド化をしてリスク分散が可能な事業者とは。比較表はダウンロードできる。

PC用表示 関連情報
Share
Tweet
LINE
Hatena

IaaS比較表をダウンロード

NISTのクラウド定義とガバナンス要求を基に、35のIaaSを徹底検証しました。比較表をExcelファイルで提供しています。「35のIaaSクラウドをガバナンス要求で徹底比較」でダウンロードしてください。


おわびと訂正

本記事の比較表「35のIaaSクラウドをガバナンス要求で徹底比較」を以下のように訂正しました。ご迷惑をお掛けしました。

【訂正前⇒訂正後】

マイクロソフト

Windows Azure Platform ⇒ Windows Azure

米国法 ⇒ 日本法(※)輸出管理規制について米国法/その他が適用される

SAS70 ⇒ SSAE 16/ISAE 3402

日本ユニシス

ユニアデックス ⇒ 日本ユニシス

BIGLOBEクラウドホスティング

IaaS管理ツールによって制御できない ⇒ IaaS管理ツールによって制御できる

仕様開示または互換性確保手段が提供されていない ⇒ 仕様開示または互換性確保手段が提供されている

日本システムウエア

日本システムソフトウェア ⇒ 日本システムウエア


 連載「クラウドガバナンス現在進行形」ではさまざまな角度からクラウドコンピューティング、特にIaaS(Infrastructure as a Service)について検討してきた。ほぼ1年前、第1回の記事「“オレオレクラウド”にはこりごり、クラウドの本質を知る」で38サービスを比較た際には、日本国内で提供され実質的にNIST定義を満足していると評価できる真のクラウドサービスは「Amazon Web Services」(AWS)と「Windows Azure」そして富士通「Fujitsu Global Cloud Platform FGCP/S5」の3つしかなかったが、現在はどうなっているだろう?

 また、2012年6月7日に富士通館林データセンターでの電源障害、同6月20日にファーストサーバのデータ喪失(関連記事:バックアップは誰の責任? ファーストサーバ事件が残した教訓)、同6月28日と7月10日にセールスフォースの障害などなど、ここ数カ月の間に起きた障害だけでも本が書けてしまうほどいろいろな問題が顕在化している。こんなときこそ基本に立ち返り、ガバナンス要件をしっかり押さえていざ障害に直面したときにうろたえずに済むようにしておきたい。この観点でのチェックポイントは、精密に記述された約款の整備状況や、約款に記載された条件の通りにサービスが提供されているかをチェックするためのログ提供やSLA定義がなされているか、さらにログやSLAの非改ざん性を保障するための仕組みが整備されているか、といった点が重要だ。

 もちろん、絶対に障害が起きないサービスは実現不可能だ(関連記事:クラウドは安全か? 事業者との責任分界点、注目すべき安全基準とは)。冗長化など施していても障害は起こり得る。それでも高可用性やデータ生残性を求めるなら複数のデータセンターを利用するなどして並列化した信頼度確保が必要になるし、その行き着くところはハイブリッドクラウド化によるリスク分散となる。ハイブリッド実装を実現するためには、ダッシュボードからのOn-demand self-service操作ができるだけでは足りない。APIによる操作など、より自動化に適した機能実装が必要だ。うるさいことを言うと、今後はインスタンスのストップ/ゴーなどの単純なAPIだけでなく、より高度なAPI公開もチェックしたいところだ。

 ガバナンス全般の観点からすると、情報セキュリティマネジメント体制の整備状況や財務会計基準の整備状況、さらにはCommunity resilience(関連記事:クラウドが普及した市場で、生き残るエンジニアと組織)を実践して情報やノウハウの共有やオープンな組織効率の追求に取り組んでいるかも押さえておきたい。

クラウド利用によって起こる本質的な変化

 何度も繰り返している話で恐縮だが、クラウド化とは仮想化を指すわけではない。本質的にクラウド化とはICTの見える化・測る化を伴うモジュラアーキテクチャ化であり、言い換えると利用者を無自覚にITIL化された市場に連れ出す舞台装置だ。


図1 クラウドの本質的特徴と運用サイクル《クリックで拡大》

 NISTが定義したクラウドの本質的特徴は実によくできていて、この定義に従った実装を利用するだけでSLM(Service Level Management)が見える化されてしまう。実際、このサイクルをより簡単に、精密に回すことを狙って、以前にも「エンドユーザーによるクラウド設備実査要求は百害あって一利なし」で紹介したNewvemなどの分析機能やCloudHarmonyなどのメトリクス機能を提供する事業者が世界では増えてきている。将来的にはクラウド運用サイクルだけでなく、あらゆるPDCAサイクルが5ライフサイクルリンケージモデル(図1右下)で提示したように相互に影響を与えるエコシステムを形成するだろう(5ライフサイクルリンケージモデルの関連記事:クラウドの応答性能とサポート品質を客観的に比較するには)。

ガバナンスとは、曖昧さを閉じ込める枠組み

 Open Cloud Campus クラウドセキュリティ分科会で吉井和明弁護士が発表していたように、ファーストサーバの事例1つを取っても見える化されていない部分についてのリスクの闇は深い(関連記事:バックアップは誰の責任? ファーストサーバ事件が残した教訓)。ガバナンスとは極論すると、曖昧な部分を減らし、曖昧な部分が残るなら範囲を決めて解決方法をあらかじめ決めてしまう取り組みだ(関連記事:エンドユーザーによるクラウド設備実査要求は百害あって一利なし)。もちろん、その考え方の根底には、エコシステム全体の崩壊を防ぐために、リスクを封じ込める思想がある。その第一歩は見える化と測る化となる。先に指摘したようにNIST定義はSLMライフサイクル=クラウド運用サイクルを見える化・測る化してくれる点がミソだ。外部監査などによって付与される第三者認証などの取り組みは、事業者と利用者の間に公平な第三者を介在させることで、見える化・測る化を可能にする。とは言っても、競争上競合相手にまで見せたくはないといった微妙な心理が働く情報を抽象化しつつ、非改ざん性を担保した形て開示するクッションとして機能する点にも意味がある。もちろんPCI DSSのように定量的な基準を提供してくれる点の重要さも忘れてはいけない。

 第三者認証を整備することには、事業者相互の不信頼が連鎖して垂直統合による閉じた市場が乱立することを防ぐ狙いもある。閉じた市場を志向する向きもあるかもしれないが、実は開かれた市場を形成することで流動性を担保すると、ゲーム理論でいう協調戦略が裏切り戦略より有利になることが既に知られている(参考:The outbreak of cooperation among success-driven individuals under noisy conditions)。裏切り戦略を当然のこととして学んできたMBAホルダーなどにはぜひ最新のゲーム理論の研究成果をご一読願いたい。

調査に当たっての項目割り出し

 今回の調査ではNIST定義とCSA Cloud Security Modelの拡張版を、ITILサービスデザインの管理項目分類を意識しつつ、情報セキュリティマネジメント認証取得状況など外部から確認可能な検証手段にマッピングして、IaaS事業者の比較条件を決定した。


図2 クラウドの枠組み《クリックで拡大》

 こうすることで、NIST定義がSLMにかかわる問題の自動化を狙っていること、その外部に広がる他の管理項目との関係を整理できること、何度か紹介してきたCloud Security ModelのスコープがNIST定義やITILなどより広いことが理解いただけると思う。

リアルクラウドとオレオレクラウドを仕分ける

 まず、割り出した調査項目一覧を全てマッピングしてクラウドと呼べるものとホスティングと呼ぶべきものを仕分ける条件として整理してみた。


図3 クラウド評価項目《クリックで拡大》

 利用者へのブロードバンドアクセスやオンデマンドセルフサービスが提供されていないなら、それは間違いなくマネージドホスティングと呼ぶべきサービスだ。一定限度のブロードバンドアクセスとオンデマンドセルフサービスが提供されているならセルフサービスホスティングとでも呼ぶべきだろう。プライベート、コミュニティー、パブリックの各デプロイメントモデルを名乗るならクラウドの本質的特徴を備えていなければならないし、ハイブリッドクラウドまで視野に入れるならAPI提供などさらに一段高い実装水準が必要だ。

 ガバナンスの観点から見て信頼性の高いサービスを割り出すことが目的なので、ホスティングであろうがクラウドであろうが、ガバナンス関連の要求については非対応可とする項目は置かなかった。また、準拠法開示は約款掲載していれば必ずできることなので、約款開示を必須とした結果、必須対応項目となっている。

2012年夏のクラウドガバナンス比較表

 先の条件マップと縦横が異なる体裁で申し訳ないが、これらの要素を35のIaaSを名乗るサービスについて検証したのが下の表だ。


表 2012年夏のクラウドガバナンス比較表

IaaS比較表をダウンロード

NISTのクラウド定義とガバナンス要求を基に、35のIaaSを徹底検証しました。比較表をExcelファイルで提供しています。「35のIaaSクラウドをガバナンス要求で徹底比較」でダウンロードしてください。


 現時点ではβ版しか公開されていないGoogle Cloud Platformを参考に追加し、比較のためにクラウドではないと提供事業者自身が定義している、さくらインターネットのVPS(仮想専用サーバ)を追加したため、記載サービスは全部で37ある。

 クラウドの本質的特徴についてBroad network accessできる(申し込みから利用までネット上の手続きだけでできる)ことを最初の条件とし、ダッシュボードによる制御の実現状況を見ることでOn-demand self-serviceが実現されているかどうかに着目した。構造上Rapid elasticityとResource poolは、Rapid elasticityが可能であれば実現できている傍証となるので2つで1つの評価とした。Measured Serviceは完全従量課金であれば実現できていることの証拠とできるが、ガバナンス上の要件へのつながりを考慮してチェック項目を多めに取っている。

 ガバナンス条件で重視した点はSLA(Service Level Agreement)が定義されていることと、SLM検証可能性を担保するログ出力可否または第三者認証の対応状況、それから約款掲示の有無とその定義内容だ。見たところクラウドを名乗る事業者には大手が多く、財務基盤などの面からのチェックよりも、基本的なサービス提供ルールの定義とその運用チェックを優先するべきと判断した。

サービス比較

 NIST定義を満足したクラウドサービスは9あった。しかもうち7サービスはAPIを整備しハイブリッドクラウドを利用することまで視界に入っている1年前の3から比べると質、量ともに飛躍的に増えていると評価できる。しかし、セルフサービスホスティングと呼ぶべきサービスが14あり、マネージドホスティングと呼ぶべきサービスも12あった。

 セルフサービスホスティングに分類すべきサービスには、もうひと押しするとIaaSと呼べそうなものが散見される。申し訳ないが、マネージドホスティングに分類すべきサービスには掛けるべき言葉がない。筆者も時折、IaaSはレッドオーシャンビジネスだからリスクが高いという意見を耳にすることがあるが、IaaSは拡大しているレッドオーシャンだ。縮小し干上がりつつあるレッドオーシャンであるなら、なるほどこれは参入するべきではないという意見に賛成できる。しかし成長市場として市井の耳目を引いてしまった分野がいつまでもブルーオーシャンであるわけがない。早晩、競合相手と肩を並べて、事業を磨かずには成長機会が得られないレッドオーシャンになるのは自明だ。問題は市場が成長しているか否かだ。

 20%以上の年間成長率が予測されるIaaSでの競争から離脱してPaaS(Platform as a Service)市場に目を向ける事業者が多いようだが、IaaSの本質が理解できていないが故に失敗した事業者がPaaSを成功させるのはさらに難しい。セルフサービスホスティングに分類すべきサービスを提供している各事業者には各サービスをぜひとも真のIaaSに進化させてほしいと思う。

 ところでこの表を作成していて気付いたのだが、ガバナンスの観点から気になる傾向が見受けられた。各種の第三者認証やログ提供機能を備えていても、どのような条件がそろったときに、どのような扱いをされるのかを決定するルールである約款・規約が掲示されていなければ安心して利用することはできない。第三者認証が審判だとすると約款・規約はルールブックだ。いくらクラウドが約款掲示義務を課されていないと言ってもルールブックが公開されていないゲームは不公平すぎる。本調査では約款掲載していない、または確認できなかった事業者を低く評価している。約款掲載していない事業者にはぜひとも改善を望みたい。

 日本国内でのCommunity Resilienceに限ってだが、さまざまなユーザー会や研究会を傘下に収めるOpen Cloud Campus(筆者もクラウドセキュリティ分科会の運営をお手伝いしている)や早稲田大学 名誉教授の丸山 不二夫先生が主催されているクラウド研究会(2012年8月9日にも第8回「エンタープライズ・クラウドの現在」が開催された)、クラウド事業者やベンダー、ユーザー会が集まって情報交換をしている「クラウドごった煮」(2012年9月1日に第6回が開催予定)などで積極的に交流を図っている事業者も11を数え、コードリポジトリ公開などを通して開発状況の見える化などに取り組んでいる事業者も5社あった。筆者は、これらの人材・組織効率ドメインに積極的な事業者がこぞって上位にランクインしているのは偶然ではないと考えている。

ホスティング市場とクラウド市場のすみ分け

 さて、以前から断っているように筆者はオンプレミスやホスティング廃絶派ではない。適材適所で使い分ければよいと考えている。先にも述べたように将来的にはクラウド自体がエコシステムを形成し、オンネットの経済が成長するだろうが、これまでのところメインフレームが絶滅していないようにオンプレミスやホスティングも当面は絶滅しないはずだ。

 JPIXが公開しているデータを見ると1日24時間のうちでもシステム繁閑の差は3倍に達する。これは10年単位の長期時系列でみても同じだ(図4)。


図4 システム繁閑の差《クリックで拡大》

 長期データを見ると季節変動によって一日のトランザクション変動を上回るバーストトラフィックも発生していることが分かる。これらのトランザクション量はざっと、

ベーストラフィック:ピークトラフィック:バーストトラフィック=1:2:1

の関係が成り立っていることが見て取れる。トラフィック量と計算量は通常は正相関するのでオンプレミスやホスティングなどの変動に弱いサーバをベーストラフィックに充て、ピークトラフィックやバーストトラフィックに変動に強いIaaSを充てるとコスト競争上有利だろう。とするとオンプレミスやホスティングなどの市場シェアは25〜30%程度に落ち着くと予測できる。以前から指摘しているように、縮小しているITCサービス市場全体の中でレッドオーシャンだといわれても成長しているクラウド市場、中でもクラウドの基礎となりクラウドの本質的特徴が最も色濃く表れるIssS市場で生き残ることは、今後のPaaSやSaaS市場で求められるより高度なガバナンス実現の足掛かりとなる。また、AWSなどのインスタンス単価はオンプレミスの時間当たり総所有コストと等価だ。単価が同じなら不稼働時にコスト負担が不要なIaaSのROIが有利になるのは自明だ。契約期間縛りがなく時間当たりでの契約が結べないホスティングサービス利用は、ベーストラフィック向けのみに抑え込まないと不合理となる。

 米IDCがAWSを利用している大手11社を対象に行った調査によると5年間で626%のROI改善がなされたという。仮想化したホスティングサービスやオンプレミスシステムでこれほどのROI改善を望むのは不可能だ。競争力を維持するためにはクラウドエコシステムを前提としたモジュラアーキテクチャへの転換を迫られていると認識するべきだろう。

川田大輔(かわだ だいすけ)

画像

外資系ITベンダー数社を経てITベンチャー創業に参画し取締役CTOを務めた後、コンテンツ事業会社に移り技術戦略を担当。事業開発、技術開発および技術投資業務を経験。2009年より電気通信事業者(旧区分一種)に勤務し、SOAに対応しNIST定義準拠したOSSクラウドアーキテクチャ開発に取り組み、2011年5月に技術公開。他に個人としてガバナンス観点からクラウドアーキテクチャを整理しメトリクス整備を目指す「atoll project」を主宰。本稿での記述内容は個人の見解であり、その責任は全て筆者個人に帰するもので、所属する組織を代表する意見ではありません。


Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る