JP2022041717A - 情報処理システム、情報処理システムの制御方法 - Google Patents

Abstract

【課題】 仮想マシンのブラウザがＷｅｂページを解釈して処理を行う間に生成されるファイルを他の仮想マシンとの間で共有可能にするための技術を提供すること。【解決手段】 仮想マシンは、ブラウザと、該ブラウザがＷｅｂページを解釈して処理を行う間に生成されるファイルを、該仮想マシンが有する記憶領域とは異なり、該仮想マシンと異なる他の仮想マシンと共有可能なストレージに対して出力する。【選択図】 図４

Description

本発明は、ブラウザがＷｅｂページを解釈して処理を行う間に生成されるファイルの処理技術に関するものである。

現在、Ｗｅｂブラウザ（以下、ブラウザと称する）を搭載し、ブラウザ上でＷｅｂページを閲覧できる機能を有する通信端末が普及している。ブラウザを通して外部サービスのＷｅｂページを表示することにより、通信端末が外部サービスと連携できるようになる。

ところで、ブラウザの形態として、クラウドサーバ上でＷｅｂページの描画結果を生成するクラウドブラウザと呼ばれる形態がある。クラウドブラウザによれば、Ｗｅｂページの解析処理や実行処理といった計算負荷の高い処理をサーバ上で実行することにより、通信端末に計算負荷がかからなくなる。

クラウドブラウザでは、ブラウザはクラウドサーバ上で稼働する仮想マシン上で稼働する。仮想マシンには、ＰＣに必要とされる様々な機器リソースが仮想的に割り当てられる。このため、仮想マシン上で稼働するブラウザは、ＰＣ上で稼働する場合と同じように動作することができる。クラウドブラウザの中には、プライバシーにかかわる情報を扱うか否かによって起動するブラウザの種類を切り替える手法が提案されている（特許文献１）。

特許第６３６９０４３号

特許文献１では、複数の通信端末に対して、単一の仮想マシン上で稼働するブラウザを利用していた。しかしながら、クラウドブラウザの可用性や耐久性を担保する施策を実施した場合、ローカルファイルを操作するＷｅｂ標準技術が正しく動作しなくなる、という問題があった。

例えば、クラウドブラウザの可用性や耐久性を担保するために、クラウドサーバ上に仮想マシンを複数用意して、ロードバランサにより利用する仮想マシンを振り分ける場合を考える。具体的には、仮想マシンＡと仮想マシンＢが用意されているとする。このとき、仮想マシンＡと仮想マシンＢとで同じブラウザが稼働している。

このとき、ブラウザが表示するＷｅｂページがｌｏｃａｌＳｔｏｒａｇｅと呼ばれるＷｅｂ標準仕様（以下、ローカルストレージ）を利用しているとする。ローカルストレージを利用すると、ブラウザはローカルファイルを生成し、その中にＷｅｂページが指定する情報を記録する。ローカルストレージは広く普及している仕様である。ローカルストレージは、ＨＴＭＬ５から規定されたＡＰＩであり、ユーザのデータをブラウザ(ローカル環境)に保存することができる仕組みである。ここで、ローカルファイルとは、Ｗｅｂ標準仕様であるローカルストレージなどに従って、ブラウザ内（ローカル環境）に記憶すべきファイルである。

ここで、通信端末が最初にクラウドブラウザを利用したとき、ロードバランサは仮想マシンＡに処理を依頼したとする。このときブラウザは仮想マシンＡ上にローカルファイルを生成し、その中にＷｅｂページの情報を記録する。ここで、通信端末が２度目にクラウドブラウザを利用したとき、ロードバランサは仮想マシンＢに処理を依頼したとする。このときブラウザは仮想マシンＢ上でローカルファイルを参照するが、仮想マシンＢ上にローカルファイルは存在しないため、ローカルストレージが意図した挙動とならない。

このため、複数の仮想マシン上でクラウドブラウザを稼働させる際に、どの仮想マシン上でブラウザが稼働しても、既存のローカルファイルを参照できる方法が望まれている。本発明では、仮想マシンのブラウザがＷｅｂページを解釈して処理を行う間に生成されるファイルを他の仮想マシンとの間で共有可能にするための技術を提供する。

本発明の一様態は、情報処理システムであって、仮想マシンを有し、前記仮想マシンは、ブラウザと、前記ブラウザがＷｅｂページを解釈して処理を行う間に生成されるファイルを、前記仮想マシンが有する記憶領域とは異なり、前記仮想マシンと異なる他の仮想マシンと共有可能なストレージに対して出力する出力部とを備えることを特徴とする。

本発明の構成によれば、仮想マシンのブラウザがＷｅｂページを解釈して処理を行う間に生成されるファイルを他の仮想マシンとの間で共有可能にすることができる。

仮想マシンのハードウェア構成例を示すブロック図。 従来のクラウドブラウザのシステムの構成例を示すブロック図。 従来のクラウドブラウザの可用性を向上させるシステムの構成例を示すブロック図。 第１の実施形態に係るクラウドブラウザのシステムの構成例を示すブロック図。 画像生成システム４００の動作を示すフローチャート。 ローカルファイルを生成して保持している画像生成システム４００の動作を示すフローチャート。 第２の実施形態に係るクラウドブラウザのシステムの構成例を示すブロック図。 第２の実施形態に係る画像生成システム７００の動作を示すフローチャート。 （Ａ）は問い合わせ画面の表示例を示す図、（Ｂ）は警告画面の表示例を示す図。 第３の実施形態に係るクラウドブラウザのシステムの構成例を示すブロック図。 第３の実施形態に係る画像生成システム１０００の動作を示すフローチャート。 図１１のフローチャートに従った処理の後における画像生成システム１０００の動作を示すフローチャート。 変形例に係るクラウドブラウザのシステムの構成例を示すブロック図。 変形例に係る画像生成システム１３００の動作を示すフローチャート。 第４の実施形態に係るクラウドブラウザのシステムの構成例を示すブロック図。 第４の実施形態に係る画像生成システム１５００の動作を示すフローチャート。

以下、添付図面を参照して実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る発明を限定するものではない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一若しくは同様の構成に同一の参照番号を付し、重複した説明は省略する。

［第１の実施形態］
本実施形態では、ブラウザがＷｅｂページを解釈して処理を行う間に生成されるローカルファイルを、仮想マシンが有する記憶領域とは異なる複数のストレージのうち、該ローカルファイルのデータ型（データ形式）に対応するストレージに保存する。本実施形態で取り扱うローカルファイルのデータ形式は、キーバリュー形式、ドキュメント形式、オブジェクト形式、であるものとするが、これらに限らない。ローカルファイルのデータ形式に応じて該ローカルファイルの保存先（ストレージ）を切り替えることは、システムのメンテナンス性の向上、読込速度の向上、ストレージの利用料金の低減、などに繋がる。ここで、ローカルファイルとは、Ｗｅｂ標準仕様であるローカルストレージなどに従って、ブラウザ内（ローカル環境）に記憶すべきファイルである。また、ローカルファイルは、Ｗｅｂ標準仕様であるｓｅｓｓｉｏｎＳｔｏｒａｇｅに従って、ブラウザ内（ローカル環境）に記憶すべきファイルであってもよい。即ち、ローカルファイルは、Ｗｅｂ標準仕様であるＷｅｂ Ｓｔｏｒａｇｅにしたがって記憶されるファイルであってもよい。

ここで、Ｗｅｂ標準技術によって仮想マシンにて生成されるキーバリュー形式のローカルファイルの保存先としては、ローカルストレージがある。一方で、Ｗｅｂ標準技術によって仮想マシンにて生成されるオブジェクト形式のローカルファイルとしては、Ｉｎｄｅｘｅｄ Ｄａｔａｂａｓｅ ＡＰＩ仕様（以下、ＩｎｄｅｘｅｄＤＢ）により生成されるファイルがある。ＩｎｄｅｘｅｄＤＢは値とオブジェクトをローカルデータベースに保持する仕様であり、この情報を記録しておくファイルが生成される。

本実施形態に係る情報処理システムにおいて動作する仮想マシンのハードウェア構成例について、図１のブロック図を用いて説明する。

ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０１は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１０２やＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）に格納されているコンピュータプログラムやデータを用いて各種の処理を実行する。これによりＣＰＵ１０１は、仮想マシン１００全体の動作制御を行うとともに、仮想マシン１００が行うものとして説明する各処理を実行もしくは制御する。

ＲＯＭ１０２には、仮想マシン１００の設定データ、仮想マシン１００の起動に係るコンピュータプログラムやデータ、仮想マシン１００の基本動作に係るコンピュータプログラムやデータ、等が格納されている。

ＲＡＭ１０３は、ＲＯＭ１０２からロードされたコンピュータプログラムやデータ、通信インターフェース１０５を介して外部装置から受信したデータ、を格納するためのエリアを有する。また、ＲＡＭ１０３は、ＣＰＵ１０１が各種の処理を実行する際に用いるワークエリアを有する。このように、ＲＡＭ１０３は、各種のエリア（記憶領域）を適宜提供することができる。

インターフェース１０４は、ＣＰＵ１０１による処理結果を画像や文字などでもって表示するための表示部、ユーザが各種の操作入力を行うために操作する操作部、を含むインターフェースである。表示部は、液晶画面やタッチパネル画面を含む。操作部は、キーボード、マウス、タッチパネル画面などのユーザインターフェースを含む。

通信インターフェース１０５は、外部装置との間のデータ通信を行うためのインターフェースである。ＣＰＵ１０１、ＲＯＭ１０２、ＲＡＭ１０３、インターフェース１０４、通信インターフェース１０５、は何れもバス１１０に接続されている。

なお、図１に示した構成は、本実施形態に係る仮想マシンに適用可能な構成の一例に過ぎず、図１に示した構成に限定することを意図したものではない。例えば、図１に示した構成において、バス１１０に更にメモリ装置を接続してもよい。メモリ装置は、例えば、ハードディスクドライブ、ＵＳＢメモリ、磁気カード、光カード、ＩＣカード、メモリカード、ドライブ装置（フレキシブルディスク（ＦＤ）、Ｃｏｍｐａｃｔ Ｄｉｓｋ（ＣＤ）等の光ディスク、等の記憶媒体のドライブ装置）を含む。このようなメモリ装置によって、後述する「仮想マシンの記憶領域」を構成してもよい。なお、仮想マシン１００は、いわゆる仮想化技術により構成され得るもので、コンピュータシステムを構成する様々な資源を、物理的な構成とは独立に論理的な単位に編成することが可能である。即ち、複数の資源を統合して仮想マシン１００を構成したり、一つの資源を分割してその一つを仮想マシン１００として構成したりすることが可能である。即ち、クラウドを構成する情報処理システムの複数の資源（複数の装置により構成され得る）の少なくとも一部を用いて仮想マシン１００を構成することができる。

ここで、従来のクラウドブラウザのシステムの構成例について、図２のブロック図を用いて説明する。図２のシステムでは、ユーザは通信端末２０１の画面を閲覧しており、ユーザが通信端末２０１を操作して、閲覧したいＷｅｂページ２０２の閲覧要求を入力すると、通信端末２０１は、該Ｗｅｂページ２０２のアドレス（以下では一例としてＵＲＬとする）を、クラウド上に設置されている情報処理システムとしての画像生成システム２０３に対して送信する。

画像生成システム２０３の仮想マシンＡ２０５におけるブラウザ２０６は、通信端末２０１から送信されたＷｅｂページ２０２のＵＲＬを、ゲートウェイ２０４を介して受信する。そしてブラウザ２０６は、該受信したＵＲＬに対応するＷｅｂページ２０２にゲートウェイ２０４を介してアクセスして、該Ｗｅｂページ２０２の描画結果を生成する。そしてブラウザ２０６は、該生成したＷｅｂページ２０２の描画結果を、ゲートウェイ２０４を介して通信端末２０１に送信する。

通信端末２０１は、画像生成システム２０３から送信された該Ｗｅｂページ２０２の描画結果を受信し、該受信した描画結果を表示するなどしてユーザに該Ｗｅｂページ２０２を提示する。

続いて、従来のクラウドブラウザの可用性を向上させるシステムの構成例について、図３のブロック図を用いて説明する。図３のシステムは、図２のシステムにおいて、画像生成システム２０３の代わりに、該画像生成システム２０３にロードバランサ３０１および仮想マシンＢ３０２を追加した画像生成システム３００を採用したものである。よって、画像生成システム３００もまた、クラウド上に設置されている情報処理システムである。

ロードバランサ３０１は、ゲートウェイ２０４を通過する通信のデータ量や該通信の特性等に応じて、仮想マシンＡ２０５と仮想マシンＢ３０２のどちらを起動するかを判断し、該判断の結果に応じた一方の仮想マシンが起動する。仮想マシンＢ３０２は仮想マシンＡ２０５と同様の構成を有しており、起動すると、仮想マシンＡ２０５と同様の動作を行う。

図３の構成では、仮想マシンＡ２０５のブラウザ２０６と仮想マシンＢ３０２のブラウザ３０３のそれぞれは、自身が生成したローカルファイルを自身の仮想マシンの記憶領域に保存するため、仮想マシン間でローカルファイルの共有ができない。

続いて、本実施形態に係るクラウドブラウザのシステムの構成例について、図４のブロック図を用いて説明する。図４のシステムは、図３のシステムにおいて、画像生成システム３００を画像生成システム４００に置き換えたものである。画像生成システム４００における仮想マシンＡ４１０は、画像生成システム３００の仮想マシンＡ２０５にデータ型判定部４０１を加えたもので、仮想マシンＢ４１１は、画像生成システム３００の仮想マシンＢ３０２にデータ型判定部４０２を加えたものである。また、画像生成システム４００は、仮想マシンＡ４１０の記憶領域（ＲＡＭ１０３や他のメモリ装置など）や仮想マシンＢ４１１の記憶領域（ＲＡＭ１０３や他のメモリ装置など）とは別個のストレージであるオブジェクト型ストレージ４０３およびキーバリュー型ストレージ４０４を有する。よって、画像生成システム４００もまた、クラウド上に設置されている情報処理システムである。オブジェクト型ストレージ４０３およびキーバリュー型ストレージ４０４は、複数の仮想マシン間で共有可能な記憶領域である。

図４のシステムにおいても、ユーザが通信端末２０１を操作して、閲覧したいＷｅｂページ２０２の閲覧要求を入力すると、通信端末２０１は、該Ｗｅｂページ２０２のＵＲＬを画像生成システム４００に対して送信する。そしてロードバランサ３０１は、ゲートウェイ２０４を通過する通信のデータ量や該通信の特性等に応じて、仮想マシンＡ４１０と仮想マシンＢ４１１のどちらを起動するかを判断し、該判断の結果に応じた一方の仮想マシンが起動する。

ここでＡｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅｓ（登録商標）を例として、オブジェクト型ストレージ４０３とキーバリュー型ストレージ４０４の具体的名称を記載する。Ａｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅｓにおけるオブジェクト型ストレージにはＡｍａｚｏｎ Ｓ３（登録商標）がある。また、Ａｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅｓにおけるキーバリュー型ストレージにはＡｍａｚｏｎ ＤｙｎａｍｏＤＢ（登録商標）がある。

次に、画像生成システム４００の動作について、図５のフローチャートに従って説明する。以下では、ロードバランサ３０１は、図５のフローチャートに従った処理の開始前における通信端末２０１との通信のデータ量や該通信の特性などに応じて仮想マシンＡ４１０を起動すると判断したものとして説明する。なお、この判断のタイミングは特定のタイミングに限らない。よって、以下では、仮想マシンＡ４１０が起動しているものとする（仮想マシンＢ４１１については起動してもよいし、起動していなくてもよい）。

ステップＳ５０１では、仮想マシンＡ４１０におけるブラウザ２０６は、通信端末２０１から送信されたＷｅｂページ２０２のＵＲＬを、ゲートウェイ２０４およびロードバランサ３０１を介して受信する。

ステップＳ５０２では、ブラウザ２０６は、ステップＳ５０１で受信したＵＲＬに対応するＷｅｂページ２０２にゲートウェイ２０４を介してアクセスして、該Ｗｅｂページ２０２のデータを取得する。Ｗｅｂページ２０２のデータは、ＨＴＭＬ文書、ＪａｖａＳｃｒｉｐｔ（登録商標）、ＣＳＳファイル、外部フォント、画像などを含む。

ステップＳ５０３では、ブラウザ２０６は、ステップＳ５０２で取得したＷｅｂページ２０２のデータであるＨＴＭＬ文書の上段から順に、該ＨＴＭＬ文書におけるＨＴＭＬ要素を解析する。

ステップＳ５０４では、データ型判定部４０１は、ステップＳ５０３における解析の結果、Ｗｅｂページ２０２のデータであるＪａｖａＳｃｒｉｐｔやＣＳＳによってローカルファイルが生成される（ブラウザ２０６がＷｅｂページ２０２を解釈して処理を行う間にローカルファイルが生成される）か否かを判断する。

この判断の結果、ローカルファイルが生成されると判断された場合には、処理はステップＳ５０５に進み、ローカルファイルは生成されないと判断された場合には、処理はステップＳ５０８に進む。

ステップＳ５０５では、データ型判定部４０１は、ＪａｖａＳｃｒｉｐｔやＣＳＳによって生成されるローカルファイル（ブラウザ２０６がＷｅｂページ２０２を解釈して処理を行う間に生成されるローカルファイル）がキーバリュー形式のデータであるか否かを判断する。

この判断の結果、ＪａｖａＳｃｒｉｐｔやＣＳＳによって生成されるローカルファイル（ブラウザ２０６がＷｅｂページ２０２を解釈して処理を行う間に生成されるローカルファイル）がキーバリュー形式のデータである場合、処理はステップＳ５０６に進む。一方、ＪａｖａＳｃｒｉｐｔやＣＳＳによって生成されるローカルファイル（ブラウザ２０６がＷｅｂページ２０２を解釈して処理を行う間に生成されるローカルファイル）がキーバリュー形式のデータではない場合には、処理はステップＳ５０７に進む。

ステップＳ５０６でデータ型判定部４０１は、ＪａｖａＳｃｒｉｐｔやＣＳＳによって生成されるローカルファイル（ブラウザ２０６がＷｅｂページ２０２を解釈して処理を行う間に生成されるローカルファイル）をキーバリュー型ストレージ４０４に保存する。

ステップＳ５０７でデータ型判定部４０１は、ＪａｖａＳｃｒｉｐｔやＣＳＳによって生成されるローカルファイル（ブラウザ２０６がＷｅｂページ２０２を解釈して処理を行う間に生成されるローカルファイル）をオブジェクト型ストレージ４０３に保存する。

ステップＳ５０８では、ブラウザ２０６は、ステップＳ５０２で取得したＷｅｂページ２０２のデータを用いて該Ｗｅｂページ２０２の描画結果を生成する。ステップＳ５０９では、ブラウザ２０６は、ステップＳ５０８で生成したＷｅｂページ２０２の描画結果を、ロードバランサ３０１およびゲートウェイ２０４を介して通信端末２０１に送信する。

なお、上記の説明は、仮想マシンＡ４１０が起動して動作したケースにおける説明であるが、仮想マシンＢ４１１が起動して動作しても同様の処理が達成される。つまり、ブラウザ２０６の代わりにブラウザ３０３が該ブラウザ２０６と同様に動作し、データ型判定部４０１の代わりにデータ型判定部４０２が該データ型判定部４０１と同様に動作する。 次に、ローカルファイルを生成して保持している画像生成システム４００の動作について、図６のフローチャートに従って説明する。図６において、図５に示した処理ステップと同じ処理ステップには同じステップ番号を付しており、該処理ステップに係る説明は省略する。

以下では、ロードバランサ３０１は、図６のフローチャートに従った処理の開始前における通信端末２０１との通信のデータ量や該通信の特性などに応じて仮想マシンＢ４１１を起動すると判断したものとして説明する。なお、この判断のタイミングは特定のタイミングに限らない。よって、以下では、仮想マシンＢ４１１が起動しているものとする（仮想マシンＡ４１０については起動してもよいし、起動していなくてもよい）。

ステップＳ６０４では、データ型判定部４０２は、ステップＳ５０３における解析の結果、Ｗｅｂページ２０２のデータであるＪａｖａＳｃｒｉｐｔやＣＳＳによってローカルファイルが更新される（ブラウザ３０３がＷｅｂページ２０２を解釈して処理を行う間にローカルファイルが更新される）か否かを判断する。

この判断の結果、ローカルファイルが更新されると判断された場合には、処理はステップＳ６０５に進み、ローカルファイルは更新されないと判断された場合には、処理はステップＳ５０８に進む。

ステップＳ６０５では、データ型判定部４０２は、ＪａｖａＳｃｒｉｐｔやＣＳＳによって更新されるローカルファイル（ブラウザ３０３がＷｅｂページ２０２を解釈して処理を行う間に更新されるローカルファイル）がキーバリュー形式のデータであるか否かを判断する。

この判断の結果、ＪａｖａＳｃｒｉｐｔやＣＳＳによって更新されるローカルファイル（ブラウザ３０３がＷｅｂページ２０２を解釈して処理を行う間に更新されるローカルファイル）がキーバリュー形式のデータである場合、処理はステップＳ６０６に進む。一方、ＪａｖａＳｃｒｉｐｔやＣＳＳによって更新されるローカルファイル（ブラウザ３０３がＷｅｂページ２０２を解釈して処理を行う間に更新されるローカルファイル）がキーバリュー形式のデータではない場合には、処理はステップＳ６０８に進む。

ステップＳ６０６では、データ型判定部４０２は、キーバリュー型ストレージ４０４からローカルファイルを読みだす。そしてステップＳ６０７では、データ型判定部４０２は、ステップＳ６０６で読みだしたローカルファイルを、ＪａｖａＳｃｒｉｐｔやＣＳＳによって更新する。ステップＳ５０６では、データ型判定部４０２は、ステップＳ６０７で更新されたローカルファイルをキーバリュー型ストレージ４０４に保存する。

ステップＳ６０８では、データ型判定部４０２は、オブジェクト型ストレージ４０３からローカルファイルを読みだす。そしてステップＳ６０９では、データ型判定部４０２は、ステップＳ６０８で読みだしたローカルファイルを、ＪａｖａＳｃｒｉｐｔやＣＳＳによって更新する。ステップＳ５０７では、データ型判定部４０２は、ステップＳ６０９で更新されたローカルファイルをオブジェクト型ストレージ４０３に保存する。

このように、仮想マシン上で稼働するブラウザが生成するローカルファイルを、該仮想マシンの記憶領域とは異なるサーバ上のストレージに保存することで、仮想マシンＡ２０５上で稼働するブラウザ２０６が生成したローカルファイルを、仮想マシンＢ３０２上で稼働するブラウザ３０３から読み込むことが可能となる。これにより、クラウドブラウザの可用性を向上させた場合であっても、ローカルファイルを利用するＷｅｂ標準技術を正しく実行することが可能となる。なお、仮想マシン１００は、Ｗｅｂページを解釈して処理を行う間に生成されるファイルのうちローカルファイル以外を、仮想マシンが有する記憶領域であって、他の仮想マシンがアクセスできない領域に記憶する構成としてもよい。

＜変形例＞
本変形例では、ローカルファイルを、該ローカルファイルのデータサイズに対応するストレージに保存する。サーバ上で稼働するストレージには、安価で大容量保存することを特徴とするストレージや、高速アクセスが可能であるが利用料金が高額なストレージなどがある。ストレージを利用するクラウドブラウザの利用料金を抑制する方法の一つに、大容量のデータを安価なストレージに保存する方法がある。

本変形例に係るクラウドブラウザのシステムの構成例について、図１３のブロック図を用いて説明する。図１３のシステムは、図４のシステムにおいて、画像生成システム４００を画像生成システム１３００に置き換えたものである。画像生成システム１３００における仮想マシンＡ１３１０は、画像生成システム４００の仮想マシンＡ４１０においてデータ型判定部４０１をサイズ判定部１３０１に置き換えたものである。また、画像生成システム１３００における仮想マシンＢ１３１１は、画像生成システム４００の仮想マシンＢ４１１においてデータ型判定部４０２をサイズ判定部１３０２に置き換えたものである。また、画像生成システム１３００は、オブジェクト型ストレージ４０３およびキーバリュー型ストレージ４０４の代わりに大容量ストレージ１３０３および高速アクセスストレージ１３０４、を有する。大容量ストレージ１３０３および高速アクセスストレージ１３０４は何れも、仮想マシンＡ１３１０の記憶領域や仮想マシンＢ１３１１の記憶領域とは別個に設けられたものである。大容量ストレージ１３０３は、安価で大容量保存することを特徴とするストレージであり、高速アクセスストレージ１３０４は、高速アクセスが可能であるが利用料金が高額なストレージである。

図１３のロードバランサ３０１は、ゲートウェイ２０４を通過する通信のデータ量や該通信の特性等に応じて、仮想マシンＡ１３１０と仮想マシンＢ１３１１のどちらを起動するかを判断し、該判断の結果に応じた一方の仮想マシンが起動する。

本変形例における画像生成システム１３００の動作について、図１４のフローチャートに従って説明する。図１４において、図５の処理ステップと同じ処理ステップには同じステップ番号を付しており、該処理ステップに係る説明は省略する。

以下では、ロードバランサ３０１は、図１４のフローチャートに従った処理の開始前における通信端末２０１との通信のデータ量や該通信の特性などに応じて仮想マシンＡ１３１０を起動すると判断したものとして説明する。なお、この判断のタイミングは特定のタイミングに限らない。よって、以下では、仮想マシンＡ１３１０が起動しているものとする（仮想マシンＢ１３１１については起動してもよいし、起動していなくてもよい）。

ステップＳ５０４における判断の結果、ローカルファイルが生成されると判断された場合には、処理はステップＳ１４０１に進み、ローカルファイルは生成されないと判断された場合には、処理はステップＳ５０８に進む。

ステップＳ１４０１でサイズ判定部１３０１はＪａｖａＳｃｒｉｐｔやＣＳＳによって生成されるローカルファイル（ブラウザ２０６がＷｅｂページ２０２を解釈して処理を行う間に生成されるローカルファイル）のデータサイズＳが閾値以上か否かを判断する。

この判断の結果、ローカルファイルのデータサイズＳが閾値以上であれば、処理はステップＳ１４０２に進み、ローカルファイルのデータサイズＳが閾値未満であれば、処理はステップＳ１４０３に進む。

ステップＳ１４０２でサイズ判定部１３０１は、ＪａｖａＳｃｒｉｐｔやＣＳＳによって生成されるローカルファイル（ブラウザ２０６がＷｅｂページ２０２を解釈して処理を行う間に生成されるローカルファイル）を大容量ストレージ１３０３に保存する。

ステップＳ１４０３でサイズ判定部１３０１はＪａｖａＳｃｒｉｐｔやＣＳＳによって生成されるローカルファイル（ブラウザ２０６がＷｅｂページ２０２を解釈して処理を行う間に生成されるローカルファイル）を高速アクセスストレージ１３０４に保存する。

［第２の実施形態］
本実施形態を含む以下の各実施形態では、第１の実施形態との差分について説明し、以下で特に触れない限りは第１の実施形態と同様であるものとする。本実施形態では、仮想マシンの記憶領域を利用して、ローカルファイルを生成するＷｅｂ標準技術を一時的に処理する事例を考える。一般的に、仮想マシンの他にサーバ上のストレージを利用すると、システムの利用料金が増加する。そのため、クラウドブラウザの顧客が、機能が制限されてもクラウドブラウザを利用したい場合、ある程度Ｗｅｂ標準技術が実施でき、システムの利用料金を抑制できる構成が望まれる。ここで、仮想マシンとは異なるサーバ上のストレージよりも、仮想マシン内部の記憶領域は利用料金が低いことが多い。そこで仮想マシン内部の記憶領域を利用して、ローカルファイルを利用するＷｅｂ標準技術の一部を処理する構成を示す。

本実施形態に係るクラウドブラウザのシステムの構成例について、図７のブロック図を用いて説明する。画像生成システム７００が有する仮想マシンＡ７１０は、図４の仮想マシンＡ４１０に記憶領域７０１を加えたものである。また、画像生成システム７００が有する仮想マシンＢ７１１は，図４の仮想マシンＢ４１１に記憶領域７０２を加えたものである。

図７のロードバランサ３０１は、ゲートウェイ２０４を通過する通信のデータ量や該通信の特性等に応じて、仮想マシンＡ７１０と仮想マシンＢ７１１のどちらを起動するかを判断し、該判断の結果に応じた一方の仮想マシンが起動する。

本実施形態に係る画像生成システム７００の動作について、図８のフローチャートに従って説明する。図８において図５の処理ステップと同じ処理ステップには同じステップ番号を付しており、該処理ステップに係る説明は省略する。

以下では、ロードバランサ３０１は、図８のフローチャートに従った処理の開始前における通信端末２０１との通信のデータ量や該通信の特性などに応じて仮想マシンＡ７１０を起動すると判断したものとして説明する。なお、この判断のタイミングは特定のタイミングに限らない。よって、以下では、仮想マシンＡ７１０が起動しているものとする（仮想マシンＢ７１１については起動してもよいし、起動していなくてもよい）。

ステップＳ８０１では、ブラウザ２０６は、ローカルファイルの保存先として、仮想マシンとは異なるサーバ上のストレージの利用を希望するか否かをユーザに問い合わせるための画面（問い合わせ画面）を上記の表示部に表示する。問い合わせ画面の表示例を図９（Ａ）に示す。

図９（Ａ）に例示している問い合わせ画面は、追加料金は発生するが、仮想マシンとは異なるサーバ上のストレージの利用を希望するか否かをユーザに問い合わせている。ユーザが上記の操作部を操作して該問い合わせ画面の「ＹＥＳ」ボタンを指示する（仮想マシンとは異なるサーバ上のストレージの利用を希望する）と、処理はステップＳ５０５に進む。一方、ユーザが上記の操作部を操作して該問い合わせ画面の「ＮＯ」ボタンを指示する（仮想マシンとは異なるサーバ上のストレージの利用を希望しない）と、処理はステップＳ８０２に進む。ステップＳ８０２では、データ型判定部４０１は、ローカルファイルを仮想マシンＡ７１０の記憶領域である記憶領域７０１に保存する。

なお、ステップＳ８０２では、ブラウザ２０６は、ユーザに警告文を記した画面（警告画面）を上記の表示部に表示するようにしても良い。警告画面の表示例を図９（Ｂ）に示す。

図９（Ｂ）に例示している警告画面は、クラウドブラウザの利用を終了するまではローカルファイルに記録したデータは保存されているが、一旦クラウドブラウザの利用を終了すると、次回クラウドブラウザを利用した際に、ローカルファイルに記録したデータを読み込むことができない旨をユーザに通知するための画面である。

ローカルファイルを仮想マシンの記憶領域に保存する用途として、ローカルストレージを利用するチャットシステムを、低コストで利用する用途がある。チャットシステムは利用開始時にローカルストレージを利用してユーザ名を記録する。次回起動時にはローカルストレージからユーザ名を読み込む。

この場合、本実施形態では、ローカルストレージを使ってユーザ名を仮想マシンの記憶領域に記憶するため、チャットシステムの利用は可能である。一方で、クラウドブラウザの次回起動時に、ロードバランサが別の仮想マシンを指定した場合、ユーザ名を再度入力する手間が発生する。クラウドブラウザのシステムの利用料金を抑制するため利便性は低下するが、主要な機能であるチャット機能を利用することが可能となる。

本実施形態において、仮想マシンの稼働終了時に、該仮想マシンの記憶領域に保存したローカルファイルを消去しても良い。ローカルファイルを消去すれば、クラウドブラウザでＷｅｂページにアクセスする度に、該Ｗｅｂページの挙動が同一となる。チャットシステムの場合、毎回ユーザ名を入力する利用方法に統一できる。

一方で、仮想マシンの稼働終了時に、ローカルファイルを記憶領域に保存したままでもよい。チャットシステムの場合、ロードバランサが別の仮想マシンを指定した場合に、ユーザ名を入力する手間が発生するが、同一の仮想マシンを指定した場合は、ユーザ名がローカルファイルから読み込まれる。

［第３の実施形態］
本実施形態では、ローカルファイルをユーザの機器に送信し、次回クラウドブラウザ利用時は、ユーザがアップロードしたローカルファイルを利用する例を示す。本実施形態に係るクラウドブラウザのシステムの構成例について、図１０のブロック図を用いて説明する。図１０の画像生成システム１０００は、画像生成システム４００において、仮想マシンＡ４１０および仮想マシンＢ４１１をそれぞれ仮想マシンＡ１０１０および仮想マシンＢ１０１１に置き換え、且つオブジェクト型ストレージ４０３およびキーバリュー型ストレージ４０４を削除した構成を有する。

図１０のロードバランサ３０１は、ゲートウェイ２０４を通過する通信のデータ量や該通信の特性等に応じて、仮想マシンＡ１０１０と仮想マシンＢ１０１１のどちらを起動するかを判断し、該判断の結果に応じた一方の仮想マシンが起動する。

本実施形態に係る画像生成システム１０００の動作について、図１１のフローチャートに従って説明する。図１１において図５の処理ステップと同じ処理ステップには同じステップ番号を付しており、該処理ステップに係る説明は省略する。

以下では、ロードバランサ３０１は、図１１のフローチャートに従った処理の開始前における通信端末２０１との通信のデータ量や該通信の特性などに応じて仮想マシンＡ１０１０を起動すると判断したものとして説明する。なお、この判断のタイミングは特定のタイミングに限らない。よって、以下では、仮想マシンＡ１０１０が起動しているものとする（仮想マシンＢ１０１１については起動してもよいし、起動していなくてもよい）。

ステップＳ５０４における判断の結果、ローカルファイルが生成されると判断された場合には、処理はステップＳ１１０１に進み、ローカルファイルは生成されないと判断された場合には、処理はステップＳ５０８に進む。ステップＳ１１０１では、ファイル送信部１００１は、ローカルファイルを、ロードバランサ３０１およびゲートウェイ２０４を介して、ユーザの機器である通信端末２０１に対して送信する。つまり、本実施形態では、通信端末２０１をローカルファイルのストレージとして取り扱っている。

図１１のフローチャートに従った処理の後における画像生成システム１０００の動作について、図１２のフローチャートに従って説明する。図１２において図５，６と同じ処理ステップには同じステップ番号を付しており、該処理ステップに係る説明は省略する。

以下では、ロードバランサ３０１は、図１２のフローチャートに従った処理の開始前における通信端末２０１との通信のデータ量や該通信の特性などに応じて仮想マシンＡ１０１０を起動すると判断したものとして説明する。なお、この判断のタイミングは特定のタイミングに限らない。よって、以下では、仮想マシンＡ１０１０が起動しているものとする（仮想マシンＢ１０１１については起動してもよいし、起動していなくてもよい）。

ステップＳ１２０１における判断の結果、ローカルファイルを読み込むと判断された場合には、処理はステップＳ１２０２に進み、ローカルファイルは読み込まれないと判断された場合には、処理はステップＳ５０８に進む。

ステップＳ１２０２では、仮想マシンＡ１０１０におけるファイル受信部１００２は、ローカルファイルをロードバランサ３０１およびゲートウェイ２０４を介して通信端末２０１から受信する。

ステップＳ６０４における判断の結果、ローカルファイルを更新すると判断された場合には、処理はステップＳ１２０４に進み、ローカルファイルを更新しないと判断された場合には、処理はステップＳ１２０３に進む。

ステップＳ１２０４では、ファイル受信部１００２は、ステップＳ１２０２で受信したローカルファイルを、ＪａｖａＳｃｒｉｐｔやＣＳＳによって更新する。そしてステップＳ１２０５では、ファイル送信部１００１は、ステップＳ１２０４で更新されたローカルファイルをロードバランサ３０１およびゲートウェイ２０４を介して通信端末２０１に対して送信する。

ステップＳ１２０３では、ファイル受信部１００２は、ステップＳ１２０２で受信したローカルファイルを、ＪａｖａＳｃｒｉｐｔやＣＳＳによって参照する。更新せず、参照のみの場合、ユーザの機器にローカルファイルを送信しない。

このように、本実施形態によれば、クラウドブラウザ上にローカルファイルを保存する領域を一切持たなくとも、ローカルファイルを生成するＷｅｂ標準技術を実行可能である。ただし、この構成では、通信端末２０１上にローカルファイルを保存しておく手間が発生する。また、遠隔地からローカルファイルを通信して取得する必要があるため、Ｗｅｂ標準技術の実行速度が低下する可能性がある。

［第４の実施形態］
本実施形態では、ローカルファイルを仮想マシン間で直接共有する例を示す。仮想マシンが多数配置されたクラウドブラウザ上でローカルファイルを共有すると、ネットワーク負荷やデータ管理コストが高くなってしまうため、第１の実施形態のように仮想マシンとは異なるサーバ上のストレージでローカルファイルを管理する方がよい。一方で、仮想マシンが数個しかなく、それらの仮想マシンが常時起動しているクラウドブラウザ上であれば、直接ローカルファイルを共有した方が、管理コストが低い場合がある。

本実施形態に係るクラウドブラウザのシステムの構成例について、図１５のブロック図を用いて説明する。図１５の画像生成システム１５００は、図４の画像生成システム４００の仮想マシンＡ４１０および仮想マシンＢ４１１をそれぞれ仮想マシンＡ１５１０および仮想マシンＢ１５１１に置き換え、且つオブジェクト型ストレージ４０３およびキーバリュー型ストレージ４０４を削除した構成を有する。

仮想マシンＡ１５１０は、ブラウザ２０６および送受信部１５０１を有する。仮想マシンＢ１５１１は、ブラウザ３０３および送受信部１５０２を有する。送受信部１５０１および送受信部１５０２は同様の動作を行うものであり、それぞれの間で直接通信を行ってローカルファイルの送受信を行う。

本実施形態に係る画像生成システム１５００の動作について、図１６のフローチャートに従って説明する。図１６において図５と同じ処理ステップには同じステップ番号を付しており、該処理ステップに係る説明は省略する。

以下では、ロードバランサ３０１は、図１６のフローチャートに従った処理の開始前における通信端末２０１との通信のデータ量や該通信の特性などに応じて仮想マシンＡ１５１０を起動すると判断したものとして説明する。なお、この判断のタイミングは特定のタイミングに限らない。よって、以下では、仮想マシンＡ１５１０が起動しているものとする（仮想マシンＢ１５１１については起動してもよいし、起動していなくてもよい）。

ステップＳ５０４における判断の結果、ローカルファイルが生成されると判断された場合には、処理はステップＳ１６０１に進み、ローカルファイルは生成されないと判断された場合には、処理はステップＳ５０８に進む。

ステップＳ１６０１では、送受信部１５０１は、ＪａｖａＳｃｒｉｐｔやＣＳＳによって生成されるローカルファイル（ブラウザ２０６がＷｅｂページ２０２を解釈して処理を行う間に生成されるローカルファイル）を送受信部１５０２に対して送信する。

［第５の実施形態］
上記の各実施形態では、図４，７，１０，１３，１５に示した仮想マシンの各機能部を処理の主体として説明した。しかし実際には、記憶領域７０１，７０２を除く各機能部の機能をＣＰＵ１０１に実行させるためのコンピュータプログラムをＣＰＵ１０１が実行することで、該機能部の機能が実現される。なお、図４，７，１０，１３，１５に示した仮想マシンの各機能部をハードウェアで実装してもよい。

また、上記の各実施形態では、ローカルファイルの出力先（保存先、送信先）として様々な出力先を説明した。しかし、これらの実施形態は、「ブラウザがＷｅｂページを解釈して処理を行う間に生成されるローカルファイル」を、仮想マシンが有する記憶領域とは異なるストレージに対して出力することの一例に過ぎない。よって、データ型判定部４０１（４０２）、ファイル送信部１００１（１００３）、サイズ判定部１３０１（１３０２）、送受信部１５０１（１５０２）は、「ブラウザがＷｅｂページを解釈して処理を行う間に生成されるローカルファイルを、仮想マシンが有する記憶領域とは異なるストレージに対して出力する出力部」の一例に過ぎない。

また、上記の実施形態で使用した数、処理タイミング、処理順、データ（情報）の送信先／送信元、画面の構成やその操作方法などは、具体的な説明を行うために一例として挙げたものであり、このような一例に限定することを意図したものではない。

また、以上説明した各実施形態や変形例の一部若しくは全部を適宜組み合わせて使用しても構わない。また、以上説明した各実施形態や変形例の一部若しくは全部を選択的に使用しても構わない。

（その他の実施形態）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

発明は上記実施形態に制限されるものではなく、発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、発明の範囲を公にするために請求項を添付する。

２０１：通信端末 ２０２：Ｗｅｂページ ２０４：ゲートウェイ ２０６：ブラウザ ３０１：ロードバランサ ３０３：ブラウザ ４００：画像生成システム ４０１：データ型判定部 ４０２：データ型判定部 ４０３：オブジェクト型ストレージ ４０４：キーバリュー型ストレージ ４１０：仮想マシンＡ ４１１：仮想マシンＢ

Claims (11)

1. 情報処理システムであって、
   仮想マシンを有し、
   前記仮想マシンは、
   ブラウザと、
   前記ブラウザがＷｅｂページを解釈して処理を行う間に生成されるファイルを、前記仮想マシンが有する記憶領域とは異なり、前記仮想マシンと異なる他の仮想マシンと共有可能なストレージに対して出力する出力部と
   を備えることを特徴とする情報処理システム。
2. 前記ストレージは複数のストレージを含み、
   前記出力部は、前記ファイルがキーバリュー形式のデータである場合には、該ファイルをキーバリュー型ストレージに保存し、前記ファイルがキーバリュー形式のデータではない場合には、該ファイルを、オブジェクト型ストレージに保存することを特徴とする請求項１に記載の情報処理システム。
3. 前記ストレージは複数のストレージを含み、
   前記出力部は、前記ファイルのデータサイズが閾値以上である場合には、該ファイルを、大容量のストレージである大容量ストレージに保存し、前記ファイルのデータサイズが閾値未満であれば、該ファイルを、高速にアクセスが可能な高速アクセスストレージに保存することを特徴とする請求項１に記載の情報処理システム。
4. 前記ブラウザは、前記仮想マシンが有する記憶領域とは異なるストレージの利用を希望するか否かをユーザに問い合わせ、
   前記出力部は、
   前記仮想マシンが有する記憶領域とは異なるストレージの利用を希望する旨の指示がユーザにより入力された場合には、前記ファイルを前記仮想マシンが有する記憶領域とは異なるストレージに保存し、
   前記仮想マシンが有する記憶領域とは異なるストレージの利用を希望しない旨の指示がユーザにより入力された場合には、前記ファイルを前記仮想マシンの記憶領域に保存する
   ことを特徴とする請求項１ないし３のいずれか１項に記載の情報処理システム。
5. 前記ストレージは、前記情報処理システムに対して前記Ｗｅｂページのアドレスを送信した通信端末であり、
   前記出力部は、前記ファイルを前記通信端末に対して送信することを特徴とする請求項１に記載の情報処理システム。
6. 前記情報処理システムは、
   前記情報処理システムが有する複数の仮想マシンのうち何れの仮想マシンを起動させるのかを判断するロードバランサを備え、
   前記ロードバランサによる判断に応じた仮想マシンが起動することを特徴とする請求項１ないし５のいずれか１項に記載の情報処理システム。
7. 前記Ｗｅｂページは、外部の通信端末から送信されたアドレスに対応するＷｅｂページであることを特徴とする請求項１ないし６のいずれか１項に記載の情報処理システム。
8. 前記ブラウザは、前記Ｗｅｂページの描画結果を生成し、該生成した描画結果を前記通信端末に対して送信することを特徴とする請求項７に記載の情報処理システム。
9. 前記出力部は、Ｗｅｂ標準仕様に定められるローカルストレージに従って記憶されるファイルを前記ストレージに対して出力することを特徴とする請求項１ないし８のいずれか１項に記載の情報処理システム。
10. 前記出力部は、前記ローカルストレージに従って記憶されるファイルと異なるファイルを前記他の仮想マシンがアクセスできない前記記憶領域に出力することを特徴とする請求項９に記載の情報処理システム。
11. 情報処理システムの制御方法であって、
    前記情報処理システムの仮想マシンが有するブラウザがＷｅｂページを解釈して処理を行う間に生成されるファイルを、前記仮想マシンが有する記憶領域とは異なり、前記仮想マシンと異なる他の仮想マシンと共有可能なストレージに対して出力する
    ことを特徴とする情報処理システムの制御方法。

Images