(57)【要約】【課題】スマートデバイスを含むデータ処理技術において、高負荷処理への対応を容易にすることを目的とする。【解決手段】クライアントと第１のサーバとの間でクライアント−サーバ間通信の接続確立後に通信毎に接続の確立が必要ない第１の通信方式により通信を行い、前記クライアントから要求された第１の処理を実行させる前記第１のサーバと、前記第１のサーバの要求に基づいて前記第１の処理のうち高負荷処理を実行する第２のサーバを複数有する第２のサーバ群であって、前記第１のサーバと前記第２のサーバとの間の通信毎に第１のサーバ−第２のサーバ群間の通信毎に接続の確立が必要な第２の通信方式により通信を行う第２のサーバ群と、を有することを特徴とするデータ処理システム。【選択図】図３
2017182269.tif 000002
【特許請求の範囲】
【請求項１】
クライアントと第１のサーバとの間でクライアント−サーバ間通信の接続確立後に通信毎に接続の確立が必要ない第１の通信方式により通信を行い、前記クライアントから要求された第１の処理を実行させる前記第１のサーバと、
前記第１のサーバの要求に基づいて前記第１の処理のうち高負荷処理を実行する第２のサーバを複数有する第２のサーバ群であって、前記第１のサーバと前記第２のサーバとの間の通信毎に第１のサーバ−第２のサーバ群間の通信毎に接続の確立が必要な第２の通信方式により通信を行う第２のサーバ群と、を有することを特徴とするデータ処理システム。
【請求項２】
前記第１のサーバと前記第２のサーバ群との間で、前記第２の通信方式により、前記第１の処理毎にデータ処理の負荷の分散を行う負荷分散装置を有することを特徴とする請求項１に記載のデータ処理システム。
【請求項３】
前記第１のサーバと前記第２のサーバ群との間に設けられ、前記第２のサーバ群による前記高負荷処理を経たデータを格納するデータベースを有することを特徴とする請求項１又は２に記載のデータ処理システム。
【請求項４】
前記データベース内に前記クライアントから要求された前記高負荷処理を経たデータが存在する場合には、
前記第２のサーバ群における前記高負荷処理の実行を行わせる前記第１のサーバからの要求を行わないことを特徴とする請求項３に記載のデータ処理システム。
【請求項５】
前記第１のサーバは、自己の処理負荷を評価する処理負荷評価部を有し、
前記処理負荷評価部の評価結果に基づいて、前記高負荷処理を前記第２のサーバに依頼するか自己により行うかを判断することを特徴とする請求項１から４までのいずれか１項に記載のデータ処理システム。
【請求項６】
クライアントと第１のサーバとの間でクライアント−サーバ間通信の接続確立後に通信毎に接続の確立が必要ない第１の通信方式により通信を行い、前記クライアントから要求された第１の処理を実行させる前記第１のサーバであって、
前記第１のサーバの要求に基づいて前記第１の処理のうち高負荷処理を実行する第２のサーバを複数有する第２のサーバ群であって、前記第１のサーバと前記第２のサーバとの間の通信毎に第１のサーバ−第２のサーバ群間の通信毎に接続の確立が必要な第２の通信方式により通信を行う第２のサーバ群と接続されることを特徴とする第１のサーバ。
【請求項７】
クライアントと第１のサーバとの間でクライアント−サーバ間通信の接続確立後に通信毎に接続の確立が必要ない第１の通信方式により通信を行い、前記クライアントから要求された第１の処理を前記第１のサーバにおいて実行するデータ処理方法であって、
前記クライアントからの第１の処理の実行要求に基づいて、前記第１のサーバが、第２のサーバを複数有する第２のサーバ群であって、前記第１のサーバと前記第２のサーバとの間の通信毎に第１のサーバ−第２のサーバ群間の通信毎に接続の確立が必要な第２の通信方式により通信を行う第２のサーバ群に前記第１の処理のうち高負荷処理を実行するよう要求するステップと、
前記高負荷処理の結果得られたデータを、前記第２のサーバから前記第１のサーバが受け取り、前記クライアントに送るステップと、を有することを特徴とするデータ処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ処理技術に関する。
【背景技術】
【０００２】
スマートフォンなどの携帯端末の普及に伴い、業務システムに、これらの携帯端末が用いられている。業務システムにおいては、データが大規模化、複雑化するため、業務システムに携帯端末を利用する上で、ユーザ操作に対する実用的な応答が難しくなっていく。例えば、特許文献１では、クライアント装置にＷｅｂページなどの長大なデータをスクロールしながら表示させる技術が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１３−１７５２０６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
例えば、クラウド、モバイルファーストによるモバイル端末からの業務システムを利用すると、データの大規模化、複雑化などによる画面の複雑化が生じる。例えば、描画処理などの高負荷処理に負荷がかかり、ユーザ操作に対する実用的な時間での応答ができないという問題がある。
【０００５】
例えば、図１５は、一般的なＷｅｂアプリにおけるクライアント−サーバ構成の一例を示す機能ブロック図である。データ処理のうち、高付加処理として画像表示を例にして説明する。
【０００６】
画像の更新が必要になると、クライアント４０１において、サーバ４１１にデータ取得要求Ｓ１を行い、サーバ４１１側で前処理Ｓ２を行った後に、クライアント４０１において高負荷処理（レンダリング処理）Ｓ３を実行する。しかしながら、一般的なコンピュータと異なり、性能の低いクライアント（スマートデバイス）４０１では、レンダリング等の高負荷処理Ｓ３の負荷が非常に重くなり、クライアント（スマートデバイス）４０１における処理が遅くなりすぎて実用に耐えられない場合が多いという問題がある。
【０００７】
本発明は、スマートデバイスを含むデータ処理技術において、高負荷処理への対応を容易にすることを目的とする。
【課題を解決するための手段】
【０００８】
本発明の一観点によれば、クライアントと第１のサーバとの間でクライアント−サーバ間通信の接続確立後に通信毎に接続の確立が必要ない第１の通信方式により通信を行い、前記クライアントから要求された第１の処理を実行させる前記第１のサーバと、前記第１のサーバの要求に基づいて前記第１の処理のうち高負荷処理を実行する第２のサーバを複数有する第２のサーバ群であって、前記第１のサーバと前記第２のサーバとの間の通信毎に第１のサーバ−第２のサーバ群間の通信毎に接続の確立が必要な第２の通信方式により通信を行う第２のサーバ群と、を有することを特徴とするデータ処理システムが提供される。
【０００９】
前記第１のサーバに対して、さらに前記第１のサーバ−第２のサーバ群間の通信毎の接続の確立が必要な第２の通信方式により通信を行う第２のサーバ群であって、前記第１のサーバの要求に基づいて前記第１の処理のうち高負荷処理を行う第２のサーバ群を設けることで、クライアントと第１のサーバとの間で、クライアント−サーバ間通信の接続確立後に通信回数に依存せずに任意に接続を維持する第１の通信方式により通信を行うことに起因する第１のサーバにおける処理の負荷の偏りを解消することができる。
【００１０】
前記第１のサーバと前記第２のサーバ群との間で、前記第２の通信方式により、前記第１の処理毎にデータ処理の負荷の分散を行う負荷分散装置を有することが好ましい。
【００１１】
前記第１のサーバと前記第２のサーバ群との間に設けられ、前記第２のサーバ群による前記高負荷処理を経たデータを格納するデータベースを有することが好ましい。
【００１２】
第１のサーバにおける高負荷処理データの保持に伴うメモリの占有化を抑制することができる。
【００１３】
前記データベース内に前記クライアントから要求された前記高負荷処理を経たデータが存在する場合には、前記第２のサーバ群における前記高負荷処理の実行を行わせる前記第１のサーバからの要求を行わないことを特徴とする。
【００１４】
これにより、元々存在する高負荷処理済データに関しては、前記第２のサーバ群における再度の前記高負荷処理を不要とすることができる。
【００１５】
前記第１のサーバは、自己の処理負荷を評価する処理負荷評価部を有し、前記処理負荷評価部の評価結果に基づいて、前記高負荷処理を前記第２のサーバに依頼するか自己により行うかを判断することを特徴とする。
【００１６】
これにより、前記第１のサーバは、自己で処理可能な負荷処理の前記第２のサーバへの依頼を不要とする。
【００１７】
また、本発明は、クライアントと第１のサーバとの間でクライアント−サーバ間通信の接続確立後に通信毎に接続の確立が必要ない第１の通信方式により通信を行い、前記クライアントから要求された第１の処理を実行させる前記第１のサーバであって、前記第１のサーバの要求に基づいて前記第１の処理のうち高負荷処理を実行する第２のサーバを複数有する第２のサーバ群であって、前記第１のサーバと前記第２のサーバとの間の通信毎に第１のサーバ−第２のサーバ群間の通信毎に接続の確立が必要な第２の通信方式により通信を行う第２のサーバ群と接続されることを特徴とする第１のサーバである。
【００１８】
また、本発明の他の観点によれば、クライアントと第１のサーバとの間でクライアント−サーバ間通信の接続確立後に通信毎に接続の確立が必要ない第１の通信方式により通信を行い、前記クライアントから要求された第１の処理を前記第１のサーバにおいて実行するデータ処理方法であって、前記クライアントからの第１の処理の実行要求に基づいて、前記第１のサーバが、第２のサーバを複数有する第２のサーバ群であって、前記第１のサーバと前記第２のサーバとの間の通信毎に第１のサーバ−第２のサーバ群間の通信毎に接続の確立が必要な第２の通信方式により通信を行う第２のサーバ群に前記第１の処理のうち高負荷処理を実行するよう要求するステップと、前記高負荷処理の結果得られたデータを、前記第２のサーバから前記第１のサーバが受け取り、前記クライアントに送るステップと、を有することを特徴とするデータ処理方法が提供される。
【００１９】
本発明は、上記に記載のデータ処理方法をコンピュータに実行させるためのプログラム、当該プログラムを記憶するコンピュータ読み取り可能な記録媒体であっても良い。
【発明の効果】
【００２０】
本発明によれば、スマートデバイスを含むデータ処理技術において、高負荷処理への対応を容易にすることができる。
【図面の簡単な説明】
【００２１】
【図１】本発明の実施の形態によるデータ処理システムの基本構成例の一例を示す図である。
【図２】図１に示すデータ処理システムを用いて、ＣＵＩＣサーバからクライアントであるスマートフォンの表示画面に画像を表示させる場合のイメージを示す図である。
【図３】図３（ａ）は、通信毎に接続の確立が必要な通信方式の例（ＨＴＴＰ）を示すタイミングチャート図であり、図３（ｂ）は、接続確立後に、任意に切断するまで接続を維持する通信方式の例（ＷｅｂＳｏｃｋｅｔ）を示すタイミングチャート図である。
【図４】本発明の第１の実施の形態によるデータ処理システムの一構成例を示す機能ブロック図である。
【図５】クライアントの一構成例を示す機能ブロック図である。
【図６】ＣＵＩＣサーバの一構成例を示す機能ブロック図である。
【図７】負荷分散装置の一構成例を示す機能ブロック図である。
【図８】レンダラサーバの一構成例を示す機能ブロック図である。
【図９】本発明の第２の実施の形態によるデータ処理システムの一構成例を示す機能ブロック図であり、図４に対応する図である。
【図１０】データベースＤＢの一構成例を示す機能ブロック図である。
【図１１】本実施の形態によるＣＵＩＣサーバの一構成例を示す機能ブロック図である。
【図１２】本発明の第３の実施の形態によるＣＵＩＣサーバの一構成例を示す機能ブロック図である。
【図１３】本発明の第４の実施の形態によるデータ処理システムの一構成例を示す機能ブロック図である。
【図１４】本実施の形態によるデータ処理システムで用いられるＣＵＩＣサーバの一構成例を示す機能ブロック図である。
【図１５】一般的なＷｅｂアプリにおけるクライアント−サーバ構成の一例を示す機能ブロック図である。
【発明を実施するための形態】
【００２２】
本明細書において、まず、以下の用語を定義する。
「ＣＵＩＣ」とは、既存Ｗｅｂアプリをスマートデバイスで利用するための“汎用的な”フレームワークである。
【００２３】
フレームワーク(ＦＷ)は、アプリケーションを開発する際に汎用的に利用可能な機能を提供する。ＦＷを利用してアプリケーションを開発することで汎用的な動作をスクラッチ開発する必要がなくなる。
【００２４】
ＦＷの対象領域としては、Ｗｅｂアプリケーションの開発に適用する。ＨＴＭＬ／JavaScript（登録商標）で構築されるＷｅｂページ内での利用を前提とするＷｅｂＵＩコンポーネントである。
【００２５】
レンダリングとは、画像や画面の内容を指示するデータの集まり(数値や数式のパラメータ、描画ルールを記述したものなど)をコンピュータプログラムで処理して、具体的な画素の集合を得ることである。
【００２６】
ＷｅｂＳｏｃｋｅｔは、サーバとクライアントが一度コネクションを行った後は、必要な通信を全てそのコネクション上で専用のプロトコルを用いて行う通信規格である。従来の通信規格に比べると、新たなコネクションを張ることがなくなる、HTTPコネクションとは異なる軽量プロトコルを使うなどの理由により通信ロスが減る、一つのコネクションで全てのデータ送受信が行えるため同一サーバに接続する他のアプリケーションへの影響が少ないなどのメリットがある。
【００２７】
以下、本発明の実施の形態によるデータ処理システムについて、図面を参照しながら詳細に説明する。尚、以下において、高負荷処理の一例として画像処理を例にしているが、動画処理、学習処理、予測処理、シミュレーション処理など、画像処理に限定されるものではない。
【００２８】
（第１の実施の形態）
図１は、本発明の実施の形態によるデータ処理システムの基本構成例（基本処理例）の一例を示す図である。
【００２９】
図１に示すデータ処理システムＡは、クライアント１と第１のサーバであるＣＵＩＣサーバ２１とを有している。クライアント１とＣＵＩＣサーバ２１との間において、画像の送受信等にはＷｅｂＳｏｃｋｅｔを利用している。
【００３０】
例えば、クライアント１から画像更新要求（Ｓ１１）がＣＵＩＣサーバ２１に送られると（Ｌ１）、ＣＵＩＣサーバ２１において、レンダリング処理等の前処理が行われ（Ｓ１３）、次いで、高負荷処理である画像のレンダリング処理／画像生成処理が行われ（Ｓ１４）、その画像が保持される（Ｓ１５）。
【００３１】
ＣＵＩＣサーバ２１は、クライアント１に対して画像を送信し（Ｌ２）、クライアント１は、受け取った画像を表示する（Ｓ１２）。
【００３２】
図１に示す構成では、高負荷処理をＣＵＩＣサーバ２１により行うため、クライアント１の負荷が少なくなる。また、画像の送受信にＷｅｂＳｏｃｋｅｔを利用しているため、クライアント１で画像処理を行う場合に比べて不利になる要因である、追加の通信処理の高速化を実現することができ、総合的には画像処理の高速化が可能となる。
【００３３】
図２は、図１に示すデータ処理システムＡを用いて、ＣＵＩＣサーバ２１からクライアント１である例えばスマートフォンの表示画面に画像を表示させる場合のイメージを示す図である。図２（ａ）のように、例えば業務計画を表示した広い領域の画像を、図２（ｂ）のようにスマートフォンの小さな表示画面で見ようとすると、スマートフォン（クライアント）１におけるスクロールに応じて新たな画像が必要となる毎に画像をスマートフォン１へ送信する必要がある。同様に、スマートフォン１において不要となった画像は、スマートフォン１のメモリ内から削除する必要がある。従って、クライアント−ＣＵＩＣサーバ間通信において、高速性が求められる。
【００３４】
そこで、図３において、図３（ａ）に示すような、例えば、ＨＴＴＰによる画像送受信のように通信毎に接続の確立が必要な通信方式ではなく、図３（ｂ）に示すような、例えばＷｅｂＳｏｃｋｅｔのように、接続確立後に、任意に通信を切断するまで接続を維持する通信方式を採用することが考えられる。
【００３５】
ところで、クライアント１が複数になると（或いはクライアント１からの要求が複数になると）、ＣＵＩＣサーバ２１は、複数のクライアントからの要求に応じて、大量の画像処理を行う必要がある。従って、ＣＵＩＣサーバ２１を設けても、例えば多クライアントの場合には、負荷軽減対策が必要になる。
【００３６】
そこで、クライアント１とＣＵＩＣサーバ２１との間に、負荷分散装置を設けるのが、一般的な負荷対策である。しかしながら、図１のように、クライアント１とＣＵＩＣサーバ２１との間の通信にＷｅｂＳｏｃｋｅｔを用いると、以下のような問題が生じる。
【００３７】
すなわち、クライアント１とＣＵＩＣサーバ２１との間の通信にＷｅｂＳｏｃｋｅｔを用いると、初期設定時に接続するＣＵＩＣサーバ２１が固定される。従って、クライアント１の利用状況によっては、ＣＵＩＣサーバ群中のいずれかに負荷が偏ることになる。
【００３８】
図４は、本実施の形態によるデータ処理システムＢの一構成例（処理例）を示す機能ブロック図である。図５から図８までは、本実施の形態によるデータ処理システムＢの各構成要素の一構成例を示す機能ブロック図である。
【００３９】
図４に示すように、データ処理システムＢは、クライアント１−１、１−２、…と、ＣＵＩＣサーバ（第１のサーバ）２１と、負荷分散装置（ＬＢ）３１と、複数のレンダラサーバ（第２のサーバ）群４１と、を有している。クライアント−ＣＵＩＣサーバ間のみＷｅｂＳｏｃｋｅｔを用い、その他の通信は、例えば、ＨＴＴＰを用いる。レンダラサーバ４１は、ＣＵＩＣサーバ２１の高負荷処理を分担する第２のサーバと称することができる。ここでは、高負荷処理の一例として画像処理を挙げているため、レンダラサーバとの呼称を用いた。
【００４０】
図５に示すように、クライアント１は、タッチパネルなどの入力部３と、各種処理を制御する制御部５と、ＣＵＩＣサーバ２１等とＷｅｂＳｓｏｃｋｅｔに基づく通信を行う通信部７と、画像等を表示する表示部（タッチパネルの場合には一部、入力部を兼ねる）１１と、アプリケーションプログラムやデータ等を記憶する記憶部１５と、を有している。
【００４１】
図６に示すように、ＣＵＩＣサーバ２１は、ＷｅｂＳｏｃｋｅｔに基づく通信を行う通信部２３と、制御部２５と、ＨＴＴＰに基づく通信を行う通信部２７とを有している。制御部２５は、画像処理等の高負荷処理の前処理を行う前処理部２５−１と、画像生成の要求を行う画像生成要求部２５−３と、画像を保持する画像保持部２５−５と、高負荷処理の存在の確認を行う処理負荷評価部（高負荷処理存在確認部、レンダリング要否判定部）２５−７と、を有する。
【００４２】
図７に示すように、負荷分散装置３１は、ＣＵＩＣサーバ２１との通信を行う通信部３３と、制御部３５と、レンダラサーバ４１との通信を行う通信部３７とを有する。制御部３５は、ＣＵＩＣサーバ２１から依頼された高負荷処理の負荷を分散する負荷分散部３５−１を有する。
【００４３】
図８に示すように、レンダラサーバ４１は、負荷分散装置３１との通信を行う通信部４３と、高負荷処理、例えば、レンダリング処理／画像生成処理を行うレンダリング／画像生成部４５−１を有する制御部４５と、を有している。
【００４４】
例えば、クライアント１−１とクライアント１−２とにおいて、入力部３からそれぞれ画像更新操作（Ｓ２１、Ｓ２２）が行われると、それぞれのクライアント１−１、１−２の通信部７からＣＵＩＣサーバ２１に対して画面更新処理１（Ｓ２３）と画面更新処理２（Ｓ２５）を行うように要求が送られる。ＷｅｂＳｏｃｋｅｔを利用して通信するため、クライアント１−１、１−２は、ＣＵＩＣサーバ２１に常時接続されている。ＣＵＩＣサーバ２１の通信部２３は、この要求を受け取り、ここで、ＣＵＩＣサーバ２１内における画面更新処理１（Ｓ２３）と画像更新処理２（Ｓ２５）とに関して、前処理部２５−１が高負荷処理とは異なる前処理１ａ（Ｓ２４）、２ａ（Ｓ２６）を行う。そして、画像生成要求部２５−３が、負荷分散装置３１に対して、高負荷処理のみをレンダラサーバ群４１に負荷分散する旨の要求を行う（Ｌ３、Ｌ４）。
【００４５】
負荷分散装置３１において、通信部３３はＣＵＩＣサーバ２１からの画像生成要求を受け取り、制御部３５内の負荷分散部３５−１において演算を行い、通信部３７を介して、レンダラサーバ群４１に含まれるレンダラサーバ４１−１〜４１−Ｍのうち、画面更新処理１と画像更新処理２とに関して、レンダリング処理／画像生成処理を行わせるレンダラサーバを指定して、高負荷処理を依頼する（Ｌ５、Ｌ６）。
【００４６】
指定された各レンダラサーバ４１−１、…、４１−Ｍは、通信部４３において、高負荷処理の依頼を受け取り、レンダリング／画像生成部４５−１において、レンダリング／画像生成を行う（Ｓ２７，Ｓ２８）。この処理を行って生成された画像は、ＣＵＩＣサーバ２１の画像保持部２５−５に送られ、次いで、画像更新要求を行ったクライアント１に送られる。
【００４７】
以上のように、本実施の形態によれば、高負荷処理（例えば、レンダリング／画像生成処理）のみをＣＵＩＣサーバ２１とは異なるレンダラサーバ群４１に行わせることで、ＣＵＩＣサーバ２１とレンダラサーバ群４１との間をスケールアウトし、負荷を効率良く分散させることができる。
【００４８】
尚、高負荷処理でない処理、例えば、レンダリングを必要としない処理（スクロール処理等）は、クライアント１−ＣＵＩＣサーバ２１間で完結するようにすることで、ＷｅｂＳｏｃｋｅｔによる高速な応答を生かすことができる。
【００４９】
一方、高負荷処理、例えば、レンダリングを必要とする処理（画像更新処理等）については、レンダリングをレンダラサーバ群４１にスケールアウトすることで、ＣＵＩＣサーバ２１の負荷の偏りを抑制することができる。
【００５０】
従って、例えば、図２で示したような、スマートフォンにおけるスクロール操作に伴う大きな領域のうちの一部を表示させながら、表示させる領域を移動させていくような操作に対して、より高速な応答性が得られる。換言すれば、スマートフォンにおけるそれほど高くないハードウェア性能であっても、良好な応答性を得ることができるという利点がある。
【００５１】
（第２の実施の形態）
【００５２】
次に、本発明の第２の実施の形態について、詳細に説明する。
第１の実施の形態では、高負荷処理、例えばレンダリング処理を行った後の画像データは、ＣＵＩＣサーバ２１の画像保持部２５−５に保存している。
【００５３】
ところが、クライアント数やクライアントの要求数等が多くなると、画像保持部２５−５内の画像数が多くなりメモリを占有していくことになる。
【００５４】
図９は、本実施の形態によるデータ処理システムＣの一構成例（処理例）を示す機能ブロック図であり、図４に対応する図である。図９では、特徴を明確にし説明を簡単にするため、レンダラサーバを１つとし、負荷分散装置を省略しているが、図４のような構成でも良いし、図９のような構成でも良い。
【００５５】
図９が図４と本質的に異なる点は、ＣＵＩＣサーバ１２１、１２２やレンダラサーバ４１とは異なるデータベースなどのストレージ（ＤＢ）５１を新たに設け、ここに高負荷処理を経たデータを保持するようにした点である。以下、ストレージについてデータベースＤＢ５１で例示する。データベースＤＢ５１は、レンダラサーバ４１とＣＵＩＣサーバ１２１、１２２とに接続されている。
【００５６】
図１０は、データベースＤＢ５１の一構成例を示す機能ブロック図である。データベースＤＢ５１は、例えば通信部（ＨＴＴＰ）５３、５４と、画像データなど、レンダラサーバ４１で生成された高負荷処理を経たデータを保持するデータ保持部（メモリ等）５７と、データ保持に関する制御を行うデータ保持制御部５５と、を有している。
【００５７】
図１１は、本実施の形態によるＣＵＩＣサーバの一構成例を示す機能ブロック図である。図１１に示すように、ＣＵＩＣサーバ１２１、１２２は、ＷｅｂＳｏｃｋｅｔでクライアント１と通信を行う通信部２３と、ＨＴＴＰでレンダラサーバ４１、データベースＤＢ５１と通信を行う通信部２７と、制御部１２５と、を有している。制御部１２５は、画像確認部１２５−１と、画像取得部１２５−２とを有している。
【００５８】
図９を参照しながら、処理の内容を説明する。まず、クライアント１の画面更新操作（Ｓ３１）がＣＵＩＣサーバ１２１、１２２になされると、ＣＵＩＣサーバ１２１、１２２の画像確認部１２５−１が、ストレージ（ＤＢ）５１に対して当該画像がストレージ（ＤＢ）５１内に存在するか否か（画像の存在確認Ｓ３３）を問い合わせる（Ｌ１１）。例えば、データ保持制御部５５がデータ保持部５７を検索させて、当該画像の有無を確認し、その結果をＣＵＩＣサーバ１２１、１２２に返信する。
【００５９】
ここで、当該画像が存在するという返信があった場合には（Ｓ３４でＹ）、画像取得部１２５−２は、ストレージ（ＤＢ）５１から当該画像を取得し（Ｓ３５、Ｌ１２）、クライアント１に当該画像を送信する。これにより、クライアント１では、画面更新操作に応じた画像を画面表示（Ｓ３２）することができる。
【００６０】
一方、Ｓ３４でＮの場合には、ストレージ（ＤＢ）５１には当該画像が存在しないため、レンダラサーバ４１にレンダリング／画像生成を要求し（Ｌ１３）、レンダラサーバ４１におけるレンダリング／画像生成処理（Ｓ３６）、ストレージ５１への画像識別ＩＤ等の画像情報を提示しての画像保存指示（Ｓ３７、Ｌ１４）を経て、ＣＵＩＣサーバ１２１、１２２が画像を取得する（Ｓ３５、Ｌ１５）。取得した画像は、クライアント１に送られ、クライアント１による画面表示に用いられる。ＣＵＩＣサーバ１２１、１２２が画像を取得する場合には、Ｌ１２、Ｌ１５のいずれのルートから取得しても良い。
【００６１】
以下に、上記の仕組みを実現するためのストレージ（ＤＢ）５１におけるデータ保存形式の一例を示す。
【００６２】
【表１】
2017182269.tif 000003
【００６３】
表１に示すように、ストレージ（ＤＢ）５１への保存形式例は、Ｔ_ＳｃｒｅｅｎＩｍａｇｅと、Ｔ_ＩｍａｇｅＢｌｏｃｋと、からなる。
【００６４】
Ｔ_ＳｃｒｅｅｎＩｍａｇｅは、主に、画像を複数のブロックに分割した画像ブロックの組である画像ブロックセットの構造情報（データブロック情報）を格納する。
【００６５】
Ｔ_ＩｍａｇｅＢｌｏｃｋは、画像ブロックに関する情報を保持するテーブルであり、データ配列情報、ブロック画像等を有する。
【００６６】
【表２】
2017182269.tif 000004
【００６７】
表２は、Ｔ_ＳｃｒｅｅｎＩｍａｇｅのテーブル項目の一例を示す表である。表２に示すように、項目は以下の通りである。
１）Ｋｅｙ：  画像ブロックセットを一意に識別するための識別子であり、画像の存在確認や画像の取得時等に用いる。
２）TotalWidth、TotalHeight：  全てのブロックを組み合わせた際に出来る画像の幅と高さを示す情報である。
３）BlockWidth、BlockHeight：  ブロック画像の幅と高さを示す情報である。
【００６８】
【表３】
2017182269.tif 000005
【００６９】
表３は、Ｔ_ＩｍａｇｅＢｌｏｃｋのテーブル項目の一例を示す表である。表３に示すように、項目は以下の通りである。
１）Ｋｅｙ：  画像ブロックが所属する画像ブロックセットのkey値である。
２）XIndex、YIndex：  画像ブロックセット内での画像ブロックの位置である。
３）ImageBlock：  画像ブロック本体のデータを示す情報である。
【００７０】
これらのテーブルは一例であり、これらのテーブルを利用する例に限定されるものではない。
【００７１】
上記のような形式で、画像データ等をストレージ（ＤＢ）５１内に保存することで、クライアント１の要求に基づく画像更新処理を経た画像データ等をストレージ（ＤＢ）５１から取得し、クライアント１に返信することで、クライアント１における画像更新処理を確実に行うことができる。
【００７２】
以上に説明したように、本実施の形態によるデータ処理技術を用いることで、クライアント数の増加等に伴う画像等のデータの保存量の増加に伴って生じるＣＵＩＣサーバ内のメモリの占有率を抑制することができる。
【００７３】
また、ＣＵＩＣサーバの能力（メモリ容量等）に依存せずに、保存できる画像量を増加させることができるという利点がある
【００７４】
（第３の実施の形態）
【００７５】
次に、本発明の第３の実施の形態について説明する。
基本的な構成例は、図９と同様である。以下、異なる点について説明する。
【００７６】
図１２に示すように、本実施の形態によるＣＵＩＣサーバ２２１は、その制御部２２５内に、画像確認部２２５−１と、レンダリング制御部２２５−２とを有している。
【００７７】
そして、画像確認部２２５−１において、ストレージ（ＤＢ）５１内に画像が存在することが確認されると、レンダラサーバ４１におけるレンダリング処理（Ｓ３６）を省略する。
【００７８】
当該処理も、第２の実施の形態と同様に、表１から表３までのテーブル等によって示される保存形式で画像データをストレージ（ＤＢ）５１に保存することで、実現することができる。
【００７９】
以上に説明したように、本実施の形態によれば、ストレージ（ＤＢ）５１内に画像が存在することが確認されると、レンダラサーバ４１におけるレンダリング処理（Ｓ３６）を省略するため、ＣＵＩＣサーバとレンダラサーバ間の通信量を減らすことができる。従って、クライアントからの要求に応じたクライアントでの画像表示までの所要時間を短くすることができる。
【００８０】
尚、第２の実施の形態によるデータ処理技術と第３の実施の形態によるデータ処理技術とを、両方用いることで、ＣＵＩＣサーバにおけるメモリの枯渇防止とデータ処理の高速化とを実現することができる。
【００８１】
（第４の実施の形態）
【００８２】
次に、本発明の第４の実施の形態について、詳細に説明する。
第１の実施の形態において、ＣＵＩＣサーバをクラウド環境での運用することを想定すると、レンダラサーバの数は処理負荷に応じて変化することになる。そこで、稼動しているサーバ数が多くなるとレンダラサーバの数も多くする必要がある。
【００８３】
一方、時間帯によっては、画像更新等のリクエストがほとんど発生しない場合もある。
図１３は、本実施の形態によるデータ処理システムの一構成例を示す機能ブロック図である。図１４は、本実施の形態によるデータ処理システムＤで用いられるＣＵＩＣサーバ３２１の一構成例を示す機能ブロック図である。
【００８４】
図１４に示すように、本実施の形態によるデータ処理システムＤで用いられるＣＵＩＣサーバ３２１は、通信部２３、２７と、制御部３２５とを有している。
【００８５】
制御部３２５は、前処理部３２５−１と、スケールアウト識別処理部（処理負荷検出部）３２５−３と、スケールアウト要否指示部３２５−５と、レンダリング処理部３２５−７とを有している。
【００８６】
そして、クライアント１から画像更新要求（Ｓ４１）があると、ＣＵＩＣサーバ３２１では、前処理部３２５−１により前処理（Ｓ４２）が実行され、スケールアウト識別処理部（処理負荷検出部）３２５−３が、スケールアウト識別処理（Ｓ４３）を行う。スケールアウトとは、サーバの数を増やすことでサーバ群全体のパフォーマンスを向上させることであり、レンダラサーバ４１−１〜４１−Ｍの追加、削除を行うことである。そして、スケールアウト要否指示部３２５−５は、スケールアウトが必要であれば（Ｓ４４、Ｙ）、レンダラサーバ４１−１〜４１−Ｍの追加、削除を行わせる（Ｓ４６）。スケールアウトが必要でない（自己の負荷が小さい）場合には（Ｓ４４、Ｎ）、ＣＵＩＣサーバ３２１自身の処理能力によりレンダリング処理を行う（Ｓ４５）。この場合には、レンダラサーバ４１は稼動させないで良い。
【００８７】
尚、レンダラサーバ４１の空きがない場合にも、ＣＵＩＣサーバ３２１自身の処理能力によりレンダリング処理を行うようにしても良い。
【００８８】
そして、いずれの場合でも、得られた画像をクライアント１に送る。
本実施の形態によれば、レンダラサーバを無駄なく稼動させることで、システムリソースを有効活用させることができる。
【００８９】
上記も処理および制御は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）やＧＰＵ（Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）によるソフトウェア処理、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）やＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）によるハードウェア処理によって実現することができる。
【００９０】
また、上記の実施の形態において、添付図面に図示されている構成等については、これらに限定されるものではなく、本発明の効果を発揮する範囲内で適宜変更することが可能である。その他、本発明の目的の範囲を逸脱しない限りにおいて適宜変更して実施することが可能である。
【００９１】
また、本発明の各構成要素は、任意に取捨選択することができ、取捨選択した構成を具備する発明も本発明に含まれるものである。
【００９２】
また、本実施の形態で説明した機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより各部の処理を行ってもよい。尚、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。
【００９３】
また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
【００９４】
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また前記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。機能の少なくとも一部は、集積回路などのハードウェアで実現しても良い。
【産業上の利用可能性】
【００９５】
本発明は、データ処理装置に利用可能である。
【符号の説明】
【００９６】
Ａ〜Ｄ…データ処理システム、１…クライアント、３…入力部、５…制御部、２１…ＣＵＩＣサーバ（第１のサーバ）、２３…ＷｅｂＳｏｃｋｅｔに基づく通信を行う通信部、２５…制御部、２７…ＨＴＴＰに基づく通信を行う通信部、２５−１…前処理部、２５−３…画像生成要求部、２５−５…画像保持部、２５−７…高負荷処理存在確認部（レンダリング要否判定部）、３１…負荷分散装置、３５−１…負荷分散部、４１…レンダラサーバ（第２のサーバ）、５１…ストレージ（データベースＤＢ）。
【図１】
2017182269.tif 000006
【図２】
2017182269.tif 000007
【図３】
2017182269.tif 000008
【図４】
2017182269.tif 000009
【図５】
2017182269.tif 000010
【図６】
2017182269.tif 000011
【図７】
2017182269.tif 000012
【図８】
2017182269.tif 000013
【図９】
2017182269.tif 000014
【図１０】
2017182269.tif 000015
【図１１】
2017182269.tif 000016
【図１２】
2017182269.tif 000017
【図１３】
2017182269.tif 000018
【図１４】
2017182269.tif 000019
【図１５】
2017182269.tif 000020