JP7323801B2 - 情報処理装置および情報処理プログラム - Google Patents

Description

本発明は、情報処理装置および情報処理プログラムに関する。

オンラインストレージサービス、クラウドストレージサービスなど、ネットワークを介してストレージ領域を提供するストレージサービスが普及している。また、このようなストレージサービスと顧客のコンピュータとの間でゲートウェイとして機能するストレージゲートウェイがある。

例えば、顧客のコンピュータとクラウドストレージなどの外部ストレージとの間で書き込みデータを中継するストレージゲートウェイが提案されている。このストレージゲートウェイは、顧客のコンピュータからファイル単位でデータの書き込み要求を受け付け、書き込みが要求されたデータの重複を排除し、重複が排除されたデータをオブジェクト単位で外部ストレージに転送する。

また、重複排除技術に関しては、例えば、非参照データセグメントを含み得るデータグループにマークアンドスイープ操作を集中させることにより、重複排除データシステムから非参照データセグメントを効率的に除去できるようにしたシステムが提案されている。

特開２０１９－９５９８６号公報 国際公開第２０１１／０８４８５４号

上記のストレージゲートウェイでは、外部ストレージに転送されたオブジェクトについてのデフラグが行われるものがある。このデフラグでは、例えば、外部ストレージに転送されたオブジェクトの中から、どのファイルからも参照されない無効なチャンクを多く含むオブジェクトが検出される。そして、検出されたオブジェクトがストレージゲートウェイに取得され、オブジェクト内の有効なチャンクだけを用いてオブジェクトが再構築されて、外部ストレージに再転送される。

しかし、このようなデフラグでは、オブジェクトのデフラグが実行されるたびにストレージゲートウェイと外部ストレージとの間で往復のオブジェクト転送が実行されるので、通信回数が増大するという問題がある。例えば外部ストレージの一例であるクラウドストレージのサービスでは、通信回数に応じて課金される場合があり、この場合には通信回数が増大するほど課金される金額も増大してしまう。

１つの側面では、本発明は、外部ストレージとの通信回数が減少する可能性を高めることが可能な情報処理装置および情報処理プログラムを提供することを目的とする。

１つの案では、次のような処理部を有する情報処理装置が提供される。この情報処理装置において、処理部は、書き込みが要求された複数の書き込みデータセットの重複を排除することで得られた複数のデータセットを、外部ストレージに格納する格納処理を実行する。この格納処理では、処理部は、複数のデータセットから出現順に選択された２以上のデータセットをオブジェクトにまとめて外部ストレージに格納する。また、処理部は、外部ストレージに格納されたオブジェクトのうち２以上のオブジェクトを生成順にまとめたオブジェクトグループを単位としてデフラグの実行要否を判定し、オブジェクトグループのうち一のオブジェクトグループのデフラグを実行すると判定すると、一のオブジェクトグループに含まれるすべてのオブジェクトをそれぞれ第１のオブジェクトとして外部ストレージから取得し、第１のオブジェクトに含まれるデータセットのうち参照数が１以上である有効データセットを、有効データセットの生成順と参照数とに基づいて組み合わせて１以上の第２のオブジェクトを生成し直し、第２のオブジェクトを第１のオブジェクトの代わりに外部ストレージに格納する第１のデフラグ処理を実行する。

また、１つの案では、上記の情報処理装置と同様の処理をコンピュータに実行させる情報処理プログラムが提供される。

１つの側面では、外部ストレージとの通信回数が減少する可能性を高めることができる。

第１の実施の形態に係るストレージシステムの構成例および処理例を示す図である。 第２の実施の形態に係る情報処理システムの構成例を示す図である。 クラウドストレージゲートウェイのハードウェア構成例を示すブロック図である。 クラウドストレージゲートウェイが備える処理機能の構成例を示すブロック図である。 チャンクマップテーブルの構成例を示す図である。 チャンク管理テーブルおよびハッシュキーテーブルの構成例を示す図である。 オブジェクトの生成例を示す図である。 オブジェクト管理テーブルの構成例を示す図である。 デフラグ判定テーブルの構成例を示す図である。 デフラグ処理手順の比較例を示す第１の図である。 デフラグ処理手順の比較例を示す第２の図である。 デフラグ処理手順の比較例を示す第３の図である。 デフラグ処理手順の比較例を示す第４の図である。 デフラグ処理手順の比較例を示す第５の図である。 第２の実施の形態におけるデフラグ処理手順を示す図である。 ２回目以降のデフラグの実行例を示す第１の図である。 ２回目以降のデフラグの実行例を示す第２の図である。 ファイル書き込み処理の手順を示すフローチャートの例（その１）である。 ファイル書き込み処理の手順を示すフローチャートの例（その２）である。 ファイル削除処理の手順を示すフローチャートの例である。 デフラグ処理の手順を示すフローチャートの例（その１）である。 デフラグ処理の手順を示すフローチャートの例（その２）である。 デフラグ処理の変形例を示すフローチャートである。

以下、本発明の実施の形態について図面を参照して説明する。
〔第１の実施の形態〕
図１は、第１の実施の形態に係るストレージシステムの構成例および処理例を示す図である。図１に示すストレージシステムは、情報処理装置１０と、この情報処理装置１０の外部に接続された外部ストレージ２０とを有する。情報処理装置１０は、外部ストレージ２０に対するデータの読み書きを制御する制御装置である。外部ストレージ２０は、情報処理装置１０に対して図示しないネットワークを介して接続され、情報処理装置１０に対してネットワークを介してデータの記憶領域を提供する。また、外部ストレージ２０は、オブジェクト単位でデータが読み書きされるオブジェクトストレージである。

情報処理装置１０は、処理部１１を有する。処理部１１は、例えば、情報処理装置１０が備える図示しないプロセッサとして実現される。この場合、処理部１１の処理は、プロセッサがプログラムを実行することで実現される。

処理部１１は、例えば図示しないホスト装置から、複数の書き込みデータセットの書き込み要求を受ける。例えば、処理部１１は、複数のファイルの書き込み要求を受け、各ファイルの実データを分割することによって、上記の複数の書き込みデータセットを取得する。

処理部１１は、このような複数の書き込みデータセットの重複を排除することで得られた複数のデータセットを、外部ストレージ２０に格納する。この格納処理では、処理部１１は、複数のデータセットからそれらの出現順に選択された２以上のデータセットを、それぞれオブジェクトにまとめて外部ストレージ２０に格納する。

図１の例では、重複排除によって得られた複数のデータセットからオブジェクトＯＢ１～ＯＢ６が生成されている。例えば、オブジェクトＯＢ１には、２以上のデータセットが出現順に組み込まれ、その次に出現したデータセットはオブジェクトＯＢ２に組み込まれる。処理部１１は、これらのオブジェクトＯＢ１～ＯＢ６を外部ストレージ２０に格納する。

また、処理部１１は、外部ストレージ２０に格納されたオブジェクトのうち２以上のオブジェクトを生成順にまとめたオブジェクトグループを単位として、デフラグの実行要否を判定する。図１の例では、オブジェクトＯＢ１～ＯＢ３がオブジェクトグループＧＰ１として管理され、オブジェクトＯＢ４～ＯＢ６がオブジェクトグループＧＰ２として管理される。各オブジェクトグループＧＰ１，ＧＰ２では、例えば、それぞれに含まれるデータセットのうち、参照数が「０」になった無効なデータセットの数が監視される。そして、例えば所定の閾値との比較により、無効なデータセットの数が多くなったと判定された場合に、そのオブジェクトグループのデフラグを実行すると判定される。なお、参照数とは、元の書き込みデータセットのうちのいくつから参照されているかを示す数値である。

図１では例として、オブジェクトグループＧＰ２についてデフラグを実行すると判定されたとする。この場合、処理部１１は次のようなデフラグ処理を実行する。なお、図１においてオブジェクトＯＢ４～ＯＢ６に示された斜線の領域は、無効なデータセットの領域を示す。

処理部１１はまず、オブジェクトグループＧＰ２に含まれるすべてのオブジェクトＯＢ４～ＯＢ６を外部ストレージ２０から取得する。そして、処理部１１は、オブジェクトＯＢ４～ＯＢ６に含まれるデータセットのうち、参照数が１以上である有効なデータセットを組み合わせて、１以上のオブジェクトを生成し直す（オブジェクト再構築）。この生成処理では、異なるオブジェクトに含まれていた有効なデータセット同士が、同一のオブジェクトに組み込まれてもよい。複数のオブジェクトを含むオブジェクトグループ単位でデフラグ処理を実行することで、このように異なるオブジェクトに含まれていた有効なデータセット同士を組み合わせることが可能になる。

図１の例では、オブジェクトＯＢ４～ＯＢ６に含まれる有効なデータセットを用いて、オブジェクトＯＢ１１，ＯＢ１２が生成されたとする。処理部１１は、生成されたオブジェクトＯＢ１１，ＯＢ１２を、元のオブジェクトＯＢ４～ＯＢ６の代わりに外部ストレージ２０に格納する。これにより、無効なデータセットを外部ストレージ２０から削除し、外部ストレージ２０の使用容量を削減できる。

ここで、処理部１１は、オブジェクトＯＢ１１，ＯＢ１２の生成の際、有効な各データセットについての生成順および参照数に基づいて、データセットの組み合わせ方を決定する。これにより、オブジェクトＯＢ１１，ＯＢ１２のそれぞれについてさらにデフラグが実行される回数が減少する可能性が高くなる。その結果、情報処理装置１０と外部ストレージ２０との間の通信回数が減少する可能性が高められる。

例えば、処理部１１は、オブジェクトＯＢ４～ＯＢ６に含まれる有効なデータセットの中から、生成順が近く、かつ参照数が近いと判定されるデータセットを、同一のオブジェクトに組み込む。生成順が近いデータセットをオブジェクトにまとめて外部ストレージ２０に格納することで、そのオブジェクト内の各データセットの参照数が同じ時期に減算される可能性が高くなる。そして、参照数が近いデータセットをオブジェクトにまとめて外部ストレージ２０に格納することで、そのオブジェクト内の各データセットの参照数が均等に減少していく可能性が高くなる。

その結果、オブジェクト内の分散した位置で無効のデータセットが長時間をかけて徐々に発生する可能性が低くなり、逆にオブジェクト内で多数の無効のデータセットが一度に発生しやすくなる。これにより、このオブジェクトについて再度デフラグが必要と判定されたときに、一度に多数の無効のデータセットを削除できる可能性が高まる。その結果、オブジェクト内で無効のデータセットが長時間をかけて少しずつ増えていく場合と比較して、同じオブジェクトについてのデフラグの実行回数が減少する可能性が高くなる。

したがって、情報処理装置１０と外部ストレージ２０との間の通信回数が減少する可能性が高くなる。また、通信回数の減少により、情報処理装置１０と外部ストレージ２０との間の通信量も削減される。

〔第２の実施の形態〕
次に、図１の外部ストレージ２０としてクラウドストレージが用いられ、図１の情報処理装置１０としてクラウドストレージゲートウェイが用いられた場合の例について説明する。

図２は、第２の実施の形態に係る情報処理システムの構成例を示す図である。図２に示す情報処理システムは、クラウドストレージゲートウェイ１００、ＮＡＳ（Network Attached Storage）クライアント２１０およびストレージシステム２２０を有する。クラウドストレージゲートウェイ１００は、ネットワーク２３１を介してＮＡＳクライアント２１０と接続され、また、ネットワーク２３２を介してストレージシステム２２０と接続されている。ネットワーク２３１は、例えばＬＡＮ（Local Area Network）であり、ネットワーク２３２は、例えばＷＡＮ（Wide Area Network）である。

ストレージシステム２２０は、ネットワーク２３２を介してクラウドストレージサービスを提供する。以下の説明では、ストレージシステム２２０が提供するクラウドストレージサービスによってサービス利用者（ここではクラウドストレージゲートウェイ１００）が利用可能な記憶領域を、「クラウドストレージ」と記載する場合がある。

また、本実施の形態では例として、ストレージシステム２２０は、データがオブジェクト単位で管理されるオブジェクトストレージによって実現される。例えば、ストレージシステム２２０は、制御サーバ２２１ａとストレージ装置２２１ｂとをそれぞれ含むストレージノード２２１を複数有する、分散型のストレージシステムとして実現される。この場合、各ストレージノード２２１において、制御サーバ２２１ａはストレージ装置２２１ｂに対するアクセスを制御し、ストレージ装置２２１ｂの記憶領域によってクラウドストレージの一部が実現される。また、サービス利用者（クラウドストレージゲートウェイ１００）からのオブジェクトの格納先とされるストレージノード２２１は、オブジェクト固有の情報に基づいて決定される。

一方、ＮＡＳクライアント２１０は、クラウドストレージゲートウェイ１００を、ファイルシステムによって管理される記憶領域を提供するＮＡＳサーバとして認識する。この記憶領域とは、ストレージシステム２２０によって提供されるクラウドストレージによる記憶領域である。そして、ＮＡＳクライアント２１０は、例えばＮＦＳ（Network File System）プロトコルやＣＩＦＳ（Common Internet File System）プロトコルにしたがって、クラウドストレージゲートウェイ１００に対してファイル単位でデータの読み書きを要求する。すなわち、ＮＡＳクライアント２１０は、クラウドストレージゲートウェイ１００のＮＡＳサーバ機能により、クラウドストレージを大容量の仮想的なネットワークファイルシステムとして利用できるようになる。

ＮＡＳクライアント２１０は、例えば、データバックアップのためのバックアップソフトウェアを実行する。この場合ＮＡＳクライアント２１０は、ＮＡＳクライアント２１０に記憶されたファイル、またはＮＡＳクライアント２１０に接続されたサーバ（例えば業務サーバ）に記憶されたファイルを、ＮＡＳサーバから提供される記憶領域にバックアップする。

クラウドストレージゲートウェイ１００は、図１に示した情報処理装置１０の一例である。クラウドストレージゲートウェイ１００は、ＮＡＳクライアント２１０とクラウドストレージとの間で転送されるデータを中継する。

例えば、クラウドストレージゲートウェイ１００は、ＮＡＳサーバ機能により、ＮＡＳクライアント２１０からファイルの書き込み要求を受信し、書き込みが要求されたファイルを内部にキャッシュする。クラウドストレージゲートウェイ１００は、書き込みが要求されたファイルをチャンク単位に分割し、チャンク内の実データ（チャンクデータ）をクラウドストレージに格納する。このとき、所定個数のチャンクデータがグループ化されてオブジェクトが生成され、生成されたオブジェクトがクラウドストレージに転送される。

また、クラウドストレージゲートウェイ１００は、ＮＡＳクライアント２１０からのファイルをキャッシュする時点で、ファイルをチャンク単位に分割し、同一内容のチャンクデータが重複して保存されないようにする「重複排除」を行う。さらに、チャンクデータは圧縮された状態で格納されてもよい。例えば、クラウドストレージサービスでは、格納されるデータ量に応じて課金が行われる場合がある。重複排除やデータ圧縮を行うことで、クラウドストレージに格納されるデータ量を削減し、サービス利用コストを抑制することができる。

図３は、クラウドストレージゲートウェイのハードウェア構成例を示すブロック図である。クラウドストレージゲートウェイ１００は、例えば、図３に示すようなコンピュータとして実現される。

クラウドストレージゲートウェイ１００は、プロセッサ１０１、ＲＡＭ（Random Access Memory）１０２、ＨＤＤ（Hard Disk Drive）１０３、グラフィックインタフェース（Ｉ／Ｆ）１０４、入力インタフェース（Ｉ／Ｆ）１０５、読み取り装置１０６および通信インタフェース（Ｉ／Ｆ）１０７を備える。

プロセッサ１０１は、クラウドストレージゲートウェイ１００全体を統括的に制御する。プロセッサ１０１は、例えばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、またはＰＬＤ（Programmable Logic Device）である。また、プロセッサ１０１は、ＣＰＵ、ＭＰＵ、ＤＳＰ、ＡＳＩＣ、ＰＬＤのうちの２以上の要素の組み合わせであってもよい。

ＲＡＭ１０２は、クラウドストレージゲートウェイ１００の主記憶装置として使用される。ＲＡＭ１０２には、プロセッサ１０１に実行させるＯＳ（Operating System）プログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、プロセッサ１０１による処理に必要な各種データが格納される。

ＨＤＤ１０３は、クラウドストレージゲートウェイ１００の補助記憶装置として使用される。ＨＤＤ１０３には、ＯＳプログラム、アプリケーションプログラム、および各種データが格納される。なお、補助記憶装置としては、ＳＳＤ（Solid State Drive）などの他の種類の不揮発性記憶装置を使用することもできる。

グラフィックインタフェース１０４には、表示装置１０４ａが接続されている。グラフィックインタフェース１０４は、プロセッサ１０１からの命令にしたがって、画像を表示装置１０４ａに表示させる。表示装置としては、液晶ディスプレイや有機ＥＬ（Electroluminescence）ディスプレイなどがある。

入力インタフェース１０５には、入力装置１０５ａが接続されている。入力インタフェース１０５は、入力装置１０５ａから出力される信号をプロセッサ１０１に送信する。入力装置１０５ａとしては、キーボードやポインティングデバイスなどがある。ポインティングデバイスとしては、マウス、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。

読み取り装置１０６には、可搬型記録媒体１０６ａが脱着される。読み取り装置１０６は、可搬型記録媒体１０６ａに記録されたデータを読み取ってプロセッサ１０１に送信する。可搬型記録媒体１０６ａとしては、光ディスク、半導体メモリなどがある。

通信インタフェース１０７は、ネットワーク１０７ａを介して他の装置との間でデータの送受信を行う。
以上のようなハードウェア構成によって、クラウドストレージゲートウェイ１００の処理機能を実現することができる。なお、ＮＡＳクライアント２１０や制御サーバ２２１ａも、図３と同様のハードウェア構成を有するコンピュータとして実現可能である。

図４は、クラウドストレージゲートウェイが備える処理機能の構成例を示すブロック図である。クラウドストレージゲートウェイ１００は、記憶部１１０、ファイル入出力部１２０、重複排除処理部１３０およびクラウド通信部１４０を備える。

なお、記憶部１１０は、例えば、ＲＡＭ１０２やＨＤＤ１０３など、クラウドストレージゲートウェイ１００が備える記憶装置の記憶領域として実現される。また、ファイル入出力部１２０、重複排除処理部１３０およびクラウド通信部１４０の処理は、例えば、プロセッサ１０１が所定のプログラムを実行することで実現される。

記憶部１１０には、ディレクトリテーブル１１１、チャンクマップテーブル１１２、チャンク管理テーブル１１３、ハッシュキーテーブル１１４、オブジェクト管理テーブル１１５およびデフラグ判定テーブル１１６が記憶される。また、記憶部１１０の記憶領域の一部は、データキャッシュ１１７として利用される。

ディレクトリテーブル１１１は、ファイルシステムにおけるディレクトリ構造を表現するための管理情報である。ディレクトリテーブル１１１には、ディレクトリ構造上のディレクトリ（フォルダ）、またはディレクトリ内のファイルに対応するレコードが登録される。各レコードには、ディレクトリまたはファイルを識別するためのｉｎｏｄｅ番号が登録されている。また、例えば、各レコードに親ディレクトリのｉｎｏｄｅ番号が登録されることで、ディレクトリ間、およびディレクトリとファイルとの関係が表現される。

チャンクマップテーブル１１２は、ファイルと重複排除されたチャンクとの対応関係を管理するための管理情報である。チャンク管理テーブル１１３は、チャンクとオブジェクトとの対応関係や、チャンクの参照数を管理するための管理情報である。ハッシュキーテーブル１１４は、チャンクに対応するハッシュキーを管理するための管理情報である。

オブジェクト管理テーブル１１５は、オブジェクトごとに、オブジェクトに含まれるチャンクのうち有効なチャンクを示す有効チャンク数と無効なチャンクを示す無効チャンク数とを管理するための管理情報である。デフラグ判定テーブル１１６は、後述するオブジェクトグループごとに、オブジェクトグループに含まれるチャンクのうち有効なチャンクを示す有効チャンク数と無効なチャンクを示す無効チャンク数とを管理するための管理情報である。オブジェクト管理テーブル１１５およびデフラグ判定テーブル１１６は、クラウドストレージ２４０に格納されたオブジェクトについてのデフラグの実行要否を判定するために利用される。

データキャッシュ１１７は、重複排除されたチャンクをキャッシュするための記憶領域である。ＮＡＳクライアント２１０から書き込みが要求されたファイルに対応するチャンクのデータは、重複排除された上で一旦データキャッシュ１１７に格納された後、オブジェクトに組み込まれてクラウドストレージ２４０に格納される。チャンクの格納によりデータキャッシュ１１７の容量が少なくなると、クラウドストレージ２４０に格納済みで、ＮＡＳクライアント２１０からのアクセス頻度が低いチャンクは、データキャッシュ１１７から削除される。

ファイル入出力部１２０は、ＮＡＳサーバとしてのインタフェース処理を実行する。例えば、ファイル入出力部１２０は、ＮＡＳクライアント２１０からのファイルの読み書き要求を受け付け、要求された内容に応じた処理を重複排除処理部１３０に依頼して、ＮＡＳクライアント２１０に応答する。

クラウド通信部１４０は、重複排除処理部１３０からの要求に応じてクラウドストレージ２４０との間の通信処理を実行する。例えば、重複排除処理部１３０は、オブジェクトストレージであるクラウドストレージ２４０との間でオブジェクトの送受信を行う。重複排除処理部１３０は、ＰＵＴコマンドによりオブジェクトをクラウドストレージ２４０にアップロードする。また、重複排除処理部１３０は、ＧＥＴコマンドによりオブジェクトをクラウドストレージ２４０から取得する。また、重複排除処理部１３０は、ＤＥＬＥＴＥコマンドによりクラウドストレージ２４０上のオブジェクトを削除する。

重複排除処理部１３０は、ファイルの実データを重複を排除した状態で格納するための処理を実行する。重複排除処理部１３０は、重複判定部１３１、チャンク管理部１３２およびデフラグ処理部１３３を備える。

重複判定部１３１は、書き込みが要求されたファイルの実データをチャンク単位に分割し、分割された実データを重複を排除しながらデータキャッシュ１１７に格納する。
チャンク管理部１３２は、重複判定部１３１によってデータキャッシュ１１７に格納されたチャンクを、適切なサイズになるように複数まとめてオブジェクトを生成し、クラウド通信部１４０を介してクラウドストレージ２４０に格納する。本実施の形態では例として、所定個数のチャンクによってオブジェクトが生成される。

デフラグ処理部１３３は、ファイルの更新や削除の要求に伴って参照されなくなったチャンク（無効チャンク）を監視し、その監視結果に基づいてデフラグを実行する。デフラグとは、発生した無効チャンクをクラウドストレージ２４０から削除して、クラウドストレージ２４０の使用容量を削減するための処理である。デフラグでは基本的に、無効チャンクを含むオブジェクトがクラウドストレージ２４０から取得され、無効チャンクデータを削除した残りのチャンクによってオブジェクトが再構築されて、再構築されたオブジェクトがクラウドストレージ２４０に格納される。

次に、重複排除処理で利用される管理情報について、図５～図７を用いて説明する。
図５は、チャンクマップテーブルの構成例を示す図である。チャンクマップテーブル１１２は、ファイルと重複排除されたチャンクとの対応関係を管理するための管理情報である。図５に示すように、チャンクマップテーブル１１２には、ファイル番号、オフセット、サイズおよびチャンク番号の各項目を有するレコードが登録される。各レコードは、ファイルの実データを分割して生成された１つのチャンクに対応付けられている。

ファイル番号は、ファイルの識別番号を示す。オフセットは、ファイルの先頭からチャンクの先頭までのオフセット量を示す。サイズは、チャンクのサイズを示す。オフセットおよびサイズの値によって、ファイルにおけるチャンクの領域が特定される。

チャンク番号は、ファイル上のチャンクに対応する、重複排除されたチャンクの識別番号を示す。あるファイル上の第１のチャンクと、それと同じファイルまたは他のファイル上の第２のチャンクとの間でデータの内容が同じ場合、第１のチャンクに対応するレコードと第２のチャンクに対応するレコードには同じチャンク番号が登録される。例えば図５では、ファイル番号「ｆ１」およびオフセット「ｏ１」で識別されるチャンクのレコードと、ファイル番号「ｆ２」およびオフセット「ｏ１４」で識別されるチャンクのレコードとには、同じチャンク番号「ｃｋ１」が登録されている。これは、前者のチャンクと後者のチャンクとの間ではデータの内容が同じであり、このデータがチャンク番号「ｃｋ１」のチャンクとしてデータキャッシュ１１７やクラウドストレージ２４０に格納されていることを示す。

なお、チャンク番号は、重複していないユニークなチャンクが出現し、データキャッシュ１１７に格納された順に付与される。したがって、チャンク番号は、重複排除されたチャンクの出現順や格納順を示す。

図６は、チャンク管理テーブルおよびハッシュキーテーブルの構成例を示す図である。
チャンク管理テーブル１１３は、重複排除されたチャンクとオブジェクトとの対応関係や、チャンクの参照数を管理するための管理情報である。図６に示すように、チャンク管理テーブル１１３には、チャンク番号、オブジェクト番号、オフセット、サイズおよび参照数の各項目を有するレコードが登録される。各レコードは、重複排除された１つのチャンクに対応付けられている。

オブジェクト番号は、チャンクが属するオブジェクトの識別番号を示す。オフセットは、オブジェクトの先頭からチャンクの先頭までのオフセット量を示す。サイズは、チャンクのサイズを示す。オフセットおよびサイズの値によって、オブジェクトにおけるチャンクの領域が特定される。参照数は、チャンク番号が示すチャンクが、ファイルを分割して生成されたチャンクのうちいくつのチャンクから参照されているかを示す。すなわち、参照数は、チャンク番号が示すチャンクがファイル上のいくつのチャンクの間で重複しているかを示す。例えば、あるチャンク番号に対応する参照数が「２」の場合、同じチャンク番号の値が登録された２つのレコードがチャンクマップテーブル１１２に存在することになる。

ここで、図５の例では、ファイル番号「ｆ１」のファイルは２つのチャンクに分割されており、ファイル番号「ｆ２」のファイルは４つのチャンクに分割されている。また、図６の例では、前者のファイルに含まれる２つのチャンクのデータと、後者のファイルに含まれるチャンクのうち先頭から２つのチャンクのデータとが、オブジェクト番号「ｏｂ１」のオブジェクトに属するチャンクとしてクラウドストレージ２４０に格納されている。

ハッシュキーテーブル１１４は、重複排除されたチャンクに対応するハッシュキーを管理するための管理情報である。図６に示すように、ハッシュキーテーブル１１４には、ハッシュキーがチャンク番号に対応付けて登録されている。ハッシュキーは、チャンクのデータに基づいて算出されたハッシュ値であり、書き込みが要求されたファイル内のチャンクのデータと同一のチャンクを検索するために利用される。

図７は、オブジェクトの生成例を示す図である。この図７を用いて、オブジェクトの生成方法について説明する。
なお、図７に示すテーブル１１３ａは、チャンク管理テーブル１１３から、オブジェクト番号「ｏｂ１１」のオブジェクトに属するチャンクに対応するレコードのチャンク番号およびオブジェクト番号の各項目を抽出したものである。同様に、図７に示すテーブル１１３ｂは、チャンク管理テーブル１１３から、オブジェクト番号「ｏｂ１２」のオブジェクトに属するチャンクに対応するレコードのチャンク番号およびオブジェクト番号の各項目を抽出したものである。また、図７に示すテーブル１１３ｃは、チャンク管理テーブル１１３から、オブジェクト番号「ｏｂ１３」のオブジェクトに属するチャンクに対応するレコードのチャンク番号およびオブジェクト番号の各項目を抽出したものである。

ＮＡＳクライアント２１０から新規のファイルの書き込みや既存のファイルの更新が要求されると、重複判定部１３１は、ファイルの実データをチャンク単位に分割する。図７の例では、ファイルｆ１１の実データが８個のチャンクに分割され、ファイルｆ１２の実データが５個のチャンクに分割されたものとする。

ここでは説明を簡単にするために、これらのチャンクのデータはすべて異なる（重複していない）ものとする。このため、ファイルｆ１１を分割して得られたチャンクのデータには個別のチャンク番号「ｃｋ１１」～「ｃｋ１８」が付与され、ファイルｆ１２を分割して得られたチャンクのデータには個別のチャンク番号「ｃｋ１９」～「ｃｋ２３」が付与されている。そして、チャンク番号「ｃｋ１１」～「ｃｋ２３」にそれぞれ対応するチャンクのデータ（チャンクｃｋ１１～ｃｋ２３）は、データキャッシュ１１７に個別に格納される。

各チャンクにはオブジェクトのオブジェクト番号が割り当てられ、そのオブジェクト番号がチャンク管理テーブル１１３に登録される。また、本実施の形態では、同じオブジェクト番号に割り当てられたチャンクの個数が所定数に達すると、オブジェクト番号がカウントアップされ、次のチャンクにはカウントアップ後のオブジェクト番号が割り当てられる。これにより、同一のオブジェクトに対しては所定個数のチャンクが割り当てられる。

なお、チャンクの個数が所定数に達していないオブジェクトの状態を、次のチャンクを受け入れ可能な「アクティブ」と呼ぶことにする。アクティブなオブジェクトは、クラウドストレージ２４０への格納準備が整っていない未完成なオブジェクトである。また、チャンクの個数が所定数に達したオブジェクトの状態を、次のチャンクを受け入れ不可能な「非アクティブ」と呼ぶことにする。非アクティブなオブジェクトは、クラウドストレージ２４０への格納準備が整ったオブジェクトとなり、所定のタイミングでクラウドストレージ２４０へ転送される。

図７の例では、まず、チャンクｃｋ１１～ｃｋ１５がオブジェクト番号「ｏｂ１１」のオブジェクト（オブジェクトｏｂ１１）に割り当てられる。そして、この段階で、オブジェクトｏｂ１１に含まれるチャンクの個数が所定数（図７では例として５個）に達し、オブジェクトｏｂ１１が非アクティブになったとする。すると、次のチャンクｃｋ１６には新たなオブジェクト番号「ｏｂ１２」が割り当てられる。

この後、チャンクｃｋ１６～ｃｋ２０がオブジェクト番号「ｏｂ１２」のオブジェクト（オブジェクトｏｂ１２）に割り当てられ、この段階でオブジェクトｏｂ１２が非アクティブになったとする。すると、次のチャンクｃｋ２１には新たなオブジェクト番号「ｏｂ１３」が割り当てられる。図７の例では、チャンクｃｋ２１～ｃｋ２３がオブジェクト番号「ｏｂ１３」のオブジェクト（オブジェクトｏｂ１３）に割り当てられるが、この段階ではオブジェクトｏｂ１３はアクティブの状態である。この場合、次に生成されるチャンク（図示せず）にはオブジェクト番号「ｏｂ１３」が割り当てられることになる。

以上の手順により、ファイルの書き込みに伴うオブジェクトの生成では、重複排除によって所定個数のチャンクが新たに出現するたびに新たなオブジェクトが完成される。オブジェクトには、生成順にオブジェクト番号が付与される。また、１つのオブジェクトには、連続するチャンク番号を有するチャンクが割り当てられる。

以上の図７では、データの重複がない場合について説明した。例えば、この後に書き込みが要求されたファイル内のチャンクに、チャンクｃｋ１１～ｃｋ２３のいずれかと同じ内容のデータを含むチャンクが存在した場合、そのチャンクのデータはデータキャッシュ１１７に新たに格納されず、クラウドストレージ２４０にも転送されない。すなわち、このチャンクについては実データの書き込みが行われず、ファイルと格納済みのチャンクとを対応付けるためのメタデータのみがチャンクマップテーブル１１２に書き込まれる。このようにして、重複するデータが記憶されないようにする「重複排除処理」が実行される。

なお、本実施の形態では、所定個数のチャンクがオブジェクトに割り当てられると、そのオブジェクトが非アクティブ化される。しかし、他の方法として、例えば、オブジェクトに割り当てられたチャンクの合計サイズが所定サイズを超えた場合に、そのオブジェクトが非アクティブ化されてもよい。

次に、デフラグの実行要否を判定するために利用される管理情報について、図８、図９を用いて説明する。
図８は、オブジェクト管理テーブルの構成例を示す図である。オブジェクト管理テーブル１１５には、オブジェクト番号に対して有効チャンク数および無効チャンク数が対応付けて登録される。有効チャンク数は、オブジェクトに含まれるチャンクデータのうち、有効なチャンクデータ（参照数が１以上のチャンクデータ）の数を示す。無効チャンク数は、オブジェクトに含まれるチャンクデータのうち、無効なチャンクデータ（参照数が０のチャンクデータ）の数を示す。

図９は、デフラグ判定テーブルの構成例を示す図である。デフラグ判定テーブル１１６は、有効チャンク数および無効チャンク数を、複数のオブジェクトを含むオブジェクトグループごとに管理するための管理情報である。デフラグ判定テーブル１１６には、オブジェクトグループに含まれるチャンクデータのチャンク番号に対して、有効チャンク数および無効チャンク数が対応付けて登録される。ファイルの書き込みに伴ってオブジェクトが生成される際、所定個数（例えば２０個）のオブジェクトが１つのオブジェクトグループにグループ化される。

また、デフラグ判定テーブル１１６の各レコードにはデフラグ済みフラグがさらに登録される。デフラグ済みフラグは、該当するオブジェクトグループについてデフラグが１回以上実行されたか否かを示すフラグ情報である。ここでは例として、デフラグ済みフラグの値は、デフラグが１回も実行されていない場合は「０」に設定され、デフラグが１回でも実行されると「１」に更新されるものとする。

ところで、クラウドストレージ２４０のようなオブジェクトストレージを提供するサービスでは、一般的に、使用容量に応じて課金される。また、ＧＥＴコマンドやＰＵＴコマンド等による通信に対して課金されるサービスもある。例えば、コマンドによる通信回数、あるいは通信データ量に応じて課金される場合がある。

クラウドストレージゲートウェイ１００は、重複排除技術により、内容が同じデータがクラウドストレージ２４０に重複して格納されないように制御する。これにより、クラウドストレージ２４０における使用容量が削減される。また、ファイルの削除や更新によって、どのファイルからも参照されない無効のチャンクが発生する場合がある。クラウドストレージゲートウェイ１００は、デフラグの実行により、クラウドストレージ２４０から無効なチャンクを削除する。これにより、クラウドストレージ２４０における使用容量のさらなる削減が図られる。

しかし、クラウドストレージ２４０のようなオブジェクトストレージを提供するサービスでは、一般的に、オブジェクト内の一部のデータ領域だけを削除するようなコマンドは用意されていない。このため、デフラグでは基本的に、無効なチャンクを含むオブジェクトを取得し、無効なチャンクを除去してオブジェクトを再構築した上で、再構築したオブジェクトを送信する、という手順が実行される。

このように、１回のデフラグを実行するためにはクラウドストレージ２４０とクラウドストレージゲートウェイ１００との間で複数回の通信が行われる場合が多い。このため、通信に対して課金されるサービスでは、デフラグの実行により通信コストが増大してしまう。したがって、デフラグ実行時における通信回数や通信データ量をできるだけ削減したいという点に課題がある。

ここで、図１０～図１４を用いてデフラグ処理手順の比較例について説明し、その後に第２の実施の形態におけるデフラグ処理手順について説明する。
まず、図１０は、デフラグ処理手順の比較例を示す第１の図である。図１０の例では、ＮＡＳクライアント２１０からクラウドストレージゲートウェイ１００に対して、ファイルｆ２１～ｆ２４の書き込みが順に要求されたとする。

可変長チャンキングにより、ファイルｆ２１はチャンクＡ～Ｄに分割され、ファイルｆ２２はチャンクＡ，Ｅ，Ｃ，Ｆに分割され、ファイルｆ２３はチャンクＡ，Ｅ，Ｇ，Ｈに分割され、ファイルｆ２４はチャンクＡ，Ｅ，Ｇ，Ｈ，Ｉに分割されたとする。ここで、同じアルファベットの文字が付与されたチャンクのデータは同じ内容であるとする。例えば、ファイルｆ２１～ｆ２４からそれぞれ分割されたチャンクＡは、すべて同じ内容のデータである。すなわち、ファイルｆ２１～ｆ２４の間ではチャンクＡのデータが重複している。

このようなファイルｆ２１～ｆ２４の書き込みが要求された場合、重複排除処理により、チャンクＡ～Ｉが１つずつデータキャッシュ１１７に格納される。また、チャンクＡ～Ｉに対応する参照数（重複数）は、それぞれ「４」、「１」、「２」、「１」、「３」、「１」、「２」、「２」、「１」となる。

また、図１０では例として、オブジェクトには３個のチャンクが割り当てられるものとする。この場合、チャンクＡ～Ｃによりオブジェクトｏｂ２１が生成され、チャンクＤ～Ｆによりオブジェクトｏｂ２２が生成され、チャンクＧ～Ｉによりオブジェクトｏｂ２３が生成される。そして、オブジェクトｏｂ２１～ｏｂ２３は、ＰＵＴコマンドによりクラウドストレージゲートウェイ１００からクラウドストレージ２４０にアップロードされる。

図１１は、デフラグ処理手順の比較例を示す第２の図である。クラウドストレージゲートウェイ１００においては、データキャッシュ１１７の残容量が所定量以下になると、クラウドストレージ２４０にアップロード済みのオブジェクトのうちアクセス頻度が低いオブジェクトが、データキャッシュ１１７から削除される。図１１では、オブジェクトｏｂ２１～ｏｂ２３がデータキャッシュ１１７から削除されているとする。

この状態で、ＮＡＳクライアント２１０からファイルｆ２１の削除が要求されたとする。これに伴い、チャンクＡの参照数は「４」から「３」に減少し、チャンクＢの参照数は「１」から「０」に減少し、チャンクＣの参照数は「２」から「１」に減少し、チャンクＤの参照数は「１」から「０」に減少する。これにより、チャンクＢ，Ｄは無効なデータとなる。

図１２は、デフラグ処理手順の比較例を示す第３の図である。この図１２では、無効になったチャンクＢ，Ｄの各データをクラウドストレージ２４０から削除するためのデフラグ処理手順の一例を示している。

図１２の例では、チャンクＢを含むオブジェクトｏｂ２１が、ＧＥＴコマンドによりクラウドストレージゲートウェイ１００に取得される。そして、チャンクＢを除くチャンクＡ，Ｃによりオブジェクトｏｂ２１が再構築され、再構築されたオブジェクトｏｂ２１がＰＵＴコマンドによりクラウドストレージ２４０に再アップロードされる。

また、チャンクＤを含むオブジェクトｏｂ２２が、ＧＥＴコマンドによりクラウドストレージゲートウェイ１００に取得される。そして、チャンクＤを除くチャンクＥ，Ｆによりオブジェクトｏｂ２２が再構築され、再構築されたオブジェクトｏｂ２２がＰＵＴコマンドによりクラウドストレージ２４０に再アップロードされる。

図１３は、デフラグ処理手順の比較例を示す第４の図である。図１３では、データキャッシュ１１７の残容量低下に伴い、再構築されたオブジェクトｏｂ２１，ｏｂ２２はデータキャッシュ１１７から削除されている。

この状態で、ＮＡＳクライアント２１０からさらにファイルｆ２２の削除が要求されたとする。これに伴い、チャンクＡの参照数は「３」から「２」に減少し、チャンクＥの参照数は「３」から「２」に減少し、チャンクＣの参照数は「１」から「０」に減少し、チャンクＦの参照数は「１」から「０」に減少する。これにより、チャンクＣ，Ｆは無効なデータとなる。

図１４は、デフラグ処理手順の比較例を示す第５の図である。この図１４では、無効になったチャンクＣ，Ｆをクラウドストレージ２４０から削除するためのデフラグ処理手順の一例を示している。

図１４の例では、チャンクＣを含むオブジェクトｏｂ２１が、ＧＥＴコマンドによりクラウドストレージゲートウェイ１００に取得される。そして、チャンクＣを除くチャンクＡによりオブジェクトｏｂ２１が再構築され、再構築されたオブジェクトｏｂ２１がＰＵＴコマンドによりクラウドストレージ２４０に再アップロードされる。

また、チャンクＦを含むオブジェクトｏｂ２２が、ＧＥＴコマンドによりクラウドストレージゲートウェイ１００に取得される。そして、チャンクＦを除くチャンクＥによりオブジェクトｏｂ２２が再構築され、再構築されたオブジェクトｏｂ２２がＰＵＴコマンドによりクラウドストレージ２４０に再アップロードされる。

以上のデフラグ処理手順により、無効になったチャンクＢ，Ｃ，Ｄ，Ｆがクラウドストレージ２４０から削除され、クラウドストレージ２４０の使用容量が削減される。しかしながら、図１２に示す１回目のデフラグ処理と図１４に示す２回目のデフラグ処理のどちらでも、各オブジェクトについて２回のコマンド送信が実行されており、通信回数が多くなっている。

図１０～図１４では説明を簡単にするためにオブジェクト数やオブジェクト内のチャンク数を少なく記載しているが、実際には数万以上のオブジェクトが生成され、各オブジェクトにも数千以上のチャンクが含まれる。このため、無効チャンクが発生するオブジェクトは大量に出現し、しかも、同じオブジェクトについて無効チャンクが複数回発生し得る。そして、それらのオブジェクトそれぞれについてＧＥＴコマンドとＰＵＴコマンドによる２回の通信が行われる。したがって、デフラグ実行に伴う通信回数は膨大な数になり、膨大な通信料金が発生してしまう。

図１５は、第２の実施の形態におけるデフラグ処理手順を示す図である。
本実施の形態のクラウドストレージゲートウェイ１００は、オブジェクトについての１回目のデフラグの実行要否をオブジェクト単位で判定するのではなく、複数のオブジェクトを含むオブジェクトグループ単位で判定する。図９に示したデフラグ判定テーブル１１６は、オブジェクトグループ単位でデフラグの実行要否を判定するために利用される。クラウドストレージゲートウェイ１００は、デフラグ判定テーブル１１６を用いて、オブジェクトグループに含まれる各オブジェクトでの無効チャンクの発生状況を監視する。そして、クラウドストレージゲートウェイ１００は、オブジェクトグループ内の無効チャンク数の割合が一定割合を超えた場合に、そのオブジェクトグループ内の各オブジェクトについてデフラグの実行が必要と判定する。

クラウドストレージゲートウェイ１００は、あるオブジェクトグループについてデフラグの実行が必要と判定すると、そのオブジェクトグループ内の全オブジェクトを取得する。そして、クラウドストレージゲートウェイ１００は、取得した全オブジェクトから無効チャンクを除去した上でオブジェクトを再構築し、再構築されたオブジェクトをクラウドストレージ２４０に再アップロードする。このオブジェクト再構築の際、クラウドストレージゲートウェイ１００は、単に同じオブジェクト内の有効チャンク同士を結合するのではなく、次回以降のデフラグの発生回数やデフラグ時の通信回数が減るように、オブジェクト間で有効チャンクの組み替えを行う。上記のようにオブジェクトグループ単位でデフラグの実行要否を判定する目的は、このようにオブジェクトグループ内のオブジェクト間で有効チャンクを組み替え可能にする点にある。

図１５の例では、ファイルの書き込み要求に伴ってオブジェクトｏｂ３１～ｏｂ３５が生成され、クラウドストレージ２４０にアップロードされたとする（初回アップロード）。また、これらのオブジェクトｏｂ３１～ｏｂ３５によってオブジェクトグループｇｐ１が形成されている。そして、その後のファイル削除やファイル更新の要求に伴ってオブジェクトグループｇｐ１内に無効チャンクが発生し、無効チャンク数の割合が一定割合を超えて、オブジェクトグループｇｐ１のデフラグ実行が必要と判定されたとする。なお、図１５中のオブジェクトｏｂ３１，ｏｂ３３，ｏｂ３４に示されている斜線部分は、無効チャンクの領域を示す。

クラウドストレージゲートウェイ１００は、ＧＥＴコマンドによりクラウドストレージ２４０からオブジェクトｏｂ３１～ｏｂ３５を取得し、これらについて一括してデフラグを実行する。このデフラグでは、クラウドストレージゲートウェイ１００は、取得したオブジェクトｏｂ３１～ｏｂ３５に含まれる有効チャンクを組み替えてオブジェクトを再構築し、再構築されたオブジェクトをクラウドストレージ２４０にアップロードする。図１５の例では、再構築によりオブジェクトｏｂ４１～ｏｂ４５が生成され、クラウドストレージ２４０にアップロードされたとする。すなわち、クラウドストレージ２４０には元のオブジェクトｏｂ３１～ｏｂ３５の代わりに再構築されたオブジェクトｏｂ４１～ｏｂ４５が格納される。

なお、再構築されたオブジェクトｏｂ４１～ｏｂ４５についても、元のオブジェクトｏｂ３１～ｏｂ３５と同じオブジェクトグループｇｐ１に属するものとして管理される。正確には、元のオブジェクトｏｂ３１～ｏｂ３５内の有効チャンク（すなわち、再構築されたオブジェクトｏｂ４１～ｏｂ４５内のチャンク）が、再構築前と同じオブジェクトグループｇｐ１に属するものとして管理される。したがって、デフラグ判定テーブル１１６（図９参照）においては、再構築されたオブジェクトｏｂ４１～ｏｂ４５内のチャンクは再構築前と同じレコードに対応付けて管理される。

一方、図示しないが、クラウドストレージゲートウェイ１００は、オブジェクトグループｇｐ１についての２回目以降のデフラグについては、オブジェクトグループ単位でなく、オブジェクト単位で実行する。例えば、再構築されたオブジェクトｏｂ４１～ｏｂ４５については、オブジェクト単位で無効チャンク数が監視され、無効チャンク数の割合が一定割合を超えたオブジェクトについて、そのオブジェクト単独で２回目のデフラグが行われる。デフラグの方法としては、図１２、図１４に示したように、単一オブジェクト内の有効チャンクのみを結合することでオブジェクトが再構築される。

ここで、オブジェクトグループｇｐ１についての１回目のデフラグでは、オブジェクトの再構築の際に、チャンク管理テーブル１１３に登録された、有効チャンクに対応する参照数およびチャンク番号が参照される。クラウドストレージゲートウェイ１００は、基本方針として、参照数およびチャンク番号が互いに近いチャンクを同一のオブジェクトにまとめるようにする。

チャンク番号が近いチャンクは、同じファイルから切り出された可能性が高い。また、バックアップ用途でＮＡＳクライアント２１０からファイルが書き込まれる場合には、複数のファイルについてまとめて書き込みや削除が要求されることが多い。このような理由から、チャンク番号が近いチャンクを１つのオブジェクトにまとめて再アップロードすることで、そのオブジェクト内のチャンクの参照数が同じ時期に減算される可能性が高くなる。また、参照数が近いチャンクを１つのオブジェクトにまとめることで、オブジェクト内の各チャンクの参照数が均等に減少していく可能性が高くなる。

その結果、オブジェクト内の分散した位置で無効チャンクが長時間をかけて徐々に発生する可能性が低くなり、逆にオブジェクト内で多数の無効チャンクが一度に発生しやすくなる。これにより、このオブジェクトについてデフラグが必要と判定されたときに、一度に多数の無効チャンクを削除できる可能性が高まる。その結果、オブジェクト内で無効チャンクが長時間をかけて少しずつ増えていく場合と比較して、同じオブジェクトについてのデフラグの実行回数が減少する可能性が高くなる。したがって、クラウドストレージゲートウェイ１００とクラウドストレージ２４０との間の通信回数が減少する可能性が高くなる。また、通信回数の減少により、クラウドストレージゲートウェイ１００とクラウドストレージ２４０との間の通信量も削減される。

ここで、図１６は、２回目以降のデフラグの実行例を示す第１の図である。図１６の左側では、図１５で再構築されたオブジェクトｏｂ４１についての状態遷移の例を示す。一方、図１６の右側では、状態遷移の比較例として、元のオブジェクトｏｂ３１について有効チャンクのみを結合することで得られたオブジェクトｏｂ５１についての状態遷移の例を示す。

オブジェクトｏｂ４１については、まとまった大きな領域で無効チャンクが発生しやすくなる。一方、オブジェクトｏｂ５１については、まとまった領域のチャンクで参照数が減少されたとしても、各チャンクの参照数に差があるため、無効チャンクの小さな領域が分散して発生しやすくなる。その結果、オブジェクトｏｂ４１の方が、デフラグが必要と判定されたときに削除される無効チャンク数が多くなる可能性が高くなる。その結果、オブジェクトｏｂ４１の方が、オブジェクト全体が削除されるまでに実行されるデフラグの回数が減少する可能性が高くなる。

以下、図１５を用いて説明を続ける。
上記のようにオブジェクト内の各チャンクの参照数が均等に減少していく可能性が高い場合には、オブジェクトのサイズが小さいほど、そのオブジェクトについてデフラグが必要と判定されたときに、オブジェクト内の全チャンクが無効になる可能性が高くなる。そこで、クラウドストレージゲートウェイ１００は、オブジェクトグループｇｐ１の１回目のデフラグの際、オブジェクトに含める参照数が小さいほど、オブジェクトのサイズを小さくする（オブジェクトに含めるチャンク数を少なくする）。これにより、オブジェクトについてデフラグが必要と判定されたときに、オブジェクト内の全チャンクが無効になっている場合には、そのオブジェクトの削除（ＤＥＬＥＴＥ）のみ実行されればよくなり、オブジェクトの取得（ＧＥＴ）と再アップロード（ＰＵＴ）は不要になる。したがって、クラウドストレージゲートウェイ１００とクラウドストレージ２４０との間の通信回数をさらに低減できる可能性が高くなる。また、通信回数の減少により、クラウドストレージゲートウェイ１００とクラウドストレージ２４０との間の通信量のさらなる削減も期待できる。

図１５の例では、再構築されたオブジェクトｏｂ４１，ｏｂ４２に含まれるチャンクの参照数より、再構築されたオブジェクトｏｂ４３～ｏｂ４５に含まれるチャンクの参照数の方が小さい。そこで、オブジェクトｏｂ４１，ｏｂ４２のサイズより、オブジェクトｏｂ４３～ｏｂ４５のサイズが小さくなっている。これにより、オブジェクトｏｂ４１，ｏｂ４２と比較して、オブジェクトｏｂ４３～ｏｂ４５の方が、ＤＥＬＥＴＥコマンドによってオブジェクト単位で削除されやすくなる。したがって、デフラグが必要と判定されたときに、オブジェクトｏｂ４３～ｏｂ４５の方が通信回数を低減できる可能性が高まる。また、オブジェクト全体のチャンクが削除されることで、オブジェクトの再構築が不要になり、クラウドストレージゲートウェイ１００の処理負荷を軽減できる。

図１７は、２回目以降のデフラグの実行例を示す第２の図である。図１７の左側では、図１５で再構築されたオブジェクトｏｂ４１についての状態遷移の例を示す。また、図１７の右側には、図１５で再構築されたオブジェクトｏｂ４３についての状態遷移の例を示す。前述のように、オブジェクトｏｂ４１に含まれるチャンクの参照数より、オブジェクトｏｂ４３に含まれるチャンクの参照数の方が小さい。また、オブジェクトｏｂ４１のサイズよりオブジェクトｏｂ４３のサイズの方が小さい。

オブジェクトｏｂ４１，ｏｂ４３のいずれでも、オブジェクト内の各チャンクの参照数が均等に減少していく可能性が高い。そして、オブジェクトｏｂ４１，ｏｂ４３のいずれでも、デフラグの実行が必要と判定されたときに削除される無効チャンク数が多くなる可能性が高い。ただし、オブジェクトｏｂ４３に含まれるチャンクの参照数の方が小さいので、オブジェクトｏｂ４３の方が早期に全体のチャンクが無効になりやすい。また、オブジェクトｏｂ４３の方が１回で全体のチャンクが無効になる可能性も高い。したがって、オブジェクトｏｂ４３の方が、クラウドストレージゲートウェイ１００とクラウドストレージ２４０との間の通信回数をさらに低減できる可能性が高くなる。

以下、図１５を用いて説明を続ける。
クラウドストレージゲートウェイ１００は、オブジェクトについての１回目のデフラグの際に生成するオブジェクトのサイズを、初回アップロード時に生成するオブジェクトのサイズより小さくしてもよい。これは、クラウドストレージ２４０についての次のような特性に基づいて行われる。

クラウドストレージゲートウェイ１００とクラウドストレージ２４０との間では、オブジェクトのサイズを大きくするほど、通信性能を高めることができる。これは、合計サイズが同じデータを複数のオブジェクトに分割して複数回送信するよりも、１つのオブジェクトにまとめて１回で送信した方が、全体として通信速度が高くなるからである。

本実施の形態では、初回アップロードは、ＮＡＳクライアント２１０からのファイル書き込みやファイル更新の要求に応じて実行される一連の処理として実行される。すなわち、必要なオブジェクトのアップロードが完了するまで、ファイル書き込みやファイル更新に対する応答がＮＡＳクライアント２１０に返されない。このため、初回アップロードは高速に実行される必要がある。そこで、初回アップロード時には、例えば平均５０ＭＢ前後の比較的大きなサイズのオブジェクトが生成されて、そのオブジェクトがクラウドストレージ２４０に送信される。これにより、ファイル書き込みやファイル更新に対する応答時間を短縮できる。

一方、デフラグは、ＮＡＳクライアント２１０からの要求に応じたＩ／Ｏ（Input／Output）処理に対してバックグラウンドで実行される。このため、デフラグにおける通信速度は、初回アップロード時ほど高くなくてよい。このことから、オブジェクトについての１回目のデフラグの際に生成するオブジェクトのサイズを、初回アップロード時に生成するオブジェクトのサイズより小さくすることができる。例えば、チャンクの参照数が大きい場合、オブジェクトのサイズが平均で数ＭＢ程度になるようにし、チャンクの参照数が小さい場合、オブジェクトのサイズが平均で１ＭＢ程度になるようにする。このようにオブジェクトのサイズを小さくすることで、２回目以降のデフラグの際のデータ通信量を削減することができる。

次に、クラウドストレージゲートウェイ１００の処理について、フローチャートを用いて説明する。
図１８、図１９は、ファイル書き込み処理の手順を示すフローチャートの例である。

［ステップＳ１１］ファイル入出力部１２０は、ＮＡＳクライアント２１０からファイルの書き込み要求およびファイルのデータを受信する。重複排除処理部１３０の重複判定部１３１は、書き込みが要求されたファイルのデータを取得し、ディレクトリテーブル１１１に、そのファイルのディレクトリ情報を示すレコードを追加する。このとき、ファイルにファイル番号が付与される。また、重複判定部１３１は、ファイルのデータを可変長のチャンクに分割する。

［ステップＳ１２］重複判定部１３１は、ファイルの先頭側から順に、処理対象のチャンクを１つ選択する。また、重複判定部１３１は、選択されたチャンクのデータに基づくハッシュキーを算出する。

［ステップＳ１３］重複判定部１３１は、チャンクマップテーブル１１２にレコードを追加し、このレコードに次のような情報を登録する。ファイル番号の項目には、書き込みが要求されたファイルのファイル番号が登録され、オフセットおよびサイズの項目には、処理対象のチャンクについての情報が登録される。

［ステップＳ１４］重複判定部１３１は、ハッシュキーテーブル１１４を参照し、ステップＳ１３で算出されたハッシュキーが登録されたレコードが存在するかを判定する。これにより、ステップＳ１２で選択されたチャンクと同じ内容のチャンクがすでに格納済みか（重複しているか）が判定される。重複判定部１３１は、該当するレコードが見つかった場合、ステップＳ１５の処理を実行し、該当するレコードが存在しない場合、図１９のステップＳ２１の処理を実行する。

［ステップＳ１５］重複判定部１３１は、ステップＳ１４でハッシュキーテーブル１１４から検索されたレコードからチャンク番号を取得し、取得したチャンク番号をステップＳ１３でチャンクマップテーブル１１２に追加したレコードに登録する。

［ステップＳ１６］重複判定部１３１は、チャンク管理テーブル１１３のレコードのうち、ステップＳ１５で取得したチャンク番号を含むレコードを参照し、このレコードに登録されている参照数をカウントアップする。

［ステップＳ１７］重複判定部１３１は、ステップＳ１１で分割されたすべてのチャンクについて処理済みかを判定する。重複判定部１３１は、未処理のチャンクがある場合は処理をステップＳ１２に進め、未処理のチャンクを先頭側から１つ選択して処理を継続する。一方、重複判定部１３１は、すべてのチャンクを処理済みの場合、ファイル書き込みが完了したことをファイル入出力部１２０に通知する。通知を受けたファイル入出力部１２０は、ＮＡＳクライアント２１０に対してファイル書き込みの完了を示す応答情報を送信する。

以下、図１９を用いて説明を続ける。
［ステップＳ２１］重複判定部１３１は、ステップＳ１２で選択されたチャンクについての新たなチャンク番号を算出する。このチャンク番号は、チャンク管理テーブル１１３に登録されているチャンク番号の最大値に「１」を加算した値とされる。重複判定部１３１は、チャンク管理テーブル１１３に新たなレコードを追加し、このレコードに対し、算出された新たなチャンク番号と、チャンクのサイズと、参照数「１」とを登録する。

［ステップＳ２２］重複判定部１３１は、ステップＳ１２で選択されたチャンクのデータをデータキャッシュ１１７に格納する。このとき、データの格納位置とチャンク番号との対応付けが行われる。また、重複判定部１３１は、ハッシュキーテーブル１１４に新たなレコードを追加し、このレコードに対し、ステップＳ２１で算出された新たなチャンク番号と、ステップＳ１２で算出されたハッシュキーとを登録する。

［ステップＳ２３］重複判定部１３１は、ステップＳ２１で算出された新たなチャンク番号を、ステップＳ１３でチャンクマップテーブル１１２に追加したレコードに登録する。

［ステップＳ２４］チャンク管理部１３２は、クラウドストレージ２４０に対して未送信のチャンク数が所定の閾値（Ｍとする）に達したかを判定する。未送信のチャンク数とは、アクティブ状態のオブジェクトに含まれるチャンクの数である。また、閾値Ｍは、例えば１００００個程度に設定される。チャンク管理部１３２は、未送信のチャンク数が閾値Ｍに達した場合、ステップＳ２５に処理を進め、未送信のチャンク数が閾値Ｍに達していない場合、ステップＳ２７に処理を進める。

［ステップＳ２５］チャンク管理部１３２は、未送信のＭ個のチャンクを結合して生成したオブジェクトをクラウドストレージ２４０にアップロードするように、クラウド通信部１４０に依頼する。これにより、当該オブジェクトは非アクティブの状態となる。クラウド通信部１４０は、ＰＵＴコマンドによりオブジェクトをクラウドストレージ２４０にアップロードする。

［ステップＳ２６］チャンク管理部１３２は、ステップＳ１２で選択されたチャンクに新たなオブジェクト番号を割り当てる。このオブジェクト番号は、ステップＳ２５でアップロードされたオブジェクトのオブジェクト番号に「１」を加算した値とされる。チャンク管理部１３２は、ステップＳ２１でチャンク管理テーブル１１３に追加されたレコードに、新たなオブジェクト番号と、オフセット「０」とを登録する。新たなオブジェクト番号に対応するオブジェクトは、アクティブ状態となる。また、チャンク管理部１３２は、オブジェクト管理テーブル１１５に新たなレコードを追加し、このレコードに新たなオブジェクト番号を登録する。

［ステップＳ２７］チャンク管理部１３２は、ステップＳ１２で選択されたチャンクに、既存の最大のオブジェクト番号を割り当てる。このオブジェクト番号は、ステップＳ２４で判定の対象となった未送信のチャンクに割り当てられているオブジェクト番号である。したがって、ステップＳ２７では、これらのチャンクに割り当てられている未送信のオブジェクト（アクティブ状態のオブジェクト）に対して、ステップＳ１２で選択されたチャンクがさらに割り当てられる。

チャンク管理部１３２は、ステップＳ２１でチャンク管理テーブル１１３に追加されたレコードに、割り当てられたオブジェクト番号と、対応するオブジェクトにおけるオフセットとを登録する。登録されるオフセットは、１つ前のレコードに登録されたオフセットとサイズとから算出される。

［ステップＳ２８］チャンク管理部１３２は、オブジェクト管理テーブル１１５およびデフラグ判定テーブル１１６に対して、有効チャンク数の登録または更新を行う。
ステップＳ２６が実行された場合、チャンク管理部１３２は、ステップＳ２６でオブジェクト管理テーブル１１５に追加したレコードに、有効チャンク数としてＭを登録する。また、チャンク管理部１３２は、このレコードに対応するオブジェクトが含まれるオブジェクトグループに対応するレコードをデフラグ判定テーブル１１６から特定し、特定したレコードに登録された有効チャンク数にＭを加算する。ただし、該当するオブジェクトグループがデフラグ判定テーブル１１６に存在しない場合、チャンク管理部１３２は、デフラグ判定テーブル１１６に新たにレコードを追加し、そのレコードに有効チャンク数としてＭを登録し、デフラグ済みフラグとして「０」を登録する。

一方、ステップＳ２７が実行された場合、チャンク管理部１３２は、オブジェクト管理テーブル１１５からステップＳ２７で割り当てられたオブジェクト番号を含むレコードを特定し、特定したレコードに登録された有効チャンク数にＭを加算する。また、チャンク管理部１３２は、このレコードに対応するオブジェクトが含まれるオブジェクトグループに対応するレコードをデフラグ判定テーブル１１６から特定し、特定したレコードに登録された有効チャンク数にＭを加算する。

以上のステップＳ２８の処理が完了すると、処理が図１８のステップＳ１７に進められる。
図２０は、ファイル削除処理の手順を示すフローチャートの例である。

［ステップＳ３１］ファイル入出力部１２０は、ＮＡＳクライアント２１０からファイルの削除要求を受信する。重複排除処理部１３０の重複判定部１３１は、削除が要求されたファイルのファイル番号をディレクトリテーブル１１１に基づいて特定する。

［ステップＳ３２］重複判定部１３１は、ステップＳ３１で特定したファイル番号が登録されたレコードをチャンクマップテーブル１１２から特定して、特定したレコードの１つを選択する。これにより、削除が要求されたファイルから生成されたチャンクの１つが選択される。

［ステップＳ３３］重複判定部１３１は、ステップＳ３２で選択されたレコードからチャンク番号を取得する。重複判定部１３１は、チャンク管理テーブル１１３において、取得したチャンク番号に対応付けられた参照数を「１」だけカウントダウンする。

［ステップＳ３４］重複判定部１３１は、カウントダウン後の参照数が「０」かを判定する。重複判定部１３１は、参照数が「０」の場合、処理をステップＳ３５に進め、参照数が「０」でない場合（「１」以上の場合）、処理をステップＳ４０に進める。

［ステップＳ３５］このケースでは、ステップＳ３３で取得したチャンク番号に対応するチャンクが無効になっている。チャンク管理部１３２は、チャンク管理テーブル１１３から、ステップＳ３３で取得したチャンク番号に対応付けられたオブジェクト番号を特定する。チャンク管理部１３２は、オブジェクト管理テーブル１１５を参照して、特定したオブジェクト番号に対応付けられた無効チャンク数に「１」を加算し、当該オブジェクト番号に対応付けられた有効チャンク数から「１」を減算する。

また、チャンク管理部１３２は、特定したオブジェクト番号が示すオブジェクトが含まれるオブジェクトグループを特定し、デフラグ判定テーブル１１６から、特定したオブジェクトグループに対応するレコードを特定する。チャンク管理部１３２は、特定したレコードに登録された無効チャンク数に「１」を加算し、当該レコードに登録された有効チャンク数から「１」を減算する。

［ステップＳ３６］チャンク管理部１３２は、ステップＳ３５での有効チャンク数の減算により、オブジェクト管理テーブル１１５の該当レコードに登録された有効チャンク数が「０」になったかを判定する。チャンク管理部１３２は、有効チャンク数が「０」の場合、処理をステップＳ３７に進め、有効チャンク数が「０」でない場合（「１」以上の場合）、処理をステップＳ３８に進める。

［ステップＳ３７］このケースでは、ステップＳ３３で取得したチャンク番号に対応するチャンクが属するオブジェクトについて、オブジェクト内の全チャンクが無効になっている。このため、このオブジェクトが不要である。そこで、チャンク管理部１３２は、このオブジェクトを削除するようにクラウド通信部１４０に依頼する。クラウド通信部１４０は、ＤＥＬＥＴＥコマンドによりクラウドストレージ２４０に対してオブジェクトの削除を要求する。これにより、クラウドストレージ２４０からオブジェクトが削除される。

［ステップＳ３８］チャンク管理部１３２は、ステップＳ３５で有効チャンク数および無効チャンク数を更新した、デフラグ判定テーブル１１６のレコードを参照する。チャンク管理部１３２は、このレコードに現在登録されている有効チャンク数と無効チャンク数とに基づいて、全チャンク数（有効チャンク数＋無効チャンク数）に対する無効チャンク数の割合を算出する。この無効チャンク数の割合は、ステップＳ３３で取得したチャンク番号に対応するチャンクを含むオブジェクトが属するオブジェクトグループについて、このオブジェクトグループにおける全チャンク数に対する無効チャンク数の割合を示す。

チャンク管理部１３２は、無効チャンク数の割合が所定の閾値（例えば２０％）を超えたかを判定する。チャンク管理部１３２は、無効チャンク数の割合が閾値を超えた場合、処理をステップＳ３９に進め、無効チャンク数の割合が閾値以下の場合、処理をステップＳ４０に進める。

［ステップＳ３９］ステップＳ３８で無効チャンク数の割合が閾値を超えた場合、ステップＳ３３で取得したチャンク番号に対応するチャンクが属するオブジェクトグループ（ステップＳ３８で参照されたレコードに対応するオブジェクトグループ）について、デフラグによるデータ削減効果が高いと判断される。この場合、チャンク管理部１３２は、このオブジェクトグループをデフラグ対象に設定する。このとき例えば、該当するオブジェクトグループに現在の時刻（デフラグ対象に設定された時刻）が付与される。

［ステップＳ４０］重複判定部１３１は、ステップＳ３２で特定された全レコードに対応するチャンク（すなわち、削除が要求されたファイルから生成されたすべてのチャンク）について処理済みかを判定する。重複判定部１３１は、未処理のチャンクがある場合は処理をステップＳ３２に進め、未処理のチャンクを１つ選択して処理を継続する。一方、重複判定部１３１は、すべてのチャンクを処理済みの場合、ファイル削除が完了したことをファイル入出力部１２０に通知する。通知を受けたファイル入出力部１２０は、ＮＡＳクライアント２１０に対してファイル削除の完了を示す応答情報を送信する。

図２１、図２２は、デフラグ処理の手順を示すフローチャートの例である。
［ステップＳ５１］重複排除処理部１３０のデフラグ処理部１３３は、図２０のステップＳ３９の処理によってあるオブジェクトグループがデフラグ対象に設定されてから、一定時間経過するのを待つ。そして、デフラグ処理部１３３は、一定時間が経過すると、当該オブジェクトグループを処理対象として処理をステップＳ５２に進める。

実際の処理としては、例えば、デフラグ処理部１３３は、デフラグ対象に設定されたオブジェクトグループ（デフラグ判定テーブル１１６のレコード）に付与された時刻（デフラグ対象に設定された時刻）に基づき、その時刻から一定時間が経過したオブジェクトグループを検知すると、ステップＳ５２以降の処理を実行する。

ここで、オブジェクトグループがデフラグ対象に設定されてからデフラグをすぐに実行するのではなく、一定時間後に実行するのは、以下の理由による。ＮＡＳクライアント２１０でのバックアップ処理では、関連する複数のファイルが一括して削除されることが多い。このため、オブジェクトグループがデフラグ対象に設定されてから一定時間が経過する間に、同じオブジェクトグループにおいてさらに多くの無効チャンクが発生することが期待できる。オブジェクトグループについてのデフラグでは、無効チャンクが多いほどクラウドストレージ２４０の使用容量を効率的に削減できる。また、特にステップＳ５３以降の処理（２回目以降のデフラグ）では、無効チャンクが多いほど１つのオブジェクトに含まれる全チャンクが無効になる可能性が高くなり、そのようなオブジェクトのデフラグに伴う通信回数や通信量を削減できる。

［ステップＳ５２］デフラグ処理部１３３は、処理対象のオブジェクトグループについて、今回のデフラグが初回のデフラグであるかを判定する。デフラグ判定テーブル１１６のレコードのうち、処理対象のオブジェクトグループに対応するレコードにおいて、デフラグ済みフラグが「０」であれば初回のデフラグと判定され、「１」であれば２回目以降のデフラグと判定される。デフラグ処理部１３３は、初回のデフラグの場合、処理を図２２のステップＳ６１に進め、初回のデフラグでない場合、処理をステップＳ５３に進める。

以下、図２２を用いて説明を続ける。初回のデフラグの場合、ステップＳ６１以降の処理が実行される。
［ステップＳ６１］デフラグ処理部１３３は、処理対象のオブジェクトグループに属するすべてのオブジェクトを取得するように、クラウド通信部１４０に依頼する。クラウド通信部１４０は、ＧＥＴコマンドにより該当する全オブジェクトをクラウドストレージ２４０からダウンロードする。

［ステップＳ６２］デフラグ処理部１３３は、新規オブジェクトに結合されたチャンク数を示す変数Ｎ（チャンク数Ｎ）を、「０」にリセットする。これにより、１つの新規オブジェクトの生成（再構築）が開始される。

［ステップＳ６３］デフラグ処理部１３３は、ステップＳ６１で取得されたオブジェクトグループの各オブジェクトに含まれる有効チャンクの中に、未結合のチャンクがあるかを判定する。「未結合のチャンク」とは、当該有効チャンクのうち、現在生成中の新規オブジェクトと、すでに生成済みの（完成した）新規オブジェクトのどちらにも結合されていない有効チャンクを示す。デフラグ処理部１３３は、未結合のチャンクがある場合、処理をステップＳ６４に進め、未結合のチャンクがない場合、処理をステップＳ７０に進める。

［ステップＳ６４］デフラグ処理部１３３は、チャンク管理テーブル１１３に基づき、未結合の有効チャンクの中から、参照数が最大で、かつチャンク番号が最小の有効チャンクを検索する。この処理で検索されたチャンクについての参照数をＮとする。また、デフラグ処理部１３３は、チャンク数Ｎに「１」を加算する。

［ステップＳ６５］デフラグ処理部１３３は、ステップＳ６１で取得されたオブジェクトグループの各オブジェクトに含まれる有効チャンクの中から、次のような有効チャンクを特定する。ステップＳ６４の次に実行された場合、ステップＳ６４で検索された有効チャンクの次の有効チャンク（チャンク番号が次に大きい有効チャンク）が特定される。また、ステップＳ６６，Ｓ６７の次に実行された場合、ステップＳ６６でオブジェクトに結合された有効チャンクの次の有効チャンクが特定される。

デフラグ処理部１３３は、チャンク管理テーブル１１３の該当レコードに基づき、特定した有効チャンクの参照数が（２／３）Ｒ以上かを判定する。デフラグ処理部１３３は、参照数が（２／３）Ｒ以上である場合、処理をステップＳ６６に進め、参照数が（２／３）Ｒより小さい場合、処理をステップＳ６８に進める。なお、係数「２／３」は一例である。ステップＳ６５では、特定した有効チャンクの参照数がＲに近い値であるか否かが判定されればよい。

［ステップＳ６６］デフラグ処理部１３３は、ステップＳ６５で特定した有効チャンクを、現在生成中の新規オブジェクトに結合する。そして、デフラグ処理部１３３は、チャンク数Ｎに「１」を加算する。

［ステップＳ６７］デフラグ処理部１３３は、チャンク数Ｎが所定の閾値Ｍ＿Ｈより大きいかを判定する。この閾値Ｍ＿Ｈは、初回アップロードのためのオブジェクト生成に用いられる閾値Ｍ（図１９のステップＳ２４参照）より小さく、かつ、後述するステップＳ６８で用いられる閾値Ｍ＿Ｌより大きい。デフラグ処理部１３３は、チャンク数Ｎが閾値Ｍ＿Ｈより大きい場合、処理をステップＳ６９に進め、チャンク数Ｎが閾値Ｍ＿Ｈ以下である場合、処理をステップＳ６５に進める。

［ステップＳ６８］デフラグ処理部１３３は、チャンク数Ｎが所定の閾値Ｍ＿Ｌより大きいかを判定する。前述のように、閾値Ｍ＿Ｌは、ステップＳ６６で用いられる閾値Ｍ＿Ｈより小さい。デフラグ処理部１３３は、チャンク数Ｎが閾値Ｍ＿Ｌより大きい場合、処理をステップＳ６９に進め、チャンク数Ｎが閾値Ｍ＿Ｌ以下である場合、処理をステップＳ６３に進める。

ここで、処理がステップＳ６３に進められた場合、ステップＳ６３，Ｓ６４では、ステップＳ６１で取得されたオブジェクトグループの各オブジェクトに含まれる有効チャンクのうち、ステップＳ６５で特定された有効チャンクを先頭とした範囲の有効チャンクが処理対象となる。また、ステップＳ６５で特定したチャンクは現在生成中の新規オブジェクトには結合されずに、未結合のチャンクとして残る。

［ステップＳ６９］デフラグ処理部１３３は、現在生成中である、Ｎ個の有効チャンクを含む新規オブジェクトの生成を完了する。デフラグ処理部１３３は、生成された（完成された）新規オブジェクトに新規のオブジェクト番号を割り当て、このオブジェクト番号を指定して新規オブジェクトのアップロードをクラウド通信部１４０に依頼する。クラウド通信部１４０は、ＰＵＴコマンドによりこの新規オブジェクトをクラウドストレージ２４０にアップロードする（再アップロード）。

また、デフラグ処理部１３３は、生成された新規オブジェクトに対応するレコードをオブジェクト管理テーブル１１５に追加する。デフラグ処理部１３３はこのレコードに対し、オブジェクト番号を登録するとともに、有効チャンク数として新規オブジェクトに含まれるチャンク数を登録し、無効チャンク数として「０」を登録する。

さらに、デフラグ処理部１３３は、チャンク管理テーブル１１３のレコードのうち、生成された新規オブジェクトに含まれる各チャンクに対応するレコードについて、オブジェクト番号とオフセットを更新する。これにより、各チャンクのチャンク番号と新規オブジェクトとの対応関係がチャンク管理テーブル１１３に登録される。

ステップＳ６９が実行された後、処理はステップＳ６２に進められ、別の新規オブジェクトの生成が開始される。
［ステップＳ７０］デフラグ処理部１３３は、デフラグ判定テーブル１１６から、処理対象のオブジェクトグループに対応するレコードを特定する。デフラグ処理部１３３は、特定したレコードに登録された無効チャンク数から、ステップＳ６１でダウンロードしたオブジェクトに含まれていた無効チャンクの数を減算する。また、デフラグ処理部１３３は、特定したレコードのチャンク番号の項目から、これらの無効チャンクのチャンク番号を削除する。さらに、デフラグ処理部１３３は、ステップＳ６１でダウンロードした各オブジェクトの削除をクラウド通信部１４０に依頼し、オブジェクト管理テーブル１１５から、これらのオブジェクトに対応するレコードを削除する。以上の処理が完了すると、デフラグ処理が終了される。

以上のステップＳ６１～Ｓ７０に示したように、オブジェクトグループについての初回のデフラグでは、オブジェクトグループ内の全オブジェクトに含まれる有効チャンクが元のオブジェクトに関係なく組み替えられることで、新規オブジェクトが再構築される。

ここで、例えば、ステップＳ６５～Ｓ６７の処理が繰り返される場合、チャンク番号が近く、参照数も近い（（２／３）Ｒ以上Ｒ以下）有効チャンクが連続してオブジェクトに組み込まれる。このようなケースでは、閾値Ｍ＿Ｈにより比較的大きなサイズのオブジェクトが生成される。

一方、ステップＳ６５でＮｏと判定される場合、参照数の差が大きい有効チャンクが現れたことになる。この場合、異なるファイルや関連性の低いファイルの有効チャンクなど、性質の異なる有効チャンクが現れた可能性が高い。すなわち、ステップＳ６５でＮｏと判定されるケースでは、オブジェクトに組み込むかの判定対象となっている領域に、性質の異なる有効チャンクが存在している可能性が高い。このような領域の有効チャンクをオブジェクトに結合した場合、オブジェクト内で無効チャンクが分散した位置に異なるタイミングで発生しやすくなり、オブジェクトのサイズを大きくしてしまうとデフラグの効率が悪化する可能性が高い。そこで、ステップＳ６８で閾値Ｍ＿Ｈより小さい閾値Ｍ＿Ｌを用いることで、小さいサイズのオブジェクトが生成される。

また、ステップＳ６８でＹｅｓと判定されるケースでは、参照数のバラツキが大きい領域の有効チャンクがオブジェクトに組み込まれるので、それらの有効チャンクの参照数は傾向として比較的小さな値となる。そのため、閾値Ｍ＿Ｌを用いることで、参照数が比較的小さい有効チャンクを含むオブジェクトのサイズが小さくなることを期待できる。

以下、図２１を用いて説明を続ける。２回目以降のデフラグの場合、ステップＳ５３以降の処理が実行される。
［ステップＳ５３］デフラグ処理部１３３は、処理対象のオブジェクトグループに属するオブジェクトを１つ選択する。なお、処理対象のオブジェクトグループに属するオブジェクトは、このオブジェクトグループに対応するデフラグ判定テーブル１１６のレコードに登録されたチャンク番号と、チャンク管理テーブル１１３においてこのチャンク番号に対応付けられたオブジェクト番号とから特定される。

［ステップＳ５４］デフラグ処理部１３３は、オブジェクト管理テーブル１１５のレコードのうち、ステップＳ５３で選択したオブジェクトに対応するレコードを参照し、このレコードから有効チャンク数と無効チャンク数を取得する。デフラグ処理部１３３は、全チャンク数（有効チャンク数と無効チャンク数との合計値）に対する無効チャンク数の割合を算出し、無効チャンク数の割合が所定の閾値（例えば３０％）を超えたかを判定する。デフラグ処理部１３３は、無効チャンク数の割合が閾値を超えた場合、処理をステップＳ５５に進め、無効チャンク数の割合が閾値以下の場合、処理をステップＳ５９に進める。

［ステップＳ５５］デフラグ処理部１３３は、ステップＳ５３で選択したオブジェクトの取得をクラウド通信部１４０に依頼する。クラウド通信部１４０は、ＧＥＴコマンドによりオブジェクトをクラウドストレージ２４０からダウンロードする。

［ステップＳ５６］デフラグ処理部１３３は、ステップＳ５５で取得したオブジェクトに含まれるチャンクのうち有効チャンクのみを結合してオブジェクトを再構築する。
［ステップＳ５７］デフラグ処理部１３３は、オブジェクト管理テーブル１１５のレコードのうち、ステップＳ５５で取得したオブジェクトに対応するレコードに登録された無効チャンク数を「０」にリセットする。また、デフラグ処理部１３３は、デフラグ判定テーブル１１６から、当該オブジェクトが属するオブジェクトグループに対応するレコード（当該オブジェクトに含まれるチャンクのチャンク番号が登録されたレコード）を特定する。デフラグ処理部１３３は、特定したレコードのチャンク番号の項目から、オブジェクト再構築によって除外した無効チャンクのチャンク番号を削除し、特定したレコードに登録された無効チャンク数から、除外した無効チャンクの数を減算する。

［ステップＳ５８］デフラグ処理部１３３は、ステップＳ５６で再構築されたオブジェクトのアップロードをクラウド通信部１４０に依頼する。クラウド通信部１４０は、ＰＵＴコマンドによりオブジェクトをクラウドストレージ２４０にアップロードする。実際には、ステップＳ５５でダウンロードされた元のオブジェクトが削除された後、再構築されたオブジェクトがアップロードされる。

［ステップＳ５９］デフラグ処理部１３３は、処理対象のオブジェクトグループに属するすべてのオブジェクトについて処理済みかを判定する。デフラグ処理部１３３は、未処理のオブジェクトがある場合、処理をステップＳ５３に進めて未処理のオブジェクトの１つを選択する。一方、デフラグ処理部１３３は、すべてのオブジェクトについて処理済みの場合、デフラグ処理を終了する。

以上のステップＳ５３～Ｓ５９に示したように、オブジェクトグループについての２回目以降のデフラグでは、単一オブジェクト内の有効チャンクを結合してオブジェクト化するというオブジェクト単位のデフラグが実行される。

ところで、図２２に示した処理を、参照数が比較的小さいチャンクが結合された新規オブジェクトのサイズが、参照数が大きいチャンクが結合された新規オブジェクトと比較してより高確率で小さくなるように変形することもできる。例えば、図２２のステップＳ６７の判定処理を次の図２３のように変形することができる。

図２３は、デフラグ処理の変形例を示すフローチャートである。
［ステップＳ６７ａ］デフラグ処理部１３３は、現在の参照数Ｒが所定の閾値以上かを判定する。この閾値としては、２以上の整数が設定される。デフラグ処理部１３３は、参照数Ｒが閾値以上の場合、処理をステップＳ６７ｂに進め、参照数Ｒが閾値より小さい場合、処理をステップＳ６７ｃに進める。

［ステップＳ６７ｂ］デフラグ処理部１３３は、チャンク数Ｎが閾値Ｍ＿Ｈより大きいかを判定する。デフラグ処理部１３３は、チャンク数Ｎが閾値Ｍ＿Ｈより大きい場合、処理をステップＳ６９に進め、チャンク数Ｎが閾値Ｍ＿Ｈ以下である場合、処理をステップＳ６５に進める。

［ステップＳ６７ｃ］デフラグ処理部１３３は、チャンク数Ｎが閾値Ｍ＿Ｌより大きいかを判定する。デフラグ処理部１３３は、チャンク数Ｎが閾値Ｍ＿Ｌより大きい場合、処理をステップＳ６９に進め、チャンク数Ｎが閾値Ｍ＿Ｌ以下である場合、処理をステップＳ６５に進める。

このような処理により、参照数がステップＳ６７ａの閾値より小さいチャンクが結合された新規オブジェクトのサイズを、参照数がその閾値以上のチャンクが結合された新規オブジェクトのサイズと比較して、より高確率で小さくすることができる。なお、ステップＳ６７ｂ，Ｓ６７ｃで用いられる閾値はそれぞれ閾値Ｍ＿Ｈ，Ｍ＿Ｌとは別の値であってもよい。すなわち、ステップＳ６７ｂで用いられる閾値は閾値Ｍ（図１９のステップＳ２４参照）より小さければよく、ステップＳ６７ｃで用いられる閾値はステップＳ６７ｂで用いられる閾値より小さければよい。

なお、前述のように、第２の実施の形態では、所定個数のチャンクがオブジェクトに割り当てられると、そのオブジェクトが非アクティブ化される。しかし、他の方法として、例えば、オブジェクトに割り当てられたチャンクの合計サイズが所定サイズを超えた場合に、そのオブジェクトが非アクティブ化されてもよい。

この場合、図１９のステップＳ２４では、未送信のチャンクの合計サイズが所定サイズ（ＳＺとする）を超えたかが判定され、超えた場合にステップＳ２５の処理が実行され、超えていない場合にステップＳ２７の処理が実行される。また、図２２のステップＳ６７では、生成中のオブジェクトのサイズが所定サイズ（ＳＺ＿Ｈとする）より大きいかが判定され、大きい場合にステップＳ６９の処理が実行され、大きくない場合にステップＳ６５の処理が実行される。さらに、図２２のステップＳ６８では、生成中のオブジェクトのサイズが所定サイズ（ＳＺ＿Ｌとする）より大きいかが判定され、大きい場合にステップＳ６９の処理が実行され、大きくない場合にステップＳ６３の処理が実行される。ただし、ＳＺ＞ＳＺ＿Ｈ＞ＳＺ＿Ｌである。

また、図２３のステップＳ６７ｂでは、生成中のオブジェクトのサイズがＳＺ＿Ｈより大きいかが判定され、大きい場合にステップＳ６９の処理が実行され、大きくない場合にステップＳ６５の処理が実行される。また、図２３のステップＳ６７ｃでは、生成中のオブジェクトのサイズがＳＺ＿Ｌより大きいかが判定され、大きい場合にステップＳ６９の処理が実行され、大きくない場合にステップＳ６５の処理が実行される。

なお、上記の各実施の形態に示した装置（例えば、情報処理装置１０、クラウドストレージゲートウェイ１００）の処理機能は、コンピュータによって実現することができる。その場合、各装置が有すべき機能の処理内容を記述したプログラムが提供され、そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記憶装置には、ハードディスク装置（ＨＤＤ）、磁気テープなどがある。光ディスクには、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、ブルーレイディスク（Blu-ray Disc：ＢＤ、登録商標）などがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムまたはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムにしたがった処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムにしたがった処理を実行することもできる。また、コンピュータは、ネットワークを介して接続されたサーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムにしたがった処理を実行することもできる。

以上の各実施の形態に関し、さらに以下の付記を開示する。
（付記１） 書き込みが要求された複数の書き込みデータセットの重複を排除することで得られた複数のデータセットを、外部ストレージに格納する格納処理であって、前記複数のデータセットから出現順に選択された２以上のデータセットをオブジェクトにまとめて前記外部ストレージに格納する前記格納処理を実行し、
前記外部ストレージに格納された前記オブジェクトのうち２以上の前記オブジェクトを生成順にまとめたオブジェクトグループを単位としてデフラグの実行要否を判定し、
前記オブジェクトグループのうち一のオブジェクトグループのデフラグを実行すると判定すると、前記一のオブジェクトグループに含まれるすべての前記オブジェクトをそれぞれ第１のオブジェクトとして前記外部ストレージから取得し、前記第１のオブジェクトに含まれるデータセットのうち参照数が１以上である有効データセットを、前記有効データセットの生成順と参照数とに基づいて組み合わせて１以上の第２のオブジェクトを生成し直し、前記第２のオブジェクトを前記第１のオブジェクトの代わりに前記外部ストレージに格納する第１のデフラグ処理を実行する、処理部、
を有する情報処理装置。

（付記２） 前記第１のデフラグ処理では、前記有効データセットの中から前記生成順が近く、かつ前記参照数が近いと判定されるデータセットを、同一の前記第２のオブジェクトに組み込む、
付記１記載の情報処理装置。

（付記３） 前記第１のデフラグ処理では、組み込まれた前記有効データセットの前記参照数と所定の基準値との比較結果に基づいて、前記第２のオブジェクトのサイズを可変する、
付記２記載の情報処理装置。

（付記４） 前記第１のデフラグ処理では、組み込まれた前記有効データセットの前記参照数が所定の基準値に基づいて小さいと判定される前記第２のオブジェクトのサイズを、組み込まれた前記有効データセットの前記参照数が前記基準値に基づいて大きいと判定される前記第２のオブジェクトのサイズより小さくする、
付記２記載の情報処理装置。

（付記５） 前記処理部は、
前記外部ストレージに格納された前記第２のオブジェクトについてのデフラグの実行要否を、前記第２のオブジェクトごとに個別に判定し、
前記第２のオブジェクトのうち一のオブジェクトのデフラグを実行すると判定すると、前記一のオブジェクトを前記外部ストレージから取得し、前記一のオブジェクトに含まれるデータセットのうち前記参照数が１以上のデータセットだけをまとめて第３のオブジェクトを生成し直し、前記第３のオブジェクトを前記一のオブジェクトの代わりに前記外部ストレージに格納する第２のデフラグ処理を実行する、
付記１乃至４のいずれか１つに記載の情報処理装置。

（付記６） 前記オブジェクトグループを単位とした実行要否の判定では、それぞれの前記オブジェクトグループに含まれるデータセットのうち前記参照数が０のデータセットの数に基づいて実行要否を判定し、
前記処理部は、前記一のオブジェクトグループのデフラグを実行すると判定してから所定時間が経過した後に、前記第１のデフラグ処理の実行を開始する、
付記１乃至５のいずれか１つに記載の情報処理装置。

（付記７） コンピュータに、
書き込みが要求された複数の書き込みデータセットの重複を排除することで得られた複数のデータセットを、外部ストレージに格納する格納処理であって、前記複数のデータセットから出現順に選択された２以上のデータセットをオブジェクトにまとめて前記外部ストレージに格納する前記格納処理を実行し、
前記外部ストレージに格納された前記オブジェクトのうち２以上の前記オブジェクトを生成順にまとめたオブジェクトグループを単位としてデフラグの実行要否を判定し、
前記オブジェクトグループのうち一のオブジェクトグループのデフラグを実行すると判定すると、前記一のオブジェクトグループに含まれるすべての前記オブジェクトをそれぞれ第１のオブジェクトとして前記外部ストレージから取得し、前記第１のオブジェクトに含まれるデータセットのうち参照数が１以上である有効データセットを、前記有効データセットの生成順と参照数とに基づいて組み合わせて１以上の第２のオブジェクトを生成し直し、前記第２のオブジェクトを前記第１のオブジェクトの代わりに前記外部ストレージに格納する第１のデフラグ処理を実行する、
処理を実行させる情報処理プログラム。

（付記８） 前記第１のデフラグ処理では、前記有効データセットの中から前記生成順が近く、かつ前記参照数が近いと判定されるデータセットを、同一の前記第２のオブジェクトに組み込む、
付記７記載の情報処理プログラム。

（付記９） 前記第１のデフラグ処理では、組み込まれた前記有効データセットの前記参照数と所定の基準値との比較結果に基づいて、前記第２のオブジェクトのサイズを可変する、
付記８記載の情報処理プログラム。

（付記１０） 前記第１のデフラグ処理では、組み込まれた前記有効データセットの前記参照数が所定の基準値に基づいて小さいと判定される前記第２のオブジェクトのサイズを、組み込まれた前記有効データセットの前記参照数が前記基準値に基づいて大きいと判定される前記第２のオブジェクトのサイズより小さくする、
付記８記載の情報処理プログラム。

（付記１１） 前記処理部は、
前記外部ストレージに格納された前記第２のオブジェクトについてのデフラグの実行要否を、前記第２のオブジェクトごとに個別に判定し、
前記第２のオブジェクトのうち一のオブジェクトのデフラグを実行すると判定すると、前記一のオブジェクトを前記外部ストレージから取得し、前記一のオブジェクトに含まれるデータセットのうち前記参照数が１以上のデータセットだけをまとめて第３のオブジェクトを生成し直し、前記第３のオブジェクトを前記一のオブジェクトの代わりに前記外部ストレージに格納する第２のデフラグ処理を実行する、
付記７乃至１０のいずれか１つに記載の情報処理プログラム。

（付記１２） 前記オブジェクトグループを単位とした実行要否の判定では、それぞれの前記オブジェクトグループに含まれるデータセットのうち前記参照数が０のデータセットの数に基づいて実行要否を判定し、
前記第１のデフラグ処理の実行は、前記一のオブジェクトグループのデフラグを実行すると判定してから所定時間が経過した後に開始される、
付記７乃至１１のいずれか１つに記載の情報処理プログラム。

１０ 情報処理装置
１１ 処理部
２０ 外部ストレージ
ＧＰ１，ＧＰ２ オブジェクトグループ
ＯＢ１～ＯＢ６，ＯＢ１１，ＯＢ１２ オブジェクト

Claims (7)

1. 書き込みが要求された複数の書き込みデータセットの重複を排除することで得られた複数のデータセットを、外部ストレージに格納する格納処理であって、前記複数のデータセットから出現順に選択された２以上のデータセットをオブジェクトにまとめて前記外部ストレージに格納する前記格納処理を実行し、
   前記外部ストレージに格納された前記オブジェクトのうち２以上の前記オブジェクトを生成順にまとめたオブジェクトグループを単位としてデフラグの実行要否を判定し、
   前記オブジェクトグループのうち一のオブジェクトグループのデフラグを実行すると判定すると、前記一のオブジェクトグループに含まれるすべての前記オブジェクトをそれぞれ第１のオブジェクトとして前記外部ストレージから取得し、前記第１のオブジェクトに含まれるデータセットのうち参照数が１以上である有効データセットを、前記有効データセットの生成順と参照数とに基づいて組み合わせて１以上の第２のオブジェクトを生成し直し、前記第２のオブジェクトを前記第１のオブジェクトの代わりに前記外部ストレージに格納する第１のデフラグ処理を実行する、処理部、
   を有する情報処理装置。
2. 前記第１のデフラグ処理では、前記有効データセットの中から前記生成順が近く、かつ前記参照数が近いと判定されるデータセットを、同一の前記第２のオブジェクトに組み込む、
   請求項１記載の情報処理装置。
3. 前記第１のデフラグ処理では、組み込まれた前記有効データセットの前記参照数と所定の基準値との比較結果に基づいて、前記第２のオブジェクトのサイズを可変する、
   請求項２記載の情報処理装置。
4. 前記第１のデフラグ処理では、組み込まれた前記有効データセットの前記参照数が所定の基準値に基づいて小さいと判定される前記第２のオブジェクトのサイズを、組み込まれた前記有効データセットの前記参照数が前記基準値に基づいて大きいと判定される前記第２のオブジェクトのサイズより小さくする、
   請求項２記載の情報処理装置。
5. 前記処理部は、
   前記外部ストレージに格納された前記第２のオブジェクトについてのデフラグの実行要否を、前記第２のオブジェクトごとに個別に判定し、
   前記第２のオブジェクトのうち一のオブジェクトのデフラグを実行すると判定すると、前記一のオブジェクトを前記外部ストレージから取得し、前記一のオブジェクトに含まれるデータセットのうち前記参照数が１以上のデータセットだけをまとめて第３のオブジェクトを生成し直し、前記第３のオブジェクトを前記一のオブジェクトの代わりに前記外部ストレージに格納する第２のデフラグ処理を実行する、
   請求項１乃至４のいずれか１項に記載の情報処理装置。
6. 前記オブジェクトグループを単位とした実行要否の判定では、それぞれの前記オブジェクトグループに含まれるデータセットのうち前記参照数が０のデータセットの数に基づいて実行要否を判定し、
   前記処理部は、前記一のオブジェクトグループのデフラグを実行すると判定してから所定時間が経過した後に、前記第１のデフラグ処理の実行を開始する、
   請求項１乃至５のいずれか１項に記載の情報処理装置。
7. コンピュータに、
   書き込みが要求された複数の書き込みデータセットの重複を排除することで得られた複数のデータセットを、外部ストレージに格納する格納処理であって、前記複数のデータセットから出現順に選択された２以上のデータセットをオブジェクトにまとめて前記外部ストレージに格納する前記格納処理を実行し、
   前記外部ストレージに格納された前記オブジェクトのうち２以上の前記オブジェクトを生成順にまとめたオブジェクトグループを単位としてデフラグの実行要否を判定し、
   前記オブジェクトグループのうち一のオブジェクトグループのデフラグを実行すると判定すると、前記一のオブジェクトグループに含まれるすべての前記オブジェクトをそれぞれ第１のオブジェクトとして前記外部ストレージから取得し、前記第１のオブジェクトに含まれるデータセットのうち参照数が１以上である有効データセットを、前記有効データセットの生成順と参照数とに基づいて組み合わせて１以上の第２のオブジェクトを生成し直し、前記第２のオブジェクトを前記第１のオブジェクトの代わりに前記外部ストレージに格納する第１のデフラグ処理を実行する、
   処理を実行させる情報処理プログラム。

Images