JP2022074654A - 情報処理装置、情報処理方法および情報処理プログラム - Google Patents

Abstract

【課題】外部ストレージとの通信回数が減少する可能性を高める。
【解決手段】処理部１１は、重複が排除された複数のデータセットを外部ストレージ２０に格納する際、２以上のデータセットをオブジェクトＯＢ１，ＯＢ２，・・・にまとめて格納する。処理部１１は、オブジェクトＯＢ１，ＯＢ２，・・・のうちオブジェクトＯＢ１１～ＯＢ１３の再構築処理を実行する際、オブジェクトＯＢ１１～ＯＢ１３に含まれる有効データセットのうち参照数が所定数以下のデータセットを、複数のファイルのうち同じファイルから参照されるデータセットごとにまとめてオブジェクトＯＢ２３，ＯＢ２４を生成し直し、オブジェクトＯＢ２３，ＯＢ２４を外部ストレージ２０に格納する。
【選択図】図１

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）ディスプレイなどがある。

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

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

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

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

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

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

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

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

チャンクグループ管理テーブル１１５は、チャンクグループごとに、チャンクグループに関連するファイルを管理するための管理情報である。チャンクグループとは、１または複数のオブジェクトに属するチャンクの集合である。チャンクグループ管理テーブル１１５により、チャンクグループに対応するオブジェクトに含まれるチャンクを参照するファイルが管理される。後述するように、チャンクグループ管理テーブル１１５は、オブジェクトを再構築する際に利用される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図８は、チャンクグループ管理テーブルの構成例を示す図である。チャンクグループ管理テーブル１１５は、チャンクグループと関連するファイルとの対応関係を管理するための管理情報である。図８に示すように、チャンクグループ管理テーブル１１５はチャンクグループ番号ごとのレコードを含み、各レコードには、チャンクグループ番号、チャンク番号およびファイル番号が登録される。チャンクグループ番号は、チャンクグループの識別番号を示す。チャンク番号は、チャンクグループに含まれるチャンクのチャンク番号を示す。ファイル番号は、チャンクグループに含まれるチャンクを参照するファイルのファイル番号を示す。

前述のように、チャンクグループは、１または複数のオブジェクトに属するチャンクの集合である。このため、チャンクグループは、１以上のオブジェクトを含む「オブジェクトグループ」を示すということもできる。本実施の形態では基本的に、オブジェクトは一定数（Ｍ個とする）のチャンクによって形成される。また、基本的にチャンクグループは、一定数（Ｎ個とする）のオブジェクトによって形成される。このため、通常、各チャンクグループには（Ｍ×Ｎ）個のチャンクが含まれる。

図７に示したように、オブジェクトに対してはチャンクが出現順に割り当てられる。また、チャンクグループに対してもチャンクが出現順に割り当てられる。したがって、図８に示すように、各チャンクグループには基本的に連続するチャンク番号を有するチャンクが含まれる。チャンクの出現に応じて、チャンクグループに対してチャンクが出現順に割り当てられ、そのチャンクグループに（Ｍ×Ｎ）個のチャンクが割り当てられると、次のチャンクは次のチャンクグループに割り当てられる。

このように、基本的に各チャンクグループには一定数のチャンクが出現順に割り当てられるので、チャンクグループ管理テーブル１１５には、各チャンクグループに対応するレコードがあらかじめ生成されていればよい。各レコードが生成された初期状態では、チャンクグループ番号と、チャンクグループに含まれるチャンクのチャンク番号とが各レコードに登録される。

ここで、オブジェクトの再構築は、チャンクグループ単位（オブジェクトグループ単位）で実行される。これは後述するように、複数のオブジェクトに含まれるチャンクの参照数や関連するファイルなどを考慮して、オブジェクトの再アップロードや再ダウンロードの回数が減少するような適切なオブジェクトを再構築できるようにするためである。チャンクグループ管理テーブル１１５は、オブジェクトを再構築する際に、オブジェクトに含まれるチャンクを参照するファイルを特定するために参照される。

なお、オブジェクトの再構築が行われると、１つのチャンクグループに対して再構築された１つのオブジェクトが割り当てられる。したがって、１回でも再構築されたオブジェクトは、その後にはオブジェクトグループ単位ではなく、オブジェクト単位で再構築が行われることになる。また、オブジェクトが再構築されると、チャンクグループ管理テーブル１１５にはそのオブジェクトに対応するオブジェクトグループのレコードが追加されていく。

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

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

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

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

ここで、オブジェクト再構築処理についての２つの比較例を説明し、その後に第２の実施の形態におけるオブジェクト再構築処理について説明する。
まず、図９～図１３を用いて、オブジェクト再構築処理の第１の比較例について説明する。

図９は、オブジェクト再構築処理の第１の比較例を示す図（その１）である。図９の例では、ＮＡＳクライアント２１０からクラウドストレージゲートウェイ１００に対して、ファイルｆ２１～ｆ２４の書き込みが順に要求されたとする。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次に、図１４、図１５を用いて、オブジェクト再構築処理の第２の比較例について説明する。第２の比較例では、各オブジェクトについての１回目の再構築処理が、個々のオブジェクト単位でなく、複数のオブジェクトを含むオブジェクトグループ単位で実行される。オブジェクトグループとは、前述したチャンクグループに含まれるオブジェクトである。このような方法により、単に同じオブジェクト内の有効チャンク同士を結合するのではなく、次回以降のオブジェクト再構築の発生回数やオブジェクト再構築時の通信回数が減るように、オブジェクト間で有効チャンクの組み替えを行うことができるようになる。第２の比較例では、オブジェクトグループ内の有効チャンクのうち、参照数が近い有効チャンク同士が１つのオブジェクトとして再構築される。

図１４は、オブジェクト再構築処理の第２の比較例を示す図（その１）である。図１４では、図９の手順で生成されたオブジェクトｏｂ２１～ｏｂ２３が、１つのオブジェクトグループを形成しているものとする。そして、この状態から、ファイルｆ２１が削除されたことを契機として、このオブジェクトグループについてのオブジェクト再構築が実行されるものとする。

この場合、オブジェクトグループに含まれるオブジェクトｏｂ２１～ｏｂ２３が、ＧＥＴコマンドによりクラウドストレージゲートウェイ１００に取得される。そして、参照数が「０」となったチャンクＢ，Ｄを除く残りのチャンクを用いて、オブジェクトが再構築される。このとき、チャンクＡ，Ｅの参照数は「３」であり、チャンクＧ，Ｈの参照数は「２」であり、チャンクＣ，Ｆ，Ｉの参照数は「１」である。このことから、チャンクＡ，Ｅを含むオブジェクトｏｂ３１と、チャンクＧ，Ｈを含むオブジェクトｏｂ３２と、チャンクＣ，Ｆ，Ｉを含むオブジェクトｏｂ３３とが新たに生成され、ＰＵＴコマンドによってクラウドストレージ２４０にアップロードされる。

このように、参照数が近い（この例では同一）チャンクをオブジェクトにまとめることで、そのオブジェクト内の各チャンクの参照数が均等に減少していく可能性が高くなる。その結果、オブジェクト内の分散した位置で無効チャンクが長時間をかけて徐々に発生する可能性が低くなり、逆に、同一オブジェクト内で多くの無効チャンクが一度に発生しやすくなる。したがって、このオブジェクトについてさらに再構築が必要と判定されたときに、一度に多数の無効のチャンクを削除できる可能性が高まる。そのため、同じオブジェクトについてのオブジェクト再構築の実行回数が減少する可能性が高くなり、結果として、クラウドストレージゲートウェイ１００とクラウドストレージ２４０との間の通信回数が減少する可能性が高くなる。また、通信回数の減少により、クラウドストレージゲートウェイ１００とクラウドストレージ２４０との間の通信量も削減される。

なお、実際には、参照数が近いだけでなくチャンク番号も近いチャンクが同一オブジェクトにまとめられることが望ましい。チャンク番号が近いチャンクは同じファイルから切り出された可能性が高く、ファイル削除に伴ってこれらが同時に無効になる可能性が高くなる。したがって、通信回数や通信量の削減効果を高めることができる。

図１４の例では、前述の第１の比較例と比較して、オブジェクトｏｂ３１，ｏｂ３２，ｏｂ３３のそれぞれについて、同一オブジェクト内のチャンクが同時に無効になる可能性が高くなる。同一オブジェクト内のチャンクが同時に無効になれば、単にそのオブジェクトを削除すればよくなり、そのオブジェクトを再ダウンロードしたり、オブジェクトを再構築して再アップロードする必要がなくなる。その結果、通信回数や通信量を削減できる。

ところが、例えば、図１４に示すオブジェクトｏｂ３３に含まれるすべてのチャンクが無効になるには、ファイルｆ２２とファイルｆ２４の両方が削除されなければならない。このため、ファイルｆ２２，ｆ２４の一方のみが削除された時点では、オブジェクトｏｂ３３内に有効なチャンクが残ってしまい、他方のファイルが削除されるまでの間に再構築のためにオブジェクトｏｂ３３が再ダウンロードされる可能性が残ってしまう。

図１５は、オブジェクト再構築処理の第２の比較例を示す図（その２）である。図１５では、図１４の状態からファイルｆ２２が削除されたものとする。この場合、オブジェクトｏｂ３３に含まれるチャンクＣ，Ｆの参照数は「０」になるが、チャンクＩは有効なままである。このため、オブジェクトｏｂ３３が再構築の対象になる可能性が残る。オブジェクトｏｂ３３が再構築される場合、図１５に示すように、ＧＥＴコマンドによりオブジェクトｏｂ３３がクラウドストレージゲートウェイ１００に取得される。そして、オブジェクトｏｂ３３に含まれる有効なチャンクＩによってオブジェクトｏｂ４１が再構築され、ＰＵＴコマンドによりクラウドストレージ２４０に再アップロードされる。

このように、参照数が近いチャンクによりオブジェクトを再構築するだけでは、オブジェクトグループに含まれるオブジェクトについての２回目の再構築が発生する可能性を十分抑制できておらず、その分だけ通信回数や通信量の削減効果が低いという課題がある。

以下、図１６、図１７を用いて、第２の実施の形態におけるオブジェクト再構築処理について説明する。本実施の形態では、オブジェクトグループ単位でのオブジェクト再構築の際に、参照数が一定数を超えるチャンクについては、第２の比較例と同様、参照数が近いチャンクをまとめてオブジェクトが再構築される。好ましくは、参照数が近く、かつ、チャンク番号が近いチャンクをまとめてオブジェクトが再構築される。一方、参照数が一定数以下のチャンクについては、このような条件に加えて、同じファイルから参照されるチャンクをまとめてオブジェクトが再構築される。

以下の説明では、例として、チャンク番号が近く、かつ、参照数が同じチャンクをまとめてオブジェクトが再構築されるものとする。そして、参照数が「１」のチャンクについてのみ、さらに参照元ファイルを考慮したオブジェクト再構築が行われるものとする。

図１６は、第２の実施の形態におけるオブジェクト再構築処理例を示す図（その１）である。図１６では例として、図１４と同様に、ファイルｆ２１が削除されたことを契機として、オブジェクトｏｂ２１～ｏｂ２３を含むオブジェクトグループについてオブジェクト再構築が実行されるものとする。

この場合、クラウドストレージゲートウェイ１００は、オブジェクトグループに含まれるオブジェクトｏｂ２１～ｏｂ２３のすべてを、ＧＥＴコマンドによりクラウドストレージ２４０から取得する。そして、クラウドストレージゲートウェイ１００は、参照数が「０」となったチャンクＢ，Ｄを除く残りのチャンクを用いて、オブジェクト再構築を実行する。

クラウドストレージゲートウェイ１００は、参照数が「３」であるチャンクＡ，Ｅをまとめてオブジェクトｏｂ３１を生成する。また、クラウドストレージゲートウェイ１００は、参照数が「２」であるチャンクＧ，Ｈをまとめてオブジェクトｏｂ３２を生成する。しかし、参照数が「１」であるチャンクＣ，Ｆ，Ｉについては、さらに参照元ファイルを考慮した処理が実行される。

チャンクＣ，Ｆはファイルｆ２２から参照されており、チャンクＩはファイルｆ２４から参照されている。そこで、クラウドストレージゲートウェイ１００は、チャンクＣ，Ｆをまとめてオブジェクトｏｂ３３を生成し、チャンクＩのみによってオブジェクトｏｂ３４を生成する。

クラウドストレージゲートウェイ１００は、このように再構築されたオブジェクトｏｂ３１～ｏｂ３４を、ＰＵＴコマンドによりクラウドストレージ２４０に再アップロードする。なお、元のオブジェクトｏｂ２１～ｏｂ２３は、ＤＥＬＥＴＥコマンドにより削除される。

図１７は、第２の実施の形態におけるオブジェクト再構築処理例を示す図（その２）である。図１７では、図１６のように再構築されたオブジェクトｏｂ３１～ｏｂ３４がアップロードされた状態から、ファイルｆ２２が削除されたとする。

クラウドストレージゲートウェイ１００は、再構築されたオブジェクトｏｂ３１～ｏｂ３４については、それぞれ個別のチャンクグループ（オブジェクトグループ）に属するものとして管理する。すなわち、オブジェクトｏｂ３１～ｏｂ３４については、オブジェクト再構築の実行要否がオブジェクトごとに個別に判定され、オブジェクト再構築も個別に実行される。

ファイルｆ２２が削除されると、チャンクＡ，Ｅの参照数は「２」に減少し、チャンクＣ，Ｆの参照数は「０」に減少する。オブジェクトｏｂ３３に含まれるすべてのチャンクＣ，Ｆが無効チャンクになることから、クラウドストレージゲートウェイ１００は、ＤＥＬＥＴＥコマンドによりオブジェクトｏｂ３３を削除する。

このように、ファイルｆ２２の削除に伴って無効化されたチャンクＣ，Ｆの分だけクラウドストレージ２４０の使用容量を削減する際、図１５に示した第２の比較例では、チャンクＣ，Ｆを含むオブジェクトｏｂ３３のダウンロードと新たなオブジェクトｏｂ４１の再アップロードが必要であった。これに対して、図１７の例では、オブジェクトのダウンロードやアップロードを行うことなく、１つのオブジェクトｏｂ３３を削除するだけでクラウドストレージ２４０の使用容量を削減できる。したがって、クラウドストレージゲートウェイ１００とクラウドストレージ２４０との間の通信回数や通信量を削減できる。

ここで、参照数やチャンク番号に加えて参照元ファイルも考慮してオブジェクトが再構築されると、再構築後のオブジェクト数が増加し得る。例えば、参照数が多いチャンクについても参照元ファイルごとにオブジェクトが生成されると、再構築後のオブジェクト数が膨大になり、それらをクラウドストレージ２４０にアップロードするための通信回数（コマンド発行数）が増大してしまう。また、その後にこれらのオブジェクトの再構築が実行される際にも通信回数が増加してしまう。

一方、参照数が少ないチャンクをまとめて生成されたオブジェクトは、その後のより早い段階でオブジェクト内の各チャンクの参照数が「０」になりやすく、オブジェクト単位で削除される可能性が高くなる。このため、このような特性を有する、参照数が少ないチャンクについてのみ、ファイルごとにオブジェクトが生成されることで、全体としてクラウドストレージゲートウェイ１００とクラウドストレージ２４０との間の通信回数や通信量が削減される可能性を高めることができる。

ところで、本実施の形態において、クラウドストレージゲートウェイ１００は、図１６のようにオブジェクトグループ（チャンクグループ）に属する複数のオブジェクトの再構築を実行する際、各オブジェクト内のチャンクを参照するファイルを認識する必要がある。オブジェクトとチャンク、およびチャンクとファイルとの対応関係は、例えば、それぞれチャンク管理テーブル１１３、チャンクマップテーブル１１２から認識することが可能である。この場合、オブジェクトに含まれるチャンクのチャンク番号がチャンク管理テーブル１１３から特定され、特定されたチャンク番号ごとにチャンクマップテーブル１１２がスキャンされることで、チャンク番号に対応するファイルが特定される。しかし、この場合には、オブジェクトグループに含まれる多数のチャンクのチャンク番号ごとにチャンクマップテーブル１１２がスキャンされる（すなわち、各チャンク番号をキーとしてレコードが検索される）ので、処理負荷が増大するという問題がある。

これに対して、本実施の形態では、オブジェクトグループ（チャンクグループ）と、そのオブジェクトグループ内の各オブジェクトに含まれるチャンクを参照するファイルとの対応関係が、チャンクグループ管理テーブル１１５によって管理される。そして、オブジェクトグループについてのオブジェクト再構築を実行する際、クラウドストレージゲートウェイ１００は、チャンクグループ管理テーブル１１５を参照することで、そのオブジェクトグループに関連するファイル番号を容易に特定できる。

これにより、クラウドストレージゲートウェイ１００は、オブジェクトグループに関連するファイル番号ごとにチャンクマップテーブル１１２をスキャンすることで、オブジェクトグループに含まれる各チャンク番号に対応するファイルを特定できる。オブジェクトグループに関連するファイル数は、オブジェクトグループに関連するチャンク数より少ない。このため、ファイル番号ごとにチャンクマップテーブル１１２をスキャンすることで、スキャンの実行回数（キーを用いた検索回数）を低減でき、各チャンクとファイルとの対応関係を認識するための処理負荷を軽減できる。

図１８、図１９は、オブジェクト再構築時における管理情報の利用方法を示す図である。図１８、図１９では、図１６に示したように、ファイルｆ２１が削除された後、オブジェクトｏｂ２１～ｏｂ２３を含むオブジェクトグループについて、オブジェクト再構築が実行される場合について例示する。なお、オブジェクトｏｂ２１～ｏｂ２３を含むオブジェクトグループに対応するチャンクグループのチャンクグループ番号を「ｃｇ１１」とし、このチャンクグループを「チャンクグループｃｇ１１」と表す。

図１８に示すように、チャンクグループ管理テーブル１１５には、チャンクグループｃｇ１１に対応するレコードに、チャンク番号「Ａ」～「Ｉ」（チャンクＡ～Ｉ）と、ファイル番号「ｆ２１」～「ｆ２４」（ファイルｆ２１～ｆ２４）が登録されている。ファイルｆ２１が削除されると、このレコードからファイルｆ２１が削除される。

クラウドストレージゲートウェイ１００は、この状態からチャンクグループｃｇ１１についてのオブジェクト再構築を実行する際には、チャンクグループ管理テーブル１１５を参照する。そして、クラウドストレージゲートウェイ１００は、チャンクグループｃｇ１１に対応するレコードから、チャンクグループｃｇ１１に関連するファイルのファイル番号として「ｆ２２」～「ｆ２４」を抽出する。

次に、クラウドストレージゲートウェイ１００は、オブジェクト再構築のために一時的に参照される管理情報として、チャンク使用管理テーブル１１７を作成する。作成されたチャンク使用管理テーブル１１７は、例えばＲＡＭ１０２に一時的に記憶される。図１８に示すように、チャンク使用管理テーブル１１７には、チャンクグループ（オブジェクトグループ）に含まれる各チャンクについて、チャンク番号、参照数、チャンクを参照するファイルのファイル番号が登録される。

クラウドストレージゲートウェイ１００は、チャンクグループ管理テーブル１１５から抽出されたファイル番号ごとにチャンクマップテーブル１１２をスキャンして、各ファイル番号が示すファイルが参照しているチャンクを特定する。そして、クラウドストレージゲートウェイ１００は、このスキャンの結果を用いてチャンク使用管理テーブル１１７を作成する。このように、チャンクグループに含まれるチャンクごとではなく、チャンクグループに関連するファイルごとにチャンクマップテーブル１１２がスキャンされることで、スキャン回数が低減される。これにより、チャンク使用管理テーブル１１７を作成するための処理負荷が軽減され、その結果として、オブジェクト再構築の処理負荷が軽減される。

また、クラウドストレージゲートウェイ１００は、スキャンによって各チャンクとファイルとの対応関係を認識した際に、各チャンクについての参照数をカウントしてチャンク使用管理テーブル１１７に登録する。ここで、チャンクの参照数については、例えば、ファイルの書き込みや更新の際にカウントされたカウント値をチャンク管理テーブル１１３で管理しておく方法も考えられる。しかし、本実施の形態では上記のように、オブジェクト再構築の際に必要なチャンクの参照数を容易にカウントできることから、チャンクの参照数をチャンク管理テーブル１１３などによってあらかじめ管理しておく必要がなくなる。

クラウドストレージゲートウェイ１００は、図１８のように作成されたチャンク使用管理テーブル１１７を参照することで、チャンクグループ（オブジェクトグループ）に含まれるチャンクの中から、参照数が同じチャンクを特定できる。図１８の例では、参照数が「３」のチャンクとしてチャンクＡ，Ｅが特定され、参照数が「２」のチャンクとしてチャンクＧ，Ｈが特定される。また、参照数が「１」であるチャンクＣ，Ｆ，Ｉについては、チャンク使用管理テーブル１１７から、さらに同じファイルから参照されているチャンクが特定される。図１８の例では、チャンクＣ，Ｆがファイルｆ２２から参照されており、チャンクＩがファイルｆ２４から参照されていることが特定される。

このような処理の結果、図１９に示すように、クラウドストレージゲートウェイ１００は、チャンクＡ，Ｅを含むオブジェクトｏｂ３１と、チャンクＧ，Ｈを含むオブジェクトｏｂ３２と、チャンクＣ，Ｆを含むオブジェクトｏｂ３３と、チャンクＩを含むオブジェクトｏｂ３４を新たに生成する。クラウドストレージゲートウェイ１００は、これらのオブジェクトｏｂ３１～ｏｂ３４をクラウドストレージ２４０にアップロードする。これとともに、クラウドストレージゲートウェイ１００は、チャンクグループｃｇ１１に対応する元のオブジェクトｏｂ２１～ｏｂ２３をクラウドストレージ２４０から削除する。

また、クラウドストレージゲートウェイ１００は、このような新オブジェクトの生成・アップロードと旧オブジェクトの削除に伴って、チャンクグループ管理テーブル１１５を更新する。図１９に示すように、オブジェクトｏｂ３１が属するチャンクグループｃｇ１０１と、オブジェクトｏｂ３２が属するチャンクグループｃｇ１０２と、オブジェクトｏｂ３３が属するチャンクグループｃｇ１０３と、オブジェクトｏｂ３４が属するチャンクグループｃｇ１０４とが新規に生成される。そして、これらのチャンクグループｃｇ１０１～ｃｇ１０４にそれぞれ対応するレコードがチャンクグループ管理テーブル１１５に追加される。また、元のチャンクグループｃｇ１１に対応するレコードはチャンクグループ管理テーブル１１５から削除される。

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

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

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

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

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

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

［ステップＳ１６］チャンク管理部１３２は、チャンクグループ管理テーブル１１５のレコードのうち、該当するチャンクグループに対応するレコードに対して、書き込みが要求されたファイルのファイル番号を追加する。この「該当するチャンクグループ」とは、ステップＳ１４でハッシュキーテーブル１１４に存在したチャンクが属するチャンクグループである。なお、同じファイル番号が上記レコードにすでに登録されている場合、ステップＳ１６の処理はスキップされる。

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

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

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

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

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

［ステップＳ２５］チャンク管理部１３２は、チャンクグループ管理テーブル１１５のレコードのうち、該当するチャンクグループに対応するレコードに対して、書き込みが要求されたファイルのファイル番号を追加する。この「該当するチャンクグループ」とは、ステップＳ２１で算出されたチャンク番号が示すチャンクが属するチャンクグループである。なお、同じファイル番号が上記レコードにすでに登録されている場合、ステップＳ２５の処理はスキップされる。

［ステップＳ２６］チャンク管理部１３２は、ステップＳ２４での割り当て先のオブジェクトに含まれるチャンク数が、所定の閾値Ｍに達したかを判定する。閾値Ｍは、例えば１００００個程度に設定される。チャンク管理部１３２は、オブジェクト内のチャンク数が閾値Ｍに達した場合、処理をステップＳ２７に処理を進め、オブジェクト内のチャンク数が閾値Ｍに達していない場合、処理を図２０のステップＳ１７に進める。

［ステップＳ２７］チャンク管理部１３２は、ステップＳ２４でのチャンクの割り当て先のオブジェクトをクラウドストレージ２４０にアップロードするように、クラウド通信部１４０に依頼する。これにより、当該オブジェクトは非アクティブの状態となる。クラウド通信部１４０は、ＰＵＴコマンドによりオブジェクトをクラウドストレージ２４０にアップロードする。なお、オブジェクトのアップロードは、この後の非同期のタイミングで実行されてもよい。

また、アップロードが依頼されたオブジェクトは、この時点ではデータキャッシュ１１６にも残される。データキャッシュ１１６の制御については図示しないが、データキャッシュ１１６の残容量が一定量以下になったとき、データキャッシュ１１６に記憶されたアップロード済みのオブジェクトのうちアクセス頻度の低いオブジェクトが、データキャッシュ１１６から削除される。

［ステップＳ２８］チャンク管理部１３２は、既存のオブジェクト番号の最大値をインクリメントする。これにより、次に新たに生成されるチャンクは、インクリメントされたオブジェクト番号が示すオブジェクトに割り当てられるようになる。ステップＳ２８の処理が終了すると、処理が図２０のステップＳ１７に進められる。

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

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

［ステップＳ３３］重複判定部１３１は、ステップＳ３２で特定されたレコードをチャンクマップテーブル１１２から削除する。
［ステップＳ３４］チャンク管理部１３２は、チャンクグループ管理テーブル１１５のレコードの中から、ステップＳ３２でチャンクマップテーブル１１２のレコードから抽出されたチャンク番号が含まれるレコードを特定する。チャンク管理部１３２は、特定されたレコードから、ステップＳ３１で特定したファイル番号を削除する。

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

図２３は、アップロード済みオブジェクトの管理処理の手順を示すフローチャートの例である。
［ステップＳ４１］重複排除処理部１３０のオブジェクト再構築部１３３は、チャンクグループ管理テーブル１１５に登録されたチャンクグループの中から、チャンクグループを１つ選択する。

ここで、図２３の処理は、例えば一定周期で、あるいは所定のスケジュールにしたがって繰り返し実行される。この場合、図２３の処理の実行のたびに、ステップＳ４１で異なるチャンクグループが選択される。

また、図２３の処理は、ファイルが削除されたことに伴って実行されてもよい。この場合、ステップＳ４１では、削除されたファイルが参照していたチャンクが属していたチャンクグループが選択される。あるいは、図２２のステップＳ３４が実行されたときに、ステップＳ３４で特定されたレコードに対応するチャンクグループが選択されて（ステップＳ４１）、ステップＳ４２以降の処理が実行されてもよい。

［ステップＳ４２］オブジェクト再構築部１３３は、ステップＳ４１で選択されたチャンクグループに対応するレコードをチャンクグループ管理テーブル１１５から特定し、特定されたレコードからファイル番号を取得する。

［ステップＳ４３］オブジェクト再構築部１３３は、ステップＳ４２で取得されたファイル番号を用いて、チャンク使用管理テーブル１１７の作成処理を実行する。
［ステップＳ４４］オブジェクト再構築部１３３は、作成されたチャンク使用管理テーブル１１７を参照し、所定の判定条件を満たすかを判定することにより、ステップＳ４１で選択されたチャンクグループに属するオブジェクトについての再構築処理を実行するかを判定する。例えば、チャンクグループ（オブジェクトグループ）に属する各オブジェクトに含まれるチャンクに関して、次の判定条件のうちの少なくとも１つを満たす場合に、オブジェクト再構築を実行すると判定される。

（判定条件１）全チャンクのうち、参照数「０」のチャンクが一定割合以上存在する。
（判定条件２）参照数「１」のチャンクが含まれるオブジェクトについて、そのオブジェクト内の全チャンクが１つのファイルから参照されている。

（判定条件３）参照数が同一で、かつ、それぞれ複数のファイルから参照されている複数のチャンクの中に、ファイルに対するオフセット値が近いものが一定数以上含まれている。

なお、判定条件２を満たす場合、参照数「１」のチャンクを含み、かつ同一ファイルから参照されるオブジェクトが必ず再構築される。再構築されたオブジェクトは、対応するファイルの削除に応じて一括して削除される。また、判定条件３を満たす場合、再構築されたオブジェクトがクラウドストレージ２４０にアップロードされた後に、ファイルの読み出しが要求され、かつキャッシュミスしたときに再アップロードされる際に、ファイルに対応するチャンクが複数オブジェクトに分散せず、１つのオブジェクトから取得されやすくなる。これにより、キャッシュミスに伴う再アップロード時の処理効率を高めることができる。

以上のステップＳ４４では、オブジェクト再構築処理を実行すると判定された場合、処理がステップＳ４５に進められ、実行しないと判定された場合、処理が終了する。
［ステップＳ４５］オブジェクト再構築部１３３は、ステップＳ４１で選択されたチャンクグループに対応するオブジェクトについての再構築処理を実行する。

図２４は、チャンク使用管理テーブルの作成処理の手順を示すフローチャートの例である。この図２４の処理は、図２３のステップＳ４３の処理に対応する。
［ステップＳ５１］オブジェクト再構築部１３３は、図２３のステップＳ４２でチャンクグループ管理テーブル１１５のレコードから取得されたファイル番号の中から、１つを選択する。

［ステップＳ５２］オブジェクト再構築部１３３は、チャンクマップテーブル１１２のレコードを先頭側からスキャンして、ステップＳ５１で選択されたファイル番号に対応付けられたチャンク番号を１つ選択する。これにより、選択されたファイル番号が示すファイルが参照している参照先のチャンクの１つが選択される。

［ステップＳ５３］オブジェクト再構築部１３３は、ステップＳ５２で選択されたチャンク番号が示すチャンクが、図２３のステップＳ４１で選択されたチャンクグループに属するかを判定する。チャンクがチャンクグループに属する場合、処理がステップＳ５４に進められ、チャンクがチャンクグループに属さない場合、処理がステップＳ５７に進められる。

［ステップＳ５４］オブジェクト再構築部１３３は、ステップＳ５２で選択されたチャンク番号がチャンク使用管理テーブル１１７に登録済みであるかを判定する。このチャンク番号が未登録の場合、処理がステップＳ５５に進められ、登録済みの場合、処理がステップＳ５６に進められる。

［ステップＳ５５］オブジェクト再構築部１３３は、チャンク使用管理テーブル１１７にレコードを追加する。オブジェクト再構築部１３３は、追加されたレコードに対して、ステップＳ５２で選択されたチャンク番号と、参照数「１」と、ステップＳ５１で選択されたファイル番号を登録する。

［ステップＳ５６］オブジェクト再構築部１３３は、チャンク使用管理テーブル１１７における、ステップＳ５２で選択されたチャンク番号が登録されたレコードに対して、ステップＳ５１で選択されたファイル番号を追加登録するとともに、そのレコードの参照数をインクリメントする。なお、このファイル番号がすでに登録されていた場合には、参照数のインクリメントのみが実行される。

［ステップＳ５７］オブジェクト再構築部１３３は、ステップＳ５１で選択されたファイル番号が示すファイルの参照先チャンク（ファイル番号に対応付けられたチャンク番号が示すチャンク）について、すべて選択済みかを判定する。未選択の参照先チャンクがある場合、処理がステップＳ５２に進められ、スキャンの続行によって未選択の参照先チャンクの中から１つが選択される。一方、すべての参照先チャンクを選択済みの場合、チャンクマップテーブル１１２の１回のスキャンが終了した（選択されたファイル番号をキーとした検索が終了した）ことになり、処理がステップＳ５８に進められる。

［ステップＳ５８］オブジェクト再構築部１３３は、ステップＳ４２で取得されたファイル番号について、すべて選択済みかを判定する。未選択のファイル番号がある場合、処理がステップＳ５１に進められ、未選択のファイル番号の中から１つが選択される。一方、すべてのファイル番号を選択済みの場合、チャンク使用管理テーブル１１７の作成が完了し、処理が図２３のステップＳ４４に進められる。

図２５、図２６は、オブジェクト再構築処理の手順を示すフローチャートの例である。この図２５、図２６の処理は、図２３のステップＳ４５の処理に対応する。
［ステップＳ６１］オブジェクト再構築部１３３は、図２３のステップＳ４３で作成されたチャンク使用管理テーブル１１７のレコードを、まず参照数をキーとして降順にソートする。オブジェクト再構築部１３３はさらに、参照数が同じレコードを、ファイル番号をキーとして昇順にソートする。

［ステップＳ６２］オブジェクト再構築部１３３は、チャンク使用管理テーブル１１７に、参照数が「２」以上のチャンクが登録されているかを判定する。該当チャンクが登録されている場合、処理がステップＳ６３に進められ、該当チャンクが登録されていない場合、処理がステップＳ６６に進められる。

［ステップＳ６３］オブジェクト再構築部１３３は、参照数が「２」以上のチャンクのうち、データキャッシュ１１６に格納されていないチャンクについては、クラウドストレージ２４０から取得する。すなわち、オブジェクト再構築部１３３は、該当チャンクを含むオブジェクトのダウンロードをクラウド通信部１４０に依頼する。この依頼に応じて、ＧＥＴコマンドによりオブジェクトがクラウドストレージ２４０からダウンロードされ、データキャッシュ１１６に格納される。

［ステップＳ６４］オブジェクト再構築部１３３は、参照数が「２」以上のチャンクを参照数の降順にソートし、同じ参照数のチャンクをまとめることでオブジェクトを再構築する。

オブジェクト再構築部１３３は、再構築されたオブジェクトのそれぞれに対応するチャンクグループのレコードを、チャンクグループ管理テーブル１１５に追加する。追加された各レコードには、新規のチャンクグループ番号が登録されるとともに、対応するオブジェクトに含まれるチャンクのチャンク番号と、チャンクの参照元のファイルを示すファイル番号とが登録される。また、オブジェクト再構築部１３３は、チャンク管理テーブル１１３を参照し、再構築されたオブジェクトに含まれるチャンクのレコードに対し、そのチャンクが属する再構築後のオブジェクトのオブジェクト番号と、そのオブジェクトにおけるチャンクの位置を示すオフセットおよびサイズとを上書きして登録する。

［ステップＳ６５］オブジェクト再構築部１３３は、再構築されたオブジェクトのアップロードをクラウド通信部１４０に依頼する。クラウド通信部１４０は、ＰＵＴコマンドによりオブジェクトをクラウドストレージ２４０にアップロードする。なお、オブジェクトのアップロードは、この後の非同期のタイミングで実行されてもよい。

［ステップＳ６６］オブジェクト再構築部１３３は、チャンク使用管理テーブル１１７に、参照数が「１」のチャンクが登録されているかを判定する。該当チャンクが登録されている場合、処理がステップＳ６７に進められ、該当チャンクが登録されていない場合、処理が図２６のステップＳ７１に進められる。

［ステップＳ６７］オブジェクト再構築部１３３は、参照数が「１」のチャンクのうち、データキャッシュ１１６に格納されていないチャンクについては、クラウドストレージ２４０から取得する。すなわち、オブジェクト再構築部１３３は、該当チャンクを含むオブジェクトのダウンロードをクラウド通信部１４０に依頼する。この依頼に応じて、ＧＥＴコマンドによりオブジェクトがクラウドストレージ２４０からダウンロードされ、データキャッシュ１１６に格納される。

［ステップＳ６８］オブジェクト再構築部１３３は、チャンク使用管理テーブル１１７に基づき、参照数が「１」のチャンクを参照元のファイルのファイル番号ごとにまとめることでオブジェクトを再構築する。

オブジェクト再構築部１３３は、再構築されたオブジェクトのそれぞれに対応するチャンクグループのレコードを、チャンクグループ管理テーブル１１５に追加する。追加された各レコードには、新規のチャンクグループ番号が登録されるとともに、対応するオブジェクトに含まれるチャンクのチャンク番号と、チャンクの参照元のファイルを示すファイル番号とが登録される。また、オブジェクト再構築部１３３は、チャンク管理テーブル１１３を参照し、再構築されたオブジェクトに含まれるチャンクのレコードに対し、そのチャンクが属する再構築後のオブジェクトのオブジェクト番号と、そのオブジェクトにおけるチャンクの位置を示すオフセットおよびサイズとを上書きして登録する。

［ステップＳ６９］オブジェクト再構築部１３３は、再構築されたオブジェクトのアップロードをクラウド通信部１４０に依頼する。クラウド通信部１４０は、ＰＵＴコマンドによりオブジェクトをクラウドストレージ２４０にアップロードする。なお、オブジェクトのアップロードは、この後の非同期のタイミングで実行されてもよい。

なお、ステップＳ６４，Ｓ６８では、再構築されたオブジェクトはそれぞれ個別のチャンクグループに割り当てられる。これにより、２回目以降のオブジェクト再構築は、複数のオブジェクトを含むオブジェクトグループ単位ではなく、個々のオブジェクト単位で実行されるようになる。

以下、図２６を用いて説明を続ける。
［ステップＳ７１］オブジェクト再構築部１３３は、チャンク使用管理テーブル１１７に、参照数が「０」のチャンクが登録されているかを判定する。該当チャンクが登録されている場合、処理がステップＳ７２に進められ、該当チャンクが登録されていない場合、処理がステップＳ７５に進められる。

［ステップＳ７２］オブジェクト再構築部１３３は、チャンクグループに属するすべてのチャンクの参照数が「０」であるかを判定する。すべての参照数が「０」である場合、処理がステップＳ７３に進められ、参照数が「０」以外のチャンクが１つ以上ある場合、処理がステップＳ７４に進められる。

［ステップＳ７３］このケースは、以前にステップＳ６９の処理によってアップロードされたオブジェクト（同一ファイルから参照される、参照数「１」のチャンク）が、再構築処理対象として再度選択されたケースを示す。この場合、チャンクグループには１つのオブジェクトのみ属しており、このオブジェクト内のすべてのチャンクの参照数が「０」である。このため、このオブジェクトのダウンロードや、再構築後のオブジェクトのアップロードは実行されず、単にオブジェクトがクラウドストレージ２４０から削除されればよい。

したがって、オブジェクト再構築部１３３は、該当オブジェクトの削除をクラウド通信部１４０に依頼する。クラウド通信部１４０は、ＤＥＬＥＴＥコマンドによりオブジェクトをクラウドストレージ２４０から削除する。なお、オブジェクトの削除は、この後の非同期のタイミングで実行されてもよい。

［ステップＳ７４］オブジェクト再構築部１３３は、参照数が「０」の各チャンクを無効化する。すなわち、オブジェクト再構築部１３３は、チャンク管理テーブル１１３およびハッシュキーテーブル１１４から、該当チャンクのレコードを削除する。

［ステップＳ７５］オブジェクト再構築部１３３は、図２３のステップＳ４１で選択された既存のチャンクグループのレコードを、チャンクグループ管理テーブル１１５から削除する。これにより、該当チャンクグループが削除される。また、オブジェクト再構築部１３３は、参照していたチャンク使用管理テーブル１１７をその記憶場所（例えばＲＡＭ１０２）から消去する。

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

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

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

１０ 情報処理装置
１１ 処理部
２０ 外部ストレージ
ＦＬ１、ＦＬ２ ファイル
ＯＢ１，ＯＢ２，ＯＢ１１～ＯＢ１３，ＯＢ２１～ＯＢ２４ オブジェクト
ＴＨ 閾値

Claims (6)

1. 書き込みが要求された複数のファイルのそれぞれを分割することで得られた複数の分割データセットから、重複を排除することで得られた複数のデータセットを、外部ストレージに格納する格納処理であって、前記複数のデータセットから選択された２以上のデータセットをオブジェクトにまとめて前記外部ストレージに格納する前記格納処理を実行し、
   前記外部ストレージに格納された前記オブジェクトの中から複数の第１オブジェクトを取得し、前記複数の第１オブジェクトに含まれるデータセットのうち参照数が１以上である有効データセットを組み合わせて１以上の第２オブジェクトを生成し直し、前記１以上の第２オブジェクトを前記複数の第１オブジェクトの代わりに前記外部ストレージに格納するオブジェクト再構築処理を実行する、処理部、
   を有する情報処理装置であって、
   前記オブジェクト再構築処理では、前記複数の第１オブジェクトに含まれる前記有効データセットのうち参照数が所定数以下のデータセットを、前記複数のファイルのうち同じファイルから参照されるデータセットごとにまとめて１以上の第３オブジェクトを生成し直し、前記１以上の第２オブジェクトの少なくとも一部として前記１以上の第３オブジェクトを前記外部ストレージに格納する、
   情報処理装置。
2. 前記処理部はさらに、前記１以上の第３オブジェクトのうち第４オブジェクトに含まれるすべてのデータセットの参照数が０になった場合、前記第４オブジェクトを前記外部ストレージから削除する、
   請求項１記載の情報処理装置。
3. 前記オブジェクト再構築処理では、前記複数の第１オブジェクトに含まれる前記有効データセットの中から参照数が近いと判定されるデータセットをまとめることで前記１以上の第２オブジェクトを生成する、
   請求項１または２記載の情報処理装置。
4. 前記情報処理装置は、
   前記外部ストレージに格納された２以上の前記オブジェクトをグループ化したオブジェクトグループごとに、前記複数のデータセットのうち前記オブジェクトグループに属するデータセットを参照するファイルが登録された第１の管理情報と、
   前記複数のデータセットと前記複数のファイルとの対応関係を示す第２の管理情報と、
   を記憶する記憶部をさらに有し、
   前記オブジェクト再構築処理では、
   前記オブジェクトグループのうち一のオブジェクトグループに含まれる前記オブジェクトとして前記複数の第１オブジェクトを選択し、前記第１の管理情報に基づいて、前記複数のファイルの中から前記一のオブジェクトグループに属するデータセットを参照するファイルを特定し、前記特定したファイルをキーとして前記第２の管理情報に対する検索を実行することで、前記一のオブジェクトグループに属するデータセットのそれぞれについて、参照数および参照元のファイルを特定する、
   請求項１乃至３のいずれか１項に記載の情報処理装置。
5. コンピュータが、
   書き込みが要求された複数のファイルのそれぞれを分割することで得られた複数の分割データセットから、重複を排除することで得られた複数のデータセットを、外部ストレージに格納する格納処理であって、前記複数のデータセットから選択された２以上のデータセットをオブジェクトにまとめて前記外部ストレージに格納する前記格納処理を実行し、
   前記外部ストレージに格納された前記オブジェクトの中から複数の第１オブジェクトを取得し、前記複数の第１オブジェクトに含まれるデータセットのうち参照数が１以上である有効データセットを組み合わせて１以上の第２オブジェクトを生成し直し、前記１以上の第２オブジェクトを前記複数の第１オブジェクトの代わりに前記外部ストレージに格納するオブジェクト再構築処理を実行する、
   情報処理方法であって、
   前記オブジェクト再構築処理では、前記複数の第１オブジェクトに含まれる前記有効データセットのうち参照数が所定数以下のデータセットを、前記複数のファイルのうち同じファイルから参照されるデータセットごとにまとめて１以上の第３オブジェクトを生成し直し、前記１以上の第２オブジェクトの少なくとも一部として前記１以上の第３オブジェクトを前記外部ストレージに格納する、
   情報処理方法。
6. コンピュータに、
   書き込みが要求された複数のファイルのそれぞれを分割することで得られた複数の分割データセットから、重複を排除することで得られた複数のデータセットを、外部ストレージに格納する格納処理であって、前記複数のデータセットから選択された２以上のデータセットをオブジェクトにまとめて前記外部ストレージに格納する前記格納処理を実行し、
   前記外部ストレージに格納された前記オブジェクトの中から複数の第１オブジェクトを取得し、前記複数の第１オブジェクトに含まれるデータセットのうち参照数が１以上である有効データセットを組み合わせて１以上の第２オブジェクトを生成し直し、前記１以上の第２オブジェクトを前記複数の第１オブジェクトの代わりに前記外部ストレージに格納するオブジェクト再構築処理を実行する、
   処理を実行させる情報処理プログラムであって、
   前記オブジェクト再構築処理では、前記複数の第１オブジェクトに含まれる前記有効データセットのうち参照数が所定数以下のデータセットを、前記複数のファイルのうち同じファイルから参照されるデータセットごとにまとめて１以上の第３オブジェクトを生成し直し、前記１以上の第２オブジェクトの少なくとも一部として前記１以上の第３オブジェクトを前記外部ストレージに格納する、
   情報処理プログラム。

Images