JP2013178660A - コンピュータシステム及びデータストレージサービスの提供方法 - Google Patents

Abstract

【課題】利用しやすく、利用するためのシステムやクライアント側のアプリケーションソフトウェアの開発が容易なデータストレージサービスを提供する。
【解決手段】ストレージ１０７は、一意の値であるキーに対応するバリューを前記キーとともに、キーとバリューの対として複数記憶し、前記キーとバリューの対は、当該バリュー自体に、他の前記キーとバリューの対を１又は複数有することが可能である。ウェブサーバ１０６は、あるファイルについて当該ファイルの階層的な格納情報とともにクエリを受信すると、前記格納情報に基づいて、前記ストレージ手段が記憶している当該ファイルを含むバリューに対応するキーを特定する。
【選択図】図４

Description

本発明は、コンピュータシステム及びデータストレージサービスの提供方法に関し、特に、ウェブサービスとしてストレージへのアクセスを提供するように構成されるデータストレージサービスに関する。

近時、クラウドコンピューティングという概念が提案されており、その基幹技術の一つとして、クラウド内のアプリケーションプログラム同士のインターフェイス、或いは、クラウド内のアプリケーションプログラムとクライアントデバイス上で動作するアプリケーションプログラムとのインターフェイスが注目されている。

あるコンピュータ上のプログラムが、他のコンピュータ上のプログラムを実行させるメカニズムとしては、従来、ＲＰＣ（リモートプロシージャコール）プロトコルが広く用いられている。しかしながら、パーソナルコンピュータやモバイルデバイス（携帯電話、パッド型のタブレットＰＣを含む）といった多種多様なデバイスがクライアントデバイスとして利用される可能性があるクラウドコンピューティングにおいては、ＲＰＣプロトコルに基づいたシステムは、多様なデバイスに対応するための開発が容易ではない。

特許文献１には、このようなコンピュータシステム及び実行中のアプリケーション同士の対話を容易にするストレージサービスのインターフェイスとして、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ（ＲＥＳＴ）形式のウェブサービスアーキテクチャで実装したインターフェイスを利用することが開示されている（例えば、段落００１４等参照）。

特開２００９−５２２６５９号公報

しかしながら、特許文献１に記載のＲＥＳＴベースインターフェイスにおいては、ウェブサービスのインターフェイスのルートに、アクセスポリシーを同じくするオブジェクトのひとまとまりが「バケット」として並ぶ構造になる（例えば、段落００１２、００１７００１８参照）。このような構造では、階層構造を持つデータを格納する際に工夫が必要である。

特許文献１の段落００２４には、階層的構造について言及がある。バケットに他のバケットを階層的に包含しなくてもよい一方で、ウェブサービス呼び出し要求に用いるキーに階層的構造を暗示させる旨の記載がある。このような低いレイヤー寄りの実装は、データストレージサービスの利用者にとって利用しにくく、手軽な利用を妨げる。利用するためのシステムやクライアント側のアプリケーションソフトウェアの開発に手間がかかる。

本発明は、上記実情に鑑みてなされたものであって、利用しやすく、利用するためのシステムやクライアント側のアプリケーションソフトウェアの開発が容易なデータストレージサービスを提供することを目的とする。

上記目的を達成するために本発明は、第１の態様として、ウェブサービスとして提供されるデータストレージサービスを提供するコンピュータシステムであって、複数台のコンピュータノードに冗長化されたストレージ手段と、外部アプリケーションから前記ウェブサービスで用いられるメソッドでクエリを受信すると、前記クエリを解析して前記ストレージ手段へ問い合わせを実行するウェブサーバと、を有し、前記ストレージ手段は、一意の値であるキーに対応するバリューを前記キーとともに、キーとバリューの対として複数記憶し、前記キーとバリューの対は、当該バリュー自体に、他の前記キーとバリューの対を１又は複数有することが可能であり、前記ウェブサーバは、あるファイルについて当該ファイルの階層的な格納情報とともにクエリを受信すると、前記格納情報に基づいて、前記ストレージ手段が記憶している当該ファイルを含むバリューに対応するキーを特定することを特徴とするコンピュータシステムを提供する。

また、上記目的を達成するために本発明は、第２の態様として、コンピュータシステムを用いてウェブサービスとして提供されるデータストレージサービスを提供する方法であって、ストレージ手段を、複数台のコンピュータノードに冗長化させ、前記ストレージ手段に、一意の値であるキーに対応するバリューを前記キーとともに、キーとバリューの対として複数記憶させ、前記キーとバリューの対が、当該バリュー自体に他の前記キーとバリューの対を１又は複数有することが可能であるように構成し、外部アプリケーションから前記ウェブサービスで用いられるメソッドでクエリを受信し、前記クエリを解析し、前記クエリが、あるファイルについて当該ファイルの階層的な格納情報とともになされたものである場合、前記格納情報に基づいて、前記ストレージ手段が記憶している当該ファイルを含むバリューに対応するキーを特定し、前記ストレージ手段へ問い合わせを実行することを特徴とするデータストレージサービスの提供方法を提供する。

本発明によれば、利用しやすく、利用するためのシステムやクライアント側のアプリケーションソフトウェアの開発が容易なデータストレージサービスを提供することが可能となる。

本発明の実施形態のネットワーク全体を例示する図である。 図１のストレージシステム１０１を構成するサーバ群の一例を示す図である。 図２のサーバアプリケーション間通信を示すシーケンス図である。 図１のストレージシステム１０１をアプリケーションレイヤの観点から見た構成を示すブロック図である。 図４のストレージ手段１０７に格納される情報について説明するための概念図である。

以下、本発明を実施形態により図面を参照しながら説明する。

［システム構成］
本実施形態に係るストレージシステム１０１は、ネットワーク全体の中においてはウェブサービスとしてストレージへのアクセスを提供するように構成される（図１参照）。ストレージシステム１０１は、いわゆる「クラウド」と呼ばれるパブリックなネットワーク（典型的には、例えばインターネット）を含むネットワーク上に置かれる。図１を参照すると、ストレージシステム１０１は、クラウド１００上に置かれ、各種クライアントデバイス２００とデータ通信する構成である。

クライアントデバイス２００は、携帯端末やパーソナルコンピュータを含む種々のものを用いることができる。携帯端末としては、限定するものではないが、米国アップルコンピュータ社が提供するオペレーティングシステム（以下、「ＯＳ」）、ｉＯＳを搭載する携帯電話端末やパッド型端末、また、米国グーグル社が提供するＯＳ、Ａｎｄｒｏｉｄ（登録商標）を搭載する携帯端末を用いることができる。

ストレージシステム１０１は、より詳細には、各クライアントデバイス２００上で動作するアプリケーションソフトウェア２０１と通信する。ここで、本実施形態において、アプリケーションソフトウェア２０１は、各ＯＳに対応する、いわゆるネイティブアプリケーションである。

他の実施形態においては、アプリケーションソフトウェア２０１に代替して、ウェブサーバと通信を行いウェブサービスの提供を受けることに適したアプリケーションソフトウェアであるブラウザアプリケーションないしブラウザアプリケーション上で動作するプラグイン（例えば、米国アドビシステムズ社のＦｌａｓｈ（登録商標）など）が、ストレージシステム１０１と通信を行うように構成してもよい。

ストレージシステム１０１とクライアントデバイス２００上のアプリケーションソフトウェア２０１とのプログラム同士の対話は、ＲＥＳＴベースインターフェイスによって実現される。本実施形態において、ＲＥＳＴベースインターフェイスでは、各ウェブサービスコールが、外部状態情報を参照することなくそのコールを処理するために必要なすべての情報を含む。

また、本実施形態において、ＲＥＳＴベースインターフェイスでは、ウェブサービスが、指定された動作および１以上のクエリパラメータを含むＵＲＬ（「Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ」）などのＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ」）として指定されたウェブサービス呼び出し要求に応答して、ＨＴＴＰ（「ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ」）を使用するＸＭＬ（「ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ」）フォーマットでデータを返す。

［インフラストラクチャレイヤ］
ストレージシステム１０１の機能を実現するためのハードウェア及び当該ハードウェアを利用して所定の情報処理を行うソフトウェアプログラムの組み合わせは、種々のものが利用できる。本実施形態においては、１台以上の汎用のコンピュータを用いて、仮想的に図２に例示するようなサーバ群として動作させるソフトウェアプログラムを利用する。

図２は、図１のストレージシステム１０１を構成するサーバ群の一例を示すものである。図２に示すように、ストレージシステム１０１は、ロードバランサ１０２と、ウェブサービスクラスタ１０３と、データベースマネジメントクラスタ１０４と、分散ファイルシステムクラスタ１０５とを含み、全体として分散型のデータストレージサービスを構成する。

ロードバランサ１０２は、プロキシサーバを含み、クライアントデバイス２００とのセッションの維持、負荷分散、ウェブサービスコールの適切なリダイレクトなど、各種機能を提供する。プロキシサーバとしては、限定するものではないが、例えば、ＨＡＰｒｏｘｙ（登録商標）を用いる。

ウェブサービスクラスタ１０３は、ＴＣＰ／ＨＴＴＰに基づいた各ウェブサービスコールを適切に処理するウェブサーバを含み、ウェブサービスを提供する機能を実現する。ウェブサーバとしては、限定するものではないが、例えば、オープンソースで開発が続けられているＡｐａｃｈｅ（登録商標）を用いる。

データベースマネジメントクラスタ１０４は、分散ファイルシステムクラスタ１０５に記録されたデータに効率的にアクセスするための大規模分散データベースの機能を提供する。データベースマネジメントクラスタ１０４の各機能は、限定するものではないが、例えば、Ｈａｄｏｏｐ Ｂａｓｅ（以下、「ＨＢａｓｅ」）によって提供される。ＨＢａｓｅを用いる場合、データベースマネジメントクラスタ１０４は、マスターサーバやリージョンサーバを含んでもよい。

マスターサーバは、リージョンサーバの管理を行い、死活管理や容量に応じてデータの統合や配置の変更などを行う。リージョンサーバは、分散ファイルシステムクラスタ１０５に記録されたデータに効率的にアクセスするための大規模分散データベースである。

分散ファイルシステムクラスタ１０５は、最低２つのネームノード、最低３つのデータノードを含んで構成される大規模分散ファイルシステムである。分散ファイルシステムクラスタ１０５の各機能は、限定するものではないが、例えば、Ｈａｄｏｏｐ Ｄｉｓｔｒｉｂｕｔｅｄ Ｆｉｌｅ Ｓｙｓｔｅｍ（以下、「ＨＤＦＳ」）によって提供される。

このように、このストレージシステム１０１のストレージは、複数台のコンピュータノードに冗長化されている。また、上述のように構成された本実施形態によれば、分散ファイルシステムクラスタ１０５のデータ容量が不足してくると、データノードを単に追加することによってパフォーマンスの低下なく容易にデータ容量を増加させることができる。したがって、スケーラブルである。

なお、図２に例示した構成は、物理的に５台のサーバマシンで実装することができる。５台のサーバマシンをそれぞれ、ノード＃１、ノード＃２、・・・、ノード＃５とすると、ノード＃１を、図２中のプロキシサーバ１、マスターサーバ１、ネームノード１として機能させ、ノード＃２を、プロキシサーバ２、マスターサーバ２、ネームノード２として機能させる。また、ノード＃３を、ウェブサーバ１、リージョンサーバ１、データノード１として機能させ、ノード＃４を、ウェブサーバ２、リージョンサーバ２、データノード２として機能させ、ノード＃５を、ウェブサーバ３、リージョンサーバ３、データノード３として機能させる。

このように、物理的にたった５台のサーバマシンから、大規模分散データベースシステムの構築が実現可能であるので、ビジネスのスモールスタートが可能である。換言すれば、少ない初期投資費用で、本実施形態が提供する大規模分散データベースシステムを利用したビジネスを始めることができる。

図３に、図２に示したサーバ群のサーバアプリケーション間通信のシーケンスを示す。図３に示されるように、本実施形態に係るストレージシステム１０１へのアクセスは、認証フェーズとデータアクセスフェーズに分かれる。

認証フェーズにおいては、クライアントデバイス２００より認証要求のクエリがなされると、ロードバランサ１０２により負荷分散されて利用可能なウェブサービスクラスタ１０３へ送信される（Ｓ１０１、Ｓ１０２）。

ウェブサービスクラスタ１０３では、クエリを解析しクエリの内容に沿った問い合わせを後段のデータベースマネジメントクラスタ１０４及び分散ファイルシステムクラスタ１０５に対して実行する（Ｓ１０３〜Ｓ１０６）。

認証フェーズにおけるクエリには、少なくとも認証情報を含む。一方で、当該クエリないしデータアクセスフェーズでアクセスしようとする記憶内容には、後述するように、その記憶内容へのアクセス権限がメタ情報（ファイル情報）として含まれている。ウェブサービスクラスタ１０３は、クエリの認証情報と、当該クエリないしデータアクセスフェーズでアクセスしようとする記憶内容へのアクセス権限とに基づいて、アクセス可否を判断し、結果をクライアントデバイス２００に返す（Ｓ１０７、Ｓ１０８、Ｓ１０９）。

データアクセスフェーズにおいても、認証フェーズとほとんど同じ情報処理が行われる。クライアントデバイス２００よりデータアクセス要求のクエリがなされると、ロードバランサ１０２により負荷分散されて利用可能なウェブサービスクラスタ１０３へ送信される（Ｓ１１０、Ｓ１１１）。

ウェブサービスクラスタ１０３では、クエリを解析しクエリの内容に沿った問い合わせを後段のデータベースマネジメントクラスタ１０４及び分散ファイルシステムクラスタ１０５に対して実行する（Ｓ１１２〜Ｓ１１５）。

データアクセスフェーズにおけるクエリには、少なくともあるファイルについて当該ファイルの階層的な格納情報を含む。なお、ここで、ディレクトリやフォルダといった概念は特殊な性質を持ったファイルとして、ファイルとして扱う。

階層的な格納情報とは、例えば、下記のようなものである。なお“／”はディレクトリやフォルダの区切りを表す。
/kigyo_name/busyo_name/user_name/folder_1/folder_2/file_name

ウェブサービスクラスタ１０３は、上記のような階層的な格納情報に基づいてファイルの格納されている場所についての階層構造を把握する。そして、好ましくは、ファイルに対応するキー（後述）を特定する。

［アプリケーションレイヤ］
図２と図３のようなインフラストラクチャレイヤの構成を備えることによって、本実施形態に係るストレージシステム１０１は、アプリケーションレイヤの観点から見て、図４に示すような３層構造をとることが可能になる。すなわち、ストレージシステム１０１は、ウェブサービスクラスタ１０３の情報処理によりウェブサービスを提供するウェブサーバ１０６と、データベースマネジメントクラスタ１０４と分散ファイルシステムクラスタ１０５の情報処理によりデータベースサービスを提供するストレージ手段１０７とを含み、外部のクライアントデバイス２００と接続する構成である。

図４に示すストレージ手段１０７は、図２と図３のようなインフラストラクチャレイヤの構成を備えることによって、スケールアウトすることが可能な極めて高いスケーラビリティを備える。また、ストレージ手段１０７は、大規模なデータを保存することが可能である。また、ストレージ手段１０７は、そのような大規模なデータを１行（１レコード）に納める設計をしても可用性が低下しない。

そこで、本実施形態では、図５に示すようなデータ構造でデータを格納する。上記のように、本実施形態では大規模なデータを１レコードに納めることができるので、１レコードの基本構造は、キーとバリューの対とする（図５（ａ））。このキーとバリューの対を格納していき、ＫＶＳ（Ｋｅｙ Ｖａｌｕｅ Ｓｔｏｒｅ）を構築する。

ここで、キーはストレージ手段１０７において一意な値とする。また、バリューには、このストレージ手段１０７に格納するべきファイルの実体と、そのファイルのファイル情報とを少なくとも含む。

ファイルの実体は、例えば、画像ファイルや動画ファイルなどのファイルそのものである。ファイル情報は、例えば、ファイル名、ファイルサイズ、所有者、アクセス権限を有するものの情報などである。

ここで、ファイルの実体には、他のキーとバリューの対を含むことができる（図５（ｂ））。そうすると、大規模なデータ量を持つキーとバリューの対が作成される可能性がある一方で、階層構造がきわめて容易に表現できる。ところが、上述したように、本実施形態では大規模なデータを１レコードに納めることができるので、大規模なデータ量を持つキーとバリューの対が作成される可能性があることにデメリットがない。

ウェブサービスクラスタ１０３の情報処理によりウェブサービスを提供するウェブサーバ１０６は、階層的な格納情報を含むクエリをクライアントデバイス２００から受信すると、当該クエリを解析して、階層的な格納情報を取り出す。そして、その階層的な格納情報に基づいてファイルの格納されている場所についての階層構造を把握する。

一方で、ストレージ手段１０７には、キーとバリューの対を入れ子に持つという方式で、把握された階層構造がそのままストレージ手段１０７上に構築されている。したがって、ウェブサーバ１０６は把握した階層構造におけるファイルの格納場所が容易に特定できるため、クエリが取得やアクセスを所望するファイルに対応するキーの特定が容易にできる。

また、本実施形態に係るストレージ手段１０７は、上述したような特徴を持つ構造であるため、データストレージサービスに利用される場合、利用しやすく、利用するためのシステムやクライアント側のアプリケーションソフトウェアの開発が容易である。したがって、本実施形態によれば、利用しやすく、利用するためのシステムやクライアント側のアプリケーションソフトウェアの開発が容易なデータストレージサービスを提供することができる。

また、本実施形態に係るストレージシステム１０１は、図３の認証フェーズに示したような認証の仕組みが存在する。したがって、セキュリティ面に考慮したデータベース設計が容易に可能となる。

また、本実施形態に係るアプリケーションソフトウェア２０１は、各ＯＳに対応する、いわゆるネイティブアプリケーションである。したがって、例えば、各ウェブサービスコールを媒介するＸＭＬを独自のアプリケーションで処理することができるため、クライアント側での自由度が高めることができるようになる。

１００ クラウド
１０１ ストレージシステム
１０２ ロードバランサ
１０３ ウェブサービスクラスタ
１０４ データベースマネジメントクラスタ
１０５ 分散ファイルシステムクラスタ
１０６ ウェブサーバ
１０７ ストレージ手段
２００ クライアントデバイス
２０１ アプリケーションソフトウェア

Claims (5)

1. ウェブサービスとして提供されるデータストレージサービスを提供するコンピュータシステムであって、
   複数台のコンピュータノードに冗長化されたストレージ手段と、
   外部アプリケーションから前記ウェブサービスで用いられるメソッドでクエリを受信すると、前記クエリを解析して前記ストレージ手段へ問い合わせを実行するウェブサーバと、
   を有し、
   前記ストレージ手段は、一意の値であるキーに対応するバリューを前記キーとともに、キーとバリューの対として複数記憶し、
   前記キーとバリューの対は、当該バリュー自体に、他の前記キーとバリューの対を１又は複数有することが可能であり、
   前記ウェブサーバは、あるファイルについて当該ファイルの階層的な格納情報とともにクエリを受信すると、前記格納情報に基づいて、前記ストレージ手段が記憶している当該ファイルを含むバリューに対応するキーを特定する
   ことを特徴とするコンピュータシステム。
2. 前記クエリは、認証情報を含み、
   前記バリューは、記憶内容の実体の他に、当該記憶内容へのアクセス権限の情報を含む
   ことを特徴とする請求項１記載のコンピュータシステム。
3. 前記認証情報は、前記外部アプリケーションを操作するユーザの認証情報と、前記外部アプリケーションが搭載されている端末装置の認証情報と、を含む
   ことを特徴とする請求項２記載のコンピュータシステム。
4. 前記外部アプリケーションは、当該外部アプリケーションが搭載されている端末装置のオペレーションシステムのネイティブアプリケーションであることを特徴とする請求項１から３のいずれか１項記載のコンピュータシステム。
5. コンピュータシステムを用いてウェブサービスとして提供されるデータストレージサービスを提供する方法であって、
   ストレージ手段を、複数台のコンピュータノードに冗長化させ、
   前記ストレージ手段に、一意の値であるキーに対応するバリューを前記キーとともに、キーとバリューの対として複数記憶させ、
   前記キーとバリューの対が、当該バリュー自体に他の前記キーとバリューの対を１又は複数有することが可能であるように構成し、
   外部アプリケーションから前記ウェブサービスで用いられるメソッドでクエリを受信し、
   前記クエリを解析し、
   前記クエリが、あるファイルについて当該ファイルの階層的な格納情報とともになされたものである場合、前記格納情報に基づいて、前記ストレージ手段が記憶している当該ファイルを含むバリューに対応するキーを特定し、
   前記ストレージ手段へ問い合わせを実行する
   ことを特徴とするデータストレージサービスの提供方法。

Images