(57)【要約】【課題】  クラウド上のリソース管理技術の提供【解決手段】サーバー・コンピュータがクライアント・コンピュータの処理要求の中で必要になったリソースを、ネットワーク上の仮想的なリソース空間から取得する。また、サーバー・コンピュータはこの取得にあたり、前記サーバー・コンピュータ自身の持っているリソースと比較し、前記サーバー・コンピュータ内のリソースがより新しければ仮想的なリソース空間のリソースを書き換える手段を備えており、コンピュータ・システムは１つのサーバー・コンピュータに対してリソースを配置するだけで、コンピュータ・システム上のすべてのサーバー・コンピュータから同じファイル、データなどを用いたサービスを、クライアント・コンピュータを通じてユーザーに提供することが出来る。【選択図】図３
2013069252.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続された１以上のサーバー・コンピュータと、前記サーバー・コンピュータに処理を要求する手段を備えることを特徴とする１以上のクライアント・コンピュータで構成されることを特徴とするコンピュータ・システムであって、前記サーバー・コンピュータが前記クライアント・コンピュータの処理要求に応じるために必要なファイルやデータなど電子的に保存されうるリソースを取得する際、前記サーバー・コンピュータ間で共有した、ネットワーク上の仮想的なリソース空間からファイルやデータを取得する手段を備えることを特徴とするコンピュータ・システム。
【請求項２】
請求項１に記載したコンピュータ・システムにおいて、前記リソースが仮想的なリソース空間にはないが前記クライアント・コンピュータから処理の要求を受けたサーバー・コンピュータに当該ファイルないしデータがある場合、前記ファイルないしデータを仮想的なリソース空間に保存する手段を備えることを特徴とするコンピュータ・システム。
【請求項３】
請求項１に記載したコンピュータ・システムにおいて、前記リソースが仮想的なリソース空間にもクライアント・コンピュータから処理の要求を受けたサーバー・コンピュータ内にもある場合、どちらのリソースが新しいかを判断するステップと、前記サーバー・コンピュータのリソースがより新しい場合は仮想的なリソース空間のリソースと置き換えを行うステップが存在し、仮想的なリソース空間のリソースを更新する手段を備えることを特徴とするコンピュータ・システム。
【請求項４】
請求項１、請求項２および請求項３に記載したリソースの取得・保存・更新を行う手段を備え、且つ、仮想的なリソース空間をネットワーク上に離散的に保持する手段を備え、且つ、仮想的なリソース空間の複製を持ち、高アクセス時および障害時に複製したリソース空間のリソース用いることを可能とする手段を備えたコンピュータ・システム。
【発明の詳細な説明】
【技術分野】
【０００１】本技術は、ネットワークに接続された１以上のサーバー・コンピュータと、前記サーバー・コンピュータから必要なファイルやデータを取得する手段を備えたことを特徴とする１以上のクライアント・コンピュータとで構成されることを特徴とするコンピュータ・システムに関する。
【背景技術】
【０００２】ネットワーク上にコンピュータ・システムからサービスを提供する場合、提供者はサーバー・コンピュータに対して必要なデータおよび必要なロジックを含んだソフトウェアを配置し、利用者はクライアント・コンピュータからサーバー・コンピュータにアクセスすることで必要なサービスを享受する。【０００３】１９９０年代、Ｗｅｂアプリケーションの提供が盛んになった頃からサーバー・コンピュータにデータベースシステムを持たせ、データ管理ロジックとアプリケーションロジックを分割する３層アーキテクチャ（３−ｔｉｅｒ  ａｒｃｈｉｔｅｃｔｕｒｅ）が用いられるようになった。データ管理ロジックはリレーショナル・データベース・マネージメント・システム（ＲＤＢＭＳ）が保持しており、データ操作のための特別な言語（ＳＱＬ）でデータの登録・更新・抽出を行うことが一般的である。【０００４】２０００年頃、クラウド・コンピューティングが注目されると、データを複数台のサーバー・コンピュータに分散、離散的に保持するｓｈａｒｄｉｎｇという形が登場した。ｓｈａｒｄｉｎｇでは、これを統括する役目を果たしているデータベース・ルーティング・システムにアクセスすれば、すべてのデータに対して登録・更新・抽出を行うことが出来る。
【発明の概要】
【発明が解決しようとする課題】
【０００５】クラウド・コンピューティングでは複数サーバー・コンピュータでのアプリケーション運営が前提となる。これは１つのアプリケーションが効率的にクラウド上コンピュータのリソースを使うためだけでなく、他のアプリケーションへのデータ、ＡＰＩの提供、システムへのアクセシビリティの確保に於いても重要な前提条件となる。【０００６】ここで「リソース」とは、オペレーティング・システムにおけるテキスト文書、バイナリ文書、画像、動画などのファイル、データベース・システムにおけるカラム、レコード、ドキュメントなどのデータ、またはアプリケーション自体を動作させる前記ファイルやデータ形式のモジュールを含む、不揮発性ハードウェアに保持されうるすべての電子的情報を指す。【０００７】構築したコンピュータ・システムを動かすためのモジュール、ファイルやデータは通常、各サーバー・コンピュータのリソースを用いるため、各サーバー・コンピュータに配置する必要がある。従って、アプリケーションモジュールを更新した場合に配置したモジュール、ファイルやデータは各サーバ・コンピュータに対して逐次更新処理を行う必要性が生じる。【０００８】クラウド・コンピューティングにおいてサーバー・コンピュータはスケーラブルに増減するため、各サーバーにファイルを配信する方法では配信洩れや配信時の一部のサーバーへの障害が生じ易い。また、サーバー・コンピュータ数が増加するほど管理コストが増大するという、デメリットを生じさせてしまう。
【課題を解決するための手段】
【０００９】本発明は上記課題を解決すべくなされたもので、請求項１に記載の発明は、ネットワークに接続された１以上のサーバー・コンピュータと、前記サーバー・コンピュータに処理を要求する手段を備えることを特徴とする１以上のクライアント・コンピュータで構成されることを特徴とするコンピュータ・システムであって、前記サーバー・コンピュータが前記クライアント・コンピュータの処理要求に応じるために必要なファイルやデータなど電子的に保存されうるリソースを取得する際、前記サーバー・コンピュータ間で共有した、ネットワーク上の仮想的なリソース空間からファイルやデータを取得する手段を備えることを特徴とするコンピュータ・システムである。【００１０】請求項２に記載の発明は、請求項１に記載したコンピュータ・システムにおいて、前記リソースが仮想的なリソース空間にはないが前記クライアント・コンピュータから処理の要求を受けたサーバー・コンピュータに当該リソースがある場合、前記リソースを仮想的なリソース空間に保存する手段を備えることを特徴とするコンピュータ・システムである。【００１１】請求項３に記載の発明は、請求項１に記載したコンピュータ・システムにおいて、前記リソースが仮想的なリソース空間にもクライアント・コンピュータから処理の要求を受けたサーバー・コンピュータ内にもある場合、どちらのリソースが新しいかを判断するステップと、前記サーバー・コンピュータのリソースがより新しい場合は仮想的なリソース空間のリソースと置き換えを行うステップが存在し、仮想的なリソース空間のリソースを更新する手段を備えることを特徴とするコンピュータ・システムである。【００１２】請求項４に記載の発明は、請求項１、請求項２および請求項３に記載したリソースの取得・保存・更新を行う手段を備え、且つ、仮想的なリソース空間をネットワーク上に離散的に保持する手段を備え、且つ、仮想的なリソース空間の複製を持ち、高アクセス時および障害時に複製したリソース空間のリソース用いることを可能とする手段を備えたコンピュータ・システムである。【００１３】以下、図面を参照し、この発明の本発明の一実施の形態（以下「本実施形態」と呼ぶ）について説明する。
【図面の簡単な説明】
【００１４】
【図１】本実施形態を示す概略図である。
【図２】本実施形態の仮想的なリソース空間の構成を示すブロック図である。
【図３】本実施形態の仮想的なリソース空間と各サーバー・コンピュータのリソースとを紐づける際の関係図である。
【図４】本実施形態の、サーバー・コンピュータがクライアント・コンピュータから要求された処理を行う上で必要なリソースを取得する際のシーケンス・フロー図である。
【図５】図４シーケンス・フロー図の続きである。
【発明を実施するための形態】
【００１５】図１は本実施形態にかかるコンピュータ・システムの概略図である。図１に基づき、本実施形態においての必要条件を述べる。
【００１６】コンピュータ・システム４０は、１以上のサーバー・コンピュータ２０、１以上のクライアント・コンピュータ１０と仮想的なリソース空間である仮想リソース空間３０からなり、クライアント１０はインターネット網やイントラネット網などのネットワークＮ１を介してサーバー・コンピュータ２０に接続されており、リクエスト・レスポンス通信方式もしくは、ソケット通信方式をして、サーバー２０とファイル、データなどリソースの授受を行うことができる。また、サーバー・コンピュータは仮想リソース空間３０に対してリソースの登録・取得・更新を行うことができる。
【００１７】図２は本実施形態において、仮想リソース空間３０の構成を示すブロック図である。
【００１８】仮想リソース空間３０はデータの離散的保持（ｓｈａｒｄｉｎｇ）が可能なデータベースシステムを備えた、１または複数のサーバー・コンピュータで構成される。図２ではＮ２を通じ、ｓｈａｒｄｉｎｇされたデータベース３０−１ａ、３０−２ａ、がそれぞれの複製（ｒｅｐｌｉｃａ）である３０−１ｂ、３０−２ｂを持ち、クライアント・コンピュータからの処理要求を実行するサーバー・コンピュータ２０はネットワークＮ２を介してＤＢ  Ｒｏｕｔｅｒ３１に対してリソースの登録・取得・更新命令を行うことで前記ｓｈａｒｄｉｎｇされたデータベースからのリソースの取得、ｓｈａｒｄｉｎｇされたデータベースへのリソースの登録・更新を行うことができる。
【００１９】図２においては、ｓｈａｒｄｉｎｇされたデータベースシステムは１つのサーバーに１つのデータベースが配置されているが、本実施形態はその限りでない。例えばｓｈａｒｉｎｇされたデータベース３０−１ａと３０−２ａが同じサーバー・コンピュータで動作している状況や、ＤＢ  Ｒｏｕｔｅｒ３１とｓｈａｒｄｉｎｇされたデータベース３０ー１ａおよび３０ー２ｂが同じサーバー・コンピュータで動作している状況も本実施形態としての要件を満たしている。
【００２０】また、サーバー・コンピュータはＲｏｕｔｅ  ＤＢ３１の数や位置を把握する必要があるが、この設定はサーバー・コンピュータのメモリ上に配置されており、サーバー・コンピュータはこれを外部から書き換え、運用を止めることなく仮想リソース空間３０の構成変化に対応できるＡＰＩを有する。
【００２１】図３は本実施形態において、クライアント・コンピュータ１０から処理の要求を受けたサーバー・コンピュータ２０がその過程でリソースを必要とした場合に、仮想リソース空間３０からリソースを要求するアドレスの取得フロー図である。
【００２２】サーバー・コンピュータ２０には３つのアドレス状態が存在する。個々のサーバー・コンピュータのリソース空間上のアドレス（Ａ１０）、そこから個々のサーバー・コンピュータ依存部分を取り除いた中間アドレス（Ａ１１）および前記中間アドレスに仮想リソース空間３０の空間名を付与した問い合わせアドレス（Ａ１２）である。
【００２３】サーバー・コンピュータ２０は自身依存部分を示す文字列または正規表現（Ｒ１０）および、前記中間アドレスＡ１１から仮想リソース空間３０の空間名を示す文字列または正規表現（Ｒ１１）を有しており、且つ、Ｒ１０を用いてＡ１０からＡ１１を算出するステップ（Ｓ１０）と、Ｒ１１を用いてＡ１１からＡ１２を算出するステップ（Ｓ１１）を有する。
【００２４】クライアント・コンピュータ１０から直接リソースの要求を受けるときはＵＲＬから変換されたＡ１０のアドレスを元に仮想リソース空間３０とリソースを授受する。また、サーバー・コンピュータに配布されるコンピュータ・システムのロジックプログラムではＡ１０またはＡ１２のアドレスを用いて仮想リソース空間３０とリソースを授受する。
【００２５】図４は本実施形態において、クライアント・コンピュータ１０から処理の要求を受けたサーバー・コンピュータ２０がその過程でリソースを必要とした場合に、仮想リソース空間３０からデータを取得する処理を行うシーケンス・フロー図である。図４、図５に基づき、本発明の詳細な動作を述べる。
【００２６】前記仮想リソース空間３０とリソースを授受するためのアドレスを取得するロジックによって、サーバー・コンピュータ２０は仮想リソース空間３０とリソースを授受するためのアドレス（Ａ）を取得する。サーバー・コンピュータ２０はＤＢ  Ｒｏｕｔｅｒ３１に対してアドレスＡおよび要求リソース状態確認命令を送信する（Ｓ１０１）。ＤＢ  Ｒｏｕｔｅｒ３１はアドレス（Ａ）からリソースの格納場所を判断し、ｓｈａｒｄｉｎｇされたデータベースへリソース状態確認コマンドを発行する（Ｓ１０２）。
【００２７】データベースからリソースの作成日時、更新日時、リソースのロック状態等を含むメタデータが送信される（Ｓ１０３）。ここで「メタデータ」とはＸＭＬ、ＪＳＯＮ等規則に従った並びをしたテキストデータを指す。前記アドレスＡに該当するリソースが存在しない場合、参照先のないポインタ（ｎｕｌｌ）が送信される。前記仮想リソース空間のメタデータをＤＢ  Ｒｏｕｔｅｒ３１はサーバー・コンピュータに送信する（Ｓ１０４）。サーバー・コンピュータは前記仮想リソース空間から取得したメタデータである仮想リソース空間上のリソースメタデータＭ１を受け取った（Ｓ１０５）のち、前記アドレスで自身のリソースの状態を捜査する（Ｓ１０６）。
【００２８】捜査するアドレスは前記仮想リソース空間３０とリソースを授受するためのアドレスを取得するロジックに基づき、自身依存部分を含むアドレスを取得し、自メタデータＭ２として保持する。自身依存部分を含むアドレスにリソースが存在しない場合、参照先のないポインタ（ｎｕｌｌ）を保持する。
【００２９】ここから３パターンに処理を分岐する。
【００３０】Ｍ１とＭ２がともにメタデータを持ち、且つ、Ｍ１の更新日時とＭ２の更新日時が同じかもしくはＭ１の更新日時がＭ２の更新日時より未来である、または、Ｍ１はメタデータを持ち、且つ、Ｍ２のメタデータが存在ない場合（Ｓ２００）、単純に仮想リソース空間３０からリソースを取得する。（Ｓ２０１〜Ｓ２０４）
【００３１】Ｍ１とＭ２がともにメタデータを持ち、且つ、Ｍ１の更新日時がＭ２の更新日時より過去である、または、Ｍ１のメタデータが存在せず、且つ、Ｍ２のメタデータがある場合（Ｓ３００）、自身のリソースを仮想リソース空間３０に保存したのち、仮想リソース空間３０からリソースを取得する。（Ｓ３０１〜Ｓ３０９）
【００３２】Ｍ１とＭ２がともにメタデータを持たない場合（Ｓ４００）、エラー処理をサーバー・コンピュータ２０で行う。
【００３３】以上が本実施形態における、詳細な動作の記述である。
【発明の効果】
【００３４】本発明に係るコンピュータ・システムは、クラウド・コンピュータをはじめとした離散的システムの構築および運用に際して、リソース管理負荷を、集中型システムと差異のないアーキテクチャで実現できる。クラウド・コンピューティングにおけるスケーラビリティに対する管理負荷を激減させ、コンピュータ・システムの開発者、運用者およびユーザーはクラウド・コンピューティングの導入を積極的に進めることができる。
【００３５】［他の実施形態］
本発明は、同様のロジックを用いた他の実施態様も含むものである。また、本発明において、各手段などの要素は、コンピュータの演算制御部に限らず、ワイヤードロジック等に基づく電子回路で実現してもよい。また、各構成図、データの図、フローチャートの図などは例示に過ぎず、各要素の有無、その順序や具体的内容などは、本発明の範囲で適宜変更可能である。
【００３６】また、本発明の実施形態に記述された効果は、本発明の実施形態から生じる好適な効果を述べたものであって、本発明による効果は、本発明の実施形態に記述されたものに限定されるものではない。
【符号の説明】
【００３７】１０  クライアント・コンピュータ
２０  サーバー・コンピュータ
３０  仮想的なリソース空間
３１  データベース・ルーティング・システム
４０  コンピュータ・システム
Ｎ１，Ｎ２    ネットワーク
【図１】
2013069252.tif 000003
【図２】
2013069252.tif 000004
【図３】
2013069252.tif 000005
【図４】
2013069252.tif 000006
【図５】
2013069252.tif 000007