JP2002251344A

JP2002251344A - サービス管理装置

Info

Publication number: JP2002251344A
Application number: JP2001046516A
Authority: JP
Inventors: Takeshi Ishida; 武石田; Kyokai In; 京海尹; Minoru Yamamoto; 実山本
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2001-02-22
Filing date: 2001-02-22
Publication date: 2002-09-06
Anticipated expiration: 2021-02-22
Also published as: US7543060B2; US20020116479A1; JP4230673B2

Abstract

(57)【要約】【課題】サービスの品質を維持しつつ、サーバの負荷を
適切に分散することの出来るサービス管理装置を提供す
る。【解決手段】インターネットに接続されたウェブサーバ
を介してクライアントからサービス要求を受け付け、サ
ービスを提供するサービスサーバが複数台、サービス要
求を振り分けるサービス管理サーバに接続された構成を
有している。サービスサーバは、提供するサービスの品
質に応じて複数のレベルにグループ化される。更に、こ
れらのレベルの他に中間サーバと呼ばれるサービス提供
品質レベルを可変とするサービスサーバを設ける。サー
ビス管理サーバは、何れかのレベルのグループのサービ
スサーバの負荷が大きくなると、中間サーバをそのグル
ープのサーバとして使用することによって、そのグルー
プの負荷を軽減する。これにより、負荷をグループ間で
均一にしつつ、品質の維持を図る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、サービスを提供す
るサービスサーバにサービス要求を分配するサービス管
理装置に関する。

【０００２】

【従来の技術】今日、インターネットの普及により、イ
ンターネット上での様々なビジネスが展開されつつあ
る。中でも、インターネットを介して、ユーザに様々な
アプリケーションサービスを提供するＡＳＰ（Applicat
ion Service Provider）サービスが実用化されてい
る。

【０００３】図１７は、ＡＳＰサービスを提供するシス
テムの概略構成図である。サービスを行う複数のサービ
スサーバ１０は、サービス要求のサービスサーバ１０へ
の分配などの管理を行うサービス管理サーバ１１に接続
され、サービス管理サーバ１１を介して、クライアント
１４からのサービス要求を受け付ける。また、サービス
管理サーバ１１は、ウェブサーバ１２に接続され、クラ
イアント１４からのサービス要求をインターネット１５
経由で受け付けるよう構成される。

【０００４】このような、ウェブサーバ１２、サービス
管理サーバ１１、及びサービスサーバ１０からなるシス
テムは、データセンタ１３と呼ばれ、様々なプロバイダ
からのアプリケーションの提供サービスをまとめて管理
する。

【０００５】ところで、最近では、アプリケーションの
提供サービスにおいて、受け付けたサービス要求を単に
サービスサーバ１０に割り振って、サービスを提供する
だけでなく、サービスの提供品質を契約によって補償し
つつ、アプリケーション提供サービスをクライアント１
４に提供するというＳＬＡ（Service Level Agreem
ent ：サービスの品質を保証する契約）を実現しようと
している。

【０００６】図１８は、ＳＬＡにおけるサービス管理サ
ーバのサービス管理方法の従来技術を説明する図であ
る。ＳＬＡにおいて補償されるサービスの品質として
は、サービスサーバの応答速度、障害復旧時間、障害発
生時の補償などが挙げられるが、以下の説明において
は、サービスの品質としてサービスサーバの応答速度を
念頭に置いて説明する。

【０００７】従来のＳＬＡの実現方法の一つとしては、
図１８（ａ）に示されるような、提供するサービスの品
質毎にサービスサーバをグループ分けする方法がある。
この場合、サービスサーバは、高品質のサービスを提供
するサーバと、一般レベルのサービスを提供するサーバ
などのグループに分けられ、それぞれのグループ内で
は、定められたサービスの品質を維持しつつサービスの
提供を行うように構成される。サービス管理サーバは、
サービス要求の品質契約内容に従って、受信したサービ
ス要求をどのグループのサービスサーバに割り振るかを
決定して、サービス要求（リクエスト）を送信する。

【０００８】このような場合、それぞれのグループで品
質を統一して維持することは容易であるが、リクエスト
が一部のレベルに集中した場合、サーバ間の負荷の格差
が大きくなり、全てのサーバ資源を有効に活用できない
と言う問題が生じる。すなわち、サービス品質がサービ
スサーバの応答速度である場合、高品質のサービスを提
供するサービスサーバは、クライアントからのサービス
要求に対して高速に応答する必要があるので、高品質サ
ービスサーバには、大きな負荷がかからないようにサー
ビス要求を割り振る必要がある。このようにすれば、高
品質サービスサーバは、常時高品質のサービスを提供す
ることができるので、サービス品質の管理は行いやす
い。しかし、上記したように、サービス品質レベル毎に
サービスサーバがグループ分けされているので、一部の
グループにサービス要求が集中しても、サービス要求の
処理はグループ内で行わなければならず、グループ間で
の負荷の格差、すなわち、サーバ資源の無駄が生じる。

【０００９】また、従来のＳＬＡの実現方法の他の方法
としては、図１８（ｂ）に記載されているように、全て
のサービスサーバが全ての品質レベルのサービスを処理
するという方法がある。この場合、各サービスサーバ
は、高品質契約のサービス要求（リクエスト）を優先的
に処理すると共に、一般レベル契約のリクエストも受付
け、処理しなければならない。このとき、サービス管理
サーバは、リクエストの品質契約内容を知る必要はな
く、各サービスサーバの負荷が出来るだけ均等になるよ
うに、各リクエストを各サービスサーバに割り振る処理
を行う。

【００１０】従って、各サービスサーバは、リクエスト
が高品質契約のものか、一般レベルのものかを判断し、
判断結果によって処理の優先度を変えて処理するという
手続きを行わなければならない。これを実現するために
は、サービスサーバに複雑なロジックからなるプログラ
ムを実装しなければならない。

【００１１】このような場合、全てのサーバ資源を均等
に使用でき、負荷分散は行いやすいが、ロジックが複雑
になる上に、品質を正確に維持することが困難になると
いう問題点がある。また、運用中のＡＳＰサービスにこ
の方式を導入しようとすると、個々のアプリケーション
サービスを根本的に作り直す必要があるため、時間的に
も金銭的にも莫大なコストが必要になる。

【００１２】

【発明が解決しようとする課題】図１９は、従来の問題
点を説明する図である。上記したように、ＳＬＡにおい
て、確実にサービス品質を確保しようとするので有れ
ば、図１８（ｂ）の構成は採用できず、図１８（ａ）の
構成を採用する必要があるが、前述したように、グルー
プ間で負荷の格差が生じ、サーバ資源が有効に使用でき
ないという問題が生じる。

【００１３】本発明の課題は、サービスの品質を維持し
つつ、サーバの負荷を適切に分散することの出来るサー
ビス管理装置を提供することである。

【００１４】

【課題を解決するための手段】本発明のサービス管理装
置は、ネットワークを介してクライアントからのサービ
ス要求に応じたサービスを提供するサービスサーバを複
数収容し、該複数のサービスサーバにサービス要求を配
分するサービス管理装置において、該複数のサービスサ
ーバを、提供するサービスの品質レベル毎の複数のグル
ープのサービスサーバと、該グループ間を移行して、移
行先のグループのサービス品質でサービスを提供する中
間サーバグループのサービスサーバとにグループ化して
管理する管理手段と、いずれかのグループのサービスサ
ーバの負荷が増加し、そのグループが提供すべき品質レ
ベルを維持できなくなる場合に、該中間サーバグループ
の最も負荷の低いサービスサーバを少なくとも１つ、該
グループのサービスサーバとして使用して、該グループ
のサービスサーバの負荷の低減を図る中間サーバ移行手
段とを備えることを特徴とする。

【００１５】本発明によれば、サービスサーバをサービ
スの品質レベル毎にグループ化してサービスを提供する
ので、安定した品質でサービスを提供できる。また、そ
の場合に問題となるグループ間での負荷の偏りを、グル
ープ間を動的に移行可能な中間サーバグループのサービ
スサーバを設け、これを負荷の多いグループへ移行させ
ることにより、解消するので、安定した品質でのサービ
スの提供と、サービスサーバ間の負荷を適切に分散する
ことが出来る。

【００１６】

【発明の実施の形態】図１は、本発明の実施形態の概略
を示す図である。本実施形態の説明においては、クライ
アント（顧客）とのサービス契約において、上位レベル
の品質と下位レベルの品質の契約のみがあるものとす
る。そして、この場合、本実施形態では、上位レベルの
サービスサーバグループと下位レベルのサービスサーバ
グループとを用意すると共に、中間グループのサービス
サーバを用意する。上位レベルグループのサービスサー
バは、上位レベル品質のリクエストを専用に受け付け、
下位レベルグループのサービスサーバは、下位レベル品
質のリクエストを専用に受け付ける。中間グループのサ
ービスサーバは、通常時は、上位レベルの品質で、下位
レベルのリクエストを処理する。すなわち、下位レベル
のリクエストを上位レベルの品質でサービス提供してい
ることになる。

【００１７】そして、例えば、上位レベルグループのサ
ービスサーバにリクエストが集中し、負荷が大きくな
り、品質の維持が難しくなったとすると、中間グループ
のサービスサーバをレベルアップさせ、下位レベルのリ
クエストではなく、上位レベルのリクエストを処理させ
るようにする。

【００１８】この場合、上記のようなリクエストの割り
振りは、サービス管理サーバが一括して行う。図２は、
本発明の実施形態が適用されるシステムの構成図であ
る。

【００１９】クライアント（不図示）は、インターネッ
ト２０を介して、ウェブサーバ２２にリクエストを送信
する。ウェブサーバ２２、サービス管理サーバ２４、サ
ービスサーバ２５−１〜２５−ｎ、及びデータベースサ
ーバ２６からなるデータセンタは、ファイアウォール２
１によって外部からの不正なアクセスに対して防御され
る。真正なクライアントは、このファイアウォール２１
をパスするＩＤなどのアカウントを有しており、これを
使って、ウェブサーバ２２にリクエストを通知する。ウ
ェブサーバ２２では、このリクエストをトリガにして起
動し、後段のサービス管理サーバ２４などに命令を通知
するサーブレットエンジン２３が設けられている。従っ
て、ウェブサーバ２２がクライアントからのリクエスト
を受け取ると、サーブレットエンジン２３が、このリク
エストに基づいた処理を行うべき旨の命令をサービス管
理サーバ２４に通知する。

【００２０】サービス管理サーバ２４は、ウェブサーバ
２２のサーブレットエンジン２３から受け取った命令に
基づいて、リクエストを適切なサービスサーバ２５−１
〜２５−ｎに振り分ける。通常状態では、上位レベルの
リクエストは、上位レベルグループのサービスサーバ
に、下位レベルのリクエストは、中間グループあるい
は、下位レベルグループのサービスサーバに受け渡す。
サービスサーバ２５−１〜２５−ｎは、データベースサ
ーバ２６に格納されている情報から、サービスの提供に
必要なデータを取得し、アプリケーションサービス内容
に変換して、クライアントに送り返す。

【００２１】ここで、図１で説明したような処理をサー
ビス管理サーバが行うためには、上位、下位レベル、中
間グループのサービスサーバを管理するための管理用デ
ータが必要となる。以下は、本実施形態において必要と
する管理用データの一例である。・サービス管理サーバで管理されているデータ −サービスサーバ情報（サービスサーバ１台毎に定義さ
れている） 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＝６に変更す
る。

【００４３】上記実施形態の場合、各グループのサービ
スサーバの台数が固定されている場合には、中間サーバ
だけでは処理しきれないリクエストの偏りが生じる可能
性がある。したがって、これを解消する必要がある。具
体的には、リクエストのログを解析して、曜日や日にち
に依存したリクエストの偏りを見つけだし、それを元に
サービスサーバの運用スケジュールを設定して、自動的
にサーバのグループ分けを行うようにする。

【００４４】図１０は、サービスサーバの運用スケジュ
ールを設定する実施形態の概念を示す図である。ここ
で、中間サーバの取り扱いについては任意性があるが、
以下の説明では中間サーバの台数は固定とし、上位、下
位レベルのサーバのみを変更するものとして説明を行
う。

【００４５】例えば、過去のリクエスト数の比率から、
月曜日には上位レベルのリクエスト数の比率が大きく、
火曜日には、上位レベルと下位レベルの比率が同じ程度
であると判断されたとすると、月曜日には、上位レベル
のサービスサーバの台数を多くし、下位レベルのサービ
スサーバの台数を少なく設定する。また、火曜日には、
上位レベルと下位レベルのサービスサーバの数を同程度
に設定する。しかしながら、上位、下位レベルのサーバ
台数を決定する際には中間サーバの存在も考慮しなくて
はならず、従って、火曜日にはリクエスト数が上位と下
位とで同数だとしても上位と下位のサーバ台数を同数に
すれば良いと言うわけではない。

【００４６】前述の実施形態の場合、サービスサーバの
グループ分けは静的な方法のみで行われており、管理者
が手動で調整するしかなかったが、その結果リクエスト
の偏りがそのまま負荷の偏りを生じさせ、パフォーマン
スの低下を招く可能性がある。しかし、上記実施形態に
よれば、過去のリクエスト数を元にサーバ構成のスケジ
ュールを立てるので、曜日や特定日に依存したリクエス
トの偏りに対応でき、リクエスト数に最適化されたサー
ビスサーバ数を各グループに配することによって、中間
サーバのレベルアップ、ダウン回数が減り、サービス管
理サーバの負荷軽減につながる。また、スケジュールに
従って自動的にサービスサーバの構成を変更させるの
で、管理者の負担や人為的なミスを減らすだけでなく、
サーバの構成変更にかかる時間も短縮化できるという利
点がある。

【００４７】図１１は、スケジュールの設定処理の概略
フローを示す図である。まず、ステップＳ６０におい
て、リクエストのログを取得する。そして、ステップＳ
６１において、リクエストの比率を解析して、サービス
サーバ台数の構成のスケジュールを立てる。ここで、リ
クエスト比率からサーバの台数構成を算出するのは運用
環境や設定の細かさ（リクエスト毎に行うのか、単にレ
ベルのみで判断するかなど）によって計算方法が変わる
が、基本的にはリクエスト数が多いレベルに多くのサー
バを割り当てる用にする。詳細については、本発明を利
用する当業者によって適宜決定されるべきことである。

【００４８】ステップＳ６２においては、システムの立
てたスケジュールを管理者が修正し、ステップＳ６３に
おいて、スケジュールを設定する。ステップＳ６２の管
理者がスケジュールを修正する処理は任意であり、スケ
ジュールの作成から運用まで、全て自動で行うこともで
きるが、作成されたスケジュールを管理者が修正するこ
とも可能であるという意味である。

【００４９】図１２は、スケジュール設定処理のより具
体的なフローチャートである。まず、ステップＳ７０に
おいて、スケジュール作成システムの起動を行う。そし
て、ステップＳ７１において、サービス管理サーバのロ
グ管理手段で記録したリクエストの処理経過である、リ
クエストログを取得する。リクエストログとは、図１２
右の（１）に示されているような記録である。そして、
ステップＳ７２において、ログを優先順位にしたがって
解析し、サーバ構成のスケジュールを作成する。すなわ
ち、図１２右の（１）のログ管理手段の情報と（２）の
サービス管理サーバの情報とを参照し、図１２右の
（３）に示すようなスケジュールを作成する。次に、必
要で有れば、ステップＳ７３に進んで、管理者が作成さ
れたスケジュールを修正し、ステップＳ７４において、
スケジュールを設定する。すなわち、図１２右の（３）
のスケジュールをサービス管理サーバに保存する。

【００５０】図１３は、スケジュールに基づいてサービ
スサーバの構成を変更する際の処理を示すフローチャー
トである。まず、ステップＳ８０において、定義された
タイミングでサービスサーバ構成変更システムを起動す
る。このとき、サービス管理サーバの情報であるchange
Time＝午前３：００などの情報を参照する。今の場合、
午前３時にサービスサーバの構成変更を行う旨が定義さ
れている。次に、ステップＳ８１において、サービス管
理サーバ内の変更を行うサービスサーバの所属グループ
の情報を更新する。すなわち、図１３右の（１）の情報
を参照し、図１３右の（２）のサービス管理サーバ内の
該当サービスサーバの情報を更新する。そして、ステッ
プＳ８２において、変更を行ったサービスサーバに変更
通知を行う。ステップＳ８３においては、通知を受けた
サービスサーバは、図１３右の（３）のサービスサーバ
の情報の内、所属グループの情報を変更する。また、こ
のとき、所属グループが行うべきリクエスト受付のレベ
ル及び維持すべき品質のレベルの設定も所属グループの
設定に合わせて変更する。そして、ステップＳ８４にお
いて、全ての変更が終わったか否かを判断し、全ての変
更が終わっていない場合にはステップＳ８１に戻って変
更処理を繰り返し、全ての変更が終わった場合には、処
理を終了する。

【００５１】次に、図１２のステップＳ７２について詳
細に説明する。スケジュールの作成に際しては、基本的
にサービスサーバの台数は集計したリクエストの比率の
従ってサービスサーバを各レベルに配分して決定する。

【００５２】例えば、サービスサーバが全部で７台あ
り、うち中間サーバが２台あるとする。ログを集計した
結果、ある曜日の平均リクエスト数が上位レベル：２００リクエスト下位レベル：１００リクエストだったとする。

【００５３】リクエスト数の比率は上位：下位＝２：１
であるから、中間サーバを除いた５台のサービスサーバ
を２：１の比率で配分することによってサーバ台数が決
定される。よって、この場合、各レベルのサービスサー
バの台数は次のように決定される。上位レベル：５×（２／３）＝３．３３３→３台下位レベル：５×（１／３）＝１．６６６→２台次に、中間サーバの存在を考慮する。すなわち、中間サ
ーバは通常下位レベルのリクエストを実行しているた
め、中間サーバのことを考慮しないと下位レベルにサー
バを多く割り当て過ぎることになる。

【００５４】例えば、上記の例では、上位レベルに３
台、下位レベルに２台のサービスサーバを割り当てた
が、中間サーバの台数が２台だったので、通常時上位レ
ベルのリクエストを実行するのが３台だけなのに対し
て、下位レベルのリクエストを実行するのは下位レベル
のサーバと中間サーバの合わせて４台になってしまう。
従って、中間サーバは下位レベルに含まれるものとして
考える必要がある。

【００５５】例えば、上記例では、リクエスト数の比率
は上位：下位＝２：１であったので、中間サーバも含め
た７台のサービスサーバを２：１の比率で分配する。各
レベルのサーバの台数は次のように決定される。上位レベル：７×（２／３）＝４．６６→５台下位レベル：７×（１／３）＝２．３３→２台中間サーバ２台は下位レベルに含まれるものと考えるの
で、下位レベルに割り当てるのは中間サーバ分の台数を
除いた２−２＝０台となる。しかし、各レベルに最低１台はサービスサーバ
が存在しないと不都合が生じてしまう（例えば、中間サ
ーバが全てレベルアップすると下位レベルのリクエスト
を処理するサーバが無くなってしまう）。よって、サー
バ構成は、次のようになる。上位：４台下位：１台中間サーバ：２台上記の例では、単純にリクエスト数の比率のみを考慮し
た例を示したが、サービス毎に処理の重さ（負荷値）が
異なる場合、それを考慮する必要がある。

【００５６】例えば、サービスＸとサービスＹがあり、
それぞれの負荷値がサービスＸ＝５、サービスＹ＝１０であるとする。

【００５７】例えば、リクエストのサービス毎の内訳が
次のようだとする。上位レベル：リクエスト総数＝２００（サービスＸ＝１
００、サービスＹ＝１００）下位レベル：リクエスト総数＝１００（サービスＸ＝２
０、サービスＹ＝８０）この場合、リクエスト数の比率は上位：下位＝２：１であるが、負荷値の合計はそれぞれ上位：１００×５＋１００×１０＝１５００下位：２０×５＋８０×１０＝９００であり、負荷値の比率は上位：下位＝５：３となる。

【００５８】サービスサーバへの負担の量を正確に表し
ているのはリクエスト数ではなく、負荷値の量であるた
め、サービスサーバの台数を設定する際も、負荷値の合
計比率を使うのが好ましい。

【００５９】そこで、負荷値の合計の比率を用いて計算
し直してみると、負荷値合計の比率は上位：下位＝５：３である。この比率に従って７台のサービスサーバを分け
ると上位：７×（５／８）＝４．３７→４台下位：７×（３／８）＝２．６２→３台中間サーバ分を下位レベルから除くと上位：４台下位：１台中間サーバ：２台と決定される。

【００６０】以上がスケジュール設定の基本的な方法で
あるが、サーバの性能の違いなどを考慮しなくてはなら
ない事項が他にもあるため、実際に運用する際にはもっ
と細かな計算が必要とされる。しかし、基本的な方法は
上記の通りリクエストの比率を元にサーバ台数を割り振
ると言うやり方には変わりはない。

【００６１】また、スケジュール設定の優先順位を考慮
することも可能である。すなわち、サービスサーバ構成
のスケジュールを立てる際に優先順位（Priority）を参
照する。例えば、優先順位１位（Priority1 ）が曜日で
２位（Priority2 ）が日にちの場合、曜日別にスケジュ
ールを立て、特に偏りの顕著な日にちのみ別に構成を設
定する。

【００６２】また、スケジュールはサービス管理サーバ
内のサーバ情報格納手段で保管され、構成の自動変更時
に参照される。図１４は、本発明の実施形態のシステム
ブロック図である。

【００６３】サービス管理サーバは、サービス管理手段
３０、スケジュール管理手段３１、待機管理手段３２、
サーバ情報格納手段３３、及びログ管理手段３４からな
っている。

【００６４】また、サービスサーバグループの各サービ
スサーバ３６は、負荷計測手段３５を備えている。サー
ビス管理手段３０は、リクエストを受信して分配先を決
定し、サービスサーバのレベルアップ（ダウン）処理を
行う。サーバ情報格納手段３３は、システム全体の情報
を管理しており、サービス管理サーバで管理されるデー
タの全てが保管されている。待機管理手段３２は、混雑
時に分配不能なリクエストを保管し、サービスサーバの
負荷が下がり次第、サービスサーバにリクエストを送信
する機能である。スケジュール管理手段３１は、サービ
スサーバ構成のスケジュールを設定管理する。ログ管理
手段３４は、リクエストのログを格納する。また、サー
ビスサーバの負荷計測手段３５は、自分のサービスサー
バの負荷状態を監視し、定期的に監視結果をサーバ情報
格納手段３３へ送信する。また、サービスサーバで管理
するデータを格納している。

【００６５】受信したリクエストをサービスサーバへ送
信する処理を行う場合、１−１に示すように、ＳＬＡ情
報を含むリクエストを受信し、１−２に示すように、サ
ーバ情報格納手段３３からサーバ情報を取得し、１−３
で該当リクエストの分配先を決定する。そして、１−４
でリクエストを実行可能な場合、最も負荷が低いサービ
スサーバ３６にリクエストを送信する。また、１−５の
ように、リクエストが実行不可能の場合（ＳＬＡを維持
できない場合）、リクエストを待機管理手段３２に送
る。

【００６６】待機リクエストを送信する処理を行う場合
には、２−１で一定間隔でサーバ情報格納手段３３から
サーバ情報を取得する。そして、２−２で、実行可能に
なった時に、サービスサーバ３６にリクエストを送る。

【００６７】スケジュールを設定する処理を行う場合
は、３−１でログ管理手段３４からリクエストのログを
取得し、３−２で、スケジュールを設定して、サーバ情
報を更新する。

【００６８】サービスサーバ３６の負荷を計測して通知
する処理を行う場合は、４−１に示されるように、サー
ビスサーバ３６の負荷値を計算して、定期的にサーバ情
報格納手段３３へ通知する。

【００６９】図１５は、図１４の各手段が有するデータ
を示した図である。サーバ情報格納手段３３は、サーバ
識別ＩＤ、閾値、所属グループ、維持する品質レベル、
各サービスの負荷値、サーバ性能評価値、サーバ構成変
更時間、リクエスト集計優先順、及びサーバ構成スケジ
ュールを有している。

【００７０】ログ管理手段３４は、リクエスト時間、サ
ービスレベル、要求するサービスなどのデータを有す
る。サービスサーバ３６の負荷計測手段３５は、実行中
の処理内容、及びサーバ情報格納手段３３が有するデー
タの内自サーバに関するデータを有する。

【００７１】図１６は、本発明の実施形態に従ったサー
ビス管理サーバあるいはサービスサーバの機能をプログ
ラムで実現する場合に要求される装置のハードウェア環
境を説明する図である。

【００７２】ＣＰＵ４１は、バス４０で接続された記憶
装置４７あるいは、記録媒体読み取り装置４８を介して
可搬記録媒体４９から当該プログラムを読み込み、同じ
バス４０を介して接続されたＲＡＭ４３にコピーして実
行する。ＣＰＵ４１にバス４０を介して接続されるＲＯ
Ｍ４２には、ＢＩＯＳなどの基本プログラムが格納され
るが、本発明の実施形態を実現するプログラムを格納し
てもよい。

【００７３】入出力装置５０は、バス４０を介してＣＰ
Ｕ４１に接続され、ＣＰＵ４１の演算結果を装置のユー
ザに提示したり、ユーザからの指示をＣＰＵ４１に伝え
るために使用され、例えば、キーボード、マウス、タブ
レット、ディスプレイなどからなる。

【００７４】通信インターフェース４４は、ネットワー
ク４５を介して図１６の装置が情報提供者４６と通信す
るために使用される。本発明の実施形態を実現するプロ
グラムを情報提供者４６からダウンロードし、ＣＰＵ４
１が実行しても良いし、ネットワーク環境下で、当該プ
ログラムを実行することも可能である。また、通信イン
ターフェース４４を介して、サービス管理サーバとサー
ビスサーバとが通信したり、ウェブサーバと通信するこ
とも可能である。

【００７５】（付記１）情報装置に、ネットワークを介
してクライアントからのサービス要求に応じたサービス
を提供するサービスサーバを複数収容し、該複数のサー
ビスサーバにサービス要求を配分するサービス管理方法
を実現させるプログラムにおいて、該複数のサービスサ
ーバを、提供するサービスの品質レベル毎の複数のグル
ープのサービスサーバと、該グループ間を移行して、移
行先のグループのサービス品質でサービスを提供する中
間サーバグループのサービスサーバとにグループ化して
管理する管理ステップと、いずれかのグループのサービ
スサーバの負荷が増加し、そのグループが提供すべき品
質レベルを維持できなくなる場合に、該中間サーバグル
ープの最も負荷が低いサービスサーバを少なくとも１
つ、該グループのサービスサーバとして使用して、該グ
ループのサービスサーバの負荷の低減を図る中間サーバ
移行ステップと、を備えることを特徴とするサービス管
理方法を情報装置に実現させるプログラム。

【００７６】（付記２）前記管理ステップは、前記グル
ープ化されたサービスサーバが、どのグループに属する
かの情報を格納する格納手段を更に備えることを特徴と
する付記１に記載のプログラム。

【００７７】（付記３）前記サービスの品質は、前記サ
ービスサーバの応答時間であることを特徴とする付記１
に記載のプログラム。（付記４）前記サービス要求の履歴を記録するログ管理
ステップと、該ログ管理手段の記録に基づいて、日にち
あるいは曜日毎にスケジュールを作成し、作成したスケ
ジュールに従って前記グループ分けの仕方を変更するス
ケジュール管理ステップと、を更に備えることを特徴と
する付記１に記載のプログラム。

【００７８】（付記５）前記各サービスサーバは、自サ
ーバがサービス要求を処理するために必要とする負荷値
を計測する負荷計測ステップを有し、該負荷計測ステッ
プから報告される各サービスサーバの負荷値に基づい
て、前記中間サーバグループのサービスサーバを別のグ
ループに移行させることを特徴とする付記１に記載のプ
ログラム。

【００７９】（付記６）ネットワークを介してクライア
ントからのサービス要求に応じたサービスを提供するサ
ービスサーバを複数収容し、該複数のサービスサーバに
サービス要求を配分するサービス管理方法において、該
複数のサービスサーバを、提供するサービスの品質レベ
ル毎の複数のグループのサービスサーバと、該グループ
間を移行して、移行先のグループのサービス品質でサー
ビスを提供する中間サーバグループのサービスサーバと
にグループ化して管理する管理ステップと、いずれかの
グループのサービスサーバの負荷が増加し、そのグルー
プが提供すべき品質レベルを維持できなくなる場合に、
該中間サーバグループのサービスサーバを少なくとも１
つ、該グループのサービスサーバとして使用して、該グ
ループのサービスサーバの負荷の低減を図る中間サーバ
移行ステップと、を備えることを特徴とするサービス管
理方法。

【００８０】（付記７）ネットワークを介してクライア
ントからのサービス要求に応じたサービスを提供するサ
ービスサーバを複数収容し、該複数のサービスサーバに
サービス要求を配分するサービス管理方法を情報装置に
実行させるプログラムにおいて、該サービス管理方法
は、該複数のサービスサーバを、提供するサービスの品
質レベル毎の複数のグループのサービスサーバと、該グ
ループ間を移行して、移行先のグループのサービス品質
でサービスを提供する中間サーバグループのサービスサ
ーバとにグループ化して管理する管理ステップと、いず
れかのグループのサービスサーバの負荷が増加し、その
グループが提供すべき品質レベルを維持できなくなる場
合に、該中間サーバグループのサービスサーバを少なく
とも１つ、該グループのサービスサーバとして使用し
て、該グループのサービスサーバの負荷の低減を図る中
間サーバ移行ステップと、を備えることを特徴とするプ
ログラム。

【００８１】（付記８）ネットワークを介してクライア
ントからのサービス要求に応じたサービスを提供するサ
ービスサーバを複数収容し、該複数のサービスサーバに
サービス要求を配分するサービス管理方法を情報装置に
実行させるプログラムを格納した、情報装置読み取り可
能な記録媒体において、該サービス管理方法は、該複数
のサービスサーバを、提供するサービスの品質レベル毎
の複数のグループのサービスサーバと、該グループ間を
移行して、移行先のグループのサービス品質でサービス
を提供する中間サーバグループのサービスサーバとにグ
ループ化して管理する管理ステップと、いずれかのグル
ープのサービスサーバの負荷が増加し、そのグループが
提供すべき品質レベルを維持できなくなる場合に、該中
間サーバグループのサービスサーバを少なくとも１つ、
該グループのサービスサーバとして使用して、該グルー
プのサービスサーバの負荷の低減を図る中間サーバ移行
ステップと、を備えることを特徴とする記録媒体。

【００８２】（付記９）ネットワークを介してクライア
ントからのサービス要求に応じたサービスを提供するサ
ービスサーバを複数収容し、該複数のサービスサーバに
サービス要求を配分するサービス管理装置において、該
複数のサービスサーバを、提供するサービスの品質レベ
ル毎の複数のグループのサービスサーバと、該グループ
間を移行して、移行先のグループのサービス品質でサー
ビスを提供する中間サーバグループのサービスサーバと
にグループ化して管理する管理手段と、いずれかのグル
ープのサービスサーバの負荷が増加し、そのグループが
提供すべき品質レベルを維持できなくなる場合に、該中
間サーバグループの最も負荷が低いサービスサーバを少
なくとも１つ、該グループのサービスサーバとして使用
して、該グループのサービスサーバの負荷の低減を図る
中間サーバ移行手段と、を備えることを特徴とするサー
ビス管理装置。

【００８３】

【発明の効果】本発明によれば、サービスを行うサービ
スサーバ間の負荷の差を適切に均等化しつつ、サービス
の品質を維持したサービスの提供を行うためのサービス
管理装置を提供することが出来る。

【図面の簡単な説明】

【図１】本発明の実施形態の概略を示す図である。

【図２】本発明の実施形態が適用されるシステムの構成
図である。

【図３】中間グループのサービスサーバ（中間サーバ）
の状態変化を示す図である。

【図４】サービス管理サーバの処理の概略を示す図であ
る。

【図５】サービス管理サーバの処理の詳細を示すフロー
チャートである。

【図６】図５のステップＳ１３、Ｓ１４の詳細を示すフ
ローチャートである。

【図７】図５のステップＳ１９を詳細に示したフローチ
ャートである。

【図８】サービス負荷の自動計測処理の流れを示す図で
ある。

【図９】サービス負荷の自動計測処理を具体的に示すフ
ローチャートである。

【図１０】サービスサーバの運用スケジュールを設定す
る実施形態の概念を示す図である。

【図１１】スケジュールの設定処理の概略フローを示す
図である。

【図１２】スケジュール設定処理のより具体的なフロー
チャートである。

【図１３】スケジュールに基づいてサービスサーバの構
成を変更する際の処理を示すフローチャートである。

【図１４】本発明の実施形態のシステムブロック図であ
る。

【図１５】図１４の各手段が有するデータを示した図で
ある。

【図１６】本発明の実施形態に従ったサービス管理サー
バあるいはサービスサーバの機能をプログラムで実現す
る場合に要求される装置のハードウェア環境を説明する
図である。

【図１７】ＡＳＰサービスを提供するシステムの概略構
成図である。

【図１８】ＳＬＡにおけるサービス管理サーバのサービ
ス管理方法の従来技術を説明する図である。

【図１９】従来の問題点を説明する図である。

【符号の説明】

２０インターネット２１ファイアウォール２２ウェブサーバ２３サーブレットエンジン２４サービス管理サーバ２５−１〜２５−ｎサービスサーバ２６データベースサーバ３０サービス管理手段３１スケジュール管理手段３２待機管理手段３３サーバ情報格納手段３４ログ管理手段３５負荷計測手段３６サービスサーバ

─────────────────────────────────────────────────────

【手続補正書】

【提出日】平成１３年１０月１６日（２００１．１０．
１６）

【手続補正１】

【補正対象書類名】明細書

【補正対象項目名】００１２

【補正方法】変更

【補正内容】

【００１２】

【発明が解決しようとする課題】図１９は、従来の問題
点を説明する図である。上記したように、ＳＬＡにおい
て、確実にサービス品質を確保しようとするので有れ
ば、図１８（ｂ）より、図１８（ａ）の構成の方がより
簡単で正確に品質を確保できるが、前述したように、グ
ループ間で負荷の格差が生じ、サーバ資源が有効に使用
できないという問題が生じる。

───────────────────────────────────────────────────── フロントページの続き (72)発明者山本実東京都文京区後楽１丁目７番27号株式会社富士通ビジネスシステム内

Claims

【特許請求の範囲】

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