(57)【要約】【課題】可用性を確保しつつ一部のデータについて迅速なレスポンスが得られるコンピュータシステムを提供する。【解決手段】ウェブサービスとして提供されるデータストレージサービスを提供するコンピュータシステムであって、複数台のコンピュータノードに冗長化されたストレージ手段１０７と、外部アプリケーションから前記ウェブサービスで用いられるメソッドでクエリを受信すると、前記クエリを解析して前記ストレージ手段１０７へ問い合わせを実行するウェブサーバ１０６と、を有し、前記ストレージ手段１０７は、１又は複数の情報を格納するフィールドを１又は複数備えたレコードからなるデータ構造のファイルを記憶し、前記ウェブサーバ１０６は、前記ファイルのＵＲＩとともに、前記ファイル内の情報への検索問い合わせを受信すると、前記ファイル内の情報への問い合わせを実行し、実行結果をＸＭＬで返す。【選択図】図４
2013235336.tif 000002
【特許請求の範囲】
【請求項１】
ウェブサービスとして提供されるデータストレージサービスを提供するコンピュータシステムであって、
複数台のコンピュータノードに冗長化されたストレージ手段と、
外部アプリケーションから前記ウェブサービスで用いられるメソッドでクエリを受信すると、前記クエリを解析して前記ストレージ手段へ問い合わせを実行するウェブサーバと、
を有し、
前記ストレージ手段は、１又は複数の情報を格納するフィールドを１又は複数備えたレコードからなるデータ構造のファイルを記憶し、
前記ウェブサーバは、前記ファイルのＵＲＩとともに、前記ファイル内の情報への検索問い合わせを受信すると、前記ファイル内の情報への問い合わせを実行し、実行結果をＸＭＬで返す
ことを特徴とするコンピュータシステム。
【請求項２】
前記ファイルの内容が電話帳であることを特徴とする請求項１記載のコンピュータシステム。
【請求項３】
前記ファイルの内容がスケジュール帳又は日記帳であることを特徴とする請求項１又は２記載のコンピュータシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータシステムに関し、特に、ウェブサービスとしてストレージへのアクセスを提供するように構成されるデータストレージサービスに関する。
【背景技術】
【０００２】
近時、クラウドコンピューティングという概念が提案されており、その基幹技術の一つとして、クラウド内のストレージの冗長性を高め、可用性を確保する技術が注目されている。きわめて高度な冗長性を実現するために、分散ファイルシステムと呼ばれる技術を利用することが従来知られている。
【０００３】
例えば、特許文献１を参照すると、ファイル操作に対するレスポンス時間、処理負荷、或いは記憶容量といった、特性の異なる複数の分散ファイルシステムを利用することが記載されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１２−０７３７７７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
分散ファイルシステムにおいては、単一のファイルシステムが複数の物理コンピュータノードに分散して存在するため、分散ファイルシステムへのファイルアクセスにかかる時間が、通常のファイルアクセスにかかる時間に比べて、長くなるのが現状である。
【０００６】
そこで、可用性が高いという分散ファイルシステムのメリットを享受しつつ、一部のデータについては少しでも迅速なファイルアクセスを望む場合、そのような一部のデータについてのみ、レスポンス時間が短い特性を持った分散ファイルシステムを利用するという方法が考えられる。
【０００７】
特許文献１に開示されているような方法で、異なる特性を持った分散ファイルシステムを複数、透過的に運用することができるかもしれない。しかしながら、特許文献１においては、分散ファイルシステム制御装置をあらたに設置して、特性の異なる複数の分散ファイルシステムの使用の差異を吸収する必要がある。制御装置によるオーバーヘッドがさらに生じる可能性がある。
【０００８】
本発明は、上記実情に鑑みてなされたものであって、可用性を確保しつつ一部のデータについて迅速なレスポンスが得られるコンピュータシステムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
上記目的を達成するために本発明は、ウェブサービスとして提供されるデータストレージサービスを提供するコンピュータシステムであって、複数台のコンピュータノードに冗長化されたストレージ手段と、外部アプリケーションから前記ウェブサービスで用いられるメソッドでクエリを受信すると、前記クエリを解析して前記ストレージ手段へ問い合わせを実行するウェブサーバと、を有し、前記ストレージ手段は、１又は複数の情報を格納するフィールドを１又は複数備えたレコードからなるデータ構造のファイルを記憶し、前記ウェブサーバは、前記ファイルのＵＲＩとともに、前記ファイル内の情報への検索問い合わせを受信すると、前記ファイル内の情報への問い合わせを実行し、実行結果をＸＭＬで返すことを特徴とするコンピュータシステムを提供するものである。
【発明の効果】
【００１０】
本発明によれば、可用性を確保しつつ一部のデータについて迅速なレスポンスが得られるコンピュータシステムを提供することが可能となる。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施形態のネットワーク全体を例示する図である。
【図２】図１のストレージシステム１０１を構成するサーバ群の一例を示す図である。
【図３】図２のサーバアプリケーション間通信を示すシーケンス図である。
【図４】図１のストレージシステム１０１をアプリケーションレイヤの観点から見た構成を示すブロック図である。
【図５】図４のストレージ手段１０７に記憶される一部のファイルのデータ構造を説明するための図である。
【発明を実施するための形態】
【００１２】
以下、本発明を実施形態により図面を参照しながら説明する。
【００１３】
［システム構成］
本実施形態に係るストレージシステム１０１は、ネットワーク全体の中においてはウェブサービスとしてストレージへのアクセスを提供するように構成される（図１参照）。ストレージシステム１０１は、いわゆる「クラウド」と呼ばれるパブリックなネットワーク（典型的には、例えばインターネット）を含むネットワーク上に置かれる。図１を参照すると、ストレージシステム１０１は、クラウド１００上に置かれ、各種クライアントデバイス２００とデータ通信する構成である。
【００１４】
クライアントデバイス２００は、携帯端末やパーソナルコンピュータを含む種々のものを用いることができる。携帯端末としては、限定するものではないが、米国アップルコンピュータ社が提供するオペレーティングシステム（以下、「ＯＳ」）、ｉＯＳを搭載する携帯電話端末やパッド型端末、また、米国グーグル社が提供するＯＳ、Ａｎｄｒｏｉｄ（登録商標）を搭載する携帯端末を用いることができる。
【００１５】
ストレージシステム１０１は、より詳細には、各クライアントデバイス２００上で動作するアプリケーションソフトウェア２０１と通信する。ここで、本実施形態において、アプリケーションソフトウェア２０１は、各ＯＳに対応する、いわゆるネイティブアプリケーションである。
【００１６】
他の実施形態においては、アプリケーションソフトウェア２０１に代替して、ウェブサーバと通信を行いウェブサービスの提供を受けることに適したアプリケーションソフトウェアであるブラウザアプリケーションないしブラウザアプリケーション上で動作するプラグイン（例えば、米国アドビシステムズ社のＦｌａｓｈ（登録商標）など）が、ストレージシステム１０１と通信を行うように構成してもよい。
【００１７】
ストレージシステム１０１とクライアントデバイス２００上のアプリケーションソフトウェア２０１とのプログラム同士の対話は、ＲＥＳＴベースインターフェイスによって実現される。本実施形態において、ＲＥＳＴベースインターフェイスでは、各ウェブサービスコールが、外部状態情報を参照することなくそのコールを処理するために必要なすべての情報を含む。
【００１８】
また、本実施形態において、ＲＥＳＴベースインターフェイスでは、ウェブサービスが、指定された動作および１以上のクエリパラメータを含むＵＲＬ（「Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ」）などのＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ」）として指定されたウェブサービス呼出し要求に応答して、ＨＴＴＰ（「ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ」）を使用するＸＭＬ（「ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ」）フォーマットでデータを返す。
【００１９】
［インフラストラクチャレイヤ］
ストレージシステム１０１の機能を実現するためのハードウェア及び当該ハードウェアを利用して所定の情報処理を行うソフトウェアプログラムの組み合わせは、種々のものが利用できる。本実施形態においては、１台以上の汎用のコンピュータを用いて、仮想的に図２に例示するようなサーバ群として動作させるソフトウェアプログラムを利用する。
【００２０】
図２は、図１のストレージシステム１０１を構成するサーバ群の一例を示すものである。図２に示すように、ストレージシステム１０１は、ロードバランサ１０２と、ウェブサービスクラスタ１０３と、データベースマネジメントクラスタ１０４と、分散ファイルシステムクラスタ１０５とを含み、全体として分散型のデータストレージサービスを構成する。
【００２１】
ロードバランサ１０２は、プロキシサーバを含み、クライアントデバイス２００とのセッションの維持、負荷分散、ウェブサービスコールの適切なリダイレクトなど、各種機能を提供する。プロキシサーバとしては、限定するものではないが、例えば、ＨＡＰｒｏｘｙ（登録商標）を用いる。
【００２２】
ウェブサービスクラスタ１０３は、ＴＣＰ／ＨＴＴＰに基づいた各ウェブサービスコールを適切に処理するウェブサーバを含み、ウェブサービスを提供する機能を実現する。ウェブサーバとしては、限定するものではないが、例えば、オープンソースで開発が続けられているＡｐａｃｈｅ（登録商標）を用いる。
【００２３】
データベースマネジメントクラスタ１０４は、分散ファイルシステムクラスタ１０５に記録されたデータに効率的にアクセスするための大規模分散データベースの機能を提供する。データベースマネジメントクラスタ１０４の各機能は、限定するものではないが、例えば、Ｈａｄｏｏｐ  Ｂａｓｅ（以下、「ＨＢａｓｅ」）によって提供される。ＨＢａｓｅを用いる場合、データベースマネジメントクラスタ１０４は、マスターサーバやリージョンサーバを含んでもよい。
【００２４】
マスターサーバは、リージョンサーバの管理を行い、死活管理や容量に応じてデータの統合や配置の変更などを行う。リージョンサーバは、分散ファイルシステムクラスタ１０５に記録されたデータに効率的にアクセスするための大規模分散データベースである。
【００２５】
分散ファイルシステムクラスタ１０５は、最低２つのネームノード、最低３つのデータノードを含んで構成される大規模分散ファイルシステムである。分散ファイルシステムクラスタ１０５の各機能は、限定するものではないが、例えば、Ｈａｄｏｏｐ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｆｉｌｅ  Ｓｙｓｔｅｍ（以下、「ＨＤＦＳ」）によって提供される。
【００２６】
このように、このストレージシステム１０１のストレージは、複数台のコンピュータノードに冗長化されている。また、上述のように構成された本実施形態によれば、分散ファイルシステムクラスタ１０５のデータ容量が不足してくると、データノードを単に追加することによってパフォーマンスの低下なく容易にデータ容量を増加させることができる。したがって、スケーラブルである。
【００２７】
なお、図２に例示した構成は、物理的に５台のサーバマシンで実装することができる。５台のサーバマシンをそれぞれ、ノード＃１、ノード＃２、・・・、ノード＃５とすると、ノード＃１を、図２中のプロキシサーバ１、マスターサーバ１、ネームノード１として機能させ、ノード＃２を、プロキシサーバ２、マスターサーバ２、ネームノード２として機能させる。また、ノード＃３を、ウェブサーバ１、リージョンサーバ１、データノード１として機能させ、ノード＃４を、ウェブサーバ２、リージョンサーバ２、データノード２として機能させ、ノード＃５を、ウェブサーバ３、リージョンサーバ３、データノード３として機能させる。
【００２８】
このように、物理的にたった５台のサーバマシンから、大規模分散データベースシステムの構築が実現可能であるので、ビジネスのスモールスタートが可能である。換言すれば、少ない初期投資費用で、本実施形態が提供する大規模分散データベースシステムを利用したビジネスを始めることができる。
【００２９】
図３に、図２に示したサーバ群のサーバアプリケーション間通信のシーケンスを示す。図３に示されるように、本実施形態に係るストレージシステム１０１へのアクセスは、認証フェーズとデータアクセスフェーズに分かれる。
【００３０】
認証フェーズにおいては、クライアントデバイス２００より認証要求のクエリがなされると、ロードバランサ１０２により負荷分散されて利用可能なウェブサービスクラスタ１０３へ送信される（Ｓ１０１、Ｓ１０２）。
【００３１】
ウェブサービスクラスタ１０３では、クエリを解析しクエリの内容に沿った問い合わせを後段のデータベースマネジメントクラスタ１０４及び分散ファイルシステムクラスタ１０５に対して実行する（Ｓ１０３〜Ｓ１０６）。
【００３２】
認証フェーズにおけるクエリには、少なくとも認証情報を含む。一方で、当該クエリないしデータアクセスフェーズでアクセスしようとする記憶内容には、その記憶内容へのアクセス権限がメタ情報（ファイル情報）として含まれている。ウェブサービスクラスタ１０３は、クエリの認証情報と、当該クエリないしデータアクセスフェーズでアクセスしようとする記憶内容へのアクセス権限とに基づいて、アクセス可否を判断し、結果をクライアントデバイス２００に返す（Ｓ１０７、Ｓ１０８、Ｓ１０９）。
【００３３】
データアクセスフェーズにおいても、認証フェーズとほとんど同じ情報処理が行われる。クライアントデバイス２００よりデータアクセス要求のクエリがなされると、ロードバランサ１０２により負荷分散されて利用可能なウェブサービスクラスタ１０３へ送信される（Ｓ１１０、Ｓ１１１）。
【００３４】
ウェブサービスクラスタ１０３では、クエリを解析しクエリの内容に沿った問い合わせを後段のデータベースマネジメントクラスタ１０４及び分散ファイルシステムクラスタ１０５に対して実行する（Ｓ１１２〜Ｓ１１５）。
【００３５】
データアクセスフェーズにおけるクエリには、少なくともあるファイルについて当該ファイルの階層的な格納情報を含む。なお、ここで、ディレクトリやフォルダといった概念は特殊な性質を持ったファイルとして、ファイルとして扱う。
【００３６】
階層的な格納情報とは、例えば、下記のようなものである。なお“／”はディレクトリやフォルダの区切りを表す。
/kigyo_name/busyo_name/user_name/folder_1/folder_2/file_name
【００３７】
ウェブサービスクラスタ１０３は、上記のような階層的な格納情報に基づいてファイルの格納されている場所についての階層構造を把握する。
【００３８】
［アプリケーションレイヤ］
図２と図３のようなインフラストラクチャレイヤの構成を備えることによって、本実施形態に係るストレージシステム１０１は、アプリケーションレイヤの観点から見て、図４に示すような３層構造をとることが可能になる。すなわち、ストレージシステム１０１は、ウェブサービスクラスタ１０３の情報処理によりウェブサービスを提供するウェブサーバ１０６と、データベースマネジメントクラスタ１０４と分散ファイルシステムクラスタ１０５の情報処理によりデータベースサービスを提供するストレージ手段１０７とを含み、外部のクライアントデバイス２００と接続する構成である。
【００３９】
図４に示すストレージ手段１０７は、図２と図３のようなインフラストラクチャレイヤの構成を備えることによって、スケールアウトすることが可能な極めて高いスケーラビリティを備える。また、ストレージ手段１０７は、大規模なデータを保存することが可能である。また、ストレージ手段１０７は、そのような大規模なデータを１行（１レコード）に納める設計をしても可用性が低下しない。
【００４０】
そこで、本実施形態では、大規模なデータになる可能性がある電話帳やスケジュール帳や日記帳を、図５に示すようなデータ構造の単一のファイルとして、ストレージ手段１０７に記憶させる。個人で使う電話帳などはたかだか数百件程度のエントリで済むことがほとんどであるが、企業の営業部などが共用する電話帳などでは、各エントリのそれぞれにアクセス権を細かく設定したりして拡張性を持たせると、大規模なデータになる可能性がある。
【００４１】
図５では、説明のための一例として電話帳を示している。図示のように、電話帳ファイルでは、「名前」「所属」「電話番号」「電子メールアドレス」などの情報が格納されるフィールドを、１又は複数備えて１つのレコードが形成される。このようなレコードが複数集まって電話帳ファイルが構成される。フィールドは列、レコードは行と表現されてもよい。
【００４２】
ウェブサーバ１０６は、この図５に示すようなデータ構造を持つファイルの中に格納されている情報に対して、そのファイルのＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｎｄｉｃａｔｏｒ）とともに、検索問い合わせのクエリを受信すると、図２及び図３を参照しながら説明したファイルそのものへのクエリと同様に処理し、ストレージ手段１０７から検索結果を得る。
【００４３】
例えば、ウェブサーバ１０６が、クライアントデバイス２００から、電話帳ＵＲＩとともに、電話帳に格納されている名前フィールドが「ＮＡＭＥ１」であるレコードの電話番号フィールドの情報を返すようにクエリを受信すると、ウェブサーバ１０６は、該当ＵＲＩの電話帳に検索問い合わせを行い、検索結果である「Ｔｅｌｅｐｈｏｎｅ  Ｎｕｍｂｅｒ１」をＸＭＬ形式に格納して、クライアントデバイス２００に返す。
【００４４】
つまり、本実施形態においては、ＲＥＳＴでレコードが扱える。このことは、図５のようなファイル内に格納されている情報（例えば、ある人物の電話番号など）を取得する際に迅速なレスポンスが得られる結果をもたらす。図１ないし図３を参照して説明したような大規模分散ファイルシステムにおいては、データアクセスの際にオーバーヘッドが生じるなどの理由で、可用性の確保と引き替えにレスポンスが遅くなる場合がある。ところが、本実施形態においては、クライアントデバイス２００におけるアプリケーションソフトウェア２０１がストレージ手段１０７に記憶されている電話帳にアクセスして電話帳の中に格納されている誰かの電話番号を検索して電話をかけるような場合、アプリケーションソフトウェア２０１が電話帳内の情報に直接アクセスできるインタフェースがＲＥＳＴによって提供されている。したがって、迅速なレスポンスが得られる。
【００４５】
従来技術においては、電話帳は、ＲＦＣ２４２５やＲＦＣ２４２６で規定されるｖＣａｒｄ形式という標準規格フォーマットを使うことが一般的である。ｖＣａｒｄの実装方式はさまざまであるが、１つのファイルに１件の連絡先を収めるようにするのが一般的な実装方式である。しかしながら、図１ないし図３を参照して説明したような大規模分散ファイルシステムにおいては、上述したような理由で１つのファイルに１件の連絡先を収めるような情報の格納形式ではレスポンスが悪い。他方で、レコードをアプリケーションソフトウェア２０１から扱えるインタフェースが用意されていないと、情報へのデータアクセスそのものが難しい。本実施形態によれば、可用性を確保しつつ電話帳内の情報などのデータについて迅速なレスポンスが得られる
【００４６】
上記では電話帳を例に挙げて説明したが、スケジュール帳や日記帳についても図５のようなデータ構造を持つ一つのファイルとして構成してもよい。この場合でも電話帳同様、良好なレスポンスが得られる。
【符号の説明】
【００４７】
１００    クラウド
１０１    ストレージシステム
１０２    ロードバランサ
１０３    ウェブサービスクラスタ
１０４    データベースマネジメントクラスタ
１０５    分散ファイルシステムクラスタ
１０６    ウェブサーバ
１０７    ストレージ手段
２００    クライアントデバイス
２０１    アプリケーションソフトウェア
【図１】
2013235336.tif 000003
【図２】
2013235336.tif 000004
【図３】
2013235336.tif 000005
【図４】
2013235336.tif 000006
【図５】
2013235336.tif 000007