JP6204287B2

JP6204287B2 - 分散処理方法、処理サーバ、および、プログラム

Info

Publication number: JP6204287B2
Application number: JP2014148063A
Authority: JP
Inventors: 雄大北野; 啓介小西; 広幸徐; 篤史外山; 幸藤岡; 博史野口
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2014-07-18
Filing date: 2014-07-18
Publication date: 2017-09-27
Anticipated expiration: 2034-07-18
Also published as: JP2016024605A

Description

本発明は、ユーザ端末からのリクエストを複数の処理サーバで分担して処理する技術に関する。

ユーザ端末からのリクエストを担当する処理サーバを決定する分散処理を行うための技術として、例えば、コンシステントハッシュ法を用いて処理の分散化を行う分散データ管理方法がある（特許文献１）。この分散データ管理方法では、コンシステントハッシュ法が用いられ、仮想ハッシュ空間上に処理サーバが割り当てられており、分散データ管理装置は、ユーザ端末からリクエスト（サービス要求信号）を受信すると、リクエストを識別するキーを元に仮想ハッシュ空間上の値を算出し、算出した仮想ハッシュ空間上の値から、そのリクエストへの応答（サービス処理）を担当する処理サーバ（サービス処理サーバ）を決定し、決定された処理サーバにそのリクエストを転送することで、分散処理を実現している。

この分散処理（Ｄ（Dispatch）信号処理）とサービス処理（ＰＳ（Processing)信号処理）は、１つのマシン（処理サーバ）に重畳させて実行することも可能である。１つのマシンに重畳させて実行することで、Ｄ信号処理の結果、サービス処理サーバが自分自身の処理サーバであった場合に、マシン間通信の必要がなく、その通信分のコストを削減することができるという利点がある。

特開２０１１−９５９７６号公報

分散処理とサービス処理を１つの処理サーバに重畳させた状況下において、分散処理用のリソース（ＣＰＵ（Central Processing Unit）、メモリなど）でサービス処理用のリソースを圧迫することは回避するべきである。なぜならば、Ｄ信号処理によって分散が実施できても、肝心のサービス処理が遅延しては、処理サーバ側に留保されるリクエストが増加し、リソース使用率の増加を招く、あるいは、処理サーバの応答時間が増加し、ユーザ端末側への影響が発生する、といったことが考えられるためである。

また、一般に、通信サーバにおいては、信号の受信処理よりも送信処理を優先するという、いわゆる出側優先の思想でソフトウェアの設計がなされている。したがって、分散処理を行う処理サーバについても、出側優先のソフトウェア設計が望ましい。

そこで、本発明は、分散処理とサービス処理を並行して行う処理サーバにおいて、分散処理の増大によるサービス処理の遅延を回避することを課題とする。

前記課題を解決するために、本発明は、複数の処理サーバそれぞれが、ユーザ端末からのリクエストを受信した場合に前記リクエストを担当する処理サーバを決定する分散処理と、前記担当する処理サーバとして決定された場合に前記リクエストに応答するサービス処理と、を並行して行う処理システムにおける前記処理サーバによる分散処理方法であって、前記処理サーバは、前記分散処理を行う分散処理部と、前記サービス処理を行うサービス処理部と、前記分散処理に関するリソースの使用状況を示すリソース使用状況情報、および、前記リソース使用状況情報に関する所定の閾値を記憶する記憶部と、リソース監視機能部と、を備えており、前記リソース監視機能部は、前記リソース使用状況情報と前記所定の閾値とを参照し、前記リソース使用状況情報が前記所定の閾値を超えている場合、前記分散処理の一時停止、保守者端末への通知、および、リソースの追加、の少なくともいずれかを実行することを特徴とする。

これによれば、分散処理とサービス処理を並行して行う処理サーバにおいて、リソース使用状況情報が所定の閾値を超えている場合に、分散処理の一時停止、保守者端末への通知、および、リソースの追加、の少なくともいずれかを実行することで、分散処理の増大によるサービス処理の遅延を回避することができる。

また、本発明は、リソース使用状況情報が、分散処理に関するＣＰＵ（Central Processing Unit）またはメモリの使用率の情報であることを特徴とする。

これによれば、リソース使用状況情報として、増大すればサービス処理の遅延に直接つながってしまう、分散処理に関するＣＰＵまたはメモリの使用率の情報を用いることで、分散処理の増大によるサービス処理の遅延をより確実に回避することができる。

また、本発明は、リソース使用状況情報が、単位時間当たりの分散処理の数の情報であることを特徴とする。

これによれば、リソース使用状況情報として、増大すればサービス処理の遅延に直接つながってしまう、単位時間当たりの分散処理の数の情報を用いることで、分散処理の増大によるサービス処理の遅延をより確実に回避することができる。

また、本発明は、コンピュータを、前記処理サーバとして機能させるためのプログラムとして実現できる。これにより、コンピュータを、前記処理サーバとして機能させることができる。

本発明によれば、分散処理とサービス処理を並行して行う処理サーバにおいて、分散処理の増大によるサービス処理の遅延を回避することができる。

本実施形態の処理サーバを含む全体構成図である。（ａ）は、リソース使用状況情報の例を示す図である。（ｂ）は、閾値情報の例を示す図である。本実施形態における処理サーバなどの処理の流れを示したシーケンス図である。（ａ）は、リソース使用状況情報の他の例を示す図である。（ｂ）は、閾値情報の他の例を示す図である。

本発明を実施するための形態（実施形態）について、図面を参照しながら説明する。図１に示すように、処理システム１００は、処理サーバ１と、複数の他の処理サーバ３とを備えている。なお、処理サーバ１と複数の他の処理サーバ３は同等であるが、ここでは、処理サーバ１に着目するものとする。また、処理サーバ１と複数の他の処理サーバ３をまとめて表現する場合は、「処理サーバ１，３」と記載する。また、「処理サーバ１，３」のうちの１つを指す場合、符号無しで「処理サーバ」と記載する場合もある。

処理システム１００において、ユーザ端末２からのリクエストを処理サーバ１，３のいずれかが受信すると、受信した処理サーバは、処理サーバ１，３のうち前記リクエストを担当する処理サーバを決定する分散処理を行い、前記決定された処理サーバが前記リクエストに応答するサービス処理を行う。つまり、処理サーバ１，３それぞれは、分散処理とサービス処理とを並行して行う。

処理サーバ１は、ＣＰＵ（Central Processing Unit）、メモリなどによって実現されるＤ信号受信機能部１１、Ｄ信号処理機能部１２、ＰＳ信号受信機能部１３、ＰＳ信号処理機能部１４、送信機能部１５、リソース監視機能部１６と、ＨＤＤ（Hard Disk Drive）、フラッシュメモリなどによって実現される記憶部１７を備えて構成される。

記憶部１７は、リソース使用状況情報１８および閾値情報１９（所定の閾値）を記憶する。また、記憶部１７は、コンピュータを処理サーバ１として機能させるためのプログラムを記憶している。このプログラムにより、コンピュータを処理サーバ１として機能させることができる。

Ｄ信号受信機能部１１は、ユーザ端末２からのリクエストの信号（Ｄ信号）を受信キューから取り出す。
Ｄ信号処理機能部１２（分散処理部）は、Ｄ信号を解析して、例えばコンシステントハッシュ法によって、担当する処理サーバを決定する分散処理を行う。

ＰＳ信号受信機能部１３は、他の処理サーバ３からの信号（ＰＳ信号）を受信キューから取り出す。
ＰＳ信号処理機能部１４（サービス処理部）は、ＰＳ信号を解析してサービス処理を行う。

送信機能部１５は、Ｄ信号処理機能部１２によって決定された処理サーバや、ユーザ端末２へ、信号を送信する。
リソース監視機能部１６は、リソース使用状況情報１８と閾値情報１９とを参照し、リソース使用状況情報１８が閾値情報１９の示す値を超えている場合、分散処理の一時停止、保守者端末４への通知、および、リソースの追加、の少なくともいずれかを実行する（詳細は後記）。

記憶部１７には、図２（ａ）に示すように、リソース使用状況情報１８として、スレッドＩＤ（IDentifier）ごとに、用途、ＣＰＵ使用率（％）、メモリ使用率（％）の各情報が格納される。なお、リソース使用状況情報１８は、Ｄ信号処理機能部１２、ＰＳ信号処理機能部１４によって逐次更新される。

記憶部１７には、図２（ｂ）に示すように、閾値情報１９として、例えば、全体ＣＰＵ使用率閾値、Ｄ信号処理スレッド用のＣＰＵ使用率閾値、全体メモリ使用率閾値、Ｄ信号処理スレッド用のメモリ使用率閾値の各情報が予め設定されている。

次に、本実施形態における処理サーバ１などの処理の流れについて説明する。図３に示すように（図１も参照）、ユーザ端末２が要求信号（Ｄ信号。リクエスト）を送信し（Ｓ１）、その要求信号を処理サーバ１が受信するものとする。

処理サーバ１において、Ｄ信号受信機能部１１は、ユーザ端末２からの要求信号を受信し、その要求信号をＤ信号処理機能部１２に受け渡す（Ｓ２）。
Ｄ信号処理機能部１２は、要求信号を受け取ると、スレッドを生成し（Ｓ３）、スレッドＩＤをリソース監視機能部１６に通知する（Ｓ４）。また、Ｄ信号処理機能部１２は、記憶部１７のリソース使用状況情報１８を更新する。

次に、Ｄ信号処理機能部１２は、その要求信号を担当する処理サーバを決定する分散処理を行い（Ｓ５）、決定された処理サーバに対して、送信機能部１５を経由してその要求信号（ＰＳ信号）を送信する（Ｓ６、Ｓ７）
その要求信号（ＰＳ信号）受け取った処理サーバ（他の処理サーバ３）は、その要求信号に応答するサービス処理を行う。

また、処理サーバ１のＰＳ信号受信機能部１３は、ユーザ端末２からの他の要求信号（Ｄ信号）を受信して分散処理を終えた他の処理サーバ３から要求信号（ＰＳ信号）を受け取ると（Ｓ８）、その要求信号をＰＳ信号処理機能部１４に受け渡す（Ｓ９）。

ＰＳ信号処理機能部１４は、要求信号を受け取ると、スレッドを生成し（Ｓ１０）、スレッドＩＤをリソース監視機能部１６に通知する（Ｓ１１）。また、ＰＳ信号処理機能部１４は、記憶部１７のリソース使用状況情報１８を更新する。

次に、ＰＳ信号処理機能部１４は、その要求信号（ＰＳ信号）に関するサービス処理を行い（Ｓ１２）、その要求信号を発したユーザ端末２に対して、送信機能部１５を経由して応答信号を送信する（Ｓ１３、Ｓ１４）。

また、リソース監視機能部１６は、定期的に起動し、Ｓ４とＳ１１で受け取ったスレッドＩＤを用いて、記憶部１７からリソース使用状況情報１８を収集する（Ｓ１５）。
次に、リソース監視機能部１６は、収集したリソース使用状況情報１８に基づいて、全体ＣＰＵ使用率、Ｄ信号処理スレッド用のＣＰＵ使用率、全体メモリ使用率、Ｄ信号処理スレッド用のメモリ使用率を算出し、それぞれの値が、閾値情報１９に記憶された全体ＣＰＵ使用率閾値、Ｄ信号処理スレッド用のＣＰＵ使用率閾値、全体メモリ使用率閾値、Ｄ信号処理スレッド用のメモリ使用率閾値を超えているか否かを判定し（Ｓ１６）、Ｙｅｓの場合はＳ１７に進み、Ｎｏの場合はＳ１７をスキップする。

Ｓ１７において、リソース監視機能部１６は、分散処理用のリソースがサービス処理用のリソースを圧迫しないように、分散処理の一時停止、保守者端末４への通知、および、リソースの追加（例えば処理サーバの追加）、の少なくともいずれかを実行する。

分散処理を一時停止すれば、分散処理用のリソースがサービス処理用のリソースを圧迫する事態を直接的に回避できる。
また、保守者端末４へ通知すれば、保守者が有効な対策を講じることができる。
また、リソースを追加すれば、分散処理用のリソースの使用率を当然に下がるので、分散処理用のリソースがサービス処理用のリソースを圧迫する事態を回避できる。

なお、分散処理を一時停止する場合は、その後、所定時間が経過したこと、あるいは、閾値を超えていた値が閾値以下になったこと、などの条件を満たしたときに、分散処理を再開すればよい。

通知を受けた保守者端末４は、表示部３１に閾値を超えた値に関する情報を表示する。保守者は、この表示を見ることで、対策を講じることができる。

このようにして、本実施形態の処理サーバ１によれば、分散処理とサービス処理を並行して行う場合に、リソース使用状況情報１８のうち、特に、分散処理に関するリソース使用状況情報（Ｄ信号処理スレッド用のＣＰＵ使用率、Ｄ信号処理スレッド用のメモリ使用率）が所定の閾値を超えている場合に、分散処理の一時停止、保守者端末４への通知、および、リソースの追加、の少なくともいずれかを実行することで、分散処理の増大によるサービス処理の遅延を回避することができる。

また、リソース使用状況情報１８として、増大すればサービス処理の遅延に直接つながってしまう、分散処理に関するＣＰＵまたはメモリの使用率の情報を用いることで、分散処理の増大によるサービス処理の遅延をより確実に回避することができる。

次に、リソース使用状況情報と閾値情報の他の例について説明する。図４（ａ）に示すように、リソース使用状況情報１８ａとして、分散処理を伴う信号（Ｄ信号）の単位時間当たりの処理数を用いることもできる。その場合、図４（ｂ）に示すように、閾値情報１９ａとして、分散処理を伴う信号（Ｄ信号）の単位時間当たりの処理数の閾値を予め設定しておく。

そして、リソース監視機能部１６が、リソース使用状況情報１８ａが閾値情報１９ａに示す値を超えている場合に、分散処理の一時停止、保守者端末４への通知、および、リソースの追加、の少なくともいずれかを実行すればよい。

これによれば、リソース使用状況情報として、増大すればサービス処理の遅延に直接つながってしまう、分散処理を伴う信号の単位時間当たりの処理数の情報を用いることで、分散処理の増大によるサービス処理の遅延をより確実に回避することができる。
なお、分散処理を一時停止する場合は、例えば、その後、単位時間が経過したときに、分散処理を再開すればよい。

以上で本実施形態の説明を終えるが、本発明の態様はこれらに限定されるものではない。
例えば、図２（ｂ）に示した「５０．０％」などの数字は一例であり、他の数字を採用してもよい。

また、図３のＳ１５〜Ｓ１７の処理を行うタイミングは、「定期的」に限定されず、例えば、リソース監視機能部１６がスレッドＩＤの通知を所定回数受信する度など、他のタイミングであってもよい。
その他、具体的な構成について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。

１処理サーバ
２ユーザ端末
３他の処理サーバ
４保守者端末
１１Ｄ信号受信機能部
１２Ｄ信号処理機能部
１３ＰＳ信号受信機能部
１４ＰＳ信号処理機能部
１５送信機能部
１６リソース監視機能部
１７記憶部
１８、１８ａリソース使用状況情報
１９、１９ａ閾値情報
３１表示部
１００処理システム

Claims

複数の処理サーバそれぞれが、ユーザ端末からのリクエストを受信した場合に前記リクエストを担当する処理サーバを決定する分散処理と、前記担当する処理サーバとして決定された場合に前記リクエストに応答するサービス処理と、を並行して行う処理システムにおける前記処理サーバによる分散処理方法であって、
前記処理サーバは、
前記分散処理を行う分散処理部と、
前記サービス処理を行うサービス処理部と、
前記分散処理に関するリソースの使用状況を示すリソース使用状況情報、および、前記リソース使用状況情報に関する所定の閾値を記憶する記憶部と、
リソース監視機能部と、を備えており、
前記リソース監視機能部は、
前記リソース使用状況情報と前記所定の閾値とを参照し、前記リソース使用状況情報が前記所定の閾値を超えている場合、前記分散処理の一時停止、保守者端末への通知、および、リソースの追加、の少なくともいずれかを実行する
ことを特徴とする分散処理方法。
前記リソース使用状況情報は、前記分散処理に関するＣＰＵ（Central Processing Unit）またはメモリの使用率の情報である
ことを特徴とする請求項１に記載の分散処理方法。
前記リソース使用状況情報は、単位時間当たりの前記分散処理の数の情報である
ことを特徴とする請求項１に記載の分散処理方法。
複数の処理サーバそれぞれが、ユーザ端末からのリクエストを受信した場合に前記リクエストを担当する処理サーバを決定する分散処理と、前記担当する処理サーバとして決定された場合に前記リクエストに応答するサービス処理と、を並行して行う処理システムにおける前記処理サーバであって、
前記分散処理を行う分散処理部と、
前記サービス処理を行うサービス処理部と、
前記分散処理に関するリソースの使用状況を示すリソース使用状況情報、および、前記リソース使用状況情報に関する所定の閾値を記憶する記憶部と、
前記リソース使用状況情報と前記所定の閾値とを参照し、前記リソース使用状況情報が前記所定の閾値を超えている場合、前記分散処理の一時停止、保守者端末への通知、および、リソースの追加、の少なくともいずれかを実行するリソース監視機能部と、
を備えることを特徴とする処理サーバ。
前記リソース使用状況情報は、前記分散処理に関するＣＰＵ（Central Processing Unit）またはメモリの使用率の情報である
ことを特徴とする請求項４に記載の処理サーバ。
前記リソース使用状況情報は、単位時間当たりの前記分散処理の数の情報である
ことを特徴とする請求項４に記載の処理サーバ。
コンピュータを、請求項４から請求項６までのいずれか一項に記載の処理サーバとして機能させるためのプログラム。