(57)【要約】【課題】クライアントがオブジェクトストレージに格納されるデータを複数のファイル単位で送信する場合であっても、ファイルの送信に利用するＵＲＬをクライアントに応答するサーバの負荷を抑えることができる情報処理システムを提供する。【解決手段】ＭＦＰ１１１が、ログ管理サービス１０１に複数のファイル単位でデータを送信する場合に、複数のファイル単位でのデータの送信に利用する第１のＵＲＬの発行をログ管理サービス１０１に要求する。ログ管理サービス１０１は、ＭＦＰ１１１から第１のＵＲＬの発行を要求された場合に、バージョニングが有効であるオブジェクトストレージ３４３ｂにおいてダミー名で格納されるオブジェクトのロケーションを示す１つのＵＲＬを上記第１のＵＲＬとしてＭＦＰ１１１に応答する。【選択図】図１
2018101294.tif 000002
【特許請求の範囲】
【請求項１】
クライアント装置と、前記クライアント装置から送信されるデータを管理する管理サーバとを有する情報処理システムであって、
前記クライアント装置は、
前記管理サーバに複数のファイル単位でデータを送信するかを判断する判断手段と、
前記複数のファイル単位で前記データを送信すると判断された場合に、複数のファイル単位での前記データの送信に利用する第１のＵＲＬの発行を前記管理サーバに要求し、１ファイル単位で前記データを送信すると判断された場合に、１ファイル単位での前記データの送信に利用する第２のＵＲＬの発行を前記管理サーバに要求する要求手段と、を有し、
前記管理サーバは、
前記クライアント装置から前記第１のＵＲＬの発行を要求されたかを判断する判断手段と、
前記第１のＵＲＬの発行を要求されたと判断された場合に、バージョニングが有効である第１のオブジェクトストレージにダミー名で格納されるオブジェクトのロケーションを示す１つのＵＲＬを前記第１のＵＲＬとして前記クライアント装置に応答し、前記第２のＵＲＬの発行を要求されたと判断された場合に、前記バージョニングが有効でない第２のオブジェクトストレージへのＵＲＬを前記第２のＵＲＬとして前記クライアント装置に応答する応答手段と、を有する
ことを特徴とする情報処理システム。
【請求項２】
前記第１のオブジェクトストレージと前記第２のオブジェクトストレージとを有するストレージサーバを、さらに有し、
前記ストレージサーバは、
前記クライアント装置から前記データのファイルを受信する受信手段と、
前記データのファイルの送信に用いられたＵＲＬが、前記第１のＵＲＬである場合に、前記第１のＵＲＬに基づいて、前記データを、バージョン付けしながら、ダミー名のオブジェクトとして前記第１のオブジェクトストレージに格納する制御手段と、を有する
ことを特徴とする請求項１に記載の情報処理システム。
【請求項３】
前記制御手段は、前記データのファイルの送信に用いられたＵＲＬが、前記第２のＵＲＬである場合に、前記第２のＵＲＬに基づいて、前記データを、前記クライアントから送信された際のファイル名のオブジェクトとして、前記第２のオブジェクトストレージに上書きで格納する
ことを特徴とする請求項２に記載の情報処理システム。
【請求項４】
前記第１のＵＲＬと前記第２のＵＲＬとには、少なくとも、トークン情報、署名情報、または有効期限情報のうちのいずれかがパラメータとして含まれている
ことを特徴とする請求項１乃至３のいずれか１項に記載の情報処理システム。
【請求項５】
前記クライアント装置は、
前記管理サーバから応答された前記第１のＵＲＬまたは前記第２のＵＲＬへ前記データのファイルを送信する送信手段を備え、
前記送信手段は、前記第１のＵＲＬへの送信に成功した前記データのファイル名を、前記データのファイルの送信結果を示す結果ファイルに記録して、前記結果ファイルを前記第１のＵＲＬへ送信する
ことを特徴とする請求項１乃至４のいずれか１項に記載の情報処理システム。
【請求項６】
前記データの公開用のファイルを作成する公開サーバをさらに有し、
前記公開サーバは、
前記クライアントが送信した前記結果ファイルを用いて、前記第１のオブジェクトストレージに格納された前記オブジェクトに基づき、前記データの送信時のファイル名で前記公開用のファイルを作成する作成手段を備える
ことを特徴とする請求項５に記載の情報処理システム。
【請求項７】
前記作成手段は、前記クライアントが送信した前記結果ファイルを取得できない場合には、前記公開用のファイルを作成しない
ことを特徴とする請求項６に記載の情報処理システム。
【請求項８】
前記作成手段は、前記クライアントが送信した前記結果ファイルを取得できない場合に、前記第１のオブジェクトストレージに格納されている前記オブジェクトのダミー名で前記公開用のファイルを作成する
ことを特徴とする請求項５に記載の情報処理システム。
【請求項９】
前記公開サーバが有する前記作成手段は、
有効期限が切れている前記第１のＵＲＬに対応するオブジェクトを対象にして、前記公開用のファイルを作成する
ことを特徴とする請求項８に記載の情報処理システム。
【請求項１０】
クライアント装置と、前記クライアント装置から送信されるデータを管理する管理サーバとを有する情報処理システムにおけるデータ管理方法であって、
前記クライアント装置が、前記管理サーバに複数のファイル単位でデータを送信するかを判断する判断工程と、
前記クライアント装置が、前記複数のファイル単位で前記データを送信すると判断した場合に、複数のファイル単位での前記データの送信に利用する第１のＵＲＬの発行を前記管理サーバに要求し、１ファイル単位で前記データを送信すると判断された場合に、１ファイル単位での前記データの送信に利用する第２のＵＲＬの発行を前記管理サーバに要求する要求工程と、
前記管理サーバが、前記クライアント装置から前記第１のＵＲＬの発行を要求されたかを判断する判断工程と、
前記管理サーバが、前記第１のＵＲＬの発行を要求されたと判断した場合に、前記第１のＵＲＬの発行を要求されたと判断された場合に、バージョニングが有効である第１のオブジェクトストレージにおいてダミー名で格納されるオブジェクトのロケーションを示す１つのＵＲＬを前記第１のＵＲＬとして前記クライアント装置に応答し、前記第２のＵＲＬの発行を要求されたと判断された場合に、前記バージョニングが有効でない第２のオブジェクトストレージへのＵＲＬを前記第２のＵＲＬとして前記クライアント装置に応答する応答工程と、を有する
ことを特徴とするデータ管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理システムおよびデータ管理方法に関する。
【背景技術】
【０００２】
特許文献１は、クライアントのログをログ管理サーバから通知された宛先情報および認証情報に従い、ログ管理サーバとは異なるログ格納サーバへ送信するシステムを開示している。このシステムは、クライアントが、ログ管理サーバから通知されたログ格納サーバであるＷｅｂＤＡＶサーバのＵＲＬに、自デバイスのシリアル番号のフォルダ名を付与して、全てのログを送信する。ＷｅｂＤＡＶサーバでは、クライアントが任意のフォルダをＷｅｂＤＡＶサーバのＵＲＬのフォルダに作成することが可能である。これは、ＲＦＣ２５１８にその内容が記載されているように、ＷｅｂＤＡＶプロトコルが、Ｗｅｂサーバ上のファイルシステムのディレクトリ構造をモデル化し、そのモデル化されたディレクトリ内でファイルを扱うプロトコルであるからである。
【０００３】
しかし、近年、従来のフォルダやディレクトリの階層構造を持つファイルストレージではなく、階層のないフラットな構造でデータを保持するオブジェクトストレージがＷｅｂで多く利用されている。これは、クラウド基盤の必須要件であるスケールアウトを実現するため、物理的なデータの格納場所の分散を容易にするためである。例えば、アマゾン社が提供するクラウドサービス（ＡＷＳ）のＡｍａｚｏｎ  Ｓ３が、典型的なオブジェクトストレージである。
【０００４】
また、事前署名付きＵＲＬ（Ｐｒｅ−Ｓｉｇｎｅｄ  ＵＲＬ）を、認証情報を持つクライアントからのリクエストに応じて発行し、クライアントが、事前署名付きＵＲＬにデータを送信する技術が提案されている。この技術は、Ａｍａｚｏｎ  Ｓ３でも機能として提供されている。事前署名付きＵＲＬの機能を提供するＡｍａｚｏｎ  Ｓ３では、オブジェクトストレージ上の１つのオブジェクトを示すＵＲＬをクライアントに通知する。事前署名付きＵＲＬで通知されるオブジェクトストレージ上のＵＲＬには、ＷｅｂＤＡＶプロトコルのように、クライアントが任意にディレクトリを作成することができない。したがって、データ（例えばログ）のファイルを送信するクライアントは、１つの事前署名付きＵＲＬに対し、１つのログファイルのみをオブジェクトとして送信可能である。
【０００５】
同一の事前署名付きＵＲＬに複数回ログファイルのコンテンツデータを送信した場合、前回送信したデータが新たに送信したコンテンツデータで上書きされる。したがって、クライアントが、オブジェクトストレージをバックエンドの基盤として利用するクラウドストレージのインターネットサービスを事前署名付きＵＲＬを用いて利用する場合、１ファイル単位で１つの事前署名付きＵＲＬを取得する必要がある。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１５−５０８２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
従来のシステムでは、ログ管理サーバは、クライアントが送信したいファイル数とファイル名が事前に分からないので、クライアントから送信したいファイル名の情報を受け取り、この情報に対応する事前署名付きＵＲＬを発行するＷｅｂサービスの形態をとる。ログ管理サーバは、クライアントから受信したリクエストに含まれるログ種別と、ログファイル名の情報とに基づいて、クラウドストレージ上のファイルのロケーションを決定し、そのロケーションを示す事前署名付きＵＲＬをクラウドストレージから取得する。そして、ログ管理サーバは、取得した事前署名付きＵＲＬをクライアントに応答する。しかし、従来のシステムでは、クライアントは、送信したいログファイル数分の事前署名付きＵＲＬの発行リクエストをログ管理サーバに送信するので、ログ管理サーバに多大な負荷がかかる。
【０００８】
本発明は、クライアントがオブジェクトストレージに格納されるデータを複数のファイル単位で送信する場合であっても、ファイルの送信に利用するＵＲＬをクライアントに応答するサーバの負荷を抑えることができる情報処理システムの提供を目的とする。
【課題を解決するための手段】
【０００９】
クライアント装置と、前記クライアント装置から送信されるデータを管理する管理サーバとを有する情報処理システムである。前記クライアント装置は、前記管理サーバに複数のファイル単位でデータを送信するかを判断する判断手段と、前記複数のファイル単位で前記データを送信すると判断された場合に、複数のファイル単位での前記データの送信に利用する第１のＵＲＬの発行を前記管理サーバに要求し、１ファイル単位で前記データを送信すると判断された場合に、１ファイル単位での前記データの送信に利用する第２のＵＲＬの発行を前記管理サーバに要求する要求手段と、を有する。前記管理サーバは、前記クライアント装置から前記第１のＵＲＬの発行を要求されたかを判断する判断手段と、前記第１のＵＲＬの発行を要求されたと判断された場合に、バージョニングが有効である第１のオブジェクトストレージにダミー名で格納されるオブジェクトのロケーションを示す１つのＵＲＬを前記第１のＵＲＬとして前記クライアント装置に応答し、前記第２のＵＲＬの発行を要求されたと判断された場合に、前記バージョニングが有効でない第２のオブジェクトストレージへのＵＲＬを前記第２のＵＲＬとして前記クライアント装置に応答する応答手段と、を有する。
【発明の効果】
【００１０】
本発明の情報処理システムによれば、クライアントがオブジェクトストレージに格納されるデータを複数のファイル単位で送信する場合であっても、ファイルの送信に利用するＵＲＬをクライアントに応答するサーバの負荷を抑えることができる。
【図面の簡単な説明】
【００１１】
【図１】本実施形態の情報処理システムの構成を示す図である。
【図２】情報処理システムを構成する装置のハードウェア構成を示す図である。
【図３】情報処理システムのソフトウェア構成の一例を示す図である。
【図４】ＭＦＰのログ送信時の動作処理を説明するフローチャートである。
【図５】アップロード結果ファイルの一例を示す図である。
【図６】ログ管理サービスの動作処理を説明するフローチャートである。
【図７】ストレージサービスの動作処理を説明するフローチャートである。
【図８】バージョン管理機能付きオブジェクトストレージでのオブジェクトの管理例である。
【図９】公開ログファイルの作成処理の例を説明するフローチャートである。
【図１０】公開ログファイルの作成処理の例を説明するフローチャートである。
【図１１】実施例２のログ公開サービスの構成を示す図である。
【図１２】ログ公開サービスの動作処理を説明するフローチャートである。
【図１３】ログ公開サービスの動作処理を説明するフローチャートである。
【発明を実施するための形態】
【００１２】
図１は、本実施形態の情報処理システムの構成を示す図である。
図１に示す情報処理システムは、ログを管理し、管理されているログを公開するシステムであるが、本発明の適用対象となるデータは、ログに限定されない。本発明は、Ｗｏｒｄのデータなど、任意のデータを管理するデータ管理方法を実行する情報処理装置に適用可能である。
【００１３】
図１に示す情報処理システムは、ネットワーク１３１を介して接続された、ログ管理サービス１０１、ログ公開サービス１０２、ストレージサービス１０３、ＭＦＰ１１１、クライアント端末１１２、管理端末１１３を有する。ＭＦＰ、Ｍｕｌｔｉｆｕｎｃｔｉｏｎ  Ｐｅｒｉｐｈｅｒａｌの略称である。ログ管理サービス１０１、ログ公開サービス１０２、ストレージサービス１０３は、一般的にサーバコンピュータ上にて実行されており、これらサービス群が各種デバイスやユーザに対してクラウドサービスを提供する。したがって、本明細書では、これらクラウドサービスを提供する各サーバをサービスと記述する。
【００１４】
ＭＦＰ１１１、クライアント端末１１２、管理端末１１３は、それぞれ複数台接続されている。ネットワーク１３１は、例えば、インターネット等のＬＡＮ、ＷＡＮ、電話回線、専用デジタル回線、ＡＴＭやフレームリレー回線、ケーブルテレビ回線、データ放送用無線回線等のいずれか、またはこれらの組み合わせにより実現される通信ネットワークである。
【００１５】
ログ管理サービス１０１、ログ公開サービス１０２、および、ストレージサービス１０３が、クラウドサービスとして存在する場合、ネットワーク１３１は、例えば、インターネットである。また、ログ管理サービス１０１、ログ公開サービス１０２、および、ストレージサービス１０３が、イントラネット内のサービスとして存在する場合、ネットワーク１３１は、例えば、企業内ネットワークである。
【００１６】
ログ管理サービス１０１は、ＭＦＰ１１１から送信されるデータを管理する管理サーバである。この例では、ログ管理サービス１０１は、ＭＦＰ１１１にログ送信を指示すると共に、ログ送信用の事前署名付きＵＲＬ発行を行うクラウドサービスである。ログ管理サービス１０１は、ログ送信設定を行うＷｅｂＵＩを管理端末１１３向けに提供する。また、ログ管理サービス１０１は、ＷｅｂＵＩで指定されたログ送信指示設定に従い、指定されたＭＦＰ１１１に一時点分のログ送信の指示を行う。
【００１７】
ログ公開サービス１０２は、ログデータの公開用のファイルを作成する公開サーバである。具体的には、ログ公開サービス１０２は、ストレージサービス１０３から定期的に、例えば１時間に一回、ログデータを取得して、公開用のファイルを作成するクラウドサービスとして機能する。また、ログ公開サービス１０２は、ログデータの公開のため、ログデータをリスト参照およびダウンロードするＷｅｂＵＩをクライアント端末１１２向けに提供する。
【００１８】
ストレージサービス１０３は、ログデータを格納するストレージサーバである。この例では、ストレージサービス１０３は、ログ管理サービス１０１からの要求に応じ、ファイル送信用の事前署名付きＵＲＬを発行すると共に、発行した事前署名付きＵＲＬを用いたＭＦＰ１１１からのファイル送信を受け取るクラウドサービスである。ストレージサービス１０３は、受信したファイルを、ストレージサービス１０３内のオブジェクトストレージに格納する。
【００１９】
ＭＦＰ１１１は、ログ送信を行うクライアントである。ＭＦＰ１１１は、ログ管理サービス１０１からの送信指示に基づき、ログ管理サービス１０１からログファイル送信用の事前署名付きＵＲＬを取得する。ＭＦＰ１１１は、取得した事前署名付きＵＲＬを用いて、ストレージサービス１０３にログ送信を行う。
【００２０】
クライアント端末１１２は、ログ利用を行うクライアントである。クライアント端末１１２は、ログ利用者の操作に基づき、ログ公開サービス１０２のＷｅｂＵＩを介して、ログデータを参照、および、取得する。管理端末１１３は、ログ管理サービス１０１のＷｅｂＵＩを介して、ＭＦＰ１１１にログ送信の指示を行うクライアントである。管理端末１１３は、ログ管理者によって利用される。なお、ＭＦＰ１１１、クライアント端末１１２、管理端末１１３は、一般的なパーソナルコンピュータ、携帯端末などのデバイスである。
【００２１】
図２は、図１に示す情報処理システムを構成する装置のハードウェア構成を示す図である。
具体的には、図２は、ログ管理サービス１０１、ログ公開サービス１０２、ストレージサービス１０３、ＭＦＰ１１１、クライアント端末１１２、管理端末１１３のそれぞれを実現するコンピュータを示す。
【００２２】
図２に示すコンピュータは、ユーザインタフェース２０１乃至拡張ＩＦ２０８を備える。ユーザインタフェース２０１は、ディスプレイ、キーボード、マウス、タッチパネルなどによる、情報の入出力を行う。ディスプレイ、キーボード、マウス、タッチパネルなどを備えないコンピュータは、リモートデスクトップやリモートシェルなどにより、他のコンピュータから接続・操作することも可能である。ネットワークインタフェース２０２は、ＬＡＮなどのネットワークに接続して、他のコンピュータやネットワーク機器との通信を行う。ＣＰＵ２０３は、ＲＯＭ２０４、ＲＡＭ２０５、二次記憶装置２０６などから読み込んだプログラムを実行して、コンピュータ全体を制御する。ＣＰＩは、Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔの略称である。ＲＯＭは、Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙの略称である。ＲＡＭは、Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙの略称である。ＲＯＭ２０４は、組込済みプログラムおよびデータを記憶する記憶手段である。ＲＡＭ２０５は、一時メモリ領域として用いられる記憶手段である。二次記憶装置２０６は、例えばＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）である。各部は入出力インターフェース２０７を介して接続されている。拡張ＩＦ２０８は、コンピュータがＭＦＰ１１１である場合は、スキャナ、ＦＡＸなどの装置が接続される。
【００２３】
図３は、図１に示す情報処理システムのソフトウェア構成の一例を示す図である。
ログ管理サービス１０１は、データベース３３１、Ｗｅｂアプリケーション３０１を備える。データベース３３１は、管理端末１１３から設定されたＭＦＰ１１１のデバイスシリアル番号と、そのデバイスシリアル番号に対するログ送信指示の有無を、送信対象のログ種別と共に保持する。また、データベース３３１は、ログ種別とデバイスシリアル番号に応じて決まる、ストレージサービス１０３のログ格納用ＵＲＬの情報を保持する。
【００２４】
Ｗｅｂアプリケーション３０１は、ＡＰＩ３１１とＷｅｂＵＩ３２１とを備える。ＡＰＩは、Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅの略称である。ＡＰＩ３１１は、ＭＦＰ１１１からログ送信指示有無の確認を受け付け、その結果を返す機能を提供する。ログ管理サービス１０１の管理ユーザによって、該当のＭＦＰ１１１のデバイスシリアル番号に対してログ送信の指示が設定されている場合は、ＡＰＩ３１１は、送信対象のログ種別と共に、ログ送信指示有りの結果を返す。ログ送信の指示が設定されていない場合は、ＡＰＩ３１１は、ログ送信指示無しの結果を返す。また、ＡＰＩ３１１は、ＭＦＰ１１１の事前署名付きＵＲＬ取得部３７４からのリクエストを受け取り、指定されたパラメータに応じた署名付きＵＲＬをストレージサービス１０３から取得し、ＭＦＰ１１１に返す。ＡＰＩ３１１は、クライアントから事前署名付きＵＲＬの発行要求を受け受け付けるためのＡＰＩとして２種類のＡＰＩを提供する。一つは、一般的な一つのファイル送信を行なうための事前署名付きＵＲＬの発行要求を受け取るＡＰＩであり、もう一つは、複数ファイル送信用の事前署名付きＵＲＬの発行要求を受け取るＡＰＩである。ＷｅｂＵＩ３２１は、管理端末１１３からのＷｅｂブラウザ３９３を介したアクセスに応じて、ログ管理サービス１０１が提供する機能を提供する。
【００２５】
ＭＦＰ１１１は、ログ送信アプリケーション３７１、ログデータ保存部３７６を備える。ログ送信アプリケーション３７１は、ログの送信処理を実行する。ログデータ保存部３７６は、ＭＦＰ１１１のオペレーティングシステムのログ、ハードウェアのログ、ＭＦＰ１１１にインストールされた各種アプリケーションのログ、ＭＦＰ１１１のローカルＵＩの操作ログなどを保存する。
【００２６】
ログ送信アプリケーション３７１は、ログ送信管理部３７２と、ログ送信指示取得部３７３と、事前署名付きＵＲＬ取得部３７４と、ログ送信部３７５とを備える。ログ送信管理部３７２は、ＭＦＰ１１１からのログの送信処理を管理する。ログ送信指示取得部３７３は、ログ送信指示があるか否かの問い合わせを、ログ管理サービス１０１のＡＰＩ３１１に対して、定期的に行う。ログ送信指示取得部３７３は、この問い合わせを、例えば２４時間に１回行う。事前署名付きＵＲＬ取得部３７４は、ログ管理サービス１０１のＡＰＩ３１１に、事前署名付きＵＲＬの発行をリクエストする。ログ送信部３７５は、事前署名付きＵＲＬを利用して、ログのファイル（ログファイル）を送信する。
【００２７】
ストレージサービス１０３は、Ｗｅｂアプリケーション３０３、オブジェクトストレージ３４３ａ、バージョン管理機能付オブジェクトストレージ３４３ｂを備える。なお、以下の説明では、バージョン管理機能付オブジェクトストレージ３４３ｂを、単にオブジェクトストレージ３４３ｂとも記述する。Ｗｅｂアプリケーション３０３は、ネットワークを経由し、他の機器からのリクエストを処理し、必要に応じてオブジェクトストレージ３４３ａ、３４３ｂのデータにアクセスして、応答を返す。Ｗｅｂアプリケーション３０３は、ＡＰＩ３１３を有する。ＡＰＩ３１３は、オブジェクトストレージ３４３ａ，３４３ｂにデータを格納するための事前署名付きＵＲＬを発行する機能を提供する。また、ＡＰＩ３１３は、事前署名付きＵＲＬを用いてクライアントが送信したデータを受信し、そのＵＲＬが示す位置情報のメタデータを紐付けて、オブジェクトストレージ３４３ａ，３４３ｂに保存する機能を提供する。
【００２８】
バージョン管理機能付オブジェクトストレージ３４３ｂは、オブジェクトの自動バージョン管理を行う機能を有する。すなわち、バージョン管理機能付オブジェクトストレージ３４３ｂは、バージョニングが有効とされた第１のオブジェクトストレージである。バージョン管理機能付きオブジェクトストレージ３４３ｂでは、オブジェクトが上書きされる際、その新しいオブジェクトに新規のバージョン番号が付与される。古いオブジェクトは、新しいオブジェクトに上書きされた後も、そのオブジェクト自体が保存された際に付与されたバージョン番号と共にそのコンテンツが保持される。オブジェクトストレージ３４３ａは、バージョニングが有効とされていない通常のオブジェクトストレージ（第２のオブジェクトストレージ）である。オブジェクトストレージ３４３ａでは、オブジェクトが上書きされる際には、古いオブジェクトは削除され、新しいオブジェクトで置き換えられる。
【００２９】
ログ公開サービス１０２は、Ｗｅｂアプリケーション３０２、バッチプログラム３５２、ファイルストレージ３４２を備える。Ｗｅｂアプリケーション３０２は、ネットワークを経由し、他の機器からのリクエストを処理し、必要に応じてファイルストレージ３４２のデータにアクセスして、応答を返す。具体的には、Ｗｅｂアプリケーション３０２は、ファイルストレージ３４２に格納されているデータを、認証、認可されたユーザに公開する。Ｗｅｂアプリケーション３０２は、ＷｅｂＵＩ３２２を有する。
【００３０】
バッチプログラム３５２は、ストレージサービス１０３のオブジェクトストレージ３４３ａ、ｂから最新のログデータを取得し、ログ公開サービス１０２のファイルストレージ３４２にコピーする。バッチプログラム３５２は、定期的に、例えば、一時間に一回、起動する。ファイルストレージ３４２には、コピーされたログデータが格納される。
【００３１】
クライアント端末１１２は、Ｗｅｂブラウザ３９２を備える。クライアント端末１１２のユーザは、Ｗｅｂブラウザ３９２を用いて、ログ公開サービス１０２のＷｅｂＵＩ３２２にアクセスし、ログ公開サービス１０２が公開するログデータを参照することができる。
【００３２】
管理端末１１３は、Ｗｅｂブラウザ１１３を備える。ログ管理サービス１０１の管理ユーザは、Ｗｅｂブラウザ３９３を用いて、ログ管理サービス１０１のＷｅｂＵＩ３２１にアクセスする。そして、管理ユーザは、ＭＦＰ１１１のデバイスシリアル番号と、送信対象のログ種別を指定して、ＭＦＰ１１１にログ送信の指示を設定することができる。
【００３３】
Ｗｅｂアプリケーション３０１乃至３０３は、ログ管理サービス１０１、ログ公開サービス１０２、ストレージサービス１０３という各デバイスの二次記憶装置２０６に格納されており、実行時にＲＡＭ２０５に読み出され、ＣＰＵ２０３によって実行される。また、ログ管理サービス１０１が備えるデータベース３３１の管理プログラムは、二次記憶装置２０６に記憶されており、実行時にＲＡＭ２０５に読み出され、ＣＰＵ２０３よって実行される。また、データベース３３１のデータは、ログ管理サービス１０１のデバイスの二次記憶装置２０６に格納される。
【００３４】
また、ログ公開サービス１０２が備えるファイルストレージ３４２の管理プログラムは、ログ公開サービス１０２の二次記憶装置２０６に記憶されており、実行時にＲＡＭ２０５に読み出され、ＣＰＵ２０３よって実行される。ファイルストレージ３４２のデータは、ログ管理サービス１０１のデバイスの二次記憶装置２０６に格納される。また、オブジェクトストレージ３４３の管理プログラムは、ストレージサービス１０３のデバイスの二次記憶装置２０６に記憶されており、実行時にＲＡＭ２０５に読み出され、ＣＰＵ２０３よって実行される。オブジェクトストレージ３４３のデータは、ストレージサービス１０３の二次記憶装置２０６に格納される。また、ログ公開サービス１０２が備えるバッチプログラム３５２は、ログ公開サービス１０２の二次記憶装置２０６に格納されており、実行時にＲＡＭ２０５に読み出され、ＣＰＵ２０３によって実行される。また、Ｗｅｂブラウザ３９２は、クライアント端末１１２の二次記憶装置２０６に格納されており、実行時にＲＡＭ２０５に読み出され、ＣＰＵ２０３によって実行される。またＷｅｂブラウザ３９３は、管理端末１１３の二次記憶装置２０６に格納されており、実行時にＲＡＭ２０５に読み出され、ＣＰＵ２０３によって実行される。
【００３５】
また、ＭＦＰ１１１が備えるログ送信アプリケーション３７１は、ＭＦＰ１１１の二次記憶装置２０６に記憶されており、実行時にＲＡＭ２０５に読み出され、ＣＰＵ２０３によって実行される。また、ログデータ保存部３７６は、ログ送信アプリケーション３７１により、ＭＦＰ１１１の二次記憶装置２０６に構築される。
【００３６】
以下に、図３を参照して、ＭＦＰ１１１からのログ送信について説明する。ＭＦＰ１１１のログ送信アプリケーション３７１が、定期的に、例えば一日に一回、ログ管理サービス１０１にアクセスし、ログの送信指示がないかを確認する。送信指示確認は、ログ送信管理部３７２が、タイマー起動で定期的に、ログ送信指示取得部３７３にログ送信指示取得確認要求を出すことによって開始される。ログ送信指示取得部３７３は、ログ管理サービス１０１のＷｅｂアプリケーション３０１にログ送信指示確認を行う。Ｗｅｂアプリケーション３０１へのログ送信指示確認は、Ｗｅｂアプリケーション３０１のＡＰＩ３１１へのＨＴＴＰリクエストで行われる。したがって、ログ送信指示取得部３７３は、ＨＴＴＰリクエストボディに、ＭＦＰ１１１のデバイスシリアル番号をセットし、ログ送信指示確認のＨＴＴＰ  ＰＯＳＴリクエストをＡＰＩ３１１に送信する。
【００３７】
次に、ログ管理サービス１０１が備えるＷｅｂアプリケーション３０１が、ＡＰＩ３１１を介して受け取ったログ送信指示確認リクエストのリクエストボディ内のデバイスシリアル番号を取得する。Ｗｅｂアプリケーション３０１は、デバイスシリアル番号に対しての送信指示要求がデータベース３３１内にあるかを確認する。該当のデバイスシリアル番号に対しての送信指示要求のエントリ行がデータベース３３１内にある場合は、Ｗｅｂアプリケーション３０１が、ログ送信指示確認リクエストのレスポンスとして、送信対象のログ種別を返信する。送信指示要求がデータベース３３１内に存在しない場合は、Ｗｅｂアプリケーション３０１が、ログ送信指示確認リクエストのレスポンスとして空のデータを返信する。なお、送信指示要求のエントリ行の送信周期カラムの値が「一度のみ」の場合、または、定期スケジュール実行の終了日を迎えている場合は、Ｗｅｂアプリケーション３０１は、その送信指示のエントリ行を削除する。
【００３８】
ログ送信指示確認リクエストのレスポンスとして送信対象のログ種別を受信したログ送信アプリケーション３７１は、ログデータ保存部３７６に保持される指定ログ種別に該当するログファイルを、一時点分のログとして、送信する処理を開始する。一時点分のログデータとは、サーバに送信するログデータの纏まりを指し、複数のファイルから構成される。ログ利用者は、特定のクライアントからの特定の日付に収集が行われた一時点分のログデータを参照する。
【００３９】
図４は、ＭＦＰのログ送信時の動作処理を説明するフローチャートである。
Ｓ４０１において、ログ送信アプリケーション３７１のログ送信管理部３７２が、一時点分のログとして送信するファイルの数が複数であるか、つまり複数のファイル単位でログを送信するかを判断する。複数のファイル単位ではなく、１ファイル単位でログを送信する場合は、処理がＳ４１２に進む。複数のファイル単位でログを送信する場合は、処理がＳ４０２に進む。
【００４０】
Ｓ４０２において、ログ送信管理部３７２が、複数ファイル送信用の事前署名付きＵＲＬの発行を、事前署名付きＵＲＬ取得部３７４を介して、ログ管理サービス１０１のＡＰＩ３１１にリクエストする。ＡＰＩ３１１へのリクエストは、ＨＴＴＰ  ＰＯＳＴによって行なわれる。リクエストボディには、ＭＦＰ１１１のデバイスシリアル番号と、送信するログ種別という２つの情報がセットされる。
【００４１】
次に、Ｓ４０３において、ログ送信管理部３７２が、複数ファイル送信用の事前署名付きＵＲＬを、事前署名付きＵＲＬ取得部３７４を介して、ログ管理サービス１０１のＡＰＩ３１１からレスポンスとして受信する。続いて、Ｓ４０４において、ログ送信管理部３７２が、一時点分のログファイルの送信結果を示すアップロード結果ファイルをＲＡＭ２０５上に作成する。ログ送信管理部３７２は、アップロード結果ファイルに、ＭＦＰ１１１のデバイスシリアル番号、ログ種別、送信開始時間（現在時刻）の３つの情報を記録する。
【００４２】
次に、Ｓ４０５において、ログ送信管理部３７２が、ログ管理サービス１０１から取得した複数ファイル送信用の事前署名付きＵＲＬに、ログ送信部３７５を介して、一時点分のログファイルを順次送信する。送信リクエストは、ＨＴＴＰ  ＰＵＴによって行なわれる。リクエストボディには、送信するログファイルのコンテンツのみがセットされる。コンテンツは、事前署名付きＵＲＬを用いたＨＴＴＰ  ＰＵＴにより、事前署名付きＵＲＬの宛先であるストレージサービス１０３に送信される。続いて、Ｓ４０６において、ログ送信管理部３７２が、複数ファイル送信用の事前署名付きＵＲＬ宛にコンテンツ送信が成功したログファイルのファイル名をアップロード結果ファイルに順次記録する。
【００４３】
Ｓ４０７において、ログ送信管理部３７２が、一時点分のログのログファイルを全て送信したかを判断する。一時点分のログのログファイルのうち、送信していないログファイルがある場合は、処理がＳ４０５に戻る。一時点分のログファイルを全て送信した場合は、処理がＳ４０８に進む。
【００４４】
Ｓ４０８において、ログ送信管理部３７２が、アップロード結果ファイルに、送信終了時間（現在時刻）、送信データの総サイズ、送信ファイル数を記録する。そして、ログ送信管理部３７２は、複数ファイル送信用の事前署名付きＵＲＬ宛に、ログ送信部３７５を介して、アップロード結果ファイルのコンテンツを送信する。
【００４５】
また、Ｓ４１２において、ログ送信管理部３７２は、１ファイル単位でログ送信を行なうための従来の事前署名付きＵＲＬの発行を、事前署名付きＵＲＬ取得部３７４を介して、ログ管理サービス１０１のＡＰＩ３１１にリクエストする。ＡＰＩ３１１へのリクエストは、ＨＴＴＰ  ＰＯＳＴによって行なわれる。リクエストボディには、ＭＦＰ１１１のデバイスシリアル番号、送信するログ種別、および、ログファイル名の３つの情報がセットされる。
【００４６】
Ｓ４１３において、ログ送信管理部３７２が、事前署名付きＵＲＬを、事前署名付きＵＲＬ取得部３７４を介して、ログ管理サービス１０１のＡＰＩ３１１からレスポンスとして受信する。続いて、Ｓ４１４において、ログ送信管理部３７２が、ログ管理サービス１０１から取得した従来の事前署名付きＵＲＬに、ログ送信部３７５を介して、ログを送信する。送信リクエストは、ＨＴＴＰ  ＰＵＴによって行なわれる。リクエストボディには、送信するログファイルのコンテンツのみがセットされる。コンテンツは、事前署名付きＵＲＬを用いたＨＴＴＰ  ＰＵＴにより、事前署名付きＵＲＬの宛先であるストレージサービス１０３に送信される。ログ送信アプリケーション３７１のログ送信管理部３７２が、ログ送信後、処理を終了する。
【００４７】
図５は、アップロード結果ファイルの一例を示す図である。
ＣｌｉｅｎｔＩｎｆｏセクション５０２は、クライアントデバイスの情報が設定されるセクションである。ＣｌｉｅｎｔＩｎｆｏセクション５０２において、５１２はデバイスシリアル番号の値が記録されるエントリを示す。
【００４８】
５０３は、Ｓｕｍｍａｒｙセクション５０３は、アップロード結果の概要が設定されるセクションである。Ｓｕｍｍａｒｙセクション５０３において、５１２はログ種別の値が記録されるエントリである。５１３は一時点分のログファイルの送信開始日時の値が記録されるエントリである。５１４は一時点分のログファイルの送信終了日時の値が記録されるエントリである。５１５は送信された一時点分のログファイルの総ファイル数の値が記録されるエントリである。５１６は送信された一時点分のログファイルの総データ量の値が記録されるエントリである。
【００４９】
ＦｉｌｅＮａｍｅセクション５０４は、アップロードしたファイルのリストを記載するセクションである。ＦｉｌｅＮａｍｅセクション５０３において、５２０は、このアップロード結果ファイルの名前「UploadResult2016-10-17.txt」を値として持つエントリである。５２１は、Ｓ４０６で複数ファイル送信用の事前署名付きＵＲＬを用いて２００番目に送信したファイル名「DebugLog2016-10-17＿0003.log」を値として持つエントリである。５２２〜５２６は、１９９番目〜１９５番目に送信したファイル名である。５２７は、１番目に送信したファイル名「DebugLog2016-10-16＿0138.log」を値として持つエントリである。
【００５０】
図６は、事前署名付きＵＲＬ発行要求を受信したログ管理サービスの動作処理を説明するフローチャートである。
Ｓ６０１において、ログ管理サービス１０１のＷｅｂアプリケーション３０１が、ＡＰＩ３１１で受信したＭＦＰ１１１からの事前署名付きＵＲＬの発行要求が、複数のファイル単位での送信用の事前署名付きＵＲＬの発行要求であるかを判断する。事前署名付きＵＲＬの発行要求が、複数のファイル単位でなく、１ファイル単位での送信用の事前署名付きＵＲＬの発行要求である場合は、処理がＳ６１２に進む。事前署名付きＵＲＬの発行要求が、複数のファイル単位での送信用の事前署名付きＵＲＬの発行要求である場合は、処理がＳ６０２に進む。
【００５１】
Ｓ６０２において、Ｗｅｂアプリケーション３０１が、ＨＴＴＰ  ＰＯＳＴによる発行リクエストのリクエストボディにセットされたデバイスシリアル番号と、ログ種別とを取得する。Ｗｅｂアプリケーション３０１は、デバイスシリアル番号と、ログ種別と、現在時刻とに基づいて、ストレージサービス１０３のオブジェクトストレージ３４３に格納するオブジェクトのキー名の中間名を決定する。オブジェクトのキー名とは、オブジェクトストレージ内でオブジェクトを一意に識別する名前である。オブジェクトストレージは、フォルダ階層を持たない。しかし、オブジェクトのキー名をフォルダのパス名のようにセパレータ（「/ 」など）で繋げた名前にすることにより、ファイルストレージ上のファイルパスを模すことができ、キー名の中間にある文字列をフォルダ名のように見せかけることができる。また、同様に、オブジェクトのキー名の最後尾のセパレータに続く末尾の文字列を、ファイル名のように見せかけることができる。この例では、Ｗｅｂアプリケーション３０１は、例えば「DebugLog/ZZZZ98765/20161017T1000/ 」のようなキー名を中間名として決定する。
【００５２】
Ｓ６０３において、Ｗｅｂアプリケーション３０１が、ストレージサービス１０３のバージョン管理機能付きオブジェクトストレージ３４３ｂにオブジェクトを格納する際に利用するキー名を、オブジェクトのキー名の先頭名とする。Ｗｅｂアプリケーション３０１は、例えば「/StorageB 」のような文字列をキー名の先頭名とする。
【００５３】
次に、Ｓ６０４において、Ｗｅｂアプリケーション３０１が、キー名の末尾の文字列にダミー名を割り当て、オブジェクトの最終的なキー名を決定する。ファイル名相当となるダミー名の文字列は、例えば「dummy.log 」のようなファイル名の文字列を割り当てる。Ｓ６０２〜Ｓ６０４により、ファイルパス相当となるキー名は、「/StorageB/DebugLog/ZZZZ98765/20161017T1000/dummy.log」のようになる。
【００５４】
Ｓ６０５において、Ｗｅｂアプリケーション３０１が、ストレージサービス１０３のＡＰＩ３１３に、事前署名付きＵＲＬの発行を要求する。要求する事前署名付きＵＲＬは、バージョン管理機能付きオブジェクトストレージ３４３ｂに、Ｓ６０４で決定したオブジェクトのキー名のオブジェクトをＨＴＴＰ  ＰＵＴで送信可能なＵＲＬ（第１のＵＲＬ）である。事前署名付きＵＲＬは、バージョン管理機能付きオブジェクトストレージ３４３ｂにおいてダミー名で格納されるオブジェクトのロケーションを示す。Ｗｅｂアプリケーション３０１は、該当のオブジェクトストレージに対して書き込み権限が付与されていることを確認可能な情報と設定したい有効期限の情報と共に、事前署名付きＵＲＬの発行要求を送信する。なお、書き込み権限が付与されていることを確認可能な情報とは、ストレージサービス１０３が利用権限に紐付けて、事前に発行するアクセスキーなどである。
【００５５】
Ｓ６０６において、Ｗｅｂアプリケーション３０１が、ストレージサービス１０３のＡＰＩ３１３から、発行された１つの事前署名付きＵＲＬを受信する。Ｓ６０４において決定されたキー名をＵＲＬのパス名として含むストレージサービス１０３から発行される事前署名付きＵＲＬは、例えば、以下のような文字列である。
「https://storageservice.example.com/StorageB/DebugLog/ZZZZ98765/20161017T1000/dummy.log?token=AAAAAA&sig=BBBBBB&period=CCCCCC」
ＵＲＬには、少なくとも、トークン情報「token 」、署名情報「sig 」、有効期限情報「period」のうちのいずれかが、クエリーパラメータとして含まれている。
【００５６】
Ｓ６０７において、Ｗｅｂアプリケーション３０１が、ストレージサービス１０３から発行された事前署名付きＵＲＬを、ＭＦＰ１１１に、発行要求のレスポンスとして応答し、処理を終了する。Ｓ６１２において、Ｗｅｂアプリケーション３０１が、ＨＴＴＰ  ＰＯＳＴによる発行リクエストのリクエストボディにセットされたデバイスシリアル番号、ログ種別、ログファイル名の情報を取得する。Ｗｅｂアプリケーション３０１は、デバイスシリアル番号、ログ種別、ログファイル名の情報と、現在時刻とに基づいて、ストレージサービス１０３のオブジェクトストレージ３４３に格納するオブジェクトのキー名の先頭以外の文字列を決定する。Ｗｅｂアプリケーション３０１は、例えば、「OpeLog/AAAA01234/20161017T1000/OpeLog.zip 」のような文字列を、先頭名を除くキー名として決定する。
【００５７】
Ｓ６１３において、Ｗｅｂアプリケーション３０１が、ストレージサービス１０３のオブジェクトストレージ３４３ａにオブジェクトを格納する際に利用するキー名を先頭名とし、オブジェクトの最終的なキー名を決定する。Ｗｅｂアプリケーション３０１は、例えば、「/StorageA 」をオブジェクトのキー名の先頭名とし、「/StorageA/OpeLog/AAAA01234/20161017T1000/OpeLog.zip 」のようなキー名を決定する。
【００５８】
次に、Ｓ６１４において、Ｗｅｂアプリケーション３０１が、ストレージサービス１０３のＡＰＩ３１３に対して、事前署名付きＵＲＬ（第２のＵＲＬ）の発行を要求する。この事前署名付きＵＲＬは、Ｓ６１３で決定したオブジェクトのキー名のオブジェクトをストレージサービス１０３のオブジェクトストレージ３４３ａにＨＴＴＰ  ＰＵＴで送信可能なＵＲＬである。以降の処理は、複数ファイル送信用の事前署名付きＵＲＬ発行時と同様である。
【００５９】
図７は、事前署名付きＵＲＬを用いたコンテンツ受信時のストレージサービスの動作処理を説明するフローチャートである。
Ｓ７０１において、ストレージサービス１０３のＷｅｂアプリケーション３０３が、ＰＵＴリクエストで指定された事前署名付きＵＲＬのクエリーパラメータに含まれる情報を取得する。具体的には、トークン情報「token 」、署名情報「sig 」、ＵＲＬ の有効期限情報「period」が取得される。Ｗｅｂアプリケーション３０３は、ＡＰＩ３１１を介して、トークン情報、署名情報、ＵＲＬの有効期限情報を取得する。
【００６０】
次に、Ｓ７０２において、Ｗｅｂアプリケーション３０３が、クエリーパラメータとして受信したトークン情報、署名情報、ＵＲＬの期限情報を検証し、指定された事前署名付きＵＲＬが有効か否かを判定する。事前署名付きＵＲＬが、期限切れや、改ざんなどの理由で、無効なものであると判定された場合は、処理がＳ７１１に進む。Ｓ７１１において、Ｗｅｂアプリケーション３０３が、ＡＰＩ３１３を介して、リクエスト拒否を示すＨＴＴＰステータスコード４００または４０３をレスポンスとしてクライアントに返し、リクエストボディに含まれていたコンテンツを廃棄し、処理を終了する。
【００６１】
事前署名付きＵＲＬが有効効であると判定された場合は、処理がＳ７０４に進む。Ｓ７０４において、Ｗｅｂアプリケーション３０３が、事前署名付きＵＲＬに含まれるパス名をオブジェクトのキー名として抽出する。具体的には、以下の事前署名付きＵＲＬから以下のキー名を取り出す。
事前署名付きＵＲＬ：「https://storageservice.example.com/StorageB/DebugLog/ZZZZ98765/20161017T1000/dummy.log?token=AAAAAA&sig=BBBBBB&period=CCCCCC」
キー名：「/StorageB/DebugLog/ZZZZ98765/20161017T1000/dummy.log」
【００６２】
Ｓ７０５において、Ｗｅｂアプリケーション３０３が、事前署名付きＵＲＬから取得したオブジェクトのキー名の先頭名が、バージョン管理機能付きオブジェクトストレージ３４３ｂを示すかを判定する。キー名の先頭名が、バージョン管理機能付きオブジェクトストレージ３４３ｂを示す場合は、処理がＳ７０６に進む。
【００６３】
Ｓ７０６において、Ｗｅｂアプリケーション３０３が、キー名に対応する最新バージョンのオブジェクトとして、リクエストボディに含まれていたコンテンツをバージョン管理機能付きオブジェクトストレージ３４３ｂに格納する。同一のキー名に対応するオブジェクトが、すでにバージョン管理機能付きオブジェクトストレージ３４３ｂに存在していた場合、Ｗｅｂアプリケーション３０３は、そのオブジェクトとは別のオブジェクトとしてコンテンツを格納する。バージョン管理機能付きオブジェクトストレージ３４３ｂでは、キー名に加え、オブジェクトにユニークなバージョンＩＤを付与することで、オブジェクトストレージ内で一意にオブジェクトを区別できるようにする。すでに同一のキー名のオブジェクトが存在していた場合、一つ前のバージョンと最新バージョンのオブジェクトは、バージョンＩＤで区別され、異なるオブジェクトとして、それぞれ個別に扱うことができる。
【００６４】
例えば、すでに同一キー名の以下のオブジェクトがバージョン管理機能付きオブジェクトストレージ３４３ｂ内に存在していた場合を想定する。
キー名：/StorageB/DebugLog/ZZZZ98765/20161017T1000/dummy.log
バージョンＩＤ：０００１
この場合には、Ｗｅｂアプリケーション３０３は、以下のようなユニークなバージョンＩＤを新たなオブジェクトに付与して、既存のオブジェクトと別に格納する。
キー名：/StorageB/DebugLog/ZZZZ98765/20161017T1000/dummy.log
バージョンＩＤ：０００２
つまり、Ｗｅｂアプリケーション３０３は、ログファイルのコンテンツをバージョン付けしながらダミー名のオブジェクトとしてバージョン管理機能付きオブジェクトストレージ３４３ｂに格納していく。
【００６５】
次に、Ｓ７０７において、Ｗｅｂアプリケーション３０３のＡＰＩ３１３が、コンテンツ格納の成功を示すＨＴＴＰステータスコード２０１をレスポンスとしてＭＦＰ１１１に返し、処理を終了する。
【００６６】
Ｓ７０５における判定処理で、キー名の先頭名がバージョン管理機能付きオブジェクトストレージ３４３ｂではなく、オブジェクトストレージ３４３ａを示すと判定された場合は、処理がＳ７２１に進む。
【００６７】
Ｓ７２１において、Ｗｅｂアプリケーション３０３が、リクエストボディに含まれていたコンテンツを、キー名に対応するオブジェクトとしてオブジェクトストレージ３４３ａに格納する。図６のＳ６１３において決定されるキー名（例えば「/StorageA/OpeLog/AAAA01234/20161017T1000/OpeLog.zip 」) には、ＭＦＰ１１１から送信されるログファイルのファイル名が含まれている。したがって、オブジェクトストレージ３４３ａには、当該ファイル名でオブジェクトが格納されることとなる。同一のキー名のオブジェクトが、すでにオブジェクトストレージ３４３ａに存在していた場合、その古いオブジェクトのコンテンツを、リクエストボディに含まれていたコンテンツで上書きして格納する。すなわち、古いオブジェクトを削除し、新しいオブジェクトで置き換える。そして、処理がＳ７０７に進む。
【００６８】
図８は、バージョン管理機能付きオブジェクトストレージでのオブジェクトの管理例である。
図８において、８２０乃至８２７は、オブジェクトを示す。各オブジェクトは、それぞれ、コンテンツ８３０乃至８３７を持つ。また、オブジェクト８２０乃至８２７は、それぞれ、キー名、バージョンＩＤ、コンテンツタイプなどのメタデータを持つ。
【００６９】
図８は、図５のアップロード結果ファイルが示すアップロード結果に対応しており、ＭＦＰ１１１による複数ファイル送信用の事前署名付きＵＲＬを用いたログファイルを送信後のオブジェクトの状況を示している。
オブジェクト８２７は、図５のアップロード結果ファイルにおけるファイル名５２７に対応している。そのコンテンツ８３７には、一時点分のログファイルとしてＭＦＰ１１１から最初に送信された「DebugLog2016-10-16＿0138.log」のコンテンツが格納されている。
【００７０】
オブジェクト８２７には、バージョンＩＤ「０００１」がメタデータとして付与されている。オブジェクト８２１は、図５のファイル名５２１に対応している。そのコンテンツ８３１には、複数ファイル送信用の事前署名付きＵＲＬを用いて２００番目に送信されたファイル「DebugLog2016-10-17＿0003.log」のコンテンツが、バージョンＩＤ「０２００」のメタデータと共に格納されている。オブジェクト８２２乃至８２６に関しても同様であり、それぞれ、ファイル名５２２乃至５２６に対応している。それらのコンテンツ８３２乃至８３６には、ＭＦＰ１１１が複数ファイル送信用の事前署名付きＵＲＬを用いて、１９９乃至１９５番目に送信したファイルのコンテンツが格納されている。各オブジェクトは、それぞれのバージョンＩＤ「０１９９」乃至「０１９５」のメタデータを持つ。
【００７１】
オブジェクト８２０は、一時点分のログファイルとしてＭＦＰ１１１から最後に送信されたアップロード結果ファイル「UploadResult2016-10-17.txt」のコンテンツが、格納されている。このコンテンツは、バージョンＩＤ「０２００」のメタデータと共に格納されている。上記のバージョンＩＤ「０００１」は、キー名「キー名：/StorageB/DebugLog/ZZZZ98765/20161017T1000/dummy.log」における最初の（最古の）バージョンＩＤである。バージョンＩＤ「０２０１」は、同キー名における最後の（最新の）バージョンＩＤである。
【００７２】
図９および図１０は、ログ公開サービスによる公開ログファイルの作成処理の例を説明するフローチャートである。
ログ公開サービス１０２は、ストレージサービス１０３から定期的にログデータを取得し、フォルダ形式でそのログデータを公開可能にする。バージョン管理機能付きオブジェクトストレージ３４３ｂには、オブジェクトのキー名として、「dummy.log 」のようなダミー名が、ファイル名に相当する部分に付けられており、しかも、そのキー名のオブジェクトが複数存在する。したがって、ストレージサービス１０３からオブジェクトのデータを単純にファイルとしてコピーするだけでは不十分である。ＭＦＰ１１１から送信されたファイル名で、ログデータを利用するユーザ向けにファイルを公開する必要がある。この例では、Linux（登録商標） のCronなどによる定期起動で、ログ公開サービス１０２のバッチ３５２が公開ログファイルの作成を開始したときの動作を例にとって説明する。
【００７３】
Ｓ９０１において、ログ公開サービス１０２のバッチ３５２が、ストレージサービス１０３のＡＰＩ３１３に、指定日時以降に新たに格納されたオブジェクトのリスト一覧の送信をＨＴＴＰ  ＧＥＴによるリクエストで要求する。日時指定は、リクエストＵＲＬのクエリーパラメータで行う。バッチ３５２は、前回リスト取得時からの差分取得のため、前回起動時に取得リクエストを送信した日時をパラメータの値として指定する。また、バッチ３５２は、次回起動時の差分取得のために、今回リクエストを送信した現在日時を、二次記憶装置２０６に格納する。
【００７４】
次に、Ｓ９０２において、バッチ３５２が、ストレージサービス１０３のＡＰＩ３１３から、前回取得時以降にストレージサービス１０３に新たに格納（追加、変更）されたオブジェクトのキー名と、その保存時刻のリスト一覧を受信する。続いて、Ｓ９０３において、バッチ３５２が、ストレージサービス１０３のＡＰＩ３１３から取得したオブジェクトのキー名のリスト一覧を元に、オブジェクトのコンテンツデータの取得を開始する。
【００７５】
次に、Ｓ９０４において、バッチ３５２が、ストレージサービス１０３のＡＰＩ３１３に、取得したオブジェクトのキー名のリストにある一つのキー名を指定し、そのオブジェクトのコンテンツ送信を、ＨＴＴＰ  ＧＥＴによるリクエストで要求する。バッチ３５２、リクエストＵＲＬのクエリーパラメータに、キー名を設定してリクエストを行う。
【００７６】
次に、Ｓ９０５において、バッチ３５２が、ストレージサービス１０３のＡＰＩ３１３から、指定キー名のオブジェクトのコンテンツを受信する。続いて、Ｓ９０６において、バッチ３５２が、指定キー名の先頭名が、バージョン管理機能付きオブジェクトストレージ３４３ｂを示すかを判断する。指定キー名の先頭名が、バージョン管理機能付きオブジェクトストレージ３４３ｂを示さない場合、すなわちオブジェクトストレージ３４３ａを示す場合は、処理がＳ９３１に進む。Ｓ９３１において、バッチ３５２が、受信した指定キー名のオブジェクトのコンテンツをファイルストレージ３４２に、指定キー名に対応するパス名およびファイル名で格納する。そして、処理が図１０のＳ９１８に進む。
【００７７】
指定キー名の先頭名が、バージョン管理機能付きオブジェクトストレージ３４３ｂを示す場合は、処理がＳ９０７に進む。Ｓ９０７において、バッチ３５２が、受信した指定キー名のオブジェクトのコンテンツをアップロード結果ファイルとして解析する。具体的には、ＣｌｉｅｎｔＩｎｆｏセクション５０２、Ｓｕｍｍａｒｙセクション５０３、ＦｉｌｅＮａｍｅセクション５０４の各セクションが存在するか否かを判定する。なお、バージョンＩＤ指定なしで、バージョン管理機能付きオブジェクトストレージ３４３ｂに格納されるオブジェクトのコンテンツ取得のリクエストを受信した場合、ストレージサービス１０３のＡＰＩ３１３は、以下の処理を実行する。ＡＰＩ３１３は、指定されたキー名の最新バージョンのオブジェクトのコンテンツを返す。したがって、Ｓ９０７で解析されるオブジェクトのコンテンツは、該当のキー名の最新バージョンのオブジェクトのコンテンツである。
【００７８】
次に、Ｓ９０８において、バッチ３５２が、受信したオブジェクトのコンテンツがアップロード結果ファイルであるかを判定する。受信したオブジェクトのコンテンツがアップロード結果ファイルでない場合は、処理がステップＳ９４１に進む。Ｓ９４１において、バッチ３５２が、指定キー名のオブジェクトが、正常なアップロード結果のオブジェクトでないと判断して、処理をスキップし、公開用のファイルを作成しない。そして、処理が図１０のＳ９１８に進む。受信したオブジェクトのコンテンツが、アップロード結果ファイルである場合は、処理がＳ９０９に進む。Ｓ９０９において、バッチ３５２が、アップロード結果ファイルであると判断したオブジェクトのコンテンツのＦｉｌｅＮａｍｅセクション５０４を参照し、最初のエントリの値を取得する。図５に示す例では、ＦｉｌｅＮａｍｅセクション５０４の最初のエントリ５２０は、アップロード結果ファイルの名前「UploadResult2016-10-17.txt」を値として持つ。
【００７９】
次に、Ｓ９１０において、バッチ３５２が、ファイルストレージ３４２に、指定キー名に対応するディクレトリ階層を作成し、エントリ５２０の値の文字列をファイル名として、アップロード結果ファイル自体のコンテンツをファイルとして格納する。すなわち、パス名「/StorageB/DebugLog/ZZZZ98765/20161017T1000/UploadResult2016-10-17.txt 」のファイルをファイルストレージ３４２に作成する。続いて、Ｓ９１１において、バッチ３５２が、ストレージサービス１０３のＡＰＩ３１３に、該当のキー名のオブジェクトのバージョンＩＤ一覧の取得を、ＨＴＴＰ  ＧＥＴによるリクエストで要求する。バッチ３５２は、リクエストＵＲＬのクエリーパラメータで、キー名、リストのソート順を保存時刻の新しい順に設定してリクエストを行う。
【００８０】
次に、Ｓ９１２において、バッチ３５２が、ストレージサービス１０３のＡＰＩ３１３から、指定キー名のオブジェクトのバージョンＩＤの一覧を受信する。続いて、Ｓ９１３において、バッチ３５２が、ストレージサービス１０３のＡＰＩ３１３に、該当のキー名の一つ前のバージョンのオブジェクトのコンテンツ取得を、ＨＴＴＰ  ＧＥＴによるリクエストで要求する。バッチ３５２は、リクエストＵＲＬのクエリーパラメータで、キー名、バージョンＩＤを設定してリクエストを行う。
【００８１】
Ｓ９１４において、バッチ３５２が、ストレージサービス１０３のＡＰＩ３１３から、指定キー名および指定バージョンＩＤのオブジェクトのコンテンツを受信する。続いて、Ｓ９１５において、バッチ３５２が、アップロード結果ファイルのコンテンツのＦｉｌｅＮａｍｅセクション５０４の次のエントリの値を取得する。ＦｉｌｅＮａｍｅセクション５０４の最初のエントリ５２０の次のエントリ５２１には、ＭＦＰ１１１が２００番目に送信したファイル名「DebugLog2016-10-17＿0003.log」が値として格納されている。
【００８２】
次に、Ｓ９１６において、バッチ３５２が、ファイルストレージ３４２の、指定キー名に対応するディクレトリ階層に、エントリ５２１の値の文字列をファイル名として、Ｓ９１４で取得したコンテンツをファイルとして格納する。すなわち、パス名「/StorageB/DebugLog/ZZZZ98765/20161017T1000/DebugLog2016-10-17＿0003.log」のファイルをファイルストレージ３４２に作成する。これにより、ＭＦＰ１１１によるログデータの送信時のファイル名で公開用のファイルが作成される。
【００８３】
次に、Ｓ９１７において、バッチ３５２が、Ｓ９１２で取得した、指定キー名のオブジェクトのバージョンＩＤ一覧にある全てのバージョンを処理済みかを判定する。未処理のバージョンがある場合は、処理がＳ９１３に戻る。全てのバージョンを処理済みである場合は、処理がＳ９１８に進む。具体的には、バッチ３５２は、バージョンＩＤ「０００１」のオブジェクト８２７を、ファイルストレージ３４２に「DebugLog2016-10-16＿0138.log」のファイル名で格納し終えるまで、処理を続ける。
【００８４】
Ｓ９１８において、バッチ３５２が、Ｓ９０２で取得したオブジェクトのキー名のリストにある全てのオブジェクトを処理済みかを判定する。未処理のオブジェクトがある場合は、処理がＳ９０４に戻る。全てのオブジェクトを処理済みである場合は、処理を終了する。
【００８５】
本実施例の情報処理システムは、一般的なオブジェクトストレージのバージョン管理機能を用いて、一つのオブジェクトに、複数の異なるログファイルのコンテンツを、バージョンを上げながら順に格納していく。ＭＦＰ１１１は、一度のみ、事前署名付きＵＲＬを取得すれば良く、取得した一つの事前署名付きＵＲＬで一時点分のログファイルをすべて送信することができる。したがって、事前署名付きＵＲＬをＭＦＰ１１１に応答するログ管理サービス１０１の負荷が軽減する。また、ＭＦＰ１１１にとって、ログ送信の負荷が軽減する。
【００８６】
（実施例２）
以下に、実施例２の情報処理システムについて説明する。実施例１では、図９のＳ９０８の判断処理で、バージョン管理機能付きオブジェクトストレージ３４３ｂに格納される最新オブジェクトが、アップロード結果ファイルではない場合は、処理をスキップした。
【００８７】
最新オブジェクトがアップロード結果ファイルでない場合として、２つの場合がある。一つ目は、図４のＳ４０５における、ＭＦＰ１１１からストレージサービス１０３への一時点分のログデータ送信が何らかの原因で途中終了した場合である。ログデータ送信が何らかの原因で途中終了した場合、図４のＳ４０８におけるアップロード結果ファイルの送信が未実施となる。ログデータ送信が途中終了する原因としては、ＭＦＰ１１１の電源断、ネットワーク断、ストレージサービスのサーバダウンなどの要因が考えられる。
【００８８】
二つ目は、クライアントからの一時点分のログデータ送信がまだ処理中の場合である。Ｓ４０５乃至Ｓ４０７のループ処理を実行中で、Ｓ４０８の処理を完了してない場合、アップロード結果ファイルの送信が未実施の状態となる。上記２つのいずれかの場合に、アップロード結果ファイルの送信が未実施で、そのコンテンツがバージョン管理機能付きオブジェクトストレージ３４３ｂに存在しない状況が生じる。実施例１のログ公開サービス１０２では、ダミー名で格納されているオブジェクトの各バージョンのコンテンツの本来の名前が分からないため、該当のオブジェクトのファイルストレージ３４２へのコピー処理をスキップした。実施例２では、アップロード結果ファイルの送信が未実施の場合においても、公開ログファイルを作成できるようにする。
【００８９】
図１１は、実施例２のログ公開サービスの構成を示す図である。
実施例２において、ログ公開サービス１０２は、実施例１の構成（図３）に加え、新たにオブジェクトストレージ３４４を備える。オブジェクトストレージ３４４の管理プログラムは、ログ公開サービス１０２のデバイスの二次記憶装置２０６に記憶されており、実行時にＲＡＭ２０５に読み出され、ＣＰＵ２０３によって実行される。オブジェクトストレージ３４４のデータは、ログ公開サービス１０２の二次記憶装置２０６に格納される。
【００９０】
図１２および図１３は、実施例２におけるログ公開サービスの動作処理を説明するフローチャートである。
図１２のＳ１００１において、ログ公開サービス１０２のバッチ３５２が、事前署名付きＵＲＬの発行要求をストレージサービス１０３に対して行う際に設定している有効期限の値を、ログ管理サービス１０１のＡＰＩ３１１に対して要求する。具体的には、バッチ３５２は、有効期限の値を、ＨＴＴＰ  ＧＥＴによるリクエストで要求する。
【００９１】
Ｓ１００２において、バッチ３５２が、ＡＰＩ３１１から、事前署名付きＵＲＬの有効期限の値を受信する。バッチ３５２は、例えば、１２０分という値を有効期限の値として受信する。
【００９２】
次に、Ｓ１００３において、バッチ３５２が、ストレージサービス１０３のオブジェクトストレージ３４３に格納されているオブジェクトを、ログ公開サービス１０２のオブジェクトストレージ３４４に同期する処理を行う。オブジェクトの同期処理は、Linuxのrsyncコマンドのように、コピー元ディレクトリとコピー先ディレクトリを同期させる処理である。この同期処理では、既にコピー先にコピーされている同一のオブジェクトはコピーされず、追加、更新されたオブジェクトのみがコピー先にコピーされる。また、複数のバージョンがオブジェクトに存在している場合であっても、その最新のバージョンしかコピーされない。
【００９３】
次に、Ｓ１００４において、バッチ３５２が、現在日時から事前署名付きＵＲＬの有効期限の値を引き算する。算出された値は、現在時刻起点で、有効期限が切れている事前署名付きＵＲＬの最新発行日時を示す。以下では、有効期限が切れている事前署名付きＵＲＬの最新発行日時を、期限切れＵＲＬの最新発行日時と記述する。続いて、Ｓ１００５において、バッチ３５２が、ログ公開サービス１０２のオブジェクトストレージ３４４から、最終更新日時が、期限切れＵＲＬの最新発行日時以前であって、前回算出した期限切れＵＲＬの最新発行日時以降であるオブジェクトを検索する。バッチ３５２は、検索結果のキー名の一覧を処理対象オブジェクトのリスト一覧としてＲＡＭ２０５上に作成する。また、バッチ３５２は、今回算出した期限切れＵＲＬの最新発行日時を、二次記憶装置２０６に格納する。
【００９４】
Ｓ１００６において、バッチ３５２が、処理対象オブジェクトのリスト一覧にある各キー名に関して、以下のステップで、ファイルストレージ３４２へのファイル作成の処理を開始する。Ｓ１００７において、バッチ３５２が、現在の処理対象のキー名に関し、そのキー名に対応するオブジェクトのコンテンツをオブジェクトストレージ３４４から取得する。続いて、Ｓ１００８において、バッチ３５２が、オブジェクトストレージ３４４から取得したオブジェクトのコンテンツに関し、図９のＳ９０７での処理と同様に、アップロード結果ファイルとして解析する。
【００９５】
Ｓ１００９において、バッチ３５２が、オブジェクトのコンテンツがアップロード結果ファイルであるかを判断する。オブジェクトのコンテンツがアップロード結果ファイルでない場合は、処理が図１３のＳ１０２１に進む。オブジェクトのコンテンツがアップロード結果ファイルである場合は、処理がＳ１０１０に進む。
【００９６】
Ｓ１０１０において、バッチ３５２が、図９のＳ９０９乃至図１０のＳ９１７と同様の処理を実行する。すなわち、バッチ３５２は、オブジェクトの各バージョンのコンテンツを、ファイルストレージ３４２の現在の処理対象のキー名に対応するディクレトリ階層に、アップロード結果ファイルから取得したファイル名でそれぞれ格納していく。バッチ３５２が、現在の処理対象のキー名のオブジェクトのすべてのバージョンに関して処理を完了した後に、処理がＳ１０１１に進む。
【００９７】
次に、Ｓ１０１１において、バッチ３５２が、Ｓ１００４で作成した処理対象オブジェクトのリスト一覧にある全てのキー名を処理済みであるかを判断する。全てのキー名を処理済みである場合は、処理を終了する。未処理のキー名がある場合は、処理がＳ１００７に戻る。
【００９８】
図１３のＳ１０２１において、バッチ３５２が、図１０のＳ９１１およびＳ９１２と同様の処理を実行する。すなわち、バッチ３５２は、現在の処理対象のキー名のすべてのオブジェクトのバージョンＩＤ一覧を取得する。続いて、Ｓ１０２２において、バッチ３５２が、バージョンＩＤ一覧における、最初つまり最古のバージョンＩＤから昇順に、オブジェクトのコンテンツ取得を、ストレージサービス１０３のＡＰＩ３１３に要求する。この要求は、ＨＴＴＰ  ＧＥＴによるリクエストで行われる。
【００９９】
Ｓ１０２３において、バッチ３５２が、図１０のＳ９１３と同様に、ストレージサービス１０３のＡＰＩ３１３から、指定キー名および指定バージョンＩＤのオブジェクトのコンテンツを受信する。Ｓ１０２４において、バッチ３５２が、現在の処理対象のキー名に対応するパス名の最後に開始番号０００１から始まる連番を付与して、Ｓ１０２３で取得したコンテンツをファイルストレージ３４２にファイルとして格納する。バッチ３５２は、例えば、パス名「/StorageB/DebugLog/ZZZZ98765/20161017T1000/dummy.log0001」というファイルをファイルストレージ３４２に作成する。これにより、バージョン管理機能付きオブジェクトストレージ３４３ｂに格納されているオブジェクトのダミー名で公開用のファイルが作成される。
【０１００】
Ｓ１０２５において、バッチ３５２が、Ｓ１０２１で取得した指定キー名のオブジェクトのバージョンＩＤ一覧にある全てのバージョンを処理済みであるかを判断する。未処理のバージョンがある場合は、処理がＳ１０２２に戻る。全てのバージョンを処理済みである場合は、処理がＳ１０１１に進む。なお、本実施例において、複数ファイル送信用の事前署名付きＵＲＬで、最初に送信するコンテンツとして、送信予定のファイルリストを送信しておくように構成してもよい。この構成によると、アップロード結果ファイルがない場合でも、ログ公開サービス１０２での元のファイル名への回復が可能となる。
【０１０１】
実施例２の情報処理システムによれば、一時点分のログデータ送信が何らかの原因で途中終了した場合、ダミー名でコンテンツをファイルとして公開することができる。したがって、クライアントから送信されて格納されたデータ（例えばデバッグログ）を至急欲しているユーザにとって有用である。また、実施例２では、ログ公開サービス１０２は、新たなバージョンのオブジェクトを送信可能な事前署名付きＵＲＬの有効期限が切れているオブジェクトのみを対象に処理する。したがって、クライアントがまだ送信処理中の一時点分のログファイルがユーザに公開されるのを防ぐことができる。
【０１０２】
（その他の実施形態）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【図１】
2018101294.tif 000003
【図２】
2018101294.tif 000004
【図３】
2018101294.tif 000005
【図４】
2018101294.tif 000006
【図５】
2018101294.tif 000007
【図６】
2018101294.tif 000008
【図７】
2018101294.tif 000009
【図８】
2018101294.tif 000010
【図９】
2018101294.tif 000011
【図１０】
2018101294.tif 000012
【図１１】
2018101294.tif 000013
【図１２】
2018101294.tif 000014
【図１３】
2018101294.tif 000015