JP2002049602A - 検索システム - Google Patents

Abstract

(57)【要約】 【課題】 特定の検索ホストに検索サーバが集中するこ
とを回避し、検索ホストの負荷が平均化され、全体とし
て検索効率を向上させる検索システムを提供する。 【解決手段】 ディスパッチャをマスタディスパッチャ
１とスレーブディスパッチャ３とに分け、検索サーバ４
の起動をマスタディスパッチャ１からスレーブディスパ
ッチャ３へ依頼することにより、特定の検索ホスト２に
検索サーバ４が集中することを回避する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、検索システムに関
し、より詳細には、ＷＷＷを通じて公開された電子図書
館の検索する際に、複数の検索ホスト間でサーバのプロ
セス数を制御することによって負荷の分散を図るデータ
ベース検索システムに関する。

【０００２】

【従来の技術】ＷＷＷを通じた検索では、クライアント
であるＷＷＷブラウザと検索サーバとの間にコネクショ
ンを保持することはできず、リクエストごとに接続・切
断される。このため、複数のリクエストでひとまとまり
の仕事を行う場合には、同一のクライアントからのひと
まとまりのリクエストをセッションとして識別し、各セ
ッションの情報をリクエスト間で保持する検索方法があ
る。

【０００３】図１１は、従来技術による検索システムの
概要を説明するためのブロック図である。１つの検索サ
ーバ内に複数のセッションの情報を持つ方法として、例
えばアパッチサーバとｍｏｄ＿ｐｅｒｌによる方法があ
る。ＷＷＷサーバソフトウェアＡｐａｃｈｅの文献「Ap
ache::Session - Maintain session state across HTTP
requests ( http://perl.apache.org/guide/modules.h
tml#Apache_Session_Maintain_sessi)」には、同一クラ
イアントからの複数リクエストをセッションとして識別
し、セッションの情報をサーバのメモリ又はファイルに
保持する方法について記載されている。この文献に示さ
れている方法は、１つの検索サーバ５４のメモリ又はフ
ァイルに、各セッション５１の情報５５を保持するもの
である。各々のセッション５１からのリクエストは、ｈ
ｔｔｐｄ（hypertext transfer protocol daemon）５２
により指定されたＣＧＩ５３へ転送される。複数のＣＧ
Ｉ５３は、クライアントから送られてくるセッションＩ
Ｄに対応したセッション情報５５に従って、１つの検索
サーバ５４によってデータベースサーバ５６を介してデ
ータベースにアクセスする。結果として、複数のセッシ
ョンからのリクエストは１つの検索サーバ５４によって
逐次的に処理される。しかし、データベースアプリケー
ションでは検索の中間結果データが大きくなるため、１
セッションにつき１プロセスとなるよう検索サーバを構
成することが望ましい。

【０００４】図１２は、従来技術による他の検索システ
ムの概要を説明するためのブロック図である。図１１で
示した検索システムの改良として、図１２で示した検索
システムでは、セッション６１と検索サーバ６４の対応
を取り、リクエストを振り分けるために、ディスパッチ
ャ６５を置く。ＣＧＩ６３はクライアントから送られて
くるセッションＩＤをディスパッチャ６５に送信する。
ディスパッチャ６５は、セッションＩＤと検索サーバ６
４の対応表を検索し、そのセッション６１に対応する検
索サーバ６４のアドレスをＣＧＩ６３に返信する。この
とき、必要であればディスパッチャ６５が検索サーバ６
４を起動する。

【０００５】さらに、特開平８−２０２７２６号公報に
は、データベースサーバとクライアントの間に中継サー
バを置き、複数のデータベースサーバのうちどれにリク
エストを転送するか決定する「分散データベースシステ
ム及びそのデータ転送方法」が記載されている。主にデ
ータ転送のネットワーク負荷を軽減することを目的とし
ているが、中継サーバではリクエストや検索結果データ
の中継も行わなければならない。

【０００６】また、特開平９−１３８７７６号公報に
は、データベースを共有する複数ホストで構成されるシ
ステムにおいて、自ホストの能力を超えるリクエストを
他ホストに依頼することによって負荷分散を図る「トラ
ンザクション処理の負荷分散方式」が記載されている。

【０００７】特開平９−２５９０９１号公報には、トラ
ンザクション処理を並列に行う複数個のホストにおい
て、各ホストの処理性能によって異なる比率でリクエス
トを分配することにより、負荷分散を図る「トランザク
ション処理のホスト負荷分散方式」が記載されている。
ホスト選択手段を備えているが、セッションという考え
方がない。

【０００８】

【発明が解決しようとする課題】しかしながら、図１２
で示した検索システム及び特開平９−１３８７７６号公
報に記載の発明は、構成上、複数の検索ホストに渡って
検索サーバを分配し、並列処理によってシステム全体の
スループット向上を図らなければならない。また、特開
平８−２０２７２６号公報に記載の発明では、中継サー
バにおいてリクエストや検索結果データの中継も行わな
ければならない。また、特開平９−２５９０９１号公報
に記載の発明では、ホスト選択手段を備えているが、セ
ッションという考え方がない。

【０００９】本発明は、上述のごとき実情に鑑みてなさ
れたものであり、特定の検索ホストに検索サーバが集中
することを回避し、検索ホストの負荷が平均化され、全
体として検索効率を向上させる検索システムを提供する
ことをその目的とする。

【００１０】

【課題を解決するための手段】請求項１の発明は、ＷＷ
Ｗ経由などのように、コネクションをリクエストにまた
がって保持できない通信環境における検索システムであ
って、同一セッションからの複数のリクエストに対し、
１つの検索サーバを起動し、リクエストを対応する検索
サーバに振り分けることにより、セッション内の情報を
リクエスト間で保持する検索システムにおいて、複数の
検索ホストの中から各検索ホストの負荷状況に応じて検
索サーバを起動する検索ホストを選択することを特徴と
したものである。

【００１１】請求項２の発明は、請求項１記載の発明に
おいて、各々の前記検索ホストの負荷状況は、複数の評
価基準の組み合わせを当該検索ホストの負荷評価値とし
て採用したものであることを特徴としたものである。

【００１２】請求項３の発明は、請求項２記載の発明に
おいて、前記組み合わせには加重和を使うことを特徴と
したものである。

【００１３】請求項４の発明は、請求項３記載の発明に
おいて、前記加重和の係数は前記各検索ホストごとに個
別に設定できることを特徴としたものである。

【００１４】請求項５の発明は、請求項１記載の発明に
おいて、当該検索システム運用中に当該検索システムを
停止することなく、検索ホストを追加又は削除できるこ
とを特徴としたものである。

【００１５】請求項６の発明は、請求項４記載の発明に
おいて、当該検索システム運用中に当該検索システムを
停止することなく、前記加重和の係数を変更できること
を特徴としたものである。

【００１６】請求項７の発明は、ＷＷＷ経由などのよう
に、コネクションをリクエストにまたがって保持できな
い通信環境における検索システムであって、クライアン
トからの検索のリクエストに対して、ネットワークを経
由して同一クライアントからのひとまとまりのリクエス
トをセッションとして識別して受信するサーバホスト
と、受信したリクエストに応じてネットワーク接続され
たデータベースサーバホストからの検索を行う複数の検
索ホストとを有する検索システムにおいて、当該検索シ
ステムは、前記複数の検索ホストの中から各検索ホスト
の負荷状況に応じて検索サーバを起動する検索ホストを
選択する検索ホスト選択手段を有し、該検索ホスト選択
手段によって選択された検索ホストは、同一セッション
からの複数のリクエストに対して１つの検索サーバを起
動し、該検索サーバは、当該検索サーバの動作する検索
ホストの負荷状況を監視し、前記検索ホスト選択手段に
通知することを特徴としたものである。

【００１７】請求項８の発明は、請求項１乃至７の検索
システムを実現するためのプログラムを記録したことを
特徴としたものである。

【００１８】

【発明の実施の形態】本発明の検索システムの概要を説
明する。図１は、本発明の一実施形態による検索システ
ムの概要を説明するためのブロック図である。本実施形
態における検索システムは、ＷＷＷ経由などのように、
コネクションをリクエストにまたがって保持できない通
信環境における検索システムであって、同一セッション
からの複数のリクエストに対し、１つの検索サーバ４を
起動し、リクエストを対応する検索サーバ４に振り分け
ることにより、セッション内の情報をリクエスト間で保
持する検索システムにおいて、複数の検索ホスト２の中
から各検索ホスト２の負荷状況に応じて検索サーバ４を
起動する検索ホスト２を選択するようにしたものであ
る。本実施形態では、ディスパッチャをマスタディスパ
ッチャ１とスレーブディスパッチャ３とに分け、検索サ
ーバ４の起動をマスタディスパッチャ１からスレーブデ
ィスパッチャ３へ依頼することにより、特定の検索ホス
ト２に検索サーバ４が集中することを回避し、検索ホス
ト２の負荷が平均化され、全体として検索効率を向上さ
せる。

【００１９】システム全体のパフォーマンスを向上する
ためには、複数の検索ホスト２の負荷状況をなるべく等
しくすることが好ましい。したがって、本発明の他の実
施形態では、新規に検索サーバを起動するべき検索ホス
ト２を、負荷状況に応じて選択するようにする。

【００２０】マスタディスパッチャ１は常時各スレーブ
ディスパッチャ３と接続を保持し、各ホスト２の負荷状
況を集める。本実施形態においては、各々の前記検索ホ
スト２の負荷状況は、複数の評価基準の組み合わせを当
該検索ホスト２の負荷評価値として採用したものとす
る。負荷状況の評価基準としては、例えば、ロードアベ
レージ、起動されているサーバ数、検索中のサーバ数、
メモリの使用量などが考えられる。ＣＧＩからのリクエ
ストに対して検索サーバを起動する際、マスタディスパ
ッチャ１は、これらの各ホスト２の負荷状況を、これら
複数の基準値の組み合わせによって評価し、どのホスト
２で検索サーバ４を起動するべきか選択する。このと
き、各ホスト２が最近選択されなかった回数のみを負荷
状況の評価基準として用いると、ラウンドロビンによる
選択となる。本発明はラウンドロビン方式を含み、さら
に拡張したものとなっている。

【００２１】また、上述した複数の基準値の組み合わせ
方として、これら複数の基準値の加重和による方法が考
えられる。したがって、本発明の他の実施形態において
は、前記組み合わせには加重和を使う。さらに、各検索
ホスト２は、その機能は同一であっても、メモリ搭載
量、ＣＰＵ搭載数などの計算能力が同一でないこともあ
る。そのようなシステム構成で全体的なパフォーマンス
を向上させるためには、各ホスト２ごとに加重和の係数
を個別に設定することが考えられる。さらに他の実施形
態においては、前記加重和の係数は前記各検索ホスト２
ごとに個別に設定できるようにしている。例えばＣＰＵ
を２個持つホストにおいては、ロードアベレージに対す
る係数を１／２にするのがよいと考えられる。

【００２２】また、本発明においては、特定の検索ホス
トのダウンや、新規検索ホストの追加時に、システム全
体を止めることなくホストの追加、削除をできることが
望ましい。本発明の他の実施形態においては、当該検索
システム運用中に当該検索システムを停止することな
く、検索ホスト２を追加又は削除できるようにする。マ
スタディスパッチャ１がスレーブディスパッチャ３の存
在を知っていればよく、そのためには主リクエストＣＧ
Ｉからのリクエストポートを用いてホスト２の追加を知
らせてやることが可能である。また、マスタ・スレーブ
間の接続の切断をもって、スレーブホストの停止を検出
することが可能である。

【００２３】同様に、ホスト別の係数を実行時に変更す
ることで、システム全体のパフォーマンス向上を図るこ
とができる。このため、本発明の他の実施形態において
は、当該検索システム運用中に当該検索システムを停止
することなく、前記加重和の係数を変更できるようにし
ている。例えば係数をマスタディスパッチャ１に保持
し、上述した通知と同様の方法で係数の変更を通知する
方法が考えられる。

【００２４】次に、本発明の検索システムの実施の形態
を詳細に説明する。図２は、本発明の一実施形態の検索
システムの全体構成を示すブロック図である。本実施形
態の検索システムは、ＷＷＷ経由などのように、コネク
ションをリクエストにまたがって保持できない通信環境
における検索システムであって、クライアント１１から
の検索のリクエストに対して、ネットワーク１２を経由
して同一クライアント１１からのひとまとまりのリクエ
ストをセッションとして識別して受信するサーバホスト
１４と、受信したリクエストに応じてネットワーク（１
３）接続されたデータベースサーバホスト３０からの検
索を行う複数の検索ホスト２５とを有する検索システム
において、当該検索システムは、前記複数の検索ホスト
２５の中から各検索ホスト２５の負荷状況に応じて検索
サーバ２９を起動する検索ホスト２５を選択する検索ホ
スト選択手段１９を有し、該検索ホスト選択手段１９に
よって選択された検索ホスト２５は、同一セッションか
らの複数のリクエストに対して１つの検索サーバ２５を
起動し、該検索サーバ２５は、当該検索サーバ２９の動
作する検索ホスト２５の負荷状況を監視し、前記検索ホ
スト選択手段１９に通知するようにしたものである。デ
ータベース検索サーバの負荷分散装置としての機能を有
する本システムのハードウェア環境としては、ｈｔｔｐ
サーバホスト１４，複数の検索ホスト２５，検索ホスト
選択手段であるマスタディスパッチャホスト１９，デー
タベースサーバホスト３０からなるＬＡＮ１３と、入出
力端末（ブラウザ）１１とが、インターネット（又はＬ
ＡＮ）１２を経由して接続されている。なお、本発明
は、上述のごとき各々の検索システムを実現するための
プログラム、すなわち後述する各機能を構成モジュール
とするプログラム及びそのプログラムを記録したコンピ
ュータ読み取り可能な記録媒体としても実現可能であ
る。

【００２５】クライアントである入出力端末（ブラウ
ザ）１４は、キーボードやポインティングデバイスなど
の入力手段と、入力手段等を管理するプログラムと、プ
ログラムを保持するメモリと、プログラムを処理するマ
イクロプロセッサと、インターネット１２との通信手段
と、ｈｔｔｐサーバホストを特定する手段とを有する。
ユーザは、この入出力端末１４を用いてリクエストを入
力する。

【００２６】インターネット（又はＬＡＮ）１２は、入
出力端末１１とｈｔｔｐサーバホスト１４を相互に接続
するケーブルと、ＴＣＰ／ＩＰのような決まったプロト
コルにしたがってデータを送受信する手段と、多数の入
出力端末１１の１つを特定し、特定した入出力端末１１
との通信手段を動的に確立する手段とを有する。

【００２７】ＬＡＮ１３は、ｈｔｔｐサーバホスト１
４，マスタディスパッチャホスト１９，複数の検索ホス
ト２５，データベースサーバホスト３０を相互に接続す
るケーブルと、ＴＣＰ／ＩＰのような決まったプロトコ
ルにしたがってデータを送受信する手段と、これらのホ
ストの間で通信手段を動的に確立する手段とを有する。

【００２８】ｈｔｔｐサーバホスト１４は、マイクロプ
ロセッサ１５と、メモリ１６と、インターネット１２を
用いた入出力端末１１との通信手段と、ＬＡＮ１３との
通信手段とを有する。マイクロプロセッサ１５は、メモ
リ１６上のプログラム（ｈｔｔｐサーバプログラム１
７，ＣＧＩプログラム１８）にしたがって、インターネ
ット１２，メモリ１６，ＬＡＮ１３との通信を行う。メ
モリ１６は、ランダムアクセス可能な記憶素子で、プロ
グラム１７，１８及び一時データを保持する。

【００２９】ｈｔｔｐサーバプログラム１７は、ＬＡＮ
１２を通じて各入出力端末１１からのＨＴＴＰプロトコ
ルによるリクエストを受け取り、各入出力端末１１との
接続を管理しながらＣＧＩプログラム１８を起動し、リ
クエストのデータを渡す。また、ＣＧＩプログラム１８
からの結果をインターネット１２を通じて入出力端末１
１に送る。

【００３０】ＣＧＩプログラム１８は、本発明の手段を
用いてリクエストの中からセッションＩＤを取り出し、
又はセッションＩＤがないことを判別し、マスタディス
パッチャプログラム２２，検索サーバプログラム２９の
アドレスを問い合わせ、得られたアドレスによって特定
される検索サーバプログラム２９にリクエストの処理を
依頼する。詳細は後述する。

【００３１】マスタディスパッチャホスト１９は、マイ
クロプロセッサ２０と、メモリ２１と、ＬＡＮ１３との
通信手段とを有する。マイクロプロセッサ２０は、メモ
リ２１上のプログラム（マスタディスパッチャプログラ
ム２２）にしたがって（１１）メモリ２１，ＬＡＮ１３
との通信を行う。メモリ２１は、マスタディスパッチャ
プログラム２２，検索サーバ対応表２３，検索ホスト負
荷管理表２４及び一時データを保持する。

【００３２】マスタディスパッチャプログラム２２は、
本発明の手段を用いてＣＧＩプログラム１８からのセッ
ションＩＤと検索サーバプログラム２９との対応を検索
サーバ対応表２３を用いて管理する。スレーブディスパ
ッチャプログラム２８と交信し、検索ホスト２５の負荷
情報を検索ホスト負荷管理表２４に記録する。新規セッ
ションに対応する検索サーバプログラム２９の起動に当
たっては、本発明の手段を用いて、複数ある検索ホスト
２５の中から、検索ホスト負荷管理表２４の情報に基づ
き１つを選択し、選択された検索ホスト２５上のスレー
ブディスパッチャ２８に起動を依頼する。詳細は後述す
る。検索サーバ対応表２３は、本発明の手段を用いて現
在稼働中のセッションのセッションＩＤと検索サーバプ
ログラム２９との対応を管理する表、検索ホスト負荷管
理表２４は、本発明の手段を用いて検索ホスト２５の負
荷状況を管理する表であり、詳細は後述する。

【００３３】検索ホスト２５は、マイクロプロセッサ２
６と、メモリ２７と、ＬＡＮ１３との通信手段とを有す
る。同一構成の検索ホスト２５が複数存在するものとす
る。マイクロプロセッサ２６は、メモリ２７上のプログ
ラム（スレーブディスパッチャプログラム２８，検索サ
ーバプログラム２９）にしたがって、メモリ２７，ＬＡ
Ｎ１３との通信を行う。メモリ２７は、スレーブディス
パッチャプログラム２８，検索サーバプログラム２９を
保持する。

【００３４】スレーブディスパッチャプログラム２８
は、本発明の手段を用いてマスタディスパッチャ２２か
らの依頼により検索サーバプログラム２９を起動する。
自分の動作する検索ホスト２５の負荷状況を監視し、定
期的にマスタディスパッチャプログラム２２に送信す
る。詳細は後述する。

【００３５】検索サーバプログラム２９は、スレーブデ
ィスパッチャプログラム２８により起動される。ＬＡＮ
１３を通してＣＧＩプログラム１８からリクエストを受
け取り、データベースサーバホスト３０へ問い合わせ、
結果を返す。

【００３６】データベースサーバホスト３０は、マイク
ロプロセッサと、メモリと、データベースと、ＬＡＮ１
３との通信手段とを有する。ＬＡＮ１３を通して、検索
サーバプログラム２９からの要求を受け、データベース
を検索し、検索結果データを返す。

【００３７】次に、本発明を用いたＣＧＩプログラムの
一実施例を説明する。図３は、本発明の一実施形態の検
索システムにおけるＣＧＩプログラムの一実施例を説明
するためのフロー図である。ＣＧＩプログラム１８は、
ｈｔｔｐサーバプログラム１７により起動され、入出力
端末１１からのリクエストをｈｔｔｐサーバプログラム
１７から受け取る（ステップＳ１）。次に、リクエスト
からセッションＩＤの抽出を行い（ステップＳ２）、そ
の結果セッションＩＤが得られたかを判定し（ステップ
Ｓ３）、得られなかった場合は「ＩＤなし」のセッショ
ンであると識別する（ステップＳ４）。次に、マスタデ
ィスパッチャプログラム２２に接続し（ステップＳ
５）、得られたセッションＩＤ又はセッションＩＤがな
いことを送信する（ステップＳ６）。リクエストを処理
すべき検索サーバプログラム２９の存在する検索ホスト
２５とホスト２５内のアドレスを受信し（ステップＳ
７）、マスタディスパッチャプログラム２２との接続を
切断した後（ステップＳ８）、得られた情報によって検
索サーバを特定し、その検索サーバプログラム２９に接
続し（ステップＳ９）、リクエストを送信する（ステッ
プＳ１０）。検索サーバプログラム２９による検索の結
果を受信し（ステップＳ１１）、検索サーバとの接続を
切断後（ステップＳ１２）、検索結果をｈｔｔｐｄしい
てはｈｔｔｐサーバプログラムに返す（ステップＳ１
３）。しかるのち、終了する。

【００３８】次に、本発明を用いたマスタディスパッチ
ャプログラムの一実施例を説明する。マスタディスパッ
チャプログラム２２は以下の４つのサブプログラムに分
けられる。

【００３９】（１）入力監視サブプログラム： ＣＧＩ
プログラム１８又はスレーブディスパッチャプログラム
２８からの入力により以下の３つのサブプログラム
（２）〜（４）のうち１つを選択して実行する。 （２）セッション管理サブプログラム： リクエストの
セッションＩＤに対応する検索サーバプログラム２９の
アドレスを検索サーバ対応表２３によって管理し、ＣＧ
Ｉプログラム１８からの問い合わせに対して答える。 （３）負荷状況監視サブプログラム： スレーブディス
パッチャプログラム２８からの負荷状況報告を検索ホス
ト負荷管理表２４によって管理する。 （４）新規セッション起動サブプログラム： 新規セッ
ション起動に際して、検索ホスト負荷管理表２４の情報
を基に、新規の検索サーバプログラム２９を起動すべき
検索ホスト２５を選択し、セッションＩＤを割り当て、
スレーブディスパッチャプログラム２８に起動を依頼す
る。

【００４０】図４は、本発明の一実施形態の検索システ
ムにおける入力監視サブプログラムの一例を説明するた
めのフロー図である。入力監視サブプログラムは、入力
を待ち（ステップＳ２１）、マスタディスパッチャ２２
へのリクエストを受信すると、検索サーバアドレスの問
い合わせ（ステップＳ２２），検索ホスト２５の状況報
告（ステップＳ２３）といったリクエストの種類を判別
する。検索サーバアドレスの問い合わせの場合にはセッ
ション管理サブプログラムを（ステップＳ２４）、状況
報告のリクエストの場合には負荷状況監視サブプログラ
ムを（ステップＳ２５）、それぞれ起動する。

【００４１】セッション管理サブプログラムは、ＣＧＩ
プログラム１８からセッションＩＤを受け取り、そのセ
ッションに対応する検索サーバプログラム２９のアドレ
スを検索サーバ対応表２３を検索して得る。セッション
ＩＤが入出力端末１１からのリクエストに含まれていな
いか、又は検索サーバ対応表２３に登録されていない場
合は、新規セッションを起動するために（４）新規セッ
ション起動サブプログラムを実行する。いずれの場合も
最終的に検索サーバプログラム２９のアドレスが得ら
れ、ＣＧＩプログラム１８に返す。以下、この処理をフ
ロー図にて説明する。

【００４２】図５は、本発明の一実施形態の検索システ
ムにおけるセッション管理サブプログラムの一例を説明
するためのフロー図である。ＣＧＩプログラム１８から
の問い合わせから、セッションＩＤを取り出し、セッシ
ョンＩＤが指定されているかを判断する（ステップＳ３
１）。「セッションＩＤなし」と識別されていた場合、
ステップＳ３４へ分岐する。得られたセッションＩＤを
キーとして検索サーバ対応表２３を検索する（ステップ
Ｓ３２）。対応するエントリが存在するかを判断し（ス
テップＳ３３）、対応するエントリが見つかれば、その
セッションに対応する検索サーバプログラム２９のアド
レスが得られる。ステップＳ３３でアドレスが得られな
ければ、この時点で、新規セッションを起動する必要が
あるので、新規セッション起動サブプログラムを実行す
る（ステップＳ３４）。実行結果として、対応する新規
の検索サーバプログラム２９が起動され、そのアドレス
が得られ、検索サーバ対応表２３に登録される。最後
に、ステップＳ３２又はステップＳ３４で得られた検索
サーバプログラム２９のアドレスをＣＧＩプログラム１
８に返信する（ステップＳ３５）。

【００４３】図６は、本発明の一実施形態の検索システ
ムにおける負荷状況監視サブプログラムの一例を説明す
るためのフロー図である。負荷状況監視サブプログラム
は、リクエストを受信すると（ステップＳ４１）、リク
エストが検索ホストの追加の要求かどうかを判断する
（ステップＳ４２）。追加の要求であれば、検索ホスト
を負荷管理表に追加し（ステップＳ４６）、処理を終了
する。ステップＳ４２において、検索ホストの追加要求
でなければ、検索ホスト２５のスレーブディスパッチャ
プログラム２８からの負荷状況報告を受け取り、検索ホ
スト負荷管理表２４を用いて各検索ホストの負荷状況を
記録する（ステップＳ４３）。この情報は新規セッショ
ン起動サブプログラムで新規検索サーバプログラム２９
の起動先の検索ホスト２５を選択する際に使用される。
また、負荷状況報告の中に検索サーバプログラム２９の
停止の情報があれば、検索サーバ対応表２３から対応す
るセッションのエントリを削除する（ステップＳ４
４）。さらに、付加評価基準係数変更要求に対し、検索
ホスト付加管理表２４内の該当する係数を変更する（ス
テップＳ４５）。

【００４４】図７は、本発明の一実施形態の検索システ
ムにおける新規セッション起動サブプログラムの一例を
説明するためのフロー図である。新規セッション起動サ
ブプログラムは、新規セッションのためのセッションＩ
Ｄを発生し、起動された検索ホスト２５及び検索サーバ
プログラム２９のアドレスとともに検索サーバ対応表２
３に登録する。より詳細には、新規セッション起動サブ
プログラムは、ＣＧＩプログラム１８から新規セッショ
ンを要求された場合、及び要求されたセッションが存在
しなかった場合に、新規に検索サーバプログラム２９を
起動する。まず、新しく未使用のセッションＩＤを生成
し（ステップＳ５１）、検索ホスト負荷管理表２４の情
報にしたがって、そこに記録されている各ホストの負荷
状況を評価して負荷評価値を与える（ステップＳ５２；
詳細は後述する）。新規検索サーバプログラム２９を起
動するべき検索ホスト２５、すなわち、負荷評価値の最
も低い検索ホスト２５を選択し（ステップＳ５３）、そ
のホスト上のスレーブディスパッチャ２８にセッション
ＩＤを送り、検索サーバ２５の起動を依頼する（ステッ
プＳ５４）。次に、スレーブディスパッチャ２８の返答
を待ち、起動された検索サーバ２５のアドレスを得る
（ステップＳ５５）。最後に、検索サーバ対応表２３に
新規セッションのエントリを追加し（ステップＳ５
６）、処理を終了する。

【００４５】ここで、負荷評価値の計算について詳細に
説明する。ステップＳ５２において、検索ホスト負荷管
理表２４には、ホストｉと負荷評価基準ｊに対応して、
負荷評価値Ｌ_ijと、それに対する重み値Ｗ_ijとが記録さ
れている。ここで、各ホストに対する組み合わせ評価値
Ｖ_iを、以下の式により算出する。 Ｖ_i ＝ Σ_j Ｗ_ij・Ｌ_ij ステップＳ５３においては、Ｖ_iの最も低いホストｉを
選択する。

【００４６】次に、検索サーバ対応表２３について詳細
に説明する。図８は、本発明の一実施形態の検索システ
ムにおける検索サーバ対応表の一例を示す図である。検
索サーバ対応表２３は、マスタディスパッチャホスト１
９のメモリ２１内に存在し、マスタディスパッチャプロ
グラム２２によって管理・参照される。

【００４７】検索サーバ対応表２３の各行は、それぞれ
現在稼動中の検索サーバプログラム２９に対応し、セッ
ションＩＤ３１，検索ホストアドレス３２，検索サーバ
プログラムのアドレス３３を保持する。ここで、セッシ
ョンＩＤ３１はマスタディスパッチャプログラム２２に
よって割り当てられる数値、検索ホストアドレス３２と
しては例えばネットワーク上のＩＰアドレス、検索サー
バプログラムのアドレス３３には例えばＴＣＰ／ＩＰソ
ケットのポート番号を使う。

【００４８】この検索サーバ対応表２３には、現在稼働
中の全ての検索ホスト２５上の全検索サーバプログラム
２９の情報が記録される。検索サーバプログラム２９が
終了した場合には、スレーブディスパッチャプログラム
２８を通じてマスタディスパッチャプログラム２２に通
知され、この表２３から該当するセッションのエントリ
が削除される。

【００４９】次に、検索ホスト負荷管理表２４について
詳細に説明する。図９は、本発明の一実施形態の検索シ
ステムにおける検索ホスト荷管理表の一例を示す図であ
る。検索ホスト負荷管理表２４は、マスタディスパッチ
ャホスト１９のメモリ２１内に存在し、マスタディスパ
ッチャプログラム２２によって管理・参照される。

【００５０】検索ホスト負荷管理表２４の各行は、それ
ぞれ検索ホスト２５に対応する。列にはホスト名４１，
ネットワークアドレス４２を保持する。それ以降の列
は、検索ホストの負荷評価値と、それに対応する重み値
を保持する。

【００５１】上述の例では、ホストａｎｔｍａｎの処理
能力が他の２つのサーバの２倍ある場合を表わしてい
る。ａｎｔｍａｎに対応する検索サーバ数４３の係数４
４及びロードアベレージ４５の係数４６を他のホストに
比べて半分にすることにより、組み合わせ負荷評価値
は、他のホストに比べａｎｔｍａｎに２倍のサーバ数又
は２倍のロードアベレージがある場合にほぼ同じ値とな
る。係数４８が負の数になっているのは、最近選択され
なかった回数４７の値が多い程、組み合わせ負荷評価値
が低く、つまり、ステップＳ５３において選択されやす
くなるようにするためである。例えば、上述のステップ
Ｓ５２の負荷評価値として図９に示す数値を例にとる
と、 antman ：８×０.５＋２.０３×１＋２×（−１）＝４.
０３ birdman：３×１＋０.３２×２＋０×（−１）＝３.６
４ catman ：４×１＋０.８９×２＋１×（−１）＝４.７
８ となり、ホストbirdmanが選択されることになる。

【００５２】最後に、スレーブディスパッチャプログラ
ムの実施例について説明する。図１０は、本発明の一実
施形態の検索システムにおけるスレーブディスパッチャ
プログラムの一実施例を説明するためのフロー図であ
る。マスタディスパッチャプログラム２２に対し、自身
の動作する検索ホスト２５を加えるよう依頼する（ステ
ップＳ６１）。次に、マスタディスパッチャプログラム
２２からの依頼を待つ（ステップＳ６２）。ここでは、
新規検索サーバ２５の起動要求か、検索サーバ２５の終
了か、タイムアウトを待つ。検索サーバプログラム２９
の起動依頼が来ると、これを起動し（ステップＳ６３，
Ｓ６４）、そのネットワークアドレス（ＴＣＰポート番
号）をマスタディスパッチャプログラム２２に返す（ス
テップＳ６５）。ステップＳ６２でマスタディスパッチ
ャプログラム２２からの依頼を待っている間に、稼働中
の検索サーバプログラム２９が終了した場合、及び一定
時間、例えば３０秒が経過するごとに、スレーブディス
パッチャプログラム２８は自検索ホスト２５の負荷状況
を計測し（ステップＳ６６）、測定した負荷状況をマス
タディスパッチャプログラム２２に送信する（ステップ
Ｓ６７）。その後、ステップＳ６２へ戻って処理をくり
返す。

【００５３】

【発明の効果】請求項１，７，８の発明によれば、セッ
ション起動時に、複数ある検索ホストの負荷状況を評価
し、検索サーバを起動するべき検索ホストを選択するこ
とにより、特定の検索ホストに検索サーバが集中するこ
とを回避し、検索ホストの負荷が平均化され、システム
全体としての効率を上げることができる。

【００５４】請求項２，８の発明によれば、負荷状況の
評価として複数の評価基準を組み合わせて用いることに
より、多角的な観点から各検索ホストの負荷状況を比較
することが可能になり、全体の負荷をより平均化させる
ことができる。

【００５５】請求項３，８の発明によれば、負荷状況の
組み合わせとして加重和を使うことにより、複数の評価
基準の間での評価の重要度を反映させることができ、検
索ホストの負荷状況をより正確に把握することが可能と
なる。

【００５６】請求項４，８の発明によれば、加重和の係
数を検索ホストごとに独立して設定することにより、検
索ホスト間に処理性能の差がある場合でも、その性能差
に見合った負荷状況の評価が可能になり、システム全体
の効率を上げることができる。

【００５７】請求項５，７，８の発明によれば、システ
ムを停止することなく検索ホストの追加、削除を行うこ
とにより、検索ホストのシステムダウンあるいは交換時
に、システムのサービスを停止する必要がなくなる。

【００５８】請求項６，８の発明によれば、システムを
停止することなく加重和の係数を変更することにより、
特定の検索ホストの負荷を通常より大きくあるいは小さ
くすることが可能になり、あるいは特定の負荷状況評価
基準を重視あるいは無視することが可能になり、その検
索ホストの能力を他のシステムに回し、あるいは一時的
に性能が落ちているホストをより有効に使用することが
可能になる。

【図面の簡単な説明】

【図１】 本発明の一実施形態による検索システムの概
要を説明するためのブロック図である。

【図２】 本発明の一実施形態の検索システムの全体構
成を示すブロック図である。

【図３】 本発明の一実施形態の検索システムにおける
ＣＧＩプログラムの一実施例を説明するためのフロー図
である。

【図４】 本発明の一実施形態の検索システムにおける
入力監視サブプログラムの一例を説明するためのフロー
図である。

【図５】 本発明の一実施形態の検索システムにおける
セッション管理サブプログラムの一例を説明するための
フロー図である。

【図６】 本発明の一実施形態の検索システムにおける
負荷状況監視サブプログラムの一例を説明するためのフ
ロー図である。

【図７】 本発明の一実施形態の検索システムにおける
新規セッション起動サブプログラムの一例を説明するた
めのフロー図である。

【図８】 本発明の一実施形態の検索システムにおける
検索サーバ対応表の一例を示す図である。

【図９】 本発明の一実施形態の検索システムにおける
検索ホスト負荷管理表の一例を示す図である。

【図１０】 本発明の一実施形態の検索システムにおけ
るスレーブディスパッチャプログラムの一実施例を説明
するためのフロー図である。

【図１１】 従来技術による検索システムの概要を説明
するためのブロック図である。

【図１２】 従来技術による他の検索システムの概要を
説明するためのブロック図である。

【符号の説明】

１…マスタディスパッチャ、２，２５…検索ホスト、３
…スレーブディスパッチャ、４，５４，６４…検索サー
バ、１１…入出力端末（ブラウザ）、１２…インターネ
ット（又はＬＡＮ）、１３…ＬＡＮ、１４…ｈｔｔｐサ
ーバホスト、１５，２０，２６…マイクロプロセッサ、
１６，２１，２７…メモリ、１７…ｈｔｔｐサーバプロ
グラム、１８…ＣＧＩプログラム、１９…マスタディス
パッチャホスト、２２…マスタディスパッチャプログラ
ム、２３…検索サーバ対応表、２４…検索ホスト負荷管
理表、２８…スレーブディスパッチャプログラム、２９
…検索サーバプログラム、３０…データベースサーバホ
スト。

Claims (8)

【特許請求の範囲】
1. 【請求項１】 ＷＷＷ経由などのように、コネクション
   をリクエストにまたがって保持できない通信環境におけ
   る検索システムであって、同一セッションからの複数の
   リクエストに対し、１つの検索サーバを起動し、リクエ
   ストを対応する検索サーバに振り分けることにより、セ
   ッション内の情報をリクエスト間で保持する検索システ
   ムにおいて、複数の検索ホストの中から各検索ホストの
   負荷状況に応じて検索サーバを起動する検索ホストを選
   択することを特徴とする検索システム。
2. 【請求項２】 請求項１記載の検索システムにおいて、
   各々の前記検索ホストの負荷状況は、複数の評価基準の
   組み合わせを当該検索ホストの負荷評価値として採用し
   たものであることを特徴とする検索システム。
3. 【請求項３】 請求項２記載の検索システムにおいて、
   前記組み合わせには加重和を使うことを特徴とする検索
   システム。
4. 【請求項４】 請求項３記載の検索システムにおいて、
   前記加重和の係数は前記各検索ホストごとに個別に設定
   できることを特徴とする検索システム。
5. 【請求項５】 請求項１記載の検索システムにおいて、
   当該検索システム運用中に当該検索システムを停止する
   ことなく、検索ホストを追加又は削除できることを特徴
   とする検索システム。
6. 【請求項６】 請求項４記載の検索システムにおいて、
   当該検索システム運用中に当該検索システムを停止する
   ことなく、前記加重和の係数を変更できることを特徴と
   する検索システム。
7. 【請求項７】 ＷＷＷ経由などのように、コネクション
   をリクエストにまたがって保持できない通信環境におけ
   る検索システムであって、クライアントからの検索のリ
   クエストに対して、ネットワークを経由して同一クライ
   アントからのひとまとまりのリクエストをセッションと
   して識別して受信するサーバホストと、受信したリクエ
   ストに応じてネットワーク接続されたデータベースサー
   バホストからの検索を行う複数の検索ホストとを有する
   検索システムにおいて、当該検索システムは、前記複数
   の検索ホストの中から各検索ホストの負荷状況に応じて
   検索サーバを起動する検索ホストを選択する検索ホスト
   選択手段を有し、該検索ホスト選択手段によって選択さ
   れた検索ホストは、同一セッションからの複数のリクエ
   ストに対して１つの検索サーバを起動し、該検索サーバ
   は、当該検索サーバの動作する検索ホストの負荷状況を
   監視し、前記検索ホスト選択手段に通知することを特徴
   とする検索システム。
8. 【請求項８】 請求項１乃至７のいずれか１記載の検索
   システムを実現するためのプログラムを記録したコンピ
   ュータ読み取り可能な記録媒体。