Amazon CTOが語るPaaS、そして企業ITの新たなスタイル：クラウドHot Topics（5）（2/2 ページ）

―― アマゾンの管理サービス／ツールを拡張してアプリケーションやネットワークを細かく監視するといったことに市場機会があると思うか？

　そうした機会については継続的に検討している。しかし、これについては、CAやBMCをはじめとする、多数のパートナーと協力している。こうした企業は、顧客のデータセンターにおけるプレゼンスをすでに確立している。彼らと協力して、標準的なエンタープライズIT管理システムに、われわれのサービスの管理をいかに統合できるかということに、高い優先順位がある。

　2つの異なる管理システムを管理する代わりに、IT担当者がオンプレミスとクラウドの双方を統合的に見られるようにしていきたい。BMC BladeLogicはサーバを管理するツールだが、AWSのリソースも管理できる。シトリックス・システムズも、オンプレミスとAWSのサーバを統合的なシステムとして運用できるテンプレート・システムを提供している。

　われわれとしては、こうしたシナリオに自社のサービスがうまく適合できることが重要だ。ソフトウェアベンダが努力するだけでなく、こうしたISVが当社のサービスを管理する際の課題に、継続的に対応していきたい。そしてわれわれのサービスの管理を容易にするため、サービスに対して機能を追加していきたい。

　同時に、そのほかの機能、特にセキュリティについては投資を進めていく。従来の企業向け製品にも見られなかったような、これまでにない新しい種類のプロダクトを投入すべく、イノベーションをもたらすような投資をおこなっていく。

　例えばAmazon VPCのバージョン2は、最初のバージョンに比べて制御性と機能が大幅に強化された。NATでパブリックとプライベートのネットワークが構築できるようになった。また、ルーティングテーブルを作成し、それを自由に制御できるようになった。

　新しいアイデンティティ・アクセス管理のメカニズムも提供開始した。どの担当者がすべてのオブジェクトにアクセスできるかを、よりきめ細かく制御できるようになった。また、きめ細かなアクセス制御言語により、このオブジェクトはこの場所から、この時間内のみ、この役割を担っているこの人だけがアクセスできるといった指定ができるようになった。

　この非常に詳細できめ細かな言語により、企業は従来実現できなかったようなポリシー制御エンジンを構築できる。

　例えば開発の一部をアウトソースしているとしよう。外注先の開発者は何かを作成はできても、削除はできないようにすることが可能だ。また、誰でもサービスを起動できるが、サービスの停止は2、3人しかできない、といった設定もできる。

　特定の法令を順守するために、このような仕組みが必要な場合もある。

　従来の企業では、こうしたツールは存在しない。われわれは、デロイトなどと協力し、このポリシー駆動型のアクセス管理メカニズムのためのハイレベルな制御システムを構築しようとしている。

AmazonクラウドはAWSよりはるかに大きな存在

―― PaaSをめぐるITベンダの動きが活発化している。これに対してアプローチしていく考えはあるのか。

　非常に面白いことが起こっていると思う。われわれはインフラの部分に力を入れてきたため、逆にこうした動きをかなり前から認識していた。しかしわれわれには（インフラのレベルで）やらなければならないことが山ほどある。永遠にやり続けることのできそうなくらいの長いリストだ。

　一方、顧客はわれわれに、PaaSへの参入も求めてきた。

　われわれにとって、プラットフォームは非常に重要だ。しかし、それよりもさらに重要なのは、AWS上で多数のプラットフォームが花開くことだ。そこで、AWSの上でPaaSを提供している企業が、何で苦労しているかを見定め、その問題を解決することで、さらに多くのPaaSが登場できるようにしたい。

　私は、開発者の数ほどプラットフォームがあってもいいと思っている。誰にも好みのコンテナや開発言語があるからだ。従ってわれわれは、AWS上でのこうしたプラットフォームの開発を、とても簡単なものにしていきたい。もちろん、すでに主要なPaaSは登場している。HerokuやEngine Yardは分かりやすい例だ。しかしさらに新しいプラットフォームが登場しつつある。PHP fog、Nodejitsuなどだ。こうした新しいプラットフォームは非常に興味深い。われわれにとっては、多数のプラットフォームがAWS上で花開くことが重要だ。

　加えて、私はIaaS、PaaS、SaaSといった分類に意味を感じていない。

　世界は進化している。複雑なアプリケーションを考えれば、さまざまなものを少しずつ使っていることに気づくだろう。Amazon EC2を使い、Java、ruby、PHPなどを使っている。Elastic BeanstalkはJavaの使い勝手を向上しているが、ほかのプラットフォームにはできないような下位の環境の制御を可能にしている。さらに、一部のアプリケーションは位置情報サービスやレコメンデーション・サービス、ビデオ通話サービスなど、ほかのサービスも使っている。ビデオ通話は果たしてPaaSなのか、IaaSなのか、それともSaaSなのだろうか？

　つまり、われわれにとってAmazonはサービスの集合体だ。階層の分類よりもはるかに大きな意味を持っている。

　顧客は多数のサービスから、さまざまなサービスを取捨選択し、自身のサービスを構築する。Amazon EC2、Elestic Beantalk、Heroku、そして位置情報ではSimpleGeoなどを使い、これらをまとめ上げることが行われる。

　われわれは、これらのサービスの1つ1つを注視し、彼らが苦労に感じていることは何かを探り、問題をできるだけ解消することで、できるだけ多数のパートナーから顧客がそれぞれの目的に特化したサービスを選択できるようにしたい。

　私の考えでは、AmazonクラウドはAWSよりはるかに大きな存在だ。それはわれわれの上で提供されているすべてのサービスの集合体であり、顧客にとって非常にリッチな体験を提供できる。サービス提供者の多くは若い企業だ。しかし、同じフレームワーク上で、SAPやオラクル、SugarCRMなどの企業が従来型のエンタープライズ・サービスを提供する。従って、顧客は単一の環境の上で、オラクルのサービスやSAPのデータ解析サービスを、ほかのサービスと組み合わせて利用できる。

―― Force.comのようなことをAWSが始める可能性はゼロだといえるのか。

　Force.com toolkitを使えばAWS上でアプリケーションを構築し、Force.comに接続できる。彼らもWebアプリケーションを構築できる環境を持っているが、対応できる規模は小さい。一方、AWSの規模は無制限だ。もし、複雑なアプリケーションを構築し、ERPやCRMのシステムと統合したいなら、Force.com toolkitを使ってアマゾンのプラットフォーム上で動くアプリケーションとForce.comを統合できる。

　最近目にした面白いアプリケーションは次のようなものだ。ある企業が、セールスフォースのデータを位置情報サービスおよびカレンダーシステムと組み合わせたアプリケーションを構築した。これを使うと、もし今日の午後に私が急に2時間の空きができた際に、自分の現在の居場所から5分以内で行かれる、一番売上ポテンシャルの高い見込み客を探し出すことができる。これは、いま起こっている新しいタイプの開発のいい例だ。

構築せずに、サービスを組み合わせる

―― エンタープライズ・アプリケーションは、より高い一貫性の保てる環境を必要とすると考える人もいるが、どう思うか。

　世界に対する見方がおそらく違うのだろう。例えば私が知るかぎり、多くの人がHerokuを使う理由は、位置情報サービスや、Fecebook／Twitter、その他多数のサービスと連携したいからだ。

　理解してほしいのは、Amazonのサービス、そしてわれわれのエコシステムを成している多くのサービスは。完全に開発言語から独立した形で作られている。われわれのサービスは、どの言語でも使うことができる。

　例えば、Simple Email ServiceはJavaからでも、Herokuからでも、Engine Yardからでも、どこからでも使える。こうしたサービスを使うのにAmazon EC2のユーザーである必要すらない。われわれのすべてのサービスはどんな開発言語でも使えなければならない。これは当初からの、われわれの方針だ。

　もし、ある企業が大規模な開発のために特定の開発プラットフォームを使いたいと考えたからといって、ほかのサービスを使ってはいけないということにはならない。自社の開発環境で活用したいからといって、例えば既存の位置情報サービスを使わずに、自社で開発するというのは、賢いこととは思えない。

　もう1つ、現実として、ほとんどの企業は大規模なソフトウェア・パッケージを使っているということもある。

　例えば、米国の連邦政府はクラウド・ファースト（クラウド最優先）の戦略をとっている。その最初に立ち上げたサイトの1つは、マイクロソフトのSharePointを、地理情報システム、SAPのデータ解析システムであるBusiness Objectsと組み合わせている。そのうえで、周りに多数のカスタム・アプリケーションを構築している。

　明らかに、ワークフロー管理システムを自前で開発したい人はいない。地理情報システムや、Business Objectsのような本格的データ解析システムを構築したい人もいない。

　すなわちわれわれは、こうしたより大きなコンポーネントを今後も活用していくだろう。これらを結びつけていくことのほうが重要になっていく。また、こうしたソフトウェアがプラットフォーム・サービスとして動くのか、それともAmazon EC2にインストールされるのかは、どちらでも構わない。これらの大きなコンポーネントはすべてAmazonクラウド上で動き、誰もがRubyやJava、JavaScript、PHPなどで使ったり、つなげたりすることができる。

―― つまり、IaaS／PaaS／SaaSといった分類は気にせず、アプリケーションを構築する人や、アプリケーションのためのプラットフォームを提供する人に対するサービスに注力するということか。

　まさにそれがわれわれの本当に、本当に力を入れたいことだ。われわれはますますエコシステムの構築に注力し、顧客がプラットフォームや関連サービスの活用においてさらに多くの選択肢を手にすることができるようにしていく。

　Elastic BeanstalkはJavaコンテナとして提供しているが、目標としているのは複数のコンテナを提供することだ。そしてこうしたコンテナをパートナーが構築してほしいと思っている。われわれがすべてをやる必要はない。われわれはやりやすくする支援をしていきたい。

AWSが災害対策に有効な理由

―― インフラレベルでまだやるべきことはたくさんあるとのことだが、今後例えばどんなことをやろうとしているのか。

　こうした点についてわれわれは秘密主義を貫いていることで有名だ（笑）。データベース関連では、まだやることがある。Amazon RDSは当初MySQLのみだった。しかし即座に、同様なサービスとしてOracleを使いたいというリクエストが顧客からあった。そこでわれわれはオラクルとの協力に基づいて、Oracleを使ったRDSを今年になってスタートした。顧客は自社のライセンスを持ち込むこともできるし、われわれのライセンスを時間課金で使うこともできる。ほかにどのデータベースを、同一のフレームワークで提供できるかを検討している。

　信頼性の向上についても検討している。Amazon SimpleDBやAmazon S3などのサービスは、そのスケーラビリティをわれわれがコントロールしている。自社でソフトウェアを開発したため、これらのサービスの拡張性や信頼性を理解しているつもりだ。

　しかし、RDSでは他社の商用ソフトウェアを使うため、拡張性や信頼性を確保しにくい。そこで、顧客がリレーショナルデータベースを継続的に使える一方で、（SimpleDBなどと）同レベルの信頼性を確保できるような機能を追加しようと考えている。

―― 今回の来日では、BCPとクラウドに関する講演などがスケジュールされているが、AWSなどのクラウドサービスをBCPのために活用するメリットは何か。

　今回、多くの時間を費やして、顧客とこれについて話し合った。例えば、多くの日本の顧客から聞くこととしては、自社の環境では単一のデータセンターで運用するしかないが、クラウド（AWS）へ移行すれば、2つのAvailability Zoneを即座に使えるようになるということだ。Availbili Zoneはそれぞれ別個の建物、別個の地震学的位置にあり、それぞれが個別の電源供給とバックアップ用発電機を有している。また、それぞれが別個のTier-1ネットワーク事業者に接続している。

　顧客がこれと同じようなことをしようとすると、大きなコストが掛かる。Amazonでは無料だ。

　すなわち、日本の顧客がいま、クラウド（AWS）を検討すべき理由は、複数のAvailability Zoneを活用して、可用性の高いアプリケーションを構築できることだ。2つのAvailability Zoneを同時に活用することもできるし、一方のAvailability Zoneにフェイルオーバすることも可能だ。アプリケーションの種類に応じて使い分けられる。

　日本の顧客がAWSに注目するもう1つの点は、すべてのリージョンが「unified deployment model」とわれわれが呼ぶモデルで作られていることだ。アプリケーションをTokyoリージョンに構築した場合も、これを即座にSingaporeリージョンやUS Westリージョンで動かすことができる。例えばオラクルは、Tokyoリージョンで稼働させながらSingaporeリージョンにバックアップするといったことを可能にするツールを提供している。

　従って、非常に大規模な災害が発生し、（Tokyoリージョンの）2つのAvailability Zoneが双方とも消え去った場合でも、SingaporeリージョンやUS Westリージョンで簡単に（サーバを）再起動して、サービス提供を継続できる。

　例えば、東日本大震災で、日本赤十字のWebサイトはトラフィックの急増により完全にダウンした。われわれのパートナーの1社であるサーバーワークスは、このWebサイトをSingaporeリージョンに移行して起動した。（シンガポールにしたのは）電力需給の逼迫を予想していたからだ。シンガポールでサーバが動いていても、コンテンツ・デリバリ・ネットワーク（CDN）のCloudFrontにより、このWebサイトは低遅延のアクセスを提供できた。

　こうした機能を持つAWSは、BCPを構築するための非常に強力なメカニズムとして機能する。