クラウドAPI: APIの乗るアーキテクチャにむしろ着目せよ
Thorsten von Eicken, CTO クラウド業界は相変わらず、活気にあふれている状況である。先日のAmazon Web Services社とEucalyptus社との間のクラウドAPI協業の発表に引き続き、OpenStack Summit開催の直前を狙って、Citrix社が自社のクラウドAPIの拡張に関する発表を行っている。この一連の活動を通して、いかにクラウドAPIが重要な要素になっているか、という事がよくわかる。特に今年は、クラウドAPIの市場はますます活発化するが、標準化どころか、複数のAPIがますますしのぎを削る市場が展開される、という事が予測される。
Citrix社の発表は、Cloud.com社がCitrix社に買収されてから初めての大きな発表になる、という点が特徴的である。買収後、Citrixチームと元Cloud.com両社共にOpenStackプロジェクトにかなりのリソースを提供し、具体的には、Swiftと呼ばれるOpenStackのストレージシステムの採用を行って来た。
興味深いのは、CloudStackのチームはOpenStackの技術を自社クラウド基盤に採用する事に関して非常にオープンではあった一方、特にOpenStack Compute部分を採用する事に関しては、少なからずとも抵抗が出て来ていたのも事実である。既にグローバルに数々の大規模パブリッククラウド事業社への導入実績を持っているCloudStackのチームにとって、OpenStack Compute部分は、技術的な面において遅れている、という認識が強くなって来た、というのが要因である。
結果的に、CloudStackの部隊としては既存のCloudStackの継続的な開発を続ける方針を維持し、OpenStackからは必要な部分のみを積極的に採用する、というスタンスをとる結果になっている。OpenStack Object Storageの採用はその一例である。
また、昨今発表したCloudStackをApache Foundation Projectに寄贈する件についても、CloudStackを独立したクラウドAPIとして競合力のある技術として位置づける方針が明確になった裏付けである。
さて、一方では、Amazon Web ServicesとEucalyptusは共同でAPIの互換性を保証する発表を行っている。従来から、Eucalyptusの主張していた、AWSとのAPI互換戦略をAWSと共に改めて市場にアピールするよい機会であったと言える。
AWSのクラウドAPIにかかわる戦略がクラウド全体の市場に与えている影響を考察すると非常に興味深いものである。Eucalyptusが登場し、RackSpaceがクラウド事業を展開し始めた当初、両社のAWS API互換戦略に対して、AWSがそれを防止するための動き、特に法的な処置に出ないかどうか、実は市場が興味深く動向を観察をしていた時期でもある。AWS内部でも、どの様な対応を取るべきか、かなりの議論がされていた筈である。結果的にAWSが取った戦略は、"Wait And See"（様子見）戦略で、市場の形成がもう少し進んだ時点で行動を起こす、というものであった。その行動の一つがEucalyptusとの発表である、という事が言える。
かなり早い段階でもう少し具体的な動きを取るべきだったのでは、という議論もある。例えば、Ubuntuの開発者である、Mark Shuttleworth氏が2011年の9月時点で、OpenStackはAWS EC2互換であるべき、と主張している。また、CitrixのCloudStackも以前よりAWS API互換をサポートしている、という実績があり、AWS APIに関する各社、団体の動きというのは市場全体に共通するクラウド事業社にとってのベンチマークAPIである、と言える。
さて、本題は、このクラウドAPIというもの、本当にそんなに大事なものなのか？ という疑問であり、クラウドAPIの互換性というものの本当の意味について分析をしてみたい。
クラウドAPI互換の問題点
以前から主張しているが、改めて述べたい。重要なのはクラウドの中のリソースのセマンティック（意味的な構造）であり、その表面上のAPIではない、という事である。
API互換は、かなり深いレベルまで互換性を確保しないと全く意味をなさない、と言う事である。
幾つか事例を通して解説をしてみたい。
＃1：
EC2は幾つかのインスタンスタイプを提供している事は有名である。1~8個のコアCPU、512MB~8GBのメモリ、ディスク0〜4スピンドル、共有ネットワークと専有10Gbpsポート、等々。これらの多種のインスタンスをプライベートクラウドに構築するのは可能ではあるが、実際問題そんな簡単な話ではない。結果的にAWSと異なるインスタンスタイプのあるプライベートクラウドにAWS上の資産を動かそうとしても結構難しい問題が発生する。また、AWSのインスタンスタイプが必ずしもユーザのアプリケーションに最適なデザインであるとは限らず、事例としてカスタマイズしたインスタンス構成を自分で作るエンドユーザも非常に多いのが実情である。この辺はクラウドAPIとは全然次元の違う課題の代表として上げられる。
＃2：
EC2 EBS Block Storageは非常にユニークが構造を持っているストレージクラウドである。それ故、好き嫌いも多いが、スナップショットや特定のI/O向けに多用されいているのが現状である。ただ、それは事実上無尽蔵にストレージを提供出来るAWS上でこそ効果を発揮する性格の技術で、小規模なプライベートクラウド上では、EBSと完全互換のストレージを提供する事はあまり意味が無い、と言える。API互換を追求するあまり、あまりシステムとしては効果の無い環境を提供する結果になってしまっては、あまり意味が無いのでは、と感じる。
＃3：
AWSクラウドは、それぞれのリージョン毎に分離され、それぞれが独立してリソースを管理/運用している。障害管理(Disaster Recoery: DR)の目的で、東海岸に一イメージ、さらに西海岸にそのイメージのコピーを作りたい場合、ある特定の頻度でイメージをコピーして同期させる必要がある。多くのクラウド事業社は、こういった複数のリージョン間のイメージ管理を自動化、若しくは簡易化したサービスをAPIとして提供している。当然、各社とも、そのアプローチ、ましてやAPIはバラバラである。AWS互換のレベルとは全く次元の異なる世界である。
＃4：
SoftLayer社は、世界各所で運用しているデータセンタとそれを繋ぐネットワークインフラを利用し、顧客に対して、グローバルなプライベートネットワークを提供するサービスを行っている。AWSのリージョン別戦略と異なり、拠点間のアドレスを統括し、一つのサーバシステムの様に見せることが出来る、というのが特長である。拠点間のサーバ管理、上位の業務運用がEC2と比較して非常に簡易になる、と言う事である。SoftLayerはその気になれば、AWS EC2互換をグローバルに提供する事も可能であるが、そうしたとしても、拠点間で運用管理をする為のツール、インスタンスの提供/管理を支えるアーキテクチャがAWSと大きく異なる為、クラウドAPIを共通化した所であまりユーザにとってメリットの無い話になってしまう。
要は、クラウドAPIはクラウド間の互換性やポータビリティを保証する要件にはなり得ない、と言う事である。単一のインスタンス上でサーバを数台起こす程度であれば、API互換は何かと重宝するが、一旦要件が、異なるクラウドへの拡張性、性能の最適化、コスト最適化、ガバナンス/コンプライアンス、障害検知/対策、等の対応を必要とする状況になった時点で、クラウドAPIだけでは到底カバー出来ない課題がうまれてくる。
互換性に対するより大きなアプローチ
上記の状況に対して、より大きなアプローチが必要になってくる、という事は自明である。
まず、現実問題としてAWS APIに加え、他にも複数のクラウドAPIが存在する、という事実を認識する必要がある（特に日本では顕著）。また、EC2には、2種類のAPIが存在する、と述べたい。"EC2 Classic"と"EC2 VPC"の2つである。後者は、AWSのVirtual Private CloudをサポートするAPIであり、Classicとはかなり異なるAPIを提供している。例えば、VPCは、i) Classicがサポートしない、egress ruleがあったり、ii) Classicが1コマンドで出来るしないインスタンス間のIPアドレスの移行に2コマンド必要である、等。
細かい事はさておいて、本質的な課題を述べると、"Amazon準拠"の真の意味は、AWSが提供している、20にも及ぶサービス全てに対して互換性を提供する事、と定義する必要がある。ただ、これ自体は大変な事であり、口でいう程簡単ではないのは明らかである。
多くのAWS互換クラウドは、EC2に加え、それに準ずるサービス、例えばElastic Load Balancing(ELB)、Relational Database Service(RDS)、Simple Queue Service (SQS)、場合によってはCloudFrontのコンテンツ配信サービス等が上げられる。その程度の互換性で上手くAWSからの移行が成立すればOKだが、問題は、自分の利用するAWSサービスが一つでも欠けていたら、AWS互換の価値が全く無くなってしまう、と言う事である。
今後の傾向としてよく理解しないといけないのは、クラウドユーザは、EC2レベルのAPI互換性ではなく、その周辺のサービスに対する互換性がより重要な課題になる、という点である。
例えば、RackSpace Hosting社は、Load Balancingをサービスとして提供を開始しており、一方では、SoftLayerはCDNサービスを提供している。Google AppEngineを見ると、Task Queues、Emailサービス、各種SQL/NoSQLのストレージサービス、等、各社サービスメニューを拡充している。また、まだ付加価値サービスを提供していないクラウドベンダーはこのサービスメニューの品揃えの重要性に早くも気づき始めている。
今時点に於いては、AWSが提供しているサービスメニューに非常に近いものが多く登場しているのが現状であるが、今後どのような新しいサービスが登場するのか、またサービス群全体としてのクラウド間互換性の動向がどの様に進むのか、が非常に興味深い所である。
まとめ
Citrixの発表した、i) 自社技術の優位性、ii) Apacheへのソース公開、iii) AWS互換性、の3点発表は興味深い戦略である。今後起きうるトレンドとして、オープンソースになったCloudStack上に、AWSの各種サービスと互換性を持つコンポーネントを開発するベンダーが登場してくるだろう、という点である。そういう意味では、Citrixは市場動向をよく分析した、非常に戦略的な動きを取っている、と評価することが出来よう。
今後の提案として2つあげたい。
1）AWSにとらわれる事なく、今後登場する他のクラウドも積極的に利用し、新たなユースケースを発見して欲しい、という事。
2）その際には、クラウド間の互換性について悩むがためにより大きな動向を見失っては行けない。
各種サービスも含めた、クラウド間の互換性、ポータビリティ、についてはより上位のレイヤーにおいて既に取組んでおり、ソリューションとして成立している、という事を是非認識して欲しい。
RightScaleの元来狙っている答えは正にそこにある訳です。
