Comments
Description
Transcript
報告書（PDF形式：1384KB）
平成 22 年度産業技術研究開発委託費 （次世代高信頼・省エネ型 IT 基盤技術開発事業 （クラウドコンポーザビリティをサポートする PaaS システムの開発）） 事業報告書 平成 23 年 3 月 31 日 株式会社 IIJ イノベーションインスティテュート 1．本事業の目的と背景 ................................................................................................................ 1 1.1. 本事業の目的 ..................................................................................................................... 1 1.2 本事業の背景 ...................................................................................................................... 1 1.2.1 クラウド・コンピューティングに関わる現状 ............................................................. 1 1.2.2 クラウド・コンピューティングの問題点 .................................................................... 3 2．本事業で開発する技術 ............................................................................................................. 5 2.1 技術的課題と課題解決のアプローチ ................................................................................... 5 2.2 開発技術の新規性、革新性................................................................................................. 6 2.3 本事業全体での開発概要 .................................................................................................... 8 2.4. クラウド・アーキテクチュアにおける PaaS ................................................................. 10 2.4.1. PaaS の役割 ............................................................................................................. 11 2.4.2.アプリケーション実行環境とスケールアウト............................................................ 12 2.4.3. PaaS と DaaS の関係 ............................................................................................. 15 2.4.4. PaaS システムの既存事例 – Google App Engine for Python .................................. 16 3．平成 22 年度の開発 ................................................................................................................ 18 3.1. 平成 22 年度の開発概要................................................................................................... 18 3.2. ベースシステム ................................................................................................................ 19 3.2.1. ノード依存関数への対処（サンドボックス機能）................................................... 20 3.2.2. セッション情報の管理 .............................................................................................. 21 3.3 メタデータ管理 ................................................................................................................. 22 3.3.1. HTTP フロントエンドとメタデータの役割 ............................................................... 22 3.3.2. クラウド間連携に関する想定 ................................................................................... 23 3.3.3 メタデータのデータ形式 ........................................................................................... 25 3.4. HTTP フロントエンド ...................................................................................................... 26 3.5. バックエンド・ストレージのサポート ........................................................................... 27 3.5.1. ストレージ・サポートのコンセプト ........................................................................ 27 3.5.2. 想定している利用シナリオ ....................................................................................... 28 3.5.3. ソフトウェア構造 ..................................................................................................... 29 3.6. 平成 22 年度開発の総括................................................................................................... 30 付録 A. National Institute of Standards and Technology ......................................................... 31 付録 B. Above the Clouds: A Berkeley View of Cloud Computing .......................................... 34 付録 C. Toward a Unified Ontology of Cloud Computing ........................................................ 45 1．本事業の目的と背景 1.1. 本事業の目的 次の二つの要求に対応可能な PaaS サービス事業を展開するため、主に PaaS をベースと するクラウド・アプリケーション開発環境の開発とオープンソース・ソフトウェアとして の配布を目的とする。 ハイブリッド・クラウドおよびコミュニティ・クラウドのサポート 情報の収集・分析に優れたクラウド・アプリケーションの開発支援 なお、本事業で開発する技術は「生産性向上に関する技術」および「相互運用・連携性に 関する技術」に該当する。 1.2 本事業の背景 1.2.1 クラウド・コンピューティングに関わる現状 ここでは本提案の背景となった国内外のクラウド・コンピューティングの現状について説 明する。クラウド・コンピューティングは未だ発展過程のパラダイムであり網羅的な説明 が難しいのだが、米国標準技術局 (NIST) が提示する The NIST Definition of Cloud Computing [1] 1のサービス・モデルとデプロイメント・モデルに基づくと比較的わかり易 く整理することが出来る。 ・サービス・モデルに基づく整理 (1) Cloud Infrastructure as a Service (IaaS). このモデルの代表例は Amazon EC2 で、既存の IT システムからの移行の容易さから現時 点でのクラウド・コンピューティングの需要の大半を担っている。これは仮想化技術等を 活用しているので既存のシステム・モデルを変更することなく移行ができることが主たる 理由である。既存システムとの親和性によりこのモデルはプロバイダにとっても比較的参 入が容易である。 (2) Cloud Platform as a Service (PaaS). このモデルの代表例は Google App Engine と Microsoft Windows Azure で、クラウドに 「自動的かつ迅速な伸縮性」を期待する利用者の需要を担っている。問題点は PaaS プロ バイダの提供するアプリケーション開発環境を前提としているため、利用者にとっては既 存システムの移行コストや特定のプロバイダへの依存性の懸念などが存在する。したがっ てこのような特性があまり問題にならない個人向けサービスがこのモデルの主たる需要に なっている。またこのモデルはクラウド・インフラストラクチャに対応したアプリケーシ 1 末尾の付録 A を参照 1 ョン開発環境一式を用意しなければならないことが、このモデルによるサービス事業参入 の大きな障壁になっている。結果的に事実上前述の代表例 2 社の寡占状態になっているよ うに見える。 (3) Cloud Software as a Service (SaaS) このモデルの代表例は SalesForce であるが、そもそも利用者としていわゆるエンドユー ザーを想定しているので、クラウド・コンピューティングとの関係はプロバイダが任意に 決定できる。したがって、このモデルのプロバイダは上記サービスの利用者となり各々の SaaS のクラウド化の状況は第 3 者にはわかりにくい。現在、IaaS を中心にクラウド・サ ービスも増えてきており、またクラウド技術がベンダーから購入可能になって来ているの で、今後の SaaS のクラウド化は加速していくと思われる。 ・デプロイメント・モデルに基づく整理 (1) パブリック・クラウド クラウド・コンピューティングで先行するプロバイダ各社がこのモデルによるサービス提 供を行ってきたので現時点では最も普及している。非常に多数の利用者でコンピューティ ング・リソースを共用するのでリソースの利用効率は非常に高いがセキュリティ等での懸 念がある。ウェブ・サービスと共通のビジネスモデルを採用しているため利用者への課金 は低額あるいは無料である。このような特性から利用者は個人あるいは SOHO が主力で ある。このモデルによる事業化はウェブ・サービスと同様に先行する海外のプロバイダが 圧倒的に有利であるため、日本国内のクラウド供給者はこのモデルによる事業化を敬遠し がちである。 (2) プライベート・クラウド パブリック・クラウドのリソース共有に対する懸念を背景に、昨年あたりから急激に立ち 上がってきたモデルである。ベンダーよりシステムとして導入するケースとプロバイダよ りサービスとして提供を受けるケースが存在するが、いずれも企業などのエンターブライ ズユースがターゲットと目されている。パブリック・クラウドよりもコンピューティング・ リソースの利用効率が低く、コスト負担に耐え得る大規模ユーザーでないとこのモデルは 利用できないことが利用者側の問題点である。現在、日本国内の供給者は先行する海外の 競合他社の優位性が影響しにくいこのモデルによる事業化を選択せざるを得ない。 (3) コミュニティ・クラウドおよびハイブリッド・クラウド 両者とも、ごく最近になって提示されるようになったモデルであり、未だ実績として確認 できる事例は尐ない。ハイブリッド・クラウドに関してはプライベート・クラウドを活用 する利用者が部分的にパブリック・クラウドとの連携を図る比較的現実的なシナリオが描 2 けるので今後の展開に一定の期待が持てるが、コスト負担の折半を前提とするコミュニテ ィ・クラウドに関しては利害関係が複雑化するのでデプロイメント・モデルとして定着す るかは不明である。 1.2.2 クラウド・コンピューティングの問題点 クラウド・コンピューティングの一般的な問題に詳しい"Above the Clouds: A Berkeley View of Cloud Computing"2 では「クラウド・コンピューティングの普及を妨げる 10 の問 題」[2]に言及している。ここでは各々の問題がどのような影響をもたらすかについて述べ る。 ○クラウド・コンピューティングの恩恵を最も享受する利用者 クラウド・コンピューティングのメリットを最も享受できるのはリソース需要が急激に拡 大する可能性のある利用者で、彼らが直面するであろうクラウド・コンピューティングを 利用する上での問題は「サービスの可用性」、「データの囲い込み」、「ストレージのスケー ラビリティ」が考えられる。特に「データの囲い込み」はプロバイダ移行の大きな障害と なる。特に既存の PaaS サービスはプロプラエタリ性が最も顕著な事例である。既存の PaaS は低コストでアプリケーション開発が容易だが、結果的にプロバイダが提供する開発 環境に依存することになるので、他のプロバイダに乗り換える必要が発生してもその判断 が難しくなる。 ○既存のエンドユーザーが得られるクラウド・コンピューティングのメリット リソース需要の変動が尐ない既存システムをクラウド化する試みは大きなメリットが得ら れないだけでなく「データの秘匿性と監査可能性」や「パフォーマンスの予測困難性」と いった新たな問題を抱え込む可能性がある。一般にエンタープライズ分野のクラウド活用 では、特に「データの秘匿性と監査可能性」の問題が付きまとうが、その対処にはより大 きなコスト負担が必要となるので、コスト負担に耐え得る事業規模を持つ大企業では既存 システムのクラウド化は進むであろうが、コストを負担できない中小企業の情報システム は相対的に立ち遅れることになり、セキュリティ懸念のあるパブリック・クラウドを利用 しなければ、クラウド・コンピューティングでのメリットはほとんど享受できないことに なる。 ○日本国内でクラウド関連ビジネスを行う事業者の課題 現在のクラウドビジネスは、顧客にクラウド技術を提供するシステム販売と顧客にクラウ ド・サービスを提供するプロバイダ事業の 2 種類の形態に概ね大別できる。システム販売 は主に顧客がプライベート・クラウドを構築する場合の需要に応じるものなので、パブリ ック・クラウドほどのリソース利用効率の向上は見込めず、そのコスト負担に耐え得る顧 2 末尾の付録 B を参照 3 客向けにしかビジネスは成立しない。一方、クラウド・サービスの提供は各社のリソース 需要を集約するのでリソース利用効率はサービスの顧客数に依存することになるが、顧客 総数を単純に比較するだけであれば、既にワールドワイドで事業を展開している海外のク ラウド・サービス事業者がコスト・パフォーマンス面で圧倒的に優位に立つ。これが国内 のクラウド・サービス事業者はニッチ・ビジネスを指向せざる得ない理由である。 ○日本の IT 産業に対するクラウド・コンピューティングの影響 クラウド・コンピューティングは本質的に、国境を越えてコンピューティング・リソース の集約と共用化による利用効率の向上を目指し、それによるスケールメリットを極限まで 追求してコスト・メリットに転換するパラダイムである。このパラダイムによりワールド ワイドでのコスト的最適化が推し進められるので、諸外国に比して高コスト体質にある日 本市場では国内需要の海外流出に直結する。業種によってその是非の議論は異なるだろう が、尐なくとも日本の IT 産業にとっては現在の国内 IT 市場の縮退を意味する。またコン ピュータインフラストラクチャに関わる技術的主導権を海外の事業者に委ねることになる ので、この分野での国際競争力は大きく落ち込む。さらに今後創出されるであろう IT 分野 での事業は海外の事業者の影響下に組み入れられる。 4 2．本事業で開発する技術 前節の現状分析により、本提案では (1) ハイブリッド・クラウドおよびコミュニティ・ク ラウドがサポートできる、(2) 情報の収集・分析に優れたクラウド・アプリケーションの開 発を支援するクラウド基盤技術を開発しオープンソース・ソフトウェアとして配布するこ とを提案する。 図 1 このソフトウェアを利用することにより、利用者は任意のマシン（所有する PC サーバーや 一般の IaaS サービスで利用できる仮想サーバーなど）の上にクラウド・アプリケーショ ンの開発環境を容易に構築することができ、作成したクラウド・アプリケーションを使っ てハイブリッド・クラウドやコミュニティ・クラウドとして機能させることができる。 2.1 技術的課題と課題解決のアプローチ このソフトウェアを開発する上での技術的課題は「独立した複数のクラウドの間での情報 交換」や「ウェブなどの外部情報サービスからの情報取得」といったクラウドと外部シス テムを統合する情報アーキテクチャを設計し実装することである。 本提案ではこの技術的課題を解決するためにクラウド・コンポーザビリティのコンセプト に基づくシステムの実現を目指す。クラウド・コンポーザビリティとは Toward a Unified 5 Ontology of Cloud Computing [3] において提示されているコンセプトで「一つ以上のクラ ウド・サービスを組み合わせて新たなクラウド・サービスを生成する能力」と定義されて いる。一般的なクラウド・システムは一つ以上のクラウド・コンポーネントから構成され、 各々のクラウド・コンポーネントはネットワーク経由のアクセスメソッドが用意されてお り、いわゆる XaaS のスタイルのサービスとして外部より利用可能である。クラウド・コ ンポーザビリティは各々のクラウド・コンポーネントが他の一つ以上のクラウド・サービ スを利用していることを示す属性と理解できる。 本提案のアーキテクチャ・モデルにクラウド・コンポーザビリティを導入するとクラウド が提供するサービスをクラウド・コンポーネントとして抽象化し複数のクラウド・コンポ ーネントの関係をシンプルに定義できるので、技術的課題である外部のクラウド・サービ スや情報サービスを包含したアーキテクチャをシンプルに表現する上で役に立つ。本提案 が提供する PaaS ベースのクラウド・アプリケーション開発環境では、クラウド・コンポ ーザビリティを定義する機能をサポートすることによりクラウド・コンポーネントとして 機能するクラウド・アプリケーションの開発を可能にする。 2.2 開発技術の新規性、革新性 クラウド・コンポーザビリティをサポートするためにはこの他にも幾つかのアプローチが 考えられる。 一つの方法は Cloud Software Infrastructure Layer（[3] のレイア 3）にクラウド間連携 に対応するクラウド・コンポーネントを追加していくアプローチである。この方法は Amazon Web Service (AWS) などで採用されているが、クラウド・システムをクラウド OS 的な視点で理解し、その構成要素を OS カーネルに類似するビルディングブロックに基づい て定義していくので全体アーキテクチャは非常に理解しやすいメリットがある。しかしな がら、個々の構成要素は全てのクラウド・アプリケーションで共用されるので共通性の高 い限られた機能しかサポートできず、利用するアプリケーション側の開発コスト（実装規 模）が増大する。またクラウドの機能を維持するためには構成要素には高い可用性が求め られるので維持・運用に大きな労力を必要とする。AWS のように既に多くの利用者を抱え ており、維持・運用に大きな投資が可能なプロバイダでは実用レベルでの可用性を達成で きるが、本提案が想定するクラウドの共同運用のような事例での可用性の維持・向上は運 用上の厳しい課題となる。 もう一つの方法はウェブ・サービスにおいて同様の機能を提供するサービス指向アーキテ クチャ (SOA) に基づく技術を導入するアプローチである。SOA の基本コンセプトは非常 に有効であり、ウェブ・アプリケーションを設計する上で考慮すべき概念として広く認知 6 されているが、それに基づいて設計されたツールやサービスはあまり普及していないとい う事実が問題点である。その原因については議論があるようだが、標準インタフェースと しての一般性を追求しすぎた結果、対応すべき仕様が膨大かつ複雑になり過ぎているとい うのが我々の見解である。アプリケーションが本来必要とする機能の開発コストよりも、 その機能を部品化するための開発コストのほうが遥かに大きいのでは実社会での定着は難 しい。 本提案の技術開発ではこのような他のアプローチの問題点を踏まえ、クラウド・コンポー ネント間のインタフェースの定義はアプリケーション開発者に委ねることとし、容易に理 解できる程度に単純かつ仕様の小さな開発環境を提供することでクラウド・アプリケーシ ョンの開発効率を向上させることを基本方針としている。運用規模の拡大が容易なクラウ ドのスケールアウト性を最大限に活用すると仮定すると、クラウド・アプリケーションの 設計時に必要な運用規模の想定は非常に困難である。ならば運用規模の拡大など各種の都 度対処は不可避と理解して、短時間で習得可能な小さく単純なアーキテクチャ・モデルの 定義とそれに対応するデバッグ環境を提供すれば、速やかな都度対処が可能になるであろ うと考えている。この考え方に基づき本提案では次の三つの機能の開発を計画している。 ・ クラウド間リソースディレクトリサービス ・ クラウド・アプリケーション向けデバッグ環境 ・ アプリケーション・フレームワークを拡張した自動スケールアウト機能 各々の内容については次の節で説明するが、ハイブリッド・クラウドやコミュニティ・ク ラウドで機能するクラウド・アプリケーションのデバッグ環境や自動スケールアウト機能 の既存事例は今のところ存在しない。 7 図 2 2.3 本事業全体での開発概要 本提案の事業は PaaS ベースのクラウド・アプリケーション開発環境の開発とそのオープ ンソース・ソフトウェア配布から成る。クラウド・アプリケーション開発環境の開発は次 の四つの工程からなる。 (1) クラウド・アプリケーション実行環境（PaaS コア）の開発 本提案が対象とするウェブベースのクラウド・アプリケーション実行環境を開発する。一 般的なウェブ・アプリケーションの実行環境と同様のスクリプト言語の実行エンジン、ア プリケーション・フレームワークに加え、クラウド・コンポーザビリティに対応する基本 インタフェースを開発する。詳細は次の節で説明する。 （平成 22 年度下期） (2) クラウド間リソースディレクトリサービスの開発 ハイブリッド・クラウドやコミュニティ・クラウドを実現するためには、アプリケーショ ンのクラウド・コンポーザビリティ対応だけではなく複数のクラウドの間でのコンピュー ティング・リソースを管理する機能が必要である。クラウド間リソースディレクトリサー ビスはクラウド間で透過的にリソース情報を共有するサービスで、これ自身はクラウド・ コンポーザビリティを活用したクラウド・アプリケーションとして開発されるが、耐障害 性を重視して P2P システムに見られるような非中央集中型でのインデックスサービスの実 装を計画している。 （平成 23 年度上期） 8 図 3 (3) クラウド・アプリケーション向けデバッグ環境の開発 本提案が対象とするクラウド・アプリケーションはウェブベースなので複数サーバーによ る並列実行が可能だが、多数のサーバーが稼動するクラウド環境においてアプリケーショ ンが異常終了した場合、異常状態の再現は非常に手間の掛かる作業になる。そこで前項の リソースディレクトリサービスを活用して、異常終了が発生したサーバーの探索と異常状 態再現に必要な各種データの取得をサポートしクラウド内の任意のマシンでクラウド・ア プリケーションのデバッグができる環境を提供する。（平成 24 年度下期） (4) アプリケーション・フレームワークを拡張した自動スケールアウト機能の開発 本提案が対象とするクラウド・アプリケーションはロードバランサーなどを活用して並列 化を行うことが可能だが、バックエンド・ストレージに対するアクセスが集中するため並 列実行には限界がある。多数の仮想サーバーを動的に追加できる IaaS の機能を積極的に 活用するため、アプリケーション・フレームワークを拡張してクラウド・アプリケーショ ンを自動的に多段化実行する機能をサポートする。アプリケーションの多段化実行とはア プリケーション・フレームワークにおいて定義されている並列実行可能なオブジェクトを その時点で利用可能な他サーバーを自動判別してリモート実行する機能である。（平成 24 年度下期） 9 2.4. クラウド・アーキテクチュアにおける PaaS クラウド・システムのアーキテクチュアは未だ一般的なコンセンサスが確立しているとは 言いがたい状況ではあるが、” Toward a Unified Ontology of Cloud Computing”3は次のレ イア構成を定義している。 図 4 この定義はクラウド・サービスが提供する機能をレイヤ構造で整理したものであるが、ク ラウド・サービスとして広く認知されている IaaS はコンピュータ・インフラストラクチュ ア相当の機能を提供しているので DaaS/CaaS とともに Cloud Software Infrastructure の レイヤに配置されている。一方、ソフトウェア開発プラットフォームを提供する PaaS は Cloud Software Environment のレイヤに配置されている。PaaS において開発されたソフ トウェアは必ずしもクラウド環境での稼働を前提とするわけではないがクラウド環境での 利用が可能な、例えば SaaS として利用可能なアプリケーションであることが多い。言い換 えれば、PaaS はクラウド環境での実行が可能な SaaS の開発を想定して利用されることが 多いので、IaaS/DaaS/CaaS といった Cloud Software Infrastructure の利用をサポートす る機能が期待される。必然的に PaaS には既存のオペレーティング・システムにおいてシス テムが持つ全ての機能が利用可能なプログラミング・インタフェースを提供するのと同様 の統合的な役割が期待される。 このようなクラウド OS 的な視点で理解すると IaaS/DaaS/CaaS が構成する Cloud Software Infrastructure はクラウド OS が提供するシステム・サービスに相当するのに対 3 末尾の付録 C を参照 10 し、Cloud Software Environment (PaaS) はクラウド・アプリケーションのためのプログ ラミング環境となる。 IaaS/DaaS/CaaS がその下位の Software Kernel と Firmware/Hardware (HaaS)にのみ 依存し、基本的には一つの機能を提供するサービスであるのに対し、PaaS はこれらの機能 を 統 合 す る 位 置 に 存 在 す る こ と が わ か る 。 ク ラ ウ ド OS 的 な 視 点 で 理 解 す る と IaaS/DaaS/CaaS が構成する Cloud Software Infrastructure はクラウド OS が提供する システム・サービスに相当するのに対し、Cloud Software Environment (PaaS) はクラウ ド・アプリケーションのためのプログラミング環境と理解できるのである。 Cloud Software Infrastructure に属する各 XaaS はそれ単体で有益なサービスを提供す る訳であるが、これらを組み合わせクラウドが有している潜在的な能力を最大限に引き出 すためには PaaS の関与は欠かせない。言い換えれば、クラウドが提供する個別のサービ スを統合し、一つの巨大なクラウド・コンピュータにまとめ挙げることも PaaS の役割と 言える。 2.4.1. PaaS の役割 Cloud Software Environment (PaaS) の第 1 の役割は、与えられたアプリケーションを Cloud Software Infrastructure が提供するスケールアウトするインフラストラクチュア の上で効率よく配置・実行することである。これによりアプリケーションの応答性能や処 理時間は大きく改善されるのだが、そのためにはアプリケーションが並列的に実行可能で なければならない。 次にそのための並列実行可能なアプリケーションの開発が容易なプログラミング環境を提 供することが PaaS の第 2 の役割である。PaaS が提供するプログラミング環境では Cloud Software Infrastructure が提供するさまざまなサービスが利用できる必要がある。 すなわち PaaS はアプリケーションのスケールアウトをより良くサポートする存在でもあ る。 11 2.4.2.アプリケーション実行環境とスケールアウト ここで SaaS のためのシステムとしては最も一般的なウェブ・アプリケーションを対象にス ケールアウトへの対応が異なる三つのアプリケーションの実行環境の事例を紹介する。 図 5 上記の図 5 は 1 台のサーバーで動作する非常に単純なウェブ・アプリケーションの構成で、 OS カーネルが対応できる範囲でスケールする、すなわちスケールアウトには対応していな い事例である。ウェブ・ブラウザからのリクエストに応じて httpd が同時並行的にウェ ブ・アプリケーションを複数起動する。実行されるプログラム・コードやプログラムが使 用するデータ等は原則としてファイルシステム上にファイルとして展開されおり、そのう ち更新データについては同時並行で実行されるアプリケーション間でのアクセス競合を回 避するためにロックなどを使用するか、アクセス競合を調停してくれる RDBMS などに格 納する。この場合は OS カーネル（および RDBMS）において並列実行に関わるアクセス 競合の調停が可能なので、ウェブ・アプリケーションの開発ではそれほどスケールを意識 する必要はない。 12 図 6 上記の図 6 は今日のウェブ・アプリケーションの実行環境として一般的な 3Tire アーキテ クチュアに準じた構成である。1 台のサーバーでは捌ききれないぐらい大量のリクエストを 受け付けるウェブ・サービスではこのような実行環境に移行せざるを得ない。原則として ウェブ・アプリケーション実行系を幾つかのコンポーネントに分割し、コンポーネント毎 にサーバーを割り当てていく構成を取る。大量のリクエストを捌くためにはウェブ・アプ リケーションを大量に起動できなければならないので httpd が動作するフロント・サーバ ーを並列的に配置する。実行中には改変されないプログラム・コードは何らかの手段を使 って全てのフロント・サーバーにデプロイされる。しかしプログラムが使用するデータに 関しては複数のウェブ・アプリケーション間での一貫性の保証が必要なため、DB サーバー に集約する形で格納される。 この構成では DB サーバーで稼動する RDBMS の性能限界までの範囲でスケールすること が可能である。ウェブ・アプリケーション開発では原則的には DB を利用するプログラミ ングを行うのだが、処理するリクエストや DB に格納しているデータが増大してきた場合 には何らかのチューニングを行わなければならなくなってくる。もっとも RDBMS はそも そもスケールアップには対応しづらい内部構造を持っているので、性能限界を引き上げる ためのチューニングにはおのずと限界がある。一方、近年のウェブ・サービスの高機能化 に伴ってウェブ・アプリケーションのフレームワークが RDBMS に格納するデータは飛躍 的に増大している。例えば、ウェブ・サービスの機能強化を行ったために RDBMS の性能 限界を超えてしまい、急激にサービスの応答性能が低下するような状況は今日のアクセス 量の多いウェブサイトでは日常的に発生している。これまで考えられていた抜本的な対策 は DB サーバー自体のグレードアップであったが、改善される性能に比してコスト高であ ることから最近では敬遠され始めている。 13 図 7 上記の図 7 はクラウド上でウェブ・アプリケーションの実行環境を構築した場合の構成で ある。このケースではフロント・サーバーには IaaS が提供する仮想サーバーを使用する ことができるので httpd はアクセス量に応じて任意に増減することが簡単にできる。DB サーバーに関しては DaaS が提供する Key-Value Store などを利用することでスケール アウト可能な構成となる。一見すると、クラウドに移行すればこれで既存のウェブ・アプ リケーション実行環境での問題は全て解決できるように見えるのだが、実際にはそうはう まく行かない。DaaS の Key-Value Store は既存の RDBMS と全く等価な機能が提供で きるわけではないからである。 Key-Value Store は文字通りキーと値のペアを格納するストレージでスケーラビリティに 優れた特性を発揮する。キーによる高速なデータ検索が可能なのでクラウド環境でのデー タベースとしての利用が期待されているが、スケーラビリティと引き換えに犠牲になるデ ータの整合性の問題が議論になっている。Key-Value Store では変更したはずのデータが 更新されていないという状態が発生する可能性がある。これは多数の仮想サーバーが自律 的に動作するクラウド環境では、データの変更を全ての仮想サーバーに瞬時に伝達するこ とができないことに起因するもので、データの整合性を重視する RDBMS とは対照的な特 性を Key-Value Store は持っている。 14 2.4.3. PaaS と DaaS の関係 この問題をクラウド・アプリケーションの視点で見た場合、これまでは RDBMS に任せて いたデータの整合性に関するケアをアプリケーション自身で対処しなければならないこと を意味している。具体的にはアプリケーションが利用する各種オブジェクトを管理してい るアプリケーション・フレームワークは永続的に保持しなければならないデータについて 格納先（RDBMS or Key-Value Store）の特性に応じて取り扱い方法を変える必要が出てく るのである。前述のデータ整合性の問題はもちろんのこと、クラウド内部ネットワークの 帯域幅の消費を節約するためには永続的オブジェクトのデータ構造や表現形式もクラウド 環境に合わせて最適化する必要がある。つまり PaaS がサポートするソフトウェア・プラ ットフォームは DaaS がサポートするストレージと密接な関係にあるのである。 こ の 問 題 に つ い て 、 既 存 の 著 名 な PaaS で あ る Google App Engine と Microsoft Windows Azure は 非 常 に 対 照 的 な 解 決 ア プ ロ ー チ を 取 っ て い る 。 App Engine は Key-Value Store としては非常にシンプルな機能を提供する BigTable を使用し、既存の アプリケーション・フレームワークの機能を制限して（サンドボックス化）提供している。 App Engine は現時点で Python と Java の 2 種類のプログラミングをサポートしている が両者は Key-Value Store レベルでのデータ交換性はない。これに対し Azure は今のと ころ Key-Value Store の機能を RDBMS レベルまで引き上げる技術的にアグレッシブな アプローチを選択した。Azure では .NET がサポートする多様なプログラミング言語が利 用できるそうだが、Key-Value Store レベルでのデータ交換を念頭において開発が進めら れている。 現在のところ Key-Value Store は未だ研究開発の段階にありデータ整合性問題の解決策に ついては様々な提案されている状態なのだが、その技術動向はアプリケーション・フレー ムワークに直接的な影響を与えること、また逆に現時点でメジャーなアプリケーション・ フレームワークを早期にサポートする Key-Value Store が今後のクラウド環境でのデファ クト・スタンダードになり易いことに留意しておく必要がある。 15 2.4.4. PaaS システムの既存事例 – Google App Engine for Python 前述の PaaS システムの技術課題を解決するための方策は様々考えられるが、その一例と して Google App Engine for Python （GAE/P）の事例に着目する。GAE/P はウェブ・ア プリケーションを開発するためのプラットフォームであり、開発されたアプリケーション は Google が提供するクラウド環境において SaaS として利用することが可能である。アプ リケーションが Google の設定した上限を超えてリソースを消費した場合には課金が発生す るが、制限範囲内では無料で SaaS を運営することができる。 Google は GAE/P 用の SDK をソースコード含めて BSD ライセンスにて公開しているが、 SDK に含まれるコードを解析した結果わかった GAE/P の内部構造を下記に示す。 図 8 GAE/P は一般的な Python によるウェブ・アプリケーションのソフトウェア構造に準じて おり、Google が提供する各種サービスへのプログラミング・インタフェースをサポートし ている。既存のウェブ・アプリケーション・フレームワークとの併用も可能で、GAE/P SDK はアプリケーション開発者とって「Google が提供する各種サービスを利用できる拡張 API」 と見なすことができる。 GAE/P SDK が提供する機能は次の二つに大別できる。 16 ランタイム GAE/P アプリケーションの起動時にアプリケーション環境を整えるためランタイムルー チンである。Google の他のサービスとの連携を保つためのアカウント・サービスの呼び出 しはここで行う。 サービス GAE/P はアプリケーションに対し各種サービスを提供するが、それを利用するための API が GAE/P SDK には収録されている。GAE の中核となる DataStore API に加え各種のサ ービスが利用可能である。また GAE/P はアプリケーション開発に有益なユーティリティ・ サービスも含まれており、既存の Python ベースのウェブ・アプリケーション・フレームワ ークとの併用が可能である。 17 3．平成 22 年度の開発 平成 22 年度の開発では PaaS システムの中核である PaaS Core と HTTP フロントエンド の開発を行う。PaaS システムは基本的には GAE/P と同等のクラウド対応可能なウェブ・ アプリケーションの実行環境の提供を目指すが、最終的にはさまざまなスクリプト言語を サポートすることを前提に平成 22 年度は PHP のサポートに絞って実装を行う。 3.1. 平成 22 年度の開発概要 図 9 に平成 22 年度の開発範囲を示す。図中の黄色のボックスは異なるサーバーの上で稼働 するソフトウェアである。 図 9 平成 22 年度の開発範囲 本事業の初期段階にあたる平成 22 年度は、前述の 2.3. の第 1 項「クラウド・アプリケー ション実行環境」の開発を行った。 （図 9 参照）この開発では解決すべき三つの技術的課題 があるが、実施計画書で掲げた開発項目は次のように対応する。 PHP スクリプト実行環境のクラウド環境への対応 本課題は開発項目の「ベースエンジンの構築」（以降、ベースシステム）に対応する。 クラウド環境特有の「システム規模が動的に大きく変化する分散環境」において PHP スクリプトを正しく駆動させるためには「ノード依存関数への対処」や「セッション 情報の管理」を行う必要がある。 18 ウェブ・コンテンツを格納するストレージのサポート 本課題は開発項目の「複数のバックエンド・ストレージ実装のサポート」 （以降、バッ クエンド・ストレージのサポート）に対応する。ウェブ・サービスを提供する一般的 なシステムにおいて負荷分散に対応する場合、そのコンテンツは分散環境でのデータ 共有をサポートするリレーショナル・データベース（RDBMS）に格納されることが多 いがクラウドのスケールアウト特性に対応することが難しく、クラウド環境では Key-Value Store（KVS）を利用することが多い。現在ユニークな機能を持つ様々な KVS が多数提案されているが、そのプログラミング・インタフェースには互換性がな い。そこで PaaS Core では様々な KVS を利用可能な統一的なプログラミング・イン タフェースのサポートを行った。 クラウド・コンポーザビリティに対応する基本インタフェースのサポート 本課題は開発項目の「クラウド・コンポーザビリティ属性を含むメタデータのサポー ト」 （以降、メタデータ管理）および「HTTP トラフィックに対するスケールアウトを 考慮したロードバランシング」 （以降、HTTP フロントエンド）に対応する。クラウド・ コンポーザビリティを実現するためには同一クラウド内およびクラウド間での管理情 報の共有を実現する必要がある。そのための主たる開発は 2.3.の第 2 項「クラウド間リ ソースディレクトリサービス」において実装するが、クラウド・コンポーザビリティ に関わる初期の検討、およびそれに基づくクラウド・アプリケーション実行環境から の基本インタフェースの定義と実装は平成 22 年度に先行的に着手した。 3.2. ベースシステム ベースエンジンの構築は平成 22 年度開発の中核であり、その開発作業では PHP で実装さ れたウェブ・アプリケーションを実行する PHP ZendEngine（ベースエンジン）に対して PaaS が動作するクラウド環境に適合させるため機能的な改修を行った。 「PaaS が動作するクラウド環境」とは原則的には一般的なウェブ・アプリケーション実行 環境とほぼ同様であると考えてよいが、IaaS などにより提供される仮想サーバーで動く可 能性があること、さらにスケールアウトにより仮想サーバーの総数が動的に変化すること を考慮しなければならない。すなわち「動的にシステム規模が大きく変化する分散環境」 においてウェブ・アプリケーションを動作させることになるので、特定のサーバーに依存 する実装を極力排除できることが望ましい。このような動的変化のある分散環境に適応す るため GAE/P ではサンドボックス化など幾つかの工夫が施されているが、PaaS Core では その方法を参考に PHP ZendEngine の改修を行なった。 19 3.2.1. ノード依存関数への対処（サンドボックス機能） PHP がサポートする機能には稼働しているノード（サーバー）に依存する関数が含まれて いる。例えば、ノード内のプロセス制御を行なう関数などがそれにあたる。このようなノ ード依存関数は動作しているノード内でしか機能が有効にならないため分散環境では意味 をなさなず、アプリケーション開発者に不用意に操作しないように呼び出しを制限するサ ンドボックス化を実装する必要がある。本開発では PHP の拡張を利用して、関数毎に呼び 出しの許可/禁止を設定できる機能を実装した。 ＊ローカル・ファイルへのアクセスの例外処理 ノードのローカル・ファイルへのアクセス関数もノードに依存する関数である。例えば、 ウェブ・アプリケーションがデータをローカル・ファイルに退避する時には、まずはデー タをファイルに書き出し、その後このファイルからデータを読み込む。この場合、データ の読み込み処理を実行する際には既にローカル・ファイルに所定のデータが書き出されて いることを仮定しているが、仮にローカル・ファイルへの書き出しと読み込みが異なるノ ードで実行された場合にはこの仮定が崩れて読み込み処理は失敗する、すなわち「ノード 間でのデータの一貫性」が欠如している状態になる。この場合は読み込み処理を実行する 前に書き出しを行ったノードに存在するローカル・ファイルを読み込むノードにコピーす る「ノード間でのデータの同期」を行う必要がある。 しかしながら ZendEngine およびウェブ・アプリケーション・フレームワークは主に起動 時の初期化処理の際にローカル・ファイルへのアクセスを行っており、ローカル・ファイ ルへのアクセスを禁止した場合には ZendEngine やウェブ・アプリケーション・フレーム ワークが機能しないので、何らかの例外的対処を行う必要があった。そこで例外的対処の 必要なローカル・ファイルへのアクセスについて次のように整理した。 ZendEngine でのローカル・ファイルへのアクセス ZendEngine でのローカル・ファイルへのアクセスはスクリプトのキャッシュによるもので、 この場合は同一のスクリプトを参照し、さらに一度書き込みが行われた後は読み込みしか 行われないので、キャッシュ・データの内容はどのノードでも常に一致する。したがって 特別な対処を行わなくてもデータの一貫性は維持される。 ウェブ・アプリケーション・フレームワークでのローカル・ファイルへのアクセス ウェブ・アプリケーション・フレームワークでのローカル・ファイルへのアクセスは各種 定義ファイルの読み込みによるもので、このアクセスは原則としてウェブ・アプリケーシ ョン起動時に一度読み込まれると終了時までアクセスされることはない。したがってウェ ブ・アプリケーションの起動直前にローカル・ファイルの同期を行えば問題は回避できる。 20 なお、これらの例外的対処はベースエンジン内部にて実装されアプリケーション開発者に は隠蔽されている。ウェブ・アプリケーションからのローカル・ファイルへのアクセスは 禁止されるので、データの格納にはバックエンド・ストレージ等を利用しなければならな い。 3.2.2. セッション情報の管理 セッション情報はウェブ・アプリケーションにおいてノード間でのデータ一貫性を厳格に 保証しなければならないデータの一つである。一般にコンピュータの対話的操作を行う際 にログインからログアウトまでの期間をセッションと呼ぶが、ウェブ・アプリケーション においてセッションを実現する場合にはアプリケーション内部でアプリケーション利用者 を識別するために必要なセッション情報を保持する。ノード間でこの情報の一貫性が保証 できなければ「ログインをしたのにログイン状態にならない」あるいは「操作途上で勝手 に他の利用者からアクセスしていることになる」といった様々な致命的なトラブルが発生 する。ウェブ・アプリケーションにおけるセッション情報の管理機構の実現については様々 な方式が知られているが、PHP アプリケーションの場合には PHP で標準サポートされる セッション情報を管理する機能を利用してセッションを実現することが一般的である。し かしこのサポートは内部的にはセッション情報をローカル・ファイルに格納する実装を行 っており。この実装ではクラウド環境でのノード間でのデータ一貫性は保証できない。 そこで PaaS Core では PHP が標準サポートするセッション情報の管理機構との API の互 換性を有し、クラウド環境でも正しく動作するセッション情報の管理機構の実装を試みた。 基本的にはセッション情報をローカル・ファイルではなく、ノード間でのデータ一貫性を 保証できる外部ストレージに格納する方法を採用している。外部ストレージにはバックエ ンド・ストレージを使用することもできるのだが、セッション情報はウェブ・アプリケー ションから頻繁に参照されることを考慮し、高速アクセスが可能なコンテンツ・キャッシ ュ（memcached）を使用している。 21 3.3 メタデータ管理 2 章ではインターネット経由で接続可能なクラウド間を連携させるクラウド・コンポーザビ リティについて述べたが、本項で説明する「メタデータの管理」および次項で説明する 「HTTP フロントエンド」はクラウド・コンポーザビリティのための開発項目として構想 されている。クラウド・コンポーザビリティ実現の中核的な開発は平成 23 年度に着手する 予定の「リソース・ディレクトリ」の開発が相当するが、平成 22 年度に着手した上記の二 つの開発項目はそのための基盤として位置づけている。 3.3.1. HTTP フロントエンドとメタデータの役割 クラウド・コンポーザビリティはクラウド間連携を定義するコンセプトであるが、その技 術的基盤としてクラウド間の情報交換機能を必要とする。本事業が想定するプラットホー ム・レベルでのクラウド間情報交換の枠組みを図 10 に示す。 図 10 クラウド間の情報交換 プラットホーム・レベルでのクラウド連携では PaaS が他のクラウドに対して何らかのリク エストを発行して情報を交換することになるが、本事業の PaaS において他のクラウドから のメッセージを受け付けるのは原則として HTTP フロントエンドであり、メタデータによ るメッセージを受け取るものと定義した。各々の詳細は後述する。 22 図 11 最も単純なシステム・モデル 3.3.2. クラウド間連携に関する想定 次に考えなければならないことは「クラウド間でどのような情報を交換するのか？」とい うことである。クラウド・コンポーザビリティのコンセプトでは様々な形態のクラウド間 連携が考えられ、クラウド向けプラットフォームの開発を提案する本事業の本来の立場に 基づけば「さまざまな形態のクラウド間連携を可能限りサポートする」と表明せざる得な いのだが、そのための基本機能を開発するにあたってはクラウド・コンポーザビリティを 実現するシステムについて何らかの具体的な想定をせざる得ない。ここではメタデータ管 理の設計段階で検討した本事業が想定するクラウド間連携について説明する。 クラウド・コンポーザビリティを実現する最も単純なシステムのモデルを図 11 に示す。こ れは、パブリック・クラウドで運営されているウェブ・サービスに連動するプライベート・ クラウドで運営されているウェブ・サービスの事例で、例えば企業においてインターネッ トに公開されている一般的なウェブ・サービスを活用しながら、独自の社外秘情報を追加 したウェブ・サービスを社内のみで運用するようなケースを想定している。Web API など 従来のウェブ・サービス連携の機能を利用して上記と類似のオリジナル・サービスのデー タを活用して付加価値を高めた拡張サービスを開発することもできるが、本事業ではクラ ウドのスケールアウト特性に適応できる形に既存の連携技術を拡張することを検討しなけ ればならない。 23 図 12 DaaS 連携システム・モデル 次にクラウド・サービスを連携させるシステム・モデルを示す。図 12 は二つの DaaS を束 ねて一つのクラウド・サービスとして見せるモデルである。このモデルはハイブリッド・ クラウドに対する実際的な要求、例えばプライマリとセカンダリの二つのストレージを用 意してクラウド・サービスのデータ信頼性を向上させる、また異なるクラウド・サービス 事業者へ移行する際の過渡的な運用など、実際のクラウド・サービスの利用において発生 し得る課題への対策を想定している。このモデルでは PaaS を利用して開発した管理システ ムにより DaaS の保守・運用を行うことを想定している。一般的な DaaS では外部から利 用可能な API が提供されることもあるが、事業者間での API の標準化が進んでいない現状 ではこのようなシステムの開発には大きなコストが発生する。本事業の PaaS にはこのよう な開発の効率改善に寄与するサポートが求められる。 さらにクラウド・サービスを連携させるシステム・モデルを示す。図 13 は既存の IaaS を 連携させて一つの Meta IaaS（仮想的な IaaS）として機能させることを想定したモデルで ある。IaaS の生成時あるいは起動時に必要なサーバーの初期イメージなどは予め DaaS に 展開しておいて、それを参照して IaaS の生成・起動を行う。スケールアウト可能な IaaS を連携させる必要性に疑問を持つ向きもあろうが、実際には IaaS のサービス内容やコスト の問題からこのような連携が必要になるケースは多いと思われる。また現時点では国内の IaaS では操作インタフェースがされてないためにオンデマンドで直接 VM の生成や制御が できないサービスの方が多いので、IaaS 向け代替操作インタフェースとしての需要も高い だろう。 24 図 13 Meta IaaS システム・モデル 以上の三つのケースが現時点で「近い将来需要が発生するであろう」と考えるクラウド間 連携システムの想定モデルである。クラウド・コンポーザビリティのコンセプトを適応で きるモデルは他にも多数考えられるであろうし、今後クラウド・サービスの利用が拡大し て行くにしたがって更に複雑なモデルも出現するであろうが、まずはこの三つのクラウド 間連携システムの定義に必要なクラウド間で共有すべき情報を明らかにするところから検 討を進めている。 3.3.3 メタデータのデータ形式 本事業の PaaS システムで使用するメタデータのデータ形式は YAML を採用することに 決定した。本 PaaS システムのリファレンスとなっている Google AppEngine において採用 されていることと PaaS システムのターゲット言語となっている PHP とシステム実装に使 用している C/C++ の各々に対応するオープンソース・ライブラリが利用可能であることが 主な選定理由である。 平成 22 年度は PHP ベースの syck/spyc を利用することとし、関連する実装は「ベースエ ンジン構築」の作業と一体化して進めた。なお平成 23 年度に開発を予定している「リソー ス・ディレクトリ」では C/C++ベースの実装を必要としているが libyaml/yaml-cpp を利用 する検討をしている。 25 3.4. HTTP フロントエンド HTTP フロントエンドは基本的に HTTP リバース・プロキシーの機能を提供する。HTTP リバース・プロキシーはウェブ・サービスを稼働させる HTTP サーバーよりもクライアン トよりに配置される代替サーバーであり、HTTP サーバーの隠蔽、リクエストの負荷分散、 コンテンツのキャッシング、各種プロトコル変換などウェブ・サービスの運用上必要な様々 な役割を担う。 HTTP フロントエンドでは HTTP リバース・プロキシーの機能に加え、前節で述べたよう にクラウド間情報交換のためのメッセージ・ゲートウェイ機能や同一クラウド内の制御な どを行う。HTTP フロントエンドの概要を図 14 に示す。 図 14 HTTP フロントエンド HTTP フロントエンドは PaaS Core を外部からのアクセスに対して隠蔽するとともに、次 の機能を提供する。 リクエストの負荷分散 セレクタによりラウンドロビンで PaaS Core にリクエストを転送する。 プロトコル変換 HTTP プロトコルを FastCGI プロトコルに変換する。HTTPS プロトコルはその前段で暗号の復号化 を行う。 メッセージ・ゲートウェイ 平成 22 年度開発ではメッセージ・ゲートウェイはノード情報のリストを管理するのみである。最終 的には PaaS Core とのメッセージ交換を行う予定だが、この開発は平成 23 年度のリソース・ディレ クトリの開発範囲となる。 26 図 15 3.5. バックエンド・ストレージのサポート 一般にクラウド環境でのストレージやデータベースには Key-Value Store (KVS)に代表さ れる分散ストレージが利用される。Google AppEngine ではストレージ利用が PaaS として 課金の対象になるため利用できるストレージを BigTable に限定しているが、機能的に優れ たオープンソース KVS が多数公開されている現状を鑑みると、今後利用者は複数の分散ス トレージを目的に応じて選択する時代になることが容易に想像できる。本開発ではこのよ うな多種多様なストレージ・システムを併用してクラウド環境を運営する状況を先取りし、 PaaS から複数のストレージ・システムを同時に並行して利用できる「バックエンド・スト レージ・サポート」機能の開発を盛り込んだ。 3.5.1. ストレージ・サポートのコンセプト 本開発でのストレージ・サポートのコンセプトを上記の図 15 に示す。 ストレージ・サポートは PaaS アプリケーションに対し多種多様なストレージ・システムを 同時に並行して利用可能な統一的なインタフェースを提供する。これにより開発者は 1 セ ットの API さえ学習すれば PaaS Core がサポートする全てのストレージ・システムを利用 することができる。 本開発では GAE/P がサポートする GQL（Google 独自の SQL のようなクエリー言語）が 定義するアプリケーション向けの標準的なインタフェース（Datastore API）に基づく互換 クエリーエンジンを開発し、その下位に各ストレージ・システムとのインタフェースを行 うストレージ・ドライバを配置するアーキテクチュアを定義した。Datastore Bridge は複 数のストレージ・システムを切り替えるディスパッチャであり、SQL データベースに置け る ODBC/JDBC と良く似た役割を果たす。 27 図 16 3.5.2. 想定している利用シナリオ 本開発では著名な KVS である MongoDB と Cassandra に加え、ウェブ・アプリケーショ ンでは最もよく使われている MySQL をストレージ・システムとしてサポートする。クラ ウド環境との親和性には問題点の多い RDBMS を敢えてサポートすることには、次のよう な利用シナリオの想定がある。 クラウド・サービスへの段階的移行（上記の図 16 参照） 一般的なウェブ・アプリケーションは RDBMS をストレージとして利用することが多いが、これらの ウェブ・アプリケーションをクラウド環境に移行するためにはストレージを RDBMS から KVS への データベース移行が必須となる。そこで次のような段階的移行のシナリオを想定した。 Step1: オリジナル・アプリケーションを PaaS に搭載 Step2: クエリー処理のみを GQL ベースに書き換え Step3: データベース自体を KVS に移行 このシナリオに従えば、ターゲットとしている KVS の機能やサポート範囲を確認しながら 段階的なデータベース移行が可能となる。 データ一貫性への対処策 トランザクション処理などデータベースのデータ一貫性が重視されるアプリケーションで は、データ一貫性を犠牲にしてスケーラビリティを確保している KVS の利用には限界があ る。しかしながらアプリケーションからの視点で見た場合、データベースに格納する全て のデータに対して厳格なデータ一貫性が保証される必要がないことが多い。現実的な対策 としてデータ一貫性が厳格に求められるデータに関しては RDBMS に、そうではない大容 量あるいは大量のデータに関しては KVS に、とデータの特性に合わせてストレージ・シス テムを使い分ける方法が有効である。 28 図 17 3.5.3. ソフトウェア構造 ストレージ・サポートのソフトウェア構造を上記の図 17 に示す。原則的には GAE/P の GQL 実装に基づくが、複数のスクリプト言語および複数のストレージ・システムをサポー トするため、全体は次の三つのレイアから構成される。 Language （L） プログラミング言語依存レイア 各スクリプト言語によるインタフェース実装であり、個々のスクリプト言語固有のデータ 表現の変換を行う。平成 22 年度の開発範囲では PHP のみをサポートしており、スクリプ ト言語に依存しないデータ表現の定義は行っていない。 Query Engine （QE） GQL 互換クエリーエンジン GAE/P の GQL 実装を模倣した C++ による互換クエリーエンジンであり、 （Python と C++ の仕様の違いに基づく相違点を除き）原則的に GQL との互換性がある。内部的には GQL と Filter の 2 階層構造になっているが、これは GAE/P の GQL 実装に起因する。 Storage Support （S） ストレージサポートレイア GQL 実装のストレージ向けインタフェースから Key-Value Store 固有の API への変換を 行うストレージ・ドライバである。DataStore Bridge も含め全て C++ による実装を行っ ている。平成 22 年度の開発範囲では MongoDB、Cassandra、MySQL をサポートしてい る。 29 3.6. 平成 22 年度開発の総括 平成 22 年度の「クラウド・アプリケーション実行環境」の開発により次の項目が達成され た。 PHP スクリプト実行環境のクラウド環境への対応 前述の「ベースエンジン」開発により、複数のノード（サーバー）で PHP スクリプト が分散実行できることを確認した。但し、ノード総数の動的な変更（スケールアウト） は平成 23 年度に開発を予定している「クラウド間リソースディレクトリサービス」の 機能を必要とするため、現時点では動作を確認していない。 ウェブ・コンテンツを格納するストレージのサポート 「バックエンド・ストレージのサポート」において Google AppEngine の GQL 互換の クエリー（問い合わせ）をサポートするとともに、MongoDB、MySQL、Cassandra の 3 種類の KVS/RDB をサポートした。特に MySQL をサポートしたことにより既存 のウェブ・アプリケーションのクラウド対応を段階的に進めるシナリオを提示できた ことはクラウド・コンピューティングの推進に寄与すると考えている。 クラウド・コンポーザビリティに対応する基本インタフェースのサポート 「メタデータ管理」および「HTTP フロントエンド」の開発作業により「クラウド間 リソースディレクトリサービス」開発の足場は整った。さらに「メタデータ管理」の 設計作業の一貫として検討したクラウド間連携の想定モデルによりクラウド・コンポ ーザビリティによるクラウド間連携の具体的なイメージが提示できるようになった。 30 付録 A. National Institute of Standards and Technology URL: http://www.cs.ucsb.edu/~lyouseff/CCOntology/CloudOntology.pdf クラウド・コンピューティングは未だ発展過程のパラダイムであり、現状では関連するベ ンダーやプロバイダによって多種多様なアプローチが試みられているので、その技術的な 実像は非常に理解しづらい。米国標準技術局 (NIST: National Institute of Standards and Technology) が公開する "The NIST Definition of Cloud Computing" ではクラウド・コン ピューティングの現状を踏まえて「ネットワーク経由で要求できるコンフィグレーション 可能なコンピューティング・リソースの共有型プールのモデル」と定義し、要件、サービ ス・モデル、デプロイメント・モデルの三つの視点から網羅的な説明を試みているが、そ の概要は以下のとおりである。 図 18 The NIST Cloud Definition Framework # Effectively and Securely Using the Cloud Computing Paradigm より 31 ・クラウド・コンピューティングの要件 (1) オンデマンド セルフ・サービス 利用者は必要に応じてコンピューティング・リソースを自らの手で確保できる。 (2) 多様なネットワーク・アクセス ラップトップや PC などの一般的なコンピュータだけではなく携帯電話や PDA などの各種 のシン・クライアントからのネットワーク・アクセスをサポートできる。 (3) リソースの集約と動的割り当て プロバイダのコンピューティング・リソースは集約され、利用者の要求に応じて速やかに 動的割り当て（および開放）することができる。利用者は原則としてリソースのロケーシ ョンを意識する必要はないが、国、州、データセンターといった抽象的な単位で指定する ことも可能である。 (4) 迅速な伸縮性 クラウド・システムは非常に高速なスケールが可能なので、利用者はいつでも必要な量の リソースを無制限に調達することができる。 (5) 利用量計測に基づくサービス クラウド・システムはストレージや回線容量、ユーザー・アカウント数といったサービス の種別に応じた抽象的な単位に基づいて利用者ごとのリソース利用量を計測し(場合によっ ては自動的に）制御や最適化を行う。またプロバイダと利用者の間で透過的に監視・制御・ 報告することができる。 ・クラウド・コンピューティングのサービス・モデル (1) Cloud Software as a Service (SaaS) 利用者はクラウド・インフラストラクチャの上で稼動するプロバイダが提供するアプリケ ーションを利用することができる。例外的にアプリケーションが用意しているコンフィグ レーションの一部を設定することができる場合もあるが、原則的には利用者がクラウド・ インフラストラクチャをコントロールすることはできない。 (2) Cloud Platform as a Service (PaaS). 利用者はクラウド・インフラストラクチャにアプリケーションを展開し、実行することが できる。このアプリケーションはプロバイダが提供するプログラミング・ツールを使用し 32 て開発される。一般にクラウド・インフラストラクチャの制御はプロバイダが提供する SDK などに隠蔽されているで、直接操作ことはない。 (3) Cloud Infrastructure as a Service (IaaS). 利用者はプロバイダが用意しているプロセッサ、ストレージ、ネットワークおよびその他 のコンピューティング・リソースを設定して、オペレーティング・システムを含む任意の ソフトウェアを実行することができる。利用者がクラウド・インフラストラクチャ全体を 管理することはできないが、確保しているリソースに限れば一定の制御が可能である。 ・クラウド・コンピューティングのデプロイメント・モデル (1) プライベート・クラウド 単一の組織によって運営されるクラウド・インフラストラクチャ。 (2) コミュニティ・クラウド 共通の関心を持つ特定のコミュニティをサポートするために複数の組織で共有されたクラ ウド・インフラストラクチャ。 (3) パブリック・クラウド 一般に公開されているクラウド・インフラストラクチャで、クラウド・サービスを販売す る会社によって所有されている。 (4) ハイブリッド・クラウド 実体としては独立しているが、データやアプリケーションのポータビリティを実現する標 準的（あるいはプロプライエタリ）な技術により結び付けられている複数の（プライベー ト、コミュニティ、パブリック）クラウドを組み合わせたクラウド・インフラストラクチ ャ。 33 付録 B. Above the Clouds: A Berkeley View of Cloud Computing URL: http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.pdf 「クラウド・コンピューティングの普及を妨げる 10 の問題」 (Top 10 Obstacles and Opportunities for Cloud Computing) "Above the Clouds: A Berkeley View of Cloud Computing"ではクラウド・コンピューティ ングのトレンドが更に加速していくと仮定し、そのために克服する必要がある 10 の課題を 掲げ、現時点で考えられる解決策について述べている。 1 サービスのダウンタイムの問題 商業ウェブ・サービスを運営している事業者が抱くクラウド・コンピューティングへの疑 問の一つにクラウド・サービスが十分な可用性を備えているか、すなわち自社サービスの ダウンタイムに対する影響の懸念がある。実際、Google の検索サービスはいつでも使える し、もし Google の検索サービスが利用できなければ利用者はインターネットがダウンし ていると判断するくらいである。クラウド・サービスに対してもこれと同じレベルの可用 性が期待されるが達成するのは簡単ではない、つまり既存の SaaS はこの点について高い 基準を設定していることになる。 公開されている情報に基づけば、実際の Amazon EC2/S3 や Google App Engine では 2～8 時間のダウンタイムが年間に 1、2 回発生したと報告されている。これが十分な可用性を持 つと判断できるのか、あるは不十分であると考えるかは意見の別れるところだと思いうが、 一般的な企業の IT インフラストラクチャの可用性としてみた場合には非常に良い成績を収 めているとは言えるだろう。 もっとも一つの事業者が提供するクラウド・サービス自体がハイ・アベイラビリティ・コ ンピューティングの領域で言うところの「単一障害点」と見なすことができる。事業者の データセンターやそれに至るネットワーク経路など設備的な可用性リスクも考えられるし、 加えてここしばらくはクラウド・サービスからの撤退などの事業的なリスクもある。こう いったリスクに対応可能な戦略がなければ、企業はクラウド・コンピューティングへの移 行に躊躇するだろう。 クラウドを利用したサービスの可用性を高める基本的な対策は、複数のクラウド・サービ ス事業者を利用することである。これは大規模なインターネット・サービス・プロバイダ ーが複数のネットワーク事業者を利用することにより、任意のネットワーク事業者の障害 によってサービス停止とならないよう備えるのと同じ戦略である。もしコスト面を度外視 し可用性の向上だけを考えるのであれば、異なる複数のクラウド・サービス事業者のサー 34 ビスを利用し、各々に対して異なるアプリケーション・ソフトウェアを搭載することによ り同じサービスを実現することが望ましいだろう。しかしアプリケーション・ソフトウェ アの開発および維持・管理コストを考えると、これはあまり現実的な方策ではない。実際 には複数のクラウド・サービス事業者を使って同じアプリケーション・ソフトウェアを稼 働させる選択が現実的だが、これの選択は後述するクラウド・サービス間のインターオペ ラビリティの問題を顕在化させることになる。 2 クラウド・サービス間のインターオペラビリティ 現時点ではクラウド・サービス事業者が提供する API は依然として基本的にプロプラエタ リな状態にある。クラウド API に関する標準化に向けた試みが幾つか存在するが、尐なく とも今のところは積極的な議論されている状態ではない。したがって利用者による任意の サイトから別のサイトへのアプリケーションやデータの移行にはかなりの労力を必要とす る。これはクラウドのデータ・ロックイン問題と呼ばれ、前述の特定のクラウド・サービ ス事業者への依存リスク回避の戦略を考える上での大きな懸念にもなり、結果クラウド・ コンピューティングの採用を手控える判断に繋がる。 クラウド・サービス事業者にとってデータ・ロックインによる顧客の囲い込みは魅力的な 側面も否定できないのだが、クラウド・サービスの利用者にとっては価格の引き上げ、信 頼性の問題、過渡的な状態にある現状ではクラウド・サービス事業者自身の事業撤退など の様々なリスクに晒されることを意味する。これに対する明快な解決策はクラウド API の 標準化を推し進めてクラウド・サービス間のインターオペラビリティを確保することであ る。その結果クラウド・サービスの利用者は複数のクラウド・サービス事業者を横断的に 活用してサービスやデータを展開することが可能になり、いずれかの事業者が倒産や事業 撤退に追い込まれても、自社のサービスやデータが道連れになることは避けられる。しか しながらこの解決策に対する明確な懸念は、クラウド・サービスの価格競争を引き起こす ことによりクラウド・サービス事業者の利益の低減や均一化を繋がりかねないことにある。 そもそもデータセンターの巨大化によるスケールメリットがなければ事業として成立しな かったクラウド・コンピューティング領域において見込まれる利益の縮退は新規参入を企 図する事業者を抑制する大きな要因になってしまうことは明らかである。 この問題は本質的に一般的な産業における需給バランスの問題で、近い将来起こるであろ うクラウド・サービス事業者の淘汰が落ち着いた先には一定のバランスが形成されている と推測される。現時点ではその状態に至るまで状況の推移を見守るしかないことは明らか である。将来もクラウド・コンピューティング事業が存続し続けられる状況に誘導するた め、現時点での需給両社の懸念を緩和する次の二つの方策が指摘されている。 35 まずクラウド・サービス事業者側の対策として品質と価格を合わせて考えるサービス・ク ラスの分化・明確化が上げられる。これまでのところクラウド・コンピューティングのメ リットとして低コストばかりが喧伝されてきているが、このプロモーションの行き着く先 は上記のとおりクラウド・サービスの安値安定状態である。これを回避するためには高利 益が期待できる新しいクラウド・サービスのクラスの設定とそのための技術開発が不可欠 であり、今後クラウド・サービス事業に参入する事業者にとっては事業化の突破口になる と思われる。 次にクラウド・サービス利用者側のデータ・ロックイン問題の対策としては、プライベー ト・クラウドの活用が現在盛んに議論されている。クラウド・サービス利用者が所有可能 なプライベート・クラウドはクラウド間のインターオペラビリティ問題においてある種の 緩衝壁的な役割を担うことができる。つまり特定のクラウド・サービスと等価なソフトウ ェア・スタックがプライベート・クラウドでも利用できれば、尐なくとも個々の利用者の 影響範囲ではパブリック・クラウドとプライベート・クラウドの間ではインターオペラビ リティを確保することができる。このパブリックとプライベートのクラウド連携はデー タ・ロックイン問題を解消するだけでなく、サージ・コンピューティングなど様々なメリ ットが提案されておりここ数ヶ月で最もヒートアップしているトピックの一つである。焦 点となるのはプライベート・クラウドで利用可能な PaaS を実現するソフトウェア・スタッ クであり、ここで確立されるデファクト・スタンダードが将来的にはクラウドの標準 API になるのではないかと思われる。 3 データの秘匿性と監査可能性 主にエンタープライズ分野のソフトウェアをパブリック・クラウドを利用してクラウド化 する際に必ず議論になるのが、データの秘匿性と監査可能性の問題である。この問題には 技術的な側面と制度に関わる側面がある。 まず技術的な側面だが、クラウド化に際しソフトウェア・アーキテクチャに対する変更を 求めない IaaS の場合には、原則的に従来の一般的な方法がそのまま適応できる。但しパブ リック・クラウドはインターネットからのアクセスが可能になるので、これに起因して追 加で検討しなければならない課題が幾つか増える。一方、PaaS の場合にはアプリケーショ ン・フレームワークなどがエンタープライズ・ニーズに対応している必要があるので、そ の条件を満たす PaaS 事業者を探さなければならない。見方を変えれば、クラウド・サービ ス事業者にとってはこのようなニーズが高利益を上げられるサービス・クラスのヒントに なると思われる。 厄介なのは制度に関わる側面である。日本に限らず多くの国々ではセキュリティ監査、内 36 部統制等の法規制が存在するため、規制の対象となるシステムを国外のデータセンターで 稼働させることは禁止されている可能性がある。また逆にデータセンターが存在する国の 法律により政府機関によるデータ等へのアクセスを義務付けられている場合もある。パブ リック・クラウドの利用ではこのような国ごとの制度の違いによる様々な制約が顕在化す る可能性がある。この種の制度は国内産業保護や国際競争力の向上なども考慮される各種 の政策の影響を受けるので、制度変更的な対策はなかなか進展しない。 この問題の抜本的な対策は国内法の制約が守られる国内にクラウド向けデータセンターを 建設することだが、今のところ海外のクラウド・サービス事業者は日本国内でのデータセ ンター建設には余り積極的ではないし、海外の事業者と競争できるクラウド・サービス事 業者は日本国内には見当たらないのが現実である。結局、現時点での最も現実的な対策は 「データの秘匿性や監査可能性が求められるシステムはプライベート・クラウドを活用す る」ということになると思う。 4 データ転送のボトルネック 現在のクラウド・コンピューティングの致命的な弱点の一つはデータ転送のボトルネック である。これはクラウド・データセンタが持つ処理能力やデータ格納能力に比べて、イン ターネットのデータ転送能力が極めて低いことに起因している。ウェブ・サービスを活用 した EC サイトなどが普及した今日、アプリケーションが取り扱うデータは急激に増え続け ているので、そのデータ転送に関わる時間的・金銭的コストは非常に重いものになってし まう。論文“Above the Clouds”では、この問題に関して非常に興味深いトピックを二つ紹介 している。 一つは時間的コストに関わる事例で、とある生物学研究所の 500GB のデータを生成する実 験を行うためにクラウドを利用するべきか？否か？という検討である。生物学研究所が所 有する 20 台のクラスタでの実行時間は 50 時間であるのに対し、Amazon EC2 のインスタ ンス 1000 台を利用して同じ実験を行った場合の実行時間は 1 時間、費用にして 150 ドル程 度なる計算だった。ところがこの実験データを Amazon のデータセンターから研究所まで 20Mbps のレートで転送すると転送に要する時間は 55 時間にかかる計算になったというこ とである。 もう一つは金銭的コストに関わる事例で、インターネット経由でのデータ転送よりも宅配 便を使ってディスクを送付した方が安上がりであるという計算である。10TB のデータを 20Mbps のレートで転送すると転送に要する時間は 45 日以上かかり、 Amazon からは 1000 ドル請求されるのに対し、1TB のディスク 10 個を宅配便を使って送付すると翌日には配達 され、その費用も 400 ドルで済む。しかもディスクの容量やギガバイト毎の値段などのコ 37 スト・パフォーマンスはネットワークの場合よりもはるかに速く向上しているので、大き なデータ転送の場合は宅配便でディスクを送るという選択肢は毎年魅力を増していると報 告している。 これらの事例はクラウドとのデータ転送の手段として「宅配便でディスクを送る」方法が 極めて有効であることを示しているが、残念ながらこれらの事例はアメリカ国内での話で ある。現在の宅配便サービスを使えば日本からでも時間的・金銭的コストは微増する程度 （インターネット経由でのデータ転送と比較して）で収まりそうだが、これらの事例では 想定されていない問題が発生する可能性は否定できない。 第 2 のデータ転送のボトルネックの回避策としてクラウドでマスター・データの保存・管 理を行うというコペルニクス的発想の転換が紹介されている。この方法であればデータ転 送の重要度自体が低下するので頻度も抑えることができ、実際的なデータ転送ボトルネッ クが顕在化する機会を減らすことができる。もっとも、このシナリオはクラウド・サービ スが提供するストレージが安全かつ安心であること、さらに前述のデータの秘匿性と監査 可能性の問題がクリアになっていることがその前提となる。現実的に考えればデータの消 失や漏洩が発生しても比較的に影響の尐ない広報データの公開サービス（例えば企業のホ ームページなど）などの用途ではあまり問題にならないだろうが、クラウド・サービス利 用者がデータ管理に何らかの義務を負うウェブ・サービスなどでは極めてリスクの高い方 法と言わざるを得ない。 結局、データ転送のボトルネックの本質的な原因はルーターやスイッチといったネットワ ーク関連機器の（コンピュータやディスクに比較した）コスト・パフォーマンスの悪さに 起因している。現在の WAN の帯域コストの 2/3 はインターネットや ISP のバックエンド に配置されているハイエンド・ルーターのコストで占められており、これが WAN サービス の料金が高止まりしている最大の原因だと指摘されているし、クラウド内のネットワーク においてもコンピュータを接続するスイッチの性能がデータ転送ボトルネックの最大の要 因だと指摘する声もある。これらのネットワーク関連機器の高性能化と低価格化が更に進 めば、この問題が大きく緩和されることは間違いない。具体的にはハイパフォーマンス・ コンピューティング向けに開発された高速ネットワーク機器や NIC などを使えばクラウド 内ネットワークのスループットは改善される。しかし残念ながらこれらの製品は今のとこ ろ非常に高額である。まずは現在のクラウド・コンピューティングのブームによりこれら の製品の需要が高まり低価格化が進むことを期待したいところである。さらには 10 ギガビ ットイーサネットの低価格製品の普及、あるいはハイエンド・ルーターのコスト・パフォ ーマンスの向上が望まれる。 38 5 予測不能なパフォーマンス 仮想サーバーを提供する IaaS では仮想化の影響によりパフォーマンスの予測が難しく、こ の問題は仮想マシンの間での IO の衝突が主たる原因であることが指摘されている。つまり 仮想サーバーを使うとディスクや NIC へのアクセスの際の IO レートのバラツキ幅が大き く、結果的に同じアプリケーションを実行した時の処理時間が多くブレてしまう結果にな る。これはクラウドが得意とするバッチ処理（実行時間が数時間以上かかる）とって処理 起動時に何時になったら処理が終了するのか予測できないなどの大きな影響を与える。 この問題は現在の PC アーキテクチャが仮想マシンでの利用に十分対応できていないこと 起因する。マルチコア・タイプのプロセッサが一般化した今日、プロセッサ自身の仮想化 対応は既に行われており、仮想サーバーを使用した場合でもプロセッサとメモリの間での コミュニケーションはうまく動くようになっている。これに対しプロセッサと IO バスのコ ミュニケーションでは不効率な振る舞いがあるということになる。この問題に対する抜本 的な対策は PC アーキテクチャを仮想化を考慮した形に変更することで、この問題に既に対 処済みのメインフレームのアーキテクチャが直接の参考になる。具体的にはブリッジ・チ ップの設計を見直すプロセッサ・メーカーの仕事になるし、IO バス周りのアーキテクチャ を改変すると OS の IO システム周辺のコードの変更も必要になる。インテルや AMD とい ったプロセッサ・メーカーが主導で新たなブリッジ・チップが開発され、それに連動して OS 開発者がブリッジ・チップをサポートする作業を行うことになるだろう。 このような抜本的な対応が行われるまでの暫定的な対処策として、SSD などのフラッシュ メモリを活用したディスクを活用することが考えられる。IO レートのバラツキが特に顕著 なのは応答時間の要する機械式ハードディスクを使用した場合である。これに対しフラッ シュメモリを活用した SSD などはアクセス時間が格段に早いため、仮想化に伴う IO 衝突 を緩和してくれる効果がある。この場合の問題は機械式ハードディスクよりも容量が尐な いこととコストが高いことである。この問題もプロセッサ・メーカーが解決すべき課題に なる。 6 スケーラブルなストレージ 「要求に応じて容量無制限にストレージを確保できる」特性はクラウド・コンピューティ ングのメリットの一つだが、 「暗黙のうちに永続的なデータ保存を期待されるストレージ本 来の要求を現在のクラウドのストレージ・システムは満たす事ができるのか？」という問 いに即座には答えられない。もちろんストレージの使用量に対しても課金されるクラウ ド・サービスを使って格納した全てをデータを永続的に保管するようなニーズは現実には 考えにくいのだが、 「仮に無限のコスト負担が可能な利用者が現れたと仮定した場合に、ス トレージ・システムがこの利用者にサービスを提供し続けるために何らかの技術的障害は 存在しないか？」と理解すべきだろう。 39 一般にストレージ・システムには単にデータの格納・参照・削除といった基本機能だけで はなく、多様なクエリーやパフォーマンスの保証、複雑なデータ構造のサポートといった スケーラビリティの拡大を疎外する様々な機能の実現も求められる。このような機能的な 充実を図るとおのずとスケーラビリティが犠牲になる。これは高度な機能をサポートする リレーショナル・データベースは分散化が非常に難しいという事実からも自明だろう。す なわちストレージ・システムにおいて機能性やパフォーマンスとスケーラビリティはトレ ード・オフの関係にあり、両者をどのようにして両立させるかがストレージ・システムの 研究開発での一つの命題である。 実際に Google や Amazon のデータセンターでは数千台のコンピュータで構成されるクラス タを使ってストレージ・システムを稼動させていると言うが、数万台あるいは数十万台で 構成されるストレージ・システムの事例は聞かない。現在のストレージ・システムを安定 的に稼働させるためには、スケーラビリティは数千台が限界であること物語っているのか もしれない。もちろんスケーラビリティという視点で、これが技術的な限界というわけで はない。例えば P2P システムの事例を見れば、数十万台規模のスケーラビリティを持つス トレージが実現可能であることは明らかである。もっとも P2P システムにおいてクラウド のストレージ・システムと同等の機能性やパフォーマンスの実現にも技術的な困難さがあ る。 「無限にスケールアップするストレージ」というと漠然としたある種哲学的な課題のよう にさえ聞こえるが、クラウド・サービス事業者にとってこれは極めて現実的な問題である。 なぜならば今、現在もクラウド・サービスの利用者は増え続けているし利用者 1 人あたり のストレージ使用量も増え続けているからである。したがって「スケーラブルなストレー ジ」はクラウド・コンピューティングにとって常に存在する普遍的な命題であり、且つ日々 向上が期待される切実な技術課題でもある。 7 大規模分散システムにおけるデバッグ手段 クラウド・コンピューティングにおける困難なハードルの一つに、非常に大規模な分散シ ステムでのデバッグがある。小規模な構成では現象が再現しないバグは普通に存在し、そ の場合は実際のデータセンターと同じ規模でデバッグを行わなければならない。この種の バグとしては多数の処理が並列的に実行される場合に発生するバグ、あるいはクラウドを 形成するマシンが障害停止をするなど想定外の環境で実行した場合に発生するバグなどが 考えられる。 このようなバグが存在するため、クラウド・コンピューティングでは分散環境でのデバッ グを回避できないが、その作業には非常に困難が伴う。特に骨が折れるのがバグが発生し 40 たマシンとソフトウェアを突き止めることである。大量のマシンを使っている場合にはバ グが発生したマシンを特定するだけも労力が掛かるし、バグの発生により連鎖的な異常停 止を引き起こしている場合にはバグの発生源の特定自体が難しくなる。このような分散環 境でのデバッグを支援するデバッガーの情報は全く見かけない。おそらくデバッガー開発 の前提となるクラウド環境での一般的なデバッグ手法そのものが、まだ確立していないか らだと思われる。 8 リソースの節約 利用した分だけ支払う従量課金制が建前のクラウド・コンピューティングで「リソースの 節約」なんてちょっとおかしな話に聞こえるかもしれない。しかしクラウド・サービス事 業者が設定している課金体系によっては、実際には使っていないリソースにも課金されて しまうことがある。これは計算処理、ストレージ、ネットワークの各々に細かくチャージ する IaaS では特に注意しなければならない事柄で、例えば Amazon EC2 の場合、実際に は何のプログラムも動かしてなくても、仮想サーバーのインスタンスを生成するだけで時 間に対し課金される。単位時間当たりにチャージされる金額は非常に小額だが、これも積 もりに積もると結果的に大きな額になってしまう。 この問題に対処するためにはクラウド・サービスの利用者自身が使用しているリソースの 管理しなければならない。例えば、特定のアプリケーションを実行するためだけにクラウ ド・サービスを使うのであれば、アプリケーションを起動する前処理としてクラウドのリ ソースを確保する（Amazon EC2 であればインスタンスを生成する）ようにし、アプリケ ーションが終了すれば直ちにクラウドのリソースを開放する（Amazon EC2 であればイン スタンスを削除する）ようにしておけば良いだろう。 一方、サーバーを常時実行しておかなければならないウェブ・サービスなどのインフラな どにクラウド・サービスを活用するのであれば、リソースの管理方法はもう尐し複雑にな ってくる。仮想サーバーの負荷状態を常時監視して、負荷が上がってきた場合には追加で リソースを確保し、負荷が下がってきた場合にはリソースを開放する、つまりクラウド・ コンピューティングのスケールアウト動作を利用者の手で制御する必要が出てくる。この 仮想サーバーのスケジューリング制御をオペレータが手作業で行うのはなかなか骨が折れ る。何らかの自動化ツール、できれば負荷状態を予測しながら仮想サーバーの数を最適化 してくれるツールがあると便利だが…これではマシンラーニング（機械学習）の研究テー マになってしまう。 本来こういう問題はクラウド・サービスで対応してくれるありがたいわけだが、この種の スケジューリング方法は対象となるアプリケーションの振る舞いに大きく依存するので、 41 通常はアプリケーションが決まらないとスケジューリング方法も決まらない。したがって ウェブ・アプリケーション限定の Google App Engine などではフル・オートマチックなス ケジューリングがサポートできるが、仮想サーバーを提供する IaaS の場合はアプリケーシ ョンが特定できないので、利用者にその役割を任せざるを得ないのである。 「リソースのスケジューリングを利用者に任せる」ということはクラウド・サービス利用 者がミスをすればその分だけ費用を徴収できるのでクラウド・サービス事業者は丸儲けだ と考える方もいるかもしれない。でも実際にこういったリソースの浪費はクラウド・サー ビス事業者も負担が強いられる。例えば Amazon EC2 のインスタンスは全く使用していな い状態でもフルパワーで利用している時に使用する電力の 2/3 を消費する。つまり、利用者 が個々に行っているわずかなリソース浪費もデータセンター全体で合わせると膨大なエネ ルギー浪費になってしまうのである。この課題はエコロジーについて盛んに議論されてい る今日的な問題でもある。 9 悪評の伝播 パブリック・クラウドもサービスとして提供されるので、他のサービスと同じように悪意 ある利用者が紛れ込むことは起こり得る。その結果クラウド・サービス全体に影響するよ うな問題が発生することは容易に考えられるだろう。例えばクラウドをスパムを送信する ために使うことも可能である。その結果として、クラウド・サービス事業者が持つ IP アド レスがスパム排除サービスのブラック・リストに掲載される事態が考えられる。こうなる と他のクラウド・サービス利用者が送ったメールもスパムとして排除されることになる。 また“Above the Cloud”ではクラウド・サービスの高可用性の論拠として DDOS 攻撃への耐 性をあげているが、そこで紹介されている DDOS 攻撃の方法は短期間レンタルされた大量 のボットネットを利用して特定のサーバーへ攻撃を仕掛けるというものである。これは対 クラウド向けの攻撃手段としてクラウドを活用できることも示唆している。実際 IaaS が提 供する「短期間に大量のコンピューティング・リソースを用意できる」メリットは、DDOS 攻撃に必要なリソース要件と非常に良く合致する。そのような意図を持った悪意ある利用 者が合法的にクラウド・サービスのアカウントを取得したり、既存のクラウド・サービス 利用者に成りすましてクラウドへ侵入する可能性は否定できない。そして仮にクラウド・ サービスが DDOS 攻撃の手段として活用された場合、他の利用者へどのような影響を与え るかは定かではないが、クラウド・サービス事業者が悪評判により大打撃を受けることだ けは間違いない。 この問題は他の IT サービスと同じ対処策が取られることになるだろう。クラウド・サービ ス事業者は悪意ある顧客の排除に努めることになる。また、万が一に備え提供するサービ 42 スにも何らかの制約を設けざるを得ない。例えば Google App Engine では無償ユーザーの プログラム実行は 1 回 30 秒間以内に制限されている。このような正当な利用者の妨げにな らずに悪意ある利用者の行動を抑制できる制限が設定されるだろう。そして不幸にして事 故が起こった場合にはクラウド・サービス事業者は法的責任の転嫁、すなわち事故の責任 は事業者ではなく事故を引き起こした利用者にあると主張するだろう。クラウド・サービ ス利用者も自身のアカウントを破られクラウドに侵入されることがないように慎重な行動 を取るべきである。とはいえ、こうなってしまってはもはや悪評の伝播は回避できないの だが… 10 ソフトウェア・ライセンス クラウド・コンピューティングが従来の商用ソフトウェア・ライセンスと相性が良くない ことは当初より指摘されていた。必要に応じて都度生成される仮想サーバーに対して付与 されるソフトウェアの使用許諾などナンセンスの極みである。これまでクラウド・サービ ス事業者の多くは、オープンソース・ソフトウェアに依存してサービスの拡充に努めてき たが、これもクラウド・コンピューティングのパラダイムが従来の商用ソフトウェア・ラ イセンスに基づくビジネスの枠組みの外で発展してきた理由の一つだろう。 この問題は既に解決の方向に向かい始めている。IBM や Oracle は既に Amazon EC2 の利 用者向けにクラウド向けライセンスの設定を行っている。このような流れに向かったのは、 やはりクラウド・コンピューティングに積極的なマイクロソフトの動向に負うところ大き いだろう。マイクロソフトは早い段階で Amazon EC2 に対してウィンドウズを始めとする 各種ソフトウェアのクラウド向けライセンスの設定を行った。マイクロソフトとしては Windows Azure へ向けた足がかり的な意味もあるのかもしれないが、結果としてこの問題 の収束を促す効果があった。 現状で強いて問題を上げればクラウド向けライセンス料金は尐々高めであることである。 数ヶ月利用すれば製品版を購入するのと同じコストを負担する価格設定をしている例もあ る。”Above the Cloud”では、クラウド・サービス事業者向けにバルク販売のディスカウン トを適用することによりクラウド・サービス利用者のコスト負担低減ができるとの提案を しているが、現在クラウド・サービスで利用可能商用サービスの価格がどのようなプロセ スを経て決定されたかは調べようがない。おそらく今後はクラウド・サービス利用者に対 し「本数限定」や「期間限定」と銘打って商用ソフトウェアが低価格で提供されるように なるのではないだろうか。 この問題の新しい側面はプライベート・クラウドの登場に起因する。おそらく企業内情報 システムなどで導入されるであろうプライベート・クラウドに対しても、全く同じソフト 43 ウェア・ライセンスの問題が発生するからである。おそらく既存の商用ソフトウェア・ベ ンダーとしては従来のクラスタ向けのライセンスの適用で解決したいと考えているだろう が、高額すぎて悪評の高い Oracle などのライセンス事例には反発が必至だと思う。結果的 にソフトウェア・ベンダーは製品版ライセンス、パブリック・クラウド向けライセンス、 プライベート・クラウド向けライセンスの三つのライセンス形態を考え、自社の戦略に合 致するようバランスを取りながら収益の拡大を目指すことになるように思う。 商用ソフトウェアの視点から見た場合、クラウド・コンピューティングのブームはオープ ンソース・ソフトウェアの台頭で揺らいだ商用ソフトウェアのビジネスモデルにさらに痛 撃を与える現象と捉えるべきなのではないかと思う。今後パブリック・クラウドが更に成 長を続け、社会の IT 需要の多くがそこへ吸い上げられていくとしたら、1990 年あたりか ら続いてきた商用ソフトウェアを軸にした IT ビジネスのパラダイムは完全に崩壊すること になり、それにより高収益を上げてきたソフトウェア・ベンダーは衰退を余儀なくされる だろう。最強のソフトウェア・ベンダーであるマイクロソフトが Windows Azure でクラウ ド・コンピューティングのビジネスに参入しようとしていることは、同社がこのパラダイ ム・シフトは不回避であると認識していることの表れかもしれない。その結果、このパラ ダイム・シフトは更に加速されることになったように見え、その他のソフトウェア・ベン ダーは今むずかしい選択を迫られているのかもしれない。ソフトウェア・ライセンスはソ フトウェア・ベンダーの生命線であるので、この最後の課題は今後しばらく様々な観点で 議論が続けられることになると思う。 44 付録 C. Toward a Unified Ontology of Cloud Computing URL: http://www.cs.ucsb.edu/~lyouseff/CCOntology/CloudOntology.pdf "Toward a Unified Ontology of Cloud Computing" は現在も議論が進んでいるクラウド技 術を統合する試みである。 この論文では、クラウドを構成するコンポーネントが XaaS 的考え方に基づいて単独のサ ービスとして利用可能である特性に着目し、複数のクラウド・サービスを組み合わせて新 たなクラウド・サービスを定義するコンポーザビリティ (composability) というコンセプ トを導入しており、それに基づき次の 5 層構造のレイヤ・モデルによるアーキテクチャを 定義している。 図 19 Cloud Computing Ontology 45 - Layer 1: Cloud Application Layer クラウド・アプリケーションは一般的な SaaS と同義と考えてよい。クラウド・オントロ ジではクラウド・アプリケーションはクラウド・ソフトウェア・エンバイロンメントにお いて開発されることを仮定しているので、このレイヤは SaaS の利用者だけでなく SaaS の開発者にもメリットを与える。課題や制限についても一般的な SaaS で議論されている、 アプリケーションの可用性、利用者データのセキュリティ、既存アプリケーションからの 移行、障害復旧、SLA の信頼性などが挙げる。 - Layer 2: Cloud Software Environment Layer このレイヤではクラウド・アプリケーションを開発するためのプログラミング環境、すな わち PaaS を提供する。したがって、このレイヤの利用者はクラウド・アプリケーション の開発者であり、彼らにはクラウドのスケールアウトする環境をより良く活用するための ランタイム環境に加え、プログラミング言語と API、さらに開発したアプリケーションを クラウド内で高速に展開するなどの各種サポートが提供される。この論文では具体例とし て Google App Engine と Salesforce の Apex を紹介している。さらに開発効率を向上さ せる手段として Hadoop や Yahoo の Pig にも言及している。 - Layer 3: Cloud Software Infrastructure Layer このレイヤは上位レイヤに対し基本的なコンピューティング・リソースを提供する。既存 のクラウド・システムの中にはシステム効率への懸念からこのレイヤの機能を利用しない 事例も存在するが、システム効率とシステム構築・運用のコストのトレード・オフにより 利用の是非は決定される。このレイヤをさらに計算リソース、データ・ストレージ、コミ ュニケーションの三つのカテゴリに分けて取り扱っている。 + 計算リソース 仮想化技術を利用した IaaS を提供する。利用者に仮想マシンを委ねることができるので、 利用者にとっては極めて高い柔軟性が提供されるが、現在の仮想化技術では仮想マシン間 の性能的な干渉を完全に回避することはできないので、サービスとして SLA の厳格な保証 はできないのが難点である。 + データ・ストレージ 分散ストレージ技術を利用した DaaS を提供する。分散ストレージの一般的な要件である 可用性、信頼性、性能、複製、データ一貫性が、このカテゴリの技術的課題である。実装 には分散ファイルシステム、分散データベース、Key-Value Store など選択肢に幅がある が、前述の可用性とデータ一貫性はトレード・オフの関係にあるので、選択には熟慮が必 要である。 46 + コミュニケーション ネットワーク・コミュニケーションに QoS 保証を付与するための CaaS を提供する。こ のカテゴリは前述の二つのカテゴリに比べ耳慣れないが、クラウド・サービスの性能保証 において重要な役割を果たす。通常クラウド・コンポーネントはネットワークを介して接 続されるが、クラウド・システムの規模拡大とともに顕在化してくるのがクラウド・ネッ トワークの帯域幅消費問題である。ネットワークが混み合うことにより、コンポーネント 間の通信速度が低下するとクラウド全体のパフォーマンスも低下する。特に通信レートな どの保証が必要なストリーム系サービスの場合にはその影響は甚大で、特定の通信に関し てはレート保証をする必要があるが、そのサービスを行うのが CaaS である。 クラウド・ソフトウェア・インフラストラクチャはオプショナル機能的な側面が強い。比 較的に小規模なクラウド・システムであれば仮想化サーバーや分散ストレージの導入は必 須ではない。しかしながら伸縮性が特徴のクラウド・システムを維持するためには、必要 に応じて動的に物理的リソースを追加していける仮想化されたリソース管理の仕組みが必 要になる。 - Layer 4: Software Kernel このレイヤはクラウドを構成する物理サーバーのソフトウェアの管理を行う。論文ではサ ーバーの資源管理や稼動状態監視などに優れたクラスタリング・ミドルウェアに言及して いる。これは既存のグリッド・コンピューティングやクラスタ・コンピューティングの研 究成果であり、その事例として Globus と Condor を紹介している。 - Layer 5: Firmware and Hardware このレイヤでは実際のハードウェア（サーバーやネットワーク・スイッチなど）を管理す る HaaS を提供する。数台から数十台程度の尐数のハードウェアしか所有していなければ、 このレイアでの議論はあまり意味のない。したがって、このレイヤの利用者は大量のハー ドウェアを所有・管理しているデータセンターや大規模イントラネットの運営者などに限 定される。 管理するハードウェアが数百～数千の場合、個々の機器の電源投入だけでも大変な労力を 必要とする。[3] ではその手段としてリモート制御とスクリプト実行が可能なブートローダ ーを取り上げ、具体例として PXE や U-Boot を紹介している。また、そのよう手段を使 っている事例として IBM の Kittyhawk（並列型のスーパーコンピュータ）も紹介してい る。 47