JP2018097450A - データ処理装置，データ処理プログラムおよびデータ処理方法 - Google Patents

Abstract

【課題】、データ列におけるアクセス対象の可変長ブロックデータを容易に特定できるようにする。
【解決手段】複数の可変長ブロックデータからなるデータ列を、所定長の複数の検索単位領域に区分けし、各可変長ブロックデータを検索単位領域毎に管理し、データ列に対してデータアクセスを行なうに際して、データアクセス要求に含まれる位置情報に基づいて、アクセス対象の可変長ブロックデータが属する検索単位領域を特定し、特定した検索単位領域に属する可変長ブロックデータを対象に、データアクセス対象の可変長ブロックデータを検索する。
【選択図】図３

Description

本発明は、データ処理装置，データ処理プログラムおよびデータ処理方法に関する。

近年、ソフトウェアやデータなどを、インターネットなどのネットワークを通じてサービスの形で必要に応じて利用するクラウドコンピューティングシステムが知られている。

図２３はクラウドコンピューティングシステムの構成例を模式的に示す図である。

この図２３に示すクラウドコンピューティングシステム５００は、サービスとしてストレージを提供するクラウドストレージサービスであり、業務サーバ５０１，バックアップサーバ５０２，クラウドバックアップゲートウェイ５０３およびクラウド５０４を備える。

クラウド５０４にはオブジェクトストレージ５０５が備えられている。オブジェクトストレージ５０５はクラウドストレージ５０５とも呼ばれる。バックアップサーバ５０２においてはバックアップソフトウェアが実行され、業務サーバ５０１によって生成されたデータは、このバックアップソフトウェアによってバックアップデータとしてコピーされ、オブジェクトストレージ５０５に格納される。

クラウドバックアップゲートウェイ５０３は、バックアップソフトウェアがバックアップとしてコピーしたファイルを、オブジェクトストレージ５０５に転送する。このクラウドバックアップゲートウェイ５０３は、バックアップソフトウェアとクラウドストレージ５０５との間のデータ転送を中継するソフトウェアによって実現される。

クラウドストレージサービスでは、データ量に応じた課金が行なわれることが多い。そのため、クラウドバックアップゲートウェイ５０３には、転送するデータ量を削減することが求められる。データ量を削減するための技術として、例えば重複排除が知られている。

重複排除においては、データ列を所定のサイズの複数のブロック（以下、チャンクという）に分割し、保存済のデータも含めてチャンクどうしを比較し、同一のチャンクは重複して保存しないようにすることで、保存するデータ量を削減する。以下、データ列を複数のチャンクに分割することをチャンキングという。

チャンキングには、固定長チャンキングと可変長チャンキングとが含まれる。

図２４は固定長チャンキングを説明するための図、図２５は可変長チャンキングを説明するための図である。

固定長チャンキングは、図２４に示すように、予め決められた一定のサイズでデータを分割する方式である。これに対して、可変長チャンキングにおいては、データの内容に沿ってデータを分割する位置が計算される。従って、可変長チャンキングにおいては、図２５に示すように、一つのデータ列から得られるチャンクのサイズは一定ではない。

このような可変長チャンキングは、ファイルのバックアップという目的において、固定長チャンキングよりも好適であると考えられる。

図２６は可変長チャンキングを用いたファイルのバックアップを固定長チャンキングと比べて説明するための図である。

一般に、バックアップは定期実行（毎日、毎週、毎月など）で運用される。図２６に示す例においては、符号（Ａ）に示すように、前回バックアップを行なったファイルの先頭に１バイトのデータが追加されたデータのバックアップを新たに行なう場合について示す。

固定長チャンキングにおいては、チャンクサイズが一定のため、ファイルの先頭に１バイトのデータが追加されると、符号（Ｂ）に示すように、後続する全てのチャンクのデータが１バイトずつずれることになる。これにより、全てのチャンクが前回バックアップ時とは異なるデータ内容となり、重複チャンクが無くなる。すなわち、全てのチャンクが保存対象となる。

これに対して、可変長チャンキングでは、データ内容に合わせてチャンク分割がされるため、符号（Ｃ）に示すように、ファイルの先頭に１バイトのデータが追加された場合に、チャンクの境界位置が１バイトずれていくだけであり、先頭のチャンク以外の各チャンクのデータ内容は変化せず、重複チャンクとして扱うことができる。すなわち、先頭のチャンクだけが保存対象となり、他のチャンクは保存対象外となる。

このような特徴から、クラウドバックアップゲートウェイにおいて転送データのデータ量削減を行なうには、可変長チャンキングによる重複排除が適していると言える。

国際公開第２０１４／１５５６６８号 特開２０１２−１４１７３８号公報 特開２０１１−６５２６８号公報

一般に、ファイルシステムにおけるデータの入出力インタフェースにおいては、ファイルに対してリードやライトのデータアクセスを行なうために、オフセット，データサイズおよびデータ格納領域の３つの情報が用いられる。

オフセットは、ファイル中におけるデータのリードもしくはライトの対象位置を示し、ファイルの先頭から何バイト目であるかを表す。データサイズは、リードもしくはライトするデータのサイズを示す。データ格納領域は、リードしたデータを格納するメモリ領域や、ライトするデータが格納されているメモリ領域を示す。

ここで、固定長チャンキングされたファイルにおいては、各チャンクのチャンクサイズが等しいので、ファイルを構成するチャンク群を単純な配列で表現することができ、入出力アクセス要求に含まれるオフセットおよびデータサイズから、アクセス対象データの先頭のチャンクと末尾のチャンクとを容易に求めることができる。

具体的には、データ先頭のチャンクインデックスは、オフセットをチャンクサイズで除算（オフセット÷チャンクサイズ）した商の整数部分により取得できる。また、データ末尾のチャンクインデックスは、（オフセット＋データサイズ）をチャンクサイズで除算した商の整数部分により取得できる。

しかしながら、従来のファイルシステムにおいて、可変長チャンキングされたファイルにおいては、アクセス対象となるデータの先頭のチャンクと末尾のチャンクとを容易に求めることができない。

すなわち、アクセス対象データのオフセットおよびデータサイズ情報と、ファイルを構成する各チャンクのオフセットおよびチャンクサイズとの比較検索が必要となる。具体的には、ファイルにおける先頭のチャンクから順番にチャンクサイズの累加等の計算を行なう必要がある。

そのため、ファイルサイズが大きくなるに従ってチャンクを特定するために要する処理時間が大きくなるため、ファイルサイズが大きくなるほどリードやライトが遅くなるという課題がある。

１つの側面では、本発明は、データ列におけるアクセス対象の可変長ブロックデータを容易に特定できるようにすることを目的とする。

このため、このデータ処理装置は、複数の可変長ブロックデータからなるデータ列を、所定長の複数の検索単位領域に区分けし、各可変長ブロックデータを前記検索単位領域毎に管理するブロックデータ管理部と、前記データ列に対してデータアクセスを行なうに際して、データアクセス要求に含まれる位置情報に基づいて、アクセス対象の可変長ブロックデータが属する検索単位領域を特定する検索単位領域特定部と、特定した前記検索単位領域に属する前記可変長ブロックデータを対象に、データアクセス対象の可変長ブロックデータを検索するブロック検索部とを備える。

一実施形態によれば、データ列におけるアクセス対象の可変長ブロックデータを容易に特定できる。

実施形態の一例としてのクラウドストレージシステムの構成を例示する図である。 実施形態の一例としてのクラウドバックアップゲートウェイのキャッシュ用バッファメモリを説明するための図である。 実施形態の一例としてのクラウドストレージシステムにおけるファイルの管理方法を説明するための図である。 図１に示すディレクトリテーブルの構成を示す図である。 ディレクトリテーブルによって示されるファイルやディレクトリの構成を例示する図である。 図１に示すエントリテーブルの構成を示す図である。 図１に示すチャンクマップテーブルの構成を示す図である。 図１に示すチャンクテーブルの構成を示す図である。 実施形態の一例としてのクラウドストレージシステムにおけるライトデータを説明するための図である。 実施形態の一例としてのクラウドストレージシステムにおけるライトデータの結合を説明するための図である。 ライト要求に付加される引数を説明するための図である。 実施形態の一例としてのクラウドバックアップゲートウェイにおけるファイルシステムとしてのライト処理の概要を説明するためのフローチャートである。 キャッシュ用バッファメモリにおけるライトデータの格納状態を示す図である。 キャッシュ用バッファメモリにおけるライトデータの格納状態を示す図である。 キャッシュ用バッファメモリにおけるライトデータの格納状態を示す図である。 実施形態の一例としてのクラウドストレージシステムにおけるライト処理を説明するための図である。 実施形態の一例としてのクラウドストレージシステムにおけるライト処理の詳細を説明するためのフローチャートである。 実施形態の一例としてのクラウドストレージシステムにおけるライト処理を説明するための図である。 実施形態の一例としてのクラウドストレージシステムにおけるライトデータへの既存チャンクの結合方法を説明するための図である。 リード要求の引数を示す図である。 実施形態の一例としてのクラウドストレージシステムにおけるリード処理を説明するためのフローチャートである。 実施形態の一例としてのクラウドストレージシステムにおけるリード処理を説明するための図である。 クラウドコンピューティングシステムの構成例を模式的に示す図である。 固定長チャンキングを説明するための図である。 可変長チャンキングを説明するための図である。 可変長チャンキングを用いたファイルのバックアップを固定長チャンキングと比べて説明するための図である。

以下、図面を参照して本データ処理装置，データ処理プログラムおよびデータ処理方法に係る実施の形態を説明する。ただし、以下に示す実施形態はあくまでも例示に過ぎず、実施形態で明示しない種々の変形例や技術の適用を排除する意図はない。すなわち、本実施形態を、その趣旨を逸脱しない範囲で種々変形して実施することができる。また、各図は、図中に示す構成要素のみを備えるという趣旨ではなく、他の機能等を含むことができる。

（Ａ）構成
図１は実施形態の一例としてのクラウドストレージシステム１の構成を例示する図である。

クラウドストレージシステム１は、クラウド５０に備えられたストレージ（クラウドストレージ５１）の記憶領域をサービスとして提供するクラウドコンピューティングシステムである。

図１に例示するクラウドストレージシステム１は、クラウド５０，業務サーバ５２，バックアップサーバ５３およびクラウドバックアップゲートウェイ１０を備える。

クラウド５０は、複数のサーバコンピュータ（図示省略）を備えるコンピュータネットワークシステムである。クラウド５０は、クラウドストレージ５１を備え、このクラウドストレージ５１の記憶領域をサービスとして提供する。

クラウドストレージ５１はデータのリードやライトが可能な記憶領域であり、１以上の記憶装置により実現される。クラウドストレージ５１は、複数の記憶装置を用いたＲＡＩＤ（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と同じ値を持つレコードを取得し、チャンクデータを読み取る。そして、ファイルアクセス処理部２２は、先頭と末尾との各チャンクについてリード要求範囲をはみ出る部分を除いて、キャッシュ用バッファメモリ１３のリードデータ格納領域にコピーする。

従って、ファイルアクセス処理部２２は、ファイルにおける、第１の可変長チャンクから第２の可変長チャンクまでの範囲内から、リードデータを抽出するリード処理部として機能するのである。

（Ｃ）効果
このように、実施形態の一例としてのクラウドストレージシステム１によれば、ファイルアクセス処理部２２が可変長チャンキングを行ない、重複排除処理部２１が、可変長チャンキングが行なわれた各チャンクについて、重複排除処理を行なう。

これにより、ライト要求等により、例えば、一部のチャンクに１バイト分のデータの増加等が行なわれた場合であっても、他のチャンクへの影響が及ぶことがなく、重複排除を効率よく行なうことができる。

ファイルアクセス処理部２２が、可変長チャンキングされたファイルを、ファイルアクセス処理部２２が、固定長の複数のリージョン（領域）に区分けする。

そして、データアクセス要求（ライト要求もしくはリード要求）が行なわれた場合に、ファイルアクセス処理部２２が、先ず、アクセス対象のリージョンの特定を行ない、この特定されたリージョンに属するチャンクに対して検索を行なうことで、データアクセス先のチャンクを短時間で特定することができる。従ってデータアクセス性能を向上させることができる。

データアクセス先のチャンクを特定するために、可変長チャンキングが行なわれたファイルの先頭から順番に、チャンクサイズの累加等の演算処理を繰り返し行なう必要がなく、効率的にデータアクセス先のチャンクを特定することができる。

（Ｄ）その他
そして、開示の技術は上述した実施形態に限定されるものではなく、本実施形態の趣旨を逸脱しない範囲で種々変形して実施することができる。本実施形態の各構成および各処理は、必要に応じて取捨選択することができ、あるいは適宜組み合わせてもよい。

上述した実施形態においては、クラウドバックアップゲートウェイ１０が、ＣＰＵ１１，メモリ１２および記憶装置１４を備えた情報処理装置として構成され、ＣＰＵ１１がデータ処理プログラムを実行することで、その機能を実現しているが、これに限定されるものではない。例えば、バックアップサーバ５３や業務サーバ５２に備えられたプロセッサがデータ処理プログラムを実行することで、その機能を実現してもよく、種々変形して実施することができる。また、上述した重複排除に加えて、ファイルに対してデータ圧縮を行なってもよい。

また、上述した開示により本実施形態を当業者によって実施・製造することが可能である。

（Ｅ）付記
以上の実施形態に関し、さらに以下の付記を開示する。

（付記１）
複数の可変長ブロックデータからなるデータ列を、所定長の複数の検索単位領域に区分けし、各可変長ブロックデータを前記検索単位領域毎に管理するブロックデータ管理部と、
前記データ列に対してデータアクセスを行なうに際して、データアクセス要求に含まれる位置情報に基づいて、アクセス対象の可変長ブロックデータが属する検索単位領域を特定する検索単位領域特定部と、
特定した前記検索単位領域に属する前記可変長ブロックデータを対象に、データアクセス対象の可変長ブロックデータを検索するブロック検索部と
を備えることを特徴とする、データ処理装置。

（付記２）
前記データアクセスとして、前記データ列にライトデータをライトする場合に、
前記検索単位領域特定部が、ライト要求に含まれる前記位置情報に基づいて、前記データ列における、前記ライトデータの先頭が書き込まれる第１の可変長ブロックデータが属する第１の検索単位領域と、前記ライトデータの末尾が書き込まれる第２の可変長ブロックデータが属する第２の検索単位領域とを特定し、
前記ブロック検索部が、前記第１の検索単位領域から前記第１の可変長ブロックデータを抽出するとともに、前記第２の検索単位領域から前記第２の可変長ブロックデータを抽出し、
前記ライトデータの先頭に前記第１の可変長ブロックを、前記ライトデータの末尾に前記第２の可変長ブロックを、それぞれ結合することで更新データを作成し、当該更新データで前記データ列を部分的に置換するライト処理部
を備えることを特徴とする、付記１記載のデータ処理装置。

（付記３）
前記更新データを複数の可変長ブロックデータに分割し、各可変長ブロックデータについて重複排除処理を行なう重複排除処理部
を備えることを特徴とする、付記２記載のデータ処理装置。

（付記４）
前記データアクセスとして、前記データ列からリードデータをリードする場合に、
前記検索単位領域特定部が、リード要求に含まれる前記位置情報に基づいて、前記データ列における、前記リードデータの先頭となる第１の可変長ブロックデータが属する第１の検索単位領域と、前記リードデータの末尾となる第２の可変長ブロックデータが属する第２の検索単位領域とを特定し、
前記ブロック検索部が、前記第１の検索単位領域から前記第１の可変長ブロックデータを抽出するとともに、前記第２の検索単位領域から前記第２の可変長ブロックデータを抽出し、
前記データ列における、前記第１の可変長ブロックから前記第２の可変長ブロックまでの範囲内から、前記リードデータを抽出するリード処理部
を備えることを特徴とする、付記１〜３のいずれか１項に記載のデータ処理装置。

（付記５）
複数の可変長ブロックデータからなるデータ列を、所定長の複数の検索単位領域に区分けし、各可変長ブロックデータを前記検索単位領域毎に管理し、
前記データ列に対してデータアクセスを行なうに際して、データアクセス要求に含まれる位置情報に基づいて、アクセス対象の可変長ブロックデータが属する検索単位領域を特定し、
特定した前記検索単位領域に属する前記可変長ブロックデータを対象に、データアクセス対象の可変長ブロックデータを検索する
処理をコンピュータに実行させることを特徴とする、データ処理プログラム。

（付記６）
前記データアクセスとして、前記データ列にライトデータをライトする場合に、
ライト要求に含まれる前記位置情報に基づいて、前記データ列における、前記ライトデータの先頭が書き込まれる第１の可変長ブロックデータが属する検索単位領域を特定して、当該検索単位領域から前記第１の可変長ブロックデータを抽出し、
前記位置情報に基づいて、前記データ列における、前記ライトデータの末尾が書き込まれる第２の可変長ブロックデータが属する検索単位領域を特定して、当該検索単位領域から前記第２の可変長ブロックデータを抽出し、
前記ライトデータの先頭に前記第１の可変長ブロックを、前記ライトデータの末尾に前記第２の可変長ブロックを、それぞれ結合することで、更新データを作成し、当該更新データで前記データ列を部分的に置換する
処理を、前記コンピュータに実行させることを特徴とする、付記５記載のデータ処理プログラム。

（付記７）
前記更新データを複数の可変長ブロックデータに分割し、各可変長ブロックデータについて重複排除処理を行なう
処理を、前記コンピュータに実行させることを特徴とする、付記６記載のデータ処理プログラム。

（付記８）
前記データアクセスとして、前記データ列からリードデータをリードする場合に、
リード要求に含まれる前記位置情報に基づいて、前記データ列における、前記リードデータの先頭となる第１の可変長ブロックデータが属する検索単位領域を特定して、当該検索単位領域から前記第１の可変長ブロックデータを抽出し、
前記位置情報に基づいて、前記データ列における、前記リードデータの末尾となる第２の可変長ブロックデータが属する検索単位領域を特定して、当該検索単位領域から前記第２の可変長ブロックデータを抽出し、
前記データ列における、前記第１の可変長ブロックから前記第２の可変長ブロックまでの範囲内から、前記リードデータを抽出する
処理を、前記コンピュータに実行させることを特徴とする、付記５〜７のいずれか１項に記載のデータ処理プログラム。

（付記９）
複数の可変長ブロックデータからなるデータ列を、所定長の複数の検索単位領域に区分けし、各可変長ブロックデータを前記検索単位領域毎に管理し、
前記データ列に対してデータアクセスを行なうに際して、データアクセス要求に含まれる位置情報に基づいて、アクセス対象の可変長ブロックデータが属する検索単位領域を特定し、
特定した前記検索単位領域に属する前記可変長ブロックデータを対象に、データアクセス対象の可変長ブロックデータを検索する
ことを特徴とする、データ処理方法。

（付記１０）
前記データアクセスとして、前記データ列にライトデータをライトする場合に、
ライト要求に含まれる前記位置情報に基づいて、前記データ列における、前記ライトデータの先頭が書き込まれる第１の可変長ブロックデータが属する検索単位領域を特定して、当該検索単位領域から前記第１の可変長ブロックデータを抽出し、
前記位置情報に基づいて、前記データ列における、前記ライトデータの末尾が書き込まれる第１の可変長ブロックデータが属する検索単位領域を特定して、当該検索単位領域から前記第２の可変長ブロックデータを抽出し、
前記ライトデータの先頭に前記第２の可変長ブロックを、前記ライトデータの末尾に前記第２の可変長ブロックを、それぞれ結合することで、更新データを作成し、当該更新データで前記データ列を部分的に置換する
ことを特徴とする、付記９記載のデータ処理方法。

（付記１１）
前記更新データを複数の可変長ブロックデータに分割し、各可変長ブロックデータについて重複排除処理を行なう
ことを特徴とする、付記１０記載のデータ処理方法。

（付記１２）
前記データアクセスとして、前記データ列からリードデータをリードする場合に、
リード要求に含まれる前記位置情報に基づいて、前記データ列における、前記リードデータの先頭となる第１の可変長ブロックデータが属する検索単位領域を特定して、当該検索単位領域から前記第１の可変長ブロックデータを抽出し、
前記位置情報に基づいて、前記データ列における、前記リードデータの末尾となる第２の可変長ブロックデータが属する検索単位領域を特定して、当該検索単位領域から前記第２の可変長ブロックデータを抽出し、
前記データ列における、前記第１の可変長ブロックから前記第２の可変長ブロックまでの範囲内から、前記リードデータを抽出する
ことを特徴とする、付記９〜１１のいずれか１項に記載のデータ処理方法。

１ クラウドストレージシステム
１１ ＣＰＵ
１２ メモリ
１３ キャッシュ用バッファメモリ
１３ａ キャッシュメモリ領域
１３ｂ 最大チャンクサイズ領域
１４ 記憶装置
２１ 重複排除処理部
２２ ファイルアクセス処理部
５０ クラウド
５１ クラウドストレージ
５２ 業務サーバ
５３ バックアップサーバ
２４０ 管理データベース
２４１ ディレクトリテーブル
２４２ エントリテーブル
２４３ チャンクマップテーブル
２４４ チャンクテーブル

Claims (6)

1. 複数の可変長ブロックデータからなるデータ列を、所定長の複数の検索単位領域に区分けし、各可変長ブロックデータを前記検索単位領域毎に管理するブロックデータ管理部と、
   前記データ列に対してデータアクセスを行なうに際して、データアクセス要求に含まれる位置情報に基づいて、アクセス対象の可変長ブロックデータが属する検索単位領域を特定する検索単位領域特定部と、
   特定した前記検索単位領域に属する前記可変長ブロックデータを対象に、データアクセス対象の可変長ブロックデータを検索するブロック検索部と
   を備えることを特徴とする、データ処理装置。
2. 前記データアクセスとして、前記データ列にライトデータをライトする場合に、
   前記検索単位領域特定部が、ライト要求に含まれる前記位置情報に基づいて、前記データ列における、前記ライトデータの先頭が書き込まれる第１の可変長ブロックデータが属する第１の検索単位領域と、前記ライトデータの末尾が書き込まれる第２の可変長ブロックデータが属する第２の検索単位領域とを特定し、
   前記ブロック検索部が、前記第１の検索単位領域から前記第１の可変長ブロックデータを抽出するとともに、前記第２の検索単位領域から前記第２の可変長ブロックデータを抽出し、
   前記ライトデータの先頭に前記第１の可変長ブロックを、前記ライトデータの末尾に前記第２の可変長ブロックを、それぞれ結合することで更新データを作成し、当該更新データで前記データ列を部分的に置換するライト処理部
   を備えることを特徴とする、請求項１記載のデータ処理装置。
3. 前記更新データを複数の可変長ブロックデータに分割し、各可変長ブロックデータについて重複排除処理を行なう重複排除処理部
   を備えることを特徴とする、請求項２記載のデータ処理装置。
4. 前記データアクセスとして、前記データ列からリードデータをリードする場合に、
   前記検索単位領域特定部が、リード要求に含まれる前記位置情報に基づいて、前記データ列における、前記リードデータの先頭となる第１の可変長ブロックデータが属する第１の検索単位領域と、前記リードデータの末尾となる第２の可変長ブロックデータが属する第２の検索単位領域とを特定し、
   前記ブロック検索部が、前記第１の検索単位領域から前記第１の可変長ブロックデータを抽出するとともに、前記第２の検索単位領域から前記第２の可変長ブロックデータを抽出し、
   前記データ列における、前記第１の可変長ブロックから前記第２の可変長ブロックまでの範囲内から、前記リードデータを抽出するリード処理部
   を備えることを特徴とする、請求項１〜３のいずれか１項に記載のデータ処理装置。
5. 処理装置とメモリとを備えたコンピュータにおいて、
   複数の可変長ブロックデータからなるデータ列を、所定長の複数の検索単位領域に区分けし、各可変長ブロックデータを前記検索単位領域毎に管理し、
   前記データ列に対してデータアクセスを行なうに際して、データアクセス要求に含まれる位置情報に基づいて、アクセス対象の可変長ブロックデータが属する検索単位領域を特定し、
   特定した前記検索単位領域に属する前記可変長ブロックデータを対象に、データアクセス対象の可変長ブロックデータを検索する
   処理を前記処理装置に実行させることを特徴とする、データ処理プログラム。
6. 複数の可変長ブロックデータからなるデータ列を、所定長の複数の検索単位領域に区分けし、各可変長ブロックデータを前記検索単位領域毎に管理し、
   前記データ列に対してデータアクセスを行なうに際して、データアクセス要求に含まれる位置情報に基づいて、アクセス対象の可変長ブロックデータが属する検索単位領域を特定し、
   特定した前記検索単位領域に属する前記可変長ブロックデータを対象に、データアクセス対象の可変長ブロックデータを検索する
   ことを特徴とする、データ処理方法。

Images