JP4230673B2

JP4230673B2 - サービス管理装置

Info

Publication number: JP4230673B2
Application number: JP2001046516A
Authority: JP
Inventors: 武石田; 京海尹; 実山本
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2001-02-22
Filing date: 2001-02-22
Publication date: 2009-02-25
Anticipated expiration: 2021-02-22
Also published as: US7543060B2; US20020116479A1; JP2002251344A

Description

【０００１】
【発明の属する技術分野】
本発明は、サービスを提供するサービスサーバにサービス要求を分配するサービス管理装置に関する。
【０００２】
【従来の技術】
今日、インターネットの普及により、インターネット上での様々なビジネスが展開されつつある。中でも、インターネットを介して、ユーザに様々なアプリケーションサービスを提供するＡＳＰ（Application Service Provider）サービスが実用化されている。
【０００３】
図１７は、ＡＳＰサービスを提供するシステムの概略構成図である。
サービスを行う複数のサービスサーバ１０は、サービス要求のサービスサーバ１０への分配などの管理を行うサービス管理サーバ１１に接続され、サービス管理サーバ１１を介して、クライアント１４からのサービス要求を受け付ける。また、サービス管理サーバ１１は、ウェブサーバ１２に接続され、クライアント１４からのサービス要求をインターネット１５経由で受け付けるよう構成される。
【０００４】
このような、ウェブサーバ１２、サービス管理サーバ１１、及びサービスサーバ１０からなるシステムは、データセンタ１３と呼ばれ、様々なプロバイダからのアプリケーションの提供サービスをまとめて管理する。
【０００５】
ところで、最近では、アプリケーションの提供サービスにおいて、受け付けたサービス要求を単にサービスサーバ１０に割り振って、サービスを提供するだけでなく、サービスの提供品質を契約によって補償しつつ、アプリケーション提供サービスをクライアント１４に提供するというＳＬＡ（Service Level Agreement ：サービスの品質を保証する契約）を実現しようとしている。
【０００６】
図１８は、ＳＬＡにおけるサービス管理サーバのサービス管理方法の従来技術を説明する図である。
ＳＬＡにおいて補償されるサービスの品質としては、サービスサーバの応答速度、障害復旧時間、障害発生時の補償などが挙げられるが、以下の説明においては、サービスの品質としてサービスサーバの応答速度を念頭に置いて説明する。
【０００７】
従来のＳＬＡの実現方法の一つとしては、図１８（ａ）に示されるような、提供するサービスの品質毎にサービスサーバをグループ分けする方法がある。この場合、サービスサーバは、高品質のサービスを提供するサーバと、一般レベルのサービスを提供するサーバなどのグループに分けられ、それぞれのグループ内では、定められたサービスの品質を維持しつつサービスの提供を行うように構成される。サービス管理サーバは、サービス要求の品質契約内容に従って、受信したサービス要求をどのグループのサービスサーバに割り振るかを決定して、サービス要求（リクエスト）を送信する。
【０００８】
このような場合、それぞれのグループで品質を統一して維持することは容易であるが、リクエストが一部のレベルに集中した場合、サーバ間の負荷の格差が大きくなり、全てのサーバ資源を有効に活用できないと言う問題が生じる。すなわち、サービス品質がサービスサーバの応答速度である場合、高品質のサービスを提供するサービスサーバは、クライアントからのサービス要求に対して高速に応答する必要があるので、高品質サービスサーバには、大きな負荷がかからないようにサービス要求を割り振る必要がある。このようにすれば、高品質サービスサーバは、常時高品質のサービスを提供することができるので、サービス品質の管理は行いやすい。しかし、上記したように、サービス品質レベル毎にサービスサーバがグループ分けされているので、一部のグループにサービス要求が集中しても、サービス要求の処理はグループ内で行わなければならず、グループ間での負荷の格差、すなわち、サーバ資源の無駄が生じる。
【０００９】
また、従来のＳＬＡの実現方法の他の方法としては、図１８（ｂ）に記載されているように、全てのサービスサーバが全ての品質レベルのサービスを処理するという方法がある。この場合、各サービスサーバは、高品質契約のサービス要求（リクエスト）を優先的に処理すると共に、一般レベル契約のリクエストも受付け、処理しなければならない。このとき、サービス管理サーバは、リクエストの品質契約内容を知る必要はなく、各サービスサーバの負荷が出来るだけ均等になるように、各リクエストを各サービスサーバに割り振る処理を行う。
【００１０】
従って、各サービスサーバは、リクエストが高品質契約のものか、一般レベルのものかを判断し、判断結果によって処理の優先度を変えて処理するという手続きを行わなければならない。これを実現するためには、サービスサーバに複雑なロジックからなるプログラムを実装しなければならない。
【００１１】
このような場合、全てのサーバ資源を均等に使用でき、負荷分散は行いやすいが、ロジックが複雑になる上に、品質を正確に維持することが困難になるという問題点がある。また、運用中のＡＳＰサービスにこの方式を導入しようとすると、個々のアプリケーションサービスを根本的に作り直す必要があるため、時間的にも金銭的にも莫大なコストが必要になる。
【００１２】
【発明が解決しようとする課題】
図１９は、従来の問題点を説明する図である。
上記したように、ＳＬＡにおいて、確実にサービス品質を確保しようとするので有れば、図１８（ｂ）より、図１８（ａ）の構成の方がより簡単で正確に品質を確保できるが、前述したように、グループ間で負荷の格差が生じ、サーバ資源が有効に使用できないという問題が生じる。
【００１３】
本発明の課題は、サービスの品質を維持しつつ、サーバの負荷を適切に分散することの出来るサービス管理装置を提供することである。
【００１４】
【課題を解決するための手段】
本発明のサービス管理装置は、ネットワークを介してクライアントからのサービス要求に応じたサービスを提供するサービスサーバを複数収容し、該複数のサービスサーバにサービス要求を配分するサービス管理装置において、該複数のサービスサーバを、提供するサービスの品質レベル毎の複数のグループのサービスサーバと、該グループ間を移行して、移行先のグループのサービス品質でサービスを提供する中間サーバグループのサービスサーバとにグループ化して管理する管理手段と、いずれかのグループのサービスサーバの負荷が増加し、そのグループが提供すべき品質レベルを維持できなくなる場合に、該中間サーバグループの最も負荷の低いサービスサーバを少なくとも１つ、該グループのサービスサーバとして使用して、該グループのサービスサーバの負荷の低減を図る中間サーバ移行手段とを備えることを特徴とする。
【００１５】
本発明によれば、サービスサーバをサービスの品質レベル毎にグループ化してサービスを提供するので、安定した品質でサービスを提供できる。また、その場合に問題となるグループ間での負荷の偏りを、グループ間を動的に移行可能な中間サーバグループのサービスサーバを設け、これを負荷の多いグループへ移行させることにより、解消するので、安定した品質でのサービスの提供と、サービスサーバ間の負荷を適切に分散することが出来る。
【００１６】
【発明の実施の形態】
図１は、本発明の実施形態の概略を示す図である。
本実施形態の説明においては、クライアント（顧客）とのサービス契約において、上位レベルの品質と下位レベルの品質の契約のみがあるものとする。そして、この場合、本実施形態では、上位レベルのサービスサーバグループと下位レベルのサービスサーバグループとを用意すると共に、中間グループのサービスサーバを用意する。上位レベルグループのサービスサーバは、上位レベル品質のリクエストを専用に受け付け、下位レベルグループのサービスサーバは、下位レベル品質のリクエストを専用に受け付ける。中間グループのサービスサーバは、通常時は、上位レベルの品質で、下位レベルのリクエストを処理する。すなわち、下位レベルのリクエストを上位レベルの品質でサービス提供していることになる。
【００１７】
そして、例えば、上位レベルグループのサービスサーバにリクエストが集中し、負荷が大きくなり、品質の維持が難しくなったとすると、中間グループのサービスサーバをレベルアップさせ、下位レベルのリクエストではなく、上位レベルのリクエストを処理させるようにする。
【００１８】
この場合、上記のようなリクエストの割り振りは、サービス管理サーバが一括して行う。
図２は、本発明の実施形態が適用されるシステムの構成図である。
【００１９】
クライアント（不図示）は、インターネット２０を介して、ウェブサーバ２２にリクエストを送信する。ウェブサーバ２２、サービス管理サーバ２４、サービスサーバ２５−１〜２５−ｎ、及びデータベースサーバ２６からなるデータセンタは、ファイアウォール２１によって外部からの不正なアクセスに対して防御される。真正なクライアントは、このファイアウォール２１をパスするＩＤなどのアカウントを有しており、これを使って、ウェブサーバ２２にリクエストを通知する。ウェブサーバ２２では、このリクエストをトリガにして起動し、後段のサービス管理サーバ２４などに命令を通知するサーブレットエンジン２３が設けられている。従って、ウェブサーバ２２がクライアントからのリクエストを受け取ると、サーブレットエンジン２３が、このリクエストに基づいた処理を行うべき旨の命令をサービス管理サーバ２４に通知する。
【００２０】
サービス管理サーバ２４は、ウェブサーバ２２のサーブレットエンジン２３から受け取った命令に基づいて、リクエストを適切なサービスサーバ２５−１〜２５−ｎに振り分ける。通常状態では、上位レベルのリクエストは、上位レベルグループのサービスサーバに、下位レベルのリクエストは、中間グループあるいは、下位レベルグループのサービスサーバに受け渡す。サービスサーバ２５−１〜２５−ｎは、データベースサーバ２６に格納されている情報から、サービスの提供に必要なデータを取得し、アプリケーションサービス内容に変換して、クライアントに送り返す。
【００２１】
ここで、図１で説明したような処理をサービス管理サーバが行うためには、上位、下位レベル、中間グループのサービスサーバを管理するための管理用データが必要となる。以下は、本実施形態において必要とする管理用データの一例である。
・サービス管理サーバで管理されているデータ
−サービスサーバ情報（サービスサーバ１台毎に定義されている）
ID=Server Ａ：サーバを識別するＩＤ
Load=20 ：現在のサービスサーバの負荷値（サービスサーバが定期的にサービス管理サーバに通知する）
Limit HighLV=50 、Limit LowLV=100 ：閾値（サービスレベル毎の品質を維持するための負荷値の限界）
Group=上位：サーバが所属しているグループ
ReqLV=上位：実行するリクエストのレベル
ResLV=上位：維持しなくてはならない品質のレベル
serviceX=5、serviceY=10 ：サービス処理の負荷値（そのサーバで各サービスの処理を実行した時の負荷値）
−共通情報
changeTime= 午前３：００：サーバ構成の自動変更を行う時間
Priority1=曜日、Priority2=日にち：リクエスト集計の優先順位（リクエストを集計する時にどの条件の偏りを優先するかを示す）
schedule：サーバ構成のスケジュールデータ
・各サービスサーバで管理されている情報
runningService= ｛X,X,X,Y ｝：実行中の処理
サービスサーバ情報（サービス管理サーバで管理されているものと同じ）
・クライアントからのリクエストから取得できる情報
Service=X ：実行する処理の種類
SL= 上位：契約しているサービスの品質レベル
図３は、中間グループのサービスサーバ（中間サーバ）の状態変化を示す図である。
【００２２】
図１８（ｂ）に示したように、従来の負荷分散の手法では、サーバやネットワーク上の負荷を計測し、最も負荷の低いサーバに処理を行わせるというものが一般的であった。しかし、そのようなサービスの品質を考慮しないやり方では、ＳＬＡを守ることと負荷分散を両立することは出来ない。
【００２３】
本実施形態では、中間サーバのレベル変化の際に維持すべき品質を細かく管理することによって負荷分散と品質の維持を両立する。
図３に示されるように、中間サーバは、通常状態では、上位レベルの品質で、下位レベルのリクエストを処理している。ここで、上位レベルグループのサービスサーバの負荷が大きくなったとすると、前述したように、上位レベルにレベルアップして、上位レベルの品質で、上位レベルのリクエストを処理する。ここで、通常状態で上位レベルへの品質を維持しているため、レベルアップして上位レベルのリクエストを受け入れても中間サーバは品質を維持することが出来る。
【００２４】
また、前述の説明では記載しなかったが、中間サーバは、上位から通常、通常から下位、下位から通常の状態遷移もすることができる。
すなわち、中間サーバが上位レベルにある場合に、実行中の上位レベルのリクエストが無くなったら、通常状態に戻す。したがって、中間サーバが上位レベルにあって、上位レベルのリクエストを処理し終わると、下位レベルのリクエストを処理しはじめる。これにより、通常状態に戻る。もし、中間サーバが、下位レベルグループの負荷が大きくなって、下位レベルにレベルダウンする場合でも、通常状態から下位レベルに移行するので、上位レベルのリクエストを処理した状態で、下位レベルのリクエストを処理しはじめることはない。
【００２５】
中間サーバが下位レベルに移行した場合には、下位レベルの品質で、下位レベルのリクエストを処理する。通常状態では、下位レベルのリクエストのみを実行しているため、レベルダウンしてサービスの品質を落としても問題は生じない。また、下位レベルグループのサービスサーバの負荷が下がって、上位レベルの品質を守ることができるようになったら、中間サーバは、通常状態に戻る。すなわち、下位レベルのリクエストを上位レベルの品質で処理するようにする。通常状態に戻った後は、前述したように、すぐに上位レベルにレベルアップすることができる。
【００２６】
図４は、サービス管理サーバの処理の概略を示す図である。
まず、ステップＳ１において、サービス管理サーバがリクエストを受信する。次に、ステップＳ２において、リクエストを振り分けるサービスサーバを決定する。また、このとき、中間サーバのレベルアップ（ダウン）が必要か否かの判断を行う。そして、ステップＳ３において、振り分け先に決まったサービスサーバにリクエストを送信する。
【００２７】
ステップＳ２及びＳ３の処理の詳細を以下に説明する。
図５は、サービス管理サーバの処理の詳細を示すフローチャートである。
図５において、左側に示されているフローは、図４と同じものであるが、ここでは、説明を簡略化するため、受信するリクエストをサービスＸに対する上位レベルのリクエストとしている。
【００２８】
図５において、右側に示されているのは、左側に示されているフローのステップＳ２、Ｓ３の詳細フローである。
まず、ステップＳ１において、サービスＸに対する上位レベルのリクエストをサービス管理サーバが受け取ると、ステップＳ１３において、上位レベルグループのサービスサーバでサービスＸを実行可能なサーバが存在するか否かを調べる。ステップＳ１３の詳細については、図６で説明する。ステップＳ１３において、実行可能なサーバが存在すると判断された場合には、ステップＳ１７に進んで、実行可能なサーバの内、負荷の最も低いサーバにリクエストを割り振る。
【００２９】
ステップＳ１３において、実行可能なサーバが無いと判断された場合には、ステップＳ１４において、レベルアップした中間サーバがもしあれば、その中でサービスＸを実行可能なサーバが存在するか否かを調べる。ステップＳ１４の詳細についても図６で説明する。ステップＳ１４において、実行可能なサーバが存在すると判断された場合には、ステップＳ１８において、実行可能なサーバの内、負荷の最も低いサーバにリクエストを割り振る。
【００３０】
ステップＳ１４において、実行可能なサーバが存在しないと判断された場合には、ステップＳ１５に進んで、通常状態の中間サーバが存在するか否かを判断する。ステップＳ１５において、通常状態の中間サーバが存在すると判断された場合には、ステップＳ１９において、中間サーバの内、１台を上位レベルにレベルアップさせる。ステップＳ１９の詳細については、図７で説明する。そして、ステップＳ２０において、レベルアップした中間サーバにリクエストを割り振る。
【００３１】
ステップＳ１５において、通常状態の中間サーバが存在しないと判断された場合には、ステップＳ１６において、実行不能なため、リクエストを待機管理手段に送信する。待機管理手段とは、サービスサーバが混雑している際に、リクエストを待機させるサーバのことである。
【００３２】
図６は、図５のステップＳ１３、Ｓ１４の詳細を示すフローチャートである。なお、図６においては、上位レベルグループ内のサーバに対する処理として示しているが、レベルアップした中間サーバを対象とする場合も同様である。
【００３３】
まず、ステップＳ２５において、調べるべきサーバ（サーバＡとする）のサーバ情報を取得する。ここで取得するサーバ情報の例が図６右上に示されている。そして、ステップＳ２６において、リクエストが実行可能か否かを判断する。今の場合、図６の右上のサーバ情報によれば、実行不可能となる。なぜなら、現在の負荷が５０であり、リクエストを実行することによって負荷が５増えるので、上位レベルの品質を保持するのに必要な負荷の限界が５０であるので、リクエストを受け付けると、上位レベルの品質を保持できなくなってしまうからである。従って、不可能な場合には、ステップＳ２８に進む。可能な場合には、ステップＳ２７において、実行可能なサーバとして情報をストック（記憶）し、すでに実行可能なサーバを記憶していた場合には、サーバ負荷の余裕（閾値との差）が大きい方を記憶して、ステップＳ２８に進む。
【００３４】
ステップＳ２８においては、上位レベルの全てのサーバに対し判定を行ったか否かを判断し、ＮＯの場合には、ステップＳ２５に戻り、ＹＥＳの場合には、ステップＳ２９に進む。ステップＳ２９においては、実行可能なサーバが存在するか否かを判断し、存在する場合には、ステップＳ３０において、実行可能なサーバの内、最も負荷の低いサーバに割り振り、存在しない場合には、ステップＳ３１において、上位レベルグループには実行可能なサーバが存在しないと判断する。
【００３５】
図７は、図５のステップＳ１９を詳細に示したフローチャートである。
ここでは、中間サーバＦをレベルアップさせるものとする。
まず、ステップＳ３５において、サービス管理サーバのサービスサーバ情報の内、サーバＦの所属グループ情報を書き換え、それに伴って処理リクエストレベルなどの情報も書き換える。図７の右上に記載されている例では、実行すべきリクエストのレベルReqLV が下位から上位に書き換えられている。また、維持すべき品質は上位のままである。次に、ステップＳ３６において、サービス管理サーバは、サービスサーバＦ（中間サーバ）にレベルアップを通知する。そして、ステップＳ３７において、サービスサーバＦは、自分の有するサーバ情報を書き換える。すなわち、図７の右下に記載されているように、ReqLV を下位から上位に書き換える。
【００３６】
次に、各サービスサーバの負荷を自動計測する実施形態について説明する。
各サービスサーバでのサービスの品質を維持していくためには、実行する各サービスの重さ（負荷値）を正しく把握しておく必要がある。しかし、サービスの実行にかかる負荷は実行するサービスサーバの能力や状態にも依存するため、静的な方法で定義した場合、正確さにかけるという問題がある。しかし、新しいサービスをインストールするたびに手動で計測を行うのは管理者の負担になるだけでなく、運用に支障を来す可能性がある。そこで、サービスの運用を行いながら自動的にサービスを実行する際の負荷を計測するようにする。
【００３７】
このようにサービスの運用を行いながらサービスを実行するための負荷を計測することによって、
・環境の変化が生じてもサービスの負荷をリアルタイムで計測、修正することによって常に正確な情報を把握することができる。その結果、的確なリクエストの分配が可能になり、ＳＬＡを守りやすくなる、
・新しいサービスをインストールした場合でも負荷計測のためにサービスを停止させる必要がない、
という利点が得られる。
【００３８】
図８は、サービス負荷の自動計測処理の流れを示す図である。
まず、ステップＳ４０において、サービス管理サーバからリクエストの割り振り先を決定し、リクエストをサービスサーバに送信する。サービスサーバでは、ステップＳ４１において、リクエストを受信し、ステップＳ４２において、実行中の処理はあるか否かが判断される。実行中の処理がある場合には、ステップＳ４３に進み、リクエストを普通に実行する。ステップＳ４２において、実行中の処理がないと判断された場合には、ステップＳ４４に進んで、リクエストを実行し、処理にかかった時間を計測する。そして、ステップＳ４５において、計測した時間を元に、その処理の負荷値を計算して、ステップＳ４６に進む。ステップＳ４６においては、今回の計測した負荷値とこれまでの負荷値の間を取るなどして、新しい負荷値を算出する。そして、ステップＳ４７において、サービス管理サーバに新しい負荷値を通知する。サービス管理サーバでは、ステップＳ４８において、該当サーバのサービスの負荷情報を更新する。
【００３９】
図９は、サービス負荷の自動計測処理を具体的に示すフローチャートである。
図９左に示す概略フローでは、まず、サービス管理サーバからサービスサーバＡにリクエストが渡され、サービスサーバにおいて、要求されたサービスＸを実行し、実行結果をサービス管理サーバを介してクライアントに返す処理からなっている。これらの内、要求されたサービスＸを実行するステップにおいて、負荷計測が行われるが、これを詳細に示したのが、図９右のフローである。
【００４０】
まず、ステップＳ５０において、サービスサーバは、実行中の処理はあるか否かについて判断を行う。今の場合、サービスサーバは、自分の情報（サービスサーバＡの情報）の内、runningService＝｛X,X,Y ｝という情報を参照する。今の場合には、実行中のサービスがあるので、ステップＳ５１に進み、要求されたサービスＸを実行する。ここで、実行中のサービスがない場合には、ステップＳ５２に進み、要求されたサービスＸを実行し、処理にかかる時間を計測する。そして、ステップＳ５３において、処理にかっかった時間を元に、そのサービスＸの負荷値を計算する。負荷値としては、処理にかかった時間をそのまま用いても良いし、サービスを実行する際のＣＰＵ等の占有時間などを用いても良い。
【００４１】
そして、ステップＳ５４において、計測によって得られた負荷値を元にそのサービスＸの負荷値を更新する。ステップＳ５５では、更新されたサービスＸの負荷値をサービス管理サーバに通知し、サービス管理サーバが管理しているサーバ情報の中のサービス負荷値を更新する。
【００４２】
ここで、ステップＳ５４とＳ５６の更新の様子が図９右端に図示されている。すなわち、サービスサーバＡがローカルに持っているサーバ情報のサービスＸの負荷値serviceX＝５をserviceX＝６に（今の場合、負荷値の計測の結果、６という負荷値が得られたとする）、サービス管理サーバが持っているサービスサーバＡの情報の負荷値serviceX＝５もserviceX＝６に変更する。
【００４３】
上記実施形態の場合、各グループのサービスサーバの台数が固定されている場合には、中間サーバだけでは処理しきれないリクエストの偏りが生じる可能性がある。したがって、これを解消する必要がある。具体的には、リクエストのログを解析して、曜日や日にちに依存したリクエストの偏りを見つけだし、それを元にサービスサーバの運用スケジュールを設定して、自動的にサーバのグループ分けを行うようにする。
【００４４】
図１０は、サービスサーバの運用スケジュールを設定する実施形態の概念を示す図である。
ここで、中間サーバの取り扱いについては任意性があるが、以下の説明では中間サーバの台数は固定とし、上位、下位レベルのサーバのみを変更するものとして説明を行う。
【００４５】
例えば、過去のリクエスト数の比率から、月曜日には上位レベルのリクエスト数の比率が大きく、火曜日には、上位レベルと下位レベルの比率が同じ程度であると判断されたとすると、月曜日には、上位レベルのサービスサーバの台数を多くし、下位レベルのサービスサーバの台数を少なく設定する。また、火曜日には、上位レベルと下位レベルのサービスサーバの数を同程度に設定する。しかしながら、上位、下位レベルのサーバ台数を決定する際には中間サーバの存在も考慮しなくてはならず、従って、火曜日にはリクエスト数が上位と下位とで同数だとしても上位と下位のサーバ台数を同数にすれば良いと言うわけではない。
【００４６】
前述の実施形態の場合、サービスサーバのグループ分けは静的な方法のみで行われており、管理者が手動で調整するしかなかったが、その結果リクエストの偏りがそのまま負荷の偏りを生じさせ、パフォーマンスの低下を招く可能性がある。しかし、上記実施形態によれば、過去のリクエスト数を元にサーバ構成のスケジュールを立てるので、曜日や特定日に依存したリクエストの偏りに対応でき、リクエスト数に最適化されたサービスサーバ数を各グループに配することによって、中間サーバのレベルアップ、ダウン回数が減り、サービス管理サーバの負荷軽減につながる。また、スケジュールに従って自動的にサービスサーバの構成を変更させるので、管理者の負担や人為的なミスを減らすだけでなく、サーバの構成変更にかかる時間も短縮化できるという利点がある。
【００４７】
図１１は、スケジュールの設定処理の概略フローを示す図である。
まず、ステップＳ６０において、リクエストのログを取得する。そして、ステップＳ６１において、リクエストの比率を解析して、サービスサーバ台数の構成のスケジュールを立てる。ここで、リクエスト比率からサーバの台数構成を算出するのは運用環境や設定の細かさ（リクエスト毎に行うのか、単にレベルのみで判断するかなど）によって計算方法が変わるが、基本的にはリクエスト数が多いレベルに多くのサーバを割り当てる用にする。詳細については、本発明を利用する当業者によって適宜決定されるべきことである。
【００４８】
ステップＳ６２においては、システムの立てたスケジュールを管理者が修正し、ステップＳ６３において、スケジュールを設定する。ステップＳ６２の管理者がスケジュールを修正する処理は任意であり、スケジュールの作成から運用まで、全て自動で行うこともできるが、作成されたスケジュールを管理者が修正することも可能であるという意味である。
【００４９】
図１２は、スケジュール設定処理のより具体的なフローチャートである。
まず、ステップＳ７０において、スケジュール作成システムの起動を行う。そして、ステップＳ７１において、サービス管理サーバのログ管理手段で記録したリクエストの処理経過である、リクエストログを取得する。リクエストログとは、図１２右の（１）に示されているような記録である。そして、ステップＳ７２において、ログを優先順位にしたがって解析し、サーバ構成のスケジュールを作成する。すなわち、図１２右の（１）のログ管理手段の情報と（２）のサービス管理サーバの情報とを参照し、図１２右の（３）に示すようなスケジュールを作成する。次に、必要で有れば、ステップＳ７３に進んで、管理者が作成されたスケジュールを修正し、ステップＳ７４において、スケジュールを設定する。すなわち、図１２右の（３）のスケジュールをサービス管理サーバに保存する。
【００５０】
図１３は、スケジュールに基づいてサービスサーバの構成を変更する際の処理を示すフローチャートである。
まず、ステップＳ８０において、定義されたタイミングでサービスサーバ構成変更システムを起動する。このとき、サービス管理サーバの情報であるchangeTime＝午前３：００などの情報を参照する。今の場合、午前３時にサービスサーバの構成変更を行う旨が定義されている。次に、ステップＳ８１において、サービス管理サーバ内の変更を行うサービスサーバの所属グループの情報を更新する。すなわち、図１３右の（１）の情報を参照し、図１３右の（２）のサービス管理サーバ内の該当サービスサーバの情報を更新する。そして、ステップＳ８２において、変更を行ったサービスサーバに変更通知を行う。ステップＳ８３においては、通知を受けたサービスサーバは、図１３右の（３）のサービスサーバの情報の内、所属グループの情報を変更する。また、このとき、所属グループが行うべきリクエスト受付のレベル及び維持すべき品質のレベルの設定も所属グループの設定に合わせて変更する。そして、ステップＳ８４において、全ての変更が終わったか否かを判断し、全ての変更が終わっていない場合にはステップＳ８１に戻って変更処理を繰り返し、全ての変更が終わった場合には、処理を終了する。
【００５１】
次に、図１２のステップＳ７２について詳細に説明する。
スケジュールの作成に際しては、基本的にサービスサーバの台数は集計したリクエストの比率の従ってサービスサーバを各レベルに配分して決定する。
【００５２】
例えば、サービスサーバが全部で７台あり、うち中間サーバが２台あるとする。ログを集計した結果、ある曜日の平均リクエスト数が
上位レベル：２００リクエスト
下位レベル：１００リクエスト
だったとする。
【００５３】
リクエスト数の比率は上位：下位＝２：１であるから、中間サーバを除いた５台のサービスサーバを２：１の比率で配分することによってサーバ台数が決定される。よって、この場合、各レベルのサービスサーバの台数は次のように決定される。
上位レベル：５×（２／３）＝３．３３３→３台
下位レベル：５×（１／３）＝１．６６６→２台
次に、中間サーバの存在を考慮する。すなわち、中間サーバは通常下位レベルのリクエストを実行しているため、中間サーバのことを考慮しないと下位レベルにサーバを多く割り当て過ぎることになる。
【００５４】
例えば、上記の例では、上位レベルに３台、下位レベルに２台のサービスサーバを割り当てたが、中間サーバの台数が２台だったので、通常時上位レベルのリクエストを実行するのが３台だけなのに対して、下位レベルのリクエストを実行するのは下位レベルのサーバと中間サーバの合わせて４台になってしまう。従って、中間サーバは下位レベルに含まれるものとして考える必要がある。
【００５５】
例えば、上記例では、リクエスト数の比率は上位：下位＝２：１であったので、中間サーバも含めた７台のサービスサーバを２：１の比率で分配する。各レベルのサーバの台数は次のように決定される。
上位レベル：７×（２／３）＝４．６６→５台
下位レベル：７×（１／３）＝２．３３→２台
中間サーバ２台は下位レベルに含まれるものと考えるので、下位レベルに割り当てるのは中間サーバ分の台数を除いた
２−２＝０台
となる。しかし、各レベルに最低１台はサービスサーバが存在しないと不都合が生じてしまう（例えば、中間サーバが全てレベルアップすると下位レベルのリクエストを処理するサーバが無くなってしまう）。よって、サーバ構成は、次のようになる。
上位：４台下位：１台中間サーバ：２台
上記の例では、単純にリクエスト数の比率のみを考慮した例を示したが、サービス毎に処理の重さ（負荷値）が異なる場合、それを考慮する必要がある。
【００５６】
例えば、サービスＸとサービスＹがあり、それぞれの負荷値が
サービスＸ＝５、サービスＹ＝１０
であるとする。
【００５７】
例えば、リクエストのサービス毎の内訳が次のようだとする。
上位レベル：リクエスト総数＝２００（サービスＸ＝１００、サービスＹ＝１００）
下位レベル：リクエスト総数＝１００（サービスＸ＝２０、サービスＹ＝８０）
この場合、リクエスト数の比率は
上位：下位＝２：１
であるが、負荷値の合計はそれぞれ
上位：１００×５＋１００×１０＝１５００
下位：２０×５＋８０×１０＝９００
であり、負荷値の比率は
上位：下位＝５：３
となる。
【００５８】
サービスサーバへの負担の量を正確に表しているのはリクエスト数ではなく、負荷値の量であるため、サービスサーバの台数を設定する際も、負荷値の合計比率を使うのが好ましい。
【００５９】
そこで、負荷値の合計の比率を用いて計算し直してみると、負荷値合計の比率は
上位：下位＝５：３
である。この比率に従って７台のサービスサーバを分けると
上位：７×（５／８）＝４．３７→４台
下位：７×（３／８）＝２．６２→３台
中間サーバ分を下位レベルから除くと
上位：４台
下位：１台
中間サーバ：２台
と決定される。
【００６０】
以上がスケジュール設定の基本的な方法であるが、サーバの性能の違いなどを考慮しなくてはならない事項が他にもあるため、実際に運用する際にはもっと細かな計算が必要とされる。しかし、基本的な方法は上記の通りリクエストの比率を元にサーバ台数を割り振ると言うやり方には変わりはない。
【００６１】
また、スケジュール設定の優先順位を考慮することも可能である。すなわち、サービスサーバ構成のスケジュールを立てる際に優先順位（Priority）を参照する。例えば、優先順位１位（Priority1 ）が曜日で２位（Priority2 ）が日にちの場合、曜日別にスケジュールを立て、特に偏りの顕著な日にちのみ別に構成を設定する。
【００６２】
また、スケジュールはサービス管理サーバ内のサーバ情報格納手段で保管され、構成の自動変更時に参照される。
図１４は、本発明の実施形態のシステムブロック図である。
【００６３】
サービス管理サーバは、サービス管理手段３０、スケジュール管理手段３１、待機管理手段３２、サーバ情報格納手段３３、及びログ管理手段３４からなっている。
【００６４】
また、サービスサーバグループの各サービスサーバ３６は、負荷計測手段３５を備えている。
サービス管理手段３０は、リクエストを受信して分配先を決定し、サービスサーバのレベルアップ（ダウン）処理を行う。サーバ情報格納手段３３は、システム全体の情報を管理しており、サービス管理サーバで管理されるデータの全てが保管されている。待機管理手段３２は、混雑時に分配不能なリクエストを保管し、サービスサーバの負荷が下がり次第、サービスサーバにリクエストを送信する機能である。スケジュール管理手段３１は、サービスサーバ構成のスケジュールを設定管理する。ログ管理手段３４は、リクエストのログを格納する。また、サービスサーバの負荷計測手段３５は、自分のサービスサーバの負荷状態を監視し、定期的に監視結果をサーバ情報格納手段３３へ送信する。また、サービスサーバで管理するデータを格納している。
【００６５】
受信したリクエストをサービスサーバへ送信する処理を行う場合、１−１に示すように、ＳＬＡ情報を含むリクエストを受信し、１−２に示すように、サーバ情報格納手段３３からサーバ情報を取得し、１−３で該当リクエストの分配先を決定する。そして、１−４でリクエストを実行可能な場合、最も負荷が低いサービスサーバ３６にリクエストを送信する。また、１−５のように、リクエストが実行不可能の場合（ＳＬＡを維持できない場合）、リクエストを待機管理手段３２に送る。
【００６６】
待機リクエストを送信する処理を行う場合には、２−１で一定間隔でサーバ情報格納手段３３からサーバ情報を取得する。そして、２−２で、実行可能になった時に、サービスサーバ３６にリクエストを送る。
【００６７】
スケジュールを設定する処理を行う場合は、３−１でログ管理手段３４からリクエストのログを取得し、３−２で、スケジュールを設定して、サーバ情報を更新する。
【００６８】
サービスサーバ３６の負荷を計測して通知する処理を行う場合は、４−１に示されるように、サービスサーバ３６の負荷値を計算して、定期的にサーバ情報格納手段３３へ通知する。
【００６９】
図１５は、図１４の各手段が有するデータを示した図である。
サーバ情報格納手段３３は、サーバ識別ＩＤ、閾値、所属グループ、維持する品質レベル、各サービスの負荷値、サーバ性能評価値、サーバ構成変更時間、リクエスト集計優先順、及びサーバ構成スケジュールを有している。
【００７０】
ログ管理手段３４は、リクエスト時間、サービスレベル、要求するサービスなどのデータを有する。
サービスサーバ３６の負荷計測手段３５は、実行中の処理内容、及びサーバ情報格納手段３３が有するデータの内自サーバに関するデータを有する。
【００７１】
図１６は、本発明の実施形態に従ったサービス管理サーバあるいはサービスサーバの機能をプログラムで実現する場合に要求される装置のハードウェア環境を説明する図である。
【００７２】
ＣＰＵ４１は、バス４０で接続された記憶装置４７あるいは、記録媒体読み取り装置４８を介して可搬記録媒体４９から当該プログラムを読み込み、同じバス４０を介して接続されたＲＡＭ４３にコピーして実行する。ＣＰＵ４１にバス４０を介して接続されるＲＯＭ４２には、ＢＩＯＳなどの基本プログラムが格納されるが、本発明の実施形態を実現するプログラムを格納してもよい。
【００７３】
入出力装置５０は、バス４０を介してＣＰＵ４１に接続され、ＣＰＵ４１の演算結果を装置のユーザに提示したり、ユーザからの指示をＣＰＵ４１に伝えるために使用され、例えば、キーボード、マウス、タブレット、ディスプレイなどからなる。
【００７４】
通信インターフェース４４は、ネットワーク４５を介して図１６の装置が情報提供者４６と通信するために使用される。本発明の実施形態を実現するプログラムを情報提供者４６からダウンロードし、ＣＰＵ４１が実行しても良いし、ネットワーク環境下で、当該プログラムを実行することも可能である。また、通信インターフェース４４を介して、サービス管理サーバとサービスサーバとが通信したり、ウェブサーバと通信することも可能である。
【００７５】
（付記１）情報装置に、ネットワークを介してクライアントからのサービス要求に応じたサービスを提供するサービスサーバを複数収容し、該複数のサービスサーバにサービス要求を配分するサービス管理方法を実現させるプログラムにおいて、
該複数のサービスサーバを、提供するサービスの品質レベル毎の複数のグループのサービスサーバと、該グループ間を移行して、移行先のグループのサービス品質でサービスを提供する中間サーバグループのサービスサーバとにグループ化して管理する管理ステップと、
いずれかのグループのサービスサーバの負荷が増加し、そのグループが提供すべき品質レベルを維持できなくなる場合に、該中間サーバグループの最も負荷が低いサービスサーバを少なくとも１つ、該グループのサービスサーバとして使用して、該グループのサービスサーバの負荷の低減を図る中間サーバ移行ステップと、
を備えることを特徴とするサービス管理方法を情報装置に実現させるプログラム。
【００７６】
（付記２）前記管理ステップは、
前記グループ化されたサービスサーバが、どのグループに属するかの情報を格納する格納手段を更に備えることを特徴とする付記１に記載のプログラム。
【００７７】
（付記３）前記サービスの品質は、前記サービスサーバの応答時間であることを特徴とする付記１に記載のプログラム。
（付記４）前記サービス要求の履歴を記録するログ管理ステップと、
該ログ管理手段の記録に基づいて、日にちあるいは曜日毎にスケジュールを作成し、作成したスケジュールに従って前記グループ分けの仕方を変更するスケジュール管理ステップと、
を更に備えることを特徴とする付記１に記載のプログラム。
【００７８】
（付記５）前記各サービスサーバは、自サーバがサービス要求を処理するために必要とする負荷値を計測する負荷計測ステップを有し、
該負荷計測ステップから報告される各サービスサーバの負荷値に基づいて、前記中間サーバグループのサービスサーバを別のグループに移行させることを特徴とする付記１に記載のプログラム。
【００７９】
（付記６）ネットワークを介してクライアントからのサービス要求に応じたサービスを提供するサービスサーバを複数収容し、該複数のサービスサーバにサービス要求を配分するサービス管理方法において、
該複数のサービスサーバを、提供するサービスの品質レベル毎の複数のグループのサービスサーバと、該グループ間を移行して、移行先のグループのサービス品質でサービスを提供する中間サーバグループのサービスサーバとにグループ化して管理する管理ステップと、
いずれかのグループのサービスサーバの負荷が増加し、そのグループが提供すべき品質レベルを維持できなくなる場合に、該中間サーバグループのサービスサーバを少なくとも１つ、該グループのサービスサーバとして使用して、該グループのサービスサーバの負荷の低減を図る中間サーバ移行ステップと、
を備えることを特徴とするサービス管理方法。
【００８０】
（付記７）ネットワークを介してクライアントからのサービス要求に応じたサービスを提供するサービスサーバを複数収容し、該複数のサービスサーバにサービス要求を配分するサービス管理方法を情報装置に実行させるプログラムにおいて、該サービス管理方法は、
該複数のサービスサーバを、提供するサービスの品質レベル毎の複数のグループのサービスサーバと、該グループ間を移行して、移行先のグループのサービス品質でサービスを提供する中間サーバグループのサービスサーバとにグループ化して管理する管理ステップと、
いずれかのグループのサービスサーバの負荷が増加し、そのグループが提供すべき品質レベルを維持できなくなる場合に、該中間サーバグループのサービスサーバを少なくとも１つ、該グループのサービスサーバとして使用して、該グループのサービスサーバの負荷の低減を図る中間サーバ移行ステップと、
を備えることを特徴とするプログラム。
【００８１】
（付記８）ネットワークを介してクライアントからのサービス要求に応じたサービスを提供するサービスサーバを複数収容し、該複数のサービスサーバにサービス要求を配分するサービス管理方法を情報装置に実行させるプログラムを格納した、情報装置読み取り可能な記録媒体において、該サービス管理方法は、
該複数のサービスサーバを、提供するサービスの品質レベル毎の複数のグループのサービスサーバと、該グループ間を移行して、移行先のグループのサービス品質でサービスを提供する中間サーバグループのサービスサーバとにグループ化して管理する管理ステップと、
いずれかのグループのサービスサーバの負荷が増加し、そのグループが提供すべき品質レベルを維持できなくなる場合に、該中間サーバグループのサービスサーバを少なくとも１つ、該グループのサービスサーバとして使用して、該グループのサービスサーバの負荷の低減を図る中間サーバ移行ステップと、
を備えることを特徴とする記録媒体。
【００８２】
（付記９）ネットワークを介してクライアントからのサービス要求に応じたサービスを提供するサービスサーバを複数収容し、該複数のサービスサーバにサービス要求を配分するサービス管理装置において、
該複数のサービスサーバを、提供するサービスの品質レベル毎の複数のグループのサービスサーバと、該グループ間を移行して、移行先のグループのサービス品質でサービスを提供する中間サーバグループのサービスサーバとにグループ化して管理する管理手段と、
いずれかのグループのサービスサーバの負荷が増加し、そのグループが提供すべき品質レベルを維持できなくなる場合に、該中間サーバグループの最も負荷が低いサービスサーバを少なくとも１つ、該グループのサービスサーバとして使用して、該グループのサービスサーバの負荷の低減を図る中間サーバ移行手段と、を備えることを特徴とするサービス管理装置。
【００８３】
【発明の効果】
本発明によれば、サービスを行うサービスサーバ間の負荷の差を適切に均等化しつつ、サービスの品質を維持したサービスの提供を行うためのサービス管理装置を提供することが出来る。
【図面の簡単な説明】
【図１】本発明の実施形態の概略を示す図である。
【図２】本発明の実施形態が適用されるシステムの構成図である。
【図３】中間グループのサービスサーバ（中間サーバ）の状態変化を示す図である。
【図４】サービス管理サーバの処理の概略を示す図である。
【図５】サービス管理サーバの処理の詳細を示すフローチャートである。
【図６】図５のステップＳ１３、Ｓ１４の詳細を示すフローチャートである。
【図７】図５のステップＳ１９を詳細に示したフローチャートである。
【図８】サービス負荷の自動計測処理の流れを示す図である。
【図９】サービス負荷の自動計測処理を具体的に示すフローチャートである。
【図１０】サービスサーバの運用スケジュールを設定する実施形態の概念を示す図である。
【図１１】スケジュールの設定処理の概略フローを示す図である。
【図１２】スケジュール設定処理のより具体的なフローチャートである。
【図１３】スケジュールに基づいてサービスサーバの構成を変更する際の処理を示すフローチャートである。
【図１４】本発明の実施形態のシステムブロック図である。
【図１５】図１４の各手段が有するデータを示した図である。
【図１６】本発明の実施形態に従ったサービス管理サーバあるいはサービスサーバの機能をプログラムで実現する場合に要求される装置のハードウェア環境を説明する図である。
【図１７】ＡＳＰサービスを提供するシステムの概略構成図である。
【図１８】ＳＬＡにおけるサービス管理サーバのサービス管理方法の従来技術を説明する図である。
【図１９】従来の問題点を説明する図である。
【符号の説明】
２０インターネット
２１ファイアウォール
２２ウェブサーバ
２３サーブレットエンジン
２４サービス管理サーバ
２５−１〜２５−ｎサービスサーバ
２６データベースサーバ
３０サービス管理手段
３１スケジュール管理手段
３２待機管理手段
３３サーバ情報格納手段
３４ログ管理手段
３５負荷計測手段
３６サービスサーバ

Claims

情報装置に、ネットワークを介してクライアントからのサービス要求に応じたサービスを提供するサービスサーバを複数収容し、該複数のサービスサーバにサービス要求を配分するサービス管理方法を実現させるプログラムにおいて、
該複数のサービスサーバを、高いサービス品質のリクエストを処理するサービスサーバからなる上位レベルのサーバグループと、低いサービス品質のリクエストを処理するサービスサーバからなる下位レベルのサーバグループと、通常時は、低いサービス品質のリクエストを高いサービス品質で提供し、上位レベルのサーバグループの処理負荷が、予期した品質でサービスを提供できない程度に大きくなった場合に、上位レベルのサーバグループに移行して、高いサービス品質でサービスを提供する中間サーバグループのサービスサーバとにグループ化して管理する管理ステップと、
上位レベルのサーバグループのサービスサーバの負荷が増加し、そのグループが提供すべき品質レベルを維持できなくなる場合に、該中間サーバグループの最も負荷が低いサービスサーバを少なくとも１つ、該上位レベルのサーバグループのサービスサーバとして使用して、該グループのサービスサーバの負荷の低減を図る中間サーバ移行ステップと、
該各サービスサーバが、自サーバがサービス要求を処理するために必要とする負荷値を計測する負荷計測ステップとを有し、
該負荷計測ステップで計測される各サービスサーバの負荷値に基づいて、前記中間サーバグループのサービスサーバを別のグループに移行させるサービス管理方法を情報装置に実現させることを特徴とするプログラム。
前記管理ステップは、前記グループ化されたサービスサーバが、どのグループに属するかの情報を格納する格納手段を更に備えることを特徴とする請求項１に記載のプログラム。
前記サービスの品質は、前記サービスサーバの応答時間であることを特徴とする請求項１に記載のプログラム。
前記サービス要求の履歴を記録するログ管理ステップと、該ログ管理ステップの記録に基づいて、日にちあるいは曜日毎にスケジュールを作成し、作成したスケジュールに従って自動で前記グループ分けの仕方を変更させるスケジュール管理ステップと、を更に備えることを特徴とする請求項１に記載のプログラム。