当然ながら、クラウドであっても性能の絶対値を知るためには、従来CPUなどで行ってきたようにベンチマークテストを行えばよい。これがサーバ購入などの話なら説明は終わりになってしまうが、同調査の回答者は「不安・懸念」を表明している。この原因を筆者は、CPUなどのパッケージ製品であれば「SPEC」が策定しているベンチマークプログラムのテストデータを参照すれば性能把握は容易だったが、共有のリソースプールから動的に資源を切り出す形で提供されるクラウド上の仮想資源においては、「理想化された環境下で取得されたベンチマーク結果と同じ性能が常に得られるものと信じてよいものか？」と利用者が懐疑的になっているためだと推測している。

　利用者が抱くこの懐疑は当然かつ正当なものだ。実際に筆者が幾つかテストした際にも、計測時間帯などの要素を変化させることによって数値が変動するケースが見られた。やはり理想を言うなら常時、複数のサンプルを用意してベンチマークを取り続け、長期時系列のパフォーマンスデータを取得することが望ましいが、個々の利用者にそれを求めるのは無理というものだろう。また、そこでどのような調査項目を用意すべきかを個々の利用者（計測者）がバラバラに定義していたのでは簡単には他のデータと比較できず、「絶対値は分かったが、その値が価格性能比で競合と比較してどのような位置にあるのか判断できない」という事態に陥り、そして人々は互いに言葉が通じなくなった、ということになりかねない。そう、またしても課題は「標準」の確立にある。これが本連載第2回「クラウドは本当にコストダウンになるのか」でメトリクス（測定基準）整備の重要性を指摘した理由の1つでもある。

　このメトリクス系標準確立の課題について、本連載第1回「“オレオレクラウド”にはこりごり、クラウドの本質を知る」で紹介した『NIST SP800-145 Definition of Cloud Computing』で、クラウドの本質的特徴としてmeasured service（計量されたサービス：従量課金）を挙げたNISTは、2011年にSP500-292として公開した『NIST Cloud Computing Reference Architecture(Draft)』で、計測機能をアーキテクチャコンポーネントとして重視する方針を打ち出した。また、SP500-293として公開した『US Government Cloud Computing Technology Roadmap Vol1/Rel1.0(Draft)』において、メトリクス定義と実装を2012年から2013年に実現することを要求している。既にお気付きのように、要は現時点で広く標準として広く受け入れられ、クラウドの提供する機能を包括的に定義したメトリクスは存在しないことになる。では利用者は今後2年間、クラウド利用を暗中模索で行わなければならないのか、といえば状況はそこまでひどくない。

　今すぐにでも、おなじみのSPECが策定した「SPECvirt_sc2010」は利用できる。同テストにはSPECweb2005、SPECjAppServer2004、SPECmail2008が含まれており、従来型のアプリケーション利用を想定し、スケールアウト性能測定に重きを置かない利用者向けには十分なテストといえる。また、TPCが策定した「TPC-W」を利用すれば、Web e-Commerceシステムのベンチマークテストも可能だ。さらに、Hadoopなどの分散アプリケーション利用を中心にスコープし、スケールアウト性能測定に重きを置いたテストとして、Yahoo! Researchが公開した「Yahoo! Cloud Serving Benchmark」も利用可能だ。この他、Windows Azureに限定するならMicrosoft ResearchのExtreme Computing Groupが公開している「Benchmarking and Guidance for Windows Azure」も有用だ。当座2年間はこれらのテストフレームワークを利用して性能計測することになるだろう。

　これだけさまざまな先行事例があるのだからメトリクス整備はもっと早くできそうに思える向きもあるかもしれないが、実はこのメトリクス整備に当たっては本連載第4回前編「クラウドはオンプレミスとデータ連携ができる？　どうなる連携コスト」でも触れたように膨大な分量のクラウドタクソノミー整備が欠かせないため、NIST SP500-293の要求するスケジュールは実は大変厳しいものだと筆者は考えている。

　話を戻すと、まずはこれらのテストフレームワークを利用してスナップショットであったとしてもベンチマークテストを行わないことには話が始まらない。とはいえ、本来「不安・懸念」の原因となっているのは、ある瞬間の性能ではなく、時々刻々変化していく性能をリアルタイムに知り、他のサービスと比較する方法の欠如にある。しかし先にも指摘したように、個々の利用者に長期時系列のパフォーマンスデータ取得を要請するのは現実的ではない。既存のテストフレームワークでも、ベンダー独自のフレームワークを利用したデータでもよいから、同一の定義に基づいた複数の事業者のパフォーマンス計測結果、できれば事業者間の比較まで可能なサービスが欲しいところだ。

　このようなサービスについて日本語で提供されている事例を筆者は知らないのだが、クラウドのメトリクス提供を行うサービスは英語圏には存在する。米Compuwareが提供する「Cloud Sleuth」がそれだ。同サービスは同社の「Compuware Gomez」を利用して構築されており、無償でコミュニティー向けに公開されているポータルだ。メトリクス取得対象となっている事業者の数はまだ16社（本稿執筆時点）だが、2010年4月のβ版公開時は6社しか対応していなかったことを考えると順調にサポート対象を増やしているといえるだろう。ただ、Cloud Sleuthは日本にデータセンターを設置している事業者を2つ（AWS：Amazon Web ServicesとIIJ：インターネットイニシアティブ）しかサポートしていないので、国内事業者のパフォーマンス比較を目的とした場合はまだ使いづらいところがある。

　また、このCloud Sleuthのパートナーにも名を連ねている米Cloud Harmonyは、有償だが2009年からの時系列メトリクスを提供している。ただし、これも残念なことに日本にデータセンターを設置している事業者は1つのみ（AWS）のサポートとなっている。国内事業者をも網羅したメトリクス提供サービスの登場が待たれるところだ。当面は、日本の各事業者がIIJのようにCloud Sleuthのパートナーとなり、データを供給しても十分実用に耐えられると考えているのだがどうだろうか？

Cloudsleuth：クラウドパフォーマンスアナライザー画面

Cloud Harmony：ベンチマーク比較例（Amazon EC2 m1.small/us-west1/apac-jp、RackSpace1G）

　少々話が脇道にそれるが、ここで、2011年12月末に実施したクラウド座談会「専門家8人が徹底討論！　クラウドにデータを預けるリスクとメリット」でも軽く言及したPaaSやSaaSといった、より抽象化度の高い提供形態の場合について若干補足しておく。まずPaaSの場合、PaaS提供者が単一の事業者であったとしても、複数のIaaS（もっというとIaaS事業者）を利用してサービスが構成される可能性がある。さらにSaaSは、そういった複数のIaaSにまたがって構築されたPaaSをまた複数組み合わせて実現する可能性がある。現時点ではそこまで複雑なサービスはまだ少ないかもしれないが、将来的には確実にこういった複雑な構成（と複雑なバリューチェーン）のサービスが増えていくだろう。そうなると、そこではガバナンス情報の継承関係だけでなく、メトリクス情報の継承関係もリアルタイムに把握しないと正確なパフォーマンス把握ができないことになる。こういった問題が予見されるため、シンプルでかつ発展性に富んだクラウドタクソノミー定義と柔軟性の高いメトリクスフレームワークを確立するために今後2年間を費やすことは非常に有益な回り道となることが理解いただけると思う。

　パッケージ表面を見るとコンシューマライゼーションが進んでいるように見えるクラウドだが、裏面を見ると加工食品と同等の表示基準に達した情報開示がなされているクラウドサービスは、まだまだ極めて少ない。

健康増進法や食品衛生法、JAS法などによって食品分野では当然になっている表示内容基準がクラウドではまだまだ未整備な状態だと言わざるを得ない。加工食品と同じく、今後はさまざまなIaaS、PaaSなどを利用して構築されたSaaS利用がコンシューマーを巻き込んで広がっていくことを考慮すると、クラウドサービスにおける表示内容の標準確立は非常に重要だと筆者は考える（掲載のパッケージ画像はダミーである。このような商品は実在しない）

　ここまでで応答性能の絶対値を知る方法と、事業者間の比較情報について、現時点で手に入るものと今後どのようになっていくかについて、ざっとした説明ができたと思う。次はサポート品質について検討してみよう。

クラウドのサポート品質を測る

　クラウドにおけるサポート品質とはなんだろうか？　本連載第1回「“オレオレクラウド”にはこりごり、クラウドの本質を知る」で紹介したように、クラウドの本質的特徴の1つにOn-demand self-serviceがある。セルフサービスが本質的特徴である以上、従来型の電話を介したオペレーターによるサポートや顧客オンサイトでのサービスエンジニアによる対応といった考え方は、クラウドにはなじまないことは明白だ。ここで、クラウドにおける、あるべきサポートの姿を検討してみよう。

　まずはサポートの定義を整理しよう。「ISO/IEC20000（ITSMS）」の基となったITIL V2（現行最新版はV3だが、V3でいうService Operationでは取り扱い範囲が広すぎるので意図的にV2のService Supportに基づいて記述）では、サービスサポートを5つのプロセスと1つの機能で構成された概念として定義している。すなわち、

• インシデント管理
• 問題管理
• 構成管理
• 変更管理
• リリース管理

の5プロセスと、

• サービスデスク

の1機能だ。

　本連載第3回「クラウドは安全か？　事業者との責任分界点、注目すべき安全基準とは」で解説したIaaSの責任分界点モデルに基づいて考えるなら、利用者に対してRapid elasticityに切り出された資源とそのバックエンドとなるResource pool、計測系でもあるMeasured Serviceの動作状況をBroad network accessを介して、インタフェース系であるOn-demand Self Serviceが提供するダッシュボードを単一窓口（SPOC：Single Point Of Contact）として管理・操作できるようにすることが、セルフサービスを原則とするクラウドにおけるサービスサポートの姿ということになる。従って、クラウドのサービスサポートとして必要条件を満たさないケースは、

（1）ダッシュボードからセルフサービスで表示・操作できないデータ・機能が存在する

（2）ダッシュボードからの操作に対してシステムがリアルタイムに挙動しない

（3）ダッシュボードにBroad network accessできない

（4）サービスサポート定義を満足したプロセス粒度でダッシュボードが実装されていない

場合となる。念のため付け加えておくと、

（5）ダッシュボードのユーザーエクスペリエンスのレベルが低い

場合も今後は問題視される可能性があるだろう。

　このように整理するとクラウド利用法の教育サービスや、設定代行サービスなどをクラウド事業者にサービスサポートとして期待する向きには少々分が悪いようだ。しかし、本連載第2回「クラウドは本当にコストダウンになるのか」でも指摘したように、クラウドは従来埋没費用化していたICT関連投資を時間費用として計測可能にし、機会費用として利用者がコントロールできる範囲を広げる経営の見える化を促進する効果が期待できるところがミソなのだから、教育サービスや設定代行サービス費用をバンドルして長期的に埋没費用を増やしても意味がないと考えるべきだろう。むしろ、積極的にアンバンドル化を要求し、さまざまな教育サービスや設定代行などのマネージドサービス事業者の市場参入と競争を促進し、多様な選択肢から費用対効果の高いサービス構成を選択した方が得だ。

図版左側が実際のサービス需要、中央がオンプレミスまたはホスティング、右側がクラウドを表す。オンプレミスやホスティングでは保守やマネージドサービスなどの費目で利用の有無にかかわらずサービスサポートコストが固定費として発生する。オンデマンドかつセルフサービスが身上のクラウドでは、ダッシュボードなどからのセルフサービスの範囲を超えるサービスサポートはアンバンドルし、クラウド利用初期の不慣れな時期は従量制でマネージドサービスを利用する。また、同じ時期に思い切った教育支出を行いセルフサービス利用力を身に付け、運用が軌道に乗った時期にマネージドサービスを解約（Rapid elasticity要件を踏まえれば即時解約できて当然）してしまえば従来と比較して大幅なTOC改善が可能になる。クラウドの場合、あらゆるインシデント、問題、構成、変更、リリース管理履歴は継続的に記録されているので、マネージドサービス事業者の切り替えも容易になるだろう

　こう書くと、「クラウドに関する情報がまだまだ十分に流通していないし、サービスの選択肢も限られているではないか」といったお叱りを頂きそうだが、状況は徐々に改善しつつある。例えば、先にも挙げたNIST SP500-292では、NIST SP800-145でIaaS、PaaS、SaaSといったサービス階層を基準にした分類方法をCloud Consumer、Cloud Auditor、Cloud Provider、Cloud Broker、Cloud Carrierというアクターを基準にした分類方法に変更して、各事業者の位置付けをはっきりさせている。実はこの定義モデル拡張があったために一部でNISTの新しい資料に対し分かりにくく一貫性がないといった批判が出ているが、よく読めば実際にはNISTのConceptual Reference Modelは正常に進化し洗練の度を増していると理解できる。この点について、説明すると長くなるので別途機会を設けたい。

NIST SP500-292掲載のConceptual Reference Modelを筆者が翻訳した。できればオフィシャルな翻訳をしかるべき機関で行い、用語統一を図ってもらいたいと考えている。Gartner Predicts 2012でも指摘されているが、今後クラウドオーディターは信頼性を測る上で非常に重要な存在になるだろう。先に本文で述べたように食品衛生法に基づく原材料表示のような、目立たないが大切な機能になっていくはずだ。注目が集まっているクラウドブローカーの機能として販売代理（原文ではService Intermediation）が置かれているのは面白い。一般にはディスインターメディエーション（中抜き）現象が起こって卸売、代理店、小売などの中間事業者がいらなくなる現象が起こっているが、クラウドではこれから中間事業者が勃興すると想定されている。サービスアービトラジについては既にAWSがスポットインスタンスを提供して先鞭（せんべん）をつけている。クラウド事業者自身の設備稼働率確保（と機会損失回避）のために、一定以上の規模になるとクラウド資源も原油や穀物のように商品市場が形成されていくだろう。クラウドの先物取引（例えば、北米ではクリスマス商戦期にインスタンス価格が高騰するなど）といった考え方も出てくるはずだ

　肝心のマネージドサービスなどについてはNIST SP500-292で新たに定義されたアクター群の中にCloud Broker（クラウドブローカー）という役割が定義されている。このCloud Brokerこそクラウド利用が主流になった時代におけるマネージドサービス事業者やSIerの立ち位置になるだろう。ただし、筆者は従来型の手工業的アプローチでのマネージドサービスやSI（そういった需要も極めて大規模なプロジェクトでは残るだろうが）ではなく、BPMN（Business Process Modeling Notation）を利用して利用者のBusiness Processをダッシュボード上でモデリングし、DevOpsを超えてNoOpsで実現する一種のPaaS事業者として立ち現われてくるのではないかと予測している。これはかつてアセンブリーラインによる大量生産が実現したのに匹敵するICT産業における生産・運用方式革命となる可能性がある。

IaaS基盤は現在のところ、利用者向けにはクラウド運用サイクルと構成・変更・リリース管理サイクル、インシデント・問題管理サイクルの一部を賄うダッシュボードしか提供できていない場合が大半だが、将来的には監査や開発も含めて全てカバーするようになるだろう。このような統合ライフサイクル管理を提供する主体としてクラウドブローカーという役割は非常に有望だと考える（ここに掲載した5ライフサイクルリンケージモデルは筆者が検討中のものであり、今後、思わぬ見落としや間違いを発見して筆者が書き換えをしてしまうかもしれないので、こんな考え方もあるという程度に覚えておいていただきたい）

　実際、自社サービス内に閉じているがAWS Elastic Beanstalkはその萌芽ともいえるサービスだし、2011年12月、NTTソフトウェアがOSSとして公開したvHutも、振り返れば、クラウドブローカーの原型の1つだといえる可能性を持っている。この他にもThe ORYX Projectなど、この分野の将来を担いそうな候補技術は豊富だ。これらのサービスや技術を利用したクラウドブローカーが数多く市場に参入してくるだろう。

　ここまで見てきた通り、クラウドのサービスサポートは先に検討したmeasured serviceを支える計測機能と比較を客観的に行うためのメトリクス整備を足掛かりに、優秀なインタフェースを装備したダッシュボードによって提供されるのが本筋だといえる。このクラウドにおけるサポートの品質を客観的かつ定量的に観測するための枠組みとしてNIST SP500-293では高品質のサービスレベル契約のための技術仕様を2012年中に取りまとめることを要求している。もちろん、関連するメトリクス定義と実装が2013年までかかる予定なので、定期的に更新することを要求することも忘れていない。この見切り発車ともいえるSLA仕様策定スケジュールが定められた背景は利用者視点（米連邦政府自身ビッグカスタマー）からリスク管理上、欠かすことができないためだろう。こういったところからもNISTによる一連のクラウド関連文書は現場の要求に目配りした良くできた資料だということができる。

　さて、第4回後編「クラウドが直面する各国の法制度　～パトリオット法の影響とは？」の最後に、第5回ではクレジット課金に当たってのPCI DSS対応のケースについて解説すると書いておきながら、しれっと性能測定とサポートの話を書いているのを読まれて、約束と違うとお怒りの方もいらっしゃるかもしれない。実は第6回で予定している話題とPCI DSSの話題の相性が良いことと、これらの話題について解説する前にクラウドにおける性能測定とサポートの話をしておかないと第6回で理解しにくい部分が出てくると判断したことを理由に、掲載する順番を無断で入れ替えさせていただいた。最後となって恐縮だがこの場での説明を持って了解願いたい。

川田大輔（かわだ だいすけ）

Cloud Architect、クラウド設計屋。18年に渡り大手ソフトウェア／ハードウェアメーカーでのマーケティング、ITベンチャーでの事業開発、技術開発、技術投資業務を経験し、2009年より現職。技術からマーケティングまで包括したICT関連事業の立ち上げを専門にしている。近作はNIST準拠のOSS Cloud Architecture、copse。

本稿での記述内容は個人の見解であり、その責任は全て筆者個人に帰するもので、所属する組織を代表する意見ではありません。