(57)【要約】【課題】キャッシュサーバの導入効果を判断することを課題とする。【解決手段】検証サーバは、システム間で送受信される、データのリクエストに関するパケットを取得して蓄積する。検証サーバは、キャッシュ対象のデータを規定したキャッシュシナリオ毎に、蓄積したパケットを用いて、キャッシュサーバを導入した際にキャッシュ対象のデータに対するリクエストにかかる応答時間を推定する。検証サーバは、推定されたキャッシュシナリオ毎の応答時間に基づいて、キャッシュサーバを導入した際のシステム要求を満たすキャッシュシナリオを特定する。【選択図】図２
2015130018.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータに、
システム間で送受信される、データのリクエストに関するパケットを取得して蓄積し、
キャッシュ対象のデータを規定したキャッシュシナリオ毎に、前記蓄積したパケットを用いて、キャッシュサーバを導入した際に前記キャッシュ対象のデータに対するリクエストにかかる応答時間を推定し、
推定されたキャッシュシナリオ毎の応答時間に基づいて、前記キャッシュサーバを導入した際のシステム要求を満たす前記キャッシュシナリオを特定する
処理を実行させることを特徴とする検証プログラム。
【請求項２】
前記キャッシュシナリオ毎に、前記データがキャッシュされている場合にかかる前記応答時間の理論値を算出する処理を前記コンピュータにさらに実行させ、
前記推定する処理は、前記キャッシュシナリオのうち前記理論値が所定値以下のキャッシュシナリオに対して、前記応答時間を推定することを特徴とする請求項１に記載の検証プログラム。
【請求項３】
応答時間が閾値より長いデータ、出現頻度が閾値より高いデータ、多重度が所定値以上となるデータの組、キャッシュ容量が所定値以上となるデータの組の少なくとも１つに該当する前記キャッシュ対象のデータを、前記蓄積したパケットから特定し、特定したデータを規定した前記キャッシュシナリオを生成する処理を、前記コンピュータにさらに実行させることを特徴とする請求項１または２に記載の検証プログラム。
【請求項４】
前記推定する処理は、アプリケーションサーバがデータベースサーバに送信する要求に対する応答の送出タイミングを変化させて前記データベースサーバの動作を擬似して、前記応答時間を推定することを特徴とする請求項１から３のいずれか一つに記載の検証プログラム。
【請求項５】
前記システム内の各リクエストについて開始時間と終了時間とを測定して、前記リクエストが最も多重する最大多重度を特定し、
特定した最大多重度に基づいて、導入対象のキャッシュサーバのメモリ容量を決定する処理を前記コンピュータにさらに実行させることを特徴とする請求項１から４のいずれか一つに記載の検証プログラム。
【請求項６】
システム間で送受信される、データのリクエストに関するパケットを取得して蓄積する蓄積制御部と、
キャッシュ対象のデータを規定したキャッシュシナリオ毎に、前記蓄積されたパケットを用いて、キャッシュサーバを導入した際に前記キャッシュ対象のデータに対するリクエストにかかる応答時間を推定する推定部と、
前記推定部によって推定されたキャッシュシナリオ毎の応答時間に基づいて、前記キャッシュサーバを導入した際のシステム要求を満たす前記キャッシュシナリオを特定する特定部と
を有することを特徴とする検証装置。
【請求項７】
コンピュータが、
システム間で送受信される、データのリクエストに関するパケットを取得して蓄積し、
キャッシュ対象のデータを規定したキャッシュシナリオ毎に、前記蓄積したパケットを用いて、キャッシュサーバを導入した際に前記キャッシュ対象のデータに対するリクエストにかかる応答時間を推定し、
推定されたキャッシュシナリオ毎の応答時間に基づいて、前記キャッシュサーバを導入した際のシステム要求を満たす前記キャッシュシナリオを特定する
処理を含んだことを特徴とする検証方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、検証プログラム、検証装置および検証方法に関する。
【背景技術】
【０００２】
システムを構成するサーバ間で多数のデータを送受信する場合、サーバ内のハードディスクドライブへのアクセスでは時間がかかり、サーバ内のキャッシュメモリでは容量が足りないことから、キャッシュサーバを設置する方法が利用されている。
【０００３】
例えば、サーバは、データＡについてキャッシュメモリに記憶させておき、データＢについてキャッシュサーバに記憶させるなど、データごとにキャッシュさせる先を変更することで、データの読み出し等にかかる時間を短縮する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平４−１８２７５５号公報
【特許文献２】特開２００４−１３９３６６号公報
【特許文献３】特開２０００−２９７６５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、キャッシュサーバをシステムに導入して期待する効果が得られるかは、システムの作りやキャッシュするデータによって異なることから、システム管理者であっても判断が難しい。
【０００６】
１つの側面では、キャッシュサーバの導入効果を判断することができる検証プログラム、検証装置および検証方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
１つの態様では、検証プログラムは、システム間で送受信される、データのリクエストに関するパケットを取得して蓄積する処理をコンピュータに実行させる。検証プログラムは、キャッシュ対象のデータを規定したキャッシュシナリオ毎に、前記蓄積したパケットを用いて、キャッシュサーバを導入した際に前記キャッシュ対象のデータに対するリクエストにかかる応答時間を推定する処理をコンピュータに実行させる。検証プログラムは、推定されたキャッシュシナリオ毎の応答時間に基づいて、前記キャッシュサーバを導入した際のシステム要求を満たす前記キャッシュシナリオを特定する処理をコンピュータに実行させる。
【発明の効果】
【０００８】
本発明の一側面として、キャッシュサーバの導入効果を判断することができる。
【図面の簡単な説明】
【０００９】
【図１】図１は、実施例１に係るシステムの全体構成例を示す図である。
【図２】図２は、実施例１に係る検証サーバの機能構成を示す機能ブロック図である。
【図３】図３は、シナリオＤＢに記憶される情報の例を示す図である。
【図４】図４は、装置間が紐づいている環境における理論値の算出を説明する図である。
【図５】図５は、装置間が紐づいていない環境における理論値の算出を説明する図である。
【図６】図６は、検証値の算出を説明する図である。
【図７】図７は、キャッシュ効果を説明する図である。
【図８】図８は、キャッシュ効果が最大限発揮できるシナリオ選択の例を示す図である。
【図９】図９は、ＡＰ改善を見据えた場合にキャッシュ効果が大きいシナリオ選択の例を示す図である。
【図１０】図１０は、コストを抑えたシナリオ選択の例を示す図である。
【図１１】図１１は、コストを無視した最適なシナリオ選択の例を示す図である。
【図１２】図１２は、実施例１に係る検証処理の流れを示すフローチャートである。
【図１３】図１３は、実施例２に係るシナリオ生成処理の流れを示すフローチャートである。
【図１４】図１４は、実施例２に係るシナリオ生成の具体例１を説明する図である。
【図１５】図１５は、実施例２に係るシナリオ生成の具体例２を説明する図である。
【図１６】図１６は、実施例２に係るシナリオ生成の具体例３を説明する図である。
【図１７】図１７は、実動系が物理サーバで検証系が仮想マシンの場合のシステム構成例を示す図である。
【図１８】図１８は、実動系が仮想マシンで検証系が物理サーバの場合のシステム構成例を示す図である。
【図１９】図１９は、異なる物理サーバ上で実動系および検証系が仮想マシンで実現される場合のシステム構成例を示す図である。
【図２０】図２０は、同一物理サーバ上で実動系および検証系が仮想マシンで実現される場合のシステム構成例を示す図である。
【図２１】図２１は、キャッシュサーバのメモリ容量の推定を説明する図である。
【図２２】図２２は、ハードウェア構成例を示す図である。
【発明を実施するための形態】
【００１０】
以下に、本願の開示する検証プログラム、検証装置および検証方法の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。また、各実施例は、矛盾のない範囲で適宜組み合わせることができる。
【実施例１】
【００１１】
［全体構成］
図１は、実施例１に係るシステムの全体構成例を示す図である。図１に示すように、このシステムは、実動系システム１と検証系システム１０を有する。
【００１２】
実動系システム１は、複数のクライアント装置２、Ｗｅｂ／ＡＰサーバ３、ＤＢサーバ４、ＨＴＴＰ（Hyper  Text  Transfer  Protocol）キャプチャ装置５、ＳＱＬ（Structured  Query  Language）キャプチャ装置６を有する。
【００１３】
複数のクライアント装置２は、Ｗｅｂ／ＡＰサーバ３にアクセスして、Ｗｅｂサービスやアプリケーションを実行する装置であり、例えばパーソナルコンピュータ、スマートフォン、携帯端末などである。例えば、クライアント装置２は、Ｗｅｂ／ＡＰサーバ３にＨＴＴＰリクエストを送信し、当該リクエストに対する応答をＷｅｂ／ＡＰサーバ３から受信する。
【００１４】
Ｗｅｂ／ＡＰサーバ３は、Ｗｅｂサービスやアプリケーションを提供するサーバ装置である。このＷｅｂ／ＡＰサーバ３は、クライアント装置２からの要求に応じて処理を実行し、要求されたデータをＤＢサーバ４に書き込み、要求されたデータをＤＢサーバ４から読み出す。例えば、Ｗｅｂ／ＡＰサーバ３は、ＳＱＬ文をＤＢサーバ４に発行して、データの読み書きを実行する。
【００１５】
ＤＢサーバ４は、データを記憶するデータベースサーバである。ＤＢサーバ４は、Ｗｅｂ／ＡＰサーバ３から受信したＳＱＬ文を実行して、データの読み出しや書き込みを実行し、その結果をＷｅｂ／ＡＰサーバ３に応答する。
【００１６】
ＨＴＴＰキャプチャ装置５は、クライアント装置２からＷｅｂ／ＡＰサーバ３へ送信されたＨＴＴＰリクエストと、Ｗｅｂ／ＡＰサーバ３からクライアント装置２へ送信されたＨＴＴＰ応答とをキャプチャする装置である。例えば、ＨＴＴＰキャプチャ装置５は、ネットワークタップやスイッチのポートミラーリングなどを利用することができる。
【００１７】
ＳＱＬキャプチャ装置６は、Ｗｅｂ／ＡＰサーバ３からＤＢサーバ４へ送信されたＳＱＬ文やＤＢサーバ４からＷｅｂ／ＡＰサーバ３へ送信されたＳＱＬ応答をキャプチャする装置である。例えば、ＳＱＬキャプチャ装置６は、ネットワークタップやスイッチのポートミラーリングなどを利用することができる。
【００１８】
検証系システム１０は、検証サーバ２０と検証Ｗｅｂサーバ３０とを有する。なお、検証Ｗｅｂサーバ３０は、検証用に作成されたサーバ装置であり、Ｗｅｂ／ＡＰサーバ３と同様の機能を有する。
【００１９】
検証サーバ２０は、キャッシュサーバの処理を擬似的に実行し、実動系システム１にキャッシュサーバを導入した場合のデータレスポンスなどを検証するサーバ装置である。この検証サーバ２０は、ＨＴＴＰキャプチャ装置５とＳＱＬキャプチャ装置６と接続される。
【００２０】
例えば、検証サーバ２０は、実動系システム１で送受信される、データのリクエストに関するパケットを取得して蓄積する。そして、検証サーバ２０は、キャッシュ対象のデータを規定したキャッシュシナリオ毎に、蓄積したパケットを用いて、キャッシュサーバを導入した際にキャッシュ対象のデータに対するリクエストにかかる応答時間を推定する。その後、検証サーバ２０は、推定したキャッシュシナリオ毎の応答時間に基づいて、キャッシュサーバを導入した際のシステム要求を満たすキャッシュシナリオを特定する。
【００２１】
このように、検証サーバ２０は、キャッシュ対象データを規定した複数シナリオから、実環境でキャプチャしたデータにシナリオを適用した際の応答時間が、実環境より短くなるシナリオを特定するので、キャッシュサーバの導入効果を判断できる。
【００２２】
［検証サーバの構成］
図２は、実施例１に係る検証サーバの機能構成を示す機能ブロック図である。なお、Ｗｅｂ／ＡＰサーバ３は、一般的なＷｅｂサーバやアプリケーションサーバと同様の機能を有し、ＤＢサーバ４は、一般的なＤＢサーバと同様の機能を有するので、詳細な説明は省略する。図２に示すように、検証サーバ２０は、通信制御部２１、記憶部２２、制御部２３を有する。
【００２３】
通信制御部２１は、他のサーバ装置との通信を制御する処理部であり、例えばネットワークインタフェースカードなどである。例えば、通信制御部２１は、ＨＴＴＰキャプチャ装置５と接続され、ＨＴＴＰキャプチャ装置５がキャプチャしたＨＴＴＰリクエストやＨＴＴＰ応答を受信する。また、通信制御部２１は、ＳＱＬキャプチャ装置６と接続され、ＳＱＬキャプチャ装置６がキャプチャしたＳＱＬ文やＳＱＬ応答を受信する。
【００２４】
記憶部２２は、制御部２３が実行するプログラムや各種データを記憶する記憶装置であり、例えば半導体メモリやハードディスクなどである。この記憶部２２は、キャプチャＤＢ２２ａとシナリオＤＢ２２ｂとを有する。
【００２５】
キャプチャＤＢ２２ａは、実動系システム１でキャプチャされたパケットを記憶するデータベースである。具体的には、キャプチャＤＢ２２ａは、実動系システム１の各装置の間でやり取りされる、データの読み書きに対応するリクエストに関するパケットを記憶する。
【００２６】
例えば、キャプチャＤＢ２２ａは、クライアント装置２からＷｅｂ／ＡＰサーバ３へのＨＴＴＰリクエスト、Ｗｅｂ／ＡＰサーバ３からＤＢサーバ４へのＳＱＬ文、ＤＢサーバ４からＷｅｂ／ＡＰサーバ３へのＳＱＬ応答、Ｗｅｂ／ＡＰサーバ３からクライアント装置２へのＨＴＴＰ応答からなる一連のリクエストにおいて送受信される各パケットを記憶する。
【００２７】
シナリオＤＢ２２ｂは、キャッシュ対象のデータを規定したキャッシュシナリオを記憶するデータベースであり、どのデータをキャッシュさせた場合にどのような効果が得られるかを判断するためのシナリオを記憶する。図３は、シナリオＤＢに記憶される情報の例を示す図である。
【００２８】
図３に示すように、シナリオＤＢ２２ｂは、「要求Ｎｏ．、データ、応答時間（実測値）、キャッシュする要求データ」を対応付けて記憶する。ここで記憶される「要求Ｎｏ．」は、実動系システム１で発生したリクエストの順番を示す。「データ」は、当該リクエストで要求されたデータを示す。「応答時間（実測値）」は、リクエストが発生してから応答が返信されるまでの時間であり、実動系システム１でキャプチャされた情報である。「キャッシュする要求データ」は、検証環境において検証する際にキャプチャ対象とするデータを示す。
【００２９】
図３の場合、データＡ、Ｂ、Ａ、Ｂ、Ｂ、Ｃ、Ｄ、Ｂ、Ａ、Ｂの順に１０個のデータがパケットキャプチャされたことを示し、応答時間の実測値が順に５、１０、５、１０、１０、１５、２０、１０、５、１０ｍｓであったことを示す。また、応答時間の合計が１００ｍｓでデータ数が１０個であるから、１データの応答時間の平均値は１０ｍｓとなる。
【００３０】
また、キャッシュ対象のデータとして、Ａ、Ｂ、Ｃ、Ｄ、ＡＢ、ＡＣ、ＡＤ、ＢＣ、ＢＤ、ＣＤ、ＡＢＣ、ＡＢＤ、ＡＣＤ、ＢＣＤ、ＡＢＣＤが設定されており、キャッシュシナリオとして、順に１から１５まで設定されている。つまり、キャッシュシナリオＮｏ．１には、キャッシュ対象としてデータＡが規定されており、これは、データＡをキャッシュサーバにキャッシュすることを示す。同様に、キャッシュシナリオＮｏ．６には、キャッシュ対象としてデータＡとデータＣが規定されており、これは、データＡとデータＣをキャッシュサーバにキャッシュすることを示す。また、キャッシュシナリオＮｏ．１４には、キャッシュ対象としてデータＢとデータＣとデータＤが規定されており、これは、データＢとデータＣとデータＤをキャッシュサーバにキャッシュすることを示す。
【００３１】
また、各キャッシュシナリオには、各要求Ｎｏ．のデータに対する応答時間の理論値が設定されている。例えば、データＡをキャッシュするキャッシュシナリオＮｏ．１は、要求Ｎｏ．１のデータＡに対しては３ｍｓ、要求Ｎｏ．２のデータＢに対しては１０ｍｓ、要求Ｎｏ．３のデータＡに対しては３ｍｓが設定されている。さらに、要求Ｎｏ．４のデータＢおよび要求Ｎｏ．５のデータＢに対しては１０ｍｓ、要求Ｎｏ．６のデータＣに対しては１５ｍｓ、要求Ｎｏ．７のデータＤに対しては２０ｍｓが設定されている。また、要求Ｎｏ．８のデータＢに対しては１０ｍｓ、要求Ｎｏ．９のデータＡに対しては３ｍｓ、要求Ｎｏ．１０のデータＢに対しては１０ｍｓが設定されている。さらに、キャッシュシナリオＮｏ．１での応答時間の理論値の合計が９４ｍｓでデータ数が１０個であるから、１データの応答時間の平均値は９．４ｍｓとなる。
【００３２】
上記キャッシュシナリオＮｏ．１の場合、データＡをキャッシュするシナリオであることから、データＡについては実測値よりも理論値の方が短くなっており、その他のデータについては実測値と理論値が同じである。同様に、キャッシュシナリオＮｏ．７の場合、データＡとデータＤをキャッシュするシナリオであることから、データＡおよびデータＤについては実測値よりも理論値の方が短くなっており、その他のデータについては実測値と理論値が同じである。これは、キャッシュ対象データについては、ＤＢサーバ４ではなくキャッシュサーバからデータを読み出すことになるので、応答時間が短縮されることを示している。
【００３３】
（理論値の算出）
ここで、データＢをキャッシュする場合を例にして理論値の算出について説明する。なお、一例として、キャッシュサーバを用いた場合のデータ読み出し時間が１ｍｓであるとして説明する。また、ここで実行される処理は、後述する制御部２３が実行する。
【００３４】
図４は、装置間が紐づいている環境における理論値の算出を説明する図である。つまり、クライアント装置２−ＷｅＢ／ＡＰサーバ３−ＤＢサーバ４が紐づいている場合である。図４に示すように、ここでは、データＡ、データＢ、データＡ、データＢ、データＢが順にキャプチャされた例で理論値の算出を説明する。なお、各データのリクエストでは、クライアント装置２からＷｅｂ／ＡＰサーバ３への要求、Ｗｅｂ／ＡＰサーバ３からＤＢサーバ４への要求、ＤＢサーバ４からＷｅｂ／ＡＰサーバ３への応答、Ｗｅｂ／ＡＰサーバ３からクライアント装置２への応答が実行される。
【００３５】
まず、キャプチャデータについて説明すると、はじめのデータＡのリクエストでは、ＤＢサーバ４からのデータ読み出しに３ｍｓかかり、クライアント装置２が要求Ａを出してから応答Ａを受信するまでに５ｍｓかかっている。また、次のデータＢのリクエストでは、ＤＢサーバ４からのデータ読み出しに８ｍｓかかり、クライアント装置２が要求Ｂを出してから応答Ｂを受信するまでに１０ｍｓかかっている。
【００３６】
また、３番目のデータＡのリクエストでは、ＤＢサーバ４からのデータ読み出しに３ｍｓかかり、クライアント装置２が要求Ａを出してから応答Ａを受信するまでに５ｍｓかかっている。また、４番目と５番目のデータＢのリクエストでは、ＤＢサーバ４からのデータ読み出しに８ｍｓかかり、クライアント装置２が要求Ｂを出してから応答Ｂを受信するまでに１０ｍｓかかっている。
【００３７】
このようにキャプチャされた状態で、キャッシュサーバを用いた場合のデータ読み出し時間が１ｍｓとした場合のリクエストにかかる応答時間の理論値について説明する。まず、はじめのデータＡのリクエストでは、キャッシュ対象外であることから、キャプチャデータと同じ時間がかかるので、実測値と理論値とが同じになる。
【００３８】
次に、２番目のデータＢのリクエストでは、データＢがキャッシュ対象であることから、ＤＢサーバ４からのデータ読み出しが理論値の１ｍｓに短縮される。このため、クライアント装置２が要求Ｂを出してから応答Ｂを受信するまでが３ｍｓとなり、理論上、キャプチャデータの応答時間より７ｍｓ短縮される。
【００３９】
３番目のデータＡのリクエストでは、キャッシュ対象外であることから、キャプチャデータと同じ時間がかかるので、実測値と理論値とが同じになる。次に、４番目と５番目のデータＢのリクエストでは、キャッシュ対象であるので、ＤＢサーバ４からのデータ読み出しが理論値の１ｍｓに短縮される。このため、クライアント装置２が要求Ｂを出してから応答Ｂを受信するまでが３ｍｓとなり、理論上、キャプチャデータの応答時間より７ｍｓ短縮される。
【００４０】
このようにして、検証サーバ２０の検証実行部２５等は、要求Ｎｏ．１から１０までの各キャプチャデータを用いて、各キャッシュシナリオについて応答時間の理論値を算出することができる。また、検証実行部２５等は、各キャッシュシナリオの各要求Ｎｏ．のデータに対応付けて、応答時間の実測値と、応答時間の理論値と、ＤＢサーバ４が応答に係る時間を示すＡＰ−ＤＢ間の応答時間とを対応付けた情報を生成する。
【００４１】
なお、クライアント装置２−Ｗｅｂ／ＡＰサーバ３−ＤＢサーバ４が紐づいていない場合であっても理論値を算出することができる。図５は、装置間で紐づいていない環境における理論値の算出を説明する図である。なお、その他の条件等については図４と同様とする。
【００４２】
図５では、装置間が紐づいていないので、要求から応答までの時間ではなく、ＤＢサーバ４における読み出し時間に着目して、実測値と理論値とを比較する。具体的には、図５に示すように、１番目と３番目のデータＡのリクエストでは、キャプチャデータではＤＢサーバ４からのデータ読み出しに３ｍｓかかるが、データＡがキャッシュ対象ではないので、理論値も同じになる。
【００４３】
２番目、４番目、５番目のデータＢのリクエストでは、キャプチャデータではＤＢサーバ４からのデータ読み出しに８ｍｓかかる。その一方で、データＢがキャッシュ対象であることから、理論上、キャッシュサーバから１ｍｓで読み出されたと想定するので、データ読み出し時間が７ｍｓ短縮されると予想できる。
【００４４】
このように、キャッシュ対象外データについてはキャプチャされたデータ読み出し時間と理論値とが同じになり、キャッシュ対象データについてはデータ読み出し時間が１ｍｓに短縮される。この方法を用いて、各キャッシュシナリオについて応答時間の理論値を算出することもできる。
【００４５】
この結果、検証実行部２５等は、各キャッシュシナリオの各要求ＮＯ．のデータに対応付けて、応答時間の実測値と、応答時間の理論値と、ＤＢサーバ４が応答に係る時間を示すＡＰ−ＤＢ間の応答時間とを対応付けた情報を生成する。なお、ＡＰ−ＤＢ間の応答時間には、実動系システム１で実際にかかった時間を示すキャプチャデータ、理論上の値であるシミュレーション、シミュレーションで短縮される時間が含まれる。
【００４６】
図２に戻り、制御部２３は、検証サーバ２０全体の処理を司る処理部であり、パケット処理部２４、検証実行部２５、特定部２６を有する。例えば、制御部２３は、プロセッサなどの電子回路であり、各処理部は、プロセッサが有する電子回路やプロセッサが実行するプロセスなどに該当する。
【００４７】
パケット処理部２４は、実動系システム１で送受信されるデータリクエストに関するパケットをキャプチャリングする処理部であり、取得部２４ａと測定部２４ｂを有する。
【００４８】
取得部２４ａは、実動系システムで送受信されるパケットを取得してキャプチャＤＢ２２ａに格納する処理部である。具体的には、取得部２４ａは、クライアント装置２からＷｅｂ／ＡＰサーバ３に送信されるＨＴＴＰリクエストのパケットやＷｅｂ／ＡＰサーバ３からクライアント装置２に送信されるＨＴＴＰ応答のパケットを、ＨＴＴＰキャプチャ装置５から取得する。
【００４９】
また、取得部２４ａは、Ｗｅｂ／ＡＰサーバ３からＤＢサーバ４に送信されるＳＱＬ文のパケットやＤＢサーバ４からＷｅｂ／ＡＰサーバ３に送信されるＳＱＬ応答のパケットを、ＳＱＬキャプチャ装置６から取得する。
【００５０】
このように、取得部２４ａは、データＡのリクエストに関するパケットを取得する。また、取得部２４ａは、各データのリクエストに対応付けてパケットを格納する。つまり、取得部２４ａは、データＡのリクエストについて、ＨＴＴＰリクエスト、ＳＱＬ文、ＳＱＬ応答、ＨＴＴＰ応答の各パケットを対応付けて格納する。
【００５１】
測定部２４ｂは、各データの応答時間の実測値を測定する処理部である。具体的には、測定部２４ｂは、キャプチャＤＢ２２ａに格納されるパケットから、クライアント装置２からリクエストが送信されて、クライアント装置２が応答を受信するまでの時間を測定する。ここで測定された時間は、各データのリクエストの応答時間の実測値として、キャッシュシナリオの作成等に利用される。また、測定部２４ｂは、実動系システム１をパケットキャプチャリングして、各データのリクエストの応答時間を測定してもよい。
【００５２】
検証実行部２５は、シナリオ選択部２５ａ、クライアント擬似部２５ｂ、ＤＢサーバ擬似部２５ｃ、キャッシュサーバ擬似部２５ｄ、推定部２５ｅを有し、これらによって、キャッシュシナリオ毎にキャッシュ導入の効果を検証する処理部である。
【００５３】
シナリオ選択部２５ａは、検証対象のキャッシュシナリオを選択する処理部である。具体的には、シナリオ選択部２５ａは、検証処理が開始されると、キャッシュシナリオを１つ選択する。そして、シナリオ選択部２５ａは、選択したキャッシュシナリオを、クライアント擬似部２５ｂ、ＤＢサーバ擬似部２５ｃ、キャッシュサーバ擬似部２５ｄ、推定部２５ｅに通知する。
【００５４】
また、シナリオ選択部２５ａは、選択したキャッシュシナリオに対する検証処理が終了すると、未選択のキャッシュシナリオを選択して検証処理を実行させる。なお、シナリオ選択部２５ａは、選択順序は任意に設定できるが、例えばキャッシュシナリオＮｏ．の先頭から順に選択することができる。また、シナリオ選択部２５ａは、理論値が所定値以下のキャッシュシナリオを検証対象として絞り込むこともできる。このようにすることで、キャッシュサーバ導入後の効果の期待が小さいキャッシュシナリオに対する検証処理を省略することができるので、検証処理の短縮に繋がる。
【００５５】
クライアント擬似部２５ｂは、クライアント装置２の動作を擬似する処理部である。具体的には、クライアント擬似部２５ｂは、リクエストの開始であるＨＴＴＰリクエストの送信処理と、リクエストの終了であるＨＴＴＰ応答の受信処理とを擬似的に実行する。
【００５６】
例えば、クライアント擬似部２５ｂは、図３に示したキャッシュシナリオＮｏ．１のキャッシュシナリオの検証を行う場合に、各要求Ｎｏ．に対応するデータリクエストの送信と応答とを実行する。
【００５７】
一例を挙げると、クライアント擬似部２５ｂは、キャッシュシナリオＮｏ．１の場合、まず要求Ｎｏ．１のデータＡのＨＴＴＰリクエストに対応するパケットをキャプチャＤＢ２２ａから取得して、検証Ｗｅｂサーバ３０に送信する。そして、クライアント擬似部２５ｂは、要求Ｎｏ．１のデータＡのＨＴＴＰ応答を検証Ｗｅｂサーバ３０から受信すると、要求Ｎｏ．２のデータＢのＨＴＴＰリクエストに対応するパケットをキャプチャＤＢ２２ａから取得して、検証Ｗｅｂサーバ３０に送信する。
【００５８】
その後、クライアント擬似部２５ｂは、要求Ｎｏ．２のデータＢのＨＴＴＰ応答を検証Ｗｅｂサーバ３０から受信すると、要求Ｎｏ．３のデータＡのＨＴＴＰリクエストに対応するパケットをキャプチャＤＢ２２ａから取得して、検証Ｗｅｂサーバ３０に送信する。このようにして、クライアント擬似部２５ｂは、ＨＴＴＰリクエストを実行し、当該リクエストの応答を受信すると、次の要求Ｎｏ．に対応するＨＴＴＰリクエストを実行する。
【００５９】
ＤＢサーバ擬似部２５ｃは、ＤＢサーバ４の動作を擬似する処理部である。具体的には、ＤＢサーバ擬似部２５ｃは、キャッシュ対象以外のデータに対するＳＱＬ文を検証Ｗｅｂサーバ３０から受信し、受信したＳＱＬ文を実行して、データの読み出し等を実行し、そのＳＱＬ応答を検証Ｗｅｂサーバ３０に送信する。このＤＢサーバ擬似部２５ｃは、実動系システム１のＤＢサーバ４と同様の処理を実行し、ＤＢサーバ４と同様の処理時間を擬似して、ＳＱＬ文に応答する。
【００６０】
キャッシュサーバ擬似部２５ｄは、実動系システム１にキャッシュサーバを増設したことを想定して、キャッシュサーバの動作を擬似する処理部である。具体的には、キャッシュサーバ擬似部２５ｄは、キャッシュ対象のデータに対するＳＱＬ文を検証Ｗｅｂサーバ３０から受信し、受信したＳＱＬ文を実行して、データの読み出し等を実行し、そのＳＱＬ応答を検証Ｗｅｂサーバ３０に送信する。
【００６１】
ここで、キャッシュサーバ擬似部２５ｄは、キャッシュサーバからのデータ読み出しを１ｍｓと想定して、ＳＱＬ文に応答する。つまり、キャッシュサーバ擬似部２５ｄは、ＳＱＬ文を受信して応答するまでの時間を１ｍｓとして、キャッシュからのデータ読み出しを実行する。
【００６２】
なお、ここでは、理論値を同じ１ｍｓを想定する例を説明したが、これに限定されるものではない。例えば、キャッシュサーバ擬似部２５ｄは、実動系システム１のリクエストの処理数等から処理負荷を算出し、処理負荷に従った応答時間で応答することもできる。例を挙げると、キャッシュサーバ擬似部２５ｄは、検証実行する時間帯の処理負荷が所定値より高い場合には、キャッシュサーバからのデータ読み出しを１．６ｍｓと想定して処理することもできる。
【００６３】
推定部２５ｅは、キャッシュ対象のデータを規定したキャッシュシナリオ毎に、蓄積したパケットを用いて、キャッシュサーバを導入した際にキャッシュ対象のデータに対するリクエストにかかる応答時間を推定する処理部である。具体的には、推定部２５ｅは、クライアント擬似部２５ｂ、ＤＢサーバ擬似部２５ｃ、キャッシュサーバ擬似部２５ｄそれぞれが実行した処理を監視して、検証結果を生成する。
【００６４】
ここで、推定部２５ｅがキャッシュシナリオ毎に検証値を推定する例を説明する。図６は、検証値の算出を説明する図である。図６に示す例は、図４と同様の例で説明する。図６に示すように、はじめのデータＡのリクエストでは、キャッシュ対象外であることから、ＤＢサーバ擬似部２５ｃは、キャプチャデータと同じ時間間隔でデータＡを応答する。したがって、推定部２５ｅは、はじめのデータＡについては実測値と検証値とを同じと推定する。
【００６５】
次のデータＢのリクエストでは、キャッシュ対象であることから、キャッシュサーバ擬似部２５ｄは、理論値の１ｍｓでデータＢを応答する。したがって、推定部２５ｅは、２番目のデータＢが要求されてから応答するまでの時間を３ｍｓと推定し、実測値に比べて７ｍｓ短縮されると推定する。
【００６６】
次のデータＡのリクエストでは、キャッシュ対象外であることから、ＤＢサーバ擬似部２５ｃは、キャプチャデータと同じ時間間隔でデータＡを応答する。したがって、推定部２５ｅは、はじめのデータＡについては実測値と検証値とを同じと推定する。
【００６７】
次のデータＢのリクエストでは、キャッシュ対象であることから、キャッシュサーバ擬似部２５ｄは、理論値の１ｍｓでデータＢを応答する。したがって、推定部２５ｅは、２番目のデータＢが要求されてから応答するまでの時間を３ｍｓと推定し、実測値に比べて７ｍｓ短縮されると推定する。
【００６８】
さらに、次のデータＢのリクエストについても同様に、キャッシュ対象であることから、推定部２５ｅは、２番目のデータＢが要求されてから応答するまでの時間を４ｍｓと推定し、実測値に比べて６ｍｓ短縮されると推定する。
【００６９】
このように、推定部２５ｅは、キャッシュシナリオ毎に各擬似部が擬似して処理した各パケットの応答時間から、実動系システム１にキャッシュサーバを導入した場合の応答時間を推定する。また、推定部２５ｅは、キャッシュシナリオ毎に推定した推定値をキャッシュシナリオやキャッシュシナリオの実測値等と対応付けて記憶部２２に格納する。
【００７０】
特定部２６は、推定部２５ｅによって推定されたキャッシュシナリオ毎の応答時間に基づいて、キャッシュサーバを導入した際のシステム要求を満たすキャッシュシナリオを特定する処理部である。具体的には、特定部２６は、推定部２５ｅが記憶部２２に格納した推定結果から、ユーザのＳＬＡ（Service  Level  Agreement）を満たすキャッシュシナリオをユーザに提示する。
【００７１】
図７は、キャッシュ効果を説明する図である。図７に示すαは、最大キャッシュ効果指数である。最大キャッシュ効果指数は、応答時間の実測値と理論値との差分であり、Ｗｅｂ／ＡＰサーバ３のボトルネックがないことを想定し、キャッシュ効果が最大限発揮される場合の改善の度合いである。例えば、特定部２６は、「（実測値（Ａ）−理論値（Ｂ））／実測値（Ａ）」で、最大キャッシュ効果指数を算出する。
【００７２】
図７に示すβは、実キャッシュ効果指数である。実キャッシュ効果指数は、応答時間の理論値と検証値との差分であり、検証系システム１０においてＷｅｂ／ＡＰサーバ３のボトルネックが応答時間に反映された状態であり、実際のキャッシュ効果の度合いである。例えば、特定部２６は、「（実測値（Ａ）−検証値（Ｃ））／実測値（Ａ）」で、実キャッシュ効果指数を算出する。
【００７３】
図７に示すγは、限界キャッシュ効果指数である。限界キャッシュ効果指数は、応答時間の検証値と実測値との差分であり、Ｗｅｂ／ＡＰサーバのボトルネックが解消されると現れるキャッシュ効果の度合いである。例えば、特定部２６は、「（検証値（Ｃ）−理論値値（Ｂ））／検証値（Ｃ）」で、限界キャッシュ効果指数を算出する。
【００７４】
すなわち、理論値と検証値が近いほど、シミュレーションに近い動作であり、Ｗｅｂ／ＡＰサーバ３の負荷が少ない状態となる。つまり、限界キャッシュ効果指数（γ）が０に近いほど、現在の実動系システム１の構成で期待するキャッシュ効果が出ると予想できる。
【００７５】
一方、理論値と検証値が離れているほど、シミュレーションと異なる動作であり、Ｗｅｂ／ＡＰサーバ３の負荷が大きい状態となる。つまり、限界キャッシュ効果指数（γ）が１に近いほど、現在の実動系システム１の構成ではＷｅｂ／ＡＰサーバ３の負荷が高く、Ｗｅｂ／ＡＰサーバ３のスケールアップやスケールアウトを行うことで、キャッシュ効果が出ると予想できる。
【００７６】
上述したように、特定部２６は、検証実行部２５の各処理部によって得られた各キャッシュシナリオの検証結果を用いて、上記最大キャッシュ効果指数（α）、実キャッシュ効果指数（β）、限界キャッシュ効果指数（γ）を算出し、ＳＬＡを満たすキャッシュシナリオをユーザに提示する。
【００７７】
次に、特定部２６は、図８から図１１を用いて、ＳＬＡを満たすキャッシュシナリオの提示例を説明する。なお、図８から図１１のキャッシュシナリオＮｏ．は、図３と同じであるとする。図８は、キャッシュ効果が最大限発揮できるシナリオ選択の例を示す図である。図８に示すように、特定部２６は、各効果指数を算出した後、限界キャッシュ効果指数（γ）を昇順に並び替える。そして、特定部２６は、限界キャッシュ効果指数（γ）が小さい上位３つのキャッシュシナリオＮｏ．２、５、１３を特定する。
【００７８】
この結果、特定部２６は、キャッシュシナリオＮｏ．２をディスプレイ等に表示し、「データがＢであればキャッシュするとキャッシュサーバ導入の効果が最も期待できる」などのメッセージも表示する。また、特定部２６は、データがＡまたはＢであればキャッシュするキャッシュシナリオＮｏ．５、データがＡ、Ｃ、ＤのいずれかであればキャッシュするキャッシュシナリオＮｏ．１３についても、大きな効果が期待できる旨のメッセージを表示することもできる。
【００７９】
図９は、ＡＰ改善を見据えた場合にキャッシュ効果が大きいシナリオ選択の例を示す図である。図９に示すように、特定部２６は、各効果指数を算出した後、限界キャッシュ効果指数（γ）を降順に並び替える。そして、特定部２６は、限界キャッシュ効果指数（γ）が大きい上位３つのキャッシュシナリオＮｏ．９、１４、１５を特定する。
【００８０】
この結果、特定部２６は、キャッシュシナリオＮｏ．９をディスプレイ等に表示し、「データがＢまたはＤであればキャッシュする」などのメッセージも表示する。また、特定部２６は、データがＢ、Ｃ、ＤのいずれかであればキャッシュするキャッシュシナリオＮｏ．１４についても、ＡＰ改善によって効果が期待できる旨のメッセージを表示することもできる。同様に、特定部２６は、データがＡ、Ｂ、Ｃ、ＤのいずれかであればキャッシュするキャッシュシナリオＮｏ．１５についても、ＡＰ改善によって効果が期待できる旨のメッセージを表示することもできる。
【００８１】
図１０は、コストを抑えたシナリオ選択の例を示す図である。ここで、コストとは、キャッシュデータをキャッシュする際に用いるキャッシュメモリ等の容量やＡＰ改善にかかる費用などの合計であり、管理者等がキャッシュシナリオ毎に予め算出して設定することができる。なお、図１０では、コストの値が大きいほど、コストが大きいことを示す。図１０に示すように、特定部２６は、各効果指数を算出した後、コストを昇順に並び替える。そして、特定部２６は、コストが小さい上位３つのキャッシュシナリオＮｏ．２、９、８、５を特定する。
【００８２】
この結果、特定部２６は、キャッシュシナリオＮｏ．２をディスプレイ等に表示し、「データがＢであればキャッシュすると、コストを抑えつつキャッシュ効果が期待できる」などのメッセージも表示する。また、特定部２６は、データがＢまたはＤであればキャッシュするキャッシュシナリオＮｏ．９についても、コストを抑えつつキャッシュ効果が期待できる旨のメッセージを表示することもできる。同様に、特定部２６は、キャッシュシナリオＮｏ．８や５についても、コストを抑えつつキャッシュ効果が期待できる旨のメッセージを表示することもできる。
【００８３】
図１１は、コストを無視した最適なシナリオ選択の例を示す図である。図１１に示すように、特定部２６は、各効果指数を算出した後、実キャッシュ効果指数（β）を降順に並び替える。そして、特定部２６は、実キャッシュ効果指数（β）が大きい上位３つのキャッシュシナリオＮｏ．１５、１４、１２を特定する。
【００８４】
この結果、特定部２６は、キャッシュシナリオＮｏ．１５をディスプレイ等に表示し、「データがＡ、Ｂ、Ｃ、Ｄのいずれかであればキャッシュすると、コストは大きいがキャッシュ効果が最大限に期待できる」などのメッセージも表示する。また、特定部２６は、データがＢ、Ｃ、ＤのいずれかであればキャッシュするキャッシュシナリオＮｏ．１４についても、同様にコストに関係なくキャッシュ効果が期待できる旨のメッセージを表示することもできる。同様に、特定部２６は、データがＡ、Ｂ、ＤのいずれかであればキャッシュするキャッシュシナリオＮｏ．１２についても、コストに関係なくキャッシュ効果が期待できる旨のメッセージを表示することもできる。
【００８５】
［処理の流れ］
図１２は、実施例１に係る検証処理の流れを示すフローチャートである。図１２に示すように、検証サーバ２０の特定部２６は、検証処理が開示されると、ユーザが希望する要求を記憶部２２等から読み込む（Ｓ１０１）。また、検証実行部２５のシナリオ選択部２５ａは、管理者が設定して記憶部２２等に記憶される応答時間の閾値を読み込む（Ｓ１０２）。
【００８６】
その後、検証実行部２５は、キャッシュシナリオを１つ選択して、キャッシュサーバ擬似部２５ｄによるキャッシュサーバ擬似を開始させて（Ｓ１０３）、キャッシュシナリオについて検証処理を実行する。
【００８７】
そして、推定部２５ｅは、検証処理が未処理のシナリオが残っている場合（Ｓ１０４：Ｎｏ）、終了したシナリオについて応答時間の検証値を算出する（Ｓ１０５）。
【００８８】
続いて、特定部２６は、当該シナリオの応答時間の検証値がＳ１０１の要求を満たす場合（Ｓ１０６：Ｙｅｓ）、ユーザへの提示候補に追加する（Ｓ１０７）。一方、特定部２６は、当該シナリオの応答時間の検証値がＳ１０１の要求を満たさない場合（Ｓ１０６：Ｎｏ）、ユーザへの提示候補から除外する（Ｓ１０８）。
【００８９】
一方、Ｓ１０４において、検証処理が未処理のシナリオが残っていないと判定された場合（Ｓ１０４：Ｙｅｓ）、キャッシュサーバ擬似部２５ｄは、キャッシュサーバ擬似を終了する（Ｓ１０９）。
【００９０】
その後、特定部２６は、すべての検証対象のシナリオで応答時間の検証値がＳ１０２の閾値を満たさない場合（Ｓ１１０：Ｙｅｓ）、キャッシュサーバを導入しても効果がないことをユーザに提示する（Ｓ１１１）。
【００９１】
一方、特定部２６は、いずれかの検証対象のシナリオで応答時間の検証値がＳ１０２の閾値を満たす場合（Ｓ１１０：Ｎｏ）、提示候補としたシナリオを記憶部２２やディスプレイ等に出力する（Ｓ１１２）。さらに、特定部２６は、Ｓ１０１で受け付けたユーザの要件に合致する最適なシナリオを記憶部２２やディスプレイ等に出力する（Ｓ１１３）。
【００９２】
［効果］
このように、検証サーバ２０は、想定されるキャッシュ対象のデータの中から、最適なキャッシュ対象を短時間で検出することができる。また、検証サーバ２０は、ユーザの要件に合致するキャッシュシナリオの選択をユーザに提示することができるので、ユーザのキャッシュサーバ導入の判断にかかる時間を短縮できる。
【００９３】
また、検証サーバ２０は、理論値、実測値、試験結果で最適なキャッシュシナリオあるいは候補を見つけることができるので、キャッシュの導入にかかる時間を短縮できる。また、検証サーバ２０は、キャッシュの理論値でシナリオを絞り込むことで時間短縮の効果が見込める。また、検証サーバ２０は、キャッシュサーバを疑似することでキャッシュサーバセットアップの手間が削減できる。
【実施例２】
【００９４】
ところで、検証サーバ２０は、実動系システム１のパケットキャプチャを用いて、キャッシュシナリオを自動で生成することができる。そこで、実施例２では、検証サーバ２０がキャッシュシナリオを生成する例を説明する。
【００９５】
［処理の流れ］
図１３は、実施例２に係るシナリオ生成処理の流れを示すフローチャートである。図１３に示すように、検証実行部２５は、処理が開始されると、キャプチャＤＢ２２ａからキャプチャデータを読み込み（Ｓ２０１）、各データのリクエストについて応答時間の実測値を算出する（Ｓ２０２）。
【００９６】
そして、検証実行部２５は、管理者が設定した応答時間の閾値を読み込み（Ｓ２０３）、キャッシュサーバの仕様などシナリオ生成の制約条件を読み込み（Ｓ２０４）、シナリオ解析方法を読み込む（Ｓ２０５）。なお、この制約条件やシナリオ解析方法についても、管理者等がユーザからの要求に応じて作成する。
【００９７】
その後、検証実行部２５は、キャッシュシナリオ解析方法のうち処理が完了してない方法が残っている場合（Ｓ２０６：Ｎｏ）、未処理のキャッシュシナリオを抽出し（Ｓ２０７）、応答時間の理論値を算出する（Ｓ２０８）。
【００９８】
そして、検証実行部２５は、当該キャッシュシナリオの応答時間の理論値が予め指定された要件を満たさない場合（Ｓ２０９：Ｎｏ）、当該シナリオを試験対象から除外する（Ｓ２１０）。
【００９９】
一方、検証実行部２５は、当該キャッシュシナリオの応答時間の理論値が予め指定された要件を満たす場合（Ｓ２０９：Ｙｅｓ）、当該シナリオを試験対象に設定する（Ｓ２１１）。
【０１００】
そして、検証実行部２５は、すべてのキャッシュシナリオ解析方法で処理が完了した場合（Ｓ２０６：Ｙｅｓ）、Ｓ２１２を実行する。すなわち、検証実行部２５は、すべての検証対象のシナリオで応答時間の理論値がＳ２０３の閾値を満たさない場合（Ｓ２１２：Ｙｅｓ）、キャッシュサーバを導入しても効果がないことをユーザに提示する（Ｓ２１３）。一方、検証実行部２５は、いずれかの検証対象のシナリオで応答時間の理論値がＳ２０３の閾値を満たす場合（Ｓ２１２：Ｎｏ）、図１２の検証処理を実行する（Ｓ２１４）。
【０１０１】
［具体例１］
次に、図１４から図１６を用いてシナリオ生成の具体例を説明する。図１４は、実施例２に係るシナリオ生成の具体例１を説明する図である。図１４の左図に示すキャプチャデータは、要求ＮＯ．１から１０までのパケットキャプチャであり、データと当該データを要求したクライアント装置２が応答を受け取るまでの応答時間とを対応付けている。
【０１０２】
具体的には、１番目のデータＡは応答時間が５ｍｓ、２番目のデータＢは応答時間が１０ｍｓ、３番目のデータＡは応答時間が５ｍｓ、４番目のデータＢは応答時間が１０ｍｓ、５番目のデータＢは応答時間が１０ｍｓである。また、６番目のデータＣは応答時間が１５ｍｓ、７番目のデータＤは応答時間が２０ｍｓ、８番目のデータＢは応答時間が１０ｍｓ、９番目のデータＡは応答時間が５ｍｓ、１０番目のデータＢは応答時間が１０ｍｓである。
【０１０３】
そして、検証実行部２５は、キャプチャデータにしたがって、各データについて応答時間と出現確率とを算出する。具体的には、図１４の右図に示すように、検証実行部２５は、キャプチャデータにおいてデータＡが３つキャプチャされ、応答時間の合計が１５ｍｓであることから、応答時間の平均を５と算出し、出現確率を３／１０とする。また、検証実行部２５は、キャプチャデータにおいてデータＢが５つキャプチャされ、応答時間の合計が５０ｍｓであることから、応答時間の平均を１０と算出し、出現確率を５／１０とする。
【０１０４】
また、検証実行部２５は、キャプチャデータにおいてデータＣが１つキャプチャされ、応答時間の合計が１５ｍｓであることから、応答時間の平均を１５と算出し、出現確率を１／１０とする。また、検証実行部２５は、キャプチャデータにおいてデータＤが１つキャプチャされ、応答時間の合計が２０ｍｓであることから、応答時間の平均を２０と算出し、出現確率を１／１０とする。
【０１０５】
この結果から、例えば、検証実行部２５は、応答時間が長いトップ３をシナリオ作成ルール１とした場合、データがＢ、Ｃ、Ｄをキャッシュするキャッシュシナリオを生成する。一例を挙げると、検証実行部２５は、データＢ、データＣ、データＤ、データＢとＣ、データＢとＤ、データＣとＤ、データＢとＣとＤを、それぞれキャッシュ対象とするキャッシュシナリオを生成する。
【０１０６】
また、別例としては、検証実行部２５は、出現確率が高い２５％以上をシナリオ作成ルール２とした場合、データがＢをキャッシュするキャッシュシナリオを生成する。このようにして、検証実行部２５は、キャプチャデータから計測した応答時間の平均値や出現確率を任意に組み合わせて、キャッシュシナリオを生成する。
【０１０７】
［具体例２］
図１５は、実施例２に係るシナリオ生成の具体例２を説明する図である。図１５の左上図に示すキャプチャデータは、要求ＮＯ．１から１０までのパケットキャプチャであり、１つのデータ（多重度１）をキャッシュした場合に、キャッシュヒットするか否かを示す図である。
【０１０８】
具体的は、検証実行部２５は、キャプチャされたデータの順にキャッシュしていき、各データがキャッシュヒットするかキャッシュミスするかを判定し、その結果を生成する。図１５の左上図は、要求ＮＯ．毎のデータに対応付けて「多重度、保存期間、（before、cache  hit、after）」を対応付けている。
【０１０９】
「多重度」は、キャッシュできるデータ数であり、図１５の左上図の例では１である。「保存期間」は、キャッシュデータを保存する期間であり、図１５の左上図では無期限である。「before」は、データを受信した際に既にキャッシュされているデータを示す。「cache  hit」は、受信データがキャッシュヒットするか否かを示す。「after」は、受信データがキャッシュヒットするか否かを判定した後にキャッシュされるデータを示し、ここでは受信データとなる。
【０１１０】
例えば、検証実行部２５は、はじめのデータＡについては、いずれのデータもキャッシュされていないので、そのままキャッシュする。次に、検証実行部２５は、次のデータＢについては、データＡがキャッシュされているので、キャッシュミスと判定し、データＢをキャッシュする。
【０１１１】
続いて、検証実行部２５は、次のデータＡについては、データＢがキャッシュされているので、キャッシュミスと判定し、データＡをキャッシュする。さらに、検証実行部２５は、次のデータＢについては、データＡがキャッシュされているので、キャッシュミスと判定し、データＢをキャッシュする。そして、検証実行部２５は、次のデータＢについては、データＢがすでにキャッシュされているので、キャッシュヒットと判定し、データＢをキャッシュから取り出すと想定する。
【０１１２】
このように、検証実行部２５は、キャプチャされたデータの順にキャッシュしていき、各データがキャッシュヒットするかキャッシュミスするかを判定し、図１５の左上図に示す結果を生成する。
【０１１３】
また、図１５の左下図は、多重度が２の場合の例を示す図である。すなわち、キャッシュできるデータ数が２個の場合である。例えば、検証実行部２５は、はじめのデータＡについては、いずれのデータもキャッシュされていないので、そのままキャッシュする。次に、検証実行部２５は、次のデータＢについては、データＡがキャッシュされているので、キャッシュミスと判定し、データＢをキャッシュする。
【０１１４】
続いて、検証実行部２５は、次のデータＡについては、データＡとＢがキャッシュされているので、キャッシュヒットと判定し、データＡをキャッシュから取り出すと想定し、データＡもキャッシュする。さらに、検証実行部２５は、次のデータＢについては、データＡとＢがキャッシュされているので、キャッシュヒットと判定し、データＢをキャッシュから取り出すと想定し、データＢもキャッシュする。
【０１１５】
さらに、検証実行部２５は、次のデータＢについては、データＡとＢがキャッシュされているので、キャッシュヒットと判定し、データＢをキャッシュから取り出すと想定し、データＢもキャッシュする。さらに、検証実行部２５は、次のデータＣについては、データＡとＢがキャッシュされているので、キャッシュミスと判定し、先にキャッシュされているデータＡに代わってデータＣをキャッシュする。
【０１１６】
このように、検証実行部２５は、キャプチャされたデータを２多重でキャッシュしていき、各データがキャッシュヒットするかキャッシュミスするかを判定し、図１５の左下図に示す結果を生成する。
【０１１７】
検証実行部２５は、上述した手法で生成された図１５の左のキャッシュ状況から、キャッシュしたデータをシナリオ作成ルール３として、キャッシュシナリオを生成する。具体的には、検証実行部２５は、データがＢの場合にキャッシュするキャッシュシナリオと、データがＡまたはＢの場合にキャッシュするキャッシュシナリオとを生成する。
【０１１８】
［具体例３］
図１６は、実施例２に係るシナリオ生成の具体例３を説明する図である。図１６の右上図に示すキャプチャデータは、要求ＮＯ．１から１０までのパケットキャプチャであり、キャッシュ容量が８０００バイトの例を示す図である。
【０１１９】
具体的は、検証実行部２５は、キャプチャされたデータの順に、キャッシュ容量を超えるまでキャッシュした場合を想定し、その結果を生成する。図１６の右上図は、要求ＮＯ．毎のデータと応答時間に対応付けて「データ長、キャッシュ容量（使用量／８０００）、キャッシュ可能／不可能」を対応付けている。
【０１２０】
「データ長」は、データの容量を示し、データリクエストのパケット等から特定できる。「キャッシュ容量（使用量／８０００）」は、どのくらいの容量をキャッシュしているかを示す。「キャッシュ可能／不可能」は、キャッシュ容量に空きがある場合には可能が設定され、キャッシュ容量に空きがない場合には不可能が設定される。
【０１２１】
例えば、検証実行部２５は、はじめのデータＡについては、いずれのデータもキャッシュされていないので、キャッシュすると判定し、データの容量「５５００」を使用量に設定する。ここでは、検証実行部２５は、キャッシュ容量に空きがあるので、キャッシュ可能を設定する。
【０１２２】
次に、検証実行部２５は、次のデータＢについては、データＡがキャッシュされているが、データ長が「１０００」であるので、キャッシュ容量の上限値「８０００」に到達しないことから、キャッシュすると判定する。そして、検証実行部２５は、データの容量「５５００＋１０００」を使用量に設定する。ここでは、検証実行部２５は、キャッシュ容量に空きがあるので、キャッシュ可能を設定する。
【０１２３】
その後のデータＡとデータＢについては、すでにキャッシュされているので、キャッシュ可能か否かの判定から除外される。そして、データＣについて、検証実行部２５は、データＣのデータ長が「７０００」であり、データＣをキャッシュすると上限値を越えるので、キャッシュできないと判断する。同様に、データＤについても、検証実行部２５は、データＤのデータ長が「１５００」であり、データＤをキャッシュすると上限値に達するので、キャッシュできないと判断する。
【０１２４】
この結果、検証実行部２５は、データがＡまたはＢの場合にはキャッシュすることをシナリオ作成ルール４として、キャッシュシナリオを生成する。
【０１２５】
また、図１６の右下図に示すキャプチャデータは、要求ＮＯ．１から１０までのパケットキャプチャであり、キャッシュ容量が１６０００バイトの例を示す図である。この場合も、上述した手法と同様の手法で、検証実行部２５は、受信データのデータ長とキャッシュの空き容量とから、受信データがキャッシュできるか否かを判定する。
【０１２６】
この結果、検証実行部２５は、データＡ、Ｂ、Ｃ、Ｄをキャッシュすることができると判定する。したがって、検証実行部２５は、シナリオ作成ルール４として、データＡ、Ｂ、Ｃ、Ｄそれぞれをキャッシュする場合と、これらのデータの組合せをキャッシュする場合とを規定したキャッシュシナリオを生成する。
【０１２７】
［効果］
このように、検証サーバ２０は、パケットキャプチャからキャッシュ対象のデータを抽出して、キャッシュ条件を満たすキャッシュシナリオを自動で生成することができる。したがって、検証サーバ２０が、パケットキャプチャから想定されるキャッシュ状況を生成して検証することができるので、管理者が、複雑な条件にしたがってキャッシュシナリオを生成する時間を短縮することができる。
【０１２８】
また、管理者の作業負担を軽減できるので、検証処理が実行しやすくなり、既存システムに対するキャッシュサーバの導入判断が行い易くなる。このため、既存システムへ適切なキャッシュシナリオのキャッシュサーバを導入することができ、既存システムのスループットの改善が図れる。
【実施例３】
【０１２９】
ところで、実動系システム１の各サーバや検証系システム１０の各サーバは、物理サーバで実現することもでき、仮想マシンで実現することもできる。そこで、実施例３では、各サーバの実現形態の例について説明する。
【０１３０】
［検証系が仮想マシン］
図１７は、実動系が物理サーバで検証系が仮想マシンの場合のシステム構成例を示す図である。図１７に示すように、実動系システム１が有する装置構成は、図１と同様であり、各装置は物理サーバ等に物理装置で実現される。
【０１３１】
一方、検証系システム１０の検証サーバ２０は、ハイパーバイザなどの仮想化ソフトウェアを用いて、仮想マシンを実行するサーバ装置である。具体的には、検証サーバ２０は、ホストＯＳ上で仮想化ソフトウェアを動作させ、仮想マシンとして管理ゲストＯＳ、クライアント擬似ゲストＯＳ、Ｗｅｂ／ＡＰゲストＯＳ、ＤＢサーバ擬似ゲストＯＳ、キャッシュサーバ擬似ゲストＯＳを動作させる。また、検証サーバ２０は、仮想スイッチを用いて、各ゲストＯＳ間を接続する。
【０１３２】
管理ゲストＯＳは、図２で説明したパケット処理部２４と同様の処理を実行する仮想マシンであり、ＨＴＴＰキャプチャ装置５およびＳＱＬキャプチャ装置６を介して、パケットをキャプチャリングする。また、管理ゲストＯＳは、図２で説明したシナリオ選択部２５ａ、推定部２５ｅ、特定部２６各々と同様の処理も実行する。
【０１３３】
クライアント擬似ゲストＯＳは、図２で説明したクライアント擬似部２５ｂと同様の処理を実行し、Ｗｅｂ／ＡＰゲストＯＳは、図１で説明した検証Ｗｅｂサーバ３０と同様の処理を実行する。また、ＤＢサーバ擬似ゲストＯＳは、図２で説明したＤＢサーバ擬似部２５ｃと同様の処理を実行し、キャッシュサーバ擬似ゲストＯＳは、図２で説明したキャッシュサーバ擬似部２５ｄと同様の処理を実行する。
【０１３４】
このように、検証系システム１０を仮想マシンで実現することにより、メモリ量などのハードウェア資源の設定変更が容易である。また、仮想化環境であることから、検証のための物理サーバの台数を減らすことができるので、検証のためのコストを抑えることができる。
【０１３５】
［実動系が仮想マシン］
図１８は、実動系が仮想マシンで検証系が物理サーバの場合のシステム構成例を示す図である。図１８に示すように、実動サーバ４０は、ハイパーバイザなどの仮想化ソフトウェアを用いて、仮想マシンを実行するサーバ装置である。
【０１３６】
具体的には、実動サーバ４０は、ホストＯＳ上で仮想化ソフトウェアを動作させ、仮想マシンとしてＷｅｂ／ＡＰゲストＯＳとＤＢサーバゲストＯＳを動作させる。また、実動サーバ４０は、仮想スイッチを用いて、各ゲストＯＳおよびホスト間を接続する。また、実動サーバ４０は、ネットワークインタフェースカード（ＮＩＣ）と仮想スイッチとを介して、クライアント装置２とＷｅｂ／ＡＰゲストＯＳとを接続する。
【０１３７】
また、実動サーバ４０は、各ゲストＯＳ間を接続する仮想スイッチで、ＨＴＴＰキャプチャとＳＱＬキャプチャを実行する。検証サーバ２０は、この実動サーバ４０の仮想スイッチに接続して、パケットキャプチャリングを実行する。
【０１３８】
また、実動サーバ４０のＷｅｂ／ＡＰゲストＯＳは、図１で説明したＷｅｂ／ＡＰサーバ３と同様の機能を実行し、ＤＢサーバゲストＯＳは、図１で説明したＤＢサーバ４と同様の機能を実行する。
【０１３９】
このように、実動系システム１を仮想マシンで実現することにより、ＨＴＴＰキャプチャとＳＱＬキャプチャの時刻同期が容易であり、キャプチャデータの採取が容易になる。したがって、キャッシュシナリオの作成時間の短縮が図れる。また、各キャプチャ間の時刻同期が容易であることから、パケットキャプチャの精度や正確性が向上するので、キャッシュシナリオの正確性や検証処理の正確性の向上が図れる。
【０１４０】
［両系が異なる物理サーバの仮想マシン］
図１９は、異なる物理サーバ上で実動系および検証系が仮想マシンで実現される場合のシステム構成例を示す図である。図１９に示すように、実動サーバ４０は、図１８で説明した構成と同様であり、検証サーバ２０は、図１７で説明した構成と同じである。
【０１４１】
図１９に示すように、両系を仮想マシンで実現することで、ＨＴＴＰキャプチャとＳＱＬキャプチャの時刻同期が容易であり、キャプチャデータの採取が容易になるとともに、検証のための物理サーバの台数を減らすことができるので、コストが削減できる。また、両系を仮想マシンで実現することで、検証のために物理サーバを用意することなく、検証処理を実行できるので、ＡＰサーバの処理やＤＢサーバの処理が変更されるたびに、簡単に検証処理を実行することができる。したがって、各サーバの構成変更にともなってボトルネックを追従することができ、最適なキャッシュ条件を抽出することができる。
【０１４２】
［両系が同一物理サーバの仮想マシン］
図２０は、同一物理サーバ上で実動系および検証系が仮想マシンで実現される場合のシステム構成例を示す図である。図２０に示すように、物理サーバ１００は、図１８で説明した実動サーバ４０の各ゲストＯＳと、図１７で説明した検証サーバ２０の各ゲストＯＳとを動作させる。また、各ゲストＯＳの動作は、上記説明と同様である。
【０１４３】
図２０に示すように、両系を同一の物理サーバの仮想マシンで実現することで、物理資源の削減が実現できる。また、実動系システムの処理能力の余裕がある場合など、実動系システムに影響を与えない範囲で検証系システム１０の仮想マシンを常時動作させておくこともできる。この結果、キャッシュサーバの検証が容易である。このため、キャッシュサーバ導入後でも、各サーバの処理負荷等にあわせて検証処理を実行でき、キャッシュサーバのメモリ容量の改善や仮想プロセッサの改善等を実行することができる。
【実施例４】
【０１４４】
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に異なる実施例を説明する。
【０１４５】
（メモリ容量の推定）
図２１は、キャッシュサーバのメモリ容量の推定を説明する図である。図２１に示すように、検証サーバ２０の検証実行部２５は、データの読み出しまたは書き込みを実行するメッセージの多重度を判定する。
【０１４６】
図２１の場合、検証実行部２５は、メッセージＭ１Ｓが時刻ｔ１に発生して時刻ｔ３に終了することを検出する。また、検証実行部２５は、メッセージＭ２Ｓが時刻ｔ２に発生して時刻ｔ４に終了することを検出する。検証実行部２５は、メッセージＭ３Ｓが時刻ｔ３に発生して時刻ｔ７に終了することを検出する。
【０１４７】
また、検証実行部２５は、メッセージＭ４Ｓが時刻ｔ３に発生してその時間内に終了することを検出する。検証実行部２５は、メッセージＭ５Ｓが時刻ｔ５に発生して時刻ｔ６に終了することを検出する。検証実行部２５は、メッセージＭ６Ｓが時刻ｔ５に発生して時刻ｔ７に終了することを検出する。検証実行部２５は、メッセージＭ７Ｓが時刻ｔ６に発生して時刻ｔ７に終了することを検出する。
【０１４８】
この結果、検証実行部２５は、時刻ｔ３および時刻ｔ６で４つのメッセージが処理中であることを検出する。したがって、検証実行部２５は、１メッセージの容量をＭとした場合、キャッシュメモリの容量を最低４Ｍと決定することができる。したがって、キャッシュメモリ容量の下限値を決定することができ、メモリの見積り不足によるエラー等を回避することができる。
【０１４９】
（キャッシュアクセス）
上記実施例では、キャッシュサーバからのデータ読み出しを例に説明したが、キャッシュサーバへのデータ書き込みについても同様に処理することができる。
【０１５０】
（システム）
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともできる。あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【０１５１】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散や統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。例えば、ＨＴＴＰキャプチャ装置５やＳＱＬキャプチャ装置６は、検証サーバ２０が有していてもよい。
【０１５２】
（ハードウェア）
図２２は、ハードウェア構成例を示す図である。ここで示すハードウェア構成例は、図１で説明した各サーバの構成例であり、ここで物理サーバ１００として説明する。
【０１５３】
図２２に示すように、物理サーバ１００は、通信インタフェース１００ａ、入力装置１００ｂ、表示装置１００ｃ、記憶部１００ｄ、プロセッサ１００ｅを有する。なお、図２２に示したハードウェア構成は一例であり、他のハードウェアを有していてもよい。
【０１５４】
通信インタフェース１００ａは、他の装置との間で通信経路を確立して、データの送受信を実行するインタフェースであり、例えばネットワークインタフェースカードや無線インタフェースなどである。
【０１５５】
入力装置１００ｂは、ユーザ等からの入力を受け付ける装置であり、例えばマウスやキーボードなどである。表示装置１００ｃは、各種情報を表示するディスプレイやタッチパネルなどである。
【０１５６】
記憶部１００ｄは、各サーバの各種機能を実行するためのデータや各種プログラムを格納する記憶装置である。例えば、記憶部１００ｄは、図２で説明した各ＤＢと同様の情報を記憶する。記憶部１００ｄの一例としては、ＲＯＭ、ＲＡＭ、ハードディスクなどがある。
【０１５７】
プロセッサ１００ｅは、記憶部１００ｄに記憶されるプログラムやデータを用いて、各サーバとしての処理を制御する。プロセッサ１００ｅの一例としては、例えばＣＰＵやＭＰＵなどがある。このプロセッサ１００ｅは、ＲＯＭ等に記憶されるプログラムをＲＡＭに展開して、各種処理に対応する各種プロセスを実行する。例えば、プロセッサ１００ｅは、図２等に示した各処理部と同様の処理を実行するプロセスを動作させる。
【符号の説明】
【０１５８】
１  実動系システム
２  クライアント装置
３  Ｗｅｂ／ＡＰサーバ
４  ＤＢサーバ
５  ＨＴＴＰキャプチャ装置
６  ＳＱＬキャプチャ装置
１０  検証系システム
２０  検証サーバ
２１  通信制御部
２２  記憶部
２２ａ  キャプチャＤＢ
２２ｂ  シナリオＤＢ
２３  制御部
２４  パケット処理部
２４ａ  取得部
２４ｂ  測定部
２５  検証実行部
２５ａ  シナリオ選択部
２５ｂ  クライアント擬似部
２５ｃ  ＤＢサーバ擬似部
２５ｄ  キャッシュサーバ擬似部
２５ｅ  推定部
２６  特定部
【図１】
2015130018.tif 000003
【図２】
2015130018.tif 000004
【図３】
2015130018.tif 000005
【図４】
2015130018.tif 000006
【図５】
2015130018.tif 000007
【図６】
2015130018.tif 000008
【図７】
2015130018.tif 000009
【図８】
2015130018.tif 000010
【図９】
2015130018.tif 000011
【図１０】
2015130018.tif 000012
【図１１】
2015130018.tif 000013
【図１２】
2015130018.tif 000014
【図１３】
2015130018.tif 000015
【図１４】
2015130018.tif 000016
【図１５】
2015130018.tif 000017
【図１６】
2015130018.tif 000018
【図１７】
2015130018.tif 000019
【図１８】
2015130018.tif 000020
【図１９】
2015130018.tif 000021
【図２０】
2015130018.tif 000022
【図２１】
2015130018.tif 000023
【図２２】
2015130018.tif 000024