掲載日時: 2010-08-26 07:00

クラウドコンピューティングのAPI--標準策定が時期尚早である理由

一部でアマゾンのAPIがクラウドAPIの「デファクトスタンダード」だと言われているが、その意見にはいくつか疑問点がある。そもそも、現時点でクラウドの標準を定めることなど可能なのだろうか。

著者 : 文:James Urquhart(Special to CNET News) 翻訳校正:川村インターナショナル

URL : https://japan.zdnet.com/article/20418528/

 サンフランシスコで6月に開催されたStructureカンファレンスにおいて、筆者はハイブリッドクラウドコンピューティングをテーマとするパネルディスカッションの司会という名誉な役目を務めた。パネリストには、Eucalyptusの最高経営責任者(CEO)のMarten Mickos氏、RightscaleのCEOであるMichael Crandell氏、AT&Tの戦略および事業開発担当バイスプレジデントJoe Weinman氏など、クラウドコンピューティングの先駆者たちが含まれていた。

 Mickos氏はそのディスカッションの中で、Eucalyptusは「Amazon Web Services(AWS)」のAPIを「80年代のPC標準のような標準になる可能性を秘めたもの」と見ているという趣旨の発言をした。PC標準によって、さまざまなコンピュータメーカーが1つのハードウェア標準を共有できるようになり、OSとアプリケーションの革新が実現した。

 クラウド・ゲートウェイ・アプライアンス・ベンダーCloudSwitchの創設者で、製品担当バイスプレジデントを勤めるEllen Rubin氏は、Mickos氏の主張を受けて、AmazonのAPIが今日の標準になれるかどうかを批判的に考察した記事を執筆した。以下はその記事からの抜粋だ。

 業界標準のようなものがあるとすれば、Amazonは間違いなく自社が標準であると強く主張できる立場にいる。同社は明白なリーダーであり、その技術は他の追随を許さないものだ。クラウドコンピューティングの進歩にも大きく貢献してきた。AmazonのAPIは多くの実績があり、広く使用されている。Amazonのクラウドは拡張性に優れ、あらゆるクラウドの中で飛び抜けた人気を誇っている。したがって、クラウドコンピューティングをメインストリームに押し上げるにあたって主導的な役割を果たしたという点については、Amazonの功績を全面的に認める。しかし、そのことでAmazonが業界標準の基盤になるべきだと主張するのは大きな飛躍である。

 筆者は1年ほど前から、AmazonのAPIは「デファクトスタンダード」であるという宣言を耳にしてきた。最初にそう聞いたのはSimon Wardley氏(当時はLinuxベンダーのCanonicalに在籍)からで、その後はEnomalyの最高技術責任者(CTO)でクラウドブロガーのReuven Cohen氏などからも耳にした。

 ユーザー数で測るならAWSの「Elastic Compute Cloud(EC2)」と「Simple Storage Service(S3)」のAPIが今日の市場を牽引するIaaSだという意見には賛成だ。だが、そのような地位にあることと長期的な標準になることは必ずしも同じではないという点については、Ruben氏に同意する。それには以下の3つの理由がある。

  1. AmazonのAPIが定義するクラウド機能セットは1つしかない。Amazonのものだけだ。確かにAmazonはクラウドサーバとストレージサービスの分野で大きくリードしている。また、その機能をサポートする極めて強力なエコシステムを有しているのも事実だ。しかし、EC2は実際には厳格に定義されたサーバおよびネットワークアーキテクチャで、分散型アプリケーションアーキテクチャとインフラストラクチャ構成における革新の余地はほとんどない。

     もし開発者コミュニティーがこのアーキテクチャの使用に伴うパフォーマンス、可用性、セキュリティの問題をすべて克服する方法を見つけられるのなら、それは大した問題ではない。しかし、エンタープライズインフラストラクチャアーキテクチャが現在の状態に進化してきた過程には、それなりの理由がある。そして多くの人々が、Amazonのアーキテクチャの欠点によってさまざまなアプリケーションの有効性が制限されてしまうと考えている。

     実際のところ、Amazon EC2が一部のユーザーを悩ませている1つの分野は、I/Oパフォーマンスに関するものだ。ネットワークアクセスとストレージアクセスの両方に予期せぬ遅延が発生することが分かっている。ある有名なオープンソースデータベースの主要開発者の1人は、筆者に対し、この問題のために一部のクライアントをほかのクラウド環境へ移行させることを検討したと話してくれた。

     ストレージの場合も同様で、ユーザーに提供されるのは、Amazonがそのユーザー向けに有効化した基本的な機能セットだ。もちろん、ユーザーはどんなデータベースでもEC2に追加できるが、その場合は「標準」のAmazon APIを使用しないということになる。それが狙いなのかどうかはよく分からない。

  1. ベンダー4社が提供しているものが1つの標準になるのか。AmazonのEC2 APIとS3 APIは多くのベンダーや開発者が使用しているが、それらを実際に提供しているベンダーはAmazon、EucalyptusCloud.com、新興企業のNimbulaの4社だけだ。これらの製品(2つはオープンソース)がEC2 APIを狙うべき目標と見なしているのは印象的なことだが、先述した点に留意することも重要である。これらのプロジェクトが行ってきたのは、自らをAWSと機能面で互換性があると定義することだ。そうすることで、一部のワークロードには合うようになるが、ほかのワークロードにはそれほど向かなくなる。

     とはいえ、いかなる標準もどこかで策定作業を始めなければならない。したがって、少なくともフラットな構成でハイスケールなクラウド環境については、これが将来「必須」のAPIセットになるものの始まりであると見なすことも可能だ。しかし、1つ問題がある。Amazonには、このAPIを著作権に縛られず営利目的の再販が法的に可能なものにしようという動きは一切なかった。これら3社はすべて、ある意味で危険なことを行っている。

     幸い、大半の企業(すべてがそうである可能性もある)は比較的簡単に、AWS APIをほかの何らかのAPIオプションで置き換えることができる。だが、マーケティングの観点から見ると、その新しいAPIを新しい標準として売り込む作業をやり直さなければならないだろう。

  1. ほとんどのものは、クラウド標準とみなすには時期尚早だ。実際のところ、この業界で今後10年間のコンピューティングがどのように展開するのかを今、正確に予測できる者は誰もいない。どのアーキテクチャが「勝利」を収めるのだろうか。商業の機能にとって極めて重要な存在になるのはどんなエッジケースだろうか。クラウドコンピューティング運用モデルの中核的な要件を変える新技術とは何か。

     EnomalyのCohen氏は最近のブログ記事で、AWS APIに対する自身の立場を改め、AWS APIを標準として宣言することを妨げている別の要因を指摘した。Cohen氏が指摘するのは、製品ベンダー以外で、現在ポータブルクラウドAPIのことを本当に気にかけている人はいるのかということだ。大半のクラウドユーザーは1社か2社のクラウドベンダーに自社の取り組みを集中させている。ユーザー企業の多くは、クラウドベンダーを変更したために主要な運用コードを変換しなければならないという苦しみをまだ味わっていないのだ。現在のクラウドコンピューティングにおいて、ポータビリティという面はまだあまり求められていない。

     この点をさらに裏付ける可能性があるのが、Object Grid Forumにおける「Open Cloud Computing Interface」標準の取り組みが明らかに崩壊しているのに、あまり騒がれていないということだ。ライセンスに関して意見が一致しなかったことから、主要メンバーの1人が極めて重要な知的財産を携えて、別の道を歩むようである。クラウドユーザーコミュニティー全体はあまり大きな怒りを表明していない。これは、同標準が現時点で、コミュニティーにとってあまり重要ではなかったということのように思える。

 一貫した標準のクラウドコンピューティングAPIを求める理由は数多くある。しかし、1人の勝者を宣言することが時期尚早である理由もたくさんある(その意味では、勝者を宣言すること自体が時期尚早である)。AWSのEC2 APIとS3 APIはそれぞれの環境において優れているが、それらは単に人気のあるAPIというだけで、現時点では、クラウドコミュニティー全体にとってのデファクトスタンダードと宣言され得るようなものではない。

この記事は海外CBS Interactive発の記事を朝日インタラクティブが日本向けに編集したものです。

ZDNET Japanは、Ziff Davisからのライセンスに基づき株式会社4Xが運営しています。
ZDNET Japan is operated by 4X Corp under license from Ziff Davis.

Copyright © 2026 4X Corp, Inc. All rights reserved. No reproduction or republication without written permission.