(57)【要約】【課題】、データ列におけるアクセス対象の可変長ブロックデータを容易に特定できるようにする。【解決手段】複数の可変長ブロックデータからなるデータ列を、所定長の複数の検索単位領域に区分けし、各可変長ブロックデータを検索単位領域毎に管理し、データ列に対してデータアクセスを行なうに際して、データアクセス要求に含まれる位置情報に基づいて、アクセス対象の可変長ブロックデータが属する検索単位領域を特定し、特定した検索単位領域に属する可変長ブロックデータを対象に、データアクセス対象の可変長ブロックデータを検索する。【選択図】図３
2018097450.tif 000002
【特許請求の範囲】
【請求項１】
複数の可変長ブロックデータからなるデータ列を、所定長の複数の検索単位領域に区分けし、各可変長ブロックデータを前記検索単位領域毎に管理するブロックデータ管理部と、
前記データ列に対してデータアクセスを行なうに際して、データアクセス要求に含まれる位置情報に基づいて、アクセス対象の可変長ブロックデータが属する検索単位領域を特定する検索単位領域特定部と、
特定した前記検索単位領域に属する前記可変長ブロックデータを対象に、データアクセス対象の可変長ブロックデータを検索するブロック検索部と
を備えることを特徴とする、データ処理装置。
【請求項２】
前記データアクセスとして、前記データ列にライトデータをライトする場合に、
前記検索単位領域特定部が、ライト要求に含まれる前記位置情報に基づいて、前記データ列における、前記ライトデータの先頭が書き込まれる第１の可変長ブロックデータが属する第１の検索単位領域と、前記ライトデータの末尾が書き込まれる第２の可変長ブロックデータが属する第２の検索単位領域とを特定し、
前記ブロック検索部が、前記第１の検索単位領域から前記第１の可変長ブロックデータを抽出するとともに、前記第２の検索単位領域から前記第２の可変長ブロックデータを抽出し、
前記ライトデータの先頭に前記第１の可変長ブロックを、前記ライトデータの末尾に前記第２の可変長ブロックを、それぞれ結合することで更新データを作成し、当該更新データで前記データ列を部分的に置換するライト処理部
を備えることを特徴とする、請求項１記載のデータ処理装置。
【請求項３】
前記更新データを複数の可変長ブロックデータに分割し、各可変長ブロックデータについて重複排除処理を行なう重複排除処理部
を備えることを特徴とする、請求項２記載のデータ処理装置。
【請求項４】
前記データアクセスとして、前記データ列からリードデータをリードする場合に、
前記検索単位領域特定部が、リード要求に含まれる前記位置情報に基づいて、前記データ列における、前記リードデータの先頭となる第１の可変長ブロックデータが属する第１の検索単位領域と、前記リードデータの末尾となる第２の可変長ブロックデータが属する第２の検索単位領域とを特定し、
前記ブロック検索部が、前記第１の検索単位領域から前記第１の可変長ブロックデータを抽出するとともに、前記第２の検索単位領域から前記第２の可変長ブロックデータを抽出し、
前記データ列における、前記第１の可変長ブロックから前記第２の可変長ブロックまでの範囲内から、前記リードデータを抽出するリード処理部
を備えることを特徴とする、請求項１〜３のいずれか１項に記載のデータ処理装置。
【請求項５】
処理装置とメモリとを備えたコンピュータにおいて、
複数の可変長ブロックデータからなるデータ列を、所定長の複数の検索単位領域に区分けし、各可変長ブロックデータを前記検索単位領域毎に管理し、
前記データ列に対してデータアクセスを行なうに際して、データアクセス要求に含まれる位置情報に基づいて、アクセス対象の可変長ブロックデータが属する検索単位領域を特定し、
特定した前記検索単位領域に属する前記可変長ブロックデータを対象に、データアクセス対象の可変長ブロックデータを検索する
処理を前記処理装置に実行させることを特徴とする、データ処理プログラム。
【請求項６】
複数の可変長ブロックデータからなるデータ列を、所定長の複数の検索単位領域に区分けし、各可変長ブロックデータを前記検索単位領域毎に管理し、
前記データ列に対してデータアクセスを行なうに際して、データアクセス要求に含まれる位置情報に基づいて、アクセス対象の可変長ブロックデータが属する検索単位領域を特定し、
特定した前記検索単位領域に属する前記可変長ブロックデータを対象に、データアクセス対象の可変長ブロックデータを検索する
ことを特徴とする、データ処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ処理装置，データ処理プログラムおよびデータ処理方法に関する。
【背景技術】
【０００２】
近年、ソフトウェアやデータなどを、インターネットなどのネットワークを通じてサービスの形で必要に応じて利用するクラウドコンピューティングシステムが知られている。
【０００３】
図２３はクラウドコンピューティングシステムの構成例を模式的に示す図である。
【０００４】
この図２３に示すクラウドコンピューティングシステム５００は、サービスとしてストレージを提供するクラウドストレージサービスであり、業務サーバ５０１，バックアップサーバ５０２，クラウドバックアップゲートウェイ５０３およびクラウド５０４を備える。
【０００５】
クラウド５０４にはオブジェクトストレージ５０５が備えられている。オブジェクトストレージ５０５はクラウドストレージ５０５とも呼ばれる。バックアップサーバ５０２においてはバックアップソフトウェアが実行され、業務サーバ５０１によって生成されたデータは、このバックアップソフトウェアによってバックアップデータとしてコピーされ、オブジェクトストレージ５０５に格納される。
【０００６】
クラウドバックアップゲートウェイ５０３は、バックアップソフトウェアがバックアップとしてコピーしたファイルを、オブジェクトストレージ５０５に転送する。このクラウドバックアップゲートウェイ５０３は、バックアップソフトウェアとクラウドストレージ５０５との間のデータ転送を中継するソフトウェアによって実現される。
【０００７】
クラウドストレージサービスでは、データ量に応じた課金が行なわれることが多い。そのため、クラウドバックアップゲートウェイ５０３には、転送するデータ量を削減することが求められる。データ量を削減するための技術として、例えば重複排除が知られている。
【０００８】
重複排除においては、データ列を所定のサイズの複数のブロック（以下、チャンクという）に分割し、保存済のデータも含めてチャンクどうしを比較し、同一のチャンクは重複して保存しないようにすることで、保存するデータ量を削減する。以下、データ列を複数のチャンクに分割することをチャンキングという。
【０００９】
チャンキングには、固定長チャンキングと可変長チャンキングとが含まれる。
【００１０】
図２４は固定長チャンキングを説明するための図、図２５は可変長チャンキングを説明するための図である。
【００１１】
固定長チャンキングは、図２４に示すように、予め決められた一定のサイズでデータを分割する方式である。これに対して、可変長チャンキングにおいては、データの内容に沿ってデータを分割する位置が計算される。従って、可変長チャンキングにおいては、図２５に示すように、一つのデータ列から得られるチャンクのサイズは一定ではない。
【００１２】
このような可変長チャンキングは、ファイルのバックアップという目的において、固定長チャンキングよりも好適であると考えられる。
【００１３】
図２６は可変長チャンキングを用いたファイルのバックアップを固定長チャンキングと比べて説明するための図である。
【００１４】
一般に、バックアップは定期実行（毎日、毎週、毎月など）で運用される。図２６に示す例においては、符号（Ａ）に示すように、前回バックアップを行なったファイルの先頭に１バイトのデータが追加されたデータのバックアップを新たに行なう場合について示す。
【００１５】
固定長チャンキングにおいては、チャンクサイズが一定のため、ファイルの先頭に１バイトのデータが追加されると、符号（Ｂ）に示すように、後続する全てのチャンクのデータが１バイトずつずれることになる。これにより、全てのチャンクが前回バックアップ時とは異なるデータ内容となり、重複チャンクが無くなる。すなわち、全てのチャンクが保存対象となる。
【００１６】
これに対して、可変長チャンキングでは、データ内容に合わせてチャンク分割がされるため、符号（Ｃ）に示すように、ファイルの先頭に１バイトのデータが追加された場合に、チャンクの境界位置が１バイトずれていくだけであり、先頭のチャンク以外の各チャンクのデータ内容は変化せず、重複チャンクとして扱うことができる。すなわち、先頭のチャンクだけが保存対象となり、他のチャンクは保存対象外となる。
【００１７】
このような特徴から、クラウドバックアップゲートウェイにおいて転送データのデータ量削減を行なうには、可変長チャンキングによる重複排除が適していると言える。
【先行技術文献】
【特許文献】
【００１８】
【特許文献１】国際公開第２０１４／１５５６６８号
【特許文献２】特開２０１２−１４１７３８号公報
【特許文献３】特開２０１１−６５２６８号公報
【発明の概要】
【発明が解決しようとする課題】
【００１９】
一般に、ファイルシステムにおけるデータの入出力インタフェースにおいては、ファイルに対してリードやライトのデータアクセスを行なうために、オフセット，データサイズおよびデータ格納領域の３つの情報が用いられる。
【００２０】
オフセットは、ファイル中におけるデータのリードもしくはライトの対象位置を示し、ファイルの先頭から何バイト目であるかを表す。データサイズは、リードもしくはライトするデータのサイズを示す。データ格納領域は、リードしたデータを格納するメモリ領域や、ライトするデータが格納されているメモリ領域を示す。
【００２１】
ここで、固定長チャンキングされたファイルにおいては、各チャンクのチャンクサイズが等しいので、ファイルを構成するチャンク群を単純な配列で表現することができ、入出力アクセス要求に含まれるオフセットおよびデータサイズから、アクセス対象データの先頭のチャンクと末尾のチャンクとを容易に求めることができる。
【００２２】
具体的には、データ先頭のチャンクインデックスは、オフセットをチャンクサイズで除算（オフセット÷チャンクサイズ）した商の整数部分により取得できる。また、データ末尾のチャンクインデックスは、（オフセット＋データサイズ）をチャンクサイズで除算した商の整数部分により取得できる。
【００２３】
しかしながら、従来のファイルシステムにおいて、可変長チャンキングされたファイルにおいては、アクセス対象となるデータの先頭のチャンクと末尾のチャンクとを容易に求めることができない。
【００２４】
すなわち、アクセス対象データのオフセットおよびデータサイズ情報と、ファイルを構成する各チャンクのオフセットおよびチャンクサイズとの比較検索が必要となる。具体的には、ファイルにおける先頭のチャンクから順番にチャンクサイズの累加等の計算を行なう必要がある。
【００２５】
そのため、ファイルサイズが大きくなるに従ってチャンクを特定するために要する処理時間が大きくなるため、ファイルサイズが大きくなるほどリードやライトが遅くなるという課題がある。
【００２６】
１つの側面では、本発明は、データ列におけるアクセス対象の可変長ブロックデータを容易に特定できるようにすることを目的とする。
【課題を解決するための手段】
【００２７】
このため、このデータ処理装置は、複数の可変長ブロックデータからなるデータ列を、所定長の複数の検索単位領域に区分けし、各可変長ブロックデータを前記検索単位領域毎に管理するブロックデータ管理部と、前記データ列に対してデータアクセスを行なうに際して、データアクセス要求に含まれる位置情報に基づいて、アクセス対象の可変長ブロックデータが属する検索単位領域を特定する検索単位領域特定部と、特定した前記検索単位領域に属する前記可変長ブロックデータを対象に、データアクセス対象の可変長ブロックデータを検索するブロック検索部とを備える。
【発明の効果】
【００２８】
一実施形態によれば、データ列におけるアクセス対象の可変長ブロックデータを容易に特定できる。
【図面の簡単な説明】
【００２９】
【図１】実施形態の一例としてのクラウドストレージシステムの構成を例示する図である。
【図２】実施形態の一例としてのクラウドバックアップゲートウェイのキャッシュ用バッファメモリを説明するための図である。
【図３】実施形態の一例としてのクラウドストレージシステムにおけるファイルの管理方法を説明するための図である。
【図４】図１に示すディレクトリテーブルの構成を示す図である。
【図５】ディレクトリテーブルによって示されるファイルやディレクトリの構成を例示する図である。
【図６】図１に示すエントリテーブルの構成を示す図である。
【図７】図１に示すチャンクマップテーブルの構成を示す図である。
【図８】図１に示すチャンクテーブルの構成を示す図である。
【図９】実施形態の一例としてのクラウドストレージシステムにおけるライトデータを説明するための図である。
【図１０】実施形態の一例としてのクラウドストレージシステムにおけるライトデータの結合を説明するための図である。
【図１１】ライト要求に付加される引数を説明するための図である。
【図１２】実施形態の一例としてのクラウドバックアップゲートウェイにおけるファイルシステムとしてのライト処理の概要を説明するためのフローチャートである。
【図１３】キャッシュ用バッファメモリにおけるライトデータの格納状態を示す図である。
【図１４】キャッシュ用バッファメモリにおけるライトデータの格納状態を示す図である。
【図１５】キャッシュ用バッファメモリにおけるライトデータの格納状態を示す図である。
【図１６】実施形態の一例としてのクラウドストレージシステムにおけるライト処理を説明するための図である。
【図１７】実施形態の一例としてのクラウドストレージシステムにおけるライト処理の詳細を説明するためのフローチャートである。
【図１８】実施形態の一例としてのクラウドストレージシステムにおけるライト処理を説明するための図である。
【図１９】実施形態の一例としてのクラウドストレージシステムにおけるライトデータへの既存チャンクの結合方法を説明するための図である。
【図２０】リード要求の引数を示す図である。
【図２１】実施形態の一例としてのクラウドストレージシステムにおけるリード処理を説明するためのフローチャートである。
【図２２】実施形態の一例としてのクラウドストレージシステムにおけるリード処理を説明するための図である。
【図２３】クラウドコンピューティングシステムの構成例を模式的に示す図である。
【図２４】固定長チャンキングを説明するための図である。
【図２５】可変長チャンキングを説明するための図である。
【図２６】可変長チャンキングを用いたファイルのバックアップを固定長チャンキングと比べて説明するための図である。
【発明を実施するための形態】
【００３０】
以下、図面を参照して本データ処理装置，データ処理プログラムおよびデータ処理方法に係る実施の形態を説明する。ただし、以下に示す実施形態はあくまでも例示に過ぎず、実施形態で明示しない種々の変形例や技術の適用を排除する意図はない。すなわち、本実施形態を、その趣旨を逸脱しない範囲で種々変形して実施することができる。また、各図は、図中に示す構成要素のみを備えるという趣旨ではなく、他の機能等を含むことができる。
【００３１】
（Ａ）構成
図１は実施形態の一例としてのクラウドストレージシステム１の構成を例示する図である。
【００３２】
クラウドストレージシステム１は、クラウド５０に備えられたストレージ（クラウドストレージ５１）の記憶領域をサービスとして提供するクラウドコンピューティングシステムである。
【００３３】
図１に例示するクラウドストレージシステム１は、クラウド５０，業務サーバ５２，バックアップサーバ５３およびクラウドバックアップゲートウェイ１０を備える。
【００３４】
クラウド５０は、複数のサーバコンピュータ（図示省略）を備えるコンピュータネットワークシステムである。クラウド５０は、クラウドストレージ５１を備え、このクラウドストレージ５１の記憶領域をサービスとして提供する。
【００３５】
クラウドストレージ５１はデータのリードやライトが可能な記憶領域であり、１以上の記憶装置により実現される。クラウドストレージ５１は、複数の記憶装置を用いたＲＡＩＤ（Redundant Arrays of Inexpensive Disks）であってもよい。
【００３６】
業務サーバ５２，バックアップサーバ５３およびクラウドバックアップゲートウェイ１０は、例えばユーザのサイトに設置される。
【００３７】
業務サーバ５２は、サーバ機能を備えるコンピュータであり、ユーザが業務等で使用するプログラムを実行することで各種機能を実現する。この業務サーバ５２の記憶領域（図示省略）のデータのコピーが、バックアップサーバ５３およびクラウドバックアップゲートウェイ１０を介して、クラウドストレージ５１に格納される。
【００３８】
バックアップサーバ５３は、例えば、ＮＦＳ（Network File System）クライアントとして機能することで、コピーしたファイルのデータをクラウドバックアップゲートウェイ１０に送信する。
【００３９】
バックアップサーバ５３は、サーバ機能を有するコンピュータであって、バックアップソフトウェアを実行することで、業務サーバ５３のデータのコピーをバックアップとしてクラウドストレージ５１の所定の領域に格納させる。
【００４０】
なお、業務サーバ５２，バックアップサ−バ５３およびクラウドストレージ５１は既知であるので、便宜上、これらの詳細な説明は省略する。また、これらの構成の図示についても省略する。
【００４１】
クラウドバックアップゲートウェイ１０は、バックアップサーバ５３（バックアップソフトウェア）がコピーしたデータをクラウドストレージ５１に転送する。すなわち、クラウドバックアップゲートウェイ１０は、バックアップソフトウェアとクラウドストレージ５１との間のデータ転送を中継するデータ処理装置である。以下、クラウドバックアップゲートウェイ１０が処理するデータを、ファイルもしくはファイルデータという場合がある。
【００４２】
本実施形態においては、図１に示すように、クラウドバックアップゲートウェイ１０は、ＣＰＵ（Central Processing Unit）１１，メモリ１２および記憶装置１４を備えた情報処理装置として構成される。
【００４３】
記憶装置１４は、ハードディスクドライブ（Hard disk drive：ＨＤＤ）、ＳＳＤ（Solid State Drive），ストレージクラスメモリ（Storage Class Memory：ＳＣＭ）等の記憶装置であって、種々のデータを格納するものである。
【００４４】
例えば、記憶装置１４には、管理データベース２４０のデータが格納され、この管理データベース２４０には、後述する、ディレクトリテーブル２４１，エントリテーブル２４２，チャンクマップテーブル２４３およびチャンクテーブル２４４の各データが格納される。
【００４５】
メモリ１２はＲＯＭ（Read Only Memory）およびＲＡＭ（Random Access Memory）を含む記憶メモリである。メモリ１２のＲＯＭには、クラウドバックアップゲートウェイ１０としての機能（例えば、ファイルアクセス制御や重複排除処理）を実現するためのソフトウェアプログラムやこのプログラム用のデータ類が書き込まれてもよい。なお、これらのプログラムやデータ類は記憶装置１４に格納されてもよい。メモリ１２上のソフトウェアプログラムは、ＣＰＵ１１に適宜読み込まれて実行される。また、メモリ１２のＲＡＭは、一次記憶メモリあるいはワーキングメモリとして利用される。
【００４６】
さらに、メモリ１２のＲＡＭにおける特定の記憶領域は、キャッシュ用バッファメモリ１３としても用いられる。
【００４７】
図２は実施形態の一例としてのクラウドバックアップゲートウェイ１０のキャッシュ用バッファメモリ１３を説明するための図である。
【００４８】
後述するファイルアクセス処理部２２は、キャッシュ用バッファメモリ１３に、クラウドストレージ５１に書き込むためのライトデータや、クラウドストレージ５１から読み出したリードデータを格納する。
【００４９】
なお、以下、キャッシュ用バッファメモリ１３を、単にバッファメモリ１３という場合がある。また、バッファメモリ１３におけるライトデータを格納する領域を、ライトデータ格納領域という。また、バッファメモリ１３におけるリードデータを格納する領域を、リードデータ格納領域という。
【００５０】
キャッシュ用バッファメモリ１３に格納されたライトデータは、後述の如く、ファイルアクセス処理部２２により複数の可変長チャンクに分割（チャンキング）される。すなわち、ファイルアクセス処理部２２は、キャッシュ用バッファメモリ１３を用いて、クラウドストレージ５１に対するデータのライトやリードを行なう。
【００５１】
図２に示すように、キャッシュ用バッファメモリ１３は、データキャッシュとして用いられるキャッシュメモリ領域１３ａの前後に、本クラウドストレージシステム１において予め規定された最大のチャンクサイズ（最大チャンクサイズ）の領域である最大チャンクサイズ領域１３ｂをそれぞれ有する。
【００５２】
従って、キャッシュ用バッファメモリ１３は、キャッシュメモリ領域１３ａのサイズに、最大チャンクサイズ領域１３ｂのサイズの２倍を加算したサイズ（バッファメモリサイズ）を有する。
【００５３】
ＣＰＵ１１は、種々の制御や演算を行なう処理装置であり、メモリ１２に格納されたＯＳやプログラムを実行することにより、種々の機能を実現する。すなわち、ＣＰＵ１１がデータ処理プログラムを実行することで、図１に示すように、重複排除処理部２１およびファイルアクセス処理部（ブロックデータ管理部，探索単位領域特定部，ブロック探索部，ライト処理部，リード処理部）２２としての機能を実現する。
【００５４】
なお、クラウドバックアップゲートウェイ１０において、重複排除処理部２１およびファイルアクセス処理部２２としての機能を実現するためのプログラム（データ処理プログラム）は、例えばフレキシブルディスク，ＣＤ（ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＣＤ−ＲＷ等），ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−ＲＡＭ，ＤＶＤ−Ｒ，ＤＶＤ＋Ｒ，ＤＶＤ−ＲＷ，ＤＶＤ＋ＲＷ，ＨＤ  ＤＶＤ等），ブルーレイディスク，磁気ディスク，光ディスク，光磁気ディスク等の、コンピュータ読取可能な記録媒体に記録された形態で提供される。そして、コンピュータはその記録媒体からプログラムを読み取って内部記憶装置または外部記憶装置に転送し格納して用いる。また、そのプログラムを、例えば磁気ディスク，光ディスク，光磁気ディスク等の記憶装置（記録媒体）に記録しておき、その記憶装置から通信経路を介してコンピュータに提供するようにしてもよい。
【００５５】
重複排除処理部２１およびファイルアクセス処理部２２としての機能を実現する際には、内部記憶装置（本実施形態ではメモリ１２）に格納されたプログラムがコンピュータのマイクロプロセッサ（本実施形態ではＣＰＵ１１）によって実行される。このとき、記録媒体に記録されたプログラムをコンピュータが読み取って実行するようにしてもよい。
【００５６】
ファイルアクセス処理部２２は、処理対象のファイルデータを管理するファイル管理機能を実現する。
【００５７】
（ａ）可変長チャンキング
ファイルアクセス処理部２２は、データファイルを複数のデータブロック（チャンク）に分割するデータ分割部としての機能を備える。例えば、ファイルアクセス処理部２２は、バックアップサーバ５３等の外部装置から受信するバックアップデータ（データファイル）を分割する。
【００５８】
ファイルアクセス処理部２２は、データファイルアクセスを複数の可変長のチャンク（可変長チャンク，部分データ）に分割し（可変長チャンキング処理）、クラウドストレージ５１に対して、チャンク単位でファイルのリード処理やライト処理を行なう。そして後述する重複排除処理部２１は、これらの生成された可変長チャンク毎に重複排除処理を行なう。
【００５９】
ファイルアクセス処理部２２は、処理対象のファイルに対して、例えばＣＤＣ（Content Defined Chunking）方式により可変長チャンクキング（可変長チャンク分割）を行なう。
【００６０】
ＣＤＣにおいては、ファイルが、その内容に応じて可変長のブロック（チャンク）に分割される。ファイルアクセス処理部２２は、ファイル（データ列）を、その先頭から固定長のWindowを１バイトずつスライドさせながらハッシュ値を計算することで、チャンクの境界線を求める。なお、ＣＤＣは既知の手法であるので、その詳細な説明は省略する。
【００６１】
また、ファイルアクセス処理部２２は、上記のＣＤＣにおける計算量を減らすために、Rabin-karp rolling hashアルゴリズムを併用してもよい。なお、Rabin-karp rolling hashアルゴリズムについても既知の手法であるので、その詳細な説明は省略する。
【００６２】
（ｂ）ファイルシステム管理
ファイルアクセス処理部２２は、ファイルシステム管理機能を備え、クラウドストレージ５１に対してデータのリードやライトを行なう。
【００６３】
例えば、ファイルアクセス処理部２２は、ＮＦＳサーバとして機能することで、バックアップサーバ５３によってコピーされたデータをファイルとしてクラウドストレージ５１に送信して格納させる。
【００６４】
図３は実施形態の一例としてのクラウドストレージシステム１におけるファイルの管理方法を説明するための図である。
【００６５】
図３に例示するファイルは、チャンク０〜３の４つの可変長チャンクにより構成されている。
【００６６】
ファイルアクセス処理部２２は、図３に示すように、ファイルを、その先頭から固定長（図３に示す例では２００バイト）の複数（図３に示す例では２つ）の検索単位領域（リージョン）に区分け（区画，分割）する。以下、検索単位領域をリージョンという。リージョンのサイズは、チャンクサイズよりも大きい。従って、各リージョンには１つ以上のチャンクが含まれる。
【００６７】
これにより、ファイルを構成する可変長チャンクは、いずれかのリージョンに含まれることになる。すなわち、ファイルにおいて可変長チャンクはいずれかのリージョンに割り当てられる。
【００６８】
本クラウドストレージシステム１においては、リージョンをリージョン番号を用いて特定する。
【００６９】
図３に示す例においては、リージョン番号“０”のリージョンをリージョン０と表し、リージョン番号“１”のリージョンをリージョン１と表す。
【００７０】
リージョンはファイルを等間隔で区分けするので、このリージョンを用いることでファイルにおける位置を特定することができる。すなわち、リージョンは、チャンクのインデックスとして機能する。従って、ファイルアクセス処理部２２は、ファイルを固定長を有する複数のリージョンで等間隔に区分けすることで、可変長チャンクによって構成されるファイルを固定長化していると言える。
【００７１】
図３に示す例においては、チャンク０，１，２がリージョン０に属し、チャンク３がリージョン１に属している。本実施形態においては、チャンクの位置をその先頭位置で表しているが、これに限定されるものではない。例えば、チャンクの末尾や中央でその位置を表してもよく、適宜変更して実施することができる。
【００７２】
ファイルアクセス処理部２２は、ディレクトリテーブル２４１，エントリテーブル２４２，チャンクマップテーブル２４３およびチャンクテーブル２４４を用いて、ファイル管理を行なう。これらのディレクトリテーブル２４１，エントリテーブル２４２，チャンクマップテーブル２４３およびチャンクテーブル２４４は、例えば、図１に示すように、管理データベース２４０に登録されて管理される。
【００７３】
図４は図１に示すディレクトリテーブル２４１の構成を示す図である。また、図５はディレクトリテーブル２４１によって示されるファイルやディレクトリの構成を例示する図である。
【００７４】
ディレクトリテーブル２４１は、ディレクトリ階層を表す管理情報である。図４に示すように、ディレクトリテーブル２４１は、項目parent，nameおよびinoを対応付けて構成される。parentは、親ディレクトリのinode番号であり、データ型（型）は数値である。inodeは、ファイルシステムにおいてファイルやディレクトリについての情報を記録した管理データである。
【００７５】
nameはエントリの名前であり、ディレクトリ名とファイル名との組合せ（ディレクトリ名/ファイル名）として登録される。nameのデータ型は文字列である。inoは、エントリのinode番号であり、データ型は数値である。
【００７６】
ディレクトリテーブル２４１は、項目inoをキーとするハッシュテーブルとして構成され、図５に示すように、inoとparentとを用いてリンクをたどることで、指定したinoのレコードを高速に検索することができる。なお、ディレクトリテーブル２４１を一般的なＳＱＬ（Structured Query Language）データベースで実現してもよい。また、ディレクトリテーブル２４１には、図４に示した以外の項目を備えてもよい。
【００７７】
図６は図１に示すエントリテーブル２４２の構成を示す図である。
【００７８】
エントリテーブル２４２は、ディレクトリやファイルのメタデータを表す管理情報である。図６に示すように、エントリテーブル２４２は、項目ino，mode，nlink，uid，gid，size，atime，mtimeおよびctimeを対応付けて構成されている。
【００７９】
inoは、inode番号を表しディレクトリテーブル２４１のinoにヒモ付けられる。modeは権限情報を表す。nlinkはハードリンクの数を表し、uidは所有者のユーザＩＤを表す。gidは所有者のグループＩＤを表し、sizeはファイルサイズを表す。atimeは、最終アクセス時刻を表し、mtimeは最終更新時刻を表す。また、ctimeは最終状態変更時刻を表す。これらのino，mode，nlink，uid，gid，size，atime，mtimeおよびctimeのデータ型は、いずれも数値である。
【００８０】
エントリテーブル２４２は、項目inoをキーとするハッシュテーブルとして構成され、これにより、指定したinoのレコードを高速に検索することができる。なお、エントリテーブル２４２を一般的なＳＱＬデータベースで実現してもよい。また、エントリテーブル２４２には、図６に示した以外の項目を備えてもよい。
【００８１】
図７は図１に示すチャンクマップテーブル２４３の構成を示す図である。
【００８２】
チャンクマップテーブル２４３は、ファイルを構成するチャンクを表す管理情報であり、ファイルがどのようなチャンクで構成されているかを示す。図７に示すように、チャンクマップテーブル２４３は、項目ino，region，offset，sizeおよびhashを対応付けて構成されている。
【００８３】
inoは、inode番号を表し、エントリテーブル２４２のinoにヒモ付けられる。regionは、リージョン番号を示す。このregionは、当該チャンクがファイル内においてどのリージョンに含まれる（属する）かを示す。
【００８４】
チャンクマップテーブル２４３に、管理項目としてこのregionを備えることにより、チャンクに、ファイル内でのリージョン番号が関連付けられる。ファイルアクセス処理部２２は、このチャンクマップテーブル２４３を作成し、更新・管理を行なうことで、ファイルを構成する複数の可変長チャンクを、リージョン毎に管理するブロックデータ管理部として機能するのである。
【００８５】
図３に示す例においては、チャンク０，１，２がリージョン０に属しており、チャンク３がリージョン１に属している。
【００８６】
offsetは、オフセットの値を示し、ファイルの先頭からの位置を示す。sizeは、チャンクサイズを示す。hashは、当該チャンクのハッシュ値であり、チャンクの内容の特定に用いられる。
【００８７】
なお、ino，region，offsetおよびsizeのデータ型は、いずれも数値であり、hashのデータ型はバイト列である。
【００８８】
チャンクマップテーブル２４３は、項目regionをキーとするハッシュテーブルとして構成され、指定したregionのレコードを高速に検索することができる。なお、チャンクマップテーブル２４３を一般的なＳＱＬデータベースで実現してもよい。なお、チャンクマップテーブル２４３には、図７に示した以外の項目を備えてもよい。
【００８９】
図８は図１に示すチャンクテーブル２４４の構成を示す図である。
【００９０】
チャンクテーブル２４４は、チャンクを表す管理情報である。図８に示すように、チャンクテーブル２４４は、項目size，hash，refcntおよびchunkを対応付けて構成されている。
【００９１】
sizeは、そのチャンクのチャンクサイズを示す。hashは、当該チャンクのハッシュ値であり、チャンクの内容の特定に用いられる。このhashは、チャンクマップテーブル２４３のhashにヒモ付けられる。refcntは、当該チャンクを有するファイルの数を示す。chunkは、チャンクデータの実態（実データ）である。なお、チャンクテーブル２４４にchunkとしてチャンクの実データを備える代わりに、他の記憶領域にチャンクの実データを格納し、チャンクテーブル２４４のchunkには、その記憶領域へのポインタ情報等を設定してもよく、種々変形して実施することができる。
【００９２】
なお、size，hashおよびrefcntのデータ型は、いずれも数値であり、chunkのデータ型はバイト列である。
【００９３】
チャンクテーブル２４４は、項目hashをキーとするハッシュテーブルとして構成され、指定したhushのレコードを高速に検索することができる。なお、チャンクテーブル２４４を一般的なＳＱＬデータベースで実現してもよい。また、チャンクテーブル２４４には、図８に示した以外の項目を備えてもよい。そして、重複排除処理部２１は、このチャンクテーブル２４４を用いることで、重複排除処理を実現する。
【００９４】
ファイルアクセス処理部２２によるクラウドストレージ５１へのライト処理について説明する。
【００９５】
ファイルアクセス処理部２２によるファイルデータの書き込みは、クラウドストレージ５１に対する所定サイズのライト要求を複数回繰り返して行なうことで実現され、最後にファイルのフラッシュやクローズが行なわれる。
【００９６】
図９は実施形態の一例としてのクラウドストレージシステム１におけるライトデータを説明するための図、図１０は実施形態の一例としてのクラウドストレージシステム１におけるライトデータの結合を説明するための図である。
【００９７】
図９に示すように、１回のライト要求で受け渡されるライトデータが、複数のチャンクに分割される場合がある。ライトデータを、その先頭から順番に複数のチャンクに分割した後に残る余りの部分（余りデータ）が１つのチャンクとして分割されるとは限らない。ファイルアクセス処理部２２は、このように１つのチャンクとすることができない余りデータを、次のライト要求のライトデータの先頭部分と結合することで１つのチャンクを生成する。
【００９８】
このような余りデータの結合処理は、書き込み処理性能の劣化に繋がる。そのため、ファイルアクセス処理部２２は、図１０に示すように、複数回分のライトデータをバッファメモリ１３上にキャッシュし、できるだけ大きいサイズでチャンキング処理することにより、結合処理の回数を減らして処理性能の劣化を抑制する。
【００９９】
図１１はライト要求に付加される引数を説明するための図である。
【０１００】
この図１１に示すように、ライト要求には、例えば、ino, offset, sizeおよびdataが引数として付加される。すなわち、ライト要求をwrite(ino, offset, size, data)と表すことができる。
【０１０１】
引数inoは、ライト要求に割り当てられたinode番号である。offsetは、データ（data）を書き込むファイルの位置（ファイル先頭からのバイト数）を表す。sizeは、ライトデータ（data）のサイズ（バイト）であり、dataはライトデータそのものである。offsetやsizeは、ファイルにおけるデータアクセス（ライト）対象の位置を示す位置情報として用いられる。
【０１０２】
重複排除処理部２１は、チャンク単位で重複排除処理を行なう。例えば、重複排除処理部２１クラウドストレージ５１にデータファイルのライトを行なう際に、クラウドストレージ５１に既に同一のチャンクが格納されている場合には、当該チャンクをクラウドストレージ５１に格納することを阻止することで重複排除を実現する。
【０１０３】
重複排除処理部２１は、複数のチャンク間において重複排除を実行し、重複排除を実行して得られたチャンクをクラウドストレージ５１に記憶させる。
【０１０４】
重複排除処理部２１は、チャンクのＦＰ（フィンガープリント：Finger Print）、すなわち、当該チャンクに含まれるデータのハッシュ値を相互に比較することによりチャンクの一致／不一致を判断し、これによりチャンクの重複を判断する。また、重複排除処理部２１は、チャンクのＦＰをクラウドストレージ５１に格納されている既存の各チャンクのＦＰと比較することでもチャンクの重複を判断する。すなわち、重複排除処理部２１は、重複記憶判定を行なう。
【０１０５】
本実施形態においては、重複排除処理部２１は、ＦＰが同一のチャンクは同一のデータブロックであると判断する。
【０１０６】
重複排除処理部２１は、例えば、ファイルをクラウドストレージ５１に格納する際に、そのファイルを構成する個々のチャンクについて、それぞれ、チャンクテーブル２４４を参照して複記憶判定を行なう。
【０１０７】
チャンクテーブル２４４は、前述の如く、各チャンクのhashを備えており、このhashが、チャンクを特定するＦＰ情報として機能する。すなわち、チャンクテーブル２４４は、重複排除処理部２１が重複排除に用いる重複排除情報として機能する。
【０１０８】
重複排除処理部２１は、チャンクテーブル２４４のhashを用いることによりチャンクの一致／不一致を判断し、これによりチャンクの重複を判断する。このhashは、既知の種々の手法を用いて実現することができ、その詳細な説明は省略する。
【０１０９】
重複排除処理部２１は、チャンクテーブル２４４（重複排除情報）を参照することで、各チャンクと同一のチャンクがクラウドストレージ５１に記憶されているか否かを判定する。
【０１１０】
また、重複排除処理部２１は、例えば、ファイルをクラウドストレージ５１に格納する際に、処理対象のチャンクと同一のチャンクがクラウドストレージ５１に格納されていると判断した場合には、その処理対象のチャンクを廃棄し、その処理対象チャンクのクラウドストレージ５１における重複保存を抑止する。すなわち、重複排除処理部２１は、同一のhashのデータブロックを一のクラウドストレージ５１においては１つしか記憶させない、重複排除（デデュープ：De-dupulication）を実現する。
【０１１１】
重複排除処理部２１は、クラウドストレージ５１中には１つだけ記憶させたチャンクを複数のファイルで共用することにより、ファイルの記憶領域を削減する。すなわち、重複排除処理部２１は、重複排除エンジンとして機能する。
【０１１２】
なお、重複排除には、例えば、ファイルのデータを重複排除処理部２１で比較しながらクラウドストレージ５１に記憶するインライン方式を用いることができる。なお、これに限定されるものではなく、例えば、いわゆるポストプロセス方式やクライアント方式等の他の手法を用いてもよく、適宜変更して実施することができる。
【０１１３】
また、重複排除処理部２１は、チャンク毎に行なったhashやチャンク構成の作成等の結果を、チャンクテーブル２４４に保存する。
【０１１４】
さらに、重複排除処理部２１は、クラウドストレージ５１からファイルを読み出す際には、そのクラウドストレージ５１に記憶されたボリュームについてのチャンクテーブル２４４を読み出す。
【０１１５】
重複排除処理部２１は、データの読み出し時において、チャンクからボリュームを復元する。重複排除処理部２１は、例えば、チャンクテーブル２４４を参照し、クラウドストレージ５１から読み出したチャンクを用いてファイルの復元を行なう。すなわち、重複排除処理部２１は、チャンクテーブル２４４に従って、チャンクの複写等を行なうことによりファイルを作成する。
【０１１６】
なお、チャンクテーブル２４４に基づくチャンクを用いたファイルの復元方法は、既知の種々の手法を用いて実現され、その詳細な説明は省略する。
【０１１７】
（Ｂ）動作
上述の如く構成された実施形態の一例としてのクラウドストレージシステム１におけるクラウドバックアップゲートウェイ１０における処理を説明する。
【０１１８】
（ａ）ファイルシステムとしてのライト処理
図１２は実施形態の一例としてのクラウドバックアップゲートウェイ１０におけるファイルシステムとしてのライト処理の概要を説明するためのフローチャート（ステップＡ１〜Ａ４）である。
【０１１９】
以下においては、新規にファイルを作成する場合の処理を示す。
【０１２０】
ステップＡ１において、ファイルアクセス処理部２２は、ディレクトリテーブル２４１のレコードを作成し、保存する。
【０１２１】
ファイルアクセス処理部２２は、新規に作成するファイルに対してinode番号を新規に割り当てる。
【０１２２】
ステップＡ２において、ファイルアクセス処理部２２は、エントリテーブル２４２のレコードを作製し、保存する。
【０１２３】
ステップＡ３において、ファイルアクセス処理部２２は、クラウドストレージ５１に対するデータ書き込みを行なう。
【０１２４】
ここで、ファイルアクセス処理部２２は、可変長チャンキングによるチャンク作成と保存とを行なう。また、併せて、ファイルアクセス処理部２２は、チャンクマップテーブル２４３およびチャンクテーブル２４４の作成も行なう。
【０１２５】
ファイルアクセス処理部２２は、以下の処理（１）〜（３）に従って、ライト要求を処理する。
【０１２６】
図１３〜図１５は、それぞれキャッシュ用バッファメモリ１３におけるライトデータの格納状態を示す図である。
【０１２７】
（１）クラウドバックアップゲートウェイ１０において、バックアップサーバ５３から最初のライト要求を受信すると、ファイルアクセス処理部２２は、図１３に示すように、キャッシュ用バッファメモリ１３におけるキャッシュメモリ領域１３ａの先頭位置にライトデータ（data）をsize分コピーする。 なお、sizeはライト要求に引数として付加されていた値である。
【０１２８】
すなわち、size分のライトデータ（data）をコピーして、キャッシュ用バッファメモリ１３におけるキャッシュメモリ領域１３ａの先頭位置に格納する。
【０１２９】
また、ファイルアクセス処理部２２は、offsetにsizeを加算した値（offset+size）をメモリ１２等の所定の領域に記憶する。
【０１３０】
（２）ファイルアクセス処理部２２は、次のライト要求を受信すると、offsetとoffset+sizeとを比較する。
【０１３１】
比較の結果、offsetとoffset+sizeとが一致した場合には、ファイルアクセス処理部２２は、処理中のライト要求が上記処理（１）と連続したライト要求であると判断し、図１４に示すように、キャッシュメモリ領域１３ａにおける、前回格納したデータに後続する位置に、ライトデータ（data）を格納する。
【０１３２】
ここで、キャッシュメモリ領域１３ａにライトデータを格納できるだけの空きがない場合には、ファイルアクセス処理部２２は、キャッシュメモリ領域１３ａにあるデータを、可変長チャンキング処理を行なった上でクラウドストレージ５１に移動させる。
【０１３３】
また、この可変長チャンキング処理により余りデータが生じた場合には、ファイルアクセス処理部２２は、図１５に示すように、この余りデータをキャッシュメモリ領域１３ａの先頭位置に移動させる。
【０１３４】
そして、ファイルアクセス処理部２２は、キャッシュメモリ領域１３ａに空きがなくて格納できなかったライトデータを、キャッシュメモリ領域１３ａにおける、余りデータに後続する位置に格納する。
【０１３５】
一方、比較の結果、offsetとoffset+sizeとが不一致である場合には、ファイルアクセス処理部２２は、新たに受信したライト要求は、先に処理したライト要求とは異なる（不連続の）ものであると判断する。ファイルアクセス処理部２２は、キャッシュメモリ領域１３ａにあるデータを、可変長チャンキング処理を行なった上でクラウドストレージ５１に移動させる。また、ファイルアクセス処理部２２は、offsetにsizeを加算した値（offset+size）をメモリ１２等の所定の領域に記憶する。
【０１３６】
（３）ファイルアクセス処理部２２は、ファイルのフラッシュ／クローズを行なう。すなわち、ファイルアクセス処理部２２は、キャッシュ用バッファメモリ１３に格納されているデータを、可変長チャンキング処理を行なった上でクラウドストレージ５１に移動させる。なお、ファイルアクセス処理部２２による可変長チャンキング処理の詳細については、図１８等を用いて後述する。
【０１３７】
また、ファイルアクセス処理部２２は、可変長チャンキングを行なうことにより、キャッシュメモリ領域１３ａにおいて余った余りデータを、そのままチャンクとして扱い、クラウドストレージ５１に保存する。
【０１３８】
その後、ステップＡ４において、ファイルアクセス処理部２２は、エントリテーブル２４２のレコード更新および保存を行なう。具体的には、ファイルアクセス処理部２２は、サイズ情報（size）や時刻情報（atime）等の更新を行なう。
【０１３９】
（ｂ）ライト処理
次に、ファイルアクセス処理部２２によるライト処理の詳細について説明する。
【０１４０】
ファイルアクセス処理部２２は、キャッシュ用バッファメモリ１３上のデータに対して、可変長チャンキングを行なうことでチャンク（可変長チャック）を作成し保存する。
【０１４１】
クラウドバックアップゲートウェイ１０は、キャッシュ用バッファメモリ１３に関して、offsetとsizeとの２つの入力情報を管理する。
【０１４２】
ここで、入力情報offsetは、キャッシュ用バッファメモリ１３内のデータを書き込むファイルの位置（ファイル先頭からのバイト数）である。また、入力情報sizeは、    キャッシュ用バッファメモリ１３内の有効なデータのサイズ（バイト）である。
【０１４３】
図１６は実施形態の一例としてのクラウドストレージシステム１におけるファイルアクセス処理部２２によるライト処理を説明するための図である。
【０１４４】
ライト要求が既存ファイルに対する追記である場合、このoffsetの直前のチャンクが存在することになるが、そのチャンクは、可変長チャンキングとして余ったデータ（余りデータ）である可能性がある。なお、余りデータとは、チャンクとして区切りよく（きれいに）分割されていないデータを意味する。
【０１４５】
また、ライト要求が既存ファイルに対する更新である場合、このoffsetとsizeに重なるチャンクが存在する。
【０１４６】
このような既存チャンクは、新しいデータと結合することでチャンク境界が変化する可能性があるため、バッファメモリ上にコピーする必要がある。
【０１４７】
図１６に示すように、ファイルアクセス処理部２２は、余りデータに後続させてライトデータを追加する。
【０１４８】
上述の如く構成された実施形態の一例としてのクラウドストレージシステム１におけるライト処理の詳細を、図１８を参照しながら、図１７に示すフローチャート（ステップＢ１〜Ｂ４）に従って説明する。なお、図１８は本クラウドストレージシステム１におけるライト処理を説明するための図である。
【０１４９】
図１８においては、可変長チャンキングされたファイルに、オフセット700からサイズ2000バイトのデータ（ライトデータ）をライトする例について示す。
【０１５０】
ステップＢ１において、ファイルアクセス処理部２２は、ライトデータの先頭に関連するチャンク情報の習得を行なう。
【０１５１】
具体的には、先ず、ライト要求に引数として付加されたoffsetをリージョンサイズで除算した値（offset÷リージョンサイズ）を算出し、その商の整数部分をリージョン番号として判断することで、ライトデータの先頭に対応するチャンクが属するリージョンを特定する。
【０１５２】
図１８に示す例においては、ファイルアクセス処理部２２は、以下の式を算出することで、ライトデータの先頭に対応するチャンクが属するリージョン番号を取得する。以下の式においては、商の整数部分がリージョン番号として用いられる。
【０１５３】
700（オフセット）÷1000（リージョンサイズ）≒0（＝リージョン０）
これにより、ライトデータの先頭部分に対応するチャンクは、リージョン０に属していることがわかる。
このように、ファイルアクセス処理部２２は、ライト要求に含まれる位置情報（offset＆size）に基づいて、ファイルにおける、ライトデータの先頭が書き込まれるチャンク（第１の可変長ブロックデータ）が属するリージョン（第１のリージョン，第１の検索単位領域）を特定する。
次に、ファイルアクセス処理部２２は、チャンクマップテーブル２４３を参照して、先に特定したリージョン番号を有するレコード（チャンク）を取得する。図１８に示す例においては、チャンク０，１，２が、リージョン０に属する。
【０１５４】
その後、ファイルアクセス処理部２２は、取得した各レコードのoffsetおよびsizeと、入力されたライトデータ（入力情報）のoffsetおよびsizeとを比較する。そして、ファイルアクセス処理部２２は、offsetおよびsizeが、入力情報のoffsetおよびsizeに相当するレコードを選択する。
【０１５５】
図１８に示す例においては、ライトデータのオフセットが700であるので、オフセット500〜800であるチャンク１が、このライトデータと部分的に重なる。また、チャンク０のオフセットは0〜500であるので、ライトデータとは重ならない。ライトデータは、オフセット700を始点として、2000バイトのデータサイズを有するので、オフセット800を始点とし、サイズ700のチャンク２の全てがライトデータに重合する。すなわち、チャンク２はライトデータによって全体が上書き（変更）される。
【０１５６】
従って、ファイルアクセス処理部２２は、ライトデータの先頭に関連するチャンクとして、チャンク１を特定する。このように、ファイルアクセス処理部２２は、特定した第１のリージョンに含まれるチャンクに対してオフセット検索を行なうことで、ライトデータの先頭に関連するチャンクを検索する。
【０１５７】
ステップＢ２において、ファイルアクセス処理部２２は、ライトデータの末尾に関連するチャンク情報の習得を行なう。ファイルアクセス処理部２２は、ステップＢ１と同様の手法で、ライトデータの末尾に関連するチャンクを特定する。
【０１５８】
図１８に示す例においては、ファイルアクセス処理部２２は、以下の式を算出することで、ライトデータの末尾に対応するチャンクが属するリージョン番号を取得する。
【０１５９】
なお、ファイルアクセス処理部２２は、“（offset+size）÷リージョンサイズ”を算出することでライトデータの末尾に関連するチャンクのリージョン（第２のリージョン）を求める。ファイルアクセス処理部２２は以下の式を算出する。以下の式においては、商の整数部分がリージョン番号として用いられる。
【０１６０】
2700（オフセット）÷1000（リージョンサイズ）≒2（＝リージョン２）
これにより、ライトデータの末尾部分に対応するチャンクは、リージョン２に属していることがわかる。
【０１６１】
このように、ファイルアクセス処理部２２は、ライト要求に含まれる位置情報（offset＆size）に基づいて、ファイルにおける、ライトデータの末尾が書き込まれるチャンク（第２の可変長ブロックデータ）が属するリージョン（第２のリージョン，第２の検索単位領域）を特定する。
【０１６２】
そして、ファイルシステム処理部２２は、ファイルに対してデータアクセスを行なうに際して、データアクセス要求に含まれる位置情報（offset＆size）に基づいて、アクセス対象の可変長チャンクが属するリージョンを特定する検索単位領域特定部として機能するのである。
【０１６３】
また、図１８に示す例においては、ライトデータのオフセットが700であり、且つ、データサイズが2000バイトである。
【０１６４】
従って、オフセット2700〜3000のチャンク６が、このライトデータの末尾と部分的に重なる。また、チャンク５のオフセットは2300〜2700であるので、この「チャンク５の全てがライトデータと重合する。ライトデータは、オフセット700を始点として、2000バイトのデータサイズを有するので、オフセット2300を始点とし、サイズ400のチャンク５の全てがライトデータに重合する。すなわち、チャンク５はライトデータによって全体が上書き（変更）される。
【０１６５】
従って、ファイルアクセス処理部２２は、ライトデータの末尾に関連するチャンクとして、チャンク６を特定する。このように、ファイルアクセス処理部２２は、特定した第２のリージョンに含まれるチャンクに対してオフセット検索を行なうことで、ライトデータの末尾に関連するチャンクを検索する。
【０１６６】
このように、ファイルアクセス処理部２２は、特定したリージョンに属する可変長チャンクを対象に、データアクセス対象の可変長チャンクを検索するブロック検索部として機能するのである。
【０１６７】
ステップＢ３において、ファイルアクセス処理部２２は、ライトデータに、ステップＢ１，Ｂ２でそれぞれ特定した、ライトデータの先頭および末尾にそれぞれ重なる既存のチャンク（既存チャンク）を結合する。
【０１６８】
すなわち、ファイルアクセス処理部２２は、チャンクマップテーブル２４３を参照して、ステップＢ１で求めた、ライトデータの始点（先頭）に重なるチャンクのhashを取得する。ファイルアクセス処理部２２は、取得したhashに基づいてチャンクテーブル２４４を参照し、このhashと同じ値を有するレコードのchunk（チャンクデータ）を第１の既存チャンク（第１の可変長ブロックデータ）として読み出す。
【０１６９】
また、ファイルアクセス処理部２２は、チャンクマップテーブル２４３を参照して、ステップＢ２で求めた、ライトデータの末尾に重なるチャンクのhashを取得する。ファイルアクセス処理部２２は、取得したhashに基づいてチャンクテーブル２４４を参照し、このhashと同じ値を有するレコードのchunk（チャンクデータ）を第２の既存チャンク（第２の可変長ブロックデータ）として読み出す。
【０１７０】
ファイルアクセス処理部２２は、読み出した第１の既存チャンクを、ライトデータの先頭に、また、第２の既存チャンクをライトデータの末尾にそれぞれ結合することで、処理対象ファイルに対する更新データを作成する。
【０１７１】
図１９は実施形態の一例としてのクラウドストレージシステム１におけるライトデータへの既存チャンクの結合方法を説明するための図である。
【０１７２】
ファイルアクセス処理部２２は、キャッシュ用バッファメモリ１３を用いて、ライトデータに既存チャンクを結合する。
【０１７３】
図１９においては、キャッシュメモリ領域１３ａにライトデータが格納され、ライトデータの先頭に既存チャンク１（チャンク１）を、また、ライトデータの末尾に既存チャンク６（チャンク６）を、それぞれ結合する例を示す。
【０１７４】
ライトデータに既存チャンクを結合するに際して、ライトデータと既存チャンクとで重なる部分については、新しいデータであるライトデータを用いる。
【０１７５】
そして、このように、ライトデータの先頭と末尾とにそれぞれ既存チャンクが結合されたデータ（更新データ）が、可変長チャンキングの処理対象となる。
【０１７６】
その後、ステップＢ４において、ファイルアクセス処理部２２は、キャッシュ用バッファメモリ１３に格納された、可変長チャンキングの処理対象のデータをチャンク分割する。また、ファイルアクセス処理部２２は、チャンクマップテーブル２４３およびチャンクテーブル２４４の各レコードを生成し、保存する。
【０１７７】
具体的には、ファイルアクセス処理部２２は、キャッシュ用バッファメモリ１３のデータをチャンク分割する。ファイルアクセス処理部２２は、生成したチャンクデータに基づき、チャンクのオフセット（offset），サイズ（size），リージョン番頭（region）およびハッシュ値（hash）をそれぞれ求める。
【０１７８】
なお、リージョン番号は、offset÷リージョンサイズを算出し、その商の整数値により求められる。
【０１７９】
ファイルアクセス処理部２２は、求めた各値を用いて、例えば、チャンクマップテーブル２４３のレコードを作成し、保存する。
【０１８０】
また、ここで、重複排除処理部２１は、生成したチャンクのhashに基づいてチャンクテーブル２４４を参照し、チャンクテーブル２４４からhashに対応するレコードを取得できるか否かを確認する。
【０１８１】
チャンクテーブル２４４から同一のhashのレコードを取得できない場合には、新規チャンクとして、チャンクテーブル２４４にレコードを作成して保存する。
【０１８２】
また、チャンクテーブル２４４から同一のhashのレコードを取得できた場合には、重複排除処理部２１は、チャンクテーブル２４４における、取得したレコードのrefcntを１加算（インクリメント）して、チャンクテーブル２４４の当該レコードを更新する。重複排除処理部２１は、チャンクテーブル２４４に同一のhashのレコードが既に格納されているので、重複排除のために生成したチャンクのhashは廃棄する。
【０１８３】
このようにして、重複排除処理部２１は、ファイルアクセス処理部２２によって可変長チャンキングが行なわれた各チャンクについて、重複排除処理を行なう。
【０１８４】
また、このように重複排除処理が行なわれた後の更新データを用いてファイルの更新が行なわれる。従って、ファイルアクセス処理部２２は、更新データでファイルを部分的に置換するライト処理部として機能するのである。
【０１８５】
（ｃ）リード処理
次に、実施形態の一例としてのクラウドストレージシステム１におけるリード処置について説明する。
【０１８６】
図２０はリード要求の引数を示す図である。リード要求には、図２０に示すように、ino，offset，sizeおよびdataが引数として付加される。すなわち、リード要求をread(ino, offset, size, data)と表すことができる。
【０１８７】
なお、引数inoは、リード要求に割り当てられたinode番号である。offsetは、リードデータ（data）を読み出すファイルの位置（ファイル先頭からのバイト数）を表す。sizeは、リードするデータ（data）のサイズ（バイト）であり、dataはリードデータを格納する領域を示す。offsetやsizeは、ファイルにおけるデータアクセス（リード）対象の位置を示す位置情報として用いられる。
【０１８８】
実施形態の一例としてのクラウドストレージシステム１におけるリード処理を、図２２を参照しながら、図２１に示すフローチャート（ステップＣ１〜Ｃ４）に従って説明する。なお、図２２はリード処理を説明するための図である。
【０１８９】
図２２においては、可変長チャンキングされたファイルに、offset700からsize2000バイトのデータ（リードデータ）をリードする例について示す。
【０１９０】
ステップＣ１において、ファイルアクセス処理部２２は、リード要求範囲の先頭に関連するチャンク情報を取得する。
【０１９１】
具体的には、先ず、リード要求に引数として付加されたoffsetをリージョンサイズで除算した値（offset÷リージョンサイズ）を算出し、その商の整数部分をリージョン番号として判断することで、リード要求範囲の先頭部分に対応するチャンクが属するリージョンを特定する。
【０１９２】
図２２に示す例においては、ファイルアクセス処理部２２は、以下の式を算出することで、リード要求範囲の先頭に対応するチャンクが属するリージョン番号を取得する。以下の式においては、商の整数部分がリージョン番号として用いられる。
【０１９３】
700（オフセット）÷1000（リージョンサイズ）≒0（＝リージョン０）
これにより、リード要求範囲の先頭部分に対応するチャンクは、リージョン０に属していることがわかる。
【０１９４】
このように、ファイルアクセス処理部２２は、リード要求に含まれる位置情報（offset＆size）に基づいて、ファイルにおける、リード範囲の先頭となるチャンク（第１の可変長ブロックデータ）が属するリージョン（第１のリージョン，第１の検索単位領域）を特定する。
【０１９５】
次に、ファイルアクセス処理部２２は、チャンクマップテーブル２４３を参照して、先に特定したリージョン番号を有するレコード（チャンク）を取得する。図２２に示す例においては、チャンク０，１，２が、リージョン０に属する。
【０１９６】
その後、ファイルアクセス処理部２２は、取得した各レコードのoffsetおよびsizeと、入力されたリード要求にかかるデータ（入力情報）のoffsetおよびsizeとを比較する。そして、ファイルアクセス処理部２２は、offsetおよびsizeが、入力情報のoffsetおよびsizeに相当するレコードを選択する。
【０１９７】
図２２に示す例においては、リードデータのオフセットが700であるので、オフセット500〜800のチャンク１にリードデータの範囲が重なる。また、チャンク０のオフセットは0〜500であるので、リードデータの範囲とは重ならない。このチャンク０のように、重なるレコード（図２２に示す例ではチャンク１）よりも前のレコードは不要である。
【０１９８】
リード要求にかかるデータは、オフセット700を始点として、2000バイトのデータサイズを有するので、オフセット800を始点とし、サイズ700のチャンク２の全てがリードデータの範囲に重合する。
【０１９９】
従って、ファイルアクセス処理部２２は、リード要求範囲の先頭に関連するチャンクとして、チャンク１を特定する。このように、ファイルアクセス処理部２２は、特定した第１のリージョンに含まれるチャンクに対してオフセット検索を行なうことで、リードデータの先頭に関連するチャンクを検索する。
【０２００】
ステップＣ２において、ファイルアクセス処理部２２は、リード要求範囲の末尾に関連するチャンク情報を取得する。
【０２０１】
ファイルアクセス処理部２２は、ステップＢ１と同様の手法で、リード要求範囲の末尾に関連するチャンクを特定する。
【０２０２】
図２２に示す例においては、ファイルアクセス処理部２２は、以下の式を算出することで、リード要求範囲の領域のデータの末尾に対応するチャンクが属するリージョン番号を取得する。
【０２０３】
なお、ファイルアクセス処理部２２は、“（offset+size）÷リージョンサイズ”を算出することでリード要求範囲の末尾に関連するチャンクのリージョン（第２のリージョン）を求める。ファイルアクセス処理部２２は以下の式を算出する。以下の式においては、商の整数部分がリージョン番号として用いられる。
【０２０４】
2700（オフセット）÷1000（リージョンサイズ）≒2（＝リージョン２）
これにより、リード要求範囲の末尾部分に対応するチャンクは、リージョン２に属していることがわかる。
【０２０５】
このように、ファイルアクセス処理部２２は、リード要求に含まれる位置情報（offset＆size）に基づいて、ファイルにおける、リードデータの末尾となるチャンク（第２の可変長ブロックデータ）が属するリージョン（第２のリージョン，第２の検索単位領域）を特定する。
【０２０６】
そして、ファイルシステム処理部２２は、ファイルに対してデータアクセスを行なうに際して、データアクセス要求に含まれる位置情報（offset＆size）に基づいて、アクセス対象の可変長チャンクが属するリージョンを特定する検索単位領域特定部として機能するのである。
【０２０７】
また、図２２に示す例においては、リード要範囲のoffsetオフセット（offset）が700であり、且つ、データサイズ（size）が2000バイトである。
【０２０８】
従って、オフセット2700〜3000のチャンク６が、このリード要求範囲の末尾と部分的に重なる。ファイルアクセス処理部２２は、リード要求範囲の末尾と重なるチャンク６を選択する。
【０２０９】
このように、ファイルアクセス処理部２２は、特定した第２のリージョンに含まれるチャンクに対してオフセット検索を行なうことで、リードデータの末尾に関連するチャンクを検索する。
【０２１０】
このように、ファイルアクセス処理部２２は、特定したリージョンに属する可変長チャンクを対象に、データアクセス対象の可変長チャンクを検索するブロック検索部として機能するのである。
【０２１１】
ステップＣ３において、ファイルアクセス処理部２２は、リード要求範囲の先頭に重なるチャンクと、その末尾に重なるチャンクとの間のチャンク情報を取得する。
【０２１２】
ファイルアクセス処理部２２は、リード要求範囲の先頭に対応するリージョン（先頭リージョン）と、リード要求範囲の末尾に対応するリージョン（末尾リージョン）とが同一でなく、かつ、隣接していない場合、先頭リージョンと末尾リージョンとの間のすべてのリージョン番号を求める。
【０２１３】
図２２に示す例においては、先頭リージョンがリージョン０であり、末尾リージョンがリージョン２である。従って、これらの先頭リージョンと末尾リージョンとの間にあるリージョン（中間リージョン）はリージョン１である。
【０２１４】
ファイルアクセス処理部２２は、チャンクマップテーブル２４３を参照して、中間リージョンのリージョン番号（region）を持つレコードを取得する。
【０２１５】
図２２に示す例においては、ファイルアクセス処理部２２は、中間リージョンのリージョン番号（region）を持つレコードとして、チャンク３，４のレコードを取得する。
【０２１６】
ステップＣ４において、ファイルアクセス処理部２２は、リードデータの構築を行なう。
【０２１７】
具体的には、ファイルアクセス処理部２２は、チャンクテーブル２４４を参照して、上記Ｃ１〜Ｃ３の各処理で取得した全てのレコードのhashと同じ値を持つレコードを取得し、チャンクデータを読み取る。そして、ファイルアクセス処理部２２は、先頭と末尾との各チャンクについてリード要求範囲をはみ出る部分を除いて、キャッシュ用バッファメモリ１３のリードデータ格納領域にコピーする。
【０２１８】
従って、ファイルアクセス処理部２２は、ファイルにおける、第１の可変長チャンクから第２の可変長チャンクまでの範囲内から、リードデータを抽出するリード処理部として機能するのである。
【０２１９】
（Ｃ）効果
このように、実施形態の一例としてのクラウドストレージシステム１によれば、ファイルアクセス処理部２２が可変長チャンキングを行ない、重複排除処理部２１が、可変長チャンキングが行なわれた各チャンクについて、重複排除処理を行なう。
【０２２０】
これにより、ライト要求等により、例えば、一部のチャンクに１バイト分のデータの増加等が行なわれた場合であっても、他のチャンクへの影響が及ぶことがなく、重複排除を効率よく行なうことができる。
【０２２１】
ファイルアクセス処理部２２が、可変長チャンキングされたファイルを、ファイルアクセス処理部２２が、固定長の複数のリージョン（領域）に区分けする。
【０２２２】
そして、データアクセス要求（ライト要求もしくはリード要求）が行なわれた場合に、ファイルアクセス処理部２２が、先ず、アクセス対象のリージョンの特定を行ない、この特定されたリージョンに属するチャンクに対して検索を行なうことで、データアクセス先のチャンクを短時間で特定することができる。従ってデータアクセス性能を向上させることができる。
【０２２３】
データアクセス先のチャンクを特定するために、可変長チャンキングが行なわれたファイルの先頭から順番に、チャンクサイズの累加等の演算処理を繰り返し行なう必要がなく、効率的にデータアクセス先のチャンクを特定することができる。
【０２２４】
（Ｄ）その他
そして、開示の技術は上述した実施形態に限定されるものではなく、本実施形態の趣旨を逸脱しない範囲で種々変形して実施することができる。本実施形態の各構成および各処理は、必要に応じて取捨選択することができ、あるいは適宜組み合わせてもよい。
【０２２５】
上述した実施形態においては、クラウドバックアップゲートウェイ１０が、ＣＰＵ１１，メモリ１２および記憶装置１４を備えた情報処理装置として構成され、ＣＰＵ１１がデータ処理プログラムを実行することで、その機能を実現しているが、これに限定されるものではない。例えば、バックアップサーバ５３や業務サーバ５２に備えられたプロセッサがデータ処理プログラムを実行することで、その機能を実現してもよく、種々変形して実施することができる。また、上述した重複排除に加えて、ファイルに対してデータ圧縮を行なってもよい。
【０２２６】
また、上述した開示により本実施形態を当業者によって実施・製造することが可能である。
【０２２７】
（Ｅ）付記
以上の実施形態に関し、さらに以下の付記を開示する。
【０２２８】
（付記１）
複数の可変長ブロックデータからなるデータ列を、所定長の複数の検索単位領域に区分けし、各可変長ブロックデータを前記検索単位領域毎に管理するブロックデータ管理部と、
前記データ列に対してデータアクセスを行なうに際して、データアクセス要求に含まれる位置情報に基づいて、アクセス対象の可変長ブロックデータが属する検索単位領域を特定する検索単位領域特定部と、
特定した前記検索単位領域に属する前記可変長ブロックデータを対象に、データアクセス対象の可変長ブロックデータを検索するブロック検索部と
を備えることを特徴とする、データ処理装置。
【０２２９】
（付記２）
前記データアクセスとして、前記データ列にライトデータをライトする場合に、
前記検索単位領域特定部が、ライト要求に含まれる前記位置情報に基づいて、前記データ列における、前記ライトデータの先頭が書き込まれる第１の可変長ブロックデータが属する第１の検索単位領域と、前記ライトデータの末尾が書き込まれる第２の可変長ブロックデータが属する第２の検索単位領域とを特定し、
前記ブロック検索部が、前記第１の検索単位領域から前記第１の可変長ブロックデータを抽出するとともに、前記第２の検索単位領域から前記第２の可変長ブロックデータを抽出し、
前記ライトデータの先頭に前記第１の可変長ブロックを、前記ライトデータの末尾に前記第２の可変長ブロックを、それぞれ結合することで更新データを作成し、当該更新データで前記データ列を部分的に置換するライト処理部
を備えることを特徴とする、付記１記載のデータ処理装置。
【０２３０】
（付記３）
前記更新データを複数の可変長ブロックデータに分割し、各可変長ブロックデータについて重複排除処理を行なう重複排除処理部
を備えることを特徴とする、付記２記載のデータ処理装置。
【０２３１】
（付記４）
前記データアクセスとして、前記データ列からリードデータをリードする場合に、
前記検索単位領域特定部が、リード要求に含まれる前記位置情報に基づいて、前記データ列における、前記リードデータの先頭となる第１の可変長ブロックデータが属する第１の検索単位領域と、前記リードデータの末尾となる第２の可変長ブロックデータが属する第２の検索単位領域とを特定し、
前記ブロック検索部が、前記第１の検索単位領域から前記第１の可変長ブロックデータを抽出するとともに、前記第２の検索単位領域から前記第２の可変長ブロックデータを抽出し、
前記データ列における、前記第１の可変長ブロックから前記第２の可変長ブロックまでの範囲内から、前記リードデータを抽出するリード処理部
を備えることを特徴とする、付記１〜３のいずれか１項に記載のデータ処理装置。
【０２３２】
（付記５）
複数の可変長ブロックデータからなるデータ列を、所定長の複数の検索単位領域に区分けし、各可変長ブロックデータを前記検索単位領域毎に管理し、
前記データ列に対してデータアクセスを行なうに際して、データアクセス要求に含まれる位置情報に基づいて、アクセス対象の可変長ブロックデータが属する検索単位領域を特定し、
特定した前記検索単位領域に属する前記可変長ブロックデータを対象に、データアクセス対象の可変長ブロックデータを検索する
処理をコンピュータに実行させることを特徴とする、データ処理プログラム。
【０２３３】
（付記６）
前記データアクセスとして、前記データ列にライトデータをライトする場合に、
ライト要求に含まれる前記位置情報に基づいて、前記データ列における、前記ライトデータの先頭が書き込まれる第１の可変長ブロックデータが属する検索単位領域を特定して、当該検索単位領域から前記第１の可変長ブロックデータを抽出し、
前記位置情報に基づいて、前記データ列における、前記ライトデータの末尾が書き込まれる第２の可変長ブロックデータが属する検索単位領域を特定して、当該検索単位領域から前記第２の可変長ブロックデータを抽出し、
前記ライトデータの先頭に前記第１の可変長ブロックを、前記ライトデータの末尾に前記第２の可変長ブロックを、それぞれ結合することで、更新データを作成し、当該更新データで前記データ列を部分的に置換する
処理を、前記コンピュータに実行させることを特徴とする、付記５記載のデータ処理プログラム。
【０２３４】
（付記７）
前記更新データを複数の可変長ブロックデータに分割し、各可変長ブロックデータについて重複排除処理を行なう
処理を、前記コンピュータに実行させることを特徴とする、付記６記載のデータ処理プログラム。
【０２３５】
（付記８）
前記データアクセスとして、前記データ列からリードデータをリードする場合に、
リード要求に含まれる前記位置情報に基づいて、前記データ列における、前記リードデータの先頭となる第１の可変長ブロックデータが属する検索単位領域を特定して、当該検索単位領域から前記第１の可変長ブロックデータを抽出し、
前記位置情報に基づいて、前記データ列における、前記リードデータの末尾となる第２の可変長ブロックデータが属する検索単位領域を特定して、当該検索単位領域から前記第２の可変長ブロックデータを抽出し、
前記データ列における、前記第１の可変長ブロックから前記第２の可変長ブロックまでの範囲内から、前記リードデータを抽出する
処理を、前記コンピュータに実行させることを特徴とする、付記５〜７のいずれか１項に記載のデータ処理プログラム。
【０２３６】
（付記９）
複数の可変長ブロックデータからなるデータ列を、所定長の複数の検索単位領域に区分けし、各可変長ブロックデータを前記検索単位領域毎に管理し、
前記データ列に対してデータアクセスを行なうに際して、データアクセス要求に含まれる位置情報に基づいて、アクセス対象の可変長ブロックデータが属する検索単位領域を特定し、
特定した前記検索単位領域に属する前記可変長ブロックデータを対象に、データアクセス対象の可変長ブロックデータを検索する
ことを特徴とする、データ処理方法。
【０２３７】
（付記１０）
前記データアクセスとして、前記データ列にライトデータをライトする場合に、
ライト要求に含まれる前記位置情報に基づいて、前記データ列における、前記ライトデータの先頭が書き込まれる第１の可変長ブロックデータが属する検索単位領域を特定して、当該検索単位領域から前記第１の可変長ブロックデータを抽出し、
前記位置情報に基づいて、前記データ列における、前記ライトデータの末尾が書き込まれる第１の可変長ブロックデータが属する検索単位領域を特定して、当該検索単位領域から前記第２の可変長ブロックデータを抽出し、
前記ライトデータの先頭に前記第２の可変長ブロックを、前記ライトデータの末尾に前記第２の可変長ブロックを、それぞれ結合することで、更新データを作成し、当該更新データで前記データ列を部分的に置換する
ことを特徴とする、付記９記載のデータ処理方法。
【０２３８】
（付記１１）
前記更新データを複数の可変長ブロックデータに分割し、各可変長ブロックデータについて重複排除処理を行なう
ことを特徴とする、付記１０記載のデータ処理方法。
【０２３９】
（付記１２）
前記データアクセスとして、前記データ列からリードデータをリードする場合に、
リード要求に含まれる前記位置情報に基づいて、前記データ列における、前記リードデータの先頭となる第１の可変長ブロックデータが属する検索単位領域を特定して、当該検索単位領域から前記第１の可変長ブロックデータを抽出し、
前記位置情報に基づいて、前記データ列における、前記リードデータの末尾となる第２の可変長ブロックデータが属する検索単位領域を特定して、当該検索単位領域から前記第２の可変長ブロックデータを抽出し、
前記データ列における、前記第１の可変長ブロックから前記第２の可変長ブロックまでの範囲内から、前記リードデータを抽出する
ことを特徴とする、付記９〜１１のいずれか１項に記載のデータ処理方法。
【符号の説明】
【０２４０】
１    クラウドストレージシステム
１１    ＣＰＵ
１２    メモリ
１３    キャッシュ用バッファメモリ
１３ａ    キャッシュメモリ領域
１３ｂ    最大チャンクサイズ領域    
１４    記憶装置
２１    重複排除処理部
２２    ファイルアクセス処理部
５０    クラウド
５１    クラウドストレージ
５２    業務サーバ
５３    バックアップサーバ
２４０    管理データベース
２４１    ディレクトリテーブル
２４２    エントリテーブル
２４３    チャンクマップテーブル
２４４    チャンクテーブル
【図１】
2018097450.tif 000003
【図２】
2018097450.tif 000004
【図３】
2018097450.tif 000005
【図４】
2018097450.tif 000006
【図５】
2018097450.tif 000007
【図６】
2018097450.tif 000008
【図７】
2018097450.tif 000009
【図８】
2018097450.tif 000010
【図９】
2018097450.tif 000011
【図１０】
2018097450.tif 000012
【図１１】
2018097450.tif 000013
【図１２】
2018097450.tif 000014
【図１３】
2018097450.tif 000015
【図１４】
2018097450.tif 000016
【図１５】
2018097450.tif 000017
【図１６】
2018097450.tif 000018
【図１７】
2018097450.tif 000019
【図１８】
2018097450.tif 000020
【図１９】
2018097450.tif 000021
【図２０】
2018097450.tif 000022
【図２１】
2018097450.tif 000023
【図２２】
2018097450.tif 000024
【図２３】
2018097450.tif 000025
【図２４】
2018097450.tif 000026
【図２５】
2018097450.tif 000027
【図２６】
2018097450.tif 000028