JP5291504B2 - 負荷分散処理システム - Google Patents

Description

この発明は負荷分散処理システムに係り、特に、サービス利用側の複数のプロセスからの処理要求をサービス提供側の複数のプロセスが受け付けて並列処理し、その処理結果がサービス利用側プロセスに返される形態の情報処理システムにおいて、サービス提供側プロセスに掛かる負荷を分散させることにより、システム全体の処理能力の向上を図る技術に関する。

クライアントサーバ型の情報処理システムにおいては、情報処理量の増加に対してサーバ機を追加し、処理の並列度を向上させることにより、システム全体の処理能力を拡張する手法が採られている。このように、処理を並列化させてシステム性能を向上させる場合には、処理を行う複数のサービス提供側プロセス間に適切に処理要求を振り分ける負荷分散機能が必要となる。このため、これまでも様々な負荷分散処理方式が考案されている。

例えば、ラウンドロビンと称する負荷分散処理方式の場合、並列しているサービス提供側プロセスに対して、順番に処理要求を振り分けるものであり、単純な実装で実現できる利点があるが、個々のサービス提供側プロセスの負荷が一切考慮されないため、重い処理を実行中のサービス提供側プロセスに対しても機械的に次の処理要求が割り振られてしまい、適切な負荷分散が行えない状況に陥る可能性があった。

これに対し、各サービス提供側プロセスからCPU負荷情報を取得し、最もCPU負荷の低いサービス提供側プロセスに対して処理要求を送信する方式の場合、一見、各サービス提供側プロセスの実際の負荷に対応した分散処理が実現できそうであるが、DISK IOがボトルネックとなっている処理では、CPU負荷が低いにもかかわらず処理が停滞している状況も生じるため、やはり適切な負荷分散が行えない状況が生じ得る。

また、各サービス提供側プロセスに対して同報通信により一斉に処理要求を発し、最も早い処理が可能な者が残りのサービス提供側プロセスに対して処理宣言を行い、この名乗りを上げたサービス提供側プロセスのみが処理を実行する負荷分散処理方式もあるが、この場合にはサービス提供側プロセス間で処理宣言が複雑に交錯するため、誤って複数のサービス提供側プロセスにおいて同一処理が実行されてしまう事故の発生や、処理宣言の電文が頻発されることによりネットワーク負荷が増大するという問題がある。

また、特許文献１においては、クライアントとサーバとの間に負荷分散処理装置を介在させておき、この負荷分散処理装置がクライアントからのリクエストを最も負荷が少なくて優先度の高いサーバに振り分ける技術が開示されている。このために、負荷分散処理装置は、各サーバの優先順位情報と各サーバの最大処理量及び実行処理量を格納しておく記憶手段を備えている。
特開２００７−５２５４２

この特許文献１の負荷分散処理システムの場合には、全てのリクエスト及び処理結果データが負荷分散処理装置を通過するため、負荷分散処理装置は各サーバの負荷状況を正確に認識することが可能となる。
しかしながら、リクエスト及び処理結果データがクライアントとサーバ間で直接やり取りされる場合に比べ、負荷分散処理装置を経由することによる伝送遅れが不可避的に生じる。また、高負荷時には負荷分散処理装置に負荷が集中することとなり、システム全体の性能低下が生じるおそれがあった。

この発明は、このような従来の課題を解決するために案出されたものであり、各サービス提供側プロセス側の負荷状況に応じて処理要求を分散することができ、しかも処理要求と処理結果をサービス利用側プロセスと提供側プロセスとの間で直接的にやり取り可能な負荷分散処理技術の提供を目的としている。

上記の目的を達成するため、請求項１に記載した負荷分散処理システムは、処理要求を生成する複数のサービス利用側プロセスと、上記処理要求に対して必要な処理を実行し、処理結果を出力する複数のサービス提供側プロセスと、上記サービス利用側プロセス毎に設けられた処理要求振分部と、上記サービス提供側プロセス毎に設けられた負荷情報管理部と、負荷情報配信部とを備えた負荷分散処理システムであって、上記処理要求振分部は、サービス提供側プロセス毎に、当該サービス提供側プロセスが応対している全サービス利用側プロセスに係る未完了の処理要求件数を格納しておく第１の記憶領域と、自己が担当するサービス利用側プロセスから処理要求が渡された際に、上記第１の記憶領域を参照し、未完了の処理要求件数が最も少ないサービス提供側プロセスを特定する機能と、当該サービス提供側プロセスに係る負荷情報管理部に処理要求を送信する機能と、当該サービス提供側プロセスによる処理結果を上記負荷情報管理部から受信し、上記サービス利用側プロセスに渡す機能と、上記負荷情報配信部からサービス提供側プロセス毎の全サービス利用側プロセスに係る未完了の処理要求件数が送信された場合に、これにより上記第１の記憶領域に格納されたサービス提供側プロセス毎の未完了の処理要求件数を更新する機能を備え、上記負荷情報管理部は、サービス利用側プロセスの処理要求を対応の処理要求振分部から受け取り、自己が担当するサービス提供側プロセスに渡す機能と、当該サービス提供側プロセスから渡された処理結果を、上記サービス利用側プロセスの処理要求振分部に返信する機能と、サービス利用側プロセス毎に、処理要求受信件数及び処理結果返信件数を格納する第２の記憶領域と、処理要求を上記処理要求振分部から受信する度に、上記処理要求受信件数に１を加算する機能と、処理結果を上記処理要求振分部に返信する度に、上記処理結果返信件数に１を加算する機能と、所定のタイミングで、各サービス利用側プロセスに係る処理要求受信件数及び処理結果返信件数を、上記負荷情報配信部に送信する機能を備え、上記負荷情報配信部は、各負荷情報管理部から送信された各サービス利用側プロセスに係る処理要求受信件数及び処理結果返信件数を格納しておく第３の記憶領域と、所定のタイミングで、サービス提供側プロセス毎に、各サービス利用側プロセスに係る処理要求受信件数から処理結果返信件数を減算して未完了の処理要求件数を求め、これを全サービス利用側プロセス分積算する機能と、このサービス提供側プロセス毎の全サービス利用側プロセスに係る未完了の処理要求件数を、各処理要求振分部に送信する機能を備えたことを特徴としている。

また、請求項２に記載した負荷分散処理システムは、請求項１のシステムを前提とし、さらに上記負荷情報管理部が、上記処理結果をサービス利用側プロセスの処理要求振分部に返信するに際し、各サービス利用側プロセスに係る処理要求受信件数の集計値と、各サービス利用側プロセスに係る処理結果返信件数の集計値を算出し、処理結果と共に処理要求振分部に送信する機能を備えており、上記処理要求振分部が、この処理要求受信件数の集計値から処理結果返信件数の集計値を減算して、当該サービス提供側プロセスの全サービス利用側プロセスに係る未完了の処理要求件数を求める機能と、この未完了の処理要求件数によって、上記第１の記憶領域における該当のサービス提供側プロセスに係る未完了の処理要求件数を更新する機能を備えたことを特徴としている。

請求項３に記載した負荷分散処理システムは、処理要求を生成する複数のサービス利用側プロセスと、上記処理要求に対して必要な処理を実行し、処理結果を出力する複数のサービス提供側プロセスと、上記サービス利用側プロセス毎に設けられた処理要求振分部と、上記サービス提供側プロセス毎に設けられた負荷情報管理部と、負荷情報配信部とを備えた負荷分散処理システムであって、上記処理要求振分部は、サービス提供側プロセス毎に、自らが当該サービス提供側プロセスに対して送信中の未完了の処理要求件数である自要求件数と、他のサービス利用側プロセスが当該サービス提供側プロセスに対して送信中の未完了の処理要求件数の合計である他要求件数を格納しておく第１の記憶領域と、自己が担当するサービス利用側プロセスから処理要求が渡された際に、上記第１の記憶領域を参照し、自要求件数と他要求件数の和である未完了の処理要求件数が最も少ないサービス提供側プロセスを特定する機能と、当該サービス提供側プロセスに係る負荷情報管理部に処理要求を送信する機能と、当該サービス提供側プロセスに係る自要求件数に１を加算する機能と、上記負荷情報管理部から処理結果を受信した際に、当該サービス提供側プロセスに係る自要求件数から１を減算する機能と、この処理結果を上記サービス利用側プロセスに渡す機能と、上記負荷情報配信部からサービス提供側プロセス毎の他のサービス利用側プロセスに係る未完了の処理要求件数の合計が送信された場合に、これにより上記第１の記憶領域に格納された他要求件数を更新する機能を備え、上記負荷情報管理部は、サービス利用側プロセスの処理要求を対応の処理要求振分部から受け取り、自己が担当するサービス提供側プロセスに渡す機能と、当該サービス提供側プロセスから渡された処理結果を、上記サービス利用側プロセスの処理要求振分部に返信する機能と、サービス利用側プロセス毎に、処理要求受信件数及び処理結果返信件数を格納する第２の記憶領域と、処理要求を上記処理要求振分部から受信する度に、上記処理要求受信件数に１を加算する機能と、処理結果を上記処理要求振分部に返信する度に、上記処理結果返信件数に１を加算する機能と、所定のタイミングで、各サービス利用側プロセスに係る処理要求受信件数及び処理結果返信件数を、上記負荷情報配信部に送信する機能を備え、上記負荷情報配信部は、各負荷情報管理部から送信された各サービス利用側プロセスに係る処理要求受信件数及び処理結果返信件数を格納しておく第３の記憶領域と、所定のタイミングで、サービス提供側プロセス毎に、各サービス利用側プロセスに係る処理要求受信件数から処理結果返信件数を減算して未完了の処理要求件数を求め、これを全サービス利用側プロセス分積算する機能と、このサービス提供側プロセス毎の全サービス利用側プロセスに係る未完了の処理要求件数から、各サービス利用側プロセスに係る未完了の処理要求件数を減算し、各サービス利用側プロセス毎の他要求件数を算出する機能と、この他要求件数を、対応のサービス利用側プロセスに係る処理要求振分部に送信する機能を備えたことを特徴としている。

請求項４に記載した負荷分散処理システムは、請求項３のシステムを前提とし、さらに上記負荷情報管理部が、上記処理結果をサービス利用側プロセスの処理要求振分部に返信するに際し、各サービス利用側プロセスに係る処理要求受信件数の集計値と、各サービス利用側プロセスに係る処理結果返信件数の集計値を算出し、処理結果と共に処理要求振分部に送信する機能を備えており、上記処理要求振分部が、この処理要求受信件数の集計値から処理結果返信件数の集計値を減算し、その差から自要求件数を減算した他要求件数を算出する機能と、この他要求件数によって、上記第１の記憶領域における該当のサービス提供側プロセスに係る他要求件数を更新する機能を備えたことを特徴としている。

請求項５に記載した負荷分散処理システムは、請求項１〜４のシステムを前提とし、さらに上記処理要求振分部が、上記処理要求をサービス提供側プロセスの負荷情報管理部に送信するに際し、当該サービス提供側プロセスに係る未完了の処理要求件数が予め設定された閾値を超えているか否かを判定する機能と、上記閾値を超えている場合に、当該処理要求を一旦待機用の第４の記憶領域に格納する機能と、上記第１の記憶領域の格納情報が更新される度に、上記第４の記憶領域に格納された各処理要求について、上記第１の記憶領域を参照して未完了の処理要求件数が最も少ないサービス提供側プロセスを特定する機能と、当該サービス提供側プロセスの未完了の処理要求件数が予め設定された閾値以下か否かを判定し、上記閾値以下の場合に当該処理要求を対応のサービス提供側プロセスの負荷情報管理部に送信する機能を備えたことを特徴としている。

請求項６に記載した負荷分散処理システムは、請求項１〜５のシステムを前提とし、さらに上記サービス利用側プロセスが、予め設定されたタイミングで、予め設定されたルールに従って価格を算出し、この価格による、自己に割り当てられた数量分の新規注文情報を生成する処理を実行する、証券取引自動執行システムの複数の発注プロセスよりなり、上記サービス提供側プロセスが、上記発注プロセスとゲートウェイプロセスとの間に介在し、発注プロセスによって生成された注文情報を受け付けて上記ゲートウェイプロセスに送信すると共に、ゲートウェイプロセスから送信された証券取引所のコンピュータからの注文確認情報を上記発注プロセスに送信する処理を実行する複数の受付プロセスよりなり、上記処理要求振分部が、上記発注プロセスによって生成された注文情報を上記処理要求として上記受付プロセスの負荷情報管理部に送信すると共に、当該受付プロセスの負荷情報管理部から送信された上記注文確認情報を上記処理結果として上記発注プロセスに渡し、上記負荷情報管理部が、上記発注プロセスの処理要求振分部から上記処理要求としての注文情報を受信し、上記受付プロセスに渡すと共に、当該受付プロセスから渡された上記処理結果としての注文確認情報を、上記発注プロセスの処理要求振分部に送信することを特徴としている。

請求項７に記載した負荷分散処理システムは、請求項６のシステムを前提とし、さらに上記サービス利用側プロセスが、上記受付プロセスよりなり、上記サービス提供側プロセスが、上記ゲートウェイプロセスよりなり、上記処理要求振分部が、上記受付プロセスから渡された注文情報を上記処理要求として上記ゲートウェイプロセスの負荷情報管理部に送信すると共に、当該ゲートウェイプロセスの負荷情報管理部から送信された上記注文確認情報を上記処理結果として上記受付プロセスに渡し、上記負荷情報管理部が、上記受付プロセスの処理要求振分部から上記処理要求としての注文情報を受信し、上記ゲートウェイプロセスに渡すと共に、ゲートウェイプロセスから渡された上記処理結果としての注文確認情報を、上記受付プロセスの処理要求振分部に送信することを特徴としている。

請求項１に記載した負荷分散処理システムの場合、サービス提供側プロセス毎に設けられた負荷情報管理部によってサービス提供側プロセスの負荷情報（サービス利用側プロセス毎の処理要求受信件数及び処理結果返信件数）が管理され、この負荷情報が定期的に負荷情報配信部に送信される。また、サービス利用側プロセス毎に設けられた処理要求振分部に対しては、負荷情報配信部から定期的にサービス利用側プロセス毎の負荷情報（未完了の処理要求件数）が配信される。この結果、各サービス利用側プロセスの処理要求振分部は、サービス利用側プロセスで生成された処理要求を送信する際に、上記の負荷情報を参照することにより、最も負荷の小さいサービス提供側プロセスに対して処理要求を送信することが可能となる。この負荷情報は、CPU負荷情報ではなく、未完了の処理要求件数からなるため、各サービス提供側プロセスの実際の負荷状況を正確に表しているといえる。
しかも、処理要求及び処理結果は、サービス利用側プロセスの処理要求振分部とサービス提供側プロセスの負荷情報管理部間で直接やり取りされるため、特許文献１のように負荷分散処理装置を経由する場合に比べ、電文の送受信が効率化される。また、負荷分散処理装置に負荷が集中することによるシステム全体の性能低下が生じるおそれもない。
負荷情報の収集・配信もリアルタイムで行われるのではなく、所定の時間間隔でまとめて実行される仕組みであるため、負荷情報の頻発によってネットワーク負荷を徒に増大させることもない。

請求項３に記載した負荷分散処理システムの場合、上記請求項１の効果に加え、処理要求振分部が保持する負荷情報が自己が担当するサービス利用側プロセスによって発せられた「自要求件数」と他の全てのサービス利用側プロセスによって発せられた「他要求件数」とに分かれており、自要求件数の増減については処理要求振分部自身が管理する仕組みを備えているため、少なくとも自己が担当するサービス利用側プロセスに係る各サービス提供側プロセスの負荷情報については、負荷情報配信部からの配信を待つことなく、リアルタイムで最新の状態に維持することが可能となる。

請求項２及び４に記載した負荷分散処理システムの場合、負荷情報管理部がサービス提供側プロセスによる処理結果をサービス提供側プロセスの処理要求振分部に返信する際に、自己が担当するサービス提供側プロセスの現時点における負荷情報が一緒に返信され、処理要求振分部はこの最新の負荷情報に基づいて自己が管理する負荷情報を更新する仕組みを備えているため、処理結果を受け取る度に、少なくとも当該サービス提供側プロセスに係る負荷情報を最新の状態にすることができる。

請求項５に記載した負荷分散処理システムにあっては、最も負荷の小さいサービス提供側プロセスの未完了の処理要求件数が所定の閾値を超えている場合には、サービス提供側プロセス全体が高負荷状態にあると判断して当該処理要求を一旦待機用の第４の記憶領域に格納させ、高負荷状態が解消した後に処理要求を送信する仕組みを備えているため、何らかの理由によって高負荷状態に陥っているサービス提供側プロセスに対して機械的に処理要求が送信され続けて、システムダウン等の障害が発生する危険性を有効に回避することができる。

図１は、この発明に係る負荷分散処理システム80の全体構成を示す模式図であり、複数のサービス利用側プロセス81と、複数のサービス提供側プロセス82と、管理デーモン83とを備えている。この管理デーモン83は、「負荷情報配信部」に該当する。

また、サービス利用側プロセス81は、負荷分散処理用のＡＰＩ（Application Program Interface）を備えている。このサービス利用側ＡＰＩ84は、「処理要求振分部」に該当し、振分待ちの処理要求データを一時的に格納する振分待ち要求記憶領域（「第４の記憶領域」に該当）85と、処理要求キュー情報を格納する処理要求キュー情報記憶領域（「第１の記憶領域」に該当）86を備えている。

上記サービス提供側プロセス82は、負荷分散処理用のＡＰＩを備えている。このサービス提供側ＡＰＩ87は、「負荷情報管理部」に該当し、サービス提供側キュー情報を格納するサービス提供側キュー情報記憶領域（「第２の記憶領域」に該当）88を備えている。

上記サービス利用側ＡＰＩ84及びサービス提供側ＡＰＩ87は、それぞれ共通のミドルウェアによって提供される関数により構成される。
また、上記管理デーモン83は、このミドルウェアの常駐プログラムであり、管理デーモンキュー情報を格納する管理デーモンキュー情報記憶領域89を備えている。
各サービス利用側ＡＰＩ84と各サービス提供側ＡＰＩ87との間、各サービス利用側ＡＰＩ84と管理デーモン83との間、及び各サービス提供側ＡＰＩ87と管理デーモン83との間は、TCP/IP（Transmission Control Protocol/Internet Protocol）によって通信可能に接続されている。

この負荷分散処理システム80においては、処理要求データ及び処理結果データはあくまでもサービス利用側ＡＰＩ84及びサービス提供側ＡＰＩ87間で直接的に送受信され、管理デーモン83がこれを中継することはない。
また、各サービス提供側プロセスから管理デーモン83に対して、一定の間隔をおいて定期的に自らの負荷状況を示す情報が送信されると共に、管理デーモン83から各サービス利用側プロセスに対して、一定の間隔をおいて定期的に各サービス提供側プロセスの負荷状況を示す情報が送信される。
各サービス利用側プロセスは、管理デーモン83から送られてきた情報を参照し、最も負荷の少ないサービス提供側プロセスを自ら選択し、処理要求を送信する。
以下、図２及び図３のフローチャートに従い、この負荷分散処理システムの動作を説明する。

まず、サービス利用側プロセスにおいて何らかの処理要求が発生すると、サービス利用側ＡＰＩ84が当該サービス利用側プロセス81によって起動される（図２のＳ60）。このサービス利用側ＡＰＩ84は、サービス利用側プロセス81から処理要求を受け取ると（Ｓ61）、処理要求キュー情報を参照し、最も負荷の小さいサービス提供側プロセス82を特定する（Ｓ12）。

すなわち、処理要求キュー情報記憶領域86には、図４に示すように、サービス提供側ID（IPアドレス＋プロセスIDより構成される）、自要求件数、他要求件数のデータ項目を備えたレコードが、サービス提供側プロセス毎に格納されている。
ここで「自要求件数」とは、当該サービス利用側プロセス自身が当該サービス提供側プロセスに対して発した未完了の処理要求件数を意味しており、サービス利用側ＡＰＩ84によって随時更新される情報である。
これに対し「他要求件数」とは、当該サービス利用側プロセス以外のサービス利用側プロセスが当該サービス提供側プロセスに対して発した未完了の処理要求件数を意味しており、管理デーモン83から定期的に送信されるクライアントキュー情報に基づいてサービス利用側ＡＰＩ84が更新する情報である。
そこでサービス利用側ＡＰＩ84は、自要求件数と他要求件数の合計値が最小となるサービス提供側プロセス82を最も負荷の小さいサービス提供側プロセスと認定する。

つぎにサービス利用側ＡＰＩ84は、この現状で最も負荷の小さいサービス提供側プロセスに係る「自要求件数＋他要求件数」の値が、予め設定された閾値よりも大きいか否かを判定する（Ｓ63）。
ここでYESの判定結果となった場合には、当該サービス提供側プロセスが高負荷状態にあることを意味するため、サービス利用側ＡＰＩ84は直ちに処理要求を発することを控える。具体的には、当該処理要求データを振分待ち要求記憶領域85に一旦格納する（Ｓ84）。

これに対し、Ｓ63においてNOの判定結果が出た場合には、サービス利用側ＡＰＩ84は当該サービス提供側プロセス82のレコードの「自要求件数」の値に「１」を加算した後（Ｓ65）、当該サービス提供側プロセス82に対して処理要求を送信する（Ｓ66）。
なお、自要求件数と他要求件数の合計値が最小となるサービス提供側プロセス82が複数存在した場合、サービス利用側ＡＰＩ84は所定のルール（例えばラウンドロビン方式）に従って一のサービス提供側プロセス82を選択し、処理要求を送信する。

これを受けたサービス提供側ＡＰＩ87は、サービス提供側キュー情報記憶領域88を検索し、当該サービス利用側プロセス81のレコードを抽出する（Ｓ67）。
すなわち、サービス提供側キュー情報記憶領域88には、図５に示すように、サービス利用側ID（IPアドレス＋プロセスIDより構成される）、処理要求受信件数、処理要求返信件数のデータ項目を備えたレコードが、サービス利用側プロセス81毎に格納されている。
このためサービス提供側ＡＰＩ87は、サービス利用側プロセス81から送信された処理要求に含まれるIPアドレス及びプロセスIDにより、当該サービス利用側プロセス81のレコードを特定することができる。

因みに、「処理要求受信件数」は当該サービス利用側プロセス81から受信した処理要求の累積件数を記録しておくデータ項目であり、「処理要求返信件数」は当該サービス利用側プロセス81に対して送信した処理結果の累積件数を記録しておくデータ項目であり、何れもサービス提供側ＡＰＩ87によって随時更新される。
この処理要求受信件数から処理要求返信件数を減ずることにより、現在処理中の未完了の処理要求件数を割り出すことが可能となる。

つぎにサービス提供側ＡＰＩ87は、抽出したサービス利用側プロセス81のレコードの処理要求受信件数に「１」を加算し（Ｓ68）、当該処理要求とレコードを関連付けた後（Ｓ69）、サービス提供側プロセス82に対して当該処理要求を渡す（Ｓ70）。

これを受け取ったサービス提供側プロセス82は、必要な処理を実行する。
そして、サービス提供側ＡＰＩ87がサービス提供側プロセス82から処理結果を受け取ると（Ｓ71）、当該サービス利用側プロセス81のレコードの処理要求返信件数に「１」を加算する（Ｓ72）。

つぎに、サービス提供側ＡＰＩ87は、サービス提供側キュー情報のサマリ情報を生成する（Ｓ73）。
このサービス提供側キュー情報のサマリ情報は、図６に示すように、処理要求受信件数及び処理要求返信件数のデータ項目を備えており、「処理要求受信件数」には当該サービス提供側プロセス82が応対した全サービス利用側プロセス81に係る処理要求件数の総計値が、また「処理要求返信件数」には当該サービス提供側プロセス82が応対した全サービス利用側プロセス81に係る処理要求件数の総計値が格納される。
このためにサービス提供側ＡＰＩ87は、サービス提供側キュー情報の全レコードに係る処理要求受信件数を加算してサマリ情報の処理要求受信件数を算出し、同じくサービス提供側キュー情報の全レコードに係る処理要求返信件数を加算してサマリ情報の処理要求返信件数を算出する。

つぎにサービス提供側ＡＰＩ87は、処理結果及びサマリ情報をサービス利用側ＡＰＩ84に返信する（Ｓ74）。
これを受けたサービス利用側ＡＰＩ84は、サービス提供側プロセス82の「IPアドレス＋プロセスID」をキーにして、処理要求キュー情報記憶領域86を検索し、当該サービス提供側プロセス82のレコードを抽出する（Ｓ75）。
つぎにサービス利用側ＡＰＩ84は、当該レコードの「自要求件数」から「１」を減算した後（Ｓ76）、サービス利用側プロセス81に処理結果を渡す（Ｓ77）。

つぎにサービス利用側ＡＰＩ84は、サービス提供側ＡＰＩ87から送信されたサマリ情報に基づいて、当該サービス提供側プロセス82のレコードにおける「他要求件数」を更新する（Ｓ78）。
具体的には、サマリ情報の処理要求受信件数から処理要求返信件数を減算し、その算出結果からさらに自要求件数を減算することにより、最新の「他要求件数」が得られるため、この値によって上記レコードの「他要求件数」を上書きする。

一方、サービス提供側ＡＰＩ87は、予め設定されたタイミングが到来する都度（Ｓ79）、各サービス利用側プロセス81に係るサービス提供側キュー情報の全レコードを、管理デーモン83に対して送信する（Ｓ80）。

これを受けた管理デーモン83は、管理デーモンキュー情報記憶領域89を検索し、当該サービス提供側プロセス82に係る各サービス利用側プロセス81のレコードを抽出する（Ｓ81）。
すなわち、管理デーモンキュー情報記憶領域89には、図７に示すように、サービス提供側ID（IPアドレス＋プロセスID）、サービス利用側ID（IPアドレス＋プロセスID）、処理要求受信件数、処理要求返信件数のデータ項目を備えたレコードが、サービス提供側プロセス×サービス利用側プロセス毎に格納されている。
このため管理デーモン83は、サービス提供側プロセス82から送信されたIPアドレス及びプロセスIDにより、当該サービス提供側プロセス82に係る全レコードを抽出した後、各サービス提供側キュー情報のサービス利用側IDに基づいて対応のレコードを特定することができる。

つぎに管理デーモン83は、当該サービス提供側プロセス82から送信されたサービス提供側キュー情報によって管理デーモンキュー情報の処理要求受信件数及び処理要求返信件数を上書き更新する（Ｓ82）。
上記のサービス提供側キュー情報は、各サービス提供側プロセス82から非同期で定期的に送信され、これを受けた管理デーモン83は、その都度、管理デーモンキュー情報の当該サービス提供側プロセス82に係るレコードを更新する。

また管理デーモン83は、予め設定されたタイミングが到来する都度（Ｓ83）、管理デーモンキュー情報に基づいてクライアントキュー情報を生成する（Ｓ84）。
このクライアントキュー情報は、図８に示すように、サービス提供側ID（IPアドレス＋プロセスID）及び他要求件数のデータ項目を備えており、サービス利用側プロセス81毎に各サービス提供側プロセス82における「他要求件数（当該サービス利用側プロセス以外のサービス利用側プロセスに係る未完了の処理要求件数の合計値）」が算出され、クライアントキュー情報となされる。

例えば、図９に示すように、サービス提供側プロセスＸの処理中（未完了）の件数が１０件あり、その中、サービス利用側プロセスＡの分が２件、サービス利用側プロセスＢの分が５件、サービス利用側プロセスＣの分が３件であった場合、処理中の全件数−各サービス利用側プロセス分の件数により、サービス提供側プロセスＸの各サービス利用側プロセス向けの「他要求件数」が、Ａ用＝８件、Ｂ用＝５件、Ｃ用＝７件のように算出される。

また、サービス提供側プロセスＹの処理中の件数が１５件あり、その中、サービス利用側プロセスＡの分が７件、サービス利用側プロセスＢの分が２件、サービス利用側プロセスＣの分が６件であった場合、処理中の全件数−各サービス利用側プロセス分の件数により、サービス提供側プロセスＹの各サービス利用側プロセス向けの「他要求件数」が、Ａ用＝８件、Ｂ用＝１３件、Ｃ用＝９件のように算出される。

同様に、サービス提供側プロセスＺの処理中の件数が２０件あり、その中、サービス利用側プロセスＡの分が８件、サービス利用側プロセスＢの分が６件、サービス利用側プロセスＣの分が６件であった場合、処理中の全件数−各サービス利用側プロセス分の件数により、サービス提供側プロセスＺの各サービス利用側プロセス向けの「他要求件数」が、Ａ用＝１２件、Ｂ用＝１４件、Ｃ用＝１４件のように算出される。

最後に、サービス利用側プロセス81毎に各サービス提供側プロセス82における他要求件数を集約することにより、各サービス利用側プロセス81向けのクライアントキュー情報ができあがる。
つぎに管理デーモン83は、各サービス利用側プロセス向けのクライアントキュー情報を、対応のサービス利用側ＡＰＩ84に送信する（Ｓ85）。

これを受けた各サービス利用側ＡＰＩ84は、処理要求キュー情報中の各サービス提供側プロセス82に係る他要求件数を上書きする（Ｓ86）。
上記のＳ78においては、処理結果と共にサービス提供側ＡＰＩ87から送信されたサマリ情報に基づいて、当該サービス提供側プロセス82に係る他要求件数のみが更新されたのに対し、このＳ86においては、全サービス提供側プロセス82に係る他要求件数が一斉に更新される点で、両処理は内容を異にしている。

ところで、上記のＳ68において、最も負荷の小さいサービス提供側プロセス82に係る「自要求件数＋他要求件数」の値が所定の閾値よりも大きい場合には、Ｓ64において当該処理要求データを振分待ち要求記憶領域85に格納する旨を記載したが、図１０のフローチャートに従い、この振分待ち要求の取扱いについて説明する。

まず、上記のＳ76やＳ78、Ｓ86のように処理要求キュー情報の更新がある都度（Ｓ90）、サービス利用側ＡＰＩ84は処理要求キュー情報を参照して最も負荷の小さいサービス提供側プロセス82を特定し（Ｓ91）、このサービス提供側プロセス82に係る「自要求件数＋他要求件数」の値が、予め設定された閾値以下か否かを判定する（Ｓ92）。
そして、当該サービス提供側プロセス82に係る「自要求件数＋他要求件数」が所定の閾値以下となった場合、サービス利用側ＡＰＩ84は当該サービス提供側プロセス82のレコードの「自要求件数」の値に「１」を加算した後（Ｓ93）、当該サービス提供側プロセス82に対して処理要求を送信する（Ｓ94）。

サービス提供側プロセス82から処理結果が返信されると（Ｓ96）、サービス利用側ＡＰＩ84は、サービス提供側プロセス82の「IPアドレス＋プロセスID」をキーにして処理要求キュー情報記憶領域86を検索し、当該サービス提供側プロセス82のレコードを抽出する（Ｓ97）。
つぎにサービス利用側ＡＰＩ84は、当該レコードの「自要求件数」から「１」を減算した後（Ｓ98）、サービス利用側プロセス81に処理結果を渡す（Ｓ99）。

上記においては、この負荷分散処理システム10が、ミドルウェアのＡＰＩ（サービス利用側ＡＰＩ84及びサービス提供側ＡＰＩ87）及び管理デーモン83によって実現される例を示したが、この発明はこの実施形態に限定されるものではなく、サービス利用側ＡＰＩ84、サービス提供側ＡＰＩ87及び管理デーモン83と同様の機能を備えた独立のプログラムによって構成することもできる。

上記のように、この負荷分散処理システム10の場合、処理要求と処理結果をサービス利用側プロセス81とサービス提供者プロセス82の間で直接的にやり取りする方式であり、特許文献１のように負荷分散処理装置によって中継される仕組みではないため、伝送遅れが生じることはない。
また、各サービス提供側プロセス82の現在の負荷状況を示す処理要求キュー情報は、サービス提供側プロセス82から処理結果が返信される都度、または管理デーモン83からクライアントキュー情報が送信される都度、最新のものに更新される仕組みを備えているため、各サービス提供側プロセス82の実際の負荷を反映させた処理要求の振分が可能となる。

このように、この負荷分散処理システム10の場合には、サービス提供側プロセス82の実際の負荷を反映させた分散処理が可能であり、しかも処理要求と処理結果が高速で伝達されるという特性を備えているため、瞬時に大量の注文情報を捌くことが求められる株式の自動執行システムなどに好適である。
以下、図１１〜図２９に基づいて証券取引自動執行システムについて説明した後、図３０及び図３１に基づき、この発明を証券取引自動執行システムに適用した例を説明する。

図１１は、証券取引自動執行システム10の全体構成を示すブロック図であり、設定登録部12と、アルゴリズムＤＢ14と、執行制御部16と、注文分割部18と、複数の発注部20と、ボリュームカーブ選択部21と、ボリュームカーブ変更部22とを備えている。
設定登録部12、執行制御部16、注文分割部18、各発注部20、ボリュームカーブ選択部21及びボリュームカーブ変更部22は、コンピュータのCPUがOS及び専用のアプリケーションプログラムに従って必要な処理を実行することにより実現される。また、アルゴリズムＤＢ14は、同コンピュータのハードディスク内に設けられている。

設定登録部12及び執行制御部16には、通信ネットワークを介してトレーダの操作するクライアント端末23が接続されている。
また、執行制御部16は、通信ネットワークを介して証券取引所のコンピュータ24と接続されている。証券取引所のコンピュータ24から執行制御部16に対しては、市況データ（銘柄コード毎の現在値データ、気配値データ、出来高データ等）及び約定データ（注文ID、約定数量、約定価格、約定日時等）が断続的に送信される。

このシステム10を利用するに当たり、トレーダは事前に複数の自動執行用アルゴリズムを設定し、アルゴリズムＤＢ14内に登録しておく必要がある。
このためにトレーダは、クライアント端末23上に専用のアプリケーションプログラムを立ち上げて設定登録部12にアクセスし、アルゴリズム設定画面をディスプレイに表示させる。
図１２は、クライアント端末23のディスプレイに表示されたアルゴリズム設定画面30の一例を示すものであり、左側ペイン31にはアルゴリズム32、ボリュームカーブ選択部品33、ボリュームカーブ変更部品34、注文分割部品35、発注部品36の各設定項目がツリー状に配置されている。

ここでトレーダは、アルゴリズム32の枝を選択した状態で右クリックを行い、展開される右クリックメニュー中から「アルゴリズムの追加」を選択し、アルゴリズム名をタイプ入力する。この結果、アルゴリズム32の配下に新しいアルゴリズム名が追加される。ここでは、「VWAP戦略」が新たに追加されたものとする。

つぎにトレーダは、追加した「VWAP戦略」を選択した状態で、右側ペイン37に表示されたボリュームカーブ選択部品指定欄38、ボリュームカーブ変更部品指定欄39、注文分割部品指定欄40に対し、具体的なボリュームカーブ選択部品名、ボリュームカーブ変更部品名、注文分割部品名を選択入力する。またトレーダは、発注部品指定欄41において、表示された発注部品のニモニック（ここでは「$LimitOrder」が表示されている）と関連付けられるべき発注部品を選択入力する。

ここで「ボリュームカーブ」とは、注文総数に対する執行率の推移と時間の経過との対応関係を示した曲線を意味し、執行のペースを規定する発注スケジュール定義データと同義である。図１３はボリュームカーブの一例を示すものであり、銘柄ごとに証券取引所における一日の取引時間と出来高の対応関係を複数日間で平均化した曲線が描かれている。これは、例えばVWAPといわれる、取引所における対象銘柄の出来高加重平均を約定価格のターゲットとするアルゴリズムにおいて採用される。これ以外にも、例えばArrivalPriceといわれるアルゴリズムでは、過去の銘柄の統計値にしたがって理論的にマーケットインパクトを最小化するような曲線を演算によってもとめたものが、ボリュームカーブとして用いられる。

「ボリュームカーブ選択部品」とは、当該アルゴリズムの起動時に予め設定された条件の判定を行い、適用されるべきボリュームカーブを決定する機能を発揮するプログラム部品を意味している。このボリュームカーブ選択部品をインスタンス化することにより、上記のボリュームカーブ選択部21が生成される。
図においては、「サンプルVWAP1」という名前のボリュームカーブ選択部品が指定されている。
なお、具体的なボリュームカーブのデータは、アルゴリズムＤＢ14に格納されている。

「ボリュームカーブ変更部品」とは、当該アルゴリズムの実行中に、予め設定されたタイミングで変更条件の判定を行い、ボリュームカーブに必要な変更を加える機能を発揮するプログラム部品を意味している。このボリュームカーブ変更部品をインスタンス化することにより、上記のボリュームカーブ変更部22が生成される。
図においては、「サンプル５分先行」という名前のボリュームカーブ変更部品が指定されている。

「注文分割部品」とは、与えられた注文総数を所定のルールに従って複数の個別注文に分割すると共に、個別注文毎に当該注文処理を担当する発注部品をインスタンス化し、算出した個別注文数量を割り当てる機能を発揮するプログラム部品を意味している。この注文分割部品をインスタンス化することにより、上記の注文分割部18が生成される。
図においては、「５分スライス」という注文分割部品が選択されている。

「発注部品」とは、注文分割部18によって割り当てられた数量の個別注文情報を執行制御部16を介して証券取引所のコンピュータ24に送信すると共に、所定のロジックに従って価格を操作することにより、できるだけ有利な価格での約定の成立を追求する機能を発揮するプログラム部品を意味している。この発注部品をインスタンス化することにより、上記の発注部20が生成される。
図においては、「$LimitOrder」という発注部品のニモニック（略称）に対して「５分後譲歩」という発注部品が関連付けられている。詳細は後述するが、この発注部品のニモニックは、注文分割部品指定欄40において選択された注文分割部品の設定時に、トレーダによって命名されたものである。

図１４は、アルゴリズムの設定項目をまとめたものである。これらボリュームカーブ選択部品の指定、ボリュームカーブ変更部品の指定、注文分割部品の指定、発注部品のニモニックと発注部品との関連付けを完了したトレーダは、メニューバーの「ファイル(F)→保存(S)」を順にクリックすることにより、設定の登録を求める。これを受けた設定登録部12は、「ボリュームカーブ選択部品：サンプルVWAP1、ボリュームカーブ変更部品：サンプル５分先行、注文分割部品：５分スライス、発注部品のニモニック（$LimitOrder）＝：５分後譲歩」の組合せ情報を、「VWAP戦略」のアルゴリズム名に関連付けてアルゴリズムＤＢ14に格納する。

図１２のアルゴリズム設定画面30においては、「VWAP戦略」以外にも「パーティシペーション」、「オポチュニティ」、「PEG最良気配」といったアルゴリズム名が列記されているが、各アルゴリズムについても上記したボリュームカーブ選択部品の指定、ボリュームカーブ変更部品の指定、注文分割部品の指定、発注部品のニモニックと発注部品との関連付けが原則としてなされている。ただし、アルゴリズムによっては注文分割部18が個別注文数量を算出する際にボリュームカーブを参照する必要のないものもあり、この場合にはボリュームカーブ選択部品の指定及びボリュームカーブ変更部品の指定は省略される。また、最初に選択したボリュームカーブを途中で変更する必要がない場合には、ボリュームカーブ選択部品の指定のみがなされ、ボリュームカーブ変更部品の指定は省略される。

トレーダは、独自のアルゴリズムを設定するために、事前に自分専用のボリュームカーブ選択部品、ボリュームカーブ変更部品、注文分割部品、発注部品を設定しておく。

まずボリュームカーブ選択部品の設定について説明すると、図１５に示すように、アルゴリズム設定画面30の左側ペイン31においてボリュームカーブ選択部品33の枝を選択した状態で右クリックを行い、展開される右クリックメニュー中から「ボリュームカーブ選択部品の追加」を選択し、ボリュームカーブ選択部品名をタイプ入力する。この結果、ボリュームカーブ選択部品33の配下に新しいボリュームカーブ選択部品名が追加される。ここでは、「サンプルVWAP1」が新たに追加されたものとする。

ボリュームカーブ選択部品に関しては、アルゴリズム起動時の状況に応じてボリュームカーブを切り替え可能とするために、複数の動作モードを設定しておくことができる。具体的には、アルゴリズム設定画面30の左側ペイン31において「サンプルVWAP1」の枝を選択した状態で右クリックを行い、展開される右クリックメニュー中から「動作モードの追加」を選択し、動作モード名をタイプ入力する。この結果、「サンプルVWAP1」の配下に新しい動作モードが追加される。図においては、「通常日」及び「SQ日」の２つの動作モードが設けられている。ここで「SQ日」とは、先物・オプション取引の清算日を意味している。

つぎにトレーダは、追加した動作モードを選択した状態で、右側ペイン37に表示されたボリュームカーブ選択入力欄42に対し、特定のボリュームカーブを選択入力する。また、適用条件入力欄43に対して、具体的な設定値を打鍵入力する。
図においては、「SQ日」の動作モードが選択されており、そのボリュームカーブとして「VWAP」が、また適用条件として「SQ日」が設定されている。これは、アルゴリズムの起動時がSQ日に該当する場合には、ボリュームカーブとして「VWAP」が参照されるべきことがルール化されていることを意味している。

図１６は、ボリュームカーブ選択部品に係る設定項目をまとめたものである。これら動作モードの生成、各動作モードにおけるボリュームカーブの指定及び適用条件の指定を完了したトレーダは、メニューバーの「ファイル(F)→保存(S)」を順にクリックすることにより、設定の登録を求める。これを受けた設定登録部12は、ボリュームカーブ選択部品の共通機能について記述された雛形のプログラムコードに対して、トレーダが選択入力した設定事項に対応したコードを付加して固有のボリュームカーブ選択部品を自動生成し、「サンプルVWAP1」のプログラム部品名に関連付けてアルゴリズムＤＢ14に格納する。

つぎにトレーダは、ボリュームカーブ変更部品の設定に移る。すなわち、図１７に示すように、アルゴリズム設定画面30の左側ペイン31においてボリュームカーブ変更部品34の枝を選択した状態で右クリックを行い、展開される右クリックメニュー中から「ボリュームカーブ変更部品の追加」を選択し、ボリュームカーブ変更部品名をタイプ入力する。この結果、ボリュームカーブ変更部品34の配下に新しいボリュームカーブ変更部品名が追加される。ここでは、「サンプル５分先行」が新たに追加されたものとする。

ボリュームカーブ変更部品に関しては、アルゴリズム実行中の状況変化に応じてボリュームカーブの柔軟な調整を可能とするために、複数の動作モードを設定しておくことができる。具体的には、アルゴリズム設定画面30の左側ペイン31において「サンプル５分先行」の枝を選択した状態で右クリックを行い、展開される右クリックメニュー中から「動作モードの追加」を選択し、動作モード名をタイプ入力する。この結果、「サンプル５分先行」の配下に新しい動作モードが追加される。図においては、「受注時」の動作モードのみが設けられているが、複数の動作モードを生成することも可能である

つぎにトレーダは、追加した動作モードを選択した状態で、右側ペイン37に表示されたタイミング選択入力欄44、変更条件入力欄45、アクション入力欄46に対し、具体的な設定値を入力する。
図においては、タイミングとして「新規案件」が選択入力されている。また、アクションとして「ボリュームカーブ調整（分, 5.0）」が入力されている。これは、トレーダからの新規案件の発注がなされた場合には、現在のボリュームカーブを５分間進めることがルール化されていることを意味している。
ここでは変更条件入力欄45がブランクであるため、新規案件のタイミングに合致する場合には常にボリュームカーブが５分間進められることとなるが、変更条件入力欄45に条件式を予め入力しておくことにより、より細かい制御を行うこともできる。例えば、条件式として「新規案件の注文数量が注文総数の３％超えること」を所定の文法で記述しておくことが該当する。

図１８は、ボリュームカーブ変更部品に係る設定項目をまとめたものである。これら動作モードの生成、各動作モードにおけるタイミングの指定、変更条件の設定、アクションの設定を完了したトレーダは、メニューバーの「ファイル(F)→保存(S)」を順にクリックすることにより、設定の登録を求める。これを受けた設定登録部12は、ボリュームカーブ変更部品の共通機能について記述された雛形のプログラムコードに対して、トレーダが選択入力した設定事項に対応したコードを付加して固有のボリュームカーブ変更部品を自動生成し、「サンプル５分先行」のプログラム部品名に関連付けてアルゴリズムＤＢ14に格納する。

つぎにトレーダは、注文分割部品の設定に移る。すなわち、図１９に示すように、アルゴリズム設定画面30の左側ペイン31において注文分割部品35の枝を選択した状態で右クリックを行い、展開される右クリックメニュー中から「注文分割部品の追加」を選択し、注文分割部品名をタイプ入力する。この結果、注文分割部品35の配下に新しい注文分割部品名が追加される。ここでは、「５分スライス」が新たに追加されたものとする。

注文分割部品に関しても、予め１または複数の動作モードを設定しておく。具体的には、アルゴリズム設定画面30の左側ペイン31において「５分スライス」の枝を選択した状態で右クリックを行い、展開される右クリックメニュー中から「動作モードの追加」を選択し、動作モード名をタイプ入力する。この結果、「５分スライス」の配下に新しい動作モードが追加される。図においては、「スライス」の動作モードのみが設けられている。

つぎにトレーダは、追加した「スライス」の動作モードを選択した状態で、右側ペイン37に表示されたタイミング選択入力欄48、条件入力欄49及び内容入力欄50に対し、具体的な設定値を選択入力する。

ここでタイミング選択入力欄48は、発注部品をインスタンス化して発注部20を生成し、新たな注文を発するか否かを判定する際の時間的条件を規定する項目であり、図においては「５分間隔」で判定を行うべき旨が規定されている。

また条件入力欄49は、発注部品をインスタンス化して新規注文を発するか否かの判定ルール（基準）を規定する項目であり、図においては「ボリュームカーブ比率を参照し、現時点までの約定数量が予定よりも遅れている場合には新規注文を発すべき」ことを指定する条件式が独自の文法で記述されている。

内容入力欄50は、発注部品のニモニック入力欄50(a)、割当数量入力欄50(b)、丸め方法選択欄50(c)から成り立っている。トレーダは、発注部品のニモニック入力欄50(a)に発注処理を担うべき発注部品の任意のニモニックを入力する。つぎにトレーダは、割当数量入力欄50(b)に数量算出のルールを入力する。具体的には、「式設定」のボタンをクリックして入力ウィンドウを開き、例えば「ボリュームカーブを参照して現時点における予定数量を算出し、この予定数量から現時点までの約定数量を減じた差を割当数量とする」ことを規定する計算式を、独自の文法で記述する。最後にトレーダは、丸め方法選択欄50(c)に割当数量に端数が生じた場合の丸め方法（四捨五入や切り捨て等）を選択入力する。

図２０は、注文分割部品に係る設定項目をまとめたものである。これら動作モードの生成、各動作モードにおけるタイミングの指定、条件の設定、内容の設定（発注部品のニモニックの入力、割当数量の計算式の入力、丸め方法の選択）を完了したトレーダは、メニューバーの「ファイル(F)→保存(S)」を順にクリックすることにより、設定の登録を求める。これを受けた設定登録部12は、注文分割部品の共通機能について記述された雛形のプログラムコードに対して、トレーダが選択入力した設定事項に対応したコードを付加して固有の注文分割部品を自動生成し、「５分スライス」のプログラム部品名に関連付けてアルゴリズムＤＢ14に格納する。

つぎにトレーダは、発注部品の定義に移る。すなわち、図２１に示すように、アルゴリズム設定画面30の左側ペイン31において発注部品36の枝を選択した状態で右クリックを行い、展開される右クリックメニュー中から「発注部品の追加」を選択し、発注部品名をタイプ入力する。この結果、発注部品36の配下に新しい発注部品名が追加される。ここでは、「５分後譲歩」が新たに追加されたものとする。

この発注部品に関しても、トレーダの価格戦略をより柔軟に具現化するために、１または複数の動作モードを設定しておくことができる。具体的には、アルゴリズム設定画面30の左側ペイン31において「５分後譲歩」の枝を選択した状態で右クリックを行い、展開される右クリックメニュー中から「動作モードの追加」を選択し、動作モード名をタイプ入力する。この結果、「５分後譲歩」の配下に新しい動作モードが追加される。図においては、「新規発注」、「PEG動作」、「５分後に譲歩」の３つの動作モードが設けられている。
この動作モードの数に制限はないが、少なくとも「新規発注」に相当する動作モードは設けられる必要がある。

つぎにトレーダは、追加した動作モードを選択した状態で、右側ペイン37に表示されたタイミング選択入力欄52、条件入力欄53、アクション入力欄54に対し、具体的な設定値を選択入力する。
図においては、「PEG動作」が選択されており、そのタイミングとして「時価情報」が選択入力されている。この「タイミング」とは、当該動作モードが発動されるべき時間的条件を意味しており、「時価情報」の値は「時価が変動した場合」を意味している。

また、条件入力欄53は価格を変更するか否かの判定ルールを規定する項目であり、図においては「現在の最良気配と自己の指値を比較し、両者に乖離が生じていた場合には訂正注文を発すべき」旨の条件式が独自の文法で記述されている。
アクション入力欄54は、注文の種別（新規注文／訂正注文）及びその価格を算出するためのルールを規定する項目であり、図においては「自己の注文価格を市場の最良気配価格（ただし執行制限値段内）に訂正する」旨が設定されている。

トレーダは、「新規発注」、「PEG動作」、「５分後に譲歩」のそれぞれの動作モードについて、上記の「タイミング」、「条件」、「アクション」を設定する。
図２２は、「５分後譲歩」の発注部品に係る設定内容を模式的に示すものであり、 「新規発注」については、タイミングとして「生成直後」が、アクションとして「新規発注／最良気配価格」が設定されている。新規発注の場合には、単純に新規注文情報を取引所のコンピュータに送信するだけで済むため、条件についてはブランクとなされている。

また、「５分後に譲歩」については、タイミングとして「生成後５分経過時」が、アクションとして「価格訂正／逆最良気配価格」が設定されている。「５分後に譲歩」の場合にも、時間的条件（タイミング）だけで発注が決まり、その要否を判定する必要がないため、条件についてはブランクとなされている。

図２３は、発注部品に係る設定項目をまとめたものである。これら動作モードの生成、各動作モードにおけるタイミングの指定、条件の設定、アクションの設定を完了したトレーダは、メニューバーの「ファイル(F)→保存(S)」を順にクリックすることにより、設定の登録を求める。これを受けた設定登録部12は、発注部品の共通機能について記述された雛形のプログラムコードに対して、トレーダが選択入力した設定事項に対応したコードを付加して固有の発注部品を自動生成し、「５分後譲歩」のプログラム部品名に関連付けてアルゴリズムＤＢ14に格納する。

図２４は、このシステム10におけるアルゴリズムの構成を示すものであり、各アルゴリズムはボリュームカーブ選択部品と、ボリュームカーブ変更部品と、注文分割部品を備えており、注文分割部品は動作モードに応じた複数の発注部品を備えている。ただし、注文分割部品について、ボリュームカーブを参照することなく個別の発注数量を算出するルールが規定されている場合には、ボリュームカーブ選択部品及びボリュームカーブ変更部品の指定は不要となる。また、注文分割部品が単一の動作モードのみを備えている場合には、発注部品は一つとなる。したがって、アルゴリズムの最小構成としては、一つの注文分割部品と一つの発注部品の組合せということになる。

先に図１２に基づいて説明したように、トレーダはアルゴリズム構成の設定画面において、ボリュームカーブ選択部品、ボリュームカーブ変更部品、注文分割部品を選択入力すると共に、発注部品のニモニックと発注部品名との関連付けを行う。

つぎに、この自動執行システム10の利用方法について説明する。
まずトレーダは、クライアント端末23から執行制御部16にアクセスし、図２５に示すように、ディスプレイに自動執行リクエスト画面60を表示させた後、自動執行の細目を設定する。
すなわち、売買種別選択欄61に「買い／売り」の種別を選択入力すると共に、銘柄コード入力欄62に銘柄コードを入力し、市場選択欄63において任意の証券取引所を選択入力し、数量入力欄64に注文総数を入力し、約定価格に上限または下限がある場合には執行制限値段入力欄65に具体的な価格を入力する。つぎに、アルゴリズム選択欄66において▼ボタンをクリックすると、当該トレーダが設定したアルゴリズム名が列挙されたプルダウンメニューが表示されるため、利用を希望するアルゴリズム名を選択する。

ここで、ユーザが選択したアルゴリズムの構成中に、パラメータの補充が必要なルールが含まれている場合、パラメータ入力欄67に項目名及び型が表示されるため、トレーダは値入力欄67aに具体的なパラメータを入力する。
例えば、注文分割部品の設定に際し、割当数量入力欄50bに「市場出来高のＸ％分の数量を注文数量とする」という算出ルールが設定されていた場合、パラメータ入力欄67において、項目名に「関与率」が、型に「小数」が表示される。これに対しトレーダは、値として「0.3」等の具体的な数値を入力する。

以上の設定を終了したユーザは、実行ボタン68をクリックし、自動執行システム10の執行制御部16に対して自動執行を指令する。

つぎに、図２６のフローチャートに従い、執行制御部16の動作について説明する。まず、クライアント端末23から売買種別、銘柄コード、市場、数量、アルゴリズム等の指定を伴う自動執行リクエストを受信した執行制御部16は（Ｓ10）、アルゴリズムＤＢ14を参照し、指定されたアルゴリズム（VWAP戦略）に係るボリュームカーブ選択部品、ボリュームカーブ変更部品、注文分割部品、発注部品を特定する（Ｓ12）。

つぎに執行制御部16は、対応のボリュームカーブ選択部品、ボリュームカーブ変更部品及び注文分割部品をインスタンス化し、ボリュームカーブ選択部21、ボリュームカーブ変更部22及び注文分割部18を生成する（Ｓ14）。
つぎに執行制御部16は、注文分割部18に対して銘柄コード、売買種別、数量、発注部品名を渡す（Ｓ16）。

ボリュームカーブ選択部21は、現在時刻と所定の領域に格納されたカレンダー情報及びＳＱ日情報とを比較し、本日がSQ日か通常日かを判断し、この結果に基づいて適用すべきボリュームカーブ名を特定し、当該ボリュームカーブ名を執行制御部16に渡す。
執行制御部16は、注文分割部18から現時点におけるボリュームカーブ比率（予定執行率）について問合わせがある度に、アルゴリズムＤＢ14内に格納された対応のボリュームカーブデータを参照して現時点におけるボリュームカーブ比率を算出し、注文分割部18に返す。

執行制御部16はこの後も、注文分割部18や発注部20、ボリュームカーブ変更部22に対し、取引所のコンピュータ24から送信された市況データや約定データ、トレーダによる注文情報を随時提供する。

ボリュームカーブ変更部22は、執行制御部16から提供される市況データやトレーダによる注文情報を常時監視し、所定の変更条件に合致した場合には、予め設定されたボリュームカーブに対する必要な変更指令（例えば、ボリュームカーブを５分間早めるべきこと）を執行制御部16に渡す。
これ以降、執行制御部16は注文分割部18からボリュームカーブ比率についての問合わせがある場合には、上記の変更を加えたボリュームカーブ比率（例えば、現時点から５分後におけるボリュームカーブ比率）を注文分割部18に提供する。

つぎに、図２７のフローチャートに従い、注文分割部18の動作について説明する。ここでは、「５分スライス」の注文分割部品に基づいて注文分割部18が生成されたものとする。まず注文分割部18は、取引開始時刻が到来すると同時に、執行制御部16によって指定された発注部品、すなわち「５分後譲歩」をインスタンス化し、最初の発注部20を生成する（Ｓ20）。

この際、注文分割部18は執行制御部16に対して現時点におけるボリュームカーブ比率を問い合わせ、執行制御部16から渡されたボリュームカーブ比率に注文総数を乗ずることにより、最初の発注部20に渡す注文数量を算出する（Ｓ22）。
つぎに注文分割部18は、銘柄コード、売買種別及び今回の注文数量を発注部20に渡す（Ｓ24）。この後、発注部20から執行制御部16経由で証券取引所のコンピュータ24に対して対応の注文情報が送信されることとなるが、詳細は後述する。

最初の発注部20を生成してから５分経過後（Ｓ26）、注文分割部18は執行制御部16に対して現時点におけるボリュームカーブ比率を再度問い合わせ、執行制御部16から渡されたボリュームカーブ比率に注文総数を乗ずることにより、予定執行数量を算出する（Ｓ28）。
つぎに注文分割部18は、現時点までの執行完了数量（約定数量の累積値）と、上記の予定執行数量とを比較し、執行完了数量が予定執行数量を下回っている場合には（Ｓ30）、「５分後譲歩」の発注部品をインスタンス化し、つぎの発注部20を生成する（Ｓ32）。
そして、この発注部20に対し、銘柄コード、売買種別及び予定執行数量と執行完了数量との差分に該当する注文数量を渡す（Ｓ34）。

これに対し、Ｓ30において執行完了数量が予定執行数量以上であると判定された場合、注文分割部18は新たな発注部20の生成を今回は見送り、つぎのタイミングが到来するまで待機する。
この自動執行システム10においては、株式売買の自動執行を執行制御部16に指令した後も、トレーダは注文総数の範囲内で自らの判断に基づき個別の注文情報を執行制御部16に送信することができ、この注文情報は執行制御部16から取引所のコンピュータ24に送信される。また、このトレーダの判断に基づく個別注文に対して約定が成立した場合には、取引所のコンピュータ24から執行制御部16に対して約定報告データが送信される。このため、執行完了数量が予定執行数量を上回る事態が生じ得る。

注文分割部18は、設定された取引終了時刻が到来するまで、上記Ｓ28〜Ｓ34の処理を５分毎に繰り返し（Ｓ26、Ｓ36）、複数の発注部20を生成し続ける。ただし、取引終了時刻到来前に累積発注数が注文総数に達した場合には、その時点で処理を停止することとなる。

つぎに、図２８のフローチャートに従い、発注部20の動作について説明する。ここでは、「５分後譲歩」の発注部品に基づいて発注部20が生成されたものとする。
まず、生成直後の発注部20は、「新規発注」モードの設定に従い、以下の内容を備えた注文情報を生成し、執行制御部16経由でトレーダが指定した取引所のコンピュータ24に送信する（Ｓ40）。
銘柄コード：4307
売買種別：買い
数量：全割り当て数量
価格：現時点での最良気配価格（指値）
現時点での最良気配価格は、執行制御部16から送信された市況データに基づいて算出する。

新規に注文情報を発した後、発注部20は「PEG動作」モードに移行する。すなわち、発注部20は執行制御部16から送信される市況データを常時監視し、市場における時価に変動が生じると（Ｓ44）、現時点における最良気配価格と自己の指値との乖離を判定する（Ｓ46）。ここで、最良気配価格と自己の指値との間に乖離が存在する場合、発注部20は指値を現在の最良気配価格に訂正するための訂正注文情報を生成し、執行制御部16経由で取引所のコンピュータ24に送信する（Ｓ48）。
発注部20は、この最良気配価格に追従するための処理を、自己の注文の全数量について約定が成立するまで（Ｓ42）、あるいは新規注文情報を送信してから５分を経過するまで継続する。

約定が成立しないまま５分間が経過すると（Ｓ50）、発注部20は「５分後に譲歩」モードに移行し、注文価格を「逆最良気配価格」に変更する価格訂正注文情報を生成し、執行制御部16経由で取引所のコンピュータ24に送信する（Ｓ52）。
「逆最良気配価格」とは、買い注文を発している場合には売り側の最良気配価格を、売り注文を発している場合には買い側の最良気配価格を意味し、指値をこの価格に変更することにより、高い確度で約定を成立させることが可能となる。この逆最良気配価格は、執行制御部16から送信される市況データに基づいて算出される。

この「５分後譲歩」の発注部品に基づいて生成された発注部20の場合、上記のように、発注後５分までは市場における最良気配価格を追従することにより、比較的強気な注文を維持するものの、５分経過後は逆最良気配価格に譲歩することにより、より確実な約定成立を目指す機能を発揮する。

上記のように、この証券取引自動執行システム10にあっては、証券取引の自動執行処理が、注文総数を複数の個別注文数量に分割する注文分割部18と、分割された各注文数量分の注文情報を証券取引所のコンピュータ24に送信する複数の発注部20との協動によって達成され、注文分割部と各発注部はトレーダが予め独自に設定しておいた注文分割部品及び発注部品をインスタンス化することによって実現される仕組みを備えている。
このためトレーダは、予め定義しておいた注文分割部品と発注部品を適宜組み合わせることにより、複雑な動作を行うアルゴリズムを極めて容易に設定することが可能となる。また、アルゴリズムの動作パターンを変更する場合にも、注文分割部品と発注部品の組合せを変更することで簡単に実現できる。

また第三者にとっても、アルゴリズムが注文分割部品と発注部品との組合せから構成されているため、注文分割部品と発注部品の設定内容を段階的に辿っていくことでアルゴリズム全体の動作を把握しやすくなり、その再利用性や保守性を向上させることが可能となる。

上記したアルゴリズムの設定は一例であり、トレーダは異なる設定パターンを備えた注文分割部品や発注部品、ボリュームカーブ選択部品、ボリュームカーブ変更部品をアルゴリズムＤＢ14内に予め多数登録しておくと共に、これらを自由に組み合わせた自動執行用アルゴリズムをアルゴリズムＤＢ14内に予め多数登録しておくことにより、銘柄の特性や市場の情勢に最適なアルゴリズムを即座に利用可能となる。

上記においては、アルゴリズムＤＢ14に全ての設定情報が格納される例を示したが、各設定情報を複数の記憶手段に格納し、必要なデータ項目同士を関連付けておくように構成してもよい。

上記のように、取引時間の進行に従って複数の発注部20が生成され、執行制御部16を介して証券取引所のコンピュータ24との間で注文情報や約定情報など大量のデータが高速でやり取りされることとなる。
図２９は、執行制御部16の内部構造を示す概念図であり、複数の受付部74と、複数のＧＷ（ゲートウェイ）部76を備えている。

各受付部74は独立したプロセスよりなり、発注部20から送信された注文情報を受け付けてＧＷ部76に渡す機能や、証券取引所のコンピュータ24から返された注文受付情報をＧＷ部76から受け取り、発注部20に渡す機能等を備えている。
また、各ＧＷ部76も独立したプロセスよりなり、受付部74から渡された注文情報をフォーマット変換して証券取引所のコンピュータ24に送信する機能や、同コンピュータ24から返された注文確認情報をフォーマット変換して受付部74に渡す等を備えている。

このように、執行制御部16内には多数の受付部74やＧＷ部76が起動しており、各プロセス相互間及び複数の発注部20との間で各種データが高速でやり取りされているため、この発明に係る負荷分散処理システム80を各部に適用することで効率化を図ることができる。

図３０は、発注部20と受付部74との間に負荷分散処理システム80を適用した例を示す模式図であり、各発注部20（発注プロセス＝サービス利用側プロセス）にはサービス利用側ＡＰＩ84がぞれぞれ設けられており、各受付部74（受付プロセス＝サービス提供側プロセス）にはサービス提供側ＡＰＩ87がそれぞれ設けられている。
サービス利用側ＡＰＩ84及びサービス提供側ＡＰＩ87は、それぞれミドルウェアによって提供される機能である。また、このミドルウェアの常駐プログラムである管理デーモン83が起動されている。

図示は省略したが、サービス利用側ＡＰＩ84は、上記と同様の振分待ち要求記憶領域85と、処理要求キュー情報記憶領域86を備えている。また、同じく図示は省略したが、サービス提供側ＡＰＩ87はサービス提供側キュー情報記憶領域88を、管理デーモン83は管理デーモンキュー情報記憶領域89をそれぞれ備えている。

そして、発注部20によって生成された注文情報（処理要求）は、サービス利用側ＡＰＩ84に渡される。
これを受けたサービス利用側ＡＰＩ84は、処理要求キュー情報を参照して、最も負荷（自要求件数＋他要求件数）の小さい受付部74を特定し、この受付部74に係る「自要求件数＋他要求件数」の値が所定の閾値以下の場合には、当該受付部74のレコードの「自要求件数」に「１」を加算した後、当該受付部74のサービス提供側ＡＰＩ87に対して注文情報を送信する。
この最も負荷の小さい受付部74の「自要求件数＋他要求件数」が閾値を超えている場合、注文情報は振分待ち要求記憶領域85に一旦格納され、「自要求件数＋他要求件数」が閾値以下となった時点で当該受付部74のサービス提供側ＡＰＩ87に送信される。

この注文情報を受けたサービス提供側ＡＰＩ87は、サービス提供側キュー情報記憶領域88を検索し、当該発注部20のレコードを抽出する。つぎにサービス提供側ＡＰＩ87は、抽出した発注部20のレコードの処理要求受信件数に「１」を加算し、当該注文情報とレコードを関連付けた後、受付部74に当該注文情報を渡す。
この注文情報は、受付部74からＧＷ部76に渡され、ＧＷ部76を介して証券取引所のコンピュータ24に送信される。

証券取引所のコンピュータ24から、注文を受け付けたことを示す注文確認情報が送信されると、ＧＷ部76経由でこの注文確認情報が受付部74に到達し、受付部74はこの注文確認情報（処理結果）をサービス提供側ＡＰＩ87に渡す。
これを受け取ったサービス提供側ＡＰＩ87は、当該発注部20のレコードの処理要求返信件数に「１」を加算した後、サービス提供側キュー情報のサマリ情報を生成し、注文確認情報と共にサービス利用側ＡＰＩ84に送信する。

これを受けたサービス利用側ＡＰＩ84は、受付部74の「IPアドレス＋プロセスID」をキーにして、処理要求キュー情報記憶領域86を検索し、当該受付部74のレコードを抽出し、その自要求件数から「１」を減算した後、発注部20に注文確認情報を渡す。
つぎにサービス利用側ＡＰＩ84は、サービス提供側ＡＰＩ87から送信されたサマリ情報に基づいて、当該受付部74のレコードにおける「他要求件数」を更新する。

予め設定されたタイミングが到来すると、サービス提供側ＡＰＩ87は、各発注部20に係るサービス提供側キュー情報を、管理デーモン83に対して送信する。

これを受けた管理デーモン83は、管理デーモンキュー情報記憶領域89を検索し、当該受付部74に係る各発注部20のレコードを抽出する。
つぎに管理デーモン83は、当該受付部74から送信されたサービス提供側キュー情報によって管理デーモンキュー情報の処理要求受信件数及び処理要求返信件数を上書き更新する。

また、管理デーモン83は、予め設定されたタイミングが到来すると、管理デーモンキュー情報に基づいてクライアントキュー情報（受付部74のID＋他要求件数）を発注部20毎に生成し、発注部20に対して送信する。
これを受けた各発注部20のサービス利用側ＡＰＩ84は、処理要求キュー情報中の各受付部74に係る他要求件数を上書き更新する。

以上の結果、各発注部20は、現時点で最も負荷の小さい受付部74に対して、注文情報を送信することが可能となる。

図３１は、受付部74とＧＷ部76との間に負荷分散処理システム80を適用した例を示す模式図であり、各受付部74（受付プロセス＝サービス利用側プロセス）にはサービス利用側ＡＰＩ84がぞれぞれ設けられており、各ＧＷ部76（ゲートウェイプロセス＝サービス提供側プロセス）にはサービス提供側ＡＰＩ87がそれぞれ設けられている。すなわち、上記においてサービス提供側プロセスとして機能した受付部74が、この場面ではサービス利用側プロセスとして機能することとなる。
サービス利用側ＡＰＩ84及びサービス提供側ＡＰＩ87は、それぞれミドルウェアによって提供される機能である。また、このミドルウェアの常駐プログラムである管理デーモン83が起動されている。

図示は省略したが、サービス利用側ＡＰＩ84は、上記と同様の振分待ち要求記憶領域85と、処理要求キュー情報記憶領域86を備えている。また、同じく図示は省略したが、サービス提供側ＡＰＩ87はサービス提供側キュー情報記憶領域88を、管理デーモン83は管理デーモンキュー情報記憶領域89をそれぞれ備えている。

そして、受付部74が発注部20から受け取った注文情報（処理要求）は、サービス利用側ＡＰＩ84に渡される。
これを受けたサービス利用側ＡＰＩ84は、処理要求キュー情報を参照して、最も負荷（自要求件数＋他要求件数）の小さいＧＷ部76を特定し、このＧＷ部76に係る「自要求件数＋他要求件数」の値が所定の閾値以下の場合には、当該ＧＷ部76のレコードの「自要求件数」に「１」を加算した後、当該ＧＷ部76のサービス提供側ＡＰＩ87に対して注文情報を送信する。
この最も負荷の小さいＧＷ部76の「自要求件数＋他要求件数」が閾値を超えている場合、注文情報は振分待ち要求記憶領域85に一旦格納され、「自要求件数＋他要求件数」が閾値以下となった時点で当該ＧＷ部76のサービス提供側ＡＰＩ87に送信される。

この注文情報を受けたサービス提供側ＡＰＩ87は、サービス提供側キュー情報記憶領域88を検索し、当該受付部74のレコードを抽出する。つぎにサービス提供側ＡＰＩ87は、抽出した受付部74のレコードの処理要求受信件数に「１」を加算し、当該注文情報とレコードを関連付けた後、ＧＷ部76に当該注文情報を渡す。
ＧＷ部76は、この注文情報を所定のフォーマットに変換した上で証券取引所のコンピュータ24に送信する。

証券取引所のコンピュータ24から注文を受け付けたことを示す注文確認情報が送信されると、ＧＷ部76はこれを所定のフォーマットに変換した後、サービス提供側ＡＰＩ87に渡す。
この注文確認情報（処理結果）を受け取ったサービス提供側ＡＰＩ87は、受付部74のレコードの処理要求返信件数に「１」を加算した後、サービス提供側キュー情報のサマリ情報を生成し、注文確認情報と共にサービス利用側ＡＰＩ84に送信する。

これを受けたサービス利用側ＡＰＩ84は、ＧＷ部76の「IPアドレス＋プロセスID」をキーにして処理要求キュー情報記憶領域86を検索し、当該ＧＷ部76のレコードを抽出し、当該レコードの「自要求件数」から「１」を減算した後、受付部74に注文確認情報を渡す。
つぎにサービス利用側ＡＰＩ84は、サービス提供側ＡＰＩ87から送信されたサマリ情報に基づいて、当該ＧＷ部76のレコードにおける「他要求件数」を更新する。

予め設定されたタイミングが到来すると、サービス提供側ＡＰＩ87は各受付部74に係るサービス提供側キュー情報の全レコードを、管理デーモン83に対して送信する。

これを受けた管理デーモン83は、管理デーモンキュー情報記憶領域89を検索し、当該ＧＷ部76に係る各受付部74のレコードを抽出する。
つぎに管理デーモン83は、当該ＧＷ部76から送信されたサービス提供側キュー情報によって管理デーモンキュー情報の処理要求受信件数及び処理要求返信件数を上書き更新する。

また、管理デーモン83は、予め設定されたタイミングが到来すると、管理デーモンキュー情報に基づいてクライアントキュー情報（ＧＷ部76のID＋他要求件数）を受付部74毎に生成し、受付部74に対して送信する。
これを受けた各受付部74のサービス利用側ＡＰＩ84は、処理要求キュー情報中の各ＧＷ部76に係る他要求件数を上書き更新する。

以上の結果、各受付部74は、現時点で最も負荷の小さいＧＷ部76に対して、注文情報を送信することが可能となる。

上記のように、各発注部20と各受付部74との間に負荷分散処理システム80を適用すると共に、各受付部74と各ＧＷ部76との間にも負荷分散処理システム80を多段階的に適用することにより、結果的に発注部20−ＧＷ部76間における注文情報及び注文確認情報のやり取りが効率化される。

この発明に係る負荷分散処理システムの全体構成を示すブロック図である。 負荷分散処理システムの動作を示すフローチャートである。 負荷分散処理システムの動作を示すフローチャートである。 処理要求キュー情報の構成を示す説明図である。 サービス提供側キュー情報の構成を示す説明図である。 サマリ情報の構成を示す説明図である。 管理デーモンキュー情報の構成を示す説明図である。 クライアントキュー情報の構成を示す説明図である。 クライアントキュー情報の生成過程を示す説明図である。 振分待ち要求に関する処理手順を示すフローチャートである。 この発明の応用例である証券取引自動執行システムの全体構成を示すブロック図である。 アルゴリズム設定画面においてアルゴリズムの全体構成を設定する場面を示す説明図である。 ボリュームカーブの具体例を示す説明図である。 アルゴリズムの設定項目を示す図である。 アルゴリズム設定画面においてボリュームカーブ選択部品を設定する場面を示す説明図である。 ボリュームカーブ選択部品の設定項目を示す図である。 アルゴリズム設定画面においてボリュームカーブ変更部品を設定する場面を示す説明図である。 ボリュームカーブ変更部品の設定項目を示す図である。 アルゴリズム設定画面において注文分割部品を設定する場面を示す説明図である。 注文分割部品の設定項目を示す図である。 アルゴリズム設定画面において発注部品を設定する場面を示す説明図である。 発注部品の設定例を示す説明図である。 発注部品の設定項目を示す図である。 アルゴリズムの構成例を示す図である。 自動執行リクエスト画面を示す説明図である。 執行制御部の動作を示すフローチャートである。 注文分割部の動作を示すフローチャートである。 発注部の動作を示すフローチャートである。 執行制御部の内部構造を示すブロック図である。 発注部と受付部との間に負荷分散処理システムを適用した例を示すブロック図である。 受付部とＧＷ部との間に負荷分散処理システムを適用した例を示すブロック図である。

10 証券取引自動執行システム
12 設定登録部
16 執行制御部
18 注文分割部
20 発注部
21 ボリュームカーブ選択部
22 ボリュームカーブ変更部
23 クライアント端末
24 証券取引のコンピュータ
30 アルゴリズム設定画面
31 左側ペイン
32 アルゴリズム
33 ボリュームカーブ選択部品
34 ボリュームカーブ変更部品
35 注文分割部品
36 発注部品
37 右側ペイン
38 ボリュームカーブ選択部品指定欄
39 ボリュームカーブ変更部品指定欄
40 注文分割部品指定欄
41 発注部品指定欄
42 ボリュームカーブ選択入力欄
43 適用条件入力欄
44 タイミング選択入力欄
45 変更条件入力欄
46 アクション入力欄
48 タイミング選択入力欄
49 条件入力欄
50 内容入力欄
50a ニモニック入力欄
50b 割当数量入力欄
50c 丸め方法選択欄
52 タイミング選択入力欄
53 条件入力欄
54 アクション入力欄
60 自動執行リクエスト画面
61 売買種別選択欄
62 銘柄コード入力欄
63 市場選択欄
64 数量入力欄
65 執行制限値段入力欄
67 パラメータ入力欄
67a 値入力欄
68 実行ボタン
72 アルゴリズム選択欄
74 受付部
76 ＧＷ部
80 負荷分散処理システム
81 サービス利用側プロセス
82 サービス提供側プロセス
83 管理デーモン
84 サービス利用側ＡＰＩ
85 振分待ち要求記憶領域
86 処理要求キュー情報記憶領域
87 サービス提供側ＡＰＩ
88 サービス提供側キュー情報記憶領域
89 管理デーモンキュー情報記憶領域

Claims (7)

1. 処理要求を生成する複数のサービス利用側プロセスと、上記処理要求に対して必要な処理を実行し、処理結果を出力する複数のサービス提供側プロセスと、上記サービス利用側プロセス毎に設けられた処理要求振分部と、上記サービス提供側プロセス毎に設けられた負荷情報管理部と、負荷情報配信部とを備えた負荷分散処理システムであって、
   上記処理要求振分部は、サービス提供側プロセス毎に、当該サービス提供側プロセスが応対している全サービス利用側プロセスに係る未完了の処理要求件数を格納しておく第１の記憶領域と、
   自己が担当するサービス利用側プロセスから処理要求が渡された際に、上記第１の記憶領域を参照し、未完了の処理要求件数が最も少ないサービス提供側プロセスを特定する機能と、
   当該サービス提供側プロセスに係る負荷情報管理部に処理要求を送信する機能と、
   当該サービス提供側プロセスによる処理結果を上記負荷情報管理部から受信し、上記サービス利用側プロセスに渡す機能と、
   上記負荷情報配信部からサービス提供側プロセス毎の全サービス利用側プロセスに係る未完了の処理要求件数が送信された場合に、これにより上記第１の記憶領域に格納されたサービス提供側プロセス毎の未完了の処理要求件数を更新する機能を備え、
   上記負荷情報管理部は、サービス利用側プロセスの処理要求を対応の処理要求振分部から受け取り、自己が担当するサービス提供側プロセスに渡す機能と、
   当該サービス提供側プロセスから渡された処理結果を、上記サービス利用側プロセスの処理要求振分部に返信する機能と、
   サービス利用側プロセス毎に、処理要求受信件数及び処理結果返信件数を格納する第２の記憶領域と、
   処理要求を上記処理要求振分部から受信する度に、上記処理要求受信件数に１を加算する機能と、
   処理結果を上記処理要求振分部に返信する度に、上記処理結果返信件数に１を加算する機能と、
   所定のタイミングで、各サービス利用側プロセスに係る処理要求受信件数及び処理結果返信件数を、上記負荷情報配信部に送信する機能を備え、
   上記負荷情報配信部は、各負荷情報管理部から送信された各サービス利用側プロセスに係る処理要求受信件数及び処理結果返信件数を格納しておく第３の記憶領域と、
   所定のタイミングで、サービス提供側プロセス毎に、各サービス利用側プロセスに係る処理要求受信件数から処理結果返信件数を減算して未完了の処理要求件数を求め、これを全サービス利用側プロセス分積算する機能と、
   このサービス提供側プロセス毎の全サービス利用側プロセスに係る未完了の処理要求件数を、各処理要求振分部に送信する機能を備えたことを特徴とする負荷分散処理システム。
2. 上記負荷情報管理部は、上記処理結果をサービス利用側プロセスの処理要求振分部に返信するに際し、各サービス利用側プロセスに係る処理要求受信件数の集計値と、各サービス利用側プロセスに係る処理結果返信件数の集計値を算出し、処理結果と共に処理要求振分部に送信する機能を備えており、
   上記処理要求振分部は、この処理要求受信件数の集計値から処理結果返信件数の集計値を減算して、当該サービス提供側プロセスの全サービス利用側プロセスに係る未完了の処理要求件数を求める機能と、
   この未完了の処理要求件数によって、上記第１の記憶領域における該当のサービス提供側プロセスに係る未完了の処理要求件数を更新する機能を備えたことを特徴とする請求項１に記載の負荷分散処理システム。
3. 処理要求を生成する複数のサービス利用側プロセスと、上記処理要求に対して必要な処理を実行し、処理結果を出力する複数のサービス提供側プロセスと、上記サービス利用側プロセス毎に設けられた処理要求振分部と、上記サービス提供側プロセス毎に設けられた負荷情報管理部と、負荷情報配信部とを備えた負荷分散処理システムであって、
   上記処理要求振分部は、サービス提供側プロセス毎に、自らが当該サービス提供側プロセスに対して送信中の未完了の処理要求件数である自要求件数と、他のサービス利用側プロセスが当該サービス提供側プロセスに対して送信中の未完了の処理要求件数の合計である他要求件数を格納しておく第１の記憶領域と、
   自己が担当するサービス利用側プロセスから処理要求が渡された際に、上記第１の記憶領域を参照し、自要求件数と他要求件数の和である未完了の処理要求件数が最も少ないサービス提供側プロセスを特定する機能と、
   当該サービス提供側プロセスに係る負荷情報管理部に処理要求を送信する機能と、
   当該サービス提供側プロセスに係る自要求件数に１を加算する機能と、
   上記負荷情報管理部から処理結果を受信した際に、当該サービス提供側プロセスに係る自要求件数から１を減算する機能と、
   この処理結果を上記サービス利用側プロセスに渡す機能と、
   上記負荷情報配信部からサービス提供側プロセス毎の他のサービス利用側プロセスに係る未完了の処理要求件数の合計が送信された場合に、これにより上記第１の記憶領域に格納された他要求件数を更新する機能を備え、
   上記負荷情報管理部は、サービス利用側プロセスの処理要求を対応の処理要求振分部から受け取り、自己が担当するサービス提供側プロセスに渡す機能と、
   当該サービス提供側プロセスから渡された処理結果を、上記サービス利用側プロセスの処理要求振分部に返信する機能と、
   サービス利用側プロセス毎に、処理要求受信件数及び処理結果返信件数を格納する第２の記憶領域と、
   処理要求を上記処理要求振分部から受信する度に、上記処理要求受信件数に１を加算する機能と、
   処理結果を上記処理要求振分部に返信する度に、上記処理結果返信件数に１を加算する機能と、
   所定のタイミングで、各サービス利用側プロセスに係る処理要求受信件数及び処理結果返信件数を、上記負荷情報配信部に送信する機能を備え、
   上記負荷情報配信部は、各負荷情報管理部から送信された各サービス利用側プロセスに係る処理要求受信件数及び処理結果返信件数を格納しておく第３の記憶領域と、
   所定のタイミングで、サービス提供側プロセス毎に、各サービス利用側プロセスに係る処理要求受信件数から処理結果返信件数を減算して未完了の処理要求件数を求め、これを全サービス利用側プロセス分積算する機能と、
   このサービス提供側プロセス毎の全サービス利用側プロセスに係る未完了の処理要求件数から、各サービス利用側プロセスに係る未完了の処理要求件数を減算し、各サービス利用側プロセス毎の他要求件数を算出する機能と、
   この他要求件数を、対応のサービス利用側プロセスに係る処理要求振分部に送信する機能を備えたことを特徴とする負荷分散処理システム。
4. 上記負荷情報管理部は、上記処理結果をサービス利用側プロセスの処理要求振分部に返信するに際し、各サービス利用側プロセスに係る処理要求受信件数の集計値と、各サービス利用側プロセスに係る処理結果返信件数の集計値を算出し、処理結果と共に処理要求振分部に送信する機能を備えており、
   上記処理要求振分部は、この処理要求受信件数の集計値から処理結果返信件数の集計値を減算し、その差から自要求件数を減算した他要求件数を算出する機能と、
   この他要求件数によって、上記第１の記憶領域における該当のサービス提供側プロセスに係る他要求件数を更新する機能を備えたことを特徴とする請求項３に記載の負荷分散処理システム。
5. 上記処理要求振分部は、上記処理要求をサービス提供側プロセスの負荷情報管理部に送信するに際し、当該サービス提供側プロセスに係る未完了の処理要求件数が予め設定された閾値を超えているか否かを判定する機能と、
   上記閾値を超えている場合に、当該処理要求を一旦待機用の第４の記憶領域に格納する機能と、
   上記第１の記憶領域の格納情報が更新される度に、上記第４の記憶領域に格納された各処理要求について、上記第１の記憶領域を参照して未完了の処理要求件数が最も少ないサービス提供側プロセスを特定する機能と、
   当該サービス提供側プロセスの未完了の処理要求件数が予め設定された閾値以下か否かを判定し、上記閾値以下の場合に当該処理要求を対応のサービス提供側プロセスの負荷情報管理部に送信する機能を備えたことを特徴とする請求項１〜４の何れかに記載の負荷分散処理システム。
6. 上記サービス利用側プロセスが、予め設定されたタイミングで、予め設定されたルールに従って価格を算出し、この価格による、自己に割り当てられた数量分の新規注文情報を生成する処理を実行する、証券取引自動執行システムの複数の発注プロセスよりなり、
   上記サービス提供側プロセスが、上記発注プロセスとゲートウェイプロセスとの間に介在し、発注プロセスによって生成された注文情報を受け付けて上記ゲートウェイプロセスに送信すると共に、ゲートウェイプロセスから送信された証券取引所のコンピュータからの注文確認情報を上記発注プロセスに送信する処理を実行する複数の受付プロセスよりなり、
   上記処理要求振分部が、上記発注プロセスによって生成された注文情報を上記処理要求として上記受付プロセスの負荷情報管理部に送信すると共に、当該受付プロセスの負荷情報管理部から送信された上記注文確認情報を上記処理結果として上記発注プロセスに渡し、
   上記負荷情報管理部が、上記発注プロセスの処理要求振分部から上記処理要求としての注文情報を受信し、上記受付プロセスに渡すと共に、当該受付プロセスから渡された上記処理結果としての注文確認情報を、上記発注プロセスの処理要求振分部に送信することを特徴とする請求項１〜５の何れかに記載の負荷分散処理システム。
7. 上記サービス利用側プロセスが、上記受付プロセスよりなり、
   上記サービス提供側プロセスが、上記ゲートウェイプロセスよりなり、
   上記処理要求振分部が、上記受付プロセスから渡された注文情報を上記処理要求として上記ゲートウェイプロセスの負荷情報管理部に送信すると共に、当該ゲートウェイプロセスの負荷情報管理部から送信された上記注文確認情報を上記処理結果として上記受付プロセスに渡し、
   上記負荷情報管理部が、上記受付プロセスの処理要求振分部から上記処理要求としての注文情報を受信し、上記ゲートウェイプロセスに渡すと共に、ゲートウェイプロセスから渡された上記処理結果としての注文確認情報を、上記受付プロセスの処理要求振分部に送信することを特徴とする請求項６に記載の負荷分散処理システム。

Images