クラウドに要求される計算や記憶、伝送能力量は時々刻々と変化していく。この確率変化を柔軟に受け止める能力がクラウドには欠かせない。オンラインサインアップを許容し、セルフサービスダッシュボードを提供し、オンデマンドサービス化すると、いつ新しい利用者がどの程度の負荷をシステムに課すか提供事業者にはコントロールできなくなる。

図表1　《クリックで拡大》

　通信事業者は20世紀初頭から、通信エンジニアにはおなじみのアーラン方程式に代表される待ち行列理論を利用していた。現代のクラウドにおいては、かつての電話サービスの比ではないほど多くの動的に変化する要素を同時に把握し、適切に操作することで、応答性能、可用性水準などを確保しつつ事業採算に乗せし、資源稼働率をコントロールしつつ減増移設のタイミングを決定している。Rapid elasticity（応答性能）要件を数日以内としている場合には不要だろうが、即時応答を標準としているサービスの場合、これらの処理は大部分自動化されている。資源抽象化・管理層でのオーケストレーション能力の優劣、せんじ詰めれば採用アルゴリズムの優劣によってシステム効率が変化しROIが変化するわけだ。リスクゼロはあり得ないという前提を受け入れた上でリスクを動的にコントロールすることが要求される、と言い換えてもよい。

　資源抽象化・管理層でのオーケストレーション能力の高低と計測可能なシステム挙動範囲の広さと深さは、事業者のROIだけでなく利用者にとってのROIにも大きな影響を与える。AWS Elastic Beanstalkが先鞭をつけ、ニフティクラウドのCloud Automation βなどが追う、構成・制御の自動化機能が十全に機能するかは、IaaSのMeasured Service実装の良しあしによって決まると言っても過言ではない。Measured Serviceについての考察が浅く、対応が粗雑な事業者は今後の競争で大いに苦しむだろう。

　クラウドの本質的な特徴がもたらす提供事業者にとっての不確実性の増大という基本的な特質が受け入れられない事業者は、（個々のファンダメンタルの問題もあるかもしれないが）定義満足度が低くなっているようだ。

　「事業継続性と運用弾力性に配慮したクラウド リファレンス アーキテクチャ v1.0」でも解説したように、今後のクラウド市場は利用者の事業継続性を高めるために運用弾力性（レジリエンス）が要求される。また運用弾力性を経済的に実現するためには即時動作する相互運用性の確保が欠かせず、互換性担保が重要になる。するとランダムネスとうまく付き合う能力の獲得は必須となる。さらに個々にはランダムに振る舞うさまざまなサービスが相互に接続されると、エコシステム全体は複雑系として振る舞い始める。このとき、Cloud-washing（※）しただけのサービスは事業者自らが苦しむだけでなく、利用者を比較競争劣位に引き込む“わな”となるだろう。

※Cloud-washing：既存の製品やサービスをリブランドして「クラウド」と名乗ること。

ガバナンス成熟度に関する考察

　もう一方、ガバナンス成熟度の高低はエコシステム形成に対する備えがどの程度できているかを表していると言ってよさそうだ。IaaSとは異なるレイヤーのサービスを紹介して恐縮だが、2013年3月29日にNHN Japanは、国際展開とエコシステム形成に積極的なLINEサービスについてSOC2、SOC3、SysTrustを同時取得した。今後、利用者数が1億人を超えるようなサービスが積極的に外部のサービスと連携を図り、エコシステムを形成しようとする際には、SOC3のように広く一般に基準が公開され報告書も開示される保証サービスの利用によって、信頼性の程度を明らかにするとともに、サプライチェーンの信頼性基準を形成していく動きが主流となっていくだろう。

　2013年6月6日に英Guardianが報じたスクープを震源とする米国家安全保障局（NSA） PRISMスキャンダルは、関与したとされる多くの事業者が釈明に追われる事態を招き、関与していない事業者にも「関与していない」との声明発表する動きが出るなど、インターネットサービス全般の信頼が揺らぐ事態に発展している。定量的に観測可能で第三者によって検証可能な信頼性基準の形成と普及は、個々のサービス提供事業者にとっての事業継続性のみならず、市場全体の事業継続性と弾力性確保のためにも必要だ。

　この面では、国内で顕在化した事例として、2012年6月のファーストサーバデータ消失事故時に注目されたSLA100％表記の安易さが思い出される（関連記事：バックアップは誰の責任？　ファーストサーバ事件が残した教訓）。さすがに同事故後はSLA100％を安易に掲げる事業者は見掛けなくなったようだが、代わりにSLO（Service Level Objective＝サービスレベル目標）に安易な数字を掲載する事業者があるようだ。IIJなどが取り組んでいるような定義公開とセットになった利用者によるサービス選択の便を図るためのSLO公開は有益だが、掲げた事業者が実績公開せず、目標未達時のペナルティも負わない無責任な宣伝文句としてのSLO掲載は有害以外の何物でない。有害さの程度を計量できるようになったならばランキングモデルにネガティブ評価パラメータとして取り込みたいくらいだ。筆者は市場の透明性確保に逆行する施策には反対の立場だ。

日本でのCloud-washingの実態

　前回「62のIaaSランキング」で、マネージドホスティングセグメントの解説をした際に軽く触れたCloud-washingの実態についてもう少し掘り下げてみよう。今回は、本調査の結果とインプレスが提供している「レンタルサーバ完全ガイド」掲載のデータを基に、各IaaSのRapid elasticity（従量制で購入可能な資源の迅速で柔軟なプロビジョニング）について比較してみた。

　最低契約期間について比較すると、「62のIaaSランキング」における「ハイブリッドクラウド」「クラウド」および「セルフサービスホスティング」セグメント上位のサービスは最低契約期間が1日以下となっているが、セルフサービスホスティングの大部分はIaaSを名乗っていながら1カ月以上の契約期間を要求しており、一般的なレンタルサーバと大差ない契約条件を提示している。「レンタルサーバ完全ガイド」によると、レンタルサーバでは契約期間が明示されていないサービスはごく少数にとどまっているが、「マネージドホスティング」セグメントに分類された大多数のサービスはサイト上で契約期間を明示しておらず不明瞭極まりない。

図表2　最低契約期間の比較。「レンタルサーバ完全ガイド」に掲載されているレンタルサーバ（左）、「62のIaas比較」に掲載されているIaaSセグメント（右）《クリックで拡大》

　次に申し込みから利用開始までの時間分布を比較してみた。「レンタルサーバ完全ガイド」では、レンタルサーバでは即時～1時間以内に利用開始が可能なサービスは14.3％ににとどまるが、「62のIaaSランキング」掲載のIaaSでは48.4％のサービスが即時～1時間以内に利用開始が可能だった。しかしセグメントごとに見ていくとマネージドホスティングに分類されるサービスでは即時～1時間以内に利用可能なサービスが1つも見当たらず、わずかに同日内に利用可能としているサービスがみられるだけだ。

図表3　レンタルサーバでの申し込みからサービス利用開始までの時間分布《クリックで拡大》

図表4　IaaSでの申し込みからサービス利用開始までの時間分布（全体／セグメント別）《クリックで拡大》

　Rapid elasticity要件に関する限り、マネージドホスティングにセグメントされたサービスはレンタルサーバサービスの分布平均にも達していないと結論付けられる。

　レンタルサーバサービスのガバナンススコアが分からないので軽々しく判断することはできないが、Rapid elasticity要件を見る限り、「62のIaaSランキング」でセルフサービスホスティング中位以下とマネージドホスティングにセグメントされたサービスは、その実態からしてレンタルサーバと比較するのが適切であるようだ。

　ガバナンス成熟度とクラウド定義満足度に基づく日本のIaaS分布を見る限り、インターネットイニシアティブ（IIJ）などの例外はあるものの、個々のサービスのガバナンス成熟度とクラウド定義満足度は相関している。

図表5　参入事業者業態とカテゴリ分類付き定義点・成熟度点サービス散布図《クリックで拡大》

　この相関が見掛けにすぎないなら杞憂となるが、事実であった場合はセルフサービスホスティング中位以下が提供する“IaaS”とレンタルサーバには何ら違いが存在しないという結論にたどりつく。米TechTargetのSearchCloudStorageの定義をもう一度振り返ってみよう。

Cloud-washing=クラウド洗浄とはベンダーが古い製品やサービスに流行語としての”クラウド”を意図的に関連付けリブランドすることで時には欺瞞の試みでもある――引用：Cloud-washing

　筆者には遠い海外での問題とは思えない。

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

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

Twitter：@daisuke_kawada

atoll project