 |
クラウドへのアプリケーション配備を円滑にするために--共通の「記述」という提言 |
筆者は以前、クラウドコンピューティング環境へのアプリケーションの配備を簡素化することについて、自分の考えの要点をまとめた。当時は、その対象がインフラストラクチャサービスやプラットフォームサービスであろうと、Javaや「Ubuntu」であろうと、VMやディスクドライブであろうと、アプリケーションを共通のフォーマットでパッケージ化する方法が必要だと考えていた。
核となるコンセプトは、このフォーマットを定義して、実際に送信されるビットと、アプリケーションがクラウド内で動作するために必要なデプロイメントロジックやランタイムサービスレベルのパラメータを結びつけるというものだった。筆者は当初、この提案を行った根本的な動機について詳しく説明しなかったが、ここでその動機をはっきりと述べておこう。
顧客には、コンピューティングとストレージの容量について真に柔軟な市場を実現するために、自分が展開したいペイロードと、そのペイロードのサポートに必要なサービスについての共通の記述が必要だと思う。
サービスプロバイダーには、ペイロードのニーズを評価する一貫した方法が必要だ。それは、ペイロードをサポートするために今すぐ使える能力を判断するためでもあり、ニーズと新しいサービス機能を対応させる革新的な方法を実現するためでもある。
提供：Flickr/Justin See
非常に率直に言うと、ペイロードの記述と評価のための共通の方法がなければ、アプリケーションやデータセンターインフラストラクチャ、そしてインターネット自体の設計に大きな変更を施さない限り、クラウド機能の円滑な市場は実現しないかもしれない。
ありがたいことに、アプリケーションのパッケージ化の記事に関して、米CNETのコメント欄、そしてTwitter上の多数のフォロワーから、大変多くのフィードバックをいただいた。フィードバックが非常に素晴らしいものだったので、筆者は最初の提案について再考せざるを得なくなった。
CNET Japan 特別企画 -PR-
ITジャーナリスト佐々木俊尚氏と日立のキーパーソンが語る！
2010年企業クラウド元年 ビジネスニーズが企業のクラウド化を加速する
今考えると、筆者の提案は2つの重要な点で間違っていた。
アプリケーションだけでなく、ほぼすべてのソフトウェアペイロード（クラウドから送信される1と0の組み合わせ）も同様に重要だった。例えば、ローデータセットやさまざまな「ミドルウェア」、さらにSaaSアプリケーションへの拡張までもが、評価すべきペイロードと見なすことができる。
パッケージ化以上に、記述の方が重要だった。企業ITのような極めて革新的で多様な世界で共通のパッケージフォーマットを実現するのは、ほぼ不可能だ。その上、どこに配備するかを決める前に、ソフトウェアバンドル全体をそれぞれのクラウドプロバイダーへ送信して評価するというのは、非常に効率が悪い。
そのため、筆者はこれらの見解について1週間ほど熟考した後、クラウドインフラストラクチャをより簡単かつリアルタイムに選定できるようにするための、より良い提案の策定に取りかかった。
筆者が提案するのは、筆者が「pCard」と呼んでいるものだ（開発コード名は「Jean-Luc」だろうか）。pCardという名称にしたのは、悪名高い電子名刺フォーマット「vCard」に多少似ているからだ。pCardはある意味で、ソフトウェアペイロード用のテレホンカードのようなものだ。pCardには（シンプルな単一コンテナのペイロードでも、複雑なマルチコンテナの分散型ペイロードでも）、サービスプロバイダーが a) ペイロードのニーズに対応できるのか、そして b) そのためにはどのようなサービスが必要なのか（また、コストはどの程度なのか）を判断するために必要な情報が含まれる。
pCardの構造は筆者の当初の提案に非常に近いものだが、実行ファイルではなく記述に重きを置くように修正を加えている。
提供：James Urquhart
CNET Japan 特別企画 -PR-
ITジャーナリスト佐々木俊尚氏と日立のキーパーソンが語る！
2010年企業クラウド元年 ビジネスニーズが企業のクラウド化を加速する
pCardには、以下の4つの要素が表示される。
pCardのフォーマットとコンテンツを記述するメタデータ。このメタデータには、クラウドプロバイダーがpCardの残りの部分を処理できるかどうかを判断するのに十分な情報を記述しなければならない。
アプリケーションビットがパッケージ化される仕組みと、そのパッケージを処理するインフラストラクチャ（例えばuntarや「WebLogic」マネージャなど）がどのようなものになるかに関する記述。この記述は環境全体ではなく、個々のパッケージのニーズに焦点を当てたものにすべきだ。ただし、これら2つを組み合わせたパッケージ（Open Virtualization Format（OVF）など）がここに含まれ、環境に関する項目（以下の3）から参照される可能性もある。
クラウド環境によってサポートされなければならない中核的なサービスと環境アーキテクチャに関する記述。これには、VMのサイジングやストレージ要件、ネットワークトポロジなどが含まれるだろう。ペイロードパッケージの外側の自動化に関する要件も含まれる可能性があり、これは初期設定の一部として実行する必要がある。
ペイロードパッケージの記述内に関連情報を参照するポインタを追加しても構わない。
単一のベンダーがこの情報を所有することも考えられるが、一定のポータビリティを確保するために、アプリケーションの分類ごとに、より一般的な標準が策定されることが望ましい。
アプリケーションビットの自動化されたランタイム操作の処理に必要な、オーケストレーションとサービスレベルポリシー。この項目には、顧客によるペイロード監視に必要な特定の管理フィードフォーマットとデータに関する要件も含まれる可能性がある。
もう一度言うが、筆者はこの分野で何らかの標準が策定されることを望んでいる。しかし、この項目では、必要な情報を宣言するための多様な方法が許容されるべきだ。
筆者が以前、次世代のクラウド対応パブリックネットワークインフラストラクチャに取り組んでいるグループにこのコンセプトを披露したところ、かなり熱狂的な反応が返ってきた。ある意味で、これはクラウドがサービス割り当てを自動化し、さまざまなペイロードをサポートできるようにするための、「クラウド」へのインプットである。
皆さんはどのようにお考えだろうか。このコンセプトは、もっと深く追求する価値があるものに思えるだろうか。正式なワーキンググループを設立して、さらなる可能性を探るだけの価値があるだろうか。このコンセプトに関して現在議論が行われているが、それに参加したい人のために、筆者は公開のGoogle groupを立ち上げた。
あるいは、このコンセプトは自分のクラウドペイロードには向いていない、という人はその理由を聞かせてほしい。その場合、どのような代替案があるだろうか。
この記事は海外CBS Interactive発の記事を朝日インタラクティブが日本向けに編集したものです。
CNET Japan 特別企画 -PR-
ITジャーナリスト佐々木俊尚氏と日立のキーパーソンが語る！
2010年企業クラウド元年 ビジネスニーズが企業のクラウド化を加速する