JP2016009224A - 履歴情報管理方法、履歴情報管理装置、及び履歴情報管理プログラム - Google Patents

Abstract

【課題】複数のアカウントからアクセス要求があるデータに対する、アカウントごとのアクセス実績を低負荷で取得する履歴情報管理方法を提供する。【解決手段】履歴情報管理方法は、複数のアカウントの各々に対応付けられたデータに対するアクセス要求に応じて生成されるアクセス要求に関する履歴情報から、複数のアクセス要求のうち競合するアクセス要求を検出しＳ２０４、実行されたアクセス要求に関する情報に基づいて、検出された競合するアクセス要求のうち、実行されたアクセス要求を特定しＳ２０６、特定された該アクセス要求と履歴情報に基づいて、データに対して実行されたアクセスの履歴情報をアカウント毎に特定する。【選択図】図６

Description

本発明は、履歴情報の管理に関する。

サービス提供者がネットワークを介して情報格納サービス等を利用者へ提供するネットワークストレージサービスがある。このようなサービスの利用者はネットワークを経由して、提供者が提供するストレージ（記憶領域）にオブジェクト（データ）の格納及び取得をすることが可能となる。

オブジェクトストレージサービスでは、サービス提供者はストレージを利用者に対して提供し、利用者のストレージの使用量の分だけ課金する。ストレージの使用量は、使用領域と使用時間の積に基づいて算出される値である。例えば、利用者が１ＧＢの領域を１．０時間（ｈ）使用した場合、１（ＧＢ）×１．０（ｈ）＝１．０（ＧＢ・ｈ）に対応する額が課金される。また例えば、利用者が１ＧＢの領域を０．５時間使用した場合、１（ＧＢ）×０．５（ｈ）＝０．５（ＧＢ・ｈ）に対応する額が課金される。

オブジェクトストレージサービスでは、使用領域と使用時間がそれぞれ正確に測定されることが望まれる。例えば、利用者（以下、アカウントと記す場合がある）がストレージを１．５（ＧＢ・ｈ）使用した場合、サービスの都合でストレージの使用量を２．０（ＧＢ・ｈ）に繰り上げることは利用者の不利益になる。また、例えば、利用者がストレージを１．５（ＧＢ・ｈ）使用した場合、サービスの都合で１．０（ＧＢ・ｈ）に切り捨てることは提供者の不利益になる。このように、サービスの都合で使用領域と使用時間が実態と異なって測定されることは、利用者と提供者の双方にとって望ましくない。

一方、ストレージ装置の管理に関する技術として、以下の第１と第２の技術がある。
第１の技術では、論理ボリュームを提供する装置であるストレージ装置と、課金額を決定する計算機である課金計算機とに、管理システムが接続される。そして、管理システムは、ユーザからストレージ装置に要求され正常に完了した操作に関する情報である操作関連ログを取得し、取得した操作関連ログを格納する。管理システムは、複数の操作関連ログに対応した複数の操作から、無効な操作に該当する条件である所定の無効操作条件に該当する操作である無効な操作を特定する。そして管理システムは、複数の操作関連ログのうちの、特定された無効な操作の操作関連ログ以外の操作関連ログを用いて、課金額の決定に必要な集計結果を含んだ情報である課金用情報を生成するための集計を行い、課金計算機に送信する。

第２の技術は、サーバからの情報のアクセスが行われるストレージを管理するストレージ装置において実行されるストレージサービスにおける技術である。まず第２の技術は、ストレージとの対応付けがサーバに予め設定されたデバイスファイルに対して、サーバがアクセスすることにより、デバイスファイルに対応するストレージへのアクセスを検知する。次に第２の技術は、ストレージへのアクセスの検知に基づいて、サーバへの課金のためのストレージサービス料金を算出する。

特開２０１１−１１３３０６号公報 特開２００４−２１７９６号公報

しかしながら複数の利用者による利用について考慮されていない上記技術では、利用者毎の実際に実行されたアクセス実績を示す情報を得ることはできない。

そこで、１つの側面では、本発明は、複数のアカウントからアクセス要求があるデータに対する、アカウントごとのアクセス実績を低負荷で取得することを目的とする。

一態様の方法は、複数のアカウントの各々に対応付けられたデータに対するアクセス要求に応じて生成されるアクセス要求に関する履歴情報から、複数のアクセス要求のうち競合するアクセス要求を検出し、実行されたアクセス要求に関する情報に基づいて、検出された競合するアクセス要求のうち、実行されたアクセス要求を特定し、特定されたアクセス要求と履歴情報に基づいて、データに対して実行されたアクセスの履歴情報を、アカウント毎に特定する。

一態様によれば、複数のアカウントからアクセス要求があるデータに対する、アカウントごとのアクセス実績を低負荷で取得することができる。

ストレージシステムの構成の一例を示す。 操作ログの構成の一例を示す。 実施形態に係る集計サーバの構成の一例を示す。 実施形態に係るストレージシステムの構成の一例を示す。 通知部の処理の詳細を図解したフローチャートの一例である。 集計サーバのログ記録処理の詳細を図解したフローチャートの一例である。 集計サーバの集計処理の詳細を図解したフローチャートの一例である。 実施形態に係る集計サーバ及び内部サーバのハードウェア構成の一例を示す。

複数の利用者に対してストレージサービスを提供する形態では、複数の利用者により、ストレージに対する競合する操作（アクセス）が同時に実行される可能性がある。オブジェクトストレージシステム等の結果整合性（eventual consistency）に基くシステムの場合、複数の操作が競合しても排他制御が行われない。この場合、複数の操作が競合すると、競合した操作のうちの一つがストレージに記憶されたデータの状態に実際に反映され、その他の操作はデータの状態に反映されないことがある。上記第１の技術では、結果整合性に基くシステムのように、一貫性が保たれないことを許容し、競合する操作のうちどちらが実行されたのかが分からなくなる状況に適用しても、正しい実行結果を得ることはできない。

図１は、ストレージシステムの構成の一例を示す。ストレージシステムは、オブジェクトストレージサービスを提供するサービス提供システム１２と、課金集計を行う集計サーバとを含む。サービス提供システム１２は、操作端末１１に通信ネットワークを介して接続される。

操作端末１１は、操作者からサービス提供システム１２に対する操作を受け付ける情報処理装置である。例えば操作端末１１は、操作者から、ストレージシステムに対するオブジェクトの生成や削除、更新、アクセス権の設定、管理情報の参照などの操作を受け付ける。そして操作端末１１は、受け付けた操作に対応するアクセス要求をサービス提供システム１２に送信する。その後、操作端末１１は送信したアクセス要求に対する応答をサービス提供システム１２から受信し、応答の結果を所定の出力装置を介して操作者に提示する。ここで、操作者は、オブジェクトの所有者である利用者と同じであってもよいし、異なっていてもよい。また操作端末１１は複数でもよい。

サービス提供システム１２は、ＳＬＢ２１（Server Load Balancer）、内部サーバ２２（２２ａ、２２ｂ）、及びストレージ装置２３を含む。ＳＬＢ２１、内部サーバ２２、及びストレージ装置２３は、バスまたは通信ネットワークを介して接続される。内部サーバ２２（２２ａ、２２ｂ）はそれぞれ、通信ネットワークまたはバスを介して集計サーバと接続される。

ＳＬＢ２１は、操作端末１１に対する通信トラフィックを、内部サーバ２２ａ、２２ｂに振分けを行う情報処理装置である。通信トラフィックを振り分けることによりＳＬＢ２１は、内部サーバ２２の負荷分散を行う。

内部サーバ２２は、ＡＰＩ（Application Programming Interface）３１（３１ａ、３１ｂ）、ミドルウェア３２（３２ａ、３２ｂ）、及び記憶部３３（３３ａ、３３ｂ）を含む。

ＡＰＩ３１は、ミドルウェア３２の機能やミドルウェア３２が管理するデータなどを、外部の他のプログラム（ソフトウェア）から呼び出して利用するための手順やデータ形式などを定めたインターフェースである。ＡＰＩ３１は、操作端末１１からＳＬＢ２１を介してオブジェクトに対するアクセス要求を受信する。そしてＡＰＩ３１は、受信したアクセス要求をミドルウェア３２に出力するとともに、アクセス要求が示す操作に関する情報を記録した操作ログ３４を記憶部３３に記録する。

記憶部３３は、ＡＰＩ３１が記録した操作ログ３４（３４ａ、３４ｂ）を記憶する。図２は、操作ログ３４の構成の一例を示す。操作ログ３４は、「タイムスタンプ」５１、「アクセス情報」５２、「所有者情報」５３、「ＩＤ」５４、及び「サイズ」５５のデータ項目を対応付けた情報である。操作ログ３４の各レコードは、ＡＰＩ３１が操作端末１１から受信した各アクセス要求に対応するものである。「タイムスタンプ」５１は、ＡＰＩ３１がアクセス要求を受信した日時を示す情報である。「アクセス情報」５２は、アクセス要求が示す操作の種別を識別するための識別情報である。「所有者情報」５３は、アクセス要求の操作の対象となるオブジェクトの所有者を識別するための識別情報である。「ＩＤ」５４は、アクセス要求の操作の対象となるオブジェクトを識別するための識別情報である。「サイズ」５５は、アクセス要求の操作の対象となるオブジェクトの操作後のオブジェクトのサイズを示す情報である。ここで、オブジェクトの所有者は、オブジェクトストレージサービスの利用者（課金対象者）である。

図２の例では、操作ログ３４には、レコード６１、６２、６３、６４が記録されている。レコード６２は、対応するアクセス要求について、ＡＰＩ３１が受信した日時が「Fri, 08 Nov 2013 12:00:00 GMT」、操作の種別が「PUT」であることを示している。さらにレコード６２は、操作の対象となるオブジェクトの所有者が「user1」、操作の対象となるオブジェクトの識別情報が「ObjectID」、操作を実行した後のオブジェクトのサイズが「1,073,741,824」であることを示している。尚、図２の「アクセス情報」５２の「PUT」は、オブジェクトをアップロードする命令、「DELETE」はオブジェクトを削除する命令を示す。

ミドルウェア３２は、使用するディスク４１を仮想化し、１または複数のディスク４１を、複数の利用者で共有して利用することを可能とする機能を提供するソフトウェアである。ミドルウェア３２はＡＰＩ３１からアクセス要求を受信し、アクセス要求で示される操作に対応する命令を実行する。例えば、レコード６３のアクセス要求で示される命令を受信すると、ミドルウェア３２は、所有者が「user1」であってＩＤが「ObjectID」のオブジェクトを、ストレージ装置２３から削除する。

尚、内部サーバ２２の数は２つに限定されず、１または複数であってもよく、また、各内部サーバ２２は冗長化されていてもよい。またＡＰＩ３１、ミドルウェア３２は、所定のプログラムであってもよい。

ストレージ装置２３は、１以上のディスク４１（４１ａ、４１ｂ、４１ｃ）を含み、ディスク４１に利用者（課金対象者）に対応付けられたオブジェクトを記憶する。オブジェクトは操作端末１１からのアクセス要求に基づいて、内部サーバ２２のミドルウェア３２によりアクセスされる。オブジェクトは所定の単位のデータであり、例えばディレクトリやファイルである。オブジェクトと利用者の対応付けを示す情報は、例えばオブジェクト毎に付与される属性情報（メタデータ）等に記憶される。オブジェクトは複数のストレージ装置２３または複数のディスク４１に分散して配置されてもよいし、多重化されて記憶されてもよい。尚、図１においてストレージ装置２３は１つ記載されているが、複数でもよい。また、ディスク４１は半導体メモリ等の所定の記憶装置であってもよい。また、オブジェクトと利用者の対応付けを示す情報は、例えば、図２における「所有者情報」５３と「ＩＤ」５４とを対応付けた情報である。

以上のようなサービス提供システム１２に対して、課金集計を行う集計サーバが接続される。集計サーバによる課金集計の方法はいくつかあるが、先ず実施形態の効果を説明するために２つの比較例を説明する。その後、実施形態の構成を説明し、比較例と比較した場合の効果を記載する。

先ず比較例１の集計の方法について説明する。比較例１の集計サーバは、定期的にサービス提供システム１２に対して、利用者毎のオブジェクトの状態を問い合わせる（取得する）ことで、各利用者のストレージの使用量を算出する。

比較例１では、予めミドルウェア３２は、オブジェクトに関する情報と、利用者に関する情報とを対応付け、この対応付けた情報を対応情報として所定の記憶領域に記憶する。ここで、オブジェクトに関する情報は例えば、オブジェクトの識別情報（オブジェクトＩＤ）やオブジェクトのサイズを示す情報である。また、利用者に関する情報は例えば、利用者の識別情報（所有者情報）である。これらのオブジェクトに関する情報と利用者に関する情報の対応付けは、例えば、オブジェクトのアップロード（新規作成時）等の所定のタイミングで行われる。

このような対応付けが予め行われているサービス提供システム１２のミドルウェア３２に対して、集計サーバは、一定時間毎に、利用者毎に個別に、オブジェクトの状態の問い合わせを行う。

ミドルウェア３２はこの問い合わせを受信すると、利用者毎の各オブジェクトの状態を確認し、確認の結果を状態情報として集計サーバに返す。オブジェクトの状態の確認では、ミドルウェア３２は例えば、先ず、各利用者のオブジェクトの一覧情報を取得する。一覧情報の取得は、所定の記憶領域に予め記憶されている対応情報に基づいて行われる。次にミドルウェア３２は、取得した一覧情報に記載されたオブジェクトについて、ストレージ装置２３にアクセスを行い、各オブジェクトのサイズを取得する。そしてミドルウェア３２は取得した各オブジェクトのサイズを集計サーバに送信する。

集計サーバは、ミドルウェア３２から状態情報を受信し、状態情報に含まれる利用者毎のオブジェクトのサイズを合計する。そして集計サーバは、合計した値を各利用者のストレージの使用量とする。

ここで、ネットワークストレージサービスにおいて、複数の利用者のうち各利用者に一つのディスクが割りあてられるようなシステムの場合、各利用者のストレージの使用量は、ディスクの統計情報を参照することで測定できる。しかしながら、例えばクラウド技術を用いたシステムの場合は、ディスクを仮想化し特定のディスクを複数の利用者で共有して利用する。この場合、各利用者のオブジェクトのサイズは、特定のディスクを複数の利用者で共有する仕組みを提供するミドルウェア３２を介して測定されることとなる。

比較例１のシステムにおいては、集計サーバからの問い合わせが高頻度で発生すると、問い合わせに対するミドルウェア３２の処理の負荷が高くなる。問い合わせを受けたミドルウェア３２は、各利用者のオブジェクト１つ１つに対してアクセスを行い、各オブジェクトのサイズを取得するため、負荷が大きい。

また、問い合わせとその応答により、ストレージ装置２３と内部サーバ２２の間の通信トラフィックが増大する。このように処理負荷や通信トラフィックが増大すると、利用者へのサービスであるオブジェクトのアップロードやダウンロードの性能に影響を与える虞もある。

その一方で、問い合わせの負荷やトラフィック量を減らすために、問い合わせの頻度を減らすと、ストレージの使用量の算出結果が不正確なものとなる。問い合わせの頻度が減少した場合、ストレージの使用量の算出結果が不正確なものとなるのは、例えば以下のようなケースが発生するからである。

比較例１において、例えば問い合わせの間隔がＴ時間の場合、Ｔ時間の間にオブジェクトのアップロードと削除が行われると、算出されるストレージの使用量は０として算出される。例えば、１時間間隔で問い合わせが行われる比較例１のシステムにおいて、以下のような操作が行われた場合を考える。
（１）０：００ 集計サーバによる問い合わせ
（２）０：２０ 使用者が１ＧＢのオブジェクトをアップロード
（３）０：５０ 使用者が１ＧＢのオブジェクトを削除
（４）１：００ 集計サーバによる問い合わせ
この場合、ストレージ使用量の実績値は、１（ＧＢ）×０．５（ｈ）＝０．５（ＧＢ・ｈ）である。しかしながら比較例１の集計サーバは、ストレージの使用量を０（ＧＢ）×０（ＧＢ）＝０．０（ＧＢ・ｈ）として算出してしまう。なぜなら、（１）と（４）においては、（２）で作成され（３）で削除された１ＧＢのオブジェクトは存在しないからである。

このように比較例１では、２つの問い合わせの間に所定のアクセスがなされた場合、それらの所定のアクセスが行われたことを正確に把握できない場合がある。これは比較例１では、最初の問い合わせが行われてから、次の問い合わせが行われるまでの間のオブジェクトの状態の変化が考慮されないからである。このように、比較例１のシステムにおいて問い合わせの頻度を減らすと、アクセスの実績を得ることができず、ストレージの使用量の算出結果が不正確なものとなる。

次に比較例２の集計の方法について説明する。比較例２の集計サーバは、利用者毎の課金額の集計処理の段階で、サービス提供システム１２から操作ログ３４を収集する。ここで、集計処理の実行タイミングと、操作ログ３４が記録されるタイミングとの間に関連はない。比較例２の集計サーバは、収集した操作ログ３４を解析して各利用者の「使用領域」と「使用時間」をトレースし、ストレージ使用量を算出する。

複数のアクセス要求が競合した場合に、操作ログ３４の内容とオブジェクトに実際に反映されるアクセス要求の内容とが異なる可能性があるシステムにおいて、比較例２を適用した場合を考える。このようなシステムには結果整合性に基くシステム等のように、複数のアクセス要求が競合した場合に、競合が発生したアクセス要求のうちの一つのアクセス要求（例えば最後に実行されたアクセス要求）だけがオブジェクトの状態に反映されるシステム等がある。この場合、比較例２の収集サーバは、競合が発生すると、ミドルウェア３２により実際に実行されたアクセス要求をトレースすることができない。ここで、複数のアクセス要求が競合する場合とは、具体的には例えば、提供システムが使用者端末から複数のアクセス要求を同時刻または所定の期間内に受信した場合などである。

例えば結果整合性に基くシステムにおいて、図２に示すような操作ログ３４が記録されているケースを考える。図２では、レコード６２とレコード６３において、「ＩＤ」５４が「ObjectID」、「所有者情報」５３が「user1」、「タイムスタンプ」５１が「Fri, 15 Nov 2013 15:00:00 GMT」と同じ値になっている。そしてレコード６２とレコード６３の「アクセス情報」５２はそれぞれ「PUT」、「DELETE」となっている。これらは、同じオブジェクトに対する２つの異なるアクセス要求が同時刻にＡＰＩ３１に受信されたことを示している。すなわちレコード６２とレコード６３にそれぞれ対応する「PUT」と「DELETE」のアクセス要求は、互いに競合する関係となっている。また、レコード６４において、レコード６２、６３のアクセス対象のオブジェクトと同じオブジェクト、すなわち、「ＩＤ」５４が「ObjectID」、「所有者情報」５３が「user1」のオブジェクトに対して、「PUT」のアクセスが行われたことが示されている。

図２の例の場合、比較例２の集計サーバは、操作ログ３４からでは、競合するレコード６２とレコード６３のどちらのアクセス要求が実際に実行されたのかを判定することはできない。

そこで、比較例２の集計サーバが、集計の段階で操作ログ３４に基づいて競合が発生したか否かを判定し、競合があると判定した場合に、ミドルウェア３２に対してオブジェクトの状態の問い合わせを行うという方法も考えられる。しかしながらこの場合も、競合するアクセスが発生してから集計までの間に、競合するアクセスの対象のオブジェクトに対して別のアクセスが行われた場合は、どちらのアクセス要求が実行されたのかを判定することはできない。

例えば図２の例の場合、競合するアクセス要求の対象のオブジェクトである、「ＩＤ」５４が「ObjectID」であって「所有者情報」５３が「user1」のオブジェクトに対して、レコード６４において「PUT」のアクセスが行われていることが示されている。従って、レコード６２とレコード６３のどちらのアクセス要求が実行されたとしても、集計時点においては、「ＩＤ」５４が「ObjectID」であって「所有者情報」５３が「user1」のオブジェクトはサイズ「２５６」のオブジェクトとして存在することとなる。従って、比較例２の集計サーバは、集計時点においてミドルウェア３２に対してオブジェクトの状態の問い合わせを行ったとしても、レコード６２とレコード６３のどちらのアクセス要求が実行されたのかを判定することはできない。このため、例えば比較例２の集計サーバは集計処理において、レコード６２とレコード６３のうち、利用者に不当に課金することのないようにレコード６３の「DELETE」が実行されたとして判定する。

図３は、実施形態に係る集計サーバの構成の一例を示す。図３において集計サーバは、検出部１、実行アクセス特定部２、履歴情報特定部３、及び履歴情報受信部４を含む。

検出部１は、複数のアカウントの各々に対応付けられたデータに対するアクセス要求に応じて生成されるアクセス要求に関する履歴情報から、複数のアクセス要求のうち競合するアクセス要求を検出する。

実行アクセス特定部２は、実行されたアクセス要求に関する情報に基づいて、検出された競合するアクセス要求のうち、実行されたアクセス要求を特定する。

履歴情報特定部３は、特定されたアクセス要求と履歴情報に基づいて、データに対して実行されたアクセスの履歴情報を、アカウント毎に特定する。

また、実行されたアクセス要求に関する情報は、実行されたアクセス要求に応じてアクセスが行われた直後のデータのサイズを示す情報である。

履歴情報受信部４は、アクセス要求を受信する受信部がアクセス要求を受信した場合に受信部から通知される履歴情報を順次受信する。また検出部１は、履歴情報を受信した場合、履歴情報から複数のアクセス要求のうち競合するアクセス要求を検出する。また実行アクセス特定部２は、競合するアクセスを検出した場合、実行されたアクセス要求に関する情報を取得し、取得した情報に基づいて、競合するアクセス要求のうち実行されたアクセス要求を特定する。

実施形態に係る集計サーバは、複数のアカウントからアクセス要求があるデータに対する、アカウントごとのアクセス実績を低負荷で取得することができる。

図４は、実施形態に係るストレージシステムの構成の一例を示す。ストレージシステムは、サービス提供システム１３と、課金集計を行う集計サーバ１４とを含む。サービス提供システム１３は、操作端末１１に通信ネットワークを介して接続される。サービス提供システム１３と集計サーバ１４は通信ネットワークまたはバスを介して接続される。

操作端末１１は、図１において説明したものと同様である。
サービス提供システム１３は、ＳＬＢ２１、内部サーバ２４（２４ａ、２４ｂ）、及びストレージ装置２３を含む。ＳＬＢ２１、内部サーバ２４、及びストレージ装置２３は、バスまたは通信ネットワークを介して接続される。内部サーバ２４（２４ａ、２４ｂ）はそれぞれ、通信ネットワークまたはバスを介して集計サーバ１４と接続される。尚、図４において、内部サーバ２４、及びストレージ装置２３の数は、１以上の所定の数としてもよい。

ＳＬＢ２１、及びストレージ装置２３は、図１で説明したものと同様である。
内部サーバ２４は、ＡＰＩ３５（３５ａ、３５ｂ）、ミドルウェア３２（３２ａ、３２ｂ）、及び記憶部３３（３３ａ、３３ｂ）を含む。

ＡＰＩ３５は、ミドルウェア３２の機能やミドルウェア３２が管理するデータなどを、外部の他のプログラム（ソフトウェア）から呼び出して利用するための手順やデータ形式などを定めたインターフェースである。ＡＰＩ３５は、操作端末１１からＳＬＢ２１を介してオブジェクトに対するアクセス要求を受信する。そしてＡＰＩ３５は、受信したアクセス要求をミドルウェア３２に出力するとともに、アクセス要求に関する情報を記録した操作ログ３４（３４ａ、３４ｂ）を記憶部３３に記録する。

またＡＰＩ３５は、通知部３６（３６ａ、３６ｂ）を含む。通知部３６は、ＡＰＩ３５がアクセス要求を受信すると、受信したアクセス要求に対応する操作ログ３４のレコード情報を生成し、生成したレコード情報を集計サーバ１４に通知する。通知部３６は、ＡＰＩ３５がアクセス要求を受信する毎に順次、集計サーバ１４に通知を行う。

ミドルウェア３２、記憶部３３は、図１において説明したものと同様である。操作ログ３４は、図２において説明したものと同様である。

尚、内部サーバ２４の数は２つに限定されず、１または複数であってもよく、また、各内部サーバ２４は冗長化されていてもよい。またＡＰＩ３５、ミドルウェア３２は、所定のプログラムであってもよい。

集計サーバ１４は、ログ記録処理と集計処理を行う。ログ記録処理は、操作ログ３４から、ミドルウェア３２により実際に実行されたアクセスのログを抽出した実行ログ７７を生成する処理である。集計処理は、実行ログ７７に基づいて、利用者毎のストレージ使用量を算出し、利用者毎の課金集計を行う処理である。

ログ記録処理において、先ず集計サーバ１４は、操作ログを受信して、受信した操作ログに基づいて、競合するアクセスを検出する。次に集計サーバ１４は、競合するアクセスを検出した場合、実行されたアクセス要求に関する情報を取得する。そして集計サーバ１４は、取得した、実行されたアクセス要求に関する情報に基づいて、操作ログから、競合するアクセス要求のうち実行されたアクセス要求を抽出し、実行ログ７７として記録する。

集計サーバ１４は、通知受信部７１、競合検出部７２、補正部７３、算出部７４、及び、記憶部７５を含む。通知受信部７１は、履歴情報受信部４の一例である。競合検出部７２は、検出部１の一例である。補正部７３は、実行アクセス特定部２、及び履歴情報特定部３の一例である。

通知受信部７１は、通知部３６から操作ログのレコード情報を受信する。そして通知受信部７１は受信した操作ログのレコード情報を競合検出部７２に出力するとともに、操作ログ７６に記録する。

競合検出部７２は、通知受信部７１からレコード情報を入力されると、操作ログ７６を参照して競合するアクセス要求を検出する。すなわち競合検出部７２は、通知受信部７１から入力されたレコード情報（以下、対象レコード情報と記す）で示されるアクセス要求が他のアクセス要求と競合しているか否かを判定する。

具体的には競合検出部７２は、操作ログ７６を参照し、「タイムスタンプ」５１が対象レコード情報と一致するレコード（以下、競合レコード情報と記す）が存在するか否かを判定する。競合レコード情報が存在すると判定した場合、競合検出部７２は、競合レコード情報を抽出し、対象レコード情報で示されるアクセス要求が他のアクセス要求と競合していると判定する。そして競合検出部７２は、対象レコード情報と競合レコード情報とを補正部７３に出力する。

「タイムスタンプ」５１が対象レコード情報と一致するレコードが存在しないと判定した場合、競合検出部７２は、対象レコード情報で示されるアクセス要求は他のアクセス要求と競合していないと判定し、対象レコード情報を実行ログ７７に記録する。

補正部７３は、競合検出部７２から対象レコード情報と競合レコード情報とを入力されると、対象レコード情報の「所有者情報」５３と「ＩＤ」５４で示されるオブジェクト（以下、競合オブジェクトと記す）の状態を、ミドルウェア３２に問い合わせる。

ミドルウェア３２はこの問い合わせを受信すると、競合オブジェクトの状態を確認し、確認の結果を状態情報として補正部７３に返す。オブジェクトの状態の確認では、具体的には例えば、ミドルウェア３２は、ストレージ装置２３または競合オブジェクトにアクセスを行い、競合オブジェクトのサイズを示す情報を取得する。例えば、ミドルウェア３２はコマンド等により直接競合オブジェクトを参照することによりサイズを取得してもよい。そしてミドルウェア３２は取得した競合オブジェクトのサイズを示す情報を集計サーバ１４に送信する。ここで状態情報は、実行されたアクセス要求に関する情報であり、その状態情報に基づいて、競合するアクセス要求のうち実行されたアクセス要求を特定することができる情報であれば、競合オブジェクトのサイズを示す情報に限定されない。

問い合わせの応答としてミドルウェア３２から状態情報を受信すると、補正部７３は、受信した状態情報に基づいて、競合レコード情報と対象レコード情報に対応するアクセス要求のうち実際に実行されたアクセス要求を特定する。

具体的には、例えば状態情報が競合オブジェクトのサイズを示す情報の場合、補正部７３は、競合するアクセス要求のうち、各々のアクセス要求が実行されたと仮定した場合の実行後のオブジェクトのサイズと、状態情報が示すサイズとをそれぞれ比較する。そして補正部７３は、比較結果が一致するアクセス要求を、実行されたアクセス要求であると特定する。例えば図２のレコード６２とレコード６３の競合するアクセス要求のうち、実行されたアクセス要求を特定する場合を考える。このとき状態情報で示されるオブジェクトのサイズが「1024」である場合には、レコード６２のアクセス要求が実行されたと仮定したオブジェクトのサイズは「1024」であるので、補正部７３は、レコード６２が実行されたアクセス要求であると特定する。

そして補正部７３は、競合レコード情報と対象レコード情報のうち、実行されたアクセス要求に対応するレコード情報を実行ログ７７に記録する。また補正部７３は、実行されていないアクセス要求に対応するレコード情報が実行ログ７７に存在する場合には、実行されていないアクセス要求に対応するレコード情報を実行ログ７７から削除する。

算出部７４は、実行ログ７７を参照して、利用者毎の使用領域と使用時間を算出する。実行ログ７７には、実際にオブジェクトに対して実行された操作ログ７６のエントリ情報が記録されている。例えば、所定の課金対象者についての使用領域と使用時間の算出において、算出部７４は先ず、実行ログ７７の「所有者情報」５３が課金対象者を示すエントリを抽出する。次に算出部７４は、抽出したエントリから、課金対象者の各オブジェクトのサイズが変更された日時を特定する。課金対象者の使用領域は、課金対象者の各オブジェクトのサイズの和と等しいので、課金対象者の各オブジェクトのサイズが変更された日時に基づいて、算出部７４は、課金対象者の使用領域と使用時間を算出することができる。そして算出部７４は、使用領域と使用時間の積を算出し、算出した値に基づいて、課金対象者の課金額を算出する。

記憶部７５は、操作ログ７６及び実行ログ７７を記憶する。操作ログ７６は、操作ログ３４ａ、３４ｂと同じ内容の情報が統合されて記録される。または、操作ログ７６は、操作ログ３４ａ、３４ｂにそれぞれ対応するように複数記憶されてもよい。実行ログ７７は、操作ログ７６に記録されたレコードのうち、実行されたと競合検出部７２及び補正部７３により判定されたアクセス要求に対応するレコードが記録された情報である。よって実行ログ７７も操作ログ７６（３４）と同様に、「タイムスタンプ」５１、「アクセス情報」５２、「所有者情報」５３、「ＩＤ」５４、及び「サイズ」５５のデータ項目を含むものである。尚、競合が検出されないアクセス要求については、実行されたアクセス要求であると判定されるものとする。

実施形態の集計サーバ１４は、ＡＰＩ３５が操作端末１１からアクセス要求を受信する毎に、通知部３６から操作ログを受信する。そして集計サーバ１４は、受信した操作ログに基づいて、競合の検出を行い、競合を検出した場合にミドルウェアに対して、競合オブジェクトの状態を問い合わせている。これにより実施形態では、比較例１と比較すると、ミドルウェア３２に対する問い合わせの頻度を減少させることができる。その結果、実施形態では、ミドルウェア３２にかかる負荷を軽減することができ、ストレージ装置２３と内部サーバ２４の間の通信トラフィックを減少させることができる。

また実施形態の集計サーバ１４において、競合検出部７２は、通知受信部７１が対象レコード情報を受信した直後のタイミングで競合の検出処理を行っている。これにより、アクセス要求の競合が実際に発生してから検出までの期間を短くすることができる。さらに集計サーバ１４は、競合を検出した直後のタイミングで競合オブジェクトの状態を問い合わせることで、競合が発生してから、問い合わせまでの期間を短くすることができる。その結果、集計サーバ１４は、比較例１及び比較例２と比較して、より正確なオブジェクトの実行状態を得ることができる。これは、競合が発生してから競合オブジェクトの問い合わせまでの間に、競合オブジェクトに対する他のアクセスが行われる確率が減少するからである。

尚、通知受信部７１は、所定の時間間隔で操作ログ３４のレコード情報をＡＰＩ３５から取得するようにしてもよい。操作ログ３４の取得処理については、競合オブジェクトの状態の問い合わせに比べて内部サーバ２４にかかる負荷が小さいため、通知受信部７１は操作ログ３４を高頻度で取得することができる。この場合、比較例１と比較すると、ミドルウェア（内部サーバ２４）にかかる負荷、及び、ストレージ装置２３と内部サーバ２４の間の通信トラフィックを減少させることができる。また実施形態では、比較例２と比較すると、より正確にアクセス実績を特定することができる。

また実施形態の集計サーバ１４は、ストレージ使用量の算出において、ミドルウェア３２の内部で出力されるログを用いなくてもアクセス実績を特定することができる。ミドルウェア３２は頻繁にバージョンアップされることが考えられるが、ミドルウェア３２のログは、ミドルウェア３２がバージョンアップされると、フォーマットに非互換が生じる可能性がある。このような非互換が生じると、サービスを提供することができなくなる。一方、このようなミドルウェアのログを用いない実施形態の集計サーバ１４においては、ストレージ使用量の集計がミドルウェア３２の非互換に依存しないため、サービスを安定して提供することができる。

次に、通知部３６の動作フローについて説明する。図５は、通知部３６の処理の詳細を図解したフローチャートの一例である。

図５において、先ず通知部３６は、アクセス要求を操作端末１１から受信したか否かを判定する（Ｓ１０１）。アクセス要求を操作端末１１から受信していないと判定した場合（Ｓ１０１でＮｏ）、通知部３６は再度処理をＳ１０１に遷移させる。

一方、アクセス要求を操作端末１１から受信したと判定した場合（Ｓ１０１でＹｅｓ）、通知部３６は、操作ログを集計サーバ１４に通知する（Ｓ１０２）。すなわち通知部３６は、受信したアクセス要求に対応する操作ログのレコード情報を生成し、生成したレコード情報を通知受信部７１に通知する。そして通知部３６は、一連の処理を終了するか否かを判定し（Ｓ１０３）、処理を続けると判定した場合（Ｓ１０３でＮｏ）、処理をＳ１０１に遷移させる。一方、処理を終了すると判定した場合（Ｓ１０３でＹｅｓ）、通知部３６は処理を終了する。

次に、集計サーバ１４のログ記録処理の動作フローについて説明する。図６は、集計サーバのログ記録処理の詳細を図解したフローチャートの一例である。

図６において、先ず通知受信部７１は、通知部３６から操作ログの対象レコード情報を含む通知を受信したか否かを判定する（Ｓ２０１）。通知を受信していないと判定した場合（Ｓ２０１でＮｏ）、処理は再度Ｓ２０１に遷移する。

一方、通知を受信したと判定した場合（Ｓ２０１でＹｅｓ）、通知受信部７１は、受信した対象レコード情報を競合検出部７２に出力するとともに、操作ログ７６に記録する（Ｓ２０２）。

次に競合検出部７２は、対象レコード情報のタイムスタンプと、操作ログ７６の各レコード情報のタイムスタンプとを比較する（Ｓ２０３）。

次に競合検出部７２は、タイムスタンプの比較の結果、操作ログ７６の各レコードから、対象レコード情報と「タイムスタンプ」５１の値が一致する競合レコード情報を検出する（Ｓ２０４）。競合レコードを検出できなかった場合（Ｓ２０４でＮｏ）、競合検出部７２は、対象レコード情報は、実行されたアクセス要求に対応するレコード情報であると特定し、処理をＳ２０７に遷移させる。

一方、競合レコードを検出した場合（Ｓ２０４でＹｅｓ）、競合検出部７２は、対象レコード情報と競合レコード情報とを補正部７３に出力する。すると補正部７３は、対象レコード情報の「所有者情報」５３と「ＩＤ」５４で示される競合オブジェクトの状態を、ミドルウェア３２に問い合わせる。そして補正部７３は、問い合わせの応答としてミドルウェア３２から状態情報を受信する（Ｓ２０５）。

次に補正部７３は、受信した状態情報に基づいて、競合レコード情報と対象レコード情報のアクセス要求のうち実際に実行されたアクセス要求を特定する（Ｓ２０６）。

次に補正部７３は、実行されたアクセス要求のレコード情報を実行ログ７７に記録する（Ｓ２０７）。ここで、実行されたアクセス要求は、Ｓ２０４において競合するアクセス要求が検出された場合には、Ｓ２０６で特定されたアクセス要求であり、Ｓ２０４において競合するアクセス要求が検出されなかった場合には、対象レコード情報のアクセス要求である。

そして補正部７３は、ログ記録処理を終了するか否かを判定し（Ｓ２０８）、処理を続けると判定した場合（Ｓ２０８でＮｏ）、処理をＳ２０１に遷移させる。一方、処理を終了すると判定した場合（Ｓ２０８でＹｅｓ）、補正部７３はログ記録処理を終了する。

次に、集計サーバ１４の集計処理の動作フローについて説明する。図７は、集計サーバの集計処理の詳細を図解したフローチャートの一例である。図７は、複数のアカウントのうちの課金対象の特定のアカウント（以下、課金対象アカウントと記す）の課金額を集計する処理のフローを示している。

図７において、先ず算出部７４は、実行ログ７７を参照する（Ｓ３０１）。次に算出部７４は、実行ログ７７を解析し、実行ログ７７から課金対象アカウントに対応するエントリ情報を抽出する（Ｓ３０２）。次に算出部７４は、抽出したエントリ情報に基づいて、課金対象アカウントの使用領域と使用時間の積を算出し、算出した値に基づいて、利用者毎の課金額を算出する（Ｓ３０３）。そして処理は終了する。

次に、集計サーバ１４及び内部サーバ２４のハードウェア構成を説明する。図８は、実施形態に係る集計サーバ及び内部サーバのハードウェア構成の一例を示す。

図８において、集計サーバ１４及び内部サーバ２４は、ＣＰＵ８１（Central Processing Unit）、メモリ８２、記憶装置８３、読取装置８４、及び通信インターフェース８５を含む。ＣＰＵ８１、メモリ８２、記憶装置８３、読取装置８４、及び通信インターフェース８５はバスを介して接続される。

集計サーバ１４において、ＣＰＵ８１は、メモリ８２を利用して上述のフローチャートの手順を記述したプログラムを実行することにより、通知受信部７１、競合検出部７２、補正部７３、及び算出部７４の一部または全部の機能を提供する。内部サーバ２４において、ＣＰＵ８１は、ＡＰＩ３５、ミドルウェア３２、及び通知部３６の一部または全部の機能を提供する。

メモリ８２は、例えば半導体メモリであり、ＲＡＭ（Random Access Memory）領域およびＲＯＭ（Read Only Memory）領域を含んで構成される。記憶装置８３は、例えばハードディスクである。なお、記憶装置８３は、フラッシュメモリ等の半導体メモリであってもよい。また、記憶装置８３は、外部記録装置であってもよい。集計サーバ１４において、メモリ８２または記憶装置８３は、記憶部７５の一部または全部の機能を提供する。内部サーバ２４において、メモリ８２または記憶装置８３は、記憶部３３の一部または全部の機能を提供する。

読取装置８４は、ＣＰＵ８１の指示に従って着脱可能記憶媒体８０にアクセスする。着脱可能記憶媒体８０は、たとえば、半導体デバイス（ＵＳＢメモリ８２等）、磁気的作用により情報が入出力される媒体（磁気ディスク等）、光学的作用により情報が入出力される媒体（ＣＤ−ＲＯＭ、ＤＶＤ等）などにより実現される。尚、読取装置８４は集計サーバ１４または内部サーバ２４に含まれなくてもよい。

通信インターフェース８５は、ＣＰＵ８１の指示に従ってネットワークまたはバスを介して通信を行うインターフェースである。集計サーバ１４において、通信インターフェース８５は、内部サーバ２４と通信を行う。内部サーバ２４において、通信インターフェース８５は、操作端末１１、集計サーバ１４、及びストレージ装置２３と通信を行う。

実施形態のプログラムは、例えば、下記の形態で集計サーバ１４及び内部サーバ２４に提供される。
（１）記憶装置８３に予めインストールされている。
（２）着脱可能記憶媒体８０により提供される。
（３）プログラムサーバ（図示せず）から通信インターフェース８５を介して提供される。

内部サーバ２４は、１以上のストレージ装置２３にバスまたは通信ネットワークを介して接続される。ストレージ装置２３は、例えばハードディスク、またはディスクアレイ装置である。なお、記憶装置８３は、フラッシュメモリ等の半導体メモリであってもよい。記憶装置８３はストレージ装置２３の一部または全部の機能を提供する。

さらに、実施形態の集計サーバ１４及び内部サーバ２４の一部は、ハードウェアで実現してもよい。或いは、実施形態の集計サーバ１４及び内部サーバ２４は、ソフトウェアおよびハードウェアの組み合わせで実現してもよい。

尚、集計サーバ１４において１以上の仮想サーバを稼動させ、各々の仮想サーバが、通知受信部７１、競合検出部７２、補正部７３、及び算出部７４の機能の一部または所定の組合せの機能を提供してもよい。また、内部サーバ２４において、１以上の仮想サーバを稼動させ、各々の仮想サーバが、ＡＰＩ３５、ミドルウェア３２、及び通知部３６の機能の一部または所定の組合せの機能を提供してもよい。また、内部サーバ２４において、記憶部３３の機能を仮想ディスクにより実現する構成としてもよい。

尚、本実施形態は、以上に述べた実施の形態に限定されるものではなく、本実施形態の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。

１ 検出部
２ 実行アクセス特定部
３ 履歴情報特定部
４ 履歴情報受信部

Claims (5)

1. 複数のアカウントの各々に対応付けられたデータに対するアクセス要求に応じて生成される該アクセス要求に関する履歴情報から、前記複数のアクセス要求のうち競合するアクセス要求を検出し、
   実行されたアクセス要求に関する情報に基づいて、検出された前記競合するアクセス要求のうち、実行されたアクセス要求を特定し、
   特定された該アクセス要求と前記履歴情報に基づいて、前記データに対して実行されたアクセスの履歴情報を、アカウント毎に特定する
   ことを特徴とする履歴情報管理方法。
2. 前記実行されたアクセス要求に関する情報は、前記実行されたアクセス要求に応じてアクセスが行われた直後の前記データのサイズを示す情報である
   ことを特徴とする請求項１に記載の履歴情報管理方法。
3. 前記アクセス要求を受信する受信部が該アクセス要求を受信した場合に該受信部から通知される前記履歴情報を順次受信し、
   前記履歴情報を受信した場合、前記履歴情報から、前記複数のアクセス要求のうち競合するアクセス要求を検出し、
   前記競合するアクセスを検出した場合、前記実行されたアクセス要求に関する情報を取得し、該取得した情報に基づいて、前記競合するアクセス要求のうち、前記実行されたアクセス要求を特定する
   ことを特徴とする請求項１または２に記載の履歴情報管理方法。
4. 複数のアカウントの各々に対応付けられたデータに対するアクセス要求に応じて生成される該アクセス要求に関する履歴情報から、前記複数のアクセス要求のうち競合するアクセス要求を検出する検出部と、
   実行されたアクセス要求に関する情報に基づいて、検出された前記競合するアクセス要求のうち、実行されたアクセス要求を特定するアクセス要求特定部と、
   特定された該アクセス要求と前記履歴情報に基づいて、前記データに対して実行されたアクセスの履歴情報を、アカウント毎に特定する履歴情報特定部と、
   を備えることを特徴とする履歴情報管理装置。
5. コンピュータに、
   複数のアカウントの各々に対応付けられたデータに対するアクセス要求に応じて生成される該アクセス要求に関する履歴情報から、前記複数のアクセス要求のうち競合するアクセス要求を検出し、
   実行されたアクセス要求に関する情報に基づいて、検出された前記競合するアクセス要求のうち、実行されたアクセス要求を特定し、
   特定された該アクセス要求と前記履歴情報に基づいて、前記データに対して実行されたアクセスの履歴情報を、アカウント毎に特定する
   処理を実行させることを特徴とする履歴情報管理プログラム。

Images