JP6107218B2 - 制御装置，制御方法，および制御プログラム - Google Patents

Description

本件は、制御装置，制御方法，および制御プログラムに関する。

従来、サーバからユーザ端末に対してネットワーク経由でサービスを提供する種々のシステムが知られている。このようなシステムでは、ユーザ端末は、サーバへサービスのリクエスト（要求）を発行し、サーバは、リクエストに対する処理を行ない、処理結果をレスポンス（応答）としてユーザ端末へ送信する。
サーバは、仮想サーバ上、又はOperating System（ＯＳ）上（つまり物理サーバ上）で、ユーザ端末に提供するサービス（アプリケーション）を実行する。例えば、サーバは、Central Processing Unit（ＣＰＵ）等の負荷が低いときには、起動中の１以上の仮想サーバ又はＯＳ（物理サーバ自体）をシャットダウン状態やスリープ状態等の停止状態に遷移させて、省電力制御を行なうことがある。

また、サーバは、システムの継続利用の観点から、継続してユーザ端末のリクエストを受け付けることが望ましいが、ＣＰＵの負荷が高いビジー状態である場合には、リクエストを受け付けることが難しい。
例えば、社内で利用される勤怠や出張旅費等の申請を受け付けるサービスでは、月曜日（またはその週の最初の営業日）の始業時から数時間、月度の締日、又は期末等の特定期間に、ユーザ端末からサーバへの接続要求のアクセスが集中すると考えられる。上述の特定期間以外ではサーバへのアクセスが少ないため、サーバは、省電力制御により、最大構成よりも少ない仮想サーバでサービスを提供したり、ＯＳ（物理サーバ自体）を停止状態にすると考えられる。

少ない仮想サーバでサービスを提供するサーバは、上述の特定期間に多数の要求を受信すると、仮想サーバの稼働数が少ないため、要求に係る処理が累積してビジー状態になり、ユーザ端末へ接続要求の応答を送信することが困難になる場合がある。また、ＯＳを停止状態にしたサーバは、上述の特定期間に多数の要求を受信しても、ユーザ端末へ接続要求の応答を送信することができない。これらの場合、接続要求を送信したユーザ端末は、サーバから応答を受け取って接続が確立できるまで、サーバへ接続要求の再送（リトライ）を繰り返す。

なお、関連する技術として、管理サーバが、リクエストを処理する複数の計算機の負荷状態に応じて、予備機の使用開始又は使用終了を管理する技術が知られている（例えば、特許文献１参照）。この技術では、管理サーバは、負荷量の閾値と負荷分散対象とすべき予備機の数とを対応付けた情報に基づいて、使用する予備機の数を増減させる。

特開２００５−１１３３１号公報

上述したシステムでは、サービスを利用中のユーザが多い状態で、新たにサービスへの接続要求を発行するユーザ端末が接続を確立できずに再送を繰り返すと、サーバ（ネットワーク）へのアクセスがさらに集中することになる。
少ない仮想サーバでサービスを提供するサーバにおいては、サーバへのアクセスが集中する結果、ビジー状態が悪化し、ユーザがサービスを利用し難い状況が深刻化するという問題がある。

また、ＯＳを停止状態にしたサーバにおいては、サーバへのアクセスが集中する結果、例えばサーバが起動処理を行なっている場合には、接続要求の受信により起動処理の遅延が発生し、サーバが応答処理を行なえる動作状態に遷移するまでに時間がかかる場合がある。この場合にも、ユーザがサービスを利用し難い状況が深刻化するという問題がある。
さらに、省電力制御を行なうサーバにおいては、ネットワークへのアクセスが集中する結果、ネットワークの輻輳が発生し、ユーザが他のサーバの提供するサービスについても利用し難い状況が発生し得る。

このように、上述したシステムでは、サーバ（処理装置）がユーザ端末（端末装置）からの要求に応答することが難しい停止状態である場合、ユーザ端末からの要求の再送に起因して、システム全体の性能が低下するという問題がある。
なお、上述した関連する技術では、上述した問題については考慮されていない。
１つの側面では、本発明は、処理装置が端末装置からの要求に応答することが難しい停止状態である場合に生じるシステムの性能低下を抑制することを目的とする。

なお、前記目的に限らず、後述する発明を実施するための形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本発明の他の目的の１つとして位置付けることができる。

本件の制御装置は、端末装置と前記端末装置からの要求に対して応答を行なう一以上の処理装置との間に介設され、前記処理装置の制御を行なう制御装置であって、前記端末装置からの要求の宛先である宛先処理装置が停止状態の場合、前記宛先処理装置に対して、停止状態から動作状態に遷移させる起動制御を行なう状態制御部と、前記宛先処理装置が停止状態の場合、前記一以上の処理装置の代わりに代理応答を行なう代理応答部に、前記端末装置に対する代理応答を実行させ、前記宛先処理装置が停止状態から動作状態に遷移すると、前記端末装置からの要求を前記宛先処理装置へ送信する要求制御部と、前記端末装置と前記代理応答部との間でセッションを確立し、前記セッションと前記端末装置の通信先である前記代理応答部とを対応付けた管理情報を管理し、前記宛先処理装置の状態が前記停止状態から前記動作状態に遷移した後、前記端末装置から前記宛先処理装置に前記要求が送信されたことに応じて、前記管理情報に対して前記セッションにおける前記端末装置の通信先を前記代理応答部から前記宛先処理装置に切り替えるセッション管理部と、をそなえる。

一実施形態によれば、処理装置が端末装置からの要求に応答することが難しい停止状態である場合に生じるシステムの性能低下を抑制することができる。

一実施形態に係る情報処理システムの構成例を示す図である。 図１に示すサービス環境制御サーバのハードウェア構成例を示す図である。 図１に示すサービス環境制御サーバの構成例を示す図である。 図１に示すサービス環境制御サーバが保持するサーバ状態情報ＤＢのデータ構造の一例を示す図である。 図１に示すサービス環境制御サーバが保持する制御条件定義情報ＤＢのデータ構造の一例を示す図である。 図１に示すサービス環境制御サーバが保持する制御情報ＤＢのデータ構造の一例を示す図である。 図１に示すサービス環境制御サーバが保持するセッション情報ＤＢのデータ構造の一例を示す図である。 図１に示すサービス環境制御サーバが保持する代理応答情報ＤＢのデータ構造の一例を示す図である。 一実施形態に係るサービス環境制御サーバの動作例を説明するフローチャートである。 一実施形態に係るサービス環境制御サーバの動作例を説明するシーケンス図である。 一実施形態に係るサービス環境制御サーバの動作例を説明するフローチャートである。 一実施形態に係るサービス環境制御サーバの動作例を説明するシーケンス図である。 一実施形態に係るサービス環境制御サーバの動作例を説明するフローチャートである。 一実施形態に係るサービス環境制御サーバの動作例を説明するフローチャートである。 一実施形態に係るサービス環境制御サーバの動作例を説明するシーケンス図である。 一実施形態に係るサービス環境制御サーバの動作例を説明するシーケンス図である。 一実施形態に係るサービス環境制御サーバの動作例を説明するシーケンス図である。

以下、図面を参照して実施の形態を説明する。
〔１〕一実施形態
〔１−１〕情報処理システムについて
図１は、一実施形態に係る情報処理システムの構成例を示す図である。図１に示すように、一実施形態に係る情報処理システムは、サービス環境制御サーバ１、ユーザ端末２、サービス提供システム３、及び管理装置４をそなえる。

ユーザ端末（端末装置）２は、ネットワーク５に接続され、サービス提供システム３へのリクエスト（要求）の発行処理を行なうとともに、サービス提供システム３からのレスポンス（応答）に応じた処理を行なう装置である。上述した処理を行なうため、ユーザ端末２は、少なくともＣＰＵ等のプロセッサ、メモリ、及びネットワーク５との間で有線又は無線による通信を行なうインタフェース（いずれも図示省略）をそなえる。なお、ユーザ端末２としては、スマートフォン、ＰＣ、又はタブレット等の種々の情報処理装置が挙げられる。また、ネットワーク５としては、インターネット又はイントラネット等の種々のネットワークが挙げられる。

サービス提供システム３は、ユーザ端末２へ所定のサービスを提供するシステムである。サービス提供システム３は、一例として、図１に示すように、勤怠管理サービスサーバ３ａ−１、出張申請サービスサーバ３ａ−２、勤怠情報Database（ＤＢ）３ｂ−１、及び出張旅費情報ＤＢ３ｂ−２をそなえる。なお、サービス提供システム３は、ハードウェアリソースとしての情報処理装置（図示省略）をそなえる。

勤怠管理サービスサーバ３ａ−１及び出張申請サービスサーバ３ａ−２は、ユーザ端末へ所定のサービスを提供する仮想サーバ又は物理サーバ（サービス提供サーバ）であり、ユーザ端末２からの要求に対して応答を行なう処理装置の一例である。
サービス提供システム３がそなえる情報処理装置は、少なくともＣＰＵ等のプロセッサ、メモリ、Hard Disk Drive（ＨＤＤ）等の記憶部、及びサービス環境制御サーバ１との間で有線又は無線による通信を行なうインタフェース（いずれも図示省略）を有する。情報処理装置は、各ハードウェアを用いて、仮想サーバ又は物理サーバとして、勤怠管理サービスサーバ３ａ−１又は出張申請サービスサーバ３ａ−２の機能を実現する。

勤怠管理サービスサーバ３ａ−１は、ユーザからの業務の勤怠情報の登録、更新、又は参照等のリクエストに応じて、所定の処理を行なうサーバであり、勤怠情報ＤＢ３ｂ−１は、ユーザごとの勤怠情報を保持するデータベースである。例えば、勤怠管理サービスサーバ３ａ−１は、ユーザ端末２からのリクエストに応じて、勤怠情報ＤＢ３ｂ−１に保持されたユーザごとの勤怠情報の登録、更新、読出等の処理を行ない、処理結果をレスポンスとしてユーザ端末２へ送信する。

出張申請サービスサーバ３ａ−２は、ユーザからの出張又は旅費に関する出張旅費情報の登録、更新、又は参照等のリクエストに応じて、所定の処理を行なうサーバであり、出張旅費情報ＤＢ３ｂ−２は、ユーザごとの出張旅費情報を保持するデータベースである。例えば、出張申請サービスサーバ３ａ−２は、ユーザ端末２からのリクエストに応じて、出張旅費情報ＤＢ３ｂ−２に保持されたユーザごとの出張旅費情報の登録、更新、読出等の処理を行ない、処理結果をレスポンスとしてユーザ端末２へ送信する。

以下、勤怠管理サービスサーバ３ａ−１及び出張申請サービスサーバ３ａ−２を区別しない場合には、サービス提供サーバ３ａ又は単にサーバ３ａという。
なお、サービス提供システム３は、図１に示す例では２つのサーバ３ａをそなえるものとして説明したが、これに限定されるものではなく、１以上のサーバ３ａをそなえることができる。

管理装置４は、サービス環境制御サーバ１の管理を行なう装置である。例えばサービス環境制御サーバ１又はサービス提供システム３の管理者は、管理装置４の操作を通じて、サービス環境制御サーバ１に後述する制御条件定義情報を設定する。
管理装置４は、ＣＰＵ等のプロセッサ、メモリ、サービス環境制御サーバ１との間で有線又は無線による通信を行なうインタフェース、及び入出力部（いずれも図示省略）をそなえる。入出力部は、例えばマウスやキーボード等の入力装置及びディスプレイやプリンタ等の出力装置の少なくとも一方を含んでよい。例えば、管理装置４のＣＰＵは、入出力部（入力装置）により管理者からの制御条件定義情報の入力を受け付け、インタフェースを介してサービス環境制御サーバ１へ送信する。また、管理装置４のＣＰＵは、サービス環境制御サーバ１からの制御の処理結果を出力装置に表示（出力）させる。

なお、図１に示す例では、管理装置４は、サービス環境制御サーバ１に接続されているが、ネットワーク５を介してサービス環境制御サーバ１に接続されてもよい。また、管理者が、サービス環境制御サーバ１の後述する入出力部１０ｅを用いてサービス環境制御サーバ１に制御条件定義情報を入力し、入出力部１０ｅに表示（出力）される処理結果を参照する場合には、管理装置４は省略されてもよい。

サービス環境制御サーバ（制御装置）１は、ユーザ端末２とサービス提供サーバ３ａとの間に介設され、サーバ３ａの制御を行なう情報処理装置である。
〔１−２〕サービス環境制御サーバのハードウェア構成
次に、図２を参照して、サービス環境制御サーバ１のハードウェア構成を説明する。図２は、図１に示すサービス環境制御サーバ１の構成例を示す図である。

サービス環境制御サーバ１は、図２に示すように、ＣＰＵ１０ａ、メモリ１０ｂ、記憶部１０ｃ、インタフェース１０ｄ、入出力部１０ｅ、記録媒体１０ｆ、及び読取部１０ｇをそなえる。
ＣＰＵ１０ａは、メモリ１０ｂ、記憶部１０ｃ、インタフェース１０ｄ、入出力部１０ｅ、記録媒体１０ｆ、及び読取部１０ｇと接続され、種々の制御や演算を行なう処理装置（プロセッサ）である。ＣＰＵ１０ａは、メモリ１０ｂ、記憶部１０ｃ、記録媒体１０ｆ、読取部１０ｇを介した記録媒体１０ｈ、又は図示しないRead Only Memory（ＲＯＭ）等に格納されたプログラムを実行することにより、サービス環境制御サーバ１における種々の機能を実現する。なお、ＣＰＵ１０ａに限らず、プロセッサとしては、Micro Processing Unit（ＭＰＵ）等の電子回路が用いられてもよい。

メモリ１０ｂは、種々のデータやプログラムを一時的に格納する記憶装置であって、ＣＰＵ１０ａがプログラムを実行する際に、データやプログラムを一時的に格納・展開して用いる。なお、メモリ１０ｂとしては、例えばRandom Access Memory（ＲＡＭ）等の揮発性メモリが挙げられる。
記憶部１０ｃは、例えばＨＤＤ等の磁気ディスク装置、Solid State Drive（ＳＳＤ）等の半導体ドライブ装置、フラッシュメモリ等の不揮発性メモリ等の各種デバイスであり、種々のデータやプログラム等を格納するハードウェアである。

インタフェース１０ｄは、有線又は無線により、サービス提供システム３及びネットワーク５との間の接続及び通信の制御を行なうコントローラである。
入出力部１０ｅは、例えばマウスやキーボード等の入力装置及びディスプレイやプリンタ等の出力装置の少なくとも一方を含んでよい。例えば入出力部１０ｅは、上述した管理者により、制御条件定義情報の入力及びサービス環境制御サーバ１による制御の処理結果の参照等に用いられる。

記録媒体１０ｆは、フラッシュメモリやＲＯＭ等の記憶装置であり、種々のデータやプログラムを記録する。読取部１０ｇは、光ディスクやUniversal Serial Bus（ＵＳＢ）メモリ等のコンピュータ読取可能な記録媒体１０ｈに記録されたデータやプログラムを読み出す装置である。
記録媒体１０ｆ及び１０ｈの少なくとも一方には、本実施形態に係るサービス環境制御サーバ１の機能を実現する制御プログラムが格納されてもよい。すなわち、ＣＰＵ１０ａは、記録媒体１０ｆ、又は読取部１０ｇを介して記録媒体１０ｈから入力された制御プログラムを、メモリ１０ｂ等の記憶装置に展開して実行することにより、サービス環境制御サーバ１の機能を実現する。

なお、上述した各ハードウェアは、互いにバスで通信可能に接続される。
また、情報処理システム間、つまりユーザ端末２及びネットワーク５間、サービス環境制御サーバ１及びネットワーク５間、並びにサービス環境制御サーバ１及びサービス提供システム３間は、有線接続及び無線接続のいずれの態様で接続されてもよい。有線接続におけるケーブルとしては、Local Area Network（ＬＡＮ）ケーブル、InfiniBand（インフィニバンド（登録商標））等のケーブル、Fibre Channel（ファイバチャネル）、又はＵＳＢケーブル等のシリアルケーブルが例として挙げられる。なお、ケーブルとして、パラレルケーブルが用いられてもよい。また、無線接続としては、無線ＬＡＮ、Bluetooth（登録商標）、又は無線ＵＳＢ等が例として挙げられる。なお、情報処理システム間は、上述した例示に限られず、種々の態様により接続することが可能である。

なお、サービス環境制御サーバ１の上述したハードウェア構成は例示である。従って、サービス環境制御サーバ１内でのハードウェアの増減や分割等は適宜行なわれてもよい。また、後述するサービス環境制御サーバ１の機能ごとに、図２に例示するハードウェアを有する情報処理装置がそなえられてもよい。
〔１−３〕サービス環境制御サーバの説明
次に、サービス環境制御サーバ１の詳細を説明する。

サービス環境制御サーバ１は、上述のように、サービス提供サーバ３ａの制御を行なう。例えば、サービス環境制御サーバ１は、ユーザ端末２及びサーバ３ａ間でやり取りされるリクエスト及びレスポンスを中継する。また、サービス環境制御サーバ１は、ユーザ端末２からのリクエストのパケットを監視し、監視結果に基づいて、サーバ３ａの状態制御を行なう。

具体的に、サービス環境制御サーバ１は、以下の（１）〜（３）の制御を行なう。
（１）ユーザ端末２によるサービス提供サーバ３ａの利用状況に基づき、所定の条件を満たすサービス提供サーバ３ａを動作状態から停止状態に遷移させる。
（２）上記利用状況に基づき、ユーザ端末２からのリクエストの宛先であるサービス提供サーバ３ａ（以下、宛先サーバ３ａともいう）及び宛先サーバ３ａのサーバ状態（状態）を判定する。宛先サーバ３ａが動作状態（動作中）の場合、リクエストを宛先サーバ３ａへ送信（中継）する。

（３）宛先サーバ３ａが停止状態の場合、以下の（３−１）及び（３−２）を行なう。
（３−１）宛先サーバ３ａに対して、停止状態から動作状態に遷移させる制御を行なうとともに、リクエストを送信したユーザ端末２に、宛先サーバ３ａが動作状態への遷移中である旨を、宛先サーバ３ａに代わって代理応答する。
（３−２）宛先サーバ３ａが動作状態に遷移すると、リクエストを宛先サーバ３ａへ送信（中継）する。

なお、動作状態とは、サービス提供サーバ３ａが、ユーザ端末２からのリクエストに対するレスポンスを送信可能である状態をいう。
また、停止状態とは、サービス提供サーバ３ａがユーザ端末２からの要求に応答することが難しい状態をいう。具体的には、停止状態には、サーバ３ａへの給電が停止したシャットダウン状態、及びサーバ３ａの一部のハードウェアへの給電が停止したスリープ状態の少なくとも一方が含まれてよい。

このように、サービス環境制御サーバ１は、上記（１）によって、ユーザ端末２によるサービスの利用状況に合わせて、サービス提供サーバ３ａを停止状態に遷移させるので、サービス提供サーバ３ａの省電力化を実現することができる。
また、サービス環境制御サーバ１は、上記（２）によって、サービス環境制御サーバ１がそなえられない場合と同様に、ユーザ端末２からのリクエストを宛先サーバ３ａへ渡すことができる。

さらに、サービス環境制御サーバ１は、上記（３）によって、宛先サーバ３ａが停止状態から動作状態に遷移するまでの間、代理応答を受信したユーザ端末２により接続要求等のリクエストが繰り返し再送（リトライ）されることを抑止することができる。これにより、サービス環境制御サーバ１は、宛先サーバ３ａ（ネットワーク５）へのアクセス集中を緩和することができる。従って、サービス環境制御サーバ１は、宛先サーバ３ａの処理負荷の低減を図ることができ、ユーザが宛先サーバ３ａのサービスを利用し難い状況の早期解消を実現することができる。また、サービス環境制御サーバ１は、ネットワークの輻輳の抑制を図ることができ、ユーザが他のサービス提供サーバ３ａのサービスを利用し難い状況に陥ることを抑止することができる。このように、サービス環境制御サーバ１は、上記（３）によって、システム全体の性能低下を抑制することができる。

〔１−４〕サービス環境制御サーバの構成例
以下、図３〜図８を参照して、サービス環境制御サーバ１の構成例を説明する。図３は、図１に示すサービス環境制御サーバ１の構成例を示す図である。図４〜図６は、それぞれ、図１に示すサービス環境制御サーバ１が保持するサーバ状態情報ＤＢ１３ｃ、制御条件定義情報ＤＢ１２ｄ、及び制御情報ＤＢ１２ｅのデータ構造の一例を示す図である。図７及び図８は、それぞれ、サービス環境制御サーバ１が保持するセッション情報ＤＢ１２ｆ及び代理応答情報ＤＢ１４ａのデータ構造の一例を示す図である。

サービス環境制御サーバ１は、図３に示すように、受付部１１、制御管理部１２、サーバ管理部１３、及び代理応答部１４をそなえる。
〔１−４−１〕サーバ管理部の説明
サーバ管理部１３は、サービス提供サーバ３ａとの間でデータ及びコマンド等の情報のやり取りを行なう。具体的には、サーバ管理部１３は、サービス提供サーバ３ａからサーバ状態（状態）を取得する。また、サーバ管理部１３は、サーバ３ａの状態制御を行なう。

サーバ管理部１３は、一例として、サーバ状態取得部１３ａ、サーバ制御部１３ｂ、及びサーバ状態情報ＤＢ１３ｃをそなえる。
サーバ状態取得部（状態取得部）１３ａは、サービス提供サーバ３ａからサーバ状態を取得する。例えば、サーバ状態取得部１３ａは、後述する制御管理部１２からサーバ状態の取得要求を受けると、サーバ３ａに対して、サーバ状態の取得要求を発行し、サーバ３ａからの応答結果に基づいて、サーバ状態を判定（取得）する。なお、サーバ状態の取得要求は制御管理部１２から定期的に発行される。サーバ管理部１３は、制御管理部１２から定期的なサーバ状態の取得要求を受け取る都度、サーバ状態の取得を行なう。

なお、サーバ状態の取得対象のサービス提供サーバ３ａは、サービス環境制御サーバ１に接続された全てのサーバ３ａであってもよいし、制御管理部１２からのサーバ状態の取得要求で指定された特定のサーバ３ａであってもよい。
サーバ状態取得部１３ａは、サーバ３ａからサーバ状態を取得すると、図４に示すサーバ状態情報ＤＢ１３ｃを更新する。

サーバ状態情報ＤＢ１３ｃは、サービス提供サーバ３ａごとのサーバ状態を管理するためのデータベースであり、図４に例示するデータ構造のサーバ状態情報（状態情報）を、サーバ３ａごとに格納する。図４に示すように、サーバ状態情報は、サーバ３ａの識別情報の一例であるサーバＩＤ、サーバ３ａのアドレスの一例であるInternet Protocol（ＩＰ）アドレス、及びサーバ３ａが提供するサービスの識別情報の一例であるサービスＩＤを含む。また、サーバ状態情報は、サーバ状態取得部１３ａによってサーバ３ａから取得されたサーバ状態、サーバ３ａのＣＰＵ使用率（％）、及びサーバ状態情報の取得時刻（状態取得時刻）をさらに含む。図４に示すサーバ状態情報ＤＢ１３ｃは、サーバＩＤ“Server01”〜“Server04”の各々のサーバ状態情報を格納する。一例として、サーバＩＤ“Server01”には、ＩＰアドレス“aaa.aaa.aaa.aaa”、サービスＩＤ“Service01”、サーバ状態“Stop”、ＣＰＵ使用率（％）“0”、状態取得時刻“yymmdd hh:mm:ss”が対応付けられる。

サーバ状態取得部１３ａは、例えば、サーバ状態情報ＤＢ１３ｃにおけるサーバ状態、ＣＰＵ使用率、及び状態取得時刻以外の項目の情報を予めサーバ３ａから収集し、サーバ状態情報ＤＢ１３ｃに設定しておくことが好ましい。なお、サーバ状態取得部１３ａは、サーバ３ａから、サーバ状態及びＣＰＵ使用率の他に、サーバ状態情報ＤＢ１３ｃにおける状態取得時刻以外の情報についても取得し、サーバ状態情報ＤＢ１３ｃに設定してもよい。

また、サーバ状態取得部１３ａは、ＣＰＵ使用率については、後述する理由により、サーバ状態の取得要求とは別に、サーバ３ａの稼動状況を監視する所定のコマンド等を用いて取得することが好ましい。ＣＰＵ使用率を取得する手法は、既知の種々の手法により行なうことが可能であり、その詳細な説明は省略する。
サーバ状態取得部１３ａは、サーバ状態及びＣＰＵ使用率を取得すると、サーバ状態情報ＤＢ１３ｃのうちの対応するレコードに、取得したサーバ状態、ＣＰＵ使用率、及びサーバ状態を取得したときの時刻（状態取得時刻）をそれぞれ設定する。

なお、サーバ状態としては、図４に例示するように、動作状態を示す“Running”、停止状態のうちのシャットダウン状態を示す“Stop”、停止状態のうちのスリープ状態を示す“Sleep”、及びビジー状態を示す“Busy”が挙げられる。
また、サーバ状態情報ＤＢ１３ｃが持つ項目は、図４に示すものに限定されるものではない。例えば、サーバ状態情報ＤＢ１３ｃには、サーバ３ａのネットワーク使用率等、サーバ３ａから取得可能な種々の項目が含まれてもよい。

さらに、サーバ３ａのアドレスとして、ＩＰアドレスを例に挙げたが、これに限定されるものではなく、ＩＰ以外のプロトコルにおいてサーバ３ａとしての仮想サーバ又は物理サーバを特定可能な種々のアドレスが用いられてもよい。
ここで、サーバ状態取得部１３ａがサーバ状態を判定する手法を説明する。
サーバ状態取得部１３ａは、サーバ３ａへサーバ状態の取得要求を発行した後、所定期間内にサーバ３ａから応答があるか否かを判断する。サーバ３ａから応答があった場合、サーバ状態取得部１３ａは、当該サーバ３ａが動作状態であると判定する。

一方、所定期間内にサーバ３ａから応答がない場合、サーバ３ａは、シャットダウン状態、スリープ状態、又はビジー状態の可能性が高い。そこで、サーバ状態取得部１３ａは、サーバ３ａのハードウェアへの給電が行なわれているか否かを、サーバ３ａのハードウェア状態を監視する所定のコマンド等を用いて判断する。なお、この判断は、既知の種々の手法により行なうことが可能であり、その詳細な説明は省略する。サーバ３ａのハードウェアへの給電が行なわれていない場合、サーバ状態取得部１３ａは、サーバがシャットダウン状態であると判定する。

また、サーバ３ａのハードウェアへの給電が行なわれている場合、サーバ３ａは、スリープ状態又はビジー状態である可能性が高い。これは、スリープ状態の場合、サーバ３ａのハードウェア（少なくともＣＰＵ及びメモリ）に給電が行なわれ、ビジー状態の場合、サーバ３ａは稼動中でありハードウェアに給電が行なわれているためである。そこで、サーバ状態取得部１３ａは、サーバ３ａから取得したＣＰＵ使用率を参照し、所定の閾値以下であるか否かを判断する。なお、サーバ状態取得部１３ａは、サーバ状態の取得要求とは別に、所定のコマンドを用いてＣＰＵ使用率を取得することで、取得要求への応答が得られない場合であっても、確実にＣＰＵ使用率を得ることができる。

ＣＰＵ使用率が所定の閾値以下である場合、サーバ状態取得部１３ａは、サーバ３ａがスリープ状態であると判定する。これは、スリープ状態の場合、サーバ３ａのＣＰＵは、主にメモリをリフレッシュする処理に用いられるため、負荷の低い状態が維持されるためである。
一方、ＣＰＵ使用率が所定の閾値よりも高い場合、サーバ状態取得部１３ａは、サーバ３ａがビジー状態であると判定する。これは、ビジー状態の場合、ＣＰＵは、サーバ状態の取得要求に対する応答を返せない程度に高負荷になっているためである。

サーバ状態取得部１３ａは、以上の手法により、サーバ状態の判定を行なう。
また、サーバ状態取得部１３ａは、制御管理部１２からの要求に応じて、サーバ状態情報ＤＢ１３ｃを更新すると、サーバ状態情報ＤＢ１３ｃ内のサーバ状態とサーバ３ａを特定するためのサーバＩＤ又はＩＰアドレスとを読み出す。そして、サーバ状態取得部１３ａは、読み出した情報を制御管理部１２へサーバ状態の取得応答として出力する。サーバ状態の取得応答には、サーバ状態情報ＤＢ１３ｃ内の全てのレコードのサーバ状態とサーバＩＤ又はＩＰアドレスとが含まれてもよいし、直近に更新が行なわれたレコードのみのサーバ状態とサーバＩＤ又はＩＰアドレスとが含まれてもよい。なお、サーバ状態取得部１３ａは、サーバ状態情報ＤＢ１３ｃ全体を取得応答として制御管理部１２へ出力してもよい。

なお、サーバ状態の取得応答は、制御管理部１２により、上記（１）の処理で、サーバ３ａを動作状態から停止状態に遷移させるか否かの判断に用いられる。
さらに、サーバ状態取得部１３ａは、制御管理部１２からサーバ状態の問合せ要求を受けた場合、問合せ要求に係るサーバ状態をサーバ状態情報ＤＢ１３ｃから読み出し、サーバ状態の問合せ応答として制御管理部１２へ出力する。なお、サーバ状態の問合せ応答は、後述する受付部１１により、上記（２）又は（３）の処理で、サーバ３ａが動作状態であるか否かの判断に用いられる。

以下、サーバ状態取得部１３ａが制御管理部１２からサーバ状態の問合せ要求を受けた場合の処理を説明する。
サーバ状態の問合せ要求には、受付部１１により指定された、サーバ３ａのＩＰアドレスが含まれる。
サーバ状態取得部１３ａは、問合せ要求を受けると、サーバ状態情報ＤＢ１３ｃを参照して、指定されたＩＰアドレスのサーバ３ａが提供するサービスのサービスＩＤを識別する。また、サーバ状態取得部１３ａは、サーバ状態情報ＤＢ１３ｃの中で、識別したサービスＩＤと同一のサービスＩＤを持つ他のサーバ３ａが存在するか否かを判断する。同一のサービスＩＤを持つ他のサーバ３ａが存在する場合、サーバ状態取得部１３ａは、識別したサービスＩＤと同一のサービスＩＤを持つ全てのサーバ３ａのサーバ状態と、サーバ３ａを特定するサーバＩＤ又はＩＰアドレスとを、サーバ状態の問合せ応答として制御管理部１２へ出力する。

ところで、サーバ状態情報ＤＢ１３ｃにおいて、同一のサービスＩＤを持つサーバ３ａ（図４に示す例では、サーバＩＤ“Server01”及び“Server03”）は、ユーザ端末２に対して同一のサービスを提供することができる。
そこで、サーバ状態取得部１３ａは、問合せ要求に含まれるＩＰアドレスのサーバ状態の他に、同一のサービスを提供することができる他のサーバ３ａ（ＩＰアドレス）が存在する場合には、他のサーバ３ａのサーバ状態も問合せ応答に含めるのである。これにより、受付部１１では、例えば同一のサービスを提供できる動作状態の他のサーバ３ａが存在するにもかかわらず、問合せ要求に係るサーバ３ａが停止状態であるために不要な起動制御が行なわれることを抑止することができる。

サーバ制御部１３ｂは、制御管理部１２からの制御要求に応じて、サービス提供サーバ３ａの状態制御を行なう。
具体的には、サーバ制御部１３ｂは、制御管理部１２から、サーバ３ａを動作状態から停止状態に遷移させる制御要求を受けると、制御要求において指定されたサーバ３ａに対して、シャットダウン又はスリープ等、停止状態へ遷移させる制御要求を発行する。また、サーバ制御部１３ｂは、制御管理部１２から、サーバ３ａを停止状態から動作状態に遷移させる制御要求を受けると、制御要求において指定されたサーバ３ａに対して、停止状態から起動状態へ遷移させる制御要求を発行する。

また、サーバ制御部１３ｂは、制御要求に応じて状態制御が実行されたサーバ３ａから制御応答を受けると、サーバ状態情報ＤＢ１３ｃのうちの対応するレコードに、遷移後のサーバ状態及びサーバ状態の更新時刻（状態取得時刻）をそれぞれ設定する。
なお、サーバ３ａは、停止状態から動作状態に遷移した場合、起動処理が完了した旨を制御応答に含めてサーバ制御部１３ｂへ出力する。

一方、サーバ３ａは、動作状態から停止状態に遷移する場合、シャットダウン処理又はスリープ処理等の停止処理の開始予定時刻（又は何秒後に行なうか）を制御応答に含めてサーバ制御部１３ｂへ出力する。この場合、制御応答を受信したサーバ制御部１３ｂは、少なくとも開始予定時刻まで待ってから、サーバ状態情報ＤＢ１３ｃの更新及び制御管理部１２への問合せ応答の送信を行なうこととしてもよい。なお、サーバ制御部１３ｂは、開始予定時刻以降に、サーバ状態取得部１３ａにサーバ３ａに対するサーバ状態の取得を指示して、サーバ３ａの停止処理が完了したか否かを確認してもよい。

なお、サーバ管理部１３は、ユーザ端末２から受付部１１を介してリクエストを受け取ると、リクエストの宛先アドレスが示すサーバ３ａが動作状態である場合に、宛先アドレスへ当該リクエストを転送する。
また、サーバ管理部１３は、ユーザ端末２からのリクエストの宛先アドレスが示すサーバ３ａが停止状態又はビジー状態の場合でも、同一のサービスＩＤを持つ動作状態の他のサーバ３ａが存在する場合には、他のサーバ３ａへ当該リクエストを転送してもよい。

なお、リクエストの宛先アドレスが示すサーバ３ａと同一のサービスＩＤを持つ他のサーバ３ａの特定手法は、上述のサーバ状態取得部１３ａと同様であるため、その説明を省略する。
このように、サーバ管理部１３は、ユーザ端末２からのリクエストの宛先である宛先サーバ３ａを、同一のサービスＩＤを持つ１以上のサーバ３ａから特定し、特定したサーバ３ａへリクエストを転送することもできる。

〔１−４−２〕受付部の説明
受付部（要求制御部）１１は、ユーザ端末２からの接続要求等のリクエストを受け付けて、リクエストの宛先である宛先サーバ３ａの状態に応じた処理を行なう。例えば、受付部１１は、宛先サーバ３ａが停止状態の場合、サーバ３ａの代わりに代理応答を行なう代理応答部１４に、ユーザ端末２に対する代理応答を実行させる。また、受付部１１は、宛先サーバ３ａが動作状態の場合、ユーザ端末２からの要求を宛先サーバ３ａへ送信（中継）する。

また、受付部１１は、上述した処理の他に、管理者からの制御条件定義情報を受け付けて制御管理部１２へ設定を要求する処理、並びに宛先サーバ３ａからのレスポンス及び代理応答部１４からの代理応答をユーザ端末２へ送信する処理を行なう。
以下、受付部１１の詳細な構成例を説明する。受付部１１は、一例として、キューイング部１１ａ及び状態判定部１１ｂをそなえる。

キューイング部（保持部）１１ａは、ユーザ端末２からインタフェース１０ｄを介して受信したリクエスト（パケット）を一時的に保持する。キューイング部１１ａは、例えばメモリ１０ｂにより実現される。
宛先判定部１１ｂは、受信したリクエスト（パケット）を監視して、ユーザ端末２の接続先、つまりリクエストの宛先アドレスを識別する。例えば、宛先判定部１１ｂは、受信したパケット又はキューイング部１１ａに保持されたパケットを参照して、宛先アドレス（例えばＩＰアドレス）を取得する。

そして、宛先判定部１１ｂは、制御管理部１２を介してサーバ管理部１３へ、サーバ状態の問合せ要求を発行する。サーバ状態の問合せ要求には、宛先判定部１１ｂが識別した宛先アドレスが含まれる。
サーバ管理部１３では、上述の如く、サーバ状態取得部１３ａにより、宛先アドレスのサーバ３ａが提供するサービスと同一のサービスを提供する全てのサーバ３ａのサーバ状態とサーバＩＤ又はＩＰアドレスとが、サーバ状態の問合せ応答として出力される。宛先判定部１１ｂは、制御管理部１２を介してサーバ状態の問合せ応答を受け取ると、以下の判断条件に従い、ユーザ端末２からのリクエストに対する制御を行なう。

（ｉ）問合せ応答のサーバ状態に、動作状態を示す“Running”が含まれる場合
宛先判定部１１ｂは、サーバ状態が動作状態であるサーバ３ａを宛先サーバ３ａと特定し、宛先サーバ３ａへリクエストの転送を行なう。
（ii）問合せ応答のサーバ状態に、動作状態を示す“Running”が含まれず、停止状態を示す“Stop”又は“Sleep”が含まれる場合
宛先判定部１１ｂは、サーバ状態が停止状態であるサーバ３ａを宛先サーバ３ａと特定し、後述する代理応答部１４に、リクエストの送信元であるユーザ端末２への代理応答を実行させる。

（iii）問合せ応答のサーバ状態に、動作状態を示す“Running”並びに停止状態を示す“Stop”又は“Sleep”が含まれず、ビジー状態を示す“Busy”が含まれる場合
この場合、全てのサーバ３ａがビジー状態であり、待機（停止）中のサーバ３ａが存在しない。従って、宛先判定部１１ｂは、サーバ状態がビジー状態であるサーバ３ａを宛先サーバ３ａと特定し、代理応答部１４に、リクエストの送信元であるユーザ端末２への代理応答を実行させる。

なお、上記（ｉ）〜（iii）のいずれの場合においても、問合せ応答のサーバ状態に、同じサーバ状態のサーバ３ａが複数含まれる場合には、宛先サーバ３ａとして、同じサーバ状態のサーバ３ａのいずれを選択してもよい。
宛先判定部１１ｂは、問合せ応答に含まれるサーバ状態について、上記（ｉ）〜（iii）の順で判断条件を満たすか否かを判定する。

以上のように、宛先判定部１１ｂは、リクエストに応答可能な１以上のサーバ３ａのサーバ状態に基づき宛先サーバ３ａを特定し、宛先サーバ３ａのサーバ状態に応じて、リクエストに対する制御を行なう。
なお、宛先判定部１１ｂによる上記（ｉ）〜（iii）の判定は、リクエストの宛先アドレスのサーバ３ａが提供するサービスと同一のサービスを提供する他のサーバ３ａがない場合であっても、同様に行なわれる。つまり宛先判定部１１ｂは、サーバ状態の問合せ応答に含まれるサーバ状態が、宛先アドレスのサーバ状態だけである場合、サーバ状態が動作状態、停止状態、及びビジー状態のいずれであるかを判定し、判定結果に応じた処理を行なう。

受付部１１は、上記（ｉ）の判断条件を満たす場合、キューイング部１１ａにキューイングされたリクエストを接続要求として宛先サーバ３ａへ向けて送出する。
また、受付部１１は、上記（ii）又は（iii）の判断条件を満たす場合、キューイング部１１ａにキューイングされたリクエストの複製を、代理応答要求として代理応答部１４へ向けて送出する。なお、代理応答と並行して、制御管理部１２及びサーバ管理部１３では、宛先サーバ３ａの起動制御が行なわれる。受付部１１は、宛先サーバ３ａが起動し制御管理部１２からサーバ３ａの起動完了通知を受けると、キューイング部１１ａにキューイングされたリクエストを起動完了通知の受信応答として宛先サーバ３ａへ向けて送出する。

なお、受付部１１は、上記（ｉ）〜（iii）の判定により、リクエスト又はリクエストの複製の送出先（宛先サーバ３ａ又は代理応答部１４）が、宛先アドレス以外のアドレスに代わる場合には、リクエスト又はリクエストの複製を送出先へリダイレクトする。
このように、受付部１１は、宛先サーバ３ａが停止状態又はビジー状態の間、ユーザ端末２に対する代理応答を代理応答部１４に実行させて、ユーザ端末２に現在の宛先サーバ３ａの状況を通知することができる。従って、ユーザ端末２によりリクエストの再送が繰り返されることにより生じる、宛先サーバ３ａ及びネットワーク５へのアクセス集中（トラフィック）を低減することができる。

なお、上述のように、サーバ管理部１３は、ユーザ端末２からのリクエストの宛先である宛先サーバ３ａを、同一のサービスＩＤを持つ１以上のサーバ３ａから特定し、特定したサーバ３ａへリクエストを転送することもできる。そこで、受付部１１（宛先判定部１１ｂ）は、宛先サーバ３ａの特定をサーバ管理部１３に実行させてもよい。つまり、宛先判定部１１ｂ及びサーバ管理部１３を宛先制御部の一例としてもよい。この場合、宛先判定部１１ｂは、上述のように、上記（ｉ）〜（iii）の判定を行ない、リクエストの転送及び代理応答のうちのいずれを実行するかを決定するが、宛先サーバ３ａの特定は行なわない。つまり、宛先サーバ３ａは、判定結果が上記（ｉ）である場合、リクエストのパケットの宛先アドレスに当該リクエストを転送すればよい。また、宛先サーバ３ａは、判定結果が上記（ii）又は（iii）である場合、リクエストのパケットをそのまま代理応答部１４へ送出すればよい。

〔１−４−３〕制御管理部の説明
制御管理部１２は、管理装置４から受け取った制御条件定義情報の管理、受付部１１からサーバ管理部１３へのサーバ状態の問合せ要求の転送、及びサーバ管理部１３から受付部１１への問合せ応答の転送を行なう。また、制御管理部１２は、受付部１１から代理応答部１４へのリクエストの転送、代理応答部１４からユーザ端末２（受付部１１）への代理応答の転送、サーバ３ａのサーバ状態の制御、及びユーザ端末２が利用するサービスのセッション情報の管理等を行なう。

以下、制御管理部１２の詳細な構成例を説明する。制御管理部１２は、一例として、制御条件管理部１２ａ、制御判定部１２ｂ、セッション管理部１２ｃ、制御条件定義情報ＤＢ１２ｄ、制御情報ＤＢ１２ｅ、及びセッション情報ＤＢ１２ｆをそなえる。
制御条件管理部１２ａは、管理者から受付部１１を介して制御条件定義情報を受け取ると、図５に示す制御条件定義情報ＤＢ１２ｄを更新する。

制御条件定義情報ＤＢ１２ｄは、サービス提供サーバ３ａごとの状態制御の条件のうち、動作状態から停止状態へ遷移させる条件を定義するデータベースであり、図５に例示するデータ構造の制御条件を、サーバ３ａごとに格納する。図５に示すように、制御条件は、サーバ３ａのＩＰアドレス、ＩＰアドレスに対応するサーバＩＤ、及び停止状態のうちのシャットダウン状態及びスリープ状態のいずれの状態に遷移させるかを示す制御種別を含む。また、制御条件は、状態制御を行なうか否かの判定に用いる判定対象、判定対象の閾値である量（ｑｕａｎｔｉｔｙ）、及び判定対象時間（ｍ）をさらに含む。図５に示す制御条件定義情報ＤＢ１２ｄは、ＩＰアドレス“aaa.aaa.aaa.aaa”〜“ddd.ddd.ddd.ddd”の各々の制御条件を格納する。一例として、ＩＰアドレス“aaa.aaa.aaa.aaa”には、サーバＩＤ“Server01”、制御種別“Sleep”、判定対象“transaction”、量（ｑｕａｎｔｉｔｙ）“10”、判定対象時間（ｍ）“5”が対応付けられる。

監視装置４は、管理者により設定された制御条件を含む定義要求をサービス環境制御サーバ１へ送信する。なお、管理者は、制御条件として、ＩＰアドレス及びサーバＩＤの少なくとも一方、制御種別、判定対象、量、並びに判定対象時間を設定する。サービス環境制御サーバ１では、制御条件管理部１２ａは、受付部１１を介して制御条件の定義要求を受け取り、制御条件定義情報ＤＢ１２ｄへ設定（更新）する。なお、制御条件管理部１２ａは、例えば、制御条件定義情報ＤＢ１２ｄにおけるＩＰアドレス及びサーバＩＤの項目の情報を予めサーバ３ａから収集し、制御条件定義情報ＤＢ１２ｄに設定してもよい。

制御判定部１２ｂは、サーバ３ａの状態制御を行なうか否かを判定する。例えば、制御判定部１２ｂは、サーバ３ａを動作状態から停止状態へ遷移させる停止制御を行なうか否か、及び、サーバ３ａを停止状態から動作状態へ遷移させる起動制御を行なうか否かを判定する。
はじめに、制御判定部１２ｂが、停止制御を行なう場合について説明する。

具体的に、制御判定部１２ｂは、サーバ状態の取得要求を発行し、サーバ管理部１３から定期的にサーバ状態を取得し、図６に示す制御情報ＤＢ１２ｅを更新する。
制御情報ＤＢ１２ｅは、サーバ管理部１３が保持するサーバ状態情報ＤＢ１３ｃと同様の情報を管理するデータベースである。図６に示す例では、制御情報ＤＢ１２ｅは、ＣＰＵ使用率の項目を持たない点がサーバ状態情報ＤＢ１３ｃと異なるが、それ以外の項目は、サーバ状態情報ＤＢ１３ｃと同一である。

制御判定部１２ｂは、サーバ管理部１３からのサーバ状態の取得応答に含まれる情報を用いて、制御情報ＤＢ１２ｅの対応するレコードを更新する。なお、制御管理部１２は、例えば、制御情報ＤＢ１２ｅにおけるサーバ状態及び状態取得時刻以外の項目の情報を予めサーバ３ａから収集し、制御情報ＤＢ１２ｅに設定しておいてもよい。また、制御管理部１２は、サーバ管理部１３からサーバ状態情報ＤＢ１３ｃ自体を受け取る場合には、受け取ったサーバ状態情報ＤＢ１３ｃにより制御情報ＤＢ１２ｅ全体を更新してもよい。

制御判定部１２ｂは、制御情報ＤＢ１２ｅを更新すると、制御条件定義情報ＤＢ１２ｄと制御情報ＤＢ１２ｅとを比較して、サーバ３ａごとに、状態制御を行なうか否かを判定する。具体的には、制御判定部１２ｂは、制御情報ＤＢ１２ｅにおいて、サーバ状態が“Running”であるサーバ３ａ（サーバＩＤ又はＩＰアドレス）を特定する。そして、制御判定部１２ｂは、特定したサーバ３ａが、制御条件定義情報ＤＢ１２ｄの判定対象、量（例えばパケット数）、及び判定対象時間により定義される制御条件を満たすか否かを判定する。

例えば、サーバ状態が“Running”であるサーバ３ａ（サーバＩＤ“Server02”）に着目する（図６参照）。制御判定部１２ｂは、当該サーバ３ａについて、過去１０分以内のトランザクションが０以下であるか否か、及び、過去１５分以内のトランザクションが０以下であるか否かを判定する（図５参照）。
判定の結果、過去１０分以内又は１５分以内のトランザクションが０以下である場合、制御判定部１２ｂは、制御条件定義情報ＤＢ１２ｄ内の対応するレコードの制御種別を参照し、停止制御としてシャットダウン及びスリープのいずれかを特定する。所定期間内にリクエストがない、又は少ないサーバ３ａは、停止状態にしてもサービスに与える影響が少ないからである。一方、過去１５分以内のトランザクションが０ではない場合、制御判定部１２ｂは、当該サーバ３ａに対する状態制御は行なわないと判定する。

制御判定部１２ｂは、サーバ状態が“Running”である全てのサーバ３ａについて同様に、制御条件を参照して判定を行なう。そして、制御判定部１２ｂは、サーバ状態が“Running”である全てのサーバ３ａについて判定を行なうと、状態制御を行なうと判定したサーバ３ａについて、特定した制御種別にサーバ状態を遷移させる制御要求を生成し、サーバ制御部１３ｂへ出力する。

なお、制御判定部１２ｂは、受付部１１から送出された、ユーザ端末２からのリクエストのパケットを、宛先サーバ３ａ又は代理応答部１４へ中継する。制御判定部１２ｂは、リクエストの中継の際に、宛先サーバ３ａのＩＰアドレスと、中継した時刻とを保持しておくことで、宛先サーバ３ａごとのトランザクションの量を収集することができる。従って、制御判定部１２ｂは、収集したトランザクションの量と中継した時刻とに基づいて、サーバ状態が“Running”であるサーバ３ａが制御条件を満たすか否かを判定することができる。

また、図５に示す例では、判定対象にトランザクションが設定されているが、これに限定されるものではない。判定対象としては、制御判定部１２ｂがパケットの監視を通じてサーバ３ａの利用状況を認識できる種々の条件とすることができる。
さらに、制御判定部１２ｂは、１つのサーバ３ａの制御条件に複数の制御種別（“Sleep”及び“Stop”）があり、いずれの制御種別に係る制御条件も満たされている場合には、状態制御を適用する制御種別を、運用に応じて任意に決定することができる。

制御判定部１２ｂは、以上のように停止制御を行なう。
なお、ここまで、制御判定部１２ｂは、管理者が定義した制御条件定義情報ＤＢ１２ｄに従って、定期的に停止制御を行なうものとして説明したが、これに限定されるものではない。例えば、管理者は、制御情報ＤＢ１２ｅ又はサーバ状態情報ＤＢ１３ｃ等を参照して、状態制御を行なうサーバ３ａ及び制御種別を手動で特定して、制御要求を生成してもよい。この場合、制御判定部１２ｂは、管理装置４を介して管理者から受け取った制御要求を、サーバ管理部１３へ転送する。

例えば、図１に示す社内サービスのような環境の場合、ユーザからのアクセス規模にある程度対応できるよう、サービス提供システム３が構成されている。しかし、アクセスが集中しない時間帯も同様の構成を維持してはリソースが余剰となり、余計な電力を消費してしまう。
一方、上述した制御判定部１２ｂは、管理者によって定義されたサーバ３ａの制御条件と、ユーザ端末２からのリクエストのパケット監視によるユーザ利用状況の観測結果と、を合わせた判定に基づき、サーバ３ａの状態制御を行なう。これにより、従来は手動で、又はスケジュール等によって実施されていたリソースの制御を、ユーザの利用状況の変化に応じたタイミングで行なうことができ、消費電力の効率的な削減を図ることができる。

上述した制御判定部１２ｂによるサーバ３ａの停止制御は、特に、多数のユーザが接続するＷｅｂサービス等を提供するサービス提供システム３に用いて好適である。
次に、制御判定部１２ｂが、起動制御を行なう場合について説明する。
上述のように、受付部１１は、宛先サーバ３ａが停止状態であると判定すると、ユーザ端末２からのリクエストの複製（代理応答要求）を代理応答部１４へ転送する。そこで、制御判定部１２ｂは、代理応答要求を代理応答部１４へ中継する際に、代理応答要求に含まれる宛先サーバ３ａ及び当該宛先サーバ３ａが停止状態であることを特定することができる。

そして、制御判定部１２ｂは、特定した宛先サーバ３ａのサーバ状態が停止状態である場合、宛先サーバ３ａに対して停止状態から動作状態へ遷移させる起動制御を行なうと判定する。また、制御判定部１２ｂは、起動制御を行なうと判定した宛先サーバ３ａについて、起動状態にサーバ状態を遷移させる制御要求を生成し、サーバ制御部１３ｂへ出力する。

なお、制御判定部１２ｂは、上述した宛先判定部１１ｂによる（ｉ）〜（iii）の判定結果を受け取り、宛先サーバ３ａ及び宛先サーバ３ａのサーバ状態を特定してもよい。
また、制御判定部１２ｂは、宛先サーバ３ａ及び宛先サーバ３ａのサーバ状態を自身で特定してもよい。例えば、制御判定部１２ｂは、受付部１１からのサーバ状態の問合せ要求及びサーバ管理部１３からの問合せ応答をそれぞれ中継する。制御判定部１２ｂは、サーバ管理部１３からの問合せ応答を受付部１１へ中継する際、問合せ応答の内容を参照し、上述した宛先判定部１１ｂと同様の手法により、宛先サーバ３ａ及び宛先サーバ３ａのサーバ状態を特定してもよい。

また、制御判定部１２ｂは、宛先サーバ３ａのサーバ状態がビジー状態である場合、上記（iii）で説明したように、宛先サーバ３ａと同一のサービスを提供する全てのサーバ３ａがビジー状態であり、待機（停止）中のサーバ３ａが存在しない。この場合、制御判定部１２ｂは、起動制御を行なわず、ビジー状態の宛先サーバ３ａが負荷の低下によって動作状態に遷移するのを待つ。なお、このとき、制御判定部１２ｂは、ビジー状態である旨を管理装置４に通知してもよい。

以上のように、制御判定部１２ｂ及びサーバ制御部１３ｂは、ユーザ端末２からの要求の宛先である宛先サーバ３ａが停止状態の場合、宛先サーバ３ａに対して、停止状態から動作状態に遷移させる起動制御を行なう状態制御部１５の一例である。
セッション管理部１２ｃは、ユーザ端末２とサーバ３ａとの間のセッション情報を管理する。例えば、ユーザ端末２からのリクエスト（例えば接続要求）が動作状態のサーバ３ａに到達すると、サーバ３ａからユーザ端末２へレスポンス（接続応答）が送出される。また、ユーザ端末２からのリクエストが受付部１１により代理応答部１４へリダイレクトされると、代理応答部１４からユーザ端末２へレスポンス（代理応答）が送出される。

セッション管理部１２ｃは、サーバ管理部１３を介して受け取った当該レスポンスを受付部１１へ中継する際に、レスポンスを参照して、図７に示すセッション情報ＤＢ１２ｆを更新する。
セッション情報ＤＢ１２ｆは、サーバ３ａが提供するサービスのセッションごとに、ユーザ端末２とサーバ３ａとの間の接続状態を管理するデータベースであり、図７に例示するデータ構造のセッション情報を、セッションごとに格納する。図７に示すように、セッション情報は、セッションの識別情報の一例であるセッションＩＤ、ユーザ端末２が利用するサービスのサービスＩＤ、ユーザ端末２の識別情報の一例であるユーザＩＤ、及びユーザ端末２とサーバ３ａとの間の接続状態を含む。図７に示すセッション情報ＤＢ１２ｆは、セッションＩＤ“Session01”〜“Session04”の各々のセッション情報を格納する。一例として、セッションＩＤ“Session01”には、サービスＩＤ“Service01”、ユーザＩＤ“User01”、接続状態“Redirected”が対応付けられる。

セッション管理部１２ｃは、サーバ３ａ又は代理応答部１４からユーザ端末２へのレスポンスを参照して、レスポンスに含まれるセッションＩＤ、サービスＩＤ、及びユーザＩＤを取得し、セッション情報ＤＢ１２ｆに設定する。また、セッション管理部１２ｃは、セッション情報ＤＢ１２ｆの対応するレコードの接続状態に、レスポンスの送信元がサーバ３ａである場合には“Connected”を、レスポンスの送信元が代理応答部１４である場合には“Redirected”を設定する。

このように、セッション情報ＤＢ１２ｆは、セッションごとに、ユーザ端末２とサーバ３ａとの間で接続が確立された状態を示す“Connected”、又はサーバ３ａが停止状態でありリクエストがサーバ３ａに到達していない状態を示す“Redirected”を対応付ける。
また、セッション管理部１２ｃは、状態制御部１５により停止状態の宛先サーバ３ａが起動されると、宛先サーバ３ａからユーザ端末２へのレスポンスを参照する。セッション管理部１２ｃは、制御情報ＤＢ１２ｅとセッション情報ＤＢ１２ｆとをサーバＩＤ又はＩＰアドレスにより紐付けて管理する。

セッション管理部１２ｃは、制御情報ＤＢ１２ｅの中で、宛先サーバ３ａのサーバ状態が“Running”に遷移したことを検出すると、セッション情報ＤＢ１２ｆの対応するレコードの接続状態を、“Redirected”から“Connected”に更新する。
このように、セッション管理部１２ｃによれば、ユーザ端末２は、宛先サーバ３ａからのレスポンスを受信できない場合でも、代理応答の送信元との間でセッションを維持することができる。また、宛先サーバ３ａが起動し動作状態になった場合には、宛先サーバ３ａからユーザ端末２へのレスポンスに基づき、セッションを容易に切り替えることができる。

〔１−４−４〕代理応答部の説明
代理応答部１４は、制御管理部１２を介して受付部１１からの代理応答要求、つまりユーザ端末２からのリクエストの複製を受信すると、リクエストの送信元であるユーザ端末２に対して、代理応答を行なう。なお、代理応答の内容としては、「サーバ起動中のためお待ちください」といった、ユーザにリクエストの再送を控えさせるメッセージを含むものが例として挙げられる。例えば、代理応答の内容には、上記メッセージを表示するｗａｉｔ画面のUniform Resource Identifier（ＵＲＩ）が含まれてもよい。

代理応答部１４は、一例として、代理応答情報ＤＢ１４ａをそなえる。
代理応答部１４は、代理応答要求を受けると、リクエストの宛先アドレス又は宛先サーバ３ａのＩＰアドレス等に基づいて、図８に示す代理応答情報ＤＢ１４ａから代理応答に含めるＵＲＩを取得し、取得したＵＲＩを含めた代理応答を行なう。
代理応答情報ＤＢ１４ａは、サービス提供サーバ３ａごとに、ユーザ端末２へ送信するメッセージ（例えばｗａｉｔ画面へのＵＲＩ）を管理するデータベースであり、図８に例示するデータ構造の代理応答情報を、サーバ３ａごとに格納する。図８に示すように、代理応答情報は、サーバ３ａのサーバＩＤ、ＩＰアドレス、サーバ３ａが提供するサービスのサービスＩＤ，及び代理応答に含めるコンテンツＵＲＩを含む。図８に示す代理応答情報ＤＢ１４ａは、ＩＰアドレス“aaa.aaa.aaa.aaa”〜“ddd.ddd.ddd.ddd”の各々の代理応答情報を格納する。一例として、ＩＰアドレス“aaa.aaa.aaa.aaa”には、サーバＩＤ“Server01”、サービスＩＤ“Service01”、応答コンテンツＵＲＩ“http://Service01/Answer”が対応付けられる。

なお、代理応答部１４は、例えば、代理応答情報ＤＢ１４ａにおけるサーバＩＤ、ＩＰアドレス、及びサービスＩＤの項目の情報を予めサーバ３ａから収集し、代理応答情報ＤＢ１４ａに設定しておくことが好ましい。また、代理応答情報ＤＢ１４ａの応答コンテンツＵＲＩは、例えば、管理装置４を介して管理者等により設定される。応答コンテンツＵＲＩは、サービス環境制御サーバ１、サーバ３ａ、及び管理装置４のうちのいずれのリソースを示すものであってもよい。

〔１−５〕動作例
次に、図９〜図１７を参照して、上述の如く構成された一実施形態に係るサービス環境制御サーバ１の動作例を説明する。図９、図１１、図１３、及び図１４は、それぞれ、一実施形態に係るサービス環境制御サーバ１の動作例を説明するフローチャートである。図１０、図１２、図１５〜図１７は、それぞれ、一実施形態に係るサービス環境制御サーバ１の動作例を説明するシーケンス図である。なお、図１６及び図１７は、処理Ｔ２５までの処理が図１５と共通するため、一部の図示を省略している。

〔１−５−１〕サーバ管理部によるサーバ状態の取得処理の動作例
はじめに、図９及び図１０を参照して、サーバ管理部１３によるサーバ状態の取得処理の動作例を説明する。
図９に示すように、サーバ管理部１３により、サーバ３ａへサーバ状態取得要求が発行される（ステップＳ１，図１０の処理Ｔ１−１）。なお、サーバ管理部１３は、制御管理部１２からのサーバ状態取得要求を受信したことをトリガとして、サーバ３ａに対してサーバ状態取得要求を発行する。サーバ３ａでは、サーバ状態取得要求が受信されると、サーバ状態を含むサーバ状態取得応答がサーバ管理部１３へ送信される（ステップＳ２，図１０の処理Ｔ１−２）。

サーバ管理部１３により、サーバ状態取得応答が受信されると、サーバ状態取得応答に含まれるサーバ状態に基づいて、図４に示すサーバ状態情報ＤＢ１３ｃが更新される（ステップＳ３，図１０の処理Ｔ２）。
次いで、制御管理部１２により、現在の時刻がサーバ状態の次回取得時刻になったか否かが判定される（ステップＳ４）。現在の時刻がサーバ状態の次回取得時刻になっていない場合（ステップＳ４のＮｏルート）、制御管理部１２により、一定時間待機され（ステップＳ５）、ステップＳ４に移行する。

一方、現在の時刻がサーバ状態の次回取得時刻になった場合（ステップＳ４のＹｅｓルート）、ステップＳ１に移行する。ステップＳ１では、制御管理部１２により、サーバ管理部１３に対して、サーバ状態取得要求が発行される。
以上のように、サーバ管理部１３によるサーバ状態の取得処理が行なわれる。
〔１−５−２〕サービス環境制御サーバにおける制御条件定義情報の設定処理及びサービス提供サーバの停止制御の動作例
次に、図１１及び図１２を参照して、サービス環境制御サーバ１における制御条件定義情報の設定処理及びサービス提供サーバ３ａの停止制御の動作例を説明する。

はじめに、図１１に示すように、管理装置４において、管理者により制御条件が設定され、管理装置４により、制御条件定義要求が発行される（ステップＳ１１）。制御条件定義要求は、受付部１１を経由して制御管理部１２により受信される（図１２の処理Ｔ１１−１及びＴ１１−２）。
次いで、制御管理部１２により、受信した制御条件定義要求に含まれる制御条件に基づいて、制御条件定義情報ＤＢ１２ｄの登録（更新）が行なわれる（ステップＳ１２，図１２の処理Ｔ１２）。そして、制御管理部１２により、制御条件の登録が正常に完了したか否かを示す情報を含む制御条件定義応答が送信される。制御条件定義応答は、受付部１１を経由して管理装置４により受信される（図１２の処理Ｔ１１−３及びＴ１１−４）。

また、制御管理部１２により、サーバ状態取得要求がサーバ管理部１３へ発行される（図１２の処理Ｔ１３−１）。サーバ管理部１３では、図９のステップＳ１〜Ｓ３の処理が実行され、サーバ状態情報ＤＢ１３ｃが更新される（ステップＳ１３，図１２の処理Ｔ１３−２，Ｔ１３−３，Ｔ１４）。サーバ状態情報ＤＢ１３ｃが更新されると、サーバ管理部１３により、取得したサーバ状態を含むサーバ状態取得応答が制御管理部１２へ発行される（図１２の処理Ｔ１３−４）。

次いで、制御管理部１２により、サーバ管理部１３から受信したサーバ状態取得応答憎まれるサーバ状態が、制御条件定義情報ＤＢ１２ｄに定義された制御条件を満たすか否かが判定される（ステップＳ１４，図１２の処理Ｔ１５）。サーバ状態が制御条件を満たさない場合（ステップＳ１４のＮｏルート）、制御管理部１２及びサーバ管理部１３により、図９のステップＳ１〜Ｓ５の処理が実行され（ステップＳ１５）、ステップＳ１４に移行する。つまり、図１２の処理Ｔ１３−１〜１３−４，Ｔ１４，Ｔ１５が実行される。なお、ステップＳ１５の処理は、定期的に実行される。

一方、ステップＳ１４において、サーバ状態が制御条件を満たす場合（ステップＳ１４のＹｅｓルート）、制御管理部１２により、制御種別として“Stop”又は“Sleep”が含まれるサーバ制御要求が発行される（ステップＳ１６）。サーバ制御要求は、サーバ管理部１３を経由してサーバ３ａにより受信される（図１２の処理Ｔ１６−１及びＴ１６−２）。

サーバ３ａでは、サーバ制御要求に含まれる制御種別に応じた停止処理が行なわれ（図１２の処理Ｔ１７）、結果がサーバ制御応答として発行される。サーバ制御応答は、サーバ管理部１３を経由して制御管理部１２により受信される（ステップＳ１７，図１２の処理Ｔ１６−３，Ｔ１６−４）。このとき、サーバ制御応答を受信したサーバ管理部１３では、サーバ３ａによる停止処理の結果に基づいて、サーバ状態情報ＤＢ１３ｃが更新される（ステップＳ１８，図１２の処理Ｔ１８）。

また、サーバ制御応答を受信した制御管理部１２では、サーバ３ａによる停止処理の結果に基づいて、サーバ状態が変化したサーバ３ａのサーバ状態とＩＰアドレス又はサーバＩＤとを含む状態変化通知が発行され（ステップＳ１９）、ステップＳ１５に移行する。状態変化通知は、受付部１１を経由して管理装置４により受信される（図１２の処理Ｔ１９−１，Ｔ１９−２）。

以上のように、サービス環境制御サーバ１における制御条件定義情報の設定処理及びサービス提供サーバの停止制御が行なわれる。
〔１−５−３〕サービス環境制御サーバにおけるユーザ端末からの接続要求への処理及びユーザ端末とサービス提供サーバとの接続処理の動作例
次に、図１３〜図１７を参照して、サービス環境制御サーバ１におけるユーザ端末２からの接続要求への処理及びユーザ端末２とサービス提供サーバ３ａとの接続処理の動作例を説明する。

はじめに、図１３に示すように、受付部１１により、ユーザ端末２からの接続要求が受信される（ステップＳ２１，図１５の処理Ｔ２１−１）。なお、接続要求は、受付部１１のキューイング部１１ａに保持される。そして、受付部１１により、受信した接続要求の接続先のサーバ、例えば宛先アドレスが識別される（ステップＳ２２，図１５の処理Ｔ２２２）。

次いで、受付部１１により、識別した宛先アドレスを含むサーバ状態問合せ要求が発行される（ステップＳ２３）。サーバ状態問合せ要求は、制御管理部１２を経由してサーバ管理部１３により受信される（図１５の処理Ｔ２３−１，Ｔ２３−２）。サーバ管理部１３では、サーバ状態情報ＤＢ１３ｃのサービスＩＤに基づき、サーバ状態問合せ要求に含まれる宛先アドレスのサーバ３ａと同一のサービスを提供する全てのサーバ３ａが識別され、結果がサーバ状態取得応答として送信される（ステップＳ２３）。サーバ状態取得応答は、制御管理部１２を経由して受付部１１により受信される（図１５の処理Ｔ２３−３，Ｔ２３−４）。

受付部１１では、サーバ状態取得応答に基づき、上述した（ｉ）〜（iii）の判定条件に従って、宛先サーバ３ａ及び宛先サーバ３ａのサーバ状態が特定される。そして、受付部１１により、宛先サーバ３ａのサーバ状態が動作状態であるか否かが判定される（ステップＳ２４，図１５の処理Ｔ２５）。
宛先サーバ３ａのサーバ状態が動作状態である場合（ステップＳ２４のＹｅｓルート）、受付部１１により、キューイング部１１ａに保持された接続要求が宛先サーバ３ａへ送信される（ステップＳ２５）。接続要求は、制御管理部１２及びサーバ管理部１３を経由して宛先サーバ３ａにより受信される（図１５の処理Ｔ２１−２〜Ｔ２１−４）。

宛先サーバ３ａでは、接続要求に応じた接続処理が行なわれ、接続の判定結果を含む結果が接続応答として送信される（ステップＳ２６）。接続応答は、サーバ管理部１３を経由して制御管理部１２により受信される（図１５の処理Ｔ２１−５，Ｔ２１−６）。
制御管理部１２では、接続応答が参照されて、接続の判定結果に基づきセッション情報ＤＢ１２ｆの接続状態が更新される（ステップＳ２７，図１５の処理Ｔ２４）。そして、制御管理部１２により、接続応答が転送される。接続応答は、受付部１１を経由してユーザ端末２により受信される（図１５の処理Ｔ２１−７，Ｔ２１−８）。

ユーザ端末２では、接続応答に含まれる接続の判定結果と、例えばログイン画面のUniform Resource Locator（ＵＲＬ）等の情報（判定結果が接続可の場合）とに基づいて、宛先サーバ３ａとの接続が行なわれる（ステップＳ２８）。
一方、ステップＳ２４において、宛先サーバ３ａが動作状態ではない場合（ステップＳ２４のＮｏルート）、図１４のステップＳ３１に移行する。

図１４に示すように、ステップＳ３１では、宛先サーバ３ａが停止状態であるか否かが判定される。
宛先サーバ３ａが停止状態である場合（ステップＳ３１のＹｅｓルート）、並行して実施されるステップＳ３２及びＳ３４に移行する。
ステップＳ３２では、受付部１１により、ユーザ端末２からの接続要求に対する代理応答要求が代理応答部１４へ送信される。代理応答要求は、制御管理部１２を経由して代理応答部１４により受信される（図１６の処理Ｔ３１−１，Ｔ３１−２）。代理応答部１４では、代理応答要求に基づいて、ユーザ端末２に対する代理応答が送信される（ステップＳ３３）。代理応答は、制御管理部１２及び受付部１１を経由してユーザ端末２により受信される（図１６の処理Ｔ３１−３〜３１−４）。なお、ユーザ端末２では、代理応答に含まれるＵＲＩへのアクセスにより、代理応答画面が表示される。また、並行して実施されるステップＳ３７が完了すると、図１３のステップＳ２５に移行する。

一方、ステップＳ３４では、制御管理部１２により、代理応答部１４へ中継する代理応答要求（図１６の処理Ｔ３１−２参照）が参照され、宛先サーバ３ａ及び宛先サーバ３ａが停止状態であることが特定される。宛先サーバ３ａが停止状態であることが特定されると、制御管理部１２により、制御種別として“起動”が含まれるサーバ制御要求が発行される。サーバ制御要求は、サーバ管理部１３を経由して宛先サーバ３ａにより受信される（図１７の処理Ｔ３２−１及びＴ３２−２）。

宛先サーバ３ａでは、サーバ制御要求に含まれる制御種別に応じた起動処理が行なわれ（図１７の処理Ｔ３３）、結果がサーバ制御応答として発行される。サーバ制御応答は、サーバ管理部１３を経由して制御管理部１２により受信される（ステップＳ３５，図１７の処理Ｔ３２−３，Ｔ３２−４）。このとき、サーバ制御応答を受信したサーバ管理部１３では、宛先サーバ３ａによる起動処理の結果に基づいて、サーバ状態情報ＤＢ１３ｃが更新される（ステップＳ３６，図１７の処理Ｔ３４）。

また、サーバ制御応答を受信した制御管理部１２では、宛先サーバ３ａによる起動処理の結果に基づいて、宛先サーバ３ａの起動完了（接続準備の完了）を示すサーバ起動完了通知がユーザ端末２へ通知される（ステップＳ３７）。サーバ起動完了通知は、受付部１１を経由してユーザ端末２により受信される（図１７の処理Ｔ３５−１，Ｔ３５−２）。
ユーザ端末２では、サーバ起動完了通知に対する応答であるサーバ起動完了通知受信応答が発行され、図１３のステップＳ２５に移行する。

つまり、サーバ起動完了通知受信応答は、受付部１１により受信されると（図１７の処理Ｔ３６−１）、受付部１１により、キューイング部１１ａに保持された接続要求が含められて制御管理部１２へ送信される（図１７の処理Ｔ３６−２）。
制御管理部１２では、受信した接続要求が、宛先サーバ３ａへ送信される。接続要求は、サーバ管理部１３を経由して宛先サーバ３ａにより受信される（図１７の処理Ｔ３７−２，Ｔ３７−２）。

宛先サーバ３ａでは、接続要求に応じた接続処理が行なわれ、接続の判定結果を含む結果が接続応答として送信される（ステップＳ２６）。接続応答は、サーバ管理部１３を経由して制御管理部１２により受信される（図１７の処理Ｔ３７−３，Ｔ３７−４）。
制御管理部１２では、接続応答が参照されて、接続の判定結果に基づきセッション情報ＤＢ１２ｆの接続状態が更新される（ステップＳ２７，図１７の処理Ｔ３８）。そして、制御管理部１２により、接続応答が転送される。接続応答は、受付部１１を経由してユーザ端末２により受信される（図１７の処理Ｔ３７−５，Ｔ３７−６）。

ユーザ端末２では、接続応答に含まれる接続の判定結果と、例えばログイン画面のＵＲＬ等の情報（判定結果が接続可の場合）とに基づいて、宛先サーバ３ａとの接続が行なわれる（ステップＳ２８）。
以上のように、サービス環境制御サーバ１におけるユーザ端末２からの接続要求への処理及びユーザ端末２とサービス提供サーバ３ａとの接続処理が行なわれる。

なお、上述のように、制御管理部１２は、サーバ管理部１３からのサーバ状態の問合せ応答を受信したときに（図１５の処理Ｔ２３−３参照）、宛先サーバ３ａ及び宛先サーバ３ａのサーバ状態を自身で特定してもよい。この場合、図１４のステップＳ３４（図１７の処理Ｔ３２−１）から先の処理は、図１３のステップＳ２３（図１５の処理Ｔ２３−３）が行なわれたときに実行されてもよい。

〔２〕その他
以上、本発明の好ましい実施形態について詳述したが、本発明は、係る特定の実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲内において、種々の変形、変更して実施することができる。
上述した一実施形態において、受付部１１、制御管理部１２、サーバ管理部１３、及び代理応答部１４のブロック間での要求及び応答、並びに種々のデータの受け渡しは、適宜省略してもよい。例えば、上記ブロックが共通の記憶部１０ｃに各ＤＢを保存する場合には、各ブロックが適宜記憶部１０ｃに保存されたＤＢを参照することで、上述した要求及び応答、並びに種々のデータを省略することができる。

なお、一実施形態のサービス環境制御サーバ１の各種機能の全部もしくは一部は、コンピュータ（ＣＰＵ，情報処理装置，各種端末を含む）が所定のプログラムを実行することによって実現されてもよい。
そのプログラムは、例えばフレキシブルディスク，ＣＤ（ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＣＤ−ＲＷなど），ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−ＲＡＭ，ＤＶＤ−Ｒ，ＤＶＤ−ＲＷ，ＤＶＤ＋Ｒ，ＤＶＤ＋ＲＷなど），ブルーレイディスク等のコンピュータ読取可能な記録媒体（例えば図２に示す記録媒体１０ｈ）に記録された形態で提供される。この場合、コンピュータはその記録媒体からプログラムを読み取って内部記憶装置または外部記憶装置に転送し格納して用いる。

ここで、コンピュータとは、ハードウェアとＯＳ（オペレーティングシステム）とを含む概念であり、ＯＳの制御の下で動作するハードウェアを意味している。また、ＯＳが不要でアプリケーションプログラム単独でハードウェアを動作させるような場合には、そのハードウェア自体がコンピュータに相当する。ハードウェアは、少なくとも、ＣＰＵ等のマイクロプロセッサと、記録媒体に記録されたコンピュータプログラムを読み取る手段とをそなえている。上記プログラムは、上述のようなコンピュータに、一実施形態のサービス環境制御サーバ１の各種機能を実現させるプログラムコードを含んでいる。また、その機能の一部は、アプリケーションプログラムではなくＯＳによって実現されてもよい。

〔３〕付記
以上の実施形態に関し、更に以下の付記を開示する。
（付記１）
端末装置と前記端末装置からの要求に対して応答を行なう一以上の処理装置との間に介設され、前記処理装置の制御を行なう制御装置であって、
前記端末装置からの要求の宛先である宛先処理装置が停止状態の場合、前記宛先処理装置に対して、停止状態から動作状態に遷移させる起動制御を行なう状態制御部と、
前記宛先処理装置が停止状態の場合、前記一以上の処理装置の代わりに代理応答を行なう代理応答部に、前記端末装置に対する代理応答を実行させ、前記宛先処理装置が停止状態から動作状態に遷移すると、前記端末装置からの要求を前記宛先処理装置へ送信する要求制御部と、をそなえる
ことを特徴とする、制御装置。

（付記２）
前記状態制御部は、前記一以上の処理装置に対して所定期間内に発行された要求に基づき、前記一以上の処理装置のうちの所定の条件を満たす処理装置に対して、動作状態から停止状態に遷移させる停止制御を行なう
ことを特徴とする、付記１記載の制御装置。

（付記３）
前記状態制御部は、前記一以上の処理装置のうちの前記所定期間内に発行された要求の数が所定の閾値以下である処理装置に対して、前記停止制御を行なう
ことを特徴とする、付記２記載の制御装置。
（付記４）
複数の前記処理装置の各々の状態を取得する状態取得部をさらにそなえ、
前記要求制御部は、前記端末装置からの要求の宛先アドレスに対応する処理装置と同一のサービスを提供する処理装置の中から、前記状態取得部が取得した状態に基づいて、前記宛先処理装置を特定する
ことを特徴とする、付記１〜３のいずれか１項記載の制御装置。

（付記５）
前記端末装置からの要求を保持する保持部をさらにそなえ、
前記要求制御部は、前記宛先処理装置が停止状態の場合、前記保持部に保持された前記端末装置からの要求の複製を前記代理応答部に転送し、前記宛先処理装置が停止状態から動作状態に遷移すると、前記保持部に保持された前記端末装置からの要求を前記宛先処理装置へ送信する
ことを特徴とする、付記１〜４のいずれか１項記載の制御装置。

（付記６）
前記要求制御部から転送された要求の複製を受信すると、受信した要求の複製の送信元である前記端末装置に対して、前記宛先処理装置に応じた代理応答を行なう前記代理応答部をさらにそなえる
ことを特徴とする、付記５記載の制御装置。

（付記７）
端末装置と前記端末装置からの要求に対して応答を行なう一以上の処理装置との間に介設され、前記処理装置の制御を行なう制御装置における制御方法であって、
前記端末装置からの要求の宛先である宛先処理装置が停止状態の場合、前記宛先処理装置に対して、停止状態から動作状態に遷移させる起動制御を行ない、
前記宛先処理装置が停止状態の場合、前記端末装置に対して前記宛先処理装置の代わりに代理応答を行ない、
前記宛先処理装置が停止状態から動作状態に遷移すると、前記端末装置からの要求を前記宛先処理装置へ送信する
ことを特徴とする、制御方法。

（付記８）
前記一以上の処理装置に対して所定期間内に発行された要求に基づき、前記一以上の処理装置のうちの所定の条件を満たす処理装置に対して、動作状態から停止状態に遷移させる停止制御を行なう
ことを特徴とする、付記７記載の制御方法。

（付記９）
前記停止制御を行なう処理は、前記一以上の処理装置のうちの前記所定期間内に発行された要求の数が所定の閾値以下である処理装置に対して、前記停止制御を行なう
ことを特徴とする、付記８記載の制御方法。
（付記１０）
複数の前記処理装置の各々の状態を取得し、
前記端末装置からの要求の宛先アドレスに対応する処理装置と同一のサービスを提供する処理装置の中から、前記複数の処理装置の各々から取得した状態に基づいて、前記宛先処理装置を特定する
ことを特徴とする、付記７〜９のいずれか１項記載の制御方法。

（付記１１）
前記代理応答を行なう処理は、前記宛先処理装置が停止状態の場合、前記端末装置からの要求を保持する保持部に保持された要求に基づいて、前記要求の送信元である前記端末装置に対して、前記宛先処理装置に応じた代理応答を行ない、
前記端末装置からの要求を前記宛先処理装置へ送信する処理は、前記宛先処理装置が停止状態から動作状態に遷移すると、前記保持部に保持された前記端末装置からの要求を前記宛先処理装置へ送信する
ことを特徴とする、付記７〜１０のいずれか１項記載の制御方法。

（付記１２）
端末装置と前記端末装置からの要求に対して応答を行なう一以上の処理装置との間に介設され、前記処理装置の制御を行なうコンピュータに、
前記端末装置からの要求の宛先である宛先処理装置が停止状態の場合、前記宛先処理装置に対して、停止状態から動作状態に遷移させる起動制御を行ない、
前記宛先処理装置が停止状態の場合、前記端末装置に対して前記宛先処理装置の代わりに代理応答を行ない、
前記宛先処理装置が停止状態から動作状態に遷移すると、前記端末装置からの要求を前記宛先処理装置へ送信する
処理を実行させることを特徴とする、制御プログラム。

（付記１３）
前記一以上の処理装置に対して所定期間内に発行された要求に基づき、前記一以上の処理装置のうちの所定の条件を満たす処理装置に対して、動作状態から停止状態に遷移させる停止制御を行なう
処理を前記コンピュータに実行させることを特徴とする、付記１２記載の制御プログラム。

（付記１４）
前記停止制御を行なう処理は、前記一以上の処理装置のうちの前記所定期間内に発行された要求の数が所定の閾値以下である処理装置に対して、前記停止制御を行なう
ことを特徴とする、付記１３記載の制御プログラム。
（付記１５）
複数の前記処理装置の各々の状態を取得し、
前記端末装置からの要求の宛先アドレスに対応する処理装置と同一のサービスを提供する処理装置の中から、前記複数の処理装置の各々から取得した状態に基づいて、前記宛先処理装置を特定する
処理を前記コンピュータに実行させることを特徴とする、付記１２〜１４のいずれか１項記載の制御プログラム。

（付記１６）
前記代理応答を行なう処理は、前記宛先処理装置が停止状態の場合、前記端末装置からの要求を保持する保持部に保持された要求に基づいて、前記要求の送信元である前記端末装置に対して、前記宛先処理装置に応じた代理応答を行ない、
前記端末装置からの要求を前記宛先処理装置へ送信する処理は、前記宛先処理装置が停止状態から動作状態に遷移すると、前記保持部に保持された前記端末装置からの要求を前記宛先処理装置へ送信する
ことを特徴とする、付記１２〜１５のいずれか１項記載の制御プログラム。

（付記１７）
端末装置と前記端末装置からの要求に対して応答を行なう一以上の処理装置との間に介設され、前記処理装置の制御を行なう制御装置であって、
プロセッサをそなえ、
前記プロセッサが、
前記端末装置からの要求の宛先である宛先処理装置が停止状態の場合、前記宛先処理装置に対して、停止状態から動作状態に遷移させる起動制御を行ない、
前記宛先処理装置が停止状態の場合、前記端末装置に対して前記宛先処理装置の代わりに代理応答を行ない、
前記宛先処理装置が停止状態から動作状態に遷移すると、前記端末装置からの要求を前記宛先処理装置へ送信する
ことを特徴とする、制御装置。

１ サービス環境制御サーバ（制御装置）
２ ユーザ端末（端末装置）
３ サービス提供システム
３ａ，３ａ−１ 勤怠管理サービスサーバ（サービス提供サーバ，処理装置）
３ａ，３ａ−２ 出張申請サービスサーバ（サービス提供サーバ，処理装置）
３ｂ−１ 勤怠情報ＤＢ
３ｂ−２ 出張旅費情報ＤＢ
４ 管理装置
５ ネットワーク
１０ａ ＣＰＵ（プロセッサ）
１０ｂ メモリ
１０ｃ 記憶部
１０ｄ インタフェース
１０ｅ 入出力部
１０ｆ，１０ｈ 記録媒体
１０ｇ 読取部
１１ 受付部（要求制御部）
１１ａ キューイング部（保持部）
１１ｂ 宛先判定部
１２ 制御管理部
１２ａ 制御条件管理部
１２ｂ 制御判定部
１２ｃ セッション管理部
１２ｄ 制御条件定義情報ＤＢ
１２ｅ 制御情報ＤＢ
１２ｆ セッション情報ＤＢ
１３ サーバ管理部
１３ａ サーバ状態取得部
１３ｂ サーバ制御部
１３ｃ サーバ状態情報ＤＢ
１４ 代理応答部
１４ａ 代理応答情報ＤＢ
１５ 状態制御部

Claims (10)

1. 端末装置と前記端末装置からの要求に対して応答を行なう一以上の処理装置との間に介設され、前記処理装置の制御を行なう制御装置であって、
   前記端末装置からの要求の宛先である宛先処理装置が停止状態の場合、前記宛先処理装置に対して、停止状態から動作状態に遷移させる起動制御を行なう状態制御部と、
   前記宛先処理装置が停止状態の場合、前記一以上の処理装置の代わりに代理応答を行なう代理応答部に、前記端末装置に対する代理応答を実行させ、前記宛先処理装置が停止状態から動作状態に遷移すると、前記端末装置からの要求を前記宛先処理装置へ送信する要求制御部と、
   前記端末装置と前記代理応答部との間でセッションを確立し、前記セッションと前記端末装置の通信先である前記代理応答部とを対応付けた管理情報を管理し、前記宛先処理装置の状態が前記停止状態から前記動作状態に遷移した後、前記端末装置から前記宛先処理装置に前記要求が送信されたことに応じて、前記管理情報に対して前記セッションにおける前記端末装置の通信先を前記代理応答部から前記宛先処理装置に切り替えるセッション管理部と、をそなえる
   ことを特徴とする、制御装置。
2. 前記状態制御部は、前記一以上の処理装置に対して所定期間内に発行された要求に基づき、前記一以上の処理装置のうちの所定の条件を満たす処理装置に対して、動作状態から停止状態に遷移させる停止制御を行なう
   ことを特徴とする、請求項１記載の制御装置。
3. 前記状態制御部は、前記一以上の処理装置のうちの前記所定期間内に発行された要求の数が所定の閾値以下である処理装置に対して、前記停止制御を行なう
   ことを特徴とする、請求項２記載の制御装置。
4. 複数の前記処理装置の各々の状態を取得する状態取得部をさらにそなえ、
   前記要求制御部は、前記端末装置からの要求の宛先アドレスに対応する処理装置と同一のサービスを提供する処理装置の中から、前記状態取得部が取得した状態に基づいて、前記宛先処理装置を特定する
   ことを特徴とする、請求項１〜３のいずれか１項記載の制御装置。
5. 前記端末装置からの要求を保持する保持部をさらにそなえ、
   前記要求制御部は、前記宛先処理装置が停止状態の場合、前記保持部に保持された前記端末装置からの要求の複製を前記代理応答部に転送し、前記宛先処理装置が停止状態から動作状態に遷移すると、前記保持部に保持された前記端末装置からの要求を前記宛先処理装置へ送信する
   ことを特徴とする、請求項１〜４のいずれか１項記載の制御装置。
6. 前記要求制御部から転送された要求の複製を受信すると、受信した要求の複製の送信元である前記端末装置に対して、前記宛先処理装置に応じた代理応答を行なう前記代理応答部をさらにそなえる
   ことを特徴とする、請求項５記載の制御装置。
7. 端末装置と前記端末装置からの要求に対して応答を行なう一以上の処理装置との間に介設され、前記処理装置の制御を行なう制御装置における制御方法であって、
   前記端末装置からの要求の宛先である宛先処理装置が停止状態の場合、前記宛先処理装置に対して、停止状態から動作状態に遷移させる起動制御を行ない、
   前記宛先処理装置が停止状態の場合、前記端末装置に対して前記宛先処理装置の代わりに代理応答を行なう代理応答部に、前記端末装置に対する代理応答を実行させ、
   前記端末装置と前記代理応答部との間でセッションを確立し、
   前記セッションと前記端末装置の通信先である前記代理応答部とを対応付けた管理情報を管理し、
   前記宛先処理装置が停止状態から動作状態に遷移すると、前記端末装置からの要求を前記宛先処理装置へ送信し、
   前記宛先処理装置の状態が前記停止状態から前記動作状態に遷移した後、前記端末装置から前記宛先処理装置に前記要求が送信されたことに応じて、前記管理情報に対して前記セッションにおける前記端末装置の通信先を前記代理応答部から前記宛先処理装置に切り替える
   ことを特徴とする、制御方法。
8. 前記一以上の処理装置に対して所定期間内に発行された要求に基づき、前記一以上の処理装置のうちの所定の条件を満たす処理装置に対して、動作状態から停止状態に遷移させる停止制御を行なう
   ことを特徴とする、請求項７記載の制御方法。
9. 端末装置と前記端末装置からの要求に対して応答を行なう一以上の処理装置との間に介設され、前記処理装置の制御を行なうコンピュータに、
   前記端末装置からの要求の宛先である宛先処理装置が停止状態の場合、前記宛先処理装置に対して、停止状態から動作状態に遷移させる起動制御を行ない、
   前記宛先処理装置が停止状態の場合、前記端末装置に対して前記宛先処理装置の代わりに代理応答を行なう代理応答部に、前記端末装置に対する代理応答を実行させ、
   前記端末装置と前記代理応答部との間でセッションを確立し、
   前記セッションと前記端末装置の通信先である前記代理応答部とを対応付けた管理情報を管理し、
   前記宛先処理装置が停止状態から動作状態に遷移すると、前記端末装置からの要求を前記宛先処理装置へ送信し、
   前記宛先処理装置の状態が前記停止状態から前記動作状態に遷移した後、前記端末装置から前記宛先処理装置に前記要求が送信されたことに応じて、前記管理情報に対して前記セッションにおける前記端末装置の通信先を前記代理応答部から前記宛先処理装置に切り替える
   処理を実行させることを特徴とする、制御プログラム。
10. 前記一以上の処理装置に対して所定期間内に発行された要求に基づき、前記一以上の処理装置のうちの所定の条件を満たす処理装置に対して、動作状態から停止状態に遷移させる停止制御を行なう
    処理を前記コンピュータに実行させることを特徴とする、請求項９記載の制御プログラム。

Images