JP4451339B2 - 負荷分散システム、および負荷分散方法 - Google Patents

Description

本発明は、クライアントからの要求を、複数のシステムに振り分ける負荷分散技術に関する。

各クライアントからの要求を処理するために、複数のサーバを並列に運用し、サーバ間での負荷が均等になるように処理を分散する負荷分散技術がある。例えば、特許文献１には、サーバの負荷状況をクライアントに通知して、クライアントの表示装置にサーバの負荷状況を表示するサーバ負荷通知システムが記載されている。
特開平１０−１０５４９７

ところで、クライアントからのアクセス件数の増加に伴い、サーバやデータベースなどの各リソースの増強を行い、負荷分散装置を用いてクライアントからのアクセス要求を複数のリソースに分散して振り分け、システム全体を効率よく稼動させる方法がある。

しかしながら、アクセス件数の大幅な増加が予想される場合には、各リソースの増強だけでは所定の性能を確保することが難しい場合がある。このような場合、現在、稼動している現行システムを、もう一式新たに併設するなどの大規模なシステムの増強を行う必要がある。このように現行システムとは別の新システムを併設した場合、各クライアントからのアクセスを所定の方法でどちらかのシステムに振り分ける必要がある。クライアント側で、現行システムにアクセスするのか、または、新システムにアクセスするのかを意識させることは困難であり、また、ユーザサービスの低下につながるおそれがある。

本発明は上記事情に鑑みてなされたものであり、本発明の目的は、クライアント側に複数のシステムを意識させることなく、クライアントからの要求を複数のシステム間で振り分けることにある。

上記課題を解決するために、本発明は、例えば、複数の業務システムを有し、クライアントからの要求を前記複数の業務システムに振り分けて処理を行う負荷分散システムである。そして、前記業務システム各々は、ユーザＩＤと当該ユーザＩＤが属するグループとが記憶されたユーザＤＢと、前記各グループと、当該グループに割り当てられた前記業務システムを識別するためのシステム情報とが記憶された振分テーブルと、前記クライアントから、ユーザＩＤを含む要求を受け付ける要求受付手段と、前記ユーザＤＢおよび前記振分テーブルを参照し、前記要求受付手段が受け付けたユーザＩＤに対応するシステム情報を取得する取得手段と、前記取得手段が取得した前記システム情報が、自業務システムのシステム情報か否かを判別する判別手段と、自業務システムのシステム情報と判別した場合、前記要求に応じた処理を行う要求処理手段と、自業務システム以外の他業務システムのシステム情報と判別した場合、前記他業務システムに前記要求受付手段が受け付けた要求を転送するための画面情報を生成し、前記クライアントに送信する転送手段と、を有する。

本発明では、クライアント側に複数のシステムを意識させることなく、クライアントからの要求を複数のシステム間で振り分けることができる。また、本発明では、各クライアントからの要求を、当該クライアントに割り当てたシステムに転送することができる。

以下、本発明の実施の形態について説明する。

図１は、本発明の一実施形態が適用されたトレードシステムの全体構成図である。トレードシステムは、投資家がネットワークを介して株式など売買するシステムである。本実施形態のトレードシステムは、各クライアントからの大量の取引データを処理するために、２つのサイト（ＡサイトおよびＢサイト）で分散して処理を行っている。

図示するトレードシステムは、少なくとも１つのクライアント１と、Ａサイトのシステム（以下、Ａシステム）２と、Ｂサイトのシステム（以下、「Ｂシステム」）３と、Ａサイト用ＤＮＳサーバ４と、Ｂサイト用ＤＮＳサーバ５と、を有する。そして、これらの各装置は、インターネットなどのネットワーク９により接続されている。

また、Ａサイト用ＤＮＳサーバ４はＡシステム２に、また、Ｂサイト用ＤＮＳサーバ５はＢシステム３にそれぞれ接続されている。そして、Ａサイト用ＤＮＳサーバ４とＢサイト用ＤＮＳサーバ５とは、Ａシステム２およびＢシステム３を介して、互いに接続されているものとする。

クライアント１は、Ｗｅｂブラウザ１１を有し、ユーザの指示を受け付けてＡシステム２またはＢシステム３に各種の要求を送信する。

Ａシステム２は、ＰＬ（presentation layer）サーバ２１と、ＢＬ（business logic layer）サーバ２２と、ＤＢ（database）サーバ２３と、を備える３層構造のシステムである。ＰＬサーバ２１は、クライアント１からの各種要求を受け付ける入力受付部２１１と、要求元のクライアント１に応答情報（画面情報）を送信する出力部２１２と、を備える。

ＢＬサーバ２は、ＰＬサーバ２が受け付けた各種の要求を処理する業務処理サーバであって、判別部２２１と、業務処理部２２２と、転送部２２３と、を備える。判別部２２１は、ＰＬサーバ２１が受け付けた要求が、自システムに割り当てられたクライアント１からの要求か否かを判別する。業務処理部２２２は、判別部２２１が自システムのクライアント１からの要求であると判別した場合、ログイン処理および各種の処理を行う。転送部２２３は、判別部２２１が他システムのクライアントからの要求であると判別した場合、クライアントから受け付けた要求を他システムに転送する。

ＤＢサーバ２３は、各種のデータを管理するデータ管理部２３１と、ユーザＤＢ２３２と、振分テーブル２３３と、を備える。ユーザＤＢ２３２は、ユーザ各々の属性を管理するためのデータベースである。振分テーブル２３３は、各ユーザを所定のグループにグルーピングするための部店コードと、当該部店コードに対応するシステム情報とが記憶されたテーブルである。なお、ユーザＤＢ２３２および振分テーブル２３３については後述する。

Ｂシステム３は、Ａシステム２と同様に、ＰＬサーバ３１と、ＢＬサーバ３２と、ＤＢサーバ３３とを備える。なお、Ｂシステム３のＰＬサーバ３１、ＢＬサーバ３２およびＤＢサーバ３３は、それぞれ、Ａシステム２のＰＬサーバ２１、ＢＬサーバ２２およびＤＢサーバ２３と同様である。

Ａサイト用ＤＮＳ（Domain Name System）サーバ４は、いわゆるネームサーバであって、クライアント１が指定する本トレードシステムを示す仮想ＵＲＬ（Uniform Resource Locator）を、Ａシステム２またはＢシステム３のＵＲＬに変換する。図示するＡサイト用ＤＮＳサーバ４は、名前解決部４１と、監視部４２と、名前解決テーブル４３と、を備える。名前解決部４１は、仮想ＵＲＬを、Ａシステム２またはＢシステム３のＵＲＬに変換する。監視部４２は、当該Ａサイト用ＤＮＳサーバ４が接続されたＡシステム２、および、Ｂシステム３の稼動状態をそれぞれ監視する。なお、監視部４２は、Ａシステム２を介してＢシステム３の稼動状態を監視するものとする。名前解決テーブル４３は、仮想ＵＲＬと、Ａシステム２のＵＲＬおよびＢシステム３のＵＲＬとを対応付けたテーブルである。なお、名前解決テーブル４３については、後述する。また、Ｂサイト用ＤＮＳサーバ５は、Ａサイト用ＤＮＳサーバ４と同様である。

上記説明した、クライアント１、Ａシステム２およびＢシステム３の各サーバ、Ａサイト用ＤＮＳサーバ４およびＢサイト用ＤＮＳサーバ５は、いずれも、例えば図２に示すようなＣＰＵ９０１と、メモリ９０２と、ＨＤＤ等の外部記憶装置９０３と、キーボードやマウスなどの入力装置９０４と、ディスプレイやプリンタなどの出力装置９０５と、ネットワークと接続するための通信制御装置９０６と、を備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、ＣＰＵ９０１がメモリ９０２上にロードされた所定のプログラムを実行することにより、各装置の各機能が実現される。

例えば、Ａシステム２の各装置の各機能は、ＰＬサーバ２１用のプログラムの場合はＰＬサーバ２１のＣＰＵ９０１が、ＢＬサーバ２２用のプログラムの場合はＢＬサーバ２２のＣＰＵ９０１が、そして、ＤＢサーバ２３用のプログラムの場合はＤＢサーバ２３のＣＰＵ９０１がそれぞれ実行することにより実現される。なお、ＤＢサーバ２３のユーザＤＢ２３２および振分テーブル２３３には、ＤＢサーバ２３のメモリ９０２または外部記憶装置９０３が用いられるものとする。また、入力装置９０４および出力装置９０５については、各装置が必要に応じて備えるものとする。

次に、ＤＢサーバ２３、３３のユーザＤＢ２３２について説明する。なお、Ａシステム２のユーザＤＢ２３２とＢシステム３のユーザＤＢ２３２とは、同一のデータが登録された同一のＤＢである。そして、各ユーザＤＢ２３２には、本トレードシステムにユーザ登録を行った（口座を開設した）ユーザの属性が記憶されている。なお、本実施形態では、ユーザ登録を行ったユーザを、カスタマー（顧客）という。

図３は、ユーザＤＢ２３２の一例を示した図である。図示するユーザＤＢ２３２は、ユーザＩＤ３１と、当該ユーザＩＤ３１に対応する部店コード３２および口座番号３３とを有する。ユーザＩＤ３１、部店コード３２および口座番号３３は、口座開設時に各ユーザに割り当てられるものである。なお、本実施形態では、部店コード３２を用いて、各クライアントからの要求を、Ａシステム２またはＢシステム３に振り分けるものとする。しかしながら、部店コード３２を用いることなく、各ユーザＩＤを所定のグループにグルーピング可能な（グループ分けが可能な）、他のグループ情報を用いることとしてもよい。

次に、ＤＢサーバ２３、３３の振分テーブル２３３について説明する。なお、Ａシステム２の振分テーブル２３３と、Ｂシステム３の振分テーブル２３３とは、同一のデータが登録された同一のテーブルである。

図４は、振分テーブル２３３の一例を示した図である。図示する振分テーブル２３３は、部店コード４１と、当該部店コード４１に割り当てられたサイトを識別するためのサイト情報（または、システム情報）４２とを有する。なお、サイト情報４２としては、サイト名、サイト区分コード、などを用いることが考えられる。

次に、Ａサイト用ＤＮＳサーバ４およびＢサイト用ＤＮＳサーバ５の名前解決テーブル４３について説明する。なお、Ａサイト用ＤＮＳサーバ４の名前解決テーブル４３と、Ｂサイト用ＤＮＳサーバ５の名前解決テーブル４３とは、基本的に同一のデータが登録された同一のテーブルである。

図５は、名前解決テーブル４３の一例を示した図である。名前解決テーブル４３は、本トレードシステムの仮想ＵＲＬを、Ａシステム２またはＢシステム３の実ＵＲＬに変換するためのテーブルである。図示する名前解決テーブル４３は、１つの仮想ＵＲＬ５１に対し、ＡシステムおよびＢシステムの２つの実ＵＲＬ５２を有する。仮想ＵＲＬ５１は、クライアント１のＷｅｂブラウザ１１に入力される、本トレードシステムの仮想的なＵＲＬである。この仮想ＵＲＬを用いることにより、クライアント側では、本トレードシステムが備える２つのシステム（Ａシステム２、Ｂシステム３）を意識することなく本トレードシステムにアクセスすることができる。

そして、名前解決テーブル４３は、実ＵＲＬ５２毎に、初回アクセスフラグ５３と、障害フラグ５４とをそれぞれ有する。初回アクセスフラグ５３は、各クライアントが本トレードシステムにアクセスする際に、最初にアクセスするサイトのシステムを識別（特定）するためのフラグである。図示する例では、初回にアクセスするシステムは、初回アクセスフラグ５３に「ＯＮ」が設定されているＡシステム２である。

障害フラグ５４は、Ａシステム２およびＢシステム３が障害か否かを識別するためのフラグである。図示する例では、「ＯＮ」は障害が発生していることを示し、「ＯＦＦ」は正常に稼動していることを示している。監視部４２は、所定のタイミングで、Ａシステム２およびＢシステム３の各装置の稼動状態をチェックし、障害を検知した場合は障害フラグを「ＯＦＦ」から「ＯＮ」に変更する。なお、図示する例では、Ａシステム２およびＢシステム３には、ともに「ＯＦＦ（正常）」が設定されているものとする。

次に、Ａサイト用ＤＮＳサーバ４およびＢサイト用ＤＮＳサーバ５の名前解決処理について説明する。

まず、図示しないローカルＤＮＳサーバは、クライアント１のＷｅｂブラウザ１１から、本トレードシステムの仮想ＵＲＬを受け付けると、当該仮想ＵＲＬの名前解決要求（実ＵＲＬの要求）を、Ａサイト用ＤＮＳサーバ４およびＢサイト用ＤＮＳサーバ５に送信する。そして、Ａサイト用ＤＮＳサーバ４およびＢサイト用ＤＮＳサーバ５は、それぞれ図６に示す名前解決処理を行い、所定の実ＵＲＬをローカルＤＮＳサーバに送信する。

そして、ローカルＤＮＳサーバは、応答が速い方のＤＮＳサーバ４、５から取得した実ＵＲＬを採用する。そして、ローカルＤＮＳサーバは、当該実ＵＲＬに対応するＩＰアドレスを当該ローカルＤＮＳサーバ（または上位のＤＮＳサーバ（不図示））の対応テーブルから取得し、要求元のクライアント１にＩＰアドレスを送信する。なお、対応テーブルは、ＵＲＬとＩＰアドレスとが対応付けられたテーブルである。これにより、Ａサイト用ＤＮＳサーバ４またはＢサイト用ＤＮＳサーバ５のいずれか一方に障害が発生した場合であっても、ローカルＤＮＳサーバは、他方の正常なサーバ４、５から実ＵＲＬを取得することができる。

図６は、Ａサイト用ＤＮＳサーバ４およびＢサイト用ＤＮＳサーバ５が、それぞれ行う名前解決処理の処理フロー図である。

まず、各ＤＮＳサーバ４、５の名前解決部４１は、ローカルＤＮＳサーバから、名前解決要求を受け付ける（Ｓ２１）。なお、名前解決要求には、本トレードシステムの仮想ＵＲＬが指定されているものとする。そして、名前解決部４１は、名前解決テーブル４３（図５参照）を参照し、初回アクセスフラグが「ＯＮ」の実ＵＲＬを特定する（Ｓ２２）。

そして、名前解決部４１は、特定した実ＵＲＬに対応する障害フラグを参照し、当該実ＵＲＬのシステムが正常に稼動しているか否かを判別する（Ｓ２３）。特定した実ＵＲＬの障害フラグが正常（ＯＦＦ）な場合（Ｓ２３：ＹＥＳ）、名前解決部４１は、Ｓ２２で特定した実ＵＲＬをローカルＤＮＳサーバに送信する（Ｓ２４）。一方、特定した実ＵＲＬの障害フラグが障害（ＯＮ）の場合（Ｓ２３：ＮＯ）、名前解決部４１は、他方の実ＵＲＬ（特定した実ＵＲＬ以外の実ＵＲＬ）の障害フラグを参照する。そして、他方の実ＵＲＬの障害フラグが正常な場合、名前解決部４１は、他方の実ＵＲＬをローカルＤＮＳサーバに送信する（Ｓ２５）。

このように、名前解決部４１が名前解決テーブル４３の障害フラグを参照することにより、一方のシステムに障害が発生している場合は、他方の正常に稼動しているシステムの実ＵＲＬをローカルＤＮＳサーバに送信することができる。

次に、本トレードステムへのログイン時の処理について説明する。

なお、本実施形態のユーザには、カスタマーとビジターの２種類のユーザが存在するものとする。カスタマーは、前述の通り本トレードステムにユーザ登録（口座開設）を行ったユーザであって、ユーザＩＤおよびパスワード等をあらかじめ取得しているものとする。ビジターは、本システムにユーザ登録を行っていない不特定多数のユーザである。

そして、本実施形態では、ビジターが使用するクライアント１から送信された要求は、Ａシステム２またはＢシステム３のどちらのシステムにおいてもが処理が行えるものとする。一方、カスタマーが使用するクライアント１から送信された要求については、当該カスタマーが属する部店コード（グループ）ごとに割り振られたいずれか一方のシステムでしか処理できないものとする。

図７は、本トレードシステムにログインする際の処理フロー図である。なお、図示する処理フローは、ユーザがカスタマーの場合の処理フロー図である。

まず、クライアント１のＷｅｂブラウザ１１は、ユーザの指示を受け付けて仮想ＵＲＬが指定されたログイン要求をネットワーク９に送信する。そして、Ｗｅｂブラウザ１１は、図５および図６で説明したように、ローカルＤＮＳサーバ（不図示）から、Ａサイト用ＤＮＳサーバ４またはＢサイト用ＤＮＳサーバ５が送信した実ＵＲＬのＩＰアドレスを取得する。なお、図示する処理では、Ｗｅｂブラウザ１１は、Ａシステム２（すなわちＰＬサーバ２１）のＩＰアドレスを取得するものとする。

そして、Ｗｅｂブラウザ１１は、取得したＩＰアドレスを用いて、最初にＡシステム２にアクセスし、Ａシステム２からトップページ（最初に表示される画面）の画面情報を取得してトップページの画面を出力装置に出力しているものとする（Ｓ４１）。なお、トップページの画面には、カスタマーがログインするためのログイン部分を有するものとする。そして、ログイン部分には、ユーザＩＤの入力欄と、パスワードの入力欄と、ログインボタンとが表示されている。

カスタマーは、ユーザＩＤおよびパスワードを入力して、ログインボタンをクリック（押下）する。Ｗｅｂブラウザ１１は、ログインボタンのクリック（イベント）を受け付けて、入力されたユーザＩＤおよびパスワードを含むログイン要求を、Ａシステム２のＰＬサーバ２１に送信する（Ｓ４２）。

Ａシステム２のＰＬサーバ２１の入力受付部２１１は、クライアント１からのログイン要求を受け付け、ＢＬサーバ２２に当該ログイン要求を引き渡す。ＢＬサーバ２２の判別部２２１は、受け付けたログイン要求に含まれるユーザＩＤのサイト情報を取得する（Ｓ４３）。すなわち、判別部２２１は、ＤＢサーバ２３にアクセスし、まず、当該ユーザＩＤの部店コードをユーザＤＢ２３２から取得する。ＤＢサーバ２３のデータ管理部２３１は、ユーザＤＢ２３２（図３参照）を検索して当該ユーザＩＤの部店コードを特定し、特定した部店コードをＢＬサーバ２２に送出する。そして、判別部２２１は、取得した部店コードに対応するサイト名を、ＤＢサーバ２３の振分テーブル２３３から取得する。すなわち、ＤＢサーバ２３のデータ管理部２３１は、振分テーブル２３３（図４参照）を検索して当該部店コードに対応するサイト情報を特定し、特定したサイト情報をＢＬサーバ２２に送出する。

そして、ＢＬサーバ２２の判別部２２１は、取得したサイト情報が自サイト（図示する場合は、「Ａサイト」）のサイト情報か否かを判別する（Ｓ４４）。なお、ＢＬサーバ２２のメモリまたは外部記憶装置には、ＢＬサーバ２２のサイト情報（「Ａサイト」）が、記憶されているものとする。判別部２２１は、取得したサイト情報が「Ａサイト」の場合は自サイトと判別し、取得したサイト情報が「Ｂサイト」の場合は他サイトと判別する。

判別部２２１が自サイトのサイト情報と判別した場合（Ｓ４４：ＹＥＳ）、業務処理部２２２は、所定の認証処理（パスワードや口座番号のチェックなど）を行う。そして、業務処理部２２２は、認証に成功した場合、ログイン完了画面の画面情報を生成し、生成した画面情報をＰＬサーバ２１に送出する（Ｓ４５）。ＰＬサーバ２１の出力部２１２は、ログイン完了画面の画面情報を受け付け、ネットワーク９を介して、ログイン要求元のクライアント１に送信する。なお、画面情報は、ＨＴＭＬ（HyperText Markup Language）、ＸＭＬ（eXtensible Markup Language）などのマークアップ言語により記述されているものとする。そして、クライアント１のＷｅｂブラウザ１１は、ログイン完了画面の画面情報を受信し、ログイン完了画面を出力装置に出力する（Ｓ５３）。

一方、判別部２２１が他サイトのサイト情報と判別した場合（Ｓ４４：ＮＯ）、転送部２２３は、リダイレクト画面の画面情報を生成し、ＰＬサーバ２１に送出する（Ｓ４６）。リダイレクト画面は、他サイト（Ｂサイト）のシステムにログイン要求を転送するため画面であって、何も表示されない白画面である。そして、転送部２２３は、ＨＴＭＬなどを用いて記述されたリダイレクト画面の画面情報の中に、Ｗｅｂブラウザ１１側で実行するスクリプト（プログラム）を埋め込むものとする。また、転送部２２３は、当該スクリプトのＰＯＳＴ変数（引数）も、リダイレクト画面の画面情報に埋め込むものとする。

なお、ＰＯＳＴ変数には、Ｓ４２のログイン要求に含まれるユーザＩＤおよびパスワードと、他サイト（Ｂサイト）のＵＲＬとが含まれる。ＢＬサーバ２２のメモリまたは外部記憶装置には、他サイトのＵＲＬが、あらかじめ記憶されているものとする。また、転送部２２３は、このようなＰＯＳＴ変数を、隠しデータとして画面情報に埋め込む。すなわち、ＨＴＭＬを用いて記述された画面情報の場合、転送部２２３は、「ＩＮＰＵＴ」タグの「ＴＹＰＥ＝ｈｉｄｄｅｎ」を用いて、クライアント１の出力装置には表示されない隠しデータ（ＰＯＳＴ変数）をクライアント１に送信する。なお、Ｗｅｂブラウザ１１が実行するスクリプトについては後述する。

そして、ＰＬサーバ２１の出力部２１２は、ＢＬサーバ２２から受け付けたリダイレクト画面の画面情報を、ネットワーク９を介してクライアント１に送信する。

クライアント１のＷｅｂブラウザ１１は、リダイレクト画面の画面情報を受信し、当該画面情報を解析して出力装置に表示するとともに（Ｓ４７）、当該画面情報に含まれるスクリプトを実行する（Ｓ４８）。リダイレクト画面の画面情報に含まれるスクリプトは、Ｗｅｂブラウザ１１に、リダイレクト画面がクライアント１の出力装置に表示（ローディング）されたタイミング（イベント）を検知して、他サイトにログイン要求を転送する処理を行わせるものである。

したがって、Ｗｅｂブラウザ１１は、画面情報に含まれるスクリプトを実行することにより、ポスト変数に含まれる他サイト（Ｂサイト）のＵＲＬに、ポスト変数に含まれるユーザＩＤおよびパスワードを含むログイン要求を送信する。なお、リダイレクト画面は、何も表示されない白画面である。このため、Ｗｅｂブラウザ１１が、画面情報を解析してリダイレクト画面を出力装置に表示するために要する時間は、ごく短い時間（一瞬）である。したがって、クライアント１の出力装置に一瞬、表示されるリダイレクト画面を、ユーザは認識することなく、自動的に他サイトにログイン要求を転送することができる。

そして、他サイト（Ｂサイト）のＰＬサーバ３１の入力受付部２１１は、クライアント１から転送されたログイン要求を受け付け、ＢＬサーバ３２に当該ログイン要求を引き渡す。そして、ＢＬサーバ３２の判別部２２１は、Ｓ４３と同様に、受け付けたログイン要求に含まれるユーザＩＤのサイト情報を取得する。そして、判別部２２１は、Ｓ４４と同様に、取得したサイト情報が自サイトのサイト情報か否かを判別する（Ｓ５０）。なお、ＢＬサーバ３２のメモリまたは外部記憶装置には、ＢＬサーバ３２のサイト情報（Ｂサイト）が、記憶されているものとする。判別部２２１は、取得したサイト情報が「Ｂサイト」の場合は自サイトと判別する。また、判別部２２１は、取得したサイト情報が「Ａサイト」の場合、このログイン要求はＡサイトから転送されたログイン要求であるためエラーと判別する。

判別部２２１が自サイトと判別した場合（Ｓ５０：ＹＥＳ）、業務処理部２２２は、Ｓ４５と同様に、所定の認証処理を行い、ログイン完了画面の画面情報を生成する。そして、業務処理部２２２は、生成したログイン完了画面の画面情報をＰＬサーバ３１に送出する。ＰＬサーバ３１の出力部２１２は、ログイン完了画面の画面情報を受け付け、ネットワーク９を介して、ログイン要求元のクライアント１に送信する（Ｓ５１）。クライアント１のＷｅｂブラウザ１１は、ログイン完了画面の画面情報を受信し、ログイン完了画面を出力装置に出力する（Ｓ５３）。

一方、判別部２２１がエラーと判別した場合（Ｓ５０：ＮＯ）、業務処理部２２２は、所定のエラー処理を行う（Ｓ５２）。すなわち、業務処理部２２２は、例えば、エラーメッセージをクライアント１に送信する、エラーのログ情報をメモリまたは外部記憶装置に記憶する、または、エラー処理を行う障害用サーバ（不図示）にエラーメッセージを送信するなどのエラー処理を行う。

図示するログイン処理をおこなうことにより、クライアント側（ユーザ）は、自分に割り当てられたシステムを意識することなく、対象のシステムにログインすることができる。

なお、ユーザがビジターの場合、クライアント１のＷｅｂブラウザ１１は、仮想ＵＲＬが指定されたログイン要求をネットワーク９に送信し、ローカルＤＮＳサーバから、Ａサイト用ＤＮＳサーバ４またはＢサイト用ＤＮＳサーバ５が送信した実ＵＲＬのＩＰアドレスを取得する。なお、図５に示す名前解決テーブル４３の場合、Ｗｅｂブラウザ１１は、最初にＡシステム２にアクセスし、Ａシステム２からトップページの画面情報を受信し、トップページの画面を出力装置に表示する。また、ビジターの場合は、Ａシステム２およびＢシステム３のどちらであっても処理が可能である。したがって、Ａシステムが障害時の場合は、Ａサイト用ＤＮＳサーバ４またはＢサイト用ＤＮＳサーバ５がＢシステムのＵＲＬを送信することにより、Ｗｅｂブラウザ１１はＢシステムにアクセスし、Ｂシステムで処理を行うものとする。

以上、本発明の一実施形態を説明した。

本実施形態では、各システムのＢＬサーバ２２、３２は、自サイト以外のユーザ（カスタマー）からの要求を受け付けた場合、リダイレクト画面の画面情報を生成して要求元のクライアントに送信する。クライアントは、リダイレクト画面の画面情報に含まれるスクリプトを実行することにより、自動的に、他サイト（当該ユーザに割り振られたサイト）のシステムにログイン要求を転送する。これにより、クライアント側に複数のシステムを意識させることなく、クライアントからの要求を複数のシステム間で振り分けることができる。また、ユーザＩＤおよびパスワードを１回入力するだけで、必要に応じてログイン要求が転送されるため、ユーザの操作負荷が増えない。

また、本実施形態のリダイレクト画面の画面情報に含まれるスクリプトは、白画面のリダイレクト画面の表示を検知し、ログイン要求を転送させる。これにより、クライアント１を使用するユーザにリダイレクト画面の存在を気づかせることなく、一瞬のうちにログイン情報を転送することができる。

また、本実施形態のトレードシステムでは、Ａサイト用ＤＮＳサーバ４およびＢサイト用ＤＮＳサーバ５を有し、本トレードシステムの仮想ＵＲＬを、Ａシステム２またはＢシステム３の実ＵＲＬに変換する。これにより、クライアント１は、本トレードシステムが備える２つのシステムを意識することなく所定のシステムにアクセスすることができる。

また、本実施形態の名前解決テーブル（図５参照）は、障害フラグを有する。これにより、一方のシステムに障害が発生している場合は、他方の正常に稼動しているシステムのＵＲＬを送信することができる。この場合、Ａシステム２およびＢシステム３の両方で処理が可能なビジターの要求については、いずれかのシステムで処理を続行することができる。

なお、本発明は上記の実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。例えば、上記実施形態の名前解決テーブル（図５参照）は、仮想ＵＲＬを実ＵＲＬに変換するためのテーブルである。しかしながら、本発明はこれに限定されず、名前解決テーブルは、実ＵＲＬに対応するＩＰアドレスをさらに有することとしてもよい。この場合、各ＤＮＳサーバ４、５の名前解決部４１は、仮想ＵＲＬを、Ａシステム２のＩＰアドレス、またはＢシステム３のＩＰアドレスに変換する。

本発明の一実施形態が適用されたトレードシステムの全体構成を示す図である。 各装置のハードウェア構成例を示す図である。 ユーザＤＢの一例を示す図である。 振分テーブルの一例を示す図である。 名前解決テーブルの一例を示す図である。 ＤＮＳサーバの名前解決処理の処理フロー図である。 ログイン処理の処理フロー図である。

符号の説明

１：クライアント、１１：Ｗｅｂブラウザ、２：Ａサイトのシステム、２１：ＰＬサーバ、２１１：入力受付部、２１２：出力部、２２：ＢＬサーバ、２２１：判別部、２２２：業務処理部、２２３：転送部、２３：ＤＢサーバ、２３１：データ管理部、２３２：ユーザＤＢ，２３３：振分テーブル、３：Ｂサイトのシステム、３１：ＰＬサーバ、３２：ＢＬサーバ、３３：ＤＢサーバ、４：Ａサイト用ＤＮＳサーバ、４１：名前解決部、４２：監視部、４３：名前解決テーブル、５：Ｂサイト用ＤＮＳサーバ、９：ネットワーク

Claims (4)

1. 複数の業務システムを有し、クライアントからの要求を前記複数の業務システムに振り分けて処理を行う負荷分散システムであって、
   前記複数の業務システム各々は、
   ユーザＩＤと当該ユーザＩＤが属するグループとが記憶されたユーザＤＢと、
   前記各グループと、当該グループに割り当てられた前記業務システムを識別するためのシステム情報とが記憶された振分テーブルと、
   前記クライアントから、ユーザＩＤを含む要求を受け付ける要求受付手段と、
   前記ユーザＤＢおよび前記振分テーブルを参照し、前記要求受付手段が受け付けたユーザＩＤに対応するシステム情報を取得する取得手段と、
   前記取得手段が取得した前記システム情報が、自業務システムのシステム情報か否かを判別する判別手段と、
   自業務システムのシステム情報と判別した場合、前記要求に応じた処理を行う要求処理手段と、
   自業務システム以外の他業務システムのシステム情報と判別した場合、前記他業務システムに前記要求受付手段が受け付けた要求を転送するためのリダイレクト画面情報を生成し、前記クライアントに送信する転送手段と、を有し、
   各業務システムに接続されたネームサーバは、
   前記複数の業務システム各々のアドレス情報を記憶した名前解決テーブルと、
   前記複数の業務システムの稼動状態を監視する監視手段と、
   前記クライアントが送信した前記負荷分散システムの仮想アドレス情報を受け付け、前記名前解決テーブルに記憶された業務システムのアドレス情報の中から前記監視手段により正常に稼動していると判別されたアドレス情報を特定し、送信する名前解決手段と、を有すること
   を特徴とする負荷分散システム。
2. 請求項１記載の負荷分散システムであって、
   前記名前解決テーブルは、前記業務システムのアドレス情報毎に、最初にアクセスするか否かを識別するための第１のフラグと、正常に稼動しているか否かを識別するための第２のフラグと、をさらに記憶し、
   前記監視手段は、前記複数の業務システムの稼動状態に応じて、前記名前解決テーブルの第２のフラグを更新し、
   前記名前解決手段は、前記仮想アドレス情報を受け付け、前記名前解決テーブルを参照して、前記第１のフラグがオンに設定されたアドレス情報の前記第２のフラグが正常の場合、当該アドレス情報を送信し、前記第１のフラグがオンに設定されたアドレス情報の前記第２のフラグが障害の場合、前記第２のフラグが正常な他のアドレス情報を送信すること
   を特徴とする負荷分散システム。
3. 請求項１または請求項２記載の負荷分散システムであって、
   前記リダイレクト画面情報には、前記要求に含まれるユーザＩＤと、前記他業務システムのアドレス情報と、前記クライアントに実行させるプログラムと、が含まれ、
   前記プログラムは、前記クライアントに、前記リダイレクト画面情報のリダイレクト画面が前記クライアントの表示装置に表示されたことを検知して、前記他業務システムのアドレス情報を宛先として、前記要求を転送させること
   を特徴とする負荷分散システム。
4. クライアントからの要求を複数の業務システムに振り分けて処理を行う負荷分散方法であって、
   前記複数の業務システム各々は、
   ユーザＩＤと当該ユーザＩＤが属するグループとが記憶されたユーザＤＢと、
   前記各グループと、当該グループに割り当てられた前記業務システムを識別するためのシステム情報とが記憶された振分テーブルと、処理部とを有し、
   前記処理部は、
   前記クライアントから、ユーザＩＤを含む要求を受け付ける要求受付ステップと、
   前記ユーザＤＢおよび前記振分テーブルを参照し、前記要求受付ステップで受け付けたユーザＩＤに対応するシステム情報を取得する取得ステップと、
   前記取得ステップで取得した前記システム情報が、自業務システムのシステム情報か否かを判別する判別ステップと、
   自業務システムのシステム情報と判別した場合、前記要求に応じた処理を行う要求処理ステップと、
   自業務システム以外の他業務システムのシステム情報と判別した場合、前記他業務システムに前記要求受付ステップで受け付けた要求を転送するためのリダイレクト画面情報を生成し、前記クライアントに送信する転送ステップと、を行い、
   各業務システムに接続されたネームサーバは、
   前記複数の業務システム各々のアドレス情報を記憶した名前解決テーブルを有し、
   前記複数の業務システムの稼動状態を監視する監視ステップと、
   前記クライアントが送信した仮想アドレス情報を受け付け、前記名前解決テーブルに記憶された業務システムのアドレス情報の中から前記監視ステップで正常に稼動していると判別されたアドレス情報を特定し、送信する名前解決ステップと、を行うこと
   を特徴とする負荷分散方法。

Images