発展途上にあるIaaS、いま着眼すべきポイントとは？：特集：これからのIaaSニーズと失敗しない選択基準（1）（3/4 ページ）

AWS API互換戦略だけが正解ではない。発展途上のIaaS市場

　さて、図5で紹介した各社のAPI互換戦略に関しては、米CloudscalingのCTO、Randy Bias氏が2013年7月、OpenStackにAWS APIを標準と認め、AWS互換API整備を求める公開書簡を発表している。既にCloudStack、OpenStackともにAWS互換を志向している現状を踏まえて、筆者はこの主張に一定の理解と同意はできるが、AWS APIへのロックインは最善手ではないと考える。

　IaaSに限らず、クラウドのアーキテクチャデザインとAPIのデザインは密接に関連している。例えば、物理資源の接続構成の仕方が違えば、パフォーマンスなどの制約モデルやシステムの挙動も当然変化する。

　AWSのシステムデザインに合わせて設計されたAWSのAPIとの互換戦略を推し進めると、行き着くところ、AWSのシステムデザインとよく似たデザインのIaaSが氾濫することになる。これは、事業者の代替性が確保されることであり、利用者にとっては代替資源を組み合わせることで結果的に高い可用性や事業継続性が提供されるため、一定の便益のある回答といえる。

　だが、誕生して10年に満たないクラウドのデザインは、まだまだ未成熟で進化の余地が大きいと筆者は考える。事実、AWS API互換戦略では、一種のHaaSまたはベアメタルクラウドとして動作するSoftLayerのようなサービスはサポートできないのだ。

　このリスクをヘッジする意味でも、「NIST SP500-292」が提案したアクタータイプである「クラウドブローカー」の果たす役割は大きい。筆者は、ニーズに適したクラウド基盤選定や、複数のクラウド基盤の管理・運用を支援する「クラウドブローカーを介して相互運用性を担保するモデル」にはもっと注目してもいいと考える。

　例えば、BlueLockが標榜するRaaSは、障害検出と迂回経路、代替資源確保、デプロイなどの一連の動作が全て自動化されたものだ。クラウドがプログラマブルで動的構成変更に対応したインフラストラクチャであることを最大限に生かしたサービスといえる。

　AWSも「Elastic Beanstalk」での「ローリングアップデート」機能を実装したし、Google Compute Engineも「transparent maintenance」というライブマイグレーションと自動再起動を利用した機能を実装して、運用の自動化に取り組んでいる。

　国内では、クラウドブローカーに業態転換したNTT Data 「BizXaaS」の他、SCSK「USiZE」が積極的に複数の事業者のAPIをサポートし、ブローカー的なサービスを展開していることも注目される。ただし、国内のクラウドブローカー的なサービスはもう一段の進化が望まれる。日本のクラウドブローカーは、「複数のIaaSを統合したコントロールパネルから、利用者自身が人力で制御・監視する」というサービスを超えて、「クラウドエコシステム上に構築される利用者のシステムを自動制御するサービス」、あるいは「アナリティクスとビッグデータに対応した意思決定支援システム」として進化するなど、新たな付加価値を確保する必要があるだろう。