図面 (/)

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

出願人 日本電信電話株式会社
発明者 北野雄大小西啓介徐広幸外山篤史藤岡幸野口博史
出願日 2014年7月18日 (5年8ヶ月経過) 出願番号 2014-148063
公開日 2016年2月8日 (4年1ヶ月経過) 公開番号 2016-024605
状態 特許登録済
技術分野 マルチプログラミング
主要キーワード 保守者端末 符号無し サービス要求信号 閾値情報 ソフトウェア設計 ハッシュ空間 分散データ リソース使用率
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2016年2月8日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (5)

課題

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

解決手段

処理サーバ1は、分散処理を行うD信号処理機能部12と、サービス処理を行うPS信号処理機能部14と、分散処理に関するリソース使用状況を示すリソース使用状況情報18、および、リソース使用状況情報18に関する所定の閾値閾値情報19)を記憶する記憶部17と、リソース使用状況情報18と所定の閾値とを参照し、リソース使用状況情報18が所定の閾値を超えている場合、分散処理の一時停止保守者端末4への通知、および、リソースの追加、の少なくともいずれかを実行するリソース監視機能部16とを備える。

概要

背景

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

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

概要

分散処理とサービス処理を並行して行う処理サーバにおいて、分散処理の増大によるサービス処理の遅延を回避することを課題とする。処理サーバ1は、分散処理を行うD信号処理機能部12と、サービス処理を行うPS信号処理機能部14と、分散処理に関するリソース使用状況を示すリソース使用状況情報18、および、リソース使用状況情報18に関する所定の閾値閾値情報19)を記憶する記憶部17と、リソース使用状況情報18と所定の閾値とを参照し、リソース使用状況情報18が所定の閾値を超えている場合、分散処理の一時停止保守者端末4への通知、および、リソースの追加、の少なくともいずれかを実行するリソース監視機能部16とを備える。

目的

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

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

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

請求項2

前記リソース使用状況情報は、前記分散処理に関するCPU(Central Processing Unit)またはメモリ使用率の情報であることを特徴とする請求項1に記載の分散処理方法。

請求項3

前記リソース使用状況情報は、単位時間当たりの前記分散処理の数の情報であることを特徴とする請求項1に記載の分散処理方法。

請求項4

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

請求項5

前記リソース使用状況情報は、前記分散処理に関するCPU(Central Processing Unit)またはメモリの使用率の情報であることを特徴とする請求項4に記載の処理サーバ。

請求項6

前記リソース使用状況情報は、単位時間当たりの前記分散処理の数の情報であることを特徴とする請求項4に記載の処理サーバ。

請求項7

コンピュータを、請求項4から請求項6までのいずれか一項に記載の処理サーバとして機能させるためのプログラム

技術分野

0001

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

背景技術

0002

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

0003

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

先行技術

0004

特開2011−95976号公報

発明が解決しようとする課題

0005

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

0006

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

0007

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

課題を解決するための手段

0008

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

0009

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

0010

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

0011

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

0012

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

0013

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

0014

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

発明の効果

0015

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

図面の簡単な説明

0016

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

実施例

0017

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

0018

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

0019

処理サーバ1は、CPU(Central Processing Unit)、メモリなどによって実現されるD信号受信機能部11、D信号処理機能部12、PS信号受信機能部13、PS信号処理機能部14、送信機能部15、リソース監視機能部16と、HDD(Hard Disk Drive)、フラッシュメモリなどによって実現される記憶部17を備えて構成される。

0020

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

0021

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

0022

PS信号受信機能部13は、他の処理サーバ3からの信号(PS信号)を受信キューから取り出す。
PS信号処理機能部14(サービス処理部)は、PS信号を解析してサービス処理を行う。

0023

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

0024

記憶部17には、図2(a)に示すように、リソース使用状況情報18として、スレッドID(IDentifier)ごとに、用途、CPU使用率(%)、メモリ使用率(%)の各情報が格納される。なお、リソース使用状況情報18は、D信号処理機能部12、PS信号処理機能部14によって逐次更新される。

0025

記憶部17には、図2(b)に示すように、閾値情報19として、例えば、全体CPU使用率閾値、D信号処理スレッド用のCPU使用率閾値、全体メモリ使用率閾値、D信号処理スレッド用のメモリ使用率閾値の各情報が予め設定されている。

0026

次に、本実施形態における処理サーバ1などの処理の流れについて説明する。図3に示すように(図1も参照)、ユーザ端末2が要求信号(D信号。リクエスト)を送信し(S1)、その要求信号を処理サーバ1が受信するものとする。

0027

処理サーバ1において、D信号受信機能部11は、ユーザ端末2からの要求信号を受信し、その要求信号をD信号処理機能部12に受け渡す(S2)。
D信号処理機能部12は、要求信号を受け取ると、スレッドを生成し(S3)、スレッドIDをリソース監視機能部16に通知する(S4)。また、D信号処理機能部12は、記憶部17のリソース使用状況情報18を更新する。

0028

次に、D信号処理機能部12は、その要求信号を担当する処理サーバを決定する分散処理を行い(S5)、決定された処理サーバに対して、送信機能部15を経由してその要求信号(PS信号)を送信する(S6、S7)
その要求信号(PS信号)受け取った処理サーバ(他の処理サーバ3)は、その要求信号に応答するサービス処理を行う。

0029

また、処理サーバ1のPS信号受信機能部13は、ユーザ端末2からの他の要求信号(D信号)を受信して分散処理を終えた他の処理サーバ3から要求信号(PS信号)を受け取ると(S8)、その要求信号をPS信号処理機能部14に受け渡す(S9)。

0030

PS信号処理機能部14は、要求信号を受け取ると、スレッドを生成し(S10)、スレッドIDをリソース監視機能部16に通知する(S11)。また、PS信号処理機能部14は、記憶部17のリソース使用状況情報18を更新する。

0031

次に、PS信号処理機能部14は、その要求信号(PS信号)に関するサービス処理を行い(S12)、その要求信号を発したユーザ端末2に対して、送信機能部15を経由して応答信号を送信する(S13、S14)。

0032

また、リソース監視機能部16は、定期的に起動し、S4とS11で受け取ったスレッドIDを用いて、記憶部17からリソース使用状況情報18を収集する(S15)。
次に、リソース監視機能部16は、収集したリソース使用状況情報18に基づいて、全体CPU使用率、D信号処理スレッド用のCPU使用率、全体メモリ使用率、D信号処理スレッド用のメモリ使用率を算出し、それぞれの値が、閾値情報19に記憶された全体CPU使用率閾値、D信号処理スレッド用のCPU使用率閾値、全体メモリ使用率閾値、D信号処理スレッド用のメモリ使用率閾値を超えているか否かを判定し(S16)、Yesの場合はS17に進み、Noの場合はS17をスキップする。

0033

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

0034

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

0035

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

0036

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

0037

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

0038

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

0039

次に、リソース使用状況情報と閾値情報の他の例について説明する。図4(a)に示すように、リソース使用状況情報18aとして、分散処理を伴う信号(D信号)の単位時間当たりの処理数を用いることもできる。その場合、図4(b)に示すように、閾値情報19aとして、分散処理を伴う信号(D信号)の単位時間当たりの処理数の閾値を予め設定しておく。

0040

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

0041

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

0042

以上で本実施形態の説明を終えるが、本発明の態様はこれらに限定されるものではない。
例えば、図2(b)に示した「50.0%」などの数字は一例であり、他の数字を採用してもよい。

0043

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

0044

1処理サーバ
2ユーザ端末
3 他の処理サーバ
4保守者端末
11 D信号受信機能部
12 D信号処理機能部
13 PS信号受信機能部
14 PS信号処理機能部
15送信機能部
16リソース監視機能部
17 記憶部
18、18aリソース使用状況情報
19、19a閾値情報
31 表示部
100 処理システム

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

該当するデータがありません

関連する公募課題

該当するデータがありません

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • みずほ情報総研株式会社の「 影響調査システム、影響調査方法及び影響調査プログラム」が 公開されました。( 2019/09/19)

    【課題】複数の情報処理が実行されるシステム内で利用される情報の影響範囲を予測するための影響調査システム、影響調査方法及び影響調査プログラムを提供する。【解決手段】影響調査システム20の制御部21が、ジ... 詳細

  • 三菱電機株式会社の「 制御システム」が 公開されました。( 2019/09/19)

    【課題】センサ構成の変更、制御プログラムの更新等によって処理負荷が増大する状況に確実に対応することができる制御システムを提供する。【解決手段】車両制御システム100は、既設ECU101に対して新設20... 詳細

  • 富士通株式会社の「 制御方法、情報処理装置および制御プログラム」が 公開されました。( 2019/09/12)

    【課題】利用者は、物理マシンを使いたいときに使いたいスペック、機種の物理マシンを使うことが可能となる。【解決手段】情報処理装置1は、物理マシンの使用要求を受け付けると、記憶部に記憶された物理マシンと予... 詳細

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

該当するデータがありません

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ